Debugging Serial Protocols with a HEX Monitor

The worst serial failures are the quiet ones. You send a command, nothing readable comes back, and a text terminal gives you no information at all: no bytes is no bytes, whether the cable is unplugged or the baud rate is wrong. A HEX monitor turns that silence into evidence.

Why text view is not enough

A terminal renders received bytes as characters. That works for printable ASCII and quietly misleads you for everything else:

• Non-printable bytes are dropped, replaced or turned into control characters.
• Binary protocols — Modbus RTU, most MCU telemetry, any custom frame — are not text at all.
• Direction matters. In a text view you cannot tell what you sent from what you received once the scrollback is long.
• Line endings and framing are invisible: \r vs \r\n vs \n is the difference between a parser working and not.

Reading a HEX view

A HEX monitor shows each byte as two hex digits, grouped, usually with an ASCII column on the right and a direction marker (TX = out, RX = in). The skills that matter:

• Read the frame, not the characters. Locate the header, the payload length and the trailing checksum.
• Watch the direction. TX with no RX is a different problem from RX with no TX.
• Compare against a known-good capture. One working exchange is worth more than an hour of guessing.

Example: a Modbus RTU frame

A read-holding-registers request to slave 1 looks like:

01 03 00 00 00 02 C4 0B

• 01 — slave address
• 03 — function code (read holding registers)
• 00 00 — starting address
• 00 02 — quantity of registers
• C4 0B — CRC-16, low byte first

A typical reply is 01 03 04 00 0A 00 14 <crc> where 04 is the byte count. If you see the request go out and an exception come back (01 83 02 ... — function code with the high bit set), the device heard you and rejected the request. That is a completely different bug from silence, and only the HEX view tells you which one you have.

Example: NMEA 0183

GPS and marine gear stream ASCII sentences framed by $ and <CR><LF>, with a * checksum: $GPRMC,...*6B. Here the HEX view is useful precisely because the text looks plausible: it reveals whether the terminating bytes are really 0D 0A, whether there is stray leading whitespace, and whether the sentence is being truncated mid-frame.

The three failure signatures

What you see	What it means	What to check
No TX, no RX	Port not open, or you are talking to the wrong port	Device Manager port number, adapter driver, cable seating
TX only, nothing returns	Device not hearing you, or TX/RX swapped	Null-modem vs straight-through, TX/RX crossover, device powered
RX garbage at a steady rate	Baud rate or framing mismatch — real traffic, wrong settings	Baud, data bits, parity, stop bits; try 9600 8N1 then 115200 8N1
Correct bytes, occasional corruption at speed	Flow control missing or buffer overrun	Enable RTS/CTS or XON/XOFF; lower the baud rate to confirm

A repeatable workflow

1. Confirm you can see your own bytes going out. If not, fix the port before touching the device.
2. Send the shortest command the device documents. Watch for any response at all.
3. If the response is unintelligible, change baud rate and nothing else, then retry.
4. Once framing is right, move to the text view and work normally — keeping the HEX monitor open in case something looks odd.
5. Capture the working exchange to a log. Future you will not remember the exact frame.

FlyTerminal's HEX monitor shows live TX/RX with direction markers alongside the normal session, so you can switch views without reconnecting — which matters, because reopening a console port can reset state you were trying to observe.

FAQ

Do I need special hardware?

No. A HEX monitor reads the same bytes your terminal already receives. A logic analyser or an RS-485 sniffer is for problems between two other devices — different job.

Can I monitor bytes while still typing normally?

With a client that keeps the HEX view alongside the session, yes. That is the useful configuration; switching modes mid-session usually means losing the connection.

Why do the bytes look right but my parser fails?

Line endings. Check whether the device sends 0D 0A, bare 0A, or 0D. The HEX view shows this immediately; the text view hides it.

Does this work over RS-485 multi-drop?

Yes, with the caveat that you are one node on the bus. You will see all traffic, including responses to other devices — useful, but expect noise.