EECE 375/474 Final Report

RFID License Plate

Instructor: Dr. Lukas Chrostowski Submission Date: July 24, 2007

Team 5 Andrei Horga Alexander De Maeseneer Li Jin Johnny Tang Allan Cheng Annie Yiu

Abstract
In order for a police officer to scan a license plate while driving, the officer must manually search for that specific license plate number in a database stored on the police laptop. Our goal is to have a fully automated system that will enable police officers to automatically check and cross reference all vehicles within a 50m radius for stolen vehicles within seconds. Our project provides a safe, secure, and cost effective system that wirelessly transmits a license plate number from a vehicle to a police laptop. The license plate number is then cross referenced against a local database to check if the specific vehicle is stolen or not. If a stolen car or overdue fines are detected, a simple program will pop up any cars listed as stolen, along with supporting information such as model, registered owner, and colour to the police. The effects of having such a system in place would be lower auto crime, increased police productivity, and increased ticketing revenue. After going through extensive development and two different microcontrollers, the implementation of the E-Zi plate has proven to be a success. At the time of this writing, the hardware has been properly configured and tested to be working. The software proved to be a problem, but in the end we managed to create working software for every block of our system. A software anti collision feature for the system has been planned for areas of high density vehicle traffic, but due to time constraints, this feature was not realized.

Table of Contents
1 2 Introduction................................................................................................................. 9 Project Background................................................................................................... 11 2.1 2.2 2.3 2.4 2.5 2.6 3 Octopus Card .................................................................................................... 11 Veriplate Automated License Plate Recognition.............................................. 13 Toll Collecting System ..................................................................................... 14 Automated Vehicle Identification (AVI) .......................................................... 15 Improvements ................................................................................................... 16 Police Feedback ................................................................................................ 16

Design Requirements and Goals............................................................................... 19 3.1 3.1.1 3.1.2 3.1.3 3.1.4 3.2 3.2.1 3.2.2 3.2.3 3.2.4 Software ............................................................................................................ 20 Local Database.......................................................................................... 20 Laptop Application ................................................................................... 21 RFID Active Reader ................................................................................. 21 RFID Active Tag....................................................................................... 22 Hardware........................................................................................................... 23 System Components.................................................................................. 23 Operating Conditions ................................................................................ 24 Detection Range........................................................................................ 24 Power Requirements. ................................................................................ 25

Results....................................................................................................................... 26

4.1 4.1.1 4.1.2 4.1.3 4.1.4 4.1.5 4.1.6 4.2 4.2.1

CC1010 Design and Implementation................................................................ 26 Positive Tradeoffs ..................................................................................... 26 Negative Tradeoffs.................................................................................... 27 Implementation - Hardware ...................................................................... 28 Implementation - Software ....................................................................... 34 Experimental Testing ................................................................................ 35 CC1010 Project Budget ............................................................................ 38 Second Implementation .................................................................................... 40 Software .................................................................................................... 40 MySQL Database.................................................................................. 40 Visual C++ Laptop Program................................................................. 42 Reader embedded software ................................................................... 44 Tag Embedded Software....................................................................... 49 Hardware................................................................................................... 51 Circuit and PCB layout ......................................................................... 51 Microcontroller ..................................................................................... 54 Transceiver............................................................................................ 56 Antennas ............................................................................................... 58 Theoretical Antenna Results ........................................................... 59 Actual Antenna Results................................................................... 63

4.2.1.1 4.2.1.2 4.2.1.3 4.2.1.4 4.2.2 4.2.2.1 4.2.2.2 4.2.2.3 4.2.2.4

4.2.2.4.1 4.2.2.4.2 4.2.2.5

Tag and Reader Placement.................................................................... 69

4.2.2.6 5

Power Calculations ............................................................................... 70

Assessment and Analysis.......................................................................................... 71 5.1 5.2 5.3 Success and Shortcomings................................................................................ 71 Feasibility Study ............................................................................................... 72 Scalability ......................................................................................................... 73

6 7 8

Sources...................................................................................................................... 80 Appendix A Received Power vs. Frequency For Different Test Cases................. 81 Appendix B Software Utilized in cc1010 .............................................................. 86 8.1 8.2 8.3 Serial Communication ...................................................................................... 86 Transmitter Code .............................................................................................. 88 Receive Code .................................................................................................... 90

Appendix C CC1010 Budget ................................................................................. 96

List of Illustrations
Figures:
Figure 1 Octopus Card ................................................................................................... 12 Figure 2 - Handheld Octopus Reading Device ................................................................. 12 Figure 3 - Add Value Machines........................................................................................ 13 Figure 4 - The E-ZPass Process ........................................................................................ 14 Figure 5- An Example of an AVI system ePlate............................................................ 15 Figure 6 - System Block Diagram .................................................................................... 20 Figure 7 Reader/Tag timing diagram............................................................................. 22 Figure 8 - Pin Configuration for RF and Crystal .............................................................. 28 Figure 9 - Component values for Pin Configuration ........................................................ 29 Figure 10 - Initial PCB Design ......................................................................................... 30 Figure 11 - Initial PCB Design Implemented ................................................................... 30 Figure 12 - Second PCB Design ....................................................................................... 31 Figure 13 - Second PCB Design Implemented ................................................................. 32 Figure 14 - Max232 Serial Connection............................................................................. 32 Figure 15 - Parallel Connection Configuration using SN74LVC245A ICs ..................... 33 Figure 16 - Serial Communication MC to PC .................................................................. 34 Figure 17 - Crystal Oscillator Waveform ......................................................................... 37 Figure 18 - Flasher Program Output ................................................................................. 38 Figure 19 - MySQL database format ................................................................................ 41

Figure 20 - Example data.................................................................................................. 41 Figure 21 - Laptop program flowchart.............................................................................. 42 Figure 22 - RS232 Serial data format ............................................................................... 43 Figure 23 - Reader Flowchart ........................................................................................... 45 Figure 24 - Microcontroller and Transciever SPI interface .............................................. 46 Figure 25 - Data transmission flowchart........................................................................... 47 Figure 26 Receiving data flowchart.............................................................................. 48 Figure 27 - Tag Software Flowchart................................................................................. 49 Figure 28 - Reader Circuit Diagram ................................................................................. 52 Figure 29 - PCB Schematic............................................................................................... 53 Figure 30 - Tag PCB ......................................................................................................... 53 Figure 31 - ATmega164 Pin Configuration ...................................................................... 55 Figure 32 - SPI interface between the microcontroller and the XE1205 transceiver ....... 57 Figure 33 - Range over Receiver Sensitivities.................................................................. 61 Figure 34 - Range Over Varied Output Power ................................................................. 62 Figure 35 - Signal Cancellation through 180 degree phase shift ...................................... 63 Figure 36 - Antenna testing system .................................................................................. 64 Figure 37 - Received Power vs. Distance Forward Measures ....................................... 65 Figure 38 - Received Power vs. Distance Reverse Measures........................................ 65 Figure 39 - Received Power vs. Distance No Obstructions, Mounted .......................... 66 Figure 40 - Received Power vs. Distance Non Mounted, No Cars In Between ............ 67

Figure 41 - Received Power vs. Distance - Non Mounted, no Obstructions .................... 67 Figure 42 Received Power vs Frequency Parking Lot, Car 1..................................... 68 Figure 43 - Received Power vs Frequency - Parking Lot, Car 2 ...................................... 68 Figure 44 - Received Power vs Frequency - Parking Lot, Car 3 ..................................... 69 Figure 45 - Tag Placement................................................................................................ 69 Figure 46 - Reader Placement........................................................................................... 70

Tables:
Table 1 - Benefits of the cc1010 in relation to ATmega164............................................. 26 Table 2 - Summary of cc1010 Costs................................................................................. 39 Table 3 - Total Budget of both Atmel and CC1010.......................................................... 76 Table 4 - Total Atmel Components .................................................................................. 78 Table 5 - Total Budget of the cc1010 ............................................................................... 96 Table 6 Actual per unit Cost of Tag............................................................................... 97 Table 7 - Actual per unit Cost of Reader .......................................................................... 98

1 Introduction
Police are a crucial part of the backbone of our society. They keep our streets safe from crime. They ensure the protection of our belongings. They prevent harm from coming to both us and our loved ones. They enforce our regulations so together we can function as a society. These law enforcers have many tasks to do during a day. So with todays technology, we are able to arm our crime fighters with new tools to help them complete their jobs faster and more effectively. Already today, police cruisers are retrofitted with on board computers, giving them access to databases used to log criminal activity. With such technology, small and remedial tasks are done more accurately and quickly, allowing them to use their time for more serious matters. We plan to further improve their efficiency by removing another remedial task, checking for cars that are stolen. Currently, it is impossible for police to check every license plate they see by cross-referencing the number with a database to check for violations. Our goal is to change this impossibility into reality. In this project, we created a working RFID license plate system, consisting of a tag that stores the license plate number, a police reader that reads this number, and a laptop application that searches through a database for the license plate number . Our initial reason for doing this project was our vision of a BC where every car has a RFID license plate installed. The police cruisers around BC would have RFID reader devices installed in their vehicles. In the event the police cruiser came within 75 meters of a car, the device reader would read the license plate number stored on the RFID tag in the license plate, and the police would be able to compare it with a list of stolen vehicles in their database. The obvious advantage for a BC with this system installed would be lower crime rate as stolen vehicles can be easily tracked.

In this report, we will describe how previous companies have used RFID technology, how we can draw on the knowledge of such applications and how our device would differ from past works. We will touch on the different components of the RFID license plate and the RFID reader and how each component interacts with one another. We will also touch on the feasibility and scalability of our project if it was indeed attempted to be mass produced in the real world. During our interviews with several PR police officers, we were able to gain some insight on how the police central database really works. However this information was for the most part confidential, thus we could only make our database simulate theirs as accurately as possible based on the clues the police officer gave us. We will describe how we used MySql to create said database, and how a Visual C++ program was used to compare this database to incoming values. During the beginning stages of our project, we planned to use the CC10101 microcontroller with a built in transceiver. With a minimum of two of these microcontrollers, we can implement a system were one microcontroller will behave as a reader, and the other as the tag. However during our development cycle we ran into unforeseen problems with this microcontroller which made implementing our system with said microcontroller not feasible. Thus we decided to continue implementing the project by switching to an Atmel 164p microcontroller. We will describe the problems we encountered when trying to implement with the CC1010 microcontroller and the differences in implementation between the two microcontrollers.

