Decoder protocol 123 not working for my Jansite external TPMS sensors

[riegelbrau]

Hallo team, many thanks for this exciting project! I am using it already for several temperature and humidity sensors from Klimalogg and others. That is working well! For my home brewing equipement I'm trying to build a fermentation pressure monitoring setup, like Andreas Spiess showed in his videos (very cool project!). So I bought the same Jansite TPMS sensors that Andreas referenced in issue #1007. They display their values on the included car unit, but I am not able to receive any signals with rtl_433 to get the decoded information. So I appreciate any help. I put one TPMS sensor in a pressure chamber to force sensor value changes, I gathered some data using the parameters from #1007 and uploaded the files here. Please respond if I should run special commands.

Thanks in advance.

TPMS_out.txt Jansite_different.OOK.txt

[zuckschwerdt]

Your collection of codes looks good, the OOK shows the same 52µs timing with MC data. But the codes seem longer: 82 bit instead of the expected 56. To understand the codes table them in a BitBench along with values from the display, then hunt for the values in the codes.

[riegelbrau]

I tried to play around with this BitBench, which is totally new for me. I'm working in the computer business since 45 years but more in the area of business applications. Nevertheless it looks as if I figured out the position of the pressure value: BitBench But the position of the temp value does not fit.

[zuckschwerdt]

Great, so pressure is in kPa with one decimal (you could write it as integer hPa or bar with 3 decimals, but kPa is the usual unit on TPMS) -- 12 bit is a big range, usually we only see 8 bits, the last 4 bits could be something else with a scaling of 1.6, which seems odd. 12 bits for temperature also seem big, we usually only see 8 bits. Did you try to match a range of temperatures? ID for TPMS is usually 7 or 8 nibbles (hex-chars). I wouldn't expect there to be any channel indication as there is no switches for that, right? But there should be some status bits, usually battery, idle/startup, rapid pressure loss warning, … I expect 8 bits checksum at the end but there is not enough randomness here, perhaps the checksum is a little more to the left with garbage in the last bits then.

[iDoka]

@riegelbrau If it help, there is definitely pressure:

For confident detecting ID position (including length) need physical access to sensor. ID printed/engraved on TPMS sensor.

[iDoka]

Right now I'm try to reveal TPMS protocol similar to Jansite TPMS sensors and found at least one issue in src/devices/tpms_jansite.c

https://github.com/iDoka/rtl_433/commit/37045c0351173fc40493e634286795d6dd2a69fe

[zuckschwerdt]

Jansite TPMS sensors and found at least one issue in src/devices/tpms_jansite.c

Yes, looks good. Do you want to PR this change?

[iDoka]

@zuckschwerdt sure https://github.com/merbanan/rtl_433/pull/1538

[riegelbrau]

Thanks for the further information. But how is x'fb', which is 191 in decimal, calculated into the visible 2.0 bar? 191 kPa = 1.91 bar, but not 2.0. Do these devices have a tricky rounding formula?

[riegelbrau]

I shifted the bits a little: BitBench

[riegelbrau]

I took a second sensor into the test and took two photos from the new RR sensor. I have no idea what the ID could be; The position of the pressure value that @iDoka mentioned looks correct. Only minimal differeces are corresponding to the same pressure from my display.

Here is my actual BitBench 2 sensors

[merbanan]

We need more readings. Permute among the sensors under similar conditions (same temp and pressure). Then take one sensor and place it in the fridge. We need to monitor messages that only differ with one parameter and in small increments.

[merbanan]

The Aliexpress link in issue #1500 indicate that the sensor is a frescale chip as it looks exactly the same. It looks like there is an accelerometer by looking at the image. Thus some of the unknown bits are probably acceleration.

[merbanan]

Ok, it was not Freescale but Infineon https://www.slideshare.net/Yole_Developpement/infineon-sp37-tire-pressure-monitoring-sensor.

[merbanan]

