Jansite TPMS model TY-468-eu2.

[Gadgeteering]

The Jansite TPMS currently sold on Amazon does not work with -R 123 and -R 180, it seems to be encrypted using the first 8bits

bitBench

[zuckschwerdt]

Does it need (two-way) pairing with the head unit? That exchange then should have some key. Otherwise those few bits would just be a bad obfuscation.

[Gadgeteering]

There is no two way pairing, I have managed to pair sensors to a different receiver but this required the sensor to be pressurised with the receiver in pairing mode.

It is some sort of encryption/obfuscation similar to #1059 @Tomazzzzz

Jansite TPMS

bitBench

[merbanan]

Can you elaborate exactly how to decrypt the payload? And can you upload some samples also?

You can get one of these to generate the needed pressure:

https://www.biltema.se/fritid/tradgard/tradgardsredskap/trycksprutor/tryckspruta-15-l-2000030676

[merbanan]

What method did you use to figure out the encryption/obfuscation?

[Gadgeteering]

Raw Data from Sensor

'7f 4f 36 7f 7c 93 47 7f', # 20PSI 23C ATTACHED '39 39 84 39 c2 4d 8d 39', ## 20PSI 23C STABLE '6f 5f 50 6f 8c 83 8f 6f', # DETACHED SENSOR '6f 6f 50 6f 8c 83 8f 6f', # DETACHED 0PSI '27 f7 97 27 d4 3b 9f 27',# ATTACHED 20 PSI 14C '71 41 48 71 8a 85 57 71', # 19 PSI 19C '69 69 4f 69 92 7d 63 69', #18PSI 20C '31 31 89 31 ca 45 9f 31', #16PSI 18C '29 29 92 29 d2 3d ab 29', # 15PSI 17C '63 63 59 63 98 77 9b 63', # 0PSI 16C '69 69 4f 69 92 7d 46 69 ', # 28PSI 20C '11 e1 a8 11 ea 25 c3 11' #15 PSI 19C

Data Xor with 1st Byte

0x30 0x49 0x00 0x3 0xec 0x38 0x0 # 20PSI 23C ATTACHED 0x00 0xbd 0x00 0xfb 0x74 0xb4 0x0 ## 20PSI 23C STABLE 0x30 0x3f 0x00 0xe3 0xec 0xe0 0x0 # DETACHED SENSOR 0x00 0x3f 0x00 0xe3 0xec 0xe0 0x0 # DETACHED 0PSI 0xd0 0xb0 0x00 0xf3 0x1c 0xb8 0x0 # ATTACHED 20 PSI 14C 0x30 0x39 0x00 0xfb 0xf4 0x26 0x0 # 19 PSI 19C 0x00 0x26 0x00 0xfb 0x14 0x0a 0x0 #18PSI 20C 0x00 0xb8 0x00 0xfb 0x74 0xae 0x0 #16PSI 18C 0x00 0xbb 0x00 0xfb 0x14 0x82 0x0 # 15PSI 17C 0x00 0x3a 0x00 0xfb 0x14 0xf8 0x0 # 0PSI 16C 0x00 0x26 0x00 0xfb 0x14 0x2f 0x0 # 28PSI 20C 0xf0 0xb9 0x00 0xfb 0x34 0xd2 0x0 #15 PSI 19C

