This ia an attempt to capture and decode the signals used by the Honeywell ActivLink family of devices. These devices are primarily wireless doorbell and PIR motion detector systems in North America and and operate at 916.5 MHz. Honeywell also uses this signal at 916.5 in Australia. In European countries, it operates at 868.3 MHz and the family of devices also include door/window sensors and home alarm kits.
There's some indication that this protocol may be based on the Friedland / Response 868MHz alarm system. This page indicates that the 868MHz variants of the Honeywell ActivLink system is compatible with the Friedland Libra+ Wirefree Doorbell system.
These devices are dissimilar to many other simple wireless doorbell systems in several ways. They operate on a much higher frequency than most other wireless doorbells, use FSK modulation instead of ASK/OOK, and the signal protocol supports multiple device types, signal flags, relay signals, battery low indication, and a parity check.
I'm using rtl_433 to receive and demodulate the signal using its default functionality. As of 2018-12-06, it supports this protocol.
I'm also able to transmit valid signals to these Honeywell receivers using the YARD Stick One, which uses the TI CC1111 chipset.
I've also had success transmitting a valid signal using the HopeRF RFM69HCW module, specifically as found as part of the Adafruit Feather 32u4 RFM69HCW Packet Radio device.
Planned further efforts include working with modules that use the TI CC1101 chip, and maybe other modules that are able to support this signal.
If you're able to run rtl_433, and have access to one of these devices, I'd like to know which device you have and what 48-bit value you receive from your device.
Using a recent build of rtl_433, here's what you can use to get that value.
North American and Australian devices:
rtl_433 -f 916800000 -q -R 0 -X n=Honeywell_ActivLink,m=FSK_PWM,s=160,l=320,r=400,y=480,invert,bits=48European devices (including Friedland Response and Libra+ devices):
rtl_433 -f 868300000 -q -R 0 -X n=Honeywell_ActivLink,m=FSK_PWM,s=160,l=320,r=400,y=480,invert,bits=48Submit My Doorbell Code To This Project
Any kind of signal you can provide helps. I'm especially interested in signals from the motion detectors and door/window sensors or other sensors used with this system.
User tos7 has detailed on an rtl-sdr.com forum that the button contains a PIC Micro controller and a FSK Transmitter chip.
The Honeywell wireless transmitter I have direct access to is the RPWL400W, though I was able to look at several of them. I also have tested with a Series 9 and Series 3 receiver.
When the wireless doorbell button is pressed, it sends out a signal centered at 916.8 MHz. It seems to be using 2FSK modulation with a 50 kHz deviation. The modulation rate seems to be 6250 baud, so each HIGH or LOW symbol is 160 microseconds (μs).
Because it is using digital symbols over 2FSK modulation, it essentially looks like two separate, simultaneous, out-of-phase OOK transmissions 100 kHz away from each other, at 916.85 MHz and and 916.75 MHz. In FSK parlance, these higher and lower frequencies are respectively referred to as the "mark" and "space" frequencies.
Data bits are encoded over three symbols. A "0" bit is defined as HIGH-LOW-LOW, and a "1" bit is defined as "HIGH-HIGH-LOW".
Each frame of data consists of a LOW-LOW-LOW signal preamble, 48 bits (144 symbols) of data, and a postamble of HIGH-HIGH-HIGH.
The signal seems to be 50 consecutive repetitions of the frame, then symbols LOW-LOW-LOW-HIGH-HIGH-HIGH, and finally 2 continuous milliseconds (2000 μs) of LOW.
So, the duration of the entire 2FSK signal is
(50 reps * ((1 + 48 + 1 bits) * (3 symbols * 160 μs))) + (6 symbols * 160 μs) + 2000 μs
=
(2500 * 480 μs) + 960 μs + 2000 μs
=
1200000 μs + 2960 μs
=
1.202960 secondsEach data frame is 48 bits, or 6 bytes long. With some experimentation (using a YARD Stick One to create custom signals), here's what I've been able to ascertain about the data in the frame.
# Frame bits used in Honeywell RCWL300A, RCWL330A, Series 3, 5, 9 and all Decor Series Wireless Chimes
# 0000 0000 1111 1111 2222 2222 3333 3333 4444 4444 5555 5555
# 7654 3210 7654 3210 7654 3210 7654 3210 7654 3210 7654 3210
# XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XX.. XXX. .... KEY DATA (any change and receiver doesn't seem to recognize signal)
# XXXX XXXX XXXX XXXX XXXX .... .... .... .... .... .... .... KEY ID (different for each transmitter)
# .... .... .... .... .... 0000 00.. 0000 0000 00.. 000. .... KEY UNKNOWN 0 (always 0 in devices I've tested)
# .... .... .... .... .... .... ..XX .... .... .... .... .... DEVICE TYPE (10 = doorbell, 01 = PIR Motion sensor)
# .... .... .... .... .... .... .... .... .... ..XX ...X XXX. FLAG DATA (may be modified for possible effects on receiver)
# .... .... .... .... .... .... .... .... .... ..XX .... .... ALERT (00 = normal, 01 or 10 = right-left halo light pattern, 11 = full volume alarm)
# .... .... .... .... .... .... .... .... .... .... ...X .... SECRET KNOCK (0 = default, 1 if doorbell is pressed 3x rapidly)
# .... .... .... .... .... .... .... .... .... .... .... X... RELAY (1 if signal is a retransmission of a received transmission, only some models)
# .... .... .... .... .... .... .... .... .... .... .... .X.. FLAG UNKNOWN (0 = default, but 1 is accepted and I don't observe any effects)
# .... .... .... .... .... .... .... .... .... .... .... ..X. LOWBAT (1 if battery is low, receiver gives low battery alert)
# .... .... .... .... .... .... .... .... .... .... .... ...X PARITY (LSB of count of set bits in previous 47 bits)For simplicity, the full Device ID for the device might just be the first 4 bytes. Device Type should be included as part of the Device ID since if it is changed, a receiver would no longer recognize the signal as being from the same device. Bits after byte 4 that seem to be part of the Key ID are always 0 on all devices I've seen.
These bits are 0 in all devices I've seen. Some preliminary tests with generating artificial signals seems to indicate that if these bits are not 0, the receiver does not seem to recognize the signal as a previously recognized device. So, these bits are either part of the device ID, or they simply must be 0 for the receiver to accept the signal as valid. Further testing here is required.
For all devices I've tested, it seems that only the two bits specified for this field change depending on the type of device used to generate the signal. It seems logical that perhaps the the width of this field is more than two bits. It might even be all of the 4th byte. I have no data to confirm this, though. For all devices I've seen, though, only these two bits of the 4th byte might be anything other than 0.
On some receivers, such as the Honeywell RDWL917AX, an alert type of 01 or 10 forces the receiver to display a blinking right and left pattern, instead of the normal full perimeter LED blinking.
On some receiver models, such as the "Honeywell RDWL917AX", the base receiver will immediately retransmit a valid received signal if the RELAY bit is NOT set. The data in the retransmitted signal will be modified with the RELAY bit set. This seems to be an effort to extend a signal to more distant receivers.
rtl_433This seems to work pretty well to pick up the signal frame data as hex in multiple rows:
rtl_433 -f 916800000 -q -R 0 -X n=Honeywell_ActivLink,m=FSK_PWM,s=160,l=320,r=400,y=480,invert,bits=48The "invert" option is specified here to provide a decoding consistent with this document.
Change the reset value to 560 to get all data in one row:
rtl_433 -f 916800000 -q -R 0 -X n=Honeywell_ActivLink,m=FSK_PWM,s=160,l=320,r=560,y=480,invert,bits=48Note that these don't seem to pick up the all the data frames. In my tests, it
only seems to pick up 24 of the 50 data frames in the signal before triggering
pulse_FSK_detect(): Maximum number of pulses reached! and ignoring the rest of
the signal.
It seems to be possible to also pick up the signal as OOK in rtl_433 by setting the frequency about 90 kHz away from the center of the FSK frequency. This seems to force rtl_433 to only notice one side of the 2FSK signal. This command seems to work well to pick up the data frames. It also has the benefit that when the maximum number of pulses is reached, it doesn't trigger an error and starts decoding data again immediately.
rtl_433 -f 916890000 -q -R 0 -X n=Honeywell_ActivLink,m=OOK_PWM,s=160,l=320,g=400,r=560,y=480,bits=48,invert
rtl_433 -f 916710000 -q -R 0 -X n=Honeywell_ActivLink,m=OOK_PWM,s=160,l=320,g=400,r=560,y=480,bits=48Convert the signal you want to send as a hex value representing the symbols in the signal where a 1 bit is a HIGH symbol and a 0 bit is a LOW symbol.
import sys
from rflib import *
def init(device):
device.setFreq(916800000)
device.setMdmModulation(MOD_2FSK)
device.setMdmDeviatn(50000)
device.setMdmSyncMode(0)
device.setMdmDRate(6250)
device.setMaxPower()
r = RfCat()
init(r)
r.RFxmit(data=pwm_signal_bytes)Here's an incomplete list of devices and kits known or suspected to use this signal.
User tos7 performed some earlier valuable analysis of this hardware and signal as detailed on an rtl-sdr.com forum post.
rtl_433 is an incredible and essential piece of software. I still have much of it to learn.
The YARD Stick One is also an incredible thing. Transmitting arbitrary digital signals to test out signal changes is essential to this project. This made it easy.
rfcat is also essential to effectively tap into the abilities of the YARD Stick One.