There is a single sentence that stops more telematics projects than any hardware problem:
*"we need your CAN protocol."*
It sounds like a technical requirement. It is actually an organisational one, and it is usually
where the project dies — not because the sender is unreasonable, but because the receiving
organisation cannot answer it quickly. This is about why we never ask that question, what we ask
instead, and what it changes in practice.
The sentence is a request for an internal document release
If you build machines, your CAN definitions are internal documentation. They describe your
controller's signals, scaling, timing and fault semantics. Handing them to a supplier means:
- an internal approval, because a protocol document usually carries more than the one signal the
supplier needs;
- a legal review, because the document describes your product's behaviour;
- a maintenance question, because once a copy exists outside, you own the job of keeping it in
step with each firmware revision.
None of these are impossible. All of them are slow, and none of them are on the supplier's
schedule. So a project that was supposed to start in March starts in September — and by then the
budget owner has moved on.
That is the actual cost of that sentence. Not the paperwork — the delay.
What we ask for instead
We ask for a list. That is the whole requirement:
1. Which values matter. Oil pressure, hydraulic temperature, engine hours, load, RPM,
whatever the machine needs to report. Named, not mapped.
2. What unit you think in. Bar or kPa, Celsius, hours, counts.
3. How often each value is worth reporting. A temperature once a minute is plenty; a fault
flag needs to be immediate.
4. Where it should go. Your platform, your fleet system, a file, an ERP endpoint.
From that list we build the sampling plan on our side and deliver the values through an API. The
mapping between your signal and our payload is written once, in a document you keep, and it is
yours to change.
The important part is what does *not* leave your organisation: the protocol document, the DBC
file, and the firmware.
Why this is not the same as an OBD-style dongle
A common assumption is that any device reading vehicle data without a protocol is doing something
clever with standardised diagnostics. That is a different product category, and it has a different
limitation: it sees only what the generic diagnostic layer exposes, which is a small subset of
what a machine actually knows.
We are not making that trade. The unit reads the CAN bus directly, at the bitrate the machine
uses, with the frames selected per project. The difference is only *who holds the definitions* —
you do, and we work from the data points you expose. That is why the approach still works when
the interesting signal is not in any standard diagnostic set.
Four ways customers actually use it
Scheduled queries. The platform asks for a value at an interval it chooses. Useful for slow
signals where the trend matters more than the instant: hydraulic temperature, battery voltage,
hour meters. The unit answers; nothing is streamed continuously.
Change-triggered upload. The unit reports when a value crosses a threshold or moves, plus a
heartbeat so you know the machine is alive and unchanged. On a fleet this is the single biggest
difference in running cost, because silence is cheap and a constant stream is not.
Remote parameter tuning. CAN bitrate and sample points can be changed remotely. This matters
more than it sounds: one unit model can then serve different machine variants, so a mixed fleet
does not become a mixed spare-parts problem.
ECU / VCU firmware upgrade through CAN pass-through. The unit forwards CAN traffic so a
remote tool can talk to an attached controller — parameter changes, and firmware updates where the
programme allows it. This is custom scope, agreed per project, not a catalogue feature.
The things that still have to be agreed
Honesty matters more than a clean story, so here is what this approach does not remove:
- The data point list is still a specification. Someone on your side has to decide what is
worth reporting. We cannot guess it from a model number.
- The API contract has to be written. Payload fields, units, timestamps, and what a message
looks like when a sensor misses a reading. That is a document, and it takes an hour of both
sides' time.
- Your side has to consume it. Integration work on the platform is yours; we deliver the
values, we do not wire your dashboard.
- Retrofit is a physical job. Where the unit goes, how it is powered, and how the harness
runs is a site decision, not a software one.
Why the first working data point is fast
The reason a first data point is often reachable in about a day of joint work is not that the
engineering is trivial. It is that the critical path is short: there is no protocol release to
approve, no document to redact, no legal review of a signal definition. Two engineers agree on
five field names and one interval, and the number starts arriving.
That is the whole argument. The hardware is not the differentiator — the approvals path is.
Where to go next
If the question you are answering is "can we get machine data without releasing our CAN
definitions", the answer is yes, and the architecture is described on
the CAN-to-4G telematics page and in more detail on
the CAN protocol API page. If what you need is the interface side rather than
the API side, CAN bus telematics covers the three connection options. And
if the data you want to record is about duty cycles rather than alarms,
the fleet data logger page describes the change-triggered approach.
If you already know what you need, send the list: the values, the units, the intervals and the
destination. That is enough for a written answer about what the hardware exposes and what your
integrator still has to do. Send us the data list.