Low Cost RFID-Based Race Timer for Smaller Events

Size: px

Start display at page:

Download "Low Cost RFID-Based Race Timer for Smaller Events"

Russell Sullivan
5 years ago
Views:

1 Low Cost RFID-Based Race Timer for Smaller Events Members: Robert Evans, Christie Sitthixay, Edward Tan, Michael Houldsworth ECE Faculty Advisor: Tom Miller Courses Involved: ECE562, ECE633, ECE634, ECE649, ECE714, ECE757, CS410, CS415 Project Completion date: May

2 Table of Contents: Page Abstract 3 Introduction 3 Background 3 Standards 4 Design Objectives 4 Methods 7 Implementation & Testing 10 Results 11 Discussion & Conclusion 10 References 16 Division of Responsibilities 16 Appendix 17 2

3 Abstract: The goal of this project was to design and implement an affordable, automated method for timing runners in an event with around 400 participants using off-the-shelf components. This was done by developing three identical handheld units that communicate with a PC program via wireless serial connection. One unit is responsible for timing runners and another scans RFID tags embedded in the runners bibs. A third unit periodically confirms the time and placement established by the other two units. The PC program then combines the data from all three units into a list of race results that can be used immediately after race completion. Introduction: Race timing systems are expensive, but with a large number of participants this isn t a problem. Modern race timing systems use RFID tags and readers to automate race timing. Each participant has a tag in his or her race number and a large antenna array at the finish line records the finish time for each participant. While practical for large races, these systems become prohibitively expensive for smaller events with fewer participants. The goal is to create a wireless, low cost system that accurately times a race using RFID technology. The background of race timing systems will be explored to further discuss the motivation behind this project. The methods section will discuss the implementation of each piece of hardware along with testing techniques. Results will then be observed; did each unit work, how accurate was it and was the overall system really low cost. Background: Modern, large race timing systems that use RFID are designed for upwards of 1,000 participants. These systems are very sophisticated, but also can be very expensive. As a result, the per-runner cost to use one of these systems can be prohibitive for smaller events. These smaller events tend to time races by hand, which can be inaccurate and takes longer to finalize 3

4 race results. A low-cost, automated system solves both problems for races with few participants: it is cost-effective for the number of runners while still providing the accuracy of the larger, more expensive systems. Standards: We are using radio-frequency identification (RFID) as a method of identifying the racers. RFID is a system that uses radio frequency electromagnetic fields to transfer data from a tag for identification tracking. RFID is defined in ISO/IEC standard; we are using specifically part 6 which defines communications at 860 MHz to 960 Mhz. As a wireless adapter in our project we selected ZigBee as our form of communication protocol. ZigBee built off of IEEE which is a standard that specifies the physical layer and media access control (MAC) for low-rate wireless personal area networks. Design Objectives: Smaller race events typically follow a system consisting of three people at the finish line similar to that shown in Figure 1. In our system we build on this by adding our three units to be used at the finish line. The system was implemented with a network of three handheld devices connected wirelessly to a PC. One handheld device, displayed in Figure 1 behind the finish line, was used to scan the RFID tags on the race participants. Another labeled Microcontroller (MC) Stopwatch Unit in Figure 1 was used to record finish times of the racers. The third handheld device was used to independently verify finish times of specific participants is labeled as Checker MC Unit in Figure 1. All three systems are able to communicate wirelessly with a PC, which is used to list finishing ID s and times in order. Figure 2 displays a block level diagram of how each handheld is constructed and connected to the PC. Each unit uses the same hardware to simplify the design and testing phase 4

and so that the software could be identical for each unit. The only exception is the RFID unit, which needed the extra RFID reader chip and the antenna to read RFID tags.

5 and so that the software could be identical for each unit. The only exception is the RFID unit, which needed the extra RFID reader chip and the antenna to read RFID tags. All system components are connected to the Arduino, which serves as the brain of the handheld device before sending data to the PC via the XBee module. All units therefore must have an XBee module to communicate with the PC, as well as an LCD, keypad, and audio feedback for interacting with the user. It is then the responsibility of the PC program to collect timing, RFID, and checker data and combine them into a list for the race organizer. Figure 1: Setup Diagram 5

