jordan.terrell
Just trying to make sense of things...

RFID Lock Prototype: Ethernet Enabled

Saturday, 2 May 2009 09:09 by jordan.terrell

Now that the Arduino DHCP library is fairly stable, I’m turning my attention back to my RFID Lock prototype.  I’ve integrated the DHCP library and it’s working perfectly for me.  The next step is to work out a protocol that the lock will respond to.  I’ve decided to use connection-less UDP messages.  I’ve already hacked in the ability to lock and unlock the deadbolt by sending a simple UDP packet – this was just to test connectivity.  I’m working through the protocol in my head (e.g. the data format, different commands, etc).  I think that I want to use the Open Sound Control (OSC) protocol as the format of the messages.  The nice thing about OSC is that it doesn’t tie me to lower level protocols (HTTP, SOAP, REST, TCP, UDP, etc).  As long as I can send and receive OSC messages, I can abstract away the communication details from the RFID Lock firmware.

Once the first draft of the protocol is finalized, I’ll begin working on a secure ASP.NET MVC application that will let me interact with the RFID Lock.  I’ll also be looking for secure ways to have it interact with my cell phone.

RFID Lock Prototype: DHCP Enabling

Sunday, 12 April 2009 12:15 by jordan.terrell

Last time I mentioned my RFID Lock prototype, I said that I was going to work on enabling Ethernet connectivity.  I knew that the Arduino Ethernet hardware and supporting library didn't directly support getting an IP address (and other supporting information) via DHCP.  I began to look around to see if someone had developed a library that would handle the DHCP handshake, and unfortunately I could find no such library - only comments of people wishing someone would develop such a library.  Well, I've started just that - a DHCP library for the Arduino Ethernet shield.

I found an DHCP Application Note on the W5100 (Ethernet IC used on the Ethernet shield) manufacture's web site.  It contained an entire application designed for an Atmel ATMega128 that would acquire an IP address via DHCP.  Although much of the code was written for already, I had to do a LOT of refactoring to get it to work as an Arduino library.  Good news is, I just accomplished my first DHCP handshake and acquired and IP address with it. However, it wasn't easy.  I kept experiencing some really strange behavior - random garbage being sent in the DHCP packets (I used Wireshark to monitor the traffic), the MCU would appear to freeze, and it would restart itself.

Finally, I had a hunch that I might be seeing the results of memory corruption or memory boundary violations - after all, I'm coding in the "Arduino language", which is essentially C++ under the covers.  I found a little code snippet that would check for available memory and found that I didn't have enough memory to allocate the structure I used for sending DHCP packets.  The provided Client class in the Ethernet library apparently takes up a lot of memory and I was allocating it right at the start of the Arduino program; I was using a modified version of the sample program that queries Google for sites containing "Arduino".  Once I removed the code that allocated the Client object, I saw that I had ~630 bytes of memory remaining, and I knew that the DHCP packet takes ~550 bytes of memory.  I ran the program again, and it acquired the IP address successfully.

I'm going to try and refactor a few things so that the DHCP packet memory is only used when it is needed - however, since it takes up more than half of the memory available on an Atmega168 chip, I'm thinking that it will be difficult to support on that chip.  I'm going to have to switch to the Atmega328 chip - TWICE the memory!  I plan to test it on an Arduino Duemilanove (both Atmega168 & Atmega328), and Arduino Mini (Atmega168-20AU), and the Arduino MEGA (although I read something that said the Ethernet shield might not work with the MEGA yet).

Once I get a little more polish on the library, I'll submit a patch to Arduino and publish it myself.  I'll be sure to note any memory issues or other concerns that I come across.

RFID Lock Prototype: Ethernet Enabling

Sunday, 15 March 2009 09:32 by jordan.terrell

I've made a bit of progress on my RFID Lock prototype.  I've got it recognizing valid RFID tags, and rejecting invalid ones.  I've also got it recognizing all the keys on a keypad, and if the deadbolt is in the unlocked state, pressing the lock button will lock the deadbolt.

One might think that this prototype is done - ready to be installed.  Not so!  The next phase of the project is what, I think, is going to make the lock interesting.  I'm going to add Ethernet support!  The end goal is to have a secured custom web site that will let me manage the list of RFID tags that are able to unlock the deadbolt, time windows when individual tags are active, plus logging and notification.  When I use my card, I don't need to be notified, but if a family member uses their card (someone who, under normal circumstances, shouldn't be unlocking my door) I will be notified via email/SMS.  I can also imagine having the "hidden key under a rock", but have it not be active - if someone who I haven't given a key to needs to unlock my door, I can remotely activate the hidden key for a brief period of time.  In talking with John Park about this prototype at MAKE: Day, he asked if I was going to have some kind of remote unlock directly from the web site.  Probably not - I'll stick to requiring an RFID tag.

Since I've been using Arduino for my microcontroller platform (technically it is the Atmel ATMEGA168 microcontroller), much of the design heavy lifting for including Ethernet connectivity has been done for me.  There is an Ethernet hardware shield and an Ethernet software library.  It's all based around the WizNet W5100 Ethernet chip. At first, I just bought the W5100 chip from Saelig, thinking that I could build a breakout board I can use on a breadboard.  Being that it has 80 pins (73 of which can be connected to) it was going to be a rather long breakout board, but I've been having trouble with the board layout.  The PCB manufacturer that I want to use requires traces to be 8 mils (0.008 inches) wide and spaced 8 mils apart.  You might think that that is very small, but since I'm trying to route this on a board that is spaced about one (1) inch wide, it is proving difficult.  If they would allow 6 or 7 mil width/spacing on a two layer board, I would have been done already.

SchmartBoard with ATMEGA168-20AU For those familiar with Arduino and the Arduino Ethernet shield, this might seem like an unnecessary task.  My argument is that I want to learn more about the W5100 chip and how to embed it in a circuit because 1) I like understanding how things work under the covers, and 2) I'm not planning to use the Ethernet shield in my final design.  I plan on building a custom PCB.  To do that, I'm going to need to be able to program an Atmel ATMEGA168-20AU - it's the same chip that is on the Arduino Mini board.  To put the Arduino bootloader on the chip, I'm using the FTDI FT232RL BitBag approach.  I wanted the have some way of easily programming the chips without them having to be in a permanent circuit, so I bought a SchmartBoard of the appropriate size from Mouser, and using painters tape I affixed the chip to the surface (see photo).  Now I can install the bootloader on this chip without having to put In-Circuit Serial Programming (ICSP) pins on my RFID lock PCB.  I tried to use a SchmartBoard for the W5100 Ethernet chip, but the traces in the center of the board were too short.  So I ended up buying a standard Ethernet shield for now so I can work through the rest of the firmware development.

Once I have a stable build of the firmware using the Ethernet shield, I will make another post.

DSC_9621   DSC_9622

RFID Lock Prototype

Friday, 20 February 2009 08:06 by jordan.terrell

Earlier, I mentioned my new found interest in embedded hardware.  I've been working on a small project for my house, a RFID tag controlled lock, and I've got it working on my bench.  Pretty cool if I do say so myself.  My next step is to figure out it's permanent power source and how I manage access control (i.e. specify which cards are granted access).  I've got a few ideas on how to do this, so I'll follow up with another post when I get a little further.

 

Tags:   ,
Categories:   Embedded Hardware
Actions:   E-mail | del.icio.us | Permalink | Comments (0) | Comment RSSRSS comment feed