Direkt zum Inhalt
[Fundamentals · 03]

Classic CAN vs CAN FD: what changed, what did not, and what comes next

CAN FD keeps everything that made CAN dependable, from arbitration to error handling, and changes only what held it back: an eight-byte payload and a bit rate tied to bus length. Knowing exactly where the two generations differ is now essential for anyone who works on vehicles built in recent years.

Reading time
13 min
Updated
7. Oktober 2026
Diagrams
02
Sections
11

This article is not yet available in your language and is shown in English.

Why CAN needed a second generation

Classical CAN was designed in the 1980s for a handful of ECUs exchanging short control values. Two of its limits became binding as vehicles grew more complex. The first is payload: with eight data bytes per frame, anything larger, from a software download to a diagnostic response, must be split into many frames that each pay 44 to 64 bits of protocol overhead. The second is speed: classical CAN cannot exceed 1 Mbit/s, and real vehicle networks rarely run above 500 kbit/s, because during arbitration every bit must make a round trip across the bus before it is sampled.

New demands made those limits painful. Driver-assistance functions exchange larger data sets; security requirements such as UN Regulation No. 155 have pushed manufacturers towards authenticated in-vehicle messages, whose authentication codes need room in every frame; and reprogramming dozens of ECUs in the workshop takes far longer over eight-byte frames. Bosch published CAN FD (flexible data rate) in 2012, and ISO standardised it in ISO 11898-1:2015.

What stays the same

CAN FD is an evolution, not a new network. All of the following carries over unchanged:

  • The medium: the same twisted pair, the same 120 Ω termination and the same recessive and dominant voltage levels described in CAN physical layer.
  • Arbitration: identifiers are still 11 or 29 bits, still resolved bit by bit, still non-destructive, and always at the nominal bit rate.
  • Acknowledgement, error signalling and fault confinement: the same error types, error flags, counters and bus-off rules as in CAN frames and arbitration.
  • Higher layers: ISO 15765-2 transport, UDS and J1939 run over CAN FD with adaptations for larger frames rather than redesigns.

The CAN FD frame, bit by bit

The visible differences sit in the control field, where classical CAN had reserved bits to spare:

Table 01Control bits in classical CAN and CAN FD
BitClassical CANCAN FD
RTR / RRSRTR: dominant in data frames, recessive in remote framesRRS: always dominant; CAN FD has no remote frames
IDEDominant for 11-bit, recessive for 29-bit identifiersUnchanged
r0 / FDFDominant (reserved)Recessive: marks an FD frame (called EDL in early documents)
res—Reserved, dominant
BRS—Recessive: switch to the data bit rate; dominant: stay at the nominal rate
ESI—Dominant: transmitter error active; recessive: error passive
DLC4 bits, 0–8 bytes4 bits, 0–64 bytes

FDF: announcing the new format

The FD format bit sits where classical CAN has its reserved bit r0, but it is sent recessive. A CAN FD controller reads it and switches to the FD frame layout. A classical controller accepts either level in that reserved position, keeps reading the following bits as a DLC and data, and inevitably runs into an error further on, most often because the data phase is faster than it can follow. It then transmits an error flag that destroys the FD frame for every node. That single fact is the root of every coexistence question covered below.

BRS: switching the bit rate

If BRS is recessive, every node switches from the nominal to the data bit rate at the sample point of the BRS bit and back again at the sample point of the CRC delimiter. Everything in between, the ESI bit, DLC, data and CRC field, travels at the faster rate. This data phase needs no round trip across the bus, because only one node is transmitting and the others are listening, so its speed is limited by signal quality rather than by bus length. Frames sent with BRS dominant run entirely at the nominal rate and still benefit from the larger payload.

Fig. 01Interactive
Payload · bytes
Arbitration rate · kbit/s
Data rate · Mbit/s
Classic CAN · Frames
8
Classic CAN · Transfer time
1.776µs
CAN FD · Transfer time
335µs
faster
×5,3

Approximate figures for an 11-bit identifier, without stuff bits.

