# Can a 485 network work if the DE (driver enable) pin of the transceiver is always on?

We are using a Beaglebone Black with the Osso Cape (https://github.com/nexlab/Osso) for comunicating with other equipment using a 485 connection and Modbus RTU.

The driver enable (DE) pin of the cape's DS485 chip is tied to the GPIO 2_24, while the RO and DI pins were tied to the UART1 RX and TX respectively.

We haven't write any code to act on the GPIO2_24 at all, other than a cape overlay that sets it as output and pin Mode GPIO.

We were troubleshooting some communication problems when we noticed something strange: Using an oscilloscope, we saw that the driver enable (DE) pin was always high, but somehow the Beaglebone was able to normally send requests and receive correctly responses from the other equipement.

Normally I would expect that the 485 comms only worked with the DE pin HIGH when transmitting and LOW when finished, to avoid driving the bus when other equipment respond.

In other capes we used, this was controlled using UART4 RTS, but I could not explain why it seems to work in this case.

Is there any explanation on why it works with the DE always on?

Due to the multipoint nature of the bus, contention between drivers may occur. This will not cause damage to the drivers since they feature short-circuit protection and also thermal shutdown protection. Thermal shutdown senses die temperature and puts the driver outputs into TRI-STATE if a fault condition occurs that causes excessive power dissipation which can elevate the junction temperature to +150°C.

Maybe the chip senses contention and goes to high-impedance state, then being able to receive the response from the other equipment?

• If you have a 'scope, you could just just as well check the 485 line waveforms, right :-) – frr Jan 26 '17 at 14:11
• Hi! Not sure what to look for in the 485 line though. The software gets the correct bytes so I assume voltages in the line should be somehow OK. – SuperGeo Jan 26 '17 at 14:44
• I have some examples here: support.fccps.cz/download/adv/frr/rs485/rs485.html#plots The 485 output driver switches to its local 0 and +5V when active. When inactive, the line will "gravitate" to 0V differential voltage, but the driver chips typically have a weak bias, and practical transceiver circuits typically add an even stronger bias, to keep the line in the "silent log.1" state when all drivers are inactive. The nominal minimum detectable signal is 200 mV diff, the receiveers actually have like 130 mV diff threshold for schmitt trigger (hysteresis). – frr Jan 27 '17 at 19:52

It is quite possible that the state with the driver always on would allow communications to work in both directions due to the overall current limit and effective output impedance of the driver.

You do want to correct this however because the driver in this condition will be under unnecessary stress and drawing way more current from your power sources than necessary. A stressed driver chip may very well have a shortened life. The correction of course is to devise the programming necessary to drive the GPIO to turn off the driver once transmission is complete.

Turning off the driver at the correct time can, in some cases, require some careful work. Due to the fact that the sending UART port will spend time sending the last loaded data bytes after the final data is loaded there is a need to comprehend when sending is complete. Some considerations...

1. Some UARTs are capable of generating an interrupt when the actual serial data pipe plus any FIFO buffered data has been sent. This can be leveraged as the time to turn off the UART.
2. If there is no actual UART EMPTY indicator then you may need to use a time delay in the software to get to the time when to turn off the driver. This could be a timer interrupt delay or an inline software delay.
3. In practical applications of RS485 interfaces it is often the best practice to assign one device as the master initiator of transaction packets on the interface. All other devices are then slave responder devices. It is a good idea for a slave responder device to delay a bit from receiving a transaction packet till sending the start of its response packet. This delay allows time for the master initiator to get off the bus before the slave tries to send. Likewise the master should delay between receipt of a response packet and start of sending the next initiator packet to allow the slave device to get back off the bus.
• +1 ... Per your item 3, the delays are defined in the Modbus RTU protocol specification. – Tut Jan 26 '17 at 14:15
• I've noticed that some UART's where the TEMT/TSRE signal is used for RS485 RX/TX steering, have minor flaws in this functionality. Such as, that the TEMT/TSRE signal is produced too literally by the shift register, as a result of which, stop bits are "eaten". A stop bit is the bit following the last data or parity bit, i.e. during the stop bit the "transmitter shift register" is indeed empty, and with this UART, the 485 TX was already off during the stop bit. Solved by proper biasing... Or, one such UART did not tell the TX driver to turn on during a break condition :-) – frr Jan 26 '17 at 14:16
• Thanks for you answer! How can I know about the effective output impedance of the driver? – SuperGeo Jan 26 '17 at 14:43
• Maybe connect just a ~50 Ohms resistor (to simulate two terminators) across the DATA+/DATA- pins and transmit a character, watching the line with an oscilloscope? Do this with and without the 50R load, and compare results. Without the load, the driver is "open ended". When loaded, the voltage will be lower. The rest is Ohm's / Kirchhof's laws... – frr Jan 27 '17 at 20:02
• @frr - Since driver output impedance is non-linear with load it can be useful to make measurements with various sized resistors (i.e. at 150, 100, 75, 50, 33, 22 ohms) to get an idea of the impedance with respect to load. Go low enough and you may also be able to see where current limit, if any, kicks in. – Michael Karas Jan 27 '17 at 20:55

Using an oscilloscope, we saw that the driver enable (DE) pin was always high, but somehow the Beaglebone was able to normally send requests and receive correctly responses from the other equipement.

This just means that the other equipment's RS485 driver could over power your tranceiver connected to the BBB - the two line drivers work against each other.

This causes high current flow on the bus lines and may not work in the field with other equipment or longer bus wires.

Maybe the chip senses contention and goes to high-impedance state

Nope. From the datasheet:

The driver is short-circuit current limited [...]

This means it will just limit the current to the values stated in the datasheet. It could go into tristate only when the chip overheats - but that is rather unlikely and easy for you to check.