SCADA Protocols
  • Articles
  • Protocols
  • Tools
  • Categories
  • About
  • Contact
Open tools
All articles
Details
Published
Aug 13, 2026
Updated
Aug 13, 2026
Reading
11 min · 2,093 words
Protocol
can
HomeArticlesCAN & CANopenCAN Bus Protocol Explained: Frames, Arbitration, Errors
All articles
CAN

CAN Bus Protocol Explained: Frames, Arbitration, Errors

CAN bus protocol explained from the standards: dominant and recessive bits, identifier arbitration, the five frame formats, error states and bus-off, CAN FD and CAN XL.

Published Aug 13, 2026Updated Aug 13, 202611 min · 2,093 words
CBFF
CEFF
FBFF
FEFF
XLFF
dominant recessive
bit stuffing
error frame
bus-off
fault confinement
ISO 11898-1
ISO 11898-2
☰Table of contents
On this page
  • Dominant and recessive: the whole protocol rests here
  • Arbitration: how collisions resolve without collisions
  • Message labels, not node addresses
  • The frame formats
  • Bit stuffing, and why it exists
  • Error handling and fault confinement
  • The physical layer
  • Where CAN stops and other protocols begin
  • FAQ

Key takeaways

  • 1CAN bus protocol explained from the standards: dominant and recessive bits, identifier arbitration, the five frame formats, error states and bus-off, CAN FD and CAN XL.
  • 2Focus protocol: CAN — browse related articles and references on the topic page.
  • 3Related topics: CBFF, CEFF, FBFF, FEFF.

This article is part of the CAN & CANopen family. For sibling coverage of the physical layer, see CAN Bus Wiring and Termination. For the full protocol family landing with links to CANopen, J1939, and DeviceNet, visit the CAN & CANopen category hub.

CAN is two wires, no master, no addresses, and no collisions — despite every node being free to start talking whenever the bus is quiet. That combination is why a protocol designed for 1980s vehicles now runs machine automation, off-highway equipment, medical devices, and industrial drives.

The trick is that CAN doesn't address messages to nodes. It labels messages by content, broadcasts them to everyone, and resolves simultaneous transmissions without anyone losing data. Once that clicks, the rest of the protocol follows.

This guide covers how CAN actually works: the electrical basis, arbitration, the frame formats including CAN FD and CAN XL, and the error handling that quietly removes broken nodes from the bus. Verified against ISO 11898-1 and ISO 11898-2.

Dominant and recessive: the whole protocol rests here

CAN signals on a differential pair, CAN_H and CAN_L, in two states:

Dominant is logical 0. The transmitter actively drives a differential voltage — nominally 2.0 V, with CAN_H around 3.5 V and CAN_L around 1.5 V on a normal 50–65 Ω bus load.

Recessive is logical 1. Nothing is driven. Both lines sit at roughly 2.5 V and the differential voltage is essentially zero.

The asymmetry is the point. If one node transmits dominant while another transmits recessive, the bus goes dominant. Zero wins. Everything else — arbitration, acknowledgment, error signalling — is built on that single electrical fact.

When no transmission is in progress the bus is idle and sits recessive. A node considers the bus idle after seeing 11 consecutive recessive bits.

Arbitration: how collisions resolve without collisions

Every node may start transmitting when the bus is idle — CAN is genuinely multi-master. When two start at once, this is what happens.

Each frame begins with an identifier, and the identifier is the priority. As each node transmits its identifier bit by bit, it simultaneously monitors the bus. A node transmitting recessive that reads back dominant knows another node is sending a lower-numbered identifier. It stops transmitting immediately and becomes a receiver.

The standard calls this identifier-based arbitration or, more formally, carrier sense multiple access with collision resolution. Note the last word: not collision detection, not collision avoidance. The collision resolves itself.

Three consequences fall out of this:

The winner loses nothing. The higher-priority frame continues uninterrupted. No backoff, no retransmission, no bandwidth wasted. Compare this with Ethernet's historical CSMA/CD, where a collision destroyed both frames.

Lower identifier means higher priority. A frame with identifier 0x001 beats 0x100 every time. This makes identifier assignment a genuine design activity — you are allocating bus priority, permanently, in your ID map.

Low-priority frames can starve. On a heavily loaded bus, a high-numbered identifier may wait a long time. Bus load planning isn't optional on CAN.

The loser doesn't discard its frame. It becomes a receiver, waits for the bus to go idle, and tries again.

Message labels, not node addresses

CAN frames carry no source address and no destination address. The identifier labels the content — "engine speed," "hydraulic pressure" — not a recipient.

Every frame reaches every node. Each node decides for itself what to keep, using acceptance filtering on the identifier. This gives CAN properties that address-based protocols have to work for: multicast is native, broadcast is just multicast to everyone, and adding a listener requires no change to the transmitter. A new node subscribing to engine speed simply configures its filter. Nobody else needs to know it exists.

