Palmito replied to the topic 'New to Astroberry and weird problem' in the forum. 3 weeks ago

Yes I would have thought the same. But maybe not.

Considering your pixel count I doubt, but I could be wrong, it will be useful for your case, but with the ASI6200 I had to increase allowed memory for INDI drivers.

On astroberry I edited:

/var/www/indiwebmanager/indi_server.py

and increased memory to 168MB (default was 100):
def __run(self, port):
        cmd = 'indiserver -p %d -m 160 -v -f %s > /tmp/indiserver.log 2>&1 &' % \
            (port, self.__fifo)
        logging.info(cmd)
        call(cmd, shell=True)


Read More...

Palmito replied to the topic 'New to Astroberry and weird problem' in the forum. 3 weeks ago

FITS viewer performs quite a lot of things when displaying an image.
The 5D mk4 is 10 bit, so I guess the bit depth is the issue.

I had the same issues you had, but only in the FITSViewer window. But the preview in the focus tab works works flawlessly even in 16bit RAW ;-)
So you should be able to focus from there without changing to 8bit RAW.

I like to monitor my subs while they are acquired. As a workaround I simply open fits files from the file browser.
Beware it will open a second instance of KStars, so you might need to extend your swap an zram partitions ;-)

Read More...

Palmito replied to the topic 'New to Astroberry and weird problem' in the forum. 3 weeks ago

wvreeven wrote: In his original message he says RPi 3B+ so 1 Gb.


Sorry about that, I thought revision 3B+ had several memory configurations, my mistake....

Read More...

Palmito replied to the topic 'New to Astroberry and weird problem' in the forum. 3 weeks ago

Hi,

How much memory does your Pi have? I suspect 1 or 2gb, and FITS viewer is quite demanding.

I am using a 4gb RPI4 and had issues (though my images are 120mb). I have managed to get FITS viewer running by adding maximum swap and zram.

However I noticed it slowed down my sequence waiting for image to load. So I have completely deactivated it, which I advice on a RPI.

Read More...

Geez I am too tired :-D The option is in the control tab and it was off.

So my issue is resolved \o/

Cheers and CS

Read More...

Hi All!

I believe I have encountered dew/ice build-up.

The ASI6200 has an integrated anti-dew heater. As per ZWO description it can be deactivated through software:

ASI6200MM Pro comes with the polyimide heater that can avoid any dew problems.
The anti-dew heater which completely fit the protective window will heat it to avoid any dew problems.
The heat anti-dew heater power is around 5W and can be turn off in software to save power


I haven't been able to find this option in the INDI control panel. Does it exist or does it need to be developed? Does anyone know if it is off by default?

Read More...

Many thanks Jeremy I just tested your code successfully.
Nice one ;-)

Read More...

Hi,

I have successfully tested your PR. There was one issue, the mount status changed to "Slewing" instead of "Parked" after parking completed.
Once I had indi running from source I spent time investigating on how to fix it. Took me long enough, but sleepMount() seems to cause the mount to go back into slewing.
I left you a comment on your PR.

Cheers!

Read More...

Thank you so much J.!

I haven't coded C++ in over 20 years, it would have taken me so much time, I am so grateful for your effort!

Yes, I'll pull source on my RPI, compile and test it. It is the least I can do ;-)

Read More...

Ok, so I came up with a quick and dirty fix. Very dirty.
I only share it for educational purposes or if someone like me is stuck...
I tested it successfully last night, but use it at your own risk ;-)

So basically what I did is write a small Bash script that is cron'd to run every 5min:

  1. It checks if the mount status is parked and not tracking, that could mean it is either truly parked or slewing to its parking position
  2. Then it waits to see if the mount status changes to parked and tracking
  3. If it is, it issues a park "command"
printlog() {
  timestamp=$(date +'[%d.%m.%Y %H:%M:%S]')
  echo "$timestamp $*"
}


printlog "Waiting 10s checking if mount parks"

indi_eval -t 10 -wo '"Losmandy Gemini.TELESCOPE_PARK.PARK"==1 && "Losmandy Gemini.TELESCOPE_TRACK_STATE.TRACK_ON"==0'


printlog "Mount is parking or parked: Waiting 60s checking if tracking restarts while parked"

if indi_eval -t 60 -wo '"Losmandy Gemini.TELESCOPE_PARK.PARK"==1 && "Losmandy Gemini.TELESCOPE_TRACK_STATE.TRACK_ON"==1'; then
  printlog "Tracking restarted while mount parked: Reparking"

  indi_setprop "Losmandy Gemini".TELESCOPE_PARK.PARK=On
fi

printlog "Mount parked"

exit 0

PS: Especially for resource usage, I should be adding an if condition on first indi_eval, but haven't tested it yet...

Read More...

Yesterday, I also noticed that when slewing from park to a target the mount control window showed "Parking" during the slew and then switched to "Tracking".

Read More...

Many thanks for your feedback Magnus!

Read More...

Hi,


I have ran into an issue since a week or so. I am not sure if it is consecutive to the update 1.6 of indi_lx200gemini but I suspect it.


I can reproduce it with the following steps:
- I create a new schedule which only contains one flat job.
- The flat job has Park Mount checked in Calibration options in the CCD tab.
- Unpark the mount and ensure tracking is on.
- Start the scheduler


What happens is:
- The mount slews to its parking position.
- In the Setup tab Capture status is "In progress" and Mount status is "Parking"
- Once the mount reaches parking position Mount status goes to "Tracking"
- The flat job never starts as it believes mount is not parked.
- Using the hand controller I checked and the mount is actually parked.
- If I click on Park in the mount tab, the job starts immediately.


Going further into logs I noticed:
2020-09-16T05:46:40.730 DEBG org.kde.kstars.indi Losmandy Gemini : "[DEBUG] CMD: <:Gv#> "
2020-09-16T05:46:40.730 DEBG org.kde.kstars.indi Losmandy Gemini : "[DEBUG] RES: <N> "
2020-09-16T05:46:40.731 DEBG org.kde.kstars.indi Losmandy Gemini : "[DEBUG] CMD: <:Gv#> "
2020-09-16T05:46:40.733 DEBG org.kde.kstars.indi Losmandy Gemini : "[DEBUG] RES: <N> "
2020-09-16T05:46:40.734 INFO org.kde.kstars.indi Losmandy Gemini : "[INFO] Slew is complete. Tracking... "

Which shows me the mount reports "NO_MOVEMENT", twice.

Looking into lx200gemini.cpp source.
"Slew is complete. Tracking..." makes me believe either the condition TrackState == SCOPE_SLEWING is not sufficient and should be complemented with a check on ParkingState, or that it just has a wrong value for some reason I haven't figured out yet.


Sorry I am running on RPi and didn't have the time to compile/debug and create a PR.


Has anyone else been having this issue, or am I missing something?


Many thanks,

Cheers,

Carl

Read More...