2.4 Beta - Centre on Sequence Start locks after PHD2 2.4 Calibration

Sequence Generator
1

Hi

This evening, I’ve tried to start a sequence on “full automatic” i.e. Start Camera Cooling on Sequence Start, Centre on Target Start, Auto Focus on Sequence Start and it works fine - autofocuses, connects to PHD2 and calibrates correctly…then stops with the message “Waiting for guiding to resume”.

A link to the log file is attached. Dropbox - Error

Any help would be appreciated please.

Cheers

Steve

2

I tried a variant - I stopped PHD2, aborted SGP. I had dither disabled. Auto slew/center and focus.
Ran Sequence, it started ok -

PHD2 was previously calibrated, I just stopped it - does SGP actually tell PHD to calibrate?

I normally have dither enabled and 0.3"settling criteria. Next time I will enable it to see if that triggers an issue.

[edited] I also thought about the guiding pause options: With dither disabled, the settling criteria did not kick in (just read the instructions and it is supposed to occur after a dither and 'pause during autofocus" - I had guiding paused during focus, the mount drifted slightly but it carried on with the first exposure without the guide trace being near zero - (just checked the log file - PHD told SGP it was settled so this is not an SGP issue)

3

SGP just tells PHD2 to start guiding. PHD2 will calibrate at the start of guiding if you are not calibrated already.

Andy

4

Steve,

It looks like the calibration ran longer than expected due to guide camera frames being dropped due to star mass change. This usually indicates passing clouds.

[19/12/2014 17:36:16] [DEBUG] [PHD2 Listener Thread] PHD2 Received: {“Event”:“StartCalibration”,“Timestamp”:1419010576.908,“Host”:“OBSERVATORY”,“Inst”:1,“Mount”:“10micron GM1000HPS”}
…
[19/12/2014 17:37:13] [DEBUG] [PHD2 Listener Thread] PHD2 Received: {“Event”:“StarLost”,“Timestamp”:1419010633.462,“Host”:“OBSERVATORY”,“Inst”:1,“Frame”:7,“Time”:-9223370617844142.000,“StarMass”:28437,“SNR”:77.73,“AvgDist”:3.95,“ErrorCode”:5,“Status”:“Star lost - mass changed”}

eventually the star was lost altogether:

[19/12/2014 17:42:04] [DEBUG] [PHD2 Listener Thread] PHD2 Received: {“Event”:“StarLost”,“Timestamp”:1419010924.151,“Host”:“OBSERVATORY”,“Inst”:1,“Frame”:34,“Time”:-9223370617843852.000,“StarMass”:0,“SNR”:0.00,“AvgDist”:100.00,“ErrorCode”:2,“Status”:“Star lost - low SNR”}

So basically calibration was stuck waiting for the star to reappear.

Later on, SGP disconnected from phd2

[19/12/2014 17:55:03] [DEBUG] [PHD2 Listener Thread] PHD2 connection terminated…
[19/12/2014 17:55:03] [DEBUG] [PHD2 Listener Thread] Unknown exception! Object reference not set to an instance of an object.

and seemed to get stuck waiting for guiding to start even though it was disconnected from phd2. Ken and Jared will need to look into this part.

Andy

5

Thanks for your replies everyone - the calibration did take a long time due to clouds causing “star lost”, but it completed calibration and started guiding. SGP remained stuck despite PHD guiding well. I terminated the sequence after a few minutes and SGP reported that the sequence had ended before guiding had settled. It was unfortunately too cloudy to run a repeat tonight.

6

I just had a filter change, autofocus and guider pause. On resume, I saw the message flash up in SGP that the tracking error was 0.1 and it started the next exposure. The star in PHD2 was completely off and took 4 more guider cycles to center. I’ll post something on PHD guiding forum.

I think the issues are connected: when you look at the PHD2 trace and the reported error in SGP, I often have a trace that is less than 0.25 pixels off and the error in SGP is reported at 0.8 or more. It might be that the algorithm to work out this error has a flaw that either causes SGP to start prematurely or not at all.

7

I think you’re right Chris - or at least there’s an issue of mis-reporting between PHD2 and SGP 2.4. I started imaging on the 15th and SGP started imaging before the guider had settled (<0.3 >4secs) … and it took a few cycles to get on track. I thought it was user error until I read your post. I can’t see anything on the log.

I also noticed that the PHD graph as intermittent (stayed blank for a long time after a “clear” and was slow to update during the session)

8

I don’t think this is a SGP 2.4 issue. I did some more investigation over the night. I have a clearer picture now (and head). PHD is clearly putting the tracking errors into a low pass filter before shipping the value to SGP. I found three potential issues with this approach:

  1. After a pause command to PHD2, it does not appear to clear out the filter, so it carries on after the resume with the old averaged tracking error, causing SGP to start the next exposure. I only noticed this when I turned off dither which somehow resets the PHD2 output.
  2. The settling delay in SGP needs to be used carefully. I have 0.3" and 1 second. SGP sends repeated commands to PHD2, which dutifully responds with the same value. My PHD2 exposure time is 5-8s - so in reality, the 1 second SGP setting has no meaning. It would need to be longer than the exposure time in PHD2 to do anything different than a simple one-off threshold.

3)The low pass filter in PHD2 is also delaying the onset of exposures after a dither. I have visually monitored the star position in PHD2 and its tracking graph and it is always hitting the target value sooner than the report sent to SGP. I’m guessing PHD2 has to have about 3 exposures to be within the settling threshold for it to report as such.

9

Thanks Buzz - that makes sense. I’m using 6s exposures and a 4s delay in PHD2, and a 4s settle time in SGP. I think I’ll try a 15s settle time - which should guarantee at least two PHD images are acquired to confirm settling.

10

Buzz,

You are exactly right, there is a filter in PHD2 and it does get reset after a dither, but not after a pause/resume. That is a bug;we’ll fix it in the next development build of PHD2.

Andy

1 Like
11

Thanks Andy for the acknowledgement- glad to be of service