Sr. Design: RFID

Over the course of the Spring 2008 Semester at the University of Iowa, I will posting various information regarding the ‘reverse engineering’ of an RFID transceiver.

(May 11, 2008)

Full Board
the Final Product … this device can read, store and transmit RFID data.

The consensus is in: our RFID Simulator is (in the words of Prof. Kuhl), “Awesome job…but scary.” Which, in the end, is not so bad. What did we discover during this project? Primarily, we proved that RFID tags can be copied. Although it does take time and a lot of engineering ‘know-how’, cloning an RFID tag is a rather simple process. All it takes is a micro controller, an RFID front-end, and antenna and the necessary components to put the pieces together.

We really appreciate those that have provided meaningful insight into completing this project: Prof. Anton Kruger and David Quackenbush. Especially, our sincerest kudos go out to Prof. Andersen, who thought outside of the box and provided the spark that culminated in (what we believe) is the ultimate senior design project the University of Iowa Engineering College has every witnessed.

To my Team Wombat members: Derek Koenigsaecker, Jason Adrian and Ruxton Smith… Thank you for being who you are; some of the most intelligent, hard-working goofballs I have ever had the pleasure to work with. This could not have been done without any of you.

(May 6, 2008)

It Works :)
Parallax RFID Reader: NOW in Compact Form! 🙂

After much gnashing of teeth and trepidation, Team Wombat has managed the (nearly) impossible. No. We did NOT hack into the Engineering Building as we hoped. We did, however, manage to assemble version 3 of our PC Board. With only ONE lifted pad, we were able to assemble the module, test, and successfully capture a Parallax RFID card. Yes. We had high hopes to grab an HID RFID card, but who says we actually didn’t? From what we have been able to gather over the past week, we have begun to realize the possible limitations to the hardware we are currently using in our design. First, the problem may lay with the RFID front-end IC: the EM4095.

The EM4095 may not be able to transmit the captured HID RFID card data. This is not because the data is so encrypted, but because of the rather high data-rate with which the HID cards transmit data ( compared to the EM4102 RFID cards we received with the kit). If the EM4095 is not able to energize the antenna coil quick enough, then the HID RFID tag receiver may simply ignore the data as being ‘invalid’. If so, then we only need to utilize a more robust 125kHz RFID front-end.

After speaking with the rest of the team, it has been generally decided to continue this project past the end of the semester. Not only can we improve our computer application (GUI), but improve the design of the RFID Emulator.

Let’s cross our fingers. 🙂

(May 2, 2008)

Well, it’s not all sunshine and roses here at Team Wombat. We’ve built our circuit board, only to find several mis-judged assumptions (is that even a word?). Our board does NOT work at all. We found some missing connections and corrected them, but for some reason, our new board does not work. We continued to work on it through-out Friday afternoon. We gave up around 10pm. We’ll start back up late Saturday morning and hopefully with some needed rest, we’ll continue and determine what exactly is wrong.

Our last stumbling block was determining that our signal to the EM4095 (SHD) is not being asserted to a logic low (0 VDC). For some reason, it appears to be tied high (+5 VDC) . But, it’s not coming from the Atmega168. It’s coming from the daughter-board we have the EM4095 soldered to. We had to cut a line in order to figure that out. Hopefully, I’ll have better news to report after Saturday.

Jason is now working on an updated circuit schematic for our show-and-tell next week.

(April 29, 2008)

Well, this is as good as it gets. We managed to successfully integrate an FSM into our main-line code. Plus, we can read the Parallax RFID cards, store them, and spoof our original Parallax RFID card reader into believing it is scanning an actual RFID card. We can read and write the HID access cards issued by the Engineering College here at the University of Iowa. But, the data we are capturing is obviously not correct, as we are unable to fool the HID RFID card readers into believing our RFID Hacker is an actual RFID card. We are not defeated, however. We have until the weekend to iron-out any kinks, so it is possible that we may succeed.

We gave a brief demonstration to our Teaching Assistant ( one of our customers ), Dave Quackenbush. By the look on his face, we could tell he was quite impressed. He even suggested that our project was on par with those we’ve seen submitted to the magazine, Circuit Cellar. He added that we should look into submitting our project to them when we are finished.

