I would be really pleased if someone with detailed knowledge can confirm the process EKOS follows to manage a period of passing cloud. With my setup I often see a few frames with significant drift during cloud and at the far side when visibility returns there has been a significant shift in the image making stacking or my case exoplanet photometry difficult or impossible to continue after cloud interruption.
In the above example, prior to the set of 4 A images, all images are good.Set A images are considerably fainter as cloud partially obscures but frames remain un-shifted and in correct location.The 3 set B images remain considerably fainter and exhibit significant shift especially the last 2.Set C images still faint and remain about 8 min out of position.Set D images at roughly pre cloud brightness and remain out of position. There after images are out of position.I notice the alignment module wasn't called after this cloudy interval so how is guiding restored pre cloud position?The impression (only an impression) is that when guiding is suspended due to loss of stars, the mount isn't set to default sidereal rate but carries on with some commanded movement so significant drift occurs until guiding re-starts. I would have thought when guiding is suspended or aborted the mount should be set to sidereal rate so it carries on to within the accuracy of its alignment and motors and is then re-aligned when cloud dissipates. Obviously guiding is re-aligning all the time to keep guide stars in position. When guiding is suspended due to cloud and re-starts, if a shift has happened it will pick a different set of guide stars so not sure how it can re-align?Next clear night will simply put the dust cap on for say 15 minutes when guiding then take it off and see what happens.These comments illustrate my lack of understanding on how it should work and would appreciate some help. Thanks.
I know that when there are clouds that mask the guide star and its is not visible, Ekos send unusefull pulses tha move the field and cause a very high RMS ang a capture abort. In these case I stop all and wait
No (re-)align seems to have been triggered.
To remain on target, cloud or no cloud, try setting the 'Verify captured image position every x frames' and the corresponding 'Rest pipeline...' values.
Cheers and HTH,
Steve, I have been turning off in-sequence checks because I was trying to avoid re-focusing as I have a problem with that, but you are right I had verify capture set to 0 frames and a large re-set pipeline value of 30 mins. From what you say the answer to my question is: Set the EKOS Alignment values so Alignment module is called after a period of cloud otherwise guiding continues at current location which may have drifted away from target location.
Should I set verify frames to 1 so it checks immediately and set the image delta to 0.3 as I usually set my-realign accuracy to 20 secs?
There is an underlying issue where the mount goes walkies (star trails) when guiding is suspended. This doesn't happen every time but quite often. The drift each time is different lengths and different directions but the pattern is always the same as below. Dots and lines in one direction. Examining the trailed images it is clear the problem happens when the guide RMS goes very high.
This could be because my mount has developed a fault so will check that out on next clear night taking a long exposure un-guided.
What does "re-set pipeline" actually mean?
"set verify frames to 1 ... image delta to 0.3"
If that's good enough for your photometry, yes. A value of 1 will indeed check alignment after every frame.
Our policy for stuff like this is to change nothing in software.
Check instead, in this order, using substitutes of known performance:
-dismantle/clean/inspect/re-grease/adjust the mount
'What does "re-set pipeline"'
Don't know, but IAC, the default value of 30 arc minutes perhaps isn't as intuitive as it could be.
Maybe a more meaningful phrase would be:
're-align if the captured image position varies more than x ...'
And change units from arc-minutes to arc-seconds.
There are several of us that have posted similar issues. When guiding is suspended due to clouds, it seems that "unpredictable results may occur" after the clouds pass. I don't know why EKOS sends extraneous pulses when guiding is suspended... but it does it frequently in my setup.
I tried using the check alignment every X frames. I used every 10 frames, but you can use a smaller number if you like. When it works, it's awesome. Just beware... I've had two nights where EKOS checked alignment and started the alignment process, finished, but never started guiding/capturing again. I posted the log on here, but no explanation/answers.
As I posted on another related thread... I wish that the KStars/EKOS team would pause working on new features for a bit and work towards coming up with a more resilient cloud recovery process.
Mounts: Sky-Watcher EQ6-R Pro, Meade LX85, Celestron NexStar Evolution Alt/Az
OTAs: Celestron 8" Edge HD w/Celestron Focus Motor, Meade 80mm APO Triplet Refractor w/ZWO EAF
Cameras: ASI533MC Pro, ASI183MC Pro, ASI224MC, ASI120MC-S, ZWO ASI290MM
Raspberry Pi 4 with Stellarmate OS, MacBook Pro
Steve, to be clear, are you saying the interface label for image delta is incorrect and it should read seconds and not minutes? Is it better if delta was given in seconds as minutes is a large value for imaging?
Should software be changed to at least give an accurate phrase. Even if underlying guide software has no errors it is really import for the user interface to be clear and precise backed up with on-line documentation. Writing good documentation is a real drag but really important.
I check cables and power supply on a regular basis and will check the mount as that could be the cause. At the moment it's clear the guiding RMS goes very high > 1000 as cloud starts to pass through and I see trailed images with mount going out of position. Turning on verify image position and setting a delta should help and put mount back to correct position but an unnecessary action if mount was left to continue guiding at sidereal rate and not go out of position.
Let me do some checks please and I will report back with results.
"...are you saying the interface label for image delta is incorrect and it should read seconds and not minutes..."
No: Arc-minutes is correct.
Yes: I'm suggesting, as well as a change in phraseology, a change of unit to arc-seconds would make more sense for imaging.