AnsweredAssumed Answered

ADM2582E fail-safe biasing glitch and RS485 half-duplex echo problem

Question asked by piyamate on Jul 23, 2015
Latest reply on Jul 26, 2015 by piyamate

I am using Digilent PmodRS485 connected together with Adafruit FT232H as a USB->Isolated RS485 interface.

Essentially it is FTDI FT232H (USB-UART) connected to ADM2582E. The transciever's A/B and Y/Z are linked to form a half-duplex configuration. Also, its DE is connected to TxEN signal from FT232H.

 

The implementation of ADM2582E is shown in this schematics.

The FT232H has 3.3V level interface, whereas the ADM2582E is supplied with 5V.

A 120R termination resistor is used, however there is no connected RS485 cable. Signals are probed directly at the PCB terminals.

Oscilloscope signals

Ch1 - RS485 A/B

Ch2 - TxD

Ch3 - RxD

Ch4 - RE

 

The first issue I found is the fail-safe biasing glitch. This only happens at higher baud rates, >1Mbps. The problem occurs when a transmission finishes. After the RS485 signal decays down to 0V, RxD pin sends a short (~100ns) low-level pulse glitch. This is long enough for the UART interface to receive a faulty data byte.

 

The figure below show an example of the glitch of a single-byte transmission of 0x00. The RE pin is shorted to GND1 to decouple this problem from another echo problem as I am going to explain afterwards.

Unbiased 12Mbps No-RE 0x00.PNG

After I connect 1k fail-safe biasing resistors to Visoin and GND2, the problem disappears.

1K-Bias 12Mbps No-RE 0x00.PNG

 

This is a simple fix, however, I do not understand why the on-chip fail-safe inputs did not work as expected.

 

 

The second problem I found is the echo problem. When using TxEN signal from FT232H to enable/disable the transmitter/receiver by connecting it to both DE and RE pins, the propagation delay (I think) causes the receiver to echo the last transmitted bit. If that byte ends with a zero bit, a short low-level pulse will appear at RxD. This again causes the UART interface to receive a faulty byte after transmission.

1K-Bias 12Mbps RE 0x00.PNG

I think this problem comes from the FT232H's TxEN that turns on the RE too early, so the Tx data is not sent out completely from the transceiver when the receiver is enabled. Therefore, causing an echo of the last transmitted bit. This problem could be solved by adding a small turn-around delay of the TxEN signal. Unfortunately the FT232H does not have this feature. I have tried a quick fix solution by adding an RC and a diode delay circuit. It could actually solve this problem.

1K-Bias 12Mbps RE Delay 0x00.PNG

RE Delay Circuit.png

My question is, is this circuit a good/robust solution for practical use? Or is there a better way to rectify this echo issue ?

Outcomes