CAN FD Explained: Bigger Frames, Faster Data Phase

This article is part of the CAN & CANopen family. For the physical layer rules that FD tightens the tolerance on, see CAN Bus Wiring and Termination. For the full protocol family landing with DeviceNet, J1939, and CANopen links, visit the CAN & CANopen category hub.

Classic CAN gives you eight bytes per frame at up to 1 Mbit/s. That was generous in 1991 and cramped by 2010, when a single ECU firmware update over CAN could take most of an afternoon and a modern sensor's data no longer fit in one message.

CAN FD — flexible data rate — fixes both limits without abandoning the thing that makes CAN work. Arbitration stays exactly as it was. Only after arbitration is settled does the bus accelerate.

This guide covers what changes and what doesn't, the two bits that control it, the compatibility problem that catches people mixing generations, and the newer CAN FD light variant. Verified against ISO 11898-1 and ISO 11898-2.

The core idea: two bit rates in one frame

A CAN FD frame runs at two different speeds.

During arbitration, the frame runs at the nominal bit time — the same rate classic CAN uses. It has to. Arbitration depends on every node on the bus hearing every bit and reacting within one bit time, which means a bit must propagate to the far end of the bus and back before the next one begins. That round trip is set by physics and cable length, and no amount of protocol cleverness shortens it.

Once arbitration is over, exactly one node is transmitting. Nobody needs to hear anything in time to react. So the frame switches to the data bit time — faster, because the round-trip constraint no longer applies — sends the payload, then switches back to the nominal rate for acknowledgment.

That's the whole trick, and it's elegant: the slow part of CAN is slow for a reason, and CAN FD leaves it alone while speeding up the part that has no such constraint.

What you gain

Payload up to 64 bytes instead of 8. Eight times the data per frame, with one set of arbitration, CRC, and acknowledgment overhead instead of eight.

A faster data phase. ISO 11898-2 specifies optional transceiver tiers of up to 2 Mbit/s and up to 5 Mbit/s for the data phase, above the 1 Mbit/s classic maximum. The corresponding bit times are 500 ns and 200 ns, against 1000 ns at 1 Mbit/s.

Those multiply. A large transfer that needed many classic frames becomes far fewer FD frames, each carrying eight times the data at up to five times the rate. Firmware flashing that took an afternoon takes minutes.

Better error detection on large payloads. The CRC is stronger and scaled to the frame size, and FD frames carry a stuff bit count so receivers can verify how many stuff bits were inserted — closing a corner case that a longer frame would otherwise expose.

The frame formats

ISO 11898-1 names each frame format precisely, which is worth knowing because vendor documentation uses these abbreviations:

So CAN FD isn't one frame format but two, mirroring classic CAN's base and extended identifier split. And FD isn't the end of the line — the 2024 edition of the standard added CAN XL, which pushes the payload to 2048 bytes. FD sits in the middle of a three-generation family.

The control bits

Three bits in the FD frame do the work, and they show up in every protocol analyzer:

FDF — FD format indicator. Distinguishes an FD frame from a classic one. This is the bit a receiver uses to know which rules apply to the rest of the frame.

BRS — bit rate switch. Determines whether the data phase actually switches to the faster rate. Set it and the frame accelerates after arbitration; clear it and the whole frame runs at the nominal rate. That's a useful subtlety: you can send a 64-byte FD frame without switching bit rates at all. On a bus where cable length or transceiver quality limits the data-phase rate, you still get the payload benefit.

ESI — error state indicator. Signals whether the transmitting node is error-active or error-passive. Classic CAN gives receivers no way to know a transmitter's error state; FD puts it in the frame. A node quietly degrading toward bus-off announces its condition in every frame it sends — genuinely useful for diagnostics, and something classic CAN never offered.

What FD needs from the physical layer

Faster data phases put demands on the wiring that classic CAN tolerates.

Ringing after edges matters more. At 200 ns bit times, reflections that had settled harmlessly at 1 Mbit/s now overlap the next bit. ISO 11898-2 addresses this with an optional transceiver capability: a low differential internal resistance — typically around 120 Ω — applied briefly after a dominant-to-recessive edge, actively damping ringing rather than waiting it out.

Loop delay eats budget. The transceiver's own loop delay can reach 255 ns. At a 200 ns data bit time, that's more than a full bit consumed inside the silicon before the cable is involved.

