The single most important sentence
The receiver is a Modbus RTU slave. It answers; it does not push.
That one sentence decides the whole integration. Your PLC or controller is the master: it decides when
to ask, how often to ask, and what to do with a missing answer. If you design as if the receiver will
"send when something changes", you will build a system that looks dead and blames the hardware.
Everything else on this page follows from that.
What the interface actually is
The receiver is built with one interface per unit, fixed at the factory — Modbus RTU is one of the
options (the same hardware is also built as CAN, RS232 or RS485). It is not four interfaces at once, and
it cannot be reconfigured in the field to be a different one. So "Modbus RTU" appears on the order, not in
a settings menu.
Physically Modbus RTU runs on RS485 in most installations: two wires plus a reference, multi-drop along
the machine. Three details decide whether it is reliable, and none of them is in the protocol:
- termination at the physical ends of the segment;
- bias so an idle line sits at a defined level;
- ground reference shared by all nodes, because a floating reference is how "it works on the bench"
becomes "it drops frames in the cabinet".
How the register map is organised (and why we do not publish a generic one)
A TPMS receiver has to present, per wheel position, at least pressure and temperature, plus status
information: which positions are heard, which sensor IDs are bound, battery condition, and the age of the
last reading. How those are packed into 16-bit registers is a design decision, and it differs with the
configuration — how many wheel positions are enabled, whether the frame carries raw sensor IDs, whether
temperatures are signed.
So the register map is supplied with the unit, per project. What this page can do is tell you how to
prepare for it, and what to check when it arrives.
When the map arrives, read these five things first:
| # | What to look for | Why |
|---|---|---|
| 1 | Register type — holding vs input registers | Decides whether you use function 03 or 04 |
| 2 | Word order for 32-bit values | A pressure packed as two registers can be either order; getting it wrong gives a plausible wrong number |
| 3 | Scaling factor per value | Raw counts × 0.1 kPa is not the same as × 1 kPa; a missing factor looks like a calibration error |
| 4 | Signed vs unsigned temperature | Sub-zero temperatures become 65000-ish values if you treat them as unsigned |
| 5 | Which positions come first | The mapping from register index to wheel position is the thing your maintenance team will live with |
That last one is worth dwelling on. A mapping that is technically correct but does not match the way the
machine is described ("front left, inside rear, third axle") will be misread by a human under time
pressure. Ask for the map to be expressed in your axle/position convention, not in "index 0..N".
A polling example (shape, not addresses)
A typical read is a single request for a block of registers, then a fixed layout on the response. In
pseudocode:
```
every 2 s:
request = slave_id, function 03, start_register, register_count
response = send(request) with timeout 300 ms
if no response:
retries += 1; if retries > 2: mark link down; continue
parse response as map describes (word order, scale, sign)
for each enabled position:
update pressure, temperature, last_seen
```
Three notes on that shape:
Poll slower than the data changes. The receiver publishes on a 500 ms cycle on the output side, so
polling at 100 ms does not give you fresher data — it gives you four identical answers and more bus
traffic. Two seconds is usually enough for a tyre-pressure decision, and it leaves headroom for other
nodes on the same segment.
Keep a last_seen per position. A position that stops appearing is a finding, not a gap. The receiver
can only report what it hears; if a sensor goes quiet or a radio path closes, the register simply stops
updating. Without last_seen, that looks like "a tyre at a stable pressure", which is the one wrong answer
you must not give.
Timeout is a state, not an error. A missing reply should set a link state (and eventually an alarm of
its own), not throw an exception that stops the scan. Bus faults are transient; a scan loop that dies on
the first timeout will be found dead days later.
Alarm logic: the part that decides whether people trust the system
Two rules, learned the hard way on vehicles and machines:
Do not alarm on a single sample. Alarm when a value is out of band for N consecutive polls, or when
it is still moving in the wrong direction on the next poll. One sample is noise; a trend is information.
Separate "low pressure" from "no data". They are different failures with different actions: a low
tyre needs the vehicle stopped; a silent position needs someone to look at a sensor or a radio path.
Merging them into one "tyre fault" alarm trains the operator to ignore both.
If you want a third state, the useful one is "sensor heard but not yet bound to a position" — that is
what you see during commissioning, and it is much better to see it on a screen than to wonder why one
wheel is missing.
What to send us to close the loop
Four things, and we answer in writing before anything ships:
1. Master model and polling rate — the PLC or controller, and how often you want to read.
2. Wheel positions and their naming — how your team describes positions, so the map matches it.
3. Existing segment — how many nodes, cable length, termination and bias already in place.
4. Alarm policy — thresholds, how many samples before an alarm, and what a "no data" position should do.
With those, the integration is a configuration exercise rather than a debugging one. Modbus is an old,
well-understood protocol; almost every Modbus integration failure in this application is a mismatch in
those four items, not in the protocol.
See the receiver and sensor options on the product pages, the interface choices on the
TR100 receiver page, and the general PLC view on the
PLC integration page. The register map for your configuration is