CAN Bus Protocol: Complete Technical Guide to Controller Area Network (2026)

A modern car can contain well over a hundred electronic control units, and a factory-floor drive cabinet can hold dozens more. Almost none of them are connected with a dedicated wire per signal. Instead they share two twisted wires and a protocol designed in the 1980s that still refuses to die. The CAN bus protocol has outlived FlexRay, survived the arrival of automotive Ethernet and keeps gaining new members (CAN FD, and now CAN XL) because it solves one problem better than anything else at its price: getting small, prioritized, loss-free messages between many cheap microcontrollers on a noisy wire.

That longevity matters in 2026 because the bus is not going away; it is being wrapped. Software-defined vehicles put zonal gateways between CAN segments and Ethernet backbones, machine builders run CANopen and J1939 beside OPC UA, and security teams now ask how a 1980s broadcast bus can authenticate anything. This guide walks the whole stack from first principles: bit-level arbitration, bit timing, fault confinement, the physical layer, the frame generations, the higher-layer protocols, security, gateways, tooling, a worked bus-load calculation and the failure modes that actually bite in the field.

What this covers: the Controller Area Network architecture, why arbitration is lossless, how nodes police themselves, classical CAN versus CAN FD versus CAN XL, J1939, CANopen, ISO-TP and UDS, SecOC, SocketCAN code, and an engineering checklist.

Context and Background

CAN was developed at Bosch in the mid-1980s and presented publicly in 1986; the specification Bosch published as CAN 2.0 in 1991 defined the 11-bit (part A) and 29-bit (part B) identifier formats still used today. The goal was to replace point-to-point harnesses, which were becoming heavy, expensive and unreliable as cars added electronics. Early production use appeared in passenger cars in the early 1990s, and ISO standardized the protocol as ISO 11898 in 1993. Treat those dates as approximate history rather than citable specifics; the standards have been revised many times since.

The current standards family is worth knowing precisely because procurement documents cite it. ISO 11898-1 defines the data link layer and the physical coding sub-layer. ISO 11898-2 defines the high-speed physical layer (the differential transceiver, the 120 ohm bus and the electrical levels). ISO 11898-3 defines a fault-tolerant, low-speed physical layer that is now rare. The 2024 revision of ISO 11898-1 consolidates classical CAN, CAN FD and CAN XL in one document, and chip vendors such as Infineon now describe their controllers as compliant with ISO 11898-1:2024. Above these sit the application profiles: SAE J1939 for heavy vehicles, CANopen (CiA 301, also published as EN 50325-4) for industrial machinery, ISO 15765-2 and ISO 14229 for diagnostics, and ODVA DeviceNet for legacy factory networks.

Why does CAN keep winning? Compare it with the alternatives engineers evaluate. LIN is cheaper but single-master and slow, around 20 kbit/s. FlexRay offered deterministic time-triggered communication at 10 Mbit/s but cost more, needed careful scheduling and has been largely displaced. Automotive Ethernet (100BASE-T1 and above) brings bandwidth and IP, but it is point-to-point with switches, and each node costs more. Our SOME/IP and automotive Ethernet guide shows where that backbone fits. CAN occupies the middle: a multi-master broadcast bus, a few dollars of silicon per node, hardware-enforced priorities and a fault model that has been refined for four decades.

The industrial side has the same story. Where Modbus gives you a simple master/slave register map (see our Modbus protocol complete guide), CAN gives you event-driven, prioritized multi-master traffic with built-in error detection. That is why drives, hydraulics controllers, battery management systems, agricultural machinery, elevators and medical devices all use it.

The CAN Bus Protocol Architecture

Figure 1: The CAN protocol stack. ISO 11898-2 defines the physical layer, ISO 11898-1 the data link, and profiles such as CANopen, J1939 and UDS sit above.

Figure 1 shows the layering: every higher-layer protocol ultimately becomes frames with an identifier and a small payload, and every frame is arbitrated, stuffed, checksummed and acknowledged by the same data-link machinery, then driven onto a differential pair by a transceiver. Understanding CAN means understanding what each of those blocks guarantees and what it leaves to you.

Direct answer: The CAN bus protocol is a multi-master, message-oriented serial bus in which every node broadcasts frames carrying an identifier rather than a destination address. Nodes compete for the bus using non-destructive bitwise arbitration: the lowest identifier wins without corrupting the frame. Hardware CRC, bit stuffing, acknowledgement and error counters give robust, self-policing delivery.

Message-oriented, not address-oriented

