CliDeck
WORKSPACE

Garbage Characters in Serial Console: Baud Rate & 8N1 Explained (With Quick Tests)

← Back to Blog

What “garbage characters” really means (and why it’s usually not broken hardware)

Random symbols, squares, unreadable text, or “scrambled” output is the classic sign that your computer and the device don’t agree on serial settings.

In most cases, it’s one of these:

  1. Wrong baud rate
  2. Wrong frame format (usually 8N1, but not always)

That’s good news: this is typically a 2-minute fix—no reflashing, no driver drama, no mystery troubleshooting.

If you work with console cables often and you’re tired of remembering per-device settings (and you want session history and logs in one place), a workspace approach is much easier long-term. That’s a core use case for CliDeck: CliDeck Workspace.

The basics: what baud rate is

Baud rate is the serial line speed (roughly: how many symbols per second). If your PC is set to 9600 but the device is transmitting at 115200, you’ll see garbage instead of readable text.

Key rule: baud rate must match on both sides.

What 8N1 means (and why it matters)

When people say “9600 8N1,” they mean the frame format:

  • 8 — data bits (8 bits of payload)
  • N — parity (None)
  • 1 — stop bits (1)

This is the most common setting for network gear console ports and a huge number of devices. But if a device uses something else (like 7E1 or 8E1), output can still look wrong even when the baud rate is correct.

How to tell it’s baud rate (not a bad cable)

Typical signs of a baud mismatch:

  • output looks like random symbols;
  • changing baud rate changes the “pattern” of garbage;
  • you occasionally see fragments of real words, but most is unreadable;
  • one speed is garbage, another speed is readable.

Signs of a physical/wiring issue:

  • absolutely no output at any speed;
  • nothing becomes readable no matter what you try;
  • the device never reacts to Enter/keystrokes;
  • the serial port doesn’t appear on the computer at all.

Always rule out baud rate and 8N1 first—it’s the fastest win.

The 2-step quick test that fixes most cases

Step 1: Try the two most common speeds

In most real-world scenarios you only need to test:

  • 9600
  • 115200

If it’s classic network gear console, start with 9600. If it’s a dev board / UART debug, start with 115200.

Step 2: Confirm 8N1 and disable flow control

Make sure you’re using:

  • Data bits: 8
  • Parity: None
  • Stop bits: 1
  • Flow control: None

Common baud rates to try (fast lookup)

Device typeMost commonNext to try
Network gear console9600115200, 38400
UART debug / dev boards11520057600, 9600
Older equipment960019200, 38400
Bootloader / low-level logs115200230400

If 9600 and 115200 don’t work, the next most productive guesses are usually 57600 and 38400.

Quick tests on macOS, Linux, and Windows

Below are minimal ways to switch speeds quickly and see results immediately.

macOS: cu (built-in) + the right device name

  1. List ports:
ls -1 /dev/cu.*
  1. Test 9600:
cu -l /dev/cu.usbserial-XXXX -s 9600
  1. If you see garbage, exit (~.), then test 115200:
cu -l /dev/cu.usbserial-XXXX -s 115200

If you’re offline and just need a console right now, cu is often the best built-in option. And if you want organized sessions and logs across multiple devices, that’s exactly where CliDeck helps: CliDeck Features.

Linux: screen (fastest “just test it” tool)

  1. Find likely devices:
ls -1 /dev/ttyUSB* /dev/ttyACM* 2>/dev/null
  1. Test 9600:
screen /dev/ttyUSB0 9600
  1. Exit: Ctrl+A, then K, then confirm.
  2. Test 115200:
screen /dev/ttyUSB0 115200

Windows: PuTTY (simple and widely used)

  1. Open Device Manager → Ports (COM & LPT) and note the COM port.
  2. In PuTTY, select Serial and enter the COM port.
  3. Set Speed to 9600, use 8N1, and set Flow control to None.
  4. If you see garbage, change Speed to 115200 and try again.

If garbage remains: what to check next

1) Parity and stop bits

If the baud rate is correct but output still looks wrong, the device may not be 8N1. Try:

  • 7E1 (7 data bits, even parity, 1 stop bit)
  • 8E1 (8 data bits, even parity, 1 stop bit)

This is less common, but it does show up on certain systems.

2) Flow control (very common gotcha)

If flow control is enabled (especially RTS/CTS), output can pause, stutter, or behave oddly.

For most console sessions: Flow control = None unless you know otherwise.

3) Wrong electrical standard: RS-232 vs TTL UART

A classic mistake is mixing RS-232 and TTL UART. They are not interchangeable and use different signal levels.

If you’re connecting to UART pins on a board, you usually need a TTL USB-UART adapter—not a traditional RS-232 adapter.

4) Wrong port or a busy port

If another program is holding the port open, behavior can be unpredictable. Close IDE serial monitors and other terminal sessions, then retry.

Mini FAQ

Why does one baud rate look like garbage but another looks fine?

Because text is transmitted as bits, and the wrong timing (speed) makes the receiver interpret bits incorrectly.

Why was it fine earlier, and now it’s garbage?

The device’s baud rate might have changed, or you connected to a different device with different defaults. Also common: bootloader output uses one speed and the main OS uses another.

Bottom line

If you see garbage characters in a serial console:

  1. Switch between 9600 and 115200 first.
  2. Confirm 8N1 and Flow control = None.
  3. If needed, try different parity/stop bits and make sure you’re using the correct electrical standard (RS-232 vs TTL UART).

And if you do this often and want sessions and logs to be organized instead of constantly re-tested, try CliDeck: CliDeck Workspace.