Fig. 01A CAN FD frame with BRS set: arbitration and acknowledgement at the nominal bit rate, the data phase at the faster data bit rate.

ESI: error state in every frame

The error state indicator lets every receiver see whether the transmitter is error active (ESI dominant) or error passive (ESI recessive). In classical CAN that information never left the node. Gateways and network monitoring can use it to spot a degrading node long before it reaches bus-off.

Payload sizes and the DLC

CAN FD keeps the four-bit DLC but uses the codes that classical CAN treated as 8 bytes to reach longer payloads in coarser steps:

Fig. 02
In classic CAN, codes 9 to 15 still carry 8 bytes. CAN FD uses them for 12 to 64 bytes.
DLCBinaryClassic CANCAN FDClassic CAN / CAN FD
0000000
1000111
2001022
3001133
4010044
5010155
6011066
7011177
8100088
91001812
101010816
111011820
121100824
131101832
141110848
151111864

In classic CAN, codes 9 to 15 still carry 8 bytes. CAN FD uses them for 12 to 64 bytes.

Fig. 02Data length codes 0–15 and the payload sizes they represent in classical CAN and CAN FD.
Table 02DLC to payload mapping
DLCClassical CAN (bytes)CAN FD (bytes)
0–80–80–8
9812
10816
11820
12824
13832
14848
15864

A payload that falls between two sizes is padded up to the next one: 30 bytes travel in a 32-byte frame with two padding bytes, and 50 bytes in a 64-byte frame with 14. Communication designers therefore lay out their messages around the available sizes, and the padding value is defined in the network specification.

Higher layers adapted accordingly. ISO 15765-2 carries up to 62 bytes of diagnostic data in a single unsegmented CAN FD frame, where classical CAN fits 7, and SAE J1939-22 packs several parameter groups into one FD frame.

Stronger error detection

A longer frame needs a stronger checksum. CAN FD selects its CRC by payload size and changes how stuffing and the CRC interact:

Table 03Error-detection features compared
FeatureClassical CANCAN FD (ISO 11898-1:2015)
CRCCRC-15CRC-17 up to 16 data bytes; CRC-21 above 16 bytes
Stuff bits in the CRC calculationExcludedDynamic stuff bits included
Stuff bit countNone3-bit Gray-coded count (modulo 8) plus a parity bit
Stuffing in the CRC fieldDynamic, as in the rest of the frameFixed stuff bits: one at the start, then one after every four bits
Fixed stuff bits in the CRC field—6 with CRC-17, 7 with CRC-21
Formula
CRC-17: x¹⁷ + x¹⁶ + x¹⁴ + x¹³ + x¹¹ + x⁶ + x⁴ + x³ + x + 1 · CRC-21: x²¹ + x²⁰ + x¹³ + x¹¹ + x⁷ + x⁴ + x³ + 1
Generator polynomials of CAN FD (0x3685B and 0x302899).

The stuff bit count closes a known weakness of classical CAN, in which two bit errors that create or remove stuff bits can shift the frame in a way the CRC may not catch. The fixed stuff bits make the length of the CRC field independent of its content.

Data-phase bit rates: 2, 5 and 8 Mbit/s

With arbitration out of the way, the data phase is limited by how cleanly a bit survives the trip between transceivers: ringing from stubs and star points, asymmetry between rising and falling edges, and the transceivers' own delays. Typical combinations:

Table 04Common CAN FD bit-rate combinations
Nominal / data rateData bit timeTypical use
500 kbit/s / 2 Mbit/s500 nsMainstream passenger-car networks (SAE J2284-4 bus-line networks); heavy-duty networks under SAE J1939-17 and J1939-22
500 kbit/s / 5 Mbit/s200 nsPoint-to-point links (SAE J2284-5) and networks with signal-improvement transceivers
500 kbit/s / 8 Mbit/s125 nsShort, carefully designed networks, typically with signal-improvement transceivers

