The Framing Tax on Every UART Byte

Ada re-derives this chapter’s own numbers step by step, at full precision

ADA · CALCULATION AUDIT

The Framing Tax on Every UART Byte

The chapter’s UART Data Rate Calculator notes that GPS modules typically use 9600 8N1, moving 960 bytes/sec — a figure quoted as if the baud rate and the data rate were the same thing. This audit asks the question that quiet substitution invites: once every 8N1 frame’s start and stop bits are counted, how much of that 9600 baud link is actually payload, and what happens to that fraction if a parity bit and a second stop bit are added?

Companion to the chapter Sensor Communication Protocols — every number here comes from that chapter.

Ada: The calculator note says a GPS module at 9600 8N1 moves 960 bytes per second. That number is exact, and it quietly exposes how much of a UART wire never carries data. Let me count the bits.

• One 8N1 frame wraps 8 data bits in 1 start + 1 stop bit: 1 + 8 + 0 + 1 = 10 bits/frame.
• Throughput: 9600 / 10 = 960 bytes/second – the calculator’s figure, confirmed.
• Payload efficiency: 8 / 10 = 80%; the other 2 / 10 = 20% is framing the wire pays on every single byte.
• Add parity and a second stop bit (8E2): 1 + 8 + 1 + 2 = 12 bits/frame, so 9600 / 12 = 800 bytes/second and efficiency falls to 8 / 12 = 66.7%.

The framing bits are the price of being asynchronous: with no shared clock, each byte must announce its own start and end, so at least 2 bits per frame are overhead that no baud-rate increase can recover. That is why UART trades throughput for wiring simplicity – choosing 8N1 over 8E2 is really choosing 20% overhead over 33% before one payload bit is sent, and it is why a “9600 baud” link is only ever a 960 byte/second link.

Every number above is taken from the chapter’s own material and re-derived step by step.