Items to finish by the weekend (May 4, 2008):

  • Spoof the HID RFID card readers (please, let this happen).
  • Presentation poster.
  • Assemble the RFID Hacker PC board.
  • Verify assembled PC Board works properly.
  • Complete DRB (Design Review Board) Presentation.

Seems like a LOT, doesn’t it? Hmmmmm.

(April 26, 2008)

Capturing the HID cards issued to the U of I Engineering students is proving to be difficult. It is apparent that the RFID data stream is clocked at a much faster rate than the Parallax RFID cards we received with our kit. The high data rate (2 – 4) clocks per data-bit is crushing our Arduino‘s interrupt-routine. This is forcing us to do what we SHOULD have done up front with the Atmega168: build a Main Loop Finite-State Machine (FSM). Currently, reading the Parallax RFID card (EM4100 or EM4102 series) is trivial. There are 32 clock cycles per data-bit with the Parallax RFID cards (64 clock-cycles if you factor-in Manchester decoding), which is giving us plenty of time to decode them. Our current focus is to rearrange the main loop into an FSM, which should give us more control with respect to when we can turn the interrupt routines on and off.

(April 22, 2008)

Serious headway was made today. Let’s count the ways:

  • We successfully transmitted a cloned RFID tag within our Parallax RFID Reader environment. Yeah. Are YOU surprised? Well, we were decidedly ecstatic when we got confirmation.
  • The GUI interface is really looking nice.
  • The board layout is nearing completion and should be available for the Engineering Shop to route by the end of the week.

(April 17, 2008)

  • More progress is being made as we make the final push to complete our Senior Design Project. Most notable are as such:
  • Our RFID Tag Encoder application is finished and writes to a UTF-8 encoded text file. The application takes the RFID tag data, adds column and row even-parity information, adds the header, followed by encoding the entire string into a Manchester Encoded data stream. The application follows-up with writing the final data stream into a series of ‘clock-cycle’ counts we are looking for. In this case, a sequence of a single bit is assigned a count of 32, whereas a sequence of two identical bits in a row are assigned a count of 64. The application will be used to verify that our decoding of our sensed RFID tag matches what we calculate the data stream to be. We will also use the data stream as a ‘dummy’ RFID tag when we successfully pawn-off our RFID Reader as an actual RFID tag. The entire application is written in Processing 1.0.
  • Ran into Prof. Kruger over the weekend. He had little to add as far as suggestions for the project. We spoke of our transition from the PIC18F452 to the Atmega168. He had much respect for the Atmega168 microcontrollers. After talking with him regarding the Processing 1.0 and Arduino (Wiring) IDE, he was rather excited about our final design stating, “This goes to show that I need to spend some time Googling these languages.”
  • Our GUI application is in the ‘Alpha’ stage.
  • We have successfully implemented a rudimentary RFID tag ‘Write’ feature into the Arduino code. This feature had us confused for the longest time. We did not fully understand how the EM4095 was used to transmit data. The solution is in the use of the MOD pin of the Em4095. In ‘read’ mode, the MOD pin is pulled low (usually tied to ground in the case of the Parallax RFID Demo Board). When the MOD pin is pulled high, this allows the coil antenna to ‘run free’ and ring at its resonant frequency (100kHz to 150kHz). To simulate an RFID tag, the tag is in a permanent ‘write’ mode, where the MOD pin is pulled high when it wants to transmit data. There is no RF modulation of the coil antenna because that’s not how RFID’s AM modulation technique is performed. Here, we do 100% AM, where we turn on and off the RF field. The key is how often (and for how long) we allow the coil to self-resonate.

(April 15, 2008)

