Return to Wireless Garage Door Sensor


First a simple hardware layout.    An ATTINY13 creates a data stream, sends to to the transmitter on one board.  The receiver on the 2nd board picks up the signal, sends it to the 2nd ATTINY13 for decoding.  Finally the ATTINY13 controls 2 LEDs, one fora  Door Open/Closed, the indicator, the other LED to indicate loss of signal.  I figured the signal loss indicator was a good idea because, that way if I lost the transmitter or it’s signal, I could differentiate that from a safely closed garage door.

Initial Garage Door Sensor Circuit

The design of the data stream was the next task.  I only needed to send a single bit of data, but I wanted to include error detection and I wanted a data stream that was easy to decode.  The data part was easy, single data bit + parity bit. ie 10 for door open and 01 for door closed.  To make decoding easy, I wanted unique start and stop bits that did not show up in the valid data stream.  Thus, 11 for the start bits and 00 for the stop bits made sense.  End result:  110100 = the data stream for ‘door closed’ and 111000 = the data stream for ‘door open’.

At this point, I threw together a breadboard prototype to validate the hardware and software configuration:

Garage Door Sensor breadboard

This worked great on the breadboard, so I put together a pair of circuit boards, both point to point and wired because the circuit was so simple.  One board for the transmitter with a switch, one for the receiver with 2 indicator LEDs.

Garage Door Sensor TX

Threw it up in the garage, confirmed that everything still worked.  Great, then went back inside the house to close the garage door.  There, I’ve got a 2nd wireless transmitter to close the garage door from inside, the house.  Nothing.  the door won’t close! Or at least the remote will no longer close or open the door.  At this point, I feared the worst and powered off the transmitter on my door open detector.  Sure enough, now the door remote works again.  The transmitter on the door open sensor is swamping out the remote transmitter.

I tried trimming the antenna wire on the sensor transmitter.  Yep, sure enough I can trim it short enough to get the door remote to work again, but at that point the sensor receiver isn’t getting a clear signal.  Finally a bit of digging on the internet and yes, the two transmitters are pretty close.  434Mhz vs 390Mhz sigh…

All is not lost, SparkFun has another variant, same form factor, same price that runs at a 315Mhz.  So I ordered a 315Mhz TX/RX pair.  Swapped’em out, put’em up in the garage and yes! the door remote still works!

I think I’m done until I try to leave to drive to work the next day.  Press the door remote, the garage door opens.  Sweet.  Get to the car, hit the remote car alarm disable/door unlock and…. no response from the car alarm.  No matter how many times or how long I mash the button, no response.  %$#@.  So… this variant probably has the same frequency as my car alarm remote.  Unplug the door sensor transmitter and still no car alarm!  Evidential the rolling code has gotten confused because of either the noise or the number of times I mashed the button with no response.  Sigh… I end up having to reprogram the car alarm remote in order to get it functional again.  More internet digging, the car alarm is exactly 315Mhz as well.

Back to the drawing board.

So, I think maybe the comments about needing to continuously transmit a data stream are incorrect.   Some software and hardware modification are required so the ATTINY13 running the transmitter can power the transmitter on/off.  It appears one ATTINY13 I/O pin can put out just about enough power to drive the transmitter.  So I re-wire the transmitter board to connect one of the ATTINY13 pins to the transmitter power pin.

Final Garage Door Sensor circuit

I then recoded the software to turn on the transmitter every 10 seconds, then send a couple of copies of the data stream and then turn off the transmitter.  The receiver is recoded to only show an error if it’s been more than 20 seconds without a valid data stream.  I figure that way I can miss one of the every 10 second transmits and still be OK.  I also figure that a brief burst of signal every 10 seconds really should not interfere with the car alarm.  I mean, what’s the chance that I’ll hit the alarm remote right when the door sensor transmits.  Besides, if I do, then just pressing the alarm remote button again should get a signal through as by then the door sensor will be into it’s idle state.

Code it up, install it, it works!  The door sensor works, the garage door remote works, the car alarm works.  I do every now and then see erroneous data on the door sensor receiver, but it clears up upon the next 10 second transmit.

Garage Door Sensor switch

Garage Door Sensor TX

