Technical Overview
CAN FD Bridge: Technical Specifications
Nexum Fleet is a CAN FD bridge that installs alongside your existing telematics device on new CAN FD vehicle deployments. 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, cloud, or customer-facing platform. The bridge connects via a standard J1939 Classic CAN interface, with no engineering integration required on your side.
At a glance
| Attribute | Specification |
|---|---|
| Input bus | CAN FD, ISO 11898-1 compliant. Arbitration rate up to 1Mbps; data-phase rate up to 6 Mbps |
| Output bus | Classic CAN2.0b 500kbps (configurable up to 1Mbps) |
| Supported higher-layer protocols (source) | SAE J1939-22; OEM-specific CAN FD schemas via signal library |
| Supported higher-layer protocols (destination) | SAE J1939 |
| MCU class | Automotive-grade CAN FD-capable |
| Form factor | [TO CONFIRM: approx. XX × XX mm standalone enclosure, XX-pin connector] |
| Supply voltage | [TO CONFIRM: 5V logic; vehicle power 9V-36V via host device] |
| Typical power consumption | [TO CONFIRM: typical mA at 12V, max mA under peak bus load] |
| Operating temperature | [TO CONFIRM: target -40 °C to +85 °C] |
| EMC | [TO CONFIRM: Designed to vehicle-grade EMC requirements ] |
| Firmware update | Over-the-air via host telematics device's existing uplink |
| Signal library update | Over-the-air, independent of firmware update |
The single design decision that makes the Nexum Fleet bridge unique is keeping the signal library OTA-deployable per device, rather than baked into a firmware build that would force a different SKU for every vehicle platform. In our experience working with TSPs, the cost of supporting a new vehicle platform isn't the firmware work itself. It's the rollout coordination, the field validation, the rollback risk, and the stock-management overhead of making sure the right hardware reaches the right vehicle. Decoupling vehicle knowledge from bridge firmware collapses all of that into a same-day OTA push to a single universal device.
Protocol and signal support
The bridge handles three classes of incoming data:
- Raw Classic CAN, CAN FD and defined CAN FD schemas. The signal library maps each target signal to a specific CAN ID, byte position, bit length, scaling, and offset. This is the path used for OEM-specific EV and CAN FD platforms.
- SAE J1939-22 - CAN FD-based J1939, including multi-PGN packing. The bridge extracts individual PGNs and re-emits them as J1939 Classic CAN frames to your telematics device. Read more on our J1939-22 explainer.
- Mixed-protocol buses - where a vehicle exposes a combination of J1939 Classic CAN and CAN FD on the same or dual CAN FD buses or via a domain gateway, the bridge can be configured to read the relevant bus and translate accordingly.
Signal coverage is defined by a signal library - a versioned, OTA-updateable configuration describing which signals on which vehicle platforms translate to which downstream J1939 PGNs or Classic CAN frame IDs. Your existing decoding stack consumes the output exactly as it consumes J1939 Classic CAN today.
Signal library architecture
The signal library is the separation between hardware (the bridge) and vehicle knowledge (the decodings). This separation matters for three reasons:
- A single Nexum Fleet bridge SKU covers many vehicle platforms - you stock one part number, not one per vehicle.
- New vehicle platforms can be added without a hardware change, without a firmware change, and without a field visit.
- The library itself is versioned, auditable, and deployable per-unit, per-fleet, or per-account.
Updates are delivered as signed, version-controlled library files. Your cloud pushes the update to your telematics device via the existing uplink; the device relays it to the bridge; the bridge validates the signature, swaps the library at the next safe checkpoint, and acknowledges.
Over-the-air update mechanism
Two independent update channels:
- Firmware updates - the bridge's executing firmware. Delivered infrequently, covers core translation logic, protocol handling, security patches. A/B partition with rollback on failed boot.
- Signal library updates - decoding definitions only. Delivered for each vehicle or as required, covers new vehicle platforms and signal refinements. Hot-swap at a safe checkpoint; no reboot required.
Both channels are cryptographically signed. Both are pushed through your telematics device's existing cellular or Wi-Fi connection - Nexum Fleet does not add a radio, does not need a separate SIM, and does not open a new network path out of the vehicle.
Bridge deployment
A typical deployment runs across four stages:
- Hardware integration - the bridge installs as a standalone unit alongside your telematics device on each new CAN FD vehicle. Separate enclosure, separate mounting, J1939 Classic CAN connection to your device.
- Signal library configuration - we work with you to identify the signals your customers need from each target CAN FD vehicle platform, including J1939-22 heavy-duty traffic, and configure the signal library to translate them into J1939 Classic CAN frames your device already understands.
- OTA update design and implementation - we set up the over-the-air pipeline that delivers signed signal library and firmware updates to deployed bridges through your existing uplink, with no second SIM and no new network path.
- Field validation - a small deployment on live vehicles to validate signal accuracy, timing, and edge cases before full production rollout.
This setup work is delivered as a one-time setup fee, 50% on signing and 50% on delivery. Typical duration: 8-12 weeks from kick-off to completed validation.
Data ownership and security
The bridge is a translation component. It does not read, store, buffer beyond the translation cycle, or retransmit vehicle or fleet data outside the intended path back to your telematics device. Your telematics device receives translated frames exactly as it would receive native J1939 Classic CAN. All cloud infrastructure, data storage, data processing, and customer relationships stay yours.
Signed firmware, signed signal library, and no external network presence on the bridge itself. Supply-chain integrity is maintained through sourcing and manufacturing program controls.
What's in the box
- The bridge itself (standalone unit, separate enclosure)
- Integration documentation (interface spec, mechanical drawing, power profile, EMC test report)
- Initial signal library covering agreed vehicle platforms
- Field support through the validation deployment
Current status
Firmware is feature-complete and validated on bench. First hardware prototype is in final debug, with validation targeted in early June 2026. We are onboarding a small number of launch integration partners now to run the first pilots immediately after hardware validation.
If you want to be one of them, talk to us.
Ready to scope a deployment?
We run fixed-fee setup engagements with a small number of launch partners. Tell us about your existing telematics product and the CAN FD vehicle platforms entering your customer fleets.