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

[ozarchie]

Sounds good. I located a couple of other PIC/HEX tools that I used during recovery of the EQ6 MCB.

I am not sure if they are of use to you, but I packaged them up and attached them.

• You need to install strawberry PERL for unPIC to work.
• hex_setup installs ICY Hexplorer Help, which has a lot of tools for different file formats in the File>export menu.

Cheers

Archie

 

 

picdisasm106.zip unPIC.zip hex_setup26.zip

Edited May 20, 2020 by ozarchie

[malc-c]

I'm downloading them now, before the moderators remove them as we are borderlining on hacking SW copy protection of their firmware

The good news is that the OP is sending me the faulty board for me to swap the PIC over, so I get to play and check it over.  What really sucks about this issue is the lack of support and assistance from Skywatcher and their UK and US representatives.  They either fail to respond to emails, or when they do they don't have any answers, which for a sole distributor of a  technical product is appalling.  The OP has been waiting days for a reply to his mail after they requested photos (which he had already sent) and is still waiting to see if in the event we fail to fix his existing motor board, if they are still able to source a replacement as all the new scopes come with "upgraded" motor boards, and then there is the issue of backward compatibility with his working AZ motor board.  These points remain unanswered.

Archie, many thanks for your help here... being able to get the HEX code from inside the wrapper was the one stumbling block that was holding this repair back... now we can move forward and hopefully by this time next week the OP will have a working board back in his scope.

[malc-c]

On 19/05/2020 at 01:57, ozarchie said:

Sorry for my late entry, but I saw your dilemna described on the EQMOD forum.

I had a similar issue with my EQ6 motor control board, shorted the 12V to the onboard PIC

Eventually, I replaced the PIC (a PIC16F886). I cannot completely read the part number from your photo but I think it is the same.

The PIC uses ICSP which is an in-chip serial programming algorithm. The connections work since you have already tried this with the 2.09 mcf firmware.

But I do not quite understand some of your statements. If the chip/MCB returned the version number (2.9.98 from memory), then both Tx and Rx are working (The PC had to ask the version, the MCB had to answer).Are you sure that only the Alt board was connected, and that it wasn't the Az board responding?

From the discussions I've had with the OP, the two boards are separate and connected via a cable, it could be that the PC software got a handshake from the PIC on the AZ board if this were the case....

If the Tx, Rx are working, then it is likely that the PIC may be sensing something about the motor/encoder inetrface. It must be the onboard interface, otherwise the motor/encoder would not work on the other controller.

From discussions with Chris on the EQMOD group, chances are that the firmware is the same in both boards, but some form of addressing, either in code or also in hardware such as pulling up a designated pin is used to route commands for AZ or ALT to the correct board

The motor driver is a l293D which is a "dumb" dual switch for the motor. From your picture, only half of it is used.

The encoder sensing is done via the quad 324 comparator and, probably, part of the 74HC14 inverter.  Did you replace both of these chips?

Yes, the OP has replaced both the L293D and the two other packages

From your photo, I can see a connection from the 8pin HC connector via L5 to pin 18 on the PIC (this is the PIC Rx line). This is the connection that is most likely damaged via 5V. Two pins up (pin20) is Vdd. If this is 3.3V, then it is even more likely that this is the problem, but I can only see one voltage reg on board and you have already measured it as 5V.

I had the OP test with a DVM and the pins are either 4.9v or 0v, so the regulator would appear to be undamaged and still functioning.

One below, Pin17 is Tx. Both Tx and Rx are joined to the six pin connector and that is working. 

So I would check the connections from the 8 pin connector to the PIC pins, 17, 18 and see what the voltages are there.

Pin 17 is 4.9v, Pin 18 also 4v on the PIC

 

Replacing the PIC is not difficult. In my case, the process was reasonably straightforward.

1. The MCF file for the EQ6 was just the binary image.
2. Use bin2hex program to create the HEX file.
3. Use an ICSP adapter to program the PIC. (Search DIY ICSP, or use a PICKIT4)
   1. The ICD2 connector, in conjunction with the 3x2 jumper block may let you do this on-board (you would have to buzz out the pin connections for me)
   2. Or, Program the chip externally using a 28pin surface mount adapter and a clamp to hold the PIC surface mount pins onto the PCB.
4. Solder it onto the main board, after removing the old one.

Best of luck,

Cheers,

Archie

 

 

 

 

 

