The Framing Tax on Every UART Byte
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.
See the relationship before changing it
The figure reads from left to right. The blue card is bits per uart frame. The middle card applies this page's rule. The green card is payload throughput. Walk the arrows once: set the input, apply the rule, then read the result with its unit.
The retained audit below checks several chapter fixtures. This model keeps those stated values fixed and changes only bits per uart frame, so the numeric fixture does not switch without explanation.
Derive the baseline in four named moves
- 1
Name the input. The chapter baseline is 10 bits/frame.
- 2
Name the relationship. throughput = 9,600 baud / frame bits
- 3
Substitute with units. 9,600 / 10 = 960 bytes/s
- 4
Read the result. Keep the unit beside the value. Use it only inside the technical boundary on this page.
Predict, then change bits per uart frame
Try Predict the direction of throughput = 9,600 baud / frame bits. Test another bits per uart frame, then compare payload throughput.
Observe Extra parity and stop bits spend baud capacity without carrying payload. Reset bits per uart frame to 10 and compare payload throughput.
Explain Extra parity and stop bits spend baud capacity without carrying payload.
Check yourself
What should you do before trusting a moved-control result?
What does this small model leave out?
Frame 8 data bits as 8N1 on a 9600 baud link, then switch the ledger to 8E2 and click Check audit.
The written ledger derives 960 bytes/s at 10 bits/frame and 800 bytes/s at 12 bits/frame, while efficiency drops from 80% to 66.7%.
Each 8E2 UART character spends 4 bits on timing and error framing, so that extra framing consumes baud capacity without carrying payload.
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 other2 / 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, so9600 / 12 = 800 bytes/secondand efficiency falls to8 / 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.
Technical boundaries: The framing quotient excludes inter-frame gaps, software buffering, flow control, clock mismatch, line errors, retries, packet headers above UART, and encoding conventions for multibyte data.