Any ideas on repairing a (slightly!) blown motor board ?

[di0de]

Hello all,

I was pointed here by @jmdl101 when I asked if he had any leads on an MC004 over on CN. I had some issues with a Flextube 200p that I just picked up used... tried updating the firmware via wifi dongle and it failed repeatedly. Synscan hand control was unreponsive and I couldn't update it or reach the motor controllers via serial cable. I have spent the last couple of days digesting this incredible thread and I'm happy to say my issue is resolved! It wasn't as dire as some of those that Malcolm et al have helped but it sure had me worried for a while when Skywatcher's "solution" was to buy a new base for $700 USD + tax and shipping... available in April or May.

I learned a heck of a lot about how these scopes are engineered (if you want to call it that...) and I will be extra careful not to make any of the mistakes (if you want to call them that!) that others have made. Many thanks to you awesome folks for dedicating your time to helping others. I will create a separate thread sharing my issue and solution in case others get caught in the same situation in the future.

Cheers from Canada! (It will be -13 and clear tomorrow night and I'm looking forward to getting my first view of Mars :D).

[malc-c]

12 hours ago, di0de said:

Hello all,

I was pointed here by @jmdl101 when I asked if he had any leads on an MC004 over on CN. I had some issues with a Flextube 200p that I just picked up used... tried updating the firmware via wifi dongle and it failed repeatedly. Synscan hand control was unreponsive and I couldn't update it or reach the motor controllers via serial cable. I have spent the last couple of days digesting this incredible thread and I'm happy to say my issue is resolved! It wasn't as dire as some of those that Malcolm et al have helped but it sure had me worried for a while when Skywatcher's "solution" was to buy a new base for $700 USD + tax and shipping... available in April or May.

I learned a heck of a lot about how these scopes are engineered (if you want to call it that...) and I will be extra careful not to make any of the mistakes (if you want to call them that!) that others have made. Many thanks to you awesome folks for dedicating your time to helping others. I will create a separate thread sharing my issue and solution in case others get caught in the same situation in the future.

Cheers from Canada! (It will be -13 and clear tomorrow night and I'm looking forward to getting my first view of Mars :D).

That's really good to hear you've resolved the issue encountered.  I can't take credit for this threads content.  If it wasn't for several other clever people here and on other forums who have basically reverse engineered the motor boards and pointed me to the tools used to convert the firmware etc.  Without them I woudn't have been able to offer my "skills" to replace the chips.

I would suggest you document your issue and the resolution on this post, or if you have already created the thread include a link to this thread so others can have a read and either attempt a repair themselves or drop any of the contributors a PM for advice, or make a request for a board repair.

Glad to hear your scope is back up and running, and hope it stays clear for you.

Edited January 15, 2023 by malc-c
typo

[ben_mtl]

Hello everyone !
Firstly, I went through this entire thread and I must say it was a pleasure to read you guys helping each other out with so much dedication and determination 🙏
I bought a second hand Dobson Flextube 300P about 3 months ago and I'm having a very strange issue with this famous MC004 board.
I know that the previous owner had to replace the hand controller and the Alt motor board but I have no information about what happened exactly.
The motors seem to work fine with the leatest firmware and there is absolutely no connection issue with the hand controller but I've never been able to perform a star alignment.
After several experiments my conclusion was that the Alt motor was rotating in the wrong direction, and I was comforted in this conclusion when I saw a review video on youtube showing the rotation of the OTA.
Indeed, my tube goes up when I press the down arrow of the controller, which is different from this video. The Az motor was ok though (going left when I press the left arrow).
Now comes the interesting part : actually the previous owner got a replacement board for both Atl and Az so, out of curiosity, I replaced the Az board and now the Az motor is rotating in the opposite direction ! (going left when I press right).
So I was convinced that there was a problem with these replacement boards and I was starting to think about switching the two black and red wires that go to the Alt motor, but then I saw this video posted by pablocarlac at page 10 of this thread, which matches my current situation. I just try to perform a 2-star alignment, chose Deneb as the first star (pointed at manually) then selected Altair as the second star, and the tube went in the wrong direction in both Atl and Az, so I'm pretty confused now...

I would have three questions :
1) I would be very pleased if Dobson owners here could share which way their tube is moving with relation to the arrows on the controller.
2) Is there a setting I'm missing, which could correct the sense of rotation of the motors ? I found nothing in the hand controller manual.
3) Let's say I put the original Az board back, how stupid is my idea to switch the 2 wires that go to the Alt motor ? (see picture below)

