Help identifying wireless doorbell signal

Get help identifying an unknown signal.
Post Reply
ilans1
Posts: 3
Joined: Tue Jul 26, 2016 10:47 pm

Help identifying wireless doorbell signal

Post by ilans1 » Tue Jul 26, 2016 10:53 pm

We are trying to capture the signal from a Honeywell (RCWL300a) wireless doorbell button using a RFM69 Adafruit Feather. However, the we've been unsuccessful in capturing anything yet. The button transmits at 916.8MhZ and we are listening at 915MhZ. The ultimate goal is to have the RFM69 transmit the signal that is captured from the button. Can anyone point us in the right direction?

rtlsdrblog
Site Admin
Posts: 1731
Joined: Mon Nov 19, 2012 11:54 pm

Re: Help identifying wireless doorbell signal

Post by rtlsdrblog » Wed Jul 27, 2016 10:33 am

Get an RTL-SDR and confirm that the doorbell is transmitting at the frequency which you expect.

Do you know what type of signal the doorbell is sending out, and are you sure the feather can even decode it?

ilans1
Posts: 3
Joined: Tue Jul 26, 2016 10:47 pm

Re: Help identifying wireless doorbell signal

Post by ilans1 » Wed Jul 27, 2016 3:01 pm

Well, we know it is transmitting at 916.8mhz. Do you know if the Feather can capture the signal if it is tuned to 915mhz? Im not familar enough with RF to know if that is possible. Assuming the Feather can capture this frequency, how could we get the Feather to replicate the signal?

rtlsdrblog
Site Admin
Posts: 1731
Joined: Mon Nov 19, 2012 11:54 pm

Re: Help identifying wireless doorbell signal

Post by rtlsdrblog » Wed Jul 27, 2016 10:30 pm

First of all you need to be sure that the doorbell and the feather speak the same protocol. You need to find out what protocol the doorbell uses. An RTL-SDR can be useful for this, but you will need some skill and understanding of waveforms to be able to understand what it is you're seeing. Do a search on rtl-sdr.com for "reverse engineering" and you'll see dozen of examples of the process, some even with doorbells. http://www.rtl-sdr.com/?s=doorbell

The adafruit feather page explains it nicely too: "The radios must be matched in frequency (e.g. 900 MHz & 900 MHz are ok, 900 MHz & 433 MHz are not). They also must use the same encoding schemes, you cannot have a 900 MHz RFM69 packet radio talk to a 900 MHz RFM96 LoRa radio."

Generally the process for a wireless doorbell would be something like 1) Reverse engineer and understand the wireless protocol with an RTL-SDR or logic analyzer, and/or looking up any available documentation/patents on the device for information about the protocol. 2) Program a micro with a wireless transceiver using your knowledge of the protocol.

Another device which may make reverse engineering protocols easier is the Yarstick One https://greatscottgadgets.com/yardstickone.

ilans1
Posts: 3
Joined: Tue Jul 26, 2016 10:47 pm

Re: Help identifying wireless doorbell signal

Post by ilans1 » Wed Jul 27, 2016 11:27 pm

honeywell.JPG
honeywell.JPG (228.13 KiB) Viewed 13456 times
Thank you. Can you tell anything from the attached label? Would the RFM69 (915mhz) be able to listen to the pushbutton at 916.8mhz with no tweaking?

tos7
Posts: 4
Joined: Sat Aug 27, 2016 12:45 pm

Re: Help identifying wireless doorbell signal

Post by tos7 » Sat Aug 27, 2016 3:24 pm

I'm trying to decode the same Honeywell doorbell.
http://www.honeywellstore.com/store/pro ... button.htm

There are some other models and options, as well as receiver kit
http://www.honeywellstore.com/store/cat ... chimes.htm

Within the button, there is a PIC Micro controller and a Transmitter chip.

PIC16F505
http://www.microchip.com/wwwproducts/en/PIC16F505
PIC16F505-pinout.png
PIC16F505 Pinout
PIC16F505-pinout.png (15.88 KiB) Viewed 12182 times
FSK Transmitter - 868/915 MHz TH72031
https://www.melexis.com/en/product/TH72 ... ransmitter



