CAN bus/The hall/Labels, not addresses
Lesson 3 of 12 · in 3D and VR

Labels, not addresses

A CAN message does not say who it is for. It carries a label saying what it is, every device hears it, and each device decides for itself whether to use it.

Lonely BinaryUpdated 2026-10-084 min readNo board required

View it in VR

Lesson 3 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/3

A message says what it is

A CAN frame has no destination field. It has an identifier, and the identifier describes the meaning of the data: wheel speed, engine temperature, door state. Every node on the bus receives every frame, and each node decides for itself whether the message is one it uses. The Bosch specification calls that message filtering.

So the sender never knows who is listening. A new device can start using wheel speed without anything changing on the sender, which is why the desks here are named for what they know and not given numbers.

The filter is a list kept by each receiver

In the bench each desk keeps a short list of labels. In a real controller the list is an acceptance filter: a code and a mask, where a one in the mask means that bit of the identifier has to match the code. It is done by the controller hardware, and software only sees the frames that were accepted.

A desk that passes on a message has still heard it: the acknowledgement of a good frame does not depend on the filter.

How big the label is

The standard format has an 11 bit identifier. The extended format has 29 bits, which this course leaves aside. The original Bosch specification says the seven most significant bits must not all be recessive, which reserves the top sixteen standard values, 0x7F0 and above. Many controllers do not enforce it, but plan for 0x000 to 0x7EF.

One label, one sender

Two nodes must never send the same identifier at once. They would both pass arbitration, because their bits are identical up to the end of the identifier. If the frames then differ, the first differing bit is a bit error: the node that sent a one reads a zero, flags an error, and the frame is destroyed and sent again. If the frames are identical and there is no third node, nobody acknowledges, and both see an acknowledgement error. Either way the cost is repeated errors on a bus that looked fine alone.

Common mistakes

  • Putting an address in the identifier and expecting the bus to route it. The bus delivers every frame to every node. Only filtering decides who uses it.
  • Giving two nodes the same identifier. The first differing bit is a bit error, and it repeats.
  • Treating the top of the range as ordinary labels. The original specification reserves the top sixteen values.

Edit this page — content/fundamentals/can/labels-not-addresses.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 →