Problems with running a sequence and Phd2 last night


I was collecting images last night for a mosaic with each panel consisting of its own target. Everything was going well initially but later in the evening around 10:30 pm in the log, when trying to restart guiding, PHD keep trying to re-calibrate. It would successfully re-calibrate and then when SGP was trying to re-start the guiding again it would again start a re-calibration instead of just guiding. I had to abort the sequence, go into phd and revert the calibration to the last one saved and then restart the sequence and it would then work fine again. At some point later in the night (1:30 Am or so) it happened again and again I had to abort the sequence and restart it.

I’m using PHD2 dev 7

Any thoughts?





The log shows that SGP is directing PHD2 to re-calibrate. Have you selected the option “Re-calibrate auto guider when target changes”?



I"m at work right now so I’ll have to check later, but the funny thing is it changed targets numerous times throughout the night and only attempted re-calibration twice. I guess it’s possible that it’s checked for only those two instances, but I certainly didn’t knowingly do so.

Also, even if it did tell phd to re-calibrate, shouldn’t it go on to start guiding after the calibration was done? It didn’t do that, it kept re-calibrating like it was in a loop.

Let me clarify that. It would finish the calibration then start guiding but when I clicked “retry” in the SGP recovery box it would immediately start another re-calibration. Only aborting and restarting the sequence got it to work correctly again.


I have now checked and confirmed that the option to re-calibrate on target change was not checked on any of the targets.

Any other ideas as to what may have happened? At this point is there any reason to believe that updating either or both Phd and SGP to the latest betas would help this situation in any way?


I would need to the PHD2 debug logs so I can correlate a specific event in SGPro with the request to re-calibrate.


I believe these are them. There are some others of the same date that are very small. If you need those too please let me know.


Thanks. @Andy can you remind me what a calibration start in the PHD2 logs look like? I would like to see what SGPro did just before that.


Ken, I sent you an email.


First thing, wondering if you were able to figure out what happened?

Second, given what happened I figured it would be wise to invest in the notification system, which I did this morning. Unfortunately I cannot get it to work.

I’m using AOL, I know I know but I’ve been using it since 1988 and it’s hard to give up, anyway I looked up the settings which indicated the outgoing server address was set to port 587. Under user I placed my email address. I tried with SSL both on and off but I cannot get a test email through. the error I get is:

Mailbox name not allowed. The server response was 5.7.1 Sender address rejected: not owned by user “my email address”

I also tried to configure text messaging. Based on the help file, I’m a little confused if this is implemented or not.I have att and found I should use but I’m not sure what I should fill in for the server info. Is it still the aol server info or is it an att server info. Sorry but I’m just not very familiar with setting stuff like this up. I read the help file and searched the forum but I still cannot get this working.



Here is the actual screen shot of the settings and error message.

Meridian Flip failure : PHD Did not settle, Additional Text in JSON

There are a few things going on in this thread now…

The Original Failure

@Andy I have not done any testing with dev7, but this is the first time I have seen this:

[11/29/2015 10:20:56 PM] [DEBUG] [PHD2 Listener Thread] Could not process PHD2 input: “{“Event”:“SettleDone”,“Timestamp”:1448853656.823,“Host”:“HOMEPC”,“Inst”:1,“Status”:0}{“Event”:“GuideStep”,“Timestamp”:1448853656.824,“Host”:“HOMEPC”,“Inst”:1,“Frame”:3,“Time”:9.530,“Mount”:“Driver for telescope connected through TheSky”,“dx”:0.071,“dy”:0.112,“RADistanceRaw”:-0.127,“DECDistanceRaw”:-0.040,“RADistanceGuide”:0.000,“DECDistanceGuide”:0.000,“StarMass”:95948,“SNR”:37.65,“AvgDist”:0.08}” : Additional text encountered after finished reading JSON content: {. Path ‘’, line 1, position 85.

Notice that the settle done event is caught up in this mess… the JSON is not malformed here but the deserializer seems to be choking on the fact that multiple roots are issued in the same message… I just know I have not seen this behavior prior to now. Any idea what changed here?

Asking PHD2 to Re-calibrate

Right now, this is by design… Maybe not a good design and maybe recovery could be smarter. A bunch of of your settles failed because of the error above. The logic is that something went bad after movement of the mount. We don’t know which side of the pier you are on any longer and we don’t know if your calibration data is backwards… because we don’t know this, when failure occurs after mount movement, we issue a command to re-calibrate.

The Notification Module

We have not tested with AOL so I can’t say we support it. Luckily, there is an easy way around this. Go get a free gmail account and use that account to populate only the bottom portion of the settings dialog (it will be used only to send messages). The top part (where you add addresses) will still have your AOL stuff.


Re: Asking PHd2 to Re-calibrate.

It wouldn’t be the end of the world if it just triggered a re-calibration and then went on its merry way, unfortunately once it performed a re-calibration and the sequence was restarted another re-calibration ensued, and so on and so on. The only way out of that loop was to abort the sequence completely and restart it. Thus I can’t run an unattended session.


That is because of the first issue I posted…


Oh and btw I’m happy to report the notification system worked with my new email :smile:



The problem is more complex than I made it out to be in the initial assessment. That problem though, is still an issue. We have never seen multiple JSON roots issued in the same message before. That said, there is another problem in the recovery process. Specifically this:

[11/29/2015 10:40:54 PM] [DEBUG] [Recovery Sequence Thread] PHD2: Attempting to start guiding, waiting for PHD2 settle done message…
[11/29/2015 10:41:06 PM] [DEBUG] [PHD2 Listener Thread] PHD2: Settle done received: 1
[11/29/2015 10:41:07 PM] [DEBUG] [Recovery Sequence Thread] PHD2 settle failed!
[11/29/2015 10:41:07 PM] [DEBUG] [Recovery Sequence Thread] Recovery: Auto select star and resume guiding failed…
[11/29/2015 10:41:07 PM] [DEBUG] [Recovery Sequence Thread] Sequence recovery failed!

I need to look into it a bit more, but this log section shows behavior immediately after SGPro asks PHD2 to start guiding with calibration. The odd part is that within 12 seconds of asking for guider re-start and recalibration, we get a settle done message from PHD2 (seems a bit to fast to me)… then for some even stranger reason, SGPro considers this news a failure.


@Andy Actually, it looks like settling is just failing on the PHD2 side:

[11/29/2015 10:41:06 PM] [DEBUG] [PHD2 Listener Thread] PHD2: Settle done received: 1

I forgot that “1” means it failed… Not sure why this is happening (it fails in exactly 12 seconds every time)


Nothing changed, but Marty was just unlucky enough to stumble upon a phd2 bug that has been present “forever”. There are multiple threads in phd2 sending messages back to SGP, and if the timing is just right two messages can be sent before the line terminators.

I just uploaded a new build of phd2 that fixes this problem: v2.5.0dev9.




The SettleDone failure responses from PHD2 were the result of Marty’s explicitly stopping the unwanted calibration.

FWIW, the failure reason is given in the SettleDone message if you want to display it in the SGP UI.

22:31:58.885 00.000 10068 evsrv: {“Event”:“SettleDone”,“Timestamp”:1448854318.885,“Host”:“HOMEPC”,“Inst”:1,“Status”:1,“Error”:“Stopped capturing”}



Thanks for getting to the bottom of this quickly. Much appreciated!