Most networks answer “who is this for?” CAN answers “what is this?” The identifier names the content, for example “engine speed” or “left front wheel speed”, and every node receives every frame, filtering in hardware on the identifier and accepting only what it needs. Adding a new listener requires no change to the transmitter. This decoupling is the reason CAN harnesses scale across vehicle variants: a new ECU simply subscribes to existing identifiers.

The identifier doubles as priority. In an 11-bit frame the identifier ranges from 0x000 to 0x7FF, and a lower number means a higher priority. A 29-bit extended identifier first compares its 11 most significant bits against standard frames, so the two formats coexist on one bus. System designers therefore allocate identifier ranges like a priority table: safety and control loops low, diagnostics and bulk data high.

Bus access: CSMA/CR (arbitration)

CAN uses carrier-sense multiple access with collision resolution, often written CSMA/CR (older documents say CSMA/BA, bitwise arbitration). When the bus has been idle, any node may start a frame. If two nodes start together, both transmit their identifier bit by bit while reading the bus. The electrical design makes a dominant bit (logical 0) override a recessive bit (logical 1), because the transceiver output stage acts like a wired-AND. A node that sends a recessive bit but reads a dominant one knows another node has a higher priority, stops transmitting immediately and becomes a receiver. The winning frame continues undisturbed, and nobody loses time to a collision.

This is why CAN is often called deterministic in the priority sense: the worst-case latency of the highest-priority message is one frame time plus any frame already in progress, because CAN does not preempt a transmission. Lower-priority messages see more interference, and their worst-case response time can be bounded using the classic response-time analysis of Tindell and Burns, later corrected by Davis and colleagues. That analysis is the basis of schedulability tools used in automotive network design.

The physical layer: differential signalling

ISO 11898-2 high-speed CAN uses two wires, CAN_H and CAN_L. In the recessive state both sit at about 2.5 V and the differential voltage is roughly 0 V. In the dominant state CAN_H rises to about 3.5 V and CAN_L falls to about 1.5 V, giving a differential of around 2 V. Receivers look at the difference, so noise coupled equally on both wires cancels. Twisted pair, nominal 120 ohm characteristic impedance, and 120 ohm termination resistors at both physical ends of the trunk complete the picture; with both terminators in place a multimeter across the bus reads about 60 ohm with power off.

Signalling speed trades against bus length because the arbitration mechanism needs a bit to propagate down the bus and back within one bit time. As rules of thumb, a classical 1 Mbit/s segment is limited to a few tens of metres (about 40 m is the commonly quoted figure), 500 kbit/s to roughly 100 m, 250 kbit/s to a few hundred metres and 125 kbit/s or less to several hundred metres or more. Exact limits depend on cable, stub lengths, transceiver delay and the sample-point configuration, so treat those as planning numbers and confirm with the network design tool.

Frames, Bit Stuffing and Bit Timing

The core CAN frame is simple to describe and subtle in the details. Learning it once explains most of CAN’s behaviour in the field.

The classical CAN data frame

A standard-format (CAN 2.0A) data frame is a sequence of fields. SOF is a single dominant start bit that hard-synchronizes the receivers. The arbitration field carries the 11-bit identifier and the RTR bit (remote transmission request, dominant for data frames). The control field carries IDE (dominant for standard frames), a reserved bit and a 4-bit data length code (DLC). The data field carries 0 to 8 bytes. The CRC field holds a 15-bit cyclic redundancy check and a recessive delimiter. The ACK slot is sent recessive by the transmitter; any receiver that got the frame correctly overwrites it with a dominant bit, followed by an ACK delimiter. Seven recessive EOF bits end the frame, and a 3-bit intermission separates it from the next.

The extended-format frame (CAN 2.0B) replaces the 11-bit identifier with a 29-bit one, split into an 11-bit base ID, SRR and IDE bits set recessive, and an 18-bit extension. Both formats can be mixed on one bus.

Bit stuffing

CAN is NRZ coded: there are no clock edges guaranteed within the data. To keep receivers synchronized, the transmitter inserts a complementary bit after five consecutive bits of the same polarity, from SOF through the CRC sequence. Receivers remove them. A sixth identical bit in a row is therefore a stuff error, which doubles as an error-detection mechanism and as the basis of the six-bit error flags.

Stuffing has a throughput cost that engineers often forget. In the worst case, a pattern such as alternating runs forces a stuff bit after the first five bits and then after every four subsequent bits. For a standard frame with 8 data bytes, the stuffed region (SOF to the end of CRC) is 98 bits, and the worst-case number of stuff bits is floor((98 – 1) / 4) = 24. We use that in the worked example below.

