rtl_433
rtl_433 copied to clipboard
merbanan
Help receiving and analyzing new simplisafe system signals
I just bought a new SimpliSafe system and I am trying to read the signals to ultimately determine if the alarm is in AWAY, HOME, or OFF mode and then also which sensors are open/close as they report. I am starting with reading data from an entry sensor since that is on the 433 MHz frequency. I am very new to all of this. Steps so far.
- Bought this antenna.
- Installed raspberry pi image which comes with rtl_433 on it (see comments of video for link).
- Running rtl_433 I have pulled in at least two devices (Schrader TPMS sensor and Oregon Scientific SL109H - not my devices but at least verified everything is working).
- Open and Close door entry sensors and nothing shows up in my terminal. I then ran it with verbose on and saw signals coming in as I opened/closed door entry sensors. This output is shown below.
Pulse Data: 15 Pulses was from the entry sensor opening and then after those pulses was from the entry sensor closing.
pi@sdr:~ $ rtl_433 -R 102 -v -vv -vvv -vvvv -M newmodel
rtl_433 version 19.08-3-g04e818a branch master at 201909021329 inputs file rtl_tcp RTL-SDR
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "rtl_433.conf"...
Trying conf file at "/home/pi/.config/rtl_433/rtl_433.conf"...
Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"...
Trying conf file at "/etc/rtl_433/rtl_433.conf"...
Registered 1 out of 136 device decoding protocols
Found 1 device(s)
trying device 0: Realtek, RTL2838UHIDIR, SN: 00000001
Found Rafael Micro R820T tuner
Using device 0: Generic RTL2832U OEM
Exact sample rate is: 250000.000414 Hz
[R82XX] PLL not locked!
Sample rate set to 250000 S/s.
Bit detection level set to 0 (Auto).
Tuner gain set to Auto.
Reading samples in async mode...
Tuned to 433.920MHz.
Allocating 15 zero-copy buffers
Pulse data: 2 pulses
[ 0] Pulse: 37, Gap: 12, Period: 49
[ 1] Pulse: 63, Gap: 2501, Period: 2564
Pulse data: 1 pulses
[ 0] Pulse: 44, Gap: 2501, Period: 2545
Pulse data: 1 pulses
[ 0] Pulse: 43, Gap: 2501, Period: 2544
Pulse data: 1 pulses
[ 0] Pulse: 42, Gap: 2501, Period: 2543
Pulse data: 1 pulses
[ 0] Pulse: 18468, Gap: 25001, Period: 43469
Pulse data: 15 pulses
[ 0] Pulse: 181, Gap: 11, Period: 192
[ 1] Pulse: 304, Gap: 13, Period: 317
[ 2] Pulse: 398, Gap: 14, Period: 412
[ 3] Pulse: 301, Gap: 17, Period: 318
[ 4] Pulse: 298, Gap: 13, Period: 311
[ 5] Pulse: 1034, Gap: 11, Period: 1045
[ 6] Pulse: 198, Gap: 11, Period: 209
[ 7] Pulse: 812, Gap: 18, Period: 830
[ 8] Pulse: 2076, Gap: 11, Period: 2087
[ 9] Pulse: 3000, Gap: 12, Period: 3012
[ 10] Pulse: 507, Gap: 13, Period: 520
[ 11] Pulse: 507, Gap: 14, Period: 521
[ 12] Pulse: 2382, Gap: 13, Period: 2395
[ 13] Pulse: 925, Gap: 12, Period: 937
[ 14] Pulse: 5367, Gap: 25001, Period: 30368
Pulse data: 1 pulses
[ 0] Pulse: 18468, Gap: 25001, Period: 43469
Pulse data: 1 pulses
[ 0] Pulse: 18470, Gap: 25001, Period: 43471
Pulse data: 1 pulses
[ 0] Pulse: 18403, Gap: 25001, Period: 43404
Pulse data: 1 pulses
[ 0] Pulse: 18475, Gap: 25001, Period: 43476
If I do not use -M newmodel. Pulses 18506, 18583, and 18574 from opening same sensor used above and then the last 3 pulses were from closing the entry sensor used above.
pi@sdr:~ $ rtl_433 -R 102 -v -vv -vvv -vvvv
rtl_433 version 19.08-3-g04e818a branch master at 201909021329 inputs file rtl_tcp RTL-SDR
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "rtl_433.conf"...
Trying conf file at "/home/pi/.config/rtl_433/rtl_433.conf"...
Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"...
Trying conf file at "/etc/rtl_433/rtl_433.conf"...
Consider using "-M newmodel" to transition to new model keys. This will become the default someday.
A table of changes and discussion is at https://github.com/merbanan/rtl_433/pull/986.
Registered 1 out of 136 device decoding protocols
Found 1 device(s)
trying device 0: Realtek, RTL2838UHIDIR, SN: 00000001
Found Rafael Micro R820T tuner
Using device 0: Generic RTL2832U OEM
Exact sample rate is: 250000.000414 Hz
[R82XX] PLL not locked!
Sample rate set to 250000 S/s.
Bit detection level set to 0 (Auto).
Tuner gain set to Auto.
Reading samples in async mode...
Tuned to 433.920MHz.
Allocating 15 zero-copy buffers
Pulse data: 2 pulses
[ 0] Pulse: 42, Gap: 55, Period: 97
[ 1] Pulse: 40, Gap: 2501, Period: 2541
Pulse data: 1 pulses
[ 0] Pulse: 43, Gap: 2501, Period: 2544
Pulse data: 1 pulses
[ 0] Pulse: 43, Gap: 2501, Period: 2544
Pulse data: 1 pulses
[ 0] Pulse: 18506, Gap: 25001, Period: 43507
Pulse data: 1 pulses
[ 0] Pulse: 18583, Gap: 25001, Period: 43584
Pulse data: 1 pulses
[ 0] Pulse: 18574, Gap: 25001, Period: 43575
Pulse data: 1 pulses
[ 0] Pulse: 18622, Gap: 25001, Period: 43623
Pulse data: 1 pulses
[ 0] Pulse: 18527, Gap: 25001, Period: 43528
Pulse data: 1 pulses
[ 0] Pulse: 18621, Gap: 25001, Period: 43622
Any help with this is greatly appreciated. Great work on rtl_433! Kevin
Run with rtl_433 -A remove the antenna, place a sensor nearby and then trigger the sensor. Then post the output.
Steps:
- Ran rtl_433 -A
- Here is the output from that
pi@sdr:~ $ rtl_433 -A
rtl_433 version 19.08-3-g04e818a branch master at 201909021329 inputs file rtl_tcp RTL-SDR
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "rtl_433.conf"...
Trying conf file at "/home/pi/.config/rtl_433/rtl_433.conf"...
Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"...
Trying conf file at "/etc/rtl_433/rtl_433.conf"...
Consider using "-M newmodel" to transition to new model keys. This will become the default someday.
A table of changes and discussion is at https://github.com/merbanan/rtl_433/pull/986.
Registered 106 out of 136 device decoding protocols [ 1-4 8 11-12 15-17 19-21 23 25-26 29-36 38-60 63 67-71 73-100 102-103 108-116 119 121 124-128 131-136 ]
Found Rafael Micro R820T tuner
Exact sample rate is: 250000.000414 Hz
[R82XX] PLL not locked!
Sample rate set to 250000 S/s.
Tuner gain set to Auto.
Tuned to 433.920MHz.
Allocating 15 zero-copy buffers
Detected OOK package 2020-01-08 19:38:44
Analyzing pulses...
Total count: 1, width: 0.17 ms ( 43 S)
Pulse width distribution:
[ 0] count: 1, width: 172 us [172;172] ( 43 S)
Gap width distribution:
Pulse period distribution:
Level estimates [high, low]: 12395, 262
RSSI: -1.2 dB SNR: 16.7 dB Noise: -17.9 dB
Frequency offsets [F1, F2]: 12369, 0 (+47.2 kHz, +0.0 kHz)
Guessing modulation: Single pulse detected. Probably Frequency Shift Keying or just noise...
Detected OOK package 2020-01-08 19:38:44
Analyzing pulses...
Total count: 1, width: 0.18 ms ( 44 S)
Pulse width distribution:
[ 0] count: 1, width: 176 us [176;176] ( 44 S)
Gap width distribution:
Pulse period distribution:
Level estimates [high, low]: 11990, 190
RSSI: -1.4 dB SNR: 18.0 dB Noise: -19.3 dB
Frequency offsets [F1, F2]: 10454, 0 (+39.9 kHz, +0.0 kHz)
Guessing modulation: Single pulse detected. Probably Frequency Shift Keying or just noise...
Detected OOK package 2020-01-08 19:38:44
Analyzing pulses...
Total count: 1, width: 0.18 ms ( 44 S)
Pulse width distribution:
[ 0] count: 1, width: 176 us [176;176] ( 44 S)
Gap width distribution:
Pulse period distribution:
Level estimates [high, low]: 11990, 191
RSSI: -1.4 dB SNR: 18.0 dB Noise: -19.3 dB
Frequency offsets [F1, F2]: 13002, 0 (+49.6 kHz, +0.0 kHz)
Guessing modulation: Single pulse detected. Probably Frequency Shift Keying or just noise...
Detected OOK package 2020-01-08 19:39:25
Analyzing pulses...
Total count: 1, width: 0.07 ms ( 17 S)
Pulse width distribution:
[ 0] count: 1, width: 68 us [68;68] ( 17 S)
Gap width distribution:
Pulse period distribution:
Level estimates [high, low]: 3127, 387
RSSI: -7.2 dB SNR: 9.1 dB Noise: -16.3 dB
Frequency offsets [F1, F2]: 881, 0 (+3.4 kHz, +0.0 kHz)
Guessing modulation: Single pulse detected. Probably Frequency Shift Keying or just noise...
Detected OOK package 2020-01-08 19:39:26
Analyzing pulses...
Total count: 1, width: 0.06 ms ( 14 S)
Pulse width distribution:
[ 0] count: 1, width: 56 us [56;56] ( 14 S)
Gap width distribution:
Pulse period distribution:
Level estimates [high, low]: 1000, 64
RSSI: -12.1 dB SNR: 11.9 dB Noise: -24.0 dB
Frequency offsets [F1, F2]: 206, 0 (+0.8 kHz, +0.0 kHz)
Guessing modulation: Single pulse detected. Probably Frequency Shift Keying or just noise...
- Disconnected the antenna (the RTL-SDR dongle still connected to the pi but the antenna on the end of the dongle was removed).
- No updates in the terminal. The sensor is about 10-14 feet from the raspberry pi that I opened/closed.
If I do the same steps as above but leave the antenna plugged in:
pi@sdr:~ $ rtl_433 -A
rtl_433 version 19.08-3-g04e818a branch master at 201909021329 inputs file rtl_tcp RTL-SDR
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "rtl_433.conf"...
Trying conf file at "/home/pi/.config/rtl_433/rtl_433.conf"...
Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"...
Trying conf file at "/etc/rtl_433/rtl_433.conf"...
Consider using "-M newmodel" to transition to new model keys. This will become the default someday.
A table of changes and discussion is at https://github.com/merbanan/rtl_433/pull/986.
Registered 106 out of 136 device decoding protocols [ 1-4 8 11-12 15-17 19-21 23 25-26 29-36 38-60 63 67-71 73-100 102-103 108-116 119 121 124-128 131-136 ]
Found Rafael Micro R820T tuner
Exact sample rate is: 250000.000414 Hz
[R82XX] PLL not locked!
Sample rate set to 250000 S/s.
Tuner gain set to Auto.
Tuned to 433.920MHz.
Allocating 15 zero-copy buffers
Detected OOK package 2020-01-08 19:46:25
Analyzing pulses...
Total count: 1, width: 0.17 ms ( 43 S)
Pulse width distribution:
[ 0] count: 1, width: 172 us [172;172] ( 43 S)
Gap width distribution:
Pulse period distribution:
Level estimates [high, low]: 12158, 208
RSSI: -1.3 dB SNR: 17.6 dB Noise: -18.9 dB
Frequency offsets [F1, F2]: 11767, 0 (+44.9 kHz, +0.0 kHz)
Guessing modulation: Single pulse detected. Probably Frequency Shift Keying or just noise...
Detected OOK package 2020-01-08 19:46:25
Analyzing pulses...
Total count: 1, width: 0.17 ms ( 43 S)
Pulse width distribution:
[ 0] count: 1, width: 172 us [172;172] ( 43 S)
Gap width distribution:
Pulse period distribution:
Level estimates [high, low]: 12146, 202
RSSI: -1.3 dB SNR: 17.8 dB Noise: -19.1 dB
Frequency offsets [F1, F2]: 10872, 0 (+41.5 kHz, +0.0 kHz)
Guessing modulation: Single pulse detected. Probably Frequency Shift Keying or just noise...
Detected FSK package 2020-01-08 19:46:40
Analyzing pulses...
Total count: 69, width: 74.74 ms (18684 S)
Pulse width distribution:
[ 0] count: 1, width: 0 us [0;0] ( 0 S)
[ 1] count: 40, width: 208 us [196;252] ( 52 S)
[ 2] count: 7, width: 416 us [416;416] ( 104 S)
[ 3] count: 10, width: 620 us [620;624] ( 155 S)
[ 4] count: 8, width: 880 us [832;1040] ( 220 S)
[ 5] count: 2, width: 1144 us [1040;1248] ( 286 S)
[ 6] count: 1, width: 8 us [8;8] ( 2 S)
Gap width distribution:
[ 0] count: 1, width: 112 us [112;112] ( 28 S)
[ 1] count: 39, width: 204 us [168;216] ( 51 S)
[ 2] count: 13, width: 412 us [384;420] ( 103 S)
[ 3] count: 3, width: 832 us [832;832] ( 208 S)
[ 4] count: 6, width: 624 us [624;628] ( 156 S)
[ 5] count: 4, width: 1720 us [1464;1876] ( 430 S)
[ 6] count: 1, width: 1044 us [1044;1044] ( 261 S)
[ 7] count: 1, width: 20064 us [20064;20064] (5016 S)
Pulse period distribution:
[ 0] count: 1, width: 112 us [112;112] ( 28 S)
[ 1] count: 27, width: 416 us [412;420] ( 104 S)
[ 2] count: 12, width: 624 us [624;628] ( 156 S)
[ 3] count: 6, width: 1316 us [1248;1460] ( 329 S)
[ 4] count: 14, width: 936 us [832;1044] ( 234 S)
[ 5] count: 6, width: 1840 us [1664;2084] ( 460 S)
[ 6] count: 1, width: 2708 us [2708;2708] ( 677 S)
[ 7] count: 1, width: 21104 us [21104;21104] (5276 S)
Level estimates [high, low]: 15903, 112
RSSI: -0.1 dB SNR: 21.5 dB Noise: -21.6 dB
Frequency offsets [F1, F2]: 8338, -3473 (+31.8 kHz, -13.2 kHz)
Guessing modulation: No clue...
Detected FSK package 2020-01-08 19:46:42
Analyzing pulses...
Total count: 67, width: 54.41 ms (13603 S)
Pulse width distribution:
[ 0] count: 1, width: 60 us [60;60] ( 15 S)
[ 1] count: 39, width: 208 us [196;212] ( 52 S)
[ 2] count: 7, width: 416 us [416;416] ( 104 S)
[ 3] count: 10, width: 624 us [620;628] ( 156 S)
[ 4] count: 7, width: 860 us [832;1036] ( 215 S)
[ 5] count: 3, width: 1108 us [1040;1248] ( 277 S)
Gap width distribution:
[ 0] count: 39, width: 208 us [204;220] ( 52 S)
[ 1] count: 13, width: 416 us [412;420] ( 104 S)
[ 2] count: 4, width: 884 us [832;1044] ( 221 S)
[ 3] count: 6, width: 624 us [624;628] ( 156 S)
[ 4] count: 4, width: 1720 us [1460;1880] ( 430 S)
Pulse period distribution:
[ 0] count: 1, width: 280 us [280;280] ( 70 S)
[ 1] count: 26, width: 416 us [408;420] ( 104 S)
[ 2] count: 12, width: 624 us [624;628] ( 156 S)
[ 3] count: 12, width: 1180 us [1040;1460] ( 295 S)
[ 4] count: 8, width: 856 us [832;1036] ( 214 S)
[ 5] count: 6, width: 1840 us [1668;2088] ( 460 S)
[ 6] count: 1, width: 2708 us [2708;2708] ( 677 S)
Level estimates [high, low]: 15935, 6
RSSI: -0.1 dB SNR: 33.6 dB Noise: -33.7 dB
Frequency offsets [F1, F2]: 5044, -4840 (+19.2 kHz, -18.5 kHz)
Guessing modulation: No clue...
Detected FSK package 2020-01-08 19:46:44
Analyzing pulses...
Total count: 68, width: 74.76 ms (18690 S)
Pulse width distribution:
[ 0] count: 1, width: 328 us [328;328] ( 82 S)
[ 1] count: 39, width: 208 us [204;256] ( 52 S)
[ 2] count: 7, width: 416 us [416;424] ( 104 S)
[ 3] count: 10, width: 624 us [624;624] ( 156 S)
[ 4] count: 6, width: 828 us [828;832] ( 207 S)
[ 5] count: 4, width: 1088 us [1036;1248] ( 272 S)
[ 6] count: 1, width: 8 us [8;8] ( 2 S)
Gap width distribution:
[ 0] count: 38, width: 204 us [196;212] ( 51 S)
[ 1] count: 1, width: 160 us [160;160] ( 40 S)
[ 2] count: 13, width: 416 us [416;420] ( 104 S)
[ 3] count: 4, width: 888 us [836;1044] ( 222 S)
[ 4] count: 6, width: 624 us [624;628] ( 156 S)
[ 5] count: 4, width: 1720 us [1460;1880] ( 430 S)
[ 6] count: 1, width: 20076 us [20076;20076] (5019 S)
Pulse period distribution:
[ 0] count: 13, width: 616 us [540;628] ( 154 S)
[ 1] count: 26, width: 416 us [404;428] ( 104 S)
[ 2] count: 13, width: 1168 us [1036;1460] ( 292 S)
[ 3] count: 7, width: 832 us [832;836] ( 208 S)
[ 4] count: 6, width: 1840 us [1664;2084] ( 460 S)
[ 5] count: 1, width: 2708 us [2708;2708] ( 677 S)
[ 6] count: 1, width: 21112 us [21112;21112] (5278 S)
Level estimates [high, low]: 15904, 181
RSSI: -0.1 dB SNR: 19.4 dB Noise: -19.5 dB
Frequency offsets [F1, F2]: 8099, -4570 (+30.9 kHz, -17.4 kHz)
Guessing modulation: No clue...
Detected FSK package 2020-01-08 19:46:50
Analyzing pulses...
Total count: 77, width: 74.73 ms (18683 S)
Pulse width distribution:
[ 0] count: 1, width: 0 us [0;0] ( 0 S)
[ 1] count: 51, width: 208 us [180;252] ( 52 S)
[ 2] count: 12, width: 416 us [416;424] ( 104 S)
[ 3] count: 4, width: 624 us [624;628] ( 156 S)
[ 4] count: 5, width: 880 us [832;1040] ( 220 S)
[ 5] count: 2, width: 1140 us [1040;1244] ( 285 S)
[ 6] count: 1, width: 1660 us [1660;1660] ( 415 S)
[ 7] count: 1, width: 24 us [24;24] ( 6 S)
Gap width distribution:
[ 0] count: 3, width: 156 us [136;168] ( 39 S)
[ 1] count: 45, width: 204 us [188;216] ( 51 S)
[ 2] count: 12, width: 412 us [372;420] ( 103 S)
[ 3] count: 4, width: 832 us [832;836] ( 208 S)
[ 4] count: 8, width: 624 us [624;628] ( 156 S)
[ 5] count: 3, width: 1656 us [1460;1876] ( 414 S)
[ 6] count: 1, width: 20048 us [20048;20048] (5012 S)
Pulse period distribution:
[ 0] count: 1, width: 136 us [136;136] ( 34 S)
[ 1] count: 33, width: 416 us [396;420] ( 104 S)
[ 2] count: 19, width: 624 us [616;632] ( 156 S)
[ 3] count: 5, width: 1332 us [1248;1460] ( 333 S)
[ 4] count: 11, width: 868 us [832;1040] ( 217 S)
[ 5] count: 5, width: 1912 us [1668;2084] ( 478 S)
[ 6] count: 1, width: 2500 us [2500;2500] ( 625 S)
[ 7] count: 1, width: 20672 us [20672;20672] (5168 S)
Level estimates [high, low]: 15988, 178
RSSI: -0.1 dB SNR: 19.5 dB Noise: -19.6 dB
Frequency offsets [F1, F2]: 8888, -3506 (+33.9 kHz, -13.4 kHz)
Guessing modulation: No clue...
Detected FSK package 2020-01-08 19:46:51
Analyzing pulses...
Total count: 75, width: 54.41 ms (13602 S)
Pulse width distribution:
[ 0] count: 1, width: 56 us [56;56] ( 14 S)
[ 1] count: 50, width: 208 us [200;212] ( 52 S)
[ 2] count: 12, width: 416 us [416;420] ( 104 S)
[ 3] count: 4, width: 620 us [620;624] ( 155 S)
[ 4] count: 4, width: 832 us [832;832] ( 208 S)
[ 5] count: 3, width: 1108 us [1040;1244] ( 277 S)
[ 6] count: 1, width: 1664 us [1664;1664] ( 416 S)
Gap width distribution:
[ 0] count: 47, width: 204 us [204;216] ( 51 S)
[ 1] count: 12, width: 416 us [416;420] ( 104 S)
[ 2] count: 4, width: 832 us [832;836] ( 208 S)
[ 3] count: 8, width: 624 us [624;628] ( 156 S)
[ 4] count: 3, width: 1668 us [1460;1876] ( 417 S)
Pulse period distribution:
[ 0] count: 1, width: 272 us [272;272] ( 68 S)
[ 1] count: 32, width: 416 us [412;420] ( 104 S)
[ 2] count: 19, width: 624 us [624;628] ( 156 S)
[ 3] count: 5, width: 1328 us [1244;1460] ( 332 S)
[ 4] count: 9, width: 832 us [828;836] ( 208 S)
[ 5] count: 5, width: 1916 us [1668;2084] ( 479 S)
[ 6] count: 1, width: 2500 us [2500;2500] ( 625 S)
[ 7] count: 2, width: 1040 us [1040;1040] ( 260 S)
Level estimates [high, low]: 15881, 7
RSSI: -0.1 dB SNR: 33.0 dB Noise: -33.1 dB
Frequency offsets [F1, F2]: 5095, -3490 (+19.4 kHz, -13.3 kHz)
Guessing modulation: No clue...
Detected FSK package 2020-01-08 19:46:53
Analyzing pulses...
Total count: 76, width: 74.45 ms (18613 S)
Pulse width distribution:
[ 0] count: 1, width: 76 us [76;76] ( 19 S)
[ 1] count: 50, width: 208 us [204;256] ( 52 S)
[ 2] count: 12, width: 416 us [416;420] ( 104 S)
[ 3] count: 4, width: 624 us [620;640] ( 156 S)
[ 4] count: 4, width: 828 us [828;832] ( 207 S)
[ 5] count: 3, width: 1104 us [1036;1244] ( 276 S)
[ 6] count: 1, width: 1708 us [1708;1708] ( 427 S)
[ 7] count: 1, width: 40 us [40;40] ( 10 S)
Gap width distribution:
[ 0] count: 47, width: 204 us [156;208] ( 51 S)
[ 1] count: 12, width: 408 us [368;420] ( 102 S)
[ 2] count: 4, width: 836 us [836;836] ( 209 S)
[ 3] count: 8, width: 616 us [580;628] ( 154 S)
[ 4] count: 3, width: 1668 us [1460;1880] ( 417 S)
[ 5] count: 1, width: 20040 us [20040;20040] (5010 S)
Pulse period distribution:
[ 0] count: 1, width: 232 us [232;232] ( 58 S)
[ 1] count: 32, width: 412 us [400;420] ( 103 S)
[ 2] count: 19, width: 620 us [608;628] ( 155 S)
[ 3] count: 5, width: 1332 us [1248;1460] ( 333 S)
[ 4] count: 11, width: 872 us [828;1044] ( 218 S)
[ 5] count: 5, width: 1916 us [1668;2088] ( 479 S)
[ 6] count: 1, width: 2500 us [2500;2500] ( 625 S)
[ 7] count: 1, width: 20664 us [20664;20664] (5166 S)
Level estimates [high, low]: 15938, 121
RSSI: -0.1 dB SNR: 21.2 dB Noise: -21.3 dB
Frequency offsets [F1, F2]: 12734, -5773 (+48.6 kHz, -22.0 kHz)
Guessing modulation: No clue...
Detected OOK package 2020-01-08 19:46:54
Analyzing pulses...
Total count: 1, width: 0.04 ms ( 10 S)
Pulse width distribution:
[ 0] count: 1, width: 40 us [40;40] ( 10 S)
Gap width distribution:
Pulse period distribution:
Level estimates [high, low]: 1000, 123
RSSI: -12.1 dB SNR: 9.1 dB Noise: -21.2 dB
Frequency offsets [F1, F2]: -572, 0 (-2.2 kHz, +0.0 kHz)
Guessing modulation: Single pulse detected. Probably Frequency Shift Keying or just noise...
Ok, run rtl_433 -S unknown to save a few sample signals. And then post them here.
g001 and g002 were immediate captures. g003-g006 were from after I opened and then closed the entry sensor.
rtl_433 -X "n=doorbell,m=FSK_PCM,s=204,l=204,r=7000,g=1000,preamble=0x5526" might give the proper decoded bits. The preamble sync might need to be adjusted.
codes : {257}16a3bc2c04013ea26bd01e0030cae222ffd842634d89ef7574da7286000000000
codes : {257}16a3bc2c04013ea26bd01e0030cae222ffd842634d89ef7574da7286000000000
codes : {256}16a3bc2c04013ea26bd21e0103b1a07f861673b5d1c531fa0bcd269c00000000
codes : {256}16a3bc2c04013ea26bd21e0103b1a07f861673b5d1c531fa0bcd269c00000000
codes : {256}16a3bc2c04013ea26bd21e0103b1a07f861673b5d1c531fa0bcd269c00000000
After that you need to figure out the meaning of the different bits by varying states and comparing different sensors with each other.
Worth not is also that the recorded signals are distorted. Reduce the gain some.
I am pulling back data now. I will compare this data to itself after opening/closing multiple times and to other sensors and see if I can find a pattern where I can determine which sensor is which and the status (OPEN/CLOSE) of each sensor.
Is there a way to tell what gain it selected automatically so that I can reduce it manually as you mentioned (using the -g flag)?
Thank you very much for all your help - this is super helpful!
Be sure to closely look at the signal, if it's Simplisafe the modulation should be PIWM. The captures look more like PCM though.
Is there a way to tell what gain it selected automatically so that I can reduce it manually as you mentioned (using the -g flag)?
No.
Thank you all for the help. Here is an update. I am getting data and can tell which device is which. Figuring out the status (OPEN/CLOSED) is more difficult. For now, I am going to go under the impression that if it is currently closed and I get a signal for that sensor, then I can assume open - same vice versa. Once I get this data into my application, I am going to move on to the keypad (capture alarm status: home, away, or off) and then maybe come back to trying to decode the status of the entry sensors. Here is the data.
Here is the data from the screenshot above.
16a3bc2c04013ea26bd41e019a2ef5f05739b7be716dfe78713e8bda000000000
16a3bc2c04013ea26bde1e014d2860ef9cca9c2d6de3f671480d2922000000000
16a3bc2c04013ea26be21e00f36b1f5cb5dc42d878c000bdcdd07e9a000000000
16a3bc2c04013ea26be61e002cd4a5227c542a0282acd91c494dc0d6000000000
16a3bc2c04013ea26bd61e00afe48d1229cd4cd87b14ac2d49c0223400000000
16a3bc2c04013ea26be01e01d415cefbd5a08d28b77dbe91793de876000000000
16a3bc2c04013ea26be41e0123ce6a3e41d20bfc4c36099ca164059000000000
16a3bc2c04013ea26be81e01c9f496e42c2bafdb99f914c1ede0471a000000000
16a3bc2c0400d1abac645601933165c5a8ebb3f85faf8b4971ed556000000000
16a3bc2c0400d1abac6a56003027364a9f207580f87e7e228814671000000000
16a3bc2c0400d1abac6e56010e668fce7e5e0ba8a3d1c71a569aa5da000000000
16a3bc2c0400d1abac7256004e677a2cdaacd30d94fdcc312f1f0c8400000000
16a3bc2c0400d1abac6656017f5bb6466380920c2c36c62f1cf04ac00000000
16a3bc2c0400d1abac6c5601e96734b74760a2f8a0cd07f4e7785b2000000000
16a3bc2c0400d1abac7056007f7bcb0bcf8a5342829f5f191163f49a000000000
16a3bc2c0400d1abac74560043cd769789294ef66aac61c279091400000000
16a3bc2c04013ea2a0922001733c1d4faba50b9ae1f0c5b01fd04abe000000000
16a3bc2c04013ea2a0962001d941c18d0fa20ff704db27e54caef1fc00000000
16a3bc2c04013ea2a09a2000d0bd8db71c7cb34324d1b59efcbfe25a000000000
16a3bc2c04013ea2a09e20010c4fa918feb245938521be220886357400000000
16a3bc2c04013ea2a0942001e71b517b2549dc5495efe2d7620cc6ae000000000
16a3bc2c04013ea2a0982000e39586ddd8d75da262a30a405d2c6c26000000000
16a3bc2c04013ea2a09c2000c0f08f947df1af5afbfbfafde7287926000000000
16a3bc2c04013ea2a0a0200193050becf1b42d52c463e40c7a285dbe000000000
Thanks again!
Maybe a BitBench can help to structure the data. There could be plain data and a MAC, or some of the data could be encrypted.
Nice find with the counter. I would say the id is the 4 bytes before the counter. But the random data after the second id guess is the real problem. This looks encrypted. I assume that the counter + id is used to encrypt the data.
A significant effort will be needed to figure out this. Some concrete things to test are:
- loop the counter to see if it creates the same data
- collide the loop counter from 2 sensors
- provide more data from the system, maybe they mention something about encryption in the manual
- open up the sensors and document the chips
Lots and lots of readings will be needed. Read up on the configuration files (conf/*) and start creating a decoding template.
Colliding the loop counters will tell if the encryption uses the id or only the counters.
4. open up the sensors and document the chips
Here is what the inside of a GEN 3 door sensor looks like:
I too am interested in support for the v3 sensors.
A couple people have had some success that may help some with these efforts:
- RadioDoor uses rtl_433
- v3 Teardown article and a PoC using a Yardstick one
That teardown is a great read! Additionally we did spot a counter, but there won't be any chance to decode the AES payload.
It seems the radiodoor project managed to get open/closed state without any decryption. I've only tested my motion sensors with the code and they seem to oscillate between two different values every time they're triggered.
Additionally we did spot a counter, but there won't be any chance to decode the AES payload.
It looks like someone has: https://github.com/tenable/poc/blob/983dcf94577b1a041f304c8e0537b670c0c18655/SimpliSafe/packet_decoder.py#L110
my motion sensors with the code and they seem to oscillate between two different values every time they're triggered.
That's not visible in the list of codes we have above. Can you capture codes and show an example?
Yeah that packet decoder came from the teardown where they wrote their own AES key to the sensor I believe.
Here is me cycling an entry sensor with that radiodoor script. I've dropped the first digit from the device ID because it seems to be garbled/random at times. The sensors send 3 messages if all is working well.
Length: 358
Device ID: 5555554985a8ef0b0100a1fa5f
Codes sent: 38b8039a358039e708a891dcb7d832375a2bf8000000000000000000000000
8b80
New data!
Length: 358
Device ID: 5555554985a8ef0b0100a1fa5f
Codes sent: 38b8039a358039e708a891dcb7d832375a2bf8000000000000000000000000
8b80
New data!
Length: 358
Device ID: 5555554985a8ef0b0100a1fa5f
Codes sent: 38b8039a358039e708a891dcb7d832375a2bf8000000000000000000000000
8b80
New data!
Length: 358
Device ID: 5555554985a8ef0b0100a1fa5f
Codes sent: 40b804889a97bbae35e94b8a94c5dadd42b918000000000000000000000000
0b80
New data!
Length: 358
Device ID: 5555554985a8ef0b0100a1fa5f
Codes sent: 40b804889a97bbae35e94b8a94c5dadd42b918000000000000000000000000
0b80
New data!
Length: 358
Device ID: 5555554985a8ef0b0100a1fa5f
Codes sent: 40b804889a97bbae35e94b8a94c5dadd42b918000000000000000000000000
0b80
New data!
Length: 358
Device ID: 5555554985a8ef0b0100a1fa5f
Codes sent: 48b80774191033992d11614fb45bf598e18eb8000000000000000000000000
8b80
New data!
Length: 358
Device ID: 5555554985a8ef0b0100a1fa5f
Codes sent: 48b80774191033992d11614fb45bf598e18eb8000000000000000000000000
8b80
New data!
Length: 358
Device ID: 5555554985a8ef0b0100a1fa5f
Codes sent: 48b80774191033992d11614fb45bf598e18eb8000000000000000000000000
8b80
I do not have a usb radio receiver yet ( my order is in process ).
From the comments in the code "# this one I got from my entry sensor firmware dump" - is it possible all the sensors use the same key ??
When you first install the sensor you push a button on the sensor....wondering if that button press sends the key so that it can be used to decode future signals.
Anyway here is the output from that decoder script:
=== PACKET DISSECTION === Packet : 1602007289cbfad2027d441c349698ab938ee973c0cd9f098d Length : 16 (22) Serial : 007289cb Counter : fad202 CMAC: : 7d441c34 Encrypted Data : 9698ab938ee973c0cd9f Chksum : 098d
Data Decryption: AES Call 1 Res : 931b85938e5073c0899fc2ba112f6b25 Decrypted Data : 05832e0000b900004400
CMAC Verify: AES Call 2 Res : 34d21f79bc403b8ccbaa7fb1585be8e2 LSFR Res1: 10e292d698e731bff897ec4458ba4fb2 CHK Data1 : 9698ab938ee973c0cd9f CHK Data2 : 867a3945160e427f3508ec4458ba4fb2 LSFR Res2: 6591a486ec54a4ee4b1c3d38c3b5cf37 LSFR Res2_xor: 6591a486ec54a46e4b1c3d38c3b5cf67 LSFR Res3: b2ee02cf2e485805329de21bbf2294e0 AES Call 3 Res : cfaa1efb0c408095ed27dc40eeae81f0 CHK Data3 (CALCULATED CMAC): 7d441c34 CMAC Match!
Checksum Verify: test: 0x98d Calculated Checksum:098d Checksum Verified!
Motion sensor dump. Hardware seems to have 150s cooldown before it will detect again. No clear value is ever sent. This is two sequential triggers from a single sensor.
New data!
Length: 357
Device ID: 5555554985a8ef0b0100c302dc
Codes sent: c0c0051b9d9617ef1301df51ad706af0d92268000000000000000000000000
0c00
New data!
Length: 357
Device ID: 5555554985a8ef0b0100c302dc
Codes sent: c0c0051b9d9617ef1301df51ad706af0d92268000000000000000000000000
0c00
New data!
Length: 358
Device ID: 5555554985a8ef0b0100c302dc
Codes sent: c0c0051b9d9617ef1301df51ad706af0d92268000000000000000000000000
0c00
New data!
Length: 358
Device ID: 5555554985a8ef0b0100c302dc
Codes sent: c8c005413316a75301e400b1a3b2ea31aa2218000000000000000000000000
8c00
New data!
Length: 358
Device ID: 5555554985a8ef0b0100c302dc
Codes sent: c8c005413316a75301e400b1a3b2ea31aa2218000000000000000000000000
8c00
New data!
Length: 358
Device ID: 5555554985a8ef0b0100c302dc
Codes sent: c8c005413316a75301e400b1a3b2ea31aa2218000000000000000000000000
8c00
@mores drop in some of the codes from the list above and check if those decode also. (I don't have any Python2 readily available anymore)
@giantorth here is your data as BitBench, note the raw codes (starting 5555) need to be aligned to 5526 and thus shift by two bits. The "toggle bytes" are not aligned -- play with the BitBench to find a good pattern. But it could well be that's it's just the high order bits of the counter we suspect. The visible toggle is suspicious though.
Results not very promising:
16a3bc2c04013ea26bd41e019a2ef5f05739b7be716dfe78713e8bda000000000
=== PACKET DISSECTION === Packet : 16a3bc2c04013ea26bd41e019a2ef5f05739b7be716dfe78713e8bda Length : 16 (22) Serial : bc2c0401 Counter : 3ea26b CMAC: : d41e019a Encrypted Data : 2ef5f05739b7be716dfe Chksum : 8bda
No key found to decrypt or verify CMAC
Checksum Verify: test: 0x13df Calculated Checksum:13df Bad Checksum!
16a3bc2c04013ea26bde1e014d2860ef9cca9c2d6de3f671480d2922000000000
=== PACKET DISSECTION === Packet : 16a3bc2c04013ea26bde1e014d2860ef9cca9c2d6de3f671480d2922 Length : 16 (22) Serial : bc2c0401 Counter : 3ea26b CMAC: : de1e014d Encrypted Data : 2860ef9cca9c2d6de3f6 Chksum : 2922
No key found to decrypt or verify CMAC
Checksum Verify: test: 0xb455 Calculated Checksum:b455 Bad Checksum!
dropped the first digit from the device ID because it seems to be garbled/random at times.
To clear that up, the 5555 is a preamble. It ends in 5526. This is used to wake-up train the timing and align the start of data. It does not need to be received perfectly.
@mores you might need to copy the key to use with that serial, i.e. encr_keys = { '\x00\x72\x89\xcb': ... needs to be encr_keys = { '\xbc\x2c\x04\x01': ...
Oh, I missed the "Counter, CMAC" hints there. I'll update the BitBench link.