ozarchie

Hi Malc, and TrevaP I think there are a lot of people on different forums with MC015 and MC020 boards that would appreciate any info you can share. Both these boards share a lot of common power supply circuitry (including the now notorious Q3). The MC020 contains a Q4 (unpopulated) with similar circuitry for the +12V supply line. I have been working with Andrew Johansen (also from Oz) in researching the Q3 circuitry. Similar faults have been reported on the groups.io site https://groups.io/g/SkywatcherEQ8/topic/94480706#5424 which also references a similar problem on the Cloudy Nights forum. While I have a preliminary version of the circuitry, it is only based on the photos that Malc sent me. If you can share any insights, I will try to incorporate them with the circuit and perhaps jointly publish a note for all forums. Cheers Archie

Hi All, Firstly, good luck with the project. The SW design based on PICs has been around for a while. I obtained my first "Upgrade" kit for the Orion EQ6 in ~2004. While the attached files are EQ6 based, you may be able to get some info from them. Andrew Johansen has a Syntatester program that will help in debugging your hardware. You can find him on most astronomy forums. Cheers Archie Schéma électrique eq6 v1.pdf PCDirectCodes Vx.txt Dossier technique v4.0.pdf

Hi Alan, Though I trained in Oz, I started at 20th Century Electronics in New Addington, later Centronics Ltd. My first 'valve' was a quadrupole mass spectrometer tube made by that company. It was used to measure the exit gas in steel furnaces (originally used in guiding missiles) and my task was to modify it for use in intensive care and respiration. All gone now unfortunately, but a great and interesting start to electronics. Cheers Archie

You are truly the Jimmy Greaves of repairing Skywatcher MCs

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

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. The Rx pins are connected between the two ICs and are connected to the Rx pin on the connector. There is nothing to do. Tx. Remove the two surface mount diodes on the bottom of the board. Cut the track between the two pins on the connector. 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) 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) Join other ends of the diodes together and to a 10k resistor. Solder the other end of the resistor to the pth near the MCLR resistor. 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: Make the cut as shown between the connector pin2 and R3 Change the Tx wire from pin4 to pin2 Join R3 to pin4

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. 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.

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: Tx (PC) -> Diode Cathode (Bar); Diode Anode -> TxRx (MC) TxRx (MC) -> Rx (PC) Ther MC already has the 10K PUR.

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.

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>) 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.

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.

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). 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. 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. Tx (PC) -> RxTx (MC) RxTx (MC) .AND. DROP -> Rx (PC) 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

Hi Malcolm and Padriac, Glad that all is restored. Congatulations Malc for your persistence and dedication. Hopefully, if I get back to the northern hemisphere, I will get to meet you in person and enjoy a beer or two. Meanwhile, I wish you both clears skies and warm nights. Cheers Archie

BTW, I tested the theory about R4 setting the board type. If you ground pin5 on the PIC, it does change the board response from Alt to Az (after cycling the power). I saw the circuit that you posted regarding the Rx, Tx lines. If that is the case, then "Tx" is/was connected from the RJ45/7 to Pin6(RA4) on the PIC, rather than Pin17 (Tx). Pin6 is also connected to R1, whick I think is a pullup resistor to Vcc. The EQMOD cable probably has Pin7, 8 shorted in the cable, which is why the onboard12V was shorted to the "Tx" pin. You could possibly check that R1 is still Ok and still connected to Vcc. It also means that the motor control software commands won't work from a terminal program as the Rx data line is multiplexed with the Tx data line i.e. it is half-duplex. In my case, I have them connected separately, the same as your FTDI/USB convertor. But, you could run the Tx line from Pin17 (using a jumper wire from the top of D3) to the Tx input on your FTDI/USB converter. That should work. Anyway, good luck. I will check later on progress. Cheers, Archie

MC004d.hex

