Power Supply Unit Design, Encoder Design - Project | ECE 445, Study Guides, Projects, Research of Electrical and Electronics Engineering

Download Power Supply Unit Design, Encoder Design - Project | ECE 445 and more Study Guides, Projects, Research Electrical and Electronics Engineering in PDF only on Docsity!

DESIGN OF A RFID GROCERY CART SCANNER

By Oliver Yang Andrew Friedl ECE 445, SENIOR DESIGN PROJECT Summer 2006 TA: Alex Spektor 29 July 2006 Project No. 7

ABSTRACT

We designed and built a system that attaches to a shopping cart and uses RFID tags to identify products. It then outputs their description to an attached LCD screen. Additionally, it is capable of outputting the item’s cost, the sum of the item’s costs (before and after tax) and a complete list of all items currently in the cart. The system is powered by 4 batteries and includes a switch that turns off the circuit when the cart is placed into a “base station.” At the heart of our design is a PIC16F877 microcontroller (“the PIC”). It polls the RFID reader module for a list of all the tags in range of its external antenna. The list of tags (“the inventory”) is sent back to the PIC, which matches and processes the inventory. Additionally, the PIC processes data from the keypad and is responsible for sending the output to the LCD screen. ii

APPENDIX C – TEST DATA.............................................................................................A.

APPENDIX D – PICTURES................................................................................................A.

APPENDIX E – PARTS AND COST................................................................................A.

iv

1. INTRODUCTION....................................................................................................................

We designed and built a system that reads the RFID tags of products placed in a shopping cart. The system uses a PIC16F877 microcontroller (“the PIC”) to continuously poll a RFID reader module (“the reader”) for a list of all the tags in range of its external antenna. The list of tags (“the inventory”) is sent back to the PIC, which matches and processes the inventory. Then the PIC displays the items on a LCD screen, and the information displayed can be controlled using a keypad. The system is powered by 4 batteries and includes a switch that turns off the circuit when the cart is placed into a “base station.” Our system provides the consumer and the retailer with the benefit of a rapid checkout process. It also opens the door for many other possibilities, which will be discussed later in this document.

1.1 Purpose...............................................................................................................................

We chose a project involving RFID technology in the retail sector because we believe that this technology has the potential to add significant convenience to the customer by cutting down on time spent at the register. We are excited because this is a cutting edge technology that is currently still in the early stages of implementation, leaving us with the opportunity to create an innovative product. While most stores still have a long way to go before such a system can be realistically implemented, the technology already exists today. We wanted to prove that systems like our are feasible today.

1.2 Specifications......................................................................................................................

Our system includes mostly sensitive components that need to function very precisely. The RFID reader used in our project is an inconsistent device and we question its reliability. Additionally, the reader has a tendency to overlook tags that are indeed within its range. Nonetheless, we aim for 90+% accuracy in this field. This means that the reader will be able to pick up tags within its range at least 90% of the time. We expect to see a range of 3 inches around the external antenna, with +-5% error. This number comes from the TI specifications, and we believe we can boost this range to approximately 1 foot using an additional voltage source. The power unit does not need to function very accurately. This is because the logic levels on our system’s electronic devices do not require an exact voltage, but rather a range of voltages which is easy to achieve with a voltage regulator circuit. We aim for an error of approximately +/- 5% in voltage levels. In regards to the keypad and LCD screen, we aim for perfect accuracy. What this means is that every key press will be detected, so long as it is held for at least 1 second. Additionally, every output sent from the PIC appears correctly on the LCD screen. Similarly, we expect perfect accuracy from the PIC. Every item sent to it from the reader must be interpreted and displayed correctly. All the items in inventory must be present when scrolling through them, and all costs must be calculated correctly.

1.3.6 LED Indicators As stated earlier, these LEDs are for the consumer to use to verify that the cart is indeed on and picking up items. The red LED indicates that the power is currently on. If the red power LED is on, but the yellow LED is blinking the consumer knows that there is an error with the reader, and will not work. If the red LED is on, and the yellow is not the user will know that the cart system is operational. The green LED is used to indicate when an item is placed in the cart. Another idea that we had for our project, but never had enough time to try it out is an LED that blinks when the battery pack is getting to the low end of it’s operational range of 4.5 V. It would blink infrequently so as to not use up much of the battery that is left.

