Setting Modbus RTU Timing So Radios and Old Meters Actually Answer

Wired right, still failing

The cable is landed, the slave address is correct, parity matches, and the link still drops frames. Nine times out of ten the drawing is fine and the timing is wrong: the master fires the next request before a radio modem, gateway, or ten-year-old drive has let go of the bus.

Baud rate and timeout are not defaults you inherit from the driver template. They set how much data fits in one scan, how long the SCADA driver waits before it retries, and whether a slow meter ever gets to answer at all. Start slow and boring, measure the real response times, then tighten — not the other way around.

Draw the request path first

The same read costs a different amount of time depending on what sits between the driver and the slave.

Path	Timing concern
Direct RS-485 multi-drop	Bus release time, cable quality, termination, duplicate address mistakes
RS-485 through serial server	TCP socket buffering plus serial transmit time
Radio modem	Push-to-talk delay, air-time contention, retry behavior
Protocol gateway	Internal request queue and per-slave turnaround
VFD or power meter	Slow register processing during local keypad or measurement update

Before you touch a timeout value, sketch the path. If a TCP-to-serial gateway is in the middle, you have two response timeouts to reconcile — the SCADA driver's and the gateway's serial-side one — plus two retry layers that multiply each other. A one-second driver timeout stacked on a gateway that already retries is how a single slow slave turns into a ten-second gap on the HMI.

The silent interval isn't optional — the spec sets it

Modbus RTU has no start/stop delimiter in the frame. It uses silence on the line to mark frame boundaries, and the MODBUS over Serial Line Specification V1.02 pins those silences to character times:

• t1.5 — 1.5 character times of quiet inside a frame flags an error. Exceed it mid-message and the slave discards the frame.
• t3.5 — 3.5 character times of quiet marks the end of a frame. Start the next request before that elapses and the receiver glues two frames together and hands you a CRC error.

A character on the wire is 11 bits (start + 8 data + parity + stop; still 11 for 8N2). So:

char_time_ms = 11 / baud_rate * 1000
t3.5_ms      = 3.5 * char_time_ms

At 9600 bps that's ~1.15 ms per character and a t3.5 of about 4.0 ms. At 19200 it's ~2.0 ms. Above 19200 the spec stops scaling and fixes the values: t3.5 = 1.75 ms, t1.5 = 750 µs, because chasing sub-millisecond gaps on a UART isn't worth it. Most drivers honor this automatically, but a serial-to-TCP gateway that reframes packets often doesn't — that's where you add an explicit inter-request delay.

For plain RS-485 the required quiet time is tiny. For radios, cheap converters, and older instruments the practical gap is far larger than t3.5, because the device needs wake-up or line-turnaround time on top of the protocol minimum. If errors vanish the moment you slow the poll down, don't reach for the shield tester first — check that you're giving the line enough silence.

Do the frame-time math before promising a scan rate

A thirty-second estimate kills a lot of impossible scan plans. At 9600 bps an 8-byte request plus a 25-byte response is 33 characters — about 38 ms of wire time before you add device processing, t3.5, gateway delay, or a single retry.

Now someone asks for 200 registers from 30 slaves every second on one serial trunk. Thirty transactions × (~38 ms wire + turnaround) blows past a second before the physics even considers the devices. The SCADA license having spare tags doesn't change what the line can carry. Either drop the rate, split the trunk, or move the fast points to their own channel.

Commission from one known-good slave outward

The fastest checkout is the dull one:

1. Connect one slave, poll a small register block.
2. Confirm baud rate, parity, stop bits, slave address.
3. Record normal and worst-observed response time.
4. Add the next slave, repeat.
5. Grow the register block only after basic reads are stable.
6. Reduce delays slowly while watching CRC errors, timeouts, and exception responses.
7. Save the final timing values on the network drawing.

Landing all thirty devices at once and then chasing random errors is the slow way. One duplicate address, one damaged transceiver, or one meter that stalls during its own measurement update makes the entire trunk look flaky, and you can't tell which device did it.

Retries hide load; scan classes expose it

Retries are useful right up until they mask a saturated line. A driver at 1 s timeout with 3 retries burns four seconds on a single missing slave before it moves on. The operator sees one frozen value; the real damage is the whole poll schedule stuck behind that retry traffic.

Split the poll into scan classes so one dead device can't drag the rest:

• fast status coils and permissives in a small high-priority group;
• energy, diagnostic, and totalizer registers in a longer group;
• known-weak devices in their own group with a conservative timeout;
• offline or spare addresses pulled off the active poll list entirely.

If one failed device delays the whole HMI screen, the fix is scan-class design, not another timing tweak.

When it breaks, it usually breaks like this

CRC errors climb after you raise the baud rate. Solid at 9600, noisy at 38400. That's almost never the protocol — it's cable length, termination, biasing, stubs, grounding, or transceivers running out of margin. Drop back to the working rate, confirm termination sits at the two physical ends only, and inspect shield bonding and branch length before you blame the driver.

The first poll after idle times out, then retries succeed. A radio or converter needs wake-up or direction-change time it isn't getting. Add turnaround or inter-request delay; if it's a radio, check the push-to-talk timing.

One client works, two clients fail. Two SCADA masters hit the same serial gateway, its queue fills, response order scrambles, and the slave gets requests too close together. Put one master on a serial segment where you can. If redundancy forces two, confirm the gateway actually supports controlled multi-client access and cap the request concurrency.

Short reads pass, long reads fail. Small blocks return fine; a 100-register block times out or throws an exception. The slave may cap max registers per request, need longer to assemble the data, or you're reading across an undocumented gap in the map. Shrink the block, stay inside documented map sections, and compare response times for 10-, 50-, and 100-register reads.

Leave the numbers behind

Write down the final baud rate, parity, stop bits, response timeout, retry count, inter-request delay, and gateway pacing — plus the measured normal and worst-case scan time. The next person to replace a device, add a slave, or ask why the link can't just go five times faster with one dropdown change will need exactly those numbers, and they won't be in the driver config in a form anyone can read at 2 a.m.