Jump to content

NLCbanner2024.jpg.2478be509670e60c2d6efd04834b8b47.jpg

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


Astro-Geek

Recommended Posts

1 hour ago, helium said:

Well, there's more trouble ...

Maybe if I asked, wouldn't you translate it for me?

AZ-EQ6 Motor Controller V0211.bin 32 kB · 1 download

Binary file converted to HEX as requested :)

However I was unable to test as I cannot find the value of crystal the AZ-EQ6 board uses.  Tried 20 Mhz which is common on MC003, MC004 and HEQ5 boards but couldn't get a ping back, even tried 16 Mhz which is often a popular value.

Downloaded the MCF file as the BIN file you provided resulted in a warning about the configuration bits, but that to had nothing set.  Saved the converted HEX file with configuration bits set in MPLAB and it still complained, but loaded and verified the code accordingly.  So I'm not sure if the reason it won't respond to :e1 is down to the wrong crystal used which will affect the serial port timings, or that the AZ-EQ6 MCF file Skywatcher provide has been doctored in some way making conversion difficult.

If you could advise what timing crystal is used that would help.  I tested on an 18F2520 as I don't have any K variant and my breadboard supply is 5v, but  as far as I can tell the K version is just the 3.3v version with a few added functions, but  code should run on both  (I welcome someone to correct me it that is wrong ? - Archie ??)

By all means try the attached code and report back

 

 

AZ-EQ6.hex

Edited by malc-c
removed hex - need to test
Link to comment
Share on other sites

I think on this one you may stuck.  On all the previous MCF files, the configuration bits (that set the timings, code protect, and basic function setting on the PIC) are included.  But the AZ-EQ6 MCF file form the Skywatcher website doesn't appear to have these in the code (as far as I can tell as I get warnings when loading the first conversion of the BIN file to HEX).  So we have no idea what are the correct settings for the oscillator, or other configuration settings.  This could be why I can't test the code, or it could be that when I import the converted base line HEX file, and then select the device in MPLAB it sets the config bits to values that are default but not correct for the hardware on the board ?  It could also be that I'm limited to testing on the 18F2520 as the programmer I have doesn't support the 18F25K20.

Anyway, I've attached the first straight conversion from MCF to  BIN and then to HEX for you to try as well

AZ6.hex

Link to comment
Share on other sites

Thanks for the image and clarification.... I did try it with a 16MHz crystal but still couldn't get it to respond.  I could program a 16F885, and get that to respond with a 20Mhz crystal, but then if I swapped out the PIC for an 18F2520 and changed crystal to a 16 Mhz one - nothing......  But this is now getting beyond my level of expertise... 

Link to comment
Share on other sites

I think the warning about the config bits is a read herring - It's down to the fact that I'm using the wrong variant of the chip.  Hopefully when you replace both PICs with the corrected code it should work OK

Link to comment
Share on other sites

1 hour ago, helium said:

Only one of the two PICs is bad. Do both still need to be replaced?

How do you know only one is blown?

Most boards have the RX and TX pins of both PICs connected together, all be it with blocking diodes on one line as discussed above... I would have thought that if for whatever reason 12v was placed on these communication lines that both PICs would have had their UARTs damaged.  IF you are confident that only one PIC has been damaged and the other is in good order (ie the handset is reporting no response from only one axis ) then no you wouldn't need to replace both PICs.

Link to comment
Share on other sites

Yeah I know. The RA axis controller is bad. I accidentally plugged the guider port into the hand control. Its supply voltage went to the guider port. That is the U4 PIC pin 27-28 (PGD, PGC). (Hand control Vpp +, and GND). The error occurs when the Mgen calibration moves the RA axis. The sidereal rate stops. When  calibrate the DEC axis, it goes down fine.

Link to comment
Share on other sites

I received a very interesting PM from  Pablocarlac this afternoon.... It seems Skywatcher have thrown us a curved ball......

On the SW website it  currently list just one version of firmware for Dobsonian scopes - Skyliner series - 8" - 16" - Version 2.09.  It would seem that this firmware is suited to the MC004 motor boards fitted in these scopes.  The confusion lies where scopes are fitted with older MC003 boards which, as Skywatcher have discontinued, is no longer supported and thus the firmware for those boards has been removed.  So for anyone who has an older scope with MC003 motor boards they may run into an issue if they download and update the firmware form Skywatchers website as they will be installing the MC004 firmware.  There is nothing in the update process that indicates the firmware is for the newer board.

Anyway, through his/her research, and insistance, Pablocarlac  has obtained the MCF file for the MC003 board, which has been shared with me for conversion to HEX and we are currently in testing to confirm the scope behaves as it should.  If it checks out I'll upload the MC003 firmware and HEX file to this thread for future reference should anyone need it.

Edited by malc-c
Link to comment
Share on other sites

Well as I was typing that last post, Pablocarlac dropped me a PM confirming that the handset now displays the right location and positioning  co-ordinates and appears to function correctly, although a clear sky is needed to confirm full functionality of the mount.

