rtl_433_tests
rtl_433_tests copied to clipboard
merbanan
Add M3-B-WI signals from Motorcycle TPMS
Those long runs of ff or 00 don't look right. I'll have a closer look soon.
Are those samples post-processed? There is no noise floor? Also you did hit one of the FSK frequencies dead on, which is not great. Try to offset the frequency by 50k (neither of the two lines should be at 0 Hz). Try https://triq.org/iqs/ to see and compare with other TPMS samples from here.
DC correction was turned on... (default)
With the following record setting:
- Frequency: 433,920M
- Sample rate: 1,000M
- Bandwidth: 1,000M
- Gain: 49
- Frequency correction: 1
- Direct sampling: disabled
- DC correction: false 😞
I get these outputs from two test signals and they look promising (Copied from 'Interpretation' tab below signal view).
aaaaaaaaaaaaaaaaaaaaaaaaaaaa5696a5aa6a5699a9599aa6966a99569aa56ae [Pause: 100088 samples]
aaaaaaaaaaaaaaaaaaaaaaaaaaaa5696a5aa5a56a9a9699a96965a99955666aae [Pause: 2708 samples]
aaaaaaaaaaaaaaaaaaaaaaaaaaaa5696a5aaaa5659a999996969aa9999a5a966e [Pause: 100085 samples]
aaaaaaaaaaaaaaaaaaaaaaaaaaaa5696a5aa9a5669a9a99959699a995a696aa6e [Pause: 3466 samples]
Now the only thing missing was to offset everything to avoid negative frequencies and after playing for some time I noticed a strange bug in https://triq.org/iqs/. In the zip-file are two identical signals, the only thing I changed is the file name - even the hashes are equal - but in IQS both have different center frequencies.
Files: TPMS_Test_Signals.zip
Test20_433-920M_1M_49G.complex16s: Center frequency @ 1000 kHz, moving the mouse over spectogram only changes time value
Test_433-920M_NO-DC.complex16s: Center frequency @ 0 mHz, moving cursor changes frequency and time values
Do you know how I can set the center frequency correctly? Tomorrow I'll record a new set of signals.
Frequency and sample rate are detected using the file name. You need to have something like 433.92M and 1000k in there, separated by underscores.
The code look good, Manchester coded. See this BitBench.
Btw. the native format of the RTL-SDR is Complex Unsigned 8-bit (.cu8), .complex16u in URH. Using that avoids most of the DC-spike.
Ok, here are the new signals. I made sure that every signal decodes to a similar Hex representation and that there is no post-processing (DC correction).
I tried to save the files as .complex16u but then URH crashed every time I wanted to open a file.
You are still hitting on frequency dead on. It's better to offset and use e.g. -s 433.97M.
If you can't save .cu8 use this to convert:
sox -t raw -e signed-integer -b 8 -c 2 -r 1000000 F-06-26_433.92M_1000K.complex16s -t raw -e unsigned-integer -b 8 -c 2 -r 1000000 F-06-26_433.92M_1000K.cu8
In URH I set the frequency to 433.97M and saved the signals as .complex16s, but now I'm not able to decode it like the ones before (e.g. aaaaaaaaaaaaaaaaaaaaaaaaaaaa5696a5aa6a5699a9599aa6966a99569aa56ae). I also used your sox command and converted it to .cu8.
Here's a signal in both file formats: TPMS_Test_Signals2.zip
Here's a signal in both file formats: TPMS_Test_Signals2.zip
I messed something up. Setting frequency to 433.97M results in decodable signals, but I'm still having a hard time with unsigned file formats. After reinstalling URH I'm able to save in .complex16u/.cu8 but looking at the signals they have a very small amplitude, shift to the bottom and URH is unable to detect something.
Are unsigned files necessary for decoding signals?
Signed 8-bit data (.cs8) isn't very useful, so I never got around to implement that in rtl_433.
Maybe you can record simply with rtl_433 -f 433.97M -w sample.cu8 or perhaps -S all now works? Both use automatic gain, which should help.
The result of your first command looks promising (?) but the second one didn't work. In URH it's just a white plane.
Here's the file all and sample.cu8 split into three detected signals: TPMS_Test_Signals3.zip
Is it correct that rtl_433 doesn't show anything in the CLI when recording? I just hit enter, played with the sensor and after some time I stopped it just to notice that there were already three messages captured.
The samples are good. You should be able to get the raw data with
rtl_433 -R 0 -X 'n=TPMS-M3-B-WI,m=FSK_PCM,s=50,l=50,r=150,preamble=aaa5'
And the Manchester decoded data with
rtl_433 -R 0 -X 'n=TPMS-M3-B-WI,m=FSK_MC_ZEROBIT,s=50,r=150'
(though the bit alignment might be off)
You should be able to collect codes, figure out which part identifies the tire, and then perhaps spot the pressure/temp values in there.
Looks like I'm running an old version of rtl_433 (19.08-1) so I used a different syntax (https://github.com/merbanan/rtl_433/issues/1007#issuecomment-472308996)
xxx@klvn:~/Schreibtisch$ rtl_433 -R 0 -X 'TPMS:FSK_PCM:50:50:150'
...
Tuned to 433.920MHz.
Allocating 15 zero-copy buffers
2020-02-01 11:46:05 : TPMS : 1 : 1 : [ :260 : aaaaaaaaaaaaaaaaaaaaaaaaaaaa5696a5aaa69699669669959aa6996656a966f] : [{260}aaaaaaaaaaaaaaaaaaaaaaaaaaaa5696a5aaa69699669669959aa6996656a966f]
^CSignal caught, exiting!
xxx@klvn:~/Schreibtisch$ rtl_433 -R 0 -X 'TPMS:FSK_MC_ZEROBIT:50:50:150'
...
Tuned to 433.920MHz.
Allocating 15 zero-copy buffers
2020-02-01 11:47:06 : TPMS : 1 : 1 : [ :44 : 00000000000] : [{44}00000000000]
2020-02-01 11:47:08 : TPMS : 1 : 1 : [ :1 : 0] : [{1}0]
2020-02-01 11:47:08 : TPMS : 1 : 1 : [ :2 : 4] : [{2}4]
2020-02-01 11:47:18 : TPMS : 1 : 1 : [ : 2 : 4] : [{2}4]
2020-02-01 11:47:20 : TPMS : 1 : 1 : [ : 22 : 000000] : [{22}000000]
2020-02-01 11:47:20 : TPMS : 1 : 1 : [ : 1 : 0] : [{1}0]
2020-02-01 11:47:20 : TPMS : 1 : 1 : [ : 1 : 0] : [{1}0]
2020-02-01 11:47:20 : TPMS : 1 : 1 : [ : 23 : 000000] : [{23}000000]
2020-02-01 11:47:20 : TPMS : 1 : 1 : [ : 1 : 0] : [{1}0]
2020-02-01 11:47:20 : TPMS : 1 : 1 : [ : 1 : 0] : [{1}0]
2020-02-01 11:47:22 : TPMS : 1 : 1 : [ : 2 : 4] : [{2}4]
2020-02-01 11:47:22 : TPMS : 1 : 1 : [ : 2 : 4] : [{2}4]
2020-02-01 11:47:23 : TPMS : 1 : 1 : [ : 1 : 0] : [{1}0]
2020-02-01 11:47:24 : TPMS : 1 : 1 : [ : 95 : 0000000000000019cf512d1e] : [{95}0000000000000019cf512d1e]
2020-02-01 11:47:24 : TPMS : 1 : 1 : [ : 2 : 4] : [{2}4]
2020-02-01 11:47:24 : TPMS : 1 : 1 : [ : 1 : 0] : [{1}0]
2020-02-01 11:47:24 : TPMS : 1 : 1 : [ : 2 : 0] : [{2}0]
2020-02-01 11:47:24 : TPMS : 1 : 1 : [ : 2 : 0] : [{2}0]
2020-02-01 11:47:24 : TPMS : 1 : 1 : [ : 49 : 0000000000000] : [{49}0000000000000]
2020-02-01 11:47:24 : TPMS : 1 : 1 : [ : 6 : 64] : [{6}64]
2020-02-01 11:47:24 : TPMS : 1 : 1 : [ : 1 : 0] : [{1}0]
2020-02-01 11:47:24 : TPMS : 1 : 1 : [ : 1 : 0] : [{1}0]
2020-02-01 11:47:26 : TPMS : 1 : 1 : [ : 2 : 4] : [{2}4]
2020-02-01 11:47:28 : TPMS : 1 : 1 : [ : 35 : 000000000] : [{35}000000000]
2020-02-01 11:47:28 : TPMS : 1 : 1 : [ : 2 : 0] : [{2}0]
2020-02-01 11:47:28 : TPMS : 1 : 1 : [ : 1 : 0] : [{1}0]
2020-02-01 11:47:28 : TPMS : 1 : 1 : [ : 1 : 0] : [{1}0]
2020-02-01 11:47:43 : TPMS : 1 : 1 : [ : 4 : 5] : [{4}5]
2020-02-01 11:47:43 : TPMS : 1 : 1 : [ : 2 : 4] : [{2}4]
2020-02-01 11:47:43 : TPMS : 1 : 1 : [ : 2 : 4] : [{2}4]
2020-02-01 11:47:43 : TPMS : 1 : 1 : [ : 2 : 4] : [{2}4]
2020-02-01 11:47:43 : TPMS : 1 : 1 : [ : 2 : 4] : [{2}4]
2020-02-01 11:47:43 : TPMS : 1 : 1 : [ : 2 : 4] : [{2}4]
2020-02-01 11:47:43 : TPMS : 1 : 1 : [ : 3 : 6] : [{3}6]
2020-02-01 11:47:43 : TPMS : 1 : 1 : [ : 2 : 4] : [{2}4]
2020-02-01 11:47:43 : TPMS : 1 : 1 : [ : 5 : 48] : [{5}48]
2020-02-01 11:47:49 : TPMS : 1 : 1 : [ : 49 : 0000000000000] : [{49}0000000000000]
2020-02-01 11:47:49 : TPMS : 1 : 1 : [ : 1 : 0] : [{1}0]
2020-02-01 11:47:49 : TPMS : 1 : 1 : [ : 1 : 0] : [{1}0]
2020-02-01 11:47:49 : TPMS : 1 : 1 : [ : 1 : 0] : [{1}0]
2020-02-01 11:48:07 : TPMS : 1 : 1 : [ : 24 : 000000] : [{24}000000]
2020-02-01 11:48:17 : TPMS : 1 : 1 : [ : 2 : 4] : [{2}4]
2020-02-01 11:48:17 : TPMS : 1 : 1 : [ : 2 : 4] : [{2}4]
2020-02-01 11:48:17 : TPMS : 1 : 1 : [ : 1 : 0] : [{1}0]
2020-02-01 11:48:17 : TPMS : 1 : 1 : [ : 4 : 6] : [{4}6]
2020-02-01 11:48:17 : TPMS : 1 : 1 : [ : 2 : 4] : [{2}4]
2020-02-01 11:48:17 : TPMS : 1 : 1 : [ : 2 : 4] : [{2}4]
2020-02-01 11:48:17 : TPMS : 1 : 1 : [ : 2 : 4] : [{2}4]
2020-02-01 11:48:17 : TPMS : 1 : 1 : [ : 2 : 4] : [{2}4]
2020-02-01 11:48:17 : TPMS : 1 : 1 : [ : 2 : 4] : [{2}4]
2020-02-01 11:48:17 : TPMS : 1 : 1 : [ : 2 : 4] : [{2}4]
2020-02-01 11:48:17 : TPMS : 1 : 1 : [ : 2 : 4] : [{2}4]
2020-02-01 11:48:17 : TPMS : 1 : 1 : [ : 2 : 4] : [{2}4]
2020-02-01 11:48:17 : TPMS : 1 : 1 : [ : 2 : 4] : [{2}4]
2020-02-01 11:48:17 : TPMS : 1 : 1 : [ : 2 : 4] : [{2}4]
2020-02-01 11:48:17 : TPMS : 1 : 1 : [ : 1 : 0] : [{1}0]
2020-02-01 11:48:25 : TPMS : 1 : 1 : [ : 46 : 000000000000] : [{46}000000000000]
2020-02-01 11:48:25 : TPMS : 1 : 1 : [ : 12 : 000] : [{12}000]
2020-02-01 11:48:49 : TPMS : 1 : 1 : [ : 37 : 0000000000] : [{37}0000000000]
2020-02-01 11:48:49 : TPMS : 1 : 1 : [ : 36 : 00000673d] : [{36}00000673d]
2020-02-01 11:48:50 : TPMS : 1 : 1 : [ : 2 : 4] : [{2}4]
2020-02-01 11:48:52 : TPMS : 1 : 1 : [ : 1 : 0] : [{1}0]
2020-02-01 11:49:20 : TPMS : 1 : 1 : [ : 2 : 4] : [{2}4]
2020-02-01 11:49:22 : TPMS : 1 : 1 : [ : 12 : 000] : [{12}000]
2020-02-01 11:49:22 : TPMS : 1 : 1 : [ : 1 : 0] : [{1}0]
2020-02-01 11:49:22 : TPMS : 1 : 1 : [ : 2 : 4] : [{2}4]
2020-02-01 11:49:24 : TPMS : 1 : 1 : [ : 36 : 000000000] : [{36}000000000]
2020-02-01 11:49:24 : TPMS : 1 : 1 : [ : 1 : 0] : [{1}0]
2020-02-01 11:49:24 : TPMS : 1 : 1 : [ : 1 : 0] : [{1}0]
2020-02-01 11:49:24 : TPMS : 1 : 1 : [ : 1 : 0] : [{1}0]
2020-02-01 11:49:24 : TPMS : 1 : 1 : [ : 77 : 0000000000000019cf90] : [{77}0000000000000019cf90]
2020-02-01 11:49:24 : TPMS : 1 : 1 : [ : 3 : 6] : [{3}6]
2020-02-01 11:49:25 : TPMS : 1 : 1 : [ : 1 : 0] : [{1}0]
2020-02-01 11:49:25 : TPMS : 1 : 1 : [ : 1 : 0] : [{1}0]
2020-02-01 11:49:26 : TPMS : 1 : 1 : [ : 42 : 00000000000] : [{42}00000000000]
2020-02-01 11:49:26 : TPMS : 1 : 1 : [ : 1 : 0] : [{1}0]
2020-02-01 11:49:26 : TPMS : 1 : 1 : [ : 25 : 0006738] : [{25}0006738]
2020-02-01 11:49:26 : TPMS : 1 : 1 : [ : 1 : 0] : [{1}0]
2020-02-01 11:49:26 : TPMS : 1 : 1 : [ : 1 : 0] : [{1}0]
2020-02-01 11:49:26 : TPMS : 1 : 1 : [ : 1 : 0] : [{1}0]
2020-02-01 11:49:26 : TPMS : 1 : 1 : [ : 2 : 4] : [{2}4]
2020-02-01 11:49:28 : TPMS : 1 : 1 : [ : 83 : 0000000000000019cfd1a] : [{83}0000000000000019cfd1a]
2020-02-01 11:49:28 : TPMS : 1 : 1 : [ : 25 : 0000000] : [{25}0000000]
2020-02-01 11:49:30 : TPMS : 1 : 1 : [ : 12 : 000] : [{12}000]
2020-02-01 11:49:30 : TPMS : 1 : 1 : [ : 51 : 0000000000032] : [{51}0000000000032]
2020-02-01 11:49:30 : TPMS : 1 : 1 : [ : 51 : 7a89681292948] : [{51}7a89681292948]
2020-02-01 11:49:30 : TPMS : 1 : 1 : [ : 33 : 000000000] : [{33}000000000]
2020-02-01 11:49:30 : TPMS : 1 : 1 : [ : 1 : 0] : [{1}0]
2020-02-01 11:49:30 : TPMS : 1 : 1 : [ : 1 : 0] : [{1}0]
2020-02-01 11:49:37 : TPMS : 1 : 1 : [ : 1 : 0] : [{1}0]
2020-02-01 11:49:40 : TPMS : 1 : 1 : [ : 1 : 0] : [{1}0]
The first output is comprehensible, I've already seen these lines in UHR but I'm not sure what to do with the second output.
The PCM is raw data, the MC already does one decoding step, but that might fail with bad data, thus the short code fragments you see.
The old format is phased out. Don't use that. You can add a minimum required bit length to suppress the bad codes (and don't forget -f 433.97M):
rtl_433 -f 433.97M -R 0 -X 'n=TPMS,m=FSK_MC_ZEROBIT,s=50,r=150,bits>=100'
You may need to try different frequency settings and maybe -s 1000k until you get a stable reception.
Freshly built rtl_433 and with new syntax. Is it now time for BitBench, using the values in "data"? The sensor send two bursts, how should I combine these two data-values?
(All these received signals after 12:08:24 may be caused by the tire deflating very fast)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2020-02-01 12:07:51
model : TPMS count : 1 num_rows : 1
rows :
len : 127 data : 00000000000000673f047a101f288246
codes : {127}00000000000000673f047a101f288246
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2020-02-01 12:07:51
model : TPMS count : 1 num_rows : 1
rows :
len : 129 data : 0000000000000019cf815ec4478aba098
codes : {129}0000000000000019cf815ec4478aba098
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2020-02-01 12:08:22
model : TPMS count : 1 num_rows : 1
rows :
len : 129 data : 0000000000000019cf59861c905282518
codes : {129}0000000000000019cf59861c905282518
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2020-02-01 12:08:22
model : TPMS count : 1 num_rows : 1
rows :
len : 129 data : 0000000000000019cf19c65cd01218c98
codes : {129}0000000000000019cf19c65cd01218c98
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2020-02-01 12:08:24
model : TPMS count : 1 num_rows : 1
rows :
len : 127 data : 00000000000000673f641a704348dd92
codes : {127}00000000000000673f641a704348dd92
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2020-02-01 12:08:24
model : TPMS count : 1 num_rows : 1
rows :
len : 127 data : 00000000000000673e651b71424ab7f2
codes : {127}00000000000000673e651b71424ab7f2
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2020-02-01 12:08:26
model : TPMS count : 1 num_rows : 1
rows :
len : 129 data : 0000000000000019cf59861c905282518
codes : {129}0000000000000019cf59861c905282518
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2020-02-01 12:08:26
model : TPMS count : 1 num_rows : 1
rows :
len : 129 data : 0000000000000019cf19c65cd01218c98
codes : {129}0000000000000019cf19c65cd01218c98
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2020-02-01 12:08:28
model : TPMS count : 1 num_rows : 1
rows :
len : 129 data : 0000000000000019cfd9069c10d237648
codes : {129}0000000000000019cfd9069c10d237648
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2020-02-01 12:08:28
model : TPMS count : 1 num_rows : 1
rows :
len : 129 data : 0000000000000019cf9946dc5092adfc8
codes : {129}0000000000000019cf9946dc5092adfc8
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2020-02-01 12:08:30
model : TPMS count : 1 num_rows : 1
rows :
len : 129 data : 0000000000000019cf59861c905282518
codes : {129}0000000000000019cf59861c905282518
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2020-02-01 12:08:30
model : TPMS count : 1 num_rows : 1
rows :
len : 129 data : 0000000000000019cf19c65cd01218c98
codes : {129}0000000000000019cf19c65cd01218c98
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2020-02-01 12:08:32
model : TPMS count : 1 num_rows : 1
rows :
len : 129 data : 0000000000000019cfd9069d10d2b7738
codes : {129}0000000000000019cfd9069d10d2b7738
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2020-02-01 12:08:32
model : TPMS count : 1 num_rows : 1
rows :
len : 129 data : 0000000000000019cf9946dd50922deb8
codes : {129}0000000000000019cf9946dd50922deb8
The data is just presented in two different formats there, just stick the codes in the BitBench.
You need to align on the first bit to get a consistent ouput. See this BitBench.
The leading (fixed) ID portion seems rather short (2 bytes) I'd expected more like 4 bytes to stay fixed. Play with the shift value and perhaps one of the columns will reveal a nicely decreasing pressure value.
The data is good though. If you right align on byte boundary (add 2 bits or remove 6) then the last 16 bits are CRC-16 poly 0x8005. I've updated the BitBench link. The data shown, or the Inverted should reveal the readings.
Here's a BitBench with measurements.
All the values from [F 38 24] were probably triggered by some alarm setting. I received a signal every 2 seconds and the little head unit started beeping, although I'm not sure how the sensor knows a certain threshold. I thought they would just give the measurements and the head unit decides whether to alarm or not (I'll check if there's also a connection from head unit to sensors. Edit: no, the head unit doesn't send anything to the sensors).
[R 23? 24?] are probably negligible because they look very different and there were difficulties when recording.
My guesses:
- ID Front:
00 19 cf f1 2e/00 19 cf b1 6e/00 19 cf 31 ee/00 19 cf 71 ae - ID Rear:
00 19 cf 39 45/00 19 cf 79 05/00 19 cf b9 c5/00 19 cf f9 85 - °C is in the next column: 25°C =
aa/ea/6a/2a; 24°C =75/35/b5/f5(don't take the comments for granted, I also found a 24°C with6abut this probably a mistake when I took notes) - PSI next to columns: 9 PSI =
10 3a/50 7abut these are the only values that matched and were taken from[F 09 25]and[R 09 25], so they definitely have something in common...
Hi, after a small break I'm still struggling to decode the hex codes... I also tried finding the CRC on my own but wasn't successful. Taking a hex value, truncating it by one bit each time, converting it to multiple CRCs and looking for common values didn't work out. What do you mean with "right align on byte boundary (add 2 bits or remove 6)"?
The guesses in my last comment are the only things I can see in the BitBench.
If you align the codes to look like this
19cf c11e8407ca 2091
19cf 815ec4478a ba09
19cf 59861c9052 8251
19cf 19c65cd012 18c9
19cf d9069c10d2 3764
19cf 9946dc5092 adfc
19cf 59861c9052 8251
19cf 19c65cd012 18c9
19cf d9069c10d2 3764
19cf 9946dc5092 adfc
19cf 59861c9052 8251
19cf 19c65cd012 18c9
19cf d9069d10d2 b773
19cf 9946dd5092 2deb
Then the last field (2 bytes) is the CRC-16 poly 0x8005 init=0x19cf remainder. This means if you strip the leading 19cf you get CRC-16 poly 0x8005 init=0x0 -- that's not by chance.
The bit-inverted codes would also work for the CRC but the init just looks random.
Codes in the format above should now have one byte of encoded temp and one byte of encoded pressure. It wont't likely be more than one byte. But there is too much changing, so it may be further coded or encrypted. You'd need to look at a long list of the middle column above and try to make something of that in correlation with readouts.
Thanks, I made progress! Somehow I was trying it with CRC-16/ARC but it's BUYPASS (same polynomial, but RefIn and RefOut are false). With this site and your examples I was able to work it out in BitBench:
19cf f12eaaecfa10 ec 1
19cf b16eeaacba8a 74 1
19cf 31ee6a273a85 42 1
where the corresponding CRCs are just the second last byte and the 1 ist just 00, therefore 0xEC00, 0x7400 and 0x4200.
I also tried it with the inverted values but as you said, it looks pretty random, although sometimes it works out:
| CRC inverted | CRC inverted (bin) | CRC inv. calculated | CRC inv. calculated (bin) |
|---|---|---|---|
| BD | 1011 1101 | C2 | 1100 0010 |
| 5A | 1011 010 | 25 | 0100 101 |
| D9 | 1101 1001 | A6 | 1010 0110 |
Should I look at the non-inverted ones for decoding? I'll take each byte, decode it and try to find something that will match with the measurements.
Edit: Maybe related: #333
Drop the tailing single 1 bit. In the first example above 2091 is the CRC remainder.
In your example above run the CRC over 19cf f12eaaecfa 10ec. I.e. either work
CRC16("19cff12eaaecfa10ec", 0x8005, 0x19cf) == 0
CRC16("f12eaaecfa10ec", 0x8005, 0) == 0
CRC16("19cf f12eaaecfa", 0x8005, 0x19cf) == 0x10ec
CRC16("f12eaaecfa", 0x8005, 0) == 0x10ec
If you want to use the online crc site then use the second of those options.
The f12eaaecfa part in this example is the interesting data. Perhaps you could either slowly change the temperature or pressure and record the sequence of values. (Freeze the sensor and thaw it, or pressurize it and let it leak.)
With the limited amount of values there is currently no pattern to the data visible.
Hello KLVN I bought a careud u903 with 4 devices that send the same messages, same format But I cannot figured out how to decode the hex code.
As the device send always two bursts, i find that some bits are always inverted between the 2 bursts. The xor between the 2 burst gives always 40404040409A980
Did you find the logic ?
Hi @al-r1517,
no, not yet and I wasn't even sure if those two bursts are just for redundancy/checksum-checking or if pressure and temperature are sent in two different signals. But I'm glad that you also have this kind of TPMS and already figured out the part with XOR. Hopefully we can reverse-engineer this together. Have you already recorded hundreds of signals including the actual value shown on the display?
no, not yet. I have recorded about 20 signals. I am wondering if a unit is best for collecting the displayed values : farentheit or celsius / bar or psi (to ease the task).
I start with the temperature : put the RR sensor in the freezer, pressure it and depressure to 0 for almost each degree, and collect the values (-21 to 20).
2bit seems to be the lsb (the ones between the brackets in this bitbench)
I do not find the others bits.
In the BitBench use 8h8h 4x at the end, it could reasonably be a 16-bit digest checksum. I'll see if I can recover it.
Indeed, gen 0xc002 key 0x8333 final xor 0xb050 produces an LFSR digest that matches all rows. The final xor hints that we didn't get it exactly right, though this LFSR has a length of 32767 which is solid (cycle length below, say, 10000 would be bad).
edit: I should have scrolled up… we already know it's CRC-16. which make more sense.
Thank you, CRC-16 poly 0x8005 works. I will change the bitbench to remove the header and crc. The payload is on 5 bytes
On the first byte, I found 3 bits that are always the same by sensors, maybe to ID the sensors
- RR : 0019cf 00001 [000] e3 98 be ba
- LF : 0019cf 01100 [110] b9 9e 88 d2
- LR : 0019cf 00011 [001] 81 06 44 4a
- RF : 0019cf 10111 [101] 5a 07 45 4a
I use this bitbench for all values