RS485 Cable from FTDI, Cause an extra ZERO BYTE to appear?

DavidM

Hi,

I have been working on my RS485 Project for some time now ( too bloody long), and I have finally bought myself a RIGOL DS1052E Oscilloscope, ( Still learning to use it, but getting there)

I have an existing Propeller project with my RS485 circuit ( I have posted info on this here some time ago), and I have that connected to my iMAC via USB.

Previously, I made a very rough RS485 board, connected to a level converter and a USB to RS232 Adaptor.
I got this to work as far as receiving data into my MAC from my propeller/rs485 device, But controlling the RTS via realbasic software had issues as far has timing was concerned. ( basically there is no way of knowing when the last bit has been transmitted form the imac)

So I bought one of these..

http://www.ftdichip.com/Products/Cables/USBRS485.htm
(USB-RS485-WE-1800-BT is the one i got)

Which has the RECEIVER & DRIVER ENABLE controlled by the Start & stop bits of the data. ( the CBUS4 parameter of the FT232R Chip is set to TXDEN)

So I hooked it up and I have noticed that at the end of every message (regardless of message length) ( via my realbasic serial app) I get an EXTRA ZERO BYTE appearing!

Because I now own a scope!, I tested the signals coming out of my RS485 Device ( on the Prop side) and my data being sent out does not have this extra ZERO Byte, I then hooked up my previous RS485 Contraption and I don't get the ZERO BYTE, I only get it when I use this FTDI Cable!

So, I did some more tests and If I keep the DRIVER ENABLED continuously, I DON'T get the extra ZERO BYTE appearing, I also noticed that on prop start up I get this ZERO BYTE as well, So for some reason the DRIVER ENABLE or DISABLE of my prop side RS485 Device is causing an extra ZERO BYTE to be sent.

Does anyone have any idea why this could happen?

(PS I have sent a question off to FTDI Support but I have not heard back from them yet)
(PSS, I have a modified FDSerial Object which controls the RS485 Chip perfectly!)

Thanks

Dave M

kwinn

I would suspect it is related to having the start/stop bits controlling the receiver/driver enable. The timing for that is very tricky. Not a problem sensing the start bit to enable the driver but to turn it off you need to know the baud rate/bit time to eliminate the problem of disabling the driver too soon. It can not rely solely on the data signal unless it can guarantee a full character time in the stop state.

DavidM

Hi Kwinn,

Thanks for the reply,

I am assuming that the FT232 Chip is handling the timing (re different baud rates), as it's internal buffer of which detects the bits being sent and received.

I have tested again, and definitely that DISABLING the Driver on the transmit side causes this problem.

I can't get my probes ( of my scope) into the USB/485 Converter as it has a hard moulded case. I would like to see what the bits are doing there in relation to the driver enabling line.

I have sent off another message to FTDI Support, and i guess I will have to wait for their reply.

thanks

Dave M

DavidM

HI,

This problem has been solved!

The RS485 Chip used on the FTDI does not have TRUE FAIL SAFE, So they suggested adding biasing resistors, This only fixes up the node with the biasing, not the whole network and does not work with terminated line too well.

So I hacked open the USB Plastic case and changed the RS485 Chip they used to this one..

MAX13485EESA+

This device has the same biasing/failsafe circuit built in which is the same as the MAX3535ECWI+ Device that I use.
It was also pin compatible with their PCB.

I check on my scope for the signal and now I get the correct signal and I don't get any more ZERO BYTES, even during startup.

The zero bytes WERE caused by the RO , staying at zero volts ( logic zero ) this "Simulated" a start bit at the end of a message being sent. The true fail safe now makes sure that the RO is always HIGH. therefore not causing a "Start BIT" to appear!

I have only tested SENDING messages from my PROP/RS485 device to the MAC ( Via the FTDI USB/RS485 Cable converter).

I am yet to test RECEIVING data to my prop device. The idea is that the FT232RL chip will handle the RE/DE toggling automatically, so that the RTS line from the MAC software does not need to be used as there is no way of knowing when the last bit was sent out of the MAC's buffer, but the FT232RL has its own hardware buffer and this is used to toggle the RE/DE lines.


Also,

FTDI said they are reviewing this product and will change the RS485 chip in the next revision so that it has TRUE FAIL SAFE.

thanks

Dave M

Erik Friesen

Interesting, I had a similar experience with these cables, never took the time to figure it out.

kwinn

DavidM, great troubleshooting. Thanks for taking the time to post the information. I really appreciate it when a problem cause or solution is posted to wrap up a thread.

DavidM

Thanks Guys!


I haven't finished yet!,

I still have to transmit from the MAC to the PROP and NOT USE RTS lines, This is why I used the FTDI chip in the first place it supposed to handle this for you. I have had lots of issues with software control on the MAC/Realbasic side of things,mainly not knowing the status of the buffers.

I have a modified FD Serial Object to handle RS485 timing, this is working really well. I still need to work out error detection etc.

I am also working on a small serial tool in realbasic, that helps with RS485 development, I might post it here as it can be used on MAC/PC & Linux and you can use the source code.

If I could find how to make screen grabs form my oscilloscope RIGOL DS1052E, then I could post these here to explain the issue even better.

regards

Dave M

kwinn

DavidM wrote: »

Thanks Guys!
I am also working on a small serial tool in realbasic, that helps with RS485 development, I might post it here as it can be used on MAC/PC & Linux and you can use the source code.
Dave M

I hope you do post it. I have been planning to build a prop based 4 port RS485 data logger using the 4 port serial and one of the SD card objects. Unfortunately I have a couple of other time consuming projects to complete before I can start on that.