Today I want to talk about something that has been part of my work for the past few years: the Controller Area Network, or CAN. You have probably heard the term before in the context of your car or motorcycle, but let us dive into it a bit more.

CAN is a protocol created by Bosch in 1983. It was designed for cars, but it has since been adopted far beyond them: industrial machines, medical devices, and even aerospace, satellites and rockets included. The protocol is standardized as ISO 11898.

Why it exists

Before CAN, every new feature in a car meant another pair of wires running point to point between two components. Add a sensor here, a control unit there, and the wiring harness grows into a heavy, expensive, failure prone mess.

CAN replaces all of that with a single shared two wire bus that every node taps into. Instead of wiring each pair of devices together, you connect everyone to the same bus and let them talk over it. Less copper, less weight, fewer connectors to fail.

How it works

A few design choices make CAN what it is.

It is a two wire differential bus. The two lines are called CAN High and CAN Low. A bit is read from the voltage difference between them rather than against ground, which makes the bus very resistant to electrical noise, exactly what you want in a car or on a factory floor. The pair is twisted and terminated with a 120 ohm resistor at each end.

It is message based, not address based. A CAN frame does not say who it is for. It carries an identifier that describes what the data is, for example “engine RPM”. Every node on the bus sees every frame and decides for itself whether it cares, usually with hardware filters so the CPU is never bothered by traffic it does not need.

It is multi master with priority arbitration. Any node can start transmitting when the bus is idle. If two start at the same time, the identifier doubles as a priority. CAN uses dominant (0) and recessive (1) bits, and a dominant bit always wins on the wire. As the nodes send their identifiers bit by bit, the one sending a recessive bit while another sends a dominant bit notices the mismatch and backs off. The lower identifier wins, keeps transmitting without interruption, and the loser simply retries later. Nothing is corrupted, no message is lost to a collision. This is the clever part of CAN.

It is reliable by design. Every frame carries a CRC, receivers acknowledge frames they accept, and any node that sees a problem can raise an error frame so the whole bus discards the message. Nodes also track their own error counters and will take themselves off the bus if they become a persistent source of faults, which keeps one broken device from taking everyone down.

Classic CAN runs at up to 1 Mbit/s, with the achievable speed trading off against bus length.

CAN bus frame definition table

Field Length (bits) Description
Start of frame 1 Denotes the start of frame transmission
Arbitration field 11 Contains the identifier of the message
Control field 6 Contains the length of the data field
Data field 0-64 Contains the data being transmitted
CRC field 15 Contains the cyclic redundancy check for error checking
Acknowledge field 2 Acknowledges the receipt of the message
End of frame 7 Denotes the end of frame transmission
Intermission 3 Delays before the next frame transmission

The 11 bit identifier above is the standard frame format. There is also an extended format with a 29 bit identifier for applications that need more unique message IDs, such as the J1939 protocol used in trucks.

CAN FD

The classic frame tops out at 8 bytes of data, which gets tight for modern systems. CAN FD (Flexible Data rate) is the modern extension: it keeps the same arbitration and wiring but allows up to 64 bytes per frame and a higher bit rate during the data phase. If you are starting something new today, it is usually CAN FD.

It is just the plumbing

Raw CAN only defines how bits and frames move across the wire. It says nothing about what the messages mean. That is left to higher layer protocols built on top of it:

  • OBD-II for vehicle diagnostics, the port your mechanic plugs into.
  • J1939 for heavy duty trucks and buses.
  • CANopen for industrial automation.

Playing with it on Linux

You do not need a car to experiment. Linux has SocketCAN built in, so a cheap USB to CAN adapter is enough to start. You can even create a virtual bus with no hardware at all:

# create a virtual CAN interface
sudo modprobe vcan
sudo ip link add dev vcan0 type vcan
sudo ip link set up vcan0

# watch traffic in one terminal
candump vcan0

# send a frame from another (id 123, 4 data bytes)
cansend vcan0 123#DEADBEEF

From Python, the python-can library wraps the same interfaces and is a nice way to script tests and decoders.

That is the short tour. CAN is old, simple, and everywhere, and once you understand the arbitration trick the rest of it falls into place.

References

This post was written with the help of AI (Claude by Anthropic).