To check, I bought NooElec tiny 2, installed driver (downloaded from NooElec link),
and Used CubicSDR to confirm it's transmitting around 916.8MHz.
http://www.nooelec.com/store/sdr/nesdr-nano2.html
CubicSDDR_ps1.png
Transmission spectrum of Honeywell Doorbell with CubicSDR
CubicSDDR_ps1.png (838.4 KiB) Viewed 12182 times
I use CPU heat sink to cool down this dongle as it was very hot and unstable.
Other than (official) 916.8MHz, I saw transmission around 916.7, and 914.8 + 914.9 MHz, although a little less strong. Maybe it's normal for the type of modulation but I don't know well about these.


Then, I downloaded windows Binary of rtl_433.
http://cognito.me.uk/computers/rtl_433- ... ry-32-bit/

With this command, I'm getting some data:
rtl_433.exe -f 916800000 -A

Code: Select all

pulse_FSK_detect(): Maximum number of pulses reached!
Detected FSK package
Analyzing pulses...
Total count: 1200,  width: 148945		(595.8 ms)
Pulse width distribution:
 [ 0] count:    1,  width:     0 [ 0; 0]	(   0 us)
 [ 1] count:   25,  width:   119 [119;121]	( 476 us)
 [ 2] count:  448,  width:    79 [78;82]	( 316 us)
 [ 3] count:  726,  width:    39 [38;42]	( 156 us)
Gap width distribution:
 [ 0] count:    1,  width:  2065 [2065;2065]	(8260 us)
 [ 1] count:   25,  width:   121 [121;122]	( 484 us)
 [ 2] count:  448,  width:    40 [38;44]	( 160 us)
 [ 3] count:  725,  width:    80 [78;82]	( 320 us)
Pulse period distribution:
 [ 0] count:    1,  width:  2065 [2065;2065]	(8260 us)
 [ 1] count:   25,  width:   241 [240;242]	( 964 us)
 [ 2] count: 1173,  width:   120 [117;124]	( 480 us)
Level estimates [high, low]:  15960,     19
Frequency offsets [F1, F2]:    3537, -23504	(+13.5 kHz, -89.7 kHz)
Guessing modulation: Pulse Code Modulation (Not Return to Zero)
Attempting demodulation... short_limit: 39, long_limit: 39, reset_limit: 39936, demod_arg: 0
pulse_demod_pcm(): Analyzer Device 
bitbuffer:: Number of rows: 1 
[00] {640} 00 00 00 00 00 00 07 1b 6d b6 d3 6d 26 d3 6d 24 92 69 24 92 49 24 92 49 24 dc 6d b6 db 4d b4 9b 4d b4 92 49 a4 92 49 24 92 49 24 93 71 b6 db 6d 36 d2 6d 36 d2 49 26 92 49 24 92 49 24 92 4d c6 db 6d b4 db 49 b4 db 49 24 9a 49 24 92 49 24 92 
I pushed many times to see if the data changes, and it was always the same, so far.

Now, I don't know how to decode the data in the bitbuffer, yet.

Sorting the binary data, I get this, and 24 ($), 49(I), 6d (m), 92 seem to appear often.
['00', '00', '00', '00', '00', '00', '07', '1b', '24', '24', '24', '24', '24', '24', '24', '24', '24', '24', '24', '26', '26', '36', '36', '49', '49', '49', '49', '49', '49', '49', '49', '49', '49', '49', '49', '4d', '4d', '4d', '69', '6d', '6d', '6d', '6d', '6d', '6d', '6d', '71', '92', '92', '92', '92', '92', '92', '92', '92', '92', '92', '92', '93', '9a', '9b', 'a4', 'b4', 'b4', 'b4', 'b4', 'b6', 'b6', 'b6', 'c6', 'd2', 'd2', 'd3', 'd3', 'db', 'db', 'db', 'db', 'db', 'dc']


I guess I have to compare the data from a few different Dooorbell to identify which part is the ID of the unit.
Also, the unit might be sending the status, such as the battery information.
So, it would be interesting to hook up with DC power supply to check if the code change.

Other than that, I guess I can check what the PIC is doing and sending to the FSK transmitter chip.
This way, I can be sure of what I'm decoding matches what PIC is sending.

PS.

The Doorbell PIC uses Pin 13 to detect the push button.
Pin 13 is pulled up to 3.0V and goes down to 0V when button is pushed.
So, we can use this unit with any switch (or external device) and let it send the signal by pulling down the pin 13 to 0V.

There are through holes for soldering cable or pins, and one of them is connected to Pin 13 of the PIC, another one is GND (VSS). Very convenient.

tos7
Posts: 4
Joined: Sat Aug 27, 2016 12:45 pm

Re: Help identifying wireless doorbell signal

Post by tos7 » Sun Aug 28, 2016 4:16 pm

