Why BLE TPMS Needs No Receiver, and When It Does Why a BLE sensor needs no receiver at all, what that changes commercially, and the vehicle cases where a receiver is still required.

The receiver exists because of the radio

Traditional tyre-pressure systems use a licence-free radio band such as 433.92 MHz or 315 MHz. A sensor on the valve transmits; a receiver in the vehicle picks the signal up and passes the values to a display or a control unit. The receiver is not optional in that architecture. Without it, the sensor's transmission has nowhere to go.

That one fact — the receiver is a required part — shapes everything downstream. It adds a component to the bill of materials, a part to stock, a harness to route and an installation step to perform. On a car with an instrument cluster, that cost is absorbed by the vehicle. On a scooter or a light three-wheeler, it is often the reason a dealer declines to fit the product at all.

How BLE removes the part

A Bluetooth Low Energy sensor transmits on the 2.4 GHz band, 2400 MHz to 2483.5 MHz, using BLE 4.1 in our implementation. The important difference is not the frequency itself but who already has a radio capable of receiving it: the customer's phone.

Every modern phone has a BLE radio and a screen. That means the sensor has a receiver, a display and a processor available at no additional hardware cost to you — the phone the customer already owns. The product becomes a sensor and an app.

For our BPU100 the radio numbers are modest by design: transmit power 3 dBm at 1 Mbps, receiver sensitivity −95 dBm. That is enough for a wheel-to-phone link in normal use, and it means the radio is not straining a coin cell. The cell is a replaceable CR1632, and replacing it does not require re-pairing the sensor.

What that changes for a buyer

Removing the receiver changes four things that show up in a business plan, not only in a specification.

Bill of materials. No receiver, no display, no harness. What ships is a sensor set, a valve arrangement and packaging.

Stock and range complexity. One sensor platform with a phone interface is easier to hold across wheel counts than a platform where each vehicle needs a matched receiver and screen. A distributor's range stops multiplying.

Installation. Nothing has to be wired into the vehicle. For a dealer, that is the difference between a product they will fit while a customer waits and a product that needs an appointment and a technician.

Interface ownership. Alarm logic and thresholds live in software, which can be updated and branded, instead of being frozen in a display's firmware. The app page covers what that interface does today, and the BPU100 page carries the full specification.

The trade is real and worth stating: the phone is the display. If the customer does not carry the phone with them, there is no live readout.

The cases where you still need a receiver

BLE is not the right architecture for every vehicle, and the boundary is worth stating directly.

You need the reading on a fixed vehicle display. A truck driver does not mount a phone on the dash for tyre pressure, and a fleet operator does not want the data trapped on a driver's personal device. Where the vehicle has a screen and a network, the data belongs on that screen and that network.

The vehicle has a CAN bus and a telematics unit. Tyre pressure is one parameter among many, and a CAN receiver puts it on the bus with the rest. Our TR-100R-CAN outputs CAN 2.0B at 250 kbps with a 10 ms data cycle, and the platform supports up to 256 wheel positions — the architecture for trailers and multi-axle units. TR-100R-UART is the serial-output version for controllers without a CAN interface.

A phone-based interface is not acceptable to the end user. Some markets, some customer groups and some duty cycles will not use an app. A rental yard, a mine site or a workshop may want a permanent, tamper-resistant readout.

Several vehicles, one viewing point. A depot that wants every vehicle's pressures visible in one place needs the data to leave the vehicle, which means a receiver and a connection.

Alarms must work with no phone present. A low-pressure alarm that appears only if somebody is running the app is not an alarm for a parked fleet.

Our receiver page describes the options, and the heavy truck application page shows the kind of programme that needs them.

Range, battery and the honest limits

Three limits are worth understanding before committing to a phone-based design.

Range. A BLE link is short. In open air it is comfortable; through a wheel, a brake assembly and a vehicle body, less so. Mounting position matters, and a supplier who has not tested a sensor in a real wheel cannot tell you what your range will be. Ask about antenna orientation and about behaviour when the wheel is stationary, since a stationary wheel can sit in a null.

Battery. A coin cell is a finite resource. Transmit power, advertising interval and the app's polling behaviour all consume it. A replaceable cell with retained pairing turns a battery event into a routine service item rather than a replacement sensor. A non-replaceable cell turns it into a disposal.

Phone behaviour. The app has to handle absent data honestly. This is a software quality question, not a radio question, and it is worth asking any supplier what their app displays when a sensor stops reporting — a stale value, a blank, or a fault.

How to decide

Work backwards from the person who has to see the pressure.

If that person is the rider or the driver, holding a phone, a BLE sensor with no receiver is the simplest architecture, and the lightest in parts and installation. If that person is a fleet manager, a maintenance controller or an in-cab display, the data has to leave the vehicle, and a receiver is required. If both, the answer is often a platform that supports both paths, with the receiver added only on the vehicles that need it.

The useful question to put to a supplier is not "do you need a receiver" but "in what situation would you tell me I do". A supplier who answers "never" is selling rather than advising. We supply both paths, and which one fits depends on the vehicle and on who reads the number. Tell us the vehicle, the wheel count and who needs to see the pressure, and we will say which architecture the requirement actually points to.