Help decoding TPMS with SP372 ASK

flambert860 commented 3 years ago

So I have been trying the last days to decode a tpms sensor, similar to the jansite but it does not use fsk till what I can see.

I have not been able to detect the Id from the bits, it seems it's manchester but I am not that familiar with 433Mhz yet. Observations so far is that it seems to send a wakeup call first, then it sends two packets with the same data, which starts with a preamble(10101010101010101010101010101010)

Data: https://triq.org/pdv/#AAB10705D0007000CC01C8004C03D03A748494A4A494A4A494A4A4A4A4B494B4B494A49494A4A58494A4A494A4A494A4A4A4A4B494B4B494A49494A4A65 raising sensor 1 n 2 5 samples sensor 1 n 2 raising with ask .txt

zuckschwerdt commented 3 years ago

The pdv data does not look like MC and it's too few bits. Can you upload a zip of a cu8 sample capture (-S unknown)?

flambert860 commented 3 years ago

Yea sure, these are the samples with command "rtl_433 -d 0 -f 433.92M -A -S unknown" the Pressure should be falling. samples.zip

zuckschwerdt commented 3 years ago

There is too much gain, the signal is clipping. Can you put more distance to the antenna, or remove the antenna and put the sensor at 10-30 cm -- that will get rid of noise. Also the signal is nearly centered, not ideal. Best if you record at 1M sample rate and tune away, e.g. -f 434M -s 1M

flambert860 commented 3 years ago

Okay, have moved the sensor futher away, my mistake thought it would have a more clear reading close by. command "rtl_433 -d 0 -f 433.92M -s 1M -S unknow samples2.zip n"

zuckschwerdt commented 3 years ago

Much better. The data is 50 µs half-bit time, MC. https://triq.org/pdv/#AAB0480401002F005E03DB2711808080808080808080808080808080818080919191808091919081809080808080808081918080809190818090819190818090818091808080808091919255+AAB0480401002F005E03DB2711808080808080808080808080808080818080919191808091919081809080808080808081918080809190818090819190818090818091808080808091919355

This will get you the decoded data rtl_433 -s 1M -R 0 -X 'n=name,m=OOK_MC_ZEROBIT,s=50,l=50,r=130'

Here is a BitBench aligned on the 0x73 seen in most rows. E.g. {80}0000 7363 4146 fb0a 8b73 and {80}0000 7373 431d 1ff6 8b73

zuckschwerdt commented 3 years ago

Next step is to ramp the pressure while recording the data codes. If you don't already have a setup for this, the small pressured spray bottles work nicely (if the diameter fits the sensor) https://www.amazon.com/s?k=pressure+spray+bottle

flambert860 commented 3 years ago

Am I doing something wrong? my data lokes kinda weird, and when I try to paste it into bitlength I just get "1" or "3" test.txt

zuckschwerdt commented 3 years ago

That looks ok. Turn of the "Align". I was just guessing the 73, seems not all rows have that. The start of a good code should be 0000 or 7fff (the 07ff seen is also ok if the length is still ~80 bits) -- the initial bits are ambiguous in MC.

flambert860 commented 3 years ago

Hey again, first of all thanks for taking your time to help me out. If I remove the align the data from yesterday seems kinda weird, and I am not able to detech any patterns. https://triq.net/bitbench?c=%5Bfrom%20yesterday%5D&c=%7B80%7D7fffee6c6828df61516e6&c=%7B80%7D000073634146fb0a8b73&c=%7B80%7D7fffee6c6828df61516e6&c=%7B80%7D000073634146fb0a8b73&c=%7B80%7D7fffb9b9a18e8ffb45b98&c=%7B80%7D00007373431d1ff68b73&c=%7B80%7D7fffdcd8d051bec2a2dcc&c=%7B80%7D000073634146fb0a8b73&c=%7B80%7D7fffdcd8d051bec2a2dcc&c=%7B80%7D000073634146fb0a8b73&c=%7B80%7D7fffffdcd8d051bec2a2dcc&c=%7B80%7D000073634146fb0a8b73&c=%5Bsensor%202%5D&c=%7B80%7D000017e79cc17b9ade17&c=%7B80%7D0000232390cd6fa6ca23&c=%7B80%7D00001b1b98c5779eca1b&c=%7B80%7D0000414172eb51c49d41&f=8h&a=Sync&m=&cw=4

