search

merbanan / rtl_433

Program to decode radio transmissions from devices on the ISM bands (and other frequencies)
GNU General Public License v2.0
6.16k stars 1.33k forks source link

Nissan TPMS MRXNIS315G3 sensor identified as Schrader SMD3MA4 #1734

Open robcazzaro opened 3 years ago

robcazzaro commented 3 years ago

I'm new to the world and playing with a SDR RTL-SDR V3 and TPMS sensors for Nissan cars.

When running rtl_433 -f 315M, my sensors are identified as Schrader-SMD3MA4. But, even if the Nissan OEM sensors (FCC ID MRXNIS315G3) are made by Schrader, the protocol is different. Even all aftermarket TPMS sensors for my car are different from the SMD3MA4 (e.g. Redi-Sensor makes the SE10001HP for the Nissan, SA10003 for Subaru which uses the SMD3MA4 sensor)

In looking at similar issues I saw that there were suggestions to run a raw capture. I tried with

rtl_433-rtlsdr -f 315M -R 0 -X n=TPMS,m=FSK_PCM,s=50,l=50,r=1000

and I got 

rtl_433 version 21.05 branch  at 202105091238 inputs file rtl_tcp RTL-SDR
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "C:\Work\SDR\rtl_433_msvc\rtl_433.conf"...
Trying conf file at "C:\Users\Roberto\AppData\Local\rtl_433\rtl_433.conf"...
Trying conf file at "C:\ProgramData\rtl_433\rtl_433.conf"...
Disabling all device decoders.
Registered 1 out of 186 device decoding protocols [ ]
Found Rafael Micro R820T/2 tuner
Exact sample rate is: 250000.000414 Hz
Sample rate set to 250000 S/s.
Tuner gain set to Auto.
Tuned to 315.000MHz.
Allocating 15 (non-zero-copy) user-space buffers
baseband_demod_FM: low pass filter for 250000 Hz at cutoff 25000 Hz, 40.0 us
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-05 17:19:53
model     : TPMS         count     : 1             num_rows  : 1
rows      :
len       : 161          data      : 553ccd534b5352b2b54b2b2d53355555352cd5338
codes     : {161}553ccd534b5352b2b54b2b2d53355555352cd5338
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-05 17:20:16
model     : TPMS         count     : 1             num_rows  : 1
rows      :
len       : 161          data      : 553cd2b334d2cccd2ad32d4d5333554ad35352ab8
codes     : {161}553cd2b334d2cccd2ad32d4d5333554ad35352ab8
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-05 17:20:16
model     : TPMS         count     : 1             num_rows  : 1
rows      :
len       : 161          data      : 553cd2b334d2cccd2ad32d4d5333554d2cacaad38
codes     : {161}553cd2b334d2cccd2ad32d4d5333554d2cacaad38
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-05 17:20:46
model     : TPMS         count     : 1             num_rows  : 1
rows      :
len       : 161          data      : 553ccd534b5352b2d34cd4b4acd2aaaacb4b2cb38
codes     : {161}553ccd534b5352b2d34cd4b4acd2aaaacb4b2cb38
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-05 17:20:58
model     : TPMS         count     : 1             num_rows  : 1
rows      :
len       : 287          data      : 1ffe1e1e66199e19e661e666199e61e6199e1e61999
999e61e1e1e6661e1999e6666619e
codes     : {287}1ffe1e1e66199e19e661e666199e61e6199e1e61999999e61e1e1e6661e1999
e6666619e
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-05 17:21:25
model     : TPMS         count     : 1             num_rows  : 1
rows      :
len       : 161          data      : 553ccd534b5352b2b54b2b2d532caaaacad32b2b8
codes     : {161}553ccd534b5352b2b54b2b2d532caaaacad32b2b8
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-05 17:21:40
model     : TPMS         count     : 1             num_rows  : 1
rows      :
len       : 161          data      : 553cccaacd2cacb534b32d2d4aacaab2d2d2cd4b8
codes     : {161}553cccaacd2cacb534b32d2d4aacaab2d2d2cd4b8
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-05 17:21:40
model     : TPMS         count     : 1             num_rows  : 1
rows      :
len       : 161          data      : 553cccaacd2cacb534b32d2d4aacaab2d2d2cd4b8
codes     : {161}553cccaacd2cacb534b32d2d4aacaab2d2d2cd4b8
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-05 17:21:40
model     : TPMS         count     : 1             num_rows  : 1
rows      :
len       : 161          data      : 553cccaacd2cacb534b32d2d4aacaab2d2d2cd4b8
codes     : {161}553cccaacd2cacb534b32d2d4aacaab2d2d2cd4b8
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-05 17:21:40
model     : TPMS         count     : 1             num_rows  : 1
rows      :
len       : 161          data      : ff3cccaacd2cacb534b32d2d4aacaab2d2d2cd4b8
codes     : {161}ff3cccaacd2cacb534b32d2d4aacaab2d2d2cd4b8
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-05 17:21:41
model     : TPMS         count     : 1             num_rows  : 1
rows      :
len       : 100          data      : 553cccaacd2ccb4d4d2cd2cb4
codes     : {100}553cccaacd2ccb4d4d2cd2cb4
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-05 17:21:41
model     : TPMS         count     : 1             num_rows  : 1
rows      :
len       : 161          data      : 553cccaacd2ccb4d4d2cd2cb4ab4aab2d2b4b3538
codes     : {161}553cccaacd2ccb4d4d2cd2cb4ab4aab2d2b4b3538
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-05 17:21:41
model     : TPMS         count     : 1             num_rows  : 1
rows      :
len       : 160          data      : 553cccaacd2ccb4d4d2cd2cb4ab4aab2d2b4b353
codes     : {160}553cccaacd2ccb4d4d2cd2cb4ab4aab2d2b4b353

does this help in understanding if the Nissan TPMS send data similar to the Subaru/Schrader SMD3MA4?

Incidentally, it looks as if Schrader forgot to ask the FCC for confidentiality for the NIS3153G device, and you can see all the details, including the schematic of that TPMS https://apps.fcc.gov/oetcf/eas/reports/ViewExhibitReport.cfm?mode=Exhibits&RequestTimeout=500&calledFromFrame=N&application_id=vNQt6tW0TOhBSofH7BHU2w%3D%3D&fcc_id=MRXNIS315G3

zuckschwerdt commented 3 years ago

Thanks. The SMD3MA4 decoder is missing false positive rejection, there is no checksum. The codes you got look good, Here is a Bitbench. We now need more codes, if possible with some annotation of e.g. [Sensor3 23C 120kPa]

From the FCC documents we expect
Sensor Schrader MRXNIS315G3?
FCC ID MRXNIS315G3
Frequency 315 MHz
Modulation Manchester ASK
Modulation Bandwidth 4KHz
Repeats 8
Start bits 18 bits of aaae (but aa7 seen)
Data bits 3 + 24 + 8 + 2

But the timing does not match, the start bits seem different, and there is about twice as much data as indicated. Outdated or inaccurate documents are common though.

And then 4kHz suggests a raw bit timing of 250 µs or 125 µs if the 4kHz apply to the MC encoded bits. What do you see with -A are there many counts of 50 and 100 µs? Or is it 125/250?

robcazzaro commented 3 years ago

Thanks for the super-quick reply and additional suggestions

I'm waiting for one of those TPMS activation tools that generate 125kHz to speed up the TPMS data collection. Right now I'm using 4 sensors I just removed from my car, and in order to activate them I need to manually trigger the centrifugal sensor by vigorously shaking them :) not ideal

At the moment the devices are sitting on a table at around 20C, should measure a pressure of 0 or close to 0, given that they are in free air. The Schrader/Subaru protocol seemed to read the pressure right (reading from 0 PSI to 0.015 PSI), but might be a fluke

Please advise on the best way to capture meaningful data. I have a new RTL-SDR V3, and connected to a dipole antenna roughly tuned to 315 MHz. And I'm clueless when it comes to SDR :), even if I have quite a lot of digital electronics experience (and tools like oscilloscope, logic analyzer, etc, in case those can help).

I tried capturing data using this

rtl_433-rtlsdr -R 0 -X n=TPMS,m=FSK_PCM,s=50,l=50,r=1000 -A -f 315025000

and I got

C:\Work\SDR\rtl_433_msvc>rtl_433-rtlsdr -R 0 -X n=TPMS,m=FSK_PCM,s=50,l=50,r=1000 -A -f 315025000
rtl_433 version 21.05 branch  at 202105091238 inputs file rtl_tcp RTL-SDR
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "C:\Work\SDR\rtl_433_msvc\rtl_433.conf"...
Trying conf file at "C:\Users\Roberto\AppData\Local\rtl_433\rtl_433.conf"...
Trying conf file at "C:\ProgramData\rtl_433\rtl_433.conf"...
Disabling all device decoders.
Registered 1 out of 186 device decoding protocols [ ]
Found Rafael Micro R820T/2 tuner
Exact sample rate is: 250000.000414 Hz
Sample rate set to 250000 S/s.
Tuner gain set to Auto.
Tuned to 315.025MHz.
Allocating 15 (non-zero-copy) user-space buffers
baseband_demod_FM: low pass filter for 250000 Hz at cutoff 25000 Hz, 40.0 us
Detected OOK package    2021-06-06 08:35:47
Analyzing pulses...
Total count:   44,  width: 13.34 ms             ( 3334 S)
Pulse width distribution:
 [ 0] count:    2,  width:  516 us [508;524]    ( 129 S)
 [ 1] count:   34,  width:  136 us [136;140]    (  34 S)
 [ 2] count:    8,  width:  260 us [260;264]    (  65 S)
Gap width distribution:
 [ 0] count:   35,  width:  104 us [104;108]    (  26 S)
 [ 1] count:    8,  width:  224 us [224;232]    (  56 S)
Pulse period distribution:
 [ 0] count:    2,  width:  620 us [612;628]    ( 155 S)
 [ 1] count:   32,  width:  244 us [240;248]    (  61 S)
 [ 2] count:    3,  width:  364 us [364;368]    (  91 S)
 [ 3] count:    6,  width:  488 us [484;492]    ( 122 S)
Pulse timing distribution:
 [ 0] count:    2,  width:  516 us [508;524]    ( 129 S)
 [ 1] count:   34,  width:  136 us [136;140]    (  34 S)
 [ 2] count:   16,  width:  244 us [224;264]    (  61 S)
 [ 3] count:   35,  width:  104 us [104;108]    (  26 S)
 [ 4] count:    1,  width: 10004 us [10004;10004]       (2501 S)
Level estimates [high, low]:  16007,     28
RSSI: -0.1 dB SNR: 27.6 dB Noise: -27.7 dB
Frequency offsets [F1, F2]:    6087,      0     (+23.2 kHz, +0.0 kHz)
Guessing modulation: Pulse Width Modulation with sync/delimiter
view at https://triq.org/pdv/#AAB1050204008800F400682714839393939393939393939393
93938392A2A2A2A293A2A293A3939393939293939393939393939393939393A455
Attempting demodulation... short_width: 136, long_width: 260, reset_limit: 236,
sync_width: 516
Use a flex decoder with -X 'n=name,m=OOK_PWM,s=136,l=260,r=236,g=0,t=0,y=516'
pulse_demod_pwm(): Analyzer Device
bitbuffer:: Number of rows: 2
[00] {13} ff f8       : 11111111 11111
[01] {29} 84 bf ff f0 : 10000100 10111111 11111111 11110

Detected OOK package    2021-06-06 08:35:47
Analyzing pulses...
Total count:   44,  width: 13.34 ms             ( 3335 S)
Pulse width distribution:
 [ 0] count:    2,  width:  512 us [504;520]    ( 128 S)
 [ 1] count:   34,  width:  136 us [136;140]    (  34 S)
 [ 2] count:    8,  width:  260 us [256;264]    (  65 S)
Gap width distribution:
 [ 0] count:   35,  width:  104 us [104;108]    (  26 S)
 [ 1] count:    8,  width:  228 us [224;232]    (  57 S)