6 Figure 2: System Diagram 6

Methods: For the selected parts below, each team member developed a parts list. From there as a group, we determined the pros and cons of each item selected to determine our final parts list.

7 Methods: For the selected parts below, each team member developed a parts list. From there as a group, we determined the pros and cons of each item selected to determine our final parts list. We had to take into consideration things like cost, the number of pins and outputs, reading range and antenna gain. In the descriptions below, the parts being described are displayed in figure 1-6 respectively. Arduino was selected as a microcontroller for its easy development, high reliability, and good price. When examining the Arduinos, the number of ports required for the project quickly became a concern. For this reason, the Arduino Mega (Figure 3) was chosen, since it has more ports than any of the alternatives. On the parts list we have three microcontrollers and their corresponding parts. We only ordered the parts for one unit first, and then ordered the rest once the system was confirmed to work. In order to simplify construction, the LCD and ZigBee wireless shields were chosen as seen in Figures 4 and 6. Figure 3: Arduino Microcontroller Figure 4: LCD Shield The keypad was chosen because it had 16 buttons, which allows for the extra buttons to be used to control the mode of operation or for other operations not directly related to data entry. Another benefit of this keypad is that the top is made out of a single sheet of plastic, making it water resistant. 7

with. Figure 6: Zigbee Wireless Module The UHF RFID kit was chosen because it operates in the unlicensed

8 Figure 5: Water Resistant Keypad XBee was chosen as a wireless communication protocol because it interfaces well with the Arduino systems, has good range for communication, is reliable, and easy to work with. Figure 6: Zigbee Wireless Module The UHF RFID kit was chosen because it operates in the unlicensed band of the UHF spectrum in the United States. This means users of our device do not need a license to use it at 8

events. Additionally, the kit included with the RFID board makes development and testing extremely easy, and the built-in antenna had reasonably good reception for its size.

9 events. Additionally, the kit included with the RFID board makes development and testing extremely easy, and the built-in antenna had reasonably good reception for its size. Figure 7: UHF RFID The circularly polarized antenna was chosen for testing because it is compatible with the reader and circularly polarized, meaning tags can be read from any direction. This antenna provides much higher gain, and is a possible stationary solution if the handheld antenna is not ideal. The greater gain translated to greater range, but the cost and size of the antenna ultimately ruled it out when considering the alternative. Figure 8: Circularly Polarized Antenna The antenna ranges and signal strength were tested for the XBee module and the RFID kit. After the project was completed we reperformed the antenna ranges and signal strength test. After we did the initial testing we implemented each component of the microcontroller separately. We started with the easier components first, which included the keypad, LCD and buzzer. We then proceeded to implement the XBee module and the RFID module. We also 9

10 created a battery sensor that used three LED (Green,Yellow and Red) to indicate what the state of the each battery was at. We then integrated each component of the microcontroller together to build our first complete system. All three of the microcontroller were programmed the same. After we completed the programming for the microcontroller we moved to programming the computer software. We created a GUI(Graphical User Interface) to make the program easy to use. Finally, the poster was designed and we presented our project at the Undergraduate Research Conference. Implementation/Testing Plan: Hardware: The microcontrollers were tested first, as all other components were built around them. Next, the XBee modules and RFID readers were tested to ensure functionality with the microcontroller. Another key aspect of testing at this stage is to determine the effective ranges for the RFID reader and the XBee modules. When the major components have been confirmed, the smaller components were tested. Implementation of the battery sensor was performed and integrated to each microcontroller. The final hardware setup was installed and the system as a whole was ready for extensive software testing. Computer Software: There are two things that was tested within software. The first was testing the code in each microcontroller and second was testing the code for the program on the PC, which is the program that collects the hardware s data. There was also a unit testing performed for both the microcontroller s program and the PC s program. The unit test for the microcontroller s program tested each hardware component (keypad, LCD display, etc.) to ensure they were working properly, and the unit testing for the PC s program tested each functionality that is required. 10