2 Project Background
Before starting any sort of design work, extensive research was conducted on similar products in the marketplace to evaluate the demand for our product. This research included visiting the RCMP and the VPD, where interviews were conducted with two different police officers and the head of public relations at the Vancouver Police Department. These initial interviews helped us set up proper design requirements for our product. What follows is a brief background on Radio Frequency Identification (RFID) RFID is not a newly discovered technology, it was first used in 1939 to identify aircrafts in World War II[1]. By the 1980s, it started to be materialized into working systems. Now, it is beginning to be applied to humans daily lives. The wide range of applications for RFID include transport payments, passports, product tracking and even human identification. Our project, in essence, is an active RFID system, composing of a tag, reader, and PC. The following sections provide an overview of some popular RFID systems in place today.

2.1 Octopus Card

Making Everyday Life Easier is the slogan of Octopus Cards Limited. Ninetyfive percent of the population of Hong Kong aged 16- 65 use the Octopus Card, thanks to its general convenience and safety. In general, it transfers payments electronically and safely by using RFID technology. It uses the Sony 13.56 MHz FeliCa passive RFID chip, which has a maximum transmission speed of up to 212 Kbit/s, and a storage capacity of 1KB to 64 KB[2]. The operating range is very short, between 30 to 100 mm. A figure of the Octopus Card is shown below.

Figure 1 Octopus Card Source: http://en.wikipedia.org/wiki/Image:AdultOctopusCard.jpg

The Octopus Card is a touch and go system. Users will first prepay a certain amount of money onto their Octopus cards through add-value machines, shown below in Figure 2[2]. These add-value machines are placed in subway stations, the most popular form of public transit in Hong Kong. An add-value machine is shown below.

Figure 2 - Handheld Octopus Reading Device Source: http://en.wikipedia.org/wiki/Image:Octopus_McDonalds_Central.jpg

Octopus reading devices and check-value machines are placed in subway stations, mini-buses, buses, stores like McDonalds and 7-eleven, and even vending machines, which are shown in Figure 3 below [2]. When a user makes a purchase with Octopus card, the Octopus reading device will automatically deduct the amount from the users card and display its updated balance.

Figure 3 - Add Value Machines Source: http://en.wikipedia.org/wiki/Image:OctopusAddValueMachine.jpg

Users are also allowed to check their card balance without purchasing any goods. They can simply place their cards on the check-value machines and can choose to go to add-value machines if they want to increase their money value of their cards. From their beginnings in 1997 to the present, no one has considered security a problem for the Octopus Card because it has yet to be successfully hacked [2].

2.2 Veriplate Automated License Plate Recognition

Currently, police officers are using vehicle mounted cameras to run automatic license plate checks. Such a system is the Veriplate Automated License Plate Recognition (ALPR) [3]. The Veriplate consists of a camera mounted on a vehicle, the corresponding software, and a stand-alone processor. The Veriplate works on a line of sight, the cameras capture what is straight ahead of the vehicle, and the ALPR processor transfers this picture into a character string that is compared against a local database. Systems such as the Veriplate are already in use here in Vancouver. IMPACT, a joint police force, uses these cameras for their operations [4]. However, there are some major shortcomings with a line of sight system such as Veriplate. For example, if there is fog or heavy rain, the camera might not pick up the license plate number. Another way of easily getting around the system would be to obstruct the license plate, with mud for instance.

2.3 Toll Collecting System

Nowadays, RFID technology is used in the United States as a toll collecting system. Two popular examples are the E-ZPass and E-zPass Plus; available in Albany International Airport in Albany, New York. These systems work by automatically deducting the toll amount from a pass that is placed on a vehicles windshield. Without cars stopping, this makes for a more efficient and fast traffic flow. Up to 300% more traffic flow has been reported in some areas [5]. The system also allows the Department of Transportation to track travel time and traffic flow data. The passes that the system uses are 900MHz passive RFID tags. They store account identification numbers and prepaid account balances. Figure 4 below demonstrates how an E-ZPass is read.

Figure 4 - The E-ZPass Process Source: http://www.geocities.com/srivathsajoshi/ezpass.gif

2.4 Automated Vehicle Identification (AVI)

AVI identifies registered vehicles in the United Kingdom. It is generally used for security, access control, tacking and processing, traffic management and customer service [5]. It involves battery powered RFID tags embedded in the vehicles license plate. Figure 6 below illustrates an example of an AVI system.

Figure 5- An Example of an AVI system ePlate Source: http://www.emediawire.com/prfiles/2006/06/09/397141/eplate.550329.jpg

Each tag that is embedded in ePlate contains a unique, encrypted identification number which is transmitted to stationary roadside RFID readers. These readers can read cars at speeds up to 320 Km/hr, in a range of up to 100 meters. As the identification number is sent, the central system of the UK Ministry of Transport will be able to see the corresponding vehicle data, such as VIN number, owner details, make, made, color and insurance renewal dates. Presently AVI is still on trial. The publics main concern with this sort of system is personal privacy.

2.5 Improvements
Our project aims to improve on work done by existing automated license plate checkers, such as the veriplate. The major difference would be that our system is not line of sight, rather, it has a wide radius of operation where every license plate in the vicinity would be scanned and processed. Our system would also be more secure. Simply obstructing the license plate will not stop our system, as it works on radio waves, and is shielded by a license plate. Any attempts to tamper with the license plate are already illegal. The system we have built will also improve the work done by ePlate. This includes changing the type of data stored on the license plate, how it is used, and who can see the data (police rather than a public ministry). While ePlate is used for a range of purposes, our system will be used specifically for detecting stolen cars and overdue fines. Customer privacy is one of our projects greatest commitments. Since our tags only contain the license plate number, no private information about customers is accessible by simply scanning the tag. Rather, the police laptop does the work of crossreferencing license plate numbers against a national police database and listing customer details, in this way, no sensitive data is ever stored in our tags. This is in contrast to the ePlate, which contains stationary readers that can be vandalized, and transmits the information to a public ministry rather than to the police.

2.6 Police Feedback

To ensure the feasibility of our project, we interviewed two police officers, in addition to the Media Relations Officer for the VPD. Our first interview was with a police officer at the local UBC RCMP branch. The interview helped us produce some basic system requirements, such as what operating system the police laptops run on, what the database should store, how far the range should be, and if the overall project would be helpful to the police.

Our second interview was with a police officer at a local RCMP branch. It was noted during this interview that license plate checks are done quite often, especially when property crime is a suspicion. A RFID system was compared to a line of site camera system, and the officer agreed with us that an RFID system has many advantages, including operation in any weather condition and an easier operation. The officer also suspected there would be no problems with installing an antenna on the roof. Our final interview was with Howard Chow, the Media Relations Officer at the VPD. This interview helped us answer some long-standing questions we still had about police protocol. It was found that there is one national database, CPIC that tracks all crimes reported in real time. A license plate inquiry on this database will show information such as the car model, registered owner, whether the car is stolen or not, and how much fines are due (if any). However, this database is centralized, and all requests for license information are done wirelessly. In order to implement a central database via wireless channels, some changes would have to be done to our original model, which was based on localized databases. Due to time constraints, these changes were not implemented, however, a feasibility study was conducted, which can be found in Section Five. Mr. Chow also explained to us that police officers are allowed to have their laptops open while driving, even if they are driving alone. Thus, our program would be useable while on the road, an initial condition of ours. The Vancouver Police Department has very strict guiding principles on what software can be installed on the police computer systems. Our software would have to pass meticulous investigations by governing bodies and technical teams in order to be approved to be installed on the police computer systems. Another option would be to have another standalone computer for the purpose of our RFID license plate system in order to avoid the risk of breach to the existing police computer system. There would also have to be changes made to the way ICBC registers license plates, and a phase by phase introduction of our RFID system to the general public. More detail on scalability can be found in Section Five.

Currently, license plate checks are made manually by having the police officer typing in the suspicious license plate into the laptop. The laptop will then connect wirelessly to the database to see if the vehicle is reported stolen. Officer Chow also told us that the response of the wireless system is very fast and the license plate checks will be made instantaneously. The only times that the response from the database would slow down, according to officer Chow, would be when the system is under maintenance or if when there are unforeseen errors with the system. However, Mr. Chow noted that officers must normally have reasonable suspicion in order to check a license plate. Checking every single license plate automatically might bring about legal challenges, something that is discussed alongside our plan to implement a central database in the feasibility section of Section Five.

3 Design Requirements and Goals

Our project has one main goal, to efficiently automate the license plate checking process for police officers, and make sure it works in the operating conditions listed in hardware section of this chapter. To realize this goal, proper design requirements were set out at the start of the term, and revamped after our interviews with the police. The minimum hardware design requirements are: An active RFID Tag An active RFID Reader A Laptop

The minimum software requirements of the system are as follows: The RFID Tag will broadcast its license plate every 0.5 seconds. When the reader receives the license plate number from the tags, it will transfer the information to the laptop. The laptop will then have a program that searches through the local database for a matching license plate number. The program will pop up the information of the registered license plate if it is reported stolen or there are overdue fines, to alert the police officers. This information will contain the vehicles model, license plate number, color, year, a column for stolen cars, and an extra column for overdue tickets and how much money is due. This all has to be done within 1.0 second of the reader sending a request out. The following subsections detail what sort of goals and requirements are needed for our software and hardware subsystems to ensure a fast, efficient, and most importantly, functional system.

3.1 Software
Our system will require four independent software programs, and the proper communication channels to link them, as shown in our system diagram below. Text in blue represents the individual software, while text in black represents a communications link. Dotted lines separate the hardware components.

Figure 6 - System Block Diagram Source: Original

3.1.1 Local Database Initially, we wanted to interface the existing CPIC national police database to the end-user application we were building for the police. However, due to valid security concerns, we were unable to gain access to the central CPIC police database. Instead, we decided to model our own database after the current CPIC database, with columns for the license plate number, the car model, the year of the model, the colour, the registered owner, whether the vehicle is stolen or not, and how much fines are due, if any.

