PHD2 freezes while guiding, yet states it is still guiding

[Robert Hambleton]

Hello,

PHD2 consistently crashes without warning and without any error message while using my ZWO 174 mini guide camera. Normally I wouldn’t ask for help, and just figure it out on my own, but I’ve put so many hours into this issue, and haven’t made any progress. It’s time to reach out. BTW, my setup is an A-P 1200GTO mount with a 7” A-P refractor, a QHY 7-position filter wheel and a QHY 600M imaging camera.

When I click Guider in NINA, PHD2 opens, connects my mount and guide camera, finds a guide star and begins guiding … perfect.  Everything seems very stable and working beautifully.  What I’ve found, though, is after about 1 to 20 minutes, PHD2 is no longer guiding, despite stating that it is still guiding. I get no error messages, no warnings. I am forced to close PHD2 and restart it.  If I hit the STOP button, I get the message “Waiting for Devices”, but in most cases, it does not stop and is locked up.  I often need to use the Task Manager to close the program.

 

After the restart, everything is different, as Guider in NINA won’t connect to PHD2 and gives the error message “PHD2 Error: No connection could be made because the target machine actively refused it. 127.0.0.1:4400”.  I then need to go into PHD2, connect my guide camera and mount, and go back to NINA and connect Guider.  And the cycle of crashes continues.

This problem feels like a data transfer problem, or an internal camera problem.  Guiding works beautifully … at first.  Do I have some wrong settings in PHD2?  I’ve studied the log, but don’t have enough knowledge to interpret parts of them.  I see where the guiding starts, and sometimes it has a time where guiding ends.  Other times, there is a start time, but no stop time.  I guess that’s where the program has crashed.  I ran PHD2 without NINA involved, and the issue persists.

My equipment is in an observatory with fiber optic to the house. I’m going to try shortening the data run from the telescope to the house by going to the observatory and plugging the equipment directly into my laptop.  Also, I have a ZWO 220 guide camera that I could use to replace the ZWO 174 and see if the problem still exists. Could it be that the powered USB hub doesn’t provide enough power to the guide camera, or is the problem with PHD2?  I just don’t know.  This is the only barrier keeping me from running NINA and PHD2 all night without my constant involvement.

 

I’ve attached the log from last night Feb. 17, 2024, which has 3 attempts to guide (starting around 21:37); one lasted about a minute, one for about 3 minutes and one for over 20 minutes.  In all 3 cases, PHD2 stopped guiding with no warning, no error message. It’s a great product, and I’ll put the blame on me, but I still need help getting it to work consistently.  Thank you.

 

[Bruce Waddington]

The debug log you sent doesn't show any evidence of PHD2 "crashing".  What it does seem to show is numerous cases where the guide camera doesn't return an image after one has been initiated.  You have evidently changed the setting for the camera timeout feature in PHD2, setting it to 1 minute.  This means you won't see any messages nor will PHD2 attempt to disconnect/re-connect until 1 minute of dead time has occurred.  That can be a very long time if you're staring at the screen waiting for something to happen.  It looks to me like your problem is with the camera driver and/or the USB sub-system.  The first thing to do is be sure you're running with the latest ZWO drivers for your camera.  If that doesn't resolve the problem you can follow the procedure presented in the Trouble-shooting section of the User Guide.  You will need to consider both the data transfer and power-delivery aspects of the camera connection.  The on-line version of the guide is here:

https://openphdguiding.org/man/Trouble_shooting.htm#Problems-_Camera_Timeouts'

Fortunately, most of this can be done during the daytime.  On an unrelated front, it looks to me like your guide camera isn't very well focused which will probably cause you problems down the road. 

Good luck,

Bruce

[Robert Hambleton]

Hi Bruce,

Thank you for interpreting the logs for me.  I hadn’t realized the significance of the camera timeout feature, and yes, that is a long time when I don’t see any changes on the screen.

You mention the USB sub-system.  I’m trying to understand what that means in my case.  My concern is that the ZWO 174 guide camera is powered by the USB connection to a powered USB hub. Are all powered USB hubs the same in terms of power?  I’m thinking that perhaps the guide camera does not receive enough power, given that it is sharing a powered USB hub with 3-4 other connections.

