You are not buying sensors
An industrial TPMS project has three parts: the sensor on the wheel, the radio link to the receiver, and the interface into whatever reads the data. Only the first is a commodity. Sensors are specified on a datasheet and can be compared between suppliers in an afternoon — pressure range, accuracy, battery life, ingress protection.
What cannot be compared so easily is the third part. 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 — limiting speed when a tire runs low, or derating — or whether the operator simply gets another screen to ignore.
So the real question is not "whose sensor is better". It is "can this supplier fit my controller, and can they prove it".
Six questions that separate a manufacturer from a trading company
Ask these in the first conversation. The answers are hard to fake.
1. Which protocols do you output on, and can I see the message map?
A manufacturer owns the firmware, so it can produce a message map or DBC file on request. A trading company has to ask its factory, and the answer arrives slowly or not at all. If the supplier cannot put a byte layout in front of you, the integration risk is yours.
2. How many wheel positions does one receiver support, and what happens on a long chassis?
The number matters less than the second half of the question. Anyone can quote a capacity figure. Repeater planning is engineering: on a long vehicle the radio path is blocked by structure, and the placement has to be worked out per machine. If the answer is "you won't need repeaters", that is a warning sign.
3. What is the largest machine you have actually instrumented?
Not the largest you *could*. Ask for the configuration: how many receivers, how many repeaters, how many sensors, and what the customer's result was. A supplier with a real field record will answer immediately and specifically.
4. Can you adapt the protocol, enclosure or display to our specification?
If the answer is no, you are buying a catalogue product. If the answer is yes, ask what the process looks like: who writes the firmware change, how it is validated, and what the minimum order is. That tells you whether there is an engineering team behind the sales address.
5. Who develops the sensor, the receiver and the cloud platform?
A full-stack supplier has less to coordinate. A supplier who assembles from third-party modules will always be a step removed from the fixes you need. Ask which parts are theirs.
6. What does certification look like for my market?
A supplier who claims every certificate for every market is not being careful. A supplier who asks which market you are selling into, and then names the standards and the test house, is.
What to put in the request
You will get a much better proposal if the first message contains five things:
- Wheel count and axle layout — a drawing is fastest, but a count is enough to start
- Operating voltage of the machine
- Which controller or system receives the data — and the protocol it already speaks
- Environment — mining, port, road; temperature range; whether there is a washdown
- Whether a cab display is required — many integration projects need none
With those five, a competent supplier can propose a configuration, a sensor count and a quote without a second round of questions. If you get a generic catalogue back instead, that is also information.
Where quotes go wrong
Two things to watch when comparing suppliers.
Sensor count assumptions. A quote that assumes one sensor per wheel, on a machine where the spare is also monitored, will be short. Ask how the count was derived.
Repeater count omitted. The cheapest quote often quietly leaves repeaters out, because they are only needed once you are on the machine. Get the repeater count in writing — it is the single most common line that changes after the order.
Ask both questions in writing and compare the answers side by side, because the cheapest total is often the one built on the shortest list of assumptions.
What good looks like after the order
The interface work does not stop at delivery. A supplier worth keeping will hand over:
- Message map or DBC, and a register map for serial output
- Alarm semantics — what each flag means, and how thresholds are configured
- Connector pinout, so your harness is right the first time
- A configuration tool for wheel count, sensor IDs and thresholds
- Someone who answers protocol questions, rather than forwarding them
That last one is the real test. Industrial TPMS is a small field; the difference between suppliers shows up in month two, when your controller is not reading the frames you expected.
How we work
GZVIA designs and builds the sensor, receiver, repeater, display and cloud platform in-house in Shenzhen. We supply port machinery builders under their own brand, instrumented a 160-wheel beam carrier in production, and the largest single machine we have done carries 224 wheels across 28 axles. The same engineering team handles firmware changes for OEM and ODM programs, which is the part a trading company cannot offer.
If you send the wheel count, the operating voltage and the controller that has to receive the data, we will reply with a configuration, the protocol documentation list and a quote.
See the CAN bus TPMS integration page or send us the machine details.