Bit timing and the sample point

Every CAN controller divides the nominal bit time into integer time quanta (tq), derived from the controller clock by a prescaler. A bit is composed of four segments: Sync_Seg (always 1 tq, where edges are expected), Prop_Seg (compensates for physical propagation delay), Phase_Seg1 and Phase_Seg2 (buffers used for resynchronization). The sample point sits between Phase_Seg1 and Phase_Seg2. The synchronization jump width (SJW) is how many tq the controller may lengthen or shorten a bit to track a drifting transmitter. Many controllers merge Prop_Seg and Phase_Seg1 into a single “TSEG1” parameter.

Figure 2: Bitwise arbitration. Three nodes start in the same bit slot; the node with the numerically lowest identifier keeps the bus and the others silently retry.

Figure 2 walks through arbitration with three real identifiers. Node A (0x120) is 00100100000 in binary, node B (0x0A5) is 00010100101 and node C (0x3F0) is 01111110000. All three send the same first bit. At the second bit C sends recessive 1 while A and B send dominant 0, so C reads a 0 on the bus and drops out. At the third bit A sends 1 while B sends 0, so A drops out. B has the lowest identifier and wins, and nobody, including B, saw a corrupted bit. There is no retransmission penalty for B; A and C simply reattempt after intermission.

A worked bit-timing example

Suppose a controller has an 80 MHz clock and the target is 500 kbit/s with a sample point near 87.5 percent, the figure CiA recommends for many CANopen networks and a sensible default elsewhere. One bit is 2000 ns. Choose a prescaler of 10, so one tq is 125 ns and a bit is 16 tq. Allocate Sync_Seg = 1, TSEG1 (Prop_Seg + Phase_Seg1) = 13 and Phase_Seg2 = 2. The sample point is at (1 + 13) / 16 = 87.5 percent. Set SJW = 2 so a bit can be stretched by up to 2 tq (12.5 percent of the bit) during resynchronization. On Linux you can request this directly with ip link set can0 type can tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 2 bitrate 500000, or simply ask for the bitrate and sample point and let the kernel compute them.

Why does this matter? Mismatched sample points are the classic cause of a network that works with three nodes and fails when the fourth is added. All nodes on the segment should use the same bit rate and similar sample points; mixed controllers must be configured so that oscillator tolerance and propagation delay fit inside the phase segments. Oscillator tolerance is bounded roughly by SJW and Phase_Seg: the CAN specification bounds the allowed oscillator tolerance at about 1.58 percent when all parameters are at their best settings, which is why crystals, not ceramic resonators, are used in demanding applications.

Error Handling and Fault Confinement

CAN’s second great idea, after arbitration, is that the bus polices itself. Every node watches every frame and every bit it sends, and five independent mechanisms detect faults: bit monitoring (the transmitter reads back what it sent), stuff-rule checking, the 15-bit CRC, the frame-format check (fixed-form bits such as delimiters and EOF) and acknowledgement checking. The 15-bit CRC gives a Hamming distance of six, which means up to five randomly distributed bit errors in a frame are always detected. Combined with the other mechanisms, the residual error probability is extremely low for a healthy bus, though it is not zero and it depends on the actual bit error rate.

When any node detects an error it destroys the frame by transmitting an error flag of six dominant bits (active) or six recessive bits (passive), which every other node sees as a stuff violation and so also discards the frame. The transmitter then retransmits automatically. This automatic retransmission is a feature and a hazard: it guarantees delivery for transient noise, but a permanent fault can consume a large share of the bandwidth.

Transmit and receive error counters

To stop one broken node from taking down the network, every controller keeps a transmit error counter (TEC) and a receive error counter (REC). In simplified form: a transmitter that detects an error adds 8 to TEC, a receiver that detects an error adds 1 to REC, and each successful frame decrements the relevant counter by 1. The asymmetry is deliberate. A transmitter is statistically more likely to be the faulty party, so it is penalized eight times harder, and a node that fails repeatedly climbs the counters quickly while a healthy node on a noisy line drifts upward slowly and recovers.

Figure 3: Fault confinement states. Counters at or above 128 push a node to error passive; a TEC above 255 makes it go bus off until it recovers.

