Friedland DC55 Window Sensor Reverse Engineering


As a hobbyist with a passion for microelectronics, I’ve been automating my home. I recently decided I wanted to know when certain windows in our house were open. I knew this could be done fairly easily with a hall effect sensor and a magnet, but I decided to take a quick look online to see how expensive an RF based window sensor would cost. The Friedland DC55 was quite cheap and boasted a long lifespan with very low power usage. While in retrospect I would have liked to have designed a PCB and flashed a low power microcontroller, reverse engineering a 433mhz protocol could be interesting and I don’t really know where to source magnets from, or an appropriate magnet strength for the task.

My first thought after powering the devices is checking if RCSwitch picks up the signal. A fairly popular but old library for Arduino microcontrollers, RCSwitch identifies the signal length and bitrate of most common protocols. I flashed an Uno development board and attached a superheterodyne 433mhz receiver, tried triggering the tamper switch. Nothing, no received data. I briefly considered looking at the library or writing my own parser to identify edge change timing, but decided to check this product was what the seller said it was - a 433mhz broadcasting window sensor.

I took a screwdriver to it and had the PCB free in a few seconds. On top is a visible crystal driven RF transmitter, a speaker, hall effect sensor, fuse, tamper switch and an external connection header. I flip the board over, I can see some resettable fuses, resistors, the LED and a microcontroller with a sticker on top labelled xx-xx (TODO: add this from the other sensor). I peeled off the sticker and inspected the microcontroller under a magnifying glass. At the right angle, I could read the silkscreen applied - PIC16F627A. I checked the internet, this ultra low power 8bit microcontroller could run at 20Mhz max. That at least promises that the RF protocol shouldn’t require incredibly difficult timing to receive.

As an aside, there’s a missing capacitor and resistor near the speaker. Likely used to charge and discharge for an alarm sound, but doesn’t seem to be utilised in this model.

I checked the crystal on the RF transmitter - this is often a small circular metal button with etching to indicate it’s frequency. This was marked 433.92mhz - a standard consumer frequency in European countries and the same frequency as my receiver. This is promising - I shouldn’t have to modify anything or purchase a specialised receiver with such a low complexity transmitter and microcontroller.

While I could try and muddle the signal from general 443mhz noise, I decided to fetch a logic analyser. I always wanted to get one, so I purchased the very cheap Cypress CY7C68013A. I purchased it from HobbyComponents for a convenient form factor and hopefully some degree of build quality. It should be sufficient for a low speed signal like this.

I identified the ground, voltage and data pins on the transmission module with a multimeter. At first, I held the header against the transmission module’s header, but my unstead hand proved to be too noisy for the logic analyser.

I soldered the male header to the exposed solder joints on the transmission module and tried again. This time, PulseView captured a very accurate snapshot - I could see clear edges with good accuracy. I reset the session and held the tamper switch down and the window sensor to the control unit. I then tried the four actions I wanted to capture - tamper release, tamper reset, window alarm, window alarm reset. After each action, I could see a clear burst of data. Great!

I zoomed in and noticed a 23.9ms gap inbetween transmissions of two equal length bursts. I assume each command is transmitted twice, so the receiver has a higher chance of receiving one during interference. A cursory glimpse over the protocol identifies a few common timings. From here, I’ll have to identify how the protocol encodes bits. The most important aspect after that will be discerning the difference between commands and controller identifier bits.

I fumble through PulseView to export the binary data of the transmission line, open tmux and vim and start programming. While I prefer Golang for serious projects, quickly hacking a Python or Javascript file is usually better for a short, computing task. Even Excel would work to parse some of this data. Once I can output a string of each transmission’s on off bits, I should be able to hardcode these into a receiver and not bother understanding the protocol.

Oh no! These devices don’t transmit much information! If you remove the 0.05ms jitter, the codes transmitted for all of the states the controller can be in are… identical!

314232323232323141414141414141414232314231423232314231423141414141423231414232314231423231423141423141414141414232323142314231414 314232323232323141414141414141414232314231423232314231423141414141423231414232314231423231423141423141414141414232323142314231414 314232323232323141414141414141414232314231423232314231423141414141423231414232314231423231423141423141414141414232323142314231414 314232323232323141414141414141414232314231423232314231423141414141423231414232314231423231423141423141414141414232323142314231414 314232323232323141414141414141414232314231423232314231423141414141423231414232314231423231423141423141414141414232323142314231414 314232323232323141414141414141414232314231423232314231423141414141423231414232314231423231423141423141414141414232323142314231414 314232323232323141414141414141414232314231423232314231423141414141423231414232314231423231423141423141414141414232323142314231414

This makes this remote sort of unsuitable for monitoring the states this controller can be in. Not only is this protocol unsupported, but it’s not detailed. It only sends an event when anything happens, rather than a different transmission per event. While I can probably figure out how to receive this data, disable the tamper switch and make an artifical on/off switch, I’ll be forced into occasionally resynchronising the artifical switch with the real state of the window sensor. This seems annoying and counterintuitive. The research into this reprogrammable microcontroller might actually be useful, because I might be forced to reflash them with test probes if I want this additional data…

So far, the thread on the internet that doesn’t recommend them seems to be pretty astute. There’s a reason they’re as cheap as chips. I still have the option of dehousing the PCB, stealing the hall effect sensor and control unit, and fitting my own controller.