TPMS Sensors not detected

[MiddleSiggy]

Hello,

I am looking for how to contribute to the RTL_433 project. I recently purchased 2 sets of TPMS sensors to be installed in my and my wife's vehicle but neither of them are detected after installation. But I can successfully detect them and program the car using a "MaxiTPMS T501" TPMS programmer so I know they work and the car finds them without issue.

I am assuming that the latest rtl_433 just does not know how to decode these devices yet.

I have attempted to try and figure out how to detect "unknown" devices and write a custom decoder, but I will be honest I am just struggling.

I have been in the IT field for more than 30 years and have plenty of knowledge in programming and what not. But I am struggling with the RF side of things and your tool, If you could assist, I am willing to put forth all the necessary effort to learn and help in this matter. I am even willing to buy every TPMS sensor I can find on Amazon and make sure we can detect the,

Please let me know how I can help, and if you can help me help the project.

Thank you.

[ProfBoc75]

Hi @MiddleSiggy :

About RF signals, you have to understand few key principles.

• The Frequency, or the central frequency of the signal, this is my first advice, is to check the exact frequency of the TPMS sensors. Just to be sure that you're listening the good one.

• The bandwidth, this is directly linked to the data speed transfer and coding, and it's directly linked to the sample rate too : at 433MHz, by default in rtl_433, the sample rate is 250Kps, at 868MHz, the default is 1024Kps. At these level, the data speed must be less than the half of sample rate, so max 125Kbps and 500Kbps. This speed is linked to the pulse (short, long), gap, sync duration, this could be check with the -A option when listening for a signal. TPMS sensors are simple devices, the TX is less than 20Kbps, so 250KHz sample rate is more than enough.

Default rtl_433 central frequency is 433.92Mhz, @ 250 KHz , so it's able to capture RF from 433.795Mhz to 434.045MHz. Outside frequencies are not listen nor decoded, you must provide a frequency like rtl_433 -f 433.42M at 868 MHz @ 1MHz rate, RF capture is from 867.5MHz to 868.5 MHz.

• Which RF modulation : FM (Frequency modulation) or AM (amplitude modulation), ie FSK or OOK/ASK. With FM/FSK you have 2 frequencies, and AM/OOK/ASK you have only one frequency.
• Which RF pulse : PWM, PCM, ...
• Which pulse coding : no coding, MC , RZ, NRZ ...

From current TPMS decoders, most are FSK PCM coded, but not all, so you need to check that with following tools and guides here too : https://triq.org/

If you are able to get RF information, then you can play with -A and -X flex decoder option, and refine the short, long, reset, ... values.

To get help of flex decoder. rtl_433 -X

if you recorded cu8 samples, you can replay them with -X option, so you don't need to wait after an RF signal to be transmitted. To replay with flex decoder, example : rtl_433 -A -X 'n=chacon,m=OOK_PWM,s=700,l=1400,y=3000,g=1500,r=1400,bits>=24' -r g001_433.92M_250k.cu8 rtl_433 -X 'n=TPMS,m=FSK_PCM,s=52,l=52,r=150' -r *.cu8

Said that, I guess you already looked into the Wiki of rtl_433 that explain how to proceed.

From your side, may be your device is already covered by rtl_433 but not able to be decoded, so, you have to try with the debug mode, -vv (verbose info) to see if you have errors that can be linked to a TPMS device.

You can also capture samples with the -S all option and see with pulseview tool if you can get the RF information.

If you need us to help you decoding these captures, just copy/paste in comment few of them (cu8 files) , and provide which tire is related to (tire position or any id), the temp & the pressure information you have in your car for each file.

Also have a look into existing decoders to write your own one or to correct an existing one not properly handled.

[MiddleSiggy]

Hello ProfBoc75,

First thank you for all of that.

I know the Frequency of these TPMS devices (315M) as it is labeled on the devices, and I can detect them with my TPMS programming tool, which also shows the Freq it detected the device at.

