Modbus over RS485 Communication Frequency and Baud Rate

One of the most important settings on any serial link is the baud rate — often called the Modbus over RS485 communication frequency. It sets how fast data moves across the bus, and it drives three things you care about on site: how far the cable can run, how many devices you can poll per second, and how much noise the link will tolerate before you start seeing CRC errors.

This guide covers what the term actually means electrically, the speeds you will meet in the field, the real distance limits, and how to calculate a poll cycle that holds up under load.

• Baud rate, bit rate, and frequency are not the same thing
• Baud rates you will meet in the field
• How far the cable can actually run
• What really caps your maximum baud rate
• Character timing and the 1.750 ms clamp
• Sizing your poll cycle
• Picking a setting
• Commissioning checklist
• Frequently asked questions

Baud rate, bit rate, and frequency are not the same thing

These three get mixed up constantly, so it's worth pinning them down before the numbers.

Baud rate is the symbol rate — how many signal states per second the line carries. Bit rate is how many bits per second move across it. On RS-485 each symbol carries one bit, so on this bus the two numbers are identical. 9600 baud is 9600 bits per second.

Frequency is where people go wrong. You will see it written that 9600 baud produces a 9.6 kHz signal. It doesn't.

RS-485 uses NRZ encoding. The line holds its state for the whole bit period and only changes when the next bit differs. Two identical bits in a row produce no transition at all. So:

• The worst case is an alternating 1010 pattern, which gives a fundamental of half the baud rate — about 4.8 kHz at 9600 baud.
• A long run of identical bits sits close to DC.
• The actual spectrum depends on the data being sent, and shifts message to message.

What matters for EMI is not the baud rate but the edge rate. A transceiver with fast rise times puts energy well above 10 MHz onto the cable even at 9600 baud. That is why many industrial transceivers deliberately slow their edges, and why cable shielding matters more than the speed setting.

Short version: baud rate is the correct term. Communication frequency is close enough in conversation, but it means something different electrically, and the difference shows up when you troubleshoot noise.

Baud rates you will meet in the field

The Modbus serial line specification requires devices to support 9600 and 19200 bps, and sets 19200 bps as the default. In practice many vendors ship at 9600, so always check the device manual rather than assuming.

Modbus RTU always uses an 11-bit character. With parity that is 1 start + 8 data + 1 parity + 1 stop. With parity disabled the spec requires 2 stop bits to keep the character at 11 bits. Devices that fall back to 8N1 (10 bits) are deviating from the spec, and mixing the two on one bus causes framing errors.

Bit time and character time are the numbers you need for timeout tuning. Master timeouts set in milliseconds without reference to these values are the most common cause of phantom communication faults on slow links.

How far the cable can actually run

The old rule that doubling the baud rate halves the cable length is not how RS-485 behaves at Modbus speeds. The reference curve is flat.

RS-485 supports 1200 m (4000 ft) up to roughly 90–100 kbps. Above that, distance falls off, with the length × data rate product landing near 10⁸ m·bps.

So 9600, 19200 and 38400 all reach the same 1200 m with decent cable, correct termination and proper biasing. Dropping from 19200 to 9600 to "get more distance" gains you nothing below 90 kbps. If a 900 m run is failing at 19200, the problem is the installation, not the speed.

These are practical guidelines, not fixed limits. What you actually achieve depends on cable capacitance, transceiver type, topology, termination quality, and the electrical noise around you.

What really caps your maximum baud rate

Two separate ceilings apply, and they have different answers. Field engineers hit the second one far more often.

Physical layer limits

Cable capacitance. This is the dominant physical limit, more than impedance. Good RS-485 cable runs 40–60 pF/m. Cheap cable can hit 100 pF/m or more. Capacitance rounds off the edges, and at high baud rates the receiver samples before the line has settled. Over 500 m the difference between good and bad cable is the difference between working and not.

Cable impedance. RS-485 expects 120 Ω characteristic impedance. Using ordinary instrument cable or shielded pairs meant for 4–20 mA creates a mismatch with your terminators, and the reflections that follow show up as intermittent CRC errors that get worse at higher speeds.

Termination quality. 120 Ω at each far end of the bus, and nowhere else. Extra terminators in the middle load the drivers and cut the differential voltage. Missing terminators cause reflections. Both problems scale with baud rate — a bus that runs fine at 9600 with no terminators can fail completely at 57600.

Stub length. Every drop off the main trunk is an unterminated branch that reflects. Keep stubs under 1 m at moderate speeds, and much shorter above 100 kbps. A daisy chain topology avoids this entirely; a star topology guarantees it.

Node count. Standard RS-485 drivers handle 32 unit loads. Transceivers rated at 1/8 UL allow up to 256 nodes. Each node adds capacitance and loads the driver, so a fully populated 1200 m bus behaves worse at high speed than a lightly loaded one. Modbus itself addresses 1–247, with 0 reserved for broadcast.

Device and system limits

Slew-rate-limited transceivers. This is the one factor that puts a hard number on your ceiling. Many industrial transceivers slow their edges deliberately to reduce EMI, and that caps them at 250 kbps or 500 kbps regardless of cable. Check the transceiver datasheet before planning anything above 115200.

The slowest device on the bus. Everything runs at one rate. One old energy meter that tops out at 19200 sets the ceiling for the whole segment, no matter how good the cable is. Survey the whole device list before choosing a speed.

Device response time. Some slaves take 20–50 ms to turn a request around. Raising the baud rate shortens the frames but does nothing to processing delay, so on a bus full of slow devices, going from 9600 to 38400 may buy you far less throughput than the numbers suggest.

Reliability factors that do not cap speed but will break the link