This might be relevant:

https://www.mouser.com/PCN/Infineon_c03020.pdf

[merbanan]

https://media.digikey.com/pdf/PCNs/Infineon/131-14.pdf

[merbanan]

https://www.mouser.com/datasheet/2/196/SP37_450kPa_PB-776958.pdf https://nl.mouser.com/datasheet/2/196/infineon_infn-s-a0004843326-1-1749619.pdf https://docplayer.net/101326742-Tpms-sp37-rom-library-function-guide-sense-control-tire-pressure-monitoring-sensor.html https://www.infineon.com/export/sites/default/cn/product/promopages/ATV_Symposium/China_ATV_Symposium_TPMS.pdf

[merbanan]

So from skimming trough all this we know there is a rom lib crc8 function and a hardware crc16 block. If there is any message integrity check in the payload it is likely one of those are used. Each chip has a 32 bit individualisation area. 26 bits seem to form a unique id (which may be what we observe in the massage payload), There are temperature, pressure, acceleration and voltage sensors on the chip. Most likely only temp and pressure are sent over the air. Acceleration is supposed to trigger a periodic start of transmission and the voltage sensor is supposed to control the battery bit in the message payload.

If you look at the one of the development kits you can see what can be sent. https://www.infineon.com/dgdl/Infineon-SP37_LF_Initiator_Kit-PB-v1.0-en.pdf?fileId=db3a30434521785c014521f61df4001e

Anyway this does not mean this is actually sent in this case, it just show what can be present. The rom library documentation mentions a standard VDA 391 - Tire Pressure Sensor that all sensors seem to comply with. That document might contain some interesting things also.

[merbanan]

Microchip has an application note that might contain some interesting stuff to read. http://ww1.microchip.com/downloads/en/AppNotes/00238C.pdf

[merbanan]

The SP37 rom library function Read_ID() returns a 4 byte id and a 1 byte product code.

Scale_Pressure(): A 450 kPa range TPMS sensor will typically transmit the pressure value as a single byte within an RF telegram: the pressure range 100…450 kPa is represented with an unsigned byte ranging from 0…255. A scale factor of 1.373 kPa/LSB is required to meet this typical requirement. The SP37 Meas_Pressure function, however, returns a signed integer value that represents pressure as 1/16 kPa/LSB. Conversion from 1/16 kPa/LSB to 1.373 kPa/LSB is therefore a commonly required task, but one that is not straightforward as care must be taken to avoid excessive rounding or loss of precision. The full scale error (FSE) of this function is less than 0.4%. As a convenience, this Scale_Pressure( ) function performs this conversion. In addition, pressure bounds checking is performed so that 0 and 255 are returned for input pressure values below 100 kPa and above 450 kPa, respectively.

Meas_Temperature() returns 16 bits of signed temp: 8000H = -256.0 °C 0000H = 0.0 °C 7FFFH = 255.9921875 °C ( = 256 °C - 1 LSB where 1 LSB = 1/128 °C)

I think you can just take the most significant byte and get rid of the decimal values. And by that you get a 8-bit temperature value. I con't find it in the payload though. I think we need more readings.

[riegelbrau]

Thanks a lot Benjamin!!

I hope to come back with more readings during weekend.

Regards Christoph

Am 30. Oktober 2020 00:29:02 schrieb Benjamin Larsson notifications@github.com:

The SP37 rom library function Read_ID() returns a 4 byte id and a 1 byte product code.

Scale_Pressure(): A 450 kPa range TPMS sensor will typically transmit the pressure value as a single byte within an RF telegram: the pressure range 100…450 kPa is represented with an unsigned byte ranging from 0…255. A scale factor of 1.373 kPa/LSB is required to meet this typical requirement. The SP37 Meas_Pressure function, however, returns a signed integer value that represents pressure as 1/16 kPa/LSB. Conversion from 1/16 kPa/LSB to 1.373 kPa/LSB is therefore a commonly required task, but one that is not straightforward as care must be taken to avoid excessive rounding or loss of precision. The full scale error (FSE) of this function is less than 0.4%. As a convenience, this Scale_Pressure( ) function performs this conversion. In addition, pressure bounds checking is performed so that 0 and 255 are returned for input pressure values below 100 kPa and above 450 kPa, respectively.

