FAQ
CAN FD & J1939 Fleet Telematics FAQ
Questions from engineers, product managers, and commercial leads evaluating CAN FD solutions for fleet telematics. Organized by topic; use the links below to jump to a section.
CAN FD foundational questions
What is CAN FD?
CAN FD (Controller Area Network with Flexible Data-Rate) is an extension of the Classic CAN protocol developed by Bosch and standardized in ISO 11898-1. It supports data payloads of up to 64 bytes per frame (versus 8 bytes in Classic CAN) and data-phase bit rates of up to 5-8 Mbps (versus 1 Mbps in Classic CAN). CAN FD is used extensively in modern passenger vehicles, electric vehicles, and newer heavy-duty platforms.
What does CAN FD stand for?
CAN FD stands for "Controller Area Network with Flexible Data-Rate." The "Flexible Data-Rate" refers to the ability to switch to a higher bit rate during the data phase of a frame while keeping the arbitration phase at standard Classic CAN speeds.
How is CAN FD different from Classic CAN?
The two main differences are payload size and bit rate. Classic CAN is limited to 8-byte payloads and 1 Mbps. CAN FD supports up to 64-byte payloads and data-phase bit rates commonly running at 2-5 Mbps (theoretically up to 8-20 Mbps). CAN FD also uses an improved CRC and a Bit Rate Switch (BRS) bit to signal the speed change. Arbitration still happens at the Classic CAN rate, preserving priority-based bus access.
Who developed CAN FD?
Bosch developed CAN FD and introduced it publicly in 2012. It is standardized under ISO 11898-1:2015 and later revisions.
What is ISO 11898-1?
ISO 11898-1 is the international standard that defines the CAN data-link layer, including both Classical CAN and CAN FD frame formats. The 2015 revision is the one that formally incorporated CAN FD.
Is CAN FD the same as CAN XL?
No. CAN XL is a third-generation CAN protocol, also from Bosch, supporting payloads up to 2048 bytes and bit rates up to 10-20 Mbps. CAN XL is newer than CAN FD and not yet widely deployed; CAN FD is the current standard in modern production vehicles.
Compatibility and interoperability
Is CAN FD backward compatible with Classic CAN?
Partially. A CAN FD controller can receive Classic CAN frames without issue. The reverse is not true: a Classic CAN controller receiving a CAN FD frame will flag it as an error, enter error states, and eventually stop communicating. CAN FD is backward compatible; Classic CAN is not forward compatible with CAN FD.
Can Classic CAN and CAN FD devices share the same bus?
Only in a restricted way. A CAN FD node can transmit Classic CAN-format frames on a mixed bus, but if any FD-format frame is transmitted while a Classic CAN node is listening, the Classic CAN node will generate error frames and ultimately disconnect from the bus. In practice, mixed networks require a gateway or translator.
What happens if a Classic CAN node receives a CAN FD frame?
The Classic CAN controller interprets the frame as malformed and transmits error frames onto the bus. Repeated errors push the node through the error-active, error-passive, and bus-off states, at which point it stops communicating.
Do I need new transceivers for CAN FD?
Yes, if you want to operate at the higher data-phase bit rates. Classic CAN transceivers are typically rated for up to 1 Mbps. CAN FD requires transceivers rated for the target data-phase bit rate (2, 5, or 8 Mbps depending on the implementation).
Can a CAN FD to Classic CAN bridge translate data between the two?
Yes, with a caveat on payload. A bridge extracts signals from CAN FD frames and re-encodes them into J1939 Classic CAN frames for downstream devices. Because Classic CAN frames carry only 8 bytes of payload, a single 64-byte CAN FD frame may need to be split across multiple Classic CAN frames, or filtered to the signals the downstream device actually needs. Purpose-built bridges - the Nexum Fleet CAN FD bridge is one example - handle this translation in real time without losing the signals the telematics device cares about.
CAN FD technical specifications
What is the maximum data rate of CAN FD?
The ISO 11898-1 specification allows up to 8 Mbps in the data phase, though most production implementations run at 2 Mbps. The arbitration phase remains at Classic CAN rates, typically 500 kbps or 1 Mbps.
What is the maximum payload of a CAN FD frame?
64 bytes, compared to 8 bytes for Classic CAN. Supported payload lengths are 0, 1, 2, 3, 4, 5, 6, 7, 8, 12, 16, 20, 24, 32, 48, and 64 bytes.
What is the Bit Rate Switch (BRS) bit?
The BRS bit is a single bit in the CAN FD frame header that signals whether the data phase of the frame should transmit at the higher data-phase bit rate or remain at the arbitration-phase rate. When BRS is set, the transceiver and controller switch to the faster rate after arbitration completes.
What is the difference between the arbitration phase and the data phase in CAN FD?
The arbitration phase is the beginning of the frame where nodes compete for bus access using message priority; it runs at Classic CAN speeds (typically 500 kbps-1 Mbps) to preserve compatibility and signal integrity across the full bus. The data phase is the portion of the frame after arbitration; in CAN FD, it can run at a higher bit rate (2-8 Mbps) because only one node is transmitting.
How does the CRC differ in CAN FD?
CAN FD uses a longer CRC (17-bit for payloads up to 16 bytes, 21-bit for payloads over 16 bytes) compared to Classic CAN's 15-bit CRC. This improves error detection at the longer payloads and higher bit rates CAN FD supports.
J1939 and J1939-22
Does J1939 support CAN FD?
Yes. SAE released J1939-22 in 2020-2021 to define how J1939 runs on CAN FD. Classic J1939 continues to run on Classic CAN (J1939-11 at 250 kbps, J1939-17 at 500 kbps). J1939-22 is the CAN FD variant.
What is J1939-22?
J1939-22 is the SAE specification for running the J1939 heavy-duty vehicle protocol on a CAN FD bus. It defines new frame formats, multi-PG (Parameter Group) packing within a single CAN FD frame, and extended addressing suitable for the larger payload. Read more on our J1939-22 explainer.
Is J1939 being replaced by CAN FD?
No - J1939 is being extended onto CAN FD via J1939-22. The semantic layer (PGNs, SPNs, parameter definitions) carries over. What changes is the underlying transport and frame format. Existing J1939 signal libraries remain largely relevant.
Are PGN and SPN definitions the same in J1939-22?
Largely yes at the semantic level, but the frame packing is different. J1939-22 allows multiple PGs (Parameter Groups) to be packed into a single CAN FD frame, which is not possible in Classic J1939. Decoders must be updated to handle multi-PG frames, but the underlying parameter definitions are preserved.
Can a legacy J1939 telematics device read data from a J1939-22 bus?
Not directly. A Classic CAN controller cannot decode CAN FD frames at the data-link layer, regardless of the higher-layer protocol. The practical path is to pair the existing telematics device with a CAN FD bridge installed alongside it on the J1939-22 vehicle. The bridge reads J1939-22 traffic from the CAN FD bus and re-emits the relevant PGs as J1939 Classic CAN frames the existing device already understands. Nexum Fleet is a CAN FD bridge built for this purpose. Read more on our J1939-22 explainer.
What is the typical J1939 baud rate?
J1939-11 specifies 250 kbps on Classic CAN. J1939-17 specifies 500 kbps on Classic CAN. J1939-22 uses CAN FD bit rates, typically 500 kbps arbitration and 2 Mbps data phase.
Electric vehicles and modern platforms
Do electric vehicles use CAN FD?
Most modern electric vehicles use CAN FD on at least some of their internal networks, particularly for battery management, high-voltage control, and ADAS-related buses. Older EV platforms and lighter-duty EVs may still use Classic CAN. The mix varies by manufacturer and model year.
Why are EV platforms moving to CAN FD?
EVs generate substantially more real-time data than ICE vehicles - battery cell voltages, temperatures, state-of-charge, state-of-health, regenerative braking, motor torque, thermal management - which exceeds the bandwidth a single Classic CAN bus can carry efficiently. CAN FD's 64-byte payload and higher data-phase bit rate handle this volume without requiring a full move to Automotive Ethernet.
Do heavy-duty electric trucks use J1939-22?
Adoption is still early. Some OEMs are extending Classic J1939 with manufacturer-specific PGNs to cover EV parameters; others are moving to J1939-22 on CAN FD; a few are using proprietary buses entirely. This inconsistency is a significant challenge for telematics providers working with mixed fleets.
Is there a standard for EV telematics data?
Not a universal one. Classic J1939 covers ICE heavy-duty parameters well but has no native coverage for EV-specific signals (SOC, SOH, battery temperature per cell, etc.). J1939-22 extends the framework but vendor adoption is uneven. In practice, telematics providers maintain their own signal libraries that combine standard PGNs with vendor-specific decodings.
CAN FD solutions and telematics
Can my existing J1939 telematics device read data from a CAN FD vehicle?
Not directly. A Classic CAN controller physically cannot decode CAN FD frames at the data-link layer, no matter how well the upstream firmware understands J1939. The practical path is to pair the existing telematics device with a CAN FD bridge installed alongside it on the new CAN FD vehicle. The bridge reads the vehicle's CAN FD or J1939-22 traffic, translates the relevant signals into J1939 Classic CAN frames the telematics device already understands, and delivers them via a standard J1939 Classic CAN connection. Nexum Fleet is a CAN FD bridge built for this purpose.
How do I provide CAN FD support into a legacy telematics tracker?
The most cost-effective approach is a CAN FD bridge that installs alongside the existing telematics device, reads the CAN FD bus directly, and presents translated J1939 Classic CAN frames to the Classic CAN controller. This avoids redesigning the telematics device, avoids backend changes, and avoids any engineering integration on the TSP side. Nexum Fleet is a CAN FD bridge built for this purpose - including support for J1939-22 multi-PG frames and over-the-air signal library updates, so new vehicle platforms can be added without further hardware changes.
What is a CAN FD bridge?
A CAN FD bridge is a standalone hardware unit that reads CAN FD or J1939-22 traffic from a vehicle bus and re-encodes it as J1939 Classic CAN frames a downstream telematics device can consume. The bridge installs alongside the telematics device on the vehicle, connects via a standard J1939 Classic CAN interface, and lets the existing device serve modern CAN FD vehicle platforms without being redesigned. Nexum Fleet is a CAN FD bridge for telematics service providers (TSPs).
What is the latency of translating CAN FD to Classic CAN?
Translation latency depends on the implementation, but well-designed translators operate in the low-millisecond range - typically faster than the cycle time of the source signals. For fleet telematics applications, translation latency is effectively invisible because most captured signals update at 100 ms-1 s intervals.
Is data lost when translating CAN FD to Classic CAN?
Only if the filter strategy discards it. Because CAN FD frames can carry up to 64 bytes and Classic CAN only 8, a translator must either (a) split a single CAN FD frame across multiple Classic CAN frames, or (b) filter signals down to those the telematics device actually needs. Nexum Fleet takes the second approach: the signal library - updatable over the air - defines precisely which PGNs and SPNs the downstream telematics device receives for each target vehicle platform, so nothing of commercial value to the TSP is lost.
Can a CAN FD to J1939 bridge preserve all J1939 signals?
If the source is J1939-22 and the destination stack supports Classic J1939, most signals can be preserved through re-packaging. Multi-PG CAN FD frames are split into individual Classic J1939 frames. Some multi-frame sequences may be required for signals that exceed Classic J1939 payload limits.
Does a CAN FD bridge require backend changes to my telematics platform?
A well-designed bridge should not. If the bridge presents J1939 Classic CAN to the existing controller, the telematics firmware, signal library, and backend decoding stack continue to operate as before - only the wire-level data capture changes. This is the architecture Nexum Fleet is built on: CAN FD parsing and protocol translation happen on the bridge installed alongside the telematics device, so everything upstream of the host controller - your cloud, your decoding, your customer-facing platform - stays untouched.
About Nexum Fleet
What is Nexum Fleet?
Nexum Fleet builds CAN FD bridges that let telematics service providers (TSPs) extend their existing telematics product onto modern CAN FD vehicle platforms. The TSP wins the new fleet business their existing device can't service today, with no redesign required.
Who is Nexum Fleet for?
Nexum Fleet is built for telematics service providers (TSPs) - companies whose primary commercial product is telematics hardware deployed into commercial vehicle fleets, and whose customer fleets are now adding modern CAN FD vehicle platforms (light-vehicle EVs, hybrids, J1939-22 heavy-duty).
How does the Nexum Fleet bridge work?
The Nexum Fleet bridge is a standalone unit that installs alongside your existing telematics device on each new CAN FD vehicle. It reads the vehicle's CAN FD or J1939-22 traffic, applies signal-library-driven translation, and delivers the resulting data to your telematics device as J1939 Classic CAN frames it already understands. No changes are required to your firmware, decoding stack, backend, or customer-facing platform.
Does Nexum Fleet replace my existing telematics device?
No. Nexum Fleet is a CAN FD bridge, not a telematics device. It installs alongside your existing telematics device on each new CAN FD vehicle and translates the vehicle's CAN FD or J1939-22 traffic into J1939 Classic CAN frames your device already understands. You keep your hardware, firmware, decoding stack, backend, customer relationship, and signal library, exactly as they are today.
What vehicles does Nexum Fleet support?
[TO CONFIRM: list of target vehicle platforms / OEMs covered in initial release]
What's the form factor of the Nexum Fleet bridge?
[TO CONFIRM: dimensions, connector type, mounting options]
What's the power consumption?
[TO CONFIRM: typical current draw in mA at 12V and 24V]
Does Nexum Fleet access or store fleet data?
No. Nexum Fleet is a translation component. Data flows from the vehicle bus to your telematics device and onwards to your backend. Nexum Fleet does not read, store, retransmit, or analyze fleet data. We do not compete with your signal library and we do not sit between you and your customer.
What does deploying Nexum Fleet involve?
A typical deployment runs across four stages: (1) Hardware integration - the bridge installs as a standalone unit alongside your telematics device on each new CAN FD vehicle, with separate enclosure, separate mounting, and a J1939 Classic CAN connection to your device; (2) Signal library configuration - we work with you to identify the signals your customers need from each target CAN FD vehicle platform and configure the signal library to translate them; (3) OTA update design and implementation - we set up the over-the-air pipeline that delivers signed signal library and firmware updates through your existing uplink; (4) Field validation - a small deployment on live vehicles before full production rollout. This setup work is delivered as a one-time setup fee, 50% on signing and 50% on delivery.
How do I start a conversation with Nexum Fleet?
Become a launch integration partner or talk to the founders - or visit the technical overview to scope a deployment.
Still have questions?
Every inbound message from a qualified TSP gets a personal reply. If your question isn't here, tell us what you're trying to solve.