Skywatcher mount message, Caution: both axes no response

[LaurenceT]

I'm suddenly getting this message from my EQ5 goto when I connect the handset also when connecting the Asiair to the mount it is not seen by the Asiair. I've tried multiple power sources, it was working last week as if that makes a difference😢.

I suspect it may be a fried motor control box and I need to buy one of these:

Skywatcher Replacement Motor Control Box For EQ5 Pro - Rother Valley Optics Ltd

any other ideas gratefully received.

[MikeAa]

Can you pop the case and check if you have power to the switching regulator? Pin 5 on U5. I have no experience fixing these.... yet!

[Cosmic Geoff]

The message basically means that the mount is not responding. That could be for various reasons.  A similar message from a Celestron Nexstar typically means that the mount firmware needs a refresh, or water has got into the mount electronics.  Solution: reload the firmware, or open the mount and dry it out.

[LaurenceT]

7 minutes ago, MikeAa said:

Can you pop the case and check if you have power to the switching regulator? Pin 5 on U5. I have no experience fixing these.... yet!

That sounds beyond my capabilities with electrical things but thanks for the suggestion.

 

5 minutes ago, Cosmic Geoff said:

The message basically means that the mount is not responding. That could be for various reasons.  A similar message from a Celestron Nexstar typically means that the mount firmware needs a refresh, or water has got into the mount electronics.  Solution: reload the firmware, or open the mount and dry it out.

That did cross my mind, I would need an EQDIR usb cable for that, I know I've bought one but where it's hiding is a different matter!

[MikeAa]

I'd be interested to see what malc-c thinks about it. I suspect he has far superior knowledge than I on this, judging from other posts of a similar nature. I also note that the original pwm control chip and its suggested pin/pin replacement are both now obsolete.

Edited January 18 by MikeAa

[malc-c]

On 18/01/2024 at 20:02, MikeAa said:

I'd be interested to see what malc-c thinks about it. 

I've cut and pasted most of the following from a reply  I made to a similar thread a couple of days ago

The "No Response XXX Axis" where XXX is RA / DEC or Both is because when the handset sent out the command e:1 to interrogate the control board it never received and reply.  If it reported a single axis isn't responding then this would suggest that the handset, cable, and the control board is powered up correctly, and the issue is with the PIC that controls said axis, or its associated blocking diode in the serial traces.  When it reports that both axis are not responding then it could be at any point in the communication path.  The curly cable, the connection on the mount, both blocking diodes or both ports on the PICs.

The handset tends to be fairly robust, so it is very rare for that to have a fault.  The simple way to rule out external connections is to use an EQDIR cable with EQMOD or GSS running on a windows PC.  If either of these two applications can't detect the mount then its pointing towards the control board in the mount, which could be anything from the RJ port where the handset plugs into or (and has been the case for the majority of the boards I've repaired) the serial ports of the two PICs being blown.  One other possible cause is condensation.  If the mount has been removed form a warm house to -3c outside the resulting change could cause moisture inside the mount or synscan box which again leads to the reported message if it shorts the serial connections.  It's therefore worth trying again once the mount / synscan has been inside  and thus at room temperature and completely dry.   Unless you have been messing about with USB to serial convertors and some how shoved the wrong voltage into the board then the issue may well be juts a connection one.   If the EQDIR cable works, but the handset doesn't, then try replacing the curly cable with a 2m Cat5 / Cat6 network patch cable to rule out the cable as being the issue.

If the board does seem to be the cause, and if it's one that is based on the older PIC microcontrollers then all is not lost.  The process of repairing the board by replacing the damaged PICs with new freshly programmed ones is covered in this thread  - I can repair these boards, but if the board is one of the newer ARM based boards then regretfully I lack the tools to program and replace these processors.

@LaurenceT I would suggest locating that EQDIR cable and see if the mount responds to commands from EQMOD / GSS.  If this reports comms issues then it would be more likely a fault on the board, and if this is the case then drop me a PM and well look at attempting a repair.

Edited January 22 by Cornelius Varley
background colour to text removed

[LaurenceT]

On 18/01/2024 at 21:49, malc-c said:

I've cut and pasted most of the following from a reply  I made to a similar thread a couple of days ago