Meas_Temperature() returns 16 bits of signed temp: 8000H = -256.0 °C 0000H = 0.0 °C 7FFFH = 255.9921875 °C ( = 256 °C - 1 LSB where 1 LSB = 1/128 °C)

I think you can just take the most significant byte and get rid of the decimal values. And by that you get a 8-bit temperature value. I con't find it in the payload though. I think we need more readings.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[riegelbrau]

Hallo, now I tried to get the same data from all 4sensors I have, but it was not so easy, because they seem to have different sensitivity. The latest rows from the 17:31 timestamp had all 0,1 bar but still 2 different temperatures: FL: 22 C FR: 22 C RL: 23 C RR: 23 C Pleas find the complete readings in TPMS_out_4sensors_20201101.txt and the extracted data with comments in TPMS_out_4sensors_20201101_data.txt: TPMS_out_4sensors_20201101.txt TPMS_out_4sensors_20201101_data.txt

From the previous information given, I tried to find the product code that might be 10 (x'a') or 13 (x'd') but I only found x'a' and x'c' as a recurring code directly after the prefix x'99'. And even the following 2 fix bits '11' I cannot find for all entries. May be I'm totally wrong.

Should I open the orther sensors to see if they have a different chip?

Regards Christoph

[enavarro222]

Hi,

I just spend few times to test and capture some records from Jansite external TPMS I recieved last week.

Everything looks similar to currently implemented protocol but it doesn't perfectly match. Here it an exemple:

$ rtl_433 -X 'n=name,m=FSK_PCM,s=50,l=50,r=1000,g=108,t=19,y=0'  g004_433.92M_250k.cu8
...
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : @1.429496s
model     : name         count     : 1             num_rows  : 1             rows      : 
len       : 435          data      : 555555555555555555555555555555555555555555555555555555555555555553532d2d2b4acb34aaaaaaaab32cab332aaad52d35328
codes     : {435}555555555555555555555555555555555555555555555555555555555555555553532d2d2b4acb34aaaaaaaab32cab332aaad52d35328
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : @1.429496s
model     : name         count     : 1             num_rows  : 1             rows      : 
len       : 1            data      : 8
codes     : {1}8
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : @1.470992s
model     : name         count     : 1             num_rows  : 1             rows      : 
len       : 435          data      : 555555555555555555555555555555555555555555555555555555555555555553532d2d2b4acb34aaaaaaaab32cab332aaad52d35328
codes     : {435}555555555555555555555555555555555555555555555555555555555555555553532d2d2b4acb34aaaaaaaab32cab332aaad52d35328
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : @1.470992s
model     : name         count     : 1             num_rows  : 1             rows      : 
len       : 1            data      : 8
codes     : {1}8

I haven't much free time for that right now, but I guess this record may help someone else... I'll try to make better records with know P and T values, and to upload all that.

[merbanan]

I am pretty sure the payload is scrambled. I don't see an easy pattern.

[riegelbrau]

Today I tried to get some readings from only the FL sensor coming out of the fridge. First I got some data, but later only the display showed changes, but not the rtl_433 tool. I changed the position of the sensor, but also no data was received. The whole thing looks rather strange...

Just for safety, this is the command I used for the readings: rtl_433 -R 0 -X n=TPMS,m=FSK_MC_ZEROBIT,s=50,l=50,r=1000,preamble=ffee The tpms.conf I use is attached, too. tpms.conf.txt Please double check, if I should change something.

[zuckschwerdt]

From what I see it looks good, strange indeed. To get an output again, try in order:

