What Is CAN FD?

Back to Blog

What CAN FD Adds Over Classic CAN

Classic CAN caps a frame at eight data bytes, which forces long messages to be split across multiple frames and adds overhead. CAN FD raises the maximum payload to 64 bytes, so a controller can send far more data in one frame with proportionally less framing overhead. For data-rich devices, an engine controller reporting many parameters, or a drive streaming diagnostics, this is a large efficiency gain and a reason newer devices adopt it.

The second change is the flexible data rate itself. In a CAN FD frame the arbitration phase runs at the normal bus rate so that priority resolution works exactly as before, but once a node has won the bus it can switch to a higher bit rate for the data and CRC portion, then drop back for the end of the frame. Speeding up only the phase where no arbitration is happening lets CAN FD move more data without breaking the timing rules that make arbitration deterministic. The result is more bytes, moved faster, on the same wiring.

Same Arbitration, Bigger and Faster Frames

Crucially, CAN FD does not change the arbitration model. It still uses 11-bit or 29-bit identifiers, still resolves contention bit by bit with dominant beating recessive, and still gives the lowest identifier the bus, exactly as described for CAN bus arbitration. Everything an engineer knows about assigning priorities through identifiers carries straight over. What changed is the frame body, not the way the bus is won.

CAN FD also strengthens the frame's integrity checking to match its larger payload, using a more capable CRC scheme so that longer frames are protected as reliably as short classic frames. This matters because a 64-byte frame that fails silently would carry far more bad data than an eight-byte one, so the error detection had to scale with the payload. The CRC still catches corrupted frames and triggers a retransmission, keeping the same never-act-on-bad-data guarantee.

For the physical layer, CAN FD raises the stakes on everything classic CAN already cared about. Because the data phase runs faster, termination, stub length, and cable quality that were merely adequate for classic CAN at a given length can become marginal for CAN FD, so a bus upgraded to FD sometimes needs its physical layer tightened even though the wiring did not change. The termination discipline and stub-length rules get less forgiving as the data-phase rate climbs.

The Compatibility Rule Integrators Miss

The rule that catches people is that a classic CAN controller cannot decode a CAN FD frame. When a classic node sees the FD-specific bits in a frame, it treats the frame as an error and transmits an error frame, which corrupts the CAN FD traffic and can push the classic node toward bus-off. So you cannot simply drop a CAN FD device onto an existing classic CAN bus and expect coexistence; the classic nodes will fight the FD frames.

There are ways to bridge the two worlds, but they are deliberate design choices, not automatic. Some controllers are FD-tolerant, meaning they can sit quietly on a bus carrying FD frames without disrupting them even if they do not use FD themselves; a fully mixed network needs every node to be at least FD-tolerant. More commonly, integrators keep a CAN FD segment separate and bridge it to classic CAN or to a higher network through a gateway that translates between them.

For monitoring, the practical consequence is that you must know which flavour a device speaks before configuring a gateway or interface, because a tool set for classic CAN will not read an FD device's frames and may disrupt an FD bus if it is not FD-tolerant. Once past the gateway the distinction disappears, exactly as it does for classic CAN, but at the wire it is a first-order compatibility question that has to be settled before any data flows. When bridging up toward a monitoring layer, the same gateway-mapping approach used for classic CAN applies, feeding named tags into a historian for trending.

Frequently Asked Questions