UART Baud Rate Error Tolerance: The Real Budget • The Science 360

Q: What is the baud rate error for 115200 on a 16 MHz Arduino?

Arduino's Serial.begin(115200) uses double speed mode with UBRR = 16, giving 16,000,000 / (8 x 17) = 117,647 baud, which is 2.12% fast. In normal mode the best setting is UBRR = 8, giving 111,111 baud, 3.55% slow.

Type Serial.begin(115200) on a 16 MHz Arduino and the chip does not send 115,200 bits per second. It sends 117,647. The 16 MHz clock simply does not divide into 115,200 evenly, so the hardware picks the nearest divider it can and you are 2.12% fast before anything else goes wrong. Most of the time it works anyway. Sometimes, with a different USB adapter, a 3.3 V board or a faster baud rate, it produces garbage, and the reason is a budget of only about 4 to 5 percent shared between both ends of the wire.

Page one mixes a Microchip help page that gives no number at all, STM32 reference-manual tables, and forum threads quoting "5%" or "2%" without saying whether that is per side or total. None of them show what Arduino's own code chooses, why the Uno's USB chip hides its error, or why 230400 is a trap. This post derives the tolerance, then spends it on real boards.

Quick answerAn 8N1 UART tolerates about 4.6% total mismatch between transmitter and receiver with 16x sampling, and about 3.9 to 4.0% with 8x (double speed). Split it between both ends: roughly 2% each. A 16 MHz Arduino at 115200 baud is already 2.12% off from divider rounding alone.

Infographic: How much baud rate error can a UART take? An 8N1 serial frame from start bit to stop bit shows the receiver's sample points drifting later bit by bit. An Arduino Uno asked for 115200 baud actually sends 117,647, 2.12% fast, from divider rounding alone, while an AVR receiver tolerates about 4.6% total in normal mode and 3.9 to 4.0% in double speed. A bar chart of Arduino baud errors shows 9600 at 0.16%, 57600 and 115200 at 2.12%, 230400 at 3.55%, 250000 exact and 460800 at 8.5%. Tiles: the ideal limit is 5.26%, a 14.7456 MHz crystal gives zero error, and the internal oscillator is only ±10%. — Tap the image to view it full size. View the accessible, editable SVG.

Why does a UART have a baud rate tolerance at all?

An asynchronous serial line has no clock wire. The receiver sees only the falling edge of the start bit and then times every following bit with its own clock. If the two clocks disagree, the receiver's sampling points drift through the frame, a little more with each bit. Resynchronisation happens only at the next start bit.

For the classic 8N1 frame (one start bit, eight data bits, no parity, one stop bit) the last thing the receiver samples is the stop bit, whose centre sits 9.5 bit times after the start edge. The sample can drift by at most half a bit before it lands in the wrong bit. That gives the ideal limit:

Ideal receiver, single sample at the centre of each bit:

\begin{aligned}\text{allowed drift} &= 0.5\ \text{bit} \\ &\ \ \text{over } 9.5\ \text{bit times} \\ |\text{error}| &\lt 0.5/9.5 = \mathbf{5.26\%}\end{aligned}

total mismatch (8N1). General, with $D = \text{data} + \text{parity bits}$ :

|\text{error}| \lt 0.5/(D + 1.5)

Figure 1 shows the drift on a real frame. The receiver's sample points (black) are computed from the ATmega328P's 16x timing; the transmitted waveforms are drawn at exactly the receiver's rate and at the two extremes the chip can survive.

Three timing diagrams of an 8N1 UART frame carrying 0x55. Dashed vertical lines show the receiver's sample points at 9/16 of each bit. In the top row the transmitter matches the receiver and every sample falls mid-bit. In the middle row the transmitter is 4.6 percent slow and the last sample lands just inside the start of the stop bit. In the bottom row the transmitter is 4.6 percent fast and the last sample lands at the very end of the stop bit. — Figure 1. Sample positions across an 8N1 frame (byte 0x55, sent LSB first). At the tolerance limits the stop-bit sample sits on a bit edge. The error accumulates, which is why the last bit is the one that fails first.

