Jump to content

SkySurveyBanner.jpg.21855908fce40597655603b6c9af720d.jpg

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


Astro-Geek

Recommended Posts

Hi Malc,

In response to " The other thing that perplexes me is if you link the TX to RX pins on a serial port it just echos back what is sent, so with the two pins on the RJ11 linked, how would the handset know which is data being sent or received ?"

I think this is the issue. Somewhere I recall a comment that early HEQ5 motor controller (MC) only worked with early HEQ5 handcontroller (HC).

HEQ5-EQ6.png.f8dd1feed4f9ed01eb50575530807065.png

 

As you can see from this excerpt from the HEQ5 manual, the HC Mount port has three comms lines, Rx , Tx, and DROP.

Somewhere in the original HEQ5 HC, the HC changed Rx, Tx, Drop into RxTx, Drop for the MC, and I think that is where the issue lies.

If your HC doesn't do that, then the MC will never understand the comms.

 

HEQ5-AZEQ6.png.a1d928bd8a2eba99cdb9ed8d610e4396.png

 

The EQ6/AZEQ6 only shows Tx, Rx. So not all HCs can change the comms for the MCs.

The MC003 board may be OK, but cannot make itself understood!

So, assuming the DROP line is working on the MC003 and is logic level HIGH, you could put together a little logic circuit to do this for the PC.

  1. Tx (PC) -> RxTx (MC)
  2. RxTx (MC) .AND. DROP -> Rx (PC)

image.png.712d004226e9c3f0379dc7c9bccdf4c3.png 

 

If the DROP line is active LOW, you will need an inverter before Pin2.

A lot of this is conjecture, so please feel free to comment :)

 

 

Edited by ozarchie
Link to comment
Share on other sites

Archie, thanks for the input, and I'll have a rumage to see if I can locate one of the logic chips, if not I'll order some form RS.  

I've contacted the owner who sent me the board and handset and he said he has never had the mount working.  The scope came in this state from the original owner, and is circa 15 years old.  Either the handset has been very well looked after, or its relatively new as there is hardly a mark on it !

I've opened up the handset to see if there is any means to identify the version... and it's thrown me a curve ball !

P1019371.JPG.9703101f0a1341c4ddb7a848cf5c2c31.JPG

Now I know Synta own Celestron, but from googling images of handsets  it would seem that all the Celestron synscan handsets have the celestron branding above the LCD screen.  This handset is plain other then the word Synscan underneath the LCD suggesting it is a Skywatcher handset.  Yet other images for a V4 SW handset also show the same Celestron board inside, unless these handsets are standard and can be programmed with either SW firmware or Celestron firmware I'm really confused ?

Link to comment
Share on other sites

OK we might be getting somewhere... but I need someone with a little more experience to analyze these results and comment on them as they raise some questions.

I hooked up my PC based logic analyzer.  It's basic and only samples for 10 seconds at a time, but this is enough to get some idea as to what's happening.  One channel connected to the drop pin from the handset. A second to the combined RX/TX pins of the RJ11.  The third and fourth to the UART of the first PIC.  I set it sampling and plugged in the power.  The handset powered up, initialised and then displayed caution, and then both axis no response message 

This was what was captured

1250071647_powerup.thumb.png.38e520c090fa5ce20cffaa8071d5f3ae.png

It seems to send an initial handset to the PIC, which gets an initial response, as you can see the TX trace responds straight after the data on the TC/RX line is passed through the diode to the RX pin on the PIC..  I'll zoom in a little so you can see in more detail

1020957684_powerup2.thumb.png.a45b8c548a4e6824df9a85c663d0a978.png 

You can see by the traces that some form of data is being sent back form the PIC as the pulse lengths vary suggesting 1's and 0's

I then took a further capture after pressing the ESC key twice, forcing the handset to re-initialise.  This was the result

1516865780_afternoresponsereinitial.thumb.png.bc73706a1b0da7c2b3e4229439793753.png

Now this where things don't seem right.  The handset sends data, which then appears to trigger the PIC to respond and says "hello" back.  But then sends some more data around 50ms later and this time gets no response. back.  My first thought was that with the RX/RX pins commoned at the socket I was simply getting echo back, but looking at the data traces they appear to my untrained eye to be different rather then identical.  If this was the case then you would expect the echo each time the data was sent to the TX line, would you not?  So why does the second set of pulses get no response ?

