Controller Area Network (CAN) has been the backbone of in-vehicle and industrial communication for decades, and it remains the default choice anywhere multiple nodes need to share a bus reliably in an electrically noisy environment. But “reliable” isn’t automatic — a CAN bus that’s wired, terminated, and configured even slightly wrong will still often work, right up until it doesn’t. This guide walks through the core principles (types, framing, arbitration, timing), the requirements that keep a bus healthy (congestion, latency, hardware design), and the methods used to actually validate one before it ships.
Types of CAN
Low Speed CAN
Low Speed CAN caps out at a 125 kbps baud rate with an 8-byte data payload. It’s also called fault-tolerant CAN, because if one wire in the bus is shorted or fails, the system can fall back to single-wire transmission and keep operating. That fault tolerance makes it a good fit for non-critical vehicle functions — interior lighting, door locks, power windows — where speed matters far less than staying alive through a wiring fault.
High Speed CAN
High Speed CAN (also called classical CAN) runs up to 1 Mbps, still with an 8-byte payload, and is the most widely deployed CAN variant in industry. It’s the standard choice for safety systems and time-critical operations — electronic braking, engine monitoring and management, transmission control, and process automation — anywhere a fast, accurate response matters more than fault tolerance.
CAN FD
CAN FD (Flexible Data-rate) extends classical CAN while staying backward compatible with it. It can reach up to 8 Mbps and supports up to 64 bytes of payload — eight times the classical CAN limit. CAN FD can use either an 11-bit or 29-bit arbitration ID. The 11-bit format (the FD base frame format) supports up to 2,048 unique IDs (2¹¹) and is sufficient for simpler networks with a limited node count; once a design needs more than 2,048 IDs, it moves to the 29-bit format, which supports up to 536,870,912 IDs (2²⁹). CAN FD’s combination of speed and payload size makes it well suited to autonomous driving systems and high-resolution infotainment.
CAN XL
The newest variant, CAN XL, pushes baud rate up to 20 Mbps with a maximum payload of 2,048 bytes per frame — built for the bandwidth demands of next-generation vehicle architectures.
At a Glance
Operational Distance of a CAN Bus
Bus length and baud rate trade off directly: the higher the baud rate, the shorter the maximum recommended bus length. A 1 Mbps bus is typically limited to on the order of tens of meters, while a 125 kbps bus can stretch to several hundred meters. Always check your transceiver and controller datasheets for the exact baud-rate-to-distance table for your specific hardware — the relationship isn’t perfectly linear across all.
Dominant and Recessive Bits, Common Mode and Differential Mode Voltages
CAN encodes logic 0 as a dominant bit and logic 1 as a recessive bit — the inverse of what many engineers expect from other buses. In the dominant state, CAN-High sits around 3.5 V and CAN-Low around 1.5 V, giving a differential voltage of roughly 2 V. In the recessive state, both lines sit near 2.5 V, giving a differential of roughly 0 V.
This matters because a dominant bit overpowers a recessive one on the bus. If two nodes transmit at the same instant — one sending recessive, one sending dominant — every node on the bus reads the dominant state. That single electrical property is what makes CAN’s arbitration scheme possible (more on that below).
What is a CAN Frame?
A CAN message is called a frame — a complete package of overhead plus data payload. There are four primary frame types:
Overload frame — signals the bus needs a delay before the next frame
Data frame — carries data
Remote frame — requests data from another node
Error frame — signals a detected error
CAN Frame Formats
CAN defines two frame formats: the standard frame (CAN 2.0A), using an 11-bit identifier, and the extended frame (CAN 2.0B), using a 29-bit identifier. The 11-bit identifier supports up to 2,048 unique IDs; the 29-bit identifier supports up to 536,870,912. It’s worth keeping the layers straight: the identifier width (11-bit vs. 29-bit) is a data-link-layer property, while low speed, high speed, CAN FD, and CAN XL are physical-layer properties — any of those physical-layer types can carry either CAN 2.0A or CAN 2.0B frames.
Standard CAN Frame Structure (CAN2.0A)
Extended CAN Frame Structure (CAN2.0B)
CAN Baud Rate versus Bandwidth
Baud rate and bandwidth are both expressed in bits per second, but they measure different things. Baud rate counts every bit on the wire — start of frame, arbitration field, control field, data field, CRC, and so on. Bandwidth counts only the data payload actually delivered, so it’s always smaller than the baud rate.
For example: a standard CAN frame is roughly 111 bits total, carrying only 64 bits (8 bytes) of payload. At a 500 kbps baud rate, the effective bandwidth is:
64 / 111 × 500 kbps ≈ 288 kbps
CAN ID and Arbitration
CAN ID is serving as the name of the message. There are two formats for CAN ID; 11-bit and 29-bit. The 11-bit is called the standard ID while the 29-bit is called the extended ID.
An 11-bit CAN provides 2048 unique message names. On the other hand, a 29-bit ID can provide 536,870,912 unique message names. If an application involves lot of messages that the 11-bit identifier is not enough, then the best choice is to use the 29-bit identifier.
CAN is a multi-master communication. It means that any nodes in the bus can initiate data transfer anytime as long as the bus is free (no node is currently transmitting message). With this characteristic, there is a chance that nodes will send message at the same time. Since CAN bus can only accommodate a single node to use the bus at a time, there is a so-called arbitration. Node refers to each device that connects to a CAN bus.
During the arbitration, only the most priority message will use the bus first. How this achieved? This is achieved through the CAN ID. The rule is that the lowest CAN ID will be the priority. The transmitting nodes (happen to attempt data transfer at the same time) will compare their CAN IDs bit-by-bit. When a node transmits a recessive bit (logic 1) but reads a dominant bit (logic 0) in the bus, it means that a more priority message is going to use the bus. The lower priority node or nodes will give way and switch to a listening mode.
CAN Frame Transmission Process
1. Wait for the bus to be idle. No node may interrupt existing bus activity. Once the bus is free, any node may begin transmitting.
2. Arbitration. Since CAN is a multi-master communication, any node in the bus can initiate message transmission. With this, there is a tendency that nodes will attempt to use the bus at the same time. There must be only one node to use the bus at a time. To comply this, there is an arbitration process. During the arbitration, the nodes message IDs are compared bit-by-bit. When a node sending a recessive bit and read a dominant bit in the bus, it means a more priority message is going to use the bus. The node with the less priority message will give way and switch to listening mode. The general rule is during message collision is that the message with the lowest CAN ID is the priority. There are two CAN ID formats, 11-bit (standard) and 29-bit (extended).
3. Send the data payload. Once arbitration completes, the winning node transmits its payload — up to 8 bytes for low speed and high speed CAN, 64 bytes for CAN FD, and 2,048 bytes for CAN XL.
4. Message reception. CAN message is broadcasted in the bus, means there is no target recipient in the message itself. All the listening nodes will check the message ID. If it is going to match on the node’s pre-programmed or whitelist IDs (in the local acceptance filter or register), the node will read the message. Otherwise, it will ignore it. The message reception process is:
- ID matching — each node will match the message ID to its pre-programmed IDs in the local acceptance filter or register. It will read the message once it matches. Otherwise, ignore it.
- Acknowledgement — after a successful reception of a message, the receiving node pulls the bus low (dominant state) during the ACK slot to inform the sender that the message is received with no errors
- Error handling — if the message received has errors, the node will forcibly assert stream of dominant bits (this is an error flag) to signal all other nodes that the current message is invalid. Then the transmitting node will stop the transmission immediately.
Timing of a CAN Message Update
CAN message is important to arrive the recipient on time. But how frequency the message must be updated? This is a great question for sure. There is no fixed rule. It is up to the need and the design of the CAN bus.
The Need – if the message is containing critical information such as vehicle safety and main function (braking, motor commands, etc.), set the update rate as frequent as possible (10ms – 20ms in most cases). For non-critical messages and messages that does not change frequently, a less frequent update rate is enough.
The Design – in a CAN bus, message update rate must be thought through carefully. The design must consider the frequency so that the bus is not flooded with message that results to congestion. When a bus is congested, latency will occur and messages will be delayed and even dropped often.
CAN Bus Congestion and Latency
CAN Bus Congestion
A CAN bus is congested when there is excessive data flow on it. This results to latency, delays, message dropped and frequent occurrence of error frames. Congestion simply means over loading. A Healthy CAN bus must have a utilization of less than 50%.
Utilization
This is the ratio of the total bit per second transmitted to the bus to the baud rate.
Utilization = total bits per second / baud rate x 100%
How to Avoid CAN Bus Congestion
First: to avoid congestion, select the right baud rate. Baud rate is the maximum capacity of a CAN bus. It is measured in bits per second. A higher baud rate can accommodate more messages per second. Baud rate requirement is can be estimated by adding all messages expected to flow to the bus in bits per second.
For instance, there are 10 nodes in a bus (with standard CAN frame of 111 bits). Each node is going to update 100 times in a second.
Total bits per second = 10 x 111 bits x 100 / second = 111,000 bits per second
Considering maximum utilization of 50%, the minimum CAN baud rate is:
Utilization = 0.5 = total bits per second / baud rate
Baud rate = total bits per second / 0.5 = 111,000 / 0.5 = 222,000 bits per second
Thus, a baud rate of 250 kbps is a good minimum choice.
Second: It is important to manage the bus load. For static messages, update rate is no necessary frequent. The same case for less like to change parameters. Set only more frequent update to messages that contains critical information. Flooding the bus with messages though not really necessary will make it slow.
Third: Minimizing data collision is also a key. CAN is a multi-master communication. Thus, multiple nodes may transmit at the same time. This will go to arbitration so that the most priority message will go through first. This process will introduce delay and when multiple nodes are attempting to take over the bus at the same time, it has the same effect as of a congested bus. Therefore, it is a good idea to make a schedule so that there is no collision or if cannot be avoided at least minimizing it. Setting a node message update interval will help.
Latency
Latency is the total time a message takes to travel from one node to another, made up of several additive delays:
- Bit transmission time — the raw time to shift bits onto the wire. A classical high-speed CAN frame at 1 Mbps transmits an 8-byte payload in roughly 110 µs, before accounting for overhead.
- Arbitration delay — the variable queuing delay a lower-priority message experiences while waiting for higher-priority traffic to clear.
- Transmitter/receiver processing delay — the conversion time between digital logic and bus voltage levels and back, typically a few microseconds.
- Hardware delay — inherent execution delay in CAN transceivers (roughly 5–10 µs for modern 1 Mbps-capable chips), plus additional delay from microcontrollers, isolation devices, logic gates, and parasitic capacitance.
- Propagation delay — governed by physical medium length, roughly 5 ns per meter. Poor termination causes reflections, which add further delay.
Reducing Latency
- Increase baud rate — more capacity directly reduces congestion-driven delay.
- Optimize priority and scheduling — assign higher (lower-priority) IDs to non-critical, infrequently-changing messages; use defined periodic update intervals rather than free-running event triggers to avoid message spikes; consider Rate Monotonic Scheduling (offsetting each node’s broadcast interval) or Time-Triggered CAN (TTCAN), which assigns each node a fixed time slot and removes arbitration delay entirely.
- Use CAN FD — arbitration at up to 1 Mbps combined with an 8 Mbps data phase reduces both congestion and per-frame transmission time, aided by the larger 64-byte payload.
- Select fast hardware — choose fast microcontrollers, CAN transceivers, isolation ICs, and logic gates, and avoid RC elements in the bus path that introduce their own time constant.
- Optimize firmware — keep message-handling code simple and avoid unnecessary processing or polling loops.
- Shorten propagation delay where possible — propagation delay can’t be eliminated, but the right medium (twisted pair or shielded twisted pair), correct termination placement, and routing CAN-H/CAN-L away from electromagnetically noisy harnesses all keep it as short and clean as the physics allows.
CAN Overheads
Not every bit in a CAN frame is data. A standard data frame runs roughly 111 bits (slightly more depending on bit stuffing), of which only 64 bits — 8 bytes — are payload. The remainder is overhead:
- Start/end of frame
- Arbitration field
- Control field
- CRC field
- ACK field
- Bit stuffing and interframe spacing
CAN Errors
CAN errors stem from a mix of hardware and software causes — though once firmware is mature, software-driven errors become far less common.
Bit Error — A transmitting node monitors its own transmission and flags an error if it reads back a different bit than it sent (e.g., sent recessive, read dominant). Usual causes: noisy CAN lines (EMI corrupting the electrical signal) or reflections from missing or incorrect termination.
Fixes to try: verify frame structure in software, confirm termination is present and correct (an effective termination reads ~60 Ω across CAN-H/CAN-L), route CAN wiring away from noisy devices, and use appropriately shielded/twisted-pair wiring.
Acknowledgement Error — Triggered when a transmitting node doesn’t receive the expected ACK. Usually points to a defective, unpowered, or disconnected receiving node.
Fixes to try: check for unpowered or defective nodes and verify each node’s connection to the bus.
CRC Error — Triggered when a receiver’s calculated checksum doesn’t match the transmitted one, indicating corrupted data. Common causes include congestion, reflections/standing waves, and EMI.
Fixes to try: check bus utilization, verify termination, and route wiring away from noise sources.
Bit Stuffing Error — CAN automatically inserts an opposite-polarity bit after five consecutive identical bits; a receiver expecting this and not seeing it flags an error. Causes include clock drift desynchronizing transmitter and receiver, protocol mismatches, mixing CAN types (low speed, high speed, FD) on one bus, or general signal interference.
Fixes to try: review clocking strategy, ensure all nodes use a consistent baud rate and CAN type, route wiring away from noise, and confirm termination.
Form Error — Triggered when a receiver detects an unexpected frame structure, commonly from mixing standard and extended frames (transmitter sends extended, receiver expects standard).
Fix to try: confirm every node on the bus shares the same frame-format expectations.
Overload Frame/Error — Appears when the bus is congested — a 6-dominant-bit flag followed by an 8-recessive-bit delimiter.
Fix to try: check bus utilization; healthy operation stays under 50%.
What is Baud Rate Mismatch
A baud rate mismatch occurs when nodes on the same bus are configured for different rates — for example, Node A at 250 kbps, Node B at 500 kbps, and Node C at 1 Mbps. Every node on a physical CAN bus must share a single baud rate; mismatches typically manifest as persistent bit-timing or CRC errors rather than a clean failure, which can make them tricky to diagnose.
CAN Bus Topologies
Linear Bus Topology
All devices are tapped to a single two-wire line using short connections. There is 120 ohm terminating resistor at the end of the bus to avoid signal reflections.
Daisy Chain Topology
This is a modified linear topology. In linear, there is a single two-wire lines wherein each node taps to it via a short connection. On the other hand, in daisy chain, the first node will pass the two-wire line to the second node via each connector the second node will do the same to the third node and so on. The termination resistors are still applied to the left end and to the right end of the bus.
Star Bus Topology
There is a central hub wherein all nodes going to connect. In this topology, individual CAN devices connecting to the hub is called stub. There are two variants; active star and raw star.
- Active Star – the central hub is intelligent like a smart CAN hub, switch or gateway. The central hub will receive the signal from each stub and it will do processing before transferring to the other nodes.
- Raw Star – the central hub is just a passive device. It is just like a connecting hub. It will not process the signal from each stub, instead pass it right away to the other stubs.
Tree Bus Topology
It is just a combination of linear and star topologies. This suitable for a very huge CAN network.
CAN Communication Hardware Requirement
- Select the correct CAN chip
- Follow the CAN chip recommendations such as voltage level, passive recommendations (resistors and capacitors), protections (like ESD and surge) and grounding.
- In the PCB, ensure the CAN high and CAN low traces are routed as differential pair and route them away from noisy components and traces.
- Ensure a solid good grounding in the PCB.
- Do not mix CAN types (such as classical and FD or with the low speed one)
- Do not mix baud rates is a CAN bus
- Put termination resistors at each end of the bus
- Ensure the termination value is correct (a 60-ohm must be measured across CAN high and CAN low)
- Route the CAN wires away from noisy devices
- Do no bundle CAN wires with noisy harness or high voltage and high current wires
- Use a correct wire (such as twisted pair, shielded and suitable wire gauge)
How to Qualify & Validate a CAN Bus?
Check the Hardware Integrity
Ensure all the hardware aspects are correctly done such asproper selection of CAN chip, following the datasheet recommendations, correct PCB routing, correct grounding, do not mixing of CAN types, no baud rate mismatch, ensure there is termination resistors and its location and values are correct, not to route CAN wires in the noisy path, not bundle CAN wire with noisy or high voltage and current harness and ensure to use right connections (such as twisted or shielded and sufficient wire gauge).
Check the Signal Integrity
Using a scope, quantify the CAN high and CAN low signals with respect to a local ground (common mode). There must be no ringing and overshoot in the waveforms. The waveform must not show sluggish rise time. Do the same for the differential signal. The ideal waveforms and levels must look like below.
Another way to check the signal integrity is through eye diagram. High end oscilloscopes can perform this analysis. The bigger the eye means a very good CAN bus while a smaller eye denotes a concerning CAN bus.
Check the Data Integrity
This is about ensuring the CAN message transmitted is received to the other end. Using a CAN analyzer like Kvaser can check the data integrity. If there is a problem, CAN error frames will show up. Part of this is to check the CAN bus utilization. A healthy CAN bus must have a utilization of not more than 50%.
Summary Checklist
Before calling a CAN bus design complete, confirm:
- Correct CAN type selected for the application (low speed, high speed, FD, or XL)
- No CAN-type or baud-rate mixing on a single physical bus
- Termination resistors present, correctly placed, and measuring ~60 Ω across CAN-H and CAN-L
- CAN-H/CAN-L routed as a differential pair, away from noise sources
- Bus utilization verified under 50% at expected message load
- Signal integrity confirmed via scope (no ringing/overshoot) and, ideally, eye diagram
- Data integrity confirmed via bus analyzer with no unexpected error frames
- Message update rates set deliberately — fast for critical data, relaxed for static data
A CAN bus that passes every item on this list at the bench is far more likely to stay quiet in the field than one validated only by “it seems to work.”