The short answer
A CAN bus TPMS is a tire pressure monitoring system whose receiver publishes tire data as standard CAN frames, instead of keeping that data inside its own display. The pressure sensor still sits on the wheel, the radio link is still there, but the last step changes: the receiver becomes a node on the machine's network rather than a box with a screen.
That sounds like a small difference. It is the difference between a product and a component. A display tells a human what the pressure is. A CAN bus TPMS tells the machine, so the machine can do something about it.
The signal chain, in order
Every industrial TPMS has the same three stages. Only the third one is different in a CAN bus system.
1. A battery-powered sensor inside or on the wheel measures pressure and temperature.
2. The sensor transmits over 433.92 MHz license-free radio to a receiver mounted on the chassis.
3. The receiver decodes the readings and outputs them on CAN.
The receiver is usually supplied from the vehicle's own electrical system at DC 10-30 V, which covers both 12 V and 24 V machines without adding a converter. On the CAN side, the interface is CAN 2.0B at a default of 250 kbps and a data cycle of 500 ms. Both are software configurable, because no two machines have the same bus budget.
What is actually on the wire
A CAN frame from a TPMS receiver carries a small, fixed payload, and what matters is that you can read the layout before you buy.
Typically each frame carries a wheel identity, pressure in kPa, temperature, and a set of status flags. The flags are the part buyers underestimate: low pressure, rapid leak, sensor battery low, and no signal are different conditions with different urgency, and they need different handling in your controller. A receiver that sends only pressure values forces you to invent your own alarm logic, and you will invent it worse than the people who wrote the firmware.
Wheel identity is the other quiet decision. A frame can identify a sensor by its radio ID, by a wheel position number, or by a position the customer defines when the system is commissioned. On a four-wheel machine any of the three works. On a 160-wheel machine, position mapping is a process, and it needs to be documented, not remembered.
This is why the first document to request is the message map or DBC file. We publish one for our receivers, and any manufacturer who owns their firmware can do the same. If a supplier cannot show you a byte layout, the integration risk is yours and it stays yours.
Why the data cycle is 500 ms
Tire pressure is a slow variable. It moves with temperature and load over minutes, not milliseconds. A 500 ms cycle, which is two updates per second per wheel, is fast enough to catch a leak in progress and slow enough to leave bus bandwidth for everything else the machine needs.
A rapid leak does not need microsecond determinism to be useful. It needs to be noticed within a second and surfaced as a flag that the controller can act on: derate, limit speed, or stop. That is a control decision, and the controller should make it, not the TPMS display.
If a project demands a faster or slower cycle, that is normally a configuration line rather than a different product. Ask for the range before you assume it.
What a CAN bus TPMS is not
It is not automatically J1939. J1939 is a higher-layer protocol that runs on top of CAN, and a receiver can output raw CAN 2.0B, J1939, or both at once. Which one you get is a specification question with a written answer, not a marketing claim. See the CAN bus TPMS integration page for how the protocol layer is chosen.
It is not a display system with a CAN port bolted on afterwards. You can often tell the difference from the alarm semantics: on a genuinely bus-first product, the flags, the thresholds and the frame layout are all configurable and documented. On an adapted display product, they are fixed and vague.
It is also not a sensor purchase. Two suppliers can sell you the same pressure accuracy and still deliver very different projects, because the work is in the frame layout, the alarm logic and the configuration tool.
Capacity, and the number that matters more
One receiver accepts up to 256 wheel positions. On a four-wheel machine that figure never comes up. On a long vehicle it does, but it is rarely the real limit: the limit is the radio path, because the chassis itself blocks 433.92 MHz signal.
That is why repeaters exist. Our production record includes a 160-wheel beam carrier built as two receivers, twelve repeaters and 160 sensors, with ten units delivered. The largest single machine we have instrumented carries 224 wheels across 28 axles. Neither number came from a bigger receiver; both came from planning the radio link.
The physical layer worth confirming
These values should be on the datasheet, and they should match what the supplier states in writing:
- Pressure accuracy of ±7 kPa, temperature accuracy of ±3 °C
- Internal sensors rated from −40 to +125 °C, external sensors from −20 to +85 °C
- IP68 sealing on the sensor
- 433.92 MHz license-free operation, so the customer needs no radio licence
- Infineon sensor silicon
- Battery life of at least 5-6 years for the internal sensor, and at least 2 years for a replaceable CR1632
If any of those is missing from the datasheet, that is a question, not a rejection. If it is missing from the conversation, that is a problem.
Questions that decide the project
Before ordering, put these five in front of the supplier:
1. Can I see the message map or DBC file before I place the order?
2. Which protocols does the receiver output, and can more than one run at the same time?
3. How are wheel positions identified on the bus, and what happens to that mapping when a sensor is replaced?
4. Which alarm flags exist, and how are the thresholds configured?
5. What is the largest machine you have actually instrumented, and in what configuration?
The answers tell you whether you are buying a component or a box. The TR100 receiver product page shows the configuration detail we publish for our own hardware.
Where we sit
GZVIA designs and builds the sensor, receiver, repeater, display and cloud platform in-house in Shenzhen. We supply port machinery under customer brands and our receivers speak CAN, J1939, RS485, RS232, Modbus RTU, PROFINET and UART.
Send the wheel count, the operating voltage and the controller that has to receive the data, and we will reply with a configuration, the protocol documentation list and a quote. Tell us about the machine.