• remove preamble=ffee
• use m=FSK_PCM
• use just -A

Let us know what turns out to work.

[riegelbrau]

From what I see it looks good, strange indeed. To get an output again, try in order:

* remove `preamble=ffee`

* use `m=FSK_PCM`

* use just `-A`

Let us know what turns out to work.

I ran these 3 steps only with the FL sensor, which might have the ID af289562 without noting display output in parallel. May be this helps already to see what's going over the air. TPMS_out_withoutPreamble.txt TPMS_out_FSK_PCM.txt TPMSout-A.txt Does anybody know, how to switch out the alarm beep of these Janitse sensors?

[riegelbrau]

Just to double check the chip, I opened another sensor, the FR propably with code c5475a0c. It seems to be the SP372 chip like the first with only different other codes.

[zuckschwerdt]

Oh, the MC slicer is acting up there. The original codes (PCM):

codes     : {433}8aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa6a65a5a66a966565999a56665a65a5a5555656565558
codes     : {433}aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa6a65a5a66a966565999a56665a65a5a5555656565558
codes     : {433}8aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa6a65a5a66a966565999a56665a65a5a5555656565558
codes     : {433}8aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa6a65a5a66a966565999a56665a65a595555a559655a8
codes     : {433}aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa6a65a5a66a966565999a56665a65a595555a559655a8
codes     : {433}aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa6a65a5a66a966565999a56665a65a595555a559655a8
codes     : {433}aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa6a65a5a66a966565999a56665a65a595555a559655a8
codes     : {445}8aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa6a65a5a66a966565999a56665a65a595555a559655a0000
codes     : {433}aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa6a65a5a66a966565999a56665a659a65555555565558
codes     : {433}aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa6a65a5a66a966565999a56665a65995555556a965558
codes     : {433}8aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa6a65a5a66a966565999a56665a6595a55559965655a8

get badly sliced as:

{217}000000000000000000000000000000001d335e512ac54d50040e5e8
{218}7fffffffffffffffffffffffffffffffee99af289562a6a802072f4
{218}7fffffffffffffffffffffffffffffffee99af289562a6a802072f4
{216}000000000000000000000000000000003a66bca2558a9a9400a48d
{217}000000000000000000000000000000001d335e512ac54d450070468
{217}000000000000000000000000000000001d335e512ac54d40006e468
{217}000000000000000000000000000000001d335e512ac54d3a0072408
{217}000000000000000000000000000000001d335e512ac54d3a0072408
{216}000000000000000000000000000000003a66bca2558a9a7400e481
{216}000000000000000000000000000000003a66bca2558a9a6a00a081
{217}000000000000000000000000000000001d335e512ac54d30004e408
{216}000000000000000000000000000000003a66bca2558a9a56002881
{216}000000000000000000000000000000003a66bca2558a9a4c017487
{216}000000000000000000000000000000003a66bca2558a9a44004481

This is somewhat expected as the leading aa (i.e. 10101010) can't fully align the symbols, only a long pulse/gap can. I'll try to test and implement some fix.

[riegelbrau]

I created a new set of files like before using the newest build 202011101522: TPMSout-A_20201110.txt TPMS_out_FSK_PCM_20201110.txt TPMS_out_withoutPreamble_20201110.txt

Regards Christoph

[zuckschwerdt]

Only PCM is needed. MC won't work directly because of the flaky preamble -- I need to come up with a way to maybe fix that.

The problem is this: if we see aa..aa that could either be MC for 0..0 or 1..1.

• If we have only clean aas then the first few data bits will decide the 0/1 case and all is well.
• But if something other is before the aas then that will decide the 0/1 ambiguity. This might work out half the time but if the guess is bad then we'll abort and restart the MC on the first few data bits and thus not see a valid preamble. Not sure what to do about that -- we can't just guess to randomly drop bits from the beginning.