The node moves through three states, shown in Figure 3. In error active (both counters below 128) it participates fully and signals errors with dominant flags that corrupt the bus. In error passive (either counter at or above 128) it may still transmit, but it signals errors with recessive flags that cannot disturb others and must wait an extra 8 bit times, the suspend transmission delay, before sending again. In bus off (TEC above 255) it disconnects itself from the bus entirely. Recovery requires observing 128 occurrences of 11 consecutive recessive bits, or a host-triggered restart in many controllers, and what happens next is a software policy decision.

Why bus-off policy matters

A common bug is a driver that auto-recovers from bus off immediately. If the cause is a short or a wrong bit rate the node will bounce between error active and bus off, flooding the bus with error frames each cycle. Good practice is exponential back-off, a log entry on each event and, for safety functions, a defined degraded mode. Linux SocketCAN exposes this through the restart-ms option; leaving it at 0 means a node stays bus off until restarted manually, which is often the safest default for a first deployment.

Limits of the error model

CAN’s error handling detects, signals and retransmits; it does not authenticate or provide guaranteed latency. A fault in one node’s transceiver that holds the bus dominant silences everyone, and the counters cannot help. A babbling node that sends a legitimate frame with a high-priority identifier at a high rate is not erroneous at all, and the protocol will faithfully give it the bus. These cases are covered in the failure-modes section below.

CAN FD and CAN XL: The Frame Generations

Classical CAN’s two limits, 8 data bytes and 1 Mbit/s, have defined every design discussion since the 2000s. The two extensions keep the same arbitration principle but change what happens after it.

CAN FD: 64 bytes and a faster data phase

CAN with Flexible Data-rate was introduced by Bosch around 2012 and is standardized in ISO 11898-1 (the 2015 edition first formalized it). It makes two changes. First, the data field grows to up to 64 bytes, via a nonlinear DLC mapping above 8 (9 to 15 map to 12, 16, 20, 24, 32, 48 and 64 bytes). Second, the controller may switch to a higher bit rate for the data phase: the FDF (FD format) bit marks an FD frame, the BRS (bit rate switch) bit commands the speed-up after the arbitration phase, and an ESI bit reports the transmitter’s error state. Arbitration still happens at the nominal rate, because it requires all nodes to agree at the bit level.

CAN FD also strengthens integrity. The CRC grows to 17 bits for frames up to 16 bytes and 21 bits above that, and a stuff-bit count field protects against stuffing errors that would otherwise slip through. The data-phase rate is typically 2 to 5 Mbit/s with standard ISO 11898-2 transceivers; signal-improvement-capability (SIC) transceivers, specified as an extension to ISO 11898-2, push practical data rates to 8 Mbit/s in suitable topologies. Real throughput gains depend on topology: longer stubs and unterminated branches limit the achievable rate more than the controller does.

An often-missed compatibility point: classical CAN controllers do not understand FD frames and flag them as errors. A mixed bus therefore needs either FD-tolerant classical controllers or a strict segmentation. CAN FD migration in vehicles has generally been done network by network, with gateways converting between classical and FD segments.

CAN XL: Ethernet-sized payloads on the same arbitration

CAN XL (specified by CAN in Automation as CiA 610-1 and incorporated in ISO 11898-1:2024) targets the gap between CAN FD and 10BASE-T1S Ethernet. According to CAN in Automation, its data field ranges from 1 to 2048 bytes and the data phase can reach 20 Mbit/s with CAN SIC XL transceivers (specified in ISO 11898-2). Arbitration is still bitwise using an 11-bit priority identifier, and a separate 32-bit acceptance field is intended for addressing. CAN XL also supports virtual CAN networks and carries a field identifying the payload type, which allows protocols such as Ethernet or IP frames to be tunnelled. Treat the exact field names and CiA document numbers as items to verify against the current specification before writing them into a design document.

Importantly, CAN XL remains a multi-master, arbitrated bus; the speed-up applies only to the data phase, and mixed networks require careful management of which node supports which format. As of writing, silicon is shipping from several vendors, but deployments are early; most 2026 production designs are still classical CAN and CAN FD. See our comparison of CAN FD, CAN XL and CANopen in industrial fieldbus and robotics for selection guidance.

Property	Classical CAN	CAN FD	CAN XL
Max data bytes	8	64	2048
Nominal (arbitration) rate	up to 1 Mbit/s	up to 1 Mbit/s typical	arbitration at modest rate, typically in the 1 Mbit/s class
Data-phase rate	same as nominal	typically 2 to 5, up to 8 Mbit/s with SIC	up to 20 Mbit/s with SIC XL
CRC	15 bits	17 or 21 bits plus stuff count	longer CRC (see spec)
Identifier	11 or 29 bits	11 or 29 bits	11-bit priority plus acceptance field
Standard	ISO 11898-1	ISO 11898-1:2015 and later	ISO 11898-1:2024

