Recovery behavior ideas

I’m watching my two systems trying to recover from a cloud front. In one case, the guidestar was lost and in the other, it was trying to do an AF routine, when cloud struck.

In the first case - even though it was a guidestar that triggered recovery, SGP does not look for the error condition to go away before recovery - it proceeds through a sequence of center and focus and then tries the guider - repeat. Another approach would be to look for the condition that caused the issue to go away before attempting a restart?

In the second, it is trying to autofocus a blank canvas. I think it is on its 4th iteration and has just now lost the guidestar too. I am not certain where the focuser ended up. There may be an opportunity to do something more with the AF failure - no stars were detected, but it carried on regardless.

In both cases, if PHD2 exposes a star intensity (SNR or star mass), there might be something that could be done to simply monitor until conditions reach a satisfactory level before attempting to restart?


SGPro functions in a different manner. It does not listen for a noisy star lost signal and then delay action until it be sure of an actual star lost event, but rather defines a decently high threshold for considering a star to be lost. This threshold should be high enough that all systems are reasonably sure that there is no reason to wait to see if there is a potential for self-recovery. Right now, SGPro considers a star as lost if it gets an actual StarLost message from PHD2 (not an uncommon event) AND the distance from the guide star is greater than 50 pixels. These seems undeniably “lost”. If you are seeing different behavior, it is a bug and logs would help in this case.

Thanks for the feedback. SGPro 3 saw an overhaul in analysis of AF data and SGPro 4 will see an overhaul of the process used for collection of data (“smart focus” so to speak). Included in this will be better detection of impossible conditions.

Thanks. I rarely watch events in real time (I can blame lockdown) and it might have been doing this sort of thing for years without me knowing. I suspect the coding is easy compared to working out a logic that works for everyone.
I have seen some other approaches that assemble a set of instructions and decisions. It seems ideal for the developer as they do not have to make the hard choices. Great for some, if you know what you are doing and have considered all failure modes but for the less experienced, a minefield.