RS-422 – The Other Bus-meat

I encountered an RS-422 bus for the first time recently and it threw me through a bit of a loop! The device was a Modbus/RTU slave device and so I anticipated a RS-485 connection as per usual, but that was not the case. It’s the same cable, and the same essential signalling standard, but if you try to interface with RS-422 as if it’s RS-485 you’re going to have a bad time.

What’s RS-422?

It’s similar to RS-485, but it has some key differences:

  • Only one device gets to be the big talker, and everyone else has to listen. If you have multiple receivers, they can’t talk back. If you only have two devices, no problem. They can actually talk at the same time, which is faster than your usual half-duplex RS-485.
  • It can have one driver (talker) and 10 receivers, RS-485 can have 32 “unit loads” which can mean many more than 32 controllers (not many manufacturers would recommend it, though)
  • It’s a four-conductor bus. Just like RS-485 has a single balanced pair, RS-422 has two balanced pairs: one for transmission, and the other for reception.
  • You wire the driver (talker)’s transmit to the receive terminals of all of the slave devices

Some RS-485 adapters support RS-422, but don’t assume it.

Based on the standard, RS-485 can be “full-duplex” too. An extra pair of wires allows a bus to send and receive at the same time by using four wires, but it’s unnecessary and rare for RS-485.

RS-485 Bus Details

Low-voltage communication buses are critical to networked automation systems and when they fail they are a pain to troubleshoot. We use them because the cables are cheap and you don’t need expensive switches, but what you save in parts you may pay in labor later. Ethernet/IP based communication is on the rise, but is still expensive as an up-front cost. RS-485 is the typical low-voltage communication electrical standard used for the bus we see in commercial and industrial automation. You’ll see it used for BACnet MS/TP, Modbus, and various proprietary protocols like Honeywell’s C-Bus and JCI’s N2 bus.

What is RS-485?

RS-485 isn’t a protocol, it’s an electrical standard that describes how to transmit bits with volts. The protocol allows multiple devices to co-exist on a long, fast bus. It’s similar to the RS-422 protocol, except with RS-485 any device can talk, and any device can listen.

Is RS-485 a Two-wire Bus?

When you want to measure a voltage with your multimeter you need both probes because voltages only exist between things. The parts that “do” RS-485 aren’t looking between your A and B ports, they are looking at each wire relative to a common reference point. The voltage reference is often the power source’s ground, earth ground, a third independent reference wire. Some choices are much better than others.

RS-485 is polarity sensitive, having an “inverting” (negative, “A”) and “non-inverting” (positive, “B”) wire. Depending on the application the conductors will be shielded or twisted-pair.  Some installers will use the shield as a signal ground to save on cable costs. This can work well, but there are caveats. Not all grounds are equal, so be careful how you terminate your shield; one lightning storm and your bus could explode. If you forget to terminate your shield in one place and you’ll offset all your signals by the noise the shield picks up, as we found in this case study.

The two-wire applications that have no ground may actually be using the power source for the controllers as the voltage reference, but that can be problematic if you mix up the transformer polarity or if you are dealing with multiple power sources. It also looks freaky on an oscilloscope – you’ll see the bus riding on a 60 Hz carrier! It’s best to avoid this kind of setup if you can, but it’s cheaper.

It takes a lot more sustained thought and consistent effort to make two wires work. When you add a different controller or use a different source of power you may find yourself with an expensive problem. If you want a solid bus, it’s best to use a twisted pair of conductors for A+B, a free conductor for the reference, and a shield to improve noise immunity.

Interference – Why We Twist Our Pairs and Use Shielding

As you can see in the above case study twisted pair works extremely well; despite a noisy environment the bus signal can still punch through pretty clearly.

Slower buses (~9,600 baud) tend to be less sensitive to interference. Twisted pair alone works fine for slower buses especially in low-noise environments. BACnet MS/TP which typically runs at 38,400 baud is much more sensitive to interference and must be properly shielded, especially in a high-noise environment.

