RFID Software:

Once the data was converted into a digital Manchester signal by the RFID circuit, we then had to process it and convert it into a useful format to the microcontroller. For this, we decided to write a library for the RFID, called rfid.c, which dealt specifically with the task of receiving and interpreting an RFID signal. Unlike Ricardo and Craigs design for RFID, we did not use a sampling method for Manchester decoding. Instead, we opted for a more robust method with less interrupts a timing-based method. This method only interrupts when it has to i.e. on a change of logic value, and then the microcontroller interprets the amount of time between interrupts in order to determine the value of the Manchester bit. To do this, we go through a sequence of events after turning on the external interrupt for any logic change: 1. Wait until we receive a start sequence (extra long logic high) 2. On next interrupt, decode the first Manchester bit: delay by a very short amount to ensure steady state, read the logic level. 3. If time difference is short, save the read logic level into a data buffer only if it wasnt recorded last time. If time difference is long, save the logic level. 4. If anything was recorded in the previous step, add to the checksum such that it is sample number dependent (we used sample * i % 9, where i is the sample number) 5. Repeat steps 2 and 3 until we read an end sequence (extra long logic low) 6. Insert a 2 at the end of the buffer, so we know where we stopped recording The sample number dependent checksum was added as a feature since it is more likely to be wrong in the case of multiple bit errors. If we only added the binary values, we would have created a parity check, which may not have been sufficient in cases of a lot of noise. This allowed us to cut down on the number of redundancy checks by a factor of three, and still get the same reliable results, leading to a faster system. To better explain what we mean by short, long, and extra long: since Manchester encoding has a logic change at every data bit, the longest delay we could have would be 0110. That means that during the pair of 1s, it stays logic high for two half-cycles. The shortest delay we could have would be 0101, where the 1 stays high for only one half-cycle. For the RFID system, if we clock it at the same scale as the previous two, there is also another state, which is 111110. This is a very long time, easily detectable, and denotes the start of a data stream. Once we successfully fill the buffer, we ensure the reliability by checking it multiple times. We checked 20 times, which was way overkill, but we really wanted to minimize the chance of a wrong ID. In reality, two checks actually is sufficient for most of the time, with three checks delivering near perfect results. Since we are only reading a 44-bit value from the RFID tag, we can do the 20 checks very quickly (approximately one second in most cases). We saved each data bit as a char in a string, so then we just convert it into a long using bin2dec so it can be returned using less space than a string. One cool final note was that by doing Manchester decoding with the timing-based method, we were able to get the data by only connecting one wire for ground and one wire for data to the microcontroller! Manchester Encoding [from Wikipedia]: In telecommunications, Manchester code is a line code in which the encoding of each data bit has at least one transition and occupies the same time. It therefore has no DC component, and is self-clocking, which means that it may be inductively or capacitively coupled, and that a clock signal can be recovered from the encoded data. Essentially Manchester encoding works

in the following way: A transition from 0 to 1 corresponds to a single 1 value and a transition from 1 to 0 corresponds to a single 0 value. Thus 01 -> 1, 10 -> 0, and the reduced bitstream is half as long as the original bitstream.

Ethernet
Hardware Overview:

Master Hardware Circuit Schematic (Click Here for Full Size) Ethernet Background: Ethernet is the term encompassing the primarily wire-based network protocols and specifications in use throughout the world today. It was originally developed in the early 1970s by Xerox PARC in order to facilitate the development of large computer networks. Ethernet uses a packet-frame architecture to transmit data (namely IP), and has methods available to deal with network congestion and reliable transport. Specifically, the pieces of the Ethernet that we used directly were: cat5 twisted-pair cabling, TCP (Transmission Control Protocol), MAC (Media Access Control), IP (Internet Protocol), HTTP (Hypertext Transport Protocol). Connecting these Ethernet devices together physically is twisted-pair cat5e cabling. We used 100BASE-TX speed, which can transmit up to 100Mb/s over the line. This IEEE 802.3u standard provides an efficient physical connection layer utilizing (not surprisingly) twisted pairs of cable to transmit bits. Clients receiving or transmitting using 100BASE-TX are responsible for synchronization and encoding bits into 4B5B binary encoding. In IP, each device gets an IP address that uniquely identifies itself to the local network. This number is a 32-bit integer, usually organized into 4 bytes separated by periods, for example x.x.x.x, where x represents a 0-255 number. What is called a subnet mask also exists, which creates a bitmask which determines which bits must be fixed during communication.A typical

