Analyzing Shenzhen EGQ TPMS Samples

[js-3972]

I have this TPMS from Amazon that can be found at https://www.amazon.com/dp/B0BK8SHDRZ?psc=1&ref=ppx_yo2ov_dt_b_product_details

When I run rtl_433, it recognizes the sensor as the Abarth-124Spider, however, none of the values (pressure, temperature, etc.) appear to be matching what the sensor is displaying.

I have ran "rtl_433 -S all" to grab samples of some of the received frames. I have attached some of the cu8 files I captured below but I'm unsure if the data I have captured is even valid. For example, I'm confused at to why the modulation scheme varies between the files even though they were taken with the same device or why some packets are longer than others. It would be much appreciated if someone couId provide some guidance on what the next steps are with the data I have captured.
ShenzenEGQ.zip

[ProfBoc75]

Hi @js-3972 ,

The length of the capture is not an issue, it depends on the rf conditions, are you isolate, or living in big city, for the last, you may capture a lot of rf signals.

Can you try with rtl_433 -R 123 , since the 3 last from your cu8 files sounds to be properly decoded with this decoder disabled by default.

For all the 4 cu8 files :

with -C customary :

Check if it's ok with -R 123. Also , what are the values and the unit on the console ? If you capture again, for each cu8 file, put the information you have, with the unit (C / F , PSI / Bar / Kpa .. )

[js-3972]

Hi @ProfBoc75 ,

The device that's being recognized is the Abarth-124Spider, not the Jansite TPMS, so I ran "-R 156" instead. I have attached a few cu8 files that were generated. As you can see, the rtl software displays a value of 31 c and 48 kpa, but the device's console displays 15 psi and 26 c.

Attached are all of the cu8 files generated with the previous values.
15psi_26c.zip

[ProfBoc75]

Hi @js-3972 ,

Thanks for the sample and the temp / pressure information.

The data message is not the same format as the Abarth-124Spider but it's similar until the checksum the reason why it's decoded as Abarth-124Spider, but the conversion of the temp & pressure sounds to be different.