Two techniques make the higher rates practical. Transmitter delay compensation (TDC): at 5 Mbit/s a data bit lasts 200 ns, comparable to the delay from the controller's TXD pin through the transceiver and back to RXD. The transmitter would read back each of its own bits too late to check it, so it measures this loop delay at the start of the data phase and checks each bit at a secondary sample point shifted by that amount. CAN in Automation's CiA 601-3 recommends enabling TDC for data rates above 1 Mbit/s.

Signal improvement capability (SIC): SIC transceivers actively damp the ringing after a dominant-to-recessive transition by briefly presenting a matched impedance to the bus. That suppresses reflections in topologies with stars or long stubs which would otherwise limit the data phase to lower rates. SIC was first specified by CAN in Automation and is now part of ISO 11898-2:2024.

Bit-timing discipline also matters more than in classical CAN. CiA 601-3 recommends CAN clocks of 20, 40 or 80 MHz, the same time-quantum length in both phases, identical sample points in all nodes and, for automotive networks, a nominal sample point no later than 80 %.

Worked example: moving 64 bytes

How much faster is CAN FD in practice? Take 64 bytes of payload on a network with a 500 kbit/s nominal rate and count the bits, ignoring dynamic stuff bits, which add a few percent in every case:

  1. 01
    Classical CAN

    Eight base-format frames of 8 bytes, each 111 bit times including intermission: 888 bits at 2 µs = 1,776 µs.

  2. 02
    CAN FD without bit-rate switch

    One frame: about 30 bits for arbitration, acknowledgement, end of frame and intermission, plus 549 bits from ESI to the end of the CRC field (ESI 1, DLC 4, data 512, stuff count 4, CRC 21, fixed stuff bits 7). 579 bits at 2 µs = 1,158 µs.

  3. 03
    CAN FD with a 2 Mbit/s data phase

    The 30 nominal bits take 60 µs; the 549 data-phase bits at 0.5 µs take 274.5 µs. Total ≈ 335 µs.

  4. 04
    CAN FD with a 5 Mbit/s data phase

    60 µs + 549 × 0.2 µs ≈ 170 µs.

Table 05Time to move 64 bytes at a 500 kbit/s nominal rate (approximate, without dynamic stuff bits)
ConfigurationFramesTimeEffective payload rateRelative to classical CAN
Classical CAN81,776 µs0.29 Mbit/s1.0×
CAN FD, no BRS11,158 µs0.44 Mbit/s1.5×
CAN FD, 2 Mbit/s data phase1335 µs1.53 Mbit/s5.3×
CAN FD, 5 Mbit/s data phase1170 µs3.02 Mbit/s10.5×

The larger payload alone brings a modest gain; the step change comes from the data phase. The numbers matter for latency too: a full 64-byte FD frame with a 2 Mbit/s data phase occupies the bus for about 335 µs, only slightly longer than one worst-case 8-byte classical frame at 500 kbit/s (270 µs). Larger frames do not have to mean longer blocking times for urgent traffic.

Mixing classical and FD nodes

Because a classical controller cannot follow an FD frame and destroys it with an error flag, a network that carries FD frames must not contain active classical CAN controllers. Manufacturers resolve this in four ways:

  • All-FD segments: every node uses an FD-capable controller, including nodes that only ever send classical frames. FD controllers handle classical frames natively.
  • Gateway separation: classical and FD networks stay on separate segments, joined by a gateway ECU that routes and repacks data between them; see Vehicle network architecture.
  • FD-passive transceivers: some partial-networking transceivers ignore FD frames while their ECU sleeps, so the sleeping node neither wakes up nor signals errors.
  • Staged migration: an FD-capable network carries only classical frames until every node supports FD, then switches.
  1. 01
    Controller

    Confirm an ISO CAN FD controller (ISO 11898-1:2015 or later), not a classical or non-ISO FD one.

  2. 02
    Transceiver

    Use a transceiver specified for the data rate in use under ISO 11898-2:2016 or later, with timing-symmetry parameters for that rate.

  3. 03
    Bit timing

    Match the network's nominal and data bit rates, sample points and time-quantum settings exactly, and enable transmitter delay compensation above 1 Mbit/s.

  4. 04
    Topology

    Keep the stub to the new device as short as possible. A stub that was harmless at 500 kbit/s can ring straight through a 500 ns data bit.

  5. 05
    Behaviour

    Make sure the device stays silent while the network sleeps and never transmits anything outside the network design.

