Most of the traffic to my website appear to come from people interested in my Senior Design RFID Project that I finished back in 2008 to graduate from the University of Iowa Engineering Department.

They search fairly typical keywords: RFID, manchester, decoding, hid, hack, spoof,  125kHz or other basic parameters of RFID technology.

These key-word searches increase during the middle of the semester, when I surmise the students are scrambling to figure out how to make their OWN RFID Senior Design projects work.

It’s cool.

Recently, some guy going by sketchsk3tch on Instructables referenced my senior design project. It was VERY kind of him to add my project to his list of references, but wasn’t to happy with what he mentioned in reference to my project, stating, “School project, cool ideas, missing some details though.”

Missing some details? Like what? The entire schematic is up on that page! What more does this guy need?

Which brought me to another issue: Why didn’t he ask me for those missing details? Because, I would not have provided the REAL missing piece: The Arduino Code. Yeah, he would have “stolen” the Arduino code (the Java-like code that instructs the Atmega168 PIC we used for the project). Well, maybe he wouldn’t have “stolen” it, but I’m confident any bits he used would NOT have been attributed properly.

…and that is precisely the reason the entire RFID project is NOT up on my website. I hate leachers. Period.

As much attention my Senior Design Project seems to get from across the globe, I refrain from providing some of the critical pieces to make the entire project work. It’s self preservation.

So, to those seriously interested in my project, skim through my website and have fun. It’s for the community to enjoy. Ask me questions! I’ll answer, but don’t be surprised if I make you work at it. How else are you really going to learn?

I ran across this article on one of my favorite geek-sites, Engadget. Being a huge fan of Mythbusters (along with the rest of my family), I was struck by how frustrated and animated Jamie became when discussing a squashed episode involving them taking a closer look at how hack-able RFID technology can be when not implemented properly.

Being as I now work in the RFID business and that my senior design project involved hacking an RFID tag, I am still astonished that large corporations can put the ‘kabosh’ on a story that needs to be told in order for us in the engineering business to work to make it [RFID] better.

It’s been a busy semester as Team Wombat has been working at a feverish pitch in order to successfully complete their senior design project: The RFID Hacker.

For those that don’t visit this blog often, our senior design project is a device that will read and write RFID tag information. What is RFID? Well, you know when you walk into FootLocker at the mall and the security alarms go off? That’s an RFID tag system. The book you bought at Barnes & Noble still have an active RFID tag embedded in the spine of the book because the bookstore clerk forgot to disable the RFID tag. An RFID tag is much like an electronic barcode, except you don’t need to wave a laser at the purchased item in order to determine it’s sale price.

Why build an RFID hacker? Well, RFID is used for security purposes and we at the University of Iowa Engineering College have an RFID security ID card so that we can access the Seamans Center during off-hours. RFID technology is great, but since it is an open-source technology, almost anyone with enough time and electronics background can defeat RFID security measures.

So far, our project is going well. We’ll be populating our 2nd printed circuit board throughout the upcoming weekend, not to mention the final project report AND a huge poster for our final presentation. For more information regarding our progress and more about RFID technology, visit our senior design project website here.

Spent last weekend at the folks house. Mom is doing much better since i last visited two weeks ago. She’s getting around MUCH better than before. Mom has pretty much discarded the walker and was pretty pleased with herself when she found she able to get in-and-out of the rocking chair that’s been a fixture in the living room.

Larry was gone much of the weekend on one of his many bowling excursions. Beth, John and Emmett watched over Mom from Friday through Monday. Christine came over Monday and hung-out until Larry got back on Tuesday. Things went pretty well.

I’m still finishing my last semester at the University of Iowa. Much of my time is taken up integrating the PIC18F452 and EM4095 for my Senior Design Project: Hacking RFID. To learn more, just visit here and you’ll get a gist of what I’m dealing with.

The semester has wound down and now it’s time for my lab partner, Derek, and myself to build our final project using the PIC18F452. There are no restrictions on how what programming tools to use, so we’ve so far determined that we’ll be writing it all in C18.

