ECE 477 Final Report  Spring 2012
Team 14  Future Register
Samuel
Oshin
Matthew
Finn
Brian
Crone
Yonatan
Feleke
Team Members:
#1: _____Brian Crone____________
Signature: ____________________ Date: __4/26____
#2: _____Samuel Oshin _________
Signature: ____________________ Date: __4/26____
#3: ____ Yonatan Feleke__________
Signature: ____________________ Date: __4/26____
#4: ____Matthew Finn___________
Signature: ____________________ Date: __4/26____
CRITERION
Technical content
Design documentation
Technical writing style
Contributions
Editing
Comments:
SCORE
0
0
0
0
0
1
1
1
1
1
2
2
2
2
2
3
3
3
3
3
4
4
4
4
4
5
5
5
5
5
6
6
6
6
6
MPY
7
7
7
7
7
8
8
8
8
8
9
9
9
9
9
10
10
10
10
10
3
3
2
1
1
TOTAL
PTS
ECE 477 Final Report
Spring 2012
Table of Contents
Abstract ........................................................................................................................................... 1
1.0 Project Overview and Block Diagram ................................................................................. 1
2.0 Team Success Criteria and Fulfillment ................................................................................ 2
3.0 Constraint Analysis and Component Selection.................................................................... 4
4.0 Patent Liability Analysis ...................................................................................................... 7
5.0 Reliability and Safety Analysis .......................................................................................... 11
6.0 Ethical and Environmental Impact Analysis...................................................................... 15
7.0 Packaging Design Considerations...................................................................................... 17
8.0 Schematic Design Considerations...................................................................................... 19
9.0 PCB Layout Design Considerations .................................................................................. 21
10.0 Software Design Considerations ........................................................................................ 24
11.0 Version 2 Changes ............................................................................................................. 30
12.0 Summary and Conclusions ................................................................................................ 30
13.0 References .......................................................................................................................... 32
Appendix A: Individual Contributions ..................................................................................... A-1
A.1 Contributions of Brian Crone: ...................................................................................... A-1
A.2 Contributions of Samuel Oshin: ................................................................................... A-2
A.3 Contributions of Yonatan Feleke: ................................................................................ A-3
A.4 Contributions of Matt Finn: ......................................................................................... A-4
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
-ii-
ECE 477 Final Report
Spring 2012
Abstract
The Future Register is point of sale system designed to implement new technologies in
order to provide a faster and more convenient checkout process for both customers and cashiers.
The product was designed to be used in environments similar to a fast food restaurant in which
the patrons order their food at a counter. Future Register features voice recognition that aides the
cashier in finding items on the menu, NFC that provides quick and paperless payment and receipt
transactions, and an IR sensor that is used for customer presence detection. These feature aim to
make the order and payment process much faster and more convenient for both the customer and
the employee.
1.0 Project Overview and Block Diagram
The Future Register consists of 3 different packages, as seen in figure 1. The LCD touch
screen will display our C# GUI and accept touch inputs from the cashier. The touch screen
connects to an Intel atom board through USB and VGA. The atom board runs Windows 7 and
powers the software that runs the application. It also connects to the microphone that is seen just
to the left of the touch screen through a standard 3.5mm audio cable. The microphone is used to
accept voice orders from a customer and send it to the application in order to use voice
recognition to suggest menu items.
The atom board uses its serial port to communicate to the third package of the product, the
PCB. The PCB enclosure is the clear acrylic box seen below the touch screen. The PCB contains
our microcontroller which interfaces with four different components. It uses ATD to accept input
from the IR sensor, which will determine when a customer is present at the register. The
microcontroller also uses GPIO pins to show messages on the LCD screen. These messages will
face the customer and inform him/her of information including total and when to pay. The last
component the microcontroller connects to is the NFC controller. The microcontroller uses SPI
to send and receive packets from the NFC controller that that are sent to and received from an
Android cell phone via near field communication (NFC). These NFC packets contain
information needed for payment and for receipts. All of this information is summarized in the
block diagram shown below in figure 2. In a restaurant environment, the touch screen will face
the cashier while the microphone and PCB enclosure will face the customer.
-1-
ECE 477 Final Report
Spring 2012
Figure 2: Finished product
-2-
ECE 477 Final Report
Spring 2012
Figure 2: Highest level block diagram
2.0 Team Success Criteria and Fulfillment
1.
2.
3.
4.
5.
Ability to customize the inventory via the user interface
Ability to communicate with an NFC devise
Ability to interface with an IR sensor to detect the presence of a customer
Ability to display prompts to a customer through an LCD screen
Ability to aid cashier by highlighting menu choices while placing orders with voice
recognition
The application successfully allows the user to customize and build an inventory from
scratch. Users can add, modify, and delete items, and the changes will be reflected every time the
application runs. The Future Register also successfully communicates with Android phones via
NFC. This allows customers to make payments and obtain receipts using their cell phones. We
successfully interfaced with our IR sensor in order to detect the presence of a customer. Presence
of a customer will engage voice recognition and show a welcome message, which means we can
successfully show message on the LCD screen. The screen will show welcome messages and
also inform the user of when to pay. Finally, we successfully implemented voice recognition.
-3-
ECE 477 Final Report
Spring 2012
When a user speaks the order, the application will search the inventory and list all items that
contain the keywords spoken by the customer. In summary, we successfully completed all
success criteria.
3.0 Constraint Analysis and Component Selection
3.1
Introduction
The future register is a product to realize the advancements in recent technologies by voice
aided ordering, NFC capable payments and NFC receipts. We intend to create this product by
using a microcontroller which will be interfaced with an LCD, an IR sensor, and an NFC
transceiver. The LCD will interface with the microcontroller through the GPIO pins. The IR
sensor will communicate with the microcontroller through the ATD converter. The NFC
transceiver will communicate through GPIO pins while simulating an SPI Interface. The
microcontroller will be connected to the atom board through a com port, which utilizes the
UART. On the atom board there will be several peripherals attached to it. The LCD monitor will
be attached through a VGA port and USB port for display and input. A microphone will be
attached through the onboard sound card. A hard drive shall be connected through SATA, and a
wireless card will be attached through the onboard PCIE.
3.2
Design Constraint Analysis
The design constraints of our project are centered on the several tasks we want it to do. Our
project should be able to receive voice input, do certain computations, display prompts and a
GUI, NFC transmission, IR sensor, and encryption. Receiving voice will be handled directly on
the atom board. The computation aspect will mostly be focused on the atom board, but the
microcontroller also has to do some computation for NFC transmission and the IR sensor.
Display will be handled both on the atom board and the microcontroller. The three big design
constraints are the microcontroller, atom board, and the NFC transceiver. There are no particular
constraints with packaging or power, as our product is an over the counter solution and will be
plugged directly to an outlet.
3.3
Computation Requirements
The computation requirements for this project are split between the atom board and the
microcontroller. The microcontroller’s job is to receive and transmit data through the NFC,
receive voltage data from the IR sensor and output messages to the LCD facing the customer.
There are no real-time constraints with the micro controller. The atom board houses most of the
computation requirements. It will house the Customer user interface, interface with the
microcontroller, the microphone, and the touch screen monitor. It will also be encrypting the data
of the receipts, credit card information, and other sensitive data.
-4-
ECE 477 Final Report
Spring 2012
3.4
Interface Requirements
There are several devices that have to interface with each other on our platform. The atom
board consists of 5 devices it needs to interface with. The Atom board will interface with the
LCD monitor, hard drive, wireless card, microphone, and the microcontroller. LCD touch screen
will be interfaced through DVI and USB. The Hard drive will be interfaced through SATA. The
Microphone will be interfaced through the MIC in audio jack. The wireless card will be
interfaced through the onboard PCIE slot.
The microcontroller will be interfaced through a com port on the atom board. The
microcontroller will also have 3 peripherals interfacing with it, the NFC, IR sensor and the LCD
screen. LCD screen shall be interfacing with regular GPIO ports, the NFC transceiver will be
interfaced through SPI, and the IR sensor will be interfaced with an ATD controller. The NFC
controller requires a voltage swing of 2.7-5.5V on its PVDD with a power dissipation of 0.5W,
but requires 3.3V on its other power ports. The LCD supply voltage is 4.5 to 5.5V. The High
level input voltage is 2.2 to Vcc. The low level input voltage is -0.3V to 0.8V. The IR sensor’s
supply voltage is from 4.75 to 5.25V and a supply current of 10mAdc.
The microcontroller will have to have a minimum of 35 GPIO pins, 1 UART, and 1 ATD
pin. The NFC transceiver needs 6 GPIO pins total, 5 GPIO pins to simulate SPI and 1 GPIO pin
for the handshaking protocol. The LCD screen will needs 8 GPIO pins for the data bus, and 3
GPIO pins for initialization and control. The IR sensor will only need 1 ATD pin for voltage
translation.
3.5
Off-Chip Peripheral Requirements
The 3 off-chip peripherals are the NFC transceiver, the IR sensor, and the LCD screen. The
NFC transceiver is needed to be able to receive payments from the customer, and send receipts to
the customer. The IR sensor is required in order to sense when a customer is in-front of the
register. The LCD screen serves as a means to communicate with the customer about when and
how to pay and receive receipts and it will also display the amount that needs to be paid.
3.6
Power Constraint
The power constraints are very minimal for our project as we will be continuously
connected to the wall. The way our product will be presented is in 3 separate parts which will
have 3 separate power chords. The touch screen monitor and the atom board will have their
power constraints handled by the manufacturers. The microcontroller module will need a wallwart. This will convert the 120V AC into a 5V DC which all our peripheral’s supply voltage are
rated. The constraint with the wall-wart is the heat it will generate. This will be handled by
having a heat sink, and ventilation slits when packaging our product.
-5-
ECE 477 Final Report
Spring 2012
3.7
Packaging Constraints
This product will have to meet a vague standard set by other Point of sale systems. The size
should roughly be the same as similar systems. It will be separated into 3 parts, the monitor
interface with the cashier, the NFC payment method and LCD screen that will be facing the
customer, and the main Atom board, which will be housed in a Mini ATX case. The monitor will
have an adjustable height to ease the cashier in viewing the screen to meet their own preference.
The LCD screen for the customer will be on a pole like structure in order to ease the customer in
reading the instructions.
3.8
Cost Constraints
The similar products on the market at the moment have a price tag of $800+. This allows us
to price our product at a lower and more reasonable cost to out-compete the competition and also
spread the use of NFC in North America. Our product will have an MSRP of $600 dollars which
ensures us about a profit of roughly $150, making it a profitable venture. For repairing purposes,
the software can be easily patched or upgraded through software upgrades. Replacing other parts
of the product will not have such a high cost, unless it is the monitor.
3.9
Component Selection Rationale
Our first major component that we researched and is our main cost is the LCD touch screen
monitor. As a group we agreed to have a monitor that is large enough to display vivid graphics
and demonstrate the User Interface we shall be implementing. There was one basic constraint
we had for the LCD touch screen which was it has to be larger than 13 inches. In our search, we
arrived at several LCD screens smaller than this size but decently cheap. We narrowed down
our search to 2 LCD touch screens that were larger than 13 inches but cheap enough for us to
buy. The first touch screen was the Planar PX2230MW [1]. It has a screen size of 21.5 inches,
resolution capable of 1920x1080. Its touch screen interface is through USB, it has VGA and
DVI inputs, and its own power supply. The other touch screen that was considered is the MPI
touch screen [2]. It has a screen size of 15 inches and a resolution of 1024x768. It has a VGA
input and the touch screen interface is USB. We chose the Planar LCD touch screen [1] for
several reasons. First, the options of interfacing the monitor to the atom board is more varied
with the Planar [1] vs. the MPI [2]. Secondly, the resolution of the planer exceeds that of the
MPI. There was also more information regarding the Planar[1] than the MPI [2]. Lastly, the
price, as the Planar [1] was more expensive, but it was only $50 more expensive, which isn’t a
great price difference.
Our second major component that we researched was the microcontroller. Our
microcontroller doesn’t have a great constraint as to on-chip peripherals, the only constraints we
have are pin count. The GPIO pin count has to exceed that of 31 and we would like extra pins
for debugging purposes or other unforeseen issues. The 2 micro controllers we looked at were
the PIC18F65K80 [3] and the dsPIC30F5011 [4].
-6-
ECE 477 Final Report
CPU Speed(MIPS)
GPIO
SPI
ATD
Ram Bytes
Program memory
Spring 2012
PIC18F65K80 [3]
16
54
1
11
3648 bytes
32 Kbytes
dsPIC30F5011 [4]
30
52
2
16
4096
66Kbytes
We chose the dsPIC30F5011 [4] mainly because it is faster. This helps because we will need
speed in receiving the transactions from the NFC transceiver [5] and sending receipts. With this
extra speed the time to process will be less than it would be on the PIC18F65K80 [3]. The
dsPIC30F5011 [4] also has an extra SPI slot which will be handy incase one doesn’t work. It
also has more program memory to accommodate our NFC [5] and LCD [6] interfacing. The
price difference between both microcontrollers is very negligible. The dsPIC30F5011 [4] also
has a lot of libraries that would help us with unforeseen situations and extra additions which we
could implement to increase our microcontroller functionality. There are a lot more supporting
documents with the dsPIC30F5011 [4] and code samples, which will greatly assist us while
programming on the board.
3.10
Summary
In this section I outlined the design constraints of our project. The product has a few
devices it should interface with. On the atom board it will interface with an LCD touch screen, a
microphone, a hard drive, a wireless card, and a micro controller. The micro controller will
interface with the atom board, the NFC transceiver, the LCD display, and the IR sensor. In order
to interface with these peripherals we need our microcontroller to have an ATD and SPI. The
atom board also has to have USB, VGA/DVI, PCIE, SATA, and a microphone jack. There are
minimal power constraints, and packaging constraints as the product will be sitting on a
countertop while been plugged directly to the wall. Our project will be able to compete with
other solutions on the market. Even without some functionality the others have, our product still
under-cuts the competition by at least $150.
4.0 Patent Liability Analysis
4.1
Introduction
The main components that warrant a detailed patent analysis are: the NFC mobile payment,
IR customer presence detection, AES encrypted receipt storage, and communication protocols
(in order of priority). In recent years NFC payment has been the source of many patent
applications. RFID, the parent of NFC, was patented in 1983 but it wasn’t until 2006 that NFC
finally got traction [2+*] leading to a multitude of patents in the last 5 years.
-7-
ECE 477 Final Report
Spring 2012
Currently there aren’t any full checkout solutions that are capable of replying with a digital
order receipt over NFC, full order management system with voice recognition and automatic
customer detection. This makes our product differ in both function and equivalence. However
through research I was able to locate a multitude of primitive RFID payment portals.
This section of the report will describe four patents and patent applications that come close
to two out of our four core subsystems: NFC mobile payment and IR customer recognition.
4.2
Results of Patent and Product Search
The following section deals with the various related patents found when searching for
patents that may be infringed, section is aimed to be of an informative nature.
4.2.1
Mobile NFC Payment
Patent US20090271276 awarded to John Richard at Qualcomm on October 29, 2009 deals
with an NFC mobile payment system where there is a point of sale device and an NFC capable
mobile device that holds encrypted financial data. This data is then decrypted for processing the
transaction [3+*]. The first claim on the patent depicts functionality relevant to future register
project.
“A method of conducting a financial transaction across an NFC-enabled point-of-sale
device, comprising: obtaining an NFC-enabled payment instrument having financial data;
selecting a mobile wireless instrument having a data processor capable of receiving and storing
the financial data, and processing and transmitting the financial data across a credit network;[3]”
The next claim then details the afore mentioned financial data as the account holder name,
primary account number, country code, expiration date and personal identification number. The
remaining claims however focus on the point of sale device computational and communication
capabilities such as being able to verify payment information over wireless mobile networks.
The next patent US20090144161 awarded to Michelle Fisher at Mobile Candy Dish on June
4, 2009 deals with a generalized mobile communication device payment system and mentions
that “the mobile device herewith mentioned can be an NFC-enabled phone [4]”. The abstract
describes an online transaction method with a point of sale device with a method of receiving
input from a user selecting items to be purchased. The method depicts sending total amount and
payment authorization to the user via a mobile communication device.
The relevant claims of the patent mostly deal in generalized terms describing most
transactions. The first claim depicts a method of conducting an online payment through a point
of sale device comprising of the user selected items, a total purchase calculation and response to
user via mobile communication. Claim 10 deals with a program that holds the shopping list and
can receive user input, calculate total and relay financial transaction messages to user. Lastly
claim 17 explains that authorization is for payment with credit, debit or prepaid card.
The third patent that was relevant to NFC mobile banking is US20100023449 awarded to
Dan Skowronek, Theodore VanDeburg and Sarah Owen at First Data Cooperation on January
-8-
ECE 477 Final Report
Spring 2012
28, 2010[5+*]. The patent deals with mobile device payment via NFC to a payment terminal via
a button or a user interface icon that starts the transaction. The abstract further states, “the NFC
component is powered off until the activation of the payment user interface device.”[5].
Only one claim is relevant to analysis for patent infringement and this is claim 1. It dictates that
the patent encompasses a method of processing a transaction with a mobile device over an NFC
protocol upon receiving a pay signal to the phone.
4.2.2
IR Customer Presence Recognition
Patent US20100274524 awarded to Gad Noor, Jacob Gabay, Dmitry Slomov and Jay White
at Motorola on October 28, 2010 deals with a distance detector of data between the data
acquisition device and an object to which data is to be acquired. This is a System and Method for
Auto Triggering of a Data Acquisition Device via distance detecting device. Within the
document we find IR is a device qualifying as a distance detecting device
Claim 11 states “A method comprising: acquiring the data from the object if the distance is
in a predetermined range.”[6]. Remaining claims reiterate or do not relate to project.
4.3
Analysis of Patent Liability
4.3.1
US20090271276 Qualcomm, Inc.
The future register product is susceptible to literal infringement and definitely infringes the
aforementioned patent under the doctrine of equivalents. The three aspects the project shares
with the patent are: the use of information on a credit card as the financial payment method,
transferring said information over NFC and lastly storing information encrypted in AES.
The encryption aspect of the project is safe from prosecution since the patent is made public
by NHTS [7]. This however doesn’t prevent the future register from being guilty of patent
infringement under the doctrine of equivalents.
4.3.2
US20100023449 First Data cooperation
Future register does not suffer literal infringement with this patent because our project is
focused on the point of sale instead of the cell phone interface for payment which is the focus of
this patent (Appendix B). The similarities with the patent occur on our cell phone interface. Both
the patent and our project depict a user putting their phone on an NFC antennae area to pay and
then confirm the payment. The patent is specific and clear in that it disables NFC capabilities of
the mobile device unless for use to pay (appendix C) where our interface has no such
responsibilities. The similarities mentioned above leave the future register project susceptible to
a lawsuit under the doctrine of equivalents but there is no cause for a lawsuit based on literal
infringement.
4.3.3
US20090144161 Mobile Candy Dish
This patent mainly deals with a self-service point of sale with the user selecting purchased
items; it is more relevant to a self-checkout procedure than a mobile payment register. The only
-9-
ECE 477 Final Report
Spring 2012
similarity to the Future Register is that NFC is mentioned as a possible medium for
communication of payment (an NFC sticker) and obvious steps involved in a financial
transaction; the steps mentioned are: a program that calculates the total, requests payment and
replies with payment confirmation up on success to user mobile device. However, the overall
patent is focused on online payment rather than mobile payment (appendix A).
The steps outlined are similar to the functions performed by our atom component however,
this depicts just about every digital register and since our core functionalities of receiving
financial information, storage of orders and digital receipts over NFC are not mentioned in the
patent, our product does not infringe this patent in neither doctrine of equivalents or literal
infringement.
4.3.4
US20100274524 Motorola: Auto Triggering of a Data Acquisition
The patent above was worth investigating but resulting analysis proved that the future
register does not infringe on this patent. The only clause in the patent that warranted such
investigation was “acquiring the data from the object if the distance is in a predetermined range”
which is similar to our micro controller making the microphone start listening when a customer
is in front of the register. However, the patent one calls the customer an object and on top of that
the patent is referring to dimension, movement and speed data when talking about data
acquisition. The two reasons put together make the future register free from infringing on this
patent.
4.4
Action Recommended
The first recommendation that applies to all the patents analyzed above is verifying that the
interpretations taken in this report are valid in a court of law by conferring with a patent lawyer.
As for the US20090271276 patent held by Qualcomm, this report recommends contacting the
company and negotiating a licensing fee in the efforts of avoiding a lawsuit. The company has a
market capital of 114.9B so it is not recommended to attempt to change the features to avoid
litigation; the entire project is closely tied with this patent so unless the project is completely
changed a drawn out legal battle is inevitable.
Next, patent US20090144161 is the most controversial patent infringement when it comes to
the mobile component of this project as per the doctrine of equivalents. The recommended action
is to advance production without licensing because the company is a small company out of
Berkeley and their implementation deals with a sticker instead of select phones built in NFC
communication capability creating a difference in function.
Patents US20090144161 and US20100274524 does not require any action as analysis shows
that the future register product does not infringe these patents in neither of the two categories.
The differences are vast enough that a lawsuit is futile.
-10-
ECE 477 Final Report
Spring 2012
4.5
Summary
The future register being mainly a mobile payment system focusing on a point of sale
terminal makes this project unique to most patents but to the saturated nature of the current NFC
ecosystem, the product is vulnerable to lawsuits. Apart from this NFC component, all the other
aspects of the project do not suffer any patent infringements.
Patent US20090271276 held by Qualcomm incorporated has been identified as an
unquestionable patent infringement. The patent describes the entire project with close precision
but since that company, Qualcomm, doesn’t have any products associated with this patent a
licensing deal is the recommended course of action.
From the detailed research and analysis of relevant patents this project is proven to market
ready if a licensing deal can be secured from Qualcomm. With the global rush towards NFC
mobile banking with Google and Apple pioneering the stampede, it puts this project in a strong
market position at the moment.
5.0 Reliability and Safety Analysis
5.1
Introduction
From a safety and reliability standpoint, the Future Register is a fairly harmless product.
As this section will go on to discuss, there are a few components that work with high voltages
that, should they fail, could result in user injury. There are three main packages for this product:
the PCB, the atom board, and the Planar touch screen. Since both the atom board and Planar
touch screen are professionally designed and tested commercial products, we will assume that
they have been designed to minimize failure rates. Therefore, they will not be within the scope of
this report. The main focus will be on the PCB and its components.
5.2
Reliability Analysis
The first component under consideration is the voltage regulator. We are using a
LD1117V50 5V LDO regulator. The regulator will provide the supply voltages for all of the
components on the PCB. We will provide the regulator with 9V and 500mA from a wall wart.
Since the operation of all the components depends on the regulator, failure of this component
would be critical. The reliability analysis of the regulator is shown in the table below.
Parameter name
VOLTAGE REGULATOR
Description
Value
C1
πT
Die complexity
Temperature coeff.
.02
16.0
-11-
Comments regarding
choice of parameter value,
especially if you had to
make assumptions.
101 to 300 transistors
100°C Max
ECE 477 Final Report
C2
πE
πL
πQ
λP
MTTF
Spring 2012
Pins Constant
Environmental Consant
Learning Factor
Quality Factor
Failures per 106 hours
Mean time to failure
.0012
2.0
1.0
10.0
3.224
35.408 years
3 pins
Ground Fixed Environment
> 2 years
Commercial Grade
The second component under consideration it the RS232 level translator. We are using the
MAX3232. We have chosen this component because it will also be handling voltages from the
serial port of the atom board, and it will most likely be operating at a higher temperature than the
rest of the components. Like the regulator, the translator is crucial to system functionality. It is
the key to communication between the microcontroller and the atom board. The reliability
analysis of the translator is shown in the table below.
Parameter name
C1
πT
C2
πE
πL
πQ
λP
MTTF
RS232 LEVEL TRANSLATOR
Description
Value
Comments regarding
choice of parameter value,
especially if you had to
make assumptions.
Die complexity
.02
101 to 300 transistors
Temperature coeff.
7.0
85°C Max
Pins Constant
.0072
16 pins
Environmental Consant
2.0
Ground Fixed Environment
Learning Factor
1.0
> 2 years
Quality Factor
10.0
Commercial Grade
6
Failures per 10 hours
1.544
Mean time to failure
73.935 years
The third component under consideration is the microcontroller. The Future Register uses a
dsPIC30F5011. We chose to component to analyze because of its high complexity and high pin
count. Because of these features, the microcontroller will be the component most likely to fail. A
failure of this would result in an overall system failure because the microcontroller is the central
control unit to the whole system. Its reliability analysis is shown below.
-12-
ECE 477 Final Report
Spring 2012
Parameter name
MICROCONTROLLER
Description
Value
C1
πT
C2
πE
πL
πQ
λP
MTTF
Die complexity
Temperature coeff.
Pins Constant
Environmental Consant
Learning Factor
Quality Factor
Failures per 106 hours
Mean time to failure
.28
3.1
.0032
2.0
1.0
10.0
9.32
12.248 years
Comments regarding
choice of parameter value,
especially if you had to
make assumptions.
16-bit addressing
125°C Max
64 pins
Ground Fixed Environment
> 2 years
Commercial Grade
The final component under consideration is the NFC controller. We are using the PN532.
The controller has 40 I/O pins and a very high complexity. These characteristics, like with the
microcontroller, make it more prone to failure than other components. Although the NFC
controller is not crucial to system operation, it is the main feature of the product. Failure of the
NFC controller would make it a much less useful product. The reliability analysis of the
component is shown below.
Parameter name
NFC CONTROLLER
Description
Value
C1
πT
C2
πE
πL
πQ
λP
MTTF
Die complexity
Temperature coeff.
Pins Constant
Environmental Constant
Learning Factor
Quality Factor
Failures per 106 hours
Mean time to failure
.14
.96
.019
2.0
1.0
10.0
0.5144
221.92 years
Comments regarding
choice of parameter value,
especially if you had to
make assumptions.
8-bit addressing
85°C Max
40 pins
Ground Fixed Environment
> 2 years
Commercial Grade
In general, the PCB component of the Future Register have pretty good reliability, with the
exception of the microcontroller. Other than the microcontroller, the smallest MTTF is over 35
years. One component even has an MTTF of over 220 years. While it is too late to redesign now,
there are a few adjustments that could have been made to increase reliability of the
-13-
ECE 477 Final Report
Spring 2012
microcontroller, and thus the reliability of the system and the product as a whole. the dsPIC too
much computing power for the purposes of this project. A different microcontroller could
possibly have been used with less I/O pins, reducing the complexity and increasing the
reliability. It should also be noted that the maximum possible values were used for the
temperature constant and quality factor. This results in a more conservative analysis, and
possibly lower MTTF’s.
5.3
Failure Mode, Effects, and Criticality Analysis (FMECA)
We have defined three different criticality levels. A high criticality failure results in an
inoperable system along with a high chance of user injury and should carry a failure rate no
greater than 10-9. A medium criticality failure results in an inoperable system, but carries little to
no chance of user injury. Finally, a low criticality failure results in a system that, though still
operable, has less functionality and inconveniences to the user Low criticality failures will have
failure rates greater than 10-6. As mentioned above, the Future Register carries very little chance
to ever injure a user. However, there could be an instance of overheating with the voltage
regulator that could result in an injury. We thought it would be best to differentiate this failure
from the rest of the component failures. The schematic has been broken into 5 functional blocks.
These blocks include power, microcontroller, NFC, and RS232. The fifth block will consist of
the LCD screen and the IR sensor. These two components are grouped together because their
failures will be low criticality and just result in inconveniences to the users. The different failure
modes and their corresponding effects and criticality levels can be seen in the FMECA tables in
appendix B.
5.4
Summary
Overall, the Future Register is a harmless and reliable product. The reliability analysis
showed favorable MTTF’s for the all of the selected components except for the microcontroller.
However, we used maximum operating conditions for components to obtain a more
conservative reliability analysis. Because of this, the system as a whole still has high reliability.
The FMECA charts in general show failure modes resulting in medium or low criticality
failures. There was only one failure mode resulting in a high criticality failure. This failure
mode was related to a voltage regulator failure and possibly overheating the board and the
package. However, because this failure is very unlikely, the Future Register remains a very safe
product. There were four low criticality failures. Two dealt with the NFC controller; one dealt
with the LCD; and the fourth dealt with the IR sensor. These four failure modes would remove
functionality from the system, but overall the system would still be operable. As was mentioned
in the beginning of the report, the product also uses an atom board and a Planar Touch screen.
We are assuming that these two components were professionally designed and thoroughly tested
for maximum reliability and safety, thus maintaining the safety and reliability of the Future
Register.
-14-
ECE 477 Final Report
Spring 2012
6.0 Ethical and Environmental Impact Analysis
6.1
Introduction
The component likely to fail the most in Future Register is the microcontroller. We expect
about 10 failures per 114 years not including outside variables. (CITE: see “Reliability and
Safety Analysis” presentation). With such a low failure rate and such a long timeframe, we
focused our product disposal strategy on individual units that break down rather than creating a
recycle/replace strategy for each Future Register made. We expect our product to be far obsolete
after the 114 year timeframe (and we’re expecting flying cars by then).
6.2
Environmental Impact Analysis
 Manufacturing StageOne manufacturing concern we had was with our large touch screen LCD. Around 2008,