Interference can come from most electronic equipment but big offenders are VFDs and any kind of switches (MCC cutoffs, relays, etc.). Devices that are improperly shielded or have failing components emit interference. Shielding your cable correctly protects your bus from these difficult to locate and potentially impossible to fix issues.

If you look at your shield by itself on an oscilloscope you’ll see the stray voltage picked up by your bus, and it’s largely just sharp spikes that usually do not last very long. Higher frequency buses are more sensitive to noise. Take 38,400 baud for example. At 38,400 bits per second one bit is sent down the bus in a flash of 26 microseconds. Any interference that lasts that long will screw up the data stream; for 9,600 baud one bit lasts for 3 times as long as that. Many applications can sacrifice some bus speed without a noticeable change in performance, but wiring your bus right is a lot more effective.

Hidden Depths

You know how we talk about how RS-485 is a two-wire bus? It’s not true. Not even 2.5, or 3, or 3.5! RS-485 can communicate in full-duplex mode using four signalling conductors in several typologies. I’ve yet to see this or a controller in the field that supports it, but the transceivers exist.

IP-based Protocols and Building Automation Security

When installers build automation systems getting it working is their main focus. They see building automation security as an obstacle to overcome rather than the goal. If authentication is getting in the way, they disable it. When firewalls are blocking communication, they disable that too. Even more problematic is the fact that several popular automation protocols do not even support authentication or auditing of any kind.

What Is Security?

Security is more than just access control or encryption. In Understanding Cryptography (a great book for anyone interested in the subject) these services of security are defined, which I am paraphrasing:

  • Secrecy – nobody can listen in
  • Integrity – ensures that attackers have not tampered with messages
  • Authentication – ensures the sender is who they say they are
  • Undeniable – the author of a message cannot deny that they sent it

All of these are valuable for an automation system, to varying degrees.

Building Automation Security Services

Secrecy is not always important, depending on what you are doing. You probably won’t mind if a motivated attacker knew your room temperatures, but in an industrial setting you might care about keeping your process secret. You may consider electrical metering information private as well as that leaks information about your business.

Integrity is important for an automation protocol when commands have critical effects that could harm your business if mishandled. If an attacker is able to modify your commands that could give them a subtle way of harming your business. Some encryption methods do not protect against this; a malicious person could modify even an encrypted message with unknown content so long as they know something about that content.

Authentication is an important security requirement for an automation protocol that I think everyone can understand. You should need some kind of username and password or other means of authentication to affect the field. Sadly, few protocols support this and those that do have very meager support.Your front end may have a login, but the protocol that ultimately commands the system may not.

In the case of a common “operator” password valid across an entire network, commands are deniable. To prevent this, we can use digital signatures where the user must enter their personal password to sign a message, validating that it was in fact them and not someone who knew some common code. This is valuable in auditing; if a problem occurs as a result of a command, we want to know who did it.

Protocol Security Support (in practice)

Advances are slow to come as security generally not a priority except in applications where the automation is considered a critical system. Manufacturers often do not support more advanced security when its available.

OPC (legacy, non-UA)

OPC is a DCOM-based protocol and as such inherits support for authentication. In fact this support is on by default and is a frequent problem when integrating these systems. Typically the client authenticates with Windows credentials that must be valid on the server. Access rights are broken up as: local access, remote access, launch and activation. As far as I know, you can’t selectively provide access to only some tags; if the user is authenticated by the system they can do anything to it.

  • Secrecy – No.
  • Integrity – No.
  • Authentication – Yes.
  • Undeniable – Depends?

OPC UA has much improved building automation security, though it is still quite new. It’s looking like it will be the most security-conscious protocol on the market.


Modbus is an extremely basic protocol and does not support authentication of any kind. If you are on the network, you can read or write anything you like. Some memory addresses are read only, but they are read only for everyone.

  • Secrecy – No.
  • Integrity – No.
  • Authentication – No.
  • Undeniable – No.


