candump / SocketCAN log formats¶

Practical Linux formats for recording and inspecting CAN traffic in offline labs.

Identity¶

Practical Linux formats for recording and inspecting CAN traffic in offline labs.

What This Protocol Teaches¶

• The format is humble, but the lab path is excellent.
• It teaches how to inspect timestamp, interface, CAN ID without mistaking field extraction for meaning.
• It keeps observer inference separate from system truth.

Operational Context¶

candump-style text records appear in Linux CAN tooling contexts and are modeled in the atlas at the capture-format layer. The binder treats one line as passive file evidence: timestamp text, interface label, CAN identifier, and payload bytes. It does not teach bus-operation behavior or complete can-utils behavior.

field-note: this page has limited runnable support for one-line Classical CAN data records. It is not a complete candump parser and is not yet a final-copy binder page.

A Concrete Artifact¶

# synthetic candump line
(1710000000.010000) can0 123#00401f401f000000

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

Worked Decode¶

1. Read the line as one offline candump-style text record.
2. 1710000000.010000 is timestamp evidence and can0 is an interface label captured in text, not a live interface requirement.
3. 123#00401f401f000000 records identifier and payload bytes in compact text form.
4. The line preserves traffic shape, but signal meaning and capture completeness require separate provenance.

Field Layout / Anatomy¶

Visual Model¶

Timing And Authority¶

Timing and authority depend on the log-record role. A file timestamp is evidence from the artifact, not proof of physical bus timing or current machine state. Semantic authority is external: a DBC, PGN/SPN definition, or integration profile is needed before payload bytes become named engineering values.

Bytes rarely explain themselves. Name the source that defines meaning before naming engineering values: standard metadata, label table, DBC, PGN/SPN definition, object dictionary, register map, DID catalog, LDF, ARXML, channel metadata, or vendor profile.

Failure And Ambiguity¶

• The interface label is text provenance, not a requirement or proof of hardware.
• Timestamp precision does not prove clock accuracy.
• Payload bytes remain anonymous without a description authority.

Observer Lesson¶

A passive observer can usually infer artifact boundaries, repeated structure, cadence, missingness, and candidate state transitions. The observer usually cannot prove physical truth, application intent, complete system state, or engineering-unit meaning without semantic authority and timing provenance.

Python Model¶

schoolbus exposes a limited text-record model for one synthetic Classical CAN data line:

"""Runnable candump text-record example for the schoolbus binder."""

from schoolbus.formats.capture import CandumpLogRecord

record = CandumpLogRecord.from_line("(1710000000.010000) can0 123#00401f401f000000")
frame = record.to_can_frame()

print(record.show_fields())
print(record.explain())
print(frame.show_fields())

to_can_frame() preserves only recorded CAN-frame fields. Timestamp, interface label, and semantic authority remain on the log record.

Local Teaching Notes¶

The artifact and diagrams are synthetic teaching material. The page intentionally omits conformance timing tables, electrical design detail, proprietary configuration, and exhaustive standard behavior.

The matching sample pack is samples/capture-description-workbook/. It is a synthetic passive workbook for file-backed inspection, not an operational capture procedure.

Source Confidence¶

Source confidence is high for scope and terminology, with semantic claims limited to public metadata, public source notes, and synthetic teaching artifacts.

Source Notes¶

References¶

Public Sources¶

• linux-can project
• can-utils tooling — tooling documentation.
• Linux kernel
• SocketCAN documentation — kernel-doc.
• Tooling references
• can-utils — CAN capture/log-format context.
• python-can — CAN log inspection and offline lab context.
• cantools — description-file parsing and signal inspection.