Pulse period distribution:
 [ 0] count:    2,  width:  620 us [612;628]    ( 155 S)
 [ 1] count:   32,  width:  244 us [244;244]    (  61 S)
 [ 2] count:    3,  width:  364 us [364;368]    (  91 S)
 [ 3] count:    6,  width:  488 us [484;492]    ( 122 S)
Pulse timing distribution:
 [ 0] count:    2,  width:  512 us [504;520]    ( 128 S)
 [ 1] count:   34,  width:  136 us [136;140]    (  34 S)
 [ 2] count:   16,  width:  244 us [224;264]    (  61 S)
 [ 3] count:   35,  width:  104 us [104;108]    (  26 S)
 [ 4] count:    1,  width: 10004 us [10004;10004]       (2501 S)
Level estimates [high, low]:  15876,     27
RSSI: -0.1 dB SNR: 27.7 dB Noise: -27.8 dB
Frequency offsets [F1, F2]:    6249,      0     (+23.8 kHz, +0.0 kHz)
Guessing modulation: Pulse Width Modulation with sync/delimiter
view at https://triq.org/pdv/#AAB1050200008800F400682714839393939393939393939393
93938392A2A2A2A293A2A293A3939393939293939393939393939393939393A455
Attempting demodulation... short_width: 136, long_width: 260, reset_limit: 236,
sync_width: 512
Use a flex decoder with -X 'n=name,m=OOK_PWM,s=136,l=260,r=236,g=0,t=0,y=512'
pulse_demod_pwm(): Analyzer Device
bitbuffer:: Number of rows: 2
[00] {13} ff f8       : 11111111 11111
[01] {29} 84 bf ff f0 : 10000100 10111111 11111111 11110

Detected OOK package    2021-06-06 08:35:47
Analyzing pulses...
Total count:   44,  width: 13.34 ms             ( 3334 S)
Pulse width distribution:
 [ 0] count:    2,  width:  508 us [500;520]    ( 127 S)
 [ 1] count:   34,  width:  136 us [132;140]    (  34 S)
 [ 2] count:    8,  width:  260 us [260;260]    (  65 S)
Gap width distribution:
 [ 0] count:   35,  width:  104 us [104;108]    (  26 S)
 [ 1] count:    8,  width:  228 us [228;232]    (  57 S)
Pulse period distribution:
 [ 0] count:    2,  width:  616 us [608;624]    ( 154 S)
 [ 1] count:   32,  width:  244 us [240;248]    (  61 S)
 [ 2] count:    3,  width:  368 us [368;368]    (  92 S)
 [ 3] count:    6,  width:  488 us [488;488]    ( 122 S)
Pulse timing distribution:
 [ 0] count:    2,  width:  508 us [500;520]    ( 127 S)
 [ 1] count:   34,  width:  136 us [132;140]    (  34 S)
 [ 2] count:   16,  width:  244 us [228;260]    (  61 S)
 [ 3] count:   35,  width:  104 us [104;108]    (  26 S)
 [ 4] count:    1,  width: 10004 us [10004;10004]       (2501 S)
Level estimates [high, low]:  15939,     38
RSSI: -0.1 dB SNR: 26.2 dB Noise: -26.3 dB
Frequency offsets [F1, F2]:    7478,      0     (+28.5 kHz, +0.0 kHz)
Guessing modulation: Pulse Width Modulation with sync/delimiter
view at https://triq.org/pdv/#AAB10501FC008800F400682714839393939393939393939393
93938392A2A2A2A293A2A293A3939393939293939393939393939393939393A455
Attempting demodulation... short_width: 136, long_width: 260, reset_limit: 236,
sync_width: 508
Use a flex decoder with -X 'n=name,m=OOK_PWM,s=136,l=260,r=236,g=0,t=0,y=508'
pulse_demod_pwm(): Analyzer Device
bitbuffer:: Number of rows: 2
[00] {13} ff f8       : 11111111 11111
[01] {29} 84 bf ff f0 : 10000100 10111111 11111111 11110

Detected OOK package    2021-06-06 08:35:47
Analyzing pulses...
Total count:   44,  width: 13.34 ms             ( 3334 S)
Pulse width distribution:
 [ 0] count:    2,  width:  512 us [504;520]    ( 128 S)
 [ 1] count:   34,  width:  136 us [136;140]    (  34 S)
 [ 2] count:    8,  width:  260 us [256;264]    (  65 S)
Gap width distribution:
 [ 0] count:   35,  width:  104 us [104;108]    (  26 S)
 [ 1] count:    8,  width:  224 us [224;228]    (  56 S)
Pulse period distribution:
 [ 0] count:    2,  width:  620 us [612;628]    ( 155 S)
 [ 1] count:   32,  width:  244 us [240;248]    (  61 S)
 [ 2] count:    3,  width:  364 us [364;368]    (  91 S)
 [ 3] count:    6,  width:  488 us [488;492]    ( 122 S)
Pulse timing distribution:
 [ 0] count:    2,  width:  512 us [504;520]    ( 128 S)
 [ 1] count:   34,  width:  136 us [136;140]    (  34 S)
 [ 2] count:   16,  width:  240 us [224;264]    (  60 S)
 [ 3] count:   35,  width:  104 us [104;108]    (  26 S)
 [ 4] count:    1,  width: 10004 us [10004;10004]       (2501 S)
Level estimates [high, low]:  15998,     27
RSSI: -0.1 dB SNR: 27.7 dB Noise: -27.8 dB
Frequency offsets [F1, F2]:    7482,      0     (+28.5 kHz, +0.0 kHz)
Guessing modulation: Pulse Width Modulation with sync/delimiter
view at https://triq.org/pdv/#AAB1050200008800F000682714839393939393939393939393
93938392A2A2A2A293A2A293A3939393939293939393939393939393939393A455
Attempting demodulation... short_width: 136, long_width: 260, reset_limit: 232,
sync_width: 512
Use a flex decoder with -X 'n=name,m=OOK_PWM,s=136,l=260,r=232,g=0,t=0,y=512'
pulse_demod_pwm(): Analyzer Device
bitbuffer:: Number of rows: 2
[00] {13} ff f8       : 11111111 11111
[01] {29} 84 bf ff f0 : 10000100 10111111 11111111 11110

Detected OOK package    2021-06-06 08:35:48
Analyzing pulses...
Total count:   44,  width: 13.34 ms             ( 3334 S)
Pulse width distribution:
 [ 0] count:    2,  width:  512 us [504;524]    ( 128 S)
 [ 1] count:   34,  width:  136 us [136;140]    (  34 S)
 [ 2] count:    8,  width:  256 us [256;260]    (  64 S)
Gap width distribution:
 [ 0] count:   35,  width:  104 us [104;108]    (  26 S)
 [ 1] count:    8,  width:  228 us [228;232]    (  57 S)
Pulse period distribution:
 [ 0] count:    2,  width:  616 us [608;628]    ( 154 S)
 [ 1] count:   32,  width:  244 us [244;248]    (  61 S)
 [ 2] count:    3,  width:  364 us [364;368]    (  91 S)
 [ 3] count:    6,  width:  488 us [488;488]    ( 122 S)
Pulse timing distribution:
 [ 0] count:    2,  width:  512 us [504;524]    ( 128 S)
 [ 1] count:   34,  width:  136 us [136;140]    (  34 S)
 [ 2] count:   16,  width:  240 us [228;260]    (  60 S)
 [ 3] count:   35,  width:  104 us [104;108]    (  26 S)
 [ 4] count:    1,  width: 10004 us [10004;10004]       (2501 S)
Level estimates [high, low]:  16002,     27
RSSI: -0.1 dB SNR: 27.7 dB Noise: -27.8 dB
Frequency offsets [F1, F2]:    6819,      0     (+26.0 kHz, +0.0 kHz)
Guessing modulation: Pulse Width Modulation with sync/delimiter
view at https://triq.org/pdv/#AAB1050200008800F000682714839393939393939393939393
93938392A2A2A2A293A2A293A3939393939293939393939393939393939393A455
Attempting demodulation... short_width: 136, long_width: 256, reset_limit: 236,
sync_width: 512
Use a flex decoder with -X 'n=name,m=OOK_PWM,s=136,l=256,r=236,g=0,t=0,y=512'
pulse_demod_pwm(): Analyzer Device
bitbuffer:: Number of rows: 2
[00] {13} ff f8       : 11111111 11111
[01] {29} 84 bf ff f0 : 10000100 10111111 11111111 11110

Detected OOK package    2021-06-06 08:35:48
Analyzing pulses...
Total count:   44,  width: 13.34 ms             ( 3334 S)
Pulse width distribution:
 [ 0] count:    2,  width:  512 us [508;520]    ( 128 S)
 [ 1] count:   34,  width:  136 us [136;140]    (  34 S)
 [ 2] count:    8,  width:  256 us [256;264]    (  64 S)
Gap width distribution:
 [ 0] count:   35,  width:  104 us [104;108]    (  26 S)
 [ 1] count:    8,  width:  228 us [228;232]    (  57 S)
Pulse period distribution:
 [ 0] count:    2,  width:  620 us [612;628]    ( 155 S)
 [ 1] count:   32,  width:  240 us [240;244]    (  60 S)
 [ 2] count:    3,  width:  364 us [364;368]    (  91 S)
 [ 3] count:    6,  width:  488 us [484;492]    ( 122 S)
Pulse timing distribution:
 [ 0] count:    2,  width:  512 us [508;520]    ( 128 S)
 [ 1] count:   34,  width:  136 us [136;140]    (  34 S)
 [ 2] count:   16,  width:  244 us [228;264]    (  61 S)
 [ 3] count:   35,  width:  104 us [104;108]    (  26 S)
 [ 4] count:    1,  width: 10004 us [10004;10004]       (2501 S)
Level estimates [high, low]:  15948,     53
RSSI: -0.1 dB SNR: 24.8 dB Noise: -24.9 dB
Frequency offsets [F1, F2]:    7707,      0     (+29.4 kHz, +0.0 kHz)
Guessing modulation: Pulse Width Modulation with sync/delimiter
view at https://triq.org/pdv/#AAB1050200008800F400682714839393939393939393939393
93938392A2A2A2A293A2A293A3939393939293939393939393939393939393A455
Attempting demodulation... short_width: 136, long_width: 256, reset_limit: 236,
sync_width: 512
Use a flex decoder with -X 'n=name,m=OOK_PWM,s=136,l=256,r=236,g=0,t=0,y=512'
pulse_demod_pwm(): Analyzer Device
bitbuffer:: Number of rows: 2
[00] {13} ff f8       : 11111111 11111
[01] {29} 84 bf ff f0 : 10000100 10111111 11111111 11110

Detected OOK package    2021-06-06 08:35:48
Analyzing pulses...
Total count:   44,  width: 13.34 ms             ( 3334 S)
Pulse width distribution:
 [ 0] count:    2,  width:  512 us [504;520]    ( 128 S)
 [ 1] count:   34,  width:  136 us [136;140]    (  34 S)
 [ 2] count:    8,  width:  260 us [260;260]    (  65 S)
Gap width distribution:
 [ 0] count:   35,  width:  104 us [104;108]    (  26 S)
 [ 1] count:    8,  width:  228 us [228;232]    (  57 S)
Pulse period distribution:
 [ 0] count:    2,  width:  620 us [612;628]    ( 155 S)
 [ 1] count:   32,  width:  244 us [240;248]    (  61 S)
 [ 2] count:    3,  width:  364 us [364;368]    (  91 S)
 [ 3] count:    6,  width:  488 us [488;492]    ( 122 S)
Pulse timing distribution:
 [ 0] count:    2,  width:  512 us [504;520]    ( 128 S)
 [ 1] count:   34,  width:  136 us [136;140]    (  34 S)
 [ 2] count:   16,  width:  244 us [228;260]    (  61 S)
 [ 3] count:   35,  width:  104 us [104;108]    (  26 S)
 [ 4] count:    1,  width: 10004 us [10004;10004]       (2501 S)