Note: values are the commonly quoted figures. The arbitration-rate and CRC entries for CAN XL are deliberately imprecise; confirm them against CiA 610-1.

Higher-Layer Protocols: J1939, CANopen, ISO-TP, UDS, DeviceNet

Raw CAN gives you identifiers and 8 bytes. Everything else, such as what an identifier means, how to send 100 bytes, how to boot a node and how to read diagnostics, is a higher-layer protocol.

SAE J1939 for trucks, buses and off-highway

J1939 runs on 250 kbit/s (500 kbit/s in the newer J1939-14) using 29-bit identifiers divided into a 3-bit priority, an 18-bit parameter group number (PGN) and an 8-bit source address. A PGN names a group of signals (for example electronic engine controller 1, which carries engine speed and torque); each signal inside the group is a suspect parameter number (SPN). Messages are either broadcast periodically or requested. Because the source address is in the identifier, J1939 includes an address-claim procedure so that ECUs can negotiate their address at power-up and detect conflicts. Larger messages use the transport protocol, with broadcast announce (BAM) or connection-managed (RTS/CTS) modes carrying up to 1785 bytes, and the extended transport protocol carrying much more. Diagnostics use diagnostic trouble codes built from an SPN and a failure mode identifier. Note that J1939 is a SAE standard family: refer to the current document set rather than relying on a summary.

CANopen for industrial machines

CANopen (CiA 301, EN 50325-4) defines an object dictionary per device plus a small set of communication services, all mapped onto the 11-bit identifier space with a predefined connection set. Typical pre-defined identifiers are: NMT command 0x000, SYNC 0x080, EMCY 0x080 plus node ID, TPDO1 0x180 plus node ID, RPDO1 0x200 plus node ID, SDO transmit 0x580 plus node ID, SDO receive 0x600 plus node ID and heartbeat 0x700 plus node ID. Process data objects (PDOs) carry real-time process values with no protocol overhead; service data objects (SDOs) read and write the object dictionary for configuration. Device profiles such as CiA 402 for drives and motion control give vendor-neutral behaviour, which is why a CANopen servo from one vendor can be exchanged for another with a modest configuration change. The newer CANopen FD (CiA 1301) carries the same model over CAN FD.

The identifier-as-priority principle shows up in CANopen design. Because lower numbers win, the predefined set puts emergency and synchronization at the top and heartbeat at the bottom. Designers remap PDO identifiers when a control loop needs higher priority than a default.

ISO-TP and UDS for diagnostics

Vehicle diagnostics run on ISO 14229 (Unified Diagnostic Services, UDS) carried over ISO 15765-2 (ISO-TP), the transport protocol that segments messages longer than a frame. ISO-TP uses four frame types: single frame (SF), first frame (FF), consecutive frame (CF) and flow control (FC); in the classical format the first frame’s 12-bit length field allows up to 4095 bytes, and later editions add an escape sequence for larger payloads. The receiver controls the pace through flow control with a block size and a separation time (STmin), so a slow ECU is not overrun. UDS services such as ReadDataByIdentifier (0x22), SecurityAccess (0x27), RoutineControl (0x31), RequestDownload (0x34) and TransferData (0x36) underpin diagnostics, calibration and flash reprogramming, which is a high-value target for attackers and a reason diagnostics access should be gated by security access and, increasingly, authentication.

DeviceNet and the long tail

ODVA’s DeviceNet maps the Common Industrial Protocol (CIP) onto CAN at 125, 250 or 500 kbit/s. It is mostly encountered in brownfield plants; new designs generally go to Ethernet-based CIP. Other CAN-based profiles include NMEA 2000 (marine), ISOBUS (ISO 11783, agriculture, based on J1939) and CANaerospace. The pattern repeats: identifier layout plus a transport and an application model. For plant integration pointers, see our guide to OPC UA, which is how CAN-attached machine data typically reaches IT systems.

Security, Gateways and Tooling

Why CAN has no built-in security

CAN was designed for a closed harness. Any node can send any identifier, frames carry no sender identity and nothing is encrypted. Once an attacker reaches the bus through an OBD-II port, a telematics unit or a compromised infotainment ECU, they can spoof frames, replay captured traffic or flood the bus with dominant identifiers to starve legitimate messages. The widely publicized vehicle remote-attack research of the mid-2010s was built on exactly this property, with the gateway or a connected ECU as the bridge into the bus.