Hi Malcolm, Yes, it got a bit hectic there for a while, so not surprising that a few things were buried. I think the pinout on the ICD2 is numbered wrong, and has an ususual connection. Pin6 of the connector is connected to MCLR\ - usually Pin1 of ICSD. Similarly, Pin2 of the connector is CLK- usually Pin5 of ICSD. And there is a strange resistor between MCLR\ and Vdd - R20. I would use your FTDI USB - 5v logic serial adaptor to serial update the device using the firmware update program from SW, rather than try to figure out the ICD2 connector. Cheers Archie

Hi All, According to a capture of the "Update" command, the reason it is failing is that it cannot find mcu2. So I think it should work when both motors are there. Cheers, Archie

I have looked at your HEX files, but am not sure what you deleted. If I compare HEQ5.hex with HEQ5config deleted.hex, it appears that the first line was deleted. This is the 'line length' line in Intel HEX format. At the end of the HEQ5.hex file, there are three lines of interest. The last line :00000001FF is the 'end marker' for the file. The second last line :2043E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA000FF003A, I am not sure. :20 is the start token (20h is the length) 43e0 is the offset word address the next 16 words are data The last word is the checksum of the record (003a) The third last line :20 4000 007F 007F 007F 007F 00FF FFFF FFFF FFA2 2F00 05FF FFFF FFFF FFFF FFFF FFFF FFFF FFE2, are the configuration words. :20 is the start token (20h is the length) 4000 is the offset word address, I think that, in the data, CONFIG1 is word eight (0000-(0007), and CONFIG2 (0008) is the ninth word. finally checksum (FFE2) I have edited your HEQ5.hex file as HEQ5a config deleted.hex and get C1E5 as the checksum. I do not know what the config bits should be, so I will leave that up to you. Cheers Archie HEQ5a-config deleted.hex

Hi Malcolm, I have managed to program a 886 PIC with the MC004 code. It does respond to Skywatcher firmware uploader, but also fails to upload code. However, it does respond to serial terminal commands, such as those used on the EQ6 - see attached image. So I am stuck. I don't really know how to help now.

Could you send me a screen capture if the error screen? The other think to check is the CRC. Maybe it needs be programmed as well. I think (but am not really sure) that it is held in the EEPROM, so maybe a dump of the EEPROM area? I think the real test is probably whether the motor control board responds to the commands detailed in the document. Cheers, Archie

Sorry All. I had forgotten to share the project. You should be able to access it now, rather than cloning it. https://easyeda.com/jmarchbold/mc004v1

I have started a documentation schematic: https://easyeda.com/join?type=project&key=bd5cc1cca39ab3ae2d634da8b17612be Anyone should be able to edit it, a bit like github for schematics.

Well done Malcolm. That smells like success to me! I am attaching the Skywatcher low-level protocol document (from Skywatcher, not me). Here you will find the motor control commands used by Skywatcher to talk to the motor control boards. It all happens at 9600 baud. Ane example command ":e1: gets the firmware revision from an EQ6. It MAY work on these boards? To answer one of your previous questions about how ALT is distinguished from AZ - From the enlarged photos: If you look near pin4 of the PIC, there is a trace going to R4, which is populated as 0R0 on the ALT and not present on the AZ. My guess is that selects the board operation. Regarding the TxRx lines, note from the Skywatcher document: UART: 9600bps, 1 start bit, 1 stop bit, no parity check. Signal level: 5V or 3.3V. On most of the EQ mount, the TX and RX lines are separated. The motor controller will send its response immediately after it received and process the command. 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. EQMOD talks to the motor controller using separated Tx and Rx lines, so if you get this to work, you can indeed connect a correctly wired EQMOD cable directly to the motor control boards. You would then need to configure EQMOD for the reported 'steps' and you would have an EQMOD telescope. Not sure about its use for astrophotography though .. you would really need to change it to a GEM Cheers, Archie skywatcher_motor_controller_command_set.pdf

https://notepad-plus-plus.org/downloads/v7.8.6/ with Hex editor plugin: https://superuser.com/questions/1324217/how-do-i-install-the-notepad-hex-editor-plugin

OK, cool, Imight leave you to it. Good luck. Cheers, Archie