I do have a Raspberry Pi running rtl_433 @ the 315M and it does detect some of my other vehicles (My daughter's Toyota and the Spare Tire from my vehicle, which was not changed when I got new tires)

I played with the -X switch, but I have not tried all of your suggestions so I will do a little more poking around and will then most likely come back with some more specific questions.

Again thank you.. and be in touch shortly.

[ProfBoc75]

Hi @MiddleSiggy .

Good start point.

To start record the rf signal, remove the antenna from the RTL-SDR dongle (to avoid receive other sensors when using -S all), keep around 1 meter between TPMS and RTL-SDR dongle. Could be little less, but not too close as the signal will clipping.

rtl_433 -f 315M -S all

This will create the gxxx_315M_250k.cu8 files, one file each time a rf signal is received, xxx number will increase. You may keep like that for few minutes, write down the values from your car at the same time you received the signal to help the decode part.

Keep the file names, since it's use by pulseview to get the central frequency and the sample rate. So, you can drag n' drop cu8 to pulseview to get a first analyzis.

Then upload here the few files and your notes, you can zip them to upload one file if you want. You have also rtl_433_tests repository to upload such information too. Theses files are very useful for us to help you to the decode part and to be able to replay the files later in case of issue or any improvement.

To be continued ...

[MiddleSiggy]

@ProfBoc75

I did some testing / work... See the notes below, I also attached the notes and samples in the attached file.

Process Followed:

• I removed the antenna from the SDR
• I used rtl_433 to capture the signals with the command 'rtl_433 -f 315M -S all'
• I Placed each TPMS sensor directly on the radio (4 in total)
• I used my MaxiTPMS TS501 to Detect, and Activate each TPMS Sensor, and validate it's ID
• I let the sensor sit until I captured 5 Samples
• Because of this the First capture could have more information as it is my understanding that the programmer sends a signal to the sensor to wake it up. Although I believe it is on a different frequency.
• I then replayed each sample with the following command: 'rtl_433 -A g003_315M_250k.cu8'
  • I assume this does it best, and tried to detect the data in the stream

For each Sensor this is what was detected for the Flex Decoder guess:

SENSOR 1:

Sensor: TPMS-A4CB100D File: g001_315M_250k.cu8 -X 'n=name,m=FSK_PWM,s=48,l=100,r=160,g=0,t=0,y=156' No clue... -X 'n=name,m=FSK_PWM,s=48,l=100,r=160,g=0,t=0,y=156' -X 'n=name,m=FSK_PWM,s=48,l=100,r=160,g=0,t=0,y=152'

Sensor: TPMS-A4CB100D File: g002_315M_250k.cu8 -X 'n=name,m=FSK_PWM,s=48,l=100,r=160,g=0,t=0,y=156' No clue...

Sensor: TPMS-A4CB100D File: g003_315M_250k.cu8 -X 'n=name,m=FSK_PWM,s=48,l=100,r=160,g=0,t=0,y=156' -X 'n=name,m=FSK_PWM,s=48,l=104,r=160,g=0,t=0,y=156'

Sensor: TPMS-A4CB100D File: g004_315M_250k.cu8 No clue... -X 'n=name,m=FSK_PWM,s=48,l=100,r=160,g=0,t=0,y=152'

Sensor: TPMS-A4CB100D File: g005_315M_250k.cu8 -X 'n=name,m=FSK_PWM,s=48,l=100,r=160,g=0,t=0,y=152' -X 'n=name,m=FSK_PWM,s=48,l=100,r=160,g=0,t=0,y=152'

Sensor 2:

Sensor: TPMS-A4CB19F6 File: g001_315M_250k.cu8 No clue... No clue... No clue... -X 'n=name,m=FSK_PWM,s=48,l=104,r=160,g=0,t=0,y=156'

Sensor: TPMS-A4CB19F6 File: g002_315M_250k.cu8 -X 'n=name,m=FSK_PWM,s=48,l=104,r=156,g=0,t=0,y=156' -X 'n=name,m=FSK_PWM,s=48,l=100,r=160,g=0,t=0,y=152'

Sensor: TPMS-A4CB19F6 File: g003_315M_250k.cu8
-X 'n=name,m=FSK_PWM,s=48,l=100,r=160,g=0,t=0,y=152' -X 'n=name,m=FSK_PWM,s=48,l=100,r=160,g=0,t=0,y=152'

Sensor: TPMS-A4CB19F6 File: g004_315M_250k.cu8
-X 'n=name,m=FSK_PWM,s=48,l=104,r=160,g=0,t=0,y=152' -X 'n=name,m=FSK_PWM,s=48,l=100,r=160,g=0,t=0,y=152'

Sensor: TPMS-A4CB19F6 File: g005_315M_250k.cu8
No clue... No clue...

• From this I assume any result that was not a "No clue..." means that the data stream was corrupt, incomplete or the analyzer did not know how to take a guess at it.

• But the "-A" flag obviously uses some code to try and figure out where the data is in the stream and provide a '-X' sample to try.

• I then used the -X with the appropriate syntax suggested and it looks like the data stream might be parsed

• Examples:

  SENSOR 1:

  Sensor: TPMS-A4CB100D File: g001_315M_250k.cu8 command: 'rtl_433 -X 'n=name,m=FSK_PWM,s=48,l=100,r=160,g=0,t=0,y=156' g001_315M_250k.cu8'

Result: [Input] Test mode active. Reading samples from file: g001_315M_250k.cu8

---

time : @0.066940s model : name count : 2 num_rows : 2 rows : len : 3 data : 2, len : 55 data : f7facb56ff6f5c codes : {3}2, {55}f7facb56ff6f5c

---

time : @0.107520s model : name count : 2 num_rows : 2 rows : len : 3 data : 2, len : 56 data : f7facb56ff6f5f codes : {3}2, {56}f7facb56ff6f5f

---

time : @0.148100s model : name count : 2 num_rows : 2 rows : len : 3 data : 2, len : 55 data : f7facb56ff6f5c codes : {3}2, {55}f7facb56ff6f5c

---

time : @0.188680s model : name count : 2 num_rows : 2 rows : len : 3 data : 2, len : 55 data : f7facb56ff6f5c codes : {3}2, {55}f7facb56ff6f5c

• So I have some questions...

• The analyzer detected 3 of the 4, and for the most part the numbers are close but not exactly the same.

• Can you help me understand the short, long, reset, and sync values and why are they the way they are (RF Theory). There is a good reason why they are all close.

• The '-X' 'Flexable Decoder' seems to have grabbed a data block (in HEX), and all 4 signals seem to be the same, which I assume is the transmitter sendingt he signal more than once to make sure a signal gets through. Which explains why all the 'data' values look to be the same. Data 1: f7facb56ff6f5c <- Same Data 2: f7facb56ff6f5f <- different - Might be corrupted, or something different sneaked in here? Data 3: f7facb56ff6f5c <- Same Data 4: f7facb56ff6f5c <- Same

• but I now struggle where to go from here..

• I assume we parse the HEX to binary? maybe.. and then use some code like in the tpms_toyota.c to parse the result: id = (unsigned)b[0] << 24 | b[1] << 16 | b[2] << 8 | b[3]; status = (b[4] & 0x80) | (b[6] & 0x7f); // status bit and 0 filler pressure1 = (b[4] & 0x7f) << 1 | b[5] >> 7; temp = (b[5] & 0x7f) << 1 | b[6] >> 7; pressure2 = b[7] ^ 0xff;

• I need a little hand holding..

• In the attached file, is the capture for 4 sensors, all the same brand, all performed the same way. TPMS - Sample Set 1.zip

[ProfBoc75]

Hi @MiddleSiggy : Good job !

from -A option or using pulseview analysis, we can see that :

We have a FSK signal, it could be PCM or PWM.

rtl_433 is not able to find which pulse coding is used, so "no clue" is shown. If you look at already existing TPMS devices, most are FSK_PCM, short=52 µs (with PCM long = short = 52 µs), reset is the duration of the data signal before gap and new row. And from -A or pulseview results, we have lot pulses at 51.5 µs, very close to 52 µs.

If we try flex decoder based on that : (from TPMS-A4CB100D and g001_315M_250k.cu8 )

rtl_433 g001_315M_250k.cu8 -X 'n=TPMS,m=FSK_PCM,s=52,l=52,r=8000'

you have this result :

The last nibble is not the same, but most of the time is useless because it's the end of the transit of the signal.

Then I compared the data with existing TPMS, and found one where it matches tpms_elantra2012.c with the same preamble 7155

And I'm able to build the data layout here We can see the TPMS id = 'a4cb100b'

So, it's FSK, PCM, s=l=52, Manchester coded, preamble is 7155, the data layout is :

PRESSURE:8h TEMP_C:8h ID:32h FLAG:8h CRC:8h

Tomorrow, I will check the code of tpms_elantra2012 why it's not decoding (pulse at 49 µs is very close to 52) ... may be because the pressure is = 0 ?

To be continued ...

[zuckschwerdt]

The reset, here and in Elantra2012 is wrong. 8000 is too much, the longest gap we expect with PCM MC is 2x the (half-)bit-width. 52 x2, rounded up we can use 150 µs. But there might be a longer desync, and we do have it here, the 7155 (111 000 101010101) has 3x gap, but the decoder is wrong to just have that very tight margin of 49 x3 = 147 -> 150. Round it up to 200 and it's fine.

Thanks for the great work analyzing! I'll commit a fix an credit you.

[ProfBoc75]

The reset, here and in Elantra2012 is wrong. 8000 is too much, the longest gap we expect with PCM MC is 2x the (half-)bit-width. 52 x2, rounded up we can use 150 µs. But there might be a longer desync, and we do have it here, the 7155 (111 000 101010101) has 3x gap, but the decoder is wrong to just have that very tight margin of 49 x3 = 147 -> 150. Round it up to 200 and it's fine.

Thanks for the great work analyzing! I'll commit a fix an credit you.

I found the same conclusion, the reset was too short 👍 , I tested both Elantra cu8 samples from rtl_433_tests and those ones from @MiddleSiggy and it works with r=200 and s=l=49.

Edit : @zuckschwerdt , in fact, here #2806 the pulse is 52 not 49 , so r = 52 x 3 = 156 , and if you test at r=156, it works. 150 was not enough, so round up to 200 is a good compromise.

Thanks.

[MiddleSiggy]

@ProfBoc75

I am going to try and get samples from the TPMS sensors on my vehicle tonight, I will upload them with the info like before, so we can head check them also. They are a different brand, but have the same issue of not being detected.

Stay tuned.

[MiddleSiggy]

@ProfBoc75

I did 4 more samples, and it looks like they have the same 7155 prefix like the first set.

I did the same process and decoded things and it seems to be in the same format. See here

This other set was also not detected, so maybe test this set also against your tests.

Sample Set 2.zip

@ProfBox75 If I have future questions, instead of opening a ticket, is there a way we can trade e-mail?

Also when will the changes be pushed to the Master branch? or is there a test branch I can DL.. Thanks

[ProfBoc75]

@MiddleSiggy : in fact, rtl_433 is already updated, @zuckschwerdt did it already, he's very fast 😄 ...

You just have to download the last version and it should work and your TPMS sensors detected as Elantra2012. The reason why also this issue is closed because rtl_433 is corrected accordingly ( commit 98b4b7c ).

Tested from your last sample set 2 :

[ProfBoc75]

@ProfBox75 If I have future questions, instead of opening a ticket, is there a way we can trade e-mail?

I guess you should find Bruno Octau in Linkedin 😉 ...