More data per frame, sent faster — but the parts of classic CAN that make it reliable didn't change.
Classic CAN caps a frame's payload at 8 bytes and its bit rate at 1 Mbit/s. As vehicles added more signals per message and more electronically-controlled systems generally, 8 bytes started forcing awkward workarounds — splitting related signals across multiple messages, or leaning on ISO-TP segmentation (see OBD-II & UDS Diagnostics) for things that aren't really multi-frame diagnostic transfers. CAN FD (Flexible Data-Rate), standardised as ISO 11898-1, raises the payload ceiling to 64 bytes and allows part of the frame to run at a higher bit rate.
| Classic CAN | CAN FD | |
|---|---|---|
| Max payload | 8 bytes | 64 bytes |
| Payload byte counts | 0-8 (any value) | 0-8, then 12, 16, 20, 24, 32, 48, 64 |
| Arbitration phase bit rate | up to 1 Mbit/s | same as classic (typically 500 kbit/s or 1 Mbit/s) |
| Data phase bit rate | n/a | typically 2-8 Mbit/s |
| CRC | 15-bit | 17-bit or 21-bit (longer, to keep error detection strong over more data) |
The arbitration phase — the identifier and the priority contest described in CAN Bus Fundamentals — runs at the same speed as classic CAN, unchanged. Only the data phase, once one node has already won arbitration and is transmitting alone, switches to the higher bit rate. This is why it's called a bit-rate switch, not simply a faster bus: arbitration has to stay at a speed every node can reliably sample, but once there's exactly one transmitter and no more contention to resolve, that constraint no longer applies.
A CAN FD-capable logger needs the wider payload and the dual bit-rate handled at the hardware/driver level, not just in software - an interface built only for classic CAN's 8-byte, single-rate frames physically can't capture an FD frame correctly. DBC decoding concepts carry over unchanged (see DBC Files & Signal Decoding) - the extension used for FD-aware databases is typically .dbc with wider payload support in the parsing tool, or the newer ARXML/CDD formats for more complex projects.
CAN FD capture and decoding is part of the roadmap for the ONAC platform's hardware backends - the same underlying capture/decode architecture in ONAC Network Studio extends to it without a different mental model, since arbitration, identifiers, and DBC-based decoding all work the same way described above.