apparent mount disconnect

[Rita Castilho]

Hi,

For a few days now, I have been experiencing what seems to be a mount disconnect during the night. I say this not only because of the guiding graph, but also because at the end of the NINA session, the mount is no longer responding to the controls. I am using GSS on an EQ6R-Pro.

1. Can this be confirmed in the debug file, which I have a hard time to understand fully.

2. Also there is a line in the debug file "Error thrown from C:\cygwin\home\Andy\projects\phd2-build-20240714-002513\scope_ascom.cpp:673->timeout exceeded waiting for guiding pulse to complete" indicating a directory that does not exist in my windows 11 (cygwin). Can this indicate a problem?

Thanks,

Rita

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

[Bruce Waddington]

The GSServer mount driver stopped processing guide commands starting at 03:21:34 and never resumed.  It had similar problems earlier in the evening but eventually recovered.  The symptom, which seems to happen not infrequently with the GSServer, is that it continuously reports that a guide command is still in process for indefinitely long periods.  These events trigger alerts in PHD2 but you have chose to suppress them.  I suspect there's some situation with the mount controller that isn't being handled correctly by the driver but I can't know what that it is.  I think you should take this up with the authors of the driver and see if they can give you some help.  It's possible the driver is creating its own log file which could help identify the source of the problem.

You should probably also consider what your imaging session was doing at the time of the failure.  You started guiding from the east side of the pier with an hour angle of 0.23 hours - so about 15 minutes west of the meridian - with a pointing altitude of 64 degrees.  By the time the driver stopped working, you had run for 4 hours.  Since sidereal tracking rotates the RA axis by 15 degrees/hour, the scope would have been pointing close to the horizon. Is it possible the driver has a horizon limit that prevents further scope movement at that location?  The session actually ran for over 8 hours so I don't understand what you were doing.  If you were trying to guide on a circumpolar target, you'll be putting the scope and mount into a pointing position that is very likely to encounter problems with cable wrapping and possibly pier collisions.

On an unrelated point, your guide camera is running in 16-bit mode but you have your saturation-ADU value set to 255 which is appropriate for an 8-bit camera.  This disrupts the PHD2 auto-find operation and causes you to unnecessarily use dimmer stars in the field of view.   You should fix that via the Advanced Settings dialog.  The things you are asking about in the debug log are of no consequence, they are simply side-effects of the software build system.  While I applaud your efforts at self-help, the reality is that the PHD2 debug log file is mostly a programming and support tool for us and typically requires knowledge of the source code to interpret correctly.

Regards,

Bruce

[Rita Castilho]

Dear Bruce,

Many thanks for your detailed and insightful analysis of the logs, and for the clear explanation regarding the GSServer driver behaviour and the possible positional limits. Your feedback was constructive.

As a note of context, I usually leave the setup to run unattended overnight, with NINA configured to stop all operations at nautical dawn and to loop until the target’s altitude is again above the horizon. However, it appears that this instruction may not be acting as intended, and I will investigate this further on the NINA side.

I installed the beta version of the GSServer yesterday, and I am pleased to report that the issue did not recur during last night’s session — no disconnects or guide command stalls were observed. Further test nights will, of course, be necessary to confirm the long-term stability, but the update might have mitigated the problem.

I also appreciate your note regarding the ADU value setting, which I have now corrected accordingly.

Thank you once again for your time, attention, and invaluable support — your work and guidance are greatly appreciated.

Best regards,
Rita

[Bruce Waddington]

No problem, Rita, glad to help.  I suggest that you maybe re-think your shut-down strategy.  If you literally allow the mount to track until dawn, it can potentially rotate into a counterweights-up position or possibly with the scope pointing way below the horizon.  For most setups, this is a hazardous business in terms of cable wraps, flexure, or even pier collisions.  I think most of us specifically prevent this sort of thing using various options - horizon limits, mount parking, slewing to safe positions, etc. In order to verify that the debug version of the driver fixed your problem, you need to work around your disabling of the PHD2 alarm for pulse-guide failures.  One way to do this is to open the debug log file - for example last night's session - and do a text search on 'alert'.  You may find there are 'suppressed' alerts for these pulse guide failures.  As I mentioned, you were getting these failures early in the evening but probably weren't aware of them because they eventually corrected themselves.  Obviously, you want to be getting "clean" debug logs with no alert conditions at all.  If you can confirm that the beta release eliminates these problems, please let us know so we can help others who also encounter them.

Good luck,

Bruce

[Rita Castilho]

Dear Bruce,

Thank you very much for your thoughtful follow-up and for the additional guidance. Your remarks about the shutdown strategy are well taken — I completely agree that allowing the mount to track until dawn can pose risks. I will revise my NINA sequence accordingly to ensure a safer end-of-session procedure, likely by introducing a controlled park or slew-to-safe position before shutdown.

I will also re-enable the PHD2 pulse-guide failure alerts and review the debug logs for any “suppressed” events, as you suggested. That’s an excellent point, and I appreciate your clarity on how to verify clean guiding performance.

I'll let you know the performance of the GSServer beta version as I continue testing over the subsequent sessions.

Many thanks again for your kind help and for all the work you do to support the user community.

Best regards,
Rita

[Rita Castilho]

Dear Bruce,

I am confirming that the mount-software disconnect disappeared for the second night in a row with the upgrading of the GSS version beta.

I had other issues, though, to which I would ask, if it is not too much, for assistance, as there may be a configuration problem with the mount settings, although I could not identify them. Both log and debug files are attached.

Best, 

Rita

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

On Friday, 10 October 2025 at 19:00:08 UTC+1 bw_m...@earthlink.net wrote:

[Bruce Waddington]

Starting at 23:27, right after the meridian flip, you got 48 instances of the problem you thought was fixed in the driver beta release.  So, unfortunately, I'd say it wasn't fixed.  Did you find release notes for the driver or get additional information from the authors of the driver - anything to suggest the problem had been addressed?  In last night's session, the problem occurred intermittently with varying time intervals between errors, so maybe that's something that has changed.  But I think this is why your guiding results degraded after the meridian flip.

If you can't get any help, try to find out if the GSServer produces a log file of its own that is human-readable.  Then see if you can find a correlation between the log files:

1.  In the PHD2 debug log, do a text search on "Alert: PulseGuide command to mount has failed" and make a list of the times when they occurred.

2.  Look at those time periods in the GSServer log (if there is one) and see what was going on.  It's possible you might have to enable a logging option in the driver, unlike PHD2.

Good luck,

Bruce