Frame restart logic question


Ken - I am having unexpected frame restarts in SGP and I’m trying to establish the root cause. I use a well-behaved Paramount MX with ProTrack. I have traditionally used PHD2 and standard hysteresis algorithms, with 8-ish second exposures and a SGP frame restart of a few pixels.

I changed the algorithm to Z-filter in PHD2, with 2s x4 setting. The outcome is that the real-time graph thrashed about with seeing but the actual guider corrections were fewer and smaller.

As soon as I used Z-filter, however, - I had several frame restarts.

So - my obvious question is, how does SGP establish a frame restart? I’m wondering if it is using the last centroid error measurement and being caught out?

If we receive a “Star Lost” message from PHD2 that will restart a frame. If you’re not seeing that in the SGP log then I’d need to checkout the logs to see what else it could be.


Jared. I’m confused. There is a setting in the SGP Auto Guide tab that triggers a frame restart if ‘guider distance’ is over a set number of pixels. I’m trying to find out what SGP is measuring as ‘guider distance’. If it is the last PHD2 error measurement then potentially, with the filtered PHD2 algorithms, it would be too reactionary. I’m assuming that the pixel error set in SGP should be immune to the guider algorithm - as it is a frame quality arbiter.

The trigger for that is the error value sent directly from PHD2. We don’t do any smoothing or anything with it.


Thanks Jared. Is SGP reading the RADistanceGuide and DECDistanceGuide parameters or the DistanceRaw ones? The PHD2 guys says the DistanceGuide measures are the interpreted error through the PHD2 guiding algorithm (so is effectively filtered to some extent).

I’m just trying to eliminate potential causes of an unexpected frame restart when the guiding was doing really well.