Unknown Chinese TPMS external sensor support about rtl_433 HOT 22 OPEN

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?

from rtl_433.

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 .

from rtl_433.

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'

from rtl_433.

@zuckschwerdt @cyberFIRM:

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.

from rtl_433.

@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.

from rtl_433.

Or this one : https://web.archive.org/web/20180826092330/http://kylin-tec.com/p_lr.asp?id=2756&cl_na=%E8%83%8E%E5%8E%8B%E7%9B%91%E6%B5%8B%E7%B3%BB%E7%BB%9F%E5%BC%80%E5%8F%91&cl_id=556&sid=0

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...

from rtl_433.

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 .

from rtl_433.

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.

from rtl_433.

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.

from rtl_433.

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

from rtl_433.

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.

from rtl_433.

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.

from rtl_433.

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 ?

from rtl_433.

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.

from rtl_433.

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.

from rtl_433.

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:

BitBench

Removing other devices, bad data, and duplicates, I get this data that passes the CRC:

BitBench

$ 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

from rtl_433.

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.

@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;

from rtl_433.

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

from rtl_433.

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.

from rtl_433.

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.

from rtl_433.

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.

from rtl_433.

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 rtl_433.