CAN bus/The message/What a message looks like
Lesson 6 of 12 · in 3D and VR

What a message looks like

A classical CAN message is a strip of fields in a fixed order, from a start bit to an end marker. Its check catches damage by accident and says nothing about meaning.

Lonely BinaryUpdated 2026-10-084 min readNo board required

View it in VR

Lesson 6 of the CAN bus course opens in a VR headset, on a table in front of you, and a voice starts three seconds after you arrive. Type this short address into the browser on a headset such as Meta Quest or Apple Vision Pro, and press Enter VR. No headset? Press Start the lesson: the same lesson, full screen.

learn.lonelybinary.com/vr/can/6

One strip, always in the same order

A classical CAN message is a run of bits in a fixed order. It begins with the start of frame, one loud bit. Then the identifier, eleven bits, which is the label the desks argue about in arbitration, then RTR, IDE and a reserved bit, one each. Then the length, four bits, which says how many bytes of data follow.

The data comes next, from nothing up to eight bytes. After it come the fifteen bit check, a delimiter, the acknowledge slot, another delimiter and seven quiet bits that end the frame. Three quiet bits of gap follow.

The Bosch specification says other length codes may not be used. Later versions of the standard let a classical frame carry codes nine to fifteen, which still mean eight bytes. More only comes with CAN FD, which Bosch introduced in 2012 and which carries up to 64 bytes.

Most of a message is not data

A frame with eight data bytes is 108 bits before stuffing, and 64 of them are the value. A frame with one data byte is 52. Lesson eight adds the stuffed bits on top.

What the check does

The sender works a fifteen bit check over every bit from the start of frame to the end of the data. Each receiver works the same sum over what it got and compares. If a bit changed on the way, the two disagree and the receiver rejects the message.

It is built for accidental damage. It finds every burst of errors shorter than fifteen bits, up to five bit errors anywhere in the frame, and any odd number of them. A very small chance of a damaged message getting through remains.

What it does not do

The check says that this frame arrived as it was sent. It says nothing about whether the value makes sense, is fresh, or came from the device you think. A wheel speed of 999 kilometres an hour with a correctly worked check passes, and so does an old message sent again. CAN has no way to prove who sent a frame.

Common mistakes

  • Thinking a passed check means a good value. It means the frame was not damaged in flight. A sensor that reads wrongly sends a valid message.
  • Expecting more than eight data bytes in a classical frame. Sixty four needs CAN FD, and a controller that only does classical frames reads an FD frame as an error.
  • Counting only the data when working out how long a message takes. The fixed fields and the check are the larger share of a short message.

Edit this page — content/fundamentals/can/what-a-message-looks-like.mdx

Discuss this article

Ask about this page. The answer stays here, on the page it belongs to, for whoever hits the same wall next.

Browse Fundamentals on the forum →