Salida RS232 del TPMS - cableado a un PLC

The problem this solves

A PLC or a custom controller usually has a spare serial port long before it has a spare CAN

interface. So the shortest path to tyre-pressure data on a machine is often RS232: a receiver that

reports per-wheel pressure and temperature as a frame your firmware parses.

That path works, but it fails in a predictable way — not on the electronics, on the agreement. Two

sides build against different assumptions about the level, the frame and the baud rate, and the

mismatch surfaces during commissioning, when the machine is already assembled. This page is the list

of things to settle before anyone writes a parser.

1. Level: TTL or RS232 is a hardware choice

The receive module's serial port is 3.3 V TTL by default, with RS232 available on request.

This is a configuration item on the board, not a line in the firmware, and it is not a separate model

number — which means it has to be stated on the order, not discovered later.

Practical consequence:

• If your controller exposes a TTL UART (most embedded boards, many PLC communication modules), a

TTL-level receiver connects nearly directly — TX, RX, GND, common ground.

• If your controller exposes a real RS232 port (DB9 on industrial equipment, older PLCs), you want

the RS232 variant, because TTL into an RS232 line driver does not work and an external converter is

another part to power and protect.

• If the cable run is long or crosses a noisy cabinet, ask about isolation before you buy the

converter. A floating ground between two cabinets is a common source of "the port works on the

bench and dies in the field".

2. Frame layout: ask for the document, do not assume a format

The receiver reports per-wheel pressure and temperature. How those values are arranged in the frame

depends on two decisions you have to make explicitly:

• raw packets or a parsed frame — a raw packet side is closer to what the radio delivers; a parsed

frame is a stable structure that is easier to consume;

• which interface is fitted — the same hardware is built as CAN, RS232, RS485 or Modbus RTU, one

interface per unit, and the frame is described per interface.

So the frame layout is supplied with the unit, per project. What you should not do is take an

older serial document for a different module and design against it. Older documents in this product

family describe a *parsed* frame from a different module generation; the raw-packet format has

different length and frequency. If you build the parser against the wrong one, the symptom is not

"no data" — it is plausible-looking garbage, which costs far more time.

3. Baud rate: confirm it, do not inherit it

Our own specification for the serial link's baud rate is confirmed per project, not published as

a fixed number, because it depends on the frame format and the controller on the other side. That is

also why this page does not quote one.

What that means for your integration plan: baud rate goes in the same email as the frame request, and

it is agreed in writing before the unit ships. A receiver configured for a different rate than your

master expects will produce framing errors, and framing errors at 3 a.m. look like a hardware fault.

4. Wiring and the four questions

The physical layer is deliberately boring: TX, RX, GND, and a common reference. What matters is that

both ends agree on the reference and the driver type.

Before you write the parser, settle these four:

That is the whole integration contract for a serial link. Everything else — scaling, endianness, how

often to poll — follows from your controller's conventions, and we will answer those in the same

thread.

5. Reading the data well (the part that decides whether people trust it)

Two habits make the difference between a system that is trusted and one that is ignored:

Do not alarm on a single frame. A frame can be missed. Alarm on a value that is out of band for

N consecutive reads, or on a pressure that is still falling when the next read arrives. The data

cycle on the output side is 500 ms; your polling rate and your alarm window are yours to choose, and

they should be chosen together.

Log the position, not just the value. Per-wheel data that arrives without a position label is

nearly useless to a maintenance team. Whatever the frame gives you, map it to a wheel position and

keep that mapping in your controller — it is the difference between "a tyre is low" and "the inside

rear on the third axle is low".

6. Where this is used beyond vehicles

The same receiver and the same serial route are used on fixed equipment: an air shaft, a test bench,

a gas circuit. The interface does not change; what changes is the sensor and the pressure range.

Two things to flag early if that is your case:

• the range — the standard sensor covers 0–500 kPa gauge (about 5 bar), so a 7 bar shaft or an

8–10 bar receiver tank is above the standard part and needs a different sensor;

• the mounting position — a closed steel body blocks radio, so where the measuring point sits

decides whether the reading can exist at all.

Ask those two questions before the frame question. They decide whether the project is possible; the

frame decides only how fast it goes.

The short version

Level is a hardware choice, the frame is supplied per project, the baud rate is agreed in writing, and

the parser should be built against the document you receive rather than the one you find. Get those

four right and a serial integration is a morning's work — get them wrong and it is a week of

oscilloscope time.

See the receiver and sensor configurations on the product pages, the interface options

on the TR100 receiver page, and the PLC-side view on the

PLC integration page. If you want the serial integration note for your

controller, send us the four answers and we will reply with the configuration.

← Todos los artículos