SGP freezes and stops PhD2 at start of sequence

Win 7, SGP A few different problems tonight. When I start a sequence, or restart one after a pause, SGP gives me a “ready” message in the bottom left corner, then does nothing for a few minutes. If I touch anything during this time, it crashes. If I leave it alone, I eventually get a message telling me the autoguider has stopped and asks if I want to have SGP restart it. It then restarts it and begins the sequence. It does this even though PhD2 was running just fine until I tried to start the sequence. It seems that SGP stops PhD2, freezes for a while, then reports on it. Downloads of each sub frame has also dramatically increased recently to around a minute from about 15 seconds. Also if I watch the PhD2 graph, it seems that the autoguider is still returning from the dither when the next frame has already begun with the imaging camera. It shouldn’t start the next frame until it has settled at under 1.5 arc seconds for a few seconds. Here is the log.


Couple of guys have had similar problems using PHD2. They went into the Control Panel (in SGP)…clicked on Auto Guide and changed the Settle Option to 2.5 pixels and everything seemed ok after that. They also tried NOT using dither and that also seemed to work.

Also check settings in Equipment Profile Manager under Auto Guider . The Profile Manager may be overriding your Control Panel settings .

Hope this helps.


I am not really sure. We have not gotten a bunch of complaints like this for the beta (this is the first really). While I can see it really happened in the logs, the socket connection to PHD2 is just bad and I’m not really sure why. When we close it and try again it seems to pick up on the socket just fine. I cannot reproduce this behavior. Starting a sequence with PHD2 guiding or not seems to produce the intended behavior. Maybe you can send your actual sgf file and we can see if it is some combination of settings you have selected.

This is because your image files are enormous and you have the image history option on.

This will not help in this case.

Hi Ken,

I’m happy to say that the problems are solved. It looks like it was a USB cable or hub problem. When I tried to start a sequence tonight, SGP froze again, only this time telling me it was connecting to the camera. It never unfroze, and I had to restart. This indicated to me that it might be a cable/hub problem, so I unplugged and replugged each device, and it no longer hangs, and no longer stops PhD on beginning a sequence. And as a bonus, my image download times are now back down to less than 20 seconds. This is the first time I have encountered a USB cable problem. I understand they are not uncommon, and will try to upgrade my cables. Thanks once again for your time.


1 Like

I am having a similar problem. Using if I have PHD2 (v2.5.0) already guiding and I start a sequence, both SGP and PHD2 appear to hang, both title bars say (Not Responding). If I wait approx. 3 mins, they come to life again and SGP gives a popup stating that:

“The auto guider is not running or the connection to it is lost. The sequence will attempt to re-establish the connection and start guiding prior to the first frame. Would you like to force the guider calibration prior to start?”

Yet, even before clicking on ‘no’ PHD2 can be seen to be guiding. I click no and the sequence starts.

This is 100% repeatable. Now if I don’t have PHD2 guiding before starting the sequence, then the sequence starts as it should, again 100% repeatable.

I have the Settle Option to 0.3 pixels

I know what you going to say, can I send a log. Sorry but no, for some reason all the past logs that had this problem are no longer on my drive. I do not remember deleting them, there are just logs from the last week, which were not imaging sessions anyway. Are they time limited and get deleted after a set period?

Next time I will send a log.



1 Like

Hey Mike,

Can you send us the logs? :slight_smile:️ Just kidding of course. Have you tried I know it’s a long shot but you never know.

I seem to be having the same issue. I’ll start PHD2 guiding, then start sequence in SGP, 50% chance it will hang up with a not responding message in the title bar. Haven’t had the patience to wait long enough to see if it comes back as I usually park the mount and restart. I’ll have to try the other suggestions next time. Did save the logs from PHD and SGP from last night. The problem started about 22:57. Seems SGP isn’t getting a response from PHD, even though PHD appears to be guiding. PHD2 2.5 version and SGP version



The SGP log shows SGP connecting to PHD2 and sending some messages:

