Sensor on the wheel
A 433.92 MHz sensor measures pressure and temperature inside or outside the tire and transmits on a licence-free band. No wiring to the wheel.
CAN Bus TPMS Integration for Commercial and Industrial Vehicles
A TPMS integration project succeeds or fails at the interface. This page is about that interface: how tire pressure and temperature get onto the vehicle bus your controller already reads, what documentation we hand over, and where projects usually break.
How tire data reaches the bus
Four stages, and only one of them is the sensor.
Repeater along the chassis
Long vehicles block radio. Repeaters are placed where the geometry demands, not by rule of thumb — on a 160-wheel carrier we use 12.
Receiver publishes to the bus
The receiver is the integration point. It holds up to 256 wheel positions and outputs tire data as CAN frames, serial strings or fieldbus registers.
Your controller reads it
The machine's own ECU, PLC, VCU or telematics unit reads tire data like any other node. Alarms can be wired into existing logic.
Output protocols and when to use each
The same receiver supports several output paths. Which one you pick depends on what the receiving system already speaks.
| Output | Typical receiving system | Notes |
|---|---|---|
| CAN 2.0B | Vehicle ECU, VCU, engine controller | Default 250 kbps, 500 ms data period, software-configurable. Message map supplied. |
| J1939 | Trucks, buses, off-highway machines with a J1939 network | PGN/SPN mapping for tire pressure and temperature; suitable for fleets that already log J1939. |
| RS485 | PLCs, industrial controllers, long cable runs in a yard | Multi-drop; good where CAN is not already present. |
| RS232 | Legacy controllers, GPS / telematics trackers, retrofit | Point-to-point; the usual choice for retrofitting older machines. |
| Modbus RTU | Siemens and other PLCs, SCADA | Register map documented; easy to read from a PLC without custom code. |
| PROFINET | Siemens PLC environments | For plants standardised on PROFINET rather than serial. |
| UART / TTL | Custom embedded boards, head units | For OEMs building the receiving board themselves. |
| 4G + REST API | Cloud platform, fleet dashboard | Not a fieldbus: the DTU uplinks the same data over cellular to our platform or your own. |
What documentation you get
Integration projects stall for one reason: the supplier hands over hardware and nothing else. We hand over the interface.
Message map / DBC
Byte layout, scaling, byte order and flag bits for every tire pressure, temperature and alarm frame.
PGN / SPN mapping
For J1939 projects, so your fleet software can decode tire data without a custom parser.
Register map
Modbus RTU and RS485 register addresses and data types.
Alarm semantics
What each alarm flag means, how thresholds are configured, and the reporting intervals.
Wiring and connector pinout
B+, GND, CANH, CANL and the sealed connector we use, so your harness is right the first time.
Configuration tool
For setting wheel count, sensor IDs, pressure thresholds and baud rate.
Integration process
What a project actually looks like from your side, and ours.
Describe the machine and the receiving system
Wheel count, axle layout, operating voltage, and which controller must receive the data. A wiring sketch from the vehicle side is enough to start.
We propose the chain
Sensor type per rim, receiver count, repeater placement and output protocol — plus a sensor count and a quote.
Evaluation units
You test on the bench or on one machine against your own controller, with the protocol documentation in hand.
Protocol adaptation if needed
If your controller needs different scaling, extra fields or a different alarm mapping, firmware or output mapping is adapted as part of an OEM programme.
Pilot, then volume
A small pilot order validates the installation and the packaging, then scheduled repeat deliveries.
Where integration projects usually break
These are the ones we have actually hit in the field.
-
01
Baud rate assumption
Assuming the bus speed matches your drawing. We default to 250 kbps and it is software-configurable — confirm before the first installation, not after.
-
02
Radio shadow on long chassis
A receiver that reaches 256 wheels on a yard machine will not reach 160 on a beam carrier without repeaters. Geometry decides, not the datasheet.
-
03
Byte order and scaling
Big-endian vs little-endian and the scaling factor are the two most common decode bugs. Both are stated in the message map; test one frame end-to-end before scaling up.
-
04
Alarm mapping into existing logic
Deciding what the machine does when a tire alarms — derate, limit speed, notify the operator — is a vehicle-side decision. Settle it before integration, not during.
-
05
Supply voltage and ignition behaviour
DC 10–30 V. On machines where the bus stays powered after ignition off, confirm the receiver's sleep behaviour with us.
Related pages
Where to go next, depending on what you are trying to solve.
Overview
All TPMS solutions
The four problem shapes we build around: integration, networking, multi-axle, IoT sensing.
ProductTR100 industrial TPMS
Up to 256 tires, CAN 2.0B / RS232 / RS485 / UART, DC 10–30 V, IP68 — full specifications.
ProgrammeOEM / ODM development
Protocol, enclosure, display UI and cloud API adapted to your specification.
IndustryTPMS for mining trucks
Rigid and articulated haul trucks, high-temperature duty, CAN integration.
IndustryTPMS for port machinery
RTG cranes, reach stackers, container handlers and stackers.
Next stepSend us the machine and the controller
Wheel count, voltage and target interface is enough for us to propose a configuration.
Tell us the controller that has to receive the data
Send the wheel count, the operating voltage and which system reads the data. We reply with a wiring plan, a sensor count, the protocol documentation list and a quote.