The standard names this information routing and network flexibility, and it's the main reason CAN networks tolerate incremental extension so well.

The frame formats

This is where the modern standard gets more interesting than most explanations admit. ISO 11898-1 defines five frame formats across three generations.

FormatIdentifierDataBit rate
CBFF — Classic base11-bit≤ 8 bytesSingle
CEFF — Classic extended29-bit≤ 8 bytesSingle
FBFF — FD base11-bitUp to 64 bytesSwitchable
FEFF — FD extended29-bitUp to 64 bytesSwitchable
XLFF — XL11-bitUp to 2048 bytesSwitched

Classic CAN (CBFF/CEFF) is what most people mean by "CAN." One bit rate for the whole frame, eight data bytes maximum. The 11-bit and 29-bit variants are the base and extended identifier formats.

CAN FD (FBFF/FEFF) adds flexible data rate: the frame switches to a faster bit rate for the data phase, then back for acknowledgment. Arbitration still happens at the slower nominal rate — it has to, since arbitration depends on every node hearing every bit within one bit time. The standard is explicit about the two timings: nominal bit time in the arbitration phase, data bit time in the data phase.

CAN XL is the newest tier, added in the 2024 edition, and it changes the scale: up to 2048 data bytes in one frame, with the bit rate switched at the beginning and end of the data phase. The XL frame also carries fields the earlier formats don't — a service data unit type and a virtual CAN channel identifier — which let higher-layer protocols identify themselves inside the frame.

Beyond data frames, three other frame types exist: the remote frame, which requests that another node transmit a particular data frame; the error frame, signalling a detected error condition; and the overload frame, signalling that a receiver needs more time.

The compatibility trap

The standard lists five implementation options for a CAN controller, and buried in a note is the interoperability rule that catches people out:

A classic-only controller that is not FD-tolerant will generate error frames when FD traffic appears on the bus. Not silence — error frames, actively disrupting communication. And the standard states plainly that nodes supporting the full classic + FD + XL set can communicate with all other nodes, which is why it recommends that combination for new designs.

The practical rule: mixing generations on one bus works only if the older nodes are explicitly tolerant of the newer frame formats. "It ignores what it doesn't understand" is an assumption worth verifying in the datasheet, not one to make.

Bit stuffing, and why it exists

CAN encodes bits as non-return-to-zero: within a bit time, the level doesn't change. A long run of identical bits therefore produces no edges — and receivers need edges to stay synchronized with the transmitter's clock.

Bit stuffing solves it. After five consecutive bits of the same value, the transmitter inserts one bit of opposite polarity. Receivers remove them. The standard defines two flavors — dynamic bit stuffing (the classic rule) and fixed bit stuffing, used in the faster formats — and CAN FD and XL frames also carry a stuff bit count so receivers can verify how many were inserted.

Two side effects worth knowing. Frame duration is variable, because stuff bits depend on the data pattern — so a "worst case" CAN frame is longer than the nominal calculation. And a stuff error, five bits followed by a sixth of the same value where a stuffed bit belonged, is one of the protocol's error detection mechanisms.

Error handling and fault confinement

CAN's error handling is the part most protocols don't have, and it's why a CAN bus survives a failing node.

Every node maintains error counters. Detect an error, the counter increases; transmit or receive successfully, it decreases. The counters drive three states:

Error-active. Normal operation. The node participates fully and signals detected errors with active error frames.

Error-passive. Too many errors accumulated. The node still communicates, but its error signalling is passive — it can no longer disturb other nodes' traffic. This is the protocol quietly reducing a suspect node's influence.

Bus-off. The node has failed too many times and, in the standard's words, does not influence the bus at all. It stops transmitting entirely. A bus-off node can recover, but only after seeing the bus idle for a defined period.

That progression is fault confinement, and it's the answer to a question every field engineer eventually asks: why does one broken device not take down the whole network? Because CAN measures its own errors and escalates a bad node out of the conversation before it can.

Error detection itself runs on several mechanisms working together: CRC on every frame, form checks on fixed-format fields, stuff-rule checking, bit monitoring (a transmitter comparing what it sent against what the bus shows), and acknowledgment checking. Between them, undetected error probability is extremely low — which is why CAN ended up in safety-related systems it was never originally designed for.

The physical layer

ISO 11898-2 specifies the high-speed medium attachment — the transceiver side. The numbers that matter in the field:

ParameterValue
Dominant differential voltage1.5 to 3.0 V (nominal 2.0 V)
Dominant CAN_H / CAN_L~3.5 V / ~1.5 V nominal
Recessive differential voltage~0 V, both lines ~2.5 V
Receiver dominant threshold0.9 V minimum differential
Receiver recessive threshold0.5 V maximum differential
Common mode range±12 V
Test bus load60 Ω (two 120 Ω terminators in parallel)
Transceiver loop delay255 ns maximum
Bit rate tiers1 Mbit/s; optional 2 Mbit/s and 5 Mbit/s for FD

