Star Lost and Sequence Ended without Recovery - beta 343

Had the opportunity to test beta 343 last night. Unfortunately fog moved in not long after I started. The sequence seemed to end on PHD2 ‘star lost’ without going through recovery (prompted to end sequence right away). Had seen this a couple times before with earlier betas - however I also seem to recall others bringing this up and that it had already been resolved?.

Double checked that recovery mode was enabled (but always possible that I screwed things up in some other way!). Log/sequence attached.

Also had situation again last night where I had to reboot the PC in order for SGP to run (before rebooting, SGP would throw up splash screen and then disappear/die). First time this happened in a while.

sg_logfile_20191106010501.txt (903.7 KB)


That’s unfortunate. I had raised the same question in beta 330 and Ken said that it had been addressed in beta 339. Hopefully it gets resolved soon because it is a pretty critical bug.

Had something like this earlier this morn doing a simulation run in .343.

While the simulation was running I popped into the PHD2 screen while
a simulation integration was in progress, stopped guiding, clicked on a
blank part of the image and restarted guiding. Almost immediately PHD
reported ‘Lost Star’ in the bottom left bar, when SGP got to the dither, it
threw up a box in the lower right showing a Dither error happened and
then just continued regardless as PHD 2 sat there not guiding. The error
box on the lower right of SGP came up every time it tried to dither until
the sequence completed.



Please be patient. This feature is brand new (recovery mode for guider star lost) and while these bugs appear to be similar, they have all been different. It will stabilize.

This particular one has been addressed and was specific to exactly what the sequence was doing when it received the star lost message.

1 Like

Thank you, Ken. I do appreciate all the recent development, especially the improved focus routine. However, stability of acquisition is paramount. I have already lost two half nights of imaging to this bug because of a passing cloud.

The recovery on guider star lost was not a problem before the recent betas. I think SGP would just continue imaging and let PhD2 do its thing if it lost the guide star, including finding a new guide star. Triggering the whole sequence recovery process for a few seconds of lost guide star may be a bit draconian.

I hope I don’t sound ungrateful or negative. I love the SGP philosophy and have no interest in going anywhere else. Just providing feedback, that’s hopefully useful.



I run unguided so have no issues with PHD2. Recovery worked fine for me when I had 2 failures to reach my requested 30 pixels. Ran all last night with 343 perfectly. Two scopes, 3 targets, 2 flips, 45 auto-focus runs. All ran perfectly.

Please see here: 330 - shutdown with lost guide star

It should be noted that PHD2 does not find a guide star on its own when it is lost. It needs intervention and it gets this in the form of recovery by SGPro.

The amount of time a guide star has been lost isn’t particularly relevant… a star lost message with a significant guider error is what we key off of to trigger this event.

Thank you for the reference to the previous thread. In that thread you mentioned:

Are the 50 pixels image pixels or guider pixels? Image scales are typically significantly different between the two. Assuming it’s 50 guider pixels, does it rely on the last available position? I have never seen a 50 pixel guide error in PhD2. I don’t understand how that condition is to be met.

As an example, I am attaching the last few minutes of the guide plot when the sequence (v330) was terminated because of star lost. You can see that the maximum error was never larger than 1.7 pixels or so.

The distance is a smoothed average of the distance between the guide star and lock position in pixels. While I realize 50 pixels is not ideal for everyone, it is likely safe to say that this value is not “ok” for anyone either. When a guide star is truly lost, PHD2 can see this kind of error pretty quickly (and is, in fact, how we arrived at the value in the first place). We have found, that while PHD2 does indeed have the capability to hold enough information to calculate scale, it is often not filled out… so we use a static pixel value that should be safe enough for all typical scales.

In terms of your specific situation, we would need to see logs of both PHD2 and SGPro that show a guide star lost event. I don’t see any issues in the code that generates the event, but their could be…

@Ken, I ran v343 tonight for several hours starting with perfectly clear skies that turned increasingly cloudy. Everything worked flawlessly. Lost stars triggered recovery and the whole cycle went through several times without any manual intervention. Thank you!

1 Like

Similar experience for me last night w/345. Clouds seemed eager to participate in testing not long after I kicked off imaging (they are pretty swell like that :grinning:). No issues with recovery process when PHD2 lost guide star.