[Astro-Geek]

I confess I hadn't realised how much time and effort people have put into the discussion on my thread since I last posted anything on it.  (I try to keep an eye on forum notifications, but I only seem to get any if someone quotes something I've posted).

Anyhow, it goes without saying that I'm indebted to everyone who has given so much time and thought to my problem with the board.

As Malcolm has said, the official response from every possible Skywatcher commercial source has been quite dissapointing. Many have not even had the courtesy to reply, despite their websites proclaiming that their mail order is still operational during ths Covid crisis.  One would have thought that any sales income would have been welcomed.

I can't say I have a definite answer to what replacment part was available, but the pitch seems to have been queered by Skywatcher "upgrading" their Goto Dobs with new PCBs that enable wifi.  This may mean that the incorrect motor controller board that the EU main agent Teleskop Express sent me (that had no components on it), might have been a "breakout" board that needed flyleads to a Skywatcher AZGTi board.  This is all conjecture on my part, trying to piece together some of the replies I've had.

If that is the case, then if my original MC004 Alt motor board is no longer available, then I would need to buy the breakout board, the AZGTi board and a new larger plastic housing.

...and that still leaves the unkown of whether it would work with my undamaged AZ axis motor controller board in the base, which is connected by an RJ lead.

Even though the fault was caused by my own stupidity by plugging in the wrong lead, it's dissapointing that a £1,500 premium telescope that is still in production is proving to be so difficult to source parts for, or even find out what is available and even what is needed.

So Plan B (repair) is still moving forward (and may end up as the only option), thanks to Malcolm's and Archie's extensive technical knowledge on the subject.

The complexity of the discussion regarding PIC programming has left me far behind, 🥴 even though I've dabbled for 50 years.

Thanks Chaps, much appreciated, (what a great resource this forum is). 🍺

ps.  Whenever I've tested or tried to program the motor boards, both boards were connected, and in fact it's the remotely connected AZ board that responds correctly when the left/right slew buttons are pressed, and the directly connected Alt motor circuitry that freezes when the up/down slew buttons are pressed.

[malc-c]

Just think of it as Kama.... when my first HEQ5 board failed I had no idea how to fix, so got stung £100 for a new board.  When that failed (again) I reached out to the forum and was given contact details of someone who might help, and the net result was the board was fixed for the cost of a couple of small capacitors....  So if I can do the same for anyone else then I'll try.  It's also been an interesting challenge to resolve this one, and I find it all a lot of fun...  

It does show just how well this forum gels together though.  Having got you to replace all the chips other than the PIC and we then came up to that hurdle of how to code the PIC with the downloadable firmware. Archie with his expertise in coding tools jumped in and we now have a possible solution.

Anyway hopefully the PICs will be here soon, as will the board and then I can report back with an update.  

[Mick J]

Great work all and an interesting read, well over my head but outstanding.  Good luck with it.

[ozarchie]

Hi Malcom,

Just a thought on testing the board.

Many injet printers have a combination DCMotor/Encoder that drives the main feed roller.

Many inkjet printers end up under someones desk somewhere.

You my be able to scavange one of these devices. You could then hook up the motor and encoder and test operation.

I will see if I can find a photo.

Cheers

Archie

Edited May 20, 2020 by ozarchie

[ozarchie]

12 hours ago, malc-c said:

I'm downloading them now, before the moderators remove them as we are borderlining on hacking SW copy protection of their firmware

 

 

Hi Malcom,

That certainly was not the intent. In general, these disassemblers allow you to understand the operation and create a mapping to the hardware. In the absence of schematics and when you are debugging hardware this is very useful. All of the programs are available online and each discusses their own raisond'etre.

There are a lot of great software projects out there for controlling telescopes with steppers (Astro-EQ, OnStep) and even some for controlling telecopes with DCMotor/Encoders( Using Stellarium & Arduino ). All with proven and supported source code.

 

12 hours ago, malc-c said:

The good news is that the OP is sending me the faulty board for me to swap the PIC over, so I get to play and check it over.  What really sucks about this issue is the lack of support and assistance from Skywatcher and their UK and US representatives.  They either fail to respond to emails, or when they do they don't have any answers, which for a sole distributor of a  technical product is appalling.  The OP has been waiting days for a reply to his mail after they requested photos (which he had already sent) and is still waiting to see if in the event we fail to fix his existing motor board, if they are still able to source a replacement as all the new scopes come with "upgraded" motor boards, and then there is the issue of backward compatibility with his working AZ motor board.  These points remain unanswered.