zuckschwerdt commented 3 years ago

If you use just v as format string you can see the bits with more contrast. The "yesterday" rows are all the same (some shifting and the initial 0000 vs ffff). The "sensor 2" rows don't look like that. There could be noise in the received bits, currently our MC decode isn't too smart and might hide decoding problems. Try perhaps rtl_433 -s 1M -R 0 -X 'n=name,m=OOK_PCM,s=50,l=50,r=130' to get raw data. There will be long preambles of fff, then aaa (or 555, same thing just shifted). Use rtl_433 -s 1M -R 0 -X 'n=name,m=OOK_PCM,s=50,l=50,r=130,preamble=aa9' to demand alignment on a bit pattern of 10101001 (aa9) -- that alignment is perfect for MC, copy to BitBench and use "Coding", inspect. Note that you are now missing the first MC bit 01. Here is a BitBench with a format string that corrects for that.

flambert860 commented 3 years ago

I am not sure what I am doing wrong, did some more messurements but can't find any field which could be the ID since they always seems different: bitBench

zuckschwerdt commented 3 years ago

The codes look flawless. The actual data is strange. Could this be a sensor that encrypts data for privacy?

flambert860 commented 3 years ago

I have also thought if it was some kind of encryption, but it's just a cheap chinese tpms sensor Imars t240, the receiver is an atA5754

flambert860 commented 3 years ago

Do we have any way how we could figure out how to decrypt it?

merbanan commented 3 years ago

Can you give some info about the sensors?

flambert860 commented 3 years ago

Sure, they are as said TPMS sensors, I bought a pack from banggood with 4 sensors and receiver, the receiver displays temparature and pressure, it sends data when the pressure changes. The sensor has a SP372 IC and the receiver uses an atA5754. Sadly I do not know much more than that. Banggood link to what I bought

flambert860 commented 3 years ago

Does anyone have an idea?

zuckschwerdt commented 3 years ago

The data looks random, but not perfect entropy, some patterns remain. E.g. the first and last byte look related. And e.g. these are mostly the same

3929 7be3 59bc b439
4939 6bf3 49cc b149

I'd guess some weak xor encryption. If you try to xor with the first byte there seem to more 0's (i.e. the second byte and last byte are almost the same as the first...) E.g. the two lines above yield

0010 42da 6085 8d00
0070 22ba 0085 f800

that's closer to what we expect from sensor data.

flambert860 commented 3 years ago

But even if it was xor, wouldn't there then be a pattern where some bytes would be the same for the id? or would it have some kind of shifting aswell?

merbanan commented 3 years ago

It could be a whitening pattern or scrambling. But we need a good set of messages and their corresponding reading. Right now I have only seen like 10 messages and I don't know if it is from different sensors or now. We need more signals and more details to be able to figure out things. I would say that we need like 100 different messages from a single sensor.

flambert860 commented 3 years ago

I will try go create a lot of msgs, so far I have done messages from 2 sensors, if you here you see examples of two sensors. But I will try to create more examples

flambert860 commented 3 years ago

would this cmd ""rtl_433 -d 0 -f 433.92M -s 1M -S unknown" be the best to record the many samples?

zuckschwerdt commented 3 years ago

rtl_433 -s 1M -R 0 -X 'n=name,m=OOK_PCM,s=50,l=50,r=130' and then we just needs the codes.

zuckschwerdt commented 3 years ago

Oh, and when copying codes do keep aa or 55 in the front, those are needed to sync. Or is that data captured with ,preamble=aa9? Then add that back to all codes so we know.

flambert860 commented 3 years ago

