Interesting conundrum

[malc-c]

I was bored this afternoon, so I programmed a couple of 16F886 PIC micros with the firmware for a SW goto mount and placed them on a solderless breadboard.  The Links were made and diodes added exactly as found on SW motor board that used these devices. 

Using an FTDI USB to serial module power was supplied and the TX/RX lines connected by jumper wires to the TX/RX pins of the PICs.  Plugged the USB cable in and device manager reported COM6, and set this up for 9600 baud.  Opening up a serial terminal and selecting Com 6 I could send :e1 to the two PICs and got the 0204 response confirming the PICs are working and the version of firmware was reported back.  I could even open a test application which interrogated the PICs further and all reported fine ( the PC was talking to an EQ6 !!)

I then programmed a 16F1455 with code that basically makes this PIC a USB to TTL serial device the same as the FTDI chip.  Bread boarded  this chip, and performed an initial test of linking the RX/RX pins together and then opening a second terminal window and setting that to Com 7 I could get back any text string, confirming it was working.  To prove this one step further I connected the TX from the FTDI module to RX of the 16F1455 and the RX from the FTDI to the TX of the 16F1455.  Now whatever text I send from the terminal window for com 6 was received by the terminal window of Com 7, and vice versa.  So I had established two way communications at 9600 baud.  So the TX and RX connections from the FTDI was removed from the 16F1455 and the 16F1455 was connected to the 16F886's, but no matter which way round I have the link wires, sending e:1 to the "mount" doesn't return the firmware version.  Which is strange as I know  the "mount" is working as it responds OK when using the FTDI module, and I know the 16F1455 is working as it was talking fine to the FTDI module...  But the 16F1455 just won't talk to the "mount"

Maybe this might explain why some people get issues with EQDIR cables that are not based on FTDI devices..    I even hooked up the 16F1455 to a DCC train controller that used serial in and out, and it talked fine to that and even updated the firmware via the PC application, confirming that the 16F1455 code works as expected.  So we have two USB to TTL serial devices, both work perfectly well yet when connected to a SW "mount" only the FTDI device can communicate with it.   I'll continue to mess about with this for fun as it would be cool to get it to work with the 16F1455, but  hopefully goes to show why we are always recommending FTDL based EQDIR cables for use with PC control of a SW mount.

[Tomatobro]

I purchased a job lot of FTDI boards from Ebay but now find that they will only work on vintage laptops and not Win 10 or 11. Seems like FTDI wised up to the chip clones and windows does not recognise the device. There is a downloadable patch but every time an update takes place it blocks the device. I now pay more and only get genuine FTDI chips. Does not relate to the above but thought I would share my experience

[Peter Drew]

Another conundrum is being British for 82 years and not being able to understand any of the above.     🙂

[Saganite]

You are not alone Peter.

[Albir phil]

4 hours ago, Peter Drew said:

Another conundrum is being British for 82 years and not being able to understand any of the above.     🙂

Yep all that went over my head,if only I knew why🤔