Some additional precisions :
- My long/lat coordinates are set up correctly. I also have the wi-fi adapter so I can use the SynSan app instead of the hand controller, and it behaves the same way.
- I contacted the SkyWatcher support and their only solution is to buy a new base at 900 $US +tx +shipping...

Thank you very much in advance.

[malc-c]

Uhmmm strange one.  The fact that the mount moves both axis and doesn't report any errors (communication or other) would suggest that the actual boards are working and that the directional issue is more of a set up problem similar to the ones people get with EQ3 / EQ5 when they rotate the DEC axis 180 degrees and put the scope on the dovertail.  The controller thinks it's point up when in fact pointing down due to the orientation of the motors.

I don't know enough about these mounts to know if reversing the polarity of the motors will work or will risk damaging the MC004 boards.  In theory it should be fine as the motors used are DC and the driver doesn't appear to be referenced to ground.  In essence the driver makes one output (say the red wire) 12v and the other output GND to move in one direction, and then makes output 2 (black wire) 12v and the output1 GND to move in the opposite direction.  All the positioning is done through the encoders.

You're welcome to try it, but I accept no responsibility if the board goes bang !

[ben_mtl]

Wow that was a quick reply, thanks ! Yes I'm aware that reversing the polarity of the motor is risky, first I'll wait and see if Dobson owners can confirm what is the expected sense of rotation.

How would you explain the fact that I have two Az board supposedly identical (MC004 Rev F) that move the motor in opposite direction ? I thought about a different firmware version but not sure that would make any sense...

[malc-c]

18 hours ago, ben_mtl said:

How would you explain the fact that I have two Az board supposedly identical (MC004 Rev F) that move the motor in opposite direction ? I thought about a different firmware version but not sure that would make any sense...

There is one subtle difference between both MC004 boards.  One will have a resistor connected between a pin on Port A of the microcontroller and +5v, the other the pin is pulled to GND.  The firmware reads if this pin is grounded or has voltage and depending on what it finds configures the board to control either the ALT or AZ axis.  The direction of the axis is down to two things.  Physical placement of the mount / scope, or in the case of software driven mounts using EQMOD or GSS, the RA reverse or DEC revers check box has been ticked.  I haven't used a handset in years so don't know if such an option exists in the handset firmware and either enabling or disabling that will make your scope track in the correct direction

[ben_mtl]

I meant my two Az boards. For Alt I only have the replacement board but for Az I have both the original and the replacement one ,which are identical and make the Az motor rotate in opposite directions.

Would that mean that at some point there was a modification in the firmware that changed the direction of rotation ? That would be strange...

I don't know how old is my telescope. When I ask the hand controller what is the firmware version, I guess it gives me the version of the Atl (master) board, so I cannot know what's the version of my original Az board

[malc-c]

The version of the PCB is stated on the board, which looks like to be Rev F  relates to the design, it will be the motor board firmware that can be found by using the Skywatcher firmware updater application.  I'm beginning to feel this is more mechanical such as having the drive on the wrong side of the mount, or back to front, possibly something the previous owner did ??   -  Changing the polarity of the motor wires, or reversing the assembly may be the way forward.  Skywatcher are not likely to change a tried and tested design for one model of telescope and then write a dedicated firmware to reverse the direction of one axis.

 

[Heldis]

On 04/02/2022 at 16:32, Anks said:

Hi thanks to the help off this forum Ive managed to repair a EQ5 with a MC002 board. this hex was programmed with a pickit2 via the ISCP header on the board.

Thanks

EQ5 MC002.hex 46.48 kB · 84 downloads

Hi, is this with protection bits removed?

[malc-c]

I've changed the code protection bit setting in the attached version

EQ5MC002-NP.hex

[malc-c]