Also, here is my routing system: The USB hub on the telescope is connected via USB to a DS-600 device which converts the USB to Cat6.  The Cat6 runs to a media converter which converts to a fiber optic line, and to a media converter at the other end, and then on to the router.  This works fine for everything else, including the QHY600M with massive downloads.  This makes me question whether the 174 camera is powered adequately, thus being the problem.  Do you see an issue here?

A separate issue, unrelated to the camera issue, is the error message: “PHD2 Error: No connection could be made because the target machine actively refused it. 127.0.0.1:4400”.  Is there a solution to this?  It doesn’t happen every time, but I don’t know a good work-around.

Thanks again.

Bob H.

[Brian Valente]

Hi Bob

I don't think it's a power issue: the 174mm requires very little power. You have a complex series of connections with physical layer conversions, and it looks like lot of potential points of failure.

When troubleshooting something like this, I suggest starting by removing as many variables as possible and build up from there. If you can connect the 174mm directly to a computer via one usb cable, test the camera timeout (you can do this by looping exposures in PHD). Then add back in an additional connection point and test again. The shorter 15 second timeout will be sufficient to alert you if there's a problem

--
You received this message because you are subscribed to the Google Groups "Open PHD Guiding" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/575d1bfa-c9b1-4952-857b-fc3c9f83f479n%40googlegroups.com.

--

Brian 

Brian Valente

astronomy portfolio https://www.astrobin.com/users/bvalente/ 

nature portfolio brianvalentephotography.com 

other astronomy https://www.brianvalentephotography.com/astrophotography/ 

[Bruce Waddington]

Hi Bob.  The network error is strange, I haven't seen one of those in years and I don't know offhand what would cause it on a Windows 10 system.  You can run the Task Manager and make sure you don't have any zombie instances of PHD2 or other astro apps running in the background.  The timeout problems can be very tedious to track down because the devil is always in the details.  For example, the USB cables that ship with Chinese-made guide cameras are often low-quality and fragile.  So the cable may work ok in the beginning but then develop damaged conductors because of flexing and handling - or perhaps they don't work well in cold temps.  Probably the first thing to do is to replace the USB cable with a high quality alternative, one with gold-plated connectors, some kind of strain relief, and 20 AWG power conductors - all with as short a length as possible.  If the devices have been outside for a long time, you may need to use conductor cleaner and be sure the cable connections are tight and not subject to twisting in the USB socket.  The reality is that no two of any manufactured things are truly identical.  Powered USB hubs also vary in quality and temperature tolerance and may develop "bad" ports over time.  It really does require a lot of attention to detail and systematic trouble-shooting to get to the bottom of things.

Good luck,

Bruce

[Robert Hambleton]

Hi Brian,

Thanks again for the advice.  I will test this timeout tomorrow evening.

Bob H.

[Robert Hambleton]

Hi Bruce,

I have replaced the original cables, but will replace what I have with the ones that you recommend.  I have taken on quite a bit lately: new programs (NINA and PHD2), new imaging camera, a switch to OAG and new guide camera, and a totally new way to control and power my observatory. You mentioned "zombie instances of PHD2 or other astro apps running in the background".  I wonder about this since sometimes when I attempt to run PHD2, a message box states that it is already running.  I've never been able to find another version of the program running, and have needed to restart the computer to rid the computer of it.  I hadn't thought to look in the Task Manager.

The powered USB on the telescope is probably at least 10 years old.  I'll replace it with a high quality hub. Thanks again for the excellent advice.

Bob H.

[Robert Hambleton]

Hi Bruce,

The troubleshooting file is an excellent resource. Very well written and the descriptions of many of the issues sound so familiar!  A lot to cover but very helpful.

Thanks,

Bob H.

On Sunday, February 18, 2024 at 12:10:45 PM UTC-5 bw_m...@earthlink.net wrote:

[Bruce Waddington]

I’m glad you’re getting value from it.  In some sense, it’s a compilation of the pain and misery of many imagers, myself included. J  With regard to the “zombie” process problem, that can happen when a camera device driver fails and a process thread is stranded, perhaps waiting for something that will never complete.  If you can get these camera connection problems sorted out, it’s unlikely you’ll see any of these network error messages again.  As Brian said, you do have a rather unusual arrangement and the long cable runs and multiple “junctions” could be part of the problem.

 

Good luck,

Bruce