Beyond FD: CAN XL

The third generation, CAN XL, is specified in ISO 11898-1:2024 alongside classical CAN and CAN FD, with its transceivers in ISO 11898-2:2024. It keeps CAN's arbitration and adds a data phase sized for Ethernet-class payloads:

Table 06Three CAN generations at a glance
PropertyClassical CANCAN FDCAN XL
Payload0–8 bytes0–64 bytes1–2,048 bytes
Data-phase bit rateNo data phase (max 1 Mbit/s)Typically 2–8 Mbit/sUp to 20 Mbit/s with SIC XL transceivers
Priority / identifier11 or 29 bits11 or 29 bits11-bit priority plus a separate 32-bit acceptance field
CRC15 bits17 or 21 bits13-bit header CRC plus 32-bit frame CRC
Protocol layering——8-bit SDU type, 8-bit virtual network ID, security flag
StandardISO 11898-1ISO 11898-1:2015 onwardsISO 11898-1:2024

The SDU type field lets CAN XL carry other protocols' frames, Ethernet frames included, which positions it as a bridge between CAN-based zones and Ethernet backbones in zonal architectures; see Vehicle network architecture. The virtual network ID allows up to 256 logical networks on one physical segment, and CANsec, the security protocol from CAN in Automation, can protect data at the link layer.

ISO 11898-1:2024 also standardises CAN FD Light, a commander/responder variant for simple sensors and actuators that need CAN FD frames but not multi-master arbitration. For vehicles already on the road, classical CAN and CAN FD will remain the reality for many years; CAN XL is an architecture decision for new platforms.

What this means in the field

  • Know the network generation before connecting anything. A classical-only device on a CAN FD network is not merely unable to read the new frames; if it acknowledges or signals errors, it actively destroys them.
  • Look at the whole frame on the scope. An FD frame with BRS set shows a visible change in bit width after the arbitration field: bits four times narrower at 500 kbit/s and 2 Mbit/s.
  • Respect the shorter data bit. Ringing that settles in 300 ns is harmless in a 2 µs nominal bit and fatal in a 200 ns data bit. Stub length and splice quality matter more on FD networks than on any classical CAN bus.
  • Expect mixed vehicles. One car can carry classical CAN on body networks, CAN FD on powertrain and driver-assistance networks, and Automotive Ethernet in the backbone.

Frequently asked questions

Can a CAN FD node talk to a classical CAN node?

Yes, using classical frames: every CAN FD controller also sends and receives classical frames. The reverse is not true. A classical controller cannot receive FD frames and will disturb them.

Does CAN FD need different wiring?

No new cable type: the same twisted pair and 120 Ω termination. What changes is the tolerance for poor topology. Long stubs, star points and untwisted sections that classical CAN forgave can limit the usable data rate.

Is the OBD-II port CAN FD?

Legislated emissions diagnostics under ISO 15765-4 run on classical CAN at 250 or 500 kbit/s. Some manufacturers' own diagnostic communication on newer vehicles uses CAN FD behind the same OBD-II connector. See OBD-II and secure gateways.

What happened to the EDL bit?

EDL (extended data length) was the bit's name in the original Bosch CAN FD documents. ISO 11898-1:2015 renamed it FDF (FD format). It is the same bit.

Will CAN XL replace CAN FD?

Not on existing platforms. CAN XL targets new architectures that need payloads and bit rates between CAN FD and Automotive Ethernet. CAN FD remains the mainstream choice for control networks.

End of articleUpdated 7. Oktober 2026
[Santim SC-1]

Every CAN vehicle. Ready from day one.

Santim SC-1 supports every classic CAN and CAN FD vehicle on the market. When a new vehicle launches, it is compatible instantly. No waiting, no requests. A next-generation CAN device.

The Santim SC-1 CAN device