2. DESIGN PROCEDURE

2.1 Power Supply Unit Design In the first design, we looked at how much the re-charger unit for 4 batteries would cost for prototyping purposes, and we found out that it cost a great deal, and the cost wouldn't be refunded later. Although this is the ideal situation for extended store use, the cost was prohibitive for us to obtain the unit. This is ideal since rechargeable batteries have an life of around 300 cycles ii , whereas the disposable batteries have a life of 1 cycle. The total life of each cycle in the non-rechargeable batteries tends to be more than in the rechargeable batteries, but it does not make up the difference in the overall picture both in terms of cost and lifespan. Our second design consisted of a 9V battery since there happened to be a spare one laying near our workbench. We used this in tandem with a LM7805 voltage regulator to create a logic level power supply that our design required. This design did indeed work during our whole project prototyping, but we determined that it was a very inefficient use of power, and over the long run couldn't be used in our design. This would be a very inefficient since all of the "over voltage" would be dissipated in the voltage regulator. We would also have to consider other cooling methods of the voltage regulator since it would be dissipating lots of power. Not only was the conversion for the 9V battery inefficient, and could potentially have cooling problems, but the battery also lacked a long lifespan with only 625 mAH .iii Our third battery design was very simple and used four common AA alkaline non-rechargeable batteries and nothing more. One might think about issues regarding the apparent difference in nominal voltage levels. The four AA batteries add up to 6 V, but in actuality come out to be more around 5.6 V when put in series due to the diode loss and resistances in the battery holders that result in voltage drops due to the following formula: V=I*R Also in practice, when put into the circuit, the voltage seemed to conform to the circuit's requirements of 5 V, and only put out 5.06 V (see Appendix). The other good thing about the four AA non-rechargeable batteries was the fact that they each have a life of 2850 mAH, for a total of 2850 mAH/ battery * 4 batteries = 11400 mAH. At a current loss rate of 210 mA -220 mA in read mode, that would be around 52 hours of continuous reading use. In the scroll mode, where the reader is in quiescent mode the circuit draws around 98mA continuously. At this rate, that would mean approximately 116 hours of use. In the 9V design the system only gets 5 V/ 9V, or 55.5% efficiency. This multiplied by the life of 625 mAH gives the useful life of the 9V of .555 * 625 mAH = 347 mAH. This divided by the two different modes of 220 mAH current draw (read mode) and 98 mA for scroll mode yield a lifetime from 1.58 hours to 3.54 hours. As for the protective diode, we chose the 1N5822 Schottky barrier diode because of its recommendation in on of our first lectures in ECE 445. The reason why it is protective is the fact that it ideally limits current to the forward direction so that no current is allowed to flow in incorrect ways that destroy the circuit. In reality, it allows 1.0 mA of current to flow in the reverse direction, which is not much at all, and can’t destroy any of the components in our circuit. The other alternative to the 1N was the 1N5817, which limited current to 1 A in the forward direction instead of 3 A for the 1N5822 but didn’t offer any additional reverse polarity protection. We might add onto the design in the future, and allowing 3 A to flow is better than allowing only 1 A to flow.

n* 14byte/(tag in database)(10 bits/byte)+15bytes/response10(bits/byte), also all divided by 57600bits/second and we have to do this for each item in the database, even if they are not (and never will be) in the cart! Items: Communication time (sec): Get_inventory() Communication time (sec): Individual Tag 10 .023. 50 .093. 100 .179. 500 .874 2. 1000 1.74 5. 5000 8.68 25. It is undoubtedly clear that in using the get_inventory command, we have substantially streamlined the time it takes our PIC to cycle through the code! Furthermore, our code can take in any tag number and compare it to a database, which currently happens to be onboard, but could easily be moved to an external device. 2.3 Encoder Design The encoder design became nessecary when we were given the keypad from the parts shop. The particular keypad functions with 8 pins, which is just too big of an I/O port commitment from the PIC. One possible alternative is to use only half the pins on the keypad. This design limits the PIC to determining only either the row or the column of a pressed key, but not both. Our appendix shows a talbe for identifying keys before and after their signal is encoded. While not terrible, the design utilizes only 25% of the available keys. Additionally, we currently use 5 keys and welcome the possibility for expansion.