This has been a REALLY good week for Team Wombat. Here’s a break down of the accomplishments so far:

  • Incorporation of the Arduino (Atmel168) uController is well underway.
  • Ability to store RFID tag information in the Arduino’s EEPROM works
  • Visual display (similar to a logic analyzer) of the incoming RFID stream works (with a few kinks). Analyzing the RFID depends upon knowing (up front) the header information.
  • Successful capture of the HID RFID cards is documented and data has been stored. The HID RFID cards we use in the Engineering Building streams data at a rather fast rate clock cycles (2 to 4) vs. (32 to 64) clock cycles for the HID tag. Verification of HID RFID tag capture now depends upon whether we can successfully transmit the RFID tag (mimicking an RFID tag).
  • Documentation for placing the EM4095 into transmit mode is poorly documented. Although the MOD pin appears to be the method for modulating the coil antenna, there is little further documentation as to how to pulse the MOD pin in order to achieve an RFID style modulation. This will be further investigated.

(April 8, 2008)

RFID Receiver Breadboard

Successfully integrated the Arduino board with the EM4095 RFID front-end. Programming the Arduino will be an interesting task. The Arduino uses an IDE offshoot of the Processing IDE, along with a programming language based upon Wiring. The syntax is very C++/Java-like. It does take some time to get used to, however. Items to note so far:

  • Manchester decoding is HARD for some reason.
  • Parallax RFID tag decoding needs to be done using Manchester decoding. We do not have enough data RAM available to perform a RAW capture.
  • The Arduino has 512 bytes of data RAM, which is just enough to capture RAW HID RFID tag information. Yeah!

(April 1, 2008)

Decoding Manchester Data

After meeting with the team, we’ve decided to continue our Manchester decoding scheme along with designing a ‘wireless’ logic analyzer to capture the RFID tag. By building a Manchester decoder, we can determine that our Parallax RFID Module implementation is correct. But, in order to capture ANY RFID tag, we need to do it without regard to what the header information would be. If all we know is the number of bits to capture, then our final design will simply do the capturing on a per-clock basis. As long as we have enough memory to store the captured data, then we are good-to-go. Derek will continue working on the Manchester decoder. Hopefully, I’ll have some code to post by the end of the week.

In addition, the Arduino board is in. Yeah!

(Mar. 29, 2008)

Ruxton and I spent the evening going over the best way to capture RFID data, yet do so in a way that optimizes the amount of data memory within the PIC18F452. Here’s what we came up with:

  • It is unwise to capture RAW RFID data every time the 125kHz clock cycles (8 uSec for each cycle). Each RFID bit (with respect to the EM4095 using Manchester encoding) is 64 clock cycles in length. That’s a LOT of data. There are 64 data bits within the RFID tag used for the Parallax demo board. There are 84 data bits within the Engineering Building’s RFID access card (designed by HID). Instead of representing each sample as a byte, we’ll bit-stuff the captured RFID data stream.
  • Why do this? Well, let’s do the math: 84 data bits x 64 clock cycles = 5,376 samples for each RFID tag. This a lot of data. To better utilize our We could get by with this method if we bit-pack: stuff 8 samples into a single byte. This would give us 5,376 samples / 8 bits = 672 bytes per RFID tag.
  • How do we capture an entire stream? The trouble with capturing the data will be to ensure the data is good. How do we do this? The data is good when the clock synchronizes with the RFID data stream. We can ensure this by using PORTB of the PIC18F452. PORTB has the capability of triggering on both positive and negative transitioning pulses. If we put the clock on one of the lower bits of PORTB (let’s say, INT0) and the RFID data stream on PORTBbits.RB4, we can utilize a high-speed interrupt.
  • Within the interrupt, we can check which of the two have triggered the interrupt (INT0 or RB4). If both have triggered the interrupt, then we know that the RFID data stream is good (not garbage) and we can begin sampling the RFID data.
  • In order to ensure that we have ALL the data, we need to capture more than we need. The math: 672 x 2 = 1,344 bytes to store two complete streams. We CAN capture less, but as long as wee stay between 672 and 1,344, we should capture enough data to analyze later AND stream back to the RFID Reader when we want to simulate an RFID tag.