BACnet is a relatively advanced protocol.makes its lack of even authentication puzzling. All modern front-ends have segmented user access permission levels, and yet this modern protocol allows the network to be a free-for-all. If you’re on the network you can override points at priority levels above the front end. Read or write access is handled by the end device and is not on a per-user basis.

  • Secrecy – No.
  • Integrity – No.
  • Authentication – No.
  • Undeniable – No.


LON does support authentication for the sender of messages though I have yet to see it in practice. The sender of LON requests has a 48 bit authentication key. When a device sees an authenticated request from the sender it sends back a 64 bit random number as a challenge to the sender. The sender uses their key to modify this random number and sends it back, providing some manner of authentication.

This at least protects against arbitrary clients commanding field devices as would be the case with Modbus or BACnet.

  • Secrecy – No.
  • Integrity – No.
  • Authentication – Yes.
  • Undeniable – No, the key is shared.


Building automation security is still in its infancy. Protocols are not built with security in mind, though the new OPC UA protocol looks promising. When you need to secure an automation system, look to defense in depth rather than relying on protocol security. Protect access to your network, lock up your controllers, and segregate your network.

Visual RS-485 Grounding and Termination Differences

RS-485 bus grounding and termination seems like a magical rite at times. Some people get lazy with the details because buses often work even when done incorrectly. I had some untwisted, shielded AWG22 lying around, so I used it to show a quick comparison between bus wiring in a controlled environment. I used a single MS/TP BACnet controller and 120 Ω termination resistors. The cable is of inconsequential length and I don’t have any weird equipment near my desk, so the electromagnetic noise should be minimal.

Shielded, Grounded Reference, No End-of-line Termination

This is with a single controller and a tiny cable length. The only effects we see with a lack of end-of-line termination is higher amplitude signals (~7V peak to peak) and capacitance in the cable resisting voltage changes as you can see at any of the “corners” that get rounded off.

Shielded, No Reference, Terminated Shielded

Grounded Reference, Terminated

The terminated version of the same waveform is shown above in two versions: with RS-485 grounding and no reference. Peak-to-peak amplitude is about 4.5 V. Strangely, it looks like there might be more noise in the example with the grounded reference which is not all that implausible considering there are no big noise sources around besides the ancient electrical system in this building. It’s not a big enough difference to take seriously, though.

Note that the waveform is inverted – that’s just because I had the probes the other way. Sorry about that!

Please note that this is a simple look on a desk in a residential area. All of the important things to do with RS-485 buses really show up in larger systems with real electromagnetic noise. The lack of noise in these captures is not similar to real-world applications. I wanted to have this as a baseline for reference. If you want to see what happens when you don’t ground your bus when you need to, check out this post!

What is a BBMD, and Why Do We Need It?

As BACnet networks get bigger and network infrastructure gets more complicated, BACnet/IP Broadcast Management Devices (BBMD) become necessary. Installers often configure these devices incorrectly despite their importance which creates the conditions for a broadcast storm.

What is a BBMD?

To understand what these are and why we need them, we first need to understand what a broadcast is. Network protocols like BACnet use broadcasts to efficiently communicate public information. A broadcast is sent once and received by all other devices on the same network. As a network gets bigger, broadcasts start to become a problem since they have to be processed by all devices. To address this problem, IT infrastructure network routers that connect different networks together block broadcasts from crossing networks. This presents a problem for us with BACnet because it requires broadcasts for discovery of devices and objects. Broadcasts are how BACnet devices announce that they exist and have points to share.

Each broadcast management device has a list of all others on other networks in its broadcast distribution table. They act as co-conspirators, getting around the broadcast blockade by smuggling the broadcasts into directly sent packages that routers allow to pass through them.

