Troubleshooting RS485 networks

By Kevin Kilford

Design Manager

Datasound Laboratories

February 02, 2018


Troubleshooting RS485 networks

This article outlines the intricacies of this popular interface, providing engineers with the tools required to ensure reliability of the data exchange within their applications.

In many situations, system assemblers are finding that RS485 networks are unreliable or simply do not work. In a world of plug and play serial digital interfaces the integral sophistication of these long standing digital serial communication interfaces and protocols are commonly underestimated and this can sometimes lead to issues in the field leading to questions relating to the quality and reliability of the systems designed in.

The purpose of this article is to outline the intricacies of this popular interface, providing engineers with the tools required to ensure reliability of the data exchange within their applications.

RS232, dating from 1960, is a digital serial interface principally designed to connect a modem to an electromechanical typewriter. Due to its ubiquity as a standard feature in personal computers up to the late 1990s, many engineers are familiar with this interface and rightly recognize its simplicity and reliability, making it popular in embedded systems to this day.

RS232 is a point to point connection where one master system can connect to one slave. Due to the signaling levels utilized and the fact that the signals are referenced to ground, the speed of transmission is limited and the cable length for a connection is technically constrained to approximately 15 m.

Using differential pairs for each signal and lower signaling levels, RS422 was one of many specifications designed to overcome the shortcomings of RS232. RS422 had one master that would continually transmit, but could transmit to multiple slaves over connections up to 1200 m long. The most common implementation of RS422 uses four connections, with one pair performing the transmit (Tx) function of RS232 and the other pair the receive (Rx) function. Modern usage of the term RS422 normally refers to a full duplex four wire version of RS485, so the discussions in this article apply to this interface, too.

RS485 is a follow-on to RS422, providing the ability to use multiple masters and slaves, all on a single network. Due to the requirement for both masters and slaves to allow transmission on the network by other units, RS485 could support a half-duplex two-wire connection with a single differential pair of connections providing both transmit and receive paths. Modern usage generally refers to the two-wire half-duplex configuration as RS485.

Device compatibility

The best understood aspect of compatibility between devices on the network relates to ensuring that all devices on the network support a common set of configuration parameters: baud rate, data bits, stop bits parity and duplex, so more detailed description is not needed: It will suffice to say that the first aspect to consider is that all devices are correctly configured to use the same settings.


The next aspect to discuss is the network topology: essentially how all of the nodes are connected together. It is recommended that RS485 networks are daisy-chained, for reliable operation. Best practice for two-wire RS485 networks is often to have the master node in middle of the network with bias resistors fitted and the two end slave nodes to have terminations fitted. This article will investigate the methods to help decide what size termination and bias resistors should be and whether they are required.

One common reason for the inability of devices to communicate, on a RS485 network, stems from the ambiguity in deciding how to mark the connections, leading to misconnection between devices. RS485 devices will often use the labels A and B for their connections. It should be noted that these pin labels are not used consistently between manufacturers, are not always used as shown in the specifications, and can even be inconsistent between different devices from the same manufacturer.

For example, the Linear Tech LTC1535 labels the Non-inverting input as A whilst the Linear Tech LTC1387 labels the inverting input as A. The TIA/EIA-422-B specification labels the inverting input as A with an alternate label of ‘-‘, and the non-inverting input as B with an alternate label of ‘+’. For correct operation, care must be taken when connecting the devices onto the network.

Other common terminal labels are Tx+/Rx+ and Tx-/Rx-. Due to the confusing labeling, these are not applied consistently, either. Only inverted and non-inverted labels are consistent, but these are seldom used by the system and device manufacturers. Therefore, without access to the TTL serial signals going to the UART, particularly if bias resistors have been fitted incorrectly, it is often difficult to correctly connect devices without some trial and error.

An important and often neglected aspect of the network topology is the effective maximum transmission length, which will be related to the baud rate chosen and the characteristics of the cabling used. Industry rules of thumb often quote the maximum length of 1200 m only with baud rates of 300 kbaud and below, with the maximum length reducing to 12 m at 10 Mbaud. Only checking the signal integrity at the network extremities with an oscilloscope will ensure that industry rules of thumb have resulted in signals that meet the RS485 specification.