I decided to use cheap logic analyzer I bought some years ago and never really tried.
https://sigrok.org/wiki/MCU123_USBee_AX_Pro_clone

I spent some time figuring out which software to use and how to configure the device, and finally succeeded in using with Sigrok Pulseview. (I used Windows Binary.)
https://sigrok.org/wiki/Main_Page

I first installed CyUSB3.sys driver, manually modifying Vendor end product ID, but possibly I didn't have to do this if I used Zadig to install WinUSB Driver for Sigrok from the beginning.
And it's well explained in the Sigrok Wiki.


I hooked up the GND and FSK Data pin from PIC16F505 and got something like this, after using higher sampling rate.
PIC16F505-chart1.png
PIC16F505 Data input and output
PIC16F505-chart1.png (76.74 KiB) Viewed 12174 times
D0 is the Pin 10 (RC0) of PIC16F505 for FSK Data output. It goes to Pin 1 (FSKDTA) of TH72031.
D1 is pin 13 (RB0/ICSPDAT) on PIC16F505 and button input (after CR).
D2 is Pin 9 (RC1) on PIC and connected to Pin 4 (ENTX) of TH72031 FSK Transmitter.

Image
TH72031_pinout.png
TH72031 pinout
TH72031_pinout.png (29.81 KiB) Viewed 12174 times
So, when the button is pushed, I guess it waits and checks for the chattering and then triggers up ENTX to enable the transmitter (about 60 to 70ms for this).
Then, about 8ms after the ENTX and carrier wave starting, data is transmitted for about 1.2 second.
PIC16F505-chart1b.png
PIC16F505-chart1b.png (72.57 KiB) Viewed 12174 times

tos7
Posts: 4
Joined: Sat Aug 27, 2016 12:45 pm

Re: Help identifying wireless doorbell signal

Post by tos7 » Fri Sep 02, 2016 2:40 pm

I did a bit more tests and ended up writing rough decoder for this signal.


It is sending 50 frames of 6 bytes (0r 48 bits) data.
Each bit is coded by 110 (for 1) or 100 (for 0).
Each frame has 6 bit header made of 111000.

So, it looks like:

Code: Select all

Header   1   1   1   0   1   1  ......
111 000 110 110 110 100 110 110 ......
 
Each of these encoded bit is 160 micro seconds long.
So, we see lots of 160 or 320 us pulses.


Example of 48 bit fixed code (for my particular unit)
111111110111001101110000001000000000000000000001

In Hex:
FF 73 70 20 00 01

And the fixed code is repeated 50 times, for the total duration of 1.2 seconds.
(The last frame may lack the final bit, though.)


By using different sampling rate, I could get similar result (with a bit of noise) with rtl_433.
But I cannot reproduce the result after that.
I"m not sure what has changed, yet.

Code: Select all


./rtl_433.exe -f 916800000 -A -s 2500000 

pulse_FSK_detect(): Maximum number of pulses reached!
Detected FSK package
Analyzing pulses...
Total count: 1200,  width: 1489358              (595.7 ms)
Pulse width distribution:
 [ 0] count:    1,  width:     0 [ 0; 0]        (   0 us)
 [ 1] count:   28,  width:  1189 [1056;1208]    ( 476 us)
 [ 2] count:  445,  width:   798 [776;886]      ( 319 us)
 [ 3] count:  726,  width:   398 [381;408]      ( 159 us)
Gap width distribution:
 [ 0] count:    1,  width: 20632 [20632;20632]  (8253 us)
 [ 1] count:   25,  width:  1201 [1192;1227]    ( 480 us)
 [ 2] count:  449,  width:   402 [392;441]      ( 161 us)
 [ 3] count:  722,  width:   801 [715;816]      ( 320 us)
 [ 4] count:    2,  width:   528 [512;545]      ( 211 us)
Pulse period distribution:
 [ 0] count:    1,  width: 20632 [20632;20632]  (8253 us)
 [ 1] count:   25,  width:  2399 [2395;2404]    ( 960 us)
 [ 2] count: 1169,  width:  1201 [1118;1482]    ( 480 us)
 [ 3] count:    3,  width:   890 [804;950]      ( 356 us)
 [ 4] count:    1,  width:  1597 [1597;1597]    ( 639 us)
