Field notes — Modbus, RS-485, and the patient practice of debugging wires
A short, honest log from an industrial deployment: what went wrong with our Modbus RTU bus, how we found it, and why a multimeter still beats every dashboard.
Last month we had a sensor bus that worked beautifully on the bench and refused to work on site.
The setup was standard for industrial IoT — half a dozen energy meters speaking Modbus RTU over RS-485, polled by a Linux gateway running a small Go service, forwarding to the backend. On the bench the gateway happily read all six devices at 9600 baud. On site, every other read timed out, and one meter never replied at all.
This is a small writeup of what we learned. Most of it is unglamorous.
Symptom: random timeouts
The first instinct was to blame the code. So we did the responsible thing and ruled it out:
# read holding register 0x0001 on slave 5 from CLI
mbpoll -m rtu -b 9600 -a 5 -r 1 -c 2 -t 4 /dev/ttyUSB0
mbpoll failed the same way. So the gateway service was not the problem. The bus was.
What it actually was
Three things, layered.
1 · Termination. RS-485 wants a 120Ω terminating resistor at each end of the trunk. The site's panel had one at the gateway end and none at the meter end — because the original installer assumed the last meter's internal terminator was enabled. It wasn't. We added a 120Ω across A/B at the far end and timeouts dropped from ~40% to ~8%.
2 · Biasing. The bus was floating between transmissions. RS-485 transceivers need a defined idle state — usually via a pair of pull-up / pull-down resistors (commonly 680Ω) on A and B. Some gateways provide this internally; ours did not. We added external biasing. Timeouts dropped to ~1%.
3 · The dead meter. Slave address 4. We swapped cables, addresses, terminations. Nothing. Eventually we put a scope on the line and saw the meter's TX driver was simply not asserting — the transceiver IC was cooked. A previous lightning event, the site engineer said, flatly. We replaced the meter and moved on.
What I would do differently
- Carry a terminator and a biasing pair. They cost nothing and they fix half the field problems before you open a laptop.
- Carry a USB-RS485 dongle for the laptop. When in doubt, take the gateway out of the picture and talk to the bus directly with
mbpoll. Half a day saved every time. - Carry a multimeter. A bus with no termination still passes traffic — usually. A bus with a shorted transceiver does not. The multimeter tells you which one you are in.
A small note on protocols
Modbus RTU is forty years old. It is small, it is honest, and it is not going anywhere. Most "modern" industrial stacks I've worked with are either Modbus over TCP (the same protocol, different transport) or a thin wrapper around it.
This is not a complaint. It is a comfort. The patient protocol almost always wins.
— Notes from a panel in Dindigul, March 2026.