Our final project will be based upon previous lab projects, however, instead of using a magnetic-stripe card-reader, Derek found a cheap RFID reader that we’ll be using instead. A magnetic-strip card-reader is the same type of device most people use to swipe their credit / debit cards when making ATM withdrawals or purchasing clothes at your favorite retailer. An RFID reader is similar to the ‘pass’ card machine that an elephant used to purchase cold / flu medication for his favorite zoo keeper in a recent commercial I’d seen on television. They operate in a similar way that the security turn-stiles at the local Target beep at you when the cashier forgets to remove the large plastic tag from your newly purchased t-shirt and tennis shoes. If you are a resident of Chicago, IL, you’ve seen similar RFID devices for the fast-lane of the numerous toll booths in the surrounding area.

RFID stands for Radio Frequency Identification and there are two basic types: passive and active. In order to keep RFID tags small, many of them are passive; they require no internal battery or power supply. Active RFID tags are larger, since they use an internal power source (perhaps a battery), however they have a much greater range which is beneficial in areas (like electronics toll booths) where there is an increased amount of RF traffic. Everyone has a radio in their possession and that’s how RFID devices work. They contain small antenna tuned to a specific radio frequency and when the RFID device passes within inches of its associated transmitter, the RFID devices converts the received RF energy into actual voltages and current to power up its built-in microchip. The RFID’s built-in microchip then transmits a series of digital ones and zeros that form that devices identification number. The identification number is similar to that of the average bar-code you see on the side of your box of Cheerio’s. The transmitter also has a built-in receiver, so that when it ‘hears’ the sequence of bits spat out by the RFID device, a series of actions are performed depending upon what the RFID device is used for: open a lock, log an entry into a database, return price information, charge a toll fee to a FasTrack subscriber, or set off an alarm.

Here at the University of Iowa during off hours, engineering students use a passive RFID card to gain access to the Seamen’s Center / Engineering Building. This is the kind of device that we’ll be using for our final project, which we’ll be basing around the Parallax RFID Reader Module shown in the picture above. Parallax reader is a 3″ x 2.5″ blue circuit board that uses a 2400 baud TTL serial interface. It is an ‘output only’ device that only requires a single +5VDC supply and houses an LED for a visual indication of activity.

Part of the trick with our final project will be to read the serial data from the RFID reader, while being able to output text information to a computer terminal. Since our PIC18F452 development board (shown at the top) has a single serial interface, this poses a communication problem.

How do we communicate with two devices with only one interface?

Fortunately, the RFID reader is an ‘output only’ device, while the PC terminal CAN be used as an ‘input only’ device. A typical serial (RS-232) interface has three connections (Transmit, Receive and Ground). The RFID reader will use Transmit and Ground, while the PC terminal will use Receive and Ground and they won’t be talking to each other directly. They will be talking to our PIC18F452 or listening. They won’t be doing both.

Wait. Doesn’t RS-232 use +/- 12VDC for it’s transmit and receive logic? Isn’t the RFID reader using TTL (+5V and Ground)?

Yes. But not to worry. Our PIC18F452 development board has a MAX232 chip, which will convert between TTL and typical RS-232 voltages. We’ll need to use that chip to communicate to the PC terminal, but we don’t need it to communicate with the RFID reader. Instead of routing the output of the RFID reader to the input pin to the MAX232, we’ll route it directly to the receive pin of the PIC18F452. In fact, instead of leaving the MAX232 chip plugged into our development board, we’ll remove it and mount it into a socket that is soldered into a smaller development board.

This would all be fine and dandy, but we still need the ability to program the PIC18F452. So, since we need some ‘bi-directional’ communication between the PIC18F452 and the computer in order to upload our (soon to be developed) program, we will route the Receive line from our development board to a switch so we can ‘choose’ which input to accept (the PIC programmer or the RFID Reader).

In the photograph above, you’ll see our PIC18F452 development board with the MAX232 chip removed and re-socket-ed onto a small square pc board. Although small, we’ve mounted the small DPDT switch to the right of the chip. The RFID Reader (held in the blue desk-clamp) is connected to the brown circuit board through four wires (+5V, GND, Chip Enable, and Serial Out).

Our initial code (written in C18), simply waits for an ID card to be placed flat and several inches away from the RFID Reader. Once the ID card has powered up from the Radio frequency generated by the RFID Reader, it ‘spits out’ its digital ID # stream, which is read back by the RFID Reader and sent to the serial input (MAX232) of our PIC18F452 development board. Our code re-assembles the ID # stream into 8-bit bytes, and sends the data out to the terminal, so we can determine what ID # was received.

