A Modbus RTU frame has no start or end flag; it begins and ends with at least 3.5 character times of silence, about 4 ms at 9600 baud. That silence is why an RTU slave needs a timer. ASCII replaces the timer with colon and CR/LF delimiters, but both endpoints must switch together; a one-sided change produces frames neither end can read.
A Modbus RTU frame carries no start flag and no end flag. Its only boundary marker is silence: the Modbus over serial line specification V1.02 requires at least 3.5 character times of idle line before and after every frame, about 4 ms at 9600 baud. That requirement is why a slave on an RTU line needs a timer, and why a custom controller that wants that timer for other jobs looks hard at Modbus ASCII, which marks frames with a colon and a CR/LF pair and needs no gap timing. This page gives the numbers behind the 3.5-character rule, a worked gap-timer design that fits in a 1 ms tick, and the decision on when the ASCII switch is worth it.
What the 3.5 character gap does
RTU sends raw binary bytes, so nothing inside the byte stream says where a frame begins or ends. The specification uses time instead of flags: every frame must be preceded by at least 3.5 character times of silence and followed by the same. The sender holds that silence before its next frame, and the same gap separates a response from the request before it, so a reply can never run into the tail of a request.
The specification pairs the gap with an inside-frame rule: characters within one frame must arrive with no more than 1.5 character times between them. If a pause passes that limit, the frame was interrupted in flight, so the receiver discards what it has and treats the next byte as the start of a new frame. Those two thresholds are the whole frame-boundary logic of RTU: 3.5 character times ends a frame, 1.5 character times kills a torn one.
How long the gap is at your baud rate
The arithmetic starts from the character the specification counts: 11 bits, made up of 1 start bit, 8 data bits, 1 parity bit and 1 stop bit. With no parity the specification fills the character out with a second stop bit, so the count stays 11. Character time is 11 bits divided by the baud rate, and the required gap is 3.5 times that.
| Baud rate | Character time (11 bits) | 3.5-character gap | 1.5-character limit in frame |
|---|---|---|---|
| 1200 baud | 9.17 ms | 32.1 ms | 13.8 ms |
| 2400 baud | 4.58 ms | 16.0 ms | 6.88 ms |
| 4800 baud | 2.29 ms | 8.02 ms | 3.44 ms |
| 9600 baud | 1.15 ms | 4.01 ms | 1.72 ms |
| 19200 baud | 0.573 ms | 2.01 ms | 0.859 ms |
Above 19200 baud the specification stops the calculation and fixes the values: 1.75 ms for the frame gap and 750 µs inside a frame, at any speed. For the same arithmetic worked through rate by rate, see a page that walks through the 3.5-character silent-interval calculation.
If your line runs 8N1, each character on the wire is really 10 bits and the physical 3.5-character gap at 9600 baud is 3.65 ms. Timing the 11-bit value, 4.01 ms, clears that with margin, which is why the safe habit is to keep the 11-bit figure on any line setting.
Example: a 9600 baud slave timed with a 1 ms tick
Inputs. Baud rate 9600, the common default on Modbus serial links, assumed here. Character length 11 bits (1 start, 8 data, 1 parity, 1 stop), from the specification's RTU format. The two rules above: 3.5 character times to end a frame, 1.5 character times to discard a torn one. One counter that ticks every 1 ms, already running in the firmware; the case is a small custom PLC that wants its one hardware timer back for other jobs.
Rule. Measure silence since the last received byte. When silence reaches 3.5 character times, the frame is complete. When silence reaches 1.5 character times before the expected end of the frame, the frame is torn: discard it and treat the next byte as a new start.
Arithmetic.
- Character time: 11 bits / 9600 baud = 1.146 ms.
- End of frame: 3.5 × 1.146 ms = 4.01 ms.
- Torn frame: 1.5 × 1.146 ms = 1.72 ms.
- Tick thresholds: a count of N ticks means at least N − 1 ms of measured silence, because the tick that pushes the count to N can fall just under N ms after the last byte. For the frame gap, N − 1 ≥ 4.01 needs N = 6, which gives 5 ms of measured silence. For the torn-frame limit, N − 1 ≥ 1.72 needs N = 3, which gives 2 ms.
- Reply side: hold the transmitter off until the same counter reaches 6 after the request ends. That adds 5 ms at most, small against a Modbus master timeout, which is typically set at 100 ms or more.
Result. One counter with two thresholds, 3 ticks and 6 ticks, does the whole job. RTU runs without a dedicated hardware timer.
Decision. At 9600 baud the 3.5-character job fits a 1 ms tick with margin, so RTU costs no extra timer here. At 19200 the thresholds move to 4 ticks and 2 ticks, against 2.01 ms and 0.859 ms. Above 19200 baud, stop calculating: 3 ticks give 2 ms of measured silence, which clears the fixed 1.75 ms gap at any speed.
What Modbus ASCII does instead
ASCII replaces time with visible delimiters. A frame begins with a colon, every data byte rides as two ASCII hex characters, the error check is a 2-character LRC placed before the end, and the frame ends with CR and LF. The specification allows up to 1 second between characters before a frame must be discarded, so the parser reads characters as they arrive and acts only on the delimiters. There is no gap to time and no timer to spend. For the check value itself, see the LRC calculation for Modbus ASCII frames.
The cost is wire time. A reply that carries 4 holding registers is 13 bytes in RTU: address, function code, byte count, 8 data bytes and 2 CRC bytes. The same reply in ASCII is the 11 payload bytes written out as 22 hex characters, plus the colon, the 2-character LRC and CR/LF, which makes 27 characters. Both modes send each character as one 10- or 11-bit serial character, so the ASCII reply takes about twice the line time. On a fast polling loop over one wire, RTU moves roughly twice the data in the same window.
Why one end cannot switch alone
Every device on a serial line must run the same mode with matching baud, parity and stop settings; the specification requires the whole line to agree. The two framings are mutually unintelligible. An ASCII receiver frames only from the colon onward and discards the binary bytes that arrive ahead of one. An RTU receiver accumulates whatever arrives between gaps, so a stream of hex characters becomes one long frame whose CRC fails. A one-sided switch therefore produces silence or CRC errors, the same symptoms as a wiring fault; the checks in why a Modbus RTU master sees no reply and address errors separate the two.
The decision then runs on one question: does every device on the line document ASCII mode, in the role it plays?
- If either endpoint documents RTU only, keep RTU. The worked example above shows the gap costing one 1 ms counter and two thresholds, which most firmware can absorb without a dedicated hardware timer.
- If every endpoint documents ASCII, change all of them in one bench session: back up the projects, set the mode and the serial settings on each device, read one known register, confirm the colon, the CR/LF and the LRC on a capture, then run the polls the machine actually uses. Work on a bench or an isolated port first, because a half-tested change stops a live line.
- Above 19200 baud the timing argument for ASCII disappears: the fixed 1.75 ms gap is easy for any 1 ms tick, so bandwidth is the only reason left to switch.
Recommendation: keep Modbus RTU and retire the dedicated timer with a counted tick. At 9600 baud, thresholds of 3 ticks to discard a torn frame and 6 ticks to end a frame meet the specification's 1.72 ms and 4.01 ms limits with margin, and above 19200 baud the fixed 1.75 ms gap is easier still. Move to Modbus ASCII only when every device on the line documents the mode and you can switch them all together on the bench before the line runs again.
Questions
How do I measure the gap on a bench?
Put an oscilloscope or a serial tap on the pair and measure the idle time between the last bit of one frame and the first bit of the next. At 9600 baud with parity the gap must be at least 4.01 ms, and pauses inside a frame must stay under 1.72 ms. A gap that measures short points to a master that turns the line around too fast; a pause inside a frame that runs long produces CRC errors on frames that were sent correctly.
What thresholds apply at 115200 baud?
At any rate above 19200 the specification fixes the values: 1.75 ms of silence to end a frame and 750 µs inside a frame. One edge case to check on the bench: a device that keeps computing 11 bits / 115200 baud instead will hold about 4.01 ms of gap. That meets the specification, so it will not break the line, but it slows polling and it is a sign the firmware is not applying the fixed values.
Does ASCII remove all the timing work?
It removes the gap timer, which is the piece that costs a hardware timer. The parser still collects two hex characters per data byte, verifies the LRC and honors the 1-second character interval the specification allows before a frame must be discarded. The timer is genuinely freed; the protocol work is smaller, not zero.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.