(Mar. 11, 2008)

  • Added necessary changes to the design. Demodulated data is still too great, with the demodulated output ranging from +5 to 0VDC. Current specifications show the DEMOD_OUT line to the EM4095 should be between +4.5 and +0.5VDC. This indicates that the Q-factor of our tuned RLC circuit is too low (probably around 50 or below). The series resistor should probably be within the range of 30 to 50 ohms. However, this may drop the current that drives the RLC antenna.
  • Designing a Manchester decoder within the PIC18F452 has been abandoned. It has been determined that we only need to record (with reasonable resolution) the RAW data streamed from the RFID tag. There is enough memory (Data and EEPROM) within the PIC18F452 to capture the data, especially if we bit-pack the received data into bytes.
  • Ruxton will work on designing a PC application (probably in Visual Basic) that will decode the Manchester encoded data sent from our RFID transceiver design. The application will look for predetermined header information to extract the necessary data and then analyze / decode the data into actual ID information.
  • Jason will continue work on the PCB layout for Prototype#2.
  • Derek will work on the Atmel IDE and what it will take to utilize this microprocessor into our design.
  • Dennis will design the initial PIC C18 code to record / transmit the RAW RFID tag information, instead of attempting to decode said information. RAW RFID tag information will be transmitted to our PC application using the RS-232 port.

(Mar. 4, 2008)

  • After considerable fretting, we managed to power-up the EM4095 RFID front-end. When turned on, the IC tuned to 132kHz, which is within the 100kHz – 150kHz specification. It appears that the demodulated signal (Manchester encoded) is a ‘tad’ high (it’s a technical term), so we’ll have to go back and reconfigure several of the components. Most notably, the capacitive divider network that strips the audio from the 125kHz carrier. Instead of 1000pF, it appears that 2000pF will do a better job.
  • Ruxton spent some time pouring through the Radio Shack catalog. We were looking for possible candidates for our final enclosure. If we take into consideration the largest possible size for our PC board, a 9V battery, a tuned coil, we may be able to achieve a size somewhere along the line of 2x4x1 (in inches).
  • Jason continues to struggle with Eagle Software. The routing software is not the most intuitive, so there is a tremendous amount of ‘re-do’ as he constructs our board layout. We have chosen to use existing libraries to define the PIC 18F452 and the EM4095.

(Mar. 3, 2008)