Likely we need to read PCM and then do the MC in the decoder only after matching the sync (ffee).

Captured (PCM) are 3 codes (the fourth is broken)

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa6a65a5a66a966565999a566659969aa556555a55a561
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa6a65a5a66a966565999a566659a69a6555595555aa91
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa6a65a5a66a966565999a566659a69a5555555695aa61
2aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabeaaaaaeaeaaaaaaaaaaeaaaaaaaaeaa6a65a5a67a966565999a566759e69aa555555a55aa61

that decode (MC) to

f..f74cd7944ab1529bc1030c1
f..f74cd7944ab152db40200f2
f..f74cd7944ab152db00018f1

[zuckschwerdt]

Your best bet for now is to collect the PCM codes, drop them in a BitBench like this (sync to aaa6 and MC). Then try to match the value you expect with the bytes you see there.

[riegelbrau]

Hi everyone, I created a few more readings and tried to catch the corresponding timestamp using my mobile cam. See the data here in BitBench. When this is decoded with PREF:8h PRODCODE:bbbb FIXED:bb IDCODE:26d -- DATA:8h 8d 8d 8d 24h, the 4th data column marked in the screenshot shows decimal values from 132 decreasing to 036: When I multiply this by 16 following this documentation, I get values from 2.112 decreasing to 576 kPA which corresponds to 2.1 to 0.5 approximately:

Microchip has an application note that might contain some interesting stuff to read. http://ww1.microchip.com/downloads/en/AppNotes/00238C.pdf The SP37 rom library function Read_ID() returns a 4 byte id and a 1 byte product code. Scale_Pressure(): A 450 kPa range TPMS sensor will typically transmit the pressure value as a single byte within an RF telegram:

• the pressure range 100…450 kPa is represented with an unsigned byte ranging from 0…255. A scale factor of 1.373 kPa/LSB is required to meet this typical requirement. The SP37 Meas_Pressure function, however, returns a signed integer value that represents pressure as 1/16 kPa/LSB. Conversion from 1/16 kPa/LSB to 1.373 kPa/LSB is therefore a commonly required task, but one that is not straightforward as care must be taken to avoid excessive rounding or loss of precision. The full scale error (FSE) of this function is less than 0.4%. • As a convenience, this Scale_Pressure( ) function performs this conversion. In addition, pressure bounds checking is performed so that 0 and 255 are returned for input pressure values below 100 kPa and above 450 kPa, respectively. Meas_Temperature() returns 16 bits of signed temp: 8000H = -256.0 °C 0000H = 0.0 °C 7FFFH = 255.9921875 °C ( = 256 °C - 1 LSB where 1 LSB = 1/128 °C) I think you can just take the most significant byte and get rid of the decimal values. And by that you get a 8-bit temperature value. I con't find it in the payload though. I think we need more readings. From merbanan's post above.

Second decoding was like this: PREF:8h PRODCODE:bbbb FIXED:bb IDCODE:26d -- DATA:8h 8h 16d 24h. Then I get a 3rd data column with values near the temerature in Celsius: Here is the original readings file and the file with the subset, that I analyzed: TPMS_out_FL_PCM_20201202.txt TPMS_out_FL_PCM_20201202_analyze.txt May by someone can check my findings to see if I am on the right trace. Thanks for all input! Regards Christoph

[mattiad83]

Hello to everyone, i'm intrested of this project and i have the same issue with Jansite sensor. I'm not an expert in decoding but if i can help by providing packet capture i do it. Thanks a lot. Bye

[mattiad83]

Hello, nobody is interested? news on decoding Jansite? thanks

[pconroy328]

Stumbled across this link. They've made progress decoding:

https://habrahabr.info/development/reverse-engineering/14173-study-of-the-protocol-of-the-vehicle-tire-pressure-monitoring-system-tpms-habr.html

[merbanan]

I bought a Jansite Solar TPMS sensor set.

