CAN Bus — Controller Area Network

CAN, Controller Area Network, is a robust multi-master bus created for automotive electronics and now used in vehicles, machines, robotics, medical equipment, industrial controllers, and battery systems. It combines differential physical signaling with hardware-level message arbitration and error handling.

Learning Objectives

By the end of this lesson, you should be able to:

explain CAN as a broadcast message bus, not an address-based device bus;
describe dominant and recessive states on CAN-H and CAN-L;
understand non-destructive arbitration using message identifiers;
identify the major fields in a classic CAN frame;
debug termination, bit rate, ACK, bus-off, and higher-layer protocol issues.

Message-Based Communication

CAN nodes do not send messages to device addresses. A node broadcasts a frame with an identifier. Every node receives the frame and decides whether that identifier matters.

flowchart LR classDef node fill:#dbeafe,stroke:#2563eb,color:#1e3a5f classDef bus fill:#dcfce7,stroke:#16a34a,color:#14532d ECU["Engine ECU\nID 0x100 RPM"]:::node ABS["ABS module\nID 0x200 wheel speed"]:::node DASH["Dashboard\nsubscribes to IDs"]:::node BMS["Battery system\nID 0x300 voltage"]:::node BUS["CAN-H / CAN-L bus"]:::bus ECU <--> BUS ABS <--> BUS DASH <--> BUS BMS <--> BUS

This publish-subscribe model lets new nodes listen without changing existing wiring.

Dominant and Recessive States

CAN uses a differential pair. In classic high-speed CAN, recessive means both wires sit near the same common-mode voltage. Dominant means the transceiver drives CAN-H higher and CAN-L lower.

Bus state	Logic	CAN-H typical	CAN-L typical	Differential
Recessive	`1`	about `2.5 V`	about `2.5 V`	about `0 V`
Dominant	`0`	about `3.5 V`	about `1.5 V`	about `2 V`

Dominant 0 wins over recessive 1. This is the electrical foundation of CAN arbitration.

Bus Topology and Termination

CAN uses a daisy-chain bus with termination at both physical ends.

flowchart LR classDef node fill:#dbeafe,stroke:#2563eb,color:#1e3a5f classDef term fill:#fef9c3,stroke:#ca8a04,color:#713f12 T1["120 ohm"]:::term N1["Node 1"]:::node N2["Node 2"]:::node N3["Node 3"]:::node T2["120 ohm"]:::term T1 --- N1 --- N2 --- N3 --- T2

With power off, many complete CAN buses measure about 60 ohm between CAN-H and CAN-L because two 120 ohm terminators are in parallel. This is a useful commissioning check, but remove or isolate powered electronics if the equipment manual requires it.

Classic CAN Frame

A standard 11-bit identifier CAN data frame contains:

Field	Size	Purpose
SOF	1 bit	dominant start of frame
Identifier	11 bits	message meaning and priority
RTR	1 bit	data frame or remote request
IDE	1 bit	standard or extended ID format
DLC	4 bits	number of data bytes
Data	0 to 8 bytes	payload in classic CAN
CRC	15 bits plus delimiter	error detection
ACK	2 bits	receivers acknowledge valid frame
EOF	7 bits	end of frame

Extended CAN uses a 29-bit identifier. CAN FD keeps arbitration compatible but allows a faster data phase and up to 64 data bytes.

Arbitration: Lower ID Wins

If two nodes begin transmitting at the same time, they monitor the bus while sending the identifier. A node that sends recessive 1 but reads dominant 0 loses arbitration and stops transmitting. The winning frame continues without corruption.

sequenceDiagram participant A as Node A ID 0x100 participant B as Bus participant C as Node C ID 0x200 A->>B: sends ID bit 0 dominant C->>B: sends ID bit 0 dominant Note over A,C: both still active A->>B: sends next bit dominant C->>B: sends next bit recessive B-->>C: bus is dominant Note over C: loses arbitration and waits A->>B: completes frame

Lower numeric identifier means higher priority because the first dominant bit wins.

Error Handling

CAN controllers check frames in hardware:

CRC detects corrupted bits.
Bit monitoring detects when transmitted and observed bus levels disagree.
Bit stuffing rules detect illegal long runs.
Frame checks validate fixed-format fields.
ACK checks prove at least one other node received the frame.

Nodes maintain transmit and receive error counters. A badly failing node can enter bus-off state and stop transmitting, preventing it from continuously damaging the network.

Speeds and Cable Length

Bit rate	Typical use	Distance guidance
1 Mbps	automotive, short machines	about 40 m or less
500 kbps	common vehicle networks	about 100 m
250 kbps	heavy vehicles, equipment	about 250 m
125 kbps	building or long machines	about 500 m

Exact limits depend on cable, topology, transceivers, oscillator tolerance, and bit timing settings. All nodes on one classic CAN segment must use the same nominal bit rate and compatible sample point.

CAN Controller and Transceiver

Many MCUs include a CAN controller, but they still need an external transceiver for the bus.

flowchart LR MCU["MCU\nCAN controller\nTXD and RXD"] TR["CAN transceiver\nTJA1050, MCP2551,\nSN65HVD230 class"] BUS["CAN-H / CAN-L"] MCU -->|"TXD"| TR TR -->|"RXD"| MCU TR <--> BUS

The controller builds frames, arbitration, CRC, ACK handling, filters, and error counters. The transceiver drives the differential bus and protects the MCU from cable electrical conditions within its rating.

Higher-Layer Protocols

CAN defines transport of frames, not the meaning of payload bytes. Common higher-layer protocols include:

Protocol	Typical domain
OBD-II over ISO 15765	vehicle diagnostics
SAE J1939	trucks and heavy equipment
CANopen	industrial automation
DeviceNet	factory automation
UAVCAN / Cyphal	robotics and vehicles

When debugging, separate CAN-layer health from protocol-layer interpretation.

Practical Checks

Measure about 60 ohm between CAN-H and CAN-L on an unpowered correctly terminated bus.
Confirm only the two physical ends have 120 ohm termination.
Keep stubs short, especially at high bit rates.
Match bit rate and sample point across all nodes.
Check transceiver supply voltage and standby/silent-mode pins.
Verify the bus has at least two active nodes; a lone transmitter usually sees ACK errors.
Read controller error counters before clearing faults.

Common Mistakes

Treating CAN IDs as destination addresses instead of message labels and priorities.
Using the same ID for unrelated messages.
Forgetting that lower numeric ID has higher priority.
Testing one node alone and misreading ACK errors as wiring failure.
Installing one or three terminators instead of two.
Mixing CAN-H and CAN-L.
Debugging J1939, CANopen, or OBD-II payloads before confirming raw CAN frames are healthy.

Summary

CAN is a differential, multi-master, message-broadcast bus with built-in arbitration and error handling. Its reliability comes from dominant/recessive signaling, priority by identifier, hardware CRC and ACK checks, bus-off behavior, correct termination, and disciplined bit timing. Higher-layer protocols give meaning to the payload bytes.

Mind Map

mindmap root((CAN Bus)) Core concept Broadcast messages Identifier is priority Multi master Hardware arbitration Electrical CAN H and CAN L Recessive logic 1 Dominant logic 0 Two 120 ohm ends 60 ohm power off check Frame fields SOF 11 or 29 bit ID DLC and data CRC ACK Calculations Lower ID wins Classic data up to 8 bytes CAN FD up to 64 bytes Speed limits cable length Practical checks Match bit rate Keep short stubs Read error counters Need ACK node Check standby pins Common mistakes ID as address Duplicate message IDs Wrong termination H L swapped Protocol before physical debug