Nissan/Infiniti TPMS ID & Pressure Confirmed... Checksum?

[MotorvateDIY]

First of all, a special thanks to chzu on Reddit. They explained pre-amble and that got me on my way!!

The data is from the TPMS sensor (PMV-C811) on my 2011 Infiniti G37 and captured using RTL-433.
This sensor seems to be used on many Nissan/Infiniti vehicles from around 2010-2020

The PMV-C811 (FCC ID: PAXPMVC811) uses an Infineon SP37 single chip TPMS sensor, with a clock of 19.687 Mhz and transmits at 314.98 Mhz using FSK modulation.

Raw signal capture:
7aaaaaaaf4cacab54ccb332d554a0

after applying and a preamble of 0x5557 and Manchester encoding we are left with a 38 bit data stream:
11010001000011110101001010100111111100

The TPMS sensor ID and pressure (n/4 = psi) have been validated. Here is the definition and a few examples of the tire pressure rising:

I tried to use various online CRC8 calculators, but didn't know how to modify/shift the bits as it is 4.75 bytes, so I got nothing.

My question are:
• Is it possible for a checksum to be only 2 bits?
• Any idea of what bits 1-5 are for?

Thanks in advance for any tips/suggestion!

Text of the 10 samples from the image above:
11010001000011110101001010100111111100
11110001000011110101001010100111111110
11110001000011110101001010101000000101
11110001000011110101001010101000001111
11110001000011110101001010101000010001
11010001000011110101001010101000010011
11010001000011110101001010101000011100
11110001000011110101001010101000100000
11110001000011110101001010101000100111
11010001000011110101001010101000101000

[zuckschwerdt]

The first check bit looks like even parity on each bit, the second looks like odd parity on every second bit. One code doesn't fit that scheme, you need more codes to confirm that guess.

[MotorvateDIY]

Thanks for the suggestion.
Over the next few days, I will record more TPMS messages and see if any pattern can be see.
Also, I will use a 125 Khz TPMS "activator" while I decrease the tire pressure.

[gdt]

Interesting that you are seeing n/4 as psi for pressure; that matches Ford TPMS sensors. While perhaps a different design that might be standard design practice. It's also interesting that there doesn't seem to be temperature.

[MotorvateDIY]

The n/4 tire pressure is the same format as the tire pressure that is broadcast on the vehicles CAN bus.
Not broadcasting temperature must of been a decision made by Nissan, as the TPMS IC (SP37) does have a temperature sensor.

As I see it, the only use for tire air temperature is to calculate the "cold air pressure" (pressure compensation) while the tire warms up when in motion. It would be interesting to see, but my car doesn't have it.

[gdt]

There are at least two uses for temperature:

• being able to warn on excessive temperatures as a safety issue
• pressure compensation as you say, so that one can assess if a tire's pressure is low when it is not cold
  but if they didn't include it, that's how it is -- just remarking that this is odd.

[MotorvateDIY]

Good points...
As this system was first used in 2010, I suspect the development would of started 3-4 years before that, so maybe at that time temperature wasn't important or the BCM didn't have the additional resources to process it... - just my guess :)

[MotorvateDIY]

In looking here: https://github.com/JoeSc/Subaru-TPMS-Spoofing

Subaru uses the 3 "Prepend"bits like this:
0x7:(no bits cleared) Sent during every "normal" transmission.
0x5:(bit 1 cleared) sent on the first transmission after the car has moved after sitting stationary for > ~1 minute.
0x3:(bit 2 cleared) I captured this when deflating tires.

I will see if that fits my sensor.

Also, this 2012 era Subaru sensor, doesn't seem to have a checksum, so maybe mine doesn't.

I guess I will find out when I broadcast the simulated TPMS signal.

[zuckschwerdt]

Also, this 2012 era Subaru sensor, doesn't seem to have a checksum, so maybe mine doesn't.

It's a guess, but xor'ing all bits, not including the last bit seems to always be 0 -> even parity on each bit.
And xor'ing every second bit seems to always be 1 -> odd parity on every second bit.

But that's needs a robust checking on maybe 50 to 100 message to exclude odd coincidences there.

[MotorvateDIY]

2023 Update: Nissan/Infiniti TPMS IDs and pressures are verified!!!

My analysis and https://github.com/alwilson/rtl_433/blob/master/src/devices/tpms_nissan.c are the same and verified on my 2011 G37.

The only change to the code I made was to remove the "correction" factor on line 68:

"pressure_psi", "Pressure", DATA_FORMAT, "%.1f PSI", DATA_DOUBLE, (double)(pressure_psi / 4.0) - 3.0,

to:

"pressure_psi", "Pressure", DATA_FORMAT, "%.1f PSI", DATA_DOUBLE, (double)(pressure_psi / 4.0),

Since the TPMS sensor uses "sealed gauge" (internal absolute pressure reference) it may or may not read the same as your tire pressure gauge, depending on your elevation. My elevation is 800' and the TPMS reads 1-2 psi lower than a calibrated gauge.

Two TPMS sensors from my car on BitBench:

http://triq.net/bitbench#c=f5555555e559a9a96a5969555594%20%5B%5D&c=f5555555e559a9a96a55565555a4%20%5B%5D&f=MODE%3A3b%20TPMS_ID%3A24h%20RAW%2FFOUR%3DPSI%3A8d%20UNKNOWN%3A2b&a=Preamble&m=555e&d=MC&cw=4

Screen shot of the "non-corrected" TPMS sensors from my car:

I'm not sure exactly how GitHub works, and the nissan.c code is not mine.... but
can the Nissan TPMS be added to the next release of RTL_433?

Thanks in advance!

[zuckschwerdt]

This can be closed, the code is waiting to be finished in #2536 and the request was already #1024 it seems.