330 - shutdown with lost guide star

I’m not sure about this change. I lost a guide star due to an aircraft trail and the entire observatory closed down. I always assumed that a shutdown was associated with unsafe conditions. It feels a bit drastic and for a slight problem that lasts a few minutes, it forces me into an entire warm up- cool down restart process. I’m under the flightpath for London and Southend airports… :frowning:

I do not know what other’s feel and I wonder what prompted the change in logic…

I had the same thing happen with 330, apparently due to one cloud. I’ll investigate if I can reconfigure recovery not to over react to try again right away. Sequence recovery seems to be very limited. Wish it had an option to just abort the current frame and start a new frame.

To be clear, SGPro does not consider a star lost message from PHD2 unless it receives an actual “StarLost” message AND the guider is more than 50 pixels away from where it should be. In this case, you would absolutely want a full recovery. I know you are saying that planes and clouds are causing this, but I’d need to see logs to determine if there is an issue.

This is typically not good enough. If you are taking 20 minutes subs and you fail at minute 18, we really need to consider restarting this like we would if we moved on to a new frame. You may need to meridian flip, you may be too close to meridian to try again, you may need to temperature compensate or auto focus and so on… In terms of recovering, this is not supposed to be a situation where we can say, “just try again” without adjustments. The current frame is no longer on target (there is at least a 50 px error), so we re-center and we need to get a new guide star (so we recover the guider). In SGPro 4, we may consider adding some kind of tolerance here that will perform a simple restart if you are less than one minute (or something), otherwise will recover and ensure the restarted frame is actually good. Maybe? We need to think about this…

OK - got it. I think I was unlucky. PHD2 was throwing an unusual tantrum and in reality, my tracking was good.

Ken:

I just had this event happen to me twice.

The star was lost, and auto recovery was not invoked as it should have been. It looks like there is a logic issue where SGP doesn’t invoke the recovery because it detects the sequence is no longer running. Please take a look at Line 69180 onward in my attached log file. Here are the pertinent parts as I see them:

[11/01/19 04:24:39.018][DEBUG] [PHD2 Listener Thread] Sending Notification: Warning - Guide star lost!
[11/01/19 04:24:39.325][DEBUG] [Guider Camera Thread] Guide star was lost!
[11/01/19 04:24:39.325][DEBUG] [Guider Camera Thread] Aborting sequence: Guide star lost
[11/01/19 04:24:39.365][DEBUG] [Camera Thread] FLI Camera: abort message received…
[11/01/19 04:24:39.365][DEBUG] [Camera Thread] FLI Camera: End exposure…
[11/01/19 04:24:39.366][DEBUG] [Camera Thread] FLI Camera: read data (16 bit)…
[11/01/19 04:24:39.366][DEBUG] [Camera Thread] FLI Camera: reading lines…
[11/01/19 04:24:39.389][DEBUG] [Camera Thread] SGM_CAMERA_CAPTURE complete…
[11/01/19 04:24:39.453][DEBUG] [Sequence Thread] Set sequence abort
[11/01/19 04:24:39.456][DEBUG] [Sequence Thread] Aborting exposure…
[11/01/19 04:24:39.457][DEBUG] [Sequence Thread] Event detects that recovery is needed because guider reports the guide star was lost…
[11/01/19 04:24:39.457][DEBUG] [Sequence Thread] RunEvent recovery start…
[11/01/19 04:24:39.458][DEBUG] [Sequence Thread] Recovery mode invoked when no sequence is running…
[11/01/19 04:24:39.458][DEBUG] [Sequence Thread] RunEvent recovery failed! Sequence abort…

I’d appreciate your attention to this at your earliest convenience. Thank you!

Best Regards,
Ben

sg_logfile_20191031164912.zip (495.4 KB)

Yep… this is timing issue. Works some times and not others… I’ll clean this up.

1 Like

Thank you, Ken!