Unknown Chinese TPMS external sensor support
cyberFIRM opened this issue · comments
Hi,
First of all great work really appreciated. I had some unknown TPMS sensor in my garage for a lot of time. I tried running rtl-433 but it did not match with any of the present decoders.
I tried debugging using URH to see the waveforms signals and tried to decode the data into Temp and Pressure but all in vain. Wondering if anyone can help.
first pulse:
010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101011001100110100110101001011001011010101010100110100101011010100110100101100110010101010101100101011010100101010110011001010101011010100101010110101010011001
nrz
555555555555555555555555555555555545555555555555555555555555555555555599a6a596aa9a56a696655595a9566556a55a84c8
manchester I
ffffffffffffffffffffffffffffffffffca91b027135fb8f5f1e14
second pulse
010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101011001100110100110101001011001011010101010100110100101011010100110100101100110010101010101100101011010100101010110011001010101011010100101010110101010011001
nrz
555555555555555555555555555555555545555555555555555555555555555555555599a6a596aa9a56a696655595a9566556a55a84c8
manchester I
ffffffffffffffffffffffffffffffffffca91b027135fb8f5f1e14
Values monitored on LCD Display:
Temp: 42 C
Pressure: 25 PSI
That's an unexpectedly long preamble buthe MC with ~10 bytes looks right.
Try to capture a long sequence of codes while changing a value slowly. E.g. let the air out slowly (the sensor should notice and start to send codes rapidly).
With usual timings you should be able to grab codes with `rtl_433 -R 0 -X 'n=name,m=FSK_PCM,s=50,l=50,g=150,r=900,preamble=5556'
Thank you for quick reply. I will work on the suggestion provided above.
Meanwhile please kindly take a look at the logs attached below:
tpms_json.txt
I am using ESP32 Dev Module with CC1101 using library RTL_433_ESP .
I pulled out what looked like the unique MC values in that tpms_json.txt file and put into BitBench for easier initial review. It looks like there's some bit errors, but there might be a few rows that decoded enough to get an idea of what's in there.
Shifting off 3 bits the values look a bit like a progression and the last byte could be a CRC. We will need more good codes.
Attached are some more codes as requested.
With usual timings, codes grabbed with `rtl_433 -R 0 -X 'n=name,m=FSK_PCM,s=50,l=50,g=150,r=900,preamble=5556'
rtl-433-R0-X.txt
Using URH, recorded the waveforms:
RTL-SDR-20240627_143405-433_92MHz-1MSps-1MHz
Comments on waveforms:
First 3 waveforms: temp 35 C and pressure 21 PSI
Waveforms 4 to 8: temp 36 C and pressure 21 PSI
Waveforms in rapid succession (slowly air leakage) : temp 36 C and pressure dropped from 20 to 18 PSI with passage of time
Last couple of waveforms: temp 36 C and pressure 18 PSI
Note on the recorded IQ file: the level of around -24 dB is dangerously close to silent.
You need to rename the file to include the proper meta data: …_433.92M_1000k.cs8 then looking at the noise levels you can preset a very low minimum level and use autolevel: -Y minlevel=-45 -Y autolevel -Y magest -M level -M noise
Here is a BitBench of the data you posted.
Here is a BitBench with the data cleaned up, deduped and with some wild guesses.
There is a CRC-8, poly 0x2f, init 0xaa that checks out for all packets. And 2f poly is one of the AUTOSAR named ones.
looks interesting. Been working on decoding pressure data. Any hints on that one?
data doesn't seem to be in kPa...
0x1F9 to 21 PSI ?
The most puzzling thing with the suspected pressure data is the placement of the upper bits. It looks like it's counting down nicely but above 1ff it should be 200 but we see 8100
The byte between temp and crc could be status/flags.
Pressure sounds to be 9 bits, PSI, offset 40, scale 10. So value can be from 0 PSI to 47.1 PSI ( 0 kPa to 324.7 kPa)
like this bitbench
I removed some data with the {132} where bits are missing and shifted.
I reviewed the rf decode part, it works fine a with FSK_MC_ZEROBIT , pulse is 54 µs and preamble = 0xfffff5, try the sample with:
rtl_433 -X "n=Chinese_TPMS,m=FSK_MC_ZEROBIT,s=54,l=0,r=200,preamble=fffff5" -Y autolevel -Y magest -Y minlevel=-45 20240627_433.92M_1000k.cs8
We have packet payload: 9 bytes.
Byte Position 0 1 2 3 4 5 6 7 8
Sample {72} b9 3f 63 b2 01 f9 24 36 bb
Layout II II II II MF1 LP TT F2 CC
- II {32} Sensor ID
- M {1} MSB Pressure,
- F {7} Flags1, unknown ? always 0x1
- LP {8} LSB Pressure, --> Pressure {9} MSB | LSB, offset 40, scale 10, PSI
- TT {8} Temperature °C
- F2 {8} Flags 2, unknown ? upper nibble always 0x3, lower nibble is variable
- CC {8} CRC, poly 0x2f, init 0xaa.
I drafted a decoder based on these above findings, ready to PR, same it works with the sample.
FYI: I checked with -A and the pulse width is more 54 µs than 50 µs.
URH sees a whole lot of data in that same sample file. I find that the symbol width is almost exactly 50 µs.
Some of the data seems to be from another device. Here is what I found with URH:
Removing other devices, bad data, and duplicates, I get this data that passes the CRC:
$ reveng -w 8 -s b93f63b201f92436bb b93f63b201f9253652 b93f63b201f2243487 b93f63b201f224303b b93f63b201f0243027 b93f63b201ef24309d b93f63b201ee243093 b93f63b201ed243081 b93f63b201ec24308f b93f63b201ea2430ab b93f63b201e82430b7 b93f63b201e72430ed b93f63b201e52430f1 b93f63b201e124362b b93f63b201e62431cc b93f63b201e6243601 b93f63b201e724360f
width=8 poly=0x2f init=0xaa refin=false refout=false xorout=0x00 check=0x2a residue=0x00 name=(none)
rtl_433 has difficulty finding all this data in the provided sample file created by URH. The rtl_433 command line with parameters in the previous message seems to only pick out a few of these signals. I suspect that allowing rtl_433 to save the signals instead of URH would yield better sample files.
Also, although it doesn't seem to matter much with these samples, caution with FSK_MC_ZEROBIT on data (like this) that begins with MC-encoded logical "0" bits (as this is what the sync/prefix truly is). FSK_MC_ZEROBIT will mis-decode these as logical "1" bits until the first "true" logical "1" bit in the decode and it slips into the real decoding. This is why FSK_MC_ZEROBIT finds a preamble of "fffff5", when the decoded MC data is actually "000015"
I had similar success using this FSK_PCM flex spec to find the same small subset of the data in that sample file.
rtl_433 -X "n=Chinese_TPMS,m=FSK_PCM,s=50,l=50,r=200,preamble=5556,symbol_zero={2}4,symbol_one={2}8" -Y autolevel -Y magest -Y minlevel=-45 RTL-SDR-20240627_143405-433_92MHz-1MSps-1MHz.complex16s
{76}5b93f63b201f92436bb
I reviewed the rf decode part, it works fine a with FSK_MC_ZEROBIT , pulse is 54 µs and preamble = 0xfffff5, try the sample with:
rtl_433 -X "n=Chinese_TPMS,m=FSK_MC_ZEROBIT,s=54,l=0,r=200,preamble=fffff5" -Y autolevel -Y magest -Y minlevel=-45 20240627_433.92M_1000k.cs8We have packet payload: 9 bytes.
Byte Position 0 1 2 3 4 5 6 7 8 Sample {72} b9 3f 63 b2 01 f9 24 36 bb Layout II II II II MF1 LP TT F2 CC
- II {32} Sensor ID
- M {1} MSB Pressure,
- F {7} Flags1, unknown ? always 0x1
- LP {8} LSB Pressure, --> Pressure {9} MSB | LSB, offset 40, scale 10, PSI
- TT {8} Temperature °C
- F2 {8} Flags 2, unknown ? upper nibble always 0x3, lower nibble is variable
- CC {8} CRC, poly 0x2f, init 0xaa.
I drafted a decoder based on these above findings, ready to PR, same it works with the sample.
FYI: I checked with -A and the pulse width is more 54 µs than 50 µs.
@ProfBoc75 thanks a lot. A dumb question since I am unable to comprehend it. How does the offset and scaling factor is playing role in calculating the pressure? Is there any formula?
Adjusted Pressure = (Pressure value - Offset) / Scale;
@cyberFIRM: Yes, from the 9 bits we have the pressure_raw.
Pressure_PSI = ( pressure_raw - 40 ) * 0.1f ( same as (pressure_raw - 40 ) / 10 or (pressure*0.1f) - 4)
And the reverse, to get the 9 bits value, (pressure_PSI * 10 ) + 40 = pressure_raw.
tpms_chinese.zip
drafted the decoder based on above finding by @ProfBoc75 . Using RTL_433_ESP library, I was able to get the codes after some tuning of CC1101.
pulse_slicer_manchester_zerobit: Unbranded Chinese TPMS codes [{214}7ffffffffffffffffffffffffffffffffd6e4fd8ec80628e1c2ec0]
pulse_slicer_manchester_zerobit: Unbranded Chinese TPMS codes [{209}000000000001ffffffffffffffffffffeb727ec764037470e1758]
Stuck on decoding part... in decoding section there is nothing to process. For more clarification:
#line547
How to parse the codes into temp, pressure, id values ?? Thanks for the help
I'd like to suggest that we switch to a non-nation-based name for this device. Is there any kind of identifying markings on the device we could use? Or perhaps something like Unbranded-TPMS-202406?
Perhaps those who have the device could try to describe everything about it that has any kind of markings as well as packaging, and how they bought it. From context I am guessing this is something labeled tpms from aliexpress, without better information.
Regarding packaging, I could not find any box as they were in my garage for a long time, I don't even know where they came from.
No markings or labels on the TPMS sensors itself other than FR, FL, RR, RL. Will disassemble a sensor when get back home for any labels.
Disassembled a sensor, there is written "kylin-wz-1.0" on the PCB nothing else. I suppose we can go with this name for the device.
Sounds reasonable to me.
"Kylin" might be a transliteration of "麒麟", "a propitious beast in ancient Chinese mythology, with the shape of a deer, tail of an ox, a single horn and scales all over its body" and likely used in various company names. Here's a reference to a product titled "EKYLIN Wireless TPMS" which may or may not have anything to do with what we're analyzing, nor even be manufactured by that company.
From Kylin-Tec (site is hacked / not working properly), they used NXP pressure module. Another link to this site : https://web.archive.org/web/20180901193313/http://new.zlgmcu.com/Item/304046.aspx
Today link : https://www.zlgmcu.com/carbcontrol/carbcontrol/article/id/7.html
And yes, look like a Chinese product.
Notice some useful information about the product, like pressure range, frequency, MCU model and so on...
Nice find. According to that archive.org page's Contact page, "Kylin Technology Co., Ltd." (其利科技有限公司) was (or is also) "Qili Tianxia Technology Development Co., Ltd." (其利天下技术开发有限公司). Searching for that, I found this page stating this company, formerly "Hong Kong Qili Technology" (香港其利科技), seemed to focus on TPMS systems and seems to own some TPMS related patent .