Level estimates [high, low]:  15970,     47
RSSI: -0.1 dB SNR: 25.3 dB Noise: -25.4 dB
Frequency offsets [F1, F2]:    7060,      0     (+26.9 kHz, +0.0 kHz)
Guessing modulation: Pulse Width Modulation with sync/delimiter
view at https://triq.org/pdv/#AAB1050200008800F400682714839393939393939393939393
93938392A2A2A2A293A2A293A3939393939293939393939393939393939393A455
Attempting demodulation... short_width: 136, long_width: 260, reset_limit: 236,
sync_width: 512
Use a flex decoder with -X 'n=name,m=OOK_PWM,s=136,l=260,r=236,g=0,t=0,y=512'
pulse_demod_pwm(): Analyzer Device
bitbuffer:: Number of rows: 2
[00] {13} ff f8       : 11111111 11111
[01] {29} 84 bf ff f0 : 10000100 10111111 11111111 11110

Detected OOK package    2021-06-06 08:35:48
Analyzing pulses...
Total count:   44,  width: 13.34 ms             ( 3334 S)
Pulse width distribution:
 [ 0] count:    2,  width:  512 us [504;520]    ( 128 S)
 [ 1] count:   34,  width:  136 us [136;140]    (  34 S)
 [ 2] count:    8,  width:  260 us [260;264]    (  65 S)
Gap width distribution:
 [ 0] count:   35,  width:  104 us [104;108]    (  26 S)
 [ 1] count:    8,  width:  228 us [228;228]    (  57 S)
Pulse period distribution:
 [ 0] count:    2,  width:  616 us [608;624]    ( 154 S)
 [ 1] count:   32,  width:  244 us [240;248]    (  61 S)
 [ 2] count:    3,  width:  364 us [364;368]    (  91 S)
 [ 3] count:    6,  width:  488 us [488;492]    ( 122 S)
Pulse timing distribution:
 [ 0] count:    2,  width:  512 us [504;520]    ( 128 S)
 [ 1] count:   34,  width:  136 us [136;140]    (  34 S)
 [ 2] count:   16,  width:  244 us [228;264]    (  61 S)
 [ 3] count:   35,  width:  104 us [104;108]    (  26 S)
 [ 4] count:    1,  width: 10004 us [10004;10004]       (2501 S)
Level estimates [high, low]:  15969,     32
RSSI: -0.1 dB SNR: 27.0 dB Noise: -27.1 dB
Frequency offsets [F1, F2]:    7173,      0     (+27.4 kHz, +0.0 kHz)
Guessing modulation: Pulse Width Modulation with sync/delimiter
view at https://triq.org/pdv/#AAB1050200008800F400682714839393939393939393939393
93938392A2A2A2A293A2A293A3939393939293939393939393939393939393A455
Attempting demodulation... short_width: 136, long_width: 260, reset_limit: 232,
sync_width: 512
Use a flex decoder with -X 'n=name,m=OOK_PWM,s=136,l=260,r=232,g=0,t=0,y=512'
pulse_demod_pwm(): Analyzer Device
bitbuffer:: Number of rows: 2
[00] {13} ff f8       : 11111111 11111
[01] {29} 84 bf ff f0 : 10000100 10111111 11111111 11110

Detected OOK package    2021-06-06 08:47:53
Analyzing pulses...
Total count:   41,  width: 13.46 ms             ( 3365 S)
Pulse width distribution:
 [ 0] count:    2,  width:  512 us [504;520]    ( 128 S)
 [ 1] count:   28,  width:  136 us [136;144]    (  34 S)
 [ 2] count:   11,  width:  260 us [260;264]    (  65 S)
Gap width distribution:
 [ 0] count:   28,  width:  104 us [100;108]    (  26 S)
 [ 1] count:   12,  width:  228 us [224;232]    (  57 S)
Pulse period distribution:
 [ 0] count:    2,  width:  616 us [612;624]    ( 154 S)
 [ 1] count:   24,  width:  244 us [240;248]    (  61 S)
 [ 2] count:    5,  width:  364 us [364;368]    (  91 S)
 [ 3] count:    9,  width:  488 us [488;492]    ( 122 S)
Pulse timing distribution:
 [ 0] count:    2,  width:  512 us [504;520]    ( 128 S)
 [ 1] count:   28,  width:  136 us [136;144]    (  34 S)
 [ 2] count:   23,  width:  240 us [224;264]    (  60 S)
 [ 3] count:   28,  width:  104 us [100;108]    (  26 S)
 [ 4] count:    1,  width: 10004 us [10004;10004]       (2501 S)
Level estimates [high, low]:  15882,     22
RSSI: -0.1 dB SNR: 28.6 dB Noise: -28.7 dB
Frequency offsets [F1, F2]:    6661,      0     (+25.4 kHz, +0.0 kHz)
Guessing modulation: Pulse Width Modulation with sync/delimiter
view at https://triq.org/pdv/#AAB1050200008800F000682714839393939393939393939393
93938392A2A2A2A293A2A293A3939392A2A392A293939393939393A29455
Attempting demodulation... short_width: 136, long_width: 260, reset_limit: 236,
sync_width: 512
Use a flex decoder with -X 'n=name,m=OOK_PWM,s=136,l=260,r=236,g=0,t=0,y=512'
pulse_demod_pwm(): Analyzer Device
bitbuffer:: Number of rows: 2
[00] {13} ff f8       : 11111111 11111
[01] {26} 84 b9 7f 40 : 10000100 10111001 01111111 01

Detected OOK package    2021-06-06 08:47:53
Analyzing pulses...
Total count:   41,  width: 13.46 ms             ( 3365 S)
Pulse width distribution:
 [ 0] count:    2,  width:  508 us [500;520]    ( 127 S)
 [ 1] count:   28,  width:  136 us [132;140]    (  34 S)
 [ 2] count:   11,  width:  256 us [256;264]    (  64 S)
Gap width distribution:
 [ 0] count:   28,  width:  104 us [104;112]    (  26 S)
 [ 1] count:   12,  width:  228 us [228;232]    (  57 S)
Pulse period distribution:
 [ 0] count:    2,  width:  616 us [608;628]    ( 154 S)
 [ 1] count:   24,  width:  244 us [240;248]    (  61 S)
 [ 2] count:    5,  width:  364 us [364;368]    (  91 S)
 [ 3] count:    9,  width:  484 us [484;492]    ( 121 S)
Pulse timing distribution:
 [ 0] count:    2,  width:  508 us [500;520]    ( 127 S)
 [ 1] count:   29,  width:  136 us [112;140]    (  34 S)
 [ 2] count:   23,  width:  240 us [228;264]    (  60 S)
 [ 3] count:   27,  width:  104 us [104;108]    (  26 S)
 [ 4] count:    1,  width: 10004 us [10004;10004]       (2501 S)
Level estimates [high, low]:  15925,     22
RSSI: -0.1 dB SNR: 28.6 dB Noise: -28.7 dB
Frequency offsets [F1, F2]:    6238,      0     (+23.8 kHz, +0.0 kHz)
Guessing modulation: Pulse Width Modulation with sync/delimiter
view at https://triq.org/pdv/#AAB10501FC008800F000682714839393939193939393939393
93938392A2A2A2A293A2A293A3939392A2A392A293939393939393A29455
Attempting demodulation... short_width: 136, long_width: 256, reset_limit: 236,
sync_width: 508
Use a flex decoder with -X 'n=name,m=OOK_PWM,s=136,l=256,r=236,g=0,t=0,y=508'
pulse_demod_pwm(): Analyzer Device
bitbuffer:: Number of rows: 2
[00] {13} ff f8       : 11111111 11111
[01] {26} 84 b9 7f 40 : 10000100 10111001 01111111 01

Detected OOK package    2021-06-06 08:47:53
Analyzing pulses...
Total count:   41,  width: 13.46 ms             ( 3365 S)
Pulse width distribution:
 [ 0] count:    2,  width:  512 us [504;520]    ( 128 S)
 [ 1] count:   28,  width:  136 us [136;140]    (  34 S)
 [ 2] count:   11,  width:  260 us [256;264]    (  65 S)
Gap width distribution:
 [ 0] count:   28,  width:  104 us [104;108]    (  26 S)
 [ 1] count:   12,  width:  228 us [228;232]    (  57 S)
Pulse period distribution:
 [ 0] count:    2,  width:  620 us [612;628]    ( 155 S)
 [ 1] count:   24,  width:  244 us [244;244]    (  61 S)
 [ 2] count:    5,  width:  364 us [364;368]    (  91 S)
 [ 3] count:    9,  width:  488 us [484;492]    ( 122 S)
Pulse timing distribution:
 [ 0] count:    2,  width:  512 us [504;520]    ( 128 S)
 [ 1] count:   28,  width:  136 us [136;140]    (  34 S)
 [ 2] count:   23,  width:  240 us [228;264]    (  60 S)
 [ 3] count:   28,  width:  104 us [104;108]    (  26 S)
 [ 4] count:    1,  width: 10004 us [10004;10004]       (2501 S)
Level estimates [high, low]:  15880,     25
RSSI: -0.1 dB SNR: 28.0 dB Noise: -28.2 dB
Frequency offsets [F1, F2]:    7347,      0     (+28.0 kHz, +0.0 kHz)
Guessing modulation: Pulse Width Modulation with sync/delimiter
view at https://triq.org/pdv/#AAB1050200008800F000682714839393939393939393939393
93938392A2A2A2A293A2A293A3939392A2A392A293939393939393A29455
Attempting demodulation... short_width: 136, long_width: 260, reset_limit: 236,
sync_width: 512
Use a flex decoder with -X 'n=name,m=OOK_PWM,s=136,l=260,r=236,g=0,t=0,y=512'
pulse_demod_pwm(): Analyzer Device
bitbuffer:: Number of rows: 2
[00] {13} ff f8       : 11111111 11111
[01] {26} 84 b9 7f 40 : 10000100 10111001 01111111 01

Detected OOK package    2021-06-06 08:47:53
Analyzing pulses...
Total count:   41,  width: 13.46 ms             ( 3365 S)
Pulse width distribution:
 [ 0] count:    2,  width:  508 us [500;520]    ( 127 S)
 [ 1] count:   28,  width:  136 us [136;140]    (  34 S)
 [ 2] count:   11,  width:  260 us [256;264]    (  65 S)
Gap width distribution:
 [ 0] count:   28,  width:  104 us [104;108]    (  26 S)
 [ 1] count:   12,  width:  228 us [228;232]    (  57 S)
Pulse period distribution:
 [ 0] count:    2,  width:  616 us [608;628]    ( 154 S)
 [ 1] count:   24,  width:  244 us [240;248]    (  61 S)
 [ 2] count:    5,  width:  364 us [364;368]    (  91 S)
 [ 3] count:    9,  width:  488 us [488;492]    ( 122 S)
Pulse timing distribution:
 [ 0] count:    2,  width:  508 us [500;520]    ( 127 S)
 [ 1] count:   28,  width:  136 us [136;140]    (  34 S)
 [ 2] count:   23,  width:  240 us [228;264]    (  60 S)
 [ 3] count:   28,  width:  104 us [104;108]    (  26 S)
 [ 4] count:    1,  width: 10004 us [10004;10004]       (2501 S)
Level estimates [high, low]:  15897,     31
RSSI: -0.1 dB SNR: 27.1 dB Noise: -27.2 dB
Frequency offsets [F1, F2]:    5704,      0     (+21.8 kHz, +0.0 kHz)
Guessing modulation: Pulse Width Modulation with sync/delimiter
view at https://triq.org/pdv/#AAB10501FC008800F000682714839393939393939393939393
93938392A2A2A2A293A2A293A3939392A2A392A293939393939393A29455
Attempting demodulation... short_width: 136, long_width: 260, reset_limit: 236,
sync_width: 508
Use a flex decoder with -X 'n=name,m=OOK_PWM,s=136,l=260,r=236,g=0,t=0,y=508'
pulse_demod_pwm(): Analyzer Device
bitbuffer:: Number of rows: 2
[00] {13} ff f8       : 11111111 11111
[01] {26} 84 b9 7f 40 : 10000100 10111001 01111111 01

