Understanding CAN Communication in Modern Vehicles

A modern car has dozens of electronic control units (ECUs) — engine, gearbox, brakes, airbags, body, instruments — and they all need to share information many times per second. Running a dedicated wire between every pair would need kilometres of copper. Instead, most of them share a single twisted pair of wires using CAN, the Controller Area Network.

Why cars use CAN

CAN was developed by Bosch in the 1980s and is standardised as ISO 11898. It solved three problems at once:

• Wiring: every ECU connects to the same two wires, so adding a node doesn't mean adding a harness.
• Priority: any node can talk whenever the bus is free, and if two start at once the more important message wins automatically — without being corrupted.
• Robustness: differential signalling rejects electrical noise, and built-in error detection lets faulty nodes take themselves offline.

CAN has no master and no addresses. Messages are broadcast; each one carries an identifier that says what the data is (say, "engine speed"), and every node decides for itself whether to use it.

The physical layer: two wires, two states

High-speed CAN uses two wires called CAN_H and CAN_L, twisted together. A transceiver chip (for example the TJA1050 or MCP2551) sits between each controller and the bus.

The bus has only two states:

• Recessive (logic 1): nobody drives the bus. Both wires float at about 2.5 V, so the difference is ~0 V.
• Dominant (logic 0): a transceiver pulls CAN_H up to about 3.5 V and CAN_L down to about 1.5 V — a difference of roughly 2 V.

The crucial property: dominant always beats recessive. If one node sends a 1 and another sends a 0 at the same moment, the bus shows 0. It's a wired-AND, and the whole arbitration scheme depends on it.

The two 120 Ω resistors match the cable's characteristic impedance so that signals don't reflect off the ends. With the bus powered off, measuring between CAN_H and CAN_L should show about 60 Ω (two 120 Ω in parallel) — one of the most useful checks you can make.

Anatomy of a CAN frame

A classic CAN data frame with a standard 11-bit identifier looks like this:

Notice what's missing: there is no destination address. The identifier describes the content. Several ECUs can listen to the same engine-speed message, and receivers usually configure hardware filters so their CPU only sees the IDs it cares about.

The ACK slot is also clever: it only tells the sender that at least one node received the frame correctly — not which one. A node alone on a bus will never see an ACK, which is a classic bench-test surprise.

Arbitration: how priorities work without collisions

Any node may start transmitting when the bus has been idle. If two start in the same bit time, they resolve it while sending the identifier, bit by bit:

1. Each transmitter reads the bus back while it sends.
2. As long as what it reads matches what it sent, it carries on.
3. If it sends a recessive 1 but reads a dominant 0, someone with a lower ID is also transmitting. It stops immediately and becomes a receiver.

Because the winner's frame is never damaged, no bandwidth is wasted — this is called non-destructive bitwise arbitration. The loser simply retries when the bus goes idle. System designers assign low IDs to safety-critical, time-sensitive messages (brakes, engine torque) and high IDs to things that can wait (cabin temperature).

Bit stuffing and timing

CAN has no separate clock line. Receivers resynchronise on edges (recessive-to-dominant transitions). To guarantee there are enough edges, the transmitter inserts an opposite bit after every five identical bits in a row; receivers remove it automatically. This is bit stuffing. It's why a frame on the wire can be a few bits longer than the table above suggests, and why six identical bits in a row inside a frame is itself an error.

Common bit rates are 125 kbit/s and 250 kbit/s for body and comfort networks and 500 kbit/s for powertrain; classic CAN tops out at 1 Mbit/s. Every node on one bus must use the same rate. Higher rates require shorter buses, because a bit must reach the far end and come back within one bit time for arbitration and ACK to work.

Error handling: how CAN stays reliable

Every node checks every frame, and five kinds of error are detected:

• Bit error — a transmitter reads back a different level than it sent (outside arbitration and the ACK slot).
• Stuff error — six identical consecutive bits.
• CRC error — the calculated checksum doesn't match.
• Form error — a fixed-format field (like a delimiter or EOF) has the wrong value.
• ACK error — the transmitter sees no dominant bit in the ACK slot.

A node that detects an error sends an error frame: six dominant bits that deliberately break the stuffing rule, so every other node discards the frame too. The sender retransmits automatically.

To keep one faulty node from jamming the bus, each controller keeps two counters — a transmit error counter (TEC) and receive error counter (REC). Errors increase them; successful frames slowly decrease them.

Real-world debugging

When a CAN network misbehaves, work from the wires upwards:

1. Power off, measure resistance between CAN_H and CAN_L. ~60 Ω is correct. ~120 Ω means one terminator is missing; ~40 Ω or lower means too many.
2. Power on, measure DC. With an idle bus both lines should sit near 2.5 V relative to ground.
3. Look with a scope. Probe CAN_H and CAN_L against ground, or use a math channel for the difference. Rounded edges and ringing point to termination or stub-length problems.
4. Check the bit rate. A node at the wrong speed will see nothing but errors — and may cause errors for everyone else.
5. Check for an ACK. If you're testing a single module on the bench, it needs at least one other active node to acknowledge its frames.

On a Linux machine (or a Raspberry Pi with an MCP2515 interface), SocketCAN and the can-utils package make the bus visible:

# bring the interface up at 500 kbit/s
                sudo ip link set can0 up type can bitrate 500000

                # print every frame on the bus
                candump can0

                # send one frame: ID 0x123, 4 data bytes
                cansend can0 123#DEADBEEF

                # show error counters and bus state
                ip -details -statistics link show can0

In a car, the OBD-II diagnostic port exposes a CAN bus on pin 6 (CAN_H) and pin 14 (CAN_L) for vehicles that use CAN for diagnostics. Only listen on a vehicle bus unless you know exactly what you're sending.

Beyond classic CAN

CAN FD (Flexible Data-rate) keeps the same arbitration but allows up to 64 bytes of data per frame and switches to a faster bit rate for the data phase. It's increasingly common in newer vehicles where software updates and sensor data need more bandwidth. Above CAN, higher-level protocols such as ISO-TP and UDS add multi-frame messages and diagnostic services.

Summary

• CAN is a broadcast bus on a twisted pair, terminated with 120 Ω at each end (≈60 Ω measured).
• Dominant (0) overrides recessive (1), which enables lossless priority arbitration — lower ID wins.
• Frames carry an ID, up to 8 data bytes (64 in CAN FD), a CRC and an ACK slot.
• Bit stuffing, five error checks and error counters keep the bus reliable and isolate faulty nodes.