[bitBench] (https://triq.net/bitbench#c=00%2026%2000%20fb%2014%202f%2000%20%20%5B28PSI%2020C%5D&c=30%2049%2000%2003%20ec%2038%2000%20%20%5B20PSI%2023C%20ATTACHED%5D&c=00%20bd%2000%20fb%2074%20b4%2000%20%20%5B20PSI%2023C%20STABLE%5D&c=00%2026%2000%20fb%2014%200a%2000%20%20%5B18PSI%2020C%5D&c=f0%20b9%2000%20fb%2034%20d2%2000%20%20%5B15PSI%2019C%5D&c=00%20b8%2000%20fb%2074%20ae%2000%20%20%5B16PSI%2018C%5D&c=00%20bb%2000%20fb%2014%2082%2000%20%20%5B15PSI%2017C%5D&c=00%203a%2000%20fb%2014%20f8%2000%20%20%5B0PSI%20%2016C%5D&c=d0%20b0%2000%20f3%201c%20b8%2000%20%20%5BATTACHED%2020%20PSI%2014C%5D&c=&c=%5BDifferent%20sensor%5D&c=00%209b%20f5%2041%2070%20fc%200%20%20%5B-15C%5D&c=00%20ba%2027%205e%204e%20e0%2000%20%5B8C%5D&c=&c=%5BDifferent%20sensor%5D&c=&c=&c=00%2039%201b%205e%2032%2020%20%5B21C%2020%20PSI%5D&c=00%203d%207d%205d%20f0%2040%20%5B16C%200%20PSI%5D&c=00%20a6%2000%20fb%2014%20fc%20%5B16C%20Alarm%20Flat%5D&c=00%20a1%20b5%2081%2030%208f&f=FLAG%208h%20TEMP%208d%20b%20ID%2024h%208d%20%20CRC%3A8h%20&cw=4)

[zuckschwerdt]

Looks somewhat plausible, yes. You can get the xor like in this BitBench.

[merbanan]

First the question regarding the message integrity. The first and the last bytes are the same. So this can be used for checking. But what is not obvious is how the first byte is calculated. There must be a rule for that. By looking at the following messages we can see that at least the last value of the message does not affect the selection of the initial xor value.

'69 69 4f 69 92 7d 63 69', #18PSI 20C
'69 69 4f 69 92 7d 46 69', #28PSI 20C

These messages also indicate where the pressure is stored.

0x00 0x26 0x00 0xfb 0x14 [0x0a] 0x0 #18PSI 20C
0x00 0x26 0x00 0xfb 0x14 [0x2f] 0x0 #28PSI 20C

But looking at other messages,

'71 41 48 71 8a 85 57 71', #19 PSI 19C
'11 e1 a8 11 ea 25 c3 11', #15 PSI 19C
0x30 0x39 0x00 0xfb 0xf4 0x26 0x0 #19 PSI 19C
0xf0 0xb9 0x00 0xfb 0x34 0xd2 0x0 #15 PSI 19C

does not show the same pattern.

My opinion is that there is something more at play then just xor of the first/last byte. TPMS devices usually has a 3 byte id, flags, temp and pressure. This payload contains 6 bytes of values which would contain the typical TPMS contents.

I suggest that the id is contained in the first 3 bytes.

'69 [69 4f 69] 92 7d 63 69', #18PSI 20C
'31 [31 89 31] ca 45 9f 31', #16PSI 18C
'29 [29 92 29] d2 3d ab 29', #15PSI 17C
'63 [63 59 63] 98 77 9b 63', #0PSI 16C

The relation that the first byte is the same as the third indicate a deterministic algorithm. Other messages does not follow this pattern but more messages and corresponding readings are missing to clearly indicate a constant pattern.

[sp372]

Hello, I have been reviewing the comments of the different sensors for a few days, I have these TPMS sensors that I bought a few years ago, I have tried to replicate the readings with the configurations for the jansite sensors, which are the closest since they use the infineon sp372 chip however I have not been able to find any matches. I leave the necessary sensor data, what would be the parameters to use the rtl_433 and start uploading readings from my sensors to be able to decode them, thanks https://articulo.mercadolibre.com.mx/MLM-885521300-kkmoon-tpms-sistema-de-monitoreo-de-presion-de-los-neumati-_JM#position=7&search_layout=grid&type=item&tracking_id=cff5def2-7586-41ec-b754-39b1fe42e58e

[zuckschwerdt]

Try to capture a sample https://triq.org/rtl_433/ANALYZE.html We can't otherwise know the timings. Usually for TPMS it would be -X 'n=name,m=FSK_PCM,s=50,l=50,r=150' or -X 'n=name,m=FSK_PCM,s=50,l=50,r=1200' or -X 'n=name,m=FSK_PCM,s=100,l=100,r=300'

[sp372]

command: rtl_433 -S unknown

The file was obtained and analyzed... lecturas rtl_433>rtl_433 -A g009_433.92M_250k[29psi,24c].cu8 rtl_433 version 21.12-108-g5c17e4e3 branch master at 202206100919 inputs file rtl_tcp RTL-SDR SoapySDR Use -h for usage help and see https://triq.org/ for documentation. Trying conf file at "C:\Users\lecturas rtl_433\rtl_433.conf"... Trying conf file at "C:\Users\AppData\Local\rtl_433\rtl_433.conf"... Trying conf file at "C:\ProgramData\rtl_433\rtl_433.conf"... Registered 186 out of 218 device decoding protocols [ 1-4 8 11-12 15-17 19-23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119 121 124-128 130-149 151-161 163-168 170-175 177-197 199 201-215 217-218 ] Test mode active. Reading samples from file: g009_433.92M_250k[29psi,24c].cu8 baseband_demod_FM: low pass filter for 250000 Hz at cutoff 25000 Hz, 40.0 us Detected OOK package @0.195784s Analyzing pulses... Total count: 1, width: 14.81 ms ( 3702 S) Pulse width distribution: [ 0] count: 1, width: 14808 us [14808;14808] (3702 S) Gap width distribution: Pulse period distribution: Pulse timing distribution: [ 0] count: 1, width: 14808 us [14808;14808] (3702 S) [ 1] count: 1, width: 100004 us [100004;100004] (25001 S) Level estimates [high, low]: 12957, 8 RSSI: -1.0 dB SNR: 32.1 dB Noise: -33.1 dB Frequency offsets [F1, F2]: -3716, 0 (-14.2 kHz, +0.0 kHz) Guessing modulation: Single pulse detected. Probably Frequency Shift Keying or just noise... view at https://triq.org/pdv/#AAB10239D8FFFF8155

Detected OOK package @0.688896s Analyzing pulses... Total count: 32, width: 16.56 ms ( 4139 S) Pulse width distribution: [ 0] count: 2, width: 1536 us [1528;1544] ( 384 S) [ 1] count: 14, width: 308 us [308;320] ( 77 S) [ 2] count: 8, width: 432 us [408;508] ( 108 S) [ 3] count: 4, width: 116 us [116;120] ( 29 S) [ 4] count: 2, width: 700 us [700;700] ( 175 S) [ 5] count: 2, width: 212 us [212;212] ( 53 S) Gap width distribution: [ 0] count: 30, width: 76 us [72;84] ( 19 S) [ 1] count: 1, width: 1008 us [1008;1008] ( 252 S) Pulse period distribution: [ 0] count: 3, width: 1512 us [1320;1616] ( 378 S) [ 1] count: 12, width: 388 us [388;396] ( 97 S) [ 2] count: 8, width: 512 us [488;588] ( 128 S) [ 3] count: 4, width: 196 us [196;196] ( 49 S) [ 4] count: 2, width: 780 us [780;780] ( 195 S) [ 5] count: 2, width: 292 us [292;296] ( 73 S) Pulse timing distribution: [ 0] count: 2, width: 1536 us [1528;1544] ( 384 S) [ 1] count: 14, width: 308 us [308;320] ( 77 S) [ 2] count: 8, width: 432 us [408;508] ( 108 S) [ 3] count: 4, width: 116 us [116;120] ( 29 S) [ 4] count: 2, width: 700 us [700;700] ( 175 S) [ 5] count: 2, width: 212 us [212;212] ( 53 S) [ 6] count: 30, width: 76 us [72;84] ( 19 S) [ 7] count: 1, width: 1008 us [1008;1008] ( 252 S) [ 8] count: 1, width: 15444 us [15444;15444] (3861 S) Level estimates [high, low]: 14748, 9 RSSI: -0.5 dB SNR: 32.1 dB Noise: -32.6 dB Frequency offsets [F1, F2]: -4526, 0 (-17.3 kHz, +0.0 kHz) Guessing modulation: No clue...

[sp372]

g009_433.92M_250k[29psi,24c].zip

[sp372]

Hello, the previous one is a preliminary sample before making samples in a massive way, any previous analysis for those who have more experience in the data?

[sp372]

-X n=name,m=FSK_PCM,s=50,l=50,r=150 : without result (without ' ') -X n=name,m=FSK_PCM,s=50,l=50,r=1200 : without result

C:\Users\Desktop\lecturas rtl_433>rtl_433 -X n=name,m=FSK_PCM,s=100,l=100,r=300 rtl_433 version 21.12-108-g5c17e4e3 branch master at 202206100919 inputs file rtl_tcp RTL-SDR SoapySDR Use -h for usage help and see https://triq.org/ for documentation. Trying conf file at "C:\Users\Desktop\lecturas rtl_433\rtl_433.conf"... Trying conf file at "C:\Users\AppData\Local\rtl_433\rtl_433.conf"... Trying conf file at "C:\ProgramData\rtl_433\rtl_433.conf"... Registered 187 out of 218 device decoding protocols [ 1-4 8 11-12 15-17 19-23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119 121 124-128 130-149 151-161 163-168 170-175 177-197 199 201-215 217-218 ] Found Rafael Micro R820T/2 tuner Exact sample rate is: 250000.000414 Hz Sample rate set to 250000 S/s. Tuner gain set to Auto. Tuned to 433.920MHz. Allocating 15 (non-zero-copy) user-space buffers baseband_demod_FM: low pass filter for 250000 Hz at cutoff 25000 Hz, 40.0 us

---

time : 2022-07-02 22:45:09 model : name count : 1 num_rows : 1 rows : len : 4 data : 0 codes : {4}0 ...

[zuckschwerdt]

If you get just that few bits (the {...} part) then it's not working.

The sample you posted is OOK. There is a 15 ms warmup toggeling at 50 µs (i.e. 300 bits). Then two packets with 32 bit preamble each, the data is 120 or 128 bit.

The sample rate of 250k is not enough to capture this signal, you need -s 1000k to get a new sample.

Then -X 'n=name,m=OOK_PCM,s=50,l=50,r=150'

[sp372]

command: rtl_433 -X n=name,m=OOK_PCM,s=50,l=50,r=150 [17psi,22c] shows:

time : 2022-07-03 10:52:51 codes : {157}fffffffedef679e79e679e67ffe7e79bff3cf3c0

time : 2022-07-03 10:52:51 codes : {154}fffffffedef33de7bcde7b3fff3f799ff9e79e0

[zuckschwerdt]

you need -s 1000k -X 'n=name,m=OOK_PCM,s=50,l=50,r=150'

[sp372]

Te command should be : rtl_433 -X n=name, m=OOK_PCM, s= 1000,l=50,r=150 ?

[zuckschwerdt]

rtl_433 -s 1000k -X 'n=name,m=OOK_PCM,s=50,l=50,r=150'

[sp372]

I'll try later

[sp372]

C:\Users\Desktop\lecturas rtl_433>rtl_433 -s 1000k -X n=name,m=OOK_PCM,s=50,l=50,r=150 rtl_433 version 21.12-108-g5c17e4e3 branch master at 202206100919 inputs file rtl_tcp RTL-SDR SoapySDR Use -h for usage help and see https://triq.org/ for documentation. Trying conf file at "C:\Users\Desktop\lecturas rtl_433\rtl_433.conf"... Trying conf file at "C:\Users\ldvs\AppData\Local\rtl_433\rtl_433.conf"... Trying conf file at "C:\ProgramData\rtl_433\rtl_433.conf"... Registered 187 out of 218 device decoding protocols [ 1-4 8 11-12 15-17 19-23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119 121 124-128 130-149 151-161 163-168 170-175 177-197 199 201-215 217-218 ] Found Rafael Micro R820T/2 tuner Exact sample rate is: 1000000.026491 Hz Sample rate set to 1000000 S/s. Tuner gain set to Auto. Tuned to 433.920MHz. Allocating 15 (non-zero-copy) user-space buffers baseband_demod_FM: low pass filter for 1000000 Hz at cutoff 100000 Hz, 10.0 us

---

time : 2022-07-04 21:41:40 model : name count : 1 num_rows : 1 rows : len : 16 data : 45ff codes : {16}45ff

---

time : 2022-07-04 21:41:40 model : name count : 1 num_rows : 1 rows : len : 3 data : 0 codes : {3}0 ...

[sp372]

C:\Users\Desktop\lecturas rtl_433>rtl_433 -s 1000k -X n=name,m=OOK_PCM,s=50,l=50,r=150 rtl_433 version 21.12-108-g5c17e4e3 branch master at 202206100919 inputs file rtl_tcp RTL-SDR SoapySDR Use -h for usage help and see https://triq.org/ for documentation. Trying conf file at "C:\Users\Desktop\lecturas rtl_433\rtl_433.conf"... Trying conf file at "C:\Users\AppData\Local\rtl_433\rtl_433.conf"... Trying conf file at "C:\ProgramData\rtl_433\rtl_433.conf"... Registered 187 out of 218 device decoding protocols [ 1-4 8 11-12 15-17 19-23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119 121 124-128 130-149 151-161 163-168 170-175 177-197 199 201-215 217-218 ] Found Rafael Micro R820T/2 tuner Exact sample rate is: 1000000.026491 Hz Sample rate set to 1000000 S/s. Tuner gain set to Auto. Tuned to 433.920MHz. Allocating 15 (non-zero-copy) user-space buffers baseband_demod_FM: low pass filter for 1000000 Hz at cutoff 100000 Hz, 10.0 us

---

time : 2022-07-04 21:44:31 model : name count : 1 num_rows : 1 rows : len : 3 data : 8 codes : {3}8

---

time : 2022-07-04 21:44:31 model : name count : 1 num_rows : 1 rows : len : 7 data : 90 codes : {7}90

---

time : 2022-07-04 21:44:31 model : name count : 1 num_rows : 1 rows : len : 3 data : 0 codes : {3}0 ...

LIBUSB_ERROR_NOT_FOUND: Entity not found! Check your RTL-SDR dongle, USB cables, and power supply.

WARNING: async read failed (-5). at 25psi,25c C:\Users\Desktop\lecturas rtl_433>

[zuckschwerdt]

That did not work.

Use:

rtl_433 -s 1000k -X 'n=name,m=OOK_PCM,s=50,l=50,r=150,bits>=20'

[sp372]

ahhm, rtl_433 -s 1000k -X 'n=name,m=OOK_PCM,s=50,l=50,r=150,bits>=20' That configuration did not give readings

[sp372]

rtl_433 -s 1000k -X 'n=name,m=OOK_PCM,s=50,l=50,r=150 25psi,26c time : 2022-07-12 18:42:28 model : name count : 1 num_rows : 1 rows : len : 162 data : aaaaaaaa569656969695aa6669aaa96996a956960 codes : {162}aaaaaaaa569656969695aa6669aaa96996a956960

---

time : 2022-07-12 18:42:28 model : name count : 1 num_rows : 1 rows : len : 162 data : aaaaaaaa569656969695aa6669aaa96996a956960 codes : {162}aaaaaaaa569656969695aa6669aaa96996a956960

[sp372]

time : 2022-07-12 19:11:45 model : name count : 1 num_rows : 1 rows : len : 179 data : ffffd55555552b2d2b2d4b5554d5353354aaccab2b2d0 codes : {179}ffffd55555552b2d2b2d4b5554d5353354aaccab2b2d0

---

time : 2022-07-12 19:11:45 model : name count : 1 num_rows : 1 rows : len : 41 data : aaaaaaaa560 codes : {41}aaaaaaaa560

[sp372]

time : 2022-07-12 19:11:38 model : name count : 1 num_rows : 1 rows : len : 162 data : aaaaaaaa565a565a96aaa9aa6a66a9559956565a0 codes : {162}aaaaaaaa565a565a96aaa9aa6a66a9559956565a0

---

time : 2022-07-12 19:11:38 model : name count : 1 num_rows : 1 rows : len : 162 data : aaaaaaaa565a565a96aaa9aa6a66a9559956565a0 codes : {162}aaaaaaaa565a565a96aaa9aa6a66a9559956565a0

---

[zuckschwerdt]

Looks good.

Collect more data in a BitBench like this.

[sp372]

time : 2022-07-14 12:52:15 model : name count : 1 num_rows : 1 rows : len : 306 data : aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa0 codes : {306}aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa0

---

time : 2022-07-14 12:52:16 model : name count : 1 num_rows : 1 rows : len : 162 data : aaaaaaaa566a566a96aaaa5a6a56a9659aa5566a0 codes : {162}aaaaaaaa566a566a96aaaa5a6a56a9659aa5566a0

---

time : 2022-07-14 12:52:16 model : name count : 1 num_rows : 1 rows : len : 162 data : aaaaaaaa566a566a96aaaa5a6a56a9659aa5566a0 codes : {162}aaaaaaaa566a566a96aaaa5a6a56a9659aa5566a0 [22C,15psi]

[sp372]

time : 2022-07-14 12:54:24 model : name count : 1 num_rows : 1 rows : len : 162 data : aaaaaaaa599a599a959a556a66a6aa959955599a0 codes : {162}aaaaaaaa599a599a959a556a66a6aa959955599a0

---

time : 2022-07-14 12:54:24 model : name count : 1 num_rows : 1 rows : len : 162 data : aaaaaaaa599a599a959a556a66a6aa959955599a0 codes : {162}aaaaaaaa599a599a959a556a66a6aa959955599a0

---

22C,18PSI

[zuckschwerdt]

Add that to the BitBench above like:

{162}aaaaaaaa566a566a96aaaa5a6a56a9659aa5566a0[22C,15psi]
{162}aaaaaaaa599a599a959a556a66a6aa959955599a0[22C,18PSI]

But: are those 4 different sensors? All data bits change -- there is no common pattern.

[sp372]

Okay, it's the same sensor let's call it RL and if I'm confused not to see a pattern

[sp372]

https://triq.net/bitbench#c=%7B162%7Daaaaaaaa56a656a69665aa96699aa999999956a60%5B27C%2C19PSI%5D&c=%7B162%7Daaaaaaaa5956aa569655aaa6696aa9a996a659560%5B27C%2C22PSI%5D&c=%7B162%7Daaaaaaaa556a556a9996a95a9556a6659a95556a0%5B28C%2C22PSI%5D&c=%7B162%7Daaaaaaaa56665666969aaa566a5aa959995a56660%5B28C%2C25PSI%5D&c=%7B162%7Daaaaaaaa6956695665aa5aa6596a59a9665969560%5B28C%2C27PSI%5D&c=%7B162%7Daaaaaaaa56665666969aaa566a5aa959995a56660%5B28C%2C25PSI%5D&c=%7B162%7Daaaaaaaa5656565696aaa9a66a6aa6a996a556560%5B28C%2C29PSI%5D&c=%7B162%7Daaaaaaaa659a659a6966596a5aa656956996659a0%5B28C%2C26PSI%5D&c=%7B162%7Daaaaaaaa6a5a6a5a5aa665aa5666655565966a5a0%5B28C%2C23PSI%5D&c=%7B162%7Daaaaaaaa555a555a99a6a6aa9566a6559aaa555a0%5B28C%2C21PSI%5D&c=%7B162%7Daaaaaaaa6a5a6a5a5aa665aa5666655565966a5a0%5B28C%2C23PSI%5D&c=%7B162%7Daaaaaaaa569656969695aa6669aaa96996a956960%5B27C%2C25PSI%5D&c=%7B162%7Daaaaaaaa69a669a665656596569a5a99656669a60%5B27C%2C27PSI%5D&c=%7B162%7Daaaaaaaa65a665a6696659965a9a56996a5565a60%5B26C%2C23PSI%5D&c=%7B162%7Daaaaaaaa5566556699a6a956955aa6599aa655660%5B26C%2C21PSI%5D&c=%7B162%7Daaaaaaaa659a659a696a596a5aa656956aa6659a0%5B26C%2C19PSI%5D&f=7h%208h8h%208h8h%208h8h%208h8h&a=Sync&m=aaa9&d=MC&cw=4

[sp372]

the above readings are from the RL sensor

[zuckschwerdt]

It's the same encryption as the SP372 #1820

[sp372]

I await directions. I don't know how to dump the firmware, I have some experience I made the rgh to an xbox 360 corona plate

[zuckschwerdt]

Best to ask the people at #1820 -- I can't help.

[sp372]

Ok thank you very much

[mhardy6351]

I have the same sensors. I hope for a proper decode as well.

[sp372]

The information found speaks of a change in ID length for the sensor from ID=6 to ID=10. The data sheet has a lot of information I am trying to understand it

[sp372]

[Sp372 data.pdf]datasheet (https://github.com/merbanan/rtl_433/files/9125130/Sp372.data.pdf)

[Gadgeteering]

The receiver uses a sh79F7416 microcontroller this needs a JET51a programmer to reader the firmware so that it can be reverse engineered using the dis51 command.

I think this is the only way to decipher the message transmitted by these sensors.

The transceiver in the unit is a ATMEL ATA5428 which uses 433MHz and 862MHz to 872MHz, so the unit might transmit and receiver

[merbanan]

It seems the F7416 is arm based. Anyway it does not matter. If we can dump the firmware we can figure out the encoding.

While it is clear we can get software for programming the chip the option to extract the code might not be there.

[merbanan]

"Encryption bits and code options can be programmed", this is text from an ad for the JET51a device. So there is a protection bit that most likely is set.

Hacking a mcu is a serious undertaking.

[Gadgeteering]

I have gone back to the drawing board and analysed the signals there seems to be two

rtl_433 -s 1000k -X 'n=name,m=OOK_PCM,s=50,l=50,r=150,bits>=20'

aaaaaaaaaaaa5a565a56955a5a56a5996566a5a65a568 55555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555402d2b4aad2d2b52ccb2b352d32d2b40

[zuckschwerdt]

Manchester decoded that's 3131 8331 ca45 cd31 1 98c1 98e5 22e6 983 or (inverted) cece 7cce 35ba 32ce 0 673e 671a dd19 670 which XORed is 0000 b200 fb74 fc00 1 0059 007d ba7e 001 or (Differential) 5352 8552 5ece 5752 1 a942 a92f 672b a91 XORed 0001 d601 0d9d 0401 1 00eb 0086 ce82 003

Both the same pattern where the first byte suspiciously appears repeated.

[sp372]

Hello then it is already decoded?

[gdt]

@Gadgeteering Where are we on this? I skimmed and it's not clear if there is enough to write even a partial decoder, but I read too fast.. Are you still working on this?