Start • RFID Technology • High-Level Overview • Hardware • Software • Design Improvements • Sources and PDF

SOFTWARE

Although the hardware portion of the RFID security system performs many of the critical functions of the reader, it would not be complete without proper software. From the program’s perspective, there are two main modes of operation: Security and Administration.

In Security mode, the reader functions as (surprisingly) the actual security system. When idle, the reader is constantly transmitting the carrier signal and waiting for a card to come into the electromagnetic field of the antenna. Once a card is detected, we keep reading until the same code is read three consecutive times. This code is then compared to the code bank stored in EEPROM. If this code matches any of the authorized codes in the code bank, the security system allows access for 3 s and signifies this by lighting a green LED. If the code is not stored in the bank, a red LED is lit for 3 s signifying that access was denied. When a card is read and either access is granted or denied, a message is sent to the PC that logs the ID number read from the card, the time at which it occurred, and whether or not access was granted. The reader enters this mode of operation on reset.

In Administration mode, the administrator has the ability (using a serial communications program such as HyperTerminal or API) to change the state of the security program, be it adding and deleting codes, unlocking the “door,” or putting the program into a state we like to call “Remote Administration mode.” The administrator can also query the microcontroller to list all of the codes stored in the code bank.

In Remote Administration mode, the administrator can add codes to the code bank by directly scanning the ID cards into the reader. This method of adding authorized IDs to the code bank is useful because there is no specific correlation between the data stored on the card and the person’s name, identification number, or any other personal information. Thus, it is the only feasible way to add codes to the code bank without having to know what number is stored on the card. To prevent reading errors and possibly storing corrupted codes in the code bank when operating in this mode, the reader will try to read the same code five times, as opposed to the three in regular Security mode.

Remote mode has two submodes: Positional Add and Batch Add. In Positional Add, the administrator specifies the specific code bank slot to add a code to and overwrite prior codes if they are there. In Batch Add mode, the administrator need only specify the number of codes to add to the code bank (up to 20) and the program will add them into whatever empty spaces it can find, stopping and prompting the user when all of the codes are added or there is no space remaining.

Serial communications on the microcontroller side were handled by a combination of the USART interrupt and functions found in the stdio library in order to send data to the administrator computer, and our own non-blocking function to receive instructions from the administrator. We chose a data rate of 9,600 bps because we didn’t really need anything faster. If you want specifics about how the functions work, please refer to our source code posted on the Circuit Cellar FTP site. For interpreting data coming from the administrator, we developed a very simple syntax, which was, for the most part, one or two letters to serve as an opcode and up to two arguments. This is detailed in a Help screen when the system boots.

How does the software know when there is a card in the antenna’s vicinity? The reader knows there is no card near the reader when the output of the flip-flop/counter circuit is logic low. When a card comes within the antenna’s read distance (approximately 3' ), the datastream from the data-processing circuit begins to pulse at TTL levels. We know that this input corresponds directly to data from the card in an NRZ format, so all we need to do is sample the data at the proper intervals.

We employed one of the ATmega32’s asynchronous external interrupts using the output from the comparator in our filter stage to trigger the interrupt (see Photo 5). Once we noticed that the datastream went high for the first time, we began storing samples in an array until the array was completely filled. Initially, when we were still developing the reader, we had no idea what this response was going to look like. Luckily, careful observation revealed a definite periodicity of 540 bits, which gave us plenty of confidence because it looked like we were on the right track.

To illustrate the basic idea, let’s pretend the number of bits received is only 78 bits long. A particular sequence received from the card would look something like:

111111111111111100000111111000001111111

111110000000000111111000000000000000000

The long sequence of 16 ones is the start sequence. The last sequence of 18 zeros is the stop sequence. The data in between is grouped in five to six zeros and ones. At first, we had no idea how to interpret the numbers, so we looked at it the simplest way possible. We assumed that a group of five to six zeros or ones condensed down to a single 1 or 0 bit. Afterward, this theory made sense. The circuit on the card probably doesn’t modulate precisely enough; thus, it pads a bit with a sequence five to six bits. Analyzing the 78-bit sequence above with what we learned, we removed the start and stop sequence and condensed the groups of five to six bits to single bits to get another sequence:

01011001

Although it may not be immediately apparent with an 8-bit sequence of numbers, it was very obvious that the full 90-bit sequence was encoded Manchester code. By splitting the sequence into pairs of bits, there is always a transition, either from low to high or high to low. In Manchester code, the former transition signifies a one and the latter signifies a zero. Applying this to our existing sequence, we got the following sequence:

1101

As you can see, the long 78-bit sequence stored only 4 bits of actual data. For our Cornell ID cards, the 540-bit sequence decoded to a 45-bit code.