CAN vs CAN FD: the differences explained simply
Same wiring, same idea, more headroom. Here is what actually changed when CAN FD arrived, in plain terms, with the parts you can click and try.
CAN FD is an upgraded version of the original CAN bus. It does two things the classic version could not: it carries more data in a single message (up to 64 bytes instead of 8), and it can send that data faster by briefly speeding up once a message has won its slot on the bus. The wiring, the connectors and the basic way nodes take turns are unchanged, which is why most teams can move to CAN FD without rebuilding their network from scratch.
| Feature | Classical CAN (CAN 2.0) | CAN FD |
|---|---|---|
| Data per message | Up to 8 bytes | Up to 64 bytes |
| Speed | One bit rate, up to 1 Mbit/s | Two rates: arbitration up to 1 Mbit/s, data phase commonly 2 to 5 Mbit/s, 8 Mbit/s with capable transceivers |
| Identifiers | 11-bit or 29-bit | 11-bit or 29-bit, same as before |
| Remote frames | Supported (RTR) | Not supported |
| Error checking | 15-bit CRC | 17 or 21-bit CRC, plus a stuff-bit count |
| Compatibility | Cannot read CAN FD frames | Can read classical CAN frames |
What CAN bus is, in one minute
CAN bus is a way for the small computers inside a vehicle or machine, the ECUs, to talk to each other over a single shared pair of wires. Instead of running a separate cable between every module, every module listens to the same line and takes turns to speak. This is what saved cars from needing miles of wiring as they gained more electronics.
Because everyone shares one line, there has to be a rule for who speaks when two modules start at once. That rule is called arbitration, and it works by priority: the message with the more urgent identifier wins and keeps going, while the others wait and try again. No data is lost, and the higher-priority message is never delayed. If you want the full picture, start with our guide to understanding the CAN bus.
The original version, now called Classical CAN or CAN 2.0, served the industry well for decades. But modern vehicles generate far more data, and engineers began to hit two ceilings: messages were capped at 8 bytes, and the whole network was capped at 1 Mbit/s. CAN FD was built to lift both ceilings while keeping everything else familiar.
What CAN FD adds
The "FD" stands for Flexible Data-rate. Bosch, the original creators of CAN, introduced it and it was standardised as part of ISO 11898-1 in 2015. Three changes do most of the work.
Bigger messages
A single CAN FD frame carries up to 64 bytes, eight times the classic limit of 8. More information per message means fewer messages overall.
A faster data phase
CAN FD can switch to a higher speed for the part of the message that carries the actual data, then drop back down. The slow part stays slow on purpose.
Better efficiency
Carrying more data per message cuts the share spent on overhead, and a longer CRC plus a stuff-bit count improves the chance of catching corrupted data.
Everything else, the physical wires, the voltage levels, the connectors and the priority-based arbitration, stays the same. That is the point. CAN FD is an evolution, not a replacement.
The clever bit: two speeds in one message
Here is the part that confuses people. If CAN FD is faster, why does it not just run fast the whole time? The answer is arbitration, the rule for who speaks first.
When several nodes might start talking at the same instant, every node on the bus has to be able to hear each bit and react in time to know whether it has won or lost its slot. That listening takes time, and it sets a speed limit. On a typical bus that limit is around 1 Mbit/s, and pushing past it would mean nodes at the far end of the wiring could not keep up.
Slow to agree who talks. Fast to send the data.
CAN FD's trick is to keep the start of the message, the part where arbitration happens, at the safe slow speed. Once a single node has won and everyone else has backed off, nobody needs to interrupt any more. So for the data-carrying part of the message, CAN FD flips a switch and speeds up. When the data is done, it drops back to the slow speed for the acknowledgement. That switch is a single bit in the frame called the BRS, the Bit Rate Switch.
Why a bigger payload matters
Every message on the bus carries a fixed amount of overhead: the identifier, the control bits, the error check and the housekeeping at each end. That overhead is roughly the same whether the message carries 1 byte or 64. So the more useful data you fit into each message, the smaller the share wasted on overhead, and the fewer messages you need to send in the first place.
Think of it as the difference between one lorry and eight vans. Sending the same goods in one larger vehicle means one set of paperwork and one trip, not eight. On a busy bus, fewer messages means more room for everything else and less chance of an important message having to wait.
Are CAN and CAN FD compatible?
Mostly, and in one direction. A CAN FD controller can understand classical CAN messages, so it happily works on an older network. This is what people mean when they say CAN FD is downward compatible.
The catch is the other way round. A controller that only speaks classical CAN does not recognise a CAN FD frame, and seeing one on the shared bus will make it report an error. So you cannot simply drop one CAN FD device onto a bus full of classical-only devices and expect peace. Every node that shares the wire needs to at least tolerate CAN FD traffic.
In practice, fleets and platforms move across in stages. During the transition it is common to keep some subsystems on classical CAN and bridge them to a CAN FD section with a gateway, which translates between the two. The takeaway: CAN FD is designed to ease the migration, but the whole bus still has to agree on the rules.
CAN FD reads classical CAN. Classical CAN cannot read CAN FD. Plan any mixed bus around that single fact.
When to use Classical CAN, and when to use CAN FD
Neither is simply better. They suit different jobs, and plenty of real networks run both.
Classical CAN
- Your messages are small and infrequent, such as a switch state or a temperature reading.
- You are working with existing hardware or a legacy platform that is already proven.
- You have many simple nodes and modest bandwidth needs, where the 8-byte limit is never a constraint.
CAN FD
- You move larger blocks of data, such as detailed sensor sets or structured diagnostic responses.
- You flash firmware or transfer files over the network, where a 64-byte payload and a fast data phase save real time.
- Your bus is getting busy and you need to fit the same traffic into fewer messages to keep latency under control.
CAN vs CAN FD FAQ
Is CAN FD faster than CAN?
Yes, for the data-carrying part of a message. Classical CAN runs at a single bit rate of up to 1 Mbit/s. CAN FD keeps that rate for arbitration, then speeds up the data phase, commonly to 2 to 5 Mbit/s and up to 8 Mbit/s with capable transceivers. Combined with its larger payload, that gives a much higher real throughput.
What is the maximum payload of CAN FD?
64 bytes per frame, compared with 8 bytes for Classical CAN. CAN FD supports a fixed set of sizes: 0, 8, 12, 16, 20, 24, 32, 48 and 64 bytes.
Is CAN FD backward compatible with CAN?
It is downward compatible: a CAN FD controller can read classical CAN messages. The reverse is not true. A classical-only controller cannot read CAN FD frames and will flag an error if it sees one, so every node on a shared bus must be able to tolerate CAN FD traffic.
Can CAN and CAN FD be on the same bus?
Yes, if every device on the wire can at least handle CAN FD frames, or if classical sections are separated by a gateway that translates between the two. You cannot mix a CAN FD device directly into a bus of classical-only devices without errors.
What does BRS mean in CAN FD?
BRS is the Bit Rate Switch, a single bit in the CAN FD frame. When it is set, the controller speeds up for the data phase of the message, then returns to the slower arbitration rate for the acknowledgement. It is the mechanism that lets one message use two different speeds.
Does CAN FD replace CAN?
Not entirely. CAN FD is an evolution of the same protocol on the same wiring, and many networks still use Classical CAN for simple, low-bandwidth signals. CAN FD is chosen where larger payloads or higher throughput are needed, and the two often coexist on the same vehicle or machine.
Written by the engineering team at Influx Technology. Specifications reflect ISO 11898-1. Always confirm bit rates and payload settings against your own hardware and configuration.
Recording Classical CAN and CAN FD
Whether your network runs classical CAN, CAN FD or a mix of the two, the data loggers from Influx Technology, including the REXGEN and REBEL ranges, capture both. REXDESK and DIALOG handle the decoding from your DBC files, so signals arrive as engineering values rather than raw frames.