We decided that MySQL was the best choice for our project. MySQL fulfilled three very important requirements we set out for our database. Firstly, the database must be secure. MySQL has a long history of secure operation, even powering bank databases [7]. Secondly, the database must be easy to use. MySQL is the most popular open source database, and has a vibrant user community that is eager to help [7]. Lastly, the database must be able to store and process a large amount of data. MySQL is the database of choice for mega-sites such as YouTube, and has proven itself up to the task [7]. 3.1.2 Laptop Application Our laptop application will be run on police laptops inside cruisers. The application has three main requirements. Firstly, it must read data being sent from the reader via the serial port. Secondly, it must compare the value read from the serial port to the database, and notify the user of a stolen car when the license plate is flagged as stolen via a popup. Lastly, the application must be run on a Windows operating system, since the police laptops run on Windows. Visual C++ was chosen as the logical choice to code both parts of the laptop application. This is because all team members had experience with C++. Some team members even had direct experience creating Windows applications via VC++. Other choices considered were Visual Basics, but route was rejected because of lack of experience and time constraints. 3.1.3 RFID Active Reader The RFID Active reader has two main requirements. Firstly, it must wirelessly receive license plate data from RFID tags via a wireless interface. Secondly, it must pass this received license plate data to the laptop computer via a serial connection. In order to communicate with the tag, the reader must be set in transmit mode, and send a request the tag to send. The reader must then go into receive mode to receive the data back from the tag. A timing diagram is shown below.

Figure 7 Reader/Tag timing diagram. Source: Original

The microcontroller we used to implement this block supported two languages for embedded programming: C and Intel Assembly. We decided to go with the highest level language possible in this instance, C. We had two choices of Integrated Development Environments for our particular chip, CodeVisionAVR, and AVR Studio. In the end, we chose CodeVisionAVR because it is more user friendly than AVR Studio. 3.1.4 RFID Active Tag The RFID Active Tag has one main requirement, to send the license plate data to the reader when prompted. In order to realize this goal, and to save power, the tag is set to receive (or hopping) mode for 10 milliseconds every 0.5 seconds. Once the tag receives a request from the reader to send data, it will set itself to transmit mode and wait 0.5 second before it sends, as show in Figure 7. Since the tag and reader are asynchronous, the tag has a range of time of 0.5 seconds for where it could be hopping. However, the timing diagrams ensure that the tags will always be in receive mode when the reader is in transmit mode, and vice versa.

The tag was implemented using the same microcontroller as the reader, therefore it had the same coding requirements, and we once again used CodeVision AVR studio for the programming.

3.2 Hardware
Our hardware must fulfill four main requirements. Firstly, it must be able to efficiently support the software and communication system in place, as shown on Figure 6. Secondly, the hardware must be able to perform in any operating condition possible, including worst case scenarios. Thirdly, the hardware must support a 75 meter range of detection. Lastly, the active tag must be able to run on an independent battery for a minimum of 10 years. 3.2.1 System Components In order to support the communications and software system we have in place, the hardware must consist of three blocks. The first block will be the Active RFID Tag, which must be able to store and process data, and quickly transmit this wireless data to the reader. A microcontroller with a transceiver will be able to perform this task. The second block will be the Active RFID Reader, which must be able to wirelessly receive the data from the Tag, and send it out via a RS232 Serial port to a PC. A microcontroller, transceiver, and LM232 chip will be able to receive the data, process it, raise it to TTL levels and send it to a computer via a serial port. The last block will be the police laptop, which must be able to receive data via a serial port. A standard police laptop fulfills this requirement. The hardware must also maintain a fast communications uplink between the reader, the tags, and the police laptop. Specifically: The tags will send 8 bytes of data to the reader, which then relays this information to the computer. We may assume a maximum of 50 cars in the readers range at any one time, so the reader will have to relay 400 bytes of data to the laptop.

Therefore a wireless connection of 30kb/s will be more than enough for the transmission and reciving of the wireless data.

A serial RS232 port running at 9800 baud will also be more than enough to handle the maximum amount of data being sent to the laptop (400 bytes, which corresponds to 400 baud).

The tags must have enough storage for the license plate data, plus the actual program. A microcontroller with 10kb of storage will be more than enough.

3.2.2 Operating Conditions The hardware must maintain a fast communications uplink between the reader and the tags, so a minimum requirement of under the worst case conditions a police car should be able to detect cars as far away as 25 meters in all directions. These worst case conditions include the following: Heavy traffic causing significant reflections of the metallic surfaces of cars All types of weather and climate conditions, including rain, fog, and extreme temperatures High Speeds (> 200 km/h)

3.2.3 Detection Range The desired operating range of the system should be 75 meters, Omni-directional. This will ensure the police can automatically pick up cars in their general area, which can be useful both for roadside operations, where a police car is moving, and for stationary operation, if the police wants to set a trap up, much like stationary radar. The hardware that directly impacts this requirement is the antennas.

3.2.4 Power Requirements. The laptop and reader will be powered by the police vehicle they are stationed in, however, this is not the case for the tag. The tag will reside underneath the license plate, and therefore must power itself via a battery. A minimum of 10 years of operation is required to ensure a long lasting life. This requirement will rely directly on the battery chosen, the general hardware that is chosen for the tag, and how long we plan on powering the tag for normal operation. A hopping protocol, described in section 3.1.4, will reduce the power consumed for normal tag operation.

4 Results
Throughout the semester, the project has gone through many changes and overhauls, including both the software and hardware components. What follows is the results of our first implementation, using the CC101 microcontroller/ transceiver, and the results of our second implementation, using an Atmel ATmega164V microcontroller combined with a DP1205 wireless transceiver.

4.1 CC1010 Design and Implementation

This section documents the design and implementation of our project using the cc1010 micro-controller. It will discuss the tradeoffs between the cc1010 and the ATmega164, detailed schematics, images, explanation of how it would be used, and why it was replaced by the Atmel micro-controller. 4.1.1 Positive Tradeoffs The cc1010 was initially chosen as the preferred micro-controller because it provided many features that were of benefit to our application. The main advantages were low cost, lower power consumption, smaller dimensions, integrated transceiver, RSSI capabilities, and 8051 core.
Table 1 - Benefits of the cc1010 in relation to ATmega164

cc1010 Cost (MC + transceiver) Power Consumption (MC + transceiver) Dimension (PCB size) RSSI capable Yes 43.2 cm2 9.1 mA $12.19

ATmega164 $5.51 + $40.03

% Benefit 274%

14.3 mA

36.7%

75.9 cm2

43.1%

~Yes

N/A

It is a necessity to keep the cost, power consumption and dimensions down to a minimum. It is desired to keep the cost down because we plan to implement a tag unit on every vehicle on the road. We want to minimize the overhead cost when the tag is replaced every five years. In addition the tag runs on batteries, hence the less power it consumes, the longer operability of the tag. The added power could also go to improve response time by waking up earlier to spot a readers signal. Finally, the license plate does not hold much room for circuitry, unless we build a very large case. In addition, the smaller size would be advantageous for security reasons. There are also other features that caused us to choose the cc1010 over the Atmel. The cc1010 transceiver has RSSI capability. This is an attractive feature because it can inform the police officer the approximate distance from a target vehicle. The transceiver paired with the ATmega does have RSSI capability however it only operates for -85 dBm or less. Furthermore the fact that the cc1010 has an 8051 core made us more confident with the software design because many of us have experience with that micro-controller. 4.1.2 Negative Tradeoffs

Many complications have arisen because we did not have an evaluation board. First, the MC is a surface mount, meaning we needed a PCB in order to flash any code into it. We had to implement circuitry for serial and parallel communication. A brief timeline is listed below 1st PCB Deadline: a simple PCB design was submitted o Failed to meet specs o This was with the Atmel controller st 1 PCB Deadline Extension: Skipped o Changed MC to cc1010 o Did not have sufficient time to complete a PCB for a new MC nd 2 PCB Deadline: our first (full) PCB design was submitted o Failed, clearance violations o We had to draw all 64 pins of the cc1010 ourselves b/c it was not in our library st 1 Personal Order: o Successful (1st design) o Ordered 2 boards

3rd PCB Deadline: o Successful (2nd design) o Ordered 8 boards with improved design detailed below nd 2 Personal Order: o Successful (used for Atmel MC) o Ordered 4 boards o One week remaining to complete project

4.1.3 Implementation - Hardware

We implemented the development module and part of the development kit for cc1010. The values for crystals, capacitors, inductors, and resisters are provided by Chipcon as shown below.

Figure 8 - Pin Configuration for RF and Crystal Source: Original

Figure 9 - Component values for Pin Configuration Source: Original

Instead of using Chipcons four layer PCB design, we used two layers and used the bottom layer to be ground and the top layer for circuitry. Due to cost constraints, we left out the power layer and the decoupling layer. We place decoupling capacitors on the bottom layer to minimize circuitry clutter on the top. Since our RF portion of the PCB is operating at 433 MHz, we kept the RF components as close together as possible to minimize noise which could interfere with the antenna radiation characteristics because the wires themselves can act as antennas. The initial design is shown below along with a picture of the actual PCB with some components.

Figure 10 - Initial PCB Design Source: Original

Figure 11 - Initial PCB Design Implemented Source: Original

In our second PCB design we made a few minor changes. The main difference between the first and second design is the socket. By using two sockets on the second design we were able to avoid the spiralling of PCB tracks from our initial design. Also, the orientation of the pins on the PCB for the oscillator was fixed. The other changes were mostly making our design clearer and easier to test. For instance all our pins from the sockets are labelled. The female connection on the sockets was larger for an easier connection with wires. Finally the new sockets included a pin for power and ground which saved us the trouble of having to solder wires the bottom of the PCB when testing. The second PCB design is shown below.

Figure 12 - Second PCB Design Source: Original

Figure 13 - Second PCB Design Implemented Source: Original

We then created circuitry for serial communication using a MAX232. This IC was used to shift the voltage from the MCs 3.3V to the PCs 5V. It also performed logic inversion on communication lines. The diagram is shown below.

Figure 14 - Max232 Serial Connection Source: Original

Shortly after having implemented our PCB, we discovered that the cc1010 flash program only accepts a parallel connection. However, we can still use this serial connection to communicate between MC to PC after the code is flashed. We designed the parallel connection based on the schematics from Chipcons development board. Instead of using the ICs 74LVC4245A we used SN74LVC245A mainly because 74LVC4245A requires a surface mount and we didnt want to purchase another PCB just to flash program into our MC. Another between the ICs is the number of pins. Our IC has only one VCC and we connected it to 3.3V because if we followed Chipcons diagram directly using our ICs we would fry our MC. This also meant that we disconnected 5V from PC. We also used a wire instead of a jumper as seen below.

Figure 15 - Parallel Connection Configuration using SN74LVC245A ICs Source: Original

Once the parallel connection was established we began to attempt to flash our code into the MC.

4.1.4 Implementation - Software