--
You received this message because you are subscribed to a topic in the Google Groups "Open PHD Guiding" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/open-phd-guiding/gCtfr742DqE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to open-phd-guidi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/c5a4b188-c9ee-427e-8fee-09bd040681f1n%40googlegroups.com.

[Bryan]

Bob

You wrote " PHD2 Error: No connection could be made because the target machine actively refused it. 127.0.0.1:4400"

Are you using a remote control program, e.g. RealVNC, TightVNC, Remote Desktop.  I use TightVNC and this is a typical message I get if I have set up the local to remote PC incorrectly (you have made many changes recently).  This could be wrong IP address for remote, wrong port (the number after the address,) wrong/missing password.

127.0.0.1  is a special IP address that allows a PC to talk to itself.  Typically, connections between a local and remote PC would be via an IP address associated with your router, e.g. 192.168.xxx.yyy, which sits 'between' the two PCs.

Bryan

[Robert Hambleton]

Hi Byran,

The DS-600 device which converts the Cat6 to USB controls the USB hub on the scope through an "SX Virtual Link".  Maybe that's where that special IP address comes in.  Everything has generally worked well, except for issues that I've created in PHD2 with some wrong settings.   I have friends who run their very sophisticated club observatories with this configuration and it has been working flawlessly. But I do see that there are numerous places for failure with this system.

As for the message that I've occasionally received, I've seen it mentioned on other forums as being a Windows 11 issue.  I'll document it better should it happen again.

Bob

[Robert Hambleton]

Hi Bruce,

I'll be using the equipment tonight with some improvements in settings, cables, etc.  I'll see how that goes.

Bob

[Brian Valente]

127.0.0.1:4400 is the PHD server port number, it's what NINA uses to connect to and use PHD

it's unrelated to your USB hub and/or any VNC related thing

If it's crashed and you restart things, it's possible PHD may be left in an unstable state and/or have a separate instance running

--

You received this message because you are subscribed to the Google Groups "Open PHD Guiding" group.

To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/a1205ee8-b830-4855-b329-32a559a364e5n%40googlegroups.com.

[Robert Hambleton]

Hello,

Here’s an update on my issues: Neither NINA nor PHD2 seem to have anything to do with my issues. I apologize for getting that wrong.  My new system for communication is complex, but it is sound.  However, there is definitely an issue in this configuration.

I’ve been testing my new system and learned quite a lot.  I’ve tried guiding with PHD2 from the house which uses the various connections including fiber optic, and found that guiding usually stops within about 8 minutes. PHD2 still indicates that it is guiding, but it is not.  The imaging camera continues to download images.  If I hit the STOP button in PHD2, I get the message Waiting for Devices, but nothing happens.  I then need to shut the program down and restart it.  I then connected my equipment directly to my computer by a USB cable to a USB hub on the telescope, bypassing all the runs of ethernet cables, etc.  I looped the guide camera in PHD2 for an hour with no issues, and then added the imaging camera, looping them both for another hour with no issues.  I still don’t know the problem, but I now know where it must be.  Last night I imaged and guided for an hour with no issues, with all equipment connected directly to my computer with a USB cable.

The first step to resolve this issue will be to replace the StarTech USB 2.0 powered hub with a StarTech 3.0 powered hub.  The QHY600 camera has a 3.0 USB connection, so this seems like a reasonable first step.  The new hub is scheduled to arrive today.  I’ve also ordered high quality USB cables to replace the existing ones.

The Silex DS-600 Device Server that I use to convert the USB to Ethernet has both a USB 2.0 port and a USB 3.0 port. Now I’ll be able to use the 3.0 port, which should give much better transmission for these massive 120 meg downloads.  As soon as the skies clear, I’ll try out this new configuration.

Thanks everyone for the help with this.  I’m glad that I went on this forum, for if I hadn’t, I wouldn’t be nearly this far along in sorting this out.

[Robert Hambleton]

Hello,

I need advice with a continuing issue.  I’m having the same problem, even after upgrading from a USB 2.0 powered hub to a USB 3.0 powered hub and replacing cables.

 