Where the 4.5% figure comes from

A real UART does worse than the ideal 5.26% for two reasons, both described in section 20.8 of the ATmega328P datasheet. First, it does not see the start edge exactly. In Normal mode it samples the line 16 times per bit (8 times in Double Speed mode), so it only knows when the start bit began to within one sample, 1/16 of a bit. Second, it decides each bit by majority vote of three samples, numbers 8, 9 and 10 of the 16, which acts as a small noise filter but moves the decision window slightly away from the exact centre.

Microchip packs both effects into two formulas, where S is samples per bit, S_F the first voting sample and S_M the middle one:

\begin{aligned}R_{\text{slow}} &= \frac{(D + 1)\,S}{S - 1 + D S + S_F} \\ R_{\text{fast}} &= \frac{(D + 2)\,S}{(D + 1)\,S + S_M}\end{aligned}

Normal mode, 8N1: $D = 8,\ S = 16,\ S_F = 8,\ S_M = 9$

\begin{aligned}R_{\text{slow}} &= 9 \times 16/(15 + 128 + 8) \\ &= 144/151 = 0.9536 \to \mathbf{-4.64\%} \\ R_{\text{fast}} &= 10 \times 16/(144 + 9) \\ &= 160/153 = 1.0458 \to \mathbf{+4.58\%}\end{aligned}

Double Speed (U2X), 8N1: $S = 8,\ S_F = 4,\ S_M = 5$

\begin{aligned}R_{\text{slow}} &= 72/(7 + 64 + 4) = 72/75 \\ &= 0.9600 \to \mathbf{-4.00\%} \\ R_{\text{fast}} &= 80/(72 + 5) = 80/77 \\ &= 1.0390 \to \mathbf{+3.90\%}\end{aligned}

These match the datasheet's Tables 20-2 and 20-3 (R_slow 95.36%, R_fast 104.58%; and 96.00%, 103.90%), with one small oddity: the normal-mode table prints the total as −4.54%, while its own R_slow of 95.36% works out to −4.64%. Either way, the "about 4.5%" rule of thumb is the normal-mode figure, and it shrinks with longer frames and with fewer samples per bit, as Figure 2 shows.

Line chart of tolerated baud mismatch against data plus parity bits from 5 to 10. The ideal centre-sample limit falls from 7.7 to 4.3 percent, normal 16x mode from 6.7 to 3.8 percent, and double speed 8x mode from 5.7 to 3.2 percent. For 8N1, the values are 5.26, 4.58 and 3.90 percent. — Figure 2. Total tolerable mismatch, computed from Microchip's equations. Adding a parity bit ( $D = 9$ ) or switching to double speed costs about 0.5 to 0.7 percentage points each.

The key word is total. The 4.6% is the ratio between the transmitter's rate and the receiver's rate. Both ends contribute, so Microchip's tables recommend that each side keep its own error within about half: ±2.0% for 8N1 in Normal mode and ±1.5% in Double Speed mode, "under the assumption that the Receiver and Transmitter equally divides the maximum total error."

How the baud rate divider rounds: UBRR

An AVR generates its baud rate by dividing the system clock with a 12-bit register, UBRR:

Normal mode (U2X = 0):

\text{BAUD} = \frac{f_{\mathrm{OSC}}}{16 \times (\text{UBRR} + 1)}

Double Speed (U2X = 1):

\text{BAUD} = \frac{f_{\mathrm{OSC}}}{8 \times (\text{UBRR} + 1)}

UBRR must be a whole number, so unless f_OSC happens to be a multiple of $16 \times \text{BAUD}$ (or $8 \times \text{BAUD}$ ), the result is off. The worked case everyone hits:

16 MHz, 115,200 baud, Normal mode:

\begin{aligned}\text{ideal UBRR} &= \frac{16{,}000{,}000}{16 \times 115{,}200} - 1 \\ &= 8.68 - 1 = 7.68 \\ &\to \text{round to } 8 \\ \text{actual} &= 16{,}000{,}000/(16 \times 9) \\ &= 111{,}111\ \text{baud} \\ \text{error} &= \frac{111{,}111}{115{,}200} - 1 \\ &= \mathbf{-3.55\%}\end{aligned}

16 MHz, 115,200 baud, Double Speed:

\begin{aligned}\text{ideal UBRR} &= \frac{16{,}000{,}000}{8 \times 115{,}200} - 1 \\ &= 17.36 - 1 = 16.36 \to 16 \\ \text{actual} &= 16{,}000{,}000/(8 \times 17) \\ &= 117{,}647\ \text{baud} \\ \text{error} &= \mathbf{+2.12\%}\end{aligned}

Here is the trade that makes U2X interesting. Normal mode has the bigger tolerance (−4.64%) but the bigger error (−3.55%), using 77% of the budget on rounding alone. Double Speed has a smaller tolerance (+3.90%) but a smaller error (+2.12%), using 54%. Double Speed wins at 115200, which is why Arduino uses it.

What does Serial.begin() actually pick?

The AVR Arduino core computes the divider in HardwareSerial::begin(). It tries Double Speed first with baud_setting = (F_CPU/4/baud-1)/2, integer arithmetic that rounds to the nearest UBRR. It falls back to Normal mode only if the value would exceed 4095, or in one hard-coded case: 57600 baud on a 16 MHz board, kept in Normal mode "for compatibility with the bootloader shipped with the Duemilanove and previous boards and the firmware on the 8U2 on the Uno and Mega 2560." Figure 3 runs that code for every common rate.

Bar chart of baud rate error for Serial.begin on a 16 MHz Arduino. 9600, 19200 and 38400: plus 0.2 percent. 57600 and 115200: plus 2.1 percent. 230400: minus 3.5 percent. 250000, 500000 and 1 megabaud: 0 percent. 460800 and 921600: plus 8.5 percent. A shaded band marks the double speed total budget of plus 3.9 to minus 4.0 percent. — Figure 3. Error of the actual baud rate produced by the Arduino AVR core at 16 MHz, computed from its UBRR formula. The values match Microchip's Table 20-7. Rates that are 16 MHz divided by a whole number are exact.

Three things stand out. The 57600 special case costs accuracy: Normal mode gives UBRR 16 and 58,824 baud (+2.12%), while Double Speed would have given UBRR 34 and 57,143 baud (−0.79%). The "odd" rates 250000, 500000 and 1000000 are perfect on a 16 MHz board because $16\ \mathrm{MHz}/(8 \times 8) = 250{,}000$ exactly. And 460800 and 921600 are hopeless at +8.5%, more than twice the budget.

Why 115200 works with the Serial Monitor but not with your adapter

This is the misconception worth correcting. A widespread explanation for flaky serial says "115200 is 2.1% off on a 16 MHz Arduino, so it is unreliable". It is 2.1% off. Whether that matters depends entirely on the other end.

On an Uno R3, the USB to serial converter is a second AVR, an ATmega16U2, also clocked at 16 MHz. Its firmware (Arduino-usbserial, built on LUFA) sets its own UART with the macro ((F_CPU / 8) + (Baud / 2)) / Baud − 1 in Double Speed mode, and also special-cases 57600 to Normal mode. At 115200 that gives:

16U2:

\begin{aligned}&((2{,}000{,}000 + 57{,}600)/115{,}200) - 1 \\ &= 17.86 \to 17 - 1 = \text{UBRR } 16\end{aligned}

U2X → 117,647 baud (+2.12%)

ATmega328P: UBRR 16, U2X → 117,647 baud (+2.12%)

Mismatch from rounding:

117{,}647/117{,}647 - 1 = \mathbf{0\%}

Both ends are wrong by the same amount, so the mismatch the receiver sees is only the difference between the two oscillators. The PC never notices: the 16U2 talks to it over USB, where baud rate has no physical meaning.

Swap in an adapter that produces the requested rate exactly, or another microcontroller with a fractional baud generator, and the full 2.12% appears. Add the clock tolerance of each end and the budget looks like Figure 4.

Figure 4. Mismatch budgets for three pairings. The 0.5% clock allowance is our assumption, not a datasheet figure. Note that the 230400 case is compared with the 3.9% fast limit for simplicity; it is actually a slow error against a 4.0% limit, and lands right on it.

Uno → exact adapter at 115200:

\begin{aligned}&2.12\% + 0.5\%\ (\text{clocks, assumed}) \\ &= 2.62\%\ \text{of } 3.90\%\end{aligned}

Works, 1.3 points spare.

Uno → exact adapter at 230400, Arduino rounding:

\begin{aligned}\text{UBRR} &= (17 - 1)/2 = 8 \\ \text{baud} &= 16\ \mathrm{MHz}/(8 \times 9) \\ &= 222{,}222\ \text{baud} \\ &= -3.55\% \\ \text{total} &= 3.55\% + 0.5\% \\ &= 4.05\%\end{aligned}

against a −4.00% limit → fails at the edge

So the same sketch that is rock solid at 230400 with the Serial Monitor can drop characters through an FTDI cable, and the cure is not a better cable but a better baud rate: 250000 is exact on both an AVR and most adapters that support arbitrary rates.

Source note The 0.5% clock allowance in Figure 4 is our assumption. The Uno R3's ATmega328P is commonly reported to run from a ceramic resonator rather than a crystal, and Microchip's datasheet warns that "for a resonator the system clock may differ more than 2% depending of the resonators tolerance". I did not open the board's bill of materials or a resonator datasheet. I also assumed the LUFA version bundled with the 16U2 firmware uses the same rounding macro as the current LUFA source, which I did read.

Why 14.7456 MHz and 11.0592 MHz crystals exist

If rounding is the problem, choose a clock that does not need rounding. Every standard rate from 300 to 115,200 baud divides into $115{,}200 \times 16 = 1{,}843{,}200\ \mathrm{Hz}$ evenly, so any crystal that is a whole multiple of 1.8432 MHz gives exact baud rates. The familiar "UART crystals" are exactly that:

1.8432\ \mathrm{MHz} = 16 \times 115{,}200

(the original 8250/16550 UART clock)

\begin{aligned}7.3728\ \mathrm{MHz} &= 4 \times 1.8432\ \mathrm{MHz} \\ &\to \text{UBRR } 3 \text{ for } 115{,}200 \\ 11.0592\ \mathrm{MHz} &= 6 \times 1.8432\ \mathrm{MHz} \\ &\to \text{UBRR } 5,\ 0.0\%\end{aligned}

(11.0592 MHz is also $12 \times 921{,}600$ for 8051 timers)

\begin{aligned}14.7456\ \mathrm{MHz} &= 8 \times 1.8432\ \mathrm{MHz} \\ &= 128 \times 115{,}200 \\ \text{UBRR} &= 128/16 - 1 = 7 \\ &\to \mathbf{0.0\%} \\ 18.432\ \mathrm{MHz} &= 10 \times 1.8432\ \mathrm{MHz} \\ &\to \text{UBRR } 9,\ 0.0\%\end{aligned}

Figure 5 sweeps the clock from 1 to 20 MHz and shows how special those frequencies are. Between them the error swings up and down as UBRR steps, with peaks of several percent. The 16 MHz everyone uses sits at 3.5% in Normal mode; 20 MHz, another common AVR clock, manages 1.4%.