11 There was also an integration testing for the microcontroller s program and the PC s program individually. Finally there was an integration testing for the microcontroller s program and the PC s program together to guarantee that everything worked well together. Arduino Microcontroller: There were many steps into implementing and testing the microcontroller. First we researched each component on the internet to see if we can find example and we can get a better understanding on them. Then we constructed the hardware to connect to specific pins on the microcontroller. Followed by implementing each component and connecting them to the microcontroller (keypad, LCD display, etc.). We coded each component separately and stored them each in a separate file so we are able to go back to them for referencing. Each component was tested independently to ensure they are working properly We created one file which integrated all the microcontroller software component and built off of that. After we completed coding each component together we tested to see if they worked properly. If we encountered a problem we went back to the integrated program and fixed it. We repeated this step several times before we had a working program. Results: The final prototype followed most of the previously set guidelines. Three handheld units were successfully created (timer, checker, and RFID reader). The RFID reader with the 9 db antenna was able to successfully scan RFID tags up to a distance of about 1-2 feet. The timer unit was able to track the racer participants with accuracy to within 1/10 of a second. The checker unit was able to verify participants crossing the finish line by sending time and racer numbers to the PC unit. The PC unit with the program was capable of receiving data from all three units with receive range of about ~100 feet. The computer program connected via wireless 11

12 XBee serial through COM ports to all three units simultaneously and compiled all the data sent to it into a grid showing the results of the race. These results were verified using 2 RFID tags to act as race participants. The tags are pictured in Figure 9. All units would be started up, after startup the units would be put in their three respective modes and then remain idle for a short period of time. The racer the tag would then cross the finish line and the timer would then record the time for the first RFID tag. The RFID reader unit would then scan their tag after the timer s data had been sent. This was repeated when then the second RFID tag finished, but the second time the checker unit would verify the results as well entering in 2 for its racer number (because its the 2nd tag) and then send the checker s time to the PC program. Figure 9: Sample RFID Tag To use the computer program to track the race results first select the COM port (Shown in Figure 10) for which the Computer XBEE unit is on. The Remaining values may be left as the defaults. Then proceed to open the COM port by pressing the button and the green indicator next to the Open/Close button should light up to indicate the port has successfully opened. Once the port has opened the race results will be automatically tracked in the two tables in the program. The RFID will populate the Race Number and Tag ID fields as tags are scanned incrementing the cell position by one with each successive scan. Take note that if the same RFID tag is scanned twice the program will automatically ignore the second scan and any successive scans that follow. The timer unit will populate the Position and the Time fields. The position field is 12

simply filled with the current position of the racer who finishes starting with one and incrementing by one each time a finisher crosses the line and the timer unit

The Time field is filled with the time value given to the PC program by the timer unit and fills one cell in the Time column incrementing by one with each time sent.

13 simply filled with the current position of the racer who finishes starting with one and incrementing by one each time a finisher crosses the line and the timer unit is pressed. The Time field is filled with the time value given to the PC program by the timer unit and fills one cell in the Time column incrementing by one with each time sent. Figure 10: Computer Program Figure 11: Completed Unit Each unit was programmed the same so any unit can be any of the handheld. The only one that needs to be specific is the RFID unit because there is a separate component to it as shown in Figure 11. When powering up the handheld, the user will be prompt with three 13

14 different options. The user will then decide which option to choose from A: Checker B: RFID and C:Timer. If the user presses A, they have chosen the Checker option which then they will be prompt with on screen direction on what to do. The directions are to enter the racer s bib number and press * when they pass the finish line. The computer program will receive the racer number and the time they pass sequentially. If the microcontroller was able to send the data, the user will be informed by a buzzer and a prompt on the LCD screen. If the user presses B, they have chosen the RFID option which is strictly receiving the RFID information and no time. To send data to the computer the program the user will have to hold the RFID unit in proximity to the user and press any button to send data. The data that is sent is the RFID information in the order that it is sent. If the microcontroller was able to send the data, the user will be informed by a buzzer and a prompt on the LCD screen. If the user presses C, they have chosen the Timer option which sends the time from when the microcontroller has started to the computer. After the user has selected the Timer option they will prompt that they can press any button to send data to the computer program via the LCD screen. As the racer crosses the finish line, the user will press any button.the data that is sent is the time within a thousandth of a second. If the microcontroller was able to send the data, the user will be informed by a buzzer and a prompt on the LCD screen. Discussion & Conclusion: The economic constraints of this system were extremely important while developing this system. Parts were compared extensively to ensure that the final cost per runner was less than the cost of a more expensive system. This was one reason a large, circularly polarized antenna was not used. The smaller antenna could read the RFID tags from the target distance and was much 14

