guiding stops: scheduler does not recover

Yes, I had a 2 second delay set for the run corresponding to the last log I posted.
Do you have a work around for recovery during dither?
Thanks again.

Hm, as a workaround you could set the delay to 0 and do not select the "Abort Autoguide on failure".

Alternatively, you could try to use my fix directly. If you know how to compile from sources, simply add my kstars fork as new remote and checkout the branch "scheduler_restart_guiding_dithering_errors". This works like this:After this, compile kstars as usual.

- Wolfgang

Ah, ok. Is there a new fix today?
It's clear here in Spain tonight so I'm out imaging (hoping we don't lose it on a dither!).
But of course, tomorrow, I'll work out the git stuff and build your branch.
Meanwhile, could you post if the fix (if there is a new one) makes it to master?
TIA,
Steve

Good luck! Here it's raining, so no chance.

I will create a new diff and post, if it has made it into master.

OK, now the change is available on the master branch. I hope it fixes the problem now.

Hi Wolfgang
Perfect; nothing I can do will now stop the sequence
This finally makes ekos' schedule-capture-guide bulletproof!
Thanks so much for your time.
Clear skies,
Steve

Hm, bullet proof is such a strong word

LOL. OK. I'll try harder to break it...
Or maybe, 'The most reliable yet' would be less extreme?!

Hi everyone
Sorry to reopen this but I've the same problem: guide star is lost but capture continues.
I sent a request to help to this list but did not get a reply:
www.indilib.org/forum/ekos/6154-lost-gui...pture-continues.html

I also sent a copy to the PHD2 list and Andy Galasso sent this reply. Maybe this will help to fix the issue?

Hi Steve,

PHD2 is sending EKOS a failure status when settling fails. Settling happens after a request to start guiding or after a request to dither. Here are the relevant entries from your log:

19:36:00.144 00.628 139929404830144 evsrv: cli 0x56227b192f00 request: {"id":449,"jsonrpc":"2.0","method":"dither","params":[5.3,false,{"pixels":3,"time":14,"timeout":90}]}
19:37:30.366 00.000 139929404830144 evsrv: {"Event":"SettleDone","Timestamp":1576694250.366,"Host":"E5430","Inst":1,"Status":1,"Error":"timed-out waiting for guider to settle","TotalFrames":45,"DroppedFrames":45}

and later

21:30:48.251 02.292 139929404830144 evsrv: cli 0x56227b192f00 request: {"id":3580,"jsonrpc":"2.0","method":"dither","params":[5.3,false,{"pixels":3,"time":14,"timeout":90}]}
21:32:19.175 00.000 139929404830144 evsrv: {"Event":"SettleDone","Timestamp":1576701139.175,"Host":"E5430","Inst":1,"Status":1,"Error":"timed-out waiting for guider to settle","TotalFrames":26,"DroppedFrames":13}

Failure of settling would be a good trigger for EKOS to act on to start some recovery process.

In addition to triggering on settling failure, it makes sense for an imaging app to abort a frame and trigger recovery when the PHD2's reported guide star offset value exceeds some threshold. PHD2 sends EKOS the guide star offset for each guide camera frame in the GuideStep and StarLost notification events. The distance value is a smoothed moving average so it is not susceptible to transient spikes or intermittent dropped camera frames. This allows imaging apps to use the offset value as a reliable indication of guide failure or loss of the guide star due to clouds over an extended time. The imaging app should trigger recovery when the distance value exceeds a user-defined threshold. You can choose a threshold value that is a bit larger than your typical guide error. When PHD2 reports a distance value larger than the threshold something really has gone wrong with guiding and the current camera frame should be aborted.

logs: drive.google.com/open?id=1tS7Q_-zN-s4LJpbFkYth-dVN85kKC0EP

Any testing or whatever, just shout.
Thanks for looking and clear skies.
Cheers,
Steve

How stupid of me. I was still in workaround mode.
Thanks and apologies for the noise.