What I don’t understand is why PHD2 guiding stops after a couple minutes when I am operating remotely.  It isn’t that the cables can’t handle the data: everything else is working fine.  It isn’t a lost star or low SNR.  This happens even when looping. When I connect directly to my computer in the observatory, everything works as long as I need it to, with no issues.  When I connect from a remote site, everything works fine, including the guiding … at first. If other equipment were having similar problems, it would be easier to understand.

 

I am downloading 120 meg images from the QHY600 camera without any issues, the filter wheel works, the mount is tracking, and the focuser works.  This feels like a data transfer problem, but given how well everything else works, I don’t see how that could be the issue.  It’s just that PHD2 stops working.  I’m having this same persistent problem: PHD2 stops taking images, despite stating that it is still guiding. I get no error messages, no warnings. I am forced to close PHD2 and restart it.  If I hit the STOP button, I get the message “Waiting for Devices”, but nothing changes.  I then need to use the Task Manager to close the program.  I may be using the wrong term when I say “freezes” or “crashes”. What I am saying is that PHD2 is no longer taking exposures, whether guiding or looping. 

 

I’m at a loss. Has anyone else had this issue of PHD2 stating it is guiding, but not actually taking exposures?  I need some direction:  What causes PHD2 to work fine and then stop working?

                        

Maybe something can be learned from the attached log. I ran looping remotely several times this morning.  At 10:01 a.m., I started looping, and at 10:24, I saw that PHD2 had stopped imaging.  I clicked STOP and nothing happened, so I forced a shutdown.  At 10:25 a.m., I started looping again.  At 10:51, exposing stopped.  I waited until 11:08 a.m. to see if it would start again, but it didn’t.  I clicked STOP, but to no effect, and I forced a shutdown. Can someone on this forum interpret this for me?  It seems like the answer to my problem might be here.

 

If settings sound like this issue, please suggest what settings could cause this and what would be appropriate values for those settings. I think that could help quite a bit.  Thanks for any help you can give me.  I definitely need more direction.

 

Bob H.

[Brian Valente]

Hi Bob

please use the log uploader feature, you only included the debug log

https://openphdguiding.org/getting-help/

I made some earlier suggestions to isolate the problem - specifically simplifying your cable system and connecting the guide camera directly to your PC (it sounds like you are doing things from inside your house so it may require you to temporarily set up a computer at the telescope).

 

--

You received this message because you are subscribed to the Google Groups "Open PHD Guiding" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/d4239b75-23d0-45ff-aa19-6ab8e8b8e0b0n%40googlegroups.com.

[Robert Hambleton]

Hello,

Two nights ago, I ran all the equipment directly into my computer via one USB cable from a USB hub on the scope while in the observatory, bypassing all the other cabling.  Everything worked fine.  So this morning, I thought that I would try looping the guide camera from my remote site, expecting it to work.  Everything worked except for the guide camera stopping after various intervals.  This is what I can't explain.  I thought switching out the USB 2.0 hub for the 3.0 hub would fix the issue, but it didn't.

Attached is the Guide Log for today.  Earlier today I uploaded the Debug log.  Hopefully this explains something. (I believe this is the Debug Log and the Guide Log.)

https://openphdguiding.org/logs/dl/PHD2_logs_Mfqs.zip

Thanks again,

Bob H.

[Brian Valente]

The guidelog you sent has nothing in it? 

need the guidelog from the description where it sporadically worked

based on your description of what worked and what didn't, it sounds like it's something other than the usb hub. Is this new test with the 3.0 hub including your ethernet/usb converter setup?

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/e43bd7b5-6f88-4595-a13b-46be4aea4e96n%40googlegroups.com.

[Robert Hambleton]

Hi,

The log from today, Feb. 29, is from the new USB hub through the entire system to the remote site. Since everything worked the other day while bypassing that system, I didn't send those logs, but I'll send them now.  Plus I'll also resend the guidelog from today.  This is what I sent earlier today, and it seems to have all the log data in it:

https://openphdguiding.org/logs/dl/PHD2_logs_Mfqs.zip

The following link is for Feb. 26, when I took my laptop to the observatory and connected directly to the equipment.  I started looping the guide camera at about 10:43 am, and added the imaging camera at 11:23 am.  I wanted to see if the imaging camera had an effect on the guide camera, but they both continued looping until I stopped them both sometime after 1:00 pm.

https://openphdguiding.org/logs/dl/PHD2_logs_jibX.zip

I hope this is what you need.  Thanks again.

