It will definitely be very helpful, since settling failure seems to provoke a chain of events that lead to the behavior. It is not only the 20ms timeframe of the control handover from Scheduler to Capture, but also this concurrency problem that one guiding step drops in after settling has failed. This combination creates the problem.

So avoiding settling failures is a good idea.

But another hint: 6px dithering on the guiding scope sounds huge to me, since on your CCD it should be even 2-3 times higher. I am using dithering with an OAG and use 2px distance, which is as far as I know a standard value.

Wolfgang

Mine is set to 5px. I use an OAG, and my guide cam has smaller pixels than the main cam (2.9 vs. 3.8 ). I don't think that is very uncommon.
I was rather astonished about the really long time it takes to catch that dither back. @Alacant: What guide speed do you use? Have you checked the 'Fast Recenter after Dither' option in PHD2?

I use the PHD2 native driver. The guidescope is not included in the profile for this telescope.
I don't think EKOS has any knowledge of my guidescope. I thought that the dither was calculated for the combination of imaging camera and telescope. ???

i'm using a dslr and a 12 pixel dither is recommended, hence the 6.
Confused...

Imaging telescope 130mm f5
dslr 4.3 micron 5208x3476
Guide telescope 60mm f4
guide camera: 3.75 micron 1280x960 bin 1

I use an OAG with our 254mm f4.7 and the dither seems to adjust with the telescope; the dither remains at 6px as it cannot be set per profile.
But please correct me...

Guide: 0.7x sidereal
Yes, have fast recenter checked.

Cheers

I have to admit, that I am not a dithering expert. But as far as I understand is, that dithering is done entirely on the guiding image, i.e. it shifts the guiding star by 6px. This automatically translates through the focal length ratio between guiding scope and primary scope (in your case 650/240 = 2.7) and the ratio of the pixel sizes (in your case 4.3/3.75 = 1,14), i.e. in your case a 6px dithering results in 6 x 2.7 / 1.14 = 14.1 px.

So indeed it's very close to your target value of 12px. If you are really aiming for a 12px dither, it sounds right, and you can ignore my comment.

I had the same problem Steve describes, but with the internal guider. I also never experienced it before. This is what happened:

[2020-06-24T23:51:46.172 CDT DEBG ][ org.kde.kstars.ekos.guide] - Received guide frame.
[2020-06-24T23:51:46.178 CDT DEBG ][ org.kde.kstars.ekos.guide] - Multistar: findTopStars 10
[2020-06-24T23:51:46.230 CDT DEBG ][ org.kde.kstars.fits] - SEP detected 0 stars.
[2020-06-24T23:51:46.230 CDT DEBG ][ org.kde.kstars.fits] - # #X #Y #Flux #Width #HFR
[2020-06-24T23:51:46.231 CDT DEBG ][ org.kde.kstars.ekos.guide] - # X Y Flux HFR sepSc SCORE SNR
[2020-06-24T23:51:46.231 CDT DEBG ][ org.kde.kstars.ekos.guide] - No suitable star detected.
[2020-06-24T23:51:46.231 CDT INFO ][ org.kde.kstars.ekos.guide] - "Failed to find any suitable guide stars. Aborting..."
[2020-06-24T23:51:46.234 CDT DEBG ][ org.kde.kstars.ekos.capture] - Guiding state changed from "Reacquiring" to "Idle"
[2020-06-24T23:51:46.235 CDT DEBG ][ org.kde.kstars.ekos.guide] - Stopping internal guider.
[2020-06-24T23:51:46.240 CDT DEBG ][ org.kde.kstars.indi] - iOptron CEM60 : "[DEBUG] CMD <:GLS#> "
[2020-06-24T23:51:46.241 CDT DEBG ][ org.kde.kstars.indi] - iOptron CEM60 : "[DEBUG] RES <-348454442028010901#> "
[2020-06-24T23:51:46.243 CDT DEBG ][ org.kde.kstars.indi] - iOptron CEM60 : "[DEBUG] CMD <:GEA#> "
[2020-06-24T23:51:46.243 CDT DEBG ][ org.kde.kstars.ekos.scheduler] - Guide State "Idle"


The scheduler was running unattended.
The guide star was lost, frames were dropped and then the guider was stopped.
However, the scheduler continued and captures also continued until the meridian flip occurred at ~ 4.15 AM. It looks like that completed fine, but then the capture sequence did not restart as the Capture module was probably waiting for the guider, which, however, had shut down hours earlier.
The scheduler finally terminated shortly before 5 AM when twilight triggered it and the mount parked normally.

Here the link to the (lengthy) log: www.dropbox.com/s/slzkkb53h3sxj0i/log_18-37-16.txt?dl=0

I am only using the internal guider, so this problem is not PHD2 specific.

Hi,
I took a look into your logs. Its a similar problem, but not the same. There is a weakness in the status model of the internal guider that switches to the state GUIDE_IDLE if it was re-aquiring a guiding star instead of GUIDE_ABORTED. In this case Capture simply ignores it and does not try to restart guiding.

I would recommend to change the way how use the scheduler. Your schedule job contains a single capture job with 50x120s Ha. If you would use a 1x120s capture job and let the scheduler run it 50x, the scheduler would have recovered guiding after each capture.

Nevertheless, it's a bug, but I can't promise how fast I can fix it. If we have a volunteer, I could give guidance.

Wolfgang

I just pushed a fix for reaquire, it should be marked ABORTED and not IDLE.

Hi everyone

Does this fix my case with PHD2 as well as the internal guider?

TIA,
Steve

No that was for internal guider, not sure what's going on with PHD2. Eric is working on a few issues there.

Fixing the issue for PHD2 needs a more complex rework and thorough testing. I have it on my list, but I would expect fixing it won't within the next days.

So please concentrate on avoiding the settling error as a workaround.

Wolfgang

Hi Wolfgang, everyone.
I've no problem doing the testing.
Cheers,
Steve