We have designed software for the three main functions necessary for our application: serial communication between MC and PC, RF transmit and RF receive. These are the programs that we were going to flash into the cc1010 and test the USART and RF functionality. Once we have established these primary functions, we can easily implement our flow charts. There are already many pre-built functions inside the headers, it is mostly learning how and when to use them. Below is a high-level view of the three main programs. Serial communication was primarily for a reader to send information to a laptop containing a database to check if the license plate is stolen. Therefore the main function we want from this is a license plate number moving from MC to PC. To establish communication, first the serial ports are configured to the right baudrate (57600), transmit and interrupt triggered. Then all thats left is to send the license plate to the PC, which can be accomplished through a predefined function.

License Plate

MC Reader

Number Transfer

PC

Figure 16 - Serial Communication MC to PC Source: Original

The transmission of a signal is used for the reader to request a license plate and for the tag to send its license plate. To achieve the transmission of a signal, the transceiver must first be configured with the following settings:

Frequency of crystal Frequency of transmission Encoder (i.e. Manchester, NRZ, .) Frequency separation Transmit mode Output Power level Baudrate

These parameters are then passed into a calibration function. After calibration, the data packet can then be sent through another function via pointer to the array. The preamble, synchronization bits and actual data transfer is handled automatically by the MC. This code can be found in the appendix The final of the three important functions is the receive task. This is used for both the tag and reader for receiving a request and license plate, respectively. To accomplish this task, a similar calibration function as above is utilized only there is no output power level and it is of course set into receiving mode as oppose to transmitting. The main function would then go into an infinite while loop. As it is looping, whenever data packets arrive (they are the size of a byte) an interrupt service routine would handle the incoming data and store it into an array of bytes. Once the array is filled, all the data will be displayed on the screen. The code found in the appendix also shows displays the RSSI (Receive Signal Strength Indicator) level. 4.1.5 Experimental Testing

After we have discovered that our micro-controller required a parallel connection in order to begin to flashing code, we have performed many attempts to transfer our code into the cc1010. Below we list the details of our testing and all attempts that we have made.

1st Attempt Created simple LED program to flash parallel Used first PCB design Flasher program cannot detect anything on the parallel port We thought it might be due to the power supply

2nd Attempt New power supply used, same set up as 1st attempt The power supply wire touched a capacitor and resulted in a big spark Rod told us our circuitry should still be okay Checked connectivity on all pins on the parallel port Checked connection of socket to PCB We thought it might be the circuitry or the MC not functioning properly Still cant detect on parallel port

3rd Attempt New PCB (second design) and new MC Accidentally used 5V to power MC when datasheet specifies max 3.6V Still no detection on parallel port

4th Attempt Utilized a new PCB and new MC (only connected components needed for MC to function, no RF components) We tried connecting the LED ports shown in section hardware section of the cc1010 o Tom said the LED ports probably wouldnt have an effect, but we tried it just in case Still no detection on parallel ports

5th Attempt Utilized same set up as 4th attempt We tried to flash code through the command prompt instead of the flasher program Same result, no success

6th Attempt Tried to flash using an SPI connection Requires an IC that we dont have

Once we have gone through all these attempts, we finally got Tom to help troubleshoot our MC design. After three hours of testing Tom wasnt able to resolve the parallel connection problem. Tom first check to make sure our oscillator was functioning properly as shown below.

Figure 17 - Crystal Oscillator Waveform Source: Original

Tom then check to make sure our software was flashing code. This was done by connecting the oscilloscope to the parallel connector and observing a transient voltage once the flasher program attempt to transfer code to the cc1010 which is shown below.

Figure 18 - Flasher Program Output Source: Original

As we can see above, the flasher program appears to be functioning properly. Because of this, Tom concluded that perhaps our MC was fried. We tried another MC and we still had the same result. A possible cause of the micro-controller malfunctioning could be that we shocked it because we did not ground ourselves when soldering components onto the PCB. At this point in time, we only had about a week left and we had to implement our contingency plan using the Atmel MC. The reason that we choose Atmega 164pv is that it consumes less power and Bo Yang from team 1 is willing to share her knowledge about this MC and help us start doing the new project quickly. 4.1.6 CC1010 Project Budget

Below the budget for the cc1010 is divided into three parts (the full budget will be discussed near the end of this report). The first part of the budget is the total cost of all the components purchased (used and thrown away) for the cc1010 portion. The second part shows how much it cost us to build one tag and one reader (actual cost). The third section provides the same per unit cost of tag and reader but massed produced. These tables can be found in the appendix C, here we summarize the totals.

Table 2 - Summary of cc1010 Costs Source: Original

Cost Type Actual Cost of Tag (per unit) Actual Cost of Reader (per unit) Massed produced Tag (per unit) Massed produced Reader (per unit) All components purchased

Cost $36.97 $47.48 $29.97 $27.59 $293.95

As we can see from the above table above, the costs are greatly reduced through mass production, especially in the case of the reader where it is almost halved. Having people replace their tag every year is seems reasonable at a price of $30.

4.2 Second Implementation

The second implementation began on July 17, giving us very little time with which to complete a working system. This implementation of an Atmel ATmega164V with a DP1205 wireless transceiver for both the tag and the reader was originally our first choice. However, due to the CC1010 being much cheaper overall ($12 vs $55), the decision was made to use the CC1010. After an unsuccessful implementation, we decided to go with our original choice, the Atmel and external transceiver, because of the challenges we faced with the CC1010, as described in the previous section. Also of great help was the face that there were quite a few helpful people in the laboratory working with the same microcontroller, including Bo, who helped us program our microcontroller. What follows are the results of this implementation, including all relevant performance measures. 4.2.1 Software The software has the task of ensuring that a license plate number can be transmitted properly, read, processed, and eventually displayed if the car is stolen. The software requirements, as described in section 3.1, were followed and optimized to provide a reliable overall system. The following sections describe the process taken to create our different software programs, and the results of our software programs, both individual and working in synchronization. 4.2.1.1 MySQL Database We originally planned to use the centralized police CSIS database, but we were not allowed to due to security concerns. Thus, we created a model database after receiving feedback from the police. MySQL was chosen over other methods of storing data, such as Excel or a text file, because of its security, scalability, and ease of use. MySQL 5.0 Community Server was downloaded from the official MySQL database, and installed according to the readme file found on the accompanying CD.

The official requirements form MySQL are met by the existing police laptops in use today, and are highlighted below. O/S: A 32-bit Windows operating system such as 2000, XP, or Windows Server 2003. Harddrive: A minimum of 200 MBs of frees pace, 10 GB recommended

After installing MySQL, a new database was formed. Inside this database we created one table for the values/columns we planned to store. The database values are accessed as strings of characters to compare, by our laptop program. The following figure describes the format of our table.

Figure 19 - MySQL database format Source: Original

The database can be updated via a text file, or by individually adding values to each column. MySQL can store large amounts of data, exceeding 4GB, thus it can be used to store all the necessary information the police requires. Our example database stores two different vehicles information, as shown below:

Figure 20 - Example data Source: Original

4.2.1.2 Visual C++ Laptop Program The laptop program must compare values received on the serial port to values found in our database. This is done in two steps as show below; firstly the program reads the serial port when data is sent, via events, and then it passes this value on to the search function, which compares the string of data received to the values inside the database.

Figure 21 - Laptop program flowchart Source: Original

It was decided to use Visual C++ to implement this program for a Windows application, because of the native Windows structure (including event-driven programming) found in Microsoft Visual C++ 6.0. Initially, the two different steps required, the receive data algorithm, and the search, compare, and popup algorithm were developed as separate programs. The receive data program was tested by sending a string of characters from our readers microcontroller to the laptop via serial connection. The format of the serial data was set as 1 start bit, 8 data bits, 1 stop bit, no parity, no flow control, and a 9600 baud rate, as the diagram shows below. The program successfully displayed the data onscreen.

Figure 22 - RS232 Serial data format Source: http://www.home.aone.net.au/~techedge/vehicle/1600asyn.gif

The search program was tested in the following way: Firstly, we made sure it could connect to the MySQL database. A program was created that displayed the contents of the database in a console window. A program was then developed that searched through the database for a license plate, and displayed the license plate information, along with a stolen message, if the stolen column was set to 1. The two programs were then integrated together as one, described below. The search program becoming a search function inside the receive program.

The receive program was modified to pass the values it received on to the search function as a string array.

The search function then searched for this string array in the license plate column of the database.

If the license plate number was not found, an error message was outputted.

If the license plate number was found, it was compared against the stolen column.

If stolen was equal to one for this license plate, the whole row would be outputted (which included information such as model, colour, owner).

If stolen was not equal to one, the program would read the next incoming license plate, or wait until a license plate is passed on.

4.2.1.3 Reader embedded software The reader is responsible for wirelessly requesting license plate data from the tags, wirelessly receiving this data from the tag, and transmitting this data via serial interface to the laptop program. The reader must operate in this way according to the timing charts in Figure 7. A high-level flowchart of the software operation we implemented to do this is shown below.

.
Figure 23 - Reader Flowchart Source: Original

The send request to tag, and receive request from tag functions must be collaborated between the microcontroller and the transceiver, which both require proper configuration for the reader to successfully send/receive wireless data. The wireless data is sent at a 32 kbps data rate. Assuming a maximum of 50 tags in the vicinity, this means: Each tag will send 8 bytes of data for the license plate number A maximum total of 400 bytes of data will be sent from the tags to the reader while the reader is in receiving mode, assuming no collisions. This will take a maximum of 400/32000 seconds, or 0.0125 seconds Using a baud rate of 9600, the reader will send 400 bytes of data to the laptop in 0.33 seconds. The total allotted time to receive the license plate data from the tags, and send it to the laptop is 0.5 seconds. Assuming a maximum of 50 tags, this will be done in 0.3425 seconds. Before the transceiver can be programmed by the microcontroller, a proper Serial Peripheral Interface Bus (SPI) connection must be set up between the two, to allow for data transmission. In this instance, the microcontroller acts as the SPI master, and the transceiver acts as the SPI slave in order to transmit data from the microcontroller to the transceiver. A diagram showing how SPI slaves and masters are connected is shown below.

Figure 24 - Microcontroller and Transceiver SPI interface Source: http://upload.wikimedia.org/wikipedia/commons/e/ed/SPI_single_slave.svg

After the transceiver and microcontroller are set up for SPI communications, the microcontroller can begin the task of sending or receiving wireless data. The microcontroller must configure the transceiver for the proper mode of operation, and then either send data to the transceivers buffer for transmit mode, or read data from the transceivers buffer receive mode. The figure below shows the Send Request to Tag block from figure 12 in more detail. The data the reader microcontroller sends out in this instance would be requesting the tag microcontrollers to send their license plate data back to the reader.