3.4 LCD Display Module.......................................................................................................

There are not many way to change the design of our LCD display. Our design, described in more details later, was chosen because we were limitied to a choice of two models of LCD displays available in the parts shop, and because we wanted to use the driver LCD.C to simplify our coding. This is probably the most common design and used by virtually all design projects. 2.5 RFID Reader Unit Design When starting the project, we were given a S6500 reader from Texas Instruments. Although the S was available in lab, we spent 2 weeks trying to get it to work at all. The nice thing about the S6500 was that it was supposed to have about 1.5 feet of range, but we never got it to work. Our next option was to buy something from TI. When selecting among RFID readers available from Texas Instruments we chose the S6350 mostly for 2 reasons: its simplicity and its cost. The next closest reader that would do what we wanted it to do was the S2000, which was around $290. Our reader cost about $110, so that was a huge savings if we were to construct this commercially. As for the relay, we chose this over a transistor because of the lack of a voltage drop across it. With a transistor, there would be around a .7 V drop from 5 volts, which would be unacceptably low for the

reader. On the other hand, the relay offers almost no voltage drop since it is practically a wire, so in the end it was a very easy decision to make. We needed a 5V activated relay since we are only using one voltage throughout our whole system. There were many different voltages for relays such as 5V, 12V, 20V, and 24V. We decided on the 5 V relay since we only had a 5V source available to us. The final item in the RFID reader unit’s design was the antenna. This is an integral part of the overall system since it is the device that either hinders or helps the system as a whole. We were given an antenna in the beginning of class, and we used it throughout the semester. We did not realize until recently the cost of the unit, which is around $430. This is a huge sum of money considering all of the other components, with the RFID reader itself only being $111. If we had more time we should consider creating our own antenna which is far less costly.

2.6 LED Indicators Design.......................................................................................................

When designing our LED circuits, we looked at how much current we thought was needed to make a bright enough light for the user to see, but yet dark enough so that the power was not wasted. Since LED, or Light Emitting Diode, are current driven devices that have a particular voltage drop for each color, we had to figure out how much current we needed to fully see the diode. We used a resistor in series with the LED in order to drive the correct amount of current. Therefore the current that would be flowing through the device would be governed by the following formula where Vd is the voltage drop due to the specific color of the LED, Vcc is the supply voltage and R was the resistor used: Id = (Vcc – Vd) / R (2.7) As for what drove the LEDs, it all varied: the red LED was hooked to +5 V at all times, the green and yellow LEDs were driven by the PIC microcontroller driving pin B7 low for the green and pin B6 for the yellow.

Figure 3 An example of the voltage for the battery after a few hours of actual use is in the appendix.

3.2 PIC Microcontroller Unit....................................................................................................

To begin a detailed description of the PIC’s code, we first need to analyze the internal database. The database is a matrix of four columns and n rows, where n represents the number of tags that may be recognized. The first column represents the tags ID number, inherently unique to every RFID tag produced. The second column represents the items state. Here, a 1 indicates the item is currently in range, while a 0 indicates it is not. The third column represents whether or not the items state has changed since the last scan. This can be used to determine if a present item was just added during the last inventory scan, or if an absent item was lost during the last scan. Finally, every item obviously needs a column to store its price. The way that we work with this database to calculate the sum of all the products is by implementing a for-loop to cycle through every item (row) in the database. If the field describing the item’s state is set to 1 (indicating it is present) then the field containing its price is added to a running total. Another variable that we need to determine is whether or not the item has had a change in it’s state. This is important because we would like to use the LCD to display an item has been added or removed. We do this by storing each items current state to a temporary value. Next, the PIC sends the get_inventory() command and matches all the found tags to the database. Finally, the PIC checks the states of the entire database compared to the temporary values. If there is a discrepancy, then the item has been added or removed. More specifically, if there has been a change and the item is no longer present, then it logically follows that the item was removed. On the other hand, if there has been a change and the item is present, then it has been added to the inventory.