Detected OOK package    2021-06-06 08:47:53
Analyzing pulses...
Total count:   41,  width: 13.46 ms             ( 3365 S)
Pulse width distribution:
 [ 0] count:    2,  width:  512 us [500;524]    ( 128 S)
 [ 1] count:   28,  width:  136 us [136;140]    (  34 S)
 [ 2] count:   11,  width:  260 us [260;264]    (  65 S)
Gap width distribution:
 [ 0] count:   28,  width:  104 us [104;108]    (  26 S)
 [ 1] count:   12,  width:  224 us [224;228]    (  56 S)
Pulse period distribution:
 [ 0] count:    2,  width:  620 us [608;632]    ( 155 S)
 [ 1] count:   24,  width:  244 us [240;248]    (  61 S)
 [ 2] count:    5,  width:  364 us [364;368]    (  91 S)
 [ 3] count:    9,  width:  488 us [484;492]    ( 122 S)
Pulse timing distribution:
 [ 0] count:    2,  width:  512 us [500;524]    ( 128 S)
 [ 1] count:   28,  width:  136 us [136;140]    (  34 S)
 [ 2] count:   23,  width:  240 us [224;264]    (  60 S)
 [ 3] count:   28,  width:  104 us [104;108]    (  26 S)
 [ 4] count:    1,  width: 10004 us [10004;10004]       (2501 S)
Level estimates [high, low]:  15945,     23
RSSI: -0.1 dB SNR: 28.4 dB Noise: -28.5 dB
Frequency offsets [F1, F2]:    5793,      0     (+22.1 kHz, +0.0 kHz)
Guessing modulation: Pulse Width Modulation with sync/delimiter
view at https://triq.org/pdv/#AAB1050200008800F000682714839393939393939393939393
93938392A2A2A2A293A2A293A3939392A2A392A293939393939393A29455
Attempting demodulation... short_width: 136, long_width: 260, reset_limit: 232,
sync_width: 512
Use a flex decoder with -X 'n=name,m=OOK_PWM,s=136,l=260,r=232,g=0,t=0,y=512'
pulse_demod_pwm(): Analyzer Device
bitbuffer:: Number of rows: 2
[00] {13} ff f8       : 11111111 11111
[01] {26} 84 b9 7f 40 : 10000100 10111001 01111111 01

Detected OOK package    2021-06-06 08:47:53
Analyzing pulses...
Total count:   41,  width: 13.46 ms             ( 3364 S)
Pulse width distribution:
 [ 0] count:    2,  width:  512 us [508;520]    ( 128 S)
 [ 1] count:   28,  width:  136 us [136;140]    (  34 S)
 [ 2] count:   11,  width:  256 us [256;264]    (  64 S)
Gap width distribution:
 [ 0] count:   28,  width:  104 us [104;108]    (  26 S)
 [ 1] count:   12,  width:  228 us [228;232]    (  57 S)
Pulse period distribution:
 [ 0] count:    2,  width:  620 us [616;624]    ( 155 S)
 [ 1] count:   24,  width:  244 us [240;248]    (  61 S)
 [ 2] count:    5,  width:  364 us [364;368]    (  91 S)
 [ 3] count:    9,  width:  488 us [484;492]    ( 122 S)
Pulse timing distribution:
 [ 0] count:    2,  width:  512 us [508;520]    ( 128 S)
 [ 1] count:   28,  width:  136 us [136;140]    (  34 S)
 [ 2] count:   23,  width:  240 us [228;264]    (  60 S)
 [ 3] count:   28,  width:  104 us [104;108]    (  26 S)
 [ 4] count:    1,  width: 10004 us [10004;10004]       (2501 S)
Level estimates [high, low]:  15955,     32
RSSI: -0.1 dB SNR: 27.0 dB Noise: -27.1 dB
Frequency offsets [F1, F2]:    6361,      0     (+24.3 kHz, +0.0 kHz)
Guessing modulation: Pulse Width Modulation with sync/delimiter
view at https://triq.org/pdv/#AAB1050200008800F000682714839393939393939393939393
93938392A2A2A2A293A2A293A3939392A2A392A293939393939393A29455
Attempting demodulation... short_width: 136, long_width: 256, reset_limit: 236,
sync_width: 512
Use a flex decoder with -X 'n=name,m=OOK_PWM,s=136,l=256,r=236,g=0,t=0,y=512'
pulse_demod_pwm(): Analyzer Device
bitbuffer:: Number of rows: 2
[00] {13} ff f8       : 11111111 11111
[01] {26} 84 b9 7f 40 : 10000100 10111001 01111111 01

Detected OOK package    2021-06-06 08:47:54
Analyzing pulses...
Total count:   41,  width: 13.46 ms             ( 3365 S)
Pulse width distribution:
 [ 0] count:    2,  width:  512 us [504;520]    ( 128 S)
 [ 1] count:   28,  width:  136 us [136;140]    (  34 S)
 [ 2] count:   11,  width:  260 us [256;264]    (  65 S)
Gap width distribution:
 [ 0] count:   28,  width:  104 us [104;108]    (  26 S)
 [ 1] count:   12,  width:  228 us [228;232]    (  57 S)
Pulse period distribution:
 [ 0] count:    2,  width:  620 us [612;628]    ( 155 S)
 [ 1] count:   24,  width:  244 us [240;248]    (  61 S)
 [ 2] count:    5,  width:  364 us [364;368]    (  91 S)
 [ 3] count:    9,  width:  488 us [488;492]    ( 122 S)
Pulse timing distribution:
 [ 0] count:    2,  width:  512 us [504;520]    ( 128 S)
 [ 1] count:   28,  width:  136 us [136;140]    (  34 S)
 [ 2] count:   23,  width:  240 us [228;264]    (  60 S)
 [ 3] count:   28,  width:  104 us [104;108]    (  26 S)
 [ 4] count:    1,  width: 10004 us [10004;10004]       (2501 S)
Level estimates [high, low]:  15897,     37
RSSI: -0.1 dB SNR: 26.3 dB Noise: -26.5 dB
Frequency offsets [F1, F2]:    7107,      0     (+27.1 kHz, +0.0 kHz)
Guessing modulation: Pulse Width Modulation with sync/delimiter
view at https://triq.org/pdv/#AAB1050200008800F000682714839393939393939393939393
93938392A2A2A2A293A2A293A3939392A2A392A293939393939393A29455
Attempting demodulation... short_width: 136, long_width: 260, reset_limit: 236,
sync_width: 512
Use a flex decoder with -X 'n=name,m=OOK_PWM,s=136,l=260,r=236,g=0,t=0,y=512'
pulse_demod_pwm(): Analyzer Device
bitbuffer:: Number of rows: 2
[00] {13} ff f8       : 11111111 11111
[01] {26} 84 b9 7f 40 : 10000100 10111001 01111111 01

Detected OOK package    2021-06-06 08:47:54
Analyzing pulses...
Total count:   41,  width: 13.46 ms             ( 3364 S)
Pulse width distribution:
 [ 0] count:    2,  width:  512 us [504;520]    ( 128 S)
 [ 1] count:   28,  width:  136 us [136;140]    (  34 S)
 [ 2] count:   11,  width:  256 us [256;260]    (  64 S)
Gap width distribution:
 [ 0] count:   28,  width:  104 us [104;108]    (  26 S)
 [ 1] count:   12,  width:  228 us [228;232]    (  57 S)
Pulse period distribution:
 [ 0] count:    2,  width:  616 us [612;624]    ( 154 S)
 [ 1] count:   24,  width:  244 us [240;248]    (  61 S)
 [ 2] count:    5,  width:  364 us [364;368]    (  91 S)
 [ 3] count:    9,  width:  488 us [488;488]    ( 122 S)
Pulse timing distribution:
 [ 0] count:    2,  width:  512 us [504;520]    ( 128 S)
 [ 1] count:   28,  width:  136 us [136;140]    (  34 S)
 [ 2] count:   23,  width:  240 us [228;260]    (  60 S)
 [ 3] count:   28,  width:  104 us [104;108]    (  26 S)
 [ 4] count:    1,  width: 10004 us [10004;10004]       (2501 S)
Level estimates [high, low]:  15957,     44
RSSI: -0.1 dB SNR: 25.6 dB Noise: -25.7 dB
Frequency offsets [F1, F2]:    7319,      0     (+27.9 kHz, +0.0 kHz)
Guessing modulation: Pulse Width Modulation with sync/delimiter
view at https://triq.org/pdv/#AAB1050200008800F000682714839393939393939393939393
93938392A2A2A2A293A2A293A3939392A2A392A293939393939393A29455
Attempting demodulation... short_width: 136, long_width: 256, reset_limit: 236,
sync_width: 512
Use a flex decoder with -X 'n=name,m=OOK_PWM,s=136,l=256,r=236,g=0,t=0,y=512'
pulse_demod_pwm(): Analyzer Device
bitbuffer:: Number of rows: 2
[00] {13} ff f8       : 11111111 11111
[01] {26} 84 b9 7f 40 : 10000100 10111001 01111111 01

Pressure close to 0, ~20C, and the device serial should be 05547949 or 20427620042333 (those are the unique IDs on the device body).

Given the suggestion produced when running with -A, I also tried

rtl_433-rtlsdr -R 0 -X n=name,m=OOK_PWM,s=136,l=260,r=232,g=0,t=0,y=512 -f 315025000

and I get many instances of 

time      : 2021-06-06 08:58:59
model     : name         count     : 2             num_rows  : 2
rows      :
len       : 13           data      : fff8,
len       : 26           data      : 84b97f4
codes     : {13}fff8, {26}84b97f4
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-06 08:58:59
model     : name         count     : 2             num_rows  : 2
rows      :
len       : 13           data      : fff8,
len       : 26           data      : 84b97f4
codes     : {13}fff8, {26}84b97f4

then when shaking the device some more 

time      : 2021-06-06 08:59:20
model     : name         count     : 2             num_rows  : 2
rows      :
len       : 13           data      : fff8,
len       : 28           data      : e25cbff
codes     : {13}fff8, {28}e25cbff
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-06 08:59:20
model     : name         count     : 2             num_rows  : 2
rows      :
len       : 13           data      : fff8,
len       : 28           data      : e25cbff
codes     : {13}fff8, {28}e25cbff

which could be the "wake mode" data stream, followed by the "drive mode" messages. But the output also suggested using y=508 and y=516 in addition to y=512 as I used above.

As I mentioned, soon I will be able to capture data from 8 sensors in total, 4 old in open air and 4 new installed. I should also be able to pressurize the old sensors to figure out the pressure value format. Just let me know how to best capture relevant data and minimize noise/improve the antenna if that can help. I tried looking at the data with SDRsharp, but my recordings didn't look very good compared to for example https://github.com/JoeSc/Subaru-TPMS-Spoofing (which I used to learn more). I had a lot more noise and much worse waveforms, even if I'm sure my ignorance of SDRsharp was the main contributing factor

merbanan commented 3 years ago

Get one of these:

https://www.biltema.se/fritid/tradgard/tradgardsredskap/trycksprutor/tryckspruta-15-l-2000030676

merbanan commented 3 years ago

Perfect for pressure sensors.

robcazzaro commented 3 years ago

Now that you mention it, I have one of those pressure sprayers, a much bigger one, something like https://www.amazon.com/Chapin-International-20000-1-Gallon-Translucent/dp/B000E28UQU

It's a great suggestion! I planned to use a Gatorade bottle (big enough mouth to get the sensor thru), drill a hole in the cap and put the pressure sensor in there, thru the hole. That way I can use my tire inflator and pressure gauge to actually measure the pressure inside the bottle and gather more precise data. But for a quick test, dropping the sensors insider the pressure sprayer and pumping it would be perfect. Thanks!

robcazzaro commented 3 years ago

Some more info. According to the schematic on the FCC site, the sensor uses either a MAX1472 or MAX7044 Tx chip. Datasheets are here https://datasheets.maximintegrated.com/en/ds/MAX1472.pdf and https://datasheets.maximintegrated.com/en/ds/MAX7044.pdf, which look identical aside from the MAX7044 having more Tx power. Those chips support OOK/ASK Transmit Data Format, up to 100kbps Data Rate.

