HEQ5 disconnects

[Clarkey]

Hi,

I am hoping someone computer / electronic savvy may be able to help me.

I have started getting regular disconnects between NINA (and PHD2) and my HEQ5 mount. The connection is directly from the mini PC to the mount - no hubs. So far I have tried changing USB sockets and a new cable without success. I also updated the driver for the FTDI. The EQMOD comms is showing regular errors which I believe are linked to a lack of response from the mount. As far as I am aware, the power supply is OK (it supplies everything else at 13.8V without issue).

I am beginning to think it might be a mount issue - any better ideas?

Thanks,

Ian

[Budgie1]

As you've replaced the FTDI USB to RJ45 cable, have you tried cleaning the RJ45 connections on the mount? A light smear of dielectric grease on the RJ45 contacts may help, in case humidity or cold is effecting it.

[Clarkey]

1 hour ago, Budgie1 said:

case humidity or cold is effecting it

I'll give it a go. I have also tried a different PC which was the same. The hand controller seemed OK. I have also removed the cover and checked for any obvious loose connections, but nothing obvious.

Edited January 2 by Clarkey
Changed wording

[malc-c]

I've seen a lot of posts recently similar to this, where NINA is used, often with it reporting the connection is lost.  Now I'm not saying that its to blame, but when it has been suggested to use CdC as the navigation platform which has EQMOD selected as the mount on a trial basis to see if the connections drop it's often reported that the session went without a hitch.  

The problem is there is so many avenues to go down.  It could be a power issue.  Whilst the PSU is outputting 13.8v, is that what the mount is receiving at all times.  Is the barrel jack a nice tight snug fit and not being pulled tight through out the session?  Assuming the power feed is good and connections are sound, check the EQDIR cable connection.  Again, that there is no strain on the RJ plug.  The suggestion of cleaning the contacts and ensuring no moisture is good, but personally I wouldn't use any conductive grease as it only needs a little in the wrong place to shove 12v straight into the PICs serial port.

Assuming the physical connections check out and the issue is looking to be software related, then it's going to be harder to diagnose.  It could be the OS that's at fault, the drivers, ASCOM platform, or any of the applications that are communicating through said platform.  The only way I can think of is to go back to basics and try using a planetarium program such as CdC that has native ASCOM connection to EQMOD and let it track a target over a timeframe of several hours that is long enough to see if EQMOD is reporting connectivity errors.  If that runs without issue then try the same with NINA.  If you get the same result with no errors then try PHD as the guiding application and see if any packets get dropped when its pulse guiding.  Again, if its all go then try NINA (I don't use NINA so can't advise, but I believe it can either guide directly, or handles the process between PHD and EQMOD ?).

Regarding the HEQ5.. ruling out any physical connections as being the issue then it's doubtful to be a fault with the control board. If the mount responds to the initial query and subsequent gotos then communications are OK.  There are only two discrete diodes on the two TX lines which are then joined, with their RX lines being direct to the port.  The only possible weak spot could be the solder joints of the RJ socket, but of all the boards I've repaired I've never come across a failed joint, or one that is that bad the flexure has caused the joint to crack and just the TX / RX pins becoming loose.  You could always check the wiring from the daughter board to the main control board.  If you suspect that as being problematical, then remaking the joints and pushing the wires so the insulation sits flush to the PCB might help.

[Clarkey]

8 minutes ago, malc-c said:

I've seen a lot of posts recently similar to this, where NINA is used, often with it reporting the connection is lost

NINA shows the failure first, but it is also being lost in PHD2 - so I do not think it is specifically NINA. The hand controller appears to be OK - but obviously the way it operates is slightly different. Power wise, I use the same set up on the HEQ5 and AZ-EQ6 and all the other kit is fine. Also, the connection fails at rest - not even tracking. Given there is virtually no power draw, I don' think it is the supply. (Also, I believe the power LED will flash at low voltage). Also, the length of cable is probably about 8 feet and it is pretty heavy duty for the demand. (I can't remember but at least 10 amp).

13 minutes ago, malc-c said:

Regarding the HEQ5.. ruling out any physical connections as being the issue then it's doubtful to be a fault with the control board. If the mount responds to the initial query and subsequent gotos then communications are OK.  There are only two discrete diodes on the two TX lines which are then joined, with their RX lines being direct to the port.  The only possible weak spot could be the solder joints of the RJ socket, but of all the boards I've repaired I've never come across a failed joint, or one that is that bad the flexure has caused the joint to crack and just the TX / RX pins becoming loose.  You could always check the wiring from the daughter board to the main control board.  If you suspect that as being problematical, then remaking the joints and pushing the wires so the insulation sits flush to the PCB might help

