GZ-CAN Home DTU CAN telematics API Data logger Integration OEM / ODM Contact Get a quote

Home / CAN bus telematics

CAN bus telematicsConnection, interval, volume. Those three decide whether it works.

The short version

A CAN bus telematics unit turns bus traffic into records a platform can store. It reads frames, applies the sampling plan, and transmits. Everything else — which signals, how often, where they land — is a decision made before the unit ships, not a feature discovered later.

Pick the connection by what the machine offers

ConnectionWhen it is the right one
CAN 2.0BThe common case on trucks, buses, cranes and port equipment.
J1939The bus already speaks the heavy-vehicle standard and the platform expects those identifiers.
RS232 / RS485Only a serial port is available, or the bus segment is closed to third-party devices.
CAN pass-throughA remote tool must reach an attached controller — parameter work, or an ECU/VCU upgrade.

Three numbers that decide the project

  • Sample interval. Slow signals (temperature, hour meters) do not need the same interval as a fault flag. Write both into the specification.
  • Message volume. Change-triggered reporting plus a heartbeat keeps a stable machine almost silent — which is what makes a fleet affordable to monitor.
  • Offline buffer depth. A pit or a tunnel is normal, not an exception; the record has to survive it.

What usually goes wrong

Three things, repeatedly: the sampling interval is left as "as fast as possible"; nobody writes down what a missing reading looks like in the payload; and the platform team sees the first records only after the pilot machines ship. All three are documents, not hardware.

Next

The unit itself is on the DTU page. If the worry is the protocol handover, read CAN protocol API first — that is usually the real decision.

Data sheet, interface list and a payload example on request — contact us (ralph@gz-can.com · +86 130 7692 2278).

Telematics is a data question before it is a hardware question

Most "CAN bus telematics" projects stall at the same place: the vehicle has a bus, the platform wants values, and nobody has written down which values, in which units, at which interval. The hardware is the easy part. The specification is the work.

Our position is deliberately narrow. We supply the unit that reads the bus and moves the data; the definitions of the signals stay with the customer. That is not a limitation we are apologising for - it is the reason a project can start without handing a protocol document to a supplier in another country.

Three protocols, three different jobs

LayerWhat it means in practice
CAN 2.0BThe standard frame format. Most machine controllers and body ECUs speak it; the frame map is whatever the machine builder wrote.
J1939 message sets29-bit extended frames with an agreed parameter structure. We have deployed J1939-format message sets in construction machinery integrations with major OEMs, and the message layout we use is documented so it can be aligned to your DBC or your parameter set.
RS232 / RS485When the data source is a serial device rather than a bus - a scale, a body controller, an older controller that predates CAN.

What the unit does with the data

What we will not claim

We do not publish a list of platforms we "support". Integrations are projects: they have a broker, a payload format and a test window. Saying we support a named platform without an integration behind it is the kind of claim that gets found out in week two. What we do instead is give you the payload example and the topic structure, and let your platform team confirm it fits.

Questions about CAN bus telematics

Which is better for a retrofit: CAN or serial?

It depends on what the machine exposes. If the controller already publishes the values you need on CAN, use CAN. If the data source is a serial device - a scale, a body controller, an older unit that predates CAN - RS232 or RS485 is the shorter path. Fitting a gateway to convert between them is a last resort, not a default.

How many values can one unit handle?

Enough that the count is rarely the constraint - the constraint is the interval and the data plan. A payload of six values every 30 seconds and a payload of sixty values every second are both possible; they are different projects, not different products.

Is 4G required, or can it be wired?

Most of these installations are mobile machines, so 4G is the normal path. On fixed plant the same unit can be specified to deliver into a local system instead, which is usually what an operator wants when the data has to sit next to the machine's own control system.