Here’s a point-form description of how they function:

  1. A BBMD packages BACnet broadcast messages that it hears on its own network into an envelope.
  2. It sends these packages directly to BBMDs on the other networks using its distribution table.
  3. Since those packages are sent directly from one device to another, routers won’t block it.
  4. When a BBMD gets a broadcast package from another BBMD, they open up that envelope and rebroadcast the message locally.

This allows your BACnet network to get around any routers in between that would block the broadcast traffic. It’s essentially smuggling, except it’s legal!

Visual Example of Broadcast Communication

Below is an example network architecture with three separate IPv4 networks and three routers. I chose the IP addresses in the example to be similar to what you’d be familiar with at home.

Example Network Architecture

An illustration of an example network. There are three separate subnets, each with their own router.

If one of the devices on the network sends a broadcast message, the other device on that network will see it. That same message will be blocked at the router and reach no other devices. This is standard router practice: they keep broadcasts local.

BACnet Broadcast Message Sent

An illustration of an example network with three separate subnets, each with their own router. In this image, a device on one of the subnets is sending a BACnet "Who-Is" message, which is being blocked at the router. The message can only reach other devices in the same subnet.
When a BBMD receives the broadcast message it encapsulates it and sends it a direct message to every other BBMD in its Broadcast Distribution Table (BDT). These other BBMDs open up the package and rebroadcast the contents locally, permitting BACnet broadcast traffic to permeate the entire network.

BACnet Broadcast Message Encapsulated and Delivered by the BBMD

An illustration showing how a BBMD gets around the broadcast block at the router level by "unicasting" the broadcast messages to other BBMDs. The BBMDs act as co-conspirators, getting the broadcast messages around routers that would block them.Common mistakes with configuring BBMDs

  • Multiple BBMDs configured on the same BACnet network is a huge, common problem. If you have more than one BBMD on a network it will cause a broadcast storm.
  • Using different broadcast distribution tables on different BBMDs.
  • Using the same network number for networks separated by routers.

Further Reading on BBMDs

Modbus Is Hard, Then Tedious

Modbus is one of the simpliest protocols you’ll find in the field. It’s the closest protocol “to the metal” of the chip on a controller since it often just directly exposes the controller’s memory. There’s no point discovery here; there are no point names or descriptions to help you integrate. All you have are datasheets and fat-finger data entry. There are hardly even data types.

The labour involved with Modbus integration can be high since point configuration is so tedious. When working with a Modbus controller it is very important to have accurate documentation of its:

  • addressing convention,
  • register layout,
  • and data formatting descriptions.

Some controllers start their addresses at 1, others start at 0. Your front end will have its own convention that you’ll have to match up accordingly (off by one errors are pretty common). The register layout will show you the addresses of the data you want. The data formatting descriptions will tell you about the data’s “endianness” and data types; the modbus protocol is just a binary data storage and retrieval protocol, it doesn’t know what a integer or a floating-point number is and it’s up to you to interpret the results.

Modbus can be seen using RS232, RS422, RS485, or IP for connectivity. People frequently make the mistake of assuming one of the above when they hear a device is Modbus. If it’s RS422 and you didn’t plan for that, you’re going to have a bad time.

When getting documentation for the above from a vendor, make sure you get them to help you interpret it! Most communication cards that come with equipment are generic and apply to multiple applications, which means that much of the data available on those data sheets is meanless for your particular application. They should be able to go over the list and highlight points that actually will mean something in your case.

Once you’ve set up a modbus integration it’s robust and fast. Adding new points shouldn’t be too hard either. It’s the initial stages of poring over data sheets and the trial and error of data types that’s the hard part. Once you’ve integrated two systems over modbus once, you should be able to replicate that integration anywhere with relative ease depending on the tools you’re using.

I’ll update this post with links to more detail, especially around data types which are the trickiest part. I’m working on some straightforward real-world examples that should make it a bit clearer.

A Case Study on the Importance of RS-485 Grounding