Level estimates [high, low]:  15891,    523
Frequency offsets [F1, F2]:     426,  -2971     (+16.3 kHz, -113.3 kHz)
Guessing modulation: Pulse Width Modulation with startbit/delimiter
Attempting demodulation... short_limit: 598, long_limit: 993, reset_limit: 20633                      , demod_arg: 2
pulse_demod_pwm_ternary(): Analyzer Device
bitbuffer:: Number of rows: 25
[00] {1} 00 : 0
[01] {48} ff 73 70 20 00 01 : 11111111 01110011 01110000 00100000 00000000 00000                      001
[02] {48} ff 73 70 20 00 01 : 11111111 01110011 01110000 00100000 00000000 00000                      001
[03] {48} ff 73 70 20 00 01 : 11111111 01110011 01110000 00100000 00000000 00000                      001
[04] {48} ff 73 70 20 00 01 : 11111111 01110011 01110000 00100000 00000000 00000                      001
[05] {48} ff 73 70 20 00 01 : 11111111 01110011 01110000 00100000 00000000 00000                      001
[06] {48} ff 73 70 20 00 01 : 11111111 01110011 01110000 00100000 00000000 00000                      001
[07] {17} ff 73 00 : 11111111 01110011 0
[08] {30} c0 80 00 04 : 11000000 10000000 00000000 000001
[09] {48} ff 73 70 20 00 01 : 11111111 01110011 01110000 00100000 00000000 00000                      001
[10] {48} ff 73 70 20 00 01 : 11111111 01110011 01110000 00100000 00000000 00000                      001
[11] {48} ff 73 70 20 00 01 : 11111111 01110011 01110000 00100000 00000000 00000                      001
[12] {48} ff 73 70 20 00 01 : 11111111 01110011 01110000 00100000 00000000 00000                      001
[13] {17} ff 73 00 : 11111111 01110011 0
[14] {30} c0 80 00 04 : 11000000 10000000 00000000 000001
[15] {48} ff 73 70 20 00 01 : 11111111 01110011 01110000 00100000 00000000 00000                      001
[16] {9} ff 00 : 11111111 0
[17] {38} cd c0 80 00 04 : 11001101 11000000 10000000 00000000 000001
[18] {48} ff 73 70 20 00 01 : 11111111 01110011 01110000 00100000 00000000 00000                      001
[19] {48} ff 73 70 20 00 01 : 11111111 01110011 01110000 00100000 00000000 00000                      001
[20] {48} ff 73 70 20 00 01 : 11111111 01110011 01110000 00100000 00000000 00000                      001
[21] {48} ff 73 70 20 00 01 : 11111111 01110011 01110000 00100000 00000000 00000                      001
[22] {48} ff 73 70 20 00 01 : 11111111 01110011 01110000 00100000 00000000 00000                      001
[23] {48} ff 73 70 20 00 01 : 11111111 01110011 01110000 00100000 00000000 00000                      001
[24] {214} ff 73 70 20 00 01 ff 73 70 20 00 01 ff 73 70 20 00 01 ff 73 70 20 00                       01 ff 73 70

Anyway, I do think it's possible to decode and identify these Honeywell door bell,
and I'm now thinking the easiest and most robust way to do so.

I've already ordered transceiver module with FSK modulation, and I'll try to use it with one of Arduino type board or raspberry type thing.

tos7
Posts: 4
Joined: Sat Aug 27, 2016 12:45 pm

Re: Help identifying wireless doorbell signal

Post by tos7 » Wed Nov 29, 2017 6:27 pm

I'm adding this post as someone asked if I had finish decoded Honeywell door chime:

Basically, each unit seems to send its own ID 50 times.
Possibly, the last digit of the ID code is battery status, but I'm not sure.

I simply used windows 7-64bit PC with NooElec NESDR Nano 2 to receive the signal:

NooElec NESDR Nano 2: Tiny RTL-SDR USB Set w/ R820T2 Tuner, Antenna and Remote Control
http://www.nooelec.com/store/sdr/nesdr-nano2.html

And I used rtl_433 to decode the signal:

Github
https://github.com/merbanan/rtl_433

Windows Binary
http://cognito.me.uk/computers/rtl_433- ... ry-32-bit/


When rtl_433 decode with pulse_demod_pwm_ternary(), it output correct data.
But somehow, it uses pulse_demod_pcm(), and I didn't find the way to force pulse_demod_pwm_ternary().
So, I wrote a script to parse the output to get same output from either one.

Here is the command line I used and some output from different door chime units.
I used with cygwin, but it can be done in dos command window, as well.

Code: Select all

$ ./rtl_433.exe -f 916800000   -z 58 -x 99 -A 2>&1 | python getdat.py
Starting. Use Ctrl-C to stop.

