A GPS tracker can tell a fleet manager that a truck has been parked at a dhaba for forty minutes. It cannot say whether the engine was running the whole time, whether the fuel level dropped while it stood there, or whether the engine control unit has been logging a fault since morning. That information already exists inside the truck. It moves between the vehicle's electronic control units (ECUs) on the CAN bus, and a telematics device connected to that bus can read it.
This article explains what the CAN bus is, which parameters you can realistically expect, how fault codes are structured, and what it takes for a telematics device to read all of it.
CAN (Controller Area Network) is the in-vehicle network that lets ECUs exchange data over a shared pair of wires instead of separate wiring between every component.
On a truck, the engine ECU, transmission controller, braking system and instrument cluster all sit on this network. Most messages are broadcast: one ECU sends a value, such as engine speed, and every other ECU that needs it reads the same message. This is what makes the CAN bus useful for telematics. A device connected to the bus can listen to the same traffic the vehicle's own systems use, without adding a separate sensor for each parameter.
The device connects to the CAN High and CAN Low lines, either through the J1939 9-pin diagnostic connector or by wiring directly to the vehicle's CAN network.
Most J1939 data is broadcast continuously, so the device simply listens. Some data, such as previously active fault codes (DM2), is sent only on request, which J1939 handles through a dedicated request message.
The PGN is embedded in the 29-bit CAN identifier. For example, PGN 61444 is EEC1 (Electronic Engine Controller 1), the message that carries engine speed.
Each SPN is defined by its bit start position, bit length, scale, offset and unit. Applying these converts raw bytes into a physical value. Messages longer than eight bytes, including fault code lists, are split across several CAN frames and reassembled using the J1939 transport protocol.
The device timestamps the decoded values, pairs them with GPS location and sends them over the mobile network to the fleet platform, where they become reports and alerts.
The exact list depends on the truck's make, model and which ECUs are fitted, so treat the categories below as what J1939 makes possible, not a guarantee for every vehicle. Examples of J1939 SPNs include Engine Speed, Wheel Based Vehicle Speed, Fuel Level 1 and Engine Oil Temperature.
Engine speed (rpm) from the engine controller, plus engine temperatures such as oil temperature where the ECU broadcasts them. These show how hard the engine is being worked and whether it is running hot.
Wheel-based vehicle speed comes from the vehicle's own sensors, which gives a second reading alongside GPS speed and keeps reporting where satellite reception is poor.
Fuel level, where the vehicle exposes it on the CAN bus. Where a truck does not broadcast usable fuel data, a separate fuel sensor is still needed.
Active and previously active diagnostic trouble codes, sent as diagnostic messages DM1 and DM2. These are covered in detail in the next section.
When engine speed is above zero while vehicle speed stays at zero, the engine is idling. When engine speed stays high for long stretches, the engine is being driven hard. Neither pattern is visible from location data alone.
A fall in fuel level while the truck is parked, matched with its GPS position and time, gives a specific event to investigate instead of a monthly discrepancy in the fuel bill. Fleetx's fuel-consumption article makes a similar point, using engine output from the truck's ECU read through CAN bus telematics.
An active DM1 code reaches the fleet team when it appears, not when the driver calls from the highway. The team can decide whether the truck continues, diverts to a workshop or is booked in at the end of the trip.
For more on this approach, see iTriangle's guide to remote vehicle diagnostics and ECU programming.
Arriving at the workshop with the SPN, FMI and occurrence count already known shortens the time spent finding the fault and makes recurring problems visible across the fleet.
Many of today's heavy-duty vehicles have two or more parallel CAN networks, and connecting to one network does not necessarily give access to all the data on the vehicle. A telematics device with a single CAN interface can only listen to one of them. A device with two CAN interfaces can listen to two networks at once. When choosing a CAN telematics device for trucks, ask which networks on your specific vehicles carry the parameters you need, and whether the device can connect to both.
iTriangle has designed and manufactured telematics devices in India since 2009, with more than one million devices deployed and over 2,500 customers. Its CAN-capable range covers fleets as well as vehicle manufacturers:
For a closer look at what fault code data enables, see iTriangle's guide: Remote Vehicle Diagnostics and ECU Programming for Fleet Maintenance.
GPS tells you where a truck is. The CAN bus tells you what the truck is doing: how hard the engine is working, how much fuel is in the tank and which faults the ECUs are reporting. J1939 makes that data readable across makes, and DM1 fault codes, decoded as SPN, FMI and occurrence count, turn it into maintenance decisions. The practical questions for any fleet are which parameters its trucks actually broadcast, which CAN networks carry them, and whether the telematics device can read them.
If you want engine, fuel and fault code data from your trucks, talk to iTriangle's team about a CAN-enabled device suited to your vehicles.
INTRODUCTION In today's interconnected world, where data insights drive progress, the transportation sector teeters on the brink of a monumental shift. Leading this paradigm change is iTriangle Telema...
INTRODUCTION In the rapidly evolving realm of fleet management, iTriangle Telematics emerges as a pivotal force, transcending conventional tracking methodolog...
INTRODUCTION In today's rapid business environment, keeping pace with technological advancements is crucial for companies striving to optimize efficiency and productivity. One key innovation with vast...