One-way errors in USB / RS-485 converter

[Electrole]

I have implemented a USB to RS-485 converter using the FT232RQ from FTDI, based on their Figure 7.2 ("Application Example Showing USB to RS485 Converter") in the FT232R USB UART IC Datasheet. The level translator I use is an ADM485EARZ from Analog Devices. The CBUS signals are routed as in the Figure 7.2.

Sadly, it does not work as intended, and I'm trying to find out why.

The data from the USB input through the FT232RQ and the ADM485EARZ  seems to be in order. However, the data I read from an RS-485 device (a laser controller) is plagued by intermittent errors.

I can see that there's a wrong checksum when an error occurs. Typically, I read 10 bytes from the RS-485 device. Of these the first 4 bytes are always correct, but errors may then occur in the bytes to follow. It also seems that I read one more byte than expected when an error occurs. The error rate is about 2 % or so. The RS-485 signal appears to be in order with no strange levels or overshoots, etc.

Anybody got a hint on what to look for?

[langwadt]

I have implemented a USB to RS-485 converter using the FT232RQ from FTDI, based on their Figure 7.2 ("Application Example Showing USB to RS485 Converter") in the FT232R USB UART IC Datasheet. The level translator I use is an ADM485EARZ from Analog Devices. The CBUS signals are routed as in the Figure 7.2.

Sadly, it does not work as intended, and I'm trying to find out why.

The data from the USB input through the FT232RQ and the ADM485EARZ  seems to be in order. However, the data I read from an RS-485 device (a laser controller) is plagued by intermittent errors.

I can see that there's a wrong checksum when an error occurs. Typically, I read 10 bytes from the RS-485 device. Of these the first 4 bytes are always correct, but errors may then occur in the bytes to follow. It also seems that I read one more byte than expected when an error occurs. The error rate is about 2 % or so. The RS-485 signal appears to be in order with no strange levels or overshoots, etc.

Anybody got a hint on what to look for?

when no one is transmitting the bus is floating, add failsafe bias resistors on the bus,

https://e2e.ti.com/blogs_/b/industrial_strength/archive/2016/12/06/rs-485-basics-two-ways-to-fail-safe-bias-your-network

[Electrole]

Thanks for the suggestion about adding pull-up/down resistors to the RS-485 lines!!
I added the resistors, and thought indeed that they had gone rid of the erroneous readings. However, after a while (and to my huge disappointment) I encountered bursts of reading errors. My impression is that the resistors may indeed be needed, but they are not sufficient to get rid of the reading errors. I assume there may be another issue lurking somewhere. Perhaps a driver / setup / timing issue??
BR

[digsys]

Coincidentally, I've been working with USB <> RS485 converters this week, even made my own in the past. I was in a hurry today and just bought a couple from the local electronics shop, to diagnose a fault on a machine I'm fixing. Got that sorted and have JUST started to compare the wave forms with my PCBs. Also had odd issues.
Agree with the termination suggestion - but sometimes, the default H,L and mid resistors need tweaking (or removing). The issue I'm working on now (tomorrow my time) is actually a TXE delay / collision. Some systems switch from half to full duplex depending on timing tests etc etc
Can you grab an off-the-shelf one to compare, like I did?
All I can offer for now, more tomorrow :-)

[mikeselectricstuff]

You need to look at the bus with  a scope to see what's going on, e.g. there  could be slight collisions if the driver enable isn't released quickly enough, or too quickly

[langwadt]

You need to look at the bus with  a scope to see what's going on, e.g. there  could be slight collisions if the driver enable isn't released quickly enough, or too quickly

yes it is probably easy to spot the problem with a scope

from the datasheet FT232RQ assert txen one bit before the startbit and de-assert at the end of the stopbit, that should be perfect and the first few bytes are supposedly always correct