What happens when PHD loses guide star?


#1

[Edit: Updated thread title to reflect new info below]
When the SGP log notes that “guider reports that it is not guiding,” does that just mean that PHD2 had lost the star at the instant that it was polled by SGP? If so, what happens then? I was guessing that PHD2 keeps getting polled, and eventually SGP assumes guiding can’t be recovered, and aborts, but testing tonight suggests that SGP aborts almost immediately. Is that correct?

I had a marginal guide star at one point this morning - mag 11.5, best I could get on a target in Coma Berenices with my OAG - so it was being lost occasionally by PHD2, but was always recovered. If anyone wants to look, the SGP log and the PHD2 guiding and debug logs are zipped up here. The sequence was aborted around 4:07 am.

Edit: I checked the SGP and PHD2 debug logs in more detail, and found something interesting. At 04:07:25, SGP sends a dither request. At 04:07:32.037, PHD2 logs that it lost the star. At 04:07:32 SGP sends a status request, and notes that it got a 4 (not guiding) back. It immediately sends another status request (in fact, in the PHD2 debug log, these status requests show as being only 1 millisecond apart). Of course PHD2 hasn’t recovered the star yet, and reports another 4 back. SGP then aborts the sequence. Only 1 millisecond after the second status request, PHD2 recovers the guide star. 35 milliseconds later, SGP sends a third status request (I’m not sure why), and gets a 3 (guiding) back. But the sequence is already aborted. I saw very similar behavior in a guiding run early tonight as well.

Is this normal behavior, to give PHD2 effectively only one chance? I had understood that SGP waited for a bit to see if the star was recovered, and only then gave up and aborted.


#2

Do you have Sequence Recovery turned on?
http://www.mainsequencesoftware.com/Content/SGPHelp/SequenceGeneratorPro.html?Sequencing.html


#3

I did not have recovery mode on at the time, but I don’t think that is related to this issue. My understanding is that recovery mode will only work when PHD2 reports, after five minutes of trying, that the guide star has not settled. That means that the guide star position is known, but it is more than 2.6 pixels off-center.

In my case, PHD2 reported that it was “not guiding” - ie, response 4 to GetStatus. I thought SGP would give PHD2 time (five minutes?) to recover the star, but in my examples it made two checks in two milliseconds, got response 4 both times, and then aborted.


#4

I’m not sure what codes are passed between SGP and PHD2 at what times. However, I know that when I lose my guiding because of clouds, SGP will try to recover and continue guiding for up to 90 minutes - assuming Sequence Recovery is turned on. I think its worth trying.


#5

It’s certainly on now. The thing that I’m wondering about is that according to the documentation, SGP allows five minutes for a guide star to settle. If not settling (error > user set limit) and lost guide star (getstatus code 4) are supposed to be handled the same way, why didn’t SGP wait five minutes before aborting? I’d prefer that it keep looking rather than swtiching straight to recovery mode, which means that it won’t check again for another ten minutes. Hmmm.

Kevin


#6

That is legacy PHD1 behavior. PHD2 is far more descriptive about what is happening. We do indeed wait five minutes for the guider to settle, but star lost messages are now handled instantaneously. When recovery starts, the first attempt starts in 60 seconds, then if that doesn’t work separates subsequent attempts by 10 minutes to allow for environmental conditions to change.


#7

Thanks Ken. So I’ll leave recovery mode on, and hopefully that will solve this.


www.mainsequencesoftware.com