Custom USB tyre pressure monitoring interface

**Robby BMW** · 10-12-2007, 11:47 AM

This threads explains how I've made my custom USB tyre pressure monitoring system by hacking this aftermarket kit bought on eBay.

Name: kit.jpg
Views: 104185
Size: 82.3 KB

The first step was to detect the RF transmission encoding method used by the sensors.
To do this it would have been required a very expensive logic analyzer, but fortunately I found this nice program that allows to simulate it (albeit with many restrictions) through the LPT port.

So the first thing was to open the display/receiver unit provided with the kit and, after having identified the receiver, start analyzing the data sent by the sensors.

Name: front.jpg
Views: 41969
Size: 39.4 KB

- the display unit -

Name: opened.jpg
Views: 41846
Size: 35.7 KB

- the display unit opened -

Name: cut_part.jpg
Views: 42195
Size: 70.8 KB

- the receiver part -

After many samples, I deduced that the encoding method used from the system is a sort of PWM format (Differential Manchester) with dT (basic pulse element) time of about 50 μs and a bit period of 2xdT (about 100 μs).

Name: pwm.jpg
Views: 42713
Size: 14.5 KB

Discovered this, I’ve noticed that the whole data packet consist of 12 bytes (96 bits) organized in this way:

Preamble (16 bits) - The preamble is a series of 15 logic ‘1’ bits followed by a single logic ‘0’ bit (FFFE in hexadecimal), used to recognize the RF transmission as a valid TX message.

Transmitter ID (32 bits): The 32 transmitter ID bits are used to uniquely identify each sensor.

Pressure (8 bit): The tire pressure in kPa is obtained by multiplying the unsigned binary value of this byte by 2.5 and subtracting 100 (the atmospheric pressure) from the result.

Temperature (8 bits): The temperature in °C is obtained by subtracting 40 from this unsigned binary value.

Battery (8 bits): The 7 least significant bits indicates the battery condition as percentage (100 indicate the 100% of charge).

Sensor state (8 bits): The bits 0 and 1 of this byte contains the following information:
00 = Initial mode (Pressure is measured every 0.85 seconds and data is sent every 0.85 seconds. This sequence is repeated 256 times)
01 = Normal mode (Pressure is measured every 3.4 seconds and data is transmitted every 60 seconds)
10 = Pressure alert mode (Pressure is measured every 0.85 seconds and data is sent every 0.85 seconds. This sequence is repeated 256 times)
11 = Temperature alert mode (If the temperature exceeds 120°C, the sensor device enters into the same measurement and transmitting pattern as the pressure alert mode)

CRC (16 bits): Implement according to CCITT (0xFFFF) standards.

Name: digital.jpg
Views: 41723
Size: 58.2 KB

- the whole data packet -

**Robby BMW** · 10-12-2007, 11:48 AM

After a relatively long time elapsed analyzing the data, the goal was to develop a device able to perform some operation such as:
- Learn the univocal sensor ID (like when a pairing is established between two Bluetooth devices). To be used during the first installation in the car or if a sensor is replaced with a new one.
- Read the data sent from every sensor and after an analysis to verify the validity (correct sensor ID and correct CRC), store them waiting a PC request. Since there is no way to know when a transmission happens, it is essential do this in real time.
- Handle the communication with the PC.
In addition, the device should have been easy to connect to the PC, small enough to be comfortably placed everywhere in the car and possibly be self-powered.
My choice was to use a PIC 18F2550, a Microchip microcontroller whit USB 2.0 compliant features, internal E2PROM memory and able to work with a clock oscillator up to 48 MHz.
The first attempt has been to use an SMD hybrid module operating on the frequency of 433,92 MHZ, but after various tests with some modules available on the market, I've noticed that the best result was with the original receiver embedded in the original display module provided with the TPMS kit, so I've decided to cut out it and use it in my hardware.

Name: part.jpg
Views: 41468
Size: 70.8 KB

- the display unit with the reciver part removed -

The schematic of the circuit is relatively simple and doesn't need further explanation, only a brief note about the transistor used to boost the signal coming out from the receiver, I've used a BC547 (European), but it isn't critical and can be replaced with an equivalent general purpose transistor like a 2N5818 (USA).

- schematic -

- copper side -

Name: board.jpg
Views: 41148
Size: 160.9 KB

- components side -

Name: 3D.jpg
Views: 33546
Size: 120.6 KB

- 3D view of the PCB -

**Robby BMW** · 10-12-2007, 11:49 AM

Name: circuit.jpg
Views: 41809
Size: 71.4 KB

- the real device -

Name: pcb.jpg
Views: 40684
Size: 77.7 KB

- the real device (copper side) -

The most difficult (and funny) part of the whole work was the development of the firmware for the microcontroller that, as described above, it should have analyzed the data received from the sensors in real time and, at the same time, to handle the data exchange with the PC.
This has led at the creation of an USB HID device, a particular device that doesn't require a driver installation on the PC where it will be connected, like a keyboard or a PS/2 mouse.
A Plug & Play device that make easy the development of software (stand-alone programs or plug-ins for the various Front Ends available on this forum) without the aid of special APIs.

In order to facilitate the communication between the device and PC, I have developed a simple communication protocol.
Basically the device waits for a request from the PC (1 byte) and returns the information required (4 byte).
The following table shows the protocol details:

00H (0) Abort any pairing request (see below) --> Returns: Nothing

01H (1) Sensor 1 pairing request --> Returns: Nothing
02H (2) Sensor 2 pairing request --> Returns: Nothing
03H (3) Sensor 3 pairing request --> Returns: Nothing
04H (4) Sensor 4 pairing request --> Returns: Nothing
05H (5) Sensor 5 pairing request --> Returns: Nothing

10H (16) State of a pairing request --> Returns: X,0H,0H,0H
Where X is the number of the sensor to be paired, or 0 if the pairing has been completed.

21H (33) Sensor 1 data request --> Returns: P,T,B,S
22H (34) Sensor 2 data request --> Returns: P,T,B,S
23H (35) Sensor 3 data request --> Returns: P,T,B,S
24H (36) Sensor 4 data request --> Returns: P,T,B,S
25H (37) Sensor 5 data request --> Returns: P,T,B,S
Where:
P is the pressure in kPa obtained by multiplying the unsigned binary value of this byte by 2.5 and subtracting 100 (the atmospheric pressure) from the result.
T is the temperature in °C obtained by subtracting 40 from this unsigned binary value.
B is the battery condition, the first seven bits of this byte indicate the percentage of charge.
S is the operating state of the sensor, 00H is storage mode, 01H normal mode, 02H pressure allert mode or 03H for temperature allert mode.

As example of how to use this device in your code, you can download a RoadRunner plugin and its source code here.
It is also in development a plugin for Centrafuse (thanks Wolfgang). For more information, see here.