It is now appropriate to discuss in detail the coding behind the three interfaces who’s design is described above. We start with a description of the PIC connection to the keypad. The interface with the keypad handles five of the PIC’s I/O ports. One of these lines contains the data available, which is 1 (“high”) when data from the keypad has become available. The remaining four lines carry data bits representing a pressed key. The aforementioned DA signal is connected on pin_C0 of the PIC, with Data0, D1, D2 and D3 being connected to pin_C1,pin_C2,pin_C3 and pin_C4, respectively. As a key is pressed, the DA signal becomes high, signaling that data is available. If this high signal coincides with a check of the DA pin, which it should (more on this later), then the four data bits are stored in memory. These four bits are then decoded to determine which key they represent and stored as the last key pressed. Our code interprets all 16 keys, though only five are every used. If DA is low, then the last key press variable remains unchanged. Testing the response from the keypad and then implementing code to make use of the data is the most straight forward of the three interfaces. Next, we discuss the interface to the LCD and its accompanying code. The LCD requires 8 pins, attached as follows: PIC Pin: LCD Connection D0 Enable D1 RS D2 RW D3 X D4 D D5 D D6 D D7 D As discussed earlier, we use a previously written driver for the LCD, titled LCD.C, to control these pins. In the subroutine to update the display, we first need to recalculate the cost of the items, using the algorithm described above. Next, we need to see what items have changed, and whether the change is an addition or a subtraction. After each time a change in an item has been found, the code displays the change to the LCD screen, in the first line. The string to display for each particular item is stored in this subroutine, and accessed by a switch statement centered around the item number in the database. The previously described code for the keypad is necessary to determine the second line of the LCD. With the previous subroutine having updated the pressed key, the current one will determine what to display in the second line. If the pressed key is 3, then the second line will contain the total cost, in addition to the cost of tax. Conversely, if this key is 4, it will display the item count and cost. However, if the key pressed is 16, we wish to scroll through the current inventory. This is achieved by using a for-loop to display only items in inventory who’s database field indicates that they are currently present. If key 16 is pressed again, the scroll mode is exited.

3.3 RFID Reader Unit.............................................................................................................

Although we did not physically design the RFID reader or antenna themselves, we did design the component that enables it to function correctly, namely the relay. The relay is a normally closed relay, which means that it is always connected. In our case, this mean that the output from it is always at 5 V since we drive it high using pin 8 as shown in its datasheetiv. Whenever the signal that comes from pin B7 is high, the reader will see 5 V and will therefore be powered up. When the signal is sent low because of an error in the RFID reader, the reader will be powered off. In essence, the relay was used as a reset switch for the reader. 3.4 LCD Display Module The LCD screen requires 8 pins, two of which are the obvious voltage source (+5V) and the ground (0V). Additionally, there are the EN, RS, RW, D4, D5, D6, D7 pins. The four data pins control the data sent to the LCD, the EN tells the LCD when data is enabled, and RW/RS control the read/write mode. The LCD has a build in driver to output characters based on the input signal. Even the input signal does not need to be manipulated in great detail though: The provided driver LCD.c handles all output signals from the PIC to the LCD. For example, to display the phrase “Hello World,” one needs to simply type: Lcd_init() //Initialized the LCD screen Lcd_putc(“\fHello World”); //where /f clears the screen. The driver is a big help, because it relieves us from having to work directly with any signals sent to the LCD.

3.5 Display Mode Interface....................................................................................................

The keypad has 8 pins, four to describe the row, and four to describe the column. Either the row or the column must be held high, and pressing the key essentially shorts the row and the column, creating current. We run this through an encoder to make it more useful to the PIC, and to save us 4 I/O ports.

3.6 LED Indicators..................................................................................................................

