The CAN FD bridge for your telematics device.

Futureproof your telematics product onto modern CAN FD vehicle platforms, and win the new-fleet business your existing device can't service today.

Become a launch integration partner Talk to the founders

The problem every TSP is facing.

Telematics service providers (TSPs) keep losing new-fleet business at existing accounts. Customers add modern CAN FD vehicle platforms - light-vehicle EVs, hybrids, J1939-22 heavy-duty trucks - and the TSP's existing telematics device can't read those vehicles. The customer needs unified telematics across their full fleet. If the TSP can't deliver, a competitor will.

Active fleet tenders, particularly in Australia and Europe, are now specifying CAN FD-only platforms as a hard technical requirement. TSPs whose products can't read CAN FD are filtered out at technical evaluation, regardless of price, service, or relationship.

Every TSP serving modernizing fleets is facing some version of this.

A CAN FD bridge that installs alongside your existing device.

Nexum Fleet is a CAN FD bridge that installs alongside your existing telematics device on new CAN FD vehicle deployments. The bridge reads the vehicle's CAN FD or J1939-22 traffic, translates the relevant signals into J1939 Classic CAN frames your device already understands, and delivers them via a standard J1939 Classic CAN connection.

How it works.

01

Tell us what your customers need.

We work with you to identify the signals your customers want from the target CAN FD vehicle platforms, including J1939-22 heavy-duty traffic from modern commercial vehicles, and configure the bridge's signal library to translate those into J1939 Classic CAN frames your device already understands.

02

Forward-fit on new vehicles.

The bridge installs alongside your existing telematics device on new CAN FD vehicle deployments. Standalone unit, separate enclosure, connects via J1939 Classic CAN.

03

Data keeps flowing.

The bridge translates CAN FD or J1939-22 traffic into J1939 Classic CAN. Your device sees the frames it expects. Your backend decodes as it always has. You're now serving CAN FD vehicles entering your customers' fleets.

That's what the bridge does. Here's why it's built the way it is.

Why Nexum Fleet

Three things we deliberately didn't lock.

Nexum Fleet is built on three deliberate design choices that protect your product, your stock, and your data path.

01

One SKU. Every platform.

A single Nexum Fleet bridge works across a light-commercial EV, a hybrid delivery van, and a J1939-22 heavy truck. The vehicle platform is configured in software, not soldered in hardware.

For engineering: one reference design to integrate once.

For operations: one part number to stock, forecast, and warranty.

For finance: one unit cost to model.

As your vehicle coverage widens, none of those grow with it.

02

Signal libraries that update over the air.

When a new vehicle platform reaches the market or an existing signal definition needs refining, an updated signal library is pushed to Nexum Fleet bridges already in the field - through your telematics device's existing uplink, with no second SIM and no new network path out of the vehicle.

Your deployed fleet stays current without a truck roll, a technician, or a minute of downtime.

The pace of CAN FD vehicle support is no longer gated by the pace of hardware deployment.

03

No SIM. No Bluetooth. No competing data path.

Nexum Fleet has no SIM, no Bluetooth, and no independent communication path. The bridge cannot see, store, or transmit data outside your existing telematics device. Your data path stays exactly as it was, and the bridge cannot become a competing telematics device in its own right.

Those three design choices only matter if you're the kind of company they solve a problem for.

Who this is for

Built for telematics service providers serving modernizing fleets.

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.

You're probably a fit if:

  • You have a proven, mature J1939 Classic CAN telematics platform in production
  • Your customer fleets are adding modern CAN FD vehicle platforms - EVs, hybrids, or J1939-22 heavy-duty
  • You're bidding into new fleet tenders that specify CAN FD compatibility as a hard technical requirement
  • Redesigning the core telematics device is a multi-year engineering investment you cannot yet justify on current CAN FD fleet volumes

If two or three of those describe you, we should talk.

Who it isn't for.

Nexum Fleet isn't a development board, a data logger, or a fleet-management platform. We don't build telematics devices and we don't sell to end fleets. If you're a fleet operator evaluating telematics for the first time, or an engineer looking for a CAN FD evaluation kit, there are better products for you - and we'd rather point you to them than waste your time.

How we work commercially.

Structured for how TSPs actually do business.

What How it works
HardwareSensible per-unit margin.
One-time setup feeCovers your CAN signal library configuration, OTA update design and implementation, and integration documentation. 50% on signing, 50% on delivery.
Firmware licenseModest per-unit annual fee, billed in advance for firmware maintenance and OTA capability.
Warranty6 months from shipment.

No revenue share on your data. No attempt to sit between you and your customer.

Frequently asked questions

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.
What is J1939-22?
J1939-22 is the SAE specification for running the J1939 heavy-duty vehicle protocol on a CAN FD bus. Released in 2020-2021, it defines new frame formats, multi-PG (Parameter Group) packing within a single CAN FD frame, and extended addressing suitable for CAN FD's larger payloads. The underlying J1939 semantic layer - PGNs, SPNs, and parameter definitions - is preserved, which is why bridging between J1939-22 and Classic J1939 is technically possible at the frame level.
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 operate on Classic CAN (J1939-11 at 250 kbps, J1939-17 at 500 kbps); J1939-22 is the CAN FD variant. Both specifications will coexist on commercial vehicle fleets for the foreseeable future - mixed fleets combining legacy Classic J1939 trucks and newer J1939-22-capable platforms are the realistic operating environment for this decade.
Why are EV platforms moving to CAN FD?
EVs generate substantially more real-time data than internal combustion vehicles - battery cell voltages, pack temperatures, state-of-charge, state-of-health, regenerative braking, motor torque, and thermal-management telemetry - which exceeds what a single Classic CAN bus can carry efficiently. CAN FD's 64-byte payload and higher data-phase bit rate handle this volume without the cost and complexity of a full move to Automotive Ethernet. For most EV and hybrid platforms launched in the 2020s, CAN FD is the pragmatic bandwidth answer.
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 in 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.
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 split a single CAN FD frame across multiple Classic CAN frames, or filter the stream down to the signals 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, and nothing irrelevant is transmitted.
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.

Full list of questions and answers - including CAN FD fundamentals, bit-rate details, deployment specifics, and more - on our full FAQ page →

Ready to talk?

We're onboarding a small number of TSPs as launch integration partners now. First pilots begin immediately after hardware validation. If your customer fleets are adding modern CAN FD vehicle platforms - EVs, hybrids, or J1939-22 heavy-duty - the conversation is worth having.

Become a launch integration partner Talk to the founders