Garage Door Sensor RX


Skip to comment form

    • admin on July 4, 2010 at 9:24 pm

    Still futzing with the code. the open signal works 100% of the time, but the error rate is still higher than I’d like it to be.

    • arjan on July 5, 2010 at 11:52 am

    did you try sending the signal with after every byte of data, the same byte in reverse (255-b) to make the amount of 1’s and zero’s the same? It might make it easier for the receiver to keep track of the bits.

    Also a bipole transmitter-antenna might considerably help.

    • Khuong Truong on July 5, 2010 at 5:07 pm

    how does a bipolar transmitter-antenna would help in this case im curious?

    • Erich on July 5, 2010 at 6:17 pm

    Some amateur radio theory might be of interest in relation to interference between the sensor transmitter and door opener receiver.

    You could have mounted two dipole antennas at right angles, one cut for 434 MHz, and one cut for 390MHz, and fed them in parallel.

    Such an antenna system would have been resonant on the two different frequencies and being at right angles, the two dipoles might not have interacted with each other as much.

    Alternatively, a two circularly polarized antennas, one left hand circularly polarized for the sensor, and one right hand circularly polarized for the door opener, would have reduced interference a lot. Helical antennas are not hard to make with wire and a former, and would be about 200mm (8 inches) in diameter for these frequencies, so a little bulky.

    Coolest of all (hack value) would be a cavity filter made with a food tin, to allow the 434MHz through but keep the unwanted 390MHz out of the door opener receiver. Google “cavity filter Harry Lythall” for dimensions of a suitable cavity. Omit the diode in the loop and you have a bandpass filter made out of a food tin with input and output terminals.

    • Blacknight03 on July 5, 2010 at 6:28 pm

    You do know that using an RF transmitter will lower the range of you garage door remote. Liftmaster openers have a problem with other signals around them. so if you see a drop in the reange that your remote is working this is your reason.

    • ke7eha on July 5, 2010 at 7:03 pm

    I think he meant dipole antenna. It could possibly be more efficient than a wire loop antenna (particularly if the loop was not properly sized) but it is omnidirectional. Perhaps a mroe directional antenna may help with the interference issue.

    One method of dealing with cluttered frequency bands is making the transceiver pair frequency-agile. Some commercial radios are capable of this, including the Texas Instruments CC1101. Unfortunately, the sparkfun radios are too far on the ‘hack’ end of the spectrum to have this ability.

    Burst transmission would also help with the interference issue as well, as the radio only is on when a packet is being transmitted. Some digital radios, again including the TI CC1101, are capable of burst transmission.

    • admin on July 5, 2010 at 9:05 pm

    Since I’m only sending one bit of data plus w/ a parity bit, I’m effectively sending the ‘reverse’ of the data every time. with the start/stop bits I end up with door open being 111000 and door closed 110100 thus always a matched number of ones and zeros all the time.

    I was just reading some stuff on the X-10 powerline signal and it’s also data + !data for each bit, but I think they use a 3 bit on preamble rather than just the 2 bits I’m using now

    • the yar on July 5, 2010 at 10:59 pm

    I’ve been working on my version of this for a while, pretty much the same parts all around. The difference is that on the display end, it connects with the PC instead of showing LEDs.

    The idea is that once other parts of my home automation come together, it should send me a text message when I leave and fail to close the garage door. Then sending a response message within some time period should make the door close.

    • guillaume on July 6, 2010 at 1:11 am

    I noticed that the switch on the transmitter side has no pull-up resistor, so when it is open, you might get errorneous signals.

    • admin on July 6, 2010 at 4:50 am

    Pull-up on the switch should be internal to the attiny13. However, I’ll have to go check the code to make sure that I actually *enabled* the pull-up resistor on appropriate pin.

    • ryan on July 20, 2010 at 9:43 pm

    I have the same transmitter and receiver, and just ordered some ATTINY13’s, waiting for them in the mail! I have a scoreboard I made, and was making a wireless glove for it. The receiver is hooked up to an Arduino board, but was planning to hook up the transmitter to a modified version of the Lilypad Arduino, but then I saw I could use an ATTINY13 and save some space AND money! Just wondering if you could email me the code? I know you said you’re still futzing with it but I’ve never programmed an ATTINY13 and the resources out there for it are NOWHERE near that of an Arduino board! If you could, that’d be great! My email is ( I’ll definitely give an update to see how things turn out too! Thanks!

    • admin on July 21, 2010 at 4:54 am

    re: ryan, coming your way…

    • Kurt on August 20, 2010 at 5:11 pm

    Same here ….. would love to see the code used on the Tiny13

    Might test this with 2 Xbee’s i have sitting around.


    • ryan on September 20, 2010 at 8:38 pm

    Hello! Same Ryan as before… Just wanted a bit of help with the code! It’s been a long summer with many projects and school’s in session but I finally have some time to work on this! I have the board made and everything, the only problem is I’m having a bit of trouble reading your code, simply because I’m only used to programming in C++. If you have a chance, can you do a quick rundown in pseudo-code?
    As well a few questions….
    a) I’m only transmitting on a button press, so do I need to worry about interrupts?
    b) Do I HAVE to hook the power from the transmitter up to the SCK pin, or did you just do that to save power?
    Any help would be greatly appreciated! Or even if anyone else could answer my question, I’ll be glad to share any code/schematics/plans/pictures of everything when it’s done!

    Thanks again, and if you want to email me my email’s up above (3 posts)

    • admin on September 21, 2010 at 7:47 pm

    In the Xmit code, you can safely omit all the debug code, ie the LDI R20, rcall Dbg stuff as well as everything from Dbg: to the RET

    pseudo for Xmit kind of looks like this:

    bit pattern to xmit is:
    11, SwitchState, !SwitchState, 0

    on reset, initialize ports, timers, etc
    at start turn the radio on
    wait for some time to make sure the radio is powered up
    FullDelay is just a delay routine to generate the bit time (ie how long a bit is on or off)

    radio on (sending a 1)
    send a 1 for 2 full delays (ie the 11 pattern)
    test the switch
    if on, goto SW1 and transmit a 1 for 0 pattern
    if off, goto Sw0 and transmit a 01 pattern
    then send a stop bit (ie transmit a 0)
    repeat this 5 times (ie counter steps 5 down to 0)
    after transmitting the bit pattern 5 times
    power off the radio
    run around the ‘more’ loop doing nothing for 10 seconds
    thus 10 seconds later do the whole thing again.

    11010 or 11100 repeated 5 times, then 10 sec silence, then repeat

    • admin on September 21, 2010 at 8:06 pm

    receive is a bit more complex 🙂

    GetBit just samples the radio data pin 3 times, best 2 out of 3 is what’s returned. Nothing more than a simple filter to try to eliminate random noise

    The idea to decoding the 11010 or 11100 is to first find a 0 to 1 transition, then make sure it stays a 1 for 2 bit times.

    At that point you can assume you found the pre-amble, so you’re now in the bit pattern

    There’s an extra 1/2 bit delay to get into the *middle* of the next bit. that way if there’s timing inaccuracy, sampling in the middle of the bit means you’re less impacted by it.

    get bit 3, then a full delay and get bit 4. that’s Switch and !Switch, so bit 3 and 4 should never be equal. ie if they’re equal, the data stream is invalid and the error LED should be lit. if they’re different, then consider it good data and set the LED pin based on bit 3 state.

    At that point your still approx in the middle of bit 4 which could be a 0 or 1, so StopBit just waits until the 0 starts which gets you into the final 0 bit. At which point you loop back to the top waiting for a 0 to 1 transition that may indicate a new preamble (ie 11) bit pattern.

    The only extra bit is the ‘watchdog’ stuff which isn’t really using the chip’s watchdog functionality. it’s just counting time so that if we don’t see a valid bit 3/4 combination for over 20 seconds, then we’re well screwed up and signal with the other LED. ie worst case if the xmit code is sending the bit pattern every 10 seconds, in a 20 second period we aught to see at least *one* valid bit pattern.

    Make any sense?

    • ryan on September 21, 2010 at 9:12 pm

    Okay great! Thank you so much! I’m doing some assignments as well (in Software engineering, only 2nd year though) but will definitely try to get this working asap! Thanks again for your help!

Comments have been disabled.