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

Home / OEM / ODM

OEM / ODM telematicsYour brand, your field names, your defaults.

What an OEM programme can change

  • Housing marking. Laser marking of brand, model code and serial identity, with per-unit traceability available.
  • Packaging. Artwork, insert and label language for the destination market.
  • Payload naming. The API field names can follow the customer's platform naming rather than ours.
  • Behaviour defaults. Sampling plan, heartbeat interval and alarm thresholds set at the factory for the customer's duty cycle.

What stays fixed (and why it is worth saying now)

  • The radio and the module. 4G CAT.1 is the platform choice, not a per-order dial.
  • Certification wording. Status today is CE in progress; we will not print a mark we do not hold.
  • Schedule honesty. We quote a lead time we can keep, which means we decline one we cannot.

How a programme runs here

Payload list agreed → sample units on one machine → marking and packaging proof → pilot batch → series. The step that is most expensive to move later is the payload list, so it is agreed before the sample ships, not after.

The commercial part

Quantities, marking, packaging and destination market are enough for a written proposal. There is no price on this page: send the requirement and the answer comes back with a configuration and a document list.

Next

DTU hardware · API and protocol ownership.

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

OEM means the unit stops looking like ours

An OEM order is not a bigger quantity of the same thing. It is a different product: your marking on the housing, your field names in the payload, your defaults set at the factory, and a documentation set that carries your name rather than ours.

What stays the same is the platform underneath - the same CAN front end, the same upload stack, the same FOTA mechanism - which is what makes an OEM version practical rather than a development project.

What is changeable

ItemTypical OEM change
Housing and markingLaser marking or label with the customer's brand and part number
Payload field namesYour schema, not ours, so your platform does not need a translation layer
Factory defaultsUpload interval, trigger thresholds, broker address pre-set for your fleet
DocumentationDatasheet and interface note under your brand
Firmware variantBus profile fixed for your machine family, so field configuration is smaller

What an OEM conversation actually needs

  1. Machine family and bus - how many variants, what the bus looks like, which controller speaks it.
  2. Values and cadence - the payload, per variant if they differ.
  3. Where the data lands - your platform, your customer's platform, or both.
  4. Marking and documentation - what the label and the datasheet have to say.
  5. Pilot size - a machine or two first, then the fleet. Nobody sensible skips this step.

Everything above is a configuration on an existing platform. If a requirement needs new hardware, we say so rather than absorbing it into a schedule we cannot hold.

A note on documentation

An OEM order usually ends with the customer's own engineers needing to maintain the units. That is why the interface note - what the payload contains, how to reconfigure, how to recover from a failed update - matters as much as the hardware. We would rather hand over a document that is accurate and short than one that is comprehensive and wrong.

Questions about OEM orders

What is the minimum change for an OEM version?

Marking and a documentation set under your brand, with factory defaults pre-set. Payload field names and a fixed bus profile are the next step up; both are configuration on the same platform rather than new hardware.

Who writes the interface documentation?

We do, and it carries your part numbers. An OEM order usually ends with your engineers maintaining the units, so the note has to be accurate about how to reconfigure and how to recover from a failed update - not just what the payload contains.

Can the same unit serve several machine variants?

Usually yes, with the bus profile and defaults set per variant. Where a variant needs something the platform cannot do, we say it before the order rather than absorbing it into a schedule we cannot hold.