subnet mask might be 255.255.255.0 (corresponding to 0xFF.0xFF.0xFF.0x00), meaning that the device can only connect to other devices with address x.x.x.y, where y can be anything from0-255. Additionally, for device to device communication in IP, each device needs to have a MAC address. This 48-bit number (every byte delimited by a :) is a unique identifier for each Ethernet interface, and IP uses it so that packets can find their way to the destination. A MAC address can be considered like a Social Security Number of a networked device. An example MAC address might be: 48:32:AE:4B:18:F6. Running on top of IP, we used TCP to provide reliable data transfer. This protocol, which is designed to maintain connection state, encapsulates its underlying data with a TCP header of 20-60 bytes, which provides all of the information necessary for reliable transmission and congestion control. Aside from this, we will leave it to the reader to research, since TCP is very well documented elsewhere and not a significant portion of our project. Finally, the most visible method of communicating over Ethernet is via HTTP. Once we are at the point that we can take the underlying levels previously described for granted, we can transmit data. HTTP is the incredibly ubiquitous protocol used in the World Wide Web today, and specifies methods of requesting and receiving text from an IP address. HTTP uses a header format that looks like: GET /process.php?rfid=491829822&pin=1234&amt=30 HTTP/1.1 Host: 10.0.0.100 As you can see, HTTP headers can be relatively simple. In reality, though, a typical web page request uses many more optional parameters that give extra information to the server, but this is beyond the scope of our project. In order to pass context information to the server, which would allow it to display dynamic content, HTTP specifies two methods: GET and POST. The latter essentially codes variables, hidden to the user, as part of the HTTP data, while the former simply appends the variable names and values to the end of the URL, using a format such as seen in the diagram. Our Implementation:

Our Ethernet Chip: WIZ812MJ Luckily for us, we were able to get our hands on a Wiznet WIZ812MJ Ethernet development board, which abstracted the design for every layer except HTTP. The WIZ812MJ board gave us pins and a physical Ethernet port, which was actually connected to a Wiznet W5100 chip, which did the actual network processing. So, instead of actually coding the complex state machines associated with each protocol, the W5100 chip did that for us, and we just had to communicate with it via SPI (Serial Peripheral Interface). Communicating over HTTP: For our application, we sent HTTP GET requests, with our parameters encoded as GET variables. First, we had to create a library for interfacing with the W5100, which we called ethlib.c. This library was created with a base from Brian Bryces AVR POP3 mail fetcher, which also used the W5100. In essence, this library provided the framework for setting up and connecting to an Ethernet network. All of the code was modularized and parts that were unnecessary to us were stripped so that it could be executed from another program, and some additional features were added. In addition, Bryces code had some connection reliability problems that were diagnosed, debugged, and fixed in the final library. Some of the features we added was a connect_defaultTCP method, which just connected the device to predefined parameters. This helped clean up the code a lot, and also made it easy to change the parameters. We decided against using the EEPROM storage available on the ATMega16 for network parameter storage as Bryce did. This design decision was simply because we had enough space to commit them to data memory, and we did not want to add a whole set of functions dedicated to setting up the device from EEPROM. That said, a lot of time was still spent debugging and documenting the W5100 until we were satisfied we had an extremely reliable device and connection established. We used 10.0.0.100 as the IP address of the server, and 10.0.0.101 as the IP address of the W5100. For HTTP communication, since the W5100 reports the entire HTTP response back (including the header), we needed a way of parsing out the data. The communication standard we designed had the actual data stream start with a $ character, and end with a ^ character. This allowed us to efficiently discard the HTTP response header in C code, so that we would be left with the data. The authentication response was also encoded in a specific format: if the authentication was not successful, we returned a status code of 0, followed by nothing else. If the authentication was successful, but the user did not have sufficient funds for the transaction, we denoted this with status code 1, followed by the users name. If everything went well, and the transaction succeeded, we return status code 2, followed by the users name. An example success, for example, looked like: $2Harry^. Ethernet Backend Operations: From the point when we had the Ethernet library and a data transfer protocol established, all that was left was to use it to transmit the data we collected from our user to the server. As previously stated, we did this by encoding the data as GET variables: rfid, pin, and amt. rfid corresponds to the RFID value, converted to a long, read in from the RFID method. pin corresponds to the entered pin number, and amt corresponds to the entered payment amount. This data was passed to a PHP script, process.php, which was running on a LAMP (Linux, Apache2, Mysql, PHP) server. The process.php scripts purpose was twofold: authenticating the user and replying with the appropriate status code and authentication data, and also to log every attempt made to access the system. We made sure to output

