Home / DTU

CAN-to-4G DTUThe machine keeps its protocol. We move its data.

What the DTU is

A CAN-to-4G data transfer unit sits on the machine bus, samples the frames selected for the project, and pushes the values over a cellular link. It is a data pipe, not a diagnostic tool and not a display: the machine keeps doing its job, and the numbers arrive where the customer's system can use them.

Built around four capabilities

Change-triggered upload with scheduled wake-up. The unit reports when a value moves or crosses a threshold, plus a heartbeat so silence means "unchanged", not "offline".
Remote parameter adjustment. CAN bitrate and sample points can be changed from a distance — one hardware build serves several machine variants.
A/B dual-partition FOTA. Firmware updates resume after a dropped connection and roll back automatically if the new image does not come up.
CAN pass-through. The unit can relay bus traffic so a remote tool reaches an attached controller, for parameter work and for upgrading an external ECU / VCU (custom scope, agreed per programme).

Transport and security

MQTT over TLS with mutual authentication, in addition to plain HTTP posting where the platform prefers it. 4G CAT.1 with fallback to 2G/3G networks for sites where coverage is not guaranteed. Power from the machine, DC 10–30 V, with a hardware watchdog for self-recovery and a three-colour status LED for the technician on site.

Positioning

GPS and BeiDou dual-mode positioning with geofence support, delivered in the same stream as the bus data — so a movement event and a data event arrive in the same record.

The interface decision

CAN 2.0B or J1939 on the vehicle side; RS232 / RS485 where the bus is closed; MQTT or HTTP on the platform side. Nothing on this page is a per-customer build — it is the same hardware with the sampling plan configured for the project.

Where the protocol lives

The customer keeps the CAN definitions. We work from the list of data points that the customer decides to expose, and deliver those through an API. That is the whole reason this product can be deployed without an internal protocol release — see the API page for how the contract is agreed.

Pages that go deeper

CAN bus telematics — the three connection options.
CAN protocol API — what we ask for instead of a protocol.
Fleet data logger — the change-triggered recording case.
Telematics integration — PLC, SCADA and MQTT paths.

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

What a CAN to 4G gateway actually does

A DTU is not a modem bolted to a vehicle. It is a small computer with two sides that must not interfere with each other: on one side it reads the CAN bus, on the other it moves selected values to a server. The design question is what happens between those two sides - and that is where most projects are won or lost.

The rule we build on is that the CAN definitions stay with you. We do not ask for your protocol document as the price of entry, and we do not reverse-engineer your bus. You tell us which values you want and how often; the DTU is configured to pick those up and publish them in a payload you can parse. That is the whole commercial point of this product: it can be added to a machine that already has a telematics or TPMS installation, without disturbing what is already there.

The four numbers that decide a DTU project

What is configurable after it ships

Where this fits a fleet that already has telematics

The common case is not a greenfield machine. It is a fleet that already runs a telematics unit for position and hours, and needs one more data source that the incumbent unit cannot reach - a third-party controller, a body builder's ECU, or a sensor network of its own. A DTU added in parallel does exactly that: it reads what it is told to read and publishes to a second endpoint. No change to the existing unit, no negotiation with the incumbent supplier.

If your platform is the destination, the integration question is the payload and the topic, not the hardware. Send us the values you want and how your broker expects them, and the reply is a configuration, not a quotation for development.

Questions we get asked about DTUs

Can a DTU read J1939, or only plain CAN?

Both. On J1939 networks we work in 29-bit extended frames and have deployed J1939-format message sets in construction machinery integrations with major OEMs; on plain CAN 2.0B the frame map is whatever the machine builder wrote. In either case the mapping from bus value to payload field is a configuration, not a rebuild.

Do we have to give you our CAN protocol?

No. That is the point of the product. You tell us which values you want, in which units and how often; the unit is configured to publish those. If you would rather align to a DBC you already own, we work from your file instead.

What happens if the machine drives out of coverage?

The unit buffers locally and uploads when the link returns, so the record has a gap in timing but not in content. It also reports its own last-successful-upload time, which is how you tell "the machine was idle" apart from "the unit stopped reporting".

Decision	Why it is the first question
Bus type and speed	CAN 2.0B at 250 or 500 kbps, J1939 message sets, or a serial line (RS232 / RS485). This decides the harness and the firmware variant before anything else.
Which values, and how often	A payload of six values every 30 s is a different device from sixty values every second. Both are possible; the specification has to say which.
Upload trigger	Time-based is simple but bills you for unchanged data. Change-triggered (only when a value moves past a threshold) is the reason a DTU can run on a small data plan.
Who terminates the server side	You can terminate MQTT on your own broker; we can hand you a payload example and the topic structure. Whoever owns the broker owns the integration schedule.