So here's the correct firmware for an MC003 Board, both binary and HEX format.

MC003_V0214_A.hex MC003_V0214.MCF

  • Like 2
Link to comment
Share on other sites

Hello.

Finally I can say that it worked well !!! Both tracking and goto.

I share a photo and a small video.

The problem was, as Malc-c commented that it was loading the wrong firmware. The page contains the updates and not the original firmware.

I was able to get the specific firmware of the board thanks to the technical support of SW.

I want to thank Malc-c for his help, he was fundamental to the success of the repair.

I didn't know anything about Pic.

Hopefully our experience will serve someone who encounters this problem.

Greetings

moon.jpeg

  • Like 1
Link to comment
Share on other sites

We'll the pandemic has hit the astronomy hobby in more ways than just the lack of telescopes and mounts.  Trying to get 16F886's is becoming near nigh impossible... I've been told by my normal supplier that an order I placed at the beginning of June should / might  be here by the middle of July....  Other suppliers I used for my components have lead times of up to 54 weeks !!!!!

Fingers crossed that things improve, otherwise it will effect our efforts to keep these old scopes running....  I currently have a pair of MC004 boards that used the last two PICs I had in my electronics hobby box.  So hopefully I'll receive my  order before I receive any more requests to try and effect a repair of a faulty motor board, otherwise it's going to be a long wait.

 

  • Like 1
Link to comment
Share on other sites

I've lost count now... is this 6 -0 or 7-0 ???? :)

I was contacted by another SGL member a few months back who had a non working SW goto dobsonian and had came across this thread and asked if I could program and send a couple of PICs to him as he has a family member who was able to swap out the PICs.  I sent him my last two 16F886's programmed with the MC004 code that was used in the OP's boards.  Anyway, the other week he contacted me again and asked if I would be willing to have a look at them as the handset was displaying "alt/dec no response" message after the PICs had been swapped out.  So details were exchanged and I received the boards on Tuesday.

Cutting a long story short, I had tried most of the things covered in this thread, and everything seemed to check out, but I still kept getting a failed ALT board message.  As luck would have it, the three 16F's I had ordered direct form Microchip (it's handy having an account with them :) ) arrived via TNT this morning... so I promptly re-programmed another PIC and heated the board up once again.... 

The new PIC was soldered into place, and a jumper wire added as one of the pads had suffered damage in the original repair.  Hooked everything up and crossed everything hoping it would work, but alas no.  At this point I was about to throw in the towel and packed up the boards and handset in readiness to return it to the owner.  But something was niggling me... something just didn't settle.  So made a cuppa and went to sit in the sunshine.... I was missing something, but couldn't quite put my finger on it.  I came back in and read through this post... and then the penny dropped.....  Pins 2 and 4 of the handset connector are shorted together.  Then D3 is connected between that junction, and tied high by a 10k resistor...so I should be getting continuity between the cathode of D3 and pins 2 and 4 of the connector, but I wasn't.  The DVM in diode / continuity mode read a voltage, so it was just testing the diode. 

S3060001.JPG.c9a177041696ebbc390f5f506c2bd38b.JPG

 

S3060002.JPG.0f42318a8ca19c82de9dadad61a5fd6d.JPG

I bridged that connection with a bodge of a job just to prove the theory.  I connected the two boards together, plugged in the handset and applied power... The screen on the handset displayed the "initializing" message... I waited and rather then showing "Caution...." followed by the "Alt/Dec no response" message, it showed the handset firm ware version...... It's alive !!!!

 

 

  • Like 4
  • Thanks 1
Link to comment
Share on other sites

Just for the record, the delighted and very grateful SGL members that Malcolm has helped out are myself and @Tomatobro. We had a plan B if the boards were not fixable, but might have known that @malc-c would score the winner in extra time.

We should now have a Syncscan/Alt/Az RF switchable controlled Dob.:hello2:

1406368751_image01057.thumb.jpeg.c4ccadda7f29d964e3db44ac679c5070.jpeg

  • Like 1
Link to comment
Share on other sites

LOL - it almost went to penalties  :)

Looking forward to seeing how it all works....  Hopefully you have the repaired SW boards to fall back on if tomoatobro's box of trick need tweaking....

  • Like 1
Link to comment
Share on other sites

Well I don't know how to call this one - its another repair, but of a previously repaired board - so we can't increase the board count !

Maihil had a MC003 board that was repaired as detailed in this thread, but due to reasons that would only be apparent a lot later would not perform gotos correctly, but still responded to the NSWE buttons being pressed.  In his efforts to resolve this it appears damage to the board occurred and the handset once again displayed the "No response both axis" message.  Miahil chose to take up fishing rather than astronomy (sorry private joke) and sold the scope, being fully transparent about its history, and pointed the new owner to this thread and suggested he contact me with a view of a further repair.  Miahil was also courteous to notify me of what he had done when I dropped him a PM regarding the availability of the correct firmware.