Because the 8-byte classical payload leaves little room, security is layered on top. AUTOSAR Secure Onboard Communication (SecOC) appends a truncated message authentication code (MAC) and a truncated freshness value (a counter or timestamp) to the protected PDU. The receiver recomputes the MAC with a shared symmetric key, typically AES-CMAC, and rejects mismatches and replays. The truncation is a real trade-off: shorter MACs leave more payload but offer fewer bits of forgery resistance, and the freshness value must be synchronized between nodes. CAN FD’s larger payload makes SecOC far more comfortable, and CAN XL’s link-layer security work in CiA aims to go further, although you should verify the current status of that specification before relying on it.

Detection complements authentication. CAN intrusion detection systems exploit the periodic nature of most traffic: a message that normally arrives every 10 ms and suddenly arrives every 1 ms, an identifier that never appeared before or an inter-arrival-time jitter pattern all stand out. Hardware-level options, such as monitoring the electrical fingerprints of transmitters, are active research. For compliance, UNECE R155 (cybersecurity management systems) and ISO/SAE 21434 are the frameworks that push OEMs toward such measures, while for industrial equipment IEC 62443 applies.

Gateways: CAN meets Ethernet

The CAN segment seldom stands alone in 2026. Vehicles are moving to zonal architectures in which a zone controller aggregates local CAN, LIN and sensor traffic and forwards it to a central compute node over automotive Ethernet. The gateway typically does three things: signal-level translation (CAN frames to SOME/IP events or DDS topics), filtering and rate limiting for security, and time synchronization (gPTP). Our guide to software-defined vehicle architecture with AUTOSAR Classic and Adaptive explains where that translation lives in the software stack.

Industrial gateways behave similarly. A CANopen master such as an industrial PC or PLC exposes the object dictionary as OPC UA nodes or MQTT topics; the digital-twin layer then subscribes to those instead of the raw bus. A practical rule: gateways should translate signals, not tunnel raw CAN to the cloud, because raw tunnelling extends the trust boundary of a bus with no authentication.

Tooling: SocketCAN and python-can

On Linux, CAN controllers appear as network interfaces through SocketCAN, and the can-utils package provides command-line tools. A typical bring-up looks like this:

# Classical CAN at 500 kbit/s, 87.5% sample point, auto-restart after 100 ms
sudo ip link set can0 type can bitrate 500000 sample-point 0.875 restart-ms 100
sudo ip link set up can0

# CAN FD: 500 kbit/s arbitration, 2 Mbit/s data phase
sudo ip link set can0 type can bitrate 500000 dbitrate 2000000 fd on
sudo ip link set up can0

candump can0                 # watch everything
cansend can0 123#DEADBEEF    # send ID 0x123 with 4 data bytes
cangen can0 -g 10 -I 0x100 -L 8   # generate load for tests
ip -details -statistics link show can0   # error counters, state

For scripting, the python-can library abstracts hardware interfaces. This short monitor decodes one signal and warns when its period drifts, a cheap intrusion and health check:

import can, time

bus = can.Bus(interface="socketcan", channel="can0", fd=False)
last = None
EXPECTED = 0.010   # 10 ms cycle for ID 0x1A0

for msg in bus:
    if msg.arbitration_id != 0x1A0:
        continue
    rpm = int.from_bytes(msg.data[0:2], "little") * 0.25   # scale from the DBC
    now = msg.timestamp
    if last and abs((now - last) - EXPECTED) > 0.003:
        print(f"jitter: {(now - last)*1000:.1f} ms, rpm={rpm:.0f}")
    last = now

Signal definitions live in DBC files (vehicle) or EDS files (CANopen); libraries such as cantools parse them. On the hardware side, protocol analyzers from the major tool vendors and low-cost USB adapters give the physical-layer view you need for termination, reflections and sample-point checks. An oscilloscope with CAN decode is the single most useful instrument: it shows the differential waveform, the ringing at the stubs and the dominant/recessive voltage levels.

Worked Example: Bus Load and Latency

Capacity planning on CAN is arithmetic, and it is worth doing before the first ECU is ordered.