Figure 5. Divider error at 115200 baud as a function of clock frequency, our calculation with the nearest UBRR in Normal mode. The green dots are the multiples of 1.8432 MHz where it is exactly zero.

The price of a UART crystal is everything else. A 14.7456 MHz clock makes millisecond timers awkward (14,745.6 cycles per millisecond) and runs a little below the 16 MHz many libraries assume. That is why Arduino chose 16 MHz and lives with 2.12%. For a design where the UART matters more than round timer numbers, such as a data logger or a Modbus node, the crystal choice is worth making, and the load capacitors are sized as in the crystal load capacitor calculation. The same divide-down logic, applied to timekeeping instead of baud rates, is why watch crystals run at 32,768 Hz.

3.3 V boards, 8 MHz and the internal oscillator

The 3.3 V Pro Mini and similar boards run at 8 MHz, and there 115200 is genuinely bad:

8 MHz, Arduino rounding:

\begin{aligned}&(8{,}000{,}000/4/115{,}200 - 1)/2 \\ &= (17 - 1)/2 = 8,\ \text{U2X} \\ \text{actual} &= 8{,}000{,}000/(8 \times 9) \\ &= 111{,}111\ \text{baud} \to \mathbf{-3.55\%}\end{aligned}

against a −4.00% limit. Normal mode would be worse: UBRR 3 → 125,000 baud, +8.5%.

That leaves under half a percent for both clocks combined. At 8 MHz, 57600 (U2X, UBRR 16, +2.12%) or 38400 (+0.16%) are the sensible choices.

Running from the internal RC oscillator is worse again. The ATmega328P datasheet gives its factory calibration accuracy as ±10% at 3 V and 25 °C, and ±1% after user calibration over the full voltage and temperature range. A ±10% clock cannot hold a ±2% per-side budget at any baud rate; even ±1% uses half of it before the divider adds anything. If a design must use the internal oscillator, calibrate it (OSCCAL) against a known reference, or use a protocol that measures the incoming bit time, such as LIN's sync byte.

The voltage level side of mixing 3.3 V and 5 V UARTs is a separate problem, covered in 3.3 V to 5 V level shifting. Edge speed matters little here: even a slow 200 ns edge is 2% of a bit at 115200.

A worked design check

Suppose a 16 MHz ATmega328P must talk at 115200 baud, 8N1, to an ESP32. Assume the ESP32's divider is close to exact and its crystal is good to 0.01%; both are typical but you should check your part.

AVR divider error (U2X, UBRR 16): +2.12%

AVR clock: crystal ±0.01% (or resonator, assume ±0.5%)

ESP32 divider + clock: assume ±0.1%

Worst-case total:

2.12 + 0.5 + 0.1 = 2.72\%

AVR receiving (U2X limit +3.90%): margin 1.18 points

ESP32 receiving: depends on its sampling, but a 16x receiver gives about ±4.6% → margin about 1.9 points

Verdict: works. Switch the AVR to 14.7456 MHz, or use 250000 baud, to remove the 2.12% entirely.

To check a link in practice, measure rather than trust the arithmetic. Send a stream of 0x55 ('U'), which alternates 0 and 1 and produces a square wave at half the baud rate, and measure the period with a scope or frequency counter; a correctly compensated probe (see how a 10x oscilloscope probe works) is plenty at these speeds. At 117,647 baud the square wave is 58.8 kHz instead of 57.6 kHz, a difference any counter shows at once.

The sampling ideas here, a fixed number of samples per bit and a vote among them, are a small cousin of the sampling theory in the Nyquist theorem: the receiver needs enough samples to locate the edge, and every sample of uncertainty comes out of the timing budget.

The short version for your bench: an 8N1 AVR receiver tolerates about ±4.6% total mismatch in Normal mode and +3.9/−4.0% in Double Speed mode; plan for ±2% per side. A 16 MHz Arduino is +2.12% at 115200 and −3.55% at 230400, but exact at 250000, 500000 and 1000000. It works with the Uno's own USB chip because both ends round the same way. For zero divider error, use a multiple of 1.8432 MHz such as 14.7456 MHz.

