Serial flow control is the mechanism that lets a receiver tell a sender to pause before its buffer overflows and data is lost. It comes in a hardware form using dedicated handshake lines and a software form using special characters embedded in the data stream. In field automation it carries a second, easily misconfigured role: the RTS line often keys a serial radio to transmit, so getting flow control wrong can silently break a whole radio-to-serial link even when everything else is correct.
Serial Flow Control in one line: Serial flow control regulates the pace of data so a fast sender does not overrun a slower receiver's buffer, using either hardware handshake lines like RTS and CTS or software characters like XON and XOFF. On radio-connected serial links, the RTS line is frequently repurposed to key the radio transmitter, making its correct configuration essential.
Hardware flow control uses extra wires alongside transmit and receive. In the common RTS/CTS scheme, a device asserts Request To Send and waits for the other end to assert Clear To Send before transmitting, and either side can deassert its line to say stop, giving near-instant pause and resume without touching the data. The DTR and DSR pair works similarly at the device-ready level. Because the signalling is out of band, hardware flow control never corrupts the payload and responds quickly.
Software flow control, called XON/XOFF, needs no extra wires. Instead the receiver injects a special XOFF character into the return stream to say pause and an XON character to say resume, so pacing rides on the same two data lines. The tradeoff is that those control bytes must not appear in the real data, which makes XON/XOFF unsuitable for binary protocols like Modbus RTU where any byte value is legitimate payload. It also reacts more slowly than hardware lines because the control character sits in a queue.
For most industrial serial links carrying binary protocols, the practical answer is to disable flow control entirely, or use hardware RTS/CTS only where the hardware genuinely supports it. Turning on the wrong mode is a frequent misconfiguration: enabling XON/XOFF on a Modbus link can silently eat payload bytes that happen to equal the control characters, producing intermittent, baffling errors that are hard to trace back to a flow-control setting.
Every serial receiver has a small buffer that holds incoming bytes until software can read them. If data arrives faster than it is consumed, for example when the CPU is busy or the downstream link is slower, the buffer fills and any further bytes are dropped, corrupting the message. Flow control exists to apply back-pressure before that happens, telling the sender to hold off until space frees up.
The mismatch that triggers overrun often appears at a bridge point rather than a single device. A serial device server or protocol gateway may accept characters at one rate on its serial port while forwarding them at a different rate over the network, and without flow control the faster side eventually swamps the buffer between them. Correctly wired hardware handshaking, or a protocol that paces itself, keeps the two sides in step.
In practice, many robust field links avoid the problem by design rather than relying on flow control. Modbus RTU, for instance, sends short bounded messages and waits for a reply, so a well-behaved master never floods a slave faster than it can respond. That is why flow control is frequently left off on such links, with the protocol's own request-and-wait rhythm providing the pacing instead.
The most consequential twist for field automation is that many serial radios use the RTS line not for flow control but as a push-to-talk key. When the connected device or gateway asserts RTS, the radio keys up and transmits; when RTS drops, the radio unkeys and listens. This repurposing means the RTS timing has to match the radio's key-up requirements, and a device configured for RTS/CTS flow control instead of RTS keying can leave the radio permanently unkeyed or mistimed, so nothing ever goes on the air.
This is a notorious source of grief when connecting a legacy serial device to a radio for the first time. The link tests fine on a bench cable but goes silent over the radio because the RTS line is doing the wrong job, or because the key-up delay was not accounted for and the radio truncates the start of each message. Diagnosing it requires knowing that flow-control settings and radio keying share the same physical line and can conflict.
For a cloud SCADA gateway polling over serial radio, the fix is to configure RTS behavior to match the radio: assert RTS to key, allow the specified key-up delay before sending payload, and drop RTS to release the channel. Once that timing is right, the gateway reads the field devices and forwards the data to the cloud like any other link. A platform that reports per-device communication health helps confirm the keying is correct, because a mistimed RTS shows up as consistent timeouts that clear the moment the delay is set properly.
Hardware flow control uses dedicated handshake wires such as RTS and CTS to signal pause and resume out of band, so it never disturbs the data and reacts quickly. Software flow control, XON/XOFF, sends special characters within the data stream instead, needing no extra wires but risking corruption on binary protocols where those characters can appear as real data. Hardware is generally preferred where the wiring supports it.
Usually no. Modbus RTU carries binary data where any byte value is valid, so XON/XOFF software flow control can corrupt messages, and the protocol's request-and-wait rhythm already paces the traffic. Most Modbus RTU links run with flow control disabled, reserving hardware RTS/CTS only for special cases or, on radios, for keying the transmitter.
Many serial radios repurpose the RTS line as a transmit key rather than for flow control, so asserting RTS keys the radio up and dropping it releases the channel. If a device is set for RTS/CTS flow control instead of RTS keying, or the key-up delay is not honored, the radio may never transmit or may clip the start of each message. Matching RTS behavior to the radio is essential for a working link.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.