A physical issue is possible, but everything looks OK. The socket looks good internally, and there are not obvious faults in the wiring. I think I am going to have to bring the mount in from the observatory and check all the electrics as best as I can. When everything is static, but connected, there are regular comms errors in EQMOD. Then it just fails completely. If it were a physical connection issue, I would expect it to be a bit more intermittent. but who knows........

[Oddsocks]

If it occurs regularly, about an hour or so after beginning a session, just check that you have disabled USB selective suspend settings (power saving) in Windows Power Settings.

It's not uncommon for USB selective suspend power saving settings to be switched back on after regular Windows Updates, particularly if you only modify the USB selective suspend option in the standard Windows Power Plans rather than creating an observatory dedicated Power Plan for the PC, which tend to survive Windows Updates that target system power control and reset the standard plan(s) settings back to default unannounced.

USB selective suspend = enabled, (the default state) looks at the amount of data flow thorough a USB port and if it falls below a certain rate then Windows decides the port is under-used and will turn it off to save power.

Try this route, > Control Panel > Power Options > Edit Plan Settings > select current plan, > Change advanced power settings >>>> then >>>> under the Advanced Settings tree, scroll to USB Settings branch > expand USB selective suspend setting > set = Disabled.

The route to get there is a little different from one version of Windows to the next but the above steps should get you in the right area.

HTH

William.

[Clarkey]

I do not think it is this due to the comms errors showing in EQMOD - but I will change the setting anyway. Also, the disconnects usually happen in a couple of minutes and when guiding.

[Bignerdguy]

What baud rate do you have the EQMOD console set to communicate to the mount at?  It needs to be set to 9600 and not higher.  the HEQ5 cannot reliably communicate at higher rates.  Also check to see if the device has disappeared in device manager on your computer. when it drops out  If it has, then windows lost all access to the device.  In that case either there is something causing it to disconnect, like power management like Oddsocks suggested, or you have some defective hardware somewhere. 

You said you were able to get the hand controller to work with the PC just fine via serial connection but the EQMOD Direct cable wouldn't, is that correct  If so then the EQMOD cable is the most likely cause. FYI some of the EQMOD direct cables you find on Amazon and other pages are not that good at communication and tend to fail quite frequently.  

[Clarkey]

It's all kit that has worked fine in the past. The cable is from FLO (the other is a cheapy), but both have the same result. It stays on device manager. Also, when it 'fails' it appears to continue sending errors to EQMOD. I'm going to dismantle the mount at the weekend and check all the connections internally. I've tried everything from new cable to new PC, reloaded all the drivers etc, etc. Gut feeling is there is something wrong with the mount.

[malc-c]

When you said it drops out at idle I thought the same as the others, that this is a setting in the PC that is closing the com port down as a power saving.   If the issue goes away when using the handset, and the handset doesn't report "No response" to either or both axis then that suggests that it can't be a hardware issue with the mount or the mounts control board.  You have also mentioned that the EQDIR cable has been replaced but still the errors occur, so its unlikely or unlucky if both EQDIR cables have the same issue.

The amount of traffic through the port is very little in normal use.  The instruction from the controlling app is passed to EQMOD which then sends a string prefixed by the instruction and then the mount is left to do its own thing.  Guiding increases the traffic as the transmissions to nudge the mount in RA or DEC are more frequent.  This could be seen by the PC as a dormant port and windows shuts it down or suspends it.  As its a mini PC I would guess that its powered by an external supply and as such has power management options similar to a laptop rather than a typical desktop PC.  I would try the suggestion William has detailed to see if that helps. 

[Clarkey]

On 03/01/2025 at 11:53, malc-c said:

closing the com port down as a power saving

I have removed this - but it was shutting down after less than a minute, so I do not think this was the issue.

On 03/01/2025 at 11:53, malc-c said:

If the issue goes away when using the handset, and the handset doesn't report "No response" to either or both axis then that suggests that it can't be a hardware issue

I only tried the handset for a few minutes, but I am not sure if the handset sends a continuous instruction (such as when slewing), or whether it send a start signal then a stop signal in the same way EQMOD does.

 

Well, I have dismantled the mount today as the disconnects were getting more and more frequent. I looked at all the connections etc and found nothing obviously wrong. Plugged it into my home PC and it ticked along without a problem for over an hour. So, I am no closer to a solution. I will put it back in the observatory and see what happens. I suspect there was a loose connection somewhere which is now OK, albeit maybe temporarily. I did check the wired connections and they all appeared OK with the ammeter. I just hope that it does not start playing up again.

[Clarkey]

