A tire pressure monitoring system is a sensing problem until the moment you try to connect it to a machine. Then it becomes an interface problem, and interface problems are where most projects lose weeks.
This note describes how tire data actually travels from a valve stem into a vehicle controller, so that a technical conversation with a supplier can start from the right place.
The sensor is rarely the hard part
An industrial TPMS sensor measures pressure and temperature and transmits them over a licence-free radio band — in our case 433.92 MHz. That part is well understood: pressure range, accuracy, battery life and ingress protection are all specified on a datasheet and can be compared between suppliers in an afternoon.
What cannot be compared so easily is what happens after the radio link. A receiver that only drives its own display is a closed product. A receiver that speaks the machine's own bus is a component. The difference decides whether the machine's controller can act on tire data — for example limiting speed when a tire runs low — or whether the operator simply gets another screen to ignore.
Three ways tire data leaves a vehicle
In practice we see three integration patterns, and they have very different consequences.
- Local display only. The receiver drives a 7-inch screen in the cab. Fastest to retrofit, no integration work, but the data stays in the cab and never reaches a fleet system.
- Fieldbus output. The receiver publishes tire data on CAN, RS485, Modbus RTU, Profinet or RS232. The machine's controller reads it like any other node, and alarms can be wired into existing logic.
- Cellular gateway. The receiver is paired with a 4G DTU. Data goes to a cloud dashboard, and optionally to the customer's own platform through an API. This is the pattern that scales past a handful of machines.
These are not mutually exclusive. The useful property is that the same receiver hardware supports all three, so a fleet can start with local displays and add networking later without replacing what is already installed.
What J1939 expects, and where TPMS fits
J1939 is the higher-layer protocol most heavy vehicles use on top of CAN. Data is organised into parameter groups, identified by a PGN, and individual values inside a group are addressed as SPNs. A controller that already consumes J1939 expects new data to arrive in the same shape as everything else — with a defined PGN, a defined byte layout, and a defined update rate.
Tire pressure and temperature do not have a universally agreed PGN in the same way engine speed does, which surprises people. In practice a TPMS integration therefore goes one of two ways:
- The supplier publishes a proprietary PGN or message set, and the OEM maps it into their own application. This is the common route for a first program.
- The two sides agree on a message layout that fits the OEM's existing convention, and the supplier implements it in firmware. This is normal in OEM/ODM work and is one of the reasons a supplier needs its own firmware team.
Either way, three numbers matter more than any marketing claim: the baud rate, the update or data cycle, and the byte layout. Ours defaults to 250 kbps with a 10 ms cycle, both software-configurable, because different machine families expect different rates.
What to ask a TPMS supplier for
Before a technical evaluation, request these four things. A supplier who cannot produce them will not be able to support an integration.
- A message or register map: which identifiers are used, what each byte means, how scaling and offsets work, and how faults are signalled.
- Baud rate and cycle time, and whether both are configurable in firmware or fixed at the factory.
- A bench setup description: what the receiver needs on the bench to start transmitting, so your engineer can reproduce it without the machine.
- An evaluation unit, with the protocol documentation, not after the order — during it.
If a supplier answers "CAN is supported" without a document, that is not an integration answer.
Points where deployments actually break
After enough installations, the failure modes stop being surprising.
- Radio shadowing on long chassis. A 20-axle machine blocks 433 MHz effectively. Repeater placement has to be planned against the chassis layout, not estimated. On a 160-wheel carrier we used twelve.
- Address assignment. With 250 possible sensor positions, someone has to map sensor IDs to physical wheel positions and keep that mapping when a sensor is replaced. Decide who owns that process before delivery, not after the first tire change.
- Ground and supply. Industrial vehicles are electrically hostile. Receiver supply range and protection matter as much as the radio spec, especially on machines with older charging systems.
- Alarm semantics. A low-pressure alarm that only lights a lamp in the cab is easy. An alarm that must trigger a speed limit or a log entry has to be specified with the same care as the measurement itself.
Where this leaves the specification
The productive first message to a supplier is not "send me your TPMS catalogue". It is a short paragraph: the machine, the number of wheel positions, which controller must receive the data, which interface it speaks today, and what the operator should be able to do when a tire is wrong.
With that, a configuration is answerable — receiver count, repeater count, sensor quantity, and the documentation set that goes with them. Without it, any answer is a guess dressed as a quotation.