Seeing how popular this thread has become over the years, and given that newer generations of mounts now have ARM based control boards in them,  I've been thinking of how best to try and help out others who find themselves in the same situation as the OP.  The idea is an exchange service, where someone with a faulty board can send me their faulty board(s) and in return will received a replacement that I've already repaired and tested.  This means less downtime for the SGL member, and takes the pressure off me to get the board fixed and returned quickly.  There will be a cost involved to cover the parts, return postage and possibly a pint or two for my time, but it will still be less than half the cost of a new replacement.  The only drawback with this idea is that I need "spare" donor boards to start the ball rolling.

To this end I would like to thank @SteveBz for his kind donation of a faulty EQ6 board and handset (plus associated cables) after it all stopped working one evening.  Steve had already been out and purchased replacements, so rather than the parts end up in the bin he kindly started the process by donating them to the cause.

So here's the first fix prior to clean up. 

It's been a while since I've last repaired a board so I was a bit rusty, and a few red herrings resulted in me straying down the wrong direction until the penny dropped and a likely cause was resolved.  After a visual inspection there was nothing glaringly obvious so an EQDIR cable was attached and the board powered on.  Communications were tested and sending :e1 and :e2 to the board resulted in no response form the board.  I first thought the issue might b the diodes, but in a bid to remove the two diodes to test out of circuit both were damaged, mainly as they were a sort of hybrid between through hole and surface mount component.  These were replaced with 1N4148s (through hole, but surface mounted to the pads).  I knew it wasn't going to be that easy, so both PIC microcontrollers were removed (using hot air gun), and the board cleaned ready for the replacements.

The EQ6 firmware was downloaded and then converted to HEX.  I had two 16F886's left in my storage box so programmed them with the remastered HEX file.  The PICs were then soldered in place and the board tested.  Now this is where my miss-direction started.  I came across a very comprehensive test program that basically simulates a handset and sends the strings of commands to interrogate the motor board.  So I tried this out and it fell over after sending the :e1 command to get the firmware version back from the PIC associated with the RA axis.  As it didn't get a response it halted running the rest of the commands rather than testing the second PIC.  If it had then it would have been clear that the new PIC controlling the DEC axis was fine and responding.  So thinking that the issue was with the TX (transmission line from PIC to PC) was still faulty on both PICs more testing was needed.  I spent a good day trying to trace out possible causes.  All voltages proved to be OK, including the 33v line for the stepper motors, so it wasn't a case of the PICs not running due to a supply issue.  I also replaced the 1N4148's thinking that maybe I was unlucky and had one or two duff ones... 

Anyway, I took the dog for his daily walk and whilst he spent his time sniffing every bush and tree my thoughts were on the repair of the board, as I had clearly missed something.  When I got back home I thought I would try an alternative means of testing and opened up a standard windows terminal.  I then sent :e1 and nothing came back, but sending :e2 returned  the firmware version... so I had a half working motor board.   I checked all the connections once more and the solder joints were fine.  I then thought that possibly the TX line was fine, but the issue was with the RX line.  The RX line that receives the commands from the computer or handset has only one component in series with it, a ceramic inductor, after which the traces go straight to the RX pins on both PICs.  Now I know the tracks to the DEC axis must be good as it was receiving and responding to the commands sent via the terminal application, so the fault could be the traces that run from the inductor to the PIC responsible for the RA axis.  I spent a good few hours trying to "bell out" the traces, but on a four layer board fully populated  it was impossible to discover where the brake was.  My thoughts are that it's internal,  so I simply bridged the link between both PICs with a wire and then tested using the terminal application.  Finally it responded and I could then test the communications using the synta test application.

This time the test application ran the full script and not only reported the firmware version, but also confirmed the board was an EQ6 and provided the mount specifics for the gearing and steps per RA revolution etc.

The board was then cleaned up and is now the first board to become part of this exchange program.  I also have a second EQ6 board donated to the cause.  This one again reported "No response Both axis" when the handset tried talking to it, and on inspection there is a nice chunk blown out of the DEC axis PIC microcontroller.  I'm hoping that replacing both PICs will resolve this, and that this board hasn't got internal damage like the other.  This board will have to wait as I have had to order some more 16F886's before getting the soldering iron back out.  

