Two systems on the same vehicle almost never share a record: the weighing controller knows axle load in kilograms, the tyre system knows pressure in bar, and nobody knows both at the same timestamp. Joining them is not a hardware problem — it is a data-layer problem, and it is solved by deciding four things before anyone writes code: which interface, at what cadence, with which scaling, and what happens when the link drops.
This note is written for people putting TPMS data into an onboard weighing or axle-load system, not for people comparing sensor brands. If you are still choosing the sensor, the products page covers the range; this page is about the layer behind it.
Why pressure belongs in a load record at all
A low tyre changes the way a vehicle sits. It reduces rolling radius on that wheel, shifts load onto its neighbours, and shows up as heat long before it shows up as a number anyone reads. In an axle-load record, that produces two practical problems:
1. A load reading you cannot explain. The axle weight moves between wheels without anyone loading the vehicle differently. If the record has no pressure channel, the anomaly looks like a sensor fault.
2. A tyre failure attributed to overload. The most expensive version of this argument happens after a blowout, when the question is whether the vehicle was overloaded or the tyre was under-inflated. A record with both channels answers it in one line.
That is the commercial reason to join the two systems. It is not about accuracy of either one — it is about being able to explain a number later.
The four decisions in the data layer
| Decision | What it fixes | The wrong choice looks like |
|---|---|---|
| Interface | Which physical path the receiving controller uses | A weighing controller with only one CAN port, and a tyre receiver that cannot share it |
| Cadence | How often each value is written | Pressure polled at 100 ms when the radio updates every 10 s — segment traffic for repeated identical values |
| Scaling | Raw register to engineering units | ±7 kPa sensor accuracy thrown away by a wrong factor |
| Gap behaviour | What the record shows when coverage or power drops | A hole in the record that looks like an overload event |
1. Interface: one per unit, decided at the factory
This is the part that most often forces a redesign. Our industrial receivers carry one interface per unit — CAN 2.0B, RS232, RS485 or Modbus RTU, chosen when the unit is built, not all four at once. If the weighing controller already occupies the only CAN port on the machine, the tyre receiver goes on RS485 as a Modbus RTU slave instead, and the weighing controller polls it.
Two facts to write into the specification rather than discover during commissioning:
- Our receiver is a Modbus RTU slave only. Your controller is the master and polls it; the receiver never initiates a transaction and never polls other devices on the segment.
- If your architecture genuinely needs two paths at once — for example CAN into the weighing controller and 4G to a platform — that is two units or a gateway, not one unit with a splitter.
2. Cadence: tie the poll rate to the radio, not to the register
A tyre sensor is a slow signal. The sensor wakes, measures and transmits on a configurable interval measured in seconds; the receiver refreshes its registers much faster. Polling the receiver at 100 ms does not give you fresher pressure — it re-reads the same value and consumes segment time that the weighing controller may want.
The useful rule: poll at or slightly faster than the sensor transmit interval, and timestamp on arrival. If the platform needs a faster heartbeat for its own liveness check, use a separate status register rather than polling the pressure registers.
3. Scaling: ask for the conversion in writing
Every integration we have seen go wrong at this layer went wrong the same way: the sensor was accurate and the factor was not. Two numbers must come from the supplier in writing before the database block is written — the raw-to-engineering conversion for pressure, and the conversion for temperature. Temperature conversion factors get forgotten more often than pressure ones.
4. Gap behaviour: buffering is part of the specification
On a vehicle, coverage and power both fail intermittently. The receiver buffers locally and uploads when the link returns, which means the record has a timing gap but not a content gap. What matters for a weighing record is that the gap is marked, not silently interpolated: a hole in pressure data next to a spike in axle load is exactly the combination that starts an argument with a customer or an insurer.
Parameters worth putting in the same document
These are the figures we specify for the 433.92 MHz industrial line. They are the ones that decide whether the two systems can share a record at all.
| Item | Value |
|---|---|
| Radio | 433.92 MHz, licence-free band |
| Pressure range | 0–4.5 bar / 0–9 bar / 0–13 bar depending on application |
| Pressure accuracy | ±7 kPa |
| Temperature range | −40 °C to +125 °C (internal sensor) |
| Ingress protection | IP68 |
| Wheel positions per receiver | up to 256 |
| Interfaces | one of CAN 2.0B, RS232, RS485 or Modbus RTU — factory-set, one per unit |
| Modbus role | slave only |
| Battery | internal version specified for 5+ years; external version uses a replaceable CR1632 cell, specified for 2+ years |
| J1939 | 29-bit extended frame; we have deployed J1939-format message sets in construction machinery integrations with major OEMs, and the layout is documented so it can be aligned to your DBC |
CE for both product lines is in progress, and we expect to hold it in November. We do not claim certification before we hold it, which is why it is written that way.
What this does not do
A tyre pressure channel does not make an onboard weighing system more accurate, and it is not a substitute for a weighbridge. Pressure is a slow, wheel-level signal; load is a fast, axle-level one. The value is in the record, not in the measurement: one timestamp, one vehicle, both channels, explainable later.
If the weighing controller and the tyre receiver are specified together, this is a configuration question. If they were specified separately by two suppliers, expect one of them to need a second interface — and that is better discovered before the purchase order than during commissioning.
A question to take to your next integration meeting
When your weighing controller polls a second device, which field in its record holds the timestamp — the controller's own clock at poll time, or the value's arrival time from the device?
That single answer decides whether the two channels can be joined at all, and most teams have never been asked it. If you are working through that now, tell us which controller you are using — for example the TR-100 receiver series with a Modbus master, or a CAN-only setup — and we will send the register layout and a payload example for that specific case rather than a generic datasheet. You can also see how we handle the PLC and Modbus path on our solutions page, or write to us directly through the contact page.