something every time process.php was accessed authentication and payment successes were logged to the rfid.log file, and anything else was logged to fail.log, along with the reason for failure. In addition, if there was a successful transaction, we also logged the information about the transaction into the database, in a specific table called transactions. This presents users with a way to view their transaction history. Once all has been logged, and the response sent, the microcontroller then parses the response and displays an appropriate message to the user.

User Database Snapshot(Click Here for Full Size)

User Transaction Snapshot(Click Here for Full Size)

Ethernet Pin Configuration: J1 J2 1 -> B.5 1 -> VCC 2 -> B.6 3 -> B.7 11 -> GND 4 -> B.4 12 -> VCC 5 -> GND 6 -> GND 7 -> GND 20 -> GND LCD: We decided to use a 16x2 LCD as it was readily available in the ECE 4760 lab. We had used the LCD in multiple labs previously and the documentation for the LCD can be found here. Information on how to connect the LCD and code to test the connections can be found in the Spring 2010, ECE 4760, Lab 1 page here. Keypad: We needed a keypad that had all the decimal digits (i.e. 0-9) and a couple of extra keys for Reset and Cancel functions. We decided to use the 4x4 keypad as it was easily available in the ECE 4760 lab. We connected Pins 1-8 on the keypad to Port A pins A.0-A.7. More information on wiring for the keypad and the code to test the connections can be found in the Spring 2010, ECE 4760, Lab 2 page here. Microcontroller Operations: We decided to use the Atmel Mega 16 microcontroller (as opposed to the Mega 644 that we had used in all of our labs during the semester) simply because we did not need much on-chip memory and the Mega 16 would count as a free chip in our budget (of course, we were also comfortably under-budget). We would like to extend our gratitude to Professor Land for providing us with his excellently designed MCU board. We used the Max233CPP for the RS232 connection during the debugging phases, but did not need it in the final project demonstration. The documentation for this board can be found here.

Prototpe Board Schematic (Credit Prof. Land)

Completed Prototpe Board Circuit (Credit Prof. Land) Port/Pin Configuration on MCU: Pin D.7 - 125[kHz] square wave to generate the RFID carrier frequency. Pin D.3 - External Interrupt 1 to accept filtered data from the RFID reception circuit. Port A - Keypad (Pins [1-8] on keypad correspond to Pins [A.0-A.7]). Port C - LCD (please refer to the LCD section of the report for the setup). Pins [B.4 - B.7] - Ethernet (please refer to the Ethernet section of the report for the setup).

Standards:
ISO/IEC 14443 or ISO/IEC 15693: The Cornell ID cards we use in this project are developed by HID. Specifically, the Cornell ID is a HID DuoProx II card that is also ISO 7810 compliant (magnetic strip). We did not need to use the magnetic strip feature. The card is also ISO/IEC 15693 compliant; ISO 15693 was developed in 1999 and has become the standard for contactless payment systems. ISO/IEC 18000: This is an international standard that describes a series of different RFID technologies. We use ISO 18000-2, which describes the air interface communications below 135 [kHz]. TCP/IP [taken from Wikipedia]: The Internet Protocol Suite (commonly known as TCP/IP) is the set of communications protocols used for the Internet and other similar networks. It is named from two of the most important protocols in it: the Transmission Control Protocol (TCP) and the Internet Protocol (IP), which were the first two networking protocols defined in this standard. Today's IP networking represents a synthesis of several developments that began to evolve in the 1960s and 1970s, namely the Internet and LANs (Local Area Networks), which emerged in the midto late-1980s, together with the advent of the World Wide Web in the early 1990s. Ethernet [taken from Wikipedia]: Ethernet is a family of frame-based computer networking technologies for local area networks (LANs). It defines a number of wiring and signaling standards for the Physical Layer of the OSI networking model as well as a common addressing format and Media Access Control at

the Data Link Layer. Ethernet is standardized as IEEE 802.3. The combination of the twisted pair versions of Ethernet for connecting end systems to the network, along with the fiber optic versions for site backbones, is the most widespread wired LAN technology. mySQL [taken from Wikipedia]: MySQL is a relational database management system (RDBMS)[1] that runs as a server providing multi-user access to a number of databases.