The "No Response XXX Axis" where XXX is RA / DEC or Both is because when the handset sent out the command e:1 to interrogate the control board it never received and reply.  If it reported a single axis isn't responding then this would suggest that the handset, cable, and the control board is powered up correctly, and the issue is with the PIC that controls said axis, or its associated blocking diode in the serial traces.  When it reports that both axis are not responding then it could be at any point in the communication path.  The curly cable, the connection on the mount, both blocking diodes or both ports on the PICs.

The handset tends to be fairly robust, so it is very rare for that to have a fault.  The simple way to rule out external connections is to use an EQDIR cable with EQMOD or GSS running on a windows PC.  If either of these two applications can't detect the mount then its pointing towards the control board in the mount, which could be anything from the RJ port where the handset plugs into or (and has been the case for the majority of the boards I've repaired) the serial ports of the two PICs being blown.  One other possible cause is condensation.  If the mount has been removed form a warm house to -3c outside the resulting change could cause moisture inside the mount or synscan box which again leads to the reported message if it shorts the serial connections.  It's therefore worth trying again once the mount / synscan has been inside  and thus at room temperature and completely dry.   Unless you have been messing about with USB to serial convertors and some how shoved the wrong voltage into the board then the issue may well be juts a connection one.   If the EQDIR cable works, but the handset doesn't, then try replacing the curly cable with a 2m Cat5 / Cat6 network patch cable to rule out the cable as being the issue.

If the board does seem to be the cause, and if it's one that is based on the older PIC microcontrollers then all is not lost.  The process of repairing the board by replacing the damaged PICs with new freshly programmed ones is covered in this thread  - I can repair these boards, but if the board is one of the newer ARM based boards then regretfully I lack the tools to program and replace these processors.

@LaurenceT I would suggest locating that EQDIR cable and see if the mount responds to commands from EQMOD / GSS.  If this reports comms issues then it would be more likely a fault on the board, and if this is the case then drop me a PM and well look at attempting a repair.

Thank you so much for a very comprehensive reply, I will endeavor to locate that elusive cable tomorrow and if it can't be located then I'll buy a new one.

Your offer to repair if subsequent tests indicate a possibility is much appreciated.

[malc-c]

Keep the thread updated.  As mentioned it could be lots of reasons why the handset can't communicate with the control board.  Once you have an EQDIR cable it should help identify if the issue is with the main board or handset.  If you find the mount works fine with the EQDIR cable, but not with the handset (even when you've tried the alternative cable), then the choice is to either run the rig via a computer via the EQDIR cable, purchase a wifi dongle and use an app on your phone to control the mount, or replace the handset.

As mentioned, I would need to confirm which version of mainboard is fitted before taking on the repair.  If its PIC based (two  28 pin packages with 16F886 printed on them) then they can be replaced.  If its a newer version with a USB - B type socket fitted then it will be an ARM based board which, as mentioned, I lack the tools to program and swap out the processor fitted to these newer boards.

[LaurenceT]

Right, please understand that my knowledge of electronics ended with A level physics in 1965😄 but here goes.

I plugged the eqdir cable into the controller handset port and opened the Skywatcher motor controller firmware loader but it cannot find the mount.

The handset lights up so I assume that current is flowing through the motor controller. I think the controller is of the "old" type but I'm not sure. I have ASCOM installed on the PC. What do I need to do now to confirm the type of controller I have?

Thanks in advance.

 

[malc-c]