rtl_433 -X 'n=name,m=FSK_PCM,s=50,l=50,r=700,g=0,t=0,y=0,unique'

BitBench

This is the same payload as @enavarro222 posted. This is not encrypted it just uses differential manchester. So far 8 bits looks like it is temperature.

[merbanan]

BitBench

[merbanan]

So it is ordinary manchester coding. The temperature and pressure values are located. There seem to be more bits for pressure sent. Maybe also for temperature, sometimes the receiver output differs from the observed bit stream.

[merbanan]

Some rounding is applied.

[merbanan]

In some cases the temperature is off by one from the observed receiver display value. The temperature offset of 55 seems bogus. But if the maybe that is correct. I need to observe low temperatures. The crc/checksum has not been investigated yet.

FIX:hhhh ID:hhhhhh UnkA: hh TEMP: d BAR: hh UnkB:hh hhhh

This above layout with A6A as sync looks good. Temp offset of 55. Guess it is time for a decoder now...

BitBench

[riegelbrau]

Looks good, this progress! Thanks for your engagement! I can help with testing. Regards

[merbanan]

This decoder works for this device:

https://www.amazon.se/gp/product/B07F74KV86/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1

The protocol is very similar to the other Jansite protocol.

[merbanan]

filtered_codes.txt

Ca 400 messages. The last 2 bytes looks like the crc. I noticed the following:

[00] {88} dd 33 1f b2 00 00 51 21 00 2c 1f
[00] {88} dd 33 1f b2 00 00 51 22 00 26 1f

A difference in one byte and one of the suspected crc bytes resulted in the same last byte. So we might have 2 checksum bytes with different algos. I also observed lots of bogus readings, I don't think I got rid of all of them.

[merbanan]

Another pattern that emerges is that these 2 positions are correlated.

dd 33 1f b2 00 00 5(1) 9e 00 2e [1]6 
dd 33 1f b2 00 00 5(2) 02 00 66 [2]0 

For all messages from the same sensor id the ()->[] mapping is the same. Another sensor has another mapping but it is still fixed.

[freundm]

I plugged some of my own readings into RevEng, i.e. ./reveng -w 16 -s 11bf00004f00003d68 11bf00004f00003d68 11bf00004f00003d68 11bf00004f00003d68, and it spit out CRC-16/UMTS as the algorithm with the input being bytes 2 through 8 of the data.

I used a CRC calculator to confirm this and it works for the data in the previous two posts from @merbanan. This calculator refers to the algorithm as CRC-16/BUYPASS.

• 1f b2 00 00 51 21 00 = 2c 1f
• 1f b2 00 00 51 22 00 = 26 1f
• 1f b2 00 00 51 9e 00 = 2e 16
• 1f b2 00 00 52 02 00 = 66 20

[merbanan]

/reveng -w 16 -s 1fb20000507c00620e 1fb200005227003823 a6d8000050420064f2 db150200501100ac14 width=16 poly=0x8005 init=0x0000 refin=false refout=false xorout=0x0000 check=0xfee8 residue=0x0000 name="CRC-16/BUYPASS"

Looks correct.

[merbanan]

Candidate PR sent, I will commit in a few days. And supply some signal samples.

[merbanan]

Code merged with 753f3a5, closing issue.

[riegelbrau]

It's working like a charm for my sensors, too. I kept my conf untouched except the enablement of decoder 180. The sample rate is still on 1536k because of my TFA Klimalogg sensors. With these settings I also get the data form the Jansite TPMS sensors. Good job from all participants! Many thanks! Regards riegelbrau/Christoph

[mattiad83]

Hello, i confirm that work well (using Jansite TY-568-FBA-EU5) with decoder 180. Now i have buy another kit of Jansite TPMS model TY-468-eu2. This sensors aren't decoded :( . Someone can help me to try to decode? I start from 0 in decoding. Any suggestion are apreciated. Thanks a lot.