Front Door:

2016-09-13 00:21:29.640323 pulse_demod_pcm() 15803 1393
ed 67 10 20 00 01 : 11101101 01100111 00010000 00100000 00000000 00000001

2016-09-13 00:21:41.171983 pulse_demod_pcm() 15848 1606
ed 67 10 20 00 01 : 11101101 01100111 00010000 00100000 00000000 00000001



PIR Motion sensor stair:

2016-09-13 00:23:15.025351 pulse_demod_pwm_ternary() 15885 851
30 93 90 10 00 01 : 00110000 10010011 10010000 00010000 00000000 00000001

2016-09-13 00:23:19.741621 pulse_demod_pwm_ternary() 15855 954
30 93 90 10 00 01 : 00110000 10010011 10010000 00010000 00000000 00000001



Back door: (Final digit 0 = battery is low?)

2016-09-13 00:23:42.806940 pulse_demod_pcm() 15914 674
ff 50 80 20 00 00 : 11111111 01010000 10000000 00100000 00000000 00000000

2016-09-13 00:23:51.719450 pulse_demod_pcm() 15968 888
ff 50 80 20 00 00 : 11111111 01010000 10000000 00100000 00000000 00000000

2016-09-13 00:23:53.817570 pulse_demod_pcm() 15895 667
ff 50 80 20 00 00 : 11111111 01010000 10000000 00100000 00000000 00000000


Elevator:

2016-09-13 00:24:20.555099 pulse_demod_pcm() 15896 1112
ff 18 50 20 00 01 : 11111111 00011000 01010000 00100000 00000000 00000001

Suite:

ff 73 70 20 00 01 : 11111111 01110011 01110000 00100000 00000000 00000001

And this is the python script I wrote (get_dat.py):

Code: Select all

#!/usr/bin/env python

import sys
stdin = sys.__stdin__
stdout = sys.__stdout__

import datetime

now = datetime.datetime.now

##pulse_FSK_detect(): Maximum number of pulses reached!
##Detected FSK package
##Analyzing pulses...
##Total count: 1200,  width: 148961               (595.8 ms)
##Pulse width distribution:
## [ 0] count:    1,  width:     0 [ 0; 0]        (   0 us)
## [ 1] count:   25,  width:   118 [118;119]      ( 472 us)
## [ 2] count:  448,  width:    78 [78;80]        ( 312 us)
## [ 3] count:  726,  width:    38 [38;40]        ( 152 us)
##Gap width distribution:
## [ 0] count:    1,  width:  2059 [2059;2059]    (8236 us)
## [ 1] count:   25,  width:   121 [121;122]      ( 484 us)
## [ 2] count:  448,  width:    41 [40;45]        ( 164 us)
## [ 3] count:  725,  width:    81 [81;82]        ( 324 us)
##Pulse period distribution:
## [ 0] count:    1,  width:  2059 [2059;2059]    (8236 us)
## [ 1] count:   25,  width:   240 [240;241]      ( 960 us)
## [ 2] count: 1173,  width:   120 [119;124]      ( 480 us)
# Level estimates [high, low]:  15945,     41
##Frequency offsets [F1, F2]:   13531, -11963     (+51.6 kHz, -45.6 kHz)
##Guessing modulation: Pulse Width Modulation with startbit/delimiter
##Attempting demodulation... short_limit: 58, long_limit: 98, reset_limit: 2060, demod_arg: 2
# pulse_demod_pwm_ternary(): Analyzer Device
##bitbuffer:: Number of rows: 25
# [00] {1} 00 : 0
# [01] {48} ff 73 70 20 00 01 : 11111111 01110011 01110000 00100000 00000000 00000001

# ######### #

# pulse_demod_pcm()
# [00] {640} 00 00 00 00 00 00 07 1b 6d b6 d3 6d 26 d3 6d 24 92 69 24 92 49 24 92 49 24 dc 6d b6 db 4d b4 9b 4d b4 92 49 a4 92 49 24 92 49 24 93 71 b6 db 6d 36 d2 6d 36 d2 49 26 92 49 24 92 49 24 92 4d c6 db 6d b4 db 49 b4 db 49 24 9a 49 24 92 49 24 92

print 'Starting. Use Ctrl-C to stop.'

def hex2b(h):
    try:
        return format(int(h,16),'0>8b')
    except:
        return ''

