doorbell

HackRF DoorBell Ringer Part 2 – Replay

Following on from capturing the signal in the previous post was to try a simple replay of the signal to see if it would set the doorbell off as expected.

For this we started off using hackrf_transfer, this receives data in to a file then transmits again from the file, perfect for a quick signal replay.

My first attempt at this was to simply set hackrf_transfer to record the signal centred on the frequency of interest 433.780Mhz.

Firstly capturing to a file:

hackrf_transfer -r 433780000.raw -f 433780000

Then transmitting from the file:

hackrf_transfer -t 433780000.raw -f 433780000 -x 20

Initially I hadn’t included a transmit gain option with -x so wasn’t seeing a signal when transmitting, this could have been reduced a bit.

Now the approach taken above did not work as expected. On looking at the signal transmitted by using an RTL-SDR device to see what was going on we can see a problem.

Hackrf_transfer no offset

The image above shows that capturing and transmitting on the same frequency has resulted in in a continuous signal being sent, the red line, through the middle of our real signal. This signal is on the exact same frequency the doorbell receiver is expecting the real signals and unsurprisingly the AM receiver doesn’t like a strong signal interfering so it didn’t ring.

The simple answer here is to offset the record and transmit frequency a bit, 20khz here, so the DC spike that exists in the middle of our recording isn’t where we’re wanting to transmit.

hackrf_transfer -r 433760000.raw -f 433760000
hackrf_transfer -t 433760000.raw -f 433760000 -x 20

As can be seen in the image below, by shifting the capture and transmit frequency 100khz away, the carrier of the spike is no longer on top of our signal and bing bong the doorbell rings!

hackrf_transfer offset

I tried to replay the signal with GNU Radio gnuradio-companion using an offset frequency and it also worked as expected and rang the doorbell first try.

Simple flow to capture to file.

Simple flow to capture to file.

The GNU Radio waterfall from the capture

The GNU Radio waterfall from the
capture showing the signal (just)

Simple flow to transmit from file.

Simple flow to transmit from file.

The only problem with this is approach is it’s transmitting the full captured sample which could land us transmitting something unintentionally captured. So while it works and is quick, a better approach would include some filtering, I have a look at this in the next post here.

I’d also like to emulate the signal in GNU Radio as retransmitting isn’t that great but that’s a bit of learning away yet.

I uploaded a short video to youtube demonstrating the doorbell ringing.

Advertisement

HackRF DoorBell Ringer Part 1 – Capture

So this is another hello world style project that’s been done a bunch of times by others but not me, take your simple wireless doorbell and try to make it ring with your SDR 🙂

The bottom of my Friedland doorbell receiver unit helpfully showed it was transmitting on 433Mhz, pretty much as expected. A little listening with GQRX identified the signal:

Original CaptureThe signal appeared to comprise of fast on off bursts, On Off Keying. As suggested by other peoples attempts at things like this, I used baudline for the first time to have a closer look at the bursts and we can see things a bit more clearly.

doorbell2 baudlineThis didn’t help too much beyond giving me a count of the number of bursts per button press, they looked similar enough to the eye too. I’m not sure if there would have been a better way to look at this in baudline but will have a look at it again another time.

I recorded the AM signal audio in GQRX to a WAV file, the bursts were quite clear to the ear. On opening this up in audacity we can see groups of pulses making up a single button press. doorbell3 On zooming in to a button press, we can see these button presses are made up of similar looking groups.

doorbell4And closer again we can see the signals are well defined with the first four peaks equidistant which suggests a preamble/sync. Each of the groups within a button press have the same waveform.

doorbell5Now I tried measuring them but there was no easy way to do this by sight or on paper so I wrote a small python script to take the wav file and alter one channel to be either +1 if > 0 or -1 if < 0 to be more clear. I’ve since changed this to be 0.9 and -0.9 as it’s more readable.

./tobin1.py -i doorbellshort.wav -o out.wav -s
Writing to: out.wav

This worked well and gave me something a bit more readable as can be seen in the output from out.wav, the top channel is the original the bottom channel is the altered one:

doorbell6Now the counting was still awkward so I added a sample count to the script to give the distance between each pulse which enabled me to pull off a stream treating it like binary known as non-return-to-zero. This didn’t however give anything that insightful, but I don’t think there’s going to be much point in going any further with this on a doorbell.

This is the output from above script with the leading 0 removed, we can see the 10101010 preamble/sync noted above:

1010101000100000100000100000010000100001000000001001000000100001000001
000001000001000000100000100001000001

The next step will be to try and record and replay the request using hackrf_transfer.