EE 477 Final Report - Purdue University
ECE 477 Final Report ( Spring 2010
Team 1 ( Inebriation Station
[pic]
Team Members:
#1: _______Mike Wei _________ Signature: ____________ _______ Date: _5/5/10___
#2: _____Jon Schwarz__________ Signature: ____________ _______ Date: _5/5/10___
#3: _____Bill Bergquist_________ Signature: ____________ _______ Date: _5/5/10___
#4: _____Carlo Mesina_________ Signature: ____________ _______ Date: _5/5/10___
|CRITERION |SCORE |MPY |PTS |
|Technical content |0 1 2 3 4 5 6 7 8 9 10 |3 | |
|Design documentation |0 1 2 3 4 5 6 7 8 9 10 |3 | |
|Technical writing style |0 1 2 3 4 5 6 7 8 9 10 |2 | |
|Contributions |0 1 2 3 4 5 6 7 8 9 10 |1 | |
|Editing |0 1 2 3 4 5 6 7 8 9 10 |1 | |
|Comments: |TOTAL | |
| |
TABLE OF CONTENTS
|Abstract |1 |
| 1.0 Project Overview and Block Diagram |1 |
| 2.0 Team Success Criteria and Fulfillment |4 |
| 3.0 Constraint Analysis and Component Selection |4 |
| 4.0 Patent Liability Analysis |10 |
| 5.0 Reliability and Safety Analysis |15 |
| 6.0 Ethical and Environmental Impact Analysis |18 |
| 7.0 Packaging Design Considerations |22 |
| 8.0 Schematic Design Considerations |28 |
| 9.0 PCB Layout Design Considerations |33 |
|10.0 Software Design Considerations |37 |
|11.0 Version 2 Changes |45 |
|12.0 Summary and Conclusions |46 |
|13.0 References |47 |
|Appendix A: Individual Contributions |A-1 |
|Appendix B: Packaging |B-1 |
|Appendix C: Schematic |C-1 |
|Appendix D: PCB Layout Top and Bottom Copper |D-1 |
|Appendix E: Parts List Spreadsheet |E-1 |
|Appendix F: FMECA Worksheet |F-1 |
Abstract
The Inebriation Station is a microcontroller-driven, standalone beverage dispenser that interfaces with a customer without continuous human vendor support. The user prepays for his drinks, obtains a cup with his information tagged on it (through RFID), and is able to use that cup at a The Inebriation Station. At the station, the user will be able to choose his beverage and choose a volume. The Inebriation Station will automatically fill the cup and charge the user for his purchase.
1. Project Overview and Block Diagram
After purchasing a cup with an embedded RFID tag, a customer places his cup under the beverage spout of the Inebriation Station and breaks an infrared beam. The beam break triggers the microcontroller to initiate a read from the RFID reader, and the RFID tag on the bottom of the customer’s cup is read. The RFID reader returns the RFID tag number to the microcontroller. Upon receiving the tag number, the microcontroller sends the RFID tag number to a wireless module, and that wireless module sends the data to a computer on the standard 802.11 protocol. The wireless module then receives user and beverage information from the computer and sends that data to the microcontroller. The microcontroller displays information such as the user’s remaining balance and beverage choices to the customer on an LCD. At the same time, the microcontroller accepts user input on a keypad. After the customer makes a selection, the microcontroller opens a solenoid to allow the correct beverage to pour the correct amount. In the background, 4 temperature sensors are read every minute to check the temperature inside of the refrigeration unit, and a relay is used to turn the refrigeration unit on and off to maintain correct beverage temperature.
[pic]
Figure 1.2: Photo of completed project
2. Team Success Criteria and Fulfillment
1. An ability to use an RFID tag to identify a user.
• This PSSC was completed in full. Each RFID tag had a unique 10-character ASCII code, which was then linked to a user’s names and funds.
2. An ability to receive user input about drink selection and drink size.
• This PSSC was completed in full, using a 20-key keypad and a 4x20 character LCD to communicate with a user.
3. An ability to fill a cup to a user-specified amount with a user-specified beverage.
• This PSSC was completed in full. The user-specified amount was defined as total volume including foam. Timing was used to toggle a solenoid on and off, allowing the user to select any beverage size in 1oz increments up to the size of his cup.
4. An ability to display user information (name, account funds, drinks purchased) and device statistics (keg fill level, temperature) on the onboard LCD.
• This PSSC was completed in full. After a user enters his pen, all of the aforementioned information is shown on various screens of the LCD.
5. An ability to communicate with a remote database to retrieve and manipulate user data.
• This PSSC was never completed on the PCB. It was completed in full on the Explorer 16 Development board using a Zero-G wireless module. The server with all of the user’s information was run on Purdue’s Shay server on port 9990, and standard TCP/IP protocol was used.
Constraint Analysis and Component Selection
.
3.1 Introduction
The Inebriation Station is an automatic kegerator that allows users to select one of four different beverages using an LCD and keypad. The user first scans his unique RFID tag using an RFID reader. The microcontroller will then transmit the RFID tag wirelessly to a remote account server to be processed. The server returns the user’s account information to the microcontroller, during which the user will then be prompted to enter a 3 pin password. Once the user has been verified, he may select the type and the amount of beverage he wants using the LCD and keypad. User account information and other miscellaneous user statistics are stored on the account server.
3.1.1 Updated PSSCs
1. An ability to use an RFID tag to identify a user.
2. An ability to receive user input about drink selection & drink size.
3. An ability to fill a cup to a user-specified amount with a user-specified beverage.
4. An ability to display user information (name, account funds, drinks purchased) and device statistics (keg fill level & temperature) on the onboard LCD.
5. An ability to communicate with a remote database to retrieve and manipulate user data.
3.2 Design Constraint Analysis
The major design constraints for our project are refrigerator size, cost of parts, and power usage. While the product will be plugged into a wall at all times, our team would like to reduce the power used since the device is designed to remain on for long periods of time.
3.2.1 Computation Requirements
The microcontroller must be able to perform the following computational tasks: Switch on and off the refrigerator to maintain beverages at a desired temperature, communicate wirelessly with the user account server, receive data from the RFID reader, take user input from the keypad/LCD, and toggle four different solenoid valves. Temperature control and reading inputs from the keypad require periodic interrupts, but only on the order of milliseconds, which an RTI can easily provide. The most computationally intensive task is receiving data from the RFID reader, and using that data in conjunction with information sent from the user account server to manage the user’s drink experience.
Suppose N is the number of cycles in one of the pushbutton polling loops. Given that there are two pushbuttons and a data available line (for the keypad) which must be polled within a period of 1 ms, that means the clock speed needs to be at least 3N kHz. In assembly, polling loops are typically very short (less than 100 cycles). This value may be higher in embedded C. Assuming 100 cycles per polling loop, only 200 kHz would be required to adequately poll both pushbuttons. The WIFI module transmits data at 1-2 Mbps and communicates with the microcontroller using SPI. The SPI for the WIFI can go up to 25MHz [5]. Since the team is not sure how large the WIFI module’s internal buffer is, the SPI clock line should be run at a speed greater than the WIFI module’s data rate. The WIFI module uses an interrupt to tell the host microcontroller that data is available. The amount of data being sent from the remote account server to the microcontroller comprises of only a few bits of information such as user name and funds. Therefore, given the 2 Mbps data rate of the WIFI module, the length of the interrupt will be very brief, allowing the microcontroller to continue polling pushbuttons and handling any additional interrupts in between sending and receiving data from the remote account server. To be safe, the microcontroller chosen should have a minimum clock speed of 4Mhz, which is twice the absolute minimum recommended clock speed.
2. Interface Requirements
The product requires a total of 12 general I/O pins: 1 for the IR Break Beam Sensor, 5 for the keypad encoder, 1 tied to an NMOS gate to switch the refrigerator on and off, 1 for the OE pin of the RFID reader, and 4 to toggle the solenoid valves. There are also 9 reprogrammable pins that have been padded out for debugging purposes or for use as pins for additional external peripherals. The I/O pins required for switching the solenoid valves and the refrigeration unit on and off will require optical isolators, as the solenoid valves are high current devices. Currently, the LEDs for the LCD display are all tied to individual I/O pins on the microcontroller. Since the PIC24FJ128GB108 microcontroller has a total of 65 I/O pins, the team decided that use of a shift register or a LED driver was unnecessary. Each of the 4 solenoid valves requires an optical isolator and additional circuitry to engage the switching of the valves. Each solenoid valve is rated at 6.9W DC and the solenoids run at 12VDC. This means that to open a valve requires 575 mA of current. The switching circuitry for the solenoids will be a power NMOS with the solenoid attached at the drain end and a 12V source voltage. The gate of the NMOS will be driven by the microcontroller.
3.2.3 On-Chip Peripheral Requirements
The product requires two UART/RS-232 modules, one I2C module, and one SPI module. One RS-232 I/O is required for transmitting display information to the LCD and receiving data from the keypad. The other RS-232 I/O is used to receive data from the RFID reader. Unlike the LCD/Keypad, the RFID reader does not require a data receive line. It only returns 10-byte (start byte, 8-byte ID, stop byte) RFIDs in ASCII [2]. The temperature sensor uses I2C.
4. Off-Chip Peripheral Requirements
There are currently no off-chip peripherals planned for our design.
5. Power Constraints
Since the product will be on for prolonged periods of time, minimizing power draw has become one of the team’s unstated goals. While a fridge has not yet been purchased, a refrigerator typically requires around 100-500W. Each solenoid is rated at 6.9 Watts at 12 VDC [1]. However, since the design requirement is at most one drink at any given time, only one solenoid valve has to be active. The solenoid valves are normally closed, so only one requires power when dispensing a beverage. The RFID reader typically draws 10 mA when idle and 100 mA when active [2]. Since the difference is a factor of 10, one way to reduce the power usage is to idle the RFID reader during periods when the user is making a drink selection. The reduction in power usage in the RFID reader when idle is 450 mW [2]. The LCD/Keypad uses 166 mW when the backlight and indicator LEDs are disabled [4]. When both backlight and indicator LEDs are enabled, the power consumption increases by roughly 970 mW [4]. If the LCD/Keypad backlight and indicator LEDs are disabled while there are no users ordering a drink, the product’s idle state power usage may again be reduced.
6. Packaging Constraints
The package needs to be designed such that refilling the kegs or replacing the CO2 is not a difficult task for a bar tender or whoever is performing maintenance. This requires guiding the tubing intelligently to avoid having parts becoming snagged or accidentally dislodged when opening the refrigerator. Parts that need to be changed periodically or have high potential for future replacement also need to be easily accessible. The RFID reader has to be placed in a location that is intuitive to the user and parallel to where the user will place an RFID tag. The RFID reader’s 3-inch read distance limits where it can be placed.
While it is possible to place the microcontroller inside of the refrigerator, our team would like to avoid this by placing the microcontroller and peripherals in an enclosure above the keg tap, along with items such as the LCD/Keypad. This would keep them from becoming subject to hazards such as spilt beverages and refrigerator ambient conditions.
7. Cost Constraints
A kegerator from companies such as Sanyo, Summit, and Danby can go for around $600 for the lowest end models up to over $4,000 for the higher end models. Our team’s goal is to design a product that is less than $1000, and offer greater functionality than even the most expensive kegators.
2. Component Selection Rationale
1. Microcontroller Selection
The companies the team looked at are Microchip, FreeScale, and Atmel. Since no one on the team has heard of Atmel before the project, the team looked more into microcontrollers from Microchip and FreeScale. Microchip has a good reputation among past ECE477 students and electronic hobbyists. Everyone on the team is familiar with FreeScale because a FreeScale microcontroller was used in ECE362.
Initially, the team looked at the FreeScale family of microcontrollers. One of the microcontrollers the team looked at was the MCF51CN128. Like most FreeScale microcontrollers with a large number of peripherals (more than 1 UART/I2C/SPI), the MCF51CN128 was a 32-bit processor. Since the team has only worked with 16-bit microcontrollers, and none of the 16-bit FreeScale microcontrollers had more than 2 UART/SPI peripherals, the team decided to look at Microchip’s microcontrollers instead.
Browsing Microchip’s website, the team found a family of microcontrollers that met the initial criteria (3 UART, 3 SPI, 2 I2C). The chip comes from the PIC24FJ256GB110 family of microcontrollers. They come in three packages: 64 pin, 80 pin, and 100 pin. Because the price difference between the 64 pin package with the least amount of memory (16K RAM, 64KB Flash) and the 100 pin packages was less than a dollar, the team decided to go with the PIC24FJ128GB108. This choice allows for additional peripherals to be added in the future. Because the product is still in its design phase, the team wanted a microcontroller that would allow for future expansion. The PIC24FJ128GB108 runs at 8Mhz natively and comes with 16K RAM, 128KB Flash, 4 UARTs, 3 SPIs, 3 I2Cs, 84 I/O pins, and USB capabilities [3].
3.3.2 LCD/Keypad Selection
The team had originally wanted to use a touch screen LCD, but found that the cost for a reasonably sized touch screen LCD was beyond our budget range. The team decided to go with a cheaper solution. The company the team chose was CrystalFontz, due to the fact that most of the team has experience using CrystalFontz LCDs. Going for a LCD with a large viewing area, the team narrowed down potential candidates to the following parts: CFA634-NFA-KS, CFA634-TFB-KS, and the CFA634-YFB-KS. The CFA634-NFA-KS is the cheapest of the three solutions ($45) and has no backlight. The CFA634-YFB-KS is the next cheapest ($60) with a plain yellow-green backlight that requires 450 mA. The CFA634-TFB-KS is the most expensive ($65) solution and has a cool blue backlight running at 160 mA. The team wanted an LCD with a backlight, specifically a blue backlight. Because the price difference between the CFA634-TFB-KS and the CFA634-YFB-KS was only $5, the team went with the CFA634-TFB-KS for its blue backlight, 4.02” by 1.63” viewing area, and significantly lower current draw.
4. Solenoid Valves
The solenoid valve had to fulfill the food-safe requirement. The team went with ARCO, a well-known solenoid valve vendor, which sells NSF 169 certified solenoid valves (meaning they are food-safe). From the NSF 169 certified valves, we were given the options of choosing 1/8” and ¼” valve. The decision was to go with ¼” valve because smaller pipes may cause the beverages to foam more when they are finally dispensed into a cup. Among the ¼” valves, the two options remaining were given a CV rating of 0.15 and 0.17. Given that both valves were priced at $57, the team chose the 0.17 CV valve because a CV rating represents gallons of water that can be dispensed before losing 1 PSI of pressure at 60 degrees F. A higher CV rating would allow for the CO2 used to pressurize the kegs to last longer. Another reason the team chose the following solenoid valve is because it was a direct acting solenoid valve, which means that closing the valve has no dependence on the pressure of the incoming fluid. The valve is also normally closed, which means current only has to be driven to the device when a drink is being dispensed.
4. WI-FI
The WI-FI module chosen for this project is a ZeroG ZG2100MC. The other option was a Letronix WiPort. Both support 802.11. The team chose to go with the ZeroG ZG2100MC because it is $29.40, whereas the Letronix WiPort is $55 [9]. The ZeroG ZG2100MC also features low power consumption, 3.3V supply voltage, and consumes only 250 uA during sleep mode [5].
5. RFID Reader
The team chose to use a Parallax Serial RFID Reader #28140. The RFID reader uses a UART/RS-232 interface, indicator LEDs to show whether or not the device is active, and has a read distance of 3 inches [2]. While this range may seem short, the team would like to avoid accidentally reading the wrong RFID tag. The RFID Reader has an OE pin which enables the microcontroller to put the device in an idle or active state, reducing power usage [2]. It can read approximately 30 RFIDs per second. The other alternatives the team looked at are the Phidget P/N 1030 and the pcProx RFID reader. The Phidget 1030 has a range of 4 inches or less, USB interface, and has a price tag of $65 [7]. The pcProx has a range of 1-3 inches, uses USB or RS-232 interface, requires an operating system, and has a price tag of $149.99 [8]. Since the Parallax is cheaper than both these solutions and able to read 30 RFIDs per second (more than enough speed for the team’s project application), the team decided to go with the Parallax RFID reader.
6. Temperature Sensor
The temperature sensor the team selected is a TI TMP175. The interface is I2C. It uses diode temperature sensing, has a built-in A/D converter, a temperature range of -25C to 125C, open drain output pins (requires pull-up resistors), and comes in an SOIC-8 package [6]. A similar model is the TI TMP75. The main difference is that the TMP175 supports up to 27 of the same device on a 2-wire I2C interface, whereas the TI TMP75 only supports 8 [6]. The team decided to use the TMP175 for greater expandability.
7. IR Break Beam Sensor
Since one of our team members (Bill) has made an IR Break Beam Sensor for his ECE 362 mini-project, the team is going to attempt to do the same using parts available from the ECE parts shop. The goal is to amplify the output signal to achieve TTL logic levels so the voltage can be sent directly to an I/O pin. Otherwise, an A/D converter will be used to determine when the beam is broken.
3. Summary
This document contains a comprehensive assessment of overall product functionality, design goals, and physical as well as hardware constraints. An explanation of what the product is capable of and its intended usage is outlined in section 1.0. An overview of design constraints is given in section 2.0. Sections 2.1-2.4 outline the internal mechanisms of the product, such as computational requirements, interface requirements, off-chip peripheral requirements and power constraints. Section 2.5 outlines the limitations and requirements of the product’s packaging. Section 2.6 details cost constraints. Section 3.0 discusses the rationale behind part selection for major components.
4.0 Patent Liability Analysis
Introduction
The Inebriation Station combines a cup with an attached identification tag with a system for controlling the purchase and distribution of a plurality of beverages. Automated beverage dispensing has existed since the 1950s. Many patents exist in the area of food containers and dispensers using RFID or other labeling technology to automatically dispense a beverage. Some issued patents are very general, making it possible for the Inebriation Station to infringe upon these patents. Many patents need to be examined closely to ensure no infringement exists.
4.1 Results of Patent and Product Search
The United States patent office was searched using “(beverage OR beer OR (fountain AND drink)) AND electronic” in both the title and abstract of all patents. The following are five of the most relevant patents found:
4.1.1) Patent 4,011,967 is a patent for “an electronically controlled ingredient dispensing system in … vending machines” that operates “after a coin triggered relay switch and beverage selection switches are activated” [10]. The novelty presented in this patent is using electrical rather than mechanical timing to control the dispensing of beverages into a cup using discrete logic gates. It was granted in March of 1977 [10].
4.1.2) Patent 5,566,732 includes a “dispenser … controlling beverage flow through a valve … and reads an indicia printed on the container which identifies the volume for that container” [11]. This patent is primarily claiming the innovation is in identifying a cup size to allow an electronic system to automatically fill the cup to its full volume without the vendor judging the pour. The patent also leaves the room open for a “serial number assigned to each container” that could be used to refuse service to a cup that has been filled before [11]. Patent 5,566,732 was granted in October of 1996 [11].
4.1.3) Patent Application 20020134831 is for “passive transponders … embedded in or otherwise attached to the food and beverage containers” such as “a plastic-based receptacle or cup” [12]. Furthermore, the patent plans to use the RFID tag to “track the containers and control the amount of consumable material with which the containers are filled, the number of times the containers are filled, and the type of material with which the containers are filled” [12]. As outlined in the application, the information is all stored in the RFID tag [12]. This patent was applied for in September 2002 [12].
4.1.4) Patent 6,934,602 specifies a “microcontroller for monitoring the user interface and for activating the valve interface responsive to user input, thereby regulating the delivery of a beverage from the dispensing valve” [13]. The patent also includes “a modem to permit communication with remotely located external devices” [13]. This patent primarily covers the portability of the electronic control of the system rather than the combination of the physical system. It was granted in August of 2005.
4.1.5) Patent 7,617,850 specifies a cup with a “read/write radio frequency identification tag on a container … After cup is purchased, the customer will go to the dispenser to receive a beverage … [the] antenna will not read [the RFID information] into the reading field to validate cup until after infrared proximity sensor(s) detects the cup” [14]. The patent further leaves the option for the “(PCB) [to] provide the overall operation and … the information can be sent using any way known in the art, for example, via cellular Ethernet (internet)” [14]. The device plans to calculate “the ounces of beverage being poured into cup using time based flow rate calculations” [14]. The product protected under patent also features “Dispensing head will stop dispensing after cup is moved away from proximity sensor, dispensing activator is deactivated, or the allotted ounce capacity for cup has been reached” [14]. This patent outlines that the “RFID antenna (write portion) at the cash register sends information (for example, location, promotion code, date, ect.) to RFID tag in bottom of cup” [14]. The device uses multiple spouts for beverage pouring, and has no automatic filling feature. The patent was granted in November of 2009 [14].
2. Analysis of Patent Liability
The Inebriation Station does not literally infringe on any of the patents found. This is due to the fact that there is at least some minimal difference between the Inebriation Station and any of the patents listed. The Inebriation station may infringe on the Doctrine of Equivalents to some of the patents listed below.
4.2.1) The Inebriation Station has the potential to infringe on Patent 4,011,967 because the Inebriation Station does use an electrical timing and actuation method for dispensing precise quantities of beverages. However, the Inebriation Station uses a microcontroller instead of discrete gates which is a significant improvement because of the reprogramming ability. Further, the Inebriation Station does not require cash to be inserted into the device which is also a significant improvement. There is no liability based on those differences, and the fact that the patent is over 20 years old anyways.
4.2.2) Patent 5,566,732 could be infringed upon by the Inebriation Station because both devices use a tag on a cup to tell the dispensing system a serial number and a volume. Both devices also correctly fill the cup automatically based on that tag. The tag in Patent 5,566,732 clearly states it is an “indicia” [11] which suggests a barcode or something read with visible light. The Inebriation Station greatly improves on this as a line of sight is not required with an RFID tag. Furthermore, the Inebriation Station also has the ability to fill a cup to different levels, and the device in Patent 5,566,732 always fills the cup to the top. Due to the significant differences, not liability exists for the Inebriation Station on Patent 5,566,732.
4.2.3) While Patent Application 20020134831 specifies storing information on the RFID tag, it seems to cover the general act of placing any passive transponder onto a food receptacle. If this patent is granted, the Inebriation Station would almost certainly infringe upon it.
4.2.4) Both the device described in Patent 6,934,602 and the Inebriation Station use a microcontroller to control the automated dispensing of a beverage at a vending machine. Both also use an internet connection to transmit data to a single server that is capable of monitoring all units. However, this patent only truly encompasses the control board and the software that interfaces with the vending machine, not the complete system. It even admits that this has been done before, but claims to have innovated the modularity of the software, where it could be plugged in to a plethora of devices and work almost seamlessly. Since the Inebriation Station uses a significantly different software scheme for interfacing with the user with an LCD and keypad, and also includes the overall refrigeration unit and dispensing valves, the Inebriation station is different enough to not be infringing.
4.2.5) Finally, Patent 7,617,850 is almost certainly infringed upon by the Inebriation Station. Both devices have the user prepaying to a cup with an RFID tag imbedded in the base of it. Both devices initiate the dispensing machine by an infrared proximity sensor. After the cup is detected, both use a passive tag to identify the RFID, and both communicate that information back to a cash register or central server with cellular Ethernet or through the internet. Both devices then automatically pour the beverage, measure the amount of fluid being dispensed by a time base flow rate calculation, and stop the user from pouring when the cup size is reached, or the cup is removed. However, the Inebriation station pours all of the beverages through one spout, allowing the user to choose which he would like with push buttons while the device from Patent 7,617,850 uses discrete spouts. Furthermore, the device in the patent stores the purchase information in the RFID in the cup, and the Inebriation Station stores all of the data in an off-device, central server. While both of these are improvements, the overall device still performs substantially the same function in substantially the same way. This means that the Inebriation Station is liable under the Doctrine of Equivalents.
3. Action Recommended
Before bringing the Inebriation Station to market, a patent attorney should be consulted regarding all of the patents listed above. For the two patents identified above as likely to be infringed upon, Patent Application 20020134831 and Patent 7,617,850, licensing is the best option for the Inebriation Station.
4.3.1) Regarding Patent Application 20020134831, it is nearly impossible with current technology for the Inebriation Station to design around the patent. To cost effectively use non-line-of-sight technology for an identification number, RFID is really the only option. Should that patent be granted while the Inebriation Station was already in production, if enough units were being used to make licensing more expensive than a lawsuit, the Inebriation Station would seek to have the patent nullified on the basis of it being obvious. However, if a patent lawyer advised the team that the patent would likely hold up in court, or the team lost the lawsuit, then licensing the technology would be the only option.
4.3.2) Being an extremely broad and inclusive patent, Patent 7,617,850 will never effectively be designed around by the Inebriation Station. ValidFill LLC has made it apparent it would like to sell to one large company such as BP gas stations, or 7-eleven convenience stores. Selling individually to thousands of unique bars is not in its business plan. Furthermore, their interfaces work best for soda, as the dispensing system is different for beer. Therefore, licensing the patent is the only option. The team believes ValidFill LLC, the owner of the patent, would be willing to license it for the production of the Inebriation Station since they are primarily targeting the soda industry while the Inebriation Station is primarily targeting the alcohol industry.
4.4 Summary
Many patents exist for products similar to the Inebriation Station. The Inebriation Station infringes upon one patent application and one granted patent. Both patents are broad enough to effectively prevent the Inebriation Station from designing around their technologies. The Inebriation Station plans to license that technology from the patent holders.
4. Reliability and Safety Analysis
1. Introduction
The Inebriation Station is an automated beverage dispenser that also keeps track of the users’ account history with an RFID Reader communicating wirelessly via Wi-Fi to an onsite computer. In addition, the wireless module also transmits information about the unit (ie. temperature and keg fill level). Since all the electrical components are kept inside the refrigeration unit and there aren’t any moving parts, the Inebriation Station doesn’t put the user in any potential danger when being used. However, the reliability issues that will be most critical to the design are components overheating, software/hardware errors with the PIC24F, noise on the protocol communication lines and relay failure. It should also be noted irresponsible use of the Inebriation Station can increase the chance of the user being harmed indirectly.
2. Reliability Analysis
The components that are most likely to fail on our board are the LT1767-3.3 and LT1767-5 switching regulators, PIC24FJ128GB108 microcontroller, and G5LE-1A4 DC12 relay. The microcontroller was chosen because it is the most complex component in our design that controls the function of all the other components. The relay was chosen because it is used to frequently switch the refrigeration unit on and off, which can lead to contact wear and tear then failure. The switching regulators were chosen because they dissipate the most heat, which has potential to overheat and fail. The following tables will show the calculations to determine the number of failures per 106 hours and mean time to failure (MTTF). The PIC24F was modeled as a 16 bit MOS logic microprocessor [17], the LT1767-3.3 and 5V switching regulators were modeled as a MOS device with linear gate/logic array, assuming it has 101 – 300 transistors [15] and the G5LE-1A4 relay was modeled to have a SPST contact form with an armature construction [18] [19].
|Parameter name |Description |Value |Comments |
|C1 |Die Complexity |.28 |16-bit MOS device |
|πT |Temperature Factor |.19 |Digital MOS; |
| | | |TC = 35o P = .576 |
| | | |ϴJC = 10 |
| | | |TJ = TC + P*ϴJC |
| | | |TJ ≈ 40.76oC |
|C2 |Package Failure Rate |.041 |Nonhermetic SMT; |
| | | |NP = 80 (# of pins) |
|πE |Environment Factor |.5 |Ground, benign; Nonmobile; Controlled |
| | | |environments accessible to maintenance |
|πQ |Quality Factors |10.0 |Commercial product |
|πL |Learning Factor |1.0 |In production for |
| | | |> 2 years |
|λp |Failure Rate |7.37 x 10-7 |Failures/hour |
|MTTF |Mean Time to Failure |≈ 1356852.1 hrs | |
| | |≈ 154.89 yrs | |
Table 2.1: PIC24FJ128GB108 (λp = (C1 * πT + C2 * πE) * πQ * πL Failures / 106 hours)
|Parameter name |Description |Value |Comments |
|C1 |Die Complexity |.02 |MOS device; Linear Gate/Logic Array; |
| | | |Assuming 101 – 300 transistors |
|πT |Temperature Factor |12 |Linear MOS; |
| | | |TJ = 95oC |
|C2 |Package Failure Rate |.0034 |Nonhermetic SMT, NP = 8 (# of pins) |
|πE |Environment Factor |.5 |Ground, benign; Nonmobile; Controlled |
| | | |environments accessible to maintenance |
|πQ |Quality Factors |10.0 |Commercial product |
|πL |Learning Factor |1.0 |In production for |
| | | |> 2 years |
|λp |Failure Rate |2.57 x 10-6 |Failures/hour |
|MTTF |Mean Time to Failure |≈ 389105.06 hrs | |
| | |≈ 44.42 yrs | |
Table 2.2: LT1767-3.3 and LT1767-5 (λp = (C1 * πT + C2 * πE) * πQ * πL Failures / 106 hours)
|Parameter name |Description |Value |Comments |
|λb |Base Failure Rate |.02 |Ambient Temp. = 85 ºC |
| | | |Rated Temp. = 85 ºC |
|πL |Load Stress Factor |≈ 1 |Resistive Load |
|πC |Contact Form Factor |1.00 |Contact Form: SPST |
|πCYC |Cycling Factor |50.00 |Cycles/hr = 500 (very most) |
|πF |Application and Construction |6.00 |Contact Rating = 10A; |
| |Factor | |Medium Power; |
| | | |Armature Construction Type |
|πQ |Quality Factor |10.00 |Commercial Product |
|πE |Environment Factor |2.00 |Ground, benign; Nonmobile; Controlled |
| | | |environments accessible to maintenance |
|λp |Failure Rate |2.4 x 10-6 |Failures/hour |
|MTTF |Mean Time to Failure |≈ 416666.67 hrs | |
| | |≈ 47.56 yrs | |
Table 2.3: G5LE-1A4 DC12 (λp = λb *πL *πC *πCYC *πF *πQ *πE Failures / 106 hours)
As you can see, from the failure rate and MTTF calculations, the PIC24F has a much larger life span than the switching regulators and relay. Although, there are several refinements that can be done to significantly increase the reliability system. The most obvious and simplest solution is to add a heat sink to the switching regulators to decrease the amount of heat that is being dissipated. By reducing the amount of heat being dissipated from the switching regulators, the overall heat dissipated from the design will be significantly reduced since they give off the most heat. Derating can also be another solution to reduce the amount of heat being dissipated. Meaning the amount of power the regulator can support should be significantly higher than the amount of power being sent to it. This way the regulator isn’t always being run at max capacity, thus reducing heat. As for the relay, the only solution that can improve the reliability of the overall system is to use a solid state relay instead. It may not be able to support as much current, but it has no moving parts switching between contacts, thus giving it virtually infinite life span. Overall the system is quite reliable, although to be certain that it’s lifetime is at its maximum potential, frequent testing of software and hardware can be done to be sure that no noise occurs on the communication lines, no wires are being shorted and that the program doesn’t get stuck in any infinite loops or other software “traps”.
3. Failure Mode, Effects, and Criticality Analysis (FMECA)
The following is our schematic broken up into various subsystems. They are the Power, Microcontroller, User Interface and the Solenoid. The Power Subsystem consist of 2 Female DC Barrel Connectors, 5V and 3.3V Switching Regulators and an 8-Channel Level Translator [16]. The Microcontroller Subsystem simply has the PIC24F and connections to various peripherals. The User Interface Subsystem has the LCD, RFID reader, IR break beam, keypad, keypad encoder, “Manual Fill” button and “Beer Me” button. Lastly, the Solenoid Subsystem has the solenoid valves and n-MOSFETs, which are used for switching the solenoids open and close. The criticality of each failure mode is given a low, medium or high level.
• Low: Failure that results in no damaged components
• Medium: Failure that can cause damage to parts, but can be replaced; System is still able to function
• High: Could potentially cause harm to the user.
A low criticality failure mode is when ( ≥ 10-5, a high critical failure mode is ( ( 10-9 and a medium critical failure mode is when ( ≈ 10-7, which falls somewhere in between.
4. Summary
In conclusion, in terms of the unit itself, the Inebriation Station is a very safe and reliable product. The only events that can result in harming the user is if the unit overheats and catches on fire or if beer overflows onto the floor creating a slipping hazard. It should also be noted that the user is responsible to use the device in moderation. The user is liable for any self inflicted harm from excessive use of the unit. The most effective way to further improve the reliability of the system is repeated testing of hardware and software, adding heat sinks to the switching regulators, proper derating of the switching regulators and replacing the electromechanical relay with a solid state relay. The Inebriation Station currently fulfills sufficient reliability expectations and has very low potential of harming the user.
5. Ethical and Environmental Impact Analysis
1. Introduction
The Inebriation Station is a digitally-controlled, automatic kegerator that dispenses alcoholic (or non-alcoholic) beverages to its user. The device was designed around the idea of speeding up lines at campus bars that are usually overcrowded. But speeding up the rate of dispensing could also speed up the rate of consumption, which most will agree is a bad thing As well, the freezer chest that this device was made out of contains dangerous ozone depleting substances and potent green houses gases [20]. As a duty to our environment, a responsible disposal process must be in place. These are just a few of the ethical and environmental issues that are related to the device.
2. Ethical Impact Analysis
There are many ethical issues that would need to be resolved before our design could be brought to market. The first and most important of which is the idea that our device would encourage binge drinking. Most would agree that this is a very dangerous situation, and could end up deterring potential customers who could see public relations backlash if certain situations ever happened. Along the same lines, potential hazards exist such as selling too much liquor to one person or letting someone drive home if they are in an incoherent state of mind. Another issue is about the enforcement of the minimum drinking age. Bar owners will lose their last layer of security against underage drinking and selling too much liquor to an inebriated customer, both of which could be risks these potential customers might not be willing to take. All of these issues would need to be addressed before this product could be brought to market.
Many possible resolutions exist to the biggest ethical issue in our design; the idea that our device would encourage binge drinking. The most obvious one would be to limit, in software, the number of drinks any one person could purchase in an hour. The algorithm could be made as complex as looking up the persons registered weight and limiting based on the well accepted norms, or it could be as unforgiving as a hard cutoff. As well, a physical device to check the purchaser’s blood alcohol level could be added, although this would just add more time to the process. Another option would be to have an employee man the machine at all times and deny anyone alcohol that has already been to the machine enough. But in the end, this issue is made moot by the fact that most people drink at bars together, and his or her acquaintance could always buy him or her more drinks. Even with the smartest algorithm, it would not be much of a challenge for the customer to find liquor, but an honest attempt would still need to be made to correct this issue.
The issues of both underage drinking and selling to an already impaired person could both be resolved by an employee at the machine, as mentioned earlier. This employee could card every user before the device is approached, checking not only their age, but their impairment level. More unrealistic resolutions could be made. Something as simple as an ID scanner could work, and more futuristically, a fingerprint or retinal scanner might get the job done, but most of the technological resolutions could be easily overcome.
As well, the idea that a customer could leave the bar and attempt to drive home under the influence after using our device is another concern. As the device ultimately uses as little human-to-human interaction, detecting when a customer has had too much to drive would be tough. Although this issue isn’t solely related to our device, as a customer could just as easily leave without being detected even with bartenders, it does increase its likelihood.
Another ethical issue that needs to be looked at is the safety of the user’s account information. Privacy is something that can’t be overlooked. Information such as name, balance, and purchase history will be stored on a central database located somewhere else in the bar. In order to protect this information, encryption algorithms could be implemented on both ends of the connection to ensure that the information is safe. This would effectively eliminate any possible “man-in-the-middle” attacks, as the information would be useless without the appropriate decryption key. The database itself could be protected by a password that only the bar owner knows, which would help prevent any information to be stolen that way.
The easiest resolution to all of these issues, although maybe not the cheapest, would be to require all bar owners who use our device to have a security team that monitors the entrance to the bar, as well as the use of the machine. On the way in, customers would be carded and marked in some way to show they are of age, and on the way out, these same employees would be able to make sure someone who is obviously impaired does not attempt to get behind a wheel. An employee at the machine could double check each customer’s ID before use, or they could just monitor the impairment of each user. In addition, warning labels can be applied to the device that state the consequences of drunk driving as well as the health hazards of alcohol poisoning. Making the customer aware of these things could persuade them to bypass any of these measures. None of these resolutions are fool-safe, but the product gains a lot of appeal if these improvements were to be made.
3. Environmental Impact Analysis
During its lifetime, the Inebriation Station will leave some kind of an impact on the environment. According to the EPA, the manufacturing of the electronics and circuit boards will consume “valuable resources, such as precious metals, copper, and engineered plastics. [21]” Throughout its normal lifetime, the possibility of harmful ozone depleting substances or green house gases being released by the refrigeration unit exists. And after the units life cycle has passed, the hazardous materials contained throughout the device must be recycled properly.
In order to mitigate some of these concerns, we chose as many RoHS compliant devices as was possible. This ensures that the creation of the components was regulated and no restricted materials were used [22]. This does not mean, however, that no hazardous materials were used. Most PCBs, for instance, contain lead. There is the option of using more eco-friendly PCBs that are created with no such materials, but they usually cost a decent amount more. In order to keep the cost of the device down, this concern must be attacked at the end of its life cycle rather than at the beginning.
Throughout the normal life cycle of this device, the possibility exists that potent green house gases and CFCs could be released into the atmosphere. Since the issue exists in all aspects of refrigeration, this is not completely specific to our design, but precautions can still be taken to ensure that this possibility is decreased. In the user manual, explicit warnings could be placed to make sure the user is aware of this possibility and of any potential environmental consequences if this were to happen As well, proper handling instructions could be given to decrease the chances of the device breaking. Installation options could be made available to ensure proper care during delivery and setup. Any of these would help reduce the chances of these gases being released.
At the end of its life cycle, the device must be recycled properly to ensure none of the hazardous materials are left in landfills. The EPA requires that any appliance be properly disposed of to prevent the release of any of the gases or materials used in its creation [23]. This would include, obviously, the freezer chest. The EPA suggests calling your local municipal public works office to inquire about safe disposal for any appliance or electronic components. In this case, for our design, we could simply relay this message to the owner of the device in the user manual. A printed warning on the device itself could also prove helpful for this cause. In the end, it would be up to the owner to do his or her part and safely dispose of the unit.
Although it seems like this design leaves a negative impact on the environment, there is one aspect that must be considered before a verdict is reached. Through the use of personal cups to identify each user, and the use of kegs to supply the beverage, resource conservation is practiced. If more of the bar’s users were to use our device, the number of discarded beer cans and bottles, as well as plastic cups, would reduce dramatically. Therefore our design promotes good practices and resource conservation. The swing in the positive direction would hinge solely on the number of users who used this device.
4. Summary
The Inebriation Station was designed around the idea of speeding up lines at bars. Less time spent in line usually means better times for the customers, but it may also mean more binge drinking. The removal of human-to-human interaction at the point of sale may give rise to more underage drinking problems and DUIs. Potential hazards exist from the environmental standpoints as well. CFCs, which are known ODS and GHGs, are found in the refrigerant of the freezer chest, and any improper handling that results in their release will be bad for the environment. Proper recycling must practiced to ensure none of the hazardous materials end up in land fills. Resolutions have been presented for all of these issues, but in the end, it will be up to the user to be responsible and for the owner to do the right thing. If either of these things doesn’t happen, our device may be seen as an ethical or environmental mistake.
6. Packaging Design Considerations
1. Introduction
The Inebriation Station is an automated beverage dispenser that also keeps track of the users’ account history with an RFID Reader communicating wirelessly via Wi-Fi to an onsite computer. In addition, the wireless module also transmits information about the unit (i.e. temperature and keg fill level). Our packaging is clean and simple, it will be a large unit with a single spout attached to the surface along with an LCD and keypad where the user can view their personal information, as well as make a beverage selection.
2. Commercial Product Packaging
There are three commercial products that offer similar features that the Inebriation Station has. The three products are the “Draft Beer Counter” from Alcohol Controls [24], “TapAdvisor” from TapDynamics [25] and the “Inventory Control System” from US Beverage Net [26].
1. Product #1
The Draft Beer Counter is a very small and simple device that runs on a 3V Lithium battery and is used to keep track of the amount of ounces that is dispensed from a keg. The installation is quick and easy. All that has to be done is replace the old beer tap with the Draft Beer Counter and it starts working immediately. The information on the website () had very limited information on the product and didn’t say how long the battery life of the product was. However, the lack of information shows that the product is very user friendly. I felt that this product was similar to the Inebriation Station because it offers the feature to inform the bartender how much alcohol is being dispensed in a given time.
The only positive features to this product is that it is compact, easy to install, and is user friendly. However, the positive features are highly outweighed by the negative, which shows how obsolete this product is. For starters, the unit is powered by a battery. Since the battery is Lithium, it may last around 8 - 10 hours assuming the unit is in constant use throughout the day, but there may be issues with the counter dying out in the middle of business hours without the user knowing, which throws off all the data. Furthermore, giving the benefit that the battery is rechargeable, frequent charging of the battery decreases its life cycle. Therefore, cost of the unit’s maintenance can accumulate over time. Another negative is that the bar attendant doesn’t have real-time information of how much is being dispensed. The counter is used to keep track of the number of ounces dispensed throughout the entire day and is then checked for the total amount after business hours. The data on the counter is then inputted to a programmed excel sheet (provided by the company), which allows the user to compare the amount of ounces sold to the amount dispensed. Thus, instead of allowing the user to view the necessary information in real time on a user interface throughout the day, they can only see it at the end of the night and will have no idea what caused the data to be skewed. With the Inebriation Station, the bartender will have the capability to view real-time information on the kegerator unit, as well as be able to detect and correct any anomalies in the data right away. In addition, the Inebriation Station isn’t battery powered, thus guaranteeing its functionality throughout business hours.
2. Product #2
The TapAdvisor appears to be a more advanced product than the Draft Beer Counter. They have similar features except TapAdvisor provides the user with real-time data from the “TapAdvisor Web Portal”. The web portal can be accessed from any computer connected to the internet, which also includes smart phones. This gives the user much more flexibility in terms of having the ability to check on the dispensing units anytime, anywhere. The TapAdvisor is installed and setup by TapDynamics. The whole system consists of just two components: the TapAdvisor Appliance (Left) and Flow Meters. The Flow Meters are installed onto the faucets, which communicates with the TapAdvisor Appliance streaming information illustrating how much liquid is being dispensed. The TapAdvisor Appliance sends this information to TapAdvisor’s server and then views the data on the web portal on a “Daily Draught Beer Score Card”, which can only be accessed by subscription. Just like the Draft Beer Counter, it allows the user to compare the amount dispensed to the amount that has been sold. Moreover, the TapAdvisor also provides information on the temperature, line pressure and cleaning activity of the user’s inventory.
The main positive for this product’s packaging is that the parts are compact and there aren’t many that need to be installed. The only components that need to be implemented are the flow meters that communicate wirelessly with a Tap Advisor unit that sends real-time data to a central server. In addition, the installation and system integration doesn’t have to be done by the consumer; it’s all done by TapDynamics. One aspect that really stands out is that the product can be implemented to any already existing dispensing unit, which makes the product more marketable. That would be a nice perk to have with the Inebriation Station, but it involves having a unit that can be operated bartender free. In turn, if we were to make the Inebriation Station capable of being installed to any existing dispensing unit, there would be more parts to be installed and the integration process would be much more strenuous due to the additional features offered. Product #1 and #2 both need the bartender to serve the customers, which makes our project unique in comparison to them.
From what’s documented on the website () there aren’t any negatives to the product in terms of its’ capabilities. The system is compact and the method of installation prevents it from being damaged in any way, therefore durability should be of no concern. The cost of the unit isn’t explicitly stated on the website, but based its nice features and services provided, it will have a price to match. It provides most of the features our project does except it doesn’t automatically charge the customer for the beverage and pour a specified amount without the need of the bartender.
Product #3
US Beverage Net’s inventory control system is another monitoring system that operates similarly to the TapAdvisor. They both have Flow Meters that are connected to each of the beer lines and communicate to a unit that transmits the data to the company server. The unit that US Beverage Net uses is called the USBN bevBox and it works with the POS (Point-Of-Sale) system within the location to send real-time data to the USBN server where the user can access the information via computer or smart phone. However, there are some feature differences between this product and the TapAdvisor. USBN has a feature that allows the user to not just know the amount of draft poured vs. the amount sold, but keep track of the inventory also. The user can manage the inventory from a computer or smart phone and order more if needed. Then, after the order has been made, the user will be notified when it has been received. On the other hand, USBN doesn’t currently offer temperature, pressure and cleaning activity updates like the TapAdvisor does, but the website states that it will be implemented in the near future.
Similar to the TapAdvisor, the major positives for USBN’s product are that it is compact and can be installed on any existing beverage dispensing units. Although, in comparison to the Inebriation Station, the product’s main user is the bartender. What makes the Inebriation Station unique is that the main users are the customers purchasing the beverage, which completely eliminates the need for the bartender altogether. In addition, our unit is able to monitor and regulate the ambient temperature of the inventory using temperature sensors controlling a relay that triggers the power of the refrigeration unit.
3. Project Packaging Specifications
Due to the size of our project, we don’t have any constraints so it’s quite simple. All the solenoid valves and tubing will be place neatly within the freezer unit completely hidden from the user. The four tubes running from the kegs will come up and out a hole drilled in the freezer lid and be enclosed a single spout. The PCB and the other components have a large operation temperature range, making it possible to also mount the PCB within the freezer. Also, to insure no condensation forms and damage the components, a conformal coating can be added over the PCB. A keg is typically kept cold between the temperatures 38 - 40º F [27]. Currently, the only components that we are planning to mount directly onto the PCB are the wireless module and the relay. The operating temperature of the wireless module is 0 - 70º C (32 - 158º F) [28] so it is capable of functioning in the freezer. We’re not sure what relay we are going to purchase, but by looking through the relay choices on Digikey, there are more than enough to choose from that are capable of operating in the freezer conditions. It should also be noted that we will be using a relay only if we are unable to figure out how to control the thermostat in the freezer by direct connection to the MCU. All the other components (LCD, Keypad, IR Sensor and RFID Reader) will have wires running from the PCB to the outside surface of the freezer, therefore there is no need for concern of their operating temperatures (assuming room temperature isn’t outside their operation range).
Currently, our main concern with mounting the PCB in the freezer is having condensation occur and ruin the PCB whenever the lid is opened for some time to do maintenance on the unit. Our solution to this problem is having a plastic enclosure with small holes to cover the PCB and still have the capability to run wires. Although, if we feel that will not sufficiently protect the PCB, we are also considering placing the PCB on the outside of the freezer unit and keep it in an enclosure. Our next concern deals with the peripherals that will be mounted on the outside surface of the freezer. We are worried that with all the liquid that will be flowing along the surface, that there is a large possibility that the equipment will get wet and ruined. Before, we wanted to have the LCD/Keypad combo, although to prevent the equipment from being damaged we have to go with two separate units. Our plan right now is to have a rubber keypad that will be exposed for the user to punch in a selection and have the LCD screen protected by a piece of plexiglass placed evenly across the entire surface of the freezer. This will allow the user to input and view their selection while keeping the equipment protected from any damage. In addition to the LCD screen, the RFID reader will also be kept safe under the plexiglass by the spout where the user will place the cup. The cup will contain the user’s RFID tag. The cups we will be using have an exposed RFID tag pasted to the bottom of a cup. However, if we were to market the Inebriation Station, the RFID tag would be melted into reusable plastic cups.
When considering these packaging ideas, we thought since the wireless module and RFID Reader had solid surfaces all around them, that their signal may be weakened. However, we found that RFID Readers can read tags through skin [30] so we assumed that it would be perfectly fine under plexiglass. Also, the wireless module’s signal will not be affected because it has 802.11b wireless networking, which has signals fully capable of operating through walls and floors. [29]
Note: The CAD drawing was made assuming we used the minimum size requirements of a internal dimensions of the freezer (19 inches wide, 19 inches deep, 31 inches tall) to fit 4 sixth-barrel kegs and solenoid valves.
7.4 PCB Footprint Layout
The components that will be surface mounted onto the PCB are the PIC24FJ128GB108 MCU, the ZG20101M wireless module, voltage regulators, level translators, keypad controller, capacitors, resistors, inductors, two female socket for 12V power supplies, and different size headers. The headers will be used to connect to the LCD, keypad, RFID Reader, IR sensor and solenoids. In addition, for expansion purposes, there will also be a large header connection for the I/O pins that we won’t be using.. The reason we have two female sockets are for the 12V power supply going directly to the solenoids sand the 12V power supply that will be regulated to 3.3V and 5V. Originally we were going to use one, but we were told that the large amount of current being drawn by the solenoids may cause noise in the signals being regulated. The solenoids will be powered only one at a time for a short period. In turn, we had to add components to switch them on and off. The power switching circuitry for the solenoids will consist of optically isolated transistors as mentioned in lecture.
Since there won’t be many large components on our PCB, we won’t have to use the given area of 60 square inches. Instead, we will use a 6 x 6 inch PCB as shown in Appendix C, which gives us more than enough space for all the necessary components. It can be seen in Appendix C that the relay and the solenoid circuitry are isolated from the other components. The relay and solenoid circuitry is isolated because they will be drawing large amounts of current, which can create noise that will affect the digital logic devices. Originally, the wireless module was positioned with the antenna off of the PCB because we were going with a module with an integrated PCB antenna. In turn, we had to follow module layout guidelines provided by the datasheet, which defines the areas of the module where there shouldn’t be any planes or traces underneath. If these guidelines weren’t followed, the signal of the antenna could be compromised. However, we recently decided to use an external antenna to increase the range of the signal by 10 times more. This also allowed us to make our PCB smaller since we weren’t limited by the guidelines.
5. Summary
It can be seen that there is no commercial product quite like the Inebriation Station. It offers similar features in comparison to the top-of-the-line products, but has more to eliminate the need for a bartender. Though our packaging is large, it is user friendly and makes the beverage distribution business faster, easier, and more enjoyable.
7. Schematic Design Considerations
1. Introduction
The Inebriation Station is a microcontroller-driven, standalone beverage dispenser that interfaces with a customer without continuous human vendor support. A customer places his cup in an indentation under the beverage spout and breaks an infrared beam which communicates with the microcontroller using a standard I/O pin. The beam break triggers the microcontroller to initiate a read from the RFID reader with a standard I/O pin, and the RFID tag on the bottom of the customer’s cup is read. The RFID reader returns the RFID tag number to the microcontroller through UART. Upon receiving the tag number, the microcontroller sends the RFID tag number to a wireless card through SPI, and that wireless card sends the data to a computer on the standard 802.11 protocol. The wireless card then receives user and beverage information from the computer and sends that data to the microcontroller through SPI. The microcontroller displays information to the customer on an LCD through a UART interface. At the same time, the microcontroller accepts user input on a keypad which communicates through an encoder in parallel. After the customer makes a selection, the microcontroller opens a solenoid with a standard I/O pin to allow the correct beverage to pour the correct amount.
2. Theory of Operation
The Inebriation Station has four discrete power nets. Two discrete wall-warts are used to produce two different +12VDC @ 1A supplies on board. Since the solenoids draw 575mA of current when on and negligible current when off [31], a voltage spike will likely be seen on the +12V line when switching which could negatively impact logic circuits. For that reason, one +12V wall-wart is used solely to power the solenoids and the fridge switch, and the other wall-wart is used to supply the logic voltages. The wall-wart supplying the solenoids is not regulated on the board as the solenoids can operate from 10.6-12.6V and still allow fluid to flow at its full rate [32]. The other +12V wall-wart feeds into two switching regulators, an LT1767-3.3 and an LT1767-5, to supply the logic voltages for the rest of the circuit components [33]. A 12V wall-wart is utilized to meet the current demands of all of the logic circuitry, including the IR LEDs, relay, LCD backlight, microcontroller, and Wi-Fi module.
If a customer is not interacting with the Inebriation Station, the only peripheral components being used are the four temperature sensors, which are all TI TMP175. The microcontroller polls the four temperature sensors every minute and averages the temperature for a more accurate reading. Each temperature sensor is given a unique 7-bit I2C address by pulling certain pins high or low. The I2C interface is used so that many (up to 27 for the TMP175) temperature sensors can all be connected on the same I2C bus [35]. Since the TMP175 can operate from 2.7-5.5V while the PIC24FJ128GB108 only operates at 3.3V logic, all of the temperature sensors are operated at 3.3V [35],[36]. This prevents the need for level translation of the signal between the microcontroller and the temperature sensors, allowing the microcontroller to communicate with the sensors directly. The I2C bus is run at 100kHz since that is the lowest frequency explicitly stated in the PIC datasheet, and the TMP175 can operate up to 3.4MHz[35],[36]. Since 100kHz will transmit the 9-bit temperature reading in a negligible amount of time, reliable data from each temperature sensor is more important than speed. Finally, the temperature sensors are run at 9-bit resolution to minimize the internal A/D conversion time (27.5ms) [35]. A 9-bit resolution achieves a .5°C temperature resolution, which is sufficient for monitoring a refrigerator’s temperature [35].
The IR beam-break sensor is a simple transmitting IR LED that is always on, and a receiving IR photo-transistor that has a 10kΩ connecting its collector to power. When the beam exists, the receiver will drive current across the 47kΩ resistor and produce a logic 1. When the beam is broken, it produces a logic 0. The circuit is driven by 5V to ensure that the input high threshold on the microcontroller is met since the output for a logic 1 can be ~1.3V lower than the driving voltage. The sensor is interfaced with a general purpose I/O pin that can handle 5V input logic to ensure a pin will not be burnt out.
Once a cup is detected by the IR sensor, the microcontroller use a general purpose I/O pin to drive the enable pin on the Parallax RFID reader low, turning the RFID antenna on [38]. Two successive 12-byte tag readings are taken by the RFID reader and sent to the microcontroller through UART at 2400 baud [38]. While 2400 baud is not a chosen value, it is sufficient to appear seamless to the user since the data from the two successive reads can be transmitted through UART to the microcontroller in 0.1s. The data sheet does not specify the time taken to actually transmit power to the tag, read the tag, and decode it, but it is likely much longer than the time it takes to transmit that data through UART, further demonstrating that 2400 baud is sufficient. Since the RFID reader operates at 5V, and the microcontroller operates at 3.3V, a bi-directional level translator (MAX3001E) sits between these two components. The level translator can operate at 4Mbps, so 2400 baud is an acceptable data rate [37].
At this point, the microcontroller sends the RFID tag number to the wireless card (ZG2101M) which communicates with an off-product database through 802.11b protocol. That database sends back beverage and user data to the wireless card. The wireless card can operate at 1Mbps or 2Mbps [39]. Since 1024 bits is the most data ever sent or received at one time (80 bytes for 4 beverages, 16 bytes for 4 fill levels, and 32 bytes for user information), the wireless card is configured to operate at 1Mbps, and will be stepped up to 2Mbps after it is proven to work at 1Mbps. At this rate, the largest data packet will transfer in 1ms. The microcontroller and Wi-Fi card communicate through SPI. While the wireless card SPI can operate at a baud rate up to 25MHz and the PIC24F can operate its SPI up to 8MHz, the SPI interface between the microcontroller and the wireless chip is operated at 100KHz to ensure enough time (640 microcontroller cycles) for the data to be read out of the SPI receive data registers to ensure data is not lost[36],[39]. Again, the largest amount of information transferred (1KB) will still be able to be transferred in 10ms. Because it takes 50ms to wake the wireless card out of hibernation, a general purpose I/O pin goes low to wake the wireless card as soon as the IR beam-break sensor is activated. The wireless card is put back into hibernation by pushing that pin high only after the entire user transaction is complete, and the Inebriation station is waiting for a new customer. Moreover, the wireless card has access to an interrupt pin on the microcontroller so it can tell the microcontroller to start reading in data through the SPI.
To display the retrieved data to the user, the microcontroller uses UART to communicate to a Crystalfontz LCD. The LCD is capable of receiving data with RS-232 or “inverted RS-232” [40]. Inverted RS-232 is the standard 0-5V UART logic output by most microcontrollers, and is how the Inebriation Station’s microcontroller is configured to communicate with the LCD. Like the RFID reader, a level translator is used to translate the 3.3V logic to 5V logic. The fastest baud rate of the LCD (19200 baud) is selected since, at that rate, it already takes 40ms to refresh the 80 character screen. Any slower of a refresh rate may be detectable by the customer.
The user communicates with the microcontroller through a 20-key keypad interfaced with an MM74C923 key encoder. The MM74C923 is configurable through modification of decoupling capacitor values [41]. To correctly de-bounce the input, capacitors were selected that would scan the keypad every 1ms and would require a key to be pressed for 10ms to be registered as a key press [41]. The encoder interfaces through parallel to the microcontroller with 5 general purpose I/O pins and 1 interrupt pin [41]. The interrupt is used to tell the microcontroller that data is available, and ensure that the data is read before it is cleared. Attempting to give the user more options, two general purpose I/O pins are controlled by pushbuttons for “Beer Me!” and “manual pour.”
The solenoids can operate at a variety of different supply voltages, from 12V-240VDC or 120VAC-480VAC [31]. The solenoids in the Inebriation Station operate at 12VDC because 12V is a readily available wall-wart. Furthermore, relative to 240V, 12V minimizes the total potential seen on the PCB, and is easier to switch with a simple n-MOS device. The AC powered solenoids were avoided because they are more difficult to switch on and off with solid state devices, and the AC signal tends to create noise. Each solenoid is switched on by a power n-MOS device (IRF510) which has its gate tied to a general purpose I/O pin on the microcontroller. The n-MOS device allows the low-current, low-voltage I/O pin to turn the 575mA, 12V solenoid on and off [34]. The solenoids are normally closed, and open for a specified amount of time to allow a specified amount of beverage to flow into the customer’s cup.
As a final note, all logic signals sent off-board are sent via shielded wire grounded near the microcontroller to prevent interference and to prevent ground loops.
3. Hardware Design Narrative
For the Inebriation Station, input and output is the most important function of the microcontroller. The internal oscillator of 8MHz was selected as the clock for the microcontroller [36]. To determine the clock rate of the microcontroller, the most cycle intensive interrupt needs to be determined. Though all of the software has not yet been written, it is reasonable to assume the longest interrupt should last less than 500 cycles. The fastest data being sent/received by the microcontroller is the SPI interface to the wireless card at 100kbps or 12.5kB/s. Therefore, if a clock rate of 8MHz is chosen, any interrupt should be fully serviced at 16k-interupts/s, leaving plenty of time to read/send more bytes to the wireless card through the SPI between interrupts. Furthermore, the internal oscillator of the PIC24FJ128GB108 natively runs at 8MHz, making 8MHz an even more “natural” choice [36].
Microcontroller pins are selected to try to use only two sides of the microcontroller so all of the headers can be located on one or two sides of the PCB. From there, pins going to the same peripherals are located as closely to each-other as possible in the order they are presented on the header so that traces on the PCB can be run in parallel, minimizing vias. A final consideration was that any input pin that received 5V logic needed to be routed to a pin capable of receiving 5V. A list of pins used can be found in Appendix A.
4. Summary
This report summarizes all of the operating considerations for each of the major components in the Inebriation Station. The major peripherals as well as their supply voltages, their operating frequencies, and their interfaces are thoroughly covered in Section 2.0. The microcontroller frequency, pin selection, and interface choices are covered in Section 3.0. As seen in this report, each component operates at the slowest, most reliable frequency acceptable to appear instantaneous to the customer, and operates as close to the microcontroller supply voltage as possible.
8. PCB Layout Design Considerations
9.1 Introduction
The project requires several external interfaces to interact with the user. These interfaces include the RFID reader, LCD display, 20-button keypad, and various pushbuttons. The project also requires 4 solenoid valves that can be electronically opened and closed, 4 temperature sensors used to monitor the refrigerator ambient temperature, and an electrical switch to power on and off the fridge. For the purpose of conveniently having all logic signals close together, it’s good to use a PCB. A PCB allows one to place ICs (which need to communicate often with the microcontroller) as close to the microcontroller as possible, and in an organized fashion.
When designing a PCB, there are many things to consider, such as component placement, trace widths, separation of analog and digital signals, and EMI interference. In this document, the team’s specific PCB design considerations are outlined.
2. PCB Layout Design Considerations - Overall
The key considerations taken during the design process of the PCB is placement of components. Headers used to link external peripherals with onboard peripherals are placed on the outermost edge of the PCB to avoid unnecessary clutter in the central region of the PCB while leaving enough room for power rails. Adequate spacing in each corner of the PCB is given for placement of mounting holes. Components that belong to a specific functional block (ie. voltage regulators, WIFI module, level translators) are placed in the same relative location to minimize trace lengths and allow for sensible routing.
On the PCB, there is a clear division between power circuitry and the WIFI module. Since there is no recommended minimum distance, the power and WIFI module were simply placed on opposite sides of the PCB. This is to prevent the switching of the step-down voltage regulators from interfering with the WIFI signal and vice versa. There is a keepout region that coincides with pins 16-18 on the WIFI module that should be devoid of traces (with the exception of escape traces for pins 16-18), vias, and ground plane, to minimize RF dispersion. The suggested area of the keepout region is 25 x 19.05 mm [43]. The microcontroller itself is placed in a central location on the PCB and oriented such that bus traces have a direct path from microcontroller pin to their designated peripherals.
More general concerns such as trace width, location of vias, and acute angles must also be met. Acute and right angles are avoided because they can cause acid traps and EMI noise. Traces for high current components are intended to be 50-70 mils while traces used to carry logic signals are intended to be 10-12 mils. Vias should be placed sufficiently far away from pins to prevent accidentally shorting them. High frequency analog signals should also be kept far away from power circuits to prevent switching in the voltage regulators from adding EMI noise to analog signals. The grounds for analog and digital components should also be separate to prevent EMI noise. Digital and analog grounds should only be tied together at a single point.
The size of the PCB is not a concern because there is plenty of space inside the refrigerator to store the microcontroller. Some type of insulation would be required to protect the microcontroller from potential ice build-up due to condensation inside the freezer. If a decision is made to have the PCB outside of the refrigerator, doing so would not be an issue because the current size of the PCB is roughly 2” by 4”. This is nowhere near the limit of 60 square inches, and we will increase the size of the PCB if it is needed.
3. PCB Layout Design Considerations - Microcontroller
The microcontroller is placed centrally between the power and WIFI circuitry. Decoupling capacitors are placed as close as possible to their corresponding power and ground pins on the microcontroller to ensure faster response from the capacitors. The microcontroller and the peripherals surrounding it are placed to allow large data buses to have a direct path between microcontroller and peripheral.
In the team’s first submission of the overall schematic, a set of pins was tentatively chosen for the overall schematic. These choices were based solely on choosing valid pins given the microcontroller’s capabilities. However, when designing the PCB itself, it was discovered that the original set of pins chosen for microcontroller peripherals caused an unnecessary crowding of traces along the top row of pins, and also created some inconvenient routing situations such as crossing of trace paths. Due to these reasons, many of the peripheral pin locations were changed to fit the current layout of the PCB. The following changes were made:
The GPIO pins used for switching the refrigerator and solenoid valves on and off were moved to pins 4-8. This allows signals from the microcontroller to feed directly to the level translator on the left side of the board without having to route around the keypad encoder bus or use an excess number of vias. The LCD and RFID UART lines were moved to pin 17-18 and 20, respectively, for the same reason. Pins 2-3 are reserved for an additional I2C line (not currently padded out), and pins 35-43 are padded out because they are programmable pins that can be used for additional UART, SPI, or general I/O [45]. The UC_UART lines, intended for debugging the WIFI module, were moved to pins 27-28 to avoid crowding on the right side, which already has 6 pins reserved for WIFI, 2 for the temp sensor I2C lines, and 2 for the oscillator circuit. This rearrangement allows for of the UC_UART pins to be closer to its corresponding header. The WIFI bus pin order has been reversed to avoid trace crossings. The BEER and FILL I/O pins were moved to pins 62 and 61 to be closer to their respective headers.
Regarding the external oscillator, the datasheet for the oscillator circuit suggests that the crystal and its associated passive components (resistors, capacitors) should be as close to the OSCI/OSCO pins as possible. The oscillator circuit and pins should also be surrounded by copper pour to reduce EMI noise. In the event that our design requires actually using the external oscillator, the resistors and capacitors will be set such that the crystal oscillates at 8 MHz. This is the speed the microcontroller’s internal clock is set to run at.
Lastly, the microcontroller is not used to provide a high current source to any device, so all traces connected to the microcontroller are only 10 mils. The size of the microcontroller also prohibits having traces much larger than 10 mils, because increasing the trace size to anything larger than 15 mils causes clearance problems. Trace size for logic signals will be made as large as possible given the clearance constraints.
4. PCB Layout Design Considerations - Power Supply
The overall circuit draws power from 2 separate 12V wall warts connected to two female DC barrel jacks. One is used to drive the solenoid valves, and the other is connected to two voltage regulators (3.3V and 5V) which are used to provide TTL voltage levels. The solenoid valve and refrigerator switching circuit require 5 power MOSFETs. Although the MOSFETs can be switched on using 3.3V, the team felt it would be safer to use a 3.3V to 5V level translator to send a strong 5V signal and ensure proper switching. This is due to the fact that if our wall warts were to provide more than 12V (16V for example), more voltage than what is desired may appear on the drain end of the NMOS, causing it to go into saturation mode rather than linear mode (linear being the mode which the NMOS appears to be ‘ON’). The data sheet also specifies the gate voltage should be 5V to achieve the device rated ON resistance. The level translator is placed in between the 3.3V and 5V regulators. The level translator requires both a 3.3V and 5V reference voltage in order to function. The level translator provides ESD protection for the microcontroller [45]. Bypass capacitors are placed directly beneath the chip as they are for the microcontroller to minimize trace distance while saving space on the mounting side of the board for signal traces.
While the MOSFETs used for switching the solenoid valves may be required to sink over an amp of current [49], the team does not anticipate requiring external heat sinks for the MOSFETs for two reasons. The first reason is that the MOSFETs we have chosen (IRL530 Power NMOS) can handle a drain current of 11A at 100C. The second reason is that only 1 MOSFET will be sinking current at a time, and this only happens when a beverage is being dispensed (infrequently from the point of view of the MOSFET). Therefore, the team does not feel external heat sinks are necessary. Since the size of the voltage regulator is 118 by 193 mils [46], copper pour is used for both voltage regulators to absorb heat.
As far as traces are concerned, a ground plane will be used to ground components while minimizing the lengths of traces to ground. Clearance issues occur while attempting to increase the width of the power and ground traces (using the auto-router). This means that while the general placement of each power-related functional block remains roughly the same, careful placement of components in their relative areas must be considered in order to satisfy the power trace width of roughly 40-60 mils, a safe range suggested in the course lecture notes. The trace width calculator provided by 4PCB suggests only 11.8 mils are required to sink 1A on an air layer at 25C [55]. This means that 40-60 mils will be plenty for the amount of current that will be running through any of our power traces (roughly 500-700 mA for the 12V wall wart sourcing logic and 500 mA for the 12V wall wart sourcing the solenoids).
1. Potential Consequences
Since several devices will be using the level translator (RFID reader, LCD, MOSFETS), it is important that the team understands how a level translator functions when interfacing with different logic devices. If the level translator does not work as intended, the power MOSFETS must be able to turn on using a 3.3V gate voltage or different MOSFETS will have to be chosen. The other components using the level translator (LCD and RFID reader) have a number of options. The LCD reader is 3.3V tolerant so sending data straight from the microcontroller to the LCD is feasible. The RFID reader operates at 5V, so if the level translator does not work, the receive lines for the RFID reader can simply be moved to one of the 5V tolerant pins on the microcontroller, which have been padded out incase such an event arises.
5. Summary
This report explains the rationale behind the team’s PCB layout. The introduction explains which components should be logically placed on the PCB. Section 2.0 goes into general layout considerations such as the motivation behind placing each functional block where they are and general PCB considerations. Section 3.0 explains the microcontroller considerations, specifically related to placement among all the other peripherals. Section 4.0 details power considerations, with emphasis on safely driving the solenoid valves and refrigerator on the PCB.
9. Software Design Considerations
1. Introduction
The Inebriation Station is a digitally controlled kegerator that allows a user to “log-in” to an account, select one of four different beverages as well as a size or quantity, and have it automatically dispensed into his or her personal cup. The system is built on top of the PIC24FJ128G family of microcontrollers from Microchip, and makes use of many its different peripherals [56]. Two UART modules are used for an RFID reader and an LCD. One SPI module is used for a Wi-Fi card. The I2C module is used for four temperature sensors. As well, various GPIO pins are used for buttons or triggers, and various timers used to control rates and flows, as well as providing interrupts for system monitoring. The application code is organized into an interrupt-driven, polling loop hybrid, as aspects of both designs are included.
10.2 Software Design Considerations
10.2.1 UART2 – LCD
The first device that the user will notice on the project is the LCD. This, in combination with the 20-button keypad, makes up the User Interface. It interfaces with the PIC24F via one of its four UART modules, specifically, UART2. Since the chosen LCD never sends data from its onboard MCU to the PIC24F, only the UART2’s Tx pin is required for communication. This pin is accessible through port RF5. Initializing the UART2 module is fairly simple, as the only two bits that need to be set high are UARTEN in the U2MODE register and UTXEN in the U2STA register. All other bits are set low. These two bits, respectively, enable the module itself as well as its Tx line.
10.2.2 GPIO – Various components
The PIC24F microcontroller supplies many GPIO pins that are used for various components in the system. The most important being the keypad encoder. It makes use of six of these GPIO pins, all currently located in the PORTD register. Coming from the encoder are a Data Available line which uses port RD10, as well as five encoded bits. Starting with the most significant bit, these bits use pins D8, RD6, RD4, RD2, and RD0. Initialization of these pins as inputs on the PIC24F only requires the ports respective bits be set low in the TRISD register.
Another GPIO pin is used by the IR break beam to let the system know that a user has placed a cup under the spout. Essentially, this will act as a push button and will be input to the PIC24F through port RG14. As before, to set this pin as an input, bit RG14 in the TRISG register must be set low.
Four more GPIO pins will be used to open the four solenoids that will control the dispensing of the beverages into the user’s cup. These pins are located in the PORTD register and use pins RD1, RD3, RD5, and RD7. Since these pins will be used to power the MOSFETs that ultimately open the valves in the solenoids, they must be set as outputs. To do so, the respective bits in the TRISD register must be set high.
The last GPIO pin is used to enable RFID reader. When it is set high, the RFID reader will begin searching for a compatible RFID tag within its range. Currently, port G12 is used as the output to do this. Again, the respective bit in the TRISG register must be set high to achieve this.
10.2.3 UART1 – RFID Reader
The RFID Reader is integrated into the system through the PIC24F’s UART1 module. Much like the LCD, it only makes use of one of the modules pins. But unlike the LCD, the RFID Reader will send data to the PIC24F; therefore UART1’s Rx pin will be used. This pin is found in the PORTF register and uses port RF2 to receive serial data from the reader. Initialization of this module consists of setting the UARTEN bit high in the U1MODE register. All other bits in this register, as well as in U1STA, are set low.
10.2.4 I2C1 – Temperature Sensors
Four temperature sensors are used to regulate the refrigeration unit that the system will be built in to. These four sensors will be linked together on a single I2C module on the PIC24F, and will use two pins in the PORTG register for the module’s SCL and SDA lines. These pins will make use of ports RG2 and RG3. To initialize the module, two bits in the I2C1CON register must be set high; specifically the ICEN and DISSLW bits. These bits enable the module itself and disable slew rate control. All other bits in this register are set low.
10.2.5 Timers1, 2, and 3 – Various System controls
The system also uses three timers to control various functions. Both Timer1 and Timer2 will be configured to interrupt the system every one millisecond. In order for this to happen, both of the timers’ TCKPS bits located in registers T2CON and T1CON must be set to 01b. This sets the timers’ prescalers to 1:1, essentially counting every one clock cycle as one count. Using this prescaler requires that both the PR1 and PR2 registers be set to 4000 in order to have the interrupts fire every one millisecond. To enable these timers’ interrupts, bits T1IE and T2IE in the IEC0 register must be set high and each timer must be assigned a priority. Timer1 is set as the highest priority, with Timer2 being the third, or lowest, priority. This is done by setting bits T1IP and T2IP in the IPC1 register to 1 and 3, respectively.
Timer3 will be configured in Gate Accumulation mode, where it will count the number of cycles that a certain input is held high. This is done by configuring Timer3 just as Timer1 and Timer2 have been, with its own registers, and then setting bit TGATE in the T3CON register high. The timer will then count the time that the TCK pin in the T3CON register is held high. This pin can be found in the PORTC register at port RC3.
10.2.6 SPI1 – Wi-Fi Card
The backbone of the project is its Wi-Fi card which will provide all of the user account data as well as other vital system information such as beverage fill level. The Wi-Fi card is integrated through the PIC24F’s SPI1 module. This requires five pins in various registers. The module’s CSN pin can be found in the PORTB register at port RB2. Pins SCK, SDO, and SDI can be found in register PORTF at ports RF6, RF7, and RF8, respectively. The last pin is located in register PORTE at port RE8 and is the INT_NX pin.
10.2.7 Application Code Organization
The code for this project will be written in C using the MPLAB IDE and the C30 compiler, both from Microchip. The code is written to make use of a polling-loop as well as periodic interrupts to control the timers; therefore it can be considered a hybrid as it contains elements of both designs. Currently, a polling-loop handles the keypad data and flags set by the timers, and the timers are used to fire interrupts to set these flags. This fits the system well, as user data will only be taken at certain times, and interrupting the system during other critical functions for superfluous button presses from the user seems inefficient.
10.2.8 Debugging Provisions
The only debugging provision that has been included in the system is the ability to bypass the gathering of information from the off-product database. To do this, user accounts have been hardcoded into the PIC24F that allow the system to function without using the Wi-Fi card, therefore speeding up debugging.
10.2.9 Memory Map
|MSB address |MSB |LSB |LSB address |
|Start - 0001h |SFR Space |Start - 0000h |
|End - 07FFh | |End - 07FEh |
|Start - 0801h |Near Data Space |Start – 0800h |
|End – 1FFFh | |End – 1FFEh |
|Start – 2001h |Data RAM |Start – 2000h |
|End – 7FFFh | |End – 7FFEh |
|Start – 8001h |Program Space Visibility Area |Start – 8000h |
|End – FFFFh | |End – FFFEh |
10.3 Software Design Narrative
10.3.1 Main
The main() function serves as the overall system controller. It is the first module run when the PIC24F is booted up, and is responsible for calling all of the module and peripheral initializations, as well as handling interactions between the user and the system’s various other modules. These initialization calls are required before anything else can happen within the system, so this is the first thing that the main module does. After that, the main module polls the IR break beam input port and once a logic ‘1’ is detected, initiates the RFID handler to collect the user’s ID tag. Once this is finished, the main module calls the Wi-Fi handler to collect the user’s data from the database, and then “activates” the system. It moves on to another polling loop where it polls the Data Available port. If this port is found to be high, it calls the keypad handler to deal with this data and the corresponding user action. As well, the main loop services the temperature check flag. This flag is set by the temperature timer when a regulation needs to occur.
Hot Link: Main module code
10.3.2 Module Initializations
This module is responsible for setting up all the peripherals, as well as the LCD handler and the Menu handler. It does so by correctly setting all of the registers and bits required by each peripheral. This module serves no other purpose.
Status: Written, tested, and functioning properly.
10.3.3 LCD Handler
There is not much for this code module to do, as the LCD chosen for this project contains an onboard MCU. This MCU handles all of the queuing and displaying of characters onto the LCD, so the LCD Handler simply sits in between the UART2 and any other modules that wish to display messages or information onto the LCD. It contains four functions, the LCDInit function and three Display functions. These functions consist of DisplayString, DisplayInteger, and DisplayMoney. The first one accepts a string as an argument and sends each one out to the UART individually. The last two take integers as their arguments, process them, and display them in the appropriate fashion.
Status: Written, tested, and functioning properly.
Hot Link: LCD handler code
10.3.4 UARTs Module
This code module is another simple module that serves the purpose of driving the two UART modules used by the PIC24F. There is a general UARTsInit function, which sets up both modules. The UART2 subset controls the interaction with the LCD. It contains one function, the the UART2PutChar function. UART2PutChar takes a character as an argument and attempts to write it to the U2TXREG register when the buffer full flag, UTXBF, is not set high. Everything else is handled by the LCD’s onboard MCU. Just like the UART2 subset, the UART1 subset is rather simple. It serves the purpose of reading the U1RXREG and returning the character to whoever called the module. It contains one function, the UART1GetChar function. UART1GetChar attempts to get the character from the register when the URXDA flag is raised.
Status: Written, tested, and functioning properly.
Hot Link: UARTs module code
10.3.5 RFID Handler
The RFID Handler is responsible for anything and everything that involves the RFID reader. It serves to activate the reader at the appropriate times, search for and validate an RFID tag being output by the reader, and handle the creation of the user’s account for the rest of the system to use. It’s most important responsibility is to properly scan the UART1 port for a valid RFID tag. Since the RFID tag may begin emitting its signal at any point in its twelve byte code, the RFID handler has to poll the UART1 module continuously until it finds the start byte, and then record the next ten bytes. These ten bytes represent the ID and are then validated by the handler. Once a valid tag has been found, the handler creates the data structure that represents the users account. This account is used in many other areas of the system. This handler also requests a PIN from the keypad handler, and compares the PIN entered with the one associated with the user’s account.
Status: Written, tested, and functioning properly.
Hot Link: RFID handler code
10.3.6 Keypad Handler
This module is responsible for controlling the flow of data between the keypad encoder and other various parts of the system. Its main purpose is to retrieve the five bits of data being input to the PIC24F from the keypad encoder and store an integer representation of the bit combination. It achieves this by creating an integer and shifting in each bit so that the end result is an easy to use representation of the keypad encoder’s data. The handler is also responsible for deciphering the data when attempting to get a PIN from the user. It returns this PIN to the RFID handler when requested, and also handles all of the keypad button presses for the Main module, and calls the appropriate functions in the Menu handler.
Status: Written, tested, and functioning properly.
Hot Link: Keypad handler code
10.3.7 Menu Driver
The Menu driver is the code module responsible for controlling the most important part of the UI. It is implemented as a state machine with each state representing the current “slide” of the menu. For example, a slide could represent a single 4x20 character message for each of the beverages that the unit dispenses. Each state calls the appropriate function to display the current slide. This module handles calls from the Keypad handler to control the flow through the menu. Each call corresponds to the user pressing one of the arrow keys, the select key, or the cancel key on the keypad. The driver then correctly updates the displaying of the menu on the LCD. Once a user has navigated through the menu to his or her drink selection and confirmed his or her choice, the Menu driver handles all of the interactions with the kegs. Depending on the selected mode, either auto or manual fill, there are functions to handle these interactions. The menu driver is also responsible for validating, updating and tracking keg fill levels and user account funds. This is the core module for this project.
Status: Written, tested, and functioning properly.
Hot Link: Menu driver code
10.3.8 Temperature Handler
The Temperature handler is responsible for regulating and controlling the temperature of the fridge. It is called by the Main module whenever the timer interrupt associated with the temperature readings sets the appropriate flag. The handler’s main purpose is to retrieve the temperature readings from the four temperature sensors. It does this by successively calling the I2C handler with requests for writes and reads to the four addresses of the sensors on the I2C bus. This module will then convert the readings from sensors into an integer representation of the Fahrenheit reading. It then proceeds to regulate the refrigeration unit depending on the average of the readings from the sensors. It does this by simply toggling a port pin connected to the unit. The hysteresis band of the unit is currently set to 34 degrees on the low side and 39 degrees on the high side. All temperatures are read in Fahrenheit.
Status: Currently, this module is coded to get the readings from the sensors, and display the average Fahrenheit temperature to the LCD.
Hot Link: Temperature handler code
10.3.9 I2C1 Handler
This module is responsible for controlling the I2C1 bus that the four temperature sensors are hooked up to. It follows the standard I2C protocol created by Philips Semiconductors [57]. This code is adopted from the code found in [58], which was made freely available by the author. When something needs to be put onto the bus, the handler initiates a sequence by sending a start bit, loads the I2C1TRN register with the appropriate message, and waits for an ACK from the correct device. If no ACK is received, an error is raised and the operation is aborted. When data needs to be read off of the bus, the handler simply sets the I2C1 module to receive mode, loads the data from the I2C1RCV register, and sends an ACK when it is done reading the data.
Status: Source modified for the system, tested, and functioning properly
Hot Link: I2C1 handler code
10.3.10 Wi-Fi Handler
This module serves as the backbone to the entire system. It handles both incoming and outgoing data to the Wi-Fi chip. It will use the TCP/IP stack provided by ZeroG, now of Microchip, to talk to the Wi-Fi card over the SPI1 module [59]. This handler will contain a hardcoded IP address and port number, as well as any authentication for the network it will attempt to connect to. When data needs to be sent or a request needs to be placed, this handler will open a new socket to the off-unit database server by using the TCP/IP stack’s various functions. Once a socket is successfully opened, the handler will send out the data and wait for a response from the database server. It will then return this data to whichever other module requested it.
Status: This module was not included in the final device, due to problems with porting the given code over to the final PIC24F.
10.3.11 SPI1 Module
This module’s purpose is to communicate with the Wi-Fi card over the SPI1 module on the PIC24F. This code is included in the TCP/IP stack from ZeroG.
Status: This module was not included in the final device, due to problems with porting the given code over to the final PIC24F.
10.3.12 Timer Interrupts
This module is responsible for controlling the three timers used by the system. It contains all of the interrupt subroutines for the timers. These subroutines simply count to appropriate times, depending on the need of each timer. When the appropriate time has been reached, the interrupt raises a flag for the Main module to handle. Timer1 is set to be used by the Menu handler to determine how much beverage has been dispensed, and when to close the solenoids. The time that it counts to is determined based on the size of the beverage that the user has selected. To change this time, this handler will simply load the calculated value for the period into the PR1. Then, the handler will start the timer, and the ISR will do the rest. Timer2 is set to run in Gated Accumulation mode and will support the “Beer Me” button that the user may or may not have. The timer simply counts the time that the input pin T2CK is held high. The “Beer Me” button will be debounced in software, and will feed an output pin high. This pin will be then be connected to T2CK to be timed. Timer3 is configured to count every four minutes. Every four minutes, this interrupt will raise a flag for the Main module, letting it know it should run a Temperature poll.
Status: Currently, code is written to work a timer is regular mode, and to display a message every one second. It does not yet set any flags for the Main module.
Hot Link: Timer interrupts code
10.4 Summary
The Inebriation Station is a digitally controlled kegerator that allows a user the ability to “log-in” to the station, choose a beverage from the menu as well as a size, and have the beverage automatically dispensed into his or her cup. This system is built on top of the PIC24FJ128G family of microcontrollers, which contain enough peripherals and modules to handle all of the functionality of the system. The system makes use of two of the PIC24F’s UART modules, as well as one I2C, one SPI, and other various GPIO and timers. When properly configured and initialized, these modules handle any interactions between the device and the user, as well as any behind the scenes operations that may not be obvious.
10. Version 2 Changes
Version 2 of the Inebriation Station would include a functional wireless module. While storing information to flash may be an acceptable practice for electrical engineers throwing a party, the general consumer does not want to have to plug in a debug module to the unit to update user information. If wireless were not added for a private application, a feature for a “device owner” (with a security code) to input user information and add new cups to the internal flash with a special code would be added. For a commercial application, a standard networking protocol would be a necessity, either in the form of wireless or Ethernet. The server software currently written is command line, so a graphical user interface would need to be written to allow a bartender with a touch screen quick access to the device details.
Version 2 would also have 3 user stations per device if it were to be a stand-alone kegerator and dispenser. Also, a beer distributor would be consulted on foam reduction. This would probably involve using an actual beer spout instead of just tubes inside PVC. However, for a commercial application where hundreds of gallons of beer are sold every night, a jockey box architecture could be used. This would mean simply running the beer lines into a cooler-like box where ice would be stored to cool the beer. This would solve the foaming problems as the beer would be sitting in these lines for a long time and most of the foam would die out. The user interface could just be placed on top of that, and the same kegs could supply beer to many Inebriation Stations. Moreover, flowmeters would be used to monitor the beer pouring in a Version 2 product instead of timing, so that any CO2 pressure could be used.
Finally, all fly-wires would obviously be fixed in a Version 2 product.
Summary and Conclusions
The Inebriation Station is a well packaged, easily-usable project that is enjoyed by almost everyone who interacts with it. While wireless was never implemented in the final project, the device still performs all of its primary features fully and elegantly, and it makes use of storing changing variables to non-volatile flash. Through the design process, the group learned about choosing components that will communicate properly together, creating a regulated power source, interfacing different logic levels, and switching power on and off to a load. The group also learned how UART, SPI, I2C, and parallel communication structures can be used together to interface many devices to a microcontroller. Furthermore, much was learned about PCB design and fabrication, as well as programming on a PIC microcontroller. As various sections in this report show, the group also learned about the professional aspects of being a practicing engineer, including patent infringement, lifetime failure analysis, ethics, and environmental impact. This project taught the group members the steps needed to turn an idea into an actual product, and will be vital to their success in the workforce.
References
[1] ASCO, “Direct Acting Sub-miniature Solenoid Valves,” 8256_NSFR1 Data Sheet, No Date.
[2] Parallax Inc, “RFID Card Reader, Serial/USB,” 28140-28340-RFID READER-V2.1 Data Sheet, Aug. 2008.
[3] Microchip, “16-Bit Flash Microcontrollers with USB On-The-Go (OTG),” PIC24FJ256GB110 Family Data Sheet, Oct. 2007 [Revised Dec. 2009].
[4] Crystalfontz America Inc, “Serial LCD Module Specifications,” CFA634-XXX-KL Datasheet, May 2007.
[5] ZeroG, “2.4GHz 802.11b Low Power Transceiver Module,” ZG2100M/ZG2101M Wi‐FiModule Datasheet, Revision 2.6 No Date.
[6] Texas Instruments, “Digital Temperature Sensor with Two-Wire Interface,” TMP75/175 Data Sheet, Jan. 2004 [Revised Dec. 2007].
[7] Phidget, “Phidgets 9999 Product Manual,” Phidget P/N 1030 Datasheet, Sept. 14, 2009.
[8] RFIDeas, “pcProx Enroll: Proximity card readers for identification and enrollment of proximity cards.” pcProx Datasheet, Oct. 2009.
[9] Lantronix, “WiPort Embedded Wireless Server,” WP200X00XX-02 Datasheet, Mar 2008.
[10] R. Halsey and M. Heillman, “Electronic System Device for Control of Ingredient Dispensing in a Cup Beverage Vendor,” U.S. Patent 4,011,967, March 15, 1977.
[11] P. Nelson, “Beverage Dispenser with a Reader for Size Indica on a Serving Container,” U.S. Patent 5,566,732, October 22, 1996.
[12] M. Saveliev and J. Schuster, “Food Containers with Transponders,” U.S. Patent Application 20020134831, September 26, 2002.
[13] D. Sudolcan and T. Chadwell, “Beverage Dispenser Including and Improved Electronic Control System,” U.S. Patent 6,934,602, August 23, 2005.
[14] P. Dorney, “Beverage Dispensing System,” U.S. Patent 7,617,850, November 17, 2009.
[15] Linear Technology, “LT1767/ LT1767-1.8/ LT1767-2.5/ LT1767-3.3/ LT1767-5 Step-Down Switching Regulators,” Not Available. [online]. Available: [Accessed: April 3, 2010].
[16] Maxim, “MAX3000E/MAX3001E/MAX3002-MAX3012 8-Channel Level Translator,” August 2008. [online]. Available: . [Accessed: April 4, 2010].
[17] Microchip, “PIC24FJ256GB110 Family,” December 2009. [online]. Available: . [Accessed: April 3, 2010].
[18] Omron, “PCB Relay G5LE,” May 2009. [online]. Available: $file/G5LE_0609.pdf. [Accessed: April 3, 2010].
[19] United States Department of Defense, “Military Handbook on Reliability Prediction of Electronic Equipment,” Dec. 1991. [online]. Available: . [Accessed: April 3, 2010].
[20] U.S. Environmental Protection Agency, “Safe Disposal of Refrigerated Household Appliances: Frequently Asked Questions (FAQ),“ US EPA, 2009. [Online]. Available: [Accessed April 15, 2010]
[21] U.S. Environmental Protection Agency, “Electronics Recycling (eCycling),” US EPA, 2009. [Online]. Available: [Accessed April 15, 2010]
[22] “RoHS: About Us,” RoHS, 2005. [Online]. Available: [Accessed April 15, 2010]
[23] U.S. Environmental Protection Agency, “Appliance Disposal Practices in the United States,” US EPA, 2010. [Online]. Available: [Accessed April 15, 2010]
[24] Alcohol Controls, “Draft Beer Counter”, [Online Document], unknown publication date, [Accessed: 2010 Feb 2], Available HTTP:
[25] TapDynamics, “TapAdvisor Service Overview”, [Online Document], unknown publication date, [Accessed: 2010 Feb 2], Available HTTP:
[26] US Beverage Net, “Company Profile”, [Online Document], unknown publication date, [Accessed: 2010 Feb 2], Available HTTP:
[27] KegWorks, “Draft Beer Systems”, [Online Document], unknown publication date, [Accessed: 2010 Feb 3], Available HTTP:
[28] “ZG2100M/ZG2102M Wi-Fi Module Datsheet”, [Online Document], unknown publication date, Available HTTP:
[29] WLAN Antennas, “Comparing Wireless Standards: 802.11a vs. 802.11b vs. 802.11g”, [Online Document], unknown publication date, [Accessed: 2010 Feb 3], Available HTTP:
[30] Technovelgy, “How RFIDs Work”, [Online Document], unknown publication date, [Accessed: 2010 Feb 3], Available HTTP:
[31] ASCO, “Subminiature Solenoid Valves,” 8256_NSFR1 Data Sheet, (n.d.). [Online]. Available: . [Accessed: February 17, 2010].
[32] ASCO, “Engineering Information,” (n.d). [Online]. Available: . [Accessed: February 17, 2010].
[33] Linear Technology, “Monolithic 1.5A, 1.25MHz Step-Down Switching Regulators,” LT1767/LT1767-1.8/LT1767-2.5/LT1767-3.3/LT1767-5 Data Sheet, 1999. [Online]. Available: . [Accessed: February 17, 2010].
[34] Vishay, “Power Mosfet,” IRF510, SiHF510 Data Sheet, 2008. [Online]. Available: . [Accessed: February 17, 2010].
[35] Texas Instruments, “Digital Temperature Sensor with Two-Wire Interface,” TMP175, TMP75 Data Sheet, 2007. [Online]. Available: . [Accessed: February 17, 2010].
[36] Microchip, “PIC24FJ256GB110 Family Data Sheet,” 2009. [Online]. Available: . [Accessed: February 17, 2010].
[37] Maxim, “+1.2V to +5.5, 15kV ESD-Protected, 0.1uA, 35Mbps, 8-Channel Level Translators,” MAX3000E/MAX3001E/MAX3002–MAX3012 Data Sheet, 2008. [Online]. Available: . [Accessed: February 17, 2010].
[38] Parallax Inc, “RFID Card Reader, Serial/USB,” 28140/28340 Data Sheet, 2008. [Online]. Available: . [Accessed: February 17, 2010].
[39] ZeroG, “DS101: ZG2100M/ZG2101M Wi-Fi Module Datasheet,” (n.d.). [Online]. Available: . [Accessed: February 17, 2010].
[40] Crystalfontz, “Serial LCD Module Specifications,” CFA634-TMC-KS Data Sheet, 2005. [Online]. Available: . [Accessed: February 17, 2010].
[41] Fairchild Semiconductor, “16/20-Key Encoder,” MM74C922/3 Data Sheet, 1987. [Online]. Available: . [Accessed: February 17, 2010].
[42] Microchip, “16-Bit Flash Microcontrollers with USB On-The-Go (OTG),” PIC24FJ256GB110 Family Data Sheet, Oct. 2007 [Revised Dec. 2009].
[43] ZeroG, “2.4GHz 802.11b Low Power Transceiver Module,” ZG2100M/ZG2101M Wi-Fi Module Datasheet, Revision 2.6 No Date.
[44] Omron, “Tactile Switch,” B3F Data Sheet, No Date.
[45] Maxim, “+1.2V to +5.5V, ±15kV ESD-Protected, 0.1μA, 35Mbps, 8-Channel Level Translators,” MAX300E-MAX3012 Data Sheet, Rev. 5, Aug. 8, 2008.
[46] Linear Technology, “Monolithic 1.5A, 1.25MHz Step-Down Switching Regulators,” LT1767-3.3/LT1767-5 Data Sheet, Rev A 2K, No Date.
[47] Fairchild Semiconductor, “MM74C922/MM74C923 16-Key Encoder/20-Key Encoder,” MM74C923 Data Sheet, October 1987 [Revised April 2001].
[48] Microsemi, “Surface Mount 1A Schottky Rectifier,” UPS120 Datasheet, July 31, 1998.
[49] ASCO, “Direct Acting Sub-miniature Solenoid Valves,” 8256_NSFR1 Data Sheet, No Date.
[50] Parallax Inc, “RFID Card Reader, Serial/USB,” 28140-28340-RFID READER-V2.1 Data Sheet, Aug. 2008.
[51] Texas Instruments, “Digital Temperature Sensor with Two-Wire Interface,” TMP75/175 Data Sheet, Jan. 2004 [Revised Dec. 2007].
[52] Cui Inc, “DC Power Jack,” PJ-056 Data Sheet, No Date.
[53] Central Semiconductor Corp., “Super-mini Schottky Diode,” CMDSH-3 Data Sheet, No Date.
[54] Crystalfontz America, Inc. “Serial LCD Module Specifications,” CFA-643_V.20 Data Sheet, Rev 2.0, Oct 2005.
[55] 4PCB, “Trace Width Calculator,” Accessed: May 03, 2010.
[56] Microchip Technologies Inc., “PIC24FJ128GA010 Family Data Sheet,” Microchip Technologies Inc., 2009. [Online]. Available: [Accessed: Jan. 25, 2010]
[57] Philips Semiconductors, “The I2C-Bus Specification,” Philips Semiconductors, DO 9398 393 40011, January 2000. [Online]. Available: [Accessed: March 25, 2010]
[58] “10.1 I2C – Part 1 – I2C Basics,” No date found. [Online]. Available: . [Accessed: Feb. 22, 2010]
[59] Microchip Technologies Inc., “TCP/IP Stack for PIC18, PIC24, dsPIC & PIC32,” Microchip Technologies Inc., 2009. [Online]. Available: [Accessed: March 25, 2010].
Appendix A: Individual Contributions
A.1 Contributions of Jon Schwarz:
As the team leader for the project, my most important contribution was ensuring everything we purchased would work together. While it may seem like a trivial task, I spent an immense amount of time ordering all of the components for our project. This involved specifying what would be needed and then making sure it would fit together with the rest of the components. For example, I had to ensure that the switching regulator had the correct passive components to supply enough current to supply all of our board, while not heating excessively. Also, I ordered all of the solenoids, tubing, connectors, and taps for our 4 keg system, and it all fit together flawlessly, with no extra parts. This is an amazing feat.
I also tracked timelines and made sure that Carlo and Bill were coding at the same speed Mike and I were building the PCB early on so that we would have code ready to go when our PCB was completed. I then made sure PCB population and peripheral testing were moving at the same pace as building the actual project. For almost every part of our project, I got the activity off of the ground, and then acted as a consultant when needed. For example, I helped design the logic and flow of our code, and then only helped Bill when he had a specific problem or design consideration he needed to make. I purchased all of the solenoids, tubing, designed the top of the freezer, purchased the wood, and then built the physical structure and applied the first coat of paint. Then, I only helped Carlo when he needed help such as deciding how to mount the solenoids and spout, or how to make everything waterproof. The fact that we went from having a bunch of people all working on separate things without a physical structure built in the 13th week and then having a completed project 9 days later speaks to my effectiveness at tracking timelines.
My major technical contribution was specifying all of the parts, and then creating the first generation schematic. Actually, my first generation schematic was almost exactly the final generation schematic, except Mike moved some of the microcontroller pins so that he could more effectively route the PCB. I also created the pad for the PCB for all the parts as I added them to the schematic in an attempt to make less work for Mike to route it. I also had a minimal part in verifying the PCB with Mike, to ensure all the traces were of sufficient size for the current they would draw.
My other technical contributions include the following (not all done exclusively by me): populating and verifying the first and second PCB, discovering and fixing the error in the switching regulator design, discovering and fixing the error in the microcontroller debug module, discovering and fixing the error in using a level translator to drive then enable line of the RFID reader, discovering and fixing the error in driving a MOSFET with a level translator, demonstrating the keypad/encoder circuit to the programmers, demonstrating the MOSFET driving circuit to the programmers, demonstrating the IR beam break circuit to the programmers, editing Microchip code to get the Wi-Fi module to work on the development board, populating the PCB, embedding a relay into an extension cord, creating the linear regulator circuit to bypass the 3.3V switching regulator, and creating breakout boards for interfacing with the microcontroller and wiring them for use by the programmers. I also helped with many parts of the physical construction as the product neared completion.
From a lets technical standpoint, I had the unpopular job of calling most team meetings, as well as making sure everyone actually did the work they said they would do. I also created or at least did major editing to most of the team documents or presentations. Finally, I had the exciting job of proofing everyone’s homework.
A.2 Contributions of Mike Wei:
For our project, I came up with a concise block diagram that allowed us to see all of the peripherals that would be connected to our microcontroller and what form of communication each peripheral required (I2C, SPI, UART). I also created a preliminary flow chart which details the logic that the microcontroller would follow for handling user requests. I also came up with the name for our project.
Later on, my focus would be essentially all hardware. I was tasked with designing the PCB. Since the PADs Layout schematic was important in regards to the actual PCB design, I helped Jon select and create the circuit diagram for our design in PADs Layout. Since Jon and I worked together on this portion, we also helped each other verify decisions made regarding circuit layout and part choices for various components. Once we had a schematic, I spent a lot of time going through the PADs tutorial provided on the course website and figuring out what each program in the PADs software package does. Initially, I used a preliminary schematic to layout all the parts on the PCB and used auto-route to route the traces. However, upon careful inspection, I realized that better choices regarding which pins to use on the microcontroller would simplify the routing significantly. So a large number of changes were made to the PADs Layout schematic such that each trace by hand would be simple and manageable.
When issues with our PCB arose, I kept the PCB schematic up to date which allowed us to easily order another PCB when we decided the old PCB was no longer useable. When the PCB arrived, I did a significant amount of soldering for fine pitched parts (microcontroller, level translator, switching regulators). Jon and I would verify each other’s soldering job to make sure there were no cold solder joints or shorts between pins.
When Carlo and Bill were porting the devboard code over to our microcontroller, I helped them troubleshoot some hardware issues such as why the keypad was no longer displaying unique values for all buttons pressed. When communicating with the RFID using a level translator as an intermediary, I discovered that the enable line was not a clean low signal like it should be and determined that the amount of current the level translator could sink was very small compared to what the RFID could potentially source.
During the construction phase, I did a significant amount of wiring for the fridge top which would lie on top of the freezer chest. Carlo and I made sure that the fridge top would be able to lay flush without crimping important connections such as the decoded keypad bus, the solenoid switching lines, RFID reader bus, LCD transmit line, etc. When all the connections for the fridge top were made, a recent version of the ported code was used to make sure the circuit was still functional. Once work on the fridge top was complete, I basically served as an additional hand during the assembly of our project and replaced parts on our PCB as required.
A.3 Contributions of Dan Carlo Mesina:
Throughout the semester, I contributed to different parts in the design process. In the beginning, I started in software where I assisted Bill with programming the PIC on the Explorer 16 development board. Bill had much more experience with programming in C than myself, therefore my contribution to the software development was in the form of suggesting course of action, debugging and soldering connection headers. The first task was to program the PIC24F to successfully communicate with each of the peripherals individually. The UART protocol used to communicate with the LCD and RFID was quickly implemented, thus majority of the time was spent getting the I2C protocol to work with the temperature sensors. Since neither of us has worked with I2C before, the majority of my time was spent searching the internet for example code and an explanation of how the protocol works. I was able to find a very helpful site explaining how the I2C worked and Bill was able to find a useful example code from an online forum. Bill and I referred to the site I found to figure out how the example code was working and then I assisted him with implementing it to our code. When the MCU was able to properly receive data from the temperature sensors, we implemented the IR break bream, keypad and pushbuttons. We then worked on the user interface where I made suggestions on the menu format and beverage selection process. After the user interface was created and all the peripherals were able to operate together, I helped Bill port all the code from the development board to the PIC microcontroller on our PCB. I deciphered how to use the Peripheral Pin Select feature, which allowed us to reprogram pins to be an I/O for any peripheral, and helped Bill interpret how to use the different timer interrupts.
When the PCB was fabricated and tested, I moved on to help Jon and Mike with the hardware implementation. From working with Bill, I was able to create simple code that would test each of the peripherals. After one was proven to work successfully, another would be added and tested. The process was repeated until everything was connected and functioning together. In addition, during the process, I helped Jon and Mike with debugging various problems found along the way, which mainly included issues with the level translator.
When the PCB was fully functional and operating with all the peripherals, I began on the construction process. Jon and I purchased all the building materials and started with building the table top of our unit at our house. When it was completed, we brought it to lab where Jon and I cut out the holes for the spout LCD, Keypad, and pushbuttons. I then mounted all the solenoids, connected all the tubing, and constructed the spout with the tubing running through it. Furthermore, I applied coats of primer and glossy black over the refrigeration unit so that it would match our table top. When everything was in place, Jon put the Plexiglass over the LCD cutout and applied silicon onto all the edges of the cuts. Our group was considering leaving the IR break beam out for aesthetic reasons, but it was confirmed by the course staff that it was required. Therefore, I went ahead and created a wooden, aesthetically pleasing enclosure to hide the IR emitter and receiver. Mike and I then mounted all the peripherals and ran all the wires under the table top. It was then brought back to mine and Jon’s house where I covered the exposed components with masking tape, painted the spout gold and applied a coat of black over the surface and the IR enclosure. Jon and I then drilled holes into the refrigeration unit for the tubing to run through and connected the keg taps and CO2.
After construction was completed, Jon and I shot the PSSC video that will be presented for our final presentation. I then went to an iTap Mac lab to use the iMovie video editing software and added features to make the video more presentable.
A.4 Contributions of Bill Bergquist:
My biggest contribution came in the form of the software. Because I was the only computer engineer on the team, I was assigned the role of Software Guru at the beginning of the semester. My main responsibilities were to make sure that the software was developed, tested, and integrated correctly on the final device. Seeing as how I want to end up doing software later in life, this role suited me perfectly.
At the beginning of the semester, around week three, I checked out the development kit for the PIC24F microcontrollers and began writing code almost immediately. The first thing I did was get familiar with the development tools that came with the kit, including the MPLAB software and the ICD2 debugger. I also familiarized myself with the demonstration code that was provided with the kit, and began adopting it to work for our project. First, I spent some time creating the initial menu driver that would serve as the main interface with the user. The basic idea was that each beverage would have its own “slide” that displayed relevant information to the user. From there, once I had implemented the basic driver, I started writing code to integrate the peripherals, such as the LCD and temperature sensors. Each week, the goal was to get one new peripheral functioning correctly, and have it fully integrated before moving on to the next one. This included creating a working prototype on a couple of breadboards.
As the weeks passed, the code became more complete, and the prototype took shape. Early on, I was able to successfully use the keypad to navigate through the menu that was displayed on the LCD. After that, user functionality was added that allowed different cups to be read by the RFID reader. Account validation followed, with the user being able to login using a 3 digit PIN only if a valid tag was read. Lastly, additional behind-the-scenes code was added to control the temperature of the freezer chest and run the timers.
After having written all of the code and creating an almost-fully-functional prototype, the next step was to port the code over to the final PIC24F MCU. I had to reconfigure some of the pins used by the peripherals, as well as the configuration registers. I ran into some hiccups along the way, but in the end, everything was ported over and functioning properly on the final device.
At this point, my responsibilities shifted to focus more on software debugging and testing, rather than developing. I made all of the changes that were requested by my team members, and added small features to make the device more polished. These included the new “welcome screen” driver as well as new functions to clean up the code and store relevant information to flash.
Along the way, I also contributed to other areas of the project, such as component selection and hardware testing. Although these may have been small contributions, they did aid in the development of the project. I also wrote the Software Design narrative and the Ethical and Environmental impact analysis, and helped maintain the website.
Appendix B: Packaging
[pic] [pic]
[pic]
Figure B-3: Top View of Unit
Appendix C: Schematic
[pic]
Figure C-1: Female DC Barrel Connectors (Left: Solenoid Valves, Right: PCB logic)
[pic]
Figure C-2: Switching Regulators (3.3V and 5V respectively)
[pic]
Figure C-3: 8-Channel Level Translator
[pic]
Figure C-5: Temperature, RFID, LCD and IR sensor connections to PIC24
[pic]
Figure C-6: PIC24F Microcontroller
[pic] [pic] [pic]
Figure C-7: Keypad Encoder Connections Figure C-8: Pushbutton Connections Figure C-9: LCD connections
[pic] [pic]
Appendix D: PCB Layout Top and Bottom Copper
[pic]
Figure D-1: Top PCB Layer
[pic]
Figure D-2: Bottom PCB Layer
Appendix E: Parts List Spreadsheet
|Part No. |Description |Unit Cost |Quantity |Total Cost |
|PIC24FJ128GB108 |16-bit Microcontroller |$0.00 |1 |$0.00 |
|Parallax 28140 |RFID Reader |$39.99 |1 |$39.99 |
|Parallax 28142 |RFID Tags |$.99 |10 |$9.90 |
|CFA-643_v2.0 |20x4 LCD Display |$64.99 |1 |$64.99 |
|ZG2101M |Wireless Module |$29.99 |1 |$29.99 |
|ZG-ANT-01 |ZG2101M Antenna Kit |$35.00 |1 |$35.00 |
|AC164136-2 |Wireless Module w/ PICtail |$59.99 |1 |$59.99 |
|TMP175 |Temperature Sensor |$0.00 |5 |$0.00 |
|ASCO U8256A108E |Food Grade Solenoid |$54.38 |4 |$217.52 |
|7485ED |Keg Tap |$24.88 |4 |$99.52 |
|BLAW5316 |Beer Line Assembly |$6.69 |1 |$6.69 |
|SSC-E2 |CO2 Cross Connector |$9.42 |1 |$9.42 |
|SST-E2 |CO2 “T” Connector |$6.83 |1 |$6.83 |
|Grayhill Series 88 |5x4 Keypad |$30.03 |1 |$30.03 |
|MMT4C923 |Keypad Encoder |$8.95 |1 |$8.95 |
|LT1767-3.3 |12 to 3.3V Switching Regulator |$6.10 |4 |$24.40 |
|LT1767-5 |12 to 5V Switching Regulator |$6.10 |4 |$24.40 |
|CMDSH-3 |Silicon Schottky Diode |$.39 |4 |$1.56 |
|UPS120 |Schottky Diode |$1.00 |4 |$4.00 |
|SD7030-5R0 |5 mH Inductor |$1.23 |4 |$4.92 |
|MAX3001E |8-Channel Level Translator |$3.95 |2 |$7.90 |
|ATS08ASM |8 MHz Oscillator |$1.17 |1 |$1.17 |
|IRL530 |Power n-MOS |$1.50 |10 |$15.00 |
|PJ-056 |Female DC Barrel Connector |$1.08 |2 |$2.16 |
|PP-019 |Male DC Barrel Connector |$.68 |2 |$1.36 |
|EN-B3F |Push Button |$0.00 |1 |$0.00 |
|AC164110 |Header-Debug RJ 11 |$9.99 |1 |$9.99 |
|G5LE-1A4 DC12 |AC Relay |$1.28 |2 |$2.56 |
| |Refrigeration Unit |$175.00 |1 |$175.00 |
|Building Materials/Supplies |Wood, Paint, Tools |$120.00 |1 |$120.00 |
|Keg 1 |¼ Barrel (Miller) |$50.00 |1 |$50.00 |
|Keg 2 |¼ Barrel (Killians) |$32.00 |1 |$32.00 |
|Passives |Caps, Resistors |$5.00 |~ |$5.00 |
| | | |TOTAL |$1075.84 |
Appendix F: FMECA Worksheet
|Failure No. |Failure Mode |Possible Causes |Failure Effects |Method of Detection |Criticality |Remarks |
|A1 |Output of LT1767-3.3 = 0V |Power not connected; Female DC |PIC24F no longer functional,|Observation |Low |User inconvenience |
| | |barrel connector failed; |thus all other components | | | |
| | |LT1767-3.3 failed open; Input or |are no longer functional | | | |
| | |Output capacitors (C3 or C4) | | | | |
| | |failed | | | | |
|A2 |Output of LT1767-3.3 |LT1767-3.3 failed short |PIC24F, Temperature Sensors |Observation |High |Parts could overheat and potentially |
| |> 3.3 V | |and Wireless Module overheat| | |cause a fire |
| | | |and fail | | | |
|A3 |Output of LT1767-3.3 is out |C3 or C4 failed |PIC24F, Temperature sensors |Observation |Medium |Damaged parts will have to replaced |
| |of tolerance | |and Wireless Module don’t | | | |
| | | |operate properly; possible | | | |
| | | |damage | | | |
|A4 |Output of LT1767-5 = 0V |Power not connected; Female DC |Keypad encoder and IR sensor|Observation |Low |User inconvenience |
| | |barrel connector failed; LT1767-5 |are no longer functional; | | | |
| | |failed open; Input or Output |Causes Failure No. A7 | | | |
| | |capacitors (C7 or C8) failed | | | | |
|A5 |Output of LT1767-5 |LT1767-5 failed short |Keypad encoder, RFID reader,|Observation |High |Parts could overheat and potentially |
| |> 5 V | |LCD, and IR sensor overheat | | |cause a fire |
| | | |and fail | | | |
|A6 |Output of LT1767-5 is out of|C7 or C8 failed |Keypad encoder and level |Observation |Medium |Damaged parts will have to replaced |
| |tolerance | |translator don’t operate | | | |
| | | |properly; possible damage; | | | |
| | | |Causes Failure No. A8 | | | |
|A7 |MAX3001E Vcc set to 0V |Same as Failure No. A4 |Switching circuitry (for the|Observation |Low |User inconvenience; Beverage isn’t |
| | | |fridge and solenoids), RFID | | |dispensing because it is frozen: |
| | | |Reader and LCD are no | | |Beverage too warm |
| | | |longer functional | | | |
|A8 |Output of MAX3001E |Same as Failure A6 or C10 failed |Switching circuitry (for the|Observation |Medium |Damaged parts will have to replaced |
| |(translating 3.3V to 5V) is| |fridge and solenoids), RFID | | | |
| |out of tolerance | |Reader and LCD don’t | | | |
| | | |operate properly; possible | | | |
| | | |damage | | | |
|A9 |Solenoids don’t open (when |Female DC barrel connector (to the|Beverage choice not |Observation |Low |User inconvenience |
| |the rest of the circuitry is|solenoids) failed |dispensed | | | |
| |working properly) | | | | | |
|B1 |Input to any of the power |C16, C17, C18, C19 and/or C20 |PIC24F doesn’t operate |Observation |Medium |Damaged parts will have to replaced |
| |pins (VDD, VSS, AVDD, AVSS) |failed |properly; PIC24F may have | | | |
| |are out of tolerance | |been damaged | | | |
|B2 |PIC24F not receiving data |PIC24F stuck in an infinite loop; |RFID from the user’s cup is |Observation |Low |User unable to make beverage |
| |from RFID Reader |Timer interrupts affecting the |never identified | | |selection |
| | |transmission of data; Noise on the| | | | |
| | |UART RS-232 line | | | | |
|B3 |PIC24F not communicating |Noise on UART RS-232 line; PIC24F|“Garbage” values are |Observation |Low |User unable to navigate through menu |
| |with LCD properly |stuck in an infinite loop |displayed; Display goes | | |or make a beverage selection |
| | | |blank; Display freezes in | | | |
| | | |menu | | | |
|B4 |PIC24F not communicating |PIC24F sent wrong slave address; |Wrong temperature values are|Observation |Low |User inconvenience; Beverage isn’t |
| |with Temperature Sensors |Noise on I2C line |received; Refrigeration unit| | |dispensing because it is frozen: |
| | | |doesn’t switch on/off; | | |Beverage too warm |
| | | |Beverages get too warm or | | | |
| | | |freeze | | | |
|B5 |PIC24F not communicating |PIC24F sent wrong slave address; |User data is never received |Observation |Low |User inconvenience and owner |
| |with Wireless Module |Noise on SPI line |and displayed on LCD; User | | |inconvenience |
| | | |account information is not | | | |
| | | |updated properly | | | |
| | | | | | | |
|C1 |Keypad Encoder not receiving|Wires from keypad to the encoder |Input form user aren’t |Observation |Low |User unable to navigate through menu |
| |input from Keypad |are being shorted |received | | |or make beverage selection |
|C2 |Output from Keypad Encoder |C11 and/or C12 failed |Incorrect or no data is sent|Observation |Low |User unable to navigate through menu |
| |is incorrect | |to PIC24F | | |or make beverage selection |
|C3 |LCD isn’t working properly |LCD controller failed |LCD is showing incorrect |Observation |Low |User unable to navigate through menu |
| | | |characters; LCD is showing a| | | |
| | | |blank screen | | | |
|C4 |“Manual Pour” Button isn’t |Software error with the Timer |Beverage isn’t being |Observation |Medium |Beverage constantly dispensing onto |
| |working properly |Interrupt; Weak connection to |dispensed when button is | | |the unit can cause damage to |
| | |PIC24F |pressed; Beverage doesn’t | | |components by moisture |
| | | |stop dispensing when button | | | |
| | | |is released | | | |
|C5 |“Beer Me” Button isn’t |Software error; Weak connection to|Beverage designated to the |Observation |Low/Medium |User inconvenience; Too much of the |
| |working properly |PIC24F |“Beer Me” Button isn’t the | | |beverage is dispense that can lead to|
| | | |correct beverage; The | | |damaged components through moisture |
| | | |incorrect amount of the | | | |
| | | |beverage is dispensed | | | |
|C6 |IR Sensor always sends a |Phototransistor failed short; |The RFID Reader is never |Observation |Low |User will not be able to make a |
| |logic low whether or not the| |enabled; RFID tag is never | | |beverage selection |
| |beam is broken | |identified | | | |
|C7 |IR Sensor always sends a |Phototransistor failed open; |The system is never reset to|Observation |Low |Other users will not be able to use |
| |logic high whether or not | |main menu after the user has| | |the system |
| |the beam is broken | |used the unit | | | |
|D1 |Solenoids don’t open or are |IRL530 Power |Beverage is never dispensed |Observation |Low/Medium |User inconvenience; Possible damage |
| |constantly open |n-MOS failed |or won’t stop dispensing | | |can occur to components through |
| | | | | | |moisture |
|D2 |Solenoids vigorously opening|IRL530 Power |Solenoid valves may be |Observation |Medium |Damaged parts will have to replaced |
| |and closing |n-MOS has a floating connection |damaged | | | |
-----------------------
Bill Bergquist
Carlo Mesina
Figure B-1: Back View of Unit
+5V H2
Beer-Me Button & Fill Button
IR Break Beam Sensor
Jon Schwarz
Tx
LCD
Mike Wei
+5V H1
Figure B-2: Front View of Unit
RFID
Reader
Solenoid Valves (x4)
PCB
“Beer Me” Button
Keypad
Sixth-Barrel Kegs (x4)
UART
SPI
UART
+3.3V
Buttons/IR
Keypad
+3.3V
ZG2101M 2.4 GHz 802.11b WI-FI
Figure C-10: Solenoid Connections
+5V
PIC24FJ128GB108
Microcontroller
Figure C-11: Solenoid Switching Circuitry
CFA634-TMC-KS
LCD Display
Keypad
6
Keypad Controller
+5V
9
+12V
+12V
A2
A1
A0
+3.3VV
4 x U8256A108E Solenoid Valves
1 x Freezer Chest
Pull-up Resistor
SDA
SCL
4 x TITMP75
Temp Sensor
OE
Rx
Serial RFID Reader
5 x IRL530 Power N-MOSFET
555
+5V
555
NOTES
1. General purpose I/O are connected directly to red Microcontroller block and unlabeled
2. Rx, Tx, SPO, SPI are all from microcontroller perspective.
3. Italics denote Active -Low
WIFI CE
WIFI INT
4
Figure 7-1: Draft
Beer Counter
Figure 1.3: Block Diagram of the Inebriation Station
I2C
Figure 7-1: TapAdvisor
Figure 7-3: Beverage Net
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- final maturity of ee savings bonds
- final maturity date for ee bonds
- calculate ee bond final value
- ee savings bonds final maturity
- final cost report nysed
- purdue university plagiarism checker
- purdue university salaries
- project final report template
- project final summary report template
- final grant report sample
- project management final report example
- project management final report template