CAN frame structure: what travels on the bus

A Controller Area Network is a broadcast bus. Every node is connected to the same twisted pair, CAN_H and CAN_L, and there is no addressing in the classic sense: every frame is visible to every node, and each receiver decides locally whether the identifier is of interest. The bus uses two states, dominant (logic 0, a differential voltage) and recessive (logic 1, no differential drive). A dominant bit always overrides a recessive one, which is the physical basis of both arbitration and acknowledgment. Typical termination is 120 ohms at each end, and classic CAN usually runs between 125 kbit/s and 1 Mbit/s depending on cable length.

A data frame starts with a single dominant SOF bit that synchronises all receivers. The arbitration field follows: an 11-bit identifier (or 29 bits for an extended frame, split into a base ID and an extension) plus the RTR bit that distinguishes a data frame from a remote frame. The control field carries IDE, a reserved bit and the DLC, the Data Length Code. In classic CAN the DLC directly encodes 0 to 8 payload bytes; CAN FD uses the same field as an index into a table that reaches 64 bytes. Bit stuffing inserts a complementary bit after five consecutive equal bits so that receivers keep their clocks aligned, and it applies from SOF through the CRC sequence.

Reading a frame from SOF to EOF

After the payload comes a 15-bit CRC (17 bits in CAN FD), a recessive CRC delimiter, and the ACK slot. The transmitter sends the ACK slot as recessive; any node that received the frame correctly pulls it dominant, so the transmitter knows at least one listener understood the frame without knowing which one. EOF is seven recessive bits, followed by a short intermission before the next frame can start. When two nodes transmit at the same time, both watch the bus while sending their identifiers: the first position where one sends recessive and the other dominant decides the winner, and the loser immediately becomes a receiver. This is non-destructive arbitration — the winning frame is never corrupted, so bus bandwidth is not wasted on collisions.

Errors are handled in hardware. A node that detects a bit error, stuff error, CRC error or form error transmits an error frame and increments its counters; repeated problems move a node from error-active to error-passive and finally to bus-off. This is why a single badly terminated cable or a mismatched bit rate can look like 'random missing messages' rather than a clean failure. The frame itself carries no names, units or scaling — only an identifier and up to eight raw bytes. Turning those bytes into engineering values is exactly what a DBC database does, and it is the next topic in this series.

Fields at a glance

• SOF — one dominant bit, start of frame and hard synchronisation
• Arbitration — 11-bit or 29-bit identifier plus RTR; lower identifier wins
• Control — IDE, reserved bit, DLC (0–8 bytes in classic CAN)
• Data — the raw payload bytes that a DBC file describes
• CRC — 15-bit checksum plus delimiter
• ACK — receivers pull the slot dominant; EOF and intermission close the frame

Step through the fields of a classic CAN data frame

From raw bytes to signals

ID 0x1F0  DLC 8  DATA 12 34 00 7A 00 00 00 00
         ^^^^ DBC SG_ lines say which bits mean what

In practice you rarely decode a frame by hand. You load a DBC file, select the message that matches the identifier, and let the tool apply start bit, length, byte order, signedness, factor and offset to every signal. Understanding the frame layout still pays off: it explains why a wrong bit rate produces no frames at all, why an 8-byte DLC is a hard limit in classic CAN, and why two signals in the same message can overlap without the bus noticing. The tool cannot detect a semantic mistake in the database; it can only show you what the file describes.