Most tyre-pressure projects do not fail at the sensor. They fail one step later, when
somebody asks where the number is supposed to appear. A buyer who wants pressure on a
fleet dashboard, an operator who wants it on a cab display and an integrator who wants it
in an existing SCADA system are describing three different systems, and the sensor is the
only part they have in common.
This article walks the four routes that tyre-pressure data actually takes out of a vehicle,
what each one needs, and the questions worth asking before a purchase order rather than
after.
First, separate two things that get confused
There are two directions in any installation, and they have different constraints:
- Sensor to receiver. This is the radio link. On our industrial line it is 433.92 MHz,
licence-free, and the interval is configurable down to 3 seconds or less. This link is
about surviving a vehicle, not about protocols.
- Receiver to the rest of the world. This is where protocols and platforms live. It is
the part that decides whether your fleet system ever sees a pressure value.
Almost every integration question is really about the second direction. So the useful
question is not "what protocol does your sensor speak" — sensors do not speak protocols —
but "what does your receiver expose, and to whom".
Route 1: receiver into the vehicle bus
The receiver sits on the vehicle and writes pressure and temperature onto CAN. On our
receivers this is CAN 2.0B, J1939 is available, default 250 kbps, with a data period of
10 ms, and the message layout is documented with a DBC file.
This route is the right one when the vehicle already has a controller that should react to
pressure — a body controller, a dash cluster, a speed limiter, a load-management system.
The receiver is a node on the bus, and the vehicle's own logic decides what to do with the
data.
What to ask for: the message map, the DBC file, and confirmation of which side owns the
scaling. Ask before you write code, not after.
If this is the route you need, the protocol background is in
what CAN bus TPMS actually is.
Route 2: receiver into a serial device
Not every vehicle has a CAN bus with a free slot, and not every site runs a vehicle network
at all. Serial is the older, simpler answer: RS485, RS232, Modbus RTU or UART, one
interface per variant.
This route fits fixed plant — a gantry crane, a stacker, a conveyor-fed yard where the data
ends up in a PLC rather than a vehicle network. The receiver becomes a device the PLC reads,
and the PLC's own program decides what an alarm means.
What to ask for: which interface the specific variant has (they are separate part numbers,
not a dropdown), the register map, and the baud/parity defaults. Also ask whether the
vendor can supply a second protocol later on the same hardware — the answer is often no,
and that shapes how many spare parts you hold.
Route 3: receiver plus a 4G gateway into a platform
This is the route most fleet projects actually want: the vehicle talks to a cloud platform,
and nobody on site has to read anything.
There are two shapes of it. In one, the receiver itself has the cellular link and the
positioning built in — our 4G CAT.1 receiver with GPS is that shape, and it publishes
directly. In the other, a separate gateway reads the vehicle bus and forwards frames; our
CAN bus gateway is that shape, and it is also used for other vehicle data, not only tyres.
The platform-facing side is where projects stall. Two things have to be agreed:
1. Transport. MQTT, HTTP posts, or a vendor-specific socket. MQTT is the usual choice
for fleet platforms because it handles intermittent connectivity.
2. Payload contract. Field names, units, timestamps, and what happens to a message when
a sensor misses a reading. This is a document, not a feature.
What to ask for: a written payload example, not a promise that it "supports MQTT". And ask
who normalises the data if your platform expects a different schema — the vendor usually
sends raw readings and the platform does the mapping.
The receiver and gateway product pages describe the hardware side of this route:
the receiver range and the 4G / gateway products.
Route 4: receiver into somebody else's telematics unit
Many buyers do not want a new platform. They already run a telematics unit from a supplier
they trust, and they want tyre pressure to appear inside it.
This is the most underestimated route, because it turns into a three-party project: your
telematics supplier, the tyre-system supplier, and you. The telematics unit needs a way to
read the data — usually CAN at the vehicle, sometimes a serial port — and its firmware needs
a message handler for it.
What to ask: does the telematics supplier already read a tyre-pressure message, and if not,
will they add one? If the answer is "we can integrate anything", ask for the integration
document they would follow. That question separates a real capability from a sales answer.
What to put in the specification
Regardless of route, these are the numbers that decide whether the project works:
- Wheel positions per receiver: up to 256. One receiver covers a whole vehicle, so
fewer mounting points and fewer connectors.
- Sensor-to-receiver interval: 3 seconds or less, configurable. Get a number, not
"fast enough".
- Receiver-to-bus period: 10 ms on CAN 2.0B at 250 kbps default. This is what the
integrator needs.
- Outputs available: CAN 2.0B, J1939, RS485, RS232, Modbus RTU, PROFINET, UART.
- Supply: DC 10–30 V.
- Pressure accuracy: ±7 kPa; tyre temperature ±3 °C.
- Sealing: IP68 on the sensor.
Write the interval and the bus period into the purchase documents. They are the two that
are easiest to leave vague, and the two that decide whether the fleet system is usable.
The three mistakes worth avoiding
Asking for an API before agreeing a transport. "Do you have an API" invites a yes.
"Which transport, and can I see a payload example" gets you something you can build against.
Assuming the sensor count is the hard part. Counting wheels takes an afternoon.
Getting a payload contract signed takes longer.
Leaving the telematics supplier out of the first conversation. If they are not in the
room when the message layout is agreed, they will be in the room when it has to change.
If you are working through one of these routes now, tell us the vehicle, the wheel count and
where the data has to end up, and we will answer in writing about what the hardware exposes
and what your integrator still has to do. Send us the integration question.