/blog
CAN bus data logger vs telematics gatewayThe two words are used interchangeably and they are not the same product. One keeps the record; the other moves it.
The distinction is simple and it decides both the hardware and the running cost. A logger records values locally. A gateway moves values to a server. Most fleet projects need some of both, and the failure mode is choosing the extreme: a pure logger whose history nobody can reach, or a pure streaming gateway that bills you for unchanged data and keeps no copy.
Side by side
| Data logger | Telematics gateway | |
|---|---|---|
| Primary job | Keep a complete local record | Move selected values to a platform |
| Failure if chosen alone | Data exists but nobody can get to it | No history when coverage drops |
| Cost driver | Storage and retrieval | Data volume and frequency |
| Best for | Diagnosis, warranty disputes, fault chasing | Dashboards, alerts, fleet operations |
Why change-triggered upload is the hinge
If a machine has sixty values and forty of them never move, streaming all sixty on a fixed interval spends most of the data plan on the same numbers. Uploading on change - only when a value crosses a threshold you set - keeps the operation visible and the record complete, and it is the single feature that decides whether a logging project is affordable across a fleet.
The practical compromise most customers end up with: a heartbeat on a slow interval so the platform knows the unit is alive, plus change-triggered uploads for the values that matter, plus a local buffer for when there is no coverage at all.
Questions that separate the two
- Who reads the history? A maintenance engineer chasing one fault wants long local detail; a dashboard wants aggregates.
- How long must history be kept? It decides buffer size and whether the unit uploads detail or summaries.
- What happens with no coverage? If the answer is "nothing is recorded", that is a logger without a buffer, not a gateway.
- Can one unit do both? Usually yes - but only if both are specified at the start, not added after the payload is fixed.
How this relates to tyre pressure
Fleets that already run TPMS often want pressure history in the same place as the rest of the machine data. That is a payload question rather than a second platform: if both sources are specified together, the tyre values and the CAN values can leave the machine in one record. If they are specified separately, you end up maintaining two platforms and reconciling two clocks.
Data sheet, interface list and a payload example on request — contact us (ralph@gz-can.com · +86 130 7692 2278).