Naturally this program will only work if the board being sent in for exchange can be repaired. If the board has a glaring burnt hole in it, or some other physical damaged then regretfully I won't be able to help.  Also it is dependent on people who have already purchased replacements to donate their faulty boards to me.  If I don't have a repaired board to exchange then a normal repair could be considered.

 

[SteveBz]

On 03/05/2023 at 18:16, malc-c said:

Seeing how popular this thread has become over the years, and given that newer generations of mounts now have ARM based control boards in them,  I've been thinking of how best to try and help out others who find themselves in the same situation as the OP.  The idea is an exchange service, where someone with a faulty board can send me their faulty board(s) and in return will received a replacement that I've already repaired and tested.  This means less downtime for the SGL member, and takes the pressure off me to get the board fixed and returned quickly.  There will be a cost involved to cover the parts, return postage and possibly a pint or two for my time, but it will still be less than half the cost of a new replacement.  The only drawback with this idea is that I need "spare" donor boards to start the ball rolling.

To this end I would like to thank @SteveBz for his kind donation of a faulty EQ6 board and handset (plus associated cables) after it all stopped working one evening.  Steve had already been out and purchased replacements, so rather than the parts end up in the bin he kindly started the process by donating them to the cause.

So here's the first fix prior to clean up. 

It's been a while since I've last repaired a board so I was a bit rusty, and a few red herrings resulted in me straying down the wrong direction until the penny dropped and a likely cause was resolved.  After a visual inspection there was nothing glaringly obvious so an EQDIR cable was attached and the board powered on.  Communications were tested and sending :e1 and :e2 to the board resulted in no response form the board.  I first thought the issue might b the diodes, but in a bid to remove the two diodes to test out of circuit both were damaged, mainly as they were a sort of hybrid between through hole and surface mount component.  These were replaced with 1N4148s (through hole, but surface mounted to the pads).  I knew it wasn't going to be that easy, so both PIC microcontrollers were removed (using hot air gun), and the board cleaned ready for the replacements.

The EQ6 firmware was downloaded and then converted to HEX.  I had two 16F886's left in my storage box so programmed them with the remastered HEX file.  The PICs were then soldered in place and the board tested.  Now this is where my miss-direction started.  I came across a very comprehensive test program that basically simulates a handset and sends the strings of commands to interrogate the motor board.  So I tried this out and it fell over after sending the :e1 command to get the firmware version back from the PIC associated with the RA axis.  As it didn't get a response it halted running the rest of the commands rather than testing the second PIC.  If it had then it would have been clear that the new PIC controlling the DEC axis was fine and responding.  So thinking that the issue was with the TX (transmission line from PIC to PC) was still faulty on both PICs more testing was needed.  I spent a good day trying to trace out possible causes.  All voltages proved to be OK, including the 33v line for the stepper motors, so it wasn't a case of the PICs not running due to a supply issue.  I also replaced the 1N4148's thinking that maybe I was unlucky and had one or two duff ones... 

Anyway, I took the dog for his daily walk and whilst he spent his time sniffing every bush and tree my thoughts were on the repair of the board, as I had clearly missed something.  When I got back home I thought I would try an alternative means of testing and opened up a standard windows terminal.  I then sent :e1 and nothing came back, but sending :e2 returned  the firmware version... so I had a half working motor board.   I checked all the connections once more and the solder joints were fine.  I then thought that possibly the TX line was fine, but the issue was with the RX line.  The RX line that receives the commands from the computer or handset has only one component in series with it, a ceramic inductor, after which the traces go straight to the RX pins on both PICs.  Now I know the tracks to the DEC axis must be good as it was receiving and responding to the commands sent via the terminal application, so the fault could be the traces that run from the inductor to the PIC responsible for the RA axis.  I spent a good few hours trying to "bell out" the traces, but on a four layer board fully populated  it was impossible to discover where the brake was.  My thoughts are that it's internal,  so I simply bridged the link between both PICs with a wire and then tested using the terminal application.  Finally it responded and I could then test the communications using the synta test application.