[5/2/2015 10:57:59 PM] [DEBUG] [Main Thread] PHD2 Not connected! Attempting to reconnect. [5/2/2015 10:57:59 PM] [DEBUG] [Main Thread] Connecting to PHD2... [5/2/2015 10:57:59 PM] [DEBUG] [PHD2 Listener Thread] Attempting to connect to PHD2... [5/2/2015 10:57:59 PM] [DEBUG] [Main Thread] PHD2 GetPhdStatus - Pre-Wait : Stopped [5/2/2015 10:57:59 PM] [DEBUG] [Main Thread] Sending to PHD2: {"method": "get_app_state", "id": 1001} [5/2/2015 10:58:00 PM] [DEBUG] [Main Thread] PHD2 GetPhdStatus - Post-Wait: Guiding [5/2/2015 10:58:00 PM] [DEBUG] [Main Thread] Successfully connected to PHD2... [5/2/2015 10:58:00 PM] [DEBUG] [Main Thread] PHD2 GetPhdStatus - Pre-Wait : Guiding [5/2/2015 10:58:00 PM] [DEBUG] [Main Thread] Sending to PHD2: {"method": "get_app_state", "id": 1001} [5/2/2015 10:58:07 PM] [DEBUG] [Main Thread] PHD2: failed to receive status in 7 seconds, sending message again... [5/2/2015 10:58:07 PM] [DEBUG] [Main Thread] Sending to PHD2: {"method": "get_app_state", "id": 1001}

In PHD2, we see the connection, but no messages coming in:

22:57:59.220 00.004 1972 evsrv: cli 003445B8 connect

Later on we see SGP try to make a second connection:

[5/2/2015 10:59:39 PM] [DEBUG] [PHD2 Listener Thread] Attempting to connect to PHD2... [5/2/2015 10:59:40 PM] [DEBUG] [PHD2 Listener Thread] Failed to establish client connection to PHD2 using port 4400: No connection could be made because the target machine actively refused it

but nothing in the phd2 log.

I’m not sure what would would cause this behavior, maybe Ken and Jared can take a look.



In my case its almost always the initial target for the night, after that, I can’t seem to remember any issues, everything works fine. And usually if I restart the computer after the issue, it will usually work. Never had this problem with the earlier versions SGP 2.3 series. Very puzzling!

Thanks for taking a look, hopefully tonight I’ll get another testing run, not that there is much I can image under a full moon :smile:


Good afternoon,

Last night I was attempting to string together several targets with just a few subs of each. Other than intermittent clouds, I also experienced a possible issue related to this thread (although this was between targets rather than at sequence start). In my case, SGP completed one target, slewed to new target, centered on new target, then waited for PHD to resume. SGP eventually timed out while waiting for PHD, but actually, PHD was happily guiding away.

The linked logs are rather long, but the event in question started around 10:23, with SGP appearing to give up around 10:28.

Version information: PHD is 2.5, SGP is

Its certainly possible that I am doing something wrong, but I decided to share logs in case it is helpful.

Best regards,

For the life of me, I cannot reproduce any issue that resembles what is being presented here. That said, I cannot deny the number of folks responding to this thread. The only conclusion I can come to is that we are doing things (testing) differently somehow.

Anyhow, I have made some changes that I hope will stabilize the initial connection to PHD2 (and if not at least there is more logging now). Releasing beta in a couple hours.

Please give SGPro a shot.

Tried version 2.4.15, first attempt still ended in a 3 minute hang followed by the msgbox asking if I want to start the guider and force a calibration. Chose no, and then everything worked. Both PHD2 and SGP windows display the not responding message. Phd connection takes place about 9:33:49.

My start up sequence involves starting SGP and acquiring the target, starting up PHD, start guiding, then start the SGP sequence. Not quite ready to start up everything automatically.

Hope this helps,

Yep, same as Lynn above. I thought the issue was a cable problem, but it isn’t. Win 7, SGP Here are the logs.

Also noticed that once the sequence did start, PhD2 seemed to skip a frame about every 5 frames. I was watching the target, and there would occasionally be an interruption in the red x’s appearing, as if it had missed one frame.


Seems like it only hangs for me if PHD is currently guiding, if its stopped or looping, I just get the Do you want to start the guider/force calibration msgbox. But clouds have rolled it so only did some testing of it.

So I’ll just let SGP try and start PHD for now.