First the Shenzhen message is longer, after the checksum we have a fix 0x40 then a CRC-16/CCITT-FALSE, in little-endian.
The Temperature offset is -55 instead of -50 ( same, it's -55 for the Jansite Solar which have a very similar data format).
The pressure is data * 3 = kpa value, instead of * 1.38.

Here the bitbench

So, to confirm that, capture again other values.
For the temperature, it's easy to confirm, remove 5 C from Abarth result and you have the same as your console's display (from your last captures, 31C - 5C = 26C as expected).
For the pressure, more complex, by default, rtl_433 will show the value in KPa for this Abarth device, ( 1 PSI = 6.89476 KPa), we need to divide the result by 6.89476 to get PSI but the pressure conversion is *3 instead of *1.38, so you need to divide by 3.17159 to get to good result from KPa value to PSI value. (from your last captures, 48KPa / 3.17159 = 15 PSI as expected)
If you want just the KPa correction take the result and * 2.1739. ( 48 KPa * 2.1739 = 104 KPa = 15 PSI).

After few captures that will confirm my hypothesis, we can update the abarth device to take into account this model.

[ProfBoc75]

Hi @zuckschwerdt , need your help please.

I'm ready to create a new PR to 'Add support for Shenzhen EGQ Q85 and improve Abarth 124 Spider'.
But in my current fork I still have another active PR #2549 Add Support for TFA Stratos, ready for merge ...

How I can create a new PR with this current issue & without conflict with the other PR ?

Notice, that I don't yet git push my update, still on my laptop for the moment, waiting your git instruction / help.

Thanks

[zuckschwerdt]

You need to start a new branch from master for the PR.
E.g. git checkout master ; git checkout -b feat-egqtpms then add the decoder, commit, push, PR.

[ProfBoc75]

You need to start a new branch from master for the PR. E.g. git checkout master ; git checkout -b feat-egqtpms then add the decoder, commit, push, PR.

Done, Thx.

[js-3972]

@ProfBoc75 Thanks for the timely response, I'm glad you were able to decode the signal.

I am particularly interested in how you were able to properly decode the bits. For example, in bitbench, you had the string "aaaa9aa9596a69569aa95665aa6a599a9a96559569aaa695a55a90" for the Shenzhen sensor. Where did this string come from? Maybe I missed it, but was this particular message included in one of the signals I provided? I am just as much interested in the process you took to decode the signal as I am in decoding the signal itself, so if you could provide some more insight that would be greatly appreciated. Thanks.

[ProfBoc75]

@js-3972 , yes, the string come from the signal you provided in the .cu8 files.

90% of the job was already done by the abarth-124Spider device driver, since your signal was decoded but the temp and pressure were wrong.

So, look at the bottom of tpms_abarth124.c file and you have the modulation information:

• FSK PCM
• Short = Long = 52 µs
• reset = 150 µs

Then into the same file, we have the preamble = 0xaaaaa9 , inverted data, Manchester encoded data and data layout

So it's enough to start a flex decoder and replay the cu8 files , keep only the abarth 124Spider enabled by -R 156 and :v for verbose the code , like this :

rtl_433 -X "n=shenzen,m=FSK_PCM,s=52,l=52,r=150,invert" *.cu8 -R 156:v

Notice that the flex decoder is useless, since we have the same result with the verbose option...

Then enough for me to build the bitbench information from all sources :

• your information, 15 PSI ( = 103.421 KPa ) and 26 C
• The shenzhen flex response : aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa9aa9596a69569aa95665aa6a599aaa96559559aaaa969659a0
• The wrong temp and pressure from Abarth decoded information.
• I also replayed Abarth captured cu8 files from rtl_433_test to get the data string samples : d5555554d52acccd4acb2b3532caccd2cd4d5554cb4d34cc6
• The data layout from the existing device driver (bit / byte mapping to ID, status, Temp, Pressure, ... )

Thanks to the builtin Manchester decoder in bitbench, then you have the hexa bytes (in bitbench on Manchester line, click on Show to see them).

07 62 79 07 ac 23 51 1b de 40 9c f1
07 62 79 07 aa 1b 51 1b e0 40 24 54
07 62 79 07 ac 23 50 1b df 40 19 b4
07 62 79 07 aa 1b 51 1b e0 40 24 54
0f 54 76 e8 b7 53 44 01 64 0a
0f 54 76 ea b7 95 40 01 a4 4a

With the help of this nice online crc calculator web site , I was able to find that the 2 last bytes are CRC16 CCITT-FALSE but little-endian formatted , it means that the first byte is the lower value and the last byte is the higher value, which is the reverse of classic format.

Then, I added the data layout information :

ID:32h FLAGS:4h4h P:8d T:8d S:4h4h CHECKSUM:8h UNKNOWN:8h CRC_Little-ENDIAN:16h

ID:07627907 FLAGS:ac P:035 T:081 S:1b CHECKSUM:de UNKNOWN:40 CRC_Little-ENDIAN:9cf1

From there, we have the decimal value for Pressure and Temp, and you can find easily the conversion.
Looking into all other device drivers to get the most likely conversion values:

• Pressure = 35 , expected around 103.4 , so 35 * 3 = 105 KPa , divided by 6.895 = 15.22 PSI ; it matches your 15 PSI (round down)
• Temp = 81 , expected 26 , so 81 - 26 = 55 , other device drivers also have this kind of offset.

After, it's coding this into the existing device driver for Abarth 124 Spider.
Looking into your amazon link , I found details about your sensor, the ref is Q85 , the brand is Shenzhen EGQ Cloud ... so I decided to call it "Shenzhen-EGQ-Q85".

The both sensors don't send the same message, one is around 195 bits (72 bits after Manchester decoded), and yours is around 353 bits (96 bits after Manchester decoded). "Around", because it's RF, some times it's longer or shorter (radio interference). But it's useful to define a type and have the good conversion.

Thanks to rtl_433_test, we have older cu8 capture files from the Abarth 124 Spider to be able to replay and compare the both signals. This help me to control that the new version of the device driver from my PR is working for both sensors.

Hope this help to understand how to decode a signal.

[js-3972]

@ProfBoc75 Thank you for the analysis. It seems like having the Abarth-124Spider as a baseline helped a lot with the decoding process. Let's say we had a device signal that was not already decoded. Is the process more of a "brute force" method when decoding the signal, or is there also an intuitive method to do so? I know you have to build a flex decoder and replicate some of the steps you did above, but what happens if you don't already have a decoder to base it off of?

[ProfBoc75]

@js-3972 : Well, in the Wiki part of rtl_433 you have plenty information.
Another starting point is from https://triq.org/ , from Christian @zuckschwerdt , who is the major contributor of rtl_433.

From scratch:

• You need a sensor and its display console, for example, a weather station with a Temp / Hum sensor.
  Most of the time, you have the frequency write down to the station and/or the sensor, to be used during the capture and/or flex decoder with rtl_433 -F frequency or by default it's tuned to 433.920MHz.

• You have to find the modulation, rtl_433 is able to give you useful information with -A option: like the type of modulation OOK/ASK or FSK, the pulse , gap length , the number of pulses and gaps into the frame, but it's limited and not perfect.

• You have to capture several cu8 files to be able to play, replay with the signal without to wait after the sensor to send something.

• Then the cu8 captures can be analyzed also with triq.org tools (Pulse view / iqSpectrogram).

• When you collected enough signal information, you can start to build a flex decoder to get some hexa byte that you need to import into bitbench to play with it. And for sure, you need to compare the byte with the display console of the sensor.

• You need to collect few messages from the sensor, sometime a lot of messages and compare which bytes have changed if the display console changed too, you take some notes into a table with the raw hexa values and the information like the temp and humidity.

• With the weather station example, when the temp changed, which byte into the frame message changed also. And step by step you can build the data layout. which bit or byte corresponds to which information, like temp, battery, pairing, open, close ... any sensor or actuator information.

• Most of the time we have the preamble sync information, then unique ID (fixed or random after battery are replaced), the data information, like temperature, humidity, battery low, ...., then one or more bytes to control the data integrity, like a checksum (cheaper) or a CRC (better). All these kind of information may be in a different order, sometime you have the CRC first then the data for example.

• Then, when you have enough information to decode the signal, you need to write a device decoder, same, at the Wiki page, it's explain how to start writing a decoder. Go to src/devices folder and you have all the decoders you can use to train.

To sum up, it takes a lot of steps to get there, and sometimes you just can't get there. Some requests have been open for months or even years. Experience, knowledge and luck are key : Try, Fail, Try again, Fail better .... , Try again, Success !

[gdt]

I see there is a PR #2558. Is there anything in this issue that is not captured in the source code improvements in the PR? If not, I would prefer to close the issue, on the general concept of progress being issue->PR->code-present-in-master.

[gdt]

PR still open, and no response to feedback