Jump to content

Garage door opener

Recommended Posts

I'm trying to make a garage door opener using some cheap CC2500 boards bought through a group-buy at 43oh.com (2 USD each) and a really nice board designed by RobG. I've made a prototype first, and it seems to work, but is not very pretty. I need to maybe make it more compact and make a case for it. Here's a picture:


The code is definitely not finished, but you can download it here if you want to look at it. It's based on the TI CC2500 library (not SimpliciTI, which would probably have been a natural choice). I'm using the bitbanging version, as I didn't have any surface mount MSP430G2553.

I guess maybe I should put the battery beneath.

Link to post
Share on other sites

Looks good. I'm just getting started on the CC2500 modules that I got with the GB.

It looks like the switch simply supplies power to the MCU + CC2500. If that is so, how long does it have to be pressed in order for the MCU + radio to startup and transmit?



Link to post
Share on other sites

The battery holder is this one http://no.farnell.com/jsp/search/produc ... f-00001000 It has room for a larger battery than I am actually using. Plan is 2032 battery, but using smaller right now.


The switch connects power, as you noticed. It transmits immediately. I can't notice a delay.


Did it this way to make sure the battery lasted :) Sorry about the bad writeup :D will write more later. That is basically the only connection. Button connects power, and software transmits a few times every second while power is on. I have made a new board now with an led also, but not really necessary. Very simple and works ok the way it is made on the picture with a protoboard.


The garage unit is not shown. My garage opener has an input I can connect to which opens or closes the door (same input does both). The input needs a relay (12 volts). So the plan is a similar unit, but connected to mains and with a relay to open/close door.


The protocol is simple. Basically transmit a 10 byte static random code. No real security. No pairing of devices like mesh networks /simpliciTI. I guess anyone could download the code and open my door. I may implement a protocol that uses encryption. These can be used to encrypt: http://www.ti.com/tool/des-msp430 or http://www.ti.com/sc/docs/psheets/abstr ... aa397a.htm


These cc2500 modules are really cool and seem to work well. So many things we could do with them. If you have an idea, feel free to post it here. One thing I would like to do is to make a remote control for my mini-quad. Or a mailbox notifier. Or some sort of toy for the kids. Or a remote controlled thermostat. Could it be used for soccer players? Put one device on each player. Unsure for what, but maybe it could measure their activity. Or maybe something for skiing. A sensor on the ski, transmitting to the chronos watch. Or base stations you pass to measure race time. Winter is approaching.

Link to post
Share on other sites

Very nice!

Maybe you can have a look at http://en.wikipedia.org/wiki/HOTP for security. It's the kind of cryptographically-secure unpredictable sequence generators that banks use for two-factor authentication. Google's two-factor authentication uses it too.


The idea is that you apply an HMAC function (some kind of hash involving a private key) to a counter. Both transmitter and receiver need to store this counter. Since both will usually be in sync, the HMAC received can be compared to the expected value, based on the shared private key, and the counter. If it fails, it can also try a few counts ahead too, in case the button was pressed accidentally out of the receiver's range.


Although banks and Google use a time-based algorithm, it's essentially the same, but using the count of 30-second ticks instead of an event counter. I think I've seen a version for the Chronos that is compatible with Google Authenticator. Should be trivial to adapt.


Since you will need to store a counter, FRAM would be ideal for zero-power-standby. But you can also use flash, or just have the MSP sleeping in LPM4 the whole time and wake it, with an interrupt from the button, for transmission (at a few uA it shouldn't be noticeable).

In this last case, you could use a three-way handshake, much like TCP/IP sockets, for keeping the counters in sync. Something like

  • [*:3rhtxy43]Remote: HEY, the current code is 123456.
    [*:3rhtxy43]Receiver: OK, please come in.
    [*:3rhtxy43]Remote: Thanks! Increment the counter! (I will increment it too)


I could continue giving ideas for centuries, it's a very interesting topic.


Cheers! I hope you're not locked out!

Link to post
Share on other sites

Hows the range on the modules? I only get like 25 feet max with these CC2500 modules. I've been trying to find a suitable PA/LNA to boost the signal a few dB. None of the manufacturers of them will send me samples though :(.


I noticed you wanted to make a mailbox monitor.. I've made something similar using one of these: http://www.ebay.com/itm/Wireless-Door-Window-Magnet-Sensor-Detector-For-Alarm-System-433-MHz-/271033425757?pt=LH_DefaultDomain_0&hash=item3f1ad9df5d


They use a PT2262 OOK encoder, I just used a receiver like this one http://www.ebay.com/itm/433Mhz-RF-transmitter-and-receiver-link-kit-for-Arduino-ARM-MCU-voltage-3v-12v-/300733295714?pt=LH_DefaultDomain_0&hash=item460519ec62 and did the decoding in software.


One time lightning blew out the remote receiver for my garage door, damn thing cost $50, you made a nice one for a couple bucks, good work!


I wish I documented my projects better myself, I don't really document anything so half the time I end up redoing stuff I've already done :oops:

Link to post
Share on other sites

I found this link with code I can use. I think maybe I would only need a hash, as I can transmit a long code.


http://circuitcellar.com/featured/ti-ch ... passwords/


Another way of doing it could be to use standard encryption of a counter value. The 'server' could keep track of the counter.and only allow higher values. If it decrypts the message to 1235 and it has received this or a lower value before, it rejects it. Then I don't need the ack, but it is still robust to lost packets.

Link to post
Share on other sites

Yeah, I guess accepting only increasing numbers is fine. If you use a sufficiently long counter (32 bits?), it'd be fine. I doubt you are ever going to get 4 billion events in the lifetime of the system. You'll need to swapt the battery first (and then you will have to resynchronize somehow). I think a simple synchronization scheme will do. Something based on button pressing and/or jumpers (say, put a jumper in the remote to set it to "sync mode", and then press a button on the server to transmit a new key and start counter at 0).

If you get sophisticated, you could have multiple remotes with different private keys (and their respective counters), thus allowing you to revoke access to one particular remote, or selectively grant access to different remotes according to some parameters (time of day, door requested to be opened [if you put more than 1 door controlled by one server], etc.).

Link to post
Share on other sites

Here's another option. Server would sends a challenge to remote with a random number, remote hashes it or encrypts it with a shared seed and sends it back to the server. Server either decrypts it, or hashes it and compares. No problems with out of sync counters and server could send new seed to remote every few successful authentications.

Link to post
Share on other sites
  • 1 month later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...