Archie, many thanks for your help here... being able to get the HEX code from inside the wrapper was the one stumbling block that was holding this repair back... now we can move forward and hopefully by this time next week the OP will have a working board back in his scope.

 

[malc-c]

I know... its not as if I am programming PICs and reverse engineering their boards or anything...

Well even though it was a lash up, I was able to program the PIC and replace the old one, with only one casualty which was fixed with a link wire.    The only way to know if this has worked is to send the board back to Astro-geek and let him hook it back up with the AZ board and see if its worked.  There are of course many "ifs".... Hopefully Archies's ripping of the code worked, hopefully the upload to the new pic works (it was verified and came back as a match), and hopefully none of the discrete components have blown internally that prevent communications between PIC and handset....

Don't touch that dial... we'll be right back

 

[Astro-Geek]

Well it was  a Valiant effort from Archie and Malcolm, and Malcolm got the repaired board back to me in superquick time and did a very neat job with the tiny components.

...but I'm afraid the fault persists, with all of the symptoms exactly the same as before, namely:

1. It powers up the handset and runs the AZ axis (left/right buttons) perfectly, responding to speed changes etc..
2. The moment the Alt axis buttons are pressed (up/down) there is no response and the hand controller then freezes until it is switched off and on again.
3.  When I switch the boards over, (connecting the Alt board to the AZ motor and the AZ board to the Alt motor),  then the opposite occurs, ie the Alt axis moves perfectly, albeit via the left/right buttons, and then when the up/down buttons are pressed, the AZ axis freezes the controller without moving.
4. I think that proves there's nothing wrong with the motors and encoders, or the AZ board, (which was unplugged anyway, when I blew the Alt board).
5. I've also ruled out the handset and cable too, because I have identical ones with an old AZ goto mount and they work with that, and the HC and cable from that doesn't work with this board.
6. I guess the power must be ok too, as it runs both motors individually and the handset with no problems.
7. The only other quirk with my testing is that these results are all with v.03.08 firmware on the handset.  When I tried v03.39.05 on the handset, I could get no response from either motor, because the handset simply said "no connection with MC".  Presumably this was because the newer HC firmware does more HW checks when starting up.

I've now heard from the main distributor, it sounds as though the pre-upgrade boards are still available as replacements, but there is a 4 month wait for them.

As I've said though, I'm most grateful for the time and effort from Archie and Malcolm and the other replies I've had on this thread.  🍺🍺🍺

[malc-c]

Well we tried...

I was limited to how much testing I could do without any handset, and having an HEQ5 didn't want to repeat the mishap by connecting my EQDir cable to the board !  

Just to add to the summary Astro-Geek has listed.  He has replaced the three other chips on the board, and the PIC that I programmed verified that the code Archie made available was loaded correctly.  The attempt to upload the MC firmware via the PC application and hand controller crashed after updating MCU1, which may be due to the same issue as why the controller freezes when the ALT buttons are pressed, or it might be due to the lack of a bootloader (it's anyone's guess).  But assuming that the original PIC was damaged, the replacement should have worked if other components on the board haven't failed.  This leads me to believe that one or more of the discrete components may be aiding and abetting the issue.  

It's been both interesting and frustrating trying to get this resolved, but at least now OVL have had it confirmed that these boards are still available form Skywatcher, even though the lead time means it will be approaching winter by the time it gets here  

If anyone has any other suggestions, please feel free to jump in

[Padraic M]

Have you checked with telescop-express? They claim to have one in stock. Can't tell which revision it is.

https://www.teleskop-express.de/shop/product_info.php?products_id=10989#cs

I've been following this thread with interest - a replacement mother board for my HEQ5-Pro is due to arrive next week. I haven't been able to trace the error on my own board, but it also blew while connecting an EQMOD cable. It's a shame that this happens so easily. I suspect that the PIC serial in/out pins either shorted to 12V or got a voltage spike as everything except the communications with the controllers seems to work. Just like yours. Once I'm sure that the new board actually fixes the problem, I'm happy to do some reverse engineering on the old board to see if I can shed any more light on the issue. Maybe we need to start a wiki on SW mount problems???

btw, I know that a lot of people including malc-c have been able to fix this issue by replacing the two large electrolytic capacitors, but this puzzles me as it looks like they are just smoothing capacitors on one of the power regulators.