Take a standard-format frame with 8 data bytes. Count the bits: SOF (1) + identifier (11) + RTR (1) + IDE (1) + reserved (1) + DLC (4) = 19; data = 64; CRC (15) + CRC delimiter (1) = 16; ACK slot and delimiter = 2; EOF = 7; intermission = 3. The total is 19 + 64 + 16 + 2 + 7 + 3 = 111 bits with no stuffing. In the worst case, the stuffed region (SOF through CRC sequence: 19 + 64 + 15 = 98 bits) can gain floor((98 – 1) / 4) = 24 extra bits, giving 135 bits.

At 500 kbit/s each bit is 2 microseconds. The nominal frame time is 111 x 2 = 222 microseconds, and the worst case is 135 x 2 = 270 microseconds. The bus can carry roughly 4,500 such frames per second at best (1 / 222 microseconds) and about 3,700 in the worst-case stuffing scenario (1 / 270 microseconds).

Suppose the network has 20 messages at 10 ms (100 frames/s each = 2,000 frames/s), 30 at 20 ms (1,500 frames/s) and 20 at 100 ms (200 frames/s). The total is 3,700 frames/s. Using the worst case frame time, utilization is 3,700 x 270 microseconds = 99.9 percent, which is unacceptable; using a realistic average stuffing of about 120 bits (240 microseconds) it is 88.8 percent, still too high. Many OEMs cap the sustained load at 30 to 50 percent for control buses and rarely exceed about 70 percent even for sparse low-priority traffic, because the response-time of low-priority frames grows steeply with load.

The fix is architectural rather than tuning: move the 100 ms traffic to a second bus, go to 1 Mbit/s, or switch to CAN FD for packed signals. Packing four 16-bit signals into one 8-byte frame instead of four frames cuts frames by 75 percent at the cost of coupling their cycle times. Moving to CAN FD, a 64-byte frame at 500 kbit/s arbitration and 2 Mbit/s data rate takes about 29 bits at the slow rate for the header plus 512 data bits at 0.5 microseconds plus CRC overhead, which is of the order of 300 microseconds (illustrative estimate), but it carries eight times the payload of the classical frame, so efficiency per byte improves dramatically.

For latency, apply the response-time idea in simple form. A frame’s worst-case latency is its own transmission time, plus blocking by one lower-priority frame already on the wire (up to 270 microseconds here), plus interference from all higher-priority frames that may queue during that window. The highest-priority frame sees about 270 + 270 = 540 microseconds in the worst case at this speed. A mid-priority frame with 40 higher-priority senders can see several milliseconds, which is why timing-critical signals should get low identifiers and why identifier allocation is a design activity, not an afterthought.

Trade-offs, Gotchas, and What Goes Wrong

Figure 4: Common CAN failure paths, from physical faults and misconfiguration to bus-off or starvation, and the gateway-level policies that contain them.

CAN is forgiving, which means problems often show up as intermittent symptoms. Figure 4 groups the typical causes.

Termination faults. A missing or doubled terminator is the number-one field failure. Measure resistance with the bus unpowered: about 60 ohm means two 120 ohm terminators are present; about 120 ohm means one is missing; an open circuit means both are. Wrong values or terminators placed in the middle of a long stub create reflections that corrupt bits only at the higher speeds, so a bus that works at 125 kbit/s may fail at 1 Mbit/s or in CAN FD data phase.

Topology abuse. CAN wants a linear trunk with short stubs. Star wiring, long drops and loose daisy-chains turn the line into an antenna. In CAN FD the allowable stub length shrinks with the data-phase rate. SIC transceivers help, but they do not rescue a bad topology.

Configuration mismatch. Two nodes at different bit rates look like a constant stream of error frames to each other. Different sample points on a long bus produce failures that appear only under temperature or supply variation. The cure is a documented network configuration and a commissioning checklist.

Babbling idiot. A faulty node that transmits a high-priority identifier continuously is not violating the protocol; it simply wins every arbitration. Mitigations are a bus guardian or gateway rate limit, per-identifier transmission monitoring and, in safety designs, a hardware watchdog able to force the transmitter off.

Stuck dominant and shorts. A transceiver with a shorted TX pin holds the bus dominant and everyone sees continuous errors. Transceivers with TXD dominant timeout limit this, which is one reason to specify a transceiver with that feature.

Bus-off oscillation. As described earlier, immediate auto-recovery turns a persistent fault into a repeated flood. Throttle restarts and log.

Ground offsets and common-mode. The ISO 11898-2 receivers tolerate a common-mode range of roughly minus 2 to plus 7 V in typical transceivers; ground shifts between distant nodes in a plant, particularly with large motor drives, can exceed that. Use galvanically isolated transceivers and a shield grounded at one point per the application guidance.