The LED Indicator Unit was designed to help the user see the status of the system. As stated before, each LED has its own unique current limiting resistor. The reason why we put the resistor in here is to limit the amount of current that the diode actually sees so that it will not break down. Using wikipedia.comv, we found out that the voltage drops for the different colored LEDs are as follows: 1.7 V for red, 2.1 V for green and 2.0 V for yellow. Also when doing our “brightness” test we noticed that a 2 kohm resistor between the +5 V terminal and the ground was needed to have the red, green and yellow LEDs light up sufficiently for the user to see when looking straight on into the LED. Since we only had 2 LEDs coming from the PIC microcontroller, we felt that the microcontroller could handle the current sourcing since we found that the total current needed to be sourced by the PIC to the two LEDs was about 3.1 mA using equation 2.7. The signal for the yellow LED came from pin B7 and then got inverted, while the signal for the green LED came from the pin B6 (See appendix). The reason why the PIC microcontroller would always have to have a high output to be off is so that the potential drop would never exceed the voltage drop of the diode, and therefore always off. The opposite would be true

if you forced the output low- there would be enough of a voltage drop to allow the diode to turn on, and therefore the light would also turn on.

Actual vs. Theoretical Current Consumption 0 50 100 150 200 250 300 Item mA (^) Theoretical Actual Figure 4 4.1.2 PIC/ RFID Transmission and Reception As described in the design review, our objective was to try and provide the RFID reader with a RS signal that was sent from the PIC microcontroller. The goal can be easily verified by seeing the plots on the oscilloscope. In light of this test, we downloaded the data from the oscilloscope to a computer so that it could be easily viewed at any time. The way that the RS232 signal language works in our case is that there is a start bit, an stop bit and the data in between that we define to be eight bits in length. The start bit is defined to be a logical 0, and the stop bit is defined to be a logical 1 which corresponds to voltages on the PIC ports of 0 V and 5 V respectively. The middle eight bits are used to send two hex “nibbles”, or two sets of four bits. The signal sent on the RS232 port in hex was: 01 0D 00 00 00 00 60 11 07 01 00 7b 84. As for the transmission of the Get Inventory signal by the PIC, we can see from a waveform in appendix that the signal was indeed sent correctly. All signals between the PIC and the RFID reader are sent through a MAX232 chip to ensure both devices operate at their respected voltages. A details description of the bytes handled by the software has already been provided above.

Furthermore, the appendix shows an image of the string of logic levels. Additionally, we have provided a schematic of the data that needs to be extracted from the response. 4.1.3 LCD Display At first our LCD display would not work, and we thought it might have been broken. We acquired a new one from the ECE parts shop. We spent a few days probing at a very simple circuit, and found a problem in our code. The LCD display did not work because we were setting the tri-state buffer when that operation was automatically handled by the CCS compiler when compiling the LCD.h header file. As for the testing of the LCD display, we found that the best way to show that it works is by using a picture. We took one picture specifically for the purpose of showing that it is operationally sound. It is displayed in the Appendix. 4.1.4 Keypad Response and Encoding In our design review we said that we would write a short code that would display that the keypad responded correctly. We decided against this because it would take more time just to write that code. We decided to just use the oscilloscope to find the values of the encoder for individual keys. The values of these are found below. Button Keypad Value A B C D 1 1 0 0 0 0 2 2 1 0 0 0 3 3 0 1 0 0 4 A 1 1 0 0 5 4 0 0 1 0 6 5 1 0 1 0 7 6 0 1 1 0 8 B 1 1 1 0 9 7 0 0 0 1 10 8 1 0 0 1 11 9 0 1 0 1 12 C 1 1 0 1 13 * 0 0 1 1 14 0 1 0 1 1 15 # 0 1 1 1 16 D 1 1 1 1 We then used these values for A, B, C, and D in our code to represent each of the various buttons that were pressed. We also know that we succeeded because in our final code, we used these buttons to change between various modes. The keypad was also used in our scroll function that scrolled up and down through the items that were currently in the inventory. One can see that the buttons were indeed working in the video (attached online) with the different modes as well as the scroll function. 4.1.4 RFID Reader operation We did manage to get the RFID reader working by sending the correct signals to it via the MAX232 chip. We had troubles testing the reader in the beginning because of the lack of knowledge on how the RS232 driver worked. After figuring out how the signals were communicated between the reader and the PIC, the transmission worked flawlessly, as one can see in the appendix.