Well… .thanks for the feedback. I wish I had better news, but the new logging did not provide any new insight and I cannot reproduce the issue in any way so it makes a fix extremely difficult.

Please update if you come across any new patterns or clues.

I appreciate the attempt, Ken. It looks like it will be several nights here before the clouds lift, so I won’t be able to offer any feedback… but, I will continue to follow this thread and update when I am able to get back out.


Hi Ken,

I have not been seeing this error, but tonight I updated to the build, and saw it twice.


The incidents were are 9:23 PM and 10:06 PM.



If you remember, can you expand a bit on the life-cycle of the the PHD2 instance that was running. How long was it running? Had the server been used? Was it a brand new instance of PHD2? etc… any other details like that might prove to be helpful.

Sure, here’s the sequence:

  • started PHD2 around 9:06PM, connected equipment
  • around 9:09pm start SGP
  • at around 9:16pm, PHD2 start looping exposures, select star, start guiding
  • 9:17pm - 9:23: solve & sync, run AF
  • 9:23 start sequence; both SGP and PHD2 become unresponsive
  • 9:26 get the error from SGP and both programs become responsive again

PHD2 debug log here:

here are the server-related log messages in the phd2 log:

21:23:18.699 00.392 5272 evsrv: cli 0386AC38 connect 21:26:27.035 00.009 5272 evsrv: cli 0386AC38 disconnect 21:26:27.035 00.000 5272 evsrv: cli 0386ACD8 connect 21:26:27.036 00.000 5272 evsrv: cli 0386AD78 connect 21:26:27.037 00.001 5272 evsrv: cli 0386ACD8 disconnect 21:26:27.037 00.000 5272 evsrv: cli 0386AE18 connect 21:26:27.037 00.000 5272 evsrv: cli 0386AD78 disconnect 21:26:27.038 00.001 5272 evsrv: cli 0386AEB8 connect 21:26:27.038 00.000 5272 evsrv: cli 0386AE18 disconnect 21:26:27.038 00.000 5272 evsrv: cli 0386AF58 connect 21:26:27.039 00.000 5272 evsrv: cli 0386AEB8 disconnect 21:26:27.039 00.000 5272 evsrv: cli 0386AF58 disconnect 21:26:57.870 00.215 5272 evsrv: cli 0386AF58 connect 21:26:58.870 00.055 5272 evsrv: cli 0386AF58 request: {"method":"get_app_state","id":1001} 21:26:58.870 00.000 5272 evsrv: cli 0386AF58 response: {"jsonrpc":"2.0","result":"Guiding","id":1001} 21:26:59.373 00.503 5272 evsrv: cli 0386AF58 request: {"method":"get_app_state","id":1001} 21:26:59.373 00.000 5272 evsrv: cli 0386AF58 response: {"jsonrpc":"2.0","result":"Guiding","id":1001} 21:27:00.473 00.346 5272 evsrv: cli 0386AF58 request: {"method":"get_app_state","id":1001} 21:27:00.473 00.000 5272 evsrv: cli 0386AF58 response: {"jsonrpc":"2.0","result":"Guiding","id":1001} 21:27:01.573 00.265 5272 evsrv: cli 0386AF58 request: {"method":"get_app_state","id":1001} 21:27:01.573 00.000 5272 evsrv: cli 0386AF58 response: {"jsonrpc":"2.0","result":"Guiding","id":1001} 21:27:02.673 00.108 5272 evsrv: cli 0386AF58 request: {"method":"get_app_state","id":1001} 21:27:02.673 00.000 5272 evsrv: cli 0386AF58 response: {"jsonrpc":"2.0","result":"Guiding","id":1001} 21:27:03.773 00.028 5272 evsrv: cli 0386AF58 request: {"method":"get_app_state","id":1001} 21:27:03.774 00.001 5272 evsrv: cli 0386AF58 response: {"jsonrpc":"2.0","result":"Guiding","id":1001} 21:27:03.873 00.099 5272 evsrv: cli 0386AF58 request: {"method":"guide","params":[{"pixels":1,"time":10,"timeout":300},false],"id":1003} 21:27:03.874 00.000 5272 evsrv: cli 0386AF58 response: {"jsonrpc":"2.0","result":0,"id":1003}

The mystery is the gap between 9:23-9:26.