So... Here's my thinking:

  • The PIC's are programmed correctly and are running fine as the response back after the initial power on / re-initialization they respond with a different byte of data than they receive.
  • The fact that the handset then displays the "alt/dec no response" message would suggest that either it doesn't recognise what it received back, or it's it recognises the result, but it's wrong / incompatible with its firmware
  • The  initial "are you there" data gets a response back with "yes", but then for whatever reason (blocking diodes on the TX lines reversing ?) when the handset sends "what version MC are you" the PIC doesn't understand and fails to respond. 

Now one thing I may have laying around from the time I had my EQ5 mount is the official SW PC direct cable that has a DB9 connector on one end and a JR11 (or 45??) on the other.  I thought that I could use the observatory PC as it has a standard serial port and try and reflash the MC with a different firmware using the SW updater software, but there is only one suitable firmware.  I've used the same 209 version used on MC04 boards as the MC03 and MC04 look very similar, and it states this is for skyliner goto dobsonian mounts between 8" and 16".  Also, I'm not in a position to cover the cost of a new handset should using the cable damage the handset because of any compatibility issues (plus I've never actually used that cable as I built an EQDIR cable within days of getting the mount).

Comments and suggestions please......

Edit: the handset reports "Synscan ver 04.37.03"

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

A further update.  I connected up both PICs to the anzlizer and got this trace.

2056070563_Initial2pic.thumb.png.e8a2cf49329d0ee9a67b3fd7b978d201.png

 

Here's a close up of the left hand side

468563172_Initial2pic-closepic1.thumb.png.32343ef7f640414ebc9846767427ce48.png

 

And the right 

833909045_initial2picsecondpic.thumb.png.ba66047721d4e5973d93b89f2475095c.png

 

Just noticed I should have swapped over the wires so that the traces made more sense, IE RX then TX and not vice versa 

To me this just seems to be echoing back what has been sent, much the same way as simply shorting TX to RX together..... :(

 

 

Link to comment
Share on other sites

 

 From Skywatcher document:

On most the Alt/Az mount, TX and RX lines are connected together, and there is another  line(Drop) to indicate that the TX/RX bus is busy.

The Drop line is controlled by the master only,  which means the master device should pull the Drop line to low level when it starts to send a  command and keep pulling it low until it receives the full response from the motor controller, or,  a time-out occurs.

The motor controller will send its response immediately after it received and  process the command, thus the master device should release the TX/RX bus as soon as possible  after the last bit of the command is shift out of the hardware register. 

The motor controller pull its TX line to high level with a 5.1K to 10K resistor, other than that, it  does not strongly pull the TX line to high level and other devices can pull the TX line to low level  without problem. 

 

Some TTL comms info:

 

When microcontrollers and other low-level ICs communicate serially they usually do so at a TTL (transistor-transistor logic) level. TTL serial signals exist between a microcontroller's voltage supply range - usually 0V to 3.3V or 5V. A signal at the VCC level (3.3V, 5V, etc.) indicates either an idle line, a bit of value 1, or a stop bit. A 0V (GND) signal represents either a start bit or a data bit of value 0.

TTL Signal
 
Link to comment
Share on other sites

So I read the comms as:

s 0 1 0 1 1 1 0 0   0x3A

s 0 1 1 0 0 1 1 0   0x66

s 1 0 0 0 1 1 0 0   0x31

s 1 0 1 1 0 0 0 0   0x0D

 

HC: 0x3A, 0X66, 0X31, 0X0D (:f1<cr>)

MC: 0x3D, 0x30, 0x30, 0x33, 0x0D (=003<cr>)

 

TxRx-SS001a.thumb.png.5621cf4ba543880ef18c5a5e466dd460.png

 

I guess it shows that the code is working.

The thing that is wrong is that PIC1 Tx data is not showing up on the RxTx data.

 

Edited by ozarchie
Link to comment
Share on other sites

Archie, thanks for the input.  In the last set of images there seems to be data on both PICs TX lines.   Where would you suggest I start looking in order to confirm that the PICs are OK and that the switching is working?

The scope is a 15 years old Skywatcher 250px flextube with AZ Syncscan GoTo  so I've assumed that the same firmware for the Skyliner (2.09) dobsonian as used on the MC04 boards in previous fixes (all dobsonians) would be the correct  one to use.  

I did have one of the SW serial cables (DB9 serial to RJ11) cable which I believe is  used to upload firmware to the handset and mount, but as I'm not in a position to be able to cover the cost of a replacement handset if i fried it I'm reluctant to try and update the firmware, and I've already used the last two sets of PICs I had on this board, and due to its age replacing the PICs could end up bricking the board completely as more and more pads lift.  So far the ones that have lifted have not traces to them and are not connected.   The only other firmware for "AZ goto mount" but also has the same version 2.09.

Looking at the EQ6 schematic, which uses separate TX and RX lines, would breaking the track on the PCB between the TX and RX pins and then hot wiring the lines in the same way the EQ6 does using the two diodes on the TX lines work ?

Link to comment
Share on other sites

You are correct in saying that both the PICs are transmitting data, but only PIC2 ( I am not sure which IC is PIC2) Tx data gets to the TxRx line.

From the photos, U4 is associated with D2, and U5 (I think) is associated with D3. The common TxRx pullup resistor is R3, which is next to the connector.

So either D2 or D3 is not working dependant on whether U4 or U5 is PIC2 on your traces. I would check the connection from D2/3 to pin 17 of the PICs first. The solder connections are in the shadows in the photos so I cannot really tell.

 

It looks like there is a solder bridge between Pin6 of the RJ11 nad R1 but I cannot tell if it is a track or solder.

Link to comment
Share on other sites

It looks like the RJ45 (8pin) connector goes to the Az motor. Is that correct?

It sounds like other people have blown the MC by mistakenly plugging in an EQMOD connector into this RJ45.

You could try connecting the TTL level from the EQDIR interface to the TxRx line.

If the PICs are not monitoring the DROP line, then they would just receive the data anyway.

You would need to put a blocking diode on the Tx line from the PC:

  1. Tx (PC) -> Diode Cathode (Bar); Diode Anode -> TxRx (MC)
  2. TxRx (MC) -> Rx (PC)

Ther MC already has the 10K PUR.

Edited by ozarchie
Link to comment
Share on other sites

Hi all,

Well we made progress to a point... but it was one step forward and two steps back...

I tried swapping the SMD Diodes with IN4148 signal diodes - still no joy.  I tested the original diodes and as far as I could tell with my DVM they were OK, so replaced them back on the board.

The next task was to reflow the solder joints on both PICs to make sure there wasn't a dry joint, and checked for any bridges on the solder joints on the links I added.  Still the same response.

I had received the Ok from the owner to try flashing the firmware using the PC-Direct cable and handset.  So I popped up to the observatory, pulled the power lead from my HEQ5 and plugged it into the MC003 board. Connected the handset, plugged in the PC-Direct cable to both the handset and the PC and powered everything up.  The Handset displayed the normal "no response" message so it was put into PC-Direct mode.  The firmware loader was launched, detected the handset on com 1 and to my suprise reported the firmware version of the motor board ! - Gobsmacked I clicked the MC version button and it cleared and came back with a version 2.9.99.  So I proceeded to load up the 2.09 firmware for dobsonian scopes, downloaded direct from the SW download page.  It progressed through to 100% for MCU1 then reported a failure.  The board was powercycled and I tried again, but this time the firmware updater could not get a ping back from the board.

657430747_dobupdate.png.3160503427c4648d83050d0c73b93ccc.png

I tried several times to upload the firmware and each time the loader could not connect to the motor controller, so it looks like the update bricked the motorboard :(

Now I no longer have stock of the PICs, and I could order more and program them again, but we could be back at the same stage.  Plus every time I remove the PICs there is a risk of more and more pads lifting, and so far I've been lucky that the ones that have lifted have been unconnected, or simple to bridge / repair.  The board is circa 15 years old which makes it more fragile, and the attaching of test wires is also having a toll on the board. 

I have no idea why the handset would not retrieve the board details post initialisation, yet would respond via the handset in PC-direct mode when the uploader application was used..

To be honest this one has now gone beyond my ability of basic diagnosis and changing re-programmed PICs which with later boards have proved to work.  I'll return it along with the handset to the owner, who has resided to continue to use the scope manually.

So it's more like 4.0 to us, but that last goal was disallowed :)

Unless anyone has some other suggestions.

 

Link to comment
Share on other sites

Archie,

Would modding the board like this work

modded.thumb.jpg.3d4a7670e0104cbd3a7d8f0deedfc650.jpg

 

Basically cut the track between the TX and RX pins on the RJ connector, then run fly leads as show (assuming RX on the RJ connect is related to the handset and not the PICs)

Link to comment
Share on other sites

I am still surprised that you could not get the other Tx line to work.

I think you are showing the diodes back to front. I think the cathode (bar) end of the diode should be connected to Tx - see below.

Diode AND gate

So Tx1and Tx2 are the same as A and B in the above diagram. When Tx1 or Tx2 is at logic high, the resistor pulls the TxRx line to logic high. When Tx1 or Tx2 go to 0, the diode connected to that line conducts and TxRx goes to (0 + diode forward voltage drop).

Hmm .. maybe that was the original issue. The previous repair mounted a new diode but placed it wrong way round. Do you have any other pictures of the board? It is difficult to see on the diodes where the bar (white line) is to identify the orientation.

But, yes, that should seperate the connections. You don’t need to run the Rx wires as they already are there. Just remove the onboard diodes and disconnect the Rx pin from the Tx pin on the connector. You can hot glue the diodes to the back of the ICs and run the leg of the diode to the IC pin or the pth that goes to the existing (removed) diode. You will need a 10k pull-up resistor to Vcc on the connector side of the diodes as the cut will disconnect R3 from the Tx line.

Edited by ozarchie
Further info
Link to comment
Share on other sites

Archire, like I said I have no idea what's going on with this board. 

What diodes would you suggest.  1n4148 or 1n4001 ?

What if I cut the tracks completely to isolate the TX and RX pins on the RJ connector and at the PICs, and then wire it like this ? - If using the MCLR pull up is a bad idea I can always connect a 10k to the other side of the resistor which is 5v.

This is of course assuming that the updating of the firmware hasn't corrupted the PICs.  There is no ICSP header on this board - and I doubt the board would take desoldering the PICs again 

 

hotware.thumb.jpg.a582b53ab8a17faaf43b114ffd31beb9.jpg

Link to comment
Share on other sites

Hi Malcolm,

I think you are trying to do too much.

If you remove the two surface mount diodes on the bottom of the board, it will isolate the Tx pins on both ICs. The only cut you will then need to make is to separate Tx and Rx on the connector. Just the cut that you have marked between the two pins. You don not need to do the cut near R3.

Rx.

  1. The Rx pins are connected between the two ICs and are connected to the Rx pin on the connector.
  2. There is nothing to do.

Tx.

  1. Remove the two surface mount diodes on the bottom of the board.
  2. Cut the track between the two pins on the connector.
  3. There is a plated through hole (pth) near the board edge just near where you marked the cuts to the Tx lines adjacent to the ICs. (Text C12,  and C8)
  4. You can solder the diodes into those holes. Use 1n4148. Make sure the Bar end of the diode (black stripe) is closest to the pth. (You are showing it the other way)
  5. Join other  ends of the diodes together and to a 10k resistor.
  6. Solder the other end of the resistor to the pth near the MCLR resistor.
  7. Use a wire to join the junction of the diodes and resistor to the Tx pin on the connector.

The only issue I can think is if Rx and Tx are the other way round on the connector.

If that is true then:

  1. Make the cut as shown between the connector pin2 and R3
  2. Change the Tx wire from pin4 to pin2
  3. Join R3 to pin4
Edited by ozarchie
Link to comment
Share on other sites

Thanks for the notes.  My logic was that by segregating what's on the board and running new wires direct it would remove any possible issues with the existing tracks or any hidden damage that is preventing the PICs from communicating.

It's 3.30am here, so I'm off to get some sleep, and will take another look later.   

Link to comment
Share on other sites

Hi Malcom,

I mocked up the MC003 with two proto boards using the circuit above. (Make sure the diodes 'point' to Tx)

After flashing with the 2.09 firmware, the devices respond to :e1 and :e2 with =020998.

MCF Firmware loader reports MC Version as 02.09.98.

I tried :f1<cr> as per your trace above.

The response was =003<cr>

I tried a few others (a, b, h) and all returned reasonable values.

After running the firmware update (which completed successfully for MCU1), controller 2 no longer responded to serial commands.

I will try to find a way to do the RxTx mod and see if that succeeds.

Good luck with your mods.

Archie

 

 

 

MC003Proto.jpg

Edited by ozarchie
Link to comment
Share on other sites

Hi Archie,

Thanks for doing that, appreciated.

I've just checked the board again using the PC-Direct mode on the handset and firmware uploader and it no longer communicates with the board, so it looked like doing the update I tried yesterday has corrupted the firmware.  I'll try soldering a few wires to the PGN / DAT / CLK pins and see if I can program the PICs again, this time in circuit.  - Once I've done that and the code verifies I'll do the modifications suggested.

Malcolm

Link to comment
Share on other sites

We'll it looks like we've scored another goal in extra time :)

The first thing I did this morning was to re-flash the PICs with the same 209 hex file I originally used.  Now as the PICs were soldered onto the PCB and there is no ICSP header or pads I had to solder the five wires directly to each PIC.  Once the wires were connected to the programmer the code was uploaded and verified.  The process was repeated for the second PIC.

I then cut the track between the two pins of the RJ connector where the handset plugs in.  In hindsight I should have left it intact and tried the repair / modification first as I later bridged the pins once more.  I  removed the existing surface mounted diodes and cleaned the pads.  I then soldered A 1n4148 signal diodes directly to RC6 / TX pin on each PIC with the lead closest to the bar on the diode attached to the leg of the PIC microcontroller.  The other legs of the diodes were then bent and soldered together.  A 10k resistor was soldered between the 5v supply and these diodes, with a wire making the connection between the diodes and pin 2 of the Rj socket.  I then  bridged the two pins to see if this fixed the communications issue, with a view of adding additional wires for the RX pins if this didn't work.

It was then a case of taking up to the observatory to hook it up to the PC in PC-direct mode with the SW cable to check that the loader application could read the firmware.  I was surprised to see the handset went from "initialising" to the Synta handset version and firmware it was running rather than reporting "both axis no response".  I didn't bother to put the handset into PC-Direct mode to check the comms as it was clear the board was now responding to interegation from the handset.  To confirm this I grabbed the video camera and shot the video below

Now from my experience of repairing these boards that have been damaged through plugging in EQDIR cables it's only the PICs that get damaged.  The rest of the components seem unaffected after doing this, so I'm hoping that when the owner receives the board and connects up the motors he'll report back with confirmation that the scope is now fully functional.  The question is why do people purchase and use an EQDIR cable to use EQMOD  with cobsonians when both are designed to work solely with EQ mounts !

Anyway, it looks like we're at 4-0 now :) 

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

It won't win any awards for looking pretty... but its functional.  - And before anyone asks the resistor is several mm above the board, so won't come into contact with the PCB, it's just the angle the image was taken..  I've since added some insulation to the legs of the diode, and cleaned off the flux with some IPA.

P1019376.JPG.9f05341ef56279a87bf951f5b35f5b5e.JPG

All that's left is to pack it up and send it back to the owner

  • Like 2
Link to comment
Share on other sites

I love this stuff!

Much of the PIC malarky goes over my head but I was playing with electronics back in the 70's, 80's and 90's and used to really enjoy fault finding and repairs. 

OC71 anyone? More recently I've been watching the youtube series below, most likely wasted on you guys fixing this stuff but It's reawakened my interest in digital electronics.

Anyway, I really hope your work pays off. It's been a pleasure to follow.

 

 

  • Like 5
Link to comment
Share on other sites

5 minutes ago, Paul M said:

OC71 anyone?

Along with the OC35 the OC71 are my favorite transistors, even now I look out for boxed mint "mullard" versions...

I am also fond of the original ECC81 valves of the mullard variety, again very hard to get mint original examples now.

Alan

  • Like 1
Link to comment
Share on other sites

47 minutes ago, Alien 13 said:

Along with the OC35 the OC71 are my favorite transistors, even now I look out for boxed mint "mullard" versions...

I am also fond of the original ECC81 valves of the mullard variety, again very hard to get mint original examples now.

Alan

I think my last valves got either used or dumped. Only really used them for "plug and play" tv repairs :)

As an aside, back in the day, both my mother and mother-in-law worked at the Mullards valve factory in Fleetwood when they were young women. Long, long since gone. I mentioned valves to a colleague claiming to have an interest in Hi-Fi. "Never heard of them mate", some Hi-Fi buff... 

Maybe modern solid state amps can deliver, I'm sure they can, but that wasn't always the case :)

....I only mention all this in place of a musical interlude while that there Synscan board is reunited with its owner... :)

  • Like 1
Link to comment
Share on other sites

1 hour ago, ozarchie said:

You are truly the Jimmy Greaves of repairing Skywatcher MCs

Couldn't have done it without my wingman :)

Seriously, thanks once again for your input and assistance... I've learnt a lot more about these boards, and how they work.

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.