RS485 with Modbus versus CAN with J1939
Before choosing a protocol, answer two questions. Where does tire data land first — on the machine controller, on a gateway, or directly in the supervisory system? And who owns the alarm: an operator who must react within seconds, or a planner reading a tire trend next week? Protocol, point names and poll rates all follow from those answers.
CAN and Modbus are often presented as competitors. They are not: they sit at different layers, and each fits a different part of the chain.
CAN with J1939 is a bus for machines. The receiver is a talker: it publishes on its own schedule, with frame-level integrity, priority arbitration and per-node error counters. If the machine already runs J1939, tire data joins as one more source and your integration work is a decoder plus a message map — with diagnostics for free and priority for a rapid-leak alarm.
RS485 with Modbus RTU is a bus for panels. A PLC or a supervisory system polls slaves in turn. Nothing speaks unless asked, so freshness equals your polling interval and a silent node stays silent until you implement timeouts. In exchange it needs no new fieldbus, and every industrial controller and SCADA package can read it.
A short way to choose:
- Controller already has CAN, and something else is on that bus — use CAN.
- The data lands in a PLC or directly in SCADA over serial — use Modbus RTU.
- You do not know yet — buy a receiver that offers both. Ours do, from the same hardware family, so the decision stays reversible. The CAN bus integration page covers the CAN route, including distance and speed trade-offs, in more depth.
The point table is the contract
The interface document matters more than the protocol choice. Whether it is a DBC file or a register map, it has to contain the same five things for every value:
- The identifier, in the naming your operators and maintenance records already use
- Byte order, start bit or register address, and length
- Scaling, offset and unit, explicitly in bar or psi and degrees Celsius
- Valid range, and what an invalid or unavailable value looks like on the wire
- Update behaviour: what changes when, and what a heartbeat looks like
Two rules save projects.
Publish by wheel position, not by sensor serial number. The receiver should present each value as the position it belongs to, and the wheel map — sensor identity to position — should live in a document the point table references. If SCADA decodes raw sensor IDs, every tyre change becomes a software change.
Write the alarm semantics once. Threshold, hysteresis, rapid-leak criterion, sensor-loss behaviour, and the delay before a state is declared. If two layers compare pressure against their own thresholds, they will eventually disagree — usually during an incident.
Polling, latency and the stale-data budget
Tire pressure is a slow signal, so the temptation is to assume latency does not matter. It matters in one specific case: alarms.
On CAN, the receiver publishes on its own schedule — our CAN output runs at 250 kbps with a 10-millisecond data cycle, and both are software-configurable. Freshness is therefore not a function of anything you write.
On serial, freshness is arithmetic: poll interval times the number of devices, plus retries. A supervisory system polling one receiver every 200 milliseconds is fast enough for tyre trends and usually for a leak alarm. A segment with a dozen devices at a slow scan class is not — no alarm logic fixes a value that arrives late.
Then add up the whole chain once, on paper:
1. Sensor to receiver over the radio at 433.92 MHz
2. Receiver to PLC or gateway
3. Gateway to PLC scan, and PLC to the supervisory system
4. The supervisory system's own scan class, plus any alarm delay you configured
Steps three and four are where projects lose the second they thought they had. Define two numbers up front: alarm latency, in seconds, and trend latency, in minutes, and check every hop against them.
One more rule, and the one that causes real damage: a communication timeout must read as unknown, not as normal. A stale value that still looks plausible is worse than no value, because the alarm logic treats it as a healthy tyre. Carry a per-position quality flag, and treat bad quality as its own alarm.
Getting alarms into the supervisory layer properly
Generate the alarm where the state is, then deliver it as a state with a timestamp. Practical points:
- Carry a status or alarm word per wheel position, so SCADA reads a state rather than deriving one from a pressure value.
- Separate and debounce the classes. Low pressure, high pressure, rapid leak, high temperature, sensor lost, comms lost: different priorities, and both radio and serial links produce single-sample glitches, so decide the delay once and implement it once.
- An acknowledgement in the supervisory system must not clear the physical alarm on the machine. The operator acknowledged the message; the tyre is still flat.
Where integrations usually go wrong
1. Byte order or scaling wrong. Test with a known pressure and temperature before you trust any number.
2. Polling too fast on a shared serial segment, or too many nodes for the scan class, producing timeouts that look like sensor faults.
3. Communication loss treated as "pressure fine". The most dangerous configuration error.
4. Two alarm engines with different thresholds, one in the PLC and one in SCADA.
5. A wheel map that goes stale after a tyre change, so alarms name the wrong position and operators stop believing them.
6. Physical layer mistakes — no termination, a star instead of a daisy chain, a shield grounded at both ends, or a segment shared with a function that matters more than tyre data.
A commissioning pass that checks one known pressure per wheel, simulates each loss and times a rapid leak end to end catches all six.
How we hand over
GZVIA develops sensors, receivers, repeaters, displays and the cloud platform in Shenzhen. A receiver addresses up to 256 wheel positions with pressure accuracy of ±7 kPa, and the same hardware family speaks CAN 2.0B, J1939, RS485, RS232, Modbus RTU, PROFINET and UART — including the TR-100R CAN and RS232 variants, the TR-300R repeater and the DB-4G-01 cloud gateway.
For an integration we hand over the message map or DBC file, the register map, the alarm semantics, a pinout and a wheel map template, and walk your integrator through the first commissioning. Send us the controller or SCADA package you read into and the wheel count, and we will recommend the interface that fits. Tell us about the machine.