Edited May 24, 2020 by Padraic M

[malc-c]

Thanks for the input...

I believe Astro-Geek actually ordered one from them, only to find out it was a blank board with no components - this is the case with newer version as it seems that rather than use two identical boards as is the case now, newer versions have all the components on one main board with a breakout AZ daughterboard that just has connectors on for the AZ motor and encoders.  The board was sent back as it was mis sold as their website (still) shows the older revision F board that is the same as the faulty one.

My HEQ5 board was an easy fix because it was the power supply that surged and blew the caps....   How did you blow your HEQ5 with a EQDir cable... From memory only three cables need to be connected to the mount from the FTDI chip, TX/RX/GND ?

Seems a common issue where some EQDIR cables stick 12v up the TX pin on the connector... 

I like the idea on setting up some sort of wiki... but it would be cool if we could find someone who knows how these boards work.  I know the guys over on the EQMOD group (Chris in particular) knows the command set inside out in order to develop EQASCOM / EQMOD, but how the boards process that and route commands etc is going to be a stumbling block.  

Normal commercial practice when designing products is to try and standardise the PCB component listings where possible, so my guess is that Synta will use the same PICs, same driver chips and same basic communications circuits for the two types of systems they employ.  By that I mean where DC motors and encoders are used, such as in the goto dobsonian range of scopes, they will all use the same components, likewise  where stepper motors are used as in the HEQ5 / EQ6 the motor control boards will all use the same components.  It seems the PIC used is the same irrespective of the type of controller used.  So my theory is that if you reverse engineered say the communications side of things on one board it would be the same for all of them.  The only real difference between boards will be the firmware as that would need to be specific to the gear ratios and equipment fitted, and possibly matched to the firmware on the supplied handset.

If you have the skills to produce a working schematic by reverse engineering your board then please get the ball rolling

[Astro-Geek]

11 hours ago, Padraic M said:

Have you checked with telescop-express? They claim to have one in stock. Can't tell which revision it is.

https://www.teleskop-express.de/shop/product_info.php?products_id=10989#cs

......

Thanks for the suggestion Padraic, but as Malcolm has said, that is the item on TS that I ordered a couple of months ago, and which turned out to be a completely different item.  They paid fro the return postage and refunded me, but haven't been able to help me any further with obtaining the correct board.

I noticed myself a couple of weeks ago that they were still showing that page with exactly the right item that I wanted, and that it was in stock (raising my hopes !), so I contacted them about it.  Unfortunately their reply was that they still couldn't get the right item and that they would update the page.

As it's still not been corrected it would be unfortunate if another customer ordered it like me and had to return it.....

[Astro-Geek]

I'll keep this thread updated as and when anything significant happens in case anyone else finds themselves in the same boat as me with one of these mounts.