So after a few PMs I received the board back, along with the handset and leads.  I had managed to source a pair of PICs which were programmed with the MC003 firmware, and after a physical inspection opted to replace the previously replaced PICs.  I had to be careful as each time the board is heated there is a risk of damage to the pads and thin tracks on the PCB.   I used the wife's hot air gun that she uses in her cardmaking hobby and to my surprise it got the board hot enough to melt the solder so the chips just fell off, with only one casualty, which thankfully was an unused pad. 

The two new PICs were soldered back in place, jumpers made where appropriate and the diodes reconnected.  I held my breath as I powered up, and the "initialising" message on the display seemed to last an eternity, but I was relieved to see the handset firmware reported.  I took a few photos, and then tidied up the switch wiring before notifying the new owner that the board has life again :)

The kit was repacked and taken to the sorting office and is now winging its way back to him via special delivery.  Fingers crossed that this time the MC003 firmware that has been posted here works, but we won't know that until the new owner can test under a clear night... that'll be Christmas then !! :)

S3100003.JPG.58f309a82a2264d9edb8a0ee0ad2d503.JPG

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

Hello!
Well, we programmed the PIC. Just one. Then we soldered it in place. After powering up, I upgraded the firmware to what went into the PIC to be the same in both. Since the weather has been bad since then I couldn't try it properly, but it rotates both axes as it should. It also does the 3-star calibration and finds the target when I type it. (presumably because I tried in a room). If Mgen does its job well, this project is a success ....... But that would require a cloud-free evening ..

  • Like 1
Link to comment
Share on other sites

Well we have an X-File case.  The last board that I repaired as shown above was packed up and returned the same day it was received, and the following day the owner connected everything up only to get the same "no response both axis" message...A few suggestions vi PMs and we still couldn't get a response....  So I've asked for the kit back so I can take another look....  Hopefully the PICs are not blown again... the ones I ordered back in June won't be in stock until August !

Link to comment
Share on other sites

Good night.

It is rare that it fails. My board MC003 it still works perfectly.

I have been doing a lot of abusive tests to add a wifi module with ESP without success yet and it still works fine.

I have tested it with both 5k and 10k resistors as pull up on tx, rx and it works with both.

Link to comment
Share on other sites

Well pleased to say that having received the repaired board back for inspection everything was looking OK, although on closer inspection it seemed as if one of the LEDs may have become dethatched as it wasn't quite as secure as I had hoped.  Out with the soldering iron and a few moments later the joints were remade.  Everything was powered back up and I was so relieved to see the display giving the firmware version and not the "no response both axis" message.

The Diodes were then physically secured to the PCB using some infilling PVA, and once cured and tested for a good dozen power cycles, the kit was repacked and returned via next day delivery, which the member graciously covered the cost of.  Today I received a PM and pleased to hear he's a happy customer :)

 

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

  • 2 months later...

Over the past couple of months I've been in conversations with a fellow SGL member who was experiencing issues with his HEQ5, where the handset reported the classic "No response" message.  The only problem was the global crisis of shortage of electronic chips caused me a big headache as my normal suppliers were backordering and the "assured" delivery date kept being shifted, and had to be cancelled when it went to October 2022 !!  However I managed to source some more, at inflated prices but hey ho !

Well I received the kits this morning and started to do some checks before replacing the PICs.

The first thing I noticed was the poor soldering of the wires form the interface board to the header that connects to the main board.

S3300001.JPG.7d3c36ce055a931b833d734009bb631d.JPG

 

These were removed and pads underneath inspected.

 

S3300006.JPG.b4026f0bcc4d50a25dd6d9adcd1091c7.JPG

 

Once  cleaned it was noted that there was some corrosion around the pads and on one track, but testing continuity proved the track OK  so the wires were remade and resoldered

S3300007.JPG.cee349a3082bc755c67dd160464c1fa5.JPG

 

This time flush with the PCB.

Other than a little oxidisation the original PICs looked fine and the board was clean.  The electrolytic caps looked fine and didn't need replacing.

The curly handset cable was tested for continuity which was fine, so the kit was put together and the fault confirmed

S3300004.thumb.JPG.a5b9dbcfc6b7b2916906c6f5f2cb8534.JPG

 

Now it reported just one axis that had failed to respond, so I checked both blocking diodes and they were OK, so rather than mess about with replacing just the single PIC, as I have no idea if the DEC processor could fail at some stage I opted to program and replace both PIC to be sure.

The old PICs were removed from the board and the pads cleaned - pleased to say that on this occasion no pads lifted.   The new PICs were soldered in and the flux cleaned with IPA.

The steppers were plugged in once more, and the interface board connected to the motor board.  With the handset plugged in power was applied.

S3300008.JPG.61e75369c4931f4a29dd00d774ada389.JPG

A few more checks and then pressing the NSEW buttons at speed 9 and the motors spooled up nicely

 

 

All that was to repack the kit and get it ready for returning when the post office opens on Monday :)

Another success.

 

  • Like 3
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. By using this site, you agree to our Terms of Use.