Reverse-engineering TPMS sensors

I like to challenge myself regularly in order to keep my mind active and open to new information. One of my long-running ideas is to create an “infotainment” system for my car that is capable of displaying and logging vehicle sensors in addition to the standard media-playing functionality. Many of the vehicle sensors can be accessed through the OBD2 interface, but my car doesn’t have a factory tire-pressure monitoring system. This means I need to get a bit more creative to acquire that data. Enter my attempt to reverse-engineer some standard TPMS sensors.

Reverse-engineering tire-pressure monitoring system (TPMS) sensors takes a combination of research, educated guessing, and experimentation. Wikipedia has a good article for background information on TPMS: https://en.wikipedia.org/wiki/Tire-pressure_monitoring_system

For more information on what hardware is needed and what software to use, see: https://github.com/jboone/tpms
This is also the software which I will be using for this post.

Overview of the steps:

• Determine if your vehicle has direct or indirect TPMS
• Assuming direct TPMS, determine the sensor radio frequency band (likely 315MHz or 433MHz)
• Get a software radio receiver that can capture complex radio spectrum data at your target frequency
• Capture data while driving, ideally in an area with few other vehicles to minimize interference
• Examine capture files, looking for transmissions that are clear and strong

The following steps will require repeated experimentation:

• Pick a clear capture file to determine the modulation and approximate bandwidth
• Determine symbol rate by measuring time between bits
• Determine preamble (this is one of the more difficult steps to get right)
• Use these parameters to try to decode more data for more sample points

This process will only work with direct TPMS. Indirect TPMS doesn’t have sensors in the tires, so there is no information transmitted and nothing to capture using this method.
There are many options for software-defined radios. The most commonly available ones are based on the Realtek R820T2 chipset.

Examining capture files:

Once you have identified the radio encoding parameters that your sensors use, you can continue to work at determining the packet structure. This requires a fair amount of guesswork, but can be made easier by collecting data under controlled conditions. For example, identifying the pressure field can be done by capturing data while changing the tire pressure. Generally, TPMS sensors will go to sleep when the vehicle is parked, but rapidly changing pressure should put them into an alarm state. This can also help you determine how the sensor values correspond to actual tire pressure. By removing and re-adding air from the tire in recorded steps (and pausing in between), you should see a clear trend in the sensor data. Note that changing the pressure will also affect the temperature slightly.

Here is an example of the graphed data when varying pressure in a single tire.

When examining all your captured and decoded data, the sensor ID field will have 4-5 distinct values depending on how many sensors your vehicle has. Pressure and temperature will both vary while driving. There may also be a few status fields and a CRC/checksum. It is likely that fields will be 8 bits wide, so that’s a good guess to start.

I only have 3 functioning sensors, but here are some examples of the interesting fields that I was able to decipher:
bits[00,32]: sensor ID
bits[32,40]: status flags?
bits[40,48]: pressure (psi * 2.72 or so)
bits[48,56]: temperature (units not yet determined)
bits[56,64]: more status flags?
bits[64,72]: checksum (initial value: 0x00, polynomial: 0x01, XOR value: 0x00)

I’ve been able to identify all the information that I consider to be important (sensor ID, pressure, and temperature), but there is still experimentation to be done for the other values. So far, this process has taken me a few weeks of poking and prodding. If you decide to take on a similar challenge, I wish you the best of luck!