Unfortunately there isn't a lot of info on those datasheets, outside of confirming that it's ASK. And it seems consistent with the data format shown at the end of this document https://fccid.io/MRXNIS315G3/Block-Diagram/TECHNICAL-DESCRIPTION-626813.pdf. 8 "words" separated by .15 sec, each composed of 18 bits of start, then 3 bits, 24 bits, 8 bits, 2 bits

zuckschwerdt commented 3 years ago

I never got any container to hold pressure after adding a hole to pressurize. I even tried to "seal" the hole with the valve part of a cut up bicyle tire. The pressure sprayer is the only thing working so far ;)

The interesting part in your -A captures is e.g.

 [ 1] count:   34,  width:  136 us [136;140]    (  34 S)

The most prominent width with 34 counts is 136 µs. That way s=125,l=125 (our slicer is quite adaptible but I'd guess 50 vs 125 is too much of a difference to get a good decoding). Also it should be OOK_PCM if the FCC documents are right (still getting something with FSK is a quirk and not reliable).

If you look at one of the pdv links from -A and use MC/125/125 the data bits should be sliced quite nicely.

robcazzaro commented 3 years ago

Using 125 usec seems to be correct, here's what I see image

I also managed to get a good audio recording in AM mode, and if I look at the format in the FCC database and the Audacity audio, I can see the 18 bits of preamble, followed by 3+24+8+2 (the following is not to scale, just a quick hack for me to "see" the data) image

It must be the right interpretation, because using MC/125/125 and using 2 sensors, I get this

Bits: {88} 00 / 00 00 / D5 4A 7D 00 08 / and Bits: {88} 00 / 00 00 / D5 4A 7D 00 08 . And if I convert the decimal serial number of those 2 TPMS, I get 54A7D0 and 54A7AD. Which are 24 bits long, and contained in those results (just after the D).

If I'm guessing right, the first 3 bits are 101 (binary), but the slicer recognizes a 0x0D because the recognized gap is 508, but I guess should be 600usec, given the 4kHz encoding, so the first 3 bits are 0x05, followed by the serial number, followed by 8 bits which are 0x00 given that the sensor is not pressurized, and finally the last two bits are 10 in binary (or 01 in another case)

My last 2 sensors have the serial number partially covered, but if I read the data as above and convert the resulting hex numbers (53E22F and 54A7E0) to decimal, all the visible numbers are a match, and that cannot be a coincidence :) 4 serials matching

In checking back with the Schrader/Subaru format, now it looks as if the data actually match. The flag is either a 5 or 7, the serial numbers are correctly shown, and the pressure shown (0.05 or 0.15) could be right. The only discrepancy, when looking at the code, is that the Subaru protocol seems to use 10 bits for pressure, but it should be 8 in the Nissan case. From the code

Data layout:
    ^^^^_^_^_^_^_^_^_^_^_^_^_^_^_^_^^^^_FFFFFFIIIIIIIIIIIII
    IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIPPPPPPPPPPPPPPPPPPPP
- PREAMBLE: 36-bits 0xF5555555E
- F: FLAGS, 3 Manchester encoded bits
- I: ID, 24 Manchester encoded bits
- P: PRESSURE, 10 Manchester encoded bits (PSI * 20)
NOTE: there is NO CRC and NO temperature data transmitted

I wonder if the last 2 bits are actually part of the pressure or if they indicate low battery (or maybe even a limited CRC). Or maybe the first 3 bits are the ones used for low battery. I'm pretty sure that one of my sensors has a low battery (my car reported only 3 working sensors, that's why I had to replace them), so hopefully I can identify it once my tool arrives and can test pressure

I'll leave this open until I can complete my tests and confirm that all Nissan/Infiniti cars use the same format (if so, maybe would be worth renaming the protocol)

robcazzaro commented 3 years ago

Good news and bad news. On the positive side, I now understand the format of this specific sensor. On the negative side, it's using the same format as the Schrader-SMD3MA4 TPMS, but encoding slightly different information.

I captured data from 8 different sensors, all same model or equivalent (e.g. Redi-sensor SE10001HP and SE10001HPR), and the format is indeed

Data layout:
    ^^^^_^_^_^_^_^_^_^_^_^_^_^_^_^_^^^^_FFFFFFIIIIIIIIIIIII
    IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIPPPPPPPPPPPPPPPPPP??
- PREAMBLE: 36-bits 0xF5555555E
- F: FLAGS, 3 Manchester encoded bits
- I: ID, 24 Manchester encoded bits
- P: PRESSURE, 8 Manchester encoded bits (PSI * 4)
- ?? possibly a short form of CRC or just junk bits
NOTE: there is NO temperature data transmitted

I'm positive that the pressure field is only 8 bits. I ran multiple tests with different pressures, both using properly inflated tires and with a pressure sprayer hack and an ESP8266/BME280 sensor providing a reference. And the value must be divided by 4 to get the correct pressure reading (i.e. 32 psi is encoded as 128)

The flag values I could determine are 0 = learning mode (when using a 125kHz coil to wake up the TPMS and have the car learn; sends 9 packets) 3 = sudden pressure change (increase/decrease) sends 7 or 8 packets 5 = wake up mode, sends 8 packets 7 = driving mode, sends 8 packets

(it seems to use each bit as a flag, and not encode all 8 possible values)

Usually the car is parked, and when the car is started and the centrifugal switch closes, the TPMS goes into wake up mode, then sends a drive mode series of packets every minute.

The last 2 bis are either unused or a weak form of CRC. It looks as if Schrader simply adapted an existing format when developing this sensor, and reused the SMD3MA4 format but with only 8 bits for the pressure field. I'm not sure if it's worth trying to understand if those 2 bits are CRC or not. What I verified, is that the same data results in always the same 2 last bits. Those are most definitely not random, but somehow calculated from the packet content (including the serial number of the device, different devices sending identical packets can have different last 2 bits)

This sensor is used in quite a lot of cars. I'm attaching two txt files, one for all the models using the SMD3MA4 (the existing decoder) and another all the models using the NIS325G3 sensor in my car (Infiniti/Nissan)

There is no easy way to identify which is which, so I'm not sure how a new decoder can be added. Either printing both possible values of the pressure, or creating an almost identical decoder that gets blacklisted by default. Looking at the car list, the NIS315G3 (also Redi-Sensor SE10001HP and many others) is common. As a matter of fact, more models use the NIS315G3 than the SMD3MA4

Schrader-NIS315G3.txt Schrader-SMD3MA4.txt

zuckschwerdt commented 3 years ago

Good work on discovering all that! If the last/lowest two "pressure" bits are a mistake in the SMD3MA4 decoder perhaps and really some checksum, then that would leave a supposed factor of 5 for PSI -- maybe it's 4 rather?

Maybe @RonNiles from #1511 can chime in on how exact his guess on the pressure unit/factor was?

I'll look into the checksum. With 2 bits it's likely parity (on different sections).

zuckschwerdt commented 3 years ago

Do you have a list of some raw codes, i.e. just lines of 0xF5555555E.....F..I..P..XX or else the MC decoded codes?

robcazzaro commented 3 years ago

I don't think that the last 2 bits are an error in the SMD3MA4 decoder. From the few packets I managed to get (from cars driving in front of my house), the values seem correct (32-36 psi range). If the SMD3MA4 sensor actually did not use the last 2 bits, all those values would be 40 to 45 psi, which seems awfully high. But admittedly my sample is too small to be factual (only 2 unique sensors)

I'd be happy to capture plenty of packets, but I have to admit I get lost in all the rtl433 options. Can you please let me know what command line I should use to capture the packets? For every one of those, I can provide the flags value, unique serial and PSI values, to help narrow things down. If there were an easy way to see the binary encoded data (i.e. the binary version of ^^^^^^^^^^^^^^^^^_^^^^_FFFFFFIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIPPPPPPPPPPPPPPPPPP??), I could also try to guess the CRC algorithm as well. I know I could just recompile a special version of the decoder, but I'm hoping that there already is an option to get the data

zuckschwerdt commented 3 years ago

Going with the timings we observed and the SMD3MA4 decoder this flex spec should grab the bits:

rtl_433 -f 315M -R 0 -X 'n=NIS315G3,m=OOK_PCM,s=125,l=125,r=600'

You can capture to a log file with e.g. -F json:myfile.txt

If you drop some codes in a https://triq.net/bitbench you can then experiment with "format strings". At a guess: preamble 555e, then Manchester, and a string of F:3b ID:24h P:8h CHK:2b

zuckschwerdt commented 3 years ago

E.g. here is a BitBench with the test data for the SMD2MA4.

RonNiles commented 3 years ago

Thanks for pinging. My implementation was based on information from this project that you referenced above. https://github.com/JoeSc/Subaru-TPMS-Spoofing I summarized the sources including FCC filings in the rtl_433_tests: https://github.com/merbanan/rtl_433_tests/pull/367/files At the time I contributed the code, I was not aware of any documents which indicated a 3 + 24 + 8 + 2 format, but that is certainly possible. Hopefully whatever bit interpretation you are proposing works for both Subaru and Nissan. I monitor my Subaru tire pressure regularly using rtl_433 and can help verify any proposed unified code for accuracy. By the way, to force a reading on my sensors with my car stationary, I tap them with my index finger for up to 30 seconds at about 2-3 Hz to simulate tire rotation.

robcazzaro commented 3 years ago

Got a few good good readings. I'm including the file captured with rtl_433 -f 315M -R 0 -X 'n=NIS315G3,m=OOK_PCM,s=125,l=125,r=600', as you suggested. And I also entered the packets in bitbench (cool tool!) to ensure it worked. I used 2 separate strings, to capture both the "human readable" data and the bits, to see if I could guess the CRC. I also tried to apply a simple XOR CRC, one of the bitbench options, but that's not it (you will see that in the links below). I wanted to upload these to start, and I'll keep trying to guess the CRC

I could only test the 4 old sensors, with no pressure on them (i.e. they are supposed to read 0 psi). It's raining and my car is parked in the street :) if needed, I can get more readings once the weather improves.

In order, I applied the TPMS tool (125kHz) to all 4 sensors in order. Then in order I woke up each sensor (flag 5), then shook them once more to get a "driving" packet (flag 7). In the included file, you might see additional "driving" signals, because my "shaking" was not always enough, and other times too much

The lines below have the sensor ID, followed by the bitbench for that sensor and that event. The included file has all the data, but it's all duplicated

Learn
54a7e0  https://triq.net/bitbench?c=%7B113%7Df5555555e55999665aaa555555680%22&f=Flag%3A3b%20ID%3A24h%20P%3Ad%20CRC%3A2b%0Aflag%3A3b%20i%3A24b%20s%3A8b%20CC%3A2b&a=Preamble&m=555e&d=MC&cf=XOR&cl=-2&cw=2#
54a7ad  https://triq.net/bitbench?c=%7B114%7Df5555555e55999665aa6699555540&f=Flag%3A3b%20ID%3A24h%20P%3Ad%20CRC%3A2b%0Aflag%3A3b%20i%3A24b%20s%3A8b%20CC%3A2b&a=Preamble&m=555e&d=MC&cf=XOR&cl=-2&cw=2#
54a7d0  https://triq.net/bitbench?c=%7B114%7Df5555555e55999665aa9955555540&f=Flag%3A3b%20ID%3A24h%20P%3Ad%20CRC%3A2b%0Aflag%3A3b%20i%3A24b%20s%3A8b%20CC%3A2b&a=Preamble&m=555e&d=MC&cf=XOR&cl=-2&cw=2#
53e22f  https://triq.net/bitbench?c=%7B113%7Df5555555e55996aa56566a9555680&f=Flag%3A3b%20ID%3A24h%20P%3Ad%20CRC%3A2b%0Aflag%3A3b%20i%3A24b%20s%3A8b%20CC%3A2b&a=Preamble&m=555e&d=MC&cf=XOR&cl=-2&cw=2#