Bob H.

[Brian Valente]

Hi Bob

>>>This is what I sent earlier today, and it seems to have all the log data in it:

are you sure these are the correct logs?

the guidelog again is basically empty. The only addition is it looks like this morning you opened PHD, changed multi-star parameters a few times and that's it. 

the debug log shows looping but the guidestar was never selected

there's about 3,000 no guidestar selected messages

10:12:16.479 00.000 11212 UpdateCurrentPosition: no star selected

looks like 9-11 ish

then at 4pm it started up but nothing transpired other than checking for the new version (maybe you just opened it to upload the logs)

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/14909a0f-15e5-440f-b765-959790f965d4n%40googlegroups.com.

[Bruce Waddington]

Hi Bob.  I've looked at the debug log file from 02/29 and specifically the times of 10:24 and 10:51 that you pointed out.  It looks to me like PHD2 sent the usual command to start the guide camera exposure and that command was not successful.  Further, I think the processing thread in PHD2 has gotten blocked on a call into the ZWO camera control code and was therefore not able to be terminated in the usual way or trigger a sensible error message.  My suspicion is that you are running into timing problems because of the elaborate connection topology you have.  We don't have any way to know how the actual camera drivers are written but they may be dependent on certain expected timing behaviors with the hardware that sometimes don't hold true on your system.  As you've demonstrated yourself, a simple connection scheme for the guide camera works correctly and of course PHD2 is always doing the same things in the same ways, it has no visibility into the cabling topology.   I don't know if you'll be able to find the source of the problem with your current setup or will just be stuck in an endless game of whack-a-mole.  Frankly, this is one of the main reasons people choose to position the imaging computer either on or close to the telescope, keeping the device connections as short and simple as possible.

Looking back at this message thread, I don't see that we've reminded you to be sure you're running the latest versions of the ZWO camera drivers.  You probably are, but I thought I'd mention it.

Regards

Bruce

[Robert Hambleton]

Hi,

I was just looping the camera since it was daylight, and even looping had been failing, or timing out.  That's why there isn't much there.  Thanks for taking a look at it for me.

[Robert Hambleton]

Hi Bruce,

Obviously I have an issue that I need to resolve.  We've certainly determined that it is my system (or perhaps some incompatible camera code) causing the interruptions, rather than the program.  I ran everything again last night for 5 hours from the observatory, directly connected to a computer, and there were no issues. Everything ran great: calibration, guiding assistant, guiding, etc. No interruptions. You've given me a lot to consider and I thank you for that.  Years ago, I had a mini PC riding on the scope; perhaps time to return to a similar system.

I do have the latest version of the ZWO camera driver, but I'll reinstall it anyway.  Before beginning this thread, I made sure I had all drivers and firmware current for all equipment.  What I may do is try a guide camera from a different company; I'm curious to see how the system might behave.  I think that would provide some very valuable information.  Thanks again.  I really did learn so much from you and the others who were willing to take the time to give this problem a serious look.  I now have the direction that I was hoping to find.

[Robert Hambleton]

To continue this saga, I did replace the ZWO 174 mini with a ZWO 220. I set it up using Guide/Connect Equipment/Manage Profiles/New using Wizard and ran it remotely.  To my surprise, the 220 guide camera worked fine.  I let it loop for an hour and then turned it off; it had no issues.  I thought, given that the 220 is using the same ZWO drivers, that there would be an issue, but there was not.

[Bruce Waddington]

Device drivers are a tricky business.  There are really two parts to the operation – the driver running in the PC and the firmware running in the camera.  Timing problems can originate in either one or both and there’s no practical way for an end-user (or us) to figure it out.   I guess the question going forward is whether this is a reliable solution to your problem or whether it’s a marginal thing that may fall apart with temperature changes or other “hidden” factors.

 

Good luck,

Bruce

 

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of Robert Hambleton

Sent: Saturday, March 2, 2024 7:39 AM
To: Open PHD Guiding <open-phd...@googlegroups.com>

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/9e9f56c8-0971-4917-b0a5-5d69f391a993n%40googlegroups.com.

[Robert Hambleton]

Hi Bruce,

Thanks again for your help.  If I have additional problems, I will significantly change the system, but for the moment, everything is working perfectly, even better than I had hoped.

All the best,

Bob H.