FAQ

How much baud rate error can a UART tolerate?

For an 8N1 frame, an ideal receiver that samples once in the middle of each bit tolerates 5.26% total mismatch. A real ATmega328P receiver tolerates about +4.6% and −4.6% in 16x mode and +3.9% and −4.0% in 8x double speed mode. That is the total between transmitter and receiver, so each side should stay within roughly half of it: Microchip recommends 2.0% and 1.5% respectively.

What is the baud rate error for 115200 on a 16 MHz Arduino?

Arduino's Serial.begin(115200) uses double speed mode with $\text{UBRR} = 16$ , giving $16{,}000{,}000/(8 \times 17) = 117{,}647$ baud, which is 2.12% fast. In normal mode the best setting is $\text{UBRR} = 8$ , giving 111,111 baud, 3.55% slow.

Why are 14.7456 MHz and 11.0592 MHz crystals used?

They are integer multiples of 1.8432 MHz, which is 16 times 115,200. Divided by 16 times a whole number they give standard baud rates exactly, so the UART divider adds zero error. 14.7456 MHz is 128 times 115,200, so $\text{UBRR} = 7$ gives exactly 115,200 baud.

Why does serial work with the Arduino Serial Monitor but not with my USB adapter?

On an Uno R3 the USB-serial chip is an ATmega16U2 also running at 16 MHz with the same divider, so both ends are 2.12% fast at 115200 and the mismatch cancels. An adapter that produces the exact baud rate sees the full 2.12% error, and at 230400 the Arduino is 3.55% slow, close to the 4% double-speed limit.

Sources

Microchip, ATmega48A/PA/88A/PA/168A/PA/328/P datasheet DS40002061A, section 20 (BAUD and UBRR equations, start bit detection, majority voting of samples 8, 9, 10, R_slow/R_fast equations, Tables 20-2 and 20-3, resonator warning, Table 20-7 UBRR examples at 14.7456 and 16 MHz) and Table 29-9 (internal RC oscillator ±10% factory, ±1% user calibration): microchip.com DS40002061A
Arduino, ArduinoCore-avr HardwareSerial.cpp, HardwareSerial::begin() (U2X first, 57600 exception, UBRR formula): github.com/arduino/ArduinoCore-avr
Arduino, Arduino-usbserial firmware for the ATmega8U2/16U2 (57600 special case, SERIAL_2X_UBBRVAL in Double Speed mode): github.com/arduino/ArduinoCore-avr firmwares
Dean Camera, LUFA Serial_AVR8.h (SERIAL_UBBRVAL and SERIAL_2X_UBBRVAL rounding macros): github.com/abcminiuser/lufa
Microchip online documentation, "Baud Rate Tolerance" (page-one example; describes the total-error concept but gives no figures): onlinedocs.microchip.com

Method note: Figures 1 to 5 are computed by us from the datasheet equations and the Arduino core's integer arithmetic. The 0.5% clock allowance and the ESP32 figures in the worked design check are stated assumptions, not datasheet values.

Header image: NASA/Ken Ulbrich (image AFRC2020-0038-38), regraded for this article.

Why does a UART have a baud rate tolerance at all?

Where the 4.5% figure comes from

How the baud rate divider rounds: UBRR

What does Serial.begin() actually pick?

Why 115200 works with the Serial Monitor but not with your adapter

Why 14.7456 MHz and 11.0592 MHz crystals exist

3.3 V boards, 8 MHz and the internal oscillator

A worked design check

FAQ

How much baud rate error can a UART tolerate?

What is the baud rate error for 115200 on a 16 MHz Arduino?

Why are 14.7456 MHz and 11.0592 MHz crystals used?

Why does serial work with the Arduino Serial Monitor but not with my USB adapter?

Related on The Science 360

Sources