Well, after much searching, I think I have found the cause. At the end of 2024 there was a Windows driver update to the comms ports. Specifically update wch.cn - Ports - 3.9.2024.9. This unfortunately causes issues with the CH340 chip in the USB to serial adaptors in the cables causing frequent problems. Now I need to see if I can roll back the driver....

 

[Clarkey]

No not the driver🙁. I have now tried 2 mini PCs and 3 cables in addition to taking the mount to bits and finding nothing (other than it worked in the house). I have reinstalled eqmod and ascom plus some other bits. Still won't work. The power supply if fine, 13.7V at the mount.

I'm going to start knitting 😡

[TiffsAndAstro]

are you using synscan app or greenswamp server? or is eqmod the equivlant of those?

[Jim Franklin]

15 minutes ago, Clarkey said:

No not the driver🙁. I have now tried 2 mini PCs and 3 cables in addition to taking the mount to bits and finding nothing (other than it worked in the house). I have reinstalled eqmod and ascom plus some other bits. Still won't work. The power supply if fine, 13.7V at the mount.

I'm going to start knitting 😡

Can I have some nice thick woollen socks please 😁

I am not familiar with NINA, I use different software, but could the issue be communications between the different programs? Windows updates have often caused me issues with telescope controls, robot controls and BMS systems that communicaste with third party equipment. In the early days it was always a ball ache finding the problem, once we discovered what it was we found that if we had problems, we simply deleted the old driver, remoted its entries in the registry, then installed an older driver we kept as a backup. 99.9% of the time that fixed the issue. 

Its not that the new driver was an issue, but the different bits of software are looking for drivers with certain attirbutes, and if they do not find them, comms is garbled and they throw a hissy fit. 

It might be an idea to download the latest versions of all your doftware and also hunt for any comms drivers that will work with EQMOD and the latest EQMOD download is availabe HERE from Sourceforge

 

[blinky]

I have the exact same issue and never solved it either!  It ONLY started happening with the newer cables, I used to have one of those old Prolific USB to serial adapters that worked perfectly but then they stopped developing the drivers for it and I had to replace it.  I see the exact issue you have, the mount seems to timeout every so often, whats strange is I also have an EQ6 and when using the new USB to Serial adapter from FLO I get the same issue with that mount as well!  I'm currently using an ancient shoestring astronomy USB to Serial for the EQ6 in the observatory as thats all that worked.  All I could out it down to was the age of the mounts and something being incompatible somehow, it cant be the FLO adapters as nobody else (other than you) has the issue and the only common thing between my HEQ5 and EQ6 is that they are both very old mounts, both must be over 20 years old, is yours a new or old mount?

[blinky]

Here is my original post - as I say, I never got it fixed and the HEQ5 is now just sitting about gathering dust 😞 I always wanted to try the PC Direct mode with the handset but I dont have that cable anymore.

Actually... When I look back at that thread, after I had returned it and got a refund somebody did come up with a fix:

FLO has offered to refund me for the cable, but I had to check few last things - Issue seems to be resolved :

1. connected the cable to a USB2.0 port (the other port was a working USB 3.0, confirmed nothing is wrong with it)

2. In device manager ->  port settings ->  Advanced :
          -> Receive (Bytes) lowered to 2048 

          -> Transmit (Bytes) lowered to 2048 

7 hours session no disconnects

 

Edited January 7 by blinky

[Clarkey]

 

9 hours ago, Jim Franklin said:

It might be an idea to download the latest versions of all your doftware and also hunt for any comms drivers that will work with EQMOD and the latest EQMOD download is availabe HERE from Sourceforge

@Jim Franklin I have reloaded all the software to the latest versions - except the comm port driver which I have left as an older version. I am sure it is related to a Windows update, as this is the only thing that would have changed on the PC - I just can't work out what.

@TiffsAndAstro I use eqmod.

@blinky I have tried the lower rate and it did not help. My mount is not that old - about 5 years.

This morning I tried connecting the mini PC on my other imaging rig to the HEQ5 and it seemed to be fine. (No drop-outs or comms errors after about 30 minutes). I also plugged the 'problem' PC to the AZ-EQ6 and this was fine to. So now I am even more confused. It looks like there is a specific issue between one of the mini PC's and one of the mounts. I am tempted to swap them over, but as I have already tried a 3rd mini PC - which also had problems I am wary of messing up both set-ups when I have clear skies.

I have re-installed all the software (NINA, EQMOD drivers, ASCOM) and this has not helped.

Where are my knitting needles.....

[Jim Franklin]

24 minutes ago, Clarkey said:

 

@Jim Franklin I have reloaded all the software to the latest versions - except the comm port driver which I have left as an older version. I am sure it is related to a Windows update, as this is the only thing that would have changed on the PC - I just can't work out what.

@TiffsAndAstro I use eqmod.