Is it possible to filter out the empty ones:

time : 2021-10-09 11:53:07 model : name count : 1 num_rows : 1 rows : len : 2 data : 0 codes : {2}0

time : 2021-10-09 11:53:08 model : name count : 1 num_rows : 1 rows : len : 2 data : 0 codes : {2}0

time : 2021-10-09 11:53:08 model : name count : 1 num_rows : 1 rows : len : 305 data : aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa0 codes : {305}aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa0

time : 2021-10-09 11:53:08 model : name count : 1 num_rows : 1 rows : len : 2 data : 0 codes : {2}0

time : 2021-10-09 11:53:08 model : name count : 1 num_rows : 1 rows : len : 161 data : aaaaaaaa569a559a9699a5666a6a96a9a959569a0 codes : {161}aaaaaaaa569a559a9699a5666a6a96a9a959569a0

time : 2021-10-09 11:53:08 model : name count : 1 num_rows : 1 rows : len : 2 data : 0 codes : {2}0

time : 2021-10-09 11:53:09 model : name count : 1 num_rows : 1 rows : len : 2 data : 0 codes : {2}0

time : 2021-10-09 11:53:10 model : name count : 1 num_rows : 1 rows : len : 2 data : 0 codes : {2}0

time : 2021-10-09 11:53:11 model : name count : 1 num_rows : 1 rows : len : 2 data : 0 codes : {2}0

zuckschwerdt commented 3 years ago

