Jump to content

sgl_imaging_challenge_2021_3.thumb.jpg.30e9b298c34c80517e8b443ce153fce3.jpg

ozarchie

Members
  • Content Count

    42
  • Joined

  • Last visited

Community Reputation

9 Neutral

About ozarchie

  • Rank
    Nebula

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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
  2. You are truly the Jimmy Greaves of repairing Skywatcher MCs
  3. 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 d
  4. 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 t
  5. 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 y
  6. 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.
  7. 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 b
  8. 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.
  9. 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 so
  10. 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, D
  11. 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
  12. 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 t
  13. 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 Archi
  14. 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
×
×
  • 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.