// blog # CAN FD Explained (2025): Frames, Bit Rates & Migration Tips Learn frame format, bit timing, bandwidth gains and how to migrate from classic CAN to CAN-FD with hardware and software examples. Updated 14 Aug, 2025 [← All posts](https://www.autopi.io/blog/) CAN FD stands for Controller Area Network with Flexible Data-Rate. It is an extension of Classical CAN, made to send more data per frame and allow a faster data phase. At the same time, it keeps the arbitration behaviour that makes CAN useful in vehicle and industrial networks. Classical CAN supports up to 8 data bytes in one frame. CAN FD increases this to 64 bytes. CAN FD can also use a higher bit rate during the data phase, while the arbitration phase still runs at the nominal CAN bit rate. In practice, the actual speed depends on the transceivers, wiring, bus length, topology and EMC requirements. So CAN FD is not only about the protocol. The physical network also matter. CAN FD is relevant where Classical CAN becomes too limited. Typical examples are EV battery systems, powertrain data, diagnostics, gateways, data logging and newer vehicle platforms with higher signal density. It is not a full replacement for Ethernet or CAN. It is more a practical upgrade when more bandwidth is needed, without changing the full network architecture. ## What is CAN FD? CAN FD is an improved version of the CAN protocol. It keeps the same basic idea as CAN. ECUs share a bus, messages are identified by CAN IDs, and arbitration decides which message gets access to the bus first. The main difference is that CAN FD allows a larger payload and a faster data phase. This means the system can move more useful data with fewer frames compared to Classical CAN. ##### Key features of CAN FD - **Larger payload:** CAN FD supports up to 64 bytes per frame, compared with 8 bytes in Classical CAN. - **Higher data-phase speed:** CAN FD can use a faster bit rate after arbitration, often several Mbit/s in networks that support it. - **Same arbitration concept:** Message priority is still based on the CAN identifier. - **Improved error detection:** CAN FD uses updated CRC handling to support the larger payloads. [ Discover the CAN FD Pro ](https://www.autopi.io/hardware/autopi-canfd-pro/) ### Why CAN FD was needed Modern vehicles move more data than older CAN networks were designed for. EV battery systems, ADAS-related controllers, gateways, diagnostics and logging systems all create higher data demands. More signals need to be moved, and often at a higher update rate. Classical CAN is still reliable and widely used. But the 8-byte payload can become inefficient when larger datasets must be moved. CAN FD solves part of this by allowing more bytes per frame and a faster data phase. ## Importance and benefits of CAN FD The main benefit of CAN FD is efficiency. More data can be sent in one frame, so the network needs fewer frames for the same amount of payload data. This is useful when many signals must be transmitted at short intervals. CAN FD also helps when diagnostic or logging systems need to collect larger datasets. Instead of spreading data over many small CAN frames, a CAN FD network can transfer larger payloads more efficient. ##### Practical benefits - **More data per frame:** Useful for battery data, diagnostics, calibration and gateway communication. - **Better bus efficiency:** Larger frames can reduce overhead compared with many small Classical CAN frames. - **Faster data transfer:** The data phase can run faster where the physical network support it. - **Good fit for newer vehicle platforms:** Useful where CAN is still suitable, but Classical CAN is too limited. ### Real-world impact CAN FD is common in systems where Classical CAN does not give enough payload capacity. EV battery management is a good example. A battery pack may need to report voltages, temperatures, state of charge, state of health, limits and diagnostic states. With Classical CAN, this data can require many frames. With CAN FD, more of the data can be grouped into fewer frames. CAN FD is also useful in gateways and data loggers. Gateways may need to collect, translate and forward many signals between networks. Data loggers need to capture high-resolution traffic without dropping important frames. "CAN FD is useful when the amount of vehicle data grows, but the system still needs CAN-style arbitration and predictable behaviour. It gives more payload and better efficiency without moving everything to Ethernet." [Image: Peter Ørts, AutoPi] **Peter Ørts** – CEO at AutoPi.io The [AutoPi CAN FD Pro](https://www.autopi.io/hardware/autopi-canfd-pro/) is built for vehicle data logging and telematics projects where CAN and CAN FD access is required. It can be used to capture raw frames, collect selected signals and forward data to AutoPi Cloud or external systems. [ ](https://www.autopi.io/hardware/autopi-canfd-pro/) [ Discover AutoPi CAN FD Pro ](https://www.autopi.io/hardware/autopi-canfd-pro/) ## How does the CAN FD protocol work? CAN FD uses the same basic bus access method as Classical CAN. When multiple nodes want to transmit, arbitration is performed using the identifier. The message with the highest priority wins access to the bus. The important difference is that a CAN FD frame can switch to a faster bit rate during the data phase. This is called bit rate switching. The arbitration phase stays at the nominal bit rate, so nodes can still arbitrate correctly. 1. ##### Arbitration Nodes compete for bus access using the identifier. Lower numeric identifiers have higher priority, like in Classical CAN. 2. ##### Control and bit rate switching A CAN FD frame can indicate that the data phase should use a higher bit rate. This makes it possible to move the payload faster after arbitration is complete. 3. ##### Larger payload The data field can contain up to 64 bytes, compared with 8 bytes in Classical CAN. 4. ##### CRC and error handling CAN FD includes CRC changes to support the larger payload and improve detection of transmission errors. Errors are detected and signaled, but CAN FD does not correct corrupted payloads in place. Invalid frames are rejected and retransmitted according to CAN error handling rules. 5. ##### Acknowledgement Receivers acknowledge valid frames. If a frame is not acknowledged, or an error is detected, the transmitter retries according to the protocol behaviour. | Step | What happens | Why it matters | | --- | --- | --- | | Arbitration | Nodes use the CAN identifier to decide bus access | Keeps priority handling predictable | | Bit rate switching | The data phase can run faster than arbitration | Transfers payload faster where the network supports it | | Data payload | Up to 64 bytes can be sent in one frame | Reduces the number of frames needed for larger data | | CRC and error handling | Invalid frames are detected and rejected | Helps maintain data integrity on the bus | | Acknowledgement | Receivers acknowledge a valid frame | Confirms that at least one node received the frame correctly | ## Technical overview of CAN FD CAN FD was designed to increase payload capacity and improve data transfer efficiency, while keeping much of the CAN communication model. This makes it useful in systems where CAN is already well understood, but more data needs to be moved. | Feature | CAN FD behavior | Practical note | | --- | --- | --- | | Payload | Up to 64 data bytes per frame | Useful for larger signal groups, diagnostics, and logging | | Bit rate switching | Higher bit rate can be used during the data phase | Actual speed depends on wiring, topology, and transceivers | | Arbitration | Identifier-based arbitration is retained | Priority behavior remains familiar from Classical CAN | | CRC | Updated CRC handling for larger frames | Improves error detection for longer payloads | | Compatibility | CAN FD controllers can usually operate in Classical CAN mode | Classical CAN-only nodes cannot understand CAN FD frames | ## CAN FD vs CAN Classical CAN and CAN FD are closely related, but they are not the same. CAN FD adds larger payloads and the option for a faster data phase. Classical CAN is still widely used because it is simple, proven and enough for many control tasks. For more on the CAN protocol, see the [CAN Bus Guide](https://www.autopi.io/blog/can-bus-explained/). | Feature | Classical CAN | CAN FD | | --- | --- | --- | | Payload | Up to 8 bytes per frame | Up to 64 bytes per frame | | Bit rate | Typically up to 1 Mbit/s | Nominal arbitration bit rate plus faster data phase | | Efficiency | More frames needed for larger data | Fewer frames needed for larger payloads | | Error detection | CAN CRC and standard error handling | Updated CRC handling for longer frames | | Compatibility | Cannot decode CAN FD frames | CAN FD controllers can often be configured for Classical CAN operation | | Typical use | General ECU communication, diagnostics, body and powertrain networks | Higher-data ECU networks, EV systems, gateways, diagnostics, and logging | "Classical CAN is still a very strong protocol, but CAN FD is useful when the amount of data increases. The larger payload and faster data phase make a real difference in logging, diagnostics, and newer vehicle platforms." [Image: Henrik Nilsson, AutoPi] **Henrik Nilsson** – CTO, Founder at AutoPi.io ### When should you consider CAN FD? CAN FD makes sense when Classical CAN becomes a bottleneck. This can happen when the system needs more payload per message, higher logging resolution, faster diagnostics or more efficient gateway communication. It is not always the right answer. If the existing CAN network has low load and the signals fit well into 8-byte frames, Classical CAN may still be enough. If the system needs very high bandwidth, Automotive Ethernet may be more suitable. ## Applications of CAN FD CAN FD is mainly used where CAN-style communication is still useful, but the payload or bandwidth requirements are higher than Classical CAN can handle efficient. ### Automotive applications In vehicles, CAN FD is used in newer ECU networks, EV systems, diagnostics and gateway architectures. It is useful when many parameters need to be exchanged quickly between controllers. Typical automotive use cases include: - **EV battery systems:** Battery management systems can send more cell, temperature, current, voltage and state data in each frame. - **Gateways:** Gateways can collect and forward larger signal groups between vehicle domains. - **Diagnostics:** Diagnostic data can be transferred more efficient than with Classical CAN in systems that support it. - **Data logging:** CAN FD allows higher-volume signal capture for development, testing and fleet data projects. ### Industrial applications CAN FD is also relevant in industrial systems where CAN is already used, but larger payloads or faster updates are needed. This can include machinery, automation systems, mobile equipment and embedded control networks. In these systems, CAN FD can help with faster status updates, richer diagnostics and more efficient communication between controllers and sensors. [ Questions? Get in touch ](https://www.autopi.io/sales-inquiry/) ### Why CAN FD matters for data logging For automotive data loggers, CAN FD support is important because many newer vehicles and machines already use CAN FD on some networks. A logger that only supports Classical CAN may miss important data or fail to decode traffic on those buses. The [automotive data logger](https://www.autopi.io/blog/what-is-automotive-data-loggers/) must match the vehicle network. If the vehicle uses CAN FD, the logger needs CAN FD-capable hardware and the correct bit rate configuration. ## Future of CAN FD CAN FD will continue to be used where moderate bandwidth, deterministic bus behaviour and CAN-style arbitration are needed. It is especially relevant in vehicles and machines that are too data-heavy for Classical CAN, but do not require Ethernet for every control network. Automotive Ethernet is growing in areas such as ADAS, infotainment and central compute. That does not remove the need for CAN FD. In many architectures, CAN FD and Ethernet are used together. Ethernet is used for high-bandwidth backbone communication, and CAN FD is used for local control networks and ECU communication. For telematics and data logging, the practical requirement is clear: hardware must support the networks used by the vehicle. On modern platforms, that often means supporting Classical CAN, CAN FD and sometimes Ethernet or DoIP, depending on the project. ## Conclusion CAN FD extends Classical CAN with larger payloads and a faster data phase. It is useful when vehicle or machine data volumes increase, but the system still benefits from CAN-style arbitration and a shared bus architecture. The main advantages are simple: up to 64 bytes per frame, better efficiency for larger data transfers and support for higher data-phase bit rates where the physical network allows it. For projects involving vehicle data logging, EV battery systems, diagnostics or newer ECU networks, CAN FD support is often required. AutoPi CAN FD Pro is built for these kind of projects, with support for CAN FD data logging and cloud-connected workflows. For CAN FD project requirements, hardware selection, or data logging questions, [contact AutoPi](https://www.autopi.io/sales-inquiry/). [ ](https://www.autopi.io/software-platform/cloud-management/) [ Questions? Get in touch ](https://www.autopi.io/sales-inquiry/) [ ← Back to all posts ](https://www.autopi.io/blog/) // hardware ## Capture data with CAN-FD Pro Evaluate CAN, CAN FD and J1939 logging. Confirm vehicle access, connectors and signal decoding before deployment. [Explore CAN-FD Pro →](https://www.autopi.io/hardware/autopi-canfd-pro/) ###### Hardware ## Choose your evaluation device Start with the hardware your project needs. Software and connectivity terms differ by device and purchase option. Prices below exclude VAT, duties, shipping and optional accessories. CAN-FD Pro In stock · ships tomorrow ### Dual CAN-FD data logger High-throughput raw frame capture on two independent CAN-FD channels. On-device DBC decoding, ASAM MDF4 output, J1939 native support and hardware-encrypted data signing - all on a Raspberry Pi CM4. → 2× CAN-FD · >3,000 fps/channel · 5 Mbps → 4 GB LPDDR4 · 32 GB eMMC + USB expansion → NXP SE051 · Tailscale SSH · Docker · S3 sync → 12–35 V DC · J1939 · OBD-II · 4G/LTE + GPS From EUR 599. AutoPi software included without a subscription. Cellular SIM and data purchased separately. [Order CAN-FD Pro](https://shop.autopi.io/products/autopi-can-fd-pro) [Learn more](https://www.autopi.io/hardware/autopi-canfd-pro/) Mini In stock · ships tomorrow ### Fleet telematics & OBD-II OBD-II and supported EV telemetry with GPS and built-in 4G/LTE. Check your exact vehicle, required signals and regional variant; installation and configuration needs vary. → OBD-II / K-Line · EV parameters · GPS tracking → 4G/LTE Cat 1 · BLE · internal antennas → −40°C to +85°C · CE/UKCA/E-Mark/RoHS → 10–30 V DC · compact · fleet-ready out of box EUR 129 + EUR 6/month for SIM and Cloud, with a 12-month minimum. First-year minimum: EUR 201. Includes 100 MB/month. [Order Mini](https://shop.autopi.io/products/autopi-mini) [Learn more](https://www.autopi.io/hardware/autopi-mini/) TMU CM4 In stock · ships tomorrow ### Edge compute platform Raspberry Pi CM4-based telematics unit for custom software stacks. Run Docker containers, Python services and CAN-FD logging on the same device - managed remotely via AutoPi Cloud. → BCM2711 CM4 · 1 GB LPDDR4 · 8 GB eMMC → 2x CAN or CAN-FD variant · Docker · Python · SocketCAN → NXP SE051 · Tailscale · WiFi · BT 5.0 · GPS → 12–35 V DC · 4G/LTE Cat 4 · IP67 option From EUR 235 with the SIM and Cloud subscription option: EUR 6/month, 12-month minimum. Also available without a subscription; select your interface and payment option in the shop for the price. [Order TMU CM4](https://shop.autopi.io/products/autopi-telematics-unit-cm4-4g-lte-edition) [Learn more](https://www.autopi.io/hardware/autopi-tmu-cm4/) [Compare all devices →](https://www.autopi.io/hardware/compare/) // related ## More posts you'll like [ View all → ](https://www.autopi.io/blog/) Raspberry Pi DIY #### Build a Raspberry Pi Touchscreen Car Computer (Step-by-Step) Assemble a Pi-based carputer with touchscreen, power, mounting and software setup. Parts list, wiring tips and configuration for a reliable in-car sys ... [ Learn More → ](https://www.autopi.io/blog/build-a-raspberry-pi-touch-screen-car-computer/) Guides #### J1939 Explained (2025): PGNs, SPNs & Heavy-Duty Diagnostics Learn J1939 basics‚ PGNs, SPNs, addressing and tools for heavy-duty trucks and machinery. Examples and troubleshooting tips included. [ Learn More → ](https://www.autopi.io/blog/j1939-explained/) Guides #### CAN Bus Explained (2025): Frames, Arbitration & Tools Understand identifiers, arbitration, error handling and analyzers used in automotive systems. Practical examples and diagrams. [ Learn More → ](https://www.autopi.io/blog/can-bus-explained/) // contact ## Still have questions? Get in touch with us - we're ready to answer any and all questions. // send a message We aim to reply within one business day. Or email [sales@autopi.io](mailto:sales@autopi.io).