Latency illusions. CAN is not hard real-time on its own. Low-priority frames have no guaranteed bound unless the analysis shows one, and software driver queues (hardware FIFO depth, interrupt latency, SocketCAN queueing disciplines) add delay beyond the wire time. Use hardware timestamps for measurement.

Security assumptions. Do not treat the CAN bus as trusted because it is internal. If the design depends on identifier uniqueness for safety, assume an attacker can send that identifier.

Practical Recommendations

Start from the requirement, not the protocol generation. Classical CAN at 500 kbit/s remains the sensible choice for control networks with small signals and long service lives; choose CAN FD when you must carry more than 8 bytes per message, need to flash firmware quickly or can no longer meet load targets; evaluate CAN XL only if you require multi-hundred-byte frames with CAN-style arbitration and have confirmed supply and tooling.

Treat identifier allocation as a system design artifact: reserve ranges by function, keep the control loops at the bottom and document every message with period, deadline and owner in a DBC or equivalent. Calculate worst-case bus load including stuffing, and keep sustained load under a conservative cap. Use a standard higher layer (CANopen, J1939) rather than inventing one, because the interoperability and tooling are worth more than the saved bytes.

At the edge of the bus, put in the protections: a gateway that filters and rate-limits, authentication via SecOC for anything that actuates, and diagnostics gated behind UDS security access.

A pre-release checklist:

Bit rate, sample point and SJW identical and documented for every node on a segment.
120 ohm termination at both ends only; unpowered resistance reads about 60 ohm.
Stubs as short as the data-phase rate demands; no star topology on FD segments.
Worst-case bus load computed with stuffing, with a headroom target agreed in writing.
Bus-off recovery policy with back-off and logging; error counters exposed to diagnostics.
Babbling-node protection (gateway rate limit or watchdog) on safety-relevant segments.
Message authentication on actuating signals; diagnostics access gated and logged.
Transceivers chosen for the data rate (HS, FD-qualified or SIC), with isolation where grounds differ.
An oscilloscope capture of the waveform at the farthest node archived with the release.

Frequently Asked Questions

What is the CAN bus protocol used for?

The CAN bus protocol connects microcontrollers in vehicles, trucks, agricultural and construction machines, factory drives, elevators, medical devices and battery systems. It carries small, prioritized control and status messages over two twisted wires, with hardware error detection and automatic retransmission. It is chosen where cost per node, noise immunity and predictable priority behaviour matter more than raw bandwidth, which is why it coexists with Ethernet rather than being replaced by it.

How does CAN bus arbitration work?

When several nodes start transmitting together, each sends its identifier bit by bit while reading the bus. Dominant (0) overrides recessive (1), so a node that sends a 1 but reads a 0 knows a higher-priority message is present and stops. The node with the lowest identifier continues without losing any bits, so no collision damage or retransmission is needed for the winner.

What is the difference between CAN, CAN FD and CAN XL?

Classical CAN carries up to 8 bytes at up to 1 Mbit/s. CAN FD carries up to 64 bytes and can switch to a faster data phase, commonly 2 to 5 Mbit/s and up to 8 Mbit/s with SIC transceivers. CAN XL carries up to 2048 bytes with a data phase up to 20 Mbit/s using SIC XL transceivers. All three use identifier-based arbitration and are covered in ISO 11898-1:2024.

How do I calculate CAN bus load?

Count the bits in each frame including stuffing (111 bits unstuffed and up to 135 for a standard 8-byte frame), multiply by the bit time to get the frame time, then multiply by frames per second and sum across all messages. At 500 kbit/s, an 8-byte frame takes 222 to 270 microseconds. Keep sustained load well below the capacity, commonly 30 to 50 percent for control buses.

Is CAN bus secure?

No. Classical CAN has no authentication or encryption, so any node can send any identifier. Security is added above the bus: SecOC adds a truncated MAC and freshness value to protected messages, gateways filter and rate-limit traffic, intrusion detection spots anomalies, and UDS security access protects diagnostics. Regulations such as UNECE R155 and standards like ISO/SAE 21434 push vehicle makers toward these layers.

Why 120 ohm termination on a CAN bus?

The twisted pair has a characteristic impedance of about 120 ohm. Terminating each end with a matching resistor absorbs the signal and prevents reflections that would otherwise corrupt bits. With both terminators in place, the two resistors appear in parallel, so you measure about 60 ohm between CAN_H and CAN_L with the power off. Terminating in the middle or adding extra resistors degrades the signal.