/blog
CAN to 4G gateway: get the data, keep the protocolThe commercial objection to telematics projects is rarely the hardware price. It is that someone asks for your CAN protocol before they will quote.
A CAN to 4G gateway sits between two worlds. On one side is the machine bus: CAN 2.0B frames, sometimes J1939 message sets, sometimes a serial device. On the other side is a server, reached over 4G. Everything interesting about the product is in the space between those two sides.
What a gateway has to decide
There are four decisions, and they are all specification decisions rather than hardware decisions.
| Decision | What it settles |
|---|---|
| Bus type and bitrate | CAN 2.0B at 250 or 500 kbps, J1939 message sets, or RS232 / RS485. This fixes the firmware variant and the harness. |
| Which values, how often | Six values every 30 seconds and sixty values every second are two different products. |
| Upload trigger | Time-based is simple but bills for unchanged data. Change-triggered uploads only when a value moves past a threshold. |
| Who terminates the server | Your broker, or your endpoint. Whoever owns it owns the integration schedule. |
Why "hand over the protocol" is the wrong starting point
Asking a machine builder for their CAN definition document is asking for the map of how their machine works. It is commercially sensitive, it is frequently incomplete, and in a competitive evaluation it is the last thing a builder wants to send abroad.
The alternative is to invert the question. Instead of "give us your protocol and we will decode it", the question becomes "tell us which values you want and how often, and we will ship a unit configured to publish those". The unit is configured against a list of values, not against a document. On J1939 networks we have deployed J1939-format message sets in construction machinery integrations with major OEMs, and the layout we use is documented so it can be aligned to a customer's DBC or parameter set - but the alignment happens on the customer's terms.
What happens when coverage drops
A mobile machine spends part of its life where there is no signal: a tunnel, a yard, a mine pit. A gateway that publishes live and forgets is a gateway that leaves holes in the record. The unit buffers locally and uploads when it can, and the buffer is what makes the difference between a record you can audit and a record you have to explain.
What to ask before buying one
- What can be changed after the unit ships - interval, thresholds, payload, firmware - and how?
- Is the update mechanism A/B, so a failed update falls back instead of bricking a unit in the field?
- What does the unit report about itself when it cannot reach the server?
- Who owns the payload definition, and can it be changed without a new hardware order?
Those four answers tell you more about the product than any list of supported platforms. A gateway is a small computer, and the interesting question is what you are allowed to change once it is on a machine in another country.
The narrow version
If you already run telematics for position and hours, and you need one more data source the incumbent unit cannot reach, a second gateway in parallel is the cheapest route: it reads what it is told, publishes to a second endpoint, and does not disturb the installation that already works.
Data sheet, interface list and a payload example on request — contact us (ralph@gz-can.com · +86 130 7692 2278).