def rtl_433_wl330a(dat):
    l = dat.split(' ')      # make a list of each byte
    l2 = map(hex2b, l[3:])  # remove header and convert to binary
    s = ''.join(l2)         # glue all bytes
    frl = s.split('111000') # split with frame header to have a list of frames
##    print 'len(frl) =',len(frl)
##    print frl
    rb = []
    rh = []
    rr = []
    fi=-1
    for f in frl:
        fi += 1
        if len(f) < 40:     # Skip if frame is less than 40 bits
            continue

##        print f
        if f[0] != '1':     # Adjust frame if it's misaligned
            f = f[1:]
##            print 'frame ajusted 1'
            if f[0] != '1':
                f = f[1:]
##                print 'frame ajusted 2'
                if f[0] != '1': # Skip bad data
                    print 'Bad frame data'
                    continue
        r = []
        i=0
        last = len(f)
        try:
            while i < last:     # Convert 110 and 100 to 1 and 0
                if f[i] != '1' or f[i+2] != '0': # Check Star and stop bit
                        print 'Error in frame',fi, f[i:i+3], i, f[i] == '1', f[i+2] == '0'
                        print  ' '.join(s[i:i+3] for i in range(0, len(f), 3))
##                        return ''
                        break

                r.append( f[i+1])   # append 2nd bit (that shows 1 or 0)
                i += 3
        except:
            pass
        s = ''.join(r)
        if not s:
            continue
        rb.append(s)
##        print s                     # Print binary
        rh.append(hex(int(s,2)))
##        print rh[-1]                # Print hex
        sh = rh[-1][2:-1]
##        print sh
        sh = ' '.join(a+b for a,b in zip(sh[::2], sh[1::2]))
##        print sh
        sb = ' '.join(s[i:i+8] for i in range(0, len(s), 8))
        rr.append(sh +' : ' + sb)

    r0 = rr[0]
    i = 1
    for rn in rr[1:-1]:
        if r0 == rn:
            i += 1
##            print 'i =', i, '  len(r) = ', len(r), i*1.0 / len(r)
##            print r0.strip()
    if (i*1.0 / len(rr)) > 0.5:
        return r0.strip()
    else:
        print i*1.0 / len(rr)
        return rr

def get_dat():
    r = []
    don = False
    while 1:
        l = stdin.readline()
        lenl = len(l)
        if lenl > 44 and l[:15] == 'Level estimates':
            lh,ll = l[29:].split(',')
            lh = lh.strip()
            ll = ll.strip()
        elif lenl > 80 and l[0] == '[':
##            print l[3:10]
            if l[3:10] == '] {48} ': # pulse_demod_pwm_ternary()
                r.append(l[10:])
                don = True
            elif  l[3:11] == '] {640} ': # pulse_demod_pcm()
                print now(), 'pulse_demod_pcm()', lh, ll
                return rtl_433_wl330a(l[11:])

        elif don:
            don = False
            if not r:
                continue
            print now(), 'pulse_demod_pwm_ternary()', lh, ll
            r0 = r[0]
            i = 0
            for rn in r[1:]:
                if r0 == rn:
                    i += 1
##            print 'i =', i, '  len(r) = ', len(r), i*1.0 / len(r)
##            print r0.strip()
            if (i*1.0 / len(r)) > 0.5:
                return r0.strip()
            r = []



def main():
    while 1:
        r = get_dat()
        print r
    pass

if __name__ == '__main__':
    main()

kwl3
Posts: 1
Joined: Thu Feb 22, 2018 8:54 am

Re: Help identifying wireless doorbell signal

Post by kwl3 » Thu Feb 22, 2018 9:39 am

After much trial and error, I'm having great success using this command to detect the doorbells I use for my Honeywell RDWL917AX2000/E Series 9 Portable Wireless Doorbell (https://amzn.com/B01HNSFTBQ).

This command seems to work fine with the two Honeywell RPWL400W2000/a Series 3, 5, 9 Wireless Doorbell Push Button with Halo Light (https://amzn.com/dp/B01LXKH0ED) that I own.

Code: Select all


rtl_433.exe -f 916800000 -q -X "Honeywell Doorbell:FSK_PCM:160:160:340,bits=149,match={4}0xe"

I'm using a NooElec NESDR SMArt RTL-SDR (https://amzn.com/B01GDN1T4S) with recent build of RTL_433 (version 0.1-395-g253ce21 branch master at 201802172245) from https://cognito.me.uk/computers/rtl_433 ... ry-32-bit/.

Each press of a doorbell gets detected with its unique code about 48 times over a couple seconds!

--Karl.

Post Reply