Figure 25 - Data transmission flowchart Source: Original

In a similar fashion, the Read Response from Tags block requires the microcontroller to configure the transceiver to receive mode. In this case the data that is read from the Receive Buffer is the license plate data. A figure is shown below.

Figure 26 Receiving data flowchart Source: Original

4.2.1.4 Tag Embedded Software The tag software is similar to the reader software, but slightly simpler. The tag is only required to store the license plate data corresponding to the vehicle it is placed on, and send this data to the reader when the reader requests it. The tag must operate in this way according to the timing charts of Figure 7. A high-level flowchart of the software operation we implemented is shown below.

Figure 27 - Tag Software Flowchart Source: Original

As the tag was implemented with the same microcontroller and transceiver as the reader, the microcontroller and transceiver must be configured to run in SPI mode when the microcontroller wants to send or receive data from the transceiver. The same diagram as Figure 13 applies here. Here the Send License Plate Data to Reader block would be implemented in much the same way as Figure 14, the key difference being the data that is being sent. The data that the tag sends is only the license plate number, compared to a request instruction for the reader. The tag receive mode works in the same way the reader receive mode works, except that instead of receiving the license plate number, as the reader does, the tag would receive and process a request command. One problem with our design is that there is no anti-collision system in place. If two tags send their data back at the same time, there is no way the reader can decipher both license plate numbers. An anti-collision algorithm was initially produced to prevent this from happening. Because of time delays, the algorithm was never implemented. More on this algorithm can be found in Section 6.1.

4.2.2 Hardware The hardware changes for the second implementation consisted of replacing the CC1010 microcontroller with build in transceiver, to an Atmel ATmega164V and a Semtech DP1205 drop-in RF transceiver module, which contained the XE1205 transceiver and the proper components needed to run it. A MAX232 was once again used for serial communications between the microcontroller and a PC. The antennas used were as following: a Linx Technologies ANT-433-HE for the tag, and a Linx Technologies ANT-433-CW-HWR for the reader.

4.2.2.1 Circuit and PCB layout Both the tag and reader share some of the same hardware, with the reader having an additional MAX232 IC and a different antenna. Our reader and tag required an ATmega164V microcontroller connected to a DP1205 drop-in transceiver module, in addition to the proper external parts such as crystal oscillators. A Sub Miniature Version a (SMA) antenna connector is needed for both reader and tag antenna. The following circuit schematic was used as the basis for our PCB. It is valid for both the reader and the tag.

Figure 28 - Reader Circuit Diagram Source: Original

The PCB for the circuit diagram above was slightly altered. The MAX232 was not included on the PCB, as our tag has no use for it, and we wanted one PCB for both tag and reader. Thus the MAX232 and its serial connection were placed on a breadboard, connected to the proper ports on the microcontroller via a 20 pin jack. A SMA antenna connector was also added onto the PCB. A diagram of our final PCB submission is shown below.

Figure 29 - PCB Schematic Source: Original

Figure 30 - Tag PCB Source: Original

The PCB was tested in the following way: The multimeter was set to the conductivity mode. If the probes touched, electricity would be conducted from one to the other and a loud beep would be heard Every track was tested by placing one probe at one end, and one probe at the other end of the track. If we heard a beep, it meant the tracks conducted properly. Additional PCB testing was done by testing the microcontroller and transceiver when they were both connected to the PCB. This is outlined in section 4.2.2.3. 4.2.2.2 Microcontroller The microcontroller is the heart and soul of both the tag and the reader. An Atmel ATmega164V was chosen for the second implementation because of a few reasons, described below. The simple hardware setup. Only a crystal, push button, resistor, and a few capacitors were needed. The microcontroller can be placed directly on a breadboard, which can come in handy for testing. A pin out is shown below [7].

Figure 31 - ATmega164 Pin Configuration Source: Atmel ATmega164 Data Sheet

The low power consumption. Only 338 micro amps in active mode, 0.5 micro amps in power-save mode [7].

The microcontroller had USART support for serial communications [7]. Other people in the laboratory were willing to help us initially configure the microcontroller, specifically Bo from Group 4.

Both the tag and reader microcontrollers were tested in the same way, described below. The in-system programmable memory was tested by flashing a simple LED blinker program into the flash memory.

All the I/O ports were also tested in this way by flashing in code to output a data value to the I/O ports, followed by a delay, and then another output. This output data and delay would blink an LED if it was set up to the port being tested. This test was a success.

Pins other than the I/O were tested using a multimeter. Each pin must have a constant voltage value, even when doing nothing. A voltage value of zero meant the pin wasnt working. All pins tested in this way were found to be working.

The crystal oscillator was tested by using an oscilloscope to observe the sin wave voltage.