wake up + drive
54a7e0  https://triq.net/bitbench?c=%7B113%7Df5555555e99999665aaa555555580&f=Flag%3A3b%20ID%3A24h%20P%3Ad%20CRC%3A2b%0Aflag%3A3b%20i%3A24b%20s%3A8b%20CC%3A2b&a=Preamble&m=555e&d=MC&cf=XOR&cl=-2&cw=2#
54a7e0  https://triq.net/bitbench?c=%7B113%7Df5555555ea9999665aaa555555680&f=Flag%3A3b%20ID%3A24h%20P%3Ad%20CRC%3A2b%0Aflag%3A3b%20i%3A24b%20s%3A8b%20CC%3A2b&a=Preamble&m=555e&d=MC&cf=XOR&cl=-2&cw=2#

54a7ad  https://triq.net/bitbench?c=%7B114%7Df5555555e99999665aa6699555640&f=Flag%3A3b%20ID%3A24h%20P%3Ad%20CRC%3A2b%0Aflag%3A3b%20i%3A24b%20s%3A8b%20CC%3A2b&a=Preamble&m=555e&d=MC&cf=XOR&cl=-2&cw=2#
54a7ad  https://triq.net/bitbench?c=%7B114%7Df5555555ea9999665aa6699555540&f=Flag%3A3b%20ID%3A24h%20P%3Ad%20CRC%3A2b%0Aflag%3A3b%20i%3A24b%20s%3A8b%20CC%3A2b&a=Preamble&m=555e&d=MC&cf=XOR&cl=-2&cw=2#

54a7d0  https://triq.net/bitbench?c=%7B114%7Df5555555e99999665aa9955555640&f=Flag%3A3b%20ID%3A24h%20P%3Ad%20CRC%3A2b%0Aflag%3A3b%20i%3A24b%20s%3A8b%20CC%3A2b&a=Preamble&m=555e&d=MC&cf=XOR&cl=-2&cw=2#
54a7d0  https://triq.net/bitbench?c=%7B114%7Df5555555ea9999665aa9955555540&f=Flag%3A3b%20ID%3A24h%20P%3Ad%20CRC%3A2b%0Aflag%3A3b%20i%3A24b%20s%3A8b%20CC%3A2b&a=Preamble&m=555e&d=MC&cf=XOR&cl=-2&cw=2#

53e22f  https://triq.net/bitbench?c=%7B113%7Df5555555e99996aa56566a9555580&f=Flag%3A3b%20ID%3A24h%20P%3Ad%20CRC%3A2b%0Aflag%3A3b%20i%3A24b%20s%3A8b%20CC%3A2b&a=Preamble&m=555e&d=MC&cf=XOR&cl=-2&cw=2#
53e22f  https://triq.net/bitbench?c=%7B113%7Df5555555ea9996aa56566a9555680&f=Flag%3A3b%20ID%3A24h%20P%3Ad%20CRC%3A2b%0Aflag%3A3b%20i%3A24b%20s%3A8b%20CC%3A2b&a=Preamble&m=555e&d=MC&cf=XOR&cl=-2&cw=2#

nopressure.txt

robcazzaro commented 3 years ago

@RonNiles if you could take a few readings of your tires with the existing protocol and see if the pressure is more or less the same you see on you dashboard, that means that the Subaru protocol has a 10 bits pressure packet. If the readings are, on the other hand, they are 20% too low, that means it's only using 8 bits. For my car, if I use the SMD3MA4 protocol, all my tires read 20% too low compared to the car values. Only by using the first 8 bits (and dividing by 4) I get the right value (as opposed as reading 10 bits and dividing by 20, as the current code does)

Unfortunately if the SMD3MA4 protocol indeed uses 10 bits, I don't see how it's possible to implement the logic in a single decoder. And at this point I'm positive that the NIS315G3 uses 8 bits, I have too many data points for that to be a coincidence

RonNiles commented 3 years ago

@robcazzaro I do get correct readings with the existing protocol - I've been using it for that purpose since I contributed the code! On the other hand, I have noticed a few readings from random cars passing by that seemed to be low by about 20%. We should try to see if there is a way to differentiate the two sensors either by finding documentation or by trial and error. Perhaps the ranges of valid serial numbers for each product is different.

robcazzaro commented 3 years ago

@RonNiles thanks for confirming your readings. And, yes, the 20% low is almost surely cars with the equivalent of the NIS315G3 which, as you can see from the files I uploaded, are quite a few and some of those are rather common cars

Aside from the 4 sensors I uploaded, my other, new sensors (redi-sensor SE100001HP, for what is worth) are CEDE23, 820900, D004E2, D6136D. Those send the exact same data as my original ones. And Redi-Sensor (which is part of Continental) sells a SE10003A sensor for cars like yours, so clearly there must be a programming difference or they wouldn't bother with different models. I really doubt that we can collect enough data to figure out if sensors have a range by type. And I really doubt that Schrader is actually coordinating with Redi-sensor and all other manufacturers to reserve block of IDs for each manufacturer. 24 bits in any case are not really enough for a true GUID

I can't claim to understand how protocol decoding decisions are made for rtl_433. But given that preamble, flags and ID are all compatible, maybe the decoder can print out both pressure values, one interpreting 10 bits for the pressure field, the other only 8, and multiplying accordingly. It's not ideal, but methinks that with a minimum of explanation the human interpreting the data will be able to figure out which one applies to them (possibly using the redi-sensor list I uploaded to pick which one is theirs). And if anyone is using rtl_433 as part of their automation, filtering on sensor ID and parsing only the right value is not that hard

RonNiles commented 3 years ago

@robcazzaro Worst case we can change rtl_433 to print out both interpretations and maybe a summary of a few popular make/models that might be associated with each. But it would be better if we could find a way to distinguish the two. Might be serial number range, data transmission rate or something else. I'll take a close look at your samples over the weekend. Another avenue might be to simply ask someone at Schrader or Redi-Sensor since obviously there are people there who know what the difference is.

RonNiles commented 3 years ago

I found several places that suggest the two-bit data field is a checksum: A gist which apparently interprets this bitstream in python and computes a checksum 2-bits at a time: https://gist.github.com/mossmann/4aa65689b2ea4f4449e232a69282e023#file-tpms-schrader-ook37-py A similar product by Schrader with more detailed documentation. The bitrate is different but the data fields are identical. It also has a full description of the flags: https://fccid.io/MRXTTR1B0/Operational-Description/12-36119.pdf

In order to verify this checksum on our data, I went into the bitbench and changed the preamble from 555e to 5557 in order to increase the total bits from 37 to 38 (an even number). Then I changed the checksum calculation to ADD / offset 0 / length 38 / width 2 / output BINary. The checksum always ends in '01' for the three .cu8 files of my data and also for several of the samples provided by @robcazzaro above.

So it appears that our devices are identical data-wise except for the scaling of the 8-bit PSI field (PSI 4 vs. PSI 5), and my implementation misinterprets the checksum as two extra LSB.

zuckschwerdt commented 3 years ago

Yes, both as 8-bit and x4 vs x5 seems more like it. PSI x20 is too much precision, the low order bits don't contribute any useful information to the pressure.

Re checksum vs CRC: CRC-1 is just parity -- think of the x+1 poly removing always 2 bits at a time, so you get the parity as remainder CRC-2 would be x²+1 and that also is parity but with two bits remainder for odd and even data bits parity sum. Generally the (weak) x^n + 1 poly for CRC-n is just parity with a stride of n.

zuckschwerdt commented 3 years ago

Can you grab a cu8 of the NIS315G3, we already have samples of the SMD3MA4, perhaps there is some subtle difference hiding in there. https://triq.org/iqs/#/Schrader_TPMS_SMD3MA4/01/driving_315M_250k.cu8

zuckschwerdt commented 3 years ago

@robcazzaro you can add comments as "[my comment]" to the codes, here is all data in one BitBench.

zuckschwerdt commented 3 years ago

You can checkout https://github.com/merbanan/rtl_433/tree/fix-SMD3MA4 which adds the flags and checksum.

robcazzaro commented 3 years ago

Awesome investigative work @RonNiles. Based on the document you found, my guess for the flags seems validated. I know that at least my device doesn't send an "entering off mode". And I could not verify that 1 means low battery, but it would be consistent with all the other findings, so I think it's safe to assume that 1=low battery

@zuckschwerdt I quickly compiled and tested your new version, and it works for my device. I didn't have time yet to verify the scaling (since I tested with the old devices on my desk). I found the formatting a bit weird, though:

model     : Schrader-SMD3MA4                       type      : TPMS
ID        : 54A7D0
Flags     : 0            Learn     : 1             Pressure  : 0.0 PSI
Integrity : PARITY
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-12 10:06:11
model     : Schrader-SMD3MA4                       type      : TPMS
ID        : 54A7D0
Flags     : 5            Wakeup    : 1             Pressure  : 0.0 PSI
Integrity : PARITY
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-12 10:06:23
model     : Schrader-SMD3MA4                       type      : TPMS
ID        : 54A7D0
Flags     : 7            Pressure  : 0.0 PSI       Integrity : PARITY

I'm not sure why you display a Learn:1 or Wakeup:1, but when in drive mode there is nothing and the format looks different.

I would think that a format like "Flag:5 - Wakeup Pressure:xxPSI" or "Flag:7 - Driving Pressure:xxPSI" would be easier to read (and to parse if used for automation). And i would add the Low battery flag as well

The only remaining issue is the different scaling for a wide class of sensors

Just to be sure, in order to capture the cu8, is this the correct command line? rtl_433 -f 315M -S known

If so, here are the same 4 sensors as before (54a7e0, 54a7ad, 54a7d0, 53e22f), sending a wake up, followed by a "driving" series of packets.

NIS315G3.zip

zuckschwerdt commented 3 years ago

The signasl really look the same. The only indication for the pressure scaling could be the ID, we see 3... for the SMD3MA4 and 5... for the NIS315G3 -- but there is no evidence for any mapping.

robcazzaro commented 3 years ago

Thanks for the prompt replies and the time you are spending on this, @zuckschwerdt

