Baud rate is the setting that determines how fast two devices push symbols across a serial line such as RS-232 or RS-485. It is one of the first parameters a field technician checks when a Modbus RTU link, a serial radio, or a flow computer refuses to talk, because if the two ends disagree on baud, nothing decodes. This guide explains what baud rate actually measures, why it must match on both ends, and how choosing a rate trades speed against range and reliability.
Baud Rate in one line: Baud rate is the number of signalling symbols transmitted per second on a serial line, expressed in units like 9600 or 19200 baud. Both devices on the link must be set to the same baud rate to communicate, and higher rates move data faster but tolerate less cable length, noise, and radio turnaround delay.
Strictly, baud measures symbols per second while bit rate measures bits per second, and the two are only equal when each symbol carries exactly one bit. On the plain RS-232 and RS-485 links used across oilfield automation, the line encoding puts one bit per symbol, so 9600 baud effectively means 9600 bits per second and the terms get used interchangeably. On modems and some radios that pack multiple bits into each symbol, the bit rate can exceed the baud rate, which is why the two words are not truly synonyms.
For everyday serial work, treat the baud number as your raw line speed and remember that not all of it becomes payload. Each character on a typical asynchronous link is wrapped in a start bit, optional parity bit, and one or more stop bits, so a byte usually consumes ten or eleven bit-times rather than eight. That framing overhead is why a 9600 baud link delivers well under 1000 useful bytes per second, and it matters when you are budgeting poll cycles for many registers.
Common serial rates step in a familiar ladder: 1200, 2400, 4800, 9600, 19200, 38400, 57600, and 115200. Older telemetry radios and legacy field devices often top out at 9600 or 19200, while short direct cable runs to a laptop happily run much faster. Picking a rate is a compromise, not a race to the top number.
The faster you signal, the shorter and narrower each bit becomes in time, which leaves less margin for the distortions a real cable or radio introduces. Long RS-485 runs behave like a transmission line: capacitance rounds off edges, reflections from unterminated ends smear bits, and electrical noise from nearby motors or VFDs corrupts the smaller timing windows a high baud rate creates. This is why a bus that runs cleanly at 9600 over a few thousand feet may throw framing and CRC errors the moment you bump it to 115200.
Radio links add their own penalty. A serial radio needs time to key up its transmitter and for the receiver to lock before real data flows, and that turnaround happens once per message regardless of baud. Running the radio channel faster shrinks the on-air time of the payload but does nothing to shrink the fixed key-up delay, so past a point raising baud yields diminishing returns and can even hurt if the radio cannot buffer characters at the higher rate.
The practical rule is to pick the lowest baud rate that still meets your poll timing, then leave headroom for line quality. For a multidrop RS-485 loop of RTUs spread across a pad, 9600 or 19200 is a conservative, robust choice that most devices support out of the box. Reserve the high rates for short, clean, point-to-point cable where you genuinely need the throughput.
In a cloud SCADA deployment, baud rate lives at the very edge of the system, on the serial hop between a gateway or serial device server and the field instrument it polls. The gateway reads Modbus registers over that serial link, then forwards the data upstream over cellular or Ethernet, so if the baud rate is wrong the gateway sees timeouts and the whole site appears offline even though the radio path is fine. Getting baud, parity, and framing right on that last serial link is a prerequisite before any data ever reaches the cloud.
Baud rate also shapes how tightly you can schedule polls. A gateway reading a dozen registers from several devices on one 9600 baud bus has a finite budget of bytes per second, and stacking too many devices or requesting too many registers per scan stretches the cycle until updates lag. When operators complain that a tank level or flow total feels sluggish on the dashboard, the cause is often an overloaded low-baud serial segment rather than the cloud platform itself.
Because the setting is invisible once a site is running, mismatched baud is a classic commissioning error: a device shipped at a factory default of 9600 quietly ignored when the panel drawing assumed 19200. A cloud platform that surfaces per-device communication health, error counts, and last-good timestamps makes these serial-layer problems visible from a browser, so a technician can confirm the fix without standing at the panel with a laptop.
9600 or 19200 baud is a safe, widely supported default for Modbus RTU over RS-485, especially on longer runs or in electrically noisy areas. Higher rates like 38400 or 115200 work well on short, clean cable when you need faster polling. Whatever you choose, every device on the same bus must be set to the identical rate.
Yes. Standard asynchronous serial has no way to negotiate speed automatically, so if the two ends disagree on baud rate the receiver samples the bits at the wrong times and reads garbage or nothing at all. Matching the baud rate, along with parity and stop bits, is the first thing to verify when a serial link will not communicate.
Higher baud shortens each bit in time, so long cables, reflections, and noise start corrupting data before you see any real throughput gain. On radio links a fixed key-up and receiver-lock delay happens per message regardless of speed, so raising baud only shrinks the payload's on-air time and leaves the overhead untouched. Past a point you get more errors and retries, not more useful data.
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.