Termination is used to match the impedance of a transmitting or receiving node to the impedance of the transmission line used. If the impedances are mismatched the transmitted signal cannot be fully absorbed by the load and some portion of the signal will be reflected back onto the transmission line. This reflected signal will travel up and down the cable reducing in amplitude over time.

The disadvantages of terminating are:

• Driver loads are increased.

• Biasing requirements are changed.

Whether termination is required, on a network, should be based upon the total cable length and the data rate employed. If all signal reflections will be damped out prior to the centre of a data bit, at which point the receiver will be sampling, termination will not be required.

For example, the propagation delay of any cable can be calculated from its length and propagation velocity (typically 66-75% of the speed of light (c)). If a cable of 100m has a round trip of 200 m and a propagation velocity of 66% of c, one round trip is completed in approximately 1 μs. Assuming that the reflections are completely damped after 5 round trips, the signal will stabilize after 5 μs.

At 9600 baud, each bit is 104 μs wide. As the signal is stable well before the center of the bit termination should not be required. At 115.2 k baud each bit is 8.7 μs wide. As the signal is not stable before the center of the bit, termination will be required. This calculation shows that we should be able to have a network length of about 80 m before termination is needed at 115.2 k baud. 

Termination resistors should only be placed at the extreme ends of a network, and no more than two termination resistors should be used per network. This explains why it is best to have a daisy-chained network: stubs add impedance mismatches and additional points of reflection. For a two-wire network, the termination resistors are typically fitted to the slave nodes at the extreme ends of a network. For four-wire networks, the termination resistors are typically fitted to the receive pair on the slave nodes at the extreme ends of a network.


The most complex and misunderstood aspect of configuring a RS485 network is biasing. When a RS485 network is idle, all nodes are set to receive data and therefore all drivers are tri-stated. Without anything driving the network, the state of the line is unknown.

If the voltage at the receiver inputs is less than ±200 mV, the receiver output logic level will be undeterminable and can often be that of the last bit received. Without this, you can miss the start bit of every communication preventing correct interpretation of the transmission.

In order to maintain the correct idle state bias, resistors can be added to the transmission lines. A pull-up resistor, typically to +5V, is added to the non-inverting input, RX+, and a pull-down, to ground, is added to the inverting input, RX-.

The bias resistor values are determined by the network load, including terminations if fitted: When termination resistors are fitted, the loading effect of these is greater than that of the nodes, which have a typical load of 12kΩ per node. This means that the bias resistor values are approximately 685Ω regardless of the number of nodes. When termination is not fitted, the bias resistors can vary from 122kΩ for two nodes to 4.5kΩ for 32 nodes, to achieve the voltage levels required.

Bias resistors can be added at any point on the network or can be split among multiple nodes. The parallel combination of all bias resistors on a network should be equal to or less than the biasing requirements. They are typically added to the master node. A number of modern RS485 transceivers have been designed to  correctly identify the idle condition without biasing resistors. Without all RS485 transceivers having this capability, and device manufacturers not disclosing the transceiver type applied, biasing must still be considered when creating a RS485 network.


One question often asked of system and device manufacturers is why termination and bias resistors are not fitted to their systems by default. As can be seen from the discussions above, this would not be possible without knowing the entire topology and length of a network before this could be possible and every network is different.

RS485 networks are far from being plug and play and many characteristics of the application must be known and considered before a reliable network can be achieved.

Kevin Kilford joined Datasound Laboratories in October 1999, progressing from Design Engineer to Design Manager. While predominantly designing IoT/IIoT devices today, Kevin also specializes in fulfilling complex legacy I/O requirements, particularly in resolving obsolescence. Kevin spent his early career as a hardware designer on a number of electronics platforms for industrial metering solutions and today functions as a multi-skilled hardware, firmware and software developer. Kevin has published articles on embedded technologies and challenges, across both software and hardware topics.

Design Engineer (IPC CID+ certified) with extensive experience in Digital and Analogue Hardware design, from simple interconnection through to full processor based embedded controllers. Software capabilities with Pascal, C, C++, Basic, SQL and more. Proficient in Verilog HDL FPGA programming. IT support from Microsoft NT 4.0 & Windows 95 through to Server 2003 & Windows 7. Specialties: Embedded Design

More from Kevin

Networking & 5G