Plan "B" ( Malcolm's very generous work on the board together with Archie's suggestions and other member's input on here to attempt to fix the board), has not been successful, (despite extremely vailant efforts). I'm therefore still pursuing Plan "A", to obtain an official Skywatcher replacement part.

Despite the 300p goto Dob being something of a premium current telescope, managing to obtain the neccessary motor control board is very difficult, due to the unprecedented difficulties faced by companies with the ongoing Covid situation and also the unfortunate fact the Skywatcher appear to be in the process of significantly altering the mechanics and electronics of these Dob Goto mounts.

The actual single faulty component, ( an MC004 - Alt  motor controller board ) appears to be no longer available from anywhere, and the alternative "upgraded" parts needed to replace it are proving to be very difficult to assess, let alone obtain.

That board has been superseded by another with integral wifi, and it may no longer work with my existing undamaged AZ motor controller board, as that is now quite different too.  To compound the problem, this mount now has new plastic covers to accomodate those new boards, and worse still, the motors inside appear to be completely different, (as the attached pictures show).  Skywatcher seem to have turned them around, so that the gear and pinion and cluches are now on the outside, instead of being behind the panel, as in my original goto dob mount.  This appears to be to enable them to be now adjusted externaly, via large plastic knobs.

So the problem now is to try and assess how few parts I need to buy to "mix and match" with these newer components, ie whether I can just fit the newer "upgraded" Alt motor board into my housings and whether it will successfully work in concert with my existing AZ motor board.

If not, the total cost of the parts will probably not be economically viable,  let alone the predicted 4 month delay for them to arrive.

Watch this space.......🥴

 

[ozarchie]

Just a few questions regarding the firmware. Earlier, you 'succeeded' in uploading firmware to the device. At that stage, this was your process:

1. MC Firmware loader v1.74 and DOB Goto Motor Controller Ver 209.mcf
2. I connected it to my PC via the skywatcher cable from the RJ11 on the handset to an RS232/USB adapter in the PC.
3. The firmware loader identified the existing motor firmware as v 2.9.98
4. It then went from 1%  to 100% of programming "MCU1", then after a few seconds, said that the update had failed, and to try again.

One of my questions was whether the Az board was connected when you did this.

• Can you try this again without he Az board attached, or does the handcontroller need the Az board attached to work?
• I cannot find V2.9.98 as motor firmware, can you verify that, with the Az board attached?
• The current firmware that Malcolm programmed was 2.09 for dobsonan mounts. Can you verify what, if any, version is returned without the Az board attached?.
• How long did it take to go from 1% to 100%? (Malcom, what was your programming time?)
• (There is also Firmware: Universal DC Motor Driver with Built-in Wi-Fi, Version 3.20  I decided against that one because of the WiFi)

Elsewhere on SGL  (search EQMOD Pinout):

         EQMOD                            MC004 (from photo)

1. Gnd                                  Gnd
2. NC                                    NC
3. NC                                    NC
4. GND                                 GND
5. Tx                                      Rx
6. Rx                                      NC
7. +12V                                 Tx
8. +12V                                 +12V

You can see why it blew up!. 12V from EQMOD into the MC004 Tx line. But!!! , what you have done should have fixed it.

The other possible candidates for failure are R2/D3. From the photos, it looks like R2/D3 may be in the Tx line circuit. Check with a multimeter that R2 is 10k. Check ithe the 'diode' setting on your multimeter that D3 shows low resistance with the Red lead on + and Black lead on -. It should show open/very high resistance when you swap the leads. (The Az motor works because it is on the connector side)

Cheers

Archie

 

EQ6 Cable Diagrams 2006.pdf

[ozarchie]

To be honest, upgrading may have it's own problems.

The DCMotor/QuadEncoder architecture in these mounts is usually driven by the quad encoder characteristics.

You would have encountered this with optical mouse pointers for PCs. The resolution of the encoders sets the sensitivity.

The problem may relate to matching the existing encoders to the new boards.

Maybe something like

https://www.instructables.com/id/Control-Your-Telescope-Using-Stellarium-Arduino/

might be a way forward.

 

Edited May 25, 2020 by ozarchie

[Astro-Geek]

Thanks for the detailed suggestions Archie. 👍

I'll check the things you mentioned and then reply again.

[malc-c]

9 hours ago, ozarchie said:

Just a few questions regarding the firmware. Earlier, you 'succeeded' in uploading firmware to the device. At that stage, this was your process:

• Can you try this again without he Az board attached, or does the handcontroller need the Az board attached to work?
•  

Cheers

Archie

 

EQ6 Cable Diagrams 2006.pdf 73.35 kB · 0 downloads

This bit is will fail.... because the new PIC doesn't contain the bootloader which gets interrogated by the PC application.  I proved this point yesterday by having a USB to 5v TTL serial convertor connected to a DIL version of the chip in my EasyPIC5 dev board (yeah its old, but does the job  )  - Uploaded the HEX files you kindly provided and then tried to re-upload the official download using the SW PC application.  On each occasion the MC board could not be found.  I tried a few of the bootloaders available on the net and again the PC app would not recognise the chip.  My guess is that SW have written their own bootloader to work with their PC application so that the correct handshake is given and received.

[malc-c]

Archie, programming the PIC using the EasyPic5 board took a couple of seconds to program and verify

[malc-c]

OK, to the best of my abilities using the images provided  (including one I took with the PIC removed which helped a lot) this is what I came up with for the serial connections.  I may have missed a connection, it was difficult working from the images having to remember the flip them when tracing, so I'm not 100% this is accurate - I'm sure I must have missed a link somewhere

I'm sure AstroGeek can have better luck confirming this as he has the board in front of him.

The links Lx are shown as looped wires

Pins 6 and 8 of the handset may not be linked - hard to tell, but three may be some webbing around pin 6 to the same copper fill as pin 8 ?

 

 

 

Edited May 25, 2020 by malc-c
Corrected schematic

[Astro-Geek]

14 hours ago, ozarchie said:

Just a few questions regarding the firmware. Earlier, you 'succeeded' in uploading firmware to the device. At that stage, this was your process:

1. MC Firmware loader v1.74 and DOB Goto Motor Controller Ver 209.mcf
2. I connected it to my PC via the skywatcher cable from the RJ11 on the handset to an RS232/USB adapter in the PC.
3. The firmware loader identified the existing motor firmware as v 2.9.98
4. It then went from 1%  to 100% of programming "MCU1", then after a few seconds, said that the update had failed, and to try again.

One of my questions was whether the Az board was connected when you did this.

• Can you try this again without he Az board attached, or does the handcontroller need the Az board attached to work?
• I cannot find V2.9.98 as motor firmware, can you verify that, with the Az board attached?
• The current firmware that Malcolm programmed was 2.09 for dobsonan mounts. Can you verify what, if any, version is returned without the Az board attached?.
• How long did it take to go from 1% to 100%? (Malcom, what was your programming time?)
• (There is also Firmware: Universal DC Motor Driver with Built-in Wi-Fi, Version 3.20  I decided against that one because of the WiFi)

Elsewhere on SGL  (search EQMOD Pinout):

         EQMOD                            MC004 (from photo)

1. Gnd                                  Gnd
2. NC                                    NC
3. NC                                    NC
4. GND                                 GND
5. Tx                                      Rx
6. Rx                                      NC
7. +12V                                 Tx
8. +12V                                 +12V

You can see why it blew up!. 12V from EQMOD into the MC004 Tx line. But!!! , what you have done should have fixed it.

The other possible candidates for failure are R2/D3. From the photos, it looks like R2/D3 may be in the Tx line circuit. Check with a multimeter that R2 is 10k. Check ithe the 'diode' setting on your multimeter that D3 shows low resistance with the Red lead on + and Black lead on -. It should show open/very high resistance when you swap the leads. (The Az motor works because it is on the connector side)

Cheers

Archie

 

EQ6 Cable Diagrams 2006.pdf 73.35 kB · 0 downloads

Ok, I've now checked the things that Archie mentioned:

When I power up the scope with the AZ board disconnected, it beeps and say "no connection to MC - standalone mode only"

I was still able to enter "PC Direct Mode", but the programming software couldn't show the current version and the programmer couldn't reprogram to PIC.  (with a "no connection" message).

I then powered off and reconnected the AZ board, the programmer then verified the current version as V2.9.98, and I was able to run the program option again, which took 42 seconds to reach 100%, and then after a further 10 seconds it displayed the failed message. (so I guess it was only able to verify and program the PIC on the AZ board).

I'll check D2 and R3 with the meter and then make another reply.

Thanks for the suggestions, keep them coming !  (please) 🙂

 

Edited May 25, 2020 by Astro-Geek

[Astro-Geek]

12 minutes ago, Astro-Geek said:

The other possible candidates for failure are R2/D3. From the photos, it looks like R2/D3 may be in the Tx line circuit. Check with a multimeter that R2 is 10k. Check ithe the 'diode' setting on your multimeter that D3 shows low resistance with the Red lead on + and Black lead on -. It should show open/very high resistance when you swap the leads. (The Az motor works because it is on the connector side)

R2 is 10.1k 

D3 is 700 ohms pos to pos and neg to neg  and more than 2000k ohms reversed.

I checked the same points on the AZ board and they were exactly the same  (unfortunately).

Edited May 25, 2020 by Astro-Geek

[Astro-Geek]

3 hours ago, malc-c said:

Pins 6 and 8 of the handset may not be linked - hard to tell, but three may be some webbing around pin 6 to the same copper fill as pin 8 ?

The handset socket is the RJ12 6p6c,   the RJ45 8p8c is the linking cable to the AZ board.

(or have I misunderstood what you're saying Malcolm ?)  🥴

[malc-c]

3 hours ago, Astro-Geek said:

The handset socket is the RJ12 6p6c,   the RJ45 8p8c is the linking cable to the AZ board.

(or have I misunderstood what you're saying Malcolm ?)  🥴

I was under the impression it was vice-versa. - so that would mean the EQDIR cable was connected to the socket where the link cable would go.... hence how 12v was placed on the TX line, and how the AZ board was not connected at the time.

My apologies