ECE 477 Final Report  Spring 2010
Team 1  Inebriation Station
Mike Wei
Jon Schwarz
Carlo Mesina
Bill Bergquist
ECE 477 Final Report
Spring 2010
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
Technical content
Design documentation
Technical writing style
Contributions
Editing
0
0
0
0
0
1
1
1
1
1
2
2
2
2
2
3
3
3
3
3
SCORE
4 5 6 7
4 5 6 7
4 5 6 7
4 5 6 7
4 5 6 7
8
8
8
8
8
9
9
9
9
9
10
10
10
10
10
MPY
3
3
2
1
1
TOTAL
Comments:
-ii-
PTS
ECE 477 Final Report
Spring 2010
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
-iii-
ECE 477 Final Report
Spring 2010
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.0 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.
1
ECE 477 Final Report
Spring 2010
Figure 1.2: Photo of completed project
2
ECE 477 Final Report
Spring 2010
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
+3.3V
ZG2101M 2.4 GHz
802.11b WI-FI
+5V H1
+5V H2
4
WIFI INT
+5V
WIFI CE
CFA634-TMC-KS
LCD Display
+3.3V
Tx
Rx
IR Break Beam
Sensor
UART
Beer-Me Button &
Fill Button
Keypad
9
+12V
Pull-up
Resistor
I2 C
6
Serial RFID
Reader
OE
PIC24FJ128GB108
Microcontroller
+5V
Keypad
Controller
UART
SPI
SCL
4 x TITMP75
Temp Sensor
SDA
5
5
5
5 x IRL530 Power N-MOSFET
5
5
1
4 x U8256A108E5 Solenoid Valves
+3.3V
V
A0
A1
+12V
1 x Freezer Chest
Figure 1.3: Block Diagram of the Inebriation Station
A2
ECE 477 Final Report
Spring 2010
2.0 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.
3.0 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
4
ECE 477 Final Report
Spring 2010
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
5
ECE 477 Final Report
Spring 2010
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.
3.2.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.
3.2.4 Off-Chip Peripheral Requirements
There are currently no off-chip peripherals planned for our design.
3.2.5 Power Constraints
6
ECE 477 Final Report
Spring 2010
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.
3.2.6 Packaging Constraints
The package needs to be designed such that refilling the kegs or replacing the CO 2 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.
3.2.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.
3.3 Component Selection Rationale
7
ECE 477 Final Report
Spring 2010
3.3.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, CFA634TFB-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
8
ECE 477 Final Report
Spring 2010
backlight, specifically a blue backlight. Because the price difference between the CFA634-TFBKS 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.
3.3.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 C V 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.
3.3.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].
3.3.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
9
ECE 477 Final Report
Spring 2010
interface, and has a price tag of $65 [7]. The pcProx has a range of 1-3 inches, uses USB or RS232 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.
3.3.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.
3.3.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.4 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
10
ECE 477 Final Report
Spring 2010
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
11
ECE 477 Final Report
beverage from the dispensing valve” [13].
Spring 2010
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].
4.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.
12
ECE 477 Final Report
Spring 2010
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
13
ECE 477 Final Report
Spring 2010
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 offdevice, 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.
4.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 nonline-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.
Inebriation Station plans to license that technology from the patent holders.
14
The
ECE 477 Final Report
Spring 2010
5 Reliability and Safety Analysis
5.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.
5.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
πT
Temperature Factor
.19
16-bit MOS device
Digital MOS;
TC = 35o P = .576
ϴJC = 10
TJ = TC + P*ϴJC
15
ECE 477 Final Report
Spring 2010
C2
Package Failure
Rate
.041
πE
Environment Factor
.5
πQ
Quality Factors
10.0
πL
Learning Factor
1.0
λp
TJ ≈ 40.76oC
Nonhermetic SMT;
NP = 80 (# of pins)
Ground, benign; Nonmobile;
Controlled environments
accessible to maintenance
Commercial product
In production for
> 2 years
Failures/hour
Failure Rate
7.37 x 10-7
Mean Time to
≈ 1356852.1 hrs
MTTF
Failure
≈ 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
πT
Temperature Factor
12
C2
Package Failure
Rate
.0034
πE
Environment Factor
.5
πQ
Quality Factors
10.0
πL
Learning Factor
1.0
λp
MOS device; Linear
Gate/Logic Array;
Assuming 101 – 300
transistors
Linear MOS;
TJ = 95oC
Nonhermetic SMT, NP = 8
(# of pins)
Ground, benign; Nonmobile;
Controlled environments
accessible to maintenance
Commercial product
In production for
> 2 years
Failures/hour
Failure Rate
2.57 x 10-6
Mean Time to
≈ 389105.06 hrs
MTTF
Failure
≈ 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
πL
Load Stress Factor
Contact Form
Factor
≈1
Ambient Temp. = 85 ºC
Rated Temp. = 85 ºC
Resistive Load
1.00
Contact Form: SPST
πC
16
ECE 477 Final Report
Spring 2010
πCYC
Cycling Factor
50.00
πF
Application and
Construction Factor
6.00
πQ
Quality Factor
10.00
πE
Environment Factor
2.00
λp
Cycles/hr = 500 (very most)
Contact Rating = 10A;
Medium Power;
Armature Construction Type
Commercial Product
Ground, benign; Nonmobile;
Controlled environments
accessible to maintenance
Failures/hour
Failure Rate
2.4 x 10-6
Mean Time to
≈ 416666.67 hrs
MTTF
Failure
≈ 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”.
5.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
17
ECE 477 Final Report
Spring 2010
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.
5.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.
6 Ethical and Environmental Impact Analysis
6.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
18
ECE 477 Final Report
Spring 2010
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.
6.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,
19
ECE 477 Final Report
Spring 2010
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 humanto-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.
6.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
20
ECE 477 Final Report
Spring 2010
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
21
ECE 477 Final Report
Spring 2010
and resource conservation. The swing in the positive direction would hinge solely on the number
of users who used this device.
6.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.
7
Packaging Design Considerations
7.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.
7.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].
22
ECE 477 Final Report
Spring 2010
7.2.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 (AlcoholControls.com) 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
Figure 7-1: Draft
Beer Counter
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.
23
ECE 477 Final Report
Spring 2010
7.2.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
Figure 7-1:
TapAdvisor
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
24
ECE 477 Final Report
Spring 2010
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 (TapDynamics.com) 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
Figure 7-3: Beverage Net
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
25
ECE 477 Final Report
Spring 2010
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.
7.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
26
ECE 477 Final Report
Spring 2010
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 sixthbarrel 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
27
ECE 477 Final Report
Spring 2010
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.
7.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.
8 Schematic Design Considerations
8.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
28
ECE 477 Final Report
Spring 2010
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.
8.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 wallwart 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 wallwart 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 9bit 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].
29
ECE 477 Final Report
Spring 2010
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 bidirectional 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
30
ECE 477 Final Report
Spring 2010
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 nMOS 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
31
ECE 477 Final Report
Spring 2010
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.
8.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.
8.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.
32
ECE 477 Final Report
9
Spring 2010
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.
9.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.
33
ECE 477 Final Report
Spring 2010
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.
9.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,
34
ECE 477 Final Report
Spring 2010
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.
9.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
35
ECE 477 Final Report
Spring 2010
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).
9.4.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
36
ECE 477 Final Report
Spring 2010
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.
9.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.
10 Software Design Considerations
10.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.
37
ECE 477 Final Report
Spring 2010
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
38
ECE 477 Final Report
Spring 2010
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
39
ECE 477 Final Report
Spring 2010
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
Start - 0001h
Start - 0000h
SFR Space
End - 07FFh
Start - 0801h
Near Data Space
End – 1FFFh
Start – 2001h
End – FFFFh
End - 07FEh
Start – 0800h
End – 1FFEh
Start – 2000h
Data RAM
End – 7FFFh
Start – 8001h
LSB address
Program Space Visibility Area
End – 7FFEh
Start – 8000h
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
40
ECE 477 Final Report
Spring 2010
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
41
ECE 477 Final Report
Spring 2010
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
42
ECE 477 Final Report
Spring 2010
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
43
ECE 477 Final Report
Spring 2010
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
44
ECE 477 Final Report
Spring 2010
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.
11 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
45
ECE 477 Final Report
Spring 2010
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.
12 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.
46
ECE 477 Final Report
Spring 2010
13 References
[1] ASCO, “Direct Acting Sub-miniature Solenoid Valves,” 8256_NSFR1 Data Sheet, No Date.
http://www.ascovalve.com/Common/PDFFiles/Product/8256_NSFR1.pdf
[2] Parallax Inc, “RFID Card Reader, Serial/USB,” 28140-28340-RFID READER-V2.1 Data
Sheet, Aug. 2008.
http://www.parallax.com/Portals/0/Downloads/docs/prod/audiovis/28140-28340RFID%20Reader-v2.1.pdf
[3] Microchip, “16-Bit Flash Microcontrollers with USB On-The-Go (OTG),”
PIC24FJ256GB110 Family Data Sheet, Oct. 2007 [Revised Dec. 2009].
http://ww1.microchip.com/downloads/en/DeviceDoc/39897c.pdf
[4] Crystalfontz America Inc, “Serial LCD Module Specifications,” CFA634-XXX-KL
Datasheet, May 2007.
http://www.crystalfontz.com/products/634/datasheets/342/CFA-634_v2.0.pdf
[5] ZeroG, “2.4GHz 802.11b Low Power Transceiver Module,” ZG2100M/ZG2101M
Wi‐FiModule Datasheet, Revision 2.6 No Date.
http://support.zerogwireless.com/FileManagement/Download/1d4f0f784fef4374ac2b534b3cba9
5b9
[6] Texas Instruments, “Digital Temperature Sensor with Two-Wire Interface,” TMP75/175
Data Sheet, Jan. 2004 [Revised Dec. 2007].
http://www.ti.com/lit/gpn/tmp175
[7] Phidget, “Phidgets 9999 Product Manual,” Phidget P/N 1030 Datasheet, Sept. 14, 2009.
http://www.phidgets.com/documentation/Phidgets/1023.pdf
[8] RFIDeas, “pcProx Enroll: Proximity card readers for identification and enrollment of
proximity cards.” pcProx Datasheet, Oct. 2009.
http://www.rfideas.com/downloads/pcProxEnrollment.pdf
[9] Lantronix, “WiPort Embedded Wireless Server,” WP200X00XX-02 Datasheet, Mar 2008.
http://www.lantronix.com/pdf/WiPort_PB.pdf
[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.
http://www.freepatentsonline.com/4011967.html
[11] P. Nelson, “Beverage Dispenser with a Reader for Size Indica on a Serving Container,” U.S.
Patent 5,566,732, October 22, 1996. http://www.freepatentsonline.com/5566732.html
47
ECE 477 Final Report
Spring 2010
[12] M. Saveliev and J. Schuster, “Food Containers with Transponders,” U.S. Patent Application
20020134831, September 26, 2002. http://www.freepatentsonline.com/20020134831.html
[13] D. Sudolcan and T. Chadwell, “Beverage Dispenser Including and Improved Electronic
Control System,” U.S. Patent 6,934,602, August 23, 2005.
http://www.freepatentsonline.com/6934602.html
[14] P. Dorney, “Beverage Dispensing System,” U.S. Patent 7,617,850, November 17, 2009.
http://www.freepatentsonline.com/7617850.html
[15] Linear Technology, “LT1767/ LT1767-1.8/ LT1767-2.5/ LT1767-3.3/ LT1767-5 StepDown Switching Regulators,” Not Available. [online]. Available:
http://www.linear.com/pc/downloadDocument.do?navId=H0,C1,C1003,C1042,C1032,C1064,P1
915,D1885 [Accessed: April 3, 2010].
[16] Maxim, “MAX3000E/MAX3001E/MAX3002-MAX3012 8-Channel Level Translator,”
August 2008. [online]. Available: http://datasheets.maxim-ic.com/en/ds/MAX3000EMAX3012.pdf. [Accessed: April 4, 2010].
[17] Microchip, “PIC24FJ256GB110 Family,” December 2009. [online]. Available:
http://ww1.microchip.com/downloads/en/DeviceDoc/39897c.pdf. [Accessed: April 3, 2010].
[18] Omron, “PCB Relay G5LE,” May 2009. [online]. Available:
http://www.components.omron.com/components/web/PDFLIB.nsf/0/0293ACA6B03161CD8625
7538007424DB/$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:
https://engineering.purdue.edu/ece477/Homework/CommonRefs/Mil-Hdbk-217F.pdf.
[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:
http://www.epa.gov/ozone/title6/608/disposal/household.html [Accessed April 15, 2010]
[21] U.S. Environmental Protection Agency, “Electronics Recycling (eCycling),” US EPA, 2009.
[Online]. Available: http://www.epa.gov/region2/ecycling/ [Accessed April 15, 2010]
[22] “RoHS: About Us,” RoHS, 2005. [Online]. Available:
http://www.rohs.gov.uk/content.aspx?id=6 [Accessed April 15, 2010]
[23] U.S. Environmental Protection Agency, “Appliance Disposal Practices in the United
States,” US EPA, 2010. [Online]. Available:
48
ECE 477 Final Report
Spring 2010
http://www.epa.gov/ozone/partnerships/rad/raddisposal_factsheet.html [Accessed April 15,
2010]
[24] Alcohol Controls, “Draft Beer Counter”, [Online Document], unknown publication date,
[Accessed: 2010 Feb 2], Available HTTP:
http://www.alcoholcontrols.com/drafbeercoun.html?gclid=CNfvweG61J8CFQEMDQodn2VScQ
[25] TapDynamics, “TapAdvisor Service Overview”, [Online Document], unknown publication
date, [Accessed: 2010 Feb 2], Available HTTP: http://www.tapdynamics.com/service.html
[26] US Beverage Net, “Company Profile”, [Online Document], unknown publication date,
[Accessed: 2010 Feb 2], Available HTTP:
http://www.usbeveragenet.com/Docs/USBN%20Profile%20Mar08.pdf
[27] KegWorks, “Draft Beer Systems”, [Online Document], unknown publication date,
[Accessed: 2010 Feb 3], Available HTTP: http://www.kegworks.com/company/draft-beersystems#DB4
[28] “ZG2100M/ZG2102M Wi-Fi Module Datsheet”, [Online Document], unknown publication
date, Available HTTP: http://www.zerogwireless.com/technology/techmicrochip.html
[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:
http://www.wlanantennas.com/wireless_standard_comparison.php
[30] Technovelgy, “How RFIDs Work”, [Online Document], unknown publication date,
[Accessed: 2010 Feb 3], Available HTTP: http://www.technovelgy.com/ct/TechnologyArticle.asp?ArtNum=2
[31] ASCO, “Subminiature Solenoid Valves,” 8256_NSFR1 Data Sheet, (n.d.). [Online].
Available: http://www.ascovalve.com/Common/PDFFiles/Product/8256_NSFR1.pdf.
[Accessed: February 17, 2010].
[32] ASCO, “Engineering Information,” (n.d). [Online]. Available:
http://www.thevalveshop.com/menu/auto/asco/engineering.pdf. [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:
http://www.linear.com/pc/downloadDocument.do?navId=H0,C1,C1003,C1042,C1032,C1064,P1
915,D1885. [Accessed: February 17, 2010].
[34] Vishay, “Power Mosfet,” IRF510, SiHF510 Data Sheet, 2008. [Online]. Available:
http://www.vishay.com/docs/91015/91015.pdf. [Accessed: February 17, 2010].
49
ECE 477 Final Report
Spring 2010
[35] Texas Instruments, “Digital Temperature Sensor with Two-Wire Interface,” TMP175,
TMP75 Data Sheet, 2007. [Online]. Available: http://focus.ti.com/lit/ds/symlink/tmp175.pdf.
[Accessed: February 17, 2010].
[36] Microchip, “PIC24FJ256GB110 Family Data Sheet,” 2009. [Online]. Available:
http://ww1.microchip.com/downloads/en/DeviceDoc/39897c.pdf. [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: http://datasheets.maxim-ic.com/en/ds/MAX3000E-MAX3012.pdf. [Accessed:
February 17, 2010].
[38] Parallax Inc, “RFID Card Reader, Serial/USB,” 28140/28340 Data Sheet, 2008. [Online].
Available: http://www.parallax.com/Portals/0/Downloads/docs/prod/audiovis/28140-28340RFID%20Reader-v2.1.pdf. [Accessed: February 17, 2010].
[39] ZeroG, “DS101: ZG2100M/ZG2101M Wi-Fi Module Datasheet,” (n.d.). [Online].
Available:
http://support.zerogwireless.com/FileManagement/Download/1d4f0f784fef4374ac2b534b3cba95
b9. [Accessed: February 17, 2010].
[40] Crystalfontz, “Serial LCD Module Specifications,” CFA634-TMC-KS Data Sheet, 2005.
[Online]. Available: http://www.crystalfontz.com/products/634/datasheets/342/CFA634_v2.0.pdf. [Accessed: February 17, 2010].
[41] Fairchild Semiconductor, “16/20-Key Encoder,” MM74C922/3 Data Sheet, 1987.
[Online]. Available: http://www.fairchildsemi.com/ds/MM/MM74C923.pdf . [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].
http://ww1.microchip.com/downloads/en/DeviceDoc/39897c.pdf
[43] ZeroG, “2.4GHz 802.11b Low Power Transceiver Module,” ZG2100M/ZG2101M Wi-Fi
Module Datasheet, Revision 2.6 No Date.
http://support.zerogwireless.com/FileManagement/Download/1d4f0f784fef4374ac2b534b3cba95
b9
[44] Omron, “Tactile Switch,” B3F Data Sheet, No Date.
http://www.omron.com/ecb/products/pdf/en-b3f.pdf
[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. http://datasheets.maximic.com/en/ds/MAX3000E-MAX3012.pdf
50
ECE 477 Final Report
Spring 2010
[46] Linear Technology, “Monolithic 1.5A, 1.25MHz Step-Down Switching Regulators,”
LT1767-3.3/LT1767-5 Data Sheet, Rev A 2K, No Date.
http://cds.linear.com/docs/Datasheet/1767fas.pdf
[47] Fairchild Semiconductor, “MM74C922/MM74C923 16-Key Encoder/20-Key Encoder,”
MM74C923 Data Sheet, October 1987 [Revised April 2001].
http://www.fairchildsemi.com/ds/MM/MM74C923.pdf
[48] Microsemi, “Surface Mount 1A Schottky Rectifier,” UPS120 Datasheet, July 31, 1998.
http://www.datasheetcatalog.org/datasheet/microsemi/MSC0889.pdf
[49] ASCO, “Direct Acting Sub-miniature Solenoid Valves,” 8256_NSFR1 Data Sheet, No Date.
http://www.ascovalve.com/Common/PDFFiles/Product/8256_NSFR1.pdf
[50] Parallax Inc, “RFID Card Reader, Serial/USB,” 28140-28340-RFID READER-V2.1 Data
Sheet, Aug. 2008. http://www.parallax.com/Portals/0/Downloads/docs/prod/audiovis/2814028340-RFID%20Reader-v2.1.pdf
[51] Texas Instruments, “Digital Temperature Sensor with Two-Wire Interface,” TMP75/175
Data Sheet, Jan. 2004 [Revised Dec. 2007]. http://focus.ti.com/lit/ds/symlink/tmp175.pdf
[52] Cui Inc, “DC Power Jack,” PJ-056 Data Sheet, No Date.
http://www.cui.com/getPDF.aspx?filename=PJ%2D056%2Epdf
[53] Central Semiconductor Corp., “Super-mini Schottky Diode,” CMDSH-3 Data Sheet, No
Date. http://www.datasheetcatalog.org/datasheet/central/CMDSH-3.pdf
[54] Crystalfontz America, Inc. “Serial LCD Module Specifications,” CFA-643_V.20 Data
Sheet, Rev 2.0, Oct 2005. http://www.crystalfontz.com/products/634/datasheets/342/CFA634_v2.0.pdf
[55] 4PCB, “Trace Width Calculator,” Accessed: May 03, 2010.
http://www.4pcb.com/index.php?load=content&page_id=95
[56] Microchip Technologies Inc., “PIC24FJ128GA010 Family Data Sheet,” Microchip
Technologies Inc., 2009. [Online]. Available:
http://ww1.microchip.com/downloads/en/DeviceDoc/39747e.pdf [Accessed: Jan. 25, 2010]
[57] Philips Semiconductors, “The I2C-Bus Specification,” Philips Semiconductors, DO 9398
393 40011, January 2000. [Online]. Available:
http://www.semiconductors.philips.com/acrobat/literature/9398/39340011.pdf [Accessed: March
25, 2010]
[58] “10.1 I2C – Part 1 – I2C Basics,” No date found. [Online]. Available:
http://www.engscope.com/pic24-tutorial/101-i2c-part-1-understanding-i2c-basics/. [Accessed:
Feb. 22, 2010]
51
ECE 477 Final Report
Spring 2010
[59] Microchip Technologies Inc., “TCP/IP Stack for PIC18, PIC24, dsPIC & PIC32,”
Microchip Technologies Inc., 2009. [Online]. Available:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2680&dDocNa
me=en537041 [Accessed: March 25, 2010].
52
ECE 477 Final Report
Spring 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.
A-1
ECE 477 Final Report
Spring 2010
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
ECE 477 Final Report
Spring 2010
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
A-3
ECE 477 Final Report
Spring 2010
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-4
ECE 477 Final Report
Spring 2010
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,
A-5
ECE 477 Final Report
Spring 2010
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-6
ECE 477 Final Report
Spring 2010
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
A-7
ECE 477 Final Report
Spring 2010
“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.
A-8
ECE 477 Final Report
Spring 2010
Appendix B: Packaging
LCD
PCB
Keypad
“Beer Me”
Button
Solenoid
Valves (x4)
RFID
Reader
Figure B-1: Back View of Unit
Figure B-2: Front View of Unit
Sixth-Barrel
Kegs (x4)
Figure B-3: Top View of Unit
B-1
ECE 477 Final Report
Spring 2010
Appendix C: Schematic
Figure C-1: Female DC Barrel Connectors (Left: Solenoid Valves, Right: PCB logic)
C-1
ECE 477 Final Report
Spring 2010
Figure C-2: Switching Regulators (3.3V and 5V respectively)
C-2
ECE 477 Final Report
Spring 2010
Figure C-3: 8-Channel Level Translator
C-3
ECE 477 Final Report
Spring 2010
Figure C-5: Temperature, RFID, LCD and IR sensor connections to PIC24
C-4
ECE 477 Final Report
Spring 2010
Figure C-6: PIC24F Microcontroller
C-5
ECE 477 Final Report
Figure C-7: Keypad Encoder Connections
Spring 2010
Figure C-8: Pushbutton Connections
C-6
Figure C-9: LCD connections
ECE 477 Final Report
Spring 2010
Figure C-10: Solenoid Connections
Figure C-11: Solenoid Switching Circuitry
C-7
ECE 477 Final Report
Spring 2010
Appendix D: PCB Layout Top and Bottom Copper
Figure D-1: Top PCB Layer
D-1
ECE 477 Final Report
Spring 2010
Figure D-2: Bottom PCB Layer
D-2
ECE 477 Final Report
Spring 2010
Appendix E: Parts List Spreadsheet
Part No.
Description
Unit Cost Quantity
PIC24FJ128GB108
Parallax 28140
Parallax 28142
CFA-643_v2.0
ZG2101M
ZG-ANT-01
AC164136-2
16-bit Microcontroller
RFID Reader
RFID Tags
20x4 LCD Display
Wireless Module
ZG2101M Antenna Kit
Wireless Module w/
PICtail
TMP175
Temperature Sensor
ASCO U8256A108E Food Grade Solenoid
7485ED
Keg Tap
BLAW5316
Beer Line Assembly
SSC-E2
CO2 Cross Connector
SST-E2
CO2 “T” Connector
Grayhill Series 88
5x4 Keypad
MMT4C923
Keypad Encoder
LT1767-3.3
12 to 3.3V Switching
Regulator
LT1767-5
12 to 5V Switching
Regulator
CMDSH-3
Silicon Schottky Diode
UPS120
Schottky Diode
SD7030-5R0
5 mH Inductor
MAX3001E
8-Channel Level
Translator
ATS08ASM
8 MHz Oscillator
IRL530
Power n-MOS
PJ-056
Female DC Barrel
Connector
PP-019
Male DC Barrel
Connector
EN-B3F
Push Button
AC164110
Header-Debug RJ 11
G5LE-1A4 DC12
AC Relay
Refrigeration Unit
Building
Wood, Paint, Tools
Materials/Supplies
Keg 1
¼ Barrel (Miller)
Keg 2
¼ Barrel (Killians)
Passives
Caps, Resistors
E-1
Total Cost
$0.00
$39.99
$.99
$64.99
$29.99
$35.00
$59.99
1
1
10
1
1
1
1
$0.00
$39.99
$9.90
$64.99
$29.99
$35.00
$59.99
$0.00
$54.38
$24.88
$6.69
$9.42
$6.83
$30.03
$8.95
$6.10
5
4
4
1
1
1
1
1
4
$0.00
$217.52
$99.52
$6.69
$9.42
$6.83
$30.03
$8.95
$24.40
$6.10
4
$24.40
$.39
$1.00
$1.23
$3.95
4
4
4
2
$1.56
$4.00
$4.92
$7.90
$1.17
$1.50
$1.08
1
10
2
$1.17
$15.00
$2.16
$.68
2
$1.36
$0.00
$9.99
$1.28
$175.00
$120.00
1
1
2
1
1
$0.00
$9.99
$2.56
$175.00
$120.00
$50.00
$32.00
$5.00
1
1
~
TOTAL
$50.00
$32.00
$5.00
$1075.84
ECE 477 Final Report
Spring 2010
Appendix F: FMECA Worksheet
Failure
No.
A1
Failure Mode
Possible Causes
Failure Effects
Output of
LT1767-3.3 = 0V
Power not connected;
Female DC barrel
connector failed;
LT1767-3.3 failed
open; Input or Output
capacitors (C3 or C4)
failed
LT1767-3.3 failed
short
PIC24F no longer
functional, thus
all other
components are
no longer
functional
A2
Output of
LT1767-3.3
> 3.3 V
A3
Output of
LT1767-3.3 is out
of tolerance
C3 or C4 failed
A4
Output of
LT1767-5 = 0V
A5
Output of
LT1767-5
>5V
Power not connected;
Female DC barrel
connector failed;
LT1767-5 failed
open; Input or Output
capacitors (C7 or C8)
failed
LT1767-5 failed
short
Method of
Detection
Observation
Criticality
Remarks
Low
User inconvenience
PIC24F,
Temperature
Sensors and
Wireless Module
overheat and fail
PIC24F,
Temperature
sensors and
Wireless Module
don’t operate
properly; possible
damage
Keypad encoder
and IR sensor are
no longer
functional;
Causes Failure
No. A7
Observation
High
Parts could overheat
and potentially cause a
fire
Observation
Medium
Damaged parts will
have to replaced
Observation
Low
User inconvenience
Keypad encoder,
RFID reader,
LCD, and IR
Observation
High
Parts could overheat
and potentially cause a
fire
F-1
ECE 477 Final Report
Spring 2010
A6
Output of
LT1767-5 is out
of tolerance
C7 or C8 failed
A7
MAX3001E Vcc
set to 0V
Same as Failure No.
A4
A8
Output of
MAX3001E
(translating 3.3V
to 5V) is out of
tolerance
Same as Failure A6
or C10 failed
A9
Solenoids don’t
open (when the
rest of the
circuitry is
working properly)
Input to any of
the power pins
(VDD, VSS,
AVDD, AVSS)
Female DC barrel
connector (to the
solenoids) failed
B1
C16, C17, C18, C19
and/or C20 failed
sensor overheat
and fail
Keypad encoder
and level
translator don’t
operate properly;
possible damage;
Causes Failure
No. A8
Switching
circuitry (for the
fridge and
solenoids), RFID
Reader and LCD
are no longer
functional
Switching
circuitry (for the
fridge and
solenoids), RFID
Reader and LCD
don’t operate
properly; possible
damage
Beverage choice
not dispensed
PIC24F doesn’t
operate properly;
PIC24F may have
been damaged
F-2
Observation
Medium
Damaged parts will
have to replaced
Observation
Low
User inconvenience;
Beverage isn’t
dispensing because it is
frozen: Beverage too
warm
Observation
Medium
Damaged parts will
have to replaced
Observation
Low
User inconvenience
Observation
Medium
Damaged parts will
have to replaced
ECE 477 Final Report
B2
are out of
tolerance
PIC24F not
receiving data
from RFID
Reader
Spring 2010
PIC24F stuck in an
infinite loop; Timer
interrupts affecting
the transmission of
data; Noise on the
UART RS-232 line
Noise on UART RS232 line; PIC24F
stuck in an infinite
loop
B3
PIC24F not
communicating
with LCD
properly
B4
PIC24F not
communicating
with Temperature
Sensors
PIC24F sent wrong
slave address; Noise
on I2C line
B5
PIC24F not
communicating
with Wireless
Module
PIC24F sent wrong
slave address; Noise
on SPI line
C1
Keypad Encoder
not receiving
input from
Keypad
Wires from keypad to
the encoder are being
shorted
RFID from the
user’s cup is
never identified
Observation
Low
User unable to make
beverage selection
“Garbage” values
are displayed;
Display goes
blank; Display
freezes in menu
Wrong
temperature
values are
received;
Refrigeration unit
doesn’t switch
on/off; Beverages
get too warm or
freeze
User data is never
received and
displayed on
LCD; User
account
information is not
updated properly
Input form user
aren’t received
Observation
Low
User unable to navigate
through menu or make
a beverage selection
Observation
Low
User inconvenience;
Beverage isn’t
dispensing because it is
frozen: Beverage too
warm
Observation
Low
User inconvenience and
owner inconvenience
Observation
Low
User unable to navigate
through menu or make
beverage selection
F-3
ECE 477 Final Report
C2
C3
C4
C5
C6
C7
D1
Output from
Keypad Encoder
is incorrect
LCD isn’t
working properly
Spring 2010
C11 and/or C12
failed
Incorrect or no
data is sent to
PIC24F
LCD controller failed LCD is showing
incorrect
characters; LCD
is showing a
blank screen
“Manual Pour”
Software error with
Beverage isn’t
Button isn’t
the Timer Interrupt;
being dispensed
working properly Weak connection to
when button is
PIC24F
pressed; Beverage
doesn’t stop
dispensing when
button is released
“Beer Me” Button Software error; Weak
Beverage
isn’t working
connection to PIC24F designated to the
properly
“Beer Me” Button
isn’t the correct
beverage; The
incorrect amount
of the beverage is
dispensed
IR Sensor always Phototransistor failed The RFID Reader
sends a logic low
short;
is never enabled;
whether or not the
RFID tag is never
beam is broken
identified
IR Sensor always Phototransistor failed
The system is
sends a logic high
open;
never reset to
whether or not the
main menu after
beam is broken
the user has used
the unit
Solenoids don’t
IRL530 Power
Beverage is never
F-4
Observation
Low
User unable to navigate
through menu or make
beverage selection
User unable to navigate
through menu
Observation
Low
Observation
Medium
Beverage constantly
dispensing onto the unit
can cause damage to
components by
moisture
Observation
Low/Medium
User inconvenience;
Too much of the
beverage is dispense
that can lead to
damaged components
through moisture
Observation
Low
User will not be able to
make a beverage
selection
Observation
Low
Other users will not be
able to use the system
Observation
Low/Medium
User inconvenience;
ECE 477 Final Report
D2
Spring 2010
open or are
constantly open
n-MOS failed
Solenoids
vigorously
opening and
closing
IRL530 Power
n-MOS has a
floating connection
dispensed or
won’t stop
dispensing
Solenoid valves
may be damaged
F-5
Observation
Medium
Possible damage can
occur to components
through moisture
Damaged parts will
have to replaced