The USART serial connection was tested by flashing in code to send a data string to a specific I/O port on the microcontroller. This I/O port then connected to the Tx pin of the MAX232 (pin #11). The MAX232 was hooked up to a serial connection, connecting to our laboratory desktop which was running HyperTerminal at the time. HyperTerminal displayed the character string being sent out by the microcontroller. This test was deemed a success

The SPI connection to the transceiver was tested by sending data through the SPI MOSI (Master Output, Slave Input) pin of the microcontroller. A data packet form was observed under the oscilloscope.

4.2.2.3 Transceiver The transceiver chosen for our project was the DP1205 Drop-In RF Module. It consists of a surface mount module that contains the XE1205 transceiver plus its external components. We chose this microcontroller because of the following reasons: It was very easy to install on the PCB. All the external components were already built onto the module. All we had to do was dropping it in and connect the pins [8].

It supported data rates of up to 152.3 kilobits/s [8]. More than enough for our application.

The output power, and thus the range, was programmable up to 15 DBm [8].

It supported a SPI interface, something that was required if we wanted it to communicate with the microcontroller [8]. A block/pin diagram of how it connects to the master (our microcontroller) is shown below.

Figure 32 - SPI interface between the microcontroller and the XE1205 transceiver Source: DP1205 datasheet

We attempted to test the XE1205 transceiver in the following way: We placed the microcontroller in SPI mode. We observed data being sent from the Master (microcontroller) to the slave (transceiver) on the oscilloscope. We sent data to configure the SPI CONFIG block. This has the task of waking up the transmitter, and placing it into transmit or receive mode.

We attempted to transmit a character string by sending data to the SPI DATA buffer. We used a spectrum analyzer to see if any data was being wirelessly sent. We did not observe any data.

At the time of this writing, we are still testing and reworking the transceiver to transmit and receive data. We expect to have it working on Tuesday, July 24. This will give us one day to implement the transmit/ receive block of the RFID reader and tag. 4.2.2.4 Antennas Two different antennas were chosen for the tag and reader respectively. The Linx Technologies ANT-433-HETH helix antenna was chosen for the tag over a whip antenna because of the following reasons: The helix antenna was much smaller than a whip antenna, 1.5 inches in length vs. 5.0+ inches. An antenna of this size is required to make the tag as small as possible, so that it may be placed behind or beside a license plate. The helix antenna could be placed parallel to the tag. This saves even more space on the tag. The antenna is extremely cheap compared to a whip antenna. Our antenna was 88 cents, versus 10 dollars for a whip antenna operating in the same range. The Linx ANT-433-CW-HWR-SMA quarter whip antenna was chosen to be placed on the police reader. This is because of the following: The antenna can be mounted to any standard SMA connector. A quarter whip antenna has better performance over a helix antenna. We need the police reader to pick up multiple cars in a large radius; therefore performance was a bigger issue than price when it came to the reader. We want the police reader to scan in a wide 70m radius. The antenna is omni-directional and adheres to the requirements.

What follows are test results of both antennas. The results are divided into theoretical results and practical results. 4.2.2.4.1 Theoretical Antenna Results The characteristics of the transceiver for both the reader and tag are: Max. output transmitting power = 15 dBm Receiver sensitivity (min. receive power) = -121 dBm

After talking with Professor Michelson, he informed us that -107 dBm is a very good sensitivity and perhaps too optimistic. Therefore, the following calculations will have a sensitivity of +20 dBm, i.e. -87 dBm

Table X1 Power Characteristics of Transceiver Power (dBm) Maximum Transmitting Power (Pt) Minimum Receive Power (Pr) 15 -121 Power (W) 10E-3 1.995E-12

Path Loss Calculations:

Lp = 4 r

Our RFID system uses the frequency of 433 MHz:

c = 0.69284 metres f

Then leaving our range as a variable r:

Lp =

3.03981E 3 r2

Then to calculate the received power:

Pr = Pt Gt Gr L p

For both the reader and tag antenna, we take the assumption of perfect isotropic radiators and hence the gains of both antennas are 0 dBi. Then converting from dBi gives:

Pr = Pt L p

Lp =

Pr Pt

3.03981E 3 Pr = Pt r2

Using the max. and min. values of Pt and Pr we obtain an exaggerated range under ideal conditions: r = 3.9 km

Another datasheet with similar transceiver characteristics does corroborate this result, which also had a range in the kilometres. Below is a plot of the transceivers range over different minimum receiving powers, in case the transceivers sensitivity:

Figure 33 - Range over Receiver Sensitivities Source: Original

The Output Power of our transceiver is able to be programmed in multiples of 5 dBm from -15 dBm to +15 dBm [9]. Below is a graph of the range of the RFID system with varied output power keeping a receiver sensitivity of -87 dBm.

Figure 34 - Range Over Varied Output Power Source: Original

From the graphs above we see that there is plenty room to vary the range of our system to the desired 70 meter distance. However it is important to note that the distances shown on the graphs are once again for ideal conditions. There are many sources of signal power loss in practice. A significant amount of transmitting power will be lost from the reflections coming off the cars on the streets because of their metallic surface. In addition, the ground itself will also be a major source of loss. As shown in the figure below, the tag is very close to the ground which would probably result in a signal taking two paths. One path goes directly to the reader (blue). The second path reflects off the ground, causing a potential 180 degree phase shift, which could cancel with the incoming signal (red). This could result in as much half of the power lost. A figure is shown below.

Figure 35 - Signal Cancellation through 180 degree phase shift Source: Original

Furthermore, high speeds and rain could also cause a reduction in range. Because both the reader and tag are external to the vehicles, the circuitry has been encased in a hard plastic waterproof compartment.
4.2.2.4.2 Actual Antenna Results

With our antennas we did testing with a VSG (Vector Signal Generator) and a spectrum analyzer courtesy of Dr. Michelson. This was during the early stages of our project when we were still unsure of the characteristics of our antennas. Our testing involves connecting our transmitting antenna to a VSG and reading the power level of the transmitting signal and connecting our receiving antenna to a spectrum analyzer and reading the strength of the received signal. We did this several times varying the distance between the transmitting and the receiving antenna. According to Dr. Michelson the absolute minimum signal power level the receiving antenna can pick up due to the microcontroller we were using was -107DBm. This means that any signal under that level would not be picked up. As the distance between the receiving and transmitting antennas increased the signal power level received by the receiving antennas would decrease. Dr. Michelson suggested in order getting reliable data we should add 20 dBm to this absolute minimum reading level thus having an absolute minimum of 87 dBm.

We used two testing methods. One method involved no cars, where the VSG was connected to the transmitting antenna and the Spectrum Analyzer was connected to the receiving antenna. The other method had the transmitting antenna mounted to the roof of a car with the VSG connected while the receiving antenna was connected to the license plate of another car with the Spectrum analyzer connected. We initially thought that our antenna was directional, but with initial testing we discovered our antenna was in fact Omni directional. This is because the data we read when reading the power of the received signal while varying the distance between the two antennas had a similar characteristic. This can be seen by the following graphs.

Figure 36 - Antenna testing system Source: Original

Figure 37 - Received Power vs. Distance Forward Measures Source: Original

Figure 38 - Received Power vs. Distance Reverse Measures Source: Original

We suspected the antennas would behave differently if there were obstructions between the transmitting and receiving antennas. Therefore we did the same tests with 2 cars in between the transmitting and receiving antenna at which point we realized that having obstructions between the transmitting and receiving antennas had no effect on the behaviour. This can be seen from the following graph.

Figure 39 - Received Power vs. Distance No Obstructions, Mounted Source: Original

Dr. Michelson suggested that a potential reason for this lack of effect on the behaviour of the antenna when there are obstructions is because we are using a low frequency of 433 MHz. Signals with frequencies this low has a tendency to weave around obstructions therefore the 2 cars serving as obstruction between the transmitter and receiver had little effect on the behaviour of the antenna. In addition to placing the receiving antenna in front and behind the transmitting

antenna and having obstructions between the two antennas we also did testing of the following: Multitone no mounted no cars in between, no mounted no obstructions. We also tested in a parking lot varying the distances between the two antennas. Here are the following plots:

Figure 40 - Received Power vs. Distance Non Mounted, No Cars In Between Source: Original

Figure 41 - Received Power vs. Distance - Non Mounted, no Obstructions Source: Original

Figure 42 Received Power vs Frequency Parking Lot, Car 1 Source: Original

Figure 43 - Received Power vs Frequency - Parking Lot, Car 2 Source: Original

Figure 44 - Received Power vs Frequency - Parking Lot, Car 3 Source: Original

4.2.2.5 Tag and Reader Placement

The tag is placed on the rear license plate of the car as shown below. Our prototype is not thin enough to be placed directly behind the license plate, so it will have to be placed slightly above or below the license plate. A figure is shown below.

Figure 45 - Tag Placement Source: Original

The reader is placed on top of the police car next to the sirens. This will ensure the reader receive signals from all directions, which was an original requirement. The

reader can be either battery powered or connected to the police cars power system, which is preferable. A figure is shown below.

Figure 46 - Reader Placement Source: Original

4.2.2.6 Power Calculations

We require our tag to last at least 10 years. The following calculations were made assuming a tag gets read 5 times a day.

5 Assessment and Analysis

In this section well talk about the microcontroller we used when trying to implement the hardware portion of our project and the obstacles we bumped into using the CC1010 microcontroller. Also well talk about how well our project can scale in the real world.

5.1 Success and Shortcomings

Our original plan was to use a CC1010 microcontroller to implement our tags and our readers. We picked this microcontroller because it had a built in transceiver which made the hardware side of implementation a lot simpler because we wouldnt have to purchase a microcontroller and transceiver separately and connect them together. However this microcontroller required a development board that was almost twice our budget and could not be placed on a breadboard as we initially expected it would like a traditional microcontroller. We started making a PCB which we would use to mount our microcontroller on after consulting with Peter Vatour who suggested we make a PCB for our microcontroller, as the time it takes to make one would be the same as ordering and shipping another microcontroller. Upon completing the PCB for our microcontroller, due to our inexperience with making PCBs our submission was rejected. This was already our second PCB submission as we did not choose our parts in time for our first submission. Faced with a microcontroller that could not be mounted on a breadboard and without a PCB we chose to purchase our own PCB. We initially thought our microcontrollers program would be flashed serially, but we eventually realized the CC1010 microcontroller needed a parallel port to flash a program in. Upon realizing this we started creating a new PCB with a parallel port in time for our third submission and purchased parallel port chips which after consulting Tom we agreed should work. After we received our 3rd PCB, we found out we still couldnt flash a program in a program even with the parallel port and parallel port chips. Upon consulting with Tom he agreed that everything was set up the way it was supposed to and he speculated we still couldnt flash any programs because we might have accidentally fried our microcontrollers due to

static or some other unknown cause at which point we switched to an ATMEGA 164P microcontroller. The ATMEGA 164P microcontroller proved to be far more simple and straightforward to setup and use. The hardware implementation proved to be more difficult because unlike the CC1010 which had a built in transceiver, for the ATMEGA 164P we had to purchase separate transceivers and connect them appropriately. However, considering the ATMEGA 164P only required a breadboard to mount on (like traditional microcontrollers weve had experience with prior to this course) we immediately found ourselves making progress. The ATMEGA 164P turned out to be a good decision because while the CC1010 did not require us to connect transceivers and parallel chips, such connections were relatively straightforward. The example code in the ATMEGA 164P was far easier to understand and implement than the example code for the CC1010 and we made more progress when we switched microcontrollers in the small amount of time that we had.

5.2 Feasibility Study

According to our interview with various PR police officers, as of right now, in every police cruiser there is a laptop where the police officers can enter license plates into and get information on a particular car from a central database. Assuming the police use a GSM cellular band to communicate between their laptop and their central database, a band which sends and receives data at a rate of 114kbits, and assuming there are 200 police cars at any given time, each police cruiser can send and receive the following amount of info in 1 second: (114000bits/second)/8 = (14250 bytes/second)/200 = 71.25bytes/second We are assuming sending a request for the license plate information (license plate number, owner, fines, and stolen flag) will require 100 bytes. Thus it is unacceptable that each police cruiser can only send and receive 71.25 bytes in one second. If this is the case, we recommend upgrading to another band or reducing the number of police cars to a lower number.

5.3 Scalability
When our RFID license plate system is implemented on every motor vehicle in BC, every registered vehicle will have a RFID chip underneath their regular license plate. All the police vehicles will be equipped with the RFID chip readers which can pick up RFID data that contains license plate numbers from the RFID chips. The RFID chips installed on license plates will only contain and transmit the license plate numbers to the readers. This prevents private information to be stolen while inside the RFID chip memory or while the data is being transmitted. The police reader will pick up all the license plate numbers in range and transmit the data onto the laptop. Each license plate number will be checked with database to determine if it is stolen or suspicious. The database will be accessed wirelessly and synchronized with crime and stolen property reports in real-time. Since there may be a lot of database query requests with a large number of police cars patrolling the streets; in order to prevent system delays, there can be a database cached in the laptops so it can be accessed from local hard drive to reduce load on the wireless network. In the future, there will be Receive Signal Strength Indicator (RSSI) to show the police officers how far away the flagged vehicle is. The police RFID readers should have a 100 meter forward range, with the aid of RSSI; the police can clearly identify the vehicle that was flagged by the system. In any engineering project, we must consider how easy our product can be produced in real life and how successfully our product can handle certain requirements when used in industry. More often than not, these requirements may differ slightly than the requirements imposed on it when it was still a prototype during the testing phase of our project. Our project consists of a RFID reader prototype that is meant to be placed on a police cruiser that can receive signals from a RFID tag placed on the license plate of a car. The reader then takes the information, namely the license plate number and compares it to a database that contains the license plates of cars that are flagged if they are stolen. Our prototype system can successfully receive the information transmitted by a single tag and send this data serially to a database we created. This database simulates the interface a police officer would see when he is in the police cruiser as accurately as we can make it based on the interviews weve had with several police officers.

One can immediately see the scalability issue with our project, we successfully implemented a system where there is communication between one reader and one tag, but our system was originally meant to function in a situation where communication between several tags and several readers are possible. This is due to the fact that on the road there may be several police cruisers in the same area (several readers) while there is bound to be substantially greater number of cars (tags) than police cruisers. We came up with algorithm that handles anti-collision between several readers and several tags, but were unable to implement them due to problems weve had using our original microcontroller and having to switch to a new microcontroller. Despite the fact that our current prototype only has communication between one reader and one tag given our anticollision algorithm was successfully implemented, a system where several tags communicate with several readers is feasible. Our original algorithm consisted of a reader sending a request signal to all tags in range. This request signal must be sent to all tags under 0.5 seconds which acts as a wake up call to all other tags in vicinity to start sending their data. This request signal serving as a wakeup call in actuality is the readers identification number. The reader then processes all the data it received from the tags and sends them to a computer which takes at most 1 second. The reader then sends a confirmation signal to the tags it has just received data from, which will serve as a shutdown signal to the tag telling it to stop transmitting data to the same reader for the time being. A
Figure 47 - Reader Flow Chart Source: Original

flow chart for the above mentioned algorithm can be seen in the following.

Our tags must send their data in a special manner in order to avoid collision where several tags send data to a reader at the exact same time. First and foremost, we planned to implement a system where each reader will have its own individual delay when transmitting its license plate to a reader. Our tags start out by waiting for a request from a reader. This request as was previously mentioned is the readers identification which will be stored in the tag. If the tag has received confirmation from that reader before, this means that this tag as already sent the reader its information and instead of transmitting its information itll simply wait for requests from other readers. In the event the tag does not have the readers identification number stored, this means that prior to this instance, this reader has never sent a request signal to this tag, this is the first time a request signal as been received from this reader and that means this tag has never sent its information to this reader. The tag will then start sending its information to the reader. As was previously mentioned, each tag sends data to each reader at a time delay. Despite of the fact that each tag sends their data to a reader at a unique delayed time, collision between two tags can still occur, albeit being more improbable. This is because depending on the location of the tag when the request signal was sent out, even with its unique time delay, the time at which a tag receives a request signal can cause it to send its data at the exact same time another tag is sending its signal resulting in a collision where both data are lost. Thus we
Figure 48 - Tag Flow Chart Source: Original

require our tags to send its data several times, each time the tags will check if it has received a confirmation from the

reader in which case it stops transmitting its data. We require our tags to send their data to the reader at most 3 times for the unlikely scenario the tag never receives a confirmation from that reader. To recap, our tag first waits for a request for a reader. Upon receiving a request the tag checks if the readers identification number is already stored. If already stored it goes back to waiting for other requests if not it sends its data at most 3 times each time checking for a confirmation. A flow chart of this algorithm can be seen in the following. Given our anti-collision algorithm was implemented the way we envisioned it; our project has the potential to be very scalable. When trying to mass produce our product we must work hand in hand with the Canadian government because they are ultimately the ones that deem there is a need for a tag in every license plate in Canada and thus are the ones to pass new laws regarding this new system. We must also work with ICBC because they are the ones that deal with vehicle registration and license plates. We must also work with the police department when they install license plate readers in every police cruiser. When mass producing our license plate tags we will require an ATMEGA164PV-10PU-ND microcontroller with a mass produce price of 3.6371 dollars CAD on digikey, and an ANT-433-HETH antenna with a mass produce price of 0.549 dollars CAD. When mass producing our license plate reader we will need a CONSMA001-SMD connector with a mass produced price of 3.6671 dollars CAD and an ATMEGA164PV-10PU-ND microcontroller with a mass produce price of 3.6371 dollars CAD.
Table 3 - Total Budget of both Atmel and CC1010 Source: Original Description MC Antenna Crystal Crystal Capacitor Capacitor Part Name CC1010PAGR ANT-433-CW-HWR-SMA CFS308-32.768KDZF-UB 405C35B14M74560 CC0603JRNP09BN100 CC0603JRNP09BN180 Q 5 1 7 7 10 10 Price 12.32 11.53 0.32 2.23 0.066 0.066 Total 61.6 11.53 2.24 15.61 0.66 0.66 TOTAL 622.09

Capacitor Capacitor Capacitor Capacitor Capacitor Inductor Inductor inductor inductor Resistor Battery socket Transceivers Microcontroller Microcontroller RF Antennas PCB

C0603C0G1H6R8D GRM1885C1H8R2DZ01D CC0603JRNP09BN151 MCH185A6R8DK C1608C0G1H120J PM0805-68NK-RC ELJ-ND27NKF ELJ-ND15NKF LQW18AN6N2D00D RT0603DRD0782KL TL-5104/S 1-535541-8 SN74LVC245AN ATMEGA164PV-10PU ATMEGA64RZAV-10PU ANT-433-CW-HD APC

10 10 50 10 10 6 6 10 6 10 6 8 2 1 1 1 1 1 1 1 1 4 6

0.059 0.08 0.098 0.065 0.058 0.46 0.4 0.326 0.45 0.267 6.29 2.55 0.69 5.98 8.76 6.35 91.17

0.59 0.8 4.9 0.65 0.58 2.76 2.4 3.26 2.7 2.67 37.74 20.4 1.38 5.98 8.76 6.35 91.17

ANTENNA ANTENNA
CONNECTOR D-S&PCB PCB Atmel Header Socket Voltage Regulator Antenna Transceivers Microcontroller Microcontroller

ANT-433-HETH ANT-433-SP
CONSMA001-SMD Annie's order APC

1.02 2.4
5.14 16.92

1.02
2.4 5.14 16.92 103.76

0.8 3.5 1.01 40.03 5.51 12.19

4.8 7 4.04 120.09 11.02 12.19

LM158CT ANT-433-HETH-ND DP1204C433LFCT-ND ATMEGA164PV-10PUND CC1010PAGR

2 4 3 2 1

Switch Diode Crystals Push Buttons

LM158CT

2 3 3 6

3.5 2.67 2.67 1.33

7 8 8 8 8 9.32

0.1 inch pin sockets digikey shipping July 17 Johnny's digikey tax July 17

Table 4 - Total Atmel Components Source: Original Description Crystal Battery PCB Atmel Connector 4MHz TL-5104/S APC CONSMA001-SMD ANT-433-CW-HWRAntenna Transceiver SMA DP1204C433LFCT-ND ATMEGA164PV-10PUMicrocontroller Inductor socket Microcontroller RF-Antenna Antenna Antenna ND 82nf 1-535541-8 ATMEGA64RZAV-10PU ANT-433-CW-HD ANT-433-HETH ANT-433-SP 1 1 8 1 1 1 1 5.98 0.66 2.55 8.76 6.35 1.02 2.4 5.98 0.66 20.4 8.76 6.35 1.02 2.4 1 3 11.53 40.03 11.53 120.09 Part Name Q 1 6 4 1 Price 0.4 6.29 91.7 5.14 Total 0.4 37.74 103.76 5.14

Header Socket Voltage Regulator Antenna LM158CT ANT-433-ND ATMEGA164PV-10PUMicrocontroller Switch Diode ND LM158CT ATMEGA164PV-10PUMicrocontroller ND

0.8

4.8

2 4

3.5 1.01

7 4.04

2 2

5.51 3.5

11.02 7

2 Total

5.51

11.68667 369.7767

6 Sources
[1] Gobel, Greg. The British Invention Of Radar January 1, 2007.Vectorsite. June 20, 2007. <http://www.vectorsite.net/ttwiz_01.html> [2] Octopus Card. Octopus Consumers About Us 2005. Octopus Card. June 20, 2007 <http://www.octopuscards.com/consumer/general/global/en/aboutus.jsp> [3] NDI Technologies. Veriplate ALPR Automatic License Plate Recognition 2007. NDI Technologies. July 22, 2007. <http://www.nditech.net/us/homelandsecurity/alpr/> [4] Chow, Howard. Personal Interview. July 19, 2007. [5] e-Plate. Welcome to e-Plate e-Plate. June 20, 2007. <http://www.eplate.com/index.html> [6] MySQL AB. The worlds most popular open-source database. 2007 MySQL AB. July 20, 2007. <http://www.mysql.com/> [7] Atmel. 8-bit microcontroller with 12/32/64 kilobytes in-system programmable flash. ATmega166P/V April 2007. Atmel Datasheet. July 17, 2007. <http://www.avrfreaks.net/index.php?module=Freaks%20Devices&func=displayDev&ob jectid=99> [8] Semtech. DP1205 C433/868/915 433, 868 and 915 MHz Drop-In RF Transceiver Modules 2006. Semtech Datasheet. July 23, 2007 <http://www.semtech.com/pc/downloadDocument.do?navId=H0,C1,C193,C194,P3163& id=1796> [9] Semtech XE1205 2006. Semtech Datasheet. July 23, 2007. <http://www.semtech.com/pc/downloadDocument.do?id=769> [10] TI CC1010 Software. <http://focus.ti.com/docs/prod/folders/print/cc1010.html>

Appendix A Received Power vs. Frequency

For Different Test Cases

Below are a series of MATLAB plots from the antenna testing. These plots give a comparison between different conditions at 15m and 45m.

8 Appendix B Software Utilized in cc1010

8.1 Serial Communication
#include <chipcon/hal.h> #include <chipcon/cc1010eb.h> #include <stdio.h> #include <string.h> //Define ASCII codes / terminal commands #define ASCII_LF 0x0A #define ASCII_CR 0x0D #define ASCII_NUL 0x00 #define ASCII_ESC 0x1B byte xdata LicensePlate; void main() { //Turn off watchdog //(otherwise the CC1010 will reset after a predefined time) WDT_ENABLE(FALSE); // Set optimum settings for speed and low power consumption MEM_NO_WAIT_STATES(); FLASH_SET_POWER_MODE(FLASH_STANDBY_BETWEEN_READS); //Setup UART0 with polled I/O or interrupt UART0_SETUP(57600, CC1010EB_CLKFREQ, UART_NO_PARITY | UART_RX_TX |UART_ISR); INT_ENABLE(INUM_UART0, INT_ON); INT_PRIORITY(INUM_UART0, INT_HIGH);

// Turn on interrupts INT_GLOBAL_ENABLE(INT_ON); //Clear screen printf("%c[2J", ASCII_ESC); //Place cursor at upper left corner printf("%c[H", ASCII_ESC); while(1); } // ISR (interrupt service routine) for uart0 void isr_uart0() interrupt INUM_UART0 { byte received_byte; if (INT_GETFLAG(INUM_UART0_RX) == INT_SET) { received_byte = UART0_RECEIVE(); //read receive buffer INT_SETFLAG(INUM_UART0_RX, INT_CLR); // clear int UART0_SEND(received_byte); // echo received character //Display licenseplate printf("License Plate Number Recieved:", received_byte); } else if (INT_GETFLAG(INUM_UART0_TX) == INT_SET) { UART0_SEND(LicensePlate); //send license plate number INT_SETFLAG(INUM_UART0_TX, INT_CLR); // clear int //Display license plate printf("License Plate Number:", LicensePlate); } } //end isr_uart0 [10]

8.2 Transmitter Code

#include <chipcon/reg1010.h> #include <chipcon/cc1010eb.h> #include <chipcon/hal.h> #define TEST_STRING_LENGTH 10 #define numPreambles void main() { int i = 0; byte testStrings[TEST_STRING_LENGTH]; byte* packetData; 2

#ifdef FREQ433

RF_RXTXPAIR_SETTINGS code RF_SETTINGS = { //0x4B, 0x2F, 0x0E, 0x43, 0x2F, 0x0E, 0x58, 0x00, 0x00, 0x41, 0xFC, 0x9C, 0x02, 0x80, 0x60, 0x48, 0x44, 0x81, 0x0A, 0xFF, // Modem 0, 1 and 2: Manchester // Modem 0, 1 and 2: NRZ // Freq A // Freq B

// FSEP 1 and 0 // PLL_RX // PLL_TX // CURRENT_RX // CURRENT_TX // FREND // PA_POW

//0x40, 0xC0, 0x00, }; #endif // Calibration data

// PA_POW => 0 dBm // MATCH // PRESCALER

RF_RXTXPAIR_CALDATA xdata RF_CALDATA; WDT_ENABLE(FALSE); // Set optimum settings for speed and low power consumption MEM_NO_WAIT_STATES(); FLASH_SET_POWER_MODE(FLASH_STANDBY_BETWEEN_READS); halRFCalib(&RF_SETTINGS, &RF_CALDATA); // Fill up reference string for(i = 0; i < TEST_STRING_LENGTH; i++){ testStrings[i]=i; } packetData= &testStrings[0]; halRFSetRxTxOff(RF_TX, &RF_SETTINGS, &RF_CALDATA); halRFSendPacket(numPreambles, packetData, TEST_STRING_LENGTH); }[10]

8.3 Receive Code

#include <chipcon/reg1010.h> #include <chipcon/cc1010eb.h> #include <chipcon/hal.h> #include <stdio.h> #define RF_RX_BUF_SIZE 50

#define TEST_STRING_LENGTH 10 //Define ASCII codes / terminal commands #define ASCII_LF 0x0A #define ASCII_CR 0x0D #define ASCII_NUL 0x00 #define ASCII_ESC 0x1B // Define RSSI limit for response #define RSSI_LIM -75 // Define monitor timeouts #define RSSI_MONITOR_TIMEOUT 0x0110 #define MAIN_MONITOR_TIMEOUT 0x00FF void RFSetupReceive(void); int main_monitor = 0; int rssi_monitor = 0; char rssi_val; int i = 0; byte rf_rx_buf[RF_RX_BUF_SIZE]; byte rf_rx_index = 0;

byte rf_rx_display = FALSE;

void main() { #ifdef FREQ433

RF_RXTXPAIR_SETTINGS code RF_SETTINGS = { 0x4B, 0x2F, 0x0E, 0x58, 0x00, 0x00, 0x41, 0xFC, 0x9C, 0x02, 0x80, 0x60, 0x48, 0x44, 0x81, 0x0A, 0xFF, 0xC0, 0x00, }; #endif // Calibration data RF_RXTXPAIR_CALDATA xdata RF_CALDATA; // Disable watchdog timer WDT_ENABLE(FALSE); // Set optimum settings for speed and low power consumption MEM_NO_WAIT_STATES(); // Modem 0, 1 and 2 // Freq A // Freq B

// FSEP 1 and 0 // PLL_RX // PLL_TX // CURRENT_RX // CURRENT_TX // FREND // PA_POW // MATCH // PRESCALER

FLASH_SET_POWER_MODE(FLASH_STANDBY_BETWEEN_READS); // Calibrate halRFCalib(&RF_SETTINGS, &RF_CALDATA); // Turn on RF for RX halRFSetRxTxOff(RF_RX, &RF_SETTINGS, &RF_CALDATA); // Initialise RSSI reading halRFReadRSSIlevel(RSSI_MODE_INIT); // Setup UART0 with polled I/O UART0_SETUP(57600, CC1010EB_CLKFREQ, UART_NO_PARITY | UART_RX_TX | UART_POLLED); // Setup RF receive RFSetupReceive(); // Reset main loop monitor main_monitor = MAIN_MONITOR_TIMEOUT; // Reset RSSI monitor rssi_monitor = RSSI_MONITOR_TIMEOUT; // Clear screen printf("%c[2J", ASCII_ESC); // Place cursor at upper left corner printf("%c[H", ASCII_ESC); // Display RF packet data + RSSI level: while (TRUE) { // Display RSSI level info: if((rssi_val = halRFReadRSSIlevel(RSSI_MODE_RUN)) > RSSI_LIM){ printf("RSSI = %4d dBm, Packet error count = %d\n", (int)rssi_val, packet_error_cnt); } else { if (rssi_monitor-- < 0x0000) {

printf("RSSI = %4d dBm, Packet error count = %d\n", (int)rssi_val, packet_error_cnt); rssi_monitor = RSSI_MONITOR_TIMEOUT; } } // Detect RF packet error and display RF packet data: if(rf_rx_display == TRUE){ rf_rx_display = FALSE; for(i = 2; i < TEST_STRING_LENGTH+2; i++){ printf("RXD%d=%d ", i-2, (int)rf_rx_buf[i]); } printf("\n"); }else{ } // Indicate main loop is running ok: if (main_monitor-- < 0x0000) { main_monitor = MAIN_MONITOR_TIMEOUT; } } }

// RF interrupt service rotine: void RF_ISR (void) interrupt INUM_RF { INT_ENABLE(INUM_RF, INT_OFF); INT_SETFLAG (INUM_RF, INT_CLR); // Get RF receive data rf_rx_buf[rf_rx_index] = RF_RECEIVE_BYTE(); // Verify packet contents:

switch(rf_rx_index){ case 0: //synchronous byte RF_LOCK_AVERAGE_FILTER(TRUE); rf_rx_index++; break; case 1: //length of string (10 bytes) rf_rx_index++; break; case TEST_STRING_LENGTH+3: //data packet received rf_rx_index = 0; rf_rx_display = TRUE; PDET &= ~0x80; PDET |= 0x80; break;

default: //for receving data bytes rf_rx_index++; break; } INT_ENABLE(INUM_RF, INT_ON); return; } // Setup RF for RX void RFSetupReceive (void) { // Disable global interrupt INT_GLOBAL_ENABLE (INT_OFF); // Setup RF interrupt

INT_SETFLAG (INUM_RF, INT_CLR); INT_PRIORITY (INUM_RF, INT_HIGH); INT_ENABLE (INUM_RF, INT_ON); // Enable RF interrupt based on bytemode RF_SET_BYTEMODE(); // Setup preamble configuration RF_SET_PREAMBLE_COUNT(16); RF_SET_SYNC_BYTE(RF_SUITABLE_SYNC_BYTE); // Make sure avg filter is free-running + 22 baud settling time MODEM1=(MODEM1&0x03)|0x24; // Reset preamble detection PDET &= ~0x80; PDET |= 0x80; // Start RX RF_START_RX(); // Enable global interrupt INT_GLOBAL_ENABLE (INT_ON); } [10]

Appendix C CC1010 Budget

Table 5 - Total Budget of the cc1010 Part Name Quantity CC1010PAGR ANT-433-CW-HWR-SMA CFS308-32.768KDZF-UB 405C35B14M74560 CC0603JRNP09BN100 CC0603JRNP09BN180 C0603C0G1H6R8D GRM1885C1H8R2DZ01D CC0603JRNP09BN151 MCH185A6R8DK C1608C0G1H120J PM0805-68NK-RC ELJ-ND27NKF ELJ-ND15NKF LQW18AN6N2D00D RT0603DRD0782KL TL-5104/S 1-535541-8 SN74LVC245AN ATMEGA164PV-10PU ATMEGA64RZAV-10PU ANT-433-CW-HD APC 5 1 7 7 10 10 10 10 50 10 10 6 6 10 6 10 6 8 2 1 1 1 1

Below are budgets for the cc1010 as discussed in section 4.1.6.

Description MC Antenna Crystal Crystal Capacitor Capacitor Capacitor Capacitor Capacitor Capacitor Capacitor Inductor Inductor inductor inductor Resistor Battery socket Transceivers Microcontroller Microcontroller RF Antennas PCB

Price $ 12.32 $ 11.53 $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ 0.32 2.23 0.07 0.07 0.06 0.08 0.10 0.07 0.06 0.46 0.40 0.33 0.45 0.27 6.29 2.55 0.69 5.98 8.76 6.35 $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $

Total 61.60 11.53 2.24 15.61 0.66 0.66 0.59 0.80 4.90 0.65 0.58 2.76 2.40 3.26 2.70 2.67 37.74 20.40 1.38 5.98 8.76 6.35 91.17

$ 91.17

ANTENNA ANTENNA
CONNECTOR

ANT-433-HETH ANT-433-SP
CONSMA001-SMD

1 1 1

$ 1.02 $ 2.40
$ 5.14

$
$ $

1.02
2.40 5.14

Total

293.95

Table 6 Actual per unit Cost of Tag Description MC ANTENNA Crystal Crystal Capacitor Capacitor Capacitor Capacitor Capacitor Capacitor Capacitor Inductor Inductor inductor inductor Part Name CC1010PAGR ANT-433-HETH CFS308-32.768KDZF-UB 405C35B14M74560 CC0603JRNP09BN100 CC0603JRNP09BN180 C0603C0G1H6R8D GRM1885C1H8R2DZ01D CC0603JRNP09BN151 MCH185A6R8DK C1608C0G1H120J PM0805-68NK-RC ELJ-ND27NKF ELJ-ND15NKF LQW18AN6N2D00D Quantity 1 1 1 1 1 2 3 1 7 2 2 1 1 1 1 Price $ 12.32 $ $ $ $ $ $ $ $ $ $ $ $ $ $ 1.02 0.32 2.23 0.07 0.07 0.06 0.08 0.10 0.07 0.06 0.46 0.40 0.33 0.45 Total $ 12.32 $ $ $ $ $ $ $ $ $ $ $ $ $ $ 1.02 0.32 2.23 0.07 0.13 0.18 0.08 0.69 0.13 0.12 0.46 0.40 0.33 0.45

Resistor Battery socket CONNECTOR PCB

RT0603DRD0782KL TL-5104/S 1-535541-8 CONSMA001-SMD UBC

1 1 2 1 1

$ $ $ $ $

0.27 1.05 2.55 5.14 6.50

$ $ $ $ $

0.27 1.05 5.10 5.14 6.50

Total Cost

$ 36.97

Description MC Antenna Crystal Crystal Capacitor Capacitor Capacitor Capacitor Capacitor Capacitor Capacitor Inductor Inductor

Table 7 - Actual per unit Cost of Reader Part Name Quantity Price CC1010PAGR ANT-433-CW-HWR-SMA CFS308-32.768KDZF-UB 405C35B14M74560 CC0603JRNP09BN100 CC0603JRNP09BN180 C0603C0G1H6R8D GRM1885C1H8R2DZ01D CC0603JRNP09BN151 MCH185A6R8DK C1608C0G1H120J PM0805-68NK-RC ELJ-ND27NKF 1 1 1 1 1 2 3 1 7 2 2 1 1 $ 12.32 $ 11.53 $ $ $ $ $ $ $ $ $ $ $ 0.32 2.23 0.07 0.07 0.06 0.08 0.10 0.07 0.06 0.46 0.40

Total $ 12.32 $ 11.53 $ $ $ $ $ $ $ $ $ $ $ 0.32 2.23 0.07 0.13 0.18 0.08 0.69 0.13 0.12 0.46 0.40

inductor inductor Resistor Battery socket CONNECTOR PCB

ELJ-ND15NKF LQW18AN6N2D00D RT0603DRD0782KL TL-5104/S 1-535541-8 CONSMA001-SMD UBC

1 1 1 1 2 1 1

$ $ $ $ $ $ $

0.33 0.45 0.27 1.05 2.55 5.14 6.50

$ $ $ $ $ $ $

0.33 0.45 0.27 1.05 5.10 5.14 6.50

Total Cost

$ 47.48