Friday, December 14, 2012

RUWIDO Merlin IR-USB-HID Receiver

There are these very neat IR Keyboards for sale at a German surplus retailer. At only one Euro they are a steal, but the reason they are this cheap is that they come without a receiver. So to the average person seeking a nice keyboard for their living room media center PC they are useless.

I bought one a few months back when they were still 2,95 € and tried to get it to work with LIRC, but had little luck. It kind of worked in raw mode but the key repeat rate was insane and also this wasn't what I was after: I didn't want to use it as a remote control with LIRC, but as a regular HID keyboard instead.

These keyboards were discussed on quite a few (mostly German) forums on the web, and someone even came up with a decoder for the IR protocol, but so far nobody seems to have written something that would act as a USB HID keyboard. So I had to do it myself.

I did it by simply combining the IR decoder with the V-USB project, which implements a USB HID driver on any old AVR device (not those expensive "U" types, which come with hardware USB).

It should run on any ATMega44/48/168/328 and even on the ATMega8. Which is quite nice because there is a type of USB ISP programmer called USBASP, which is also based on V-USB (I think), and those are available on Ebay for about 3,- €.

So all that's left to do is to get one of those and solder a IR-receiver to it, so I can get it off the breadboard.
The schematic is really simple. And the best thing is, the USBASP already contains everything everything except the TSOP1756 !
As usual, the code can be found in my Github-repository.

Saturday, November 24, 2012

Debugging the garage door remote

A while ago I built a little remote to open my garage door (well, not actually my garage door but the one of the house I live in, but who cares). But the greedy kid I am, I wasn't satisfied with just opening the garage door with it. After all it has four buttons, and so I planned on also using it as a remote for my yet to be built home automation system (a few parts of it already exist, but there is a lot of work to be done before I can really call it that).

The problem was that it had a nasty bug which was really hard to track down: It would work as intended for some time (sometimes hours, sometimes even days), but then, all of a sudden it would hang. And not only did it seize to work, it also stayed in some state where it consumed lots of power and ate up the battery in no time. This was far from usable in real life.

I had heard of a little thing called watchdog timer, which could reset the MCU if it hung. So the first thing I did was to add this watchdog timer to my code. Sure enough that didn't fix my problem, so I tried everything I could think of from incrementing counters in EEPROM after every "real" instruction in the code to hooking up oscilloscopes and logic analyzers. But the only thing I found out was that it somehow, sometimes would get stuck in some weird kind of a reset loop.

When I ran out of ideas of what else to try I started badgering people on various internet forums. And after trying all sorts of changes to the code that people suggested, someone came up with the idea of deliberately causing a reset (among a few other things). I implemented that idea in my code and what happened was, that now every time I caused the reset, the MCU would hang. That may not sound like a good thing at first, but at least now I could reproduce the bug!

After that all it took was a bit of searching the web until I found out about a register called MCUSR, the MCU status register. Turns out that if the watchdog wants to reset the MCU, it writes some value to this register that would cause the MCU to perform the reset. But for some reason it doesn't get cleared after the reset is done, causing the MCU to keep resetting itself until the battery is dead or the world ends, whichever comes first.

So in the end all I had to do was to set the MCUSB to zero right at the beginning of the setup() routine and all of a sudden the reset would be performed as intended and the MCU would work again. For now. I'll have to give it a few weeks to really call this case closed, but I'm pretty confident that this was it.

All that's left to do is to say a big THANK YOU to all the people who tried to help me solve this mystery, and especially JohnO on the Jeelabs forum, who came up with the idea of causing that reset on purpose (although he might have had something completely different in mind than crashing the MCU every time the reset fired).

The updated code can be downloaded here.

Friday, November 23, 2012

Building Arduino Sketches without the IDE

I really love the Arduino, because after all it was what started all this.