Topology discipline tightens. Stub lengths and termination errors that a 250 kbit/s network shrugged off become real at 2 or 5 Mbit/s. The rules in the CAN wiring guide don't change — the tolerance for breaking them does.

The practical takeaway: an existing CAN network doesn't automatically support a fast FD data phase. The wiring gets audited, or the bit rate gets lowered, or BRS stays clear and you take the payload benefit alone.

The compatibility problem

This is the part that catches projects out, and the standard is unusually direct about it.

A classic CAN controller that is not FD-tolerant does not politely ignore FD traffic. It sees a frame it can't parse, concludes the bus is faulty, and transmits error frames — actively destroying the FD communication and driving its own error counters up.

One legacy node can therefore break an entire FD network.

ISO 11898-1 lists five implementation options for a controller, ranging from classic-only through classic-plus-FD-tolerant to full classic + FD + XL support. Its guidance is plain: nodes implementing the full set can communicate with all other nodes, which is why that's the recommendation for new designs.

Three practical rules follow:

"Supports CAN" is not "tolerates CAN FD." Check the datasheet for explicit FD tolerance before mixing generations on one bus.

FD-tolerant is not FD-capable. A tolerant classic node ignores FD frames without complaining — it still can't send or receive them. That's the right property for a legacy device on a mixed bus, and it isn't an upgrade.

Mixed-generation buses are a design decision, not an accident. If legacy nodes must stay, every one of them needs verified tolerance, and the network design should assume classic frames continue alongside FD.

CAN FD light

Added in the 2024 edition of ISO 11898-1, CAN FD light targets the low end: simple sensors and actuators too cost-sensitive for a full CAN FD controller.

It works on a commander/responder model. A commander node controls communication; responder nodes implement a reduced protocol and answer rather than initiate. The responder silicon is smaller and cheaper than a full FD controller, while sitting on the same physical bus alongside full FD nodes.

The trade is autonomy. Responders don't arbitrate for the bus on their own initiative in the way a full node does, so CAN FD light suits star-of-sensors topologies rather than peer-to-peer control networks. Where it fits, it puts CAN FD into device classes that previously couldn't justify it.

Should you use CAN FD?

Yes, when payloads exceed 8 bytes and you're currently fragmenting across frames; when bulk transfers like firmware updates are painful; when bus load is high and consolidating messages would relieve it; or when you want ESI's transmitter-error-state visibility for diagnostics.

Reconsider when the network has legacy classic nodes that aren't FD-tolerant and can't be replaced; when the existing wiring wouldn't support a fast data phase and re-cabling isn't justified; or when the higher-layer protocol in use hasn't adopted FD in the profile you need.

A middle path worth knowing: run FD frames with BRS clear. You get 64-byte payloads at the nominal bit rate, on wiring that never has to change. Fewer frames, same physical layer, no data-phase risk.

FAQ

What does FD stand for? Flexible data rate — the frame's ability to switch to a faster bit rate for the data phase and back for acknowledgment.

Is CAN FD backward compatible with classic CAN? Only in one direction. FD controllers handle classic frames. Classic controllers handle FD frames only if they're explicitly FD-tolerant; if they aren't, they generate error frames and disrupt the bus.

How much data can a CAN FD frame carry? Up to 64 bytes, against 8 for classic CAN.

How fast is CAN FD? Arbitration stays at the nominal rate, up to 1 Mbit/s. The data phase can use optional transceiver tiers of up to 2 Mbit/s or up to 5 Mbit/s. Achievable rate depends on topology, cable, and transceiver quality.

Can I use CAN FD on existing wiring? Sometimes. The payload benefit works on any compliant bus. A fast data phase demands better topology discipline, since stub reflections and termination errors that were harmless at low rates become bit errors at 200 ns. Audit before committing, or send FD frames with BRS clear.

What is the ESI bit for? It tells receivers whether the transmitting node is error-active or error-passive. Classic CAN offered no such visibility, so a node degrading toward bus-off was invisible until it dropped off. FD makes that state observable in every frame.

What is CAN XL? The next generation after FD, added in the 2024 edition of the standard: up to 2048 data bytes per frame, with the bit rate switched around the data phase and fields identifying the higher-layer protocol inside the frame itself.

Do CANopen and J1939 support CAN FD? Both have FD-capable variants, but adoption varies by profile and device generation. Check what your specific devices implement rather than assuming the higher-layer protocol's support extends to the products in front of you.