Results
Speed of Execution: Our mobile-payment system prototype completed read an RFID tag in about a second, and database access over Ethernet took less than 1 second. In all, the user would be strictly waiting only for a total of about 2 seconds. Of course, this 2 seconds does not take into account the time that the cashier takes to enter the amount, or the time that the user takes to enter his/her security pin. In order to make the RFID reading quicker we would need to reduce the number of times we check the tag. We did not want to reduce the number of checks from 20 to say 5, but that would also reduce the accuracy of the system. Accuracy: We had an accuracy of 100%. We had no false positives, as we would check the same tag 20 times in order to make sure that the ID is actually the same. However, depending on the angle in which the tag is held in front of the coil, or the distance of the angle from the coil, we did have a few false negatives. Now, we could account for this in software but we cant find any hardware method to detect this scenario. In the eventual commercial application, when the tag is used a sticker on the users phone, users could simply be prompted to bring their phone within a 1 reading distance. Safety: This device does not pose any safety or health threats to its users. We have an insulating cardboard box as the container for the system and the user interacts with the device only through the keypad, which is made out of insulating plastic. There are power and Ethernet cables that are connected to the device and these components cannot inflict harm upon a user as the user does not interact with these cables. Interference: This is an issue that any communication medium deals with, however, as this is a NearField-Communication system, chances of interference from another 125[kHz] emitter are very slim. Also, if there are two tags on a users phone (say for different applications, both using 125[kHz] as the carrier frequency), the system would be unusable. However, in the general case, this system does not suffer from any interference issues. Usability: Our system is usable by most individuals without serious physical ailments. Individuals with certain disabilities may find our device inconvenient to use, however we are in no ways

discriminating against anyone. The device may be modified so as to offer auditory feedback for the blind, Braille key-modification on the keypad and possibly voice recognition for authentication for individuals who have lost their hands.

Conclusions
We feel that we have successfully implemented the first prototype of our mobile-payment system. We achieved every goal that we had defined in our Project Proposal and at the end of a fantastic five weeks we are extremely satisfied with our mammoth project! We will be looking forward to adding all our friends to our database and stress-testing the system to iron out any creases. Our next step will be to implement data transfer over a 2G network, after which, we will be aim to add levels of encryption to make the system hack-proof.

Relief, Satisfaction, Happiness! Ethical Considerations: We ensured that our project properly follows the IEEE Code of Ethics and our project does not pose any ethical problems. We believe that all the decisions we made were fully ethical and followed the code of ethics guidelines. While working in lab we ensured that we met with the highest safety and health standards, and made sure that we were not adversely affecting the welfare of the public. Moreover, this device does not pose any safety or health threats to its users. We have an insulating card-board box as the container for the system and the user interacts with the device only through the keypad, which is made out of insulating plastic. There are power and Ethernet cables that are connected to the device and these components cannot inflict harm upon a user as the user does not interact with these cables. While developing this project we did not come across any situations that involved perceived conflicts of interest. In fact, as is expected in the ECE 4760 lab we were always willing to help our fellow classmates whenever they asked for assistance in their projects. To our knowledge we have been fully honest in making any claims or stating any estimates based on measured data. There was never any instance of bribery that we encountered. Also, as we have mentioned before, neither of us were experts in the fields of the various components we used in our project, and our goal was to improve the understanding of technology, its

