Blown capacitor on HEQ5 pro motherboard

[Mr Frodo 57]

I’m looking for some advice regarding a possible motherboard failure.  In the photo of the board in my mount the capacitor circled doesn’t look too good; I believe it has failed. ☹️

I’m using the mount with a Raspberry pi 3B running Stellarmate.  The Pi is powered by the official Rpi power supply and the mount by a 12v power brick with sufficient power for the mount and the peripherals.  The mount carries my Skywatcher Explorer 200p and both scope and mount are well balanced.  

What is happening is the mount will slew easily enough to a target then it will track for a while quite happily, but after a period of time, which varies between a minute and several minutes the reticle on my laptop screen will jump E/W or N/S sometimes by several degrees all the while the mount goes on tracking.  Then a N/S jump will take the supposed position below the horizon and the mount will stop tracking. 

I have also had the mount spontaneously slew to a different position, or creep until the ‘scope is pointing to the ground or worse still, collides with the tripod legs.  On occasions it has also  been slow to respond.  Polar alignment via Stellarmate is near impossible as the software reports 'Mount aborted. Please restart the process and reduce the speed.'  If I ignore this I can sometimes get an alignment but not always and reducing the speed does not help.  The same thing happens when calibrating the auto-guider, making calibration, on times, impossible.

I’ve removed the R-pi and noted the mount also misbehaves when using the Synscan dongle linked to Skysafari.  I’ve not had it do a random slew in this configuration but I did not have the scope on the mount at the time.  All I saw was the reticle on Skysafari flashing on and off at random intervals.  I can leave the mount running with the handset and everything seems fine but the whole idea of using the Rpi was to stay warm whilst photographing the stars and using a robotic telescope on my back yard.

It appears the problems are worse when the mount is loaded.

I understand from my research the failed capacitor is a smoothing capacitor for the power supply to the board.  Is its failure likely to be responsible for odd signals being transmitted to the Rpi which then cause the behaviour in the third paragraph above.  Is this the likely source of the problem?  Would it be worth simply replacing the failed capacitor in the photo to see if that would help?  Or is the board completely Kaput?

Any thoughts and advice would be appreciated especially if you have done something like this yourself.

[malc-c]

I've had some experience repairing motorboards   (documented here)  

I've also replaced the two capacitors on my HEQ5 board which is a straight forward task, however I would suggest using capacitors of the same uF value, but at a higher voltage rating such as 50v - 100v - The reason is that the PSU generates around 30-35v to drive the steppers, so the factory fitted ones are really on the limit. - Best to replace both, which should still give you change out of a quid.  Just note the polarity.  

Try that first and if you are still getting running issues and you are sure your 12v power brick is rated for all the equipment (personally I prefer to power the mount via its one 13.8v  5amp supply), then report back and we can try a few other things

Personally I can't comment if the strange slewing behaviour is related to the blown cap, as I don't use a Pi and associated software, or dongle ( which could also be a problem if the wi-fi signals are being corrupted).  A way to rule the dongle out is to use either an EQDIR cable between the computer / pi and mount, or if your handset is a new version with USB port, use an A-B USB cable and place the handset in PC-DIRECT mode so it acts as a pass through to the mount and control the mount that way.  This would confirm if the issue is with corrupted wi-fi signals.

Hope that helps

[Cosmic Geoff]

Electrolytic capacitors do age and fail with swollen tops, so you should definitely replace the two capacitors as suggested above.

You say that the mount works OK with the handset, which indicates that the fault lies with the other stuff.

We used WiFi to connect laptops in a lab where I once worked, but had to take it out because the other gear in the lab interfered with the wifi, making it useless.

[malc-c]

55 minutes ago, Cosmic Geoff said:

We used WiFi to connect laptops in a lab where I once worked, but had to take it out because the other gear in the lab interfered with the wifi, making it useless.

I agree.  So much stuff use wi-fi that there is now a lot of competition for bandwidth.  We use to have issues when turning remote controlled RGB lighting on would wipe out any DAB radio in the room.

[Mr Frodo 57]

14 hours ago, malc-c said:

I've also replaced the two capacitors on my HEQ5 board which is a straight forward task, however I would suggest using capacitors of the same uF value, but at a higher voltage rating such as 50v - 100v -

1 hour ago, Cosmic Geoff said:

Electrolytic capacitors do age and fail with swollen tops, so you should definitely replace the two capacitors as suggested above.

Thanks for the encouragement I've managed to source a couple of new caps so will be fitting them when they arrive.

31 minutes ago, malc-c said:

So much stuff use wi-fi that there is now a lot of competition for bandwidth. 

I know what you mean here as there are about dozen wifi connections listed in my immediate area.

I'll report back once I've soldered in the caps, observing the polarity as you rightly say Malcolm.

 

 

[Mr Frodo 57]

On 12/03/2022 at 11:28, Mr Frodo 57 said:

Thanks for the encouragement I've managed to source a couple of new caps so will be fitting them when they arrive.

I know what you mean here as there are about dozen wifi connections listed in my immediate area.

I'll report back once I've soldered in the caps, observing the polarity as you rightly say Malcolm.

 

 

Ok so to report back.  Installed the caps and tested the mount indoors and it tracked on Stellarmate for an hour before Kstars crashed.  Nice and steady no jitters nothing so the first clear night I get I will set up and load up with the scope etc and test it for real.  Tonight would have been suitable if I hadn't got work in the morning.

So it is possible this is the culprit.

 

[malc-c]

Sounds like a result then

What value cap did you use as a replacement and did you replace both  as advised ?

[Mr Frodo 57]

19 hours ago, malc-c said:

Sounds like a result then

What value cap did you use as a replacement and did you replace both as advised ?

470uf and 40v any bigger and they would have rubbed against the Dec axis and yes I replaced both.  Checked all the soldering with a magnifier and no dry joints or anything else so all good there.

But no result 😞

Tonight when testing under load I had the same problem again, the mount and 'scope (Skywatcher explorer 200p) are both balanced.  There were two random slews and plenty of loss of tracking due to the horizon limit being exceeded even though the 'scope didn't move in the slightest.  

The set up was full rig with control by Stellarmate on a Raspberry pi 3B with manufacturer's PSU, via wifi to my laptop 2 feet away.  The video clip of the laptop screen shows what is happening.  

Something appears to be upsetting the data so that the Rpi thinks it's had an instruction to go below the horizon limit and so cuts off tracking but as I say the 'scope does not move.

I have alternative systems Stellarium and Sky safari 6 and I will be testing with them to see what happens.

So scratching my head at the moment on this one.

 

 

[malc-c]

This is a difficult one to diagnose as there are so many variables,  I'm guessing the laptop is running windows and you are remoting into the Pi via some application over a wireless link / network.  Then the pi is running linux and you are using INDI as the interconnecting platform for GS Server / Kstars / PHD2 etc to communicate over?

From my limited research, the motorboard firmware has no real idea where the scope is pointing.  It simply receives its  starting position when first connected to EQMOD/GSServer and the software sends the command to move whatever axis to a position and the firmware converts that to the number of steps the motor needs to run for, and then returns a code back to the software when it reaches that count to signify the slew is complete.  If the planetarium software is sending positional commands that the scope driver (EQMOD / GSserver ) detects are below the limits set for horizon or to avoid impacting the tripod then it will override that instruction.

Personally, if this were my problem I would first check that there is no physical problem with the mount.  I would connect the handset and having placed it in the default home position, set it to speed 9 and use the directional buttons to slew the scope through 360 on both axis (having ensured the scope is in a position to clear the tripod in RA).  This would confirm if the mount is actually slipping or if the drive train is meshed correctly (gears or belts).  I would then purchase a Lynx EQDIR cable and connect that straight to the laptop and install either EQMOD or GSServer under windows, along with ASCOM and then repeat the same operation using the directional buttons on the software.  If that works then take this a step further and install a free planetarium application such as Cartes du Ciel, set that up with the same location information and then run a live session on the next opportunity to select the same target (with no limits set) and see if that replicates the same problem.  If it doesn't then it would seem that the issue is either related to wireless interference, corrupted limit data, or corruption of data over INDI between applications.

The alternative if driving the mount via the handset works OK is to basically re-install linux on the Pi and start from scratch, but following the same steps, ie use a direct connection to the mount with an EQDIR cable, install GSServer and INDI and make sure the scope can be rotated fully from GSS and then set up the limits etc... and test again.

[Mr Frodo 57]

My setup is a Skywatcher explorer 200p on a HEQ5 Pro.  The mount is connected to the Rpi via a Lynx astro, usb to serial cable.  The Rpi is running Stellarmate used in wireless hotspot mode.  The laptop is running W10 and connects wirelessly to the Stellarmate hotspot.

Using the handcontroller and the mount slews smoothly in both Dec and RA with no issues.  

So taking up the alternative I will reflash the sd card containing Stellarmate to see if that makes any difference.

[malc-c]

14 hours ago, Mr Frodo 57 said:

My setup is a Skywatcher explorer 200p on a HEQ5 Pro.  The mount is connected to the Rpi via a Lynx astro, usb to serial cable.  The Rpi is running Stellarmate used in wireless hotspot mode.  The laptop is running W10 and connects wirelessly to the Stellarmate hotspot.

Using the handcontroller and the mount slews smoothly in both Dec and RA with no issues.  

 

Well that would rule out a hardware issue as far as the mount / motorboard is concerned.  

I've no experience with a pi or Stellarmate, but as mentioned, you could always try the direct connection of the Lynx cable to the laptop and use an alternative planetarium program to see if that works better, or use a network cross over cable and try a hardwired alternative to wifi to try and narrow the issue down further.