merbanan
2021 Jeep Grand Cherokee (WK2) TPMS pressure is half
rtl_433 version 25.02-44-ge37c0d78 branch master at 202508301514 inputs file rtl_tcp RTL-SDR
The WK2 Jeep reports protocol 82 as a Citroen TPMS, however the pressure reports 1/2 actual value. According to my OBD-II scanner, the TPMS sensors are reported as Continental. The sensor serial number also appears to be reporting correctly.
I added a test decoder for Jeep, just duplicating Citroen and multiplying the pressure by 2. This seems to be reporting accurately.
Is Citroen decoding correctly, or is this simply submitting a request to push the above change into live code? (my git skills are close to non-existent).
It's a fair question if any existing code is correct. Another fair question is if there are one kind of sensor with one pressure encoding and another that is almost the same, but has a different encoding, with each specified for different cars.
It may be better to label the protocol as Continental, if that's the TPMS manufacturer, and it just happens to be found on Citroen.
I see it was added in 2017 by @zuckschwerdt who perhaps knows. (Around me I see one Citroen every 5 years.)
My client code is for a specific vehicle, so I'm just multiplying by 2.
Sure, but what you'd want to submit in a PR is just changing the multiplier, which would change other people's data. Which is only ok if their current data is wrong. Unless you have a way to recognize your TPMS vs their TPMS differently. I am saying that we really should try to figure out what's going on - which you are helping with by posting here.
Oh, I agree. I'm really just highlighting my observation. Without knowing which is right/wrong, I'll just let my client deal with it. The other way to manage it would be to post a PR to duplicate 82, multiple by 2, and name it Jeep/Continental or some such.
You are of course free to have a local fix. I often do that to make things be what I want, when I'm not sure enough to impose it on others.
@gdt I think the pressure formula came from an analysis Josh McCormick and you did in Dec. 2018 on the list. We should add these findings at least as comment "Seen on 2021 Jeep Grand Cherokee (WK2), however pressure reports 1/2 actual value according to OBD, sensors are Continental."
@Tenesmusphyre is the value exact? And is it exact for lower and higher pressure too? The current calculation raw * 1.364, for you raw * 2.728, seems so random...
@zuckschwerdt I didn't perform exhaustive testing; the sensors only transmit in motion.
I did, however, set pressures on each of the 4 tires to 33,34,35, and 36psi to identify tire location, and the results tracked. Temperature also appears reasonable. It's hard to tell exact with ambient vs actual temperature, but temperature did change slightly during a short drive and each sensor also tracked well with each other.
I can't find any pressure conversion that would include 1.364 (or 2.728), but the x2 could just be a bit shift/truncation.
Additional updates. Using recorded data.
Picking a single sensor, the OBD scanner recognized it as id 705761CB. rtl_433 displayed it as 705761be. 16psi, 73F. Another (same?) packet received at the same timestamp, same rssi/snr/noise was decoded as protocol 201 with an id of c705761b. 191psi, 295F.
There's a lot of suggestive information there, but I don't know where to go next to dig deeper.
If this helps, this is the packet of interest. https://triq.org/pdv/#AAB10600D000300068013C00400000849491919191919191919191919191A19192A191929191A1919291919191A2A2A19192A192919191A192A19191919291919191A2A192A2A291A291A291A291A291A291A291A19291A1929191B555
Decoded as:
Detected FSK package @0.448152s
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : @0.448152s Protocol : 82
model : Citroen type : TPMS id : 705761be
state : dc flags : 0 repeat : 11 Pressure : 16 PSI Temperature: 73 F maybe_battery: 36
Integrity : CHECKSUM
Modulation: FSK Freq1 : 434.0 MHz Freq2 : 433.9 MHz
RSSI : 1.0 dB SNR : 31.7 dB Noise : -31.7 dB
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : @0.448152s Protocol : 201
model : Truck type : TPMS id : c705761b
wheel : 224 Pressure : 191 PSI Temperature: 295 F Battery Ok: 1 Flag? : b Integrity : CHECKSUM
Modulation: FSK Freq1 : 434.0 MHz Freq2 : 433.9 MHz
RSSI : 1.0 dB SNR : 31.7 dB Noise : -31.7 dB
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Never noticed this before. Both Citroen and Truck TPMS have the same timings and XOR-checksum, slightly different data layout though.
Note that Truck is showing up at 1/10th the rate of Citroen (13 vs 132). Just from a raw grep of the decoded original file. There are also 13 decodes with the same timestamp.
I didn't look at the individual decodes, just a brute force grep/awk/uniq of the decoded data. Odds are it's the same behavior seen above.
EDIT: I did look at the individual decodes (text). Every Truck decode has a predecessor Citroen decode with the same timestamp.
Yes the Truck TPMS is offset by 4 bit to the Citroen, strange why it works at all. The Truck TPMS needs less bits, e.g. a truncated reception might trigger it.
Can you record a sample, and upload as zip here, where only Citroen is triggered and one where both are triggered? Then we can really compare Truck, Citroen, and yours in depth.
Try this. I'm not sure if it's the same decode as above, but it's 2 stand-alone Citroen and a Citroen/Truck pair.
I don't reallly remember 2017 that well :-) It sounds like we are making progress in understanding what's going on. It would not shock me if there are mutiple on-air protocols that collide in decoders. I don't know anybody local with a Jeep, so for now I'll cheer you on quietly. If there is solid evidence for decoding behavior, i'm fine to discard my original 2017 thoughts as perhaps not correct.
Summary of raw data and MC decode:
-
Truck TPMS Raw PCM
{401}55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 56 99 55 66 95 56 9A 59 95 56 55 59 5A 55 55 55 56 A9 96 9A AA FF 8(single last bit)2 packets, 2.2 ms apart, lead-out of 9 bits. MC:0 00 00 00 00 00 00 00 00 00 00 00 00 00 01 | a0 58 1b 28 10 23 00 01 e9 bf -
Citroen TPMS Raw PCM
{199} 55 55 55 56 A6 59 95 99 A6 A6 65 95 A6 65 55 56 A6 65 65 96 55 A9 66 96 7E (no last bit)3 packets 108 ms apart, lead-out of 6 bits. MC:00 01 | d2 8a dd 48 d4 01 d4 49 0e 59 (single 0 bit) -
Jeep TPMS Raw PCM
{203}F5 55 55 55 6A 6A 66 A5 56 66 A6 95 59 56 95 59 66 66 66 5A 65 A5 6A 95 67 E (no last bit)3 packets, 105 ms apart, lead-out of 6 bits, lead-in of 4 bits. MC:00 01 | dd 70 57 60 86 09 55 4d 31 e1 (single 0 bit)00 01 | dd 70 57 60 86 0a 55 4d 31 e2 (single 0 bit)00 01 | dd 70 57 60 86 0b 55 4d 31 e3 (single 0 bit)
So the Jeep TPMS looks very much like the Citroen TPMS but with a short lead-in (4 bit). We are not likely to always capture that lead-in before the preamble.
The Truck TPMS has much longer preamble and a longer lead-out (9 bits). We could maybe detect that. Also the Truck will have 2 identical packets, the others have repeats with the counter going up.
It seems like we are heading for a doctrine change of treating multiple packets of a single logical transmission as a first-class entity. I think that's good but we should probably step back and think about the larger issues.
It seems that Truck can also be distinguished by the shorter 2.2 ms inter-packet interval.
It is seeming like Citroen and Jeep have hard-to-distinguish wire formats and different encodings. I guess maybe let them both decode and the user can select the protocol/id they care about, if they don't want to disable the other etc.
For my own knowledge, how did you get from the capture file to Manchester, and then how does that relate to pulling in the payload? There is nothing recognizable as far as mapping it to the decode section of the device source file.
Is there a reference page I haven't found?
Use our https://triq.org/pdv3/ to go from sample file to bits and then https://triq.org/bitbench/ to analyse and decode the bits. Organize sample files with https://github.com/triq-org/iqviewer and if you are on Mac get a preview with https://github.com/triq-org/iqspectrogram-quicklook
I guess maybe let them both decode and the user can select the protocol/id they care about, if they don't want to disable the other etc.
My local copy does that. It populated as protocol 282 vs Citroen's 82. I used -R -82 (or -R 0) to filter it out and just -R 282 for the Jeep. I don't want to rebuild rtl_433 on the Pi, though, so I just have the client do the multiplication. Client is an ESP32 CYD that reads MQTT published decodes from RTL_433 to display tire pressure of the Jeep towed behind RV.
@zuckschwerdt FWIW, I found Universal Radio Hacker (URH) https://github.com/jopohl/urh
"For my purposes" it worked great. Start with a .cu8, get it to FSK. Find the bit width. Decode. Filter. I don't know how it would work on more complex signals, but I was able to tear apart the Jeep and Ford TPMS signals and see where some noise was coming from on the Ford (I used the Jeep as known good sample).
As far as I can tell, other than the 1/2-pressure reported, the Jeep decode (#82) has been fine. I don't know if it's a Jeep difference or Citroen with an original oops.