One nuance that surprises people: the cable and connectors are out of scope of ISO 11898-2. The standard specifies the transceiver, not the medium — the physical media dependent sublayer is explicitly excluded. The familiar 120 Ω termination at each end appears implicitly, through the 60 Ω effective bus load used throughout the transceiver test conditions. Cable specifics come from the higher-layer protocol or the equipment vendor.

The 2016 edition also absorbed two older parts of the series, ISO 11898-5 and ISO 11898-6, so low-power mode and selective wake-up now live in one document alongside the base transceiver requirements.

Where CAN stops and other protocols begin

Read the scope of ISO 11898 carefully and you find a deliberate gap: the OSI layers above the data link layer are not specified. CAN gives you frames, arbitration, and error handling. It says nothing about what an identifier means, how to configure a device, how to transfer more data than fits in one frame, or how to manage a network's state.

That gap is filled by higher-layer protocols, and which one you meet depends on the industry:

CANopen — machine automation, motion control, medical. Adds an object dictionary, standardized device profiles, process and service data objects, and network management.

J1939 — trucks, off-highway equipment, gensets. Adds parameter group numbers, suspect parameter numbers, address claiming, and transport for multi-frame messages.

DeviceNet — industrial device-level networks, built on the CIP object model, with bus power on the same cable.

Each takes CAN's frames and imposes meaning on the identifiers. When someone says a device "speaks CAN," the useful follow-up question is always: which higher-layer protocol?

FAQ

Is CAN a master-slave protocol? No. CAN is multi-master — any node may begin transmitting when the bus is idle. Some higher-layer protocols layer a master role on top (CANopen has an NMT master), but the CAN protocol itself has no master.

How does CAN avoid collisions? It doesn't avoid them, it resolves them. Simultaneous transmissions arbitrate bit by bit on the identifier, dominant overwriting recessive, and the lower identifier wins while continuing without interruption. The loser reverts to receiving and retries later.

What is the difference between CAN and CAN FD? CAN FD adds a switchable data-phase bit rate and larger payloads — up to 64 bytes versus 8. Arbitration still runs at the slower nominal rate. Classic controllers that aren't FD-tolerant will generate error frames on an FD bus.

What is CAN XL? The newest frame format, added in the 2024 edition of ISO 11898-1. It carries up to 2048 data bytes with the bit rate switched around the data phase, and adds fields identifying the higher-layer protocol inside the frame itself.

What does bus-off mean? A node's error counters exceeded the limit and it has removed itself from the bus entirely — it no longer influences the bus. This is fault confinement doing its job: a failing transceiver or a mis-terminated node gets escalated out rather than being allowed to disrupt everyone.

Does CAN use addresses? No. Identifiers label message content, not nodes, and every frame is broadcast. Nodes use acceptance filtering to decide what to process. Node addressing, where it exists, comes from higher-layer protocols like CANopen or J1939.

What bit rate can CAN run? Classic CAN is specified up to 1 Mbit/s at the transceiver. CAN FD adds optional tiers up to 2 Mbit/s and up to 5 Mbit/s for the data phase. Achievable rate depends on bus length and topology — arbitration requires a bit to propagate across the whole bus and back within one bit time, which is what fundamentally links length to speed.

PreviousDeviceNet Explained: CAN, CIP, Power and WiringAug 14, 2026
Next CAN Bus Wiring and Termination: The Complete GuideAug 13, 2026

Related articles

CAN & CANOPEN

CANopen Explained: Object Dictionary, PDO, SDO, NMT

CANopen explained: the object dictionary at the centre of every device, SDO vs PDO, expedited and normal transfers, heartbeat and EMCY, and how device profiles work.

Aug 15, 202614
CAN & CANOPEN

CANopen vs CAN Bus: What's the Difference? (Explained)

CANopen vs CAN bus explained: they are not competitors but two layers of the same stack. What CAN provides, what CANopen adds, and how to tell which one a device speaks.

Aug 15, 20268
On this page
  • Dominant and recessive: the whole protocol rests here
  • Arbitration: how collisions resolve without collisions
  • Message labels, not node addresses
  • The frame formats
  • Bit stuffing, and why it exists
  • Error handling and fault confinement
  • The physical layer
  • Where CAN stops and other protocols begin
  • FAQ
SCADA Protocols

Practical guides, free decoders, and tools for SCADA and industrial protocols, including DNP3, IEC 60870-5, IEC 61850, Modbus, OPC UA, MQTT, and more.

Explore

  • Articles
  • Protocols
  • Tools
  • Categories
  • Tags

Protocols

  • DNP3
  • IEC 60870-5-104
  • IEC 60870-5-101
  • Modbus
  • IEC 61850
  • All Protocols →

Site

  • About
  • Privacy Policy
  • Terms of Service
  • Contact

© 2026 SCADA Protocols. All rights reserved.

Protocol and vendor names are trademarks of their respective owners. Content is for educational reference only.