Measured the inductance of our initial coil (Coil #1): 684 uH, which is really close to what we had calculated for (700uH). With this information, we’ll go back and troubleshoot our connections to the EM4095. There is no reason we shouldn’t have had a successful run of our initial code. There MUST be some connection issues we did not find our first time around.

(Mar. 2, 2008)

Manchester Capture
Manchester Capture
  • We have established (with reasonable certain), that the encoding scheme between RFID tag and RFID Reader is Manchester. We used the LA-2124 logic analyzer to capture the data sent from the EM4095 (on the Parallax board) to the micro controller.
  • Our current coil does NOT appear to have the correct inductance. With our current configuration for the reader antenna, it appears the circuit is tuned to 650kHz, which is WAY too high. Derek took another stab at winding another coil, but the result was 400kHz (closer, but still no cigar).

(Feb. 28, 2008)

  • current design indicates that we are REALLY close to the typical frequency of 125kHz. See the graph to the right:
graph snapshot of antenna design
graph snapshot of antenna design

(Feb. 27, 2008)

  • Attached our antenna coil to the rest of its associated hardware. We did not get the frequency response that we were hoping for. From injecting a 5Vpp signal into the antenna, we noticed a peak around 500kHz, which is a factor of 5 OFF from our intended 125kHz design. We checked our calculations and everything seemed good. We will send an email to Prof. Kruger and get an idea of where we may have gone wrong.
  • Dennis seems confident that the encoding scheme (from RFID tag to RFID reader) is using Manchester encoding. Derek will send an email to Parallax in an effort to confirm that hunch.
  • Dennis will be designing the PIC application that will interface with the EM4095 RFID front-end IC. This will be done using C18 and MPLAB. The first prototype of the application will only read the RFID information. No attampts to write to an RFID tag will be undertaken at this time.
  • Jason took physical measurments of our circuit components so that laying out the PC board with Eagle will take less time. We discussed typical dimensions for most components. Jason will be using our initial circuit schematic and lay it out. Hopefully the transfer to an actual board-layout will go smoothly.

(Feb. 19, 2008)

  • Ruxton managed to procure a logic analyzer for our use.
  • Discussed various methods for mounting a PC board to a form that will hold our RFID tuned coil antenna.
  • Successfully decoded the ID# from one of our RFID tags using the logic analyzer. The next step will be to use the network analyzer to determine the encoding method used to transmit ID# from the tag to the RFID Reader.
  • Completed the 5-week interim Project Report.
  • Scheduled a meeting with Prof. Andersen (tentative for Thur. at Noon)
  • Jason reports that the Eagle PC-Board routing software is very flexible. We should be able to design our own printed-circuit board for (not only our protoypes), but our final design as well.
  • Ruxton reports that our dotProject site is back up and running. This is good, as we stored much of our data, code and research on that website.

(Feb. 12, 2008)

  • Derek wound our first stab at a 125kHz loop antenna. The final spec. was as follows: 36AWG, 46 turns, wound around a 20 oz. Sprite bottle. Not very scientific, but it worked.
  • Used the coil to (with an oscilloscope) to ‘sniff’ the frequency generated from the HID RFID card reader at the entrance to our lab. To our surprise, we discovered a 10Vpp, 125kHz sine wave generated from the card reader. There was much rejoicing. Not only will this work with our Parallax Card Reader Module, but there is a distinct possibility that we can actually read the HID cards issued to the Engineering students.
  • Whether the coil is tuned exactly to 125kHz remains to be seen. We’ll need better equipment to determine that. Ruxton will be working on getting a logic analyzer and a spectrum analyzer in the lab.
  • Jason will play around with Eagle (PC board generating software) before our next meeting. He’s rather interested in board design.
  • I will research the ability to acquire surface mount (SMT) capacitors and resistors through the Engineering Shop.

(Feb. 10, 2008)

Parallax Card and the PIC

So far, here is what we’ve got:

  • Derek has already assembled the EM4095 RFID Front-End onto a daughter card. The EM4095 is a surface-mount IC, so Derek created a small interface board which will allow us to simply insert the board onto our bread-board; making connecting the EM4095 and micro-controller much easier.
  • We’ll need to research several protocols which the EM4095 uses to communicate with the RFID tag. At the moment, we are unsure as to which protocol is used on the Parallax RFID Reader Module. However, since our Reader Module was purchased with a series of EM4100 family tags, we’ll be focusing on that particular protocol.
  • There are three different encoding schemes used to transmit data between the RFID tag and reader: Manchester, BiPhase and PSK. These are determined by how the EM4095 is physically configured. We hope to gain access to a logic analyzer, which could help us determine the encoding scheme without having to probe too deep into the hardware.
  • The EM4100 Series of RFID tags are READ-ONLY. We cannot write to them, as their ID# is laser etched into the tag during the manufacturing process.
  • The Manchester Decoder should be oversampled with a factor of two and convert the input sequence 01 to the output sequence 00. The input sequence 10 should be converted to the output sequence 11. In case the Manchester encoder is out of phase with the incoming signal, it has to recover as fast as possible and take care of the sequences 11- and 00- in an appropriate way.

(Feb. 5, 2008)

  • What’s with the stupid weather?

(Jan. 31, 2008)

  • Unable to meet, as the weather outside is frightful.

3 thoughts on “Sr. Design: RFID

  1. I’m trying to start an Arduino-based RFID reader with this EM4095. At the moment, it is just a hobby.

    My main problem is that I cannot get a good frame from it: sometimes there are aliasing problems (because of the Arduino functions) or software problems inside the Arduino.

    Can you let me have a look at the Manchester Decoding section of your code?

    My e-mail is


    1. See the Manchester Decoding section of our code? Now, what fun would THAT be? 🙂 For our purposes, we didn’t do the decoding on the Arduino. We thought about it, but decided to offload that work to a separate application we wrote using Processing… which is the basis for the Arduino’s java-like code.

      The first step is getting the BIG picture on how to decode Manchester. In code, it is a finite state machine and even hobbyist should be able to understand that concept. In fact, if you can sketch a finite state diagram that mimics Manchester Decoding, then you are WELL on your way to make it work. In the end, Manchester Decoding is a bit of a bugger, so I am not surprised that you are having some difficulty.

      1. Besides… what would be the fun of designing if I were to simply “hand-over” the source. You gotta’ work for it, man! 🙂

Comments are closed.