This time the test application ran the full script and not only reported the firmware version, but also confirmed the board was an EQ6 and provided the mount specifics for the gearing and steps per RA revolution etc.

The board was then cleaned up and is now the first board to become part of this exchange program.  I also have a second EQ6 board donated to the cause.  This one again reported "No response Both axis" when the handset tried talking to it, and on inspection there is a nice chunk blown out of the DEC axis PIC microcontroller.  I'm hoping that replacing both PICs will resolve this, and that this board hasn't got internal damage like the other.  This board will have to wait as I have had to order some more 16F886's before getting the soldering iron back out.  

Naturally this program will only work if the board being sent in for exchange can be repaired. If the board has a glaring burnt hole in it, or some other physical damaged then regretfully I won't be able to help.  Also it is dependent on people who have already purchased replacements to donate their faulty boards to me.  If I don't have a repaired board to exchange then a normal repair could be considered.

 

Great job Malcom. 

[malc-c]

Finally the second EQ6 board that had a hole blown out of it was fixed this evening.

The old PIC was updated to the current firmware as well.  So that's 2 x EQ6 mainboards for the exchange program.  👍

[malc-c]

Not sure what the trend is but so far I've had three EQ6 boards donated to the cause... 🤔

The latest contribution was sent by @bottletopburly . This was an old board as it used 2 x 16F73's rather than 16F886's, and had a different fault compared to most of those discussed in this thread.  The DEC axis worked perfectly fine, however the RA was very jerky on the spooling up and down but would sound sweet on full slew speed.  It would also only run in one direction regardless what direction the mount was instructed to move.  The board had already been worked on as a jumper wire to one of the A3959SLBT drivers, but worryingly there were a cluster of via's missing close to the same chip.  These boards are four layer and looking at the two outer sides it's quite possible that these were blind so connected to an internal layer rather then through to the bottom layer.  I tried replacing both drivers on the RA, which made no difference, and as the PIC controllers were running an old 1.06v of firmware and lacked the bootloader the firmware couldn't be updated.  So this board was used as a donor board with all 3959's and some of the regulators being removed.

Even though this board was beyond repair it was still fun, and gave me more practice at replacing surface mounted components.  

My thanks to all those SGL members who have donated their old non working boards to the cause.  The two EQ6 boards that have already been repaired are now ready to find new homes should anyone need them....

 

 

 

[kostaskara9]

hello, i need some help with my board too

i have some questions

i cant find parts to replace this motherboard, and i cant find other similar motherboard

what can i do

 

i have a dobsonian 16inch goto

[kostaskara9]

1 minute ago, kostaskara9 said:

hello, i need some help with my board too

i have some questions

i cant find parts to replace this motherboard, and i cant find other similar motherboard

what can i do

 

i have a dobsonian 16inch goto

the motherboard is SYNTA MC004 Rev. F

 

[malc-c]

Where do you live ?  You should be able to order the PICs from one of the global suppliers such as DigiKey, Mouser or RS.  

On several occasions I've been asked to supply pre-programmed PICs to people outside of the UK and it has only ever gone smoothly once and that was using an expensive tracked and signed for service for all stages of the shipment.  Others either gel lost in transit, delivered to the wrong address, or delivered to the wright address but signed for by someone other than the addressee and thus have been stolen !!   I certainly wouldn't entertain a full repair from someone outside the UK where the handset needs to be sent along with the faulty boards, for these reasons.  It would also be very costly given the weight and value and I'm not prepared to take that risk with someone else's equipment, nor deal with the hassle of claiming on the insurance should the parcel go missing.

Look for companies local to you who do the soldering and assembly of third party products,  I'm sure they would be able to replace the two PICs for you once you have programmed them with the HEX code contained in this thread.  They may even be able to do the programming and soldering for you for a reasonable fee.

 

[kostaskara9]

https://stargazerslounge.com/topic/351363-any-ideas-on-repairing-a-slightly-blown-motor-board/

the motherboard its the same with this guy here

and it burnt an the same spot as his motherboard

can i fix it insted i buy a new one?

 

[kostaskara9]

2 minutes ago, kostaskara9 said:

https://stargazerslounge.com/topic/351363-any-ideas-on-repairing-a-slightly-blown-motor-board/

the motherboard its the same with this guy here

and it burnt an the same spot as his motherboard

can i fix it insted i buy a new one?

 

blown motherboard

 

[malc-c]

If it's displaying the "no response" message on the handset with power applied to the board then it needs to have the PICs replaced.  The process of removing the old microcontrollers, programming them with a converted firmware file and then soldering them back is documented in this thread.  You will need to get two PIC16F886 microcontrollers and a PIC programmer in order to load the code.  If you live in the UK then drop me a PM and I'll let you have the details on how to have the board repaired.  If you are outside of the UK then you will either have to buy the components and do the job yourself, or find an electronics repair shop that fixes laptops etc and get a quote from them for doing the work.

Unfortunately, you can't buy a replacement and drop it into the existing dobsonian base for the reasons the OP stated in his posts.  The new boards don't fit without changing the housings, which together comes to almost the cost of a new scope, hence who this thread got started

[malc-c]

Thanks to the kind donations from the members above I now have four EQ6 motor boards all working and tested, so for now the scheme is fine for EQ6 boards.  Each board comes with a report generated by interrogating the processors to confirm its fully working, so if you have an EQ6 that is failing to respond, either to the handset and / or EQMOD drop me a PM before ordering a new board...

[bosun21]

This thread has put me off from buying an EQ6 in the future for sure. Do the motherboards have a vulnerability that the other SW mounts don't?

[malc-c]

18 minutes ago, bosun21 said:

This thread has put me off from buying an EQ6 in the future for sure. Do the motherboards have a vulnerability that the other SW mounts don't?

No more than any other SW mount.  You have a couple of ground pins with a couple of +12v pins that provide power to the handset,  then TX / RX  (5v) comms.  Under normal use there is no chance of the 12v reaching the wrong pins as the EQ6 uses a D-9 connector and can only be fitted the correct way.  Same goes for most of the other mounts as the RJ plug will only fit one way.  However it's very easy to assume that a standard RS232 cable can be used as that is generally what D-9 plugs and sockets were used for, but using one blows the board as Pin4 of the SW connector is  ground buy on RS232 plug is the DTR pin, which will be on at  +12v (or more) when data is being sent.  Thus blows the power stages of the motor board.  Other pins on the SW connector that are used for +12v connect to other control lines on the RS232 connector, which switch form high to low or vice versa, so again, grounding the 12v supply from the motorboard.   The two pins that are connected direct to the PICs serial port via two diodes (6 and 9) are DSR and Ring - both of which swing between high and low voltages which is typically 12v.  Shoving 12v into a 5v CMOS port doesn't do the PIC any good, and damages the port

With the MC004 boards used in Dosonian mounts the inter-connecting cable uses the same RJ connector, but as they are wired differently end up doing the same thing, and shove 12v into the port.  If the designers had used their brains a little more they would have ensured that the supply pins used aren't the ones for communications and thus if the interlink cable gets plugged into the wrong hole...

[SteveBz]

9 hours ago, bosun21 said:

This thread has put me off from buying an EQ6 in the future for sure. Do the motherboards have a vulnerability that the other SW mounts don't?

I have an eq6 that works perfectly. I did change the handset once, I think with Malc here, but I also had problems from time to time with my eq5 and an eq3. All electronics go wrong from time to time, especially if they're left outside in an observatory. But the eq6 is the best mount I've ever had. I have no plans to change it.

Steve.

[malc-c]

On 04/10/2023 at 13:47, bosun21 said:

This thread has put me off from buying an EQ6 in the future for sure. Do the motherboards have a vulnerability that the other SW mounts don't?

Since I put out my plea for old boards from those who had already replaced their boards I now have five repaired EQ6 boards.  I have no idea why these are failing.  It might be that there are more EQ6's out there than any other mount.  Or it could be people using some form of adaptor for an EQDIR cable thinking the D 9 socket is a standard comm port ??

 

As I have far too many than really needed for the exchange program I might list the excess in the classified section to recover the cost of the components and time spent repairing them.