The ID=5 in the NIS315G3 is purely a side effect of the serials in the 4 old devices under test. The IDs for the 4 new sensors are CEDE23, 820900, D004E2 and D6136D (I didn't capture data from those because it's less convenient to do the tests on a car parked on the street while it's raining :). The original sensors had ID more "clustered together" because those came with the car, and very likely part of a batch. The new sensors are aftermarket Redi-sensor bought thru Amazon, so have pretty random IDs.

The new sensors are immediately recognized and work just fine in my Infiniti, so clearly the ID=5 is not a factor. Some of the random readings I get from cars driving by, also have IDs all over the place. I'm pretty sure that @RonNiles will have captured IDs with completely random distribution, and the only way we can tell them apart is by noticing a pressure value too low. For example, my car sensors read a 32 PSI tire as 26 PSI using the SMD3MA4 decoder, and that can't be a real value, since the car computer would have alerted the driver with a low pressure alarm. It's unlikely to have so many cars driving by with very low tires (in my case). I didn't save the random IDs I got, but I'm sure those were not all starting with 5

I really don't think that there is any programmatic way to tell the 2 sensors apart. Either the decoder prints both values and leaves the decision to the person interpreting the results, or a new decoder has to be created, and either R 168 or the new one gets blacklisted. Since all the other data is identical, my preference (for what is worth) would be to print both values and have a note in the readme somewhere with the list of car models using one or the other sensor type.

RonNiles commented 3 years ago

Here are all my stray readings since I started monitoring. I have a raspberry PI which logs to a text file in json format and I use the jq utility to parse it. I don't live near heavy traffic so there aren't many strays and most are duplicates, probably close neighbors. Since I need to use PSI / 5 to get a sensible reading, PSI / 4 would result in a too high reading. My four sensor ID (3F0650 3F0B51 3F103C 3F135B) are the original ones from when I bought my car from the Subaru dealer 1 year ago. I removed these from the command line and printed the readings for unknown vehicles below. There seems to be only one sensor (788C89) with an abnormally high reading sshuser1@raspberrypi-2:~ $ tail -n 61000 /home/pi/tpms | jq -c 'select(.model=="Schrader-SMD3MA4")|{id}' | sort -u | cut -b8-13 | tr '\n' ' ' 3AE33B 3AE92A 3AE948 3AEDA4 3F0650 3F0B51 3F103C 3F135B 788C89 78E7CE 79F153 B0CB02 sshuser1@raspberrypi-2:~ $ sshuser1@raspberrypi-2:~ $ for id in 3AE33B 3AE92A 3AE948 3AEDA4 788C89 78E7CE 79F153 B0CB02; do tail -n 60000 /home/pi/tpms | jq -c 'select(.id=='\"$id\"')|{id,pressure_PSI,time}'; done {"id":"3AE33B","pressure_PSI":25.7,"time":"2020-11-07 18:06:03"} {"id":"3AE33B","pressure_PSI":25.7,"time":"2020-11-07 18:06:03"} {"id":"3AE33B","pressure_PSI":25.7,"time":"2020-11-07 18:06:03"} {"id":"3AE33B","pressure_PSI":30.25,"time":"2020-12-25 13:24:15"} {"id":"3AE33B","pressure_PSI":29.35,"time":"2021-03-19 14:05:46"} {"id":"3AE33B","pressure_PSI":29.35,"time":"2021-03-19 14:05:47"} {"id":"3AE33B","pressure_PSI":29.35,"time":"2021-03-19 14:05:47"} {"id":"3AE33B","pressure_PSI":33.1,"time":"2021-05-27 12:59:28"} {"id":"3AE33B","pressure_PSI":33.1,"time":"2021-05-27 12:59:28"} {"id":"3AE33B","pressure_PSI":33.1,"time":"2021-05-27 12:59:28"} {"id":"3AE33B","pressure_PSI":33.1,"time":"2021-05-27 12:59:28"} {"id":"3AE33B","pressure_PSI":33.1,"time":"2021-05-27 12:59:28"} {"id":"3AE33B","pressure_PSI":33.1,"time":"2021-05-27 12:59:28"} {"id":"3AE33B","pressure_PSI":33.1,"time":"2021-05-27 12:59:29"} {"id":"3AE92A","pressure_PSI":29.1,"time":"2020-10-27 13:05:22"} {"id":"3AE92A","pressure_PSI":30.6,"time":"2020-12-20 11:53:49"} {"id":"3AE92A","pressure_PSI":30.6,"time":"2020-12-20 11:53:49"} {"id":"3AE92A","pressure_PSI":30.95,"time":"2021-06-02 14:52:29"} {"id":"3AE92A","pressure_PSI":30.95,"time":"2021-06-02 14:52:29"} {"id":"3AE92A","pressure_PSI":30.95,"time":"2021-06-02 14:52:30"} {"id":"3AE92A","pressure_PSI":30.95,"time":"2021-06-02 14:52:30"} {"id":"3AE92A","pressure_PSI":30.95,"time":"2021-06-02 14:52:30"} {"id":"3AE948","pressure_PSI":29.55,"time":"2020-10-31 14:18:38"} {"id":"3AE948","pressure_PSI":29.55,"time":"2020-10-31 14:18:38"} {"id":"3AE948","pressure_PSI":29.55,"time":"2020-10-31 14:18:38"} {"id":"3AE948","pressure_PSI":29.55,"time":"2020-10-31 14:18:39"} {"id":"3AE948","pressure_PSI":29.55,"time":"2020-10-31 14:18:39"} {"id":"3AE948","pressure_PSI":29.55,"time":"2020-10-31 14:18:39"} {"id":"3AE948","pressure_PSI":28,"time":"2020-11-07 18:06:03"} {"id":"3AE948","pressure_PSI":28,"time":"2020-11-07 18:06:03"} {"id":"3AE948","pressure_PSI":28,"time":"2020-11-07 18:06:03"} {"id":"3AE948","pressure_PSI":32.2,"time":"2021-01-05 12:04:02"} {"id":"3AE948","pressure_PSI":32.2,"time":"2021-01-05 12:04:02"} {"id":"3AE948","pressure_PSI":32.2,"time":"2021-01-05 12:04:02"} {"id":"3AE948","pressure_PSI":32.2,"time":"2021-01-05 12:04:02"} {"id":"3AE948","pressure_PSI":32.2,"time":"2021-01-05 12:04:02"} {"id":"3AE948","pressure_PSI":32.2,"time":"2021-01-05 12:04:02"} {"id":"3AE948","pressure_PSI":32.55,"time":"2021-01-09 13:00:42"} {"id":"3AE948","pressure_PSI":32.55,"time":"2021-01-09 13:00:42"} {"id":"3AE948","pressure_PSI":32.55,"time":"2021-01-09 13:00:42"} {"id":"3AE948","pressure_PSI":32.55,"time":"2021-01-09 13:00:43"} {"id":"3AE948","pressure_PSI":32.55,"time":"2021-01-09 13:00:43"} {"id":"3AE948","pressure_PSI":32.55,"time":"2021-01-09 13:00:43"} {"id":"3AE948","pressure_PSI":32.55,"time":"2021-01-09 13:00:43"} {"id":"3AE948","pressure_PSI":31.35,"time":"2021-01-22 12:59:54"} {"id":"3AE948","pressure_PSI":31.35,"time":"2021-01-22 12:59:54"} {"id":"3AE948","pressure_PSI":31.35,"time":"2021-01-22 12:59:54"} {"id":"3AE948","pressure_PSI":31.35,"time":"2021-01-22 12:59:54"} {"id":"3AE948","pressure_PSI":31.35,"time":"2021-01-22 12:59:54"} {"id":"3AE948","pressure_PSI":32.2,"time":"2021-02-04 13:41:39"} {"id":"3AE948","pressure_PSI":32.2,"time":"2021-02-04 13:41:39"} {"id":"3AE948","pressure_PSI":32.2,"time":"2021-02-04 13:41:39"} {"id":"3AE948","pressure_PSI":32.05,"time":"2021-02-09 13:32:38"} {"id":"3AE948","pressure_PSI":32.05,"time":"2021-02-09 13:32:38"} {"id":"3AE948","pressure_PSI":32.05,"time":"2021-02-09 13:32:38"} {"id":"3AE948","pressure_PSI":32.05,"time":"2021-02-09 13:32:39"} {"id":"3AE948","pressure_PSI":32.05,"time":"2021-02-09 13:32:39"} {"id":"3AE948","pressure_PSI":33.15,"time":"2021-04-01 16:23:31"} {"id":"3AE948","pressure_PSI":33.15,"time":"2021-04-01 16:23:31"} {"id":"3AE948","pressure_PSI":33.15,"time":"2021-04-01 16:23:31"} {"id":"3AE948","pressure_PSI":33.15,"time":"2021-04-01 16:23:32"} {"id":"3AE948","pressure_PSI":33.15,"time":"2021-04-01 16:23:32"} {"id":"3AE948","pressure_PSI":33.15,"time":"2021-04-01 16:23:32"} {"id":"3AE948","pressure_PSI":33.15,"time":"2021-04-01 16:23:32"} {"id":"3AE948","pressure_PSI":31.5,"time":"2021-04-03 11:41:23"} {"id":"3AE948","pressure_PSI":31.5,"time":"2021-04-03 11:41:23"} {"id":"3AE948","pressure_PSI":31.5,"time":"2021-04-03 11:41:23"} {"id":"3AE948","pressure_PSI":31.5,"time":"2021-04-03 11:41:24"} {"id":"3AE948","pressure_PSI":31.5,"time":"2021-04-03 11:41:24"} {"id":"3AE948","pressure_PSI":32.55,"time":"2021-05-27 12:59:31"} {"id":"3AE948","pressure_PSI":32.55,"time":"2021-05-27 12:59:31"} {"id":"3AE948","pressure_PSI":32.55,"time":"2021-05-27 12:59:31"} {"id":"3AE948","pressure_PSI":32.7,"time":"2021-06-04 12:53:48"} {"id":"3AE948","pressure_PSI":32.7,"time":"2021-06-04 12:53:48"} {"id":"3AEDA4","pressure_PSI":28.05,"time":"2020-10-14 13:05:10"} {"id":"3AEDA4","pressure_PSI":27.3,"time":"2020-10-27 13:05:21"} {"id":"3AEDA4","pressure_PSI":27.3,"time":"2020-10-27 13:05:21"} {"id":"3AEDA4","pressure_PSI":27.3,"time":"2020-10-27 13:05:21"} {"id":"3AEDA4","pressure_PSI":27,"time":"2020-11-04 13:02:41"} {"id":"3AEDA4","pressure_PSI":27,"time":"2020-11-04 13:02:41"} {"id":"3AEDA4","pressure_PSI":27,"time":"2020-11-04 13:02:42"} {"id":"3AEDA4","pressure_PSI":25.6,"time":"2020-11-07 18:05:58"} {"id":"3AEDA4","pressure_PSI":29.1,"time":"2020-12-17 14:58:02"} {"id":"3AEDA4","pressure_PSI":29.1,"time":"2020-12-17 14:58:02"} {"id":"3AEDA4","pressure_PSI":29.1,"time":"2020-12-17 14:58:02"} {"id":"3AEDA4","pressure_PSI":29.1,"time":"2020-12-17 14:58:03"} {"id":"3AEDA4","pressure_PSI":29.1,"time":"2020-12-17 14:58:03"} {"id":"3AEDA4","pressure_PSI":29.1,"time":"2020-12-17 14:58:03"} {"id":"3AEDA4","pressure_PSI":29.1,"time":"2021-01-09 13:00:40"} {"id":"3AEDA4","pressure_PSI":28.05,"time":"2021-01-22 12:59:53"} {"id":"3AEDA4","pressure_PSI":28.05,"time":"2021-01-22 12:59:53"} {"id":"3AEDA4","pressure_PSI":28.05,"time":"2021-01-22 12:59:54"} {"id":"3AEDA4","pressure_PSI":28.55,"time":"2021-02-09 13:32:38"} {"id":"3AEDA4","pressure_PSI":28.55,"time":"2021-02-09 13:32:38"} {"id":"3AEDA4","pressure_PSI":28.55,"time":"2021-02-09 13:32:39"} {"id":"3AEDA4","pressure_PSI":28.55,"time":"2021-02-09 13:32:39"} {"id":"3AEDA4","pressure_PSI":28.55,"time":"2021-02-09 13:32:39"} {"id":"3AEDA4","pressure_PSI":28.55,"time":"2021-02-09 13:32:39"} {"id":"3AEDA4","pressure_PSI":28.55,"time":"2021-03-29 12:58:47"} {"id":"3AEDA4","pressure_PSI":28.55,"time":"2021-03-29 12:58:47"} {"id":"3AEDA4","pressure_PSI":28.55,"time":"2021-03-29 12:58:48"} {"id":"3AEDA4","pressure_PSI":28.55,"time":"2021-03-29 12:58:48"} {"id":"3AEDA4","pressure_PSI":28.55,"time":"2021-03-29 12:58:48"} {"id":"3AEDA4","pressure_PSI":27.6,"time":"2021-05-23 10:31:45"} {"id":"3AEDA4","pressure_PSI":27.6,"time":"2021-05-23 10:31:45"} {"id":"3AEDA4","pressure_PSI":27.6,"time":"2021-05-23 10:31:45"} {"id":"3AEDA4","pressure_PSI":27.6,"time":"2021-05-23 10:31:46"} {"id":"3AEDA4","pressure_PSI":27.6,"time":"2021-05-23 10:31:46"} {"id":"788C89","pressure_PSI":39.75,"time":"2021-03-18 15:16:04"} {"id":"788C89","pressure_PSI":39.75,"time":"2021-03-18 15:16:04"} {"id":"788C89","pressure_PSI":39.75,"time":"2021-03-18 15:16:04"} {"id":"788C89","pressure_PSI":39.75,"time":"2021-03-18 15:16:04"} {"id":"788C89","pressure_PSI":39.75,"time":"2021-03-18 15:16:04"} {"id":"78E7CE","pressure_PSI":15,"time":"2021-05-29 13:49:06"} {"id":"79F153","pressure_PSI":31.6,"time":"2021-03-31 12:02:15"} {"id":"79F153","pressure_PSI":31.6,"time":"2021-03-31 12:02:16"} {"id":"79F153","pressure_PSI":31.6,"time":"2021-03-31 12:02:16"} {"id":"B0CB02","pressure_PSI":27.1,"time":"2020-11-07 17:52:28"} {"id":"B0CB02","pressure_PSI":27.1,"time":"2020-11-07 17:52:28"} {"id":"B0CB02","pressure_PSI":27.1,"time":"2020-11-07 17:52:28"} {"id":"B0CB02","pressure_PSI":27.1,"time":"2020-11-07 17:52:28"} {"id":"B0CB02","pressure_PSI":27.1,"time":"2020-11-07 17:52:28"} {"id":"B0CB02","pressure_PSI":27.1,"time":"2020-11-07 17:52:28"} {"id":"B0CB02","pressure_PSI":27.1,"time":"2020-11-07 17:52:28"} {"id":"B0CB02","pressure_PSI":27.1,"time":"2020-11-07 17:53:32"} sshuser1@raspberrypi-2:~ $

RonNiles commented 3 years ago

Taking another look at this, I did get my logic backwards - if a PSI * 4 sensor gets decoded by my version of RTL which prints out PSI/5, it would appear too low as @robcazzaro mentioned several times. So to summarize my data, it appears that I have a lot of readings from a vehicle with four sensors that begin with 3AE and these tires seem to deflate to about 28 PSI and reinflate to about 33 PSI as is normal, so this is likely a Subaru-compatible sensor. The vehicle with the 39.75 PSI could be grossly overinflated and since we received multiple transmissions, the data is likely correct. The vehicle with PSI 15 is very low, even if we account for 5:4 inaccuracy due to sensor type. It would be interesting to compute the checksum on this stray reading to see if it is corrupt since there were no concurrent duplicate transmissions received. The final sensor shows PSI 27.1 which is in the range where it could be an underinflated Subaru or a normally inflated Nissan.

robcazzaro commented 3 years ago

In order for me to get more car sensor readings, I need to have my SDR-RTL outdoors, but since I live in Seattle, finding a dry day is not easy :) As soon as the weather cooperates, I'll get more data and see if there's a logic to the device IDs (but since there are multiple manufacturers, I'm not optimistic). Also, my new devices have a device ID printed on the body that is 32 bit, not 24. But as far as I can tell, only 24 bits are sent, and the upper 8 bits are not transmitted, just used in manufacturing. The printed IDs are 0CCEDE23, 0C820900, 0CD004E2 and 0CD6136D and send CEDE23, 820900, D004E2, D6136D, respectively. I'll get some cu8 streams for those to see if the upper 8 bits are somehow present (yes, when it's not raining :)

robcazzaro commented 3 years ago

I captured a few cu8 from the new sensors, using the "learn option", flag 0, attached in this zip file. The first 6 characters of the file name are the sensor ID. Since I captured those in a busy street, I'm pretty sure that there are spurious signals intermixed, but hopefully the relevant packets are present (they look present, to my eyes)

New_NIS315G3.zip

robcazzaro commented 3 years ago

I finally managed to get a couple of days of logging. All the sensors with pressure >30 psi are almost surely SMD3MA4. Anything lower than 25 psi is almost surely a NIS315G3. The ones in between can be either. There doesn't seem to be any logic to the IDs

Incidentally, as I mentioned before, the new code is more difficult to parse than the old one, with records having different number of fields. @zuckschwerdt, it would be good if you could change the code once again and revisit that aspect. And also decide how to handle the fact that identical looking sensors have different pressure scaling (4 and 5)

log NIS315G3.json.txt

zuckschwerdt commented 3 years ago

Thanks for all the logging and puzzling. Really bad that we can derive the type from anything :/

About the flags field: rtl_433 is not concerned with actual presentation of values. It's mostly raw values (converted to common units maybe) and some breakouts of flags (e.g. battery). We don't want a textual description in the value. But I can remove the wakeup/learn fields. Other TPMS don't have those mapped. If flags are really interesting for some application you could always decode them easily. (if you are parsing the output you should use JSON for best compatibility.)

Not sure what to do about two different sensors using the same protocol but varying scaling (in pressure). We could add a duplicate decoder using the other scaling. Select the right one and it looks nice. But select both and the output is duplicate and somewhat confusing, I guess.

merbanan commented 3 years ago

I think adding a protocol option is the only way we can handle this in a sane way. The option can enable one or the other scale value. Duplicating the output is not needed. If someone has both sensors they will need to add special handling in the consumers based on the sensor id.

I see no other way around this.

robcazzaro commented 3 years ago

As a (new) user of rtl_433, my preferred options in order would be:

If a protocol has to be blacklisted, probably NIS315G3 should be the one. From my absolutely unscientific sample in an affluent coastal city :), there seems to be more SMD3MA4 sensors driving around

Once again, thanks for looking into this and your responsiveness.

RonNiles commented 3 years ago

Maybe the default behavior (in the event of no protocol specified on command line) should be to simply print the raw 8-bits of pressure value via a new protocol ID. Then in the case where -R 168 is specified we can do SUBARU scaling, and have still another new protocol ID defined for NISSAN scaling. The advantages of this are (1) fairness: the default behavior will favor neither model, and (2) backwards compatibility for people like me who use -R 168 in the command line

gdt commented 1 year ago

contributor hat: It seems obvious from reading way too fast that we need a conf file with a list of IDs that sort into flavors. It doesn't make sense for someone to ask for one decode vs another, because some other car might come by, they might be wardriving, and they might have one of each kind of car.

gdt commented 1 year ago

ticket gardening: What's the status? What's next? There's a ton of useful info in here, but if it isn't captured in the source code, we haven't locked in the value. Is anyone working on it/

therealchalz commented 3 months ago

I stumbled across this by running into the same issues with the Schraeder EG53MA4 decoder and whatever units happen to be in my tires, where it is decoded "properly" and the length, bits, CRC and such are all OK but just the actual translation of pressure and temperature are wrong (I'm not sure about the flags).

I agree that the preferred option would likely be a protocol option. It's just not scalable to always create new pratically identical decoders just because the pressure or temperature scaling might be different.

There are valid concerns about backwards compatibility and about what new users will have issues with when it's showing their TPMS is being decoded properly but the numbers don't seem to be quite right. I think this really a documentation issue, and it seems the number of people who are digging into rtl_433 just for TPMS may warrant practically a whole documentation section on just that, including possibly user curated lists of vehicle make/model and/or TPMS P/N and their corresponding decoder id (and protocol option) (in the wiki maybe?).

In any case I'm not sure what the protocol option would look like but I get the impression that the implication would be, say 1 = P/N ABC, 2 = P/N XYZ and the code would switch out the temp & pressure calculations. I think this would be practical if it is documented well.

Extending the idea a bit further, and seeing that we can only supply a single argument in the current architecture, but that this argument is a char*, we do have a bit of flexibility to be a bit more verbose. I think we can assume the general case of encoding the pressure and temperature into the bits are linear transformation with a slope and offset, so perhaps in addition to pre-made encodings, you could alternatively supply your own slope and offset for pressure and temperature. I can't speak for anyone maintaining rtl_433 but I would assume we'd ideally want to get away from requiring code changes when people find new, but compatible with existing, TPMS sensors. Instead just the docs would be updated to say "If you have P/N ABCD, use protocol option p_offset:0.0;p_gain:0.4;t_offset:-60;t_gain:1" as a crude example.

zuckschwerdt commented 3 months ago

Protocol decoders should be short and simple. The flexibility of custom decoding parameters seems nice initially but creates a kind of inner platform anti-pattern.

We should have multiple decoders and tell users to pick one. Best case would be if decoders could reliably reject improbable looking data in addition to CRC.

We also have a "priority" mechanism to allow a decoders to take precedence, if they can successfully decode.

loki-amorf commented 1 week ago

Opel Astra H and Vectra C TPMS sensors has very close structure of data packets. My investigating is in progress now. The only one that frequency is 433,92 MHz

loki-amorf commented 4 days ago

CRC-2

Could you please help me with direction, where I can find any information about CRC-2 implementation

merbanan commented 4 days ago

Can you post some decoded messages? I highly doubt that a 2-bit CRC is in use.

loki-amorf commented 4 days ago

Can you post some decoded messages? I highly doubt that a 2-bit CRC is in use.

^^^^^^^^^^^^^^^^^^^^^_FFFFFF IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII PPPPPPPPPPPPPPPPCCCCTTTTTTTTTTTTTTTTUUUU

T & U never used for CRC calculation

PRE |------------ID-ADDR-----------| |PRESSU| CRC |TEMPER| ?? 000 00001010 01000001 00011110 00000000 11 01001010 00

Untitled___

I have Autel MaxiTPMS PAD and I wrote code for STM32 with CC1101 and now I able to emulate sensors and check if my code and idea right.

merbanan commented 4 days ago

You can use bitbench to investigate the bit patterns.

loki-amorf commented 3 days ago

trying to investigate..

HEX binary CS parity 0x22'f6e0 001000101111011011100000 = 01 (1) p1 0x22'f6e1 001000101111011011100001 = 00 (0) p0 0x22'f6e2 001000101111011011100010 = 11 (3) p0 0x22'f6e3 001000101111011011100011 = 10 (2) p1 0x22'f6e4 001000101111011011100100 = 00 (0) p0 0x22'f6e5 001000101111011011100101 = 11 (3) p1 0x22'f6e6 001000101111011011100110 = 10 (2) p1 0x22'f6e7 001000101111011011100111 = 01 (1) p0 0x22'f6e8 001000101111011011101000 = 11 (3) p0 0x22'f6e9 001000101111011011101001 = 10 (2) p1 0x22'f6ea 001000101111011011101010 = 01 (1) p1 0x22'f6eb 001000101111011011101011 = 00 (0) p0 0x22'f6ec 001000101111011011101100 = 10 (2) p1 0x22'f6ed 001000101111011011101101 = 01 (1) p0 0x22'f6ee 001000101111011011101110 = 00 (0) p0 0x22'f6ef 001000101111011011101110 = 11 (3) p1 0x22'f6f0 001000101111011011110000 = 00 (0) p0 0x22'f6f1 001000101111011011110001 = 11 (3) p0

zuckschwerdt commented 3 days ago

You can use a BitBench like this. But those codes seem short? We are expecting 45+2 bits, right?

loki-amorf commented 3 days ago

I can't understand how Bitbench may be useful for checksum algorithm clarification. For checksum calculation PREPEND ADDRESS and PRESSURE are involved. I zeroed PREPEND bits and PRESSURE byte just to check that Autel MaxiTPMS Pad passed messages to it's GUI. Then I incremented ADDRESS word and brute forced checksum to be sure that Autel recognize message.

// Compute parity
int parity = xor_bytes(b, 4) ^ (b[4] & 0xe0);
parity     = (parity >> 4) ^ (parity & 0x0f);
parity     = (parity >> 2) ^ (parity & 0x03);

Using this algo I get wrong result. Also I tried checksum calculation with x²+1 poly (5 if I not mistaken) and get wrong result. Then I tried initial value with 0xFF and also fail. I calculate parity bit of whole word and nothing clear nor interfere with checksum

zuckschwerdt commented 3 days ago

Ok, I misread, BitBench is not able to help with field-width checksums, only whole-message sums.

Generally you can only reverse sums for bits with observed changes. Then you might extrapolate the insight gained, maybe. I.e. if you try to solve 

00000 = 01
00001 = 00
00010 = 11
00011 = 10
00100 = 00
00101 = 11
00110 = 10
00111 = 01
01000 = 11
01001 = 10
01010 = 01
01011 = 00
01100 = 10
01101 = 01
01110 = 00
01110 = 11
10000 = 00
10001 = 11

Then it's not a simple XOR (parity) as e.g. 00010 = 11 XOR 00011 = 10 = 00001 = 01 but should equal 00001 = 00

Strange.