Lab
Baud mismatch playground
Garbage in the Serial Monitor is one number, not a broken module. Set the two rates below and watch the same signal turn into different bytes — the receiver is sampling a real waveform at the wrong moments, and the result is completely predictable.
Try 9600 → 4800 and type B. It arrives as ü, every time. Then type A: it vanishes, because a start bit sampled high is rejected as noise. That is why a garbled line is often shorter than what was sent.
What this shows
Garbage in a serial terminal is one number set wrong, not a broken module. Both ends sample a real waveform; when they disagree about speed, the receiver samples at the wrong moments and assembles bytes that were never sent.
The result is completely deterministic, not random. Send capital B — 0x42 — at 9600 to a receiver listening at 4800 and it arrives as 0xFC, the character ü, every single time. The same input always produces the same wrong output.
Some characters do not arrive at all. Send capital A — 0x41 — under the same mismatch and it vanishes, because the receiver checks that the start bit is still low halfway through and rejects the frame as noise when it is not. This is why a garbled line is often shorter than what was sent.
The model here follows the ATmega328P USART: the line idles high, a falling edge begins a frame, eight data bits go out least significant first, and the receiver oversamples sixteen times per bit and takes the majority of samples 8, 9 and 10 at each bit centre.
Common questions
- Why does my Arduino Serial Monitor show garbage characters?
- The Serial Monitor and the sketch, or the sketch and the module, are set to different baud rates. Bytes are arriving and the wiring is fine — the receiver is simply sampling the waveform at the wrong moments. Set both ends to the same number and the text becomes readable.
- Why is the garbage the same every time?
- Because sampling at the wrong rate is deterministic, not random. A given byte at a given pair of rates always decodes to the same wrong byte. 0x42 sent at 9600 and read at 4800 is always 0xFC.
- Why are some characters missing from the garbage?
- Their start bit failed validation. The receiver re-checks the start bit at its midpoint and abandons the frame if the line has gone high, treating it as noise. Under a rate mismatch this happens to some byte values and not others, so the garbled output is shorter than the input.