Ground potential differences. RS-485 receivers work over a common-mode range of −7 V to +12 V. Two panels on separate earth points in a large plant can easily exceed that, and when they do the link fails outright rather than degrading. Use isolated transceivers where grounds are far apart, and bond the shield at one end only.

Bias resistors. When no driver is active the bus floats and receivers output random data. Failsafe bias resistors pull the idle line above the ±200 mV receiver threshold with margin to spare. Typical values run 560 Ω to 1 kΩ, applied once per bus, not per node. Over-biasing loads the drivers and eats noise margin.

EMC noise. VFDs, contactors and switching supplies inject common-mode noise. This does not directly limit baud rate, but it shrinks your margin, so a link running at the edge of its distance budget fails first. Route away from power cables, cross at right angles, and ground the shield at a single point.

Character timing and the 1.750 ms clamp

Modbus RTU has no start or stop delimiter. Frames are separated by silence, which makes two timing values critical:

• t1.5 — 1.5 character times. More than this between two characters inside a frame means the frame is incomplete and gets discarded.
• t3.5 — 3.5 character times of silence marks the end of a frame.

Above 19200 bps these values are fixed rather than scaled: t1.5 becomes 750 µs and t3.5 becomes 1.750 ms. The reason is practical — at 115200 the calculated t3.5 would be 334 µs, which most UARTs and operating systems cannot resolve reliably.

If a master and slave disagree on this rule, you get intermittent frame errors that appear only under load. It is a common cause of mismatches between a modern PLC and an older third-party device.

Sizing your poll cycle

This is where most baud rate decisions are actually made, and where the usual "messages per second" figures mislead.

Modbus RTU is request and response. A complete transaction is not one frame. It is:

request frame + slave processing time + response frame + t3.5 silence

Work an example at 9600 bps, character time 1.15 ms:

• Request — Read Holding Registers is 8 bytes (address, function code, start address, quantity, CRC) → 9.2 ms
• Slave processing — typically 10–20 ms, sometimes far more → say 15 ms
• Response — 10 registers returns 25 bytes (address, function code, byte count, 20 data bytes, CRC) → 28.7 ms
• t3.5 gap → 4.0 ms

Total: about 57 ms per transaction. That is roughly 17 transactions per second, not the 60–80 you get from dividing 1 second by a single frame time. With small responses and fast slaves you might reach 25–35 per second. Frame time alone is never the answer.

For 15 slaves polled once each, the cycle is 15 × 57 ms ≈ 0.9 seconds. If your SCADA needs a 1 second update, you are already at the limit at 9600. Moving to 38400 cuts the frame portion by 4× but leaves the 15 ms processing untouched, giving about 25 ms per transaction and a 0.4 second cycle — a real gain, but not the 4× the baud rate suggests.

Two practical consequences:

• Group registers into fewer, larger reads. Fixed overhead per transaction dominates, so one read of 40 registers beats four reads of 10.
• Measure real device response time before sizing anything. Capture the bus with Wireshark on the serial link or a line monitor, and use the measured turnaround, not a datasheet number.

Picking a setting

Commissioning checklist

1. Confirm every device on the segment supports the target speed, including the oldest one.
2. Match baud rate, data bits, parity and stop bits across all nodes. Remember: no parity means 2 stop bits.
3. Use 120 Ω twisted pair rated for RS-485, and check the capacitance figure on the datasheet.
4. Terminate 120 Ω at each far end only. Disable termination on every device in between.
5. Fit failsafe bias resistors once per bus, sized for your node count.
6. Keep stubs under 1 m; shorter above 100 kbps.
7. Ground the shield at one end only.
8. Verify common-mode voltage between panels stays inside −7 V to +12 V, or fit isolated transceivers.
9. Set master timeouts from measured character time, not from a round number.
10. Log CRC error counts for 24 hours before signing off. Errors that only appear at shift change point to load-related noise.

Frequently asked questions

What is the Modbus over RS485 communication frequency?

It refers to the baud rate — how many bits per second the bus carries. Common values are 9600 and 19200 bps. The word frequency is loose here: with NRZ encoding the fundamental signal frequency is at most half the baud rate, around 4.8 kHz at 9600 bps, and it varies with the data being sent.

What is the default baud rate for Modbus RTU?

The serial line specification sets 19200 bps with even parity as the default, and requires support for 9600 bps. Many vendors ship at 9600 anyway, so check each device manual.

Does a lower baud rate let me run a longer cable?

Not below about 90 kbps. RS-485 supports 1200 m at every speed from 1200 up to 57600 bps. Dropping from 19200 to 9600 does not extend your reach. If a long run is unreliable, look at cable type, termination, biasing and grounding instead.

How many Modbus messages per second can I get at 9600 bps?

Around 17 to 35 complete transactions per second, depending on frame size and how fast the slave responds. Each transaction includes a request, the slave's processing delay, a response, and 3.5 character times of silence. Dividing one second by a single frame time gives roughly double the real figure.

Why is t3.5 fixed at 1.750 ms above 19200 bps?

Because the calculated value becomes too short to measure reliably. At 115200 bps, 3.5 character times is 334 µs, below what most UART drivers and operating systems can time consistently. The specification therefore fixes t3.5 at 1.750 ms and t1.5 at 750 µs for all higher rates.

Can I mix baud rates on the same RS-485 bus?

No. Every device on a segment must use identical baud rate, data bits, parity and stop bits. A device set differently will corrupt frames for everyone. If you need different speeds, split the network into separate segments with their own master port or use a gateway.

What limits the maximum baud rate on my network?

Usually the devices, not the cable. Slew-rate-limited transceivers cap many industrial products at 250 or 500 kbps, and the slowest device on the bus sets the ceiling for everyone. On the physical side, cable capacitance, termination quality and stub length matter more than raw distance.