potential applications and eventual consequences. We hoped to use existing technologies to develop a device that can truly serve as a proof-of-concept for a mobile-payment system. We had intended to maintain and improve our technical competence and understand that we can undertake technological tasks for others only if we are qualified by training, or after the full disclosure of pertinent limitations. We are open to advice, criticism and essentially any comments on our technical work. We will be willing to acknowledge and pleased to correct any errors, and have made sure to credit properly the contributions of others. Our device does not discriminate against any race, religion, gender, age or national origin. Individuals with certain disabilities may find our device inconvenient to use, however we are in no ways discriminating against anyone. The device may be modified so as to offer auditory feedback for the blind, Braille keymodification on the keypad and possibly voice recognition for authentication for individuals who have lost their hands. During the course of our project, we made sure to avoid injuring any fellow classmates, their property or reputation by malicious action. On the contrary, we were always glad to help our classmates out whenever we could be of assistance. Intellectual Property Considerations: As mentioned before, neither my partner nor I have taken courses in RFID design and in fact this was our first experience in working with the standard. We have made sure to cite any and all designs that we referenced (in our Acknowledgements section) and locally while describing the module. There are many patents filed by the HID corporation itself on methods to read their cards (an example can be found here. Similarly there are many patents filed under mobile payments (an example can be found here. However, we have violated no patents while working on our project as (1) we have a specific concept for our final system (and this prototype is just the first step in getting there), (2) this is an academic project that is following all FCC standards . We are very grateful to WIZNET for sampling us their WIZ812MJ module. They did not require us to sign any non-disclosure as no code came with the device. Legal Considerations: [From RFID Gazette] Part 15 of the FCCs rules for low-powered devices deals with RFID regulations. RFID devices are referred to as intentional radiators. These low-powered devices do not raise a serious threat of interference with other devices and hence can be operated without a license. All the same, RFID devices have to meet the RF emissions limitations and power restrictions as laid down by the FCC. Societal Impact: As Internet and ATM machines are unavailable in rural areas and penetration is low even in urban areas, the following problems exist: 1. Individuals who have opened bank accounts in the cities have a problem accessing their bank-services 2. Individuals without bank-accounts who would like to avail of convenient services such as ATM debit cards have to resort to cash for all their financial needs 3. Migrants working in places elsewhere in the country have difficulties sending their remittances home

4. Financial institutions find it unviable to setup station in remote locations in the country 5. Micro-finance lenders have trouble connecting with viable recipients 6. Average Revenues Per User and margins for telecomm operators have been declining and the field needs Value Added Services if it is to sustain healthy growth An idea such as Mivo has the potential to solve these issues. We see many problems in todays payment systems in developed countries- security and convenience (of say, peer-topeer payments) being the important ones. No system is perfect but the system we envision could potentially solve these issues. Acknowledgements: First and foremost we would like to extend our gratitude to Professor Bruce Land for preparing us to develop our Final Project through the course of the semester, have the lab open endless hours for our projects and for helping us debug our problems. We want to thank Bruce for his code for the LCD libraries. We would also like to thank all the TAs for all their help and particularly our Friday lab TA, Yuchen Zhang. We are extremely grateful to WIZNET for donating us their WIZ812MJ module. We would recommend any future ECE 4760 students to approach WIZNET for their networking considerations! Finally, we are grateful to Craig Ross and Ricardo Goto (Spring 2006), whose comprehensive report made it possible for us to complete our project in the given time, even though we had so many varied components to integrate into a single microcontroller chip. Their project can be found at: http://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/s2006/cjr37/Website/index.htm. We found the microID 125[kHz] reference guide through them which turned out to be the most helpful resource. The datasheet can be found at: http://ww1.microchip.com/downloads/en/DeviceDoc/51115F.pdf. We would also like to thank Brian A. Bryce for his Ethernet code. Brian wrote POP3 Email client using W5100 and his code can be found at: http://babryce.com/w5100/emailV010.c. It is quite a co-incidence that Brian is actually a Cornell alumni (we found out from his stellar CV). Division of Work: Harsh Harry RFID Circuit RFID Receive Code RFID Transmit Code Ethernet Code State Machine Code State Machine Code System Integration System Integration Final Report Final Report Website Design

Appendix

Parts List Manufacturer/ Supplier JW Miller A Bourns RF Choke Company Op Amp Texas Instruments Decade Texas Instruments Counter Dual D ECE 4760 Lab Flip Flop Diodes ECE 4760 Lab Transistors ECE 4760 Lab Ethernet WIZNET Controller LCD ECE 4760 Lab Keypad ECE 4760 Lab Breadoard ECE 4760 Lab Power ECE 4760 Lab Supply Custom ECE 4760 Lab PC Board Mega16 ECE 4760 Lab DIP ECE 4760 Lab sockets Header ECE 4760 Lab Pins Misc: Caps/ ECE 4760 Lab Resistors/ Regulators Total Part Code Listings: Main Program Files: state_machine.c ethlib.c rfid.c HTTP Backend Files: eth_setup_476.sh mysql_close.inc.php mysql_connect.inc.php process.php DigiKey Part Number 5800-102-RC TL084CN CD4017BE SN74HC74N 1N4001 2N3906. 2N3904 WIZ812MJ Unit Cost $1.33 $0.63 $0.50 $0.00 $0.00 $0.00 $0.00 $8.00 $6.00 $6.00 $5.00 $4.00 $0.00 $0.50 $0.05 Quantity Total 1 1 1 1 1 2 1 1 1 1 1 1 1 2 60 $1.33 $0.63 $0.50 $0.00 $0.00 $0.00 $0.00 $8.00 $6.00 $6.00 $5.00 $4.00 $0.00 $1.00 $3.00

$0.00

$0.00 $35.46

Libary and Header Files: ethlib.h rfid.h lcd_lib.c lcd_lib.h uart.c uart.h

References MicroID 125[kHz] Reference Guide Ricardo and Craigs website Bryan Bryces website WIZ812MJ datasheet ATMega16 datasheet