SGPro loses connection with HEQ5 Pro Mount

I’ve just joined the forum, hopefully I’m following posting protocol, let me know if not.

I’ve been using SGPro for a few months now, and think it’s absolutely stunning. I had an issue with my mount, which involved the two boards being replaced, but it seems to be working now, tracking properly etc etc.

Unfortunately, I now seem to get occasional serial drop-outs. Sometimes it runs for hours OK, sometimes it will drop out after an hour or so. I sort of imagine that this happens more often when I’m busy doing other things on the laptop (resources?), but I might be imagining this.

The symptom is that the orange connected box (with the chain, two boxes to the right of the “Telescope-EQMOD ASCOM HEQ5/6”) box goes grey, and the EQMOD window closes.
If I click to re-connect, it does so, tracking is off in the EQMOD window, but if I turn it back on, the mount seems to have actually maintained position.

I started a comms log in EQMOD, and these were the last communications I got for one disconnect:-
17:53:08.674 TX :s1

17:53:08.690 RX =1C0501

17:53:08.690 TX :s2

17:53:08.706 RX =1C0501

17:53:08.706 TX :V200

17:53:08.722 RX =

17:53:08.722 TX :q1010000

17:53:08.737 RX !0

17:53:08.737 TX :O10

17:53:08.753 RX !0

It seems that data is no longer being received. I am not sure which end is doing the transmitting and which is receiving.

Does anyone have any ideas what might be causing this, how I might be able to track it down, or are there any settings that could be changed (timeout etc)?

All help gratefully received.

Hi, can you confirm you have told Windows to disable USB sleep in the advanced power settings?

Thanks for coming back Buzz. The laptop is plugged in when observing…

1)USB settings:-
USB selective suspend setting, disabled on battery or plugged in.
2)Sleep settings…
Sleep after on battery or plugged in both are never
Allow hybrid sleep on battery or plugged in are both off.
Hibernate after on battery or plugged in are both never
3)Under Device Manager, USB, I have
Generic USB Hub. This had “Allow the computer to turn off this device to save power” ticked. I have now unticked that.

All of the other entries here “USB composite device” x 2 and “USB serial converter” x 2 all had that tick box cleared.

Are these all the settings?


Here is some more specific guidance for EQMOD.

In terms of general guidance:

  • If you have enough USB ports on you machine, keep the mount connected directly to the machine (not implying you should always operate this way, but it is good for eliminating variables).
  • If you are using a powered USB hub, do you have any other high traffic devices on it? Like maybe a camera? We have sometimes seen image download clobber other data on hubs that do not manage burst traffic well.
  • Is the USB hub very cold (maybe in UK?)? Sometimes, depending on build materials the USB cable and USB Hub port metals will contract at different rates and cause spurious connection loss.
  • Have you tried a different USB cable?
  • Do you have access to a different RS-232 to USB adapter? Some users have reported difficulty with certain brands.

Dave - that should certainly help and remove the most obvious of the hurdles to extended unattended imaging.

Buzz, thanks for that…

Thanks. Appreciate it, liked the EQMOD link.

The Fujitsi laptop has three USB3 ports, I have no USB hub. The mount is connected directly via USB to one of these three ports. The problem has been seen indoors, so cold might be a factor, but not the whole answer.
The USB cable I use is made my Hitech Astro for Rother Valley Optics. Last week I bought a replacement short cable (1 metre) but the problem still occurs.

You’ll need to get a better handle on what’s happening that’s causing the disconnect. I’d suggest you install SkyChart (CdC) with just its basic catalogs. After SGP is connected to the mount, start CdC and connect it to the mount. Now, if the EQMOD panel stays up after SGP has disconnected, the problem lies in the SGP-EQMOD connection and isn’t a communications issue. Whenever I’ve had communications problems with the mount, I always see a “Communications Lost” message from EQMOD. Your not mentioning seeing this message is an indication that the issue may not be computer to mount communications.

If you’re using PHD for guiding, it would to the same thing that CdC would do in keeping EQMOD running.

Appreciate that, will give it a try. The problem is it takes so long for the disconnect, sometimes hours, that it’s a nightmare to test.

I’m not sure about that message, would that be in the status bar?

May not be your problem but if you have mount limits (horizon or meridian) set in EQMOD maybe they are somehow affecting your connection to SGP. Mount limits got me a few times in the past - depending on what action you choose for mount limits to take when activated your mount could stop tracking or it could park. I can’t remember if it disconnects from SGPro under certain circumstances.



Thanks Derek. Mount limits have caught me out in the past too, but they are definitely disabled at the moment.

Whoops, pressed return too early!

I have some more information. I tried running off my power pack rather than the battery. Comms was lost after about 2 hours, so probably not a mains power to the mount dropping momentarily then.

Someone suggested that I try running Cartes De Ciel in parallel, connecting to the mount, and seeing what happened.

Interesting … SGPro dropped out, but NOT CDC, and the EQMOD window was still up and updating, so that, in association with the fact that APT seemed not to drop out in previous tests points pretty much at SGPro communications…

Well - it is possibly more complicated than that. EQMOD, if memory serves, is an ASCOM driver. Its communications with the mount are direct and uses the Synscan API.

CDC and SGP connect using ASCOM commands to EQMOD. It is quite possible that EQMOD works fine but its external ASCOM interface is part of the issue. We don’t know the details between CDC and SGP. They may not necessarily be using the same (of the many) ASCOM calls. It could also be possible that two applications accessing EQMOD at the same time may cause issues. It gets one call and then another comes in, that it is not expecting. It might be worth only connecting SGP to see if it drops out on its own. You should not really need a planetarium once SGP sequence starts off.

I get similar issues with a Paramount. TheSkyX works fine but it sometimes throws an exception through the ASCOM interface if commands coming into the ASCOM hub conflict with actions in progress. It appears that guide pulses from PHD2 happening at the same time as a slew command in progress cause PHD2 to give up.

Hi Buzz,
I tried many times with SGPro only, and it definitely failed in that configuration. The combining with CDC was only a diagnostic. It still feels like SGPro is the issue. Does anyone know whether you can configure the way that communication happens, such as timeouts, retries etc?


You can configure timeouts/retries, etc in EQMOD, I believe, in SETUP EASCOM in the EQMOD folder.

I’ve had this issue twice in 2 years running SGP.

Once was bad USB cable - replaced it with an active USB cable.

Once was my EQMOD meridian limits (had reset after a power failure and my profile file saved as garbage. Back those files up.