RS-485 grounding is frequently missing from commercial automation installations. It’s especially egregious when you are using your shield as your signal reference, because that reference is now noisy as heck. The shield’s job to collect interference. It’s up to you to make sure that interference goes somewhere.

The Case Study

I was looking at the RS-485 (MS/TP BACnet) buses for variable frequency drives (VFDs) terminated on a BACnet/IP gateway today. Devices on this bus kept going offline and online periodically, so a bus issue was the first thing to look for. Below is what one conductor of the RS-485 bus looked like by itself on my oscilliscope:

VFDs are noisy. It doesn’t help that the bus cable goes through these before they terminate in the low-voltage side:

It’s going to pick up a lot of that interference from these high voltage things.

The cable is twisted pair and shielded, so interference on one conductor mostly cancels out the interference on the other one. Here’s what they look like together, and what a controller would see:

Much better, but that’s still very bad. This is because this cable is shielded, and the shield was terminated at the BACnet MS/TP to IP gateway in the VREF terminal. This is the reference “ground” that the A and B conductors are measured with respect to. The shield is going to pick up interference along the bus run, because that’s what it’s for. The interference is going to drain to this reference and throw off the voltage of the bus signal.

Here’s what the shield looks like by itself:

As you can see, I am measuring spikes greater than 1.7 V on the shield. This will throw off our measurement of A and B by the same amount, causing frame errors.

The Solution

Since this is a shield, I wired it like you’re supposed to. Let the interference drain to earth ground:

Now the combined signal looks like this:

Much better. Still, now I’m not using anything for a reference. Ideally the bus cable used would have a free conductor, but it doesn’t. I could earth-ground it too and do the same at all the VFDs in the field, but I don’t want a thunderstorm to blow up controllers. It works much better now, so I think I’ll just leave it as is. Not too happy about it, but not the worst outcome.

The Bus Problem Superweapon: The Oscilliscope

I had the opportunity to troubleshoot an MS/TP BACnet bus using my Rigol DS1052E oscilloscope. Oscilloscopes are much more useful for bus diagnostics than a multimeter. Although they don’t tell you where the problem physically is, they can immediately confirm that you are in fact looking at a bus fault instead of a software problem and also identify when it is corrected.

The Problem

The bus in question appears to have a short. Communication does still work, but it takes a long time to poll points or override them. I presume there’s a lot of error-correction and trying in the background making up for the bad bus on the platform I’m using here (Tridium AX).

You can’t really tell there’s a problem from the software side besides the slowness and some strange errors about frame errors printed in a log. With the oscilloscope I can see immediately that there is a problem and I know what conductor the problem is on. That doesn’t exactly solve it for me, but it’s a clear indication at least which has a clear, tedious solution.


The picture above is a good-quality frame. There’s a bit of rounding from capacitance, but it shouldn’t interfere with communication as it’s quite minor. The square wave signal is clear and the peaks are consistent. I took this sample in the middle of the problem bus with the ground clips for both my probes on the reference conductor. I told my oscilloscope to invert one of the channels, and I am displaying above the addition of both. That’s essentially what an RS-485 transceiver will do in your controller.

The above is not a good frame. It’s not that clear that it’s bad. You can see a bit of capacitance, you can see that the peaks are not that consistent, and maybe a bit of noise. The total amplitude is lower than with the good one. I was surprised to see this result on the bad side of the bus, so I looked at the channels separately. Then, I saw what is clearly a problem – here’s one of the conductors (A or B) of the bad side of the bus:

Yeah, that’s not a square wave signal. That looks like a signal that wants very much to stay near to ground. I.E., this wire is shorted to ground somewhere. Given that this is an underfloor ventilation system and we have a lot of wires bell-tied to struts we get a lot of damaged cables when people are over-zealous with pulling.

I’ll update as I investigate!

The Solution

Yup, that conductor was shorted to the shield which is grounded. This is a floating floor system, and the bus is cable-tied to struts under the floor. It looks like someone pulled a little too zealously. Very easy to repair.