Thermopro TP11

[merbanan]

thermopro11_codes.txt

./revdgst thermopro11_codes.txt Code len is 4 bytes (8 nibbles), 12 codes read. Processing... Done with g a8 k a2 final XOR 44 using xor xor (82 %) Time elapsed in s: 0.04 for: Galois BIT_REFLECT BYTE_REFLECT

Done with g 51 k 04 final XOR 00 using xor xor (100 %) Done with g 51 k 04 final XOR 00 using xor sub (100 %) Done with g 9e k 04 final XOR 00 using xor xor (82 %) Done with g 9e k 04 final XOR 00 using xor sub (82 %) Time elapsed in s: 0.03 for: Rev-Galois BYTE_REFLECT

./revsum thermopro11_codes.txt Code len is 4 bytes (8 nibbles), 12 codes read. Row weights: Max 18 /32 bit (56.2%) Min 12 /32 bit (37.5%) Avg 16.0 /32 bit (50.0%) Processing... Complete message... Found: crc8(&b[0], 3, 0x04, 0x28) ^ b[3] == 0; // (58.3%) Found: xor_shift_bytes(&b[0], 3, 0x02, 0x0a) ^ b[3] == 0; // (58.3%) Found: xor_shift_bytes(&b[0], 3, 0x22, 0x0a) ^ b[3] == 0; // (58.3%) Found: xor_shift_bytes(&b[0], 3, 0x42, 0x0a) ^ b[3] == 0; // (58.3%) Found: xor_shift_bytes(&b[0], 3, 0x62, 0x0a) ^ b[3] == 0; // (58.3%)

100% is better then 58.3%. Can you look into if it is indeed correct?

[merbanan]

data_thermopro12.txt

./revdgst data_thermopro12.txt Code len is 5 bytes (10 nibbles), 4 codes read. Processing... Time elapsed in s: 0.01 for: Galois

Time elapsed in s: 0.02 for: Galois BYTE_REFLECT

Time elapsed in s: 0.01 for: Galois BIT_REFLECT

Time elapsed in s: 0.02 for: Galois BIT_REFLECT BYTE_REFLECT

Time elapsed in s: 0.01 for: Rev-Galois

Done with g 51 k 04 final XOR 00 using xor xor (100 %) Done with g 51 k 04 final XOR 00 using xor sub (100 %) Done with g 6b k 4a final XOR 1d using xor xor (100 %)

[zuckschwerdt]

Oh, same gen twice, this really looks like something.

[merbanan]

Yupp, it should fix this issue: https://github.com/merbanan/rtl_433/issues/1231 and I'll fix the rubicson code that I don't understand why I didn't do myself.

[merbanan]

The amount of codes are not alot but it is the same integrity algorithm check for 2 different sensors with similar sounding names.

[zuckschwerdt]

The key list is

./keylst -g 51 -i 4 -G -r
04 08 10 20 40 80 51 a2 15 2a 54 a8 01 02

which is also mentioned in the code already. Rev-Galois BYTE_REFLECT does sound strange but there is a recent sensor that also used the LFSR "right to left". So it looks plausible enough.

[merbanan]

04 08 10 20 40 80 51 a2 15 2a 54 a8 [00 00] Last 2 bytes differ.

[zuckschwerdt]

I suspect that's just not fully analyzed in the decoder. The zeros and then some random entries don't seem right. The gen in your example would have run fine with the full sequence just repeating.

[zuckschwerdt]

It's a pretty bad example of a Galois gen anyway, I'd give it 14/255 points ;)