a lot of articles came out concerned with the fact that Nitrogen Trifluoride was being used in
the manufacturing of LCD screens. This is a significant greenhouse gas and
environmentalists were very concerned [1]. Many LCD manufacturers quickly responded and
replaced the greenhouse gas with Fluorine. [2].
Microchip, the company that makes our microcontroller, is a “Certified Green Partner”
company. This is a collaboration of companies that adhere to third party environmental
standards and inspections [3].
We trust that Purdue has picked a respectable company to create our PCB, because not
much environmental information is listed on their website.

Normal UseDuring the normal use of our product, we have two environmental concerns: the power
consumption of our device and the noise pollution from our wireless NFC and Wi-Fi
transmissions. Each of our components has relatively low power consumptions. 48W from
our touch screen LCD, 69W from our atom board, and 1.44W from our PCB. This sums to a
total power consumption of about 119W. At this low level, we are not very concerned with
putting the system in a “sleep state.”
Future Register has a low frequency footprint as well. The NFC transmissions have a
range of only a few decimeters, and our Wi-Fi adapter is 802.11b certified.

DisposalDisposal/Recycling is the most complicated part of our environmental strategy. We plan
on our product being implemented nationwide, so a single recycling plan is not sufficient.
We have divided Future Register up into two parts for disposal: the touch screen and the
-15-
ECE 477 Final Report
Spring 2012
atom board/PCB. Planar, the company that manufactures the touch screen, has an
“environmental initiative” that points a customer in the right direction for recycling their
products [4]. Their products contain small amounts of mercury so we need to be very careful
when disposing of our touch screen. Most states have electronics recycling policies in place
to handle this for us, and several regional programs such as “E-Cycle St. Louis” exist for
states without such programs [5].
The EPA suggests that we find a local recycling program for our PCB. We can either
take our broken PCBs to a state/regional recycling center like we are with the touch screen,
or we could use an online recycler such as “B.W. Recycling” to recycle large quantities [6].
6.3
Ethical Challenges
There are two main ethical challenges with Future Register. First, customers trust us with
their credit card information, so have to ensure their information is not compromised in any way.
We accomplish this by using AES encryption throughout our transaction with the customer. All
credit card data is encrypted and then stored. This will help us avoid any “plain text” hacks that
have plagued companies for the past two years.
Secondly, our product collects a lot of data about a user involving their shopping habits.
“Big data” companies have thrived since the emergence of Facebook, and the ethicality of
tracking users through their shopping habits is a lengthy debate [6]. Unfortunately, we cannot do
much to deter companies from using Future Register to collect shopping data. At the end of the
day, it is the company’s decision to handle the data they collect responsibly.
Our product does not have any moving parts, so the only warnings we would need are:
“make sure to securely fasten each component to a stable surface,” and “do not open any of the
project enclosures.”
6.4
Summary
This report addresses the environmental and ethical concerns of producing, using, and
recycling Future Register. There are no large issues that go unaddressed and we are confident
that every effort has been made to make Future Register a safe and reliable product.
-16-
ECE 477 Final Report
Spring 2012
7.0 Packaging Design Considerations
7.1
Introduction
The register will have a customer side and a cashier side. The cashier will use a large 23”
touch screen to make orders. The atom board will be in a standard computer case. The customer
interface will be enclosed in a clear acrylic case in order to illustrate the circuitry of our device.
7.2
7.2.1
Commercial Product Packaging
Product 1
Figure 7.2.1-1: TouchSuite
http://www.touchsuite.com/
The first commercial product we looked at was the “TouchSuite” [2]. This is a modern day
cash register that is targeted towards small businesses. It is an all-in-one register that comes with
inventory, marketing, and accounting support. They have a very modular approach to their
packaging. The LCD screen serves as the center piece of the modules with the receipt printer, bar
code scanner, and headset all serving as peripherals. We took a very similar approach. We have a
main computing station and then a separate interface for both the cashier and customer. This will
provides flexibility for our device. It can adjust to various cash register setups. We deviated from
TouchSuite’s design by having two separate interfaces instead of one big one. TouchSuite’s
design has the cashier doing all of the work, while we are focusing on automating as much as
possible.
-17-
ECE 477 Final Report
7.2.2
Spring 2012
Product 2
Figure 7.2.2-1: Toshib point of sale box
http://www.toshibatecusa.com/products/pointofsalesystems/ST-A20_Main.htm
This product from Toshiba is a simplified version of the above idea. It comes with a touch
screen and a credit card reader. However, there are no bar code scanners, receipt printers, or
other peripherals. Again, this product is focused on exchanging information with the customer
through the traditional method of handing over your credit card and receiving a receipt.
7.3
Project Packaging Specifications
Our design is split up into three different sections: customer interface, computing module,
and cashier interface.
The customer interface houses a microcontroller, an LCD screen, the NFC transceiver, and
the IR sensor. The micro controls the other components and also relays NFC communication
information to/from the computing module. The LCD screen is there to give the customer
commands, telling them when to hold up their NFC-enabled cell phone and whether each
transaction is successful. Our main goal in this portion is to have our NFC transceiver be right up
against the packaging. This will maximize our transmit distance to an NFC-enabled device. We
will have to fly wire several of our components to the PCB in order to make the packaging more
user friendly. Appendix A shows an initial image of our Customer interface box. We have
tentatively placed the NFC receiver directly underneath the LCD screen. However, this might
need to be adjusted because of concerns with mixing our analog NFC device with our digital
circuit. There will be two cables coming out of the back/top/bottom. The location of the cable
exit hole is not important and easily can be adjusted up until drill time. We will have a 9V wall
wart cable to provide power to the PCB, as well as a COM cable to enable communication
between our micro and our atom board. Lastly, the microphone cable will travel from the
customer interface to the atom board. For now, we plan on fitting this into a custom built clear
acrylic box [4]. This will enable us to more easily present the circuitry involved in our design.
The computing module holds an atom board, internet connection, and long-term storage
device. Both the customer interface and cashier interface interact through the computing module.
Here is where a majority of the software runs, controlling tasks such as: recording orders,
-18-
ECE 477 Final Report
Spring 2012
keeping track of inventory, controlling each interface, and logging all relevant data. Our atom
board comes in a computer case and we will be using that as our packaging for this portion.
The cashier interface is a touch screen LCD. The actual program that provides the GUI is
run in the computing module; this is simply a visual I/O device to communicate with the cashier.
We will be using the package that the LCD screen comes in.
7.4
PCB Footprint Layout
We are looking to have sockets for our LCD screen, NFC device/antennae, and IR sensor
connections. All of these components need to be fly-wired from the PCB board so that we can
place them on the edges of the project enclosure box. Headers will easily enable us to connect
these components to the PCB and still let them be stand-alone and adjustable. While we have not
actually connected all of the components, the footprint in Appendix C shows a scale model of
each component’s size. For now, the headers will be placed in any available space.
7.5
Summary
This report analyzes the packaging specifications of Future Register. We are not
anticipating problems with heat generation; however we can easily adjust the enclosures to
include fans and heat sinks. The customer interface needs to allow for easy interaction with the
customer and a good visual of our PCB and other circuitry. The computer case comes with its
own enclosure for the atom board. The cashier interface has its own touch screen enclosure as
well.
8.0 Schematic Design Considerations
8.1
Introduction
Future Register is split ino two main subsystems. These two subsystems are centralized
around an atom board and a microcontroller. The atom board will interface with the touch
monitor, the microphone, and the WiFi transceiver. The microcontroller will interface with the
IR sensor, the NFC transceiver, and a small LCD screen used to display messages to the
customer. This section will go onto discuss the theory of operation behind these two systems,
along with the hardware design relating to the microcontroller subsystem.
Because portability is not a goal of this product, the future register will have three different
power sources. The microcontroller and atom board subsystems will be powered separately
because they operate at different voltage levels and are also in separate packages. Finally, the
LCD touch monitor will have its own power source due to it large amount of power it will be
dissipating.
8.2
Theory of Operation
As mentioned above, the future register is divided into two major subsystems, with the
first revolving around an atom board. We will be using an ICH8M Mini-ITX motherboard
running an Intel Atom Processor D510, which is a dual-core processor running at 1.33 GHz. The
-19-
ECE 477 Final Report
Spring 2012
board requires a 12V DC source, which will be supplied by the provided AC adapter. The board
will communicate to a WiFi transceiver through one of its USB ports. It will receive voice input
from the microphone through a standard 3.5mm audio port. The last main peripheral of the atom
board subsystem is the LCD touch monitor. The atom board will transmit graphics data through
its dedicated VGA port, and the monitor will transmit touch input data through a USB line. The
monitor will also have its own independent power source because it will be running directly off
of an AC outlet.
The second subsystem is centered on the microcontroller. We have chosen the
dsPIC30F0511, which has a operation voltage of 2.5V – 5.5V. The three components that the
microcontroller will be communicating with are the IR sensor, the NFC chip, and the small LCD
screen. The LCD and IR sensor have operating voltages of 5 volts, but the NFC chip operates at
3.3 volts. Therefore, its power line will first go through a voltage regulator. The rest of the power
signals will come from a 5V DC source. The source comes from a 9 V 500 mA wall wart that
first passes through a LD1117V50 voltage regulator.
The microcontroller and atom board will have to communicate in order to transfer payment
information, receipts, etc. This will be accomplished through the serial port of the atom board
and the UART of the microcontroller. Because the microcontroller will be operating at 5V, it
will first have to transmit its data to an RS232 level translator to be able to handle the voltage
difference. The translator we will be using is the MAX3232. It also has an operating voltage of
5V. Therefore, it will also be powered by the DC source for the microcontroller subsystem. The
translator will send its signal to a D-SUB 9 connector so that we will be able to connect to the
atom board through the use of a COM cable.
8.3
Hardware Design Narrative
The future register will be using the SPI, UART, ADC, and GPIO subsystems of the
microcontroller. The SPI peripheral will be used to communicate with the NFC transceiver.
However, because the PN532 operates at 3.3 volts, the SPI signals will first have to go through a
SN74LVC8T245 logic level converter. The NFC chip will require 4 pins from the
microcontroller in order to transmit at 5 MHz it will connect to the SCK2, SDI2, SDO2, and SS2
on PORTF. The UART will be used to transmit data to an RS-232 level translator which will
then communicate with the serial port of the atom board. It will be assigned to U2RX and U2TX.
With this port assignment, the UART and SPI are separated on PORTF and PORTG. Any other
combination of pins from the SPI and UART would have been conflicting.
The ADC will connect to the IR sensor through one of the analog pins located on PORTB.
By using an analog signal from the IR sensor as opposed to a digital input, we will be able to
detect the proximity of a customer with greater accuracy instead of a threshold of present or not
present. This will leave all of PORTD available to be programmed as GPIO pins to connect to
the LCD screen. The LCD will require 3 pins for control signals along with 8 more pins for
parallel data transmission. We chose to use a parallel transmission because the other subsystems
will be using a relatively low number of pins. Therefore, parallel connections will allow for
-20-
ECE 477 Final Report
Spring 2012
faster transmissions and a quicker refresh. There will also be one pin designated to a pushbutton
which will be programmed as a reset button.
8.4
Summary
The future register is divided into two subsystems and three power supplies. The first
subsystem is centered on the atom board, which has the first power supply of 12V DC. The atom
board will communicate with a WiFi receiver through the USB port to back up all stored
payment data and transactions. It will communicate with a microphone to receive voice
commands. Finally, it will communicate with an LCD touch monitor, which has the second
power source connected directly to an AC outlet, through its VGA and USB ports. The atom
board will communicate with the microcontroller through its serial port.
The second subsystem is centered on the microcontroller. This entire subsystem will be
running off of the third power source, which is a 9V wall wart. The microcontroller will be
communicating with a small LCD screen using its GPIO pins, with the NFC chip using SPI, and
with the IR sensor using its analog input and ADC. The microcontroller will then transmit its
data to the atom board with its UART through an RS-232 level translator. All components will
be running off of a 5V regulated power signal, and the NFC chip will run off of a 3.3V regulated
signal.
9.0 PCB Layout Design Considerations
9.1
Introduction
The printed circuit board is responsible for the customer prompt display LCD, NFC
controller, NFC antenna, microcontroller, atom COM interface and IR sensor. The remaining
components are implemented by the use of an atom board. To keep the layout modular it is
divided into four parts; the NFC controller and antenna, microcontroller and IR sensor, LCD and
MAX3232 COM interface and finally the Voltage regulator and power circuit. These modules
have been grouped as such to avoid and overcome noise problems. The overall layout is
currently set at 6’x5’ to simplify preliminary routing. The layout is restricted to two layers and a
maximum of 45 degree bends on traces. The following sections will go in-depth describing how
the specific layout choices reduce noise and heat.
PCB Layout Design Considerations – Overall
Let us first start with the general considerations for the overall PCB layout design in the
attempt of following recommendations for recommendations for Electromagnetic Compatibility
[1]. Traces are one of the main ways to reduce noise generation and coupling. Hence, the layout
has taken the following considerations: straight and short traces to reduce noise generation,
thicker and isolated high current traces so as not to disrupt high frequency or low level analog
signals. For example, the antenna header is isolated from the thick regulator output trace carrying
9.2
-21-
ECE 477 Final Report
Spring 2012
250 mA and IR analog output trace carrying 33 mA. Other general precautions include avoiding
components from being in the middle of a circuit loop and trying to have maximum possible
space between traces.
Now let’s discuss the specific considerations for the different modules. The first module we
will discuss is the NFC antenna and controller, as you can observe from appendix A the antenna
circuit and header is isolated from the system at the top left portion of the layout. The controller
also features an external oscillator we have put them at opposite sides of the controller circuit,
since a low analog signal (ANT) in close proximity to a high frequency clock signal is against
EMC layout recommendations [1]. Again in the efforts of complying with EMC
recommendations we have put the oscillator close to the controller and put the antenna farther
away. Due to time running out we decided to get a premade NFC breakout board and have that
replace our prior implementation. This decision was made because there wasn’t enough
information and to debug hardware and software at the same time. Hence, buying the breakout
board allowed us to have a working hardware base to build on.
The second module consideration has to deal with the LCD placement and MAX3232
COM interface. The LCD has been paced as a part just to use as a place holder on the PCB to
check for height compatibility but there is a header to the LCD. Since the LCD utilizes port d
GPIO of the microcontroller [4], it has been placed directly above the microcontroller. For
further details refer to section 3 below. Similarly the MAX3232 COM interface utilizes the lower
pins with current micro orientation it is placed below the microcontroller. The MAX3232 is
placed as closed to the edge of the board because it deals with a COM DSBU9 and to reduce
noise coupling we have kept it as close to the I/O as possible [1].
The third module consideration is the microcontroller and IR, the micro controller
considerations are specified below in section 3. The IR sensor is located close to the micro but
the trace follows an unconventional path to avoid data traces from the NFC and MAX3232. It is
recommended to separate analog and digital switching traces or make them perpendicular [1], as
a design decision we decided to go with option one and kept it away from the data traces coming
from the NFC and MAX3232.
Finally the voltage regulator has a module for its self the entire circuit is located at the
bottom right corner right next to the power and ground header and 0.1 µF Bulk capacitor. Even
though the entire circuit is going to be using ground and power from the regulator we chose to
trade trace length for the benefit of isolating a high noise circuit and keep it close to the input
header. Further details about the power layout can be found in section 3.
PCB Layout Design Considerations – Microcontroller
The layout considerations for the microcontroller were relatively simplified because we are
not sourcing any power or clock signals from the microcontroller. That being said we still had to
take care to separate analog circuitry and digital components so that they do not conflict with
each other.
9.3
-22-
ECE 477 Final Report
Spring 2012
The primary concern with the microcontroller placement is to minimize trace distance to all
peripherals as such the microcontroller was place in the center relative to other components. One
challenge in doing this is that both, IR analog output to ATD input and NFC SPI communication,
were coming from the same side of the microcontroller. Considering this the two paths were put
were prevented from being parallel to each other through out their paths. The power bypass
capacitor and other circuitry such as a filters and pull up registers (for example UART pull up
resistor) are all kept at close proximity to the micro for maximum filter accuracy.
The microcontroller implementation also requires us to ground 4 pins each on opposite side
of the micro; this led to the possibility of a ground loop [1] which we avoided by bringing a
separate ground line to each of this pins instead of routing from a middle trunk like and
connecting them all to the same junction. This made pin routing a little difficult but was worth
the benefit of reducing ground noise as we cannot filter out.
ATD inputs were also kept straight, mostly horizontal and away from power sources. The
NFC SPI connection was routed with the shortest route in order to get minimum impedance for
the data connection. By having separated analog ground and power and digital ground and power
sources we also minimized noise bleeding into the different components such as IR low level
analog output or high frequency UART communication. And finally the trace carrying the power
was brought to the micro avoiding most components but once it got close to the micro there
wasn’t much that could be done.
PCB Layout Design Considerations – Power Supply
The first PCB layout had power running below and ground on the top layer, but after learning
that it is easier to filter out power noises than ground noise coupling it was changed to the current
implementation where ground is in the back layer and power on top. Another misconception that
was fixed was the need for voltage dropout regulator, in the early stages we were under the
impression that the circuit was built into the wall wart and hence did not need to be on the PCB
but after conferring with the course staff we have added this component.
The first power supply consideration was where to place the dropout regulator circuit. Going
along with EMC recommendation to keep IO logic close to their ports and isolating high current
or high noise circuits the power header and circuit were place at the bottom right edge of the
circuit. With this layout design we avoid any high frequency traces or low level analog signals
from noise coupling. A 0.1 µF Bulk capacitor right at the header also reduces some high
frequency environmental noises that may have gotten to the input header.
Ground routing was also another concern to avoid any voltage spikes or ground loops. The
design decision that realizes this is having many parallel paths to ground that eventually ends up
at the output of the regulator. This is a derivation of the ideal that Single point or star grounding
lowers common impedance coupling [1]. That combined with Conductance being inversely
proportional to log of diameter and directly to length [1] we have implemented thicker and
shorter routes for ground and power.
9.4
-23-
ECE 477 Final Report
Spring 2012
The atom board having a separate power supply was also considered as a possible problem
but by adding a MAX3232 we were able to account for any operating differences between COM
DSUB9 inputs [5]. Overall our analog and digital components have different legs of ground and
power. The power and ground paths were also kept as parallel as possible. Power systems can be
decoupled with filters so the layout was more focused on avoiding ground noise.
9.5
Summary
So far the report has detailed the various reasons that resulted in the PCB layout located in
the appendix A. Some of the factors that were taken into consideration are heat dissipation, space
conservation and electromagnetic interface from various sources such as high current traces,
inductance in ground, environmental noise, voltage spikes and so on. Some of the solutions have
not been implemented in appendix A as this is the preliminary layout and we are populating
more and more components as the weeks go by.
The overall PCB layout consideration was to make sensitive low level analog or high
frequency digital traces away from each other while maintaining economical space and trace
length. The microcontroller was a challenge to route since it has power, low level analog and
high frequency data traces; tools used to overcome this include thicker traces, perpendicular
paths for opposing traces and isolation. Finally the power component header was kept isolated
with the linear voltage dropout regulator to reduce noise coupling at the cost of having long
traces, and due to the high current content power and ground components were implemented
using thicker traces.
10.0 Software Design Considerations
10.1
Introduction
The future register is a register that will eliminate the use of paper during a transaction
through the use of the NFC by the NXP PN532[2]. The Atom board shall handle all its
peripherals through a class structure written in C#. The tester module shall be written through the
android SDK supplied by Google, and shall interface with the onboard NFC on the device. The
tester module shall be sending credit card credentials through its NFC antenna to the PN532
attached to our microcontroller, the dsPIC30F5011[3]. It will also be able to receive receipts
through the SPI peripheral. Attached to the dsPIC30 is an infrared sensor to determine the
presence of a customer. This shall be interfaced through the microcontroller’s ATD port. There
will be an LCD interfaced with the microcontroller through general purpose pins. This will be
used to prompt the user when and where to place their NFC device. The overall microcontroller
is organized in a flag driven fashion designed in embedded C.
10.2
Software Design Considerations
The main control station of our project is the dsPIC30F. This micro controls most of our
functionality that deals with interfacing with all the important aspects of our project. The
dsPIC30 interfaces with the Atom, PN532, Long range IR Sensor, and the LCD.
-24-
ECE 477 Final Report
Spring 2012
The LCD will be interfaced through the PORTD pins on the dsPIC30F, RD0 to RD10. To
initialize the LCD several specific sets of instructions need to occur. The first part of initializing
is turning on the LCD and waiting for a minimum of 15ms. This is to make sure the internal
initializations are done completely. Through the entire process of initialization, RD0 and RD2
will stay at 0 to ensure instructions are written to the internal registers. Following the internal
initialization, RD7 and RD8 have to be logic 1 for at least 4.1ms, after the enable signal has been
strobed. RD7 and RD8 shall remain logic 1 for another at least 100 us after another enable signal
strobe. Finally to use the 8-Bit interface, you strobe this command once more and wait until the
busy flag isn’t 1, RD10. After initializing the LCD to 8-Bit mode, the remaining configurations
can be taken place. First set both RD6 and RD5 to set a 2 line 5x10 LCD. Then turn the display
off by de-asserting other RD pins and asserting RD and strobing RD1 (enable pin). Wait for
LCD to not be busy, then de-assert all pins and set RD3 then strobe RD1 to clear the display.
Wait for the LCD to not be busy then de-assert all pins and set RD5 and RD4 and strobe RD1 to
set the address to increment and not shift the screen. Finally, to set the cursor and blinking mode,
wait for LCD to not be busy, then clear RD pins and set RD3, RD4, RD5, and RD6, this will turn
the cursor on and blinking. After this, initialization is complete. During initialization, the
PORTD pins are set to output in order to send the correct bits to the LCD to choose the correct
mode and achieve proper initialization. However, these pins are switched from inputs to outputs
throughout the course of interfacing with the LCD. The method of changing the direction is
governed by the TRISD registers. To make the pins output you need to set each bit in the register
to 0 or 1 for input. Data can be retrieved from these pins through the PORTD registers, and can
be written through the LATD register, through these registers the LCD can be sent bytes to be
written.
The IR Sensor will be interfaced through the ATD peripheral onboard the dsPIC30F. It will
be using the port RB1/AN1/CN3/VR-, pin 15. The ATD initialization is quite a daunting process.
To configure the ATD for the IR Sensor, we will first select the AN1 pin to be used as an analog
input by making ADPCFG = FD. Next we select where the voltage reference will be taken from
through ADCON<15:13> being 000. Then the conversion clock is selected to be 32*TCY by
ADCON3<5:0> being 111111. Since this conversion isn’t too complex we can simply select
CH0 for AN1 by de-asserting ADCON2<9:8>. Next we pick the channels to be sampled
individually and as an input scan. We also need to select a positive input through AN1 at CH0
through ADCHS being 1. An appropriate conversion trigger source is the internal counter, and
control of when sampling should start is in our control. For this we need to make
ADCON1<7:0> = E0. And seeing as we want to sample at a quite slower rate, a 31*TAD is
chose for sampling which is ADCON3<12:8> = 11111. We want the conversion to be unsigned
integers to simplify calculation of the distance, ADCON1<9:8> = 00. After every 2nd conversion
and sample we want to have an interrupt. Finally we turn on the ATD module through
ADCON1<15> = 1. If need be further configuration of the ATD interrupt could be attained. To
get the ATD sample, read the value at ADCBUF0.
-25-
ECE 477 Final Report
Spring 2012
The PN532 will be interfaced through its SPI interface with 4 GPIO pins which will
simulate an SPI interface. This was implemented mainly due to the nature of a design flaw we
encountered. 1 Extra GPIO pin will be required to satisfy handshaking protocols. Other pins that
needed to be interfaced before are either directly handled through jumpers or handled on the
breakout board. To simulate the SPI function, we assign LATC14 to be MOSI, RG14 to be
MISO, LATG0 to be SCK, and SSL to be LAC13. The IRQ pin coming from the PN532
breakout board, shall be interfaced with the RG15 pin. Drivers have been created to act like SPI
Reads and SPI writes in accordance to the PN532 behavior.
The Atom communication shall be accomplished through the use of a MAX3232 chip to
step up voltage from the 5V being supplied. This chip also utilizes the UART peripheral on the
dsPIC30F. The MAX3232 is connected to pin 31 and pin 32, U2RX and U2TX respectively.
The baud rate of 9600 shall be accomplished by setting the U2BRG register to
((14745600/9600)/16)-1 which is 95. This will effectively create a baud rate of 9600, which is a
0% error. The UART setting we shall aim for is 8-bit data, no parity, and 1 stop bit. To achieve
this, we will set U2MODE<2:0> to 000. Then the UART will be enabled through U2EN
(U2STA<10>). This process will initialize the UART for both transmitting and receiving. To
send load bytes into U2TXREG until U2STA<9> is set. To receive, poll U2STA<0> till its set.
If it’s set, there is a word in the buffer that can be read.
The main function shall be flag driven or polled. The flow of the program can be broken up
into stages, which allows polling to be more favorable. We continue to poll the ATD until it
meets our threshold. Then we transmit through UART and poll the UART receive buffer until we
receive a message, check the message then send to LCD and poll SPI until it receives
information. Transmit through UART and poll UART receive buffer until we receive another
message. Then send to LCD and send through SPI to PN532. This is our basic flow which
greatly favors polling, if there were interrupts, when we aren’t expecting information, the
program could be interrupted, slowing the operation as a whole.
Currently our code will be located in the flash memory which boasts 22K. The instructions
we shall be running are not computational intensive or exceedingly large. 22K is large enough to
contain all sufficient code. Temporary storage of local variables, heap, and stack shall reside in
the SRAM. A temporary storage of the credit card information and the information to recreate
the receipt on the NFC device shall also be stored in the SRAM.
dsPIC30F5011 Memory Map
000000h
000002h
000004h
00007Eh
000080h
000084h
0000FEh
Reset – GOTO instruction
Reset – Target Address
Interrupt Vector Table
Reserved
Alternate Vector Table
-26-
ECE 477 Final Report
000100h
00AFFEh
00B000h
7FFBFEh
7FFC00h
7FFFFFh
Spring 2012
User Flash Program Memory
(22K instructions)
Reserved
Data EEPROM
(1 Kbyte)
For debugging purposes, we have extra pin headers attached to our PCB for debugging and
other issues that may arise. These pins will be used to monitor signals through either its SPI
functionality or basic GPIO functionality. There are several ways that debugging can occur. With
this method a hook up to a logic analyzer would be ideal to check the signal levels and what
exactly is occurring. A debug mode would be created which will enable all debugging features,
but can only be activated before programming. When debug mode is active, there will be signal
LCD signals routed to RG0,RG1,RG2,RG3,RG12,R13,RG14, and RG15. These will monitor the
data signals going through the LCD. This will allow debugging of the LCD. Another method
could be using the 2nd SPI on our dsPIC30F. With this method we can debug all 11 signals that
go to the LCD instead of just 8. To debug other aspects of our project, simple print statements to
the LCD screen will be used. This will give us a visual look at what exactly is going on, and
makes it easier to debug because it mimics print statements which we are all used to. These
debugging methods are not finalized.
10.3
Software Design Narrative
The project consists of 3 main software areas, the Atom board, the dsPIC30F, and the
Tester application. The tester application is a simple program that will send and receive through
the NFC application built on Android SDK.
The software on the atom board will be a Windows 7 application, developed in C#. The
application will be comprised of 6 modules. These modules are the GUI, class hierarchy, speech
recognition, serial port communication, security and cryptography, and database backup. The
GUI is where the cashier or manager will process the order and manage the inventory of the
restaurant via the touch screen. Because Windows development is fairly new to the entire group,
the GUI is still in the research and design phase. The class hierarchy will make up the
infrastructure of the application. Here, there will be classes such as menuItem and comboItem
that will build up into one main class called restaurant. The restaurant class will contain the
inventory of the restaurant along with information about the restaurant plus the administrative
password used for encrypting and changing settings. The class hierarchy has been completed and
is ready for implementation. The speech recognition module will take the voice input from the
customer and convert it to text. This module will be developed using the
System.Speech.Recognition namespace [4] in the .NET 4.0 framework. This namespace used the
Windows voice recognition software. Due to the complexity of the namespace, this module is
still being researched. The serial port module will be used by the GUI to send and receive
-27-
ECE 477 Final Report
Spring 2012
payment and receipt information to the microcontroller. This will be accomplished using
serialPort class in the System.IO.Ports namespace [6], which is also in the .NET 4.0 framework.
This module is in the pseudo code stage. The next module, security, will serve the purpose of
encrypting payment information before it is stored onto the hard drive. The security module will
use the System.Security.Cryptography namespace [5] in order to encrypt the data using AES.
This module has not yet been started, but it has a fairly simple implementation. The final module
is the database backup module. In order to avoid storing a large number of credit cards on a local
disk, the application will be able to dump its payment information onto a secure database. The
database will be created on Microsoft SQL Server, and the communication will be handled using
LINQ in the .NET 4.0 framework.
The dsPIC30F hierarchical arrangement is a polling type structure that will involve 6
different modules, 4 of which will be manually coded and 2 which are provided by the MPLAB.
There will be a main controller which abides over all 6 modules and directs where the flow of the
program is and where it should be going. The main controller will be connected to the ATD
module, UART module, LCD module, SPI module, p30F5011 module, and libpic30 module. The
main controller will go through the general flow of the program as outlined in Appendix B. The
main controller’s purpose is to oversee the general flow of the program is in order, and to bring
each modularized segment together into one big program. To check the ATD threshold a .25s
delay shall be implemented before each check of the ATD buffer. The main controller is also in
charge of making sure the data received is correct in order to continue through the flow of the
program. For example, making sure the signal received from the UART is the “GO” signal in
order to continue to writing to the LCD. The main controller shall be implemented through a
series of while loops. This is because the flow could be broken up into stages. The flow can’t
advance until a certain requirement has been met. With the while loops, you can be assured the
required conditions have been met before continuing. The main program in progress but very
little progress has been made. Status: Not Done
The 2 modules provided by MPLAB are the p30f5011.h and libpic30.h. P30f5011.h
simplifies accessing all the ports and registers. They give each register a name instead addressing
them by their hexadecimal digit, a simple and easy to remember name is in place. Individual bits
can also be accessed individually through this module. The libpic30.h module makes it easy to
implement delays, mainly for LCD interfacing and the IR sensor threshold. Since these 2
modules are given by MPLAB, the status is completed, and it just needs to be integrated into the
main program.
The LCD module is the main interface with the LCD. It contains all the functions that will
be able to communicate with the LCD and all its initializations. The LCD module is there to add
a layer of abstraction to interfacing with the LCD display itself. It provides useful functions such
as putc, gotoxy, init, cursor on, and other such functions. This will simplify the main controller’s
code exponentially. The LCD module works by utilizing GPIO pins to communicate with the
LCD. The initialization module will initialize the LCD accordingly as described in Section 2.0.
There is gotoxy function, which will move the cursor to the position specified by the input
-28-
ECE 477 Final Report
Spring 2012
parameters. There is a putc function, which will be able to write a string specified through the
input arguments to the LCD, this function heavy relies on send_byte. The send_byte function is a
corner stone to interfacing with the LCD. The send_byte function is responsible for sending raw
data directly to the LCD by putting the address on the proper data line, strobing the enable signal
and waiting for the appropriate time needed. Another important function is the read_byte
function. This is the opposite of send_byte and it’s mostly used to check the busy signal and
know when to wait. The LCD module is 75% done. It contains almost all necessary functions
and more. It is a complete rewrite of the LCD functions supplied by MPLAB.
Status: In progress [1].
The ATD module is the interface with the IR sensor. It contains all the functions that will
be needed to accomplish customer detection. Its main purpose is to return information of the
current ATD sample in order for the main function to determine the presence of a customer. This
module will contain 2 functions, init and cur_sample. The init () function is the initialization of
the ATD in order to perform a 1 channel conversion on AN1. This initialization has been
outlined extensively in Section 2.0. The cur_sample () function will be a simple function that
will return the value of ADCBUF0. With this value the threshold can be compared to the current
sample. Coding for this module has not begun. Status: Not started, but it has been outlined, and
research has been conducted.
The UART module is the interface with the COM port and MAX3232. It contains all
functions needed to communicate with the Atom board. The purpose of this module is to ease the
communication with the COM port and allow for an easier interface to send and receive
information. This module will contain 3 functions in order to interface with the COM port. Init ()
will initialize the UART to a baud rate of 9600 and all other configurations outlined in Section
2.0. Send (str) will send a string through the UART. It will loop through the string while
monitoring the TXBUF to make sure there isn’t an overrun and keep filling the buffer as it
becomes available until there are no more characters to be sent. The Receive () function will
receive a string through the UART. It will continue to receive through the UART until a
terminator character is received. The function will then return the string accumulated by the
Receive function. Coding for this module has not begun. Status: Not Started, but it has been
outlined, and research has been conducted.
The SPI module is the interface with the PN532. It contains all functions needed to
communicate with the PN532 NFC controller chip. The purpose of this module is to simplify
communication through SPI by only bottlenecking it into 5 lines. This module would have low
level functions that simulate SPI communications, both read and writes (spi_read, spi_write) due
to the PN532 operating only in half duplex mode. A higher level function is to frame each
command in its own packet that the PN532 understands. Increasing the abstraction layer brings
you to the send command and ACK function. This function allows the microcontroller to send a
command, wait till the PN532 is ready, correctly receive the ACK packet, and then confirm it is
ready again. This is most useful in sending commands and making sure the PN532 correctly
receives it. On top of these functions lie all the other command functions to initiate the PN532
-29-
ECE 477 Final Report
Spring 2012
into a target or an initiator, with varying settings. There are also functions that send messages to
the NFC device and receive messages from the NFC device.
10.4
Summary
The Future Register project aims to rid the transaction process of paper, both cash and
receipts. The project is comprised of 3 parts, an atom board, a touch screen, and the payment
package. The Atom board is coded in C# and comprised of 6 modules, GUI, Speech, Menu,
Serial, Cryptography, and Database backup. The project also utilizes a dsPIC30F5011
microcontroller which is coded in embedded C. The project utilizes the ATD, SPI, UART, and
several GPIO to completely interface with an IR sensor, NFC Controller, Max3232, and an LCD.
11.0 Version 2 Changes
Having completed the project, there are many changes we would make along with things
we could have done better if we had a second iteration of the project. The first change we would
make would be to choose a different microcontroller. Although the dsPIC30 is powerful, we did
not do any signal processing, therefore using a dsPIC was unnecessary. A lower numbered PIC
microcontroller would have been sufficient. Another change we would have made would be to
redesign the NFC circuit. Our NFC circuit was not quite complete when we had it printed. This
led to us needing to purchase the breakout board. Also, we would have the NFC portion printed
on a separate board and connect it to the rest of the circuit with wires. This would allow us to
place the antenna wherever was convenient for a user to communicate with. Another change we
would make would be to either use a different touch screen or a different SDK. There were
several instances where the touch screen would not behave as expected. For example, double
tapping the screen would not fire the double click event on our application. This resulted in us
having to redesign the functionality slightly. A different touch screen, or a different SDK that is
designed to be used with touch screens, would solve this issue. One final addition we would
consider making would be to interface with a credit card reader in addition to the NFC payments.
We still want to eliminate paper transactions, but it would still be logical to be able to pay with
credit cards.
12.0 Summary and Conclusions
The future register was a successful project. We were able to achieve all of our goals and
meet all of our success criteria. Although not everything worked as expected the first time, we
were able to debug and either fix what was not working or find an alternate solution. We were
able to put learned skills to use and even learn a few new ones along the way.
From a software perspective, we successfully designed a C# application that used the .NET
4.0 framework. We were able to implement voice recognition, object-oriented design, serial port
communication, AES, and an elaborate GUI. Not only did we implement all of these features,
but we also had to design each module so that they could be interfaced with each other with
fairly low overhead.
-30-
ECE 477 Final Report
Spring 2012
From a hardware perspective, we successfully interfaced a microcontroller with many
several different components. We used ADC to interface with an IR sensor in order to determine
the presence of a customer. We used GPIO pins to display messages on an LCD screen. Finally,
we used SPI and other GPIO pins to interface with an NFC controller. By doing so, we were able
to send and receive data to an application we developed on an Android cell phone. In addition to
all of this, we were able to mount all of these components on our designed printed circuit board.
All of the skills and accomplishments mentioned thus far have been technical. However, as
we learned this semester, not all design constraints come from technical requirements. We also
had to take into account many other factors when building the Future Register. We had to take
into account patent liability and ensure that we were not infringing on previously designed
products. We had to look at the environmental impact of our design and the lifecycle of the
product. We also had to take into account any ethical liabilities users would undertake by using
our product. For example, with the Future Register, users are handling credit card numbers of
customers. Therefore, we had to protect this information so that it would be safe if it ended up in
the wrong hands. The last main non technical aspect we had to consider was safety and
reliability. We made sure that the Future Register used components that had a low failure rate in
order to provide a reliable product. In the end, we learned that you can’t just sit down and start
building the project. There is an extensive research and design process that needs to happen to
ensure that the product will meet a number of requirements.
-31-
ECE 477 Final Report
Spring 2012
References
[1]
ECE477 Homepage. “Military Handbook – Reliability Prediction of Electronic
Equipment”, [Online], Available:
https://engineering.purdue.edu/ece477/Homework/CommonRefs/Mil-Hdbk-217F.pdf
[2]
Microchip Technology. “dsPIC30F Family Reference Manual”, [Online], Available:
ww1.microchip.com/downloads/en/DeviceDoc/70046D.pdf . [Accessed April 5, 2012]
[3]
BallSoHard. “PN532—LONG DATA SHEET”, [Online], Available:
https://engineering.purdue.edu/477grp14/Specs/NFC/PN532-%20LONG%20DATA%20SHEET.pdf. [Accessed April 5, 2012]
[4] Intel. (n.d). Intel.com [Online] Available:
http://edc.intel.com/Platforms/Atom-N450-D410-D510/
[5] Microchip. (n.d). microchip.com [Online] Available:
http://ww1.microchip.com/downloads/en/DeviceDoc/70116e.pdf
[6] Texas Instruments. (n.d). ti.com [Online] Available:
http://www.ti.com/lit/ds/symlink/max3232.pdf
[7] Newegg. (n.d). Newegg.com [Online]. Available:
http://www.newegg.com/Product/Product.aspx?Item=N82E16824016156
[8] Amazon. (n.d). Amazon.com: 15 Inches LCD Touch Screen Monitor (4:3): Electronics
[Online]. Available: http://www.amazon.com/Inches-LCD-Touch-ScreenMonitor/dp/B004C4UFOG/ref=sr_1_3?s=electronics&ie=UTF8&qid=1328144247&sr=1-3
[9] Microchip. (n.d). PIC18F65K80 [Online]. Available:
http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en550196
[10] Microchip. (n.d). dsPIC30F5011 [Online]. Available:
http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en010346
[11] Digi-Key. (n.d). Digi-Key – 568-8600-ND [Online]. Available:
http://search.digikey.com/scripts/DkSearch/dksus.dll?wt.z_cid=ref_hearst_0211_buynow&
site=us&mpart=PN5321A3HN%2fC106%3b55
[12] Digi-Key. (n.d). Digi-Key – 73-1249-ND [Online]. Available:
http://search.digikey.com/us/en/products/C-51847NFJ-SLW-ADN/73-1249-ND/769330
[13] Future Register, (n.d) “Project proposal” [online] Available:
https://engineering.purdue.edu/477grp14/Documents/Project%20Proposal.doc
-32-
ECE 477 Final Report
Spring 2012
[14] "NFC Forum Unveils Technology Architecture And Announces Initial Specifications And
Mandatory Tag Format Support". 05 Jun 2006. Retrieved 14 June 2011. [online]
http://www.nfc-forum.org/
news/pr/view?item_key=0b210bbd23e9c1a07cb3d975e6317d1d650ed51f
[15] Qualcomm, (n.d) “US Application Patent application US20090271276”, Richard,John,
October 29,2009
[16] Mobile Candy Dish, (n.d) “US Application Patent application US20090144161” Fisher,
Michell, June 4, 2009.
[17] First Data Cooperation, (n.d) “US Application Patent application US20100023449”
Skowronek, Dan; VanDeburg, Theodore; Owen, Sarah July 25, 2008.
[18] Motorola, (n.d) “US Application Patent application US20100274524” Noor, Gad;
Gabay, Jacob; Slomov, Dmitry; White, Jay Paul October 28, 2010.
[19] National Institute of Standards and Technology, “AES encryption” retrieved March 29,
2012. [Online] http://csrc.nist.gov/archive/aes/index2.html
[20] LCD making worse for environment than coal? (n, d). C|NET. [Online] Available:
http://news.cnet.com/8301-11128_3-9983744-54.html
[21] Dangerous Chemical in LCD TVs Being Replaced (n, d). Gizmodo. [Online] Available:
http://gizmodo.com/5027558/dangerous-chemical-in-lcd-tvs-being-replaced
[22] Certified Green Partners (n, d). [Online] Available:
http://certifiedgreenpartners.org/new_site/
[23] Environmental Initiatives (n, d). Planar. [Online] Available:
http://www.planarsystems.com/green/
[24] E-Cycle St. Louis (n, d). [Online] Available: http://www.ecyclestlouis.org/
[25] Call for an Ethical Code Regarding Big Data (n, b). Dataversity. [Online] Available:
http://www.dataversity.net/call-for-an-ethical-code-regarding-big-data/3597/
[26] Toshiba (n.d). Toshibateusa.com [Online] Available:
http://www.toshibatecusa.com/products/pointofsalesystems/ST-A20_Main.htm
[27] Touch Suite (n.d). Inverntstar [Online] Available: http://www.touchsuite.com/
[28] M. Glenewinkel, “System Design and Layout Techniques for Noise Reduction in MCUBased Systems” [online], Available:
https://engineering.purdue.edu/ece477/Homework/CommonRefs/AN1259.pdf
-33-
ECE 477 Final Report
Spring 2012
[29] Texas Instruments, High Speed Clock Sources and Their Effect on Electromagnetic
Compatibility (n.d). ti.com [online] Available:
http://www.ti.com/lit/an/snoa346/snoa346.pdf#page=2
[30] Texas Instruments. (n.d). ti.com [Online] Available:
http://www.ti.com/lit/ds/symlink/tps7201.pdf
[31] Microchip. (n.d). microchip.com [Online] Available:
http://ww1.microchip.com/downloads/en/DeviceDoc/70116e.pdf
[32] BallSoHard. “LCD.C”, [Online], Available:
https://engineering.purdue.edu/477grp14/Documents/LCD.c
[33] MSDN, “System.Speech.Recognition Namespace ()”, [Online], Available
http://msdn.microsoft.com/en-us/library/system.speech.recognition.aspx. [Accessed March
21, 2012]
[34] MSDN, “System.Security.Cryptography Namespace”, [Online], Availble:
http://msdn.microsoft.com/enus/library/system.security.cryptography%28v=vs.71%29.aspx. [Accessed March 21, 2012]
[35] MSDN. “SerialPort Class (System.IO.Ports)”, [Online], Available:
http://msdn.microsoft.com/en-us/library/system.io.ports.serialport.aspx. [Accessed March
21, 2012]
-34-
ECE 477 Final Report
Appendix A:
Spring 2012
Individual Contributions
A.1 Contributions of Brian Crone:
My main responsibility on this project was the software. However, I wasn’t able to do
much with this the first half until we had our PCB complete and the rest of the design. The first
few weeks we had to finalize our design and research what parts we were going to use. I would
say we all contributed equally to this portion of the project. My subject for the technical report
dealt with theory of operation and schematic design. This is where most of my contributions
came from for the first part of the project. I put in a significant amount of time designing the
preliminary schematic. Researching the theory of operation also resulted in discovering more
parts that we would eventually need. I also helped out significantly with the PCB design. More
specifically, I arranged the parts and completed a significant amount of the traces. Aside from
other minor contributions to wherever help was needed, these were most of my contributions for
the first part of the semester, which dealt mostly with the project and hardware design.
My contributions to Future Register were more significant the second part of the semester
because we were able to start writing the software. My responsibility was planning the C#
application that would run on the atom board. I did a substantial amount of research on this
before actually starting to code anything. I concluded that we could implement everything we
needed to by using the .NET 4.0 framework by Microsoft. I split the application in to different
modules, and ended up delegating the serial communication module to Yonatan, and I delegated
the speech recognition module to Matt. This left me to take the reins on the GUI, the AES
module, and the object-oriented design. However, Yonatan did help out with the GUI. It was his
decision to use WPF instead of standard Windows Forms. Yonatan had the basic design for the
order screen and login screen. I was responsible for the design of the new item and edit item
screens. I also implemented my Restaurant API on all screens, which allowed each screen to
dynamically populate with data. I also designed the .fut file format that the application uses. This
file format allows the inventory and information of each restaurant to be saved to the local disk.
Therefore, all changes are reflected and saved every time the application is opened. The
functions I wrote for this will save all the information from the global restaurant into a .fut file.
The read function will read a .fut file and use all of the information contained in the file to set up
the global restaurant object.
My subject for the professional report was reliability and safety analysis. I spent most of
one week completing that report. This consisted of completing the FMECA charts for each
module of the product and also calculating MTTFs for several different components. That week,
I also delivered the TCSP for reliability and safety. After I completed all of the software and the
report, I pretty much gave help to whoever needed it. I helped Sam debug whenever I could and I
helped Matt to design and even build some of the enclosure.
After the product was completed, I took the lead on handling and organizing all of the
final documentation for the project. I compiled all of the sections for the final report, in addition
A-1
ECE 477 Final Report
Spring 2012
to writing any new sections that required original content. I also wrote the ECE Senior Design
report. I also compiled and edited the film and audio footage to create our PSSC demo video.
A.2 Contributions of Matt Finn:
My personal contribution mostly centers on software and the packaging enclosure.
My first role was to come up with a packaging enclosure for the customer interface portion of
Future Register. I had initially planned on using a “Project Enclosure Box” from Radio Shack.
The 7”x5”x3” version of the box had plenty of room to store our PCB, NFC chip, and LCD
screen.
Throughout the semester, our packing had to be adjusted to incorporate changes in our
design. First, we changed from a pressure pad sensor to an IR sensor to detect the presence of a
user. This involved making sure there was enough room to include an IR sensor in our enclosure.
Switching to an IR sensor greatly simplified the act of detecting a customer. Instead of having to
create a pressure pad with a sensor on it, we could now just point the IR sensor out and use an
A/D input.
With about a week left before the project was due, we decided to change our enclosure to
be clear. We wanted to make this change so that we could more easily present the circuitry of our
design. The Project Enclosure Box was a standard, black box and didn’t make the project stick
out at all. You couldn’t see inside it without opening it up. A clear enclosure would allow us to
easily show every component of our circuit and looks a lot cooler than a black box.
I started off by sketching a clear design. I added an incline to the presentation side of the
enclosure. This gave the enclosure some “dimension,” not just another square box. I also made
the enclosure bigger. We had to fly-wire several additional components onto our PCB
(potentiometer, level translator), and I wanted to make sure that we could fit these additional
components without the risk of them touching each other.
After sketching a design, I began cutting the acrylic and putting all the pieces together. A
combination of scoring and saw cutting finally created all of the acrylic pieces we needed. Given
all of the fly-wire adjustments we had made to our PCB design, I waited until the last few days to
finally cut out holes for the LCD, IR sensor, and COM/power cables.
The clear enclosure came together very well and we can easily show our circuit design
along with all of the fly-wire adjustments we had to do throughout the semester.
On the software side of Future Register, I was tasked with enabling voice recognition when
we were taking an order. Given a signal from the IR sensor (meaning a user is detected), the
voice recognition had to automatically turn of and interpret what the customer was saying “on
the fly.” Microsoft’s .NET framework provided all of the tools needed to accomplish this, and
the main challenge became figuring out how to utilize the voice recognition library. First I
created a sample program that would output all recognized words and show its “confidence” in
each word. Then I modified the voice recognition grammar library to only include a list of
keywords that we provide. This greatly cut down on erroneous guesses and improved our voice
recognition accuracy. Finally, I worked with Yonatan to integrate the voice recognition into
A-2
ECE 477 Final Report
Spring 2012
Future Register. We used the keywords for each item as the objects in our Grammar class. When
Future Register runs in debug mode, there is a side window that shows voice recognition
statistics including: recognized words, confidence in each word, and microphone status.
A.3 Contributions of Samuel Oshin:
My personal contribution to this team project ranges from hardware through software. My
first role was to take control of the microprocessor interfaces by developing a working and
proper schematic as researched from the varying datasheets. But I did more than my assigned
role. I mainly developed, researched all the microprocessor interfaces, did most hardware
soldering jobs, NFC app, co-developed the protocol that interfaces microprocessor with atom,
did all the prototyping, and helped extensively in the final schematic.
I took control of the microprocessor interfaces by researching the parts that needed to
be interfaced, and come up with a strategy to properly attach them to the microprocessor. For the
IR sensor, I had to specify which ATD to use and the specific pin assignments. I also had to
derive circuits for almost all the parts that had to get on the PCB. The most important part of the
schematic I worked on was the NFC circuit. This was derived from an already working model
that is being produced and sold by adafruit. With the help of their already created antenna circuit,
I was able to create an antenna circuit that would fit our needs. After creation of the printed
schematic, I assisted in routing parts on the initial and final PCB designs. My contribution was in
rerouting the capacitors after moving them closer to their respective pins to reduce noise on the
PCB.
After the PCB was completed, the next task I took on was to prototype all parts that
will be needed for the project. I started off by soldering a dsPIC30F unto a breakout board. With
this micro controller I started prototyping the IR sensor, first wiring as done in the schematic,
and then followed up with writing the code to initialize the ATD, and completely convert the IR
signal. Next item was the LCD. After following our schematic, an error was found. A
potentiometer was needed to correctly adjust the contrast on the screen. This also needed a fix on
the PCB, which I implemented. Next part was the COM + UART functionality. Prototyped it by
using the suggested UART initialization, but getting the correct speed was quite difficult. I
manually calculated the speed, by measuring the frequency of a blinking LED on an
oscilloscope. After receiving the PCB, I soldered all the parts onto the PCB and did burn in tests,
as well as test all prototyped parts on the PCB. After verifying all working parts, after a couple of
failures, such as the micro controller and the LDO, I moved on to prototype the NFC board.
While prototyping the NFC, figured a major design flaw, the power requirements for
the NFC chip not what we expected. There are 2 different power requirements, a 5V and a 3V.
Due to the PCB already being printed, another solution had to be created. We bought the
breakout board that the initial design was made from, to focus more on the interfacing rather than
hardware design issues. After I received the NFC breakout board, a lot of work was put into
researching the protocols for NFC transmission with an Android device. While learning the
protocols for NFC, I also took control of the Android app development. Added to the application
A-3
ECE 477 Final Report
Spring 2012
foundation laid out by Yonatan Feleke, by implementing the NFC functionality, and adding more
practical options to the NFC app. Poured several days into getting functionality from the PN532
chip and allowing the Android to recognize the chip. The main issue throughout the process was
the automatic and manual protocols that needed to be implemented. The PN532 is able to
automatically handle certain commands from other devices while the Android can’t
automatically respond once an NFC field has been detected. Once the correct command/packet
was derived, I was able to establish communication. After communication was established we
moved on to creating a main function that would run on the microcontroller to handle all the
functions of the product. The next contribution was in figuring out how to interface the now
working PN532 breakout board with our PCB through fly-wire techniques. First tried to solder
directly to the pins of the microcontroller, but through the insight of my teammates, we already
fleshed out some GPIO pins to be used as backup in case we run into situations such as these. By
using a general SPI driver which can simulate SPI communication through GPIO, there was no
need to directly solder unto the PCB.
The next major contribution is the communication protocol with the atom board. I
worked with Yonatan Feleke to implement a communication protocol that will allow both
software logics to understand each other. First we had to derive signals that will allow the atom
to know when it can continue with its process. We also then created a scheme to craft a receipt
that will be sent to the NFC phone. This was done to minimize the amount of chatter on the
COM port. A simple receipt showing the total and date was created which would fit within a
simple NFC-A packet. After the COM protocol was ironed out, I started to debug the
functionality as a whole, making sure the process could be repeated and iron out the sluggishness
of the process. I then helped record the video that was used to display our PSSCs, which I was
with Matt Finn in presenting to the afternoon class of ECE362 students.
A.4 Contributions of Yonatan Feleke:
As the group leader Yonatan Feleke rotated around the various components of the project.
The main contributions were in areas of the windows form application GUI, MicrocontrollerAtom board Serial Communication, Android Application UI, Patent Analysis and PCB design;
minor contributions in packaging work and microcontroller transaction processing protocol.
Documentation wise I contributed by researching and writing patent analysis report and the
PCB design consideration report. In the beginning my contributions revolved around the printed
circuit board
In the earlier stages of the project, the future register user interface was being designed in
windows forms. Brian Crone was tasked with functionality of the project and my contribution
was to design the 5 windows. I started the task by researching beautiful applications and learned
about windows presentation forms (WPF), an XAML markup design that allows separation of c#
code and design. With the discover I set on the task of creating the windows. The first screen is a
banner screen that would allow login or creation of a new restaurant. The next screen designed is
A-4
ECE 477 Final Report
Spring 2012
the corresponding Order Screen. Creating the order screen I added a menu toolbar, order item list
box, voice recognition list box and lastly an order summary section. Upon completion I designed
and implemented an order item user control that contains an icon, name and price which is added
into the corresponding list box. The next 2 widows designed are the new item and order item,
since these windows are more backend focused, I provided Brian Crone a general template to
modify and implement. The last window, payment processing window, was initially designed to
be a progress bar the updates with the transaction. However, I further updated this to show a
debug terminal when run in debug mode. The window featured all Serial communication
component implementation discussed below.
After the completion of most of the future register UI I moved on to designing the android
application to process the transaction over NFC. Utilizing eclipse and my android galaxy nexus I
was able to design a UI with a transmit button, that prepares an already written text in hex for
transmission over NFC. The actual NFC component libraries and functions were set up but the
actual coding of the custom protocol was done by Samuel Oshin.
The voice recognition integration and serial communication were the next two components.
After Matt Finn completed the separate voice recognition component, I interfaced that with the
current order screen and added controls to show the status of the Voice recognition. The next
step was to implement a communication protocol. To implement the serial communication I
wrote a communication manager class that features methods for instantiating, opening, sending,
receiving, and displaying messages. Having completed the functions I moved on to implement a
debug mode in the payment processing window to display messages and also simulate
sending/receiving messages since hardware component was not completed at the time. Once I
received a working future register terminal I implemented a communication protocol that utilizes
a different thread to listen for messages and updates the debug window.
Once above contributions were completed, I moved on to implementing a serial voice
recognition controller based on the customer present (FF) or gone flags (00) sent over com. With
that completed, I then worked on ironing out the bugs such as increasing delay time between
messages to improve performance of order screen. Try and catch statements so that the software
would run without voice recognition on older windows versions.
Once the project was finally completed, I contributed in recording the video that was to be
edited for the presentation. Also took part in the bonus presentation for the ECE 270 students. By
the end of the semester, summing up all my contributions I have accumulated over 280 hours
working on the project.
A-5
ECE 477 Final Report
Appendix B:
Spring 2012
Packaging
Figure B – 1: Original Packaging Design, Front
Figure B-2: Original Packaging Design, Back
B-1
ECE 477 Final Report
Spring 2012
Figure B-3: Final Package, Back
Figure B-3: Final Package, Front
B-2
ECE 477 Final Report
Appendix C:
Spring 2012
Schematic
Figure C-1: Overview of Schematic
C-1
ECE 477 Final Report
Spring 2012
Figure C-2: IR/LCD Schematic
Figure C-3: Power Regulation Schematic
C-2
ECE 477 Final Report
Spring 2012
Figure C-4: Schematic for COM communication
C-3
ECE 477 Final Report
Spring 2012
Figure C-5: NFC Schematic
C-4
ECE 477 Final Report
Appendix D:
Spring 2012
PCB Layout Top and Bottom Copper
Figure D-1: Top Layer PCB
Figure D-2: Bottom Layer PCB
D-1
ECE 477 Final Report
Spring 2012
Figure D-3: Top and Bottom Layer PCB
D-2
ECE 477 Final Report
Appendix E:
Spring 2012
Parts List Spreadsheet
Vendor
Manufacturer
Microchip
Newegg
dsPIC30F5011
ACM-51B
16-bit microcontroller
Microphone
PN5321A3HN/C106
C-51847NFJ-SLW-ADN
GP2Y0A02YK0F
PX2230MW
MAX3232CSE
NFC transceiver
LCD screen
IR Sensor
Touchscreen
RS-232 Translator
1734348-1
Texas
Instruments
Adafruit
Microchip
Cyber
Acoustics
NXP
Optrex
Sharp
Planar
Maxim
Integrated
Products
TE
Connectivity
STMicroelectro
nics
Texas
Instruments
Adafruit
Nonpurchasing:
OutletPC
Newegg
Trendnet
Intel
Digi-Key
Digi-Key
Digi-Key
Tigerdirect
Digi-Key
Digi-Key
Digi-Key
Part No.
Description
Unit Cost
Qty
7.55
2.99
1
1
Total
Cost
7.55
2.99
10.28
17.72
14.95
269.99
2.09
1
1
1
1
1
10.28
17.72
14.95
269.99
2.09
D-SUB 9 Connector
0.85
1
0.85
LD1117V50
5V Voltage Regulator
0.60
1
0.60
SN74LVC8T245
Bus Transceiver
0.80
1
0.80
364
PN532 controller breakout board
50.00
1
50.00
TEW-424UB
http://www.newegg.com/Product/Pro
duct.aspx?Item=N82E16813121442
USB WiFi transceiver
Atom board
19.98
74.99
1
1
19.98
74.99
TOTAL
E-1
$472.79
ECE 477 Final Report
Appendix F:
Spring 2012
FMECA Worksheet
Failure
Failure Mode
No.
A1
Output = 0V
Possible Causes
POWER
Failure Effects
Failure of regulator
or associated passive
components, external
short
Components have
no power, system
unable to operate
Method of
Detection
Observation, no
response from
GUI on atom,
voltage probe
Criticality
Remarks
Medium
No injury. System
inoperable.
A2
Output > 5V
Regulator Failure
Component
destruction,
Overheating
Observation,
package
overheating
High
Only high criticality
failure. Overheating
could cause injury to
user.
A3
Output out of
tolerance
Regulator, Passive
Component Failure
Component
operating voltage
incorrect,
unpredictable
effects
Observation,
voltage probes
Medium
Components not
operating at correct
levels will result in an
inoperable system
F-1
ECE 477 Final Report
Failure
Failure Mode
No.
B1
Output = 0V
B2
Output not
translated
Failure
Failure Mode
No.
C1
Output
continuously 0
C2
Output
continuously 1
Spring 2012
Possible Causes
RS232
Failure Effects
Failure of translator.
Failure of associated
passive components.
External short
Atom and micro
unable to
communicate
MAX3232 Failure
Atom and micro
unable to
communicate.
High voltage to
micro, possible
destruction
Possible Causes
Software, external
short or short of
passive components
Software, passive
components
Method of
Detection
Observation.
GUI will
always be
waiting on info
from micro
Observation,
Voltage probes
MICROCONTROLLER
Failure Effects
Method of
Detection
Blocks will not
Observation,
receive
software
instructions from debugging,
micro
voltage probes
Improper
communication
between blocks,
random behavior
F-2
Observation,
check LEDs
and messages
on GUI
Criticality
Remarks
Medium
No injury. Inoperable
system.
Medium
No injury. System
inoperable. Micro
possibly irreparable.
Criticality
Remarks
Medium
No injury. System
inoperable.
Medium
No injury. System
inoperable
ECE 477 Final Report
Failure
Failure Mode
No.
D1
Output = 0V
D2
Incorrect
operating
frequency
Failure
Failure Mode
No.
E1
LCD Failure
E2
IR failure
Spring 2012
Possible Causes
Oscillator Failure,
Passive components,
external short
Oscillator failure
Possible Causes
NFC
Failure Effects
NFC data will not
be sent/received.
NFC RAM will
always show
empty
Improper data
communication,
potential for
incorrect/lost data
LCD/IR
Failure Effects
Software, external
short, LCD
component failure
No prompts to
user
Voltage spike,
external short,
software
No customer
detection.
Requires verbal
communication
between cashier
and customer
F-3
Method of
Detection
Observation,
probes
Observation,
verify payment
information
with receipt
Method of
Detection
Observation,
LCD not
showing
messages
Observation,
LED will not
light up to show
presence
Criticality
Remarks
Low
System still operable,
though payment not
possible
Low
System still operable,
payment not possible
Criticality
Remarks
Low
Inconvenience to user
Low
Inconvenience to users