@blinky I have tried the lower rate and it did not help. My mount is not that old - about 5 years.

This morning I tried connecting the mini PC on my other imaging rig to the HEQ5 and it seemed to be fine. (No drop-outs or comms errors after about 30 minutes). I also plugged the 'problem' PC to the AZ-EQ6 and this was fine to. So now I am even more confused. It looks like there is a specific issue between one of the mini PC's and one of the mounts. I am tempted to swap them over, but as I have already tried a 3rd mini PC - which also had problems I am wary of messing up both set-ups when I have clear skies.

I have re-installed all the software (NINA, EQMOD drivers, ASCOM) and this has not helped.

Where are my knitting needles.....

I did an experiment this morning, installed NINA and all the same software as you - same problems as you, comms between my EQ5 Pro and the laptop kept dropping out. Uninstall NINA, rebooted the computer, everything worked fine and I then used SharpCap to capture images - no issues, I then used FireCapture, again no issues. I would humbly suggest the root cause of the problem is NINA. It might be worth contacting the authors of the software and letting them know, it may be an easy fix. 

[Clarkey]

4 minutes ago, Jim Franklin said:

root cause of the problem is NINA.

This was my initial thought, but for a few reasons I am not sure. Firstly, the other PC's I have used with NINA worked absolutely fine (well 2 of 4 that I have tried). Secondly, the set up I am using has been working without issue for ages. There has not been a NINA update, and it just started failing. Thirdly, PHD2 is dropping the connection even when NINA is not running.

[TiffsAndAstro]

Try gss or synscan instead of eqmod see if problem persists

[Clarkey]

10 minutes ago, TiffsAndAstro said:

Try gss

I might have to - I was just trying to keep the systems common to all my set ups. The other option may be the Synscan USB dongle which uses Prolific chips rather than FTDI. Another option would be a wifi dongle. 

I have just re-installed Windows - no change.

[TiffsAndAstro]

16 minutes ago, Clarkey said:

I might have to - I was just trying to keep the systems common to all my set ups. The other option may be the Synscan USB dongle which uses Prolific chips rather than FTDI. Another option would be a wifi dongle. 

I have just re-installed Windows - no change.

Try gss or synscan if they both work it points finger at eqmod and/or some sneaky windows update that breaks eqmod

[malc-c]

A few observations.  Most EQDIR cables from retailers such as FLO or RVO are based on FTDI chipsets, and the cheaper ones form Amazon tend to be based around the Prolific chipsets.  I've not come across an EQDIR cable that uses the CH340 chipset, and in your first post you mentioned you had tried a new FTDI driver, so can't see the relevance of the issue with Windows update and CH340 chipset drivers.

You mentioned you have tried this with two mini PCs, three EQDIR cables and the issue is replicated each time.  Do you have access to a desktop pc that can have NINA, EQMOD and the same drivers installed and see if running the mount from that results in the same dropped connection.  Just trying to rule out a common denominator of mini PCs and NINA.

The fact that Jim has replicated your issue, albeit with a different mount, which when he removed NINA he reported no drop in communications does seem to back up earlier assumptions that NINA is the cause.   If it was me with this issue I would try the following in no particular order.

Either back up any imagine results etc and then cleanly format the hard drive, or get a fresh blank hard drive and install windows 10 from the current downloadable image.  Download and install  Cartes du Ciel, ASCOM and the latest release of EQMOD.  Connect the mount to the mini PC using the FTDI based EQDIR cable and set up EQMOD / CDC with location data etc.  Choose a target in CDC, right click on it and select slew to target, and then leave the thing to track for a few hours.  If you discover that communications have been lost then it rules out NINA as being the issue.   If there are no drop outs then install PHD2 and replicate the experiment, but this time at night and have PHD2 guide the mount.  If you get drop out now then check the cable and drivers used for the guide camera.  It might be that the guide camera is flooding the USB hub chipset used in these mini PC's, which then results in any instructions from PHD2 or CdC being lost until the camera data has been passed through.

One other option is to roll the PC back to a previous time when everything was working, either through any old back up images (you do back up your PC's don't you ???).  If you have no backups then install an older version of  windows, either earlier build or even windows 7 and then turn off / disable automatic updates.  Install the original build of EQMOD that you used, or just a previous build from the time you had a working system.

[Jim Franklin]

My drive is still guiding beside me - running everything EXCEPT NINA - it has the ASAI538MC imaging the office cieling, SharpCap is capturing and stacking - its amazing the detail a camera captures that your eye doesn't or you simply "tune out". Although deforked, I have the LX90 mount here also running from the same laptop, but using Firecapture to capture images from my ASI120 - again of the cieling but in black and white. Both have been running since around 08:00hrs without issue.