Suggested workflow (sorry if it sounds patronising - that's not my intention)

• Boot the PC up in to windows.  Connect the EQDIR cable - you should hear the "bing bong" signifying its been detected.
• Open up Device Manager, and confirm the presence of a new COM port under the "Ports (COM & LPT) section
• Ensure there is no warning or exclamation mark against the port that signifies it either can't be started or is missing the driver
• Most of the Lynx cables are FTDI based so the driver is automatically installed.  If the EQDIR cable uses Prolific chip set then the driver will need to be located and installed.
• Assuming there are no issues or warnings, right click on the port assigned to the EQDIR cable and select properties 
• Under the port setting tab confirm the bits per second is set to 9600.  If it's any other value select 9600 from the dropdown list and then click OK
• Connect the EQDIR cable to the mount and power on the mount.
• Open up the firmware updating application, and uncheck the option to search for the com port
• Manually select the com port windows assigned to the EQDIR cable
• Click the "MC Version" button to make the application interrogate the mount
• If it can detect the mount then we can go one step further.

Download EQMOD from here  - Install it and then try the following

• From the windows start button navigate to All Programs > EQMOD > EQASCOM and run the toolbox utility
• Under the middle section called "set up" select  EQMOD.EXE in the drop down, and click the "Driver Setup" button
• EQASCOM will now launch.  To the left is a section "EQMOD port details".  Where it says "port" click the drop down menu and select the port that the PC assigned to the EQDIR cable
• Above the port selection is "Baud".  Select 9600 from the list of values in the drop down list.
• For now there is no need to fill in any other details, so click OK
• The EQASCOM window will close taking you back to the toolbox window.
• Click on ASCOM Connect.
• It will now do one of two things.  It will connect to the mount and display a load of RA/DEC/ALT/AZ values which confirms the board in the mount is fine, or it will keep cycling with "Comm Error" or words to that effect which confirms the result you had with the firmware update application, and points to the control board in the mount as being defective
• Click ASCOM Disconnect button on the toolbox, and then close the Toolbox application.
• Power down the mount and disconnect the EQDIR cable from the Synscan unit

If this failed to connect to the mount then this would confirm that the issue is with the SynScan board.  As mentioned, if it's a new unit with a USB-B socket then it will be one of the newer SMT32 ARM based boards which I don't have the tools to remove and replace them.  If is one of the older boards without a USB port then undo the screws holding the plastic housing in place and take a look at the PCB

 

Ignore the circles in this image, but if your board has a single PIC chip, which has 16F886 written on it then this is indeed repairable, assuming its just the communications that is at fault.  If so then drop me a PM (ideally with an image to confirm the board version as it may not look 100% identical to this image)  and I'll give you details on how we can attempt a repair, which will be a lot less than the £130 for a brand new unit.

 

[LaurenceT]

Thanks for that, it didn't get past stage 1. The board seems very similar but not identical to the board in this post:

SkyWatcher EQ5 motor controller - Getting Started Equipment Help and Advice - Stargazers Lounge

Here are my images, is it fixable or should I buy a new one? I can't find 16F886 written anywhere.

 

 

[MikeAa]

The PIC is the chip on the top of the board with a red paint dot, U3.

[malc-c]

Yes that is a repairable board.

I've been in conversation with Laurence and he has agreed to a repair attempt, and we are just sorting out the logistics.  I'll update this thread once the board has been received

[bosun21]

17 hours ago, LaurenceT said:

I can't find 16F886 written anywhere.

It's clearly written on the PIC with the red dot on the top line 

 

[malc-c]

Update:

I've been in conversations with Lawrence via PMs and he sent me his handset, curly cable and synscan unit, which was received today.  I plugged the handset in and confirmed the same message was present. Powered down and replaced the handset with my FTDI EQDIR cable used with my HEQ5, and having powered the board back on opened up the test program which reported no response  / mount not present,  which confirmed the PIC's serial EUART was damaged.

I downloaded the latest (2.7.02) EQ5 firmware for the synscan box and converted the binary file to HEX and programmed a new 16F886 with the code.  The synscan unit was disassembled and  and the board removed.  The old pic was removed and the newly programmed one soldered in its place.  The handset was connected and power applied.  I was gutted to see the same "no response both axis " message, suggesting there may be more to this than I first though.  So I reconnected my EQDIR cable and ran the test program once more.  I was pleased to see the report showed it was fully functional.  I also backed this up by launching the SW firmware application which read back the firmware without issue.

So I look the back off the handset, and was greeted by that lovely unique smell of cooked electronics.

Seems a ferrite bead got so hot that it not only completely burnt itself out, it managed to take a layer out of the PCB, exposing the fibre glass below...  On cleaning it was found that part of the track was floating, and was beyond my skill to grind the board away patch it and then try and protect the parts.  Plus there was no guarantee that no other damage to the ARM processor's communication port had been done, and if a bodge repair was made that it would work.

So the now working synscan unit was packed back up along with a print of the report and boxed ready to go back to Lawrence.  Given the damage to the handset Lawrence was willing to donate the handset to the cause and told me to keep the it as it  might come in handy should someone have the same version handset with a cracked screen, or one with a blown Q3 MOSFET.   

I believe Lawrence is looking at purchasing a replacement handset which should restore the mount to full operation.

Just like to than Lawrence for giving me the opportunity to work on the board, and for donating the handset to me, just sorry that I couldn't achieve a 100% fix 

 

Edited January 24 by malc-c
typo