Skip to content

Protocol Binder

The binder is the reading layer of schoolbus: one concrete synthetic artifact first, then field decode, timing, authority, ambiguity, and observer reconstruction. It should teach the machine before it teaches the project.

Start with the artifact in front of you. Decode only what the artifact supports, name the authority that made the decode possible, and keep the observer claim bounded.

How To Read A Protocol Page

Strong pages follow one reader route:

  1. See the concrete artifact.
  2. Notice the inspection trap: the false inference the artifact tempts you to make.
  3. Walk the worked decode in evidence order.
  4. Separate field shape from semantic authority.
  5. Ask what the artifact supports, what it does not support, and what a passive observer can safely claim.

The project still tracks sources, safety, maturity, and promotion rules. Those surfaces stay nearby without forcing every reader through the maintainer path: safety and examples, source and standards posture, and support and maturity.

Choose A Maturity Lane

Navigation separates pages by their current teaching status before you open them. Protocol importance does not determine placement; page evidence and runtime posture do.

Lane Reader expectation
Final-copy teaching guides Finished exemplars with a page-specific artifact, worked decode, ambiguity case, source posture, and bounded observer claim.
Draft Core Labs (not final) Protocols on the Core Lab path whose pages still need stronger artifact depth, review, or example support.
Field notes Narrow, useful slices grounded in synthetic capture records; these do not imply broad format or protocol support.
Docs-only references Source-grounded maps with no promised parser or decoder. Use them to orient further research, not as finished teaching guides or claims of current runtime capability.

Every protocol and format page repeats its exact page status, example posture, runtime status, and source posture directly below the title. See support and maturity for the label definitions.

Read In This Order

  1. Inspection ladder
  2. Semantic authority
  3. Timing and cadence
  4. Observer reconstruction
  5. CAN
  6. DBC
  7. CAN FD
  8. LIN
  9. ISO-TP
  10. UDS
  11. OBD-II
  12. UART
  13. Modbus RTU
  14. MIL-STD-1553

Explore By Question

Question Start with
How does priority shape evidence? CAN, CAN FD, J1939
What turns bytes into meaning? DBC, LIN, OBD-II, Modbus RTU
What does timing prove or fail to prove? UART, LIN, NMEA 0183, observer reconstruction
How do multi-frame conversations work? ISO-TP, UDS, MIL-STD-1553
Where are the honest drafts? RS-485, RS-232, RS-422, SOME/IP, AFDX
Where are capture formats? DBC, ASC, candump Log, PCAP / PCAPNG

Start From The Artifact

I have... Reader route
Bytes or a frame payload Use CAN for arbitration and payload opacity, CAN FD for larger payload metadata, LIN for protected identifiers, or Modbus RTU for register-shaped bytes.
A waveform or serial line Start with UART for bit timing and framing, then LIN when break/sync/schedule evidence appears. Keep RS-485 as an electrical draft until the carried byte protocol is identified.
A log or capture record Start with ASC or candump Log when the file already names CAN-like records; use PCAP / PCAPNG as a draft map for packet-capture boundaries and provenance.
A database or description file Use DBC for CAN signal authority, LDF for draft LIN description context, ARXML for AUTOSAR-shaped draft context, or EDS / DCF for CANopen object-dictionary context.
A transaction or request/answer Use ISO-TP for transport reassembly, UDS for observed diagnostic exchanges, OBD-II for regulatory diagnostic views, or MIL-STD-1553 for command/status transactions.
A source-confidence question Read source and standards posture, safety and examples, and support and maturity before treating any decode as source-grounded evidence.

Binder Path

flowchart LR artifact["Concrete artifact"] --> decode["Worked decode"] decode --> anatomy["Field layout / anatomy"] anatomy --> timing["Timing and authority"] timing --> semantics["Semantic authority"] semantics --> ambiguity["Failure and ambiguity"] ambiguity --> observer["Observer state hypothesis"]

Discipline

The binder is not a standards mirror. It paraphrases structure, cites source notes, and avoids reproducing copyrighted standards tables. It is not an operational guide for real buses. Examples are synthetic and passive so readers learn inspection reasoning without receiving instructions to manipulate live systems.

Maintainer material, support tiers, and review rules live under Project Internals. Use the documentation standard, protocol page template, and final page checklist when adding or revising pages.