15 cheaper than the alternative. The whole cost of the system was $740. Budget details are included in Table 1 of the appendix. In order to further cut costs in the future, specialized handhelds could be used with fewer components, as the goal was to only develop one set of hardware. Cutting back on the number of components used would save money to make this solution even more cost effective. However, this would require specialized software for each handheld. Due to the high cost of RFID race timing systems, a low cost system was created for races with less participants. This system included three handheld units: a RFID, a checker and a stopwatch unit. Since the system is wireless, a computer station is also needed. The RFID unit successfully identified the runner and his/her RFID tag, the checker accurately verifies a specific racer s finish time and the stopwatch unit is accurate to a tenth of a second. The computer program displays the racer s name, ID tag and finish time. The program can also account for double scans from the RFID unit, to ensure an RFID tag is not entered into the system twice. For future progress on this system, thorough battery testing would have been done next. While the units will work for a respectable amount of time, the longevity could be improved upon. After battery life considerations, a case would have been designed next. The case would have to be waterproof in case of inclement weather and shockproof in case a unit is accidentally dropped. Although these modifications were not performed on this system, the low cost system was created successfully. After choosing the correct mode on the handheld unit, each unit will perform its desired task. The computer program is also user friendly and easy to gather data. 15

16 References: "Arduino - PlayMelody." Arduino. Winter 2013 < Blumc, Jeremy. "Tutorial 9 for Arduino: Wireless Communication." JeremyBlumcom. Winter 2013 < Kaui, Cindy. "How does arduino communicate with our AS3992 UHF RFID reader." SolidDigi Technology Forum. Winter 2013 < "QextSerialPort Getting Started." QextSerialPort_1_2_Beta1. Winter 2013 < "RGB LCD Shield." Adafruit Learning System. Winter 2013 < "Tutorial: Arduino and XBee Communication." Smith College Computer Science. Winter 2013 < "Xbee configuration." Element 14. Winter 2013 < Division of Responsibilities: Edward Tan -Robert Evans - Michael Houldsworth - Christie Sitthixay - Select and purchase components - All team members Integrate and test uc components - Robert Evans and Edward Tan Build first complete uc system - Robert Evans and Edward Tan Perform ZigBee radio tests - Robert Evans and Edward Tan Test RFID reader/antenna connected to PC - Michael Houldsworth and Christie Sitthixay Evaluate read distance and antenna issues - Michael Houldsworth and Christie Sitthixay 16

17 Understand ZigBee/Arduino interface - Robert Evans and Edward Tan Understand RFID/Arduino interface - Michael Houldsworth and Christie Sitthixay Progress report - All Team Members Build & test final handhelds - All Team Members uc & PC software - All Team Members Final systems tests and evaluation - All Team Members Poster & final report - All Team Members Appendix: Budget Part Unit Cost Quantity Total Cost keypad $ $20.70 Arduino Mega $ $ LCD Shield $ $59.85 XBee Shield $ $ XBee Programmer $ $24.95 LEDs $ $3.20 XBee Module $ $25.95 UHF RFID Reader Kit $ $ Speaker $ $7.47 Total Cost $ Table 1: Budget 17

18 Code Files: Completed code for the microcontroller is located at: Since all three handhelds use the same code, they can all be programmed with the above file. Code for the PC program is located at: Running this code requires QT creator and the qextserialpot library. 18

International Journal of Scientific & Engineering Research, Volume 7, Issue 3, March ISSN

International Journal of Scientific & Engineering Research, Volume 7, Issue 3, March-2016 1026 LIFI BASED AUTOMATED SMART TROLLEY USING RFID V.Padmapriya 1, R.Sangeetha 2, R.Suganthi 3, E.Thamaraiselvi