The one thing I don't like is the IDE that comes with it. It's not the IDE's fault, It's just that I'm a console guy and I don't really like IDEs in general (and yes, I've seen others and I think this one is not particularly good). Luckily there are ways around it, like Makefiles that automatically include all the needed libraries and even upload the sketch to the board. There are several of these out there, and I went with this one which is a slightly modified version of this one. The Makefile is pretty good as is, but I added a few minor changes:

  1. The Makefile can search for libraries in ~/sketchbook/libraries, but instead of the ~/sketchbook folder I use ~/src/arduino, so I just replaced that.
  2. It reads the boards.txt file in the Arduino installation directory but I have my own boards.txt in ~/src/arduino, where I added my own boards, so I changed that path, too.
  3. The setup howto suggests that you symlink the file to your sketch-directories, but if you do that, you'd still have to set the environment variable $BOARD to the right type, which I found a bit tedious. So instead of symlink it, I create a new Makefile in each sketch folder that contains only two lines: The first one sets $BOARD to the board type that sketch uses, and the other just includes the original Makefile.
The result is a very tidy build system with no redundancies whatsoever.

As usual everything can be downloaded in my github repository:

Sunday, November 11, 2012

Smartmeter III - blinking LEDs

This is a short one. At least compared to the usual walls of text I post.

Due to the nature of my water heater (a continuous-flow-type), it's power consumption is highly dependent on the water pressure and flow-speed. The more and faster the water flows, the more power it consumes. Apparently this happens in three stages. The first two turn on immediately as you turn on warm water. But the third will only com on if needed, i.e. if the water consumption continues to increase. Also these three stages are connected to three different mains lines, which means, they get counted separately.

Saving energy, resources and money is fine, but sacrificing creature comforts for it? No way!
When I take a shower I want it hot. And I don't want it trickling down on me, either.

That's not a problem with my new water (and thus electricity) saving shower head. What is a problem, though, is that the water flow has to be adjusted just right to keep the third (and greediest) stage of the water heater from turning on.

So to be able to see what the water heater is up to, while in the shower, I built this little thingy:

It's just a Jeenode with a few LEDs

The yellow, green and white LEDs blink if there's a pulse received for one of the three mains lines, and the red one will blink if a packed got lost. Right now it's powered with a single AA battery, but that lasts only a couple of days, so I'll have to add a little power supply, probably from an old phone, since I have plenty of those.

The code to drive it is here:

Saturday, November 10, 2012

Smartmeter revisited

Einstein once said that only two things were infinite: The universe and human stupidity. The former even he wasn't sure about, and the latter I found out the hard way. But I'll start from the top:

I've had my smartmeter running for a while now and since the readings looked plausible I assumed they were accurate. Well, they weren't.

The meters I use generate 2000 pulses of 90ms length for every consumed kWh, and the way I counted them was to collect them for five seconds and then transmit a summary. After a while I found out two things about my power consumption:

  1. The water heater (a continuous-flow-type) consumes an insane amount of power, and
  2. The computer running the metering software also was a bit too greedy for my taste.

I couldn't do anything about the water heater because it's installed permanently and after all it's not even mine, but I could try and tame it's power consumption by reducing the water pressure and/or the flow speed by using a water saving shower head. As a side effect I'd also reduce my water consumption. Two birds with one stone! And the PC running the metering software also had to go.

To get rid of the PC I had to rewrite the metering software from scratch, because the software from the project I was using is based on a full-fledged LAMP-stack (Linux, Apache, MySQL, PHP). The main problem was the MySQL-database, as this keeps every reading I ever took and has to access them all at once every time I'd wanted to view my consumption graph (remember, I took readings every five seconds, so there were a LOT of values in there).

I opted to use something called RRDTool instead. This is a nifty little tool, well known to sysadmins around the world to keep stats about routers and switches, system loads and whatnot. Since there are usually a lot of data sources too keep track of, the databases have to be kept small. The way it achieves this is to use fixed size databases of different resolutions and aggregation functions to consolidate older data.

While I was at it, I also changed the way I collected the pulses from the meters from the five-second-summary-method to transmitting every pulse as it came in. This is where things started to go South...


But the really stupid thing I did was changing something that drastically influenced my power consumption (the shower head) and the way I collected and processed the consumption data at the same time.

The result was that I grossly overestimated the savings from changing the shower head and thought I'd cut my consumption by about 50%, since that was what my new readings suggested. I never even bothered to check the "official" meter from the power company, which finally bit me in the ass when the next power bill came in.


Only then did I find out that my readings were way off! They may have looked plausible, but weren't anywhere near my true consumption.

After this wake up call I started to investigate the error. At first it looked like the new way of counting pulses was to blame, so I changed that back to the old way. That gave me way higher readings but by then I had grown suspicious if those were correct. They also weren't.

So the new method was obviously loosing pulses while the old way was counting pulses that weren't there. The one thing both had in common was the way they went into the controller:

When idle the controller was in sleep mode and an incoming pulse would cause an interrupt to wake up the controller and send out a packet or increment a counter, respectively. Since the driver for the RFM12 transceiver is also heavily based on interrupts I figured that might have been the problem. I also had some code to blink an LED using the Arduino delay() function, which is a really bad idea when using interrupts at the same time, but I threw that out first and it didn't fix the problem.

So I changed the code to poll the inputs instead of sleeping and waiting for interrupts and that seemed to help with the lost pulses.

But things only got weirder: Now some pulses were counted twice. So I started counting milliseconds between pulses and it turned out there was some kind of bouncing about 75ms after some pulses, while others looked OK.

I knew that mechanical buttons tend to bounce, but this bouncing would occur in the first ten ms after the button was pressed, not 75ms later! 75ms is close to eternity, even for a tiny and slow 8 bit microcontroller. A real computer could go fetch a coffe and have a smoke in 75ms! Also there weren't any mechanical switches anywhere near the circuit I've built. The pulses are generated digitally by the counters, go to an optocoupler and straight to the controller.

But I didn't want to rip the whole thing out of my breaker box and dissect it with an oscilloscope, so I just wrote a little routine that ignores every state change that occurs less than 90ms after the input went low. Think of it as a really slow debouncing routine.

and the real thing (hopefully)

So far my readings look OK, there still is some 0.03kWh error per day, give or take, but that's nowhere near what my old code produced.

As usual, the code can be found in my github account:

Wednesday, August 15, 2012

My DIY Smartmeter

This one started with a power bill. One exceptionally high power bill, that is.

I had been reading and thinking about smart metering and smart grids for some time already, and when the bill hit me I decided it was time to act. But where to start? Those kill-a-watt-kind-of-things weren't an option because I needed to measure the power right at the point where the lines enter my apartment, because I didn't want to miss anything like the stove or the water heater, which don't plug into sockets, but are connected directly.

The guts of my Breakerbox:
In the lower row you can see the main breaker on the left
and the breakers for the stove and the water heater.
But I also didn't really want to mess with my breakerbox if there was any way I could avoid it. So the first things I had a look at were inductive sensors. Only two problems with that:

First, the coil or the ferrite core of the sensor has to go around the conductor you want to measure. So either the coil, the core or the conductor has to be split open to mount it. There are sensors made especially for this purpose, like these:, so this issue could be addressed by simply throwing money at it, because those specialized sensors anren't too cheap. Actually there are even some DIY projects for these sensors out there.

The second problem is, that these sensors only measure current. We want to measure power consumption and power is the product of current and voltage. So we'd need to measure the voltage, too, if we want accurate measurements. Now this definitely isn't achievable without a physical connection to the conductor.

So there you have it: No accurate measurement without physical contact to hot wires. Just no way around it. Shit.

This meant, I couldn't do his by myself. Luckily that's not that much of a problem, because a friend of mine, who is a certified electrician, had offered to help me out.

The inevitable disclaimer:
Working with AC mains power can kill you! Don't do it unless you really know what you're doing!

This also meant, that I didn't have to awkwardly hack about with current clamps and later figure out how to calibrate and measure the whole shebang, but I now could look at an entirely different concept.

The meter(s):

There are lots of electronic powermeters out there, calibrated and uncalibrated, the main difference being that the calibrated ones are only required if you want to use them for billing purposes.

In my case an uncalibrated one would do fine. These meters have an interface that generates pulses when power is consumed. The pulses are 90ms long and come in different resolutions, 1000 or 2000 pulses per consumed kWh are the most common. Basically they all look like these.

So I picked up three, because where I live it's common to have three wires carrying 230V (and one neutral wire) going into your home, and all three of these have to be measured.

With all the basic supplies ready it was time to move on to the interesting part of this build:

The controller:

It looks like smart metering is about to become a big thing in Europe, but people are worried about the power companies being able to track their power consumption in such high resolution, and they are absolutely right about it! Just imagine someone at the power company who uses the data to keep track of who is at home and who is not, and sending a team of burglars over to the places where the owners are out for their weekly movie night, or whatever. Or imagine getting a call from the power company with the person on the other end of the line going: "We noticed that you didn't take a shower for two days in a row now, you really should take more care about your personal hygiene..."

Not wanting to give up this data to the power company is one thing, but there are still many positive aspects about smart metering, like, for starters, I want to know what it actually costs to take a shower.

This is why some folks in Germany started the (which roughly translates to "peoples power meter") project. This project is a really great starting point for everything about DIY smart metering. They've got open source software to track the consumption (among other things like temperatures) and several controller designs to connect your meters to the internet (or LAN).

This is the frontend.

Actually I only used the power supply and the input driver boards of the project, because the controller board would be connected by Ethernet and I don't have Ethernet anywhere near my breaker box.

There is another controller design by the same guy that uses Wifi and is compatible to the one I was building, so I tried to use that. That might have even worked had I not tried to make the PCB myself (The guy who designed these controllers also sells kits, but he had no pcb for the wifi-controller):

I have access to a little CNC-Mill capable of making PCBs via isolation routing. This is good for single sided boards (even with SMT parts like TQFPs), but it really sucks to make a double sided board on it. Especially if the board is designed to be made in a real fabrication house where they can make chemical vias, apply soldermask, and so on. The fact that I hadn't really worked with PCB design software like eagle before, didn't help.

So I just imported the design into eagle and didn't care about re-positioning the vias, so that they aren't below any parts, and milled away... That left me with a semi-functional board where everything would work fine for a while, and then the Wifi-module would perform an unprovoked factory reset.
This was the first design. It was based on a RN171-Wifi-module and an ATTiny2313, and didn't work. Notice how crammed the area above and on the right of the RN171 is. That's not only capacitors and resistors, there's a good deal of vias in there, too.
The bottom side of the beast.
I spent literally months of debugging before I finally decided to can it and start from scratch.

This is what I came up with:

Not much to it. The crucial parts are an ATMega, the RFM12, and the headers to connect to the other board.
Actually this design is derived from the JeeNode, which is (kind of) an Arduino clone with a RFM12B 868MHz FSK transceiver.

Since I was eager to keep things simple this time, and also because this was my first attempt to design a pcb in eagle (or any pcb-layout-software, for that matter), I went with a single sided board. For this all SMT-parts have to be mirrored and placed on the back. But after that epic failure with the first board I also decided to use as few SMT-parts as possible. Luckily the RFM12B is the only one and that's also comfortably big.
The layout in eagle. Notice the RFM12B on the back of the board
 Before you can feed the layout to the router, you have to convert the eagle file to gcode, and while you're at it, you could just widen the traces a bit, so that you'd have a bit less milling. If you don't know what I'm talking about, the next few pictures are pretty self-explanatory.

This is what the layout looks like before being "blown up"

This is what the layout looks like after the traces have been "blown up". The colors are added by the software to ease identifying traces and nets.

The milled and drilled board. I only remembered to take a picture after I already had started soldering stuff to it. Note that it's no problem to route traces between IC-pins. Also note that some holes (e.g. the ones for the pin headers) are wider than others.

This was done with pcb2gcode which is available at

Unfortunately, there aren't any more photos of the construction because I broke my phone's camera function.

The receiver:

- Tell me, Captain Obvious, what good is a single RFM12B radio transceiver if it has no one to talk to?
- Well, not too much, obviously!

Anything with a RFM12B module (and probably others) can act as a receiver for the power meter.
I went and built a receiver into my Asus WL500gP Wifi-router, but you don't have to:

There are (Arduino compatible) kits and assembled USB-dongles that contain a RFM12B and an ATMega328 available at, so you could just get a JeeLink or a JeeNode USB and use that.

My breakerbox with my smartmeter in it: Upper row: The controller, middle row on the right: The three meters.


I've only just started learning C, so the code is probably shit.


All PCB milling was done at the Attraktor hackerspace in Hamburg (website in German).

Sunday, August 5, 2012

Garage door remote for real

(featuring my first real factory made PCB)

It's been a while since I built the garage-door-proof-of-concept-remote. As stated in the according post, the "industrial design" part of the PoC managed to be flimsy and clunky at the same time. So there was some room for improvement.

Back when I still thought the original remote was using 434 MHz, I bought two little "cloning remotes" or at least so I thought. I was eager to save a few Euros, so I got mine from some shady Chinese eBay-shop, and sure enough the ones I bought were far from capable of cloning anything. Instead they just sent out fixed codes, no matter what I tried. Well, at least they did something.

The enclosure.

But even if I had gotten the "real" ones, it wouldn't have helped a bit, because those still would only work with 434 MHz and I needed 868 MHz.

So there I was with my homemade (but working) remote and my two Chinese knockoffs. Even though those were useless, I still liked the enclosure and started wondering if I could just use that and design my own PCB to put inside. I could even harvest a few parts of the original PCBs, like the buttons and the blue LED.

The disassembled remote and the original PCB. They use a 12V battery for the 434 MHz transmitter.

The first thing I did was to take measurements of the original PCB and transfer that to a simple Eagle layout. After quintuple checking the positions of every hole, notch, button and the LED I locked their positions so that I wouldn't accidentally move them out of place later in the process.

The back of the board on a scanner.
And the front. At first I tried to take measurements from the scan, but I soon realized I would have to get a caliper.

The problem with my layout was that it would not work with the kind of PCBs I could make on the CNC router at the Attraktor because the board would have to be double sided and I've tried to make a double sided board before and failed miserably. So I had to have the board for this project manufactured in a real fab house. The problem with that is that it's really expensive for low volumes. If I had the board made on my own in Germany it would have cost me about $50. So that wasn't an option.

By chance a friend told me about the dorkbot PCB-service (now called OSHPark). This is an extremely cool service run by a guy who started out collecting PCB layouts for his local hackerspace and put them all together on a big panel to reduce manufacturing cost. To fill up the panels quicker he opened his service to the public, so that is where I went.

My Idea of a garage door remote in Eagle. Except for the antenna on the right I was really lazy and let Eagle autoroute most of the traces, which wasn't too brilliant.
Having the boards made and shipping them across half the globe takes about 4-6 weeks, so after a long wait I finally had these in the mail:

I had round edges and a little notch on the "Dimension" layer. The notch is there but the round edges aren't. I'll have to remember to sort that out before I order the next batch.

And when I finally held them in my hands, it wasn't long until I discovered the first fundamental design fault: There are a bunch of vias (gold plated, even!) right where the negative terminal of the battery would go. These I would have to insulate somehow.

Later that night one of the boards looked like this:

The ATMega is facing the wrong way. Ignore that.

I soldered the TQFP part using the solder wick technique shown at about 6:25 in this video (and probably many others).

I left out the LED and the accompanying resistor on this board. Also note that I left out the notches on the sides of the board. I figured that it would be easier to just cut the enclosure to fit instead. Which worked.
I insulated the vias under the battery clip with this stuff and I also put a lot of solder on the sqaure pad in the middle to raise its level above that of the vias.

The ISP connector is done with the pads on the left. Now I had to find a connector to fit. A PCI connector should fit, or maybe an old floppy drive connector. Too bad I didn't have any of those around. All I could find was an old connector for a C64 datasette port, if anyone still remembers those.

My barely working ISP Plug.

The pitch was totally off but it was the only thing I could find, so I used it. It was a royal pain in the ass but at least sometimes it worked.

Not that night, though... The programmer wouldn't even find a controller to talk to. After checking all of the connections were good, I finally found it: The ATMega was facing the wrong way. Nice work.

De-soldering a TQFP part is no fun but it can be done. You have to add lots of solder, so that all pins are covered, and heat all four sides in a swift procession. The trick is to have the fourth side heated while the first is still hot. You'll have to go around the chip for a few times but eventually it'll come loose and you can just wipe it off the board. The major rule is: Patience > Violence.

After having this fixed I could flash the controller but the damn thing still wouldn't work. I had to get out the logic analyzer. Luckily the connection between the ATMega and the RFM12B is an SPI connection, which is basically the same as the ISP connection for the programmer, and it also uses the same pins (mostly). So I could connect all but one of the analyzer probes to the programming connector. With help of the analyzer I could see that the controller was talking to the RFM12B on the MOSI line but wasn't getting an answer on the MISO line. This meant that the RFM12B wasn't working properly for whatever reason, most probably a short circuit somewhere on the board.

After poking around with the multimeter for another while I found it. Or, more precisely, I found out which nets were shorted out, but I had no idea where.

By now I had a little practice in de-soldering larger SMD parts, but even after removing the ATMega and the RFM12B (the de-soldering trick described for the ATMega works with that, too), the short was still there. It was between the SEL signal of the RFM12B and VCC, i.e. the positive terminal of the battery. But since these two nets virtually never cross paths or even come close to one another it had to be somewhere else. And here it was:

The SEL trace of the RFM12B crossing the drawing of the battery clip on the "Dimension" layer. Looks perfectly innocent in Eagle.
This is what it looks like in real life:
Not so much in real life. The metal of the battery clip cut through the soldermask somehow and shorted out VCC with SEL.
After gently bending the battery clip everything worked like a charm. Well, at least the hardware did.

The software:
The PoC didn't have a real program logic at all. As soon as you connected the power, it would transmit away. For this project I wanted something slightly more elegant. In addition to just sending the garage opening signal, the buttons should send something I could use around the house, like a unique ID, that I could process in projects to come. Also I had to do something about the current consumption. Both, the ATMega328p and the RFM12B have ultra low power sleep modes and I needed to utilize those to make the coin cell last more than a few hours. Again I had lots of help from the internets, particularly here and here somewhere near the bottom. After some tweaking I had the standby power consumption down to under 1 µA.

At this point I'd like to praise the Internet. I couldn't do shit without it.
The only problem with the code was that it wasn't very stable, and I couldn't really fix that.

(The PCB design actually reflects how little trust I had in my own coding skills: I put in a little solder jumper to be able to use one of the keys as a reset button for the AVR. But that was planned as a last resort in case I really couldn't get the code to run properly.)

Luckily, for cases just like this, the ATMega (and probably other microcontrollers as well) has a watchdog timer, that will reset the whole controller if you don't reset the timer before it runs out. After implementing that, everything is running smoothly for several days now.

I've learned quite a few things about PCB design doing this project:

  • Don't trust the autorouter of your PCB design software. Better yet, on a project as simple as this, don't even use it.
  • Think 3D! It's hard to imagine a real life PCB just from an Eagle layout. There are 3D rendering plugins for Eagle and other software with this functionality built in, but I found it the easiest to just print out the PCB layout on a piece of paper and place the parts on it.
  • Only use parts in your design that are actually available to you. I have  yet to find a correctly pitched edge connector for the ISP connection.
Total cost of the project:

  • PCB: 3.30 €
  • ATMega328p: 1.80 €
  • RFM12B: 4.00 €
  • Chinese fake-cloning-remote: 2.50 €

Makes a total of 11.60 € or US $ 14.35 at the time of writing. All prices include tax and shipping and all items were purchased in low volumes.

All design files as well as the source code for the controller are available at my github repository:

As it turned out, the watchdog timer (or rather the way I implemented it) didn't really help, actually it made matters worse! After a long and tedious debugging process I finally think I've got it right. Read about it here.

Tuesday, July 31, 2012

It all started with a garage door remote

(or me being to cheap to get one from the administration)

I live in an apartment house with an underground garage, but I don't have a car, so I didn't rent a space in there. I do have a bike though, and I want to put it in the basement which is also reachable from the garage. And since I have no parking space in the garage I don't have a remote for the door. I could have just got one from the administration but where is the fun in that? Also, they wanted 50 € for one and I didn't want to spend a hundred Euros just to be able to let me and my girlfriend put our bicycles in the basement.

So what I was going to do was borrow one from a neighbor, reverse engineer it, and build my own. Sounds easy enough. I had to pester that poor guy what felt like a hundred times for that stupid remote before I finally got it right!

First I had to find out what was transmitted, and which frequency it was transmitted on. In Europe only 433 MHz and 868 MHz are used for these things, so I spent some quality time with my radioscanner (a very old and cheap one) to try and find the transmission frequency. And, what do you know, soon enough I found it. Or at least so I thought. I got a reasonably clear signal on 433.925 MHz, which is a commonly used frequency, so I assumed this was the frequency being used by the keyfob I was looking at. Well, it wasn't, but more on that later..

Next thing I did, was hooking up the scanner to a pc to record the signal and have a closer look at it. This is what it looked like in Audacity:

As you can see, there are long and short pulses and also long and short gaps. This signal is repeated at least three times and it doesn't ever change, regardless of how often you push the button on the remote.
This is good news as it means that the remote uses neither a rolling code nor some kind of challenge response mechanism. So it should be simple to mimic what the original remote is transmitting.

After a bit of transcribing and measuring the timing of the pulses and gaps I had this:


The ones represent a high state while the zeroes represent low and since the long pulses are exactly twice as long as the short ones, I selected the short period as my standard pulse length. Hence the two ones in the beginning for only one long high pulse.

Now all there is left to do is hook up a 433 MHz-transmitter like this to an Arduino and write a few lines of code, right? Wrong.

After countless times of checking, re-checking, double-checking and comparing my generated signal to the original one, and almost losing my mind in the process, I came to the conclusion that my signal looked at least as good as the original one, in fact, amplitude-wise, it looked even better.

Wait a minute, why should my 434 MHz signal look stronger and healthier than the original 434 MHz signal, unless...

Turns out, the original remote is actually using 868 MHz and the reason I got such a clear signal on ~434 MHz is that it's (almost) exactly half of 868 and thus a harmonic. What this means is, the signal of the original remote was strong enough on the harmonic to be picked up by my scanner in close range but the original receiver would reject my signal due to better filtering or whatever.

It took me a while until I finally found out about this and I must admit I was a bit angry at the manufacturer at first. But then, who can blame them for using 868 MHz over 434 MHz? It's clearly the better frequency to use, because 434 MHz is flooded with noise from wireless weather stations, remotely controlled power outlets and all kinds of other cheap shit. There are rules though for the 868 MHz Band: You have to listen in to the frequency you want to transmit on before you transmit anything, to see if there isn't another transmission going on, and you have to keep your duty cycle below one percent. That means that for 1 second of transmitting you'd have to shut up for 99 seconds before you are allowed to transmit again.

Having this figured out, I picked up a RFM12B 868 MHz transceiver and hooked that up to the ATMega.

I stole this image from here.

I chose the RFM12B because there are a few libraries out there for this device to work with AVR controllers, and even one which works with the Arduino environment. The library (and lots of other cool stuff, and also a very inspiring blog) can be found at There are also further instructions about how to connect it to an Arduino (or ATMegas in general).

The proof of concept on a breadboard. The little button simply connects the battery when pressed.

The thing about the 868 MHz-Band and the RFM12B is though, that they use FSK, which stands for frequency shift keying, instead of ASK (amplitude shift keying) or OOK (on off keying), the probably simplest form of wireless digital communication: The transmitter is either on (1) or off (0). And what you see in the screenshot above is exactly that. Actually there is a little bit more to it: The signal is encoded in manchester code, but that is irrelevant for the transmission itself, so I won't go into it right now.

The point is, the original remote uses OOK and the RFM12B isn't designed to do that. But luckily the RF12 lib has a function for that, so that shouldn't be a problem.

So I adjusted my code to work with the RF12-lib, uploaded it to the ATMega and went to the garage once again, almost shivering with anticipation.

Standing at the gate I hooked up the battery and, what do you know, the damn thing opened!
IT WORKED! IT ACTUALLY WORKED!!!1 I finally built something that worked!
(wanted to quote Doc Brown there, but to say I invented it would be taking a bit too much credit)

After I was done making an ass out of myself dancing through the parked cars, I figured I'd have to come up with something a bit more permanent than an ATMega on a breadboard if I was going to use it for real. So i took a piece of perfboard and a battery holder and put it all into a maxim sample case, and this is what it looks like:

My garage door remote
without the case
There is not much to it, just an ATMega 328 (which is total overkill for a task like this), the RFM12B, a button, an LED and a few resistors.

It worked pretty well but it wasn't very tough, and when it fell down one time too often I got sick of fixing it, and i needed the parts for another project, and winter was closing in, and we were having a baby, so I figured, I wouldn't be needing it too often anyway, so I ripped it apart.


This was my first real microcontroller based project after playing with the Arduino for a while and learning about microcontrollers in the process, and it even did something useful.

If the original remote had used 434 MHz this would have been way less hassle, but then again, I'd maybe never (or a lot later) learned about the RFM12B and the library from JeeLabs, which have become the cornerstone of virtually every new project I start.

Also, now you can build a remote for my garage door, too!