UART¶

This page teaches why a UART byte decode must keep the framing hypothesis that produced it: idle polarity, baud rate, data bits, parity, stop bits, and sampling phase.

A Concrete Artifact¶

# synthetic UART 8E1 frame for byte 0x55, LSB first
0 1 0 1 0 1 0 1 0 0 1

Synthetic offline sample for explanation; not a real operational trace or live-system instruction.

Inspection Trap¶

A stable-looking byte stream can be a framing artifact. The bit sequence in this page decodes to 0x55 only under the stated idle-high 8E1 assumption. A passive observer should keep the framing hypothesis attached to the byte instead of treating the byte as context-free evidence.

UART framing can produce candidate bytes. Another protocol, text convention, or device-specific byte format must explain what those bytes mean.

Worked Decode¶

1. The first 0 is interpreted as a start bit only under an idle-high UART assumption.
2. The next eight sampled bits are 1 0 1 0 1 0 1 0 in time order. UART commonly sends the least-significant bit first, yielding 0x55.
3. The parity bit is 0; because 0x55 has four one bits, even parity remains satisfied.
4. The final 1 is a stop bit. If the receiver expected two stop bits, different parity, or a different baud rate, the same trace would be judged differently.
5. A UART byte is not simply seen; it is reconstructed under a timing hypothesis. Preserve the baud rate, idle polarity, data-bit count, parity, stop bits, and sampling phase with every decoded byte.

What The Evidence Supports¶

Under the stated idle-high 8E1 assumption, the synthetic bit sequence can be read as one UART character carrying 0x55. The parity bit is consistent with even parity for that byte, and the final high bit is consistent with one stop bit under the same timing assumption.

A passive observer can preserve this as a bounded decode: candidate byte 0x55, produced under a stated framing configuration and sampling hypothesis. Keep the byte as a configuration hypothesis until higher-layer context explains the stream. Readers should preserve the baud rate with the byte-level result, not only the hex value.

What The Evidence Does Not Support¶

The artifact does not prove the true baud rate, endpoint intent, byte-stream protocol, ASCII meaning, engineering value, device state, or electrical compliance. A different baud, parity, stop-bit, polarity, or sampling-phase assumption could produce a different decode or make this one invalid.

A valid parity bit supports one-character framing integrity under the chosen parity assumption. It does not prove the application protocol or the meaning of the byte stream.

Field Layout / Anatomy¶

Visual Model¶

idle high
   ┌──────┐      ┌──────┐      ┌──────┐            ┌────── stop
───┘      └──────┘      └──────┘      └──── ... ───┘
    start   b0     b1     b2     ...    parity
      ^      ^      ^      ^
      sample near inferred bit centers under the baud-rate hypothesis

Timing And Authority¶

UART authority is mostly prior agreement, not negotiation. The transmitter and receiver must already share framing parameters, and a passive observer must infer or preserve those parameters with each decoded byte.

UART framing explains candidate bytes. It does not explain the byte stream's application meaning. ASCII, NMEA sentences, Modbus RTU, device-specific packet formats, or another higher-layer convention would be the semantic authority.

Failure And Ambiguity¶

• UART decodes are configuration hypotheses rather than guaranteed truths.
• A passive observer may not initially know baud rate, parity configuration, stop-bit count, bit ordering, voltage convention, idle state, or sampling phase.
• Wrong baud rate can produce stable-looking but false bytes.
• Wrong parity or stop-bit assumptions can make a valid stream look corrupt.
• A partial capture can start mid-character and shift every subsequent interpretation.
• Many apparently valid decodes are framing mistakes that accidentally produce plausible ASCII or binary output.
• Voltage-layer confusion can invert or clip the waveform before byte decoding begins.
• ASCII-looking bytes do not prove the application protocol or command semantics.

Python Model¶

The current package exposes a concrete framing example:

"""Runnable UART framing example for the schoolbus binder."""

from schoolbus.protocols.uart import UartFraming

framing = UartFraming(data_bits=8, parity="even", stop_bits=1)
bits = framing.encode_byte(0x55)

print(framing.show_fields())
print(bits)
print(framing.decode_bits(bits))
print(framing.explain())

The model records framing configuration with the byte so explanations do not detach value from timing assumptions.

The first workbook sample pack includes a passive synthetic UART fixture under samples/first-workbook/ that decodes a sampled bit sequence only under an explicit framing hypothesis.

The bit string is synthetic and assumes idle-high 8E1 framing. The page avoids electrical-compliance claims, autobaud algorithms, metastability analysis, and vendor-specific UART peripheral behavior.

Source Notes¶

References¶

Public Sources¶

• Vendor technical references
• UART / USART vendor documentation collection — vendor technical reference for a de facto framing convention.
• Tooling references
• pyserial — Serial port IO.
• sigrok / PulseView — Logic analyzer acquisition and decoders.

Project posture is aggregated in the protocol support policy, source policy, and project charter.