Yes, `rtl_433 -s 1M -R 0 -X 'n=name,m=OOK_PCM,s=50,l=50,r=130,bits>=100'

flambert860 commented 3 years ago

here is one sensors output, around 80 valid data packages sensor-a.txt

zuckschwerdt commented 3 years ago

Here those codes to poke around in BitBench:

``` aaaaaaa99a599a599a6955696a5a9a9655559a58 aaaaaaaa66966696669a555a5a96a6a595556696 aaaaaaaa565a565a99569aa66aaa96699a9a565a aaaaaaaa565a565a99569aa66aaa96699a9a565a aaaaaaaa65a665a6696aaa6a6566a6556aa665a6 aaaaaaaa65a665a6696aaa6a6566a6556aa665a6 aaaeaaaa656a656a69a6aa56659aa5996a9a656a aaaaaaaa656a656a69a6aa56659aa5996a9a656a aaaaaaaa5aa65aa66a6aa96a6666a555965a5aa6 aaaaaaaa5aa65aa66a6aa96a6666a555965a5aa6 aaaaaaaa66a666a6666a556a5a66a955956a66a6 aaaaaaaa66a666a6666a556a5a66a955956a66a6 aaaaaaaa65965a96699aaa5a6596a5a599a96596 aaaaaaaa65965a96699aaa5a6596a5a599a96596 aaaaaaaa5aa659a66a6aa96a6666a555a5555aa6 aaaaaaaa5aa659a66a6aa96a6666a555a5555aa6 aaaaaaaa55aaa6aa99669a96955a9659a95655aa aaaaaaaa55aaa6aa99669a96955a9659a95655aa aaaaaaaa66a666a6666a556a5a66a95595a566a6 aaaaaaaa66a666a6666a556a5a66a95595a566a6 aaaaaaaa59a659a6956aa66a69669a559a5659a6 aaaaaaaa59a659a6956aa66a69669a559a5659a6 aaaaaaaa66966696669a555a5a96a6a595556696 aaaaaaaa66966696669a555a5a96a6a595556696 aaaaaaaa6a566a56655a569a5956aa6569566a56 aaaaaaaa6a566a56655a569a5956aa6569566a56 aaaaaaaa66aa66aa666655965a5aa95969a666aa aaaaaaaa66aa66aa666655965a5aa95969a666aa aaaaaaaa6a666a665aa956aa56a6aa9566566a66 aaaaaaaa6a666a665aa956aa56a6aa9566566a66 aaaaaaaa696a696a65a55656599aa99966a6696a aaaaaaaa696a696a65a55656599aa99966a6696a aaaaabaa665a665a6955aaa65aaaa6699596665a aaaaaaaa665a665a6955aaa65aaaa6699596665a aaaaaaaa669a659a669655665a6aa6a99956669a aaaaaaaa669a659a669655665a6aa6a99956669a aaaaaaaa56a655a69669a56a6a669955a95556a6 aaaaaaaa56a655a69669a56a6a669955a95556a6 aaaaaaaa569a569a969aaaa56aa5a696a95a569a aaaaaaaa569a569a969aaaa56aa5a696a95a569a aaaaaaaa5566a66699a999aa95a69595a9a95566 aaaaaaaa5566a66699a999aa95a69595a9a95566 aaaaaaaa555aa65a9a5599a695aa9569a966555a aaaaaaaa555aa65a9a5599a695aa9569a966555a aaaaaaaa6a5a655a655556a656aaaa69699a6a5a aaaaaaaa6a5a655a655556a656aaaa69699a6a5a aaaaaaaa655a655a6a55a9a665aaa569965a655a aaaaaaaa655a655a6a55a9a665aaa569965a655a aaaaaaaa555a555a9a5aa669699a9699aa9a555a aaaaaaaa555a555a9a5aa669699a9699aa9a555a aaaaaaaa6666666666a9aaaa5aa6a6956a996666 aaaaaaaa6666666666a9aaaa5aa6a6956a996666 aaaaaaaa65a665a669969956596695659a5665a6 aaaaaaaa65a665a669969956596695659a5665a6 aaaaaaaa5a965a966a99a95a66969aa595aa5a96 aaaaaaaa5a965a966a99a95a66969aa595aa5a96 aaaaaaaa555655569a59999a96569565a5595556 aaaaaaaa555655569a59999a96569565a5595556 aaaaaaaa669a669a669555665a6aa6a96956669a aaaaaaaa669a669a669555665a6aa6a96956669a aaaaaaaa5966596695a9a5aa69a699959a555966 aaaaaaaa5966596695a9a5aa69a699959a555966 aaaaaaaa6aaa69aa5a655996565a555969aa6aaa aaaaaaaa6aaa69aa5a655996565a555969aa6aaa aaaaaaaa699666966599565a5996a9a5965a6996 aaaaaaaa699666966599565a5996a9a5965a6996 aaaaaaaa65965a966996aa5a6596a5a599a56596 aaaaaaaa65965a966996aa5a6596a5a599a56596 aaaaaaaa65aa56aa6965aa96655aa659966a65aa aaaaaaaa65aa56aa6965aa96655aa659966a65aa aaaaaaaa56aaa9aa965aa5966a5a99599a9956aa aaaaaaaa56aaa9aa965aa5966a5a99599a9956aa aaaaaaaa59aa59aa955aa696695a9a59996659aa aaaaaaaa59aa59aa955aa696695a9a59996659aa aaaaaaaa6a566a566556569a5956aa65696a6a56 aaaaaaaa6a566a566556569a5956aa65696a6a56 aaaaaaaa5666566696a69aaa6aa69695a6aa5666 aaaaaaaa5666566696a69aaa6aa69695a6aa5666 aaaaaaaa6a566a566556569a5956aa6595a56a56 aaaaaaaa6a566a566556569a5956aa6595a56a56 ```

Gadgeteering commented 2 years ago

3929 7be3 59bc b439 4939 6bf3 49cc b149

If you XOR first byte with the bytes of the data above you get this 0x10:0x42:0xda:0x60:0x85:0x8d:0x0 0x70:0x22:0xba:0x0:0x85:0xf8:0x0

Then XOR byte with the next byte in the series you get this 0x52:0x98:0xba:0xe5:0x8:0x8d 0x52:0x98:0xba:0x85:0x7d:0xf8

bitBench

Gadgeteering commented 2 years ago

If we take the raw data from https://github.com/merbanan/rtl_433/issues/1820#issuecomment-939314458

Put it into bitBench

We get 00 01 4d 4d 49 f9 8c 46 ff 26 00 00 a6 a6 a4 fc c6 23 7f a6 00 00 ec ec 5e 42 80 69 44 ec 00 00 ec ec 5e 42 80 69 44 ec 00 00 b2 b2 98 08 ba 2f 82 b2 00 00 b2 b2 98 08 ba 2f 82 b2 00 00 b8 b8 92 0e b4 35 84 b8 00 00 c2 c2 88 18 aa 3f 6c c2 00 00 c2 c2 88 18 aa 3f 6c c2 00 00 a2 a2 a8 f8 ca 1f 78 a2 00 00 a2 a2 a8 f8 ca 1f 78 a2 00 00 b6 c6 94 0c b6 33 51 b6 00 00 b6 c6 94 0c b6 33 51 b6 00 00 c2 d2 88 18 aa 3f 3f c2 00 00 c2 d2 88 18 aa 3f 3f c2 00 00 f0 20 5a 46 7c 6d 1e f0 00 00 f0 20 5a 46 7c 6d 1e f0 00 00 a2 a2 a8 f8 ca 1f 73 a2 00 00 a2 a2 a8 f8 ca 1f 73 a2 00 00 d2 d2 78 28 9a 4f 4e d2 00 00 d2 d2 78 28 9a 4f 4e d2 00 00 a6 a6 a4 fc c6 23 7f a6 00 00 a6 a6 a4 fc c6 23 7f a6 00 00 8e 8e bc e4 de 0b 9e 8e 00 00 8e 8e bc e4 de 0b 9e 8e 00 00 a0 a0 aa f6 cc 1d 92 a0 00 00 a0 a0 aa f6 cc 1d 92 a0 00 00 8a 8a c1 e0 e2 07 ae 8a 00 00 8a 8a c1 e0 e2 07 ae 8a 00 00 98 98 b3 ee d4 15 a2 98 00 00 98 98 b3 ee d4 15 a2 98 00 00 ac ac 9f 02 c0 29 76 ac 00 00 a4 b4 a6 fa c8 21 5e a4 00 00 a4 b4 a6 fa c8 21 5e a4 00 00 e2 f2 69 38 8a 5f 1f e2 00 00 e2 f2 69 38 8a 5f 1f e2 00 00 e4 e4 64 03 83 26 1c e4 00 00 e4 e4 64 03 83 26 1c e4 00 00 fa 2a 51 50 72 77 11 fa 00 00 fa 2a 51 50 72 77 11 fa 00 00 fc 2c 4f 52 70 79 1a fc 00 00 fc 2c 4f 52 70 79 1a fc 00 00 8c bc bf e2 e0 09 94 8c 00 00 8c bc bf e2 e0 09 94 8c 00 00 bc bc 8f 12 b0 39 6c bc 00 00 bc bc 8f 12 b0 39 6c bc 00 00 fc fc 4c 29 94 65 04 fc 00 00 fc fc 4c 29 94 65 04 fc 00 00 aa aa a1 00 c2 27 85 aa 00 00 aa aa a1 00 c2 27 85 aa 00 00 b2 b2 96 5e da 7b 4e b2 00 00 b2 b2 96 5e da 7b 4e b2 00 00 c6 c6 85 1c a6 43 70 c6 00 00 c6 c6 85 1c a6 43 70 c6 00 00 fe fe 4d 54 6e 7b 3d fe 00 00 fe fe 4d 54 6e 7b 3d fe 00 00 a4 a4 a7 fa c8 21 9e a4 00 00 a4 a4 a7 fa c8 21 9e a4 00 00 da da 71 30 92 57 4f da 00 00 da da 71 30 92 57 4f da 00 00 80 90 cb d6 ec fd 90 80 00 00 80 90 cb d6 ec fd 90 80 00 00 96 a6 b5 ec d6 13 6c 96 00 00 96 a6 b5 ec d6 13 6c 96 00 00 b6 c6 96 0c b6 33 53 b6 00 00 b6 c6 96 0c b6 33 53 b6 00 00 b0 e0 9b 06 bc 2d 68 b0 00 00 b0 e0 9b 06 bc 2d 68 b0 00 00 e0 10 6c 36 8c 5d 45 e0 00 00 e0 10 6c 36 8c 5d 45 e0 00 00 d0 d0 7c 26 9c 4d 5a d0 00 00 d0 d0 7c 26 9c 4d 5a d0 00 00 8e 8e be e4 de 0b 98 8e 00 00 8e 8e be e4 de 0b 98 8e 00 00 ea ea 62 40 82 67 20 ea 00 00 ea ea 62 40 82 67 20 ea 00 00 8e 8e be e4 de 0b 73 8e 00 00 8e 8e be e4 de 0b 73 8e

if you XOR the 3rd byte with the 4-10 you get this 00 04 b4 c1 0b b2 00 02 5a 60 85 d9 00 b2 ae 6c 85 a8 00 b2 ae 6c 85 a8 00 2a ba 08 9d 30 00 2a ba 08 9d 30 00 2a b6 0c 8d 3c 00 4a da 68 fd ae 00 4a da 68 fd ae 00 0a 5a 68 bd da 00 0a 5a 68 bd da 70 22 ba 00 85 e7 70 22 ba 00 85 e7 10 4a da 68 fd fd 10 4a da 68 fd fd d0 aa b6 8c 9d ee d0 aa b6 8c 9d ee 00 0a 5a 68 bd d1 00 0a 5a 68 bd d1 00 aa fa 48 9d 9c 00 aa fa 48 9d 9c 00 02 5a 60 85 d9 00 02 5a 60 85 d9 00 32 6a 50 85 10 00 32 6a 50 85 10 00 0a 56 6c bd 32 00 0a 56 6c bd 32 00 4b 6a 68 8d 24 00 4b 6a 68 8d 24 00 2b 76 4c 8d 3a 00 2b 76 4c 8d 3a 00 33 ae 6c 85 da 10 02 5e 6c 85 fa 10 02 5e 6c 85 fa 10 8b da 68 bd fd 10 8b da 68 bd fd 00 80 e7 67 c2 f8 00 80 e7 67 c2 f8 d0 ab aa 88 8d eb d0 ab aa 88 8d eb d0 b3 ae 8c 85 e6 d0 b3 ae 8c 85 e6 30 33 6e 6c 85 18 30 33 6e 6c 85 18 00 33 ae 0c 85 d0 00 33 ae 0c 85 d0 00 b0 d5 68 99 f8 00 b0 d5 68 99 f8 00 0b aa 68 8d 2f 00 0b aa 68 8d 2f 00 24 ec 68 c9 fc 00 24 ec 68 c9 fc 00 43 da 60 85 b6 00 43 da 60 85 b6 00 b3 aa 90 85 c3 00 b3 aa 90 85 c3 00 03 5e 6c 85 3a 00 03 5e 6c 85 3a 00 ab ea 48 8d 95 00 ab ea 48 8d 95 10 4b 56 6c 7d 10 10 4b 56 6c 7d 10 30 23 7a 40 85 fa 30 23 7a 40 85 fa 70 20 ba 00 85 e5 70 20 ba 00 85 e5 50 2b b6 0c 9d d8 50 2b b6 0c 9d d8 f0 8c d6 6c bd a5 f0 8c d6 6c bd a5 00 ac f6 4c 9d 8a 00 ac f6 4c 9d 8a 00 30 6a 50 85 16 00 30 6a 50 85 16 00 88 aa 68 8d ca 00 88 aa 68 8d ca 00 30 6a 50 85 fd 00 30 6a 50 85 fd

merbanan commented 2 years ago

00 00 8e 8e bc e4 de 0b 9e 8e
00 00 8e 8e be e4 de 0b 98 8e
00 00 8e 8e be e4 de 0b 73 8e

Ok, here we have the same prevalue of 0x8e. If we guess that the pressure is 0 then we have different temperature readings that generate the last byte. What we can deduce is that we have a byte wise stream cipher. And the prevalue seem to be an initialisation vector. And the first byte together with the IV seems to output the IV. That implies that the operation is linear in this first step.

In most cases this holds but there are cases where it doesn't.

00 00 e0 10 6c 36 8c 5d 45 e0

We are missing information if there are several sensors in the data or just one.

merbanan commented 2 years ago

Lets assume that what we have is simple xor encryption. But we don't have a single byte to xor with. What we have is an IV in the first and last byte that is used as seed for a random number generator.


00 00 a4 [a4] a7 |fa c8 21| [9e] a4
00 00 a4 [b4] a6 |fa c8 21| [5e] a4

00 00 c2 [c2] 88 |18 aa 3f| [6c] c2
00 00 c2 [d2] 88 |18 aa 3f| [3f] c2

If we look at these messages they both show the same pattern. I assume that this is 2 different sensors with different id value in some bytes and different temperature in one byte. With this pattern occurring in 2 places I think that this data is not a decoding error. And the take here is that even though there is different data in the beginning of the message the pattern is identical after the difference. This means that the encryption does not depend on the previous input and that a seed generating a psudo random string of bytes would match the encryption.

I really don't think that there is just 1 bytes used in the process. But I also don't see how we will be able to recover the byte string generation process just by analysing the messages. I think we need to reverse engineer the action sensors or the receiver.

zuckschwerdt commented 2 years ago

If we could assume the sensor IDs to be mostly sequential, then the same IV for different sensors should show a few bytes (MSB of the ID) to be the same. Same for the MSB of pressure and temp in a very controlled setup. Might be worth a look.

flambert860 commented 2 years ago

In the tests I have only had one sensor in the pressure champer

merbanan commented 2 years ago

Ok, then maybe the first byte is not fixed after all. But I don't see a next step forward except more messages with matching pressure and temperature readings.

It still indicate a generated string of 8-bit numbers to XOR with. And my best bet here is to dump the firmware of the sensor or receiver.

Gadgeteering commented 2 years ago

If you remove all the duplicates and put them in sequential you can start to see a pattern

00 02 5a 60 85 d9 10 02 5e 6c 85 fa 00 b3 aa 90 85 c3 00 03 5e 6c 85 3a 00 04 b4 c1 0b b2 00 0a 5a 68 bd da 00 0a 5a 68 bd d1 00 0a 56 6c bd 32 00 0b aa 68 8d 2f 70 20 ba 00 85 e5 70 22 ba 00 85 e7 30 23 7a 40 85 fa 00 24 ec 68 c9 fc 00 2a ba 08 9d 30 00 2a b6 0c 8d 3c 50 2b b6 0c 9d d8 00 2b 76 4c 8d 3a 00 30 6a 50 85 fd 00 30 6a 50 85 16 00 32 6a 50 85 10 00 33 ae 6c 85 da 30 33 6e 6c 85 18 00 33 ae 0c 85 d0 00 43 da 60 85 b6 10 4a da 68 fd fd 00 4a da 68 fd ae 00 4b 6a 68 8d 24 10 4b 56 6c 7d 10 00 80 e7 67 c2 f8 00 88 aa 68 8d ca 10 8b da 68 bd fd f0 8c d6 6c bd a5 d0 aa b6 8c 9d ee 00 aa fa 48 9d 9c 00 ab ea 48 8d 95 d0 ab aa 88 8d eb 00 ac f6 4c 9d 8a 00 b0 d5 68 99 f8 00 b2 ae 6c 85 a8 d0 b3 ae 8c 85 e6

bitBench

Gadgeteering commented 2 years ago

Decode

flambert860 commented 2 years ago

I can still not identify any pattern for something like sensor id

gdt commented 1 year ago

What's the status and plan?

merbanan / rtl_433

Help decoding TPMS with SP372 ASK #1820