(April 28, 2007) – Spent some time yesterday trying to incorporate code from our last several projects into this final project. We are currently trying to incorporate the 12-digit keypad, but appear to have found ourselves stuck. Typically, we print out the value of the key that was pressed back to the terminal, but when we tried this Friday it didn’t work. Plus, we found that our RFID Reader no longer worked. I’ve been working this issue this afternoon and have finally found the culprit. Simply put: WE GOT LAZY. When we determined that the RFID Reader was ready to send us data, we stupidly turned around and sent data back out to the terminal –> printf(“We got data “); This erased the contents of the buffer (holding our input data) with what we wrote back out. So, when we tried to read the contents of the buffer, it was empty. There was nothing to actually read. Talk about feeling stupid.

(April 29, 2007) – After Saturday’s fiasco, we still had more work to do with RS-232 communication. The frustrating part was the issues we were running into were not fully explained in the MPLAB C18 Manuals. The problem came from attempting to repeatedly read the ID numbers off of our RFID embedded cards (they look just like an ATM card, but blank with no magnetic strip on the back). We could read the cards MAYBE twice or three times in a row, before our C18 program would quit reading the data from the RFID Reader. We didn’t have any problems in previous labs when we were communicating via RS-232 to our PC terminal. Of course, those experiments involved serial communication at 19,200 baud. To communicate to the RFID Reader, we need so slow things down to 2,400 baud. After trying every ReadUSART, getsUSART and getcUSART command (and their variations) in the C18 Manual and tweaking the OpenUSART a hundred times, we finally hit upon the real problem: Framing & Over-Run Errors.

What are those? Well, they are the kinds of errors one encounters often when trying to dial into AOL from 30 miles outside of town. A framing error is an error in … ‘framing’. Every byte (8 or 9 bits) sent over the line has a ‘start bit’ at the beginning and one or two ‘stop bits’ at the end. A framing errors means that the receiver didn’t see the ‘stop bits’, when it expected them to appear. Conversely, an over-run error is an error that occurs when the receiver isn’t extracting the the received bytes fast enough. This means that the receiver is a little slower than the transmitter and there exists a risk that data will be lost. The RFID Reader spits out the RFID card data at 2400 baud, without regard to how fast the receiver is extracting the data. We can’t inform the RFID Reader (over RS-232) that data needs to be re-transmitted, in case the receiver suspects it has lost some information. Under NORMAL RS-232 communications, we could, but the RFID Reader is a transmit device ONLY. It won’t receive anything.

To fix this we had to dig through the MPLAB C18 Manuals to determine what the PIC18F452 does when it wants to flag a possible framing or over-run error. Unfortunately, no matter what we did, the USART_Status variable (suggested by the C18 Manuals) did absolutely NOTHING. We had to hunt down what this mysterious ‘USART_Status’ variable in the C18 source code to find the ACTUAL status bits this variable was supposed to represent. We found the right status bits in: RCSTAbits.OERR , RCSTAbits.FERR and RCSTAbits.CREN. OERR is the over-run error bit, FERR is the framing error bit and CREN is the bit to toggle (set low, then set high) when either of those errors occur.

(April 30, 2007) – Derek and I hammered away at this project for a few more hours. With the rest of the code in-place. It looks like we have a completed final project. We wondered if we needed to change some of the LCD messages, but we concluded it would be easier to change the intended messages in the flow-chart. We also discussed the possibility of adding the EEPROM code, so we could add the ID card numbers & PIN numbers into non-volatile memory. It would be nice, but it isn’t necessary for our “proof-of-concept.” We’ll have to offer our final presentation on Tuesday, which should go well… as long as I don’t spend too much time ‘yaking’. Derek will probably do most of the presentation, while I will field questions during the Q&A session afterwards.

(May 2, 2007) – The final presentation went well and our T.A. was VERY impressed as i put our project through its paces. Every-other word from his mouth was, “Cooool.”

(May 17, 2007) – The Spring Semester is over and grades are out. Our final project must have been a hit with both our instructor and the T.A. (teaching assistant). Somehow, after doing poorly on the first mid-term exam in Embedded Systems, I managed to pull an ‘A’ in that class. Here’s the PowerPoint Presentation we gave for the RFID final project. It’s been transformed into an Adobe PDF file: RFID Access Control System