RFID Interface

When I was a kid my parents bought me an electronics kit that had several different projects to build but the only one I remember was the vacuum tube AM radio.  I remember the thrill of having it work when I was done and then being able to occasionally tune in stations several states away when the evening atmospheric conditions were just right.  To me that was kind of like magic because I had no idea why it worked that way.

Today there is so much “magic” in electronics that I think we sometimes just take it all for granted.  One of those magical things is Near Field Communications (NFC).  It’s especially magical when applied to Radio Frequency Identification (RFID) where the key has no power source of its own for its communication circuitry.  There are several variations of RFID circuit modules available for experimentation and in this post we take a look at a simple, inexpensive one.

RFID Modules

RFID Module

RFID Module Pinout

While my electronics stuff was packed away during my move I bought three different RFID modules on ebay.  In general, these modules come in two different frequencies: 125 kHz and 13.56 MHz.  Some of them have a separate antenna and some have the antenna built into the circuit card.  Some communicate using TTL-level asynchronous serial, some use SPI, some use I2C, and some allow you to set switches to select the mode of communications.  Some can receive configuration commands and some are transmit only.  The one used in this project is pretty simple because it is transmit only and uses asynchronous serial communications.  One nice thing, if you are building a real lock with it, is that the antenna is separate.  That makes it easier to place it where you want it.

The RFID keys come in a variety of forms.  I bought a bag of 10 key FOBs for about $3 to go along with this circuit because it didn’t come with any keys.  You can also get keys in the form of a credit card, some with a hole for a lanyard so you can wear it around your neck.  I’ve also seen keys in the form of a flexible wrist strap.  Just make sure that you get keys that match the frequency of your RFID module.

Here’s a link to an online wiki for a similar board: http://wiki.seeedstudio.com/wiki/125Khz_RFID_module_-_UART


RFID Module Interface

The hardware is pretty straightforward.  The RFID module needs +5 volts and ground to operate.  The transmit output connects to the serial receive input of the PIC.  The Green LED will light up whenever a key is found in the PIC EEPROM and indicates an unlocked state.  The Green LED output can also be used to drive a transistor or relay that is used to power a lock solenoid.  The Red LED has two functions.  If it is fully on, then it indicates the locked state.  If the circuit is powered up and there are no keys found in the PIC EEPROM, then the Red LED will flash to indicate that a key must be added.

There are two locations in the circuit for temporary placement of jumpers.  These could also be simple on/off switches (e.g.: DIP switches) if you prefer.  The “Clear Mem” jumper will erase all information that was previously stored in the PIC EEPROM.  That jumper should be in position before applying power to the circuit.  After a few seconds both power and the jumper can be removed.

The “New Key” jumper allows you to store a new key in the PIC EEPROM.  Generally you would place that jumper before powering on the circuit because the check for it is done during the initialization part of the software.  To add a key when the jumper is on just place it near the antenna and wait until the Red LED goes out and the Green LED turns on.  As noted earlier, if the PIC does not have any keys in EEPROM the Red LED will flash on power up.  The software is set up so that you could place the “New Key” jumper while it is flashing and then add the key.  No need to power down first in that case.


The software link is listed below.  While it is targeted for the 16F688, it is easily ported to other versions of the PIC.  Just make sure that you choose one that has the asynchronous serial port capability.  You will also need to change the line that identifies the PIC version (LIST=) and the INCLUDE file but those are intuitive changes.  The __CONFIG line may also need tweaking just because one or two of the labels used are spelled differently in some of the INCLUDE files.

The RFID module transmits data via a TTL-level serial port whenever a key is detected.  The baud rate is fixed at 9600 so that is how the PIC asynchronous serial port is set up.  The key data consists of 14 bytes.  The first byte is always 02 hex and the last byte is always 03 hex.  In between are 10 bytes of key ID followed by two bytes for the checksum.  The interesting but complicating thing is that the data and checksum bytes are transmitted in ASCII format but represent hex values.  It complicates things if you want to verify the checksum because that is based on an XOR of packed hex versions of the data bytes.  Take a look at the wiki referenced in the RFID Module step of this post for how that works.

The heart of the software consists of reading the data string from the RFID module and the reading and writing of the strings in the PIC EEPROM.  When the data is read from the RFID module all 14 bytes are stored in PIC RAM.  To ease the search process the two checksum bytes (in ASCII format) are summed and written over the 03 hex byte at the end of the data string.  That value is used to do a quick search of the keys stored in EEPROM.  If a match is found, then the entire string is scanned and verified.  The 10 keys I bought all have different string values but two of them ended up having the same checksum.  The software handles that case.

One interesting thing I discovered is that the key FOBs all have a unique 10-digit code printed on the outside.  It would be reasonable to assume that the printed code would match the 10-digit value embedded in the key.  And you would be reasonably wrong because that is not the case.  I have yet to see an explanation for what the printed value means.

The Main_Loop in the software has several lines of Delay1sec following the setting of the Green LED (unlock) output.  After that, the Green LED is turned off and the Red LED is turned back on (locked).  That is consistent with typical behavior of things like entry doors.  You can easily vary the length of the unlock time by adding or removing delay function calls.

I originally included LCD message routines in the software during development so that I could see what was happening at various points.  You can still verify that the keys are getting stored properly in the PIC EEPROM without having an LCD connection.  To do that, put the PIC back into the programmer and click the arrow alongside the Upload symbol in the MPLAB X IDE software.  That will bring up a list of upload options including one to save the contents of the EEPROM to a text file.  The file created is called “memory.hex” (unless you name it differently) and can be opened with the Windows Notepad editor.  Keep in mind that the file gets written in 16-bit format even though the EEPROM is in 8-bit format.  Basically that means that every “real” byte of data is padded with a 00 hex byte in the file.  As can be seen in the sample file below, the first three memory locations will be 88 66 x0 where the third byte points to the next location for key storage.  All keys are stored on 16-byte boundaries so there are a maximum of 15 keys that can be stored.  That’s it for this post.  Check out my other electronics projects.