ECE 477 Final Report  Spring 2008
Team 9  myRoom
Andrew Hampton, Zach Beechler, Laurie Duncan, Gesine Hinterwalder
Team Members:
#1: ____________________________
Signature: ____________________ Date: _________
#2: ____________________________
Signature: ____________________ Date: _________
#3: ____________________________
Signature: ____________________ Date: _________
#4: ____________________________
Signature: ____________________ Date: _________
CRITERION
Technical content
Design documentation
Technical writing style
Contributions
Editing
Comments:
0
0
0
0
0
1
1
1
1
1
2
2
2
2
2
3
3
3
3
3
SCORE
4 5 6 7
4 5 6 7
4 5 6 7
4 5 6 7
4 5 6 7
8
8
8
8
8
9
9
9
9
9
10
10
10
10
10
MPY
3
3
2
1
1
TOTAL
PTS
ECE 477 Final Report
Spring 2008
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
8
5.0 Reliability and Safety Analysis
13
6.0 Ethical and Environmental Impact Analysis
16
7.0 Packaging Design Considerations
21
8.0 Schematic Design Considerations
24
9.0 PCB Layout Design Considerations
27
10.0 Software Design Considerations
30
11.0 Version 2 Changes
34
12.0 Summary and Conclusions
34
13.0 References
35
Appendix A: Individual Contributions
A-1
Appendix B: Packaging
B-1
Appendix C: Schematic
C-1
Appendix D: PCB Layout Top and Bottom Copper
D-1
Appendix E: Parts List Spreadsheet
E-1
Appendix F: Software Listing
F-1
Appendix G: FMECA Worksheet
G-1
-ii-
ECE 477 Final Report
Spring 2008
Abstract
This report is an overview of the myRoom system, how it was designed, and how it
operates. myRoom is a remote home appliance control system, which turns on appliances and
sets them to a user’s preferred settings when a user enters the room. It is the culmination of one
semester’s work by four seniors at Purdue University. Following is a collection of professional
and design considerations, final project status, and an assessment of additions and changes that
would be made if given more time.
1.0 Project Overview and Block Diagram
Figure 1.1 – The myRoom System
myRoom is a complete, customizable room control system. It is meant to be mounted
near the entrance to a room. Each family member will have an ID card with built-in RFID
-1-
ECE 477 Final Report
Spring 2008
technology, which is scanned upon entering the room. When myRoom detects that a new person
has entered, their personal preferences - which have been downloaded from the internet via an
Ethernet connection – are accessed by the microcontroller. Appliances that are controlled by
myRoom (which include light, TV, DVD player, CD player and fan) will be changed
instantaneously by receiving infrared signals sent by the myRoom system.
myRoom was created to be an innovative system that would entice customers by being
both fun and functional, as well as being a good way to conserve energy. The purpose of
myRoom is to make the use of regularly used home appliances easier and less tedious. When
users don’t have to shuffle through numerous remote controls to turn on and adjust their
electronics every time they enter a room, they are able to get more use and enjoyment out of
them. myRoom’s ability to turn off all appliances when the user leaves the room adds the benefit
of energy conservation for those who might forget to turn off their appliances otherwise.
Remote Control
IR
IR Receiver
1
RFIDReader
1
Microcontroller
Ethernet
1
Television
IR
Infrared Transmitter
IR
IR
DVD-Player
Figure 1.2 – Block Diagram of myRoom
-2-
CD-Player
ECE 477 Final Report
Spring 2008
The block diagram shows each of the major components of the myRoom system. The
microcontroller is a Freescale MC9S12NE64. It receives a unique code from the ID Innovations
ID-12 RFID reader for each RFID card that is scanned. It also receives IR codes via the Sharp
Microelectronics GP1UD26XK IR receiver. The microcontroller then sends the appropriate IR
codes out through the Vishay TSAL7600 IR transmitter. The microcontroller also has an onchip Ethernet component, where it hosts the myRoom website for user preference control.
2.0 Team Success Criteria and Fulfillment
1. An ability to identify a registered user via an RFID tag.
Complete. Each RFID card is embedded with a unique ID tag, which the myRoom
system detects and stores temporarily in memory when a card is scanned.
2. An ability to add/delete users and modify their associated preferences via an
embedded web page.
Incomplete. Although a working web page was created and tested on a development
board, integrating this code with the rest of the project code proved to be a significant
challenge. There was not enough time to resolve this issue before submitting the Final
Report.
3. An ability to look up current user’s preferences and act on them.
Complete. After an RFID card is scanned and its ID tag is stored, this data is sent to a
function which looks up the settings for that particular user. Since the myRoom system
currently only works with a TV, the function checks to see if the TV should be on or off.
If the user prefers the TV to be off, no action is taken. If the user prefers the TV to be on,
the IR code for “Power” is transmitted through myRoom’s IR transmitters, followed by
the IR codes for each digit of the desired channel.
4. An ability to learn infrared commands using an infrared receiver.
Complete. To start “Learn” mode the user must press pushbutton 1. The red LED will
light up, indicating to the user that the system is ready to receive the first signal. The user
-3-
ECE 477 Final Report
Spring 2008
must point the TV remote control at the IR receiver, then press and hold the “Power”
button until the green LED lights up and the red LED turns off. This indicates that the
signal has been received and stored in memory. After one second, the green LED will
turn off and the red LED will light up again, indicating to the user that the system is
ready to receive the next signal. The user must repeat this process for the digits 0-9 on
their remote control. When all codes have been received, both LEDs will turn off.
5. An ability to control operation of entertainment devices (TV, stereo, etc.) using IR
commands.
Complete. When a user who has set their preferences to turn the TV on scans their RFID
card, the appropriate IR signals for “Power” and channel are sent via the IR transmitters.
When the myRoom system was tested on a Sony television it was able to turn it on and
turn it to the correct channel. Due to variations in the frequencies of IR signals for
different brands of electronics, the myRoom system is only guaranteed to work on Sony
devices, which run at 40 kHz.
3.0 Constraint Analysis and Component Selection
3.1
Design Constraint Analysis
The major design constraints which guided component selections were IR emitters
capable of transmitting at frequencies used by most standard IR receivers, an IR receiver that
was capable of receiving the same frequencies, an RFID reader that was capable of reading a tag
at a distance of at most six inches, and a microcontroller with embedded Ethernet and a PWM
module capable of creating signals with a frequency of around 36 kHz. Minor constraints
included cost, packaging, and power requirements.
3.2
Computation Requirements
The microcontroller needed to accept data from the RFID reader in the form of a RFID
tag number, look up that number in a database, and change the system variables (TV channel,
CD player on, DVD player off, etc.) if necessary. The microcontroller then needed to use its SCI
or PWM to output to the IR emitting diodes, and an SCI input pin for the IR receiver. The
microcontroller also had to be able to accept data from its Ethernet adapter, determine where the
-4-
ECE 477 Final Report
Spring 2008
data needed to be stored, and store the new data into the appropriate memory addresses. Speed
was not a major requirement, as long as the microcontroller could perform all execution tasks
(read RFID information, process information, output necessary waveforms) in a timely manner
(1 second or less).
3.3
Interface Requirements
All interface requirements were device-specific, as the control box needed to be made of
compatible components. The microcontroller needed to be able to accept data from an RFID
reader, but which protocol was used was not important. The RFID reader on the other hand
needed to be able to output in a form the microcontroller could accept. The main constraints
used for choosing device components did not involve current, voltage swing, or any other I/O
requirements.
3.4
On-Chip Peripheral Requirements
The microcontroller needed to have an SCI or similar module capable of outputting
signals at frequencies of about 40 kHz, because the entire design revolved around being able to
transmit IR signals. An on-chip Ethernet adapter was highly preferable due to ease of use, but
was not required. I2C, SCI, or SPI would be needed depending of the RFID reader chosen.
3.5
Off-Chip Peripheral Requirements
The control box needed to have an RFID reader and IR transmitters. The RFID reader
needed to be capable of communicating with a microcontroller through the controller’s SPI or
SCI channels. It also needed to have an effective range of at least one inch, so that signals could
travel through the packaging. The RFID tags used by the reader needed to operate at a frequency
the RFID reader could receive.
The IR transmitters needed to have a wide emission angle to reduce the number of
transmitters required. It also needed the capability of emitting at an intensity high enough for
standard IR receivers to recognize over a distance of up to 25 feet. If necessary, a chip
containing IR transmission codes would be purchased and interfaced with the microcontroller
depending on storage requirements as well as vendors’ willingness to share their IR codes. The
-5-
ECE 477 Final Report
Spring 2008
need for such a device was situational. If an on-chip Ethernet adapter was not available, an offchip version would have been required.
3.6
Power Constraints
Because the control box was to be plugged directly into a wall outlet, there were no real
power constraints. For ease of use, components requiring the same supply voltage would be
ideal, but not necessary. To prevent possible current spikes from damaging the microcontroller
and other devices, the power supply needed to be isolated from the rest of the circuit and
regulated. The initial design called for six IR emitters, each requiring 100mA. The power
supply needed to be able to handle at least 600mA for the emitters, plus all other components. A
rough estimate of total current draw, based on final parts chosen, lay between 800mA and 1A.
The power supply therefore needed to be able to handle at least 1A.
3.7
Packaging Constraints
The final design was expected only to be as large as the largest component used. The
control box only needed to be large enough for the RFID reader to work properly. A reasonable
size would be anything smaller than a one foot cube. Since the control box was to be mounted
on a wall, it needed to be light enough to not fall off easily and would preferably be made of a
light plastic to make drilling holes for LEDs and mounting holes easier.
3.8
Cost Constraints
No similar product currently exists on the market, so a direct cost comparison was not
possible. However, component costs needed to be kept to a minimum without sacrificing
performance due to budgetary concerns. Overall, the entire cost of the design needed to fit into
the budget of the designers.
3.9
Component Selection Rationale
The control box uses a Freescale MC9S12NE64VTUE as its core. The
MC9S12NE64VTUE is the smallest microcontroller (in terms of capabilities) with embedded
Ethernet that was found, and while it doesn’t have a PWM, it does have a TIM that is capable of
outputting at the required frequencies. The other consideration was the Rabbit RCM4010. The
-6-
ECE 477 Final Report
Spring 2008
Rabbit is smaller, has a dedicated PWM, and has more memory (both flash and SRAM).
However, the MSRP is $69 per unit. The Freescale on the other hand has a faster Ethernet
adapter, is substantially cheaper ($9.84 per unit), and is familiar to the designers. In the end, it
was determined that the cost of the Rabbit was too high and the other features were overkill for
our application’s requirements, in addition to poor documentation (the data sheet can only be
acquired by purchasing a development kit for $239, according to Rabbit Semiconductor’s
website[1]).
The RFID reader chosen is the RFID Reader ID-12 by ID Innovations, because it meets
all constraints better than the competing TRRO2OEM from Intersoft. The RFID Reader ID-12
has a lower supply voltage, longer range, ability to transmit in ASCII, lower cost, and contains
all necessary components (the TRRO2OEM requires an additional antennae and power supply).
The only drawback to the RFID Reader ID-12 is that it has a pin spacing of 2mm and is larger
that the TRRO2OEM. However, ID Innovations sells a pin conversion board that converts the
2mm spacing to .1” spacing and size is not a major design constraint, making these drawbacks
less of a concern. RFID tags made by the manufacturer of the RFID reader were chosen because
they are specifically designed for said reader.
Vishay Semiconductor offered a wider array of products than any of its competitors, and
Vishay’s products are readily available. The IR emitting diode chosen is the TSAL7600 due to
its large beam angle (30 degrees) as well as high intensity (25 mW/sr). Other IR diodes may be
considered, such as the TSHG8400 with an intensity of 70 mW/sr and beam angle of 22 degrees,
but at the moment the TSAL7600 appears to meet all constraints. Because the control box will
require 180 degrees of transmitting capability, a minimum of six diodes are required.
Finally, a GP1UD26XK from Sharp Microelectronics was chosen to be the IR receiver.
At first, the Vishay TSOP98200 was chosen for its ability to work with IR code receiving
applications. However, it was impossible to find this item in stock anywhere, so the Sharp
model was chosen instead. The Sharp model was selected for since its power supply voltage was
3.3V, which was the same as most of the rest of the circuit.
3.10 Summary
The major design components chosen, the Freescale MC9S12NE64VTUE
microcontroller, the RFID Reader ID-12, the GP1UD26XK IR receiver, and the TSAL7600 IR
-7-
ECE 477 Final Report
Spring 2008
transmitter, fit or surpassed the already established design constraints; all at a reasonable cost.
The quantities chosen for purchase included extra parts in case a mishap was to occur.
4.0 Patent Liability Analysis
4.1
Introduction
When seeking patents for systems with the same primary functionality as the myRoom
system, a few requirements for specific sub-functions were considered. Similar patents would be
expected to be an advanced remote control system which controlled a plurality of devices. The
systems would be expected to learn command codes from IR remote controls made for the
appliances, and then use those codes to transmit commands to the appliances. The ability to
control many appliances with a single user input would be considered significant.
4.2
Results of Patent and Product Search
4.2.1 US Patent #7,136,709: Home appliance control system and methods in a networked
environment
Filed November 1, 2004
This system uses a remote control unit (RCU) to control household appliances through a
home network. [2] In the exemplary scenario of the use of this patent, a home would consist of a
number of appliances that are network enabled (such as those that are UPnP and/or HAVi
compliant) as well as some legacy appliances which are not. [2] Legacy appliances would be
connected to the network by a network enablement device which communicates with the
appliance via IR signals. [2] Once connected to the network, appliances could easily be accessed
by some RCU that also had access to the network. Using the home network makes
standardization easy, so a number of different devices could be used as the RCU, such as a
laptop or PDA. Any type of input that the RCU is capable of, including but not limited to button
press, voice, text, or gestures could be used to communicate with household appliances. [2]
These inputs would then be converted into generic action descriptors before being sent through
the network to the appropriate appliance. [2]
Most of the claims in this patent revolve around the use of a home network as an
intermediary between an RCU and the appliances it controls. However, claim 1 states: “In a
-8-
ECE 477 Final Report
Spring 2008
controlling device, a method for normalizing command input, comprising: receiving from
another controlling device a command; using the command received from the another controlling
device to teach a command input decoding engine accessible to the controlling device to
recognize the command as being a match for a generic action descriptor within a database of
predefined generic action descriptors; subsequently receiving the command; and using the
command input decoding engine accessible to the controlling device to match the command.” [2]
This is in some ways similar to the myRoom learning mode for learning remote control IR codes.
4.2.2 US Patent #5,646,608: Apparatus and method for an electronic device control
system
Filed December 22, 1994
This system is used to control a plurality of home appliances with a single remote control.
Each appliance is required to have an identification code stored in the system’s memory, so that
the code can be transmitted by IR throughout the room that it is in. [3] The RCU for this system
receives these identification codes, and is able to discern its location in this way. [3] It displays
on its main LCD screen which room the user is in as well as what appliances are within
controlling range. [3] The user can then send IR signals from the RCU to each of the available
appliances, setting each appliance in the room to their own preferences.
The claims in this patent focus primarily on the system’s ability to determine its location
based on the identification signals sent by each appliance in the room. The claim most similar to
features of the myRoom system is claim 1. To paraphrase, it states that it is a remote control
system for controlling electronic devices in a room. The electronic devices controlled by the
remote control unit must have the ability to send out a unique identification signal to the RCU,
which display that device’s menu items on the RCU’s LCD screen. [3] Aside from the device
identification mechanisms, it is a general description of essentially what the myRoom system
does.
4.2.3 US Patent #6,792,323: Method, system, and computer program product for
managing controlled residential or non-residential environments
Filing Date: March 7, 2003
-9-
ECE 477 Final Report
Spring 2008
This system is probably the most complex of the three, and certainly has the most claims.
It is an RCU which sends commands to a main hub, which then communicates with a plurality of
household appliances through IR signals, including some X10 devices. [4] Similarly to the
previous patent, this system receives signals from appliances which indicate the location of the
portable RCU. [4] This tells the RCU what options to display on the LCD screen. The user may
select preferences to adjust the environment of the room they are in. One of the most important
features of this system is the ability to create macros for appliances within the same location or
room. [4] For example, in a room that has a TV, a DVD player, and a light dimmer, the user may
create a macro which turns the TV on and sets it to receive input from the DVD player, turns the
DVD player on and makes it play, and sets the light dimmer to a low lighting. This macro can
then be stored as the command “Watch Movie”, so that selecting the single command will result
in numerous signals being sent to each appliance in quick succession. [4]
There are a total of 78 claims in this patent, 5 of which are somewhat similar to the
myRoom system. [4] Claim 1 is “A method of managing network devices within a controlled
environment, comprising the steps of: receiving a request to control a plurality of network
devices within the controlled environment; identifying said plurality of network devices for
receiving device-specific commands associated with said request; sending to each identified
network device a sequence of device-specific commands to control an operation or a function of
said identified network device; and executing each of said device-specific commands to control
the plurality of identified network devices for implementing said request.” [4] This is essentially
what the myRoom system does. Claims 7, 9, 10, and 11 describe the process of creating, storing,
and accessing macros. Specifically, claim 7 states: “A method of managing a plurality of
network devices within a controlled environment, comprising the steps of: enabling creation of a
sequence of commands that, when executed, controls an operation or a function of the plurality
of network devices; associating said sequence with a single command; storing said sequence on a
control center; and storing said single command on a controller device such that execution of
said single command sends a request to said control center to execute said sequence of
commands.” [4] This is quite similar to myRoom’s ability to control many appliances at once.
4.3
Analysis of Patent Liability
-10-
ECE 477 Final Report
Spring 2008
The myRoom system works similarly to the feature described in claim 1 of US Patent
#7,136,709. myRoom will have a learning mode in which IR signals from the remote control of
an appliance are sent to the myRoom IR receivers, which then store the codes in the
microcontroller’s memory. Claim 1 of the patent describes a similar learning sequence, which
could imply infringement under the doctrine of equivalents. However, this claim also includes
“using the command received from the another controlling device to teach a command input
decoding engine accessible to the controlling device to recognize the command as being a match
for a generic action descriptor within a database of predefined generic action descriptors”. [2]
Since the myRoom system does not normalize codes or store them in a “command input
decoding engine,” it seems unlikely that there is any infringement on this patent.
The claim with the most potential for infringement from patent #5,646,608 is claim 1,
which describes a remote control system with a main hub as well as an RCU, a device
identification system, the ability to send commands to devices within the room, and a display on
the RCU for indicating command options to the user. The myRoom system does include an
electronic device placed in a room as well as an RCU, but in the myRoom system, these are
contained in a single package. The myRoom system also does not store identification codes for
appliances attached to the system, nor does it have display means. Therefore, myRoom does not
seem to be infringing upon this patent either literally or under the doctrine of equivalents.
The final patent, #6,792,323, holds the greatest likelihood for possible infringement. The
myRoom system manages a number of appliances within a controlled environment by receiving
a request, identifying proper devices, and sending a sequence of commands to the proper
devices. This description is nearly identical to that of claim 1 of this patent, which could indicate
the possibility of a literal infringement. The one key phrase here is “managing network devices”,
which myRoom does not do. [4] The devices in the myRoom system are controlled by infrared
alone, and any networking capabilities that myRoom appliances might have will be ignored.
Therefore, any infringement would be under the doctrine of equivalents, if an infringement exists
at all. Claims 7, 9, 10, and 11, which describe the process of creating, storing, and accessing
macros coincide closely with the functions of the myRoom system. The major difference
between this patent and the myRoom system is that macros are executed by the swipe of an
RFID card in myRoom, and by the press of a button in the system described in the patent. Since
-11-
ECE 477 Final Report
Spring 2008
the myRoom system performs the same function as the system described by the patent but in a
different way, it could be considered infringement by the doctrine of equivalents.
4.4
Action Recommended
Although the aforementioned patents were the three most similar in overall function to
the myRoom system, the potential for infringement existed in only one of them. Claims 1,
7,9,10, and 11 of patent #6,792,323 were potentially liable under the doctrine of equivalents,
since the myRoom system performs these functions using a different method. To safeguard the
myRoom system from potential legal conflicts, the owner of this patent should be contacted
regarding the payment of royalties or licensing of the product.
Since the myRoom system’s primary features are unique to any systems that currently
hold patents, it would probably be wise to file a patent application for it. There were no other
patents for systems which used RFID to distinguish between users, none that used a website to
receive preference inputs from the user, and none that stored macros based on the user rather
than the desired activity. These major differences are probably useful, novel, and non-obvious
enough to warrant their own patent. A lawyer would be contacted to pursue this action.
4.5
Summary
The myRoom system is a unique idea, not a copy of products that have already been
designed. Searching for patents similar to the primary functionality of the myRoom system was
difficult, and the patents that were deemed most similar were still very different ideas. Patent
#6,792,323 for managing controlled residential environments included 5 claims out of a total of
78 which the myRoom system could be infringing upon by the doctrine of equivalents. Even
within these claims, though, there existed significant differences which could be used as
arguments against infringement in the case of legal action. However, in order to prevent legal
conflict, the owner of this patent should be contacted regarding the payment of royalties or
licensing of the product. Also, the myRoom team should pursue the possibility of filing a new
patent for this useful, novel, and non-obvious system.
5.0 Reliability and Safety Analysis
-12-
ECE 477 Final Report
5.1
Spring 2008
Introduction
Reliability and safety are mainly inconveniences to the user, but there are still a few
instances that could result in injury to the user, and as such it is pertinent to make the project as
safe as possible. The critical components in this safety analysis are the components that could be
a potential fire hazard. The remaining potential failures lead to reduction of functionality, and as
such should be as limited as possible, but should in no way be capable of harming the user.
5.2
Reliability Analysis
Reliability analysis was performed on three major components of the design. The first
component was the MC9S12NE64 microcontroller developed by Freescale. This component was
chosen because it is central to the overall design, and also has 80 pins which makes it the most
complex, thus making it the most susceptible to failure. The failure model that was most fitting
was the model for microprocessors detailed within the Reliability Prediction of Electronic
Equipment Military Handbook which defines the failure rate as  P  (C1 T  C 2 E ) Q L
Failures/106 Hours. The first parameter for the equation, C1 , is called the Die Complexity Failure
Rate. It is chosen to equal 0.28 due to the microcontroller being CMOS and being 16-bit. The
next parameter,  T , which is the temperature factor. This can be approximated based upon the
junction temperature, TJ. According to the datasheet for the MC9S12NE64 the maximum
junction temperature is 125°C. Using this value causes  T to be equal to 3.1. The next parameter
to evaluate is C2 , which is the package failure rate. Provided that the packaging is non-hermetic,
then C2 will be equal to 0.041 because the version of the MC9S12NE64 that is being used has
80 pins. The environment factor,  E , was chosen to correspond to the ground, fixed amount
which assumes a worse case scenario of potentially not being in a heated area, but still being
adequately cooled causing the value to be 2.0. The quality factor,  Q , is assumed to be 10 as the
screening levels is unsure, and it is a commercial product. The final parameter is the learning
factor,  L , which would be equal to 1.0 because the device has been in production for over two
years. Now that all of the parameters have been assigned we see that we end up with a failure
rate of  P = 9.5 Failures/106 Hours. This failure rate results in a mean time to failure, MTTF, of
12.0 years.
-13-
ECE 477 Final Report
Spring 2008
The next component for analysis is the LM1117 Low-Dropout Linear Regulator
developed by National Semiconductor. This component was chosen because it heats up the most,
and is the primary suspect for a failure that has the potential to end in injury. The failure model
chose for this device was the microprocessor model which once again uses the equation
 P  (C1 T  C 2 E ) Q L Failures/106 Hours. The value of the Die Complexity Failure rate, C1 ,
was chosen to be 0.010 because the device has less than 100 linear transistors. The maximum
value of the junction temperature, TJ, is 150°C which results in the temperature factor,  T to be
equal to 180 due to it being linear MOS. The package failure rate, C2 , assuming that it is nonhermetic would be 0.0012 due to the presence of three pins. The environmental factor,  E , would
be 2.0 which is the same as the microcontroller. The quality factor,  Q , is assumed to be 10 due
once again to this being a commercial product rather than a military use product. The final
parameter, the learning factor,  L , would be equal to 1.2 because of the assumption that this
particular piece has been in production for between 1.5 and two years due to the published data
of April 2006 on the top of the datasheet. All of these values cause the failure rate to be  P =
21.6 Failures/106 Hours which results in a MTTF of 5.3 years.
The final component for analysis is the ID-12 RFID Reader developed by IDInnovations. This component was chosen because if it fails then it essentially renders the entire
device unusable. This component uses the same failure model as the previous two components
have used. Because the components datasheet does not list the approximate number of transistors
contained within the device, an approximation of between 300 and 1,000 linear transistors is
going to be made causing the die complexity failure rate, C1 , to be 0.040. This should be a
conservative estimate based on the complexity of the device. As there is no specified maximum
junction temperature, the equation TJ   JC P  TC will be used. TC is assumed to be 45°C due to
the fixed ground environment. The junction-to-case thermal resistance,  JC , is assumed to be 20
based upon the die area of the device. The maximum power dissipation, P, can be inferred to be
0.15 Watts. This causes the junction temperature to be 48°C which then results in a temperature
factor,  T to be equal to 0.71. The package failure rate, C2 , assuming that it is non-hermetic
would be 0.0053 due to the presence of eleven pins. The environmental factor,  E , would once
again be 2.0. The quality factor,  Q , remains at 10 as this is also a commercial product. The final
-14-
ECE 477 Final Report
Spring 2008
parameter for this component is once again the learning factor,  L , which would be 1.0 because
the device has been manufactured for longer than two years. This results in a final failure rate of
 P = 0.39 Failures/106 Hours. This ultimately comes down to a MTTF of 292.7 years.
Component
Failure Rate
(Failures/106 Hours)
MTTF
(Years)
MC9S12NE64
9.5
12.0
LM1117 LDO
21.6
5.3
ID-12 RFID Reader
0.39
292.7
Table 5.2.1 - Failure Rates and MTTF of components
After performing the analysis on the components, it is easy to see that it would be
extremely beneficial to improve the reliability of the Low-Dropout Linear Regulator and the
microcontroller. A large reason that these failure rates are as high as they are is due to assuming
a worse case scenario, and using the maximum junction temperature. If this junction temperature
was reduced to a more reasonable operating condition rather than the maximum the failure rate
would drop drastically, especially for the linear regulator. The environmental factor is also a
worst case scenario. In most cases it would be 0.50 instead of the value used of 2.0. Both of these
overestimates cause the failure rate to be higher than what would be expected to see once the
device was deployed, but the linear regulator’s fail rate would still be higher than preferred
considering that it is the component that has the highest probability of resulting in injury. Adding
some hardware to provide a backup for this component would be necessary to reduce that
possibility further.
5.3
Failure Mode, Effects, and Criticality Analysis (FMECA)
In order to provide a detailed analysis of the potential failure modes, the schematic has
been broken down into three major components: the power circuitry, the microcontroller
circuitry, and the peripheral circuitry. These major areas have been outlined in Appendix A. In
order to provide a measure to compare different failures, two criticality levels have been
assigned. A criticality level of High means that that particular failure has the potential to end in
injury. For this level of criticality the failure rate must be  P  10-9 Failures/Hour in order to be
acceptable. The other criticality level is Low. This level indicates that the system may have
-15-
ECE 477 Final Report
Spring 2008
partial or total failure resulting in inconvenience to the user. An acceptable failure rate for this
type of failure is if  P  10-6 Failures/ Hour. The effects of each failure are outlined in the
FEMCA worksheets that are listed in Appendix B for each potential failure, and the resulting
criticality.
5.3
Summary
This reliability and safety analysis has hopefully provided a good overview of the
potential safety hazards inherent within our design, and the probability of those failures
occurring. With the current design the potential for a high criticality failure is too high and would
necessitate some added safety precautions. Before releasing this project for manufacture the
addition of additional safety features would be necessary. The low criticality failures are within
an acceptable failure rate.
6.0 Ethical and Environmental Impact Analysis
6.1 Introduction
There are not many ethical and environmental issues the team has to deal with. The
probability that the system does harm to the user is little. It is basically safe, as long as users,
especially children, do not play around with it. As far as security is concerned, it could happen
that someone hacks into the web-page, and find out the customers preferences, or even worse can
changes the customer settings. During its lifetime the system is only going to use electrical
energy, and not producing any other hazardous substances, such that the environmental impact is
low. Of a higher concern is the production and disposal of the system. It will be pointed out how
to keep the environmental impact as low as possible. Steps can be taken in the manufacturing
phase (using parts and production processes that are environment-friendly) as well as in the
disposal phase, by emphasizing that the product is disposed properly.
6.2 Ethical Impact Analysis
There are not many ethical issues that have to be faced when producing the myRoom
system. There is almost no chance of getting injured while using the system. However, it is
supplied by electrical energy so the user should not work on it while the wall wart is plugged into
-16-
ECE 477 Final Report
Spring 2008
the outlet. In order to avoid that, we can label the box and also put a note in the user manual. We
can also seal the box to make accessing it more difficult. Nevertheless, as the current running
through the board is not high enough to seriously injure anyone, it is not likely that problems will
occur.
A bigger concern is the web-page. It is not encrypted nor password protected. Instead it is
accessible only from inside a local area network, and then it can only be accessed when the user
has swiped their RFID tag. This is sufficient security as long as the system is used within a
family home. Here it would probably be necessary to state in the user manual that this system
should not be used within LANs where a lot of people have access to, and that it should only be
used with people who trust each other.
Even though the intensity of the RFID reader is small it might be a good choice to state in
the system that electromagnetic energy is used within the system, and that even though the
probability is low that it does harm to the user (a lot of tests have been made) it might be the
safer way to state that one should not mount the system directly next to his bed, because we do
not really know about the long-term effects of it, when the body is confronted with it constantly.
It is obviously the better way to go, to inform the purchaser about potential dangers, even though
they are not likely to happen.
6.3 Environmental Impact Analysis
The lifecycle of the myRoom system will be taken as an outline for analyzing the
environmental impact of the device. There are three main phases: manufacture, normal use and
finally disposal and/or recycling.
Advanced Circuits, which is the company where we ordered the printed circuit board,
state on their web-page: “Boards we produce that are not processed using leaded solder for a
final finish will meet all of the RoHS' restrictions.” [11]. RoHS (Directive on the Restriction of
the Use of certain Hazardous Substances in Electrical and Electronic Equipment) requires the
amount of certain hazardous substances (such as lead, mercury, cadmium, etc.) in electronic
devices not to exceed a certain limit. So this is accomplished by the unprocessed board and as
well by most of the parts that were ordered. There are some companies, from which parts were
ordered, that do not state on their web-pages if their production process and products are RoHS
compliant. The problem is that we are using solder that contains lead to finish up the board. To
-17-
ECE 477 Final Report
Spring 2008
use lead free solder, we would have to use a different kind of printed circuit board, as the board
would have to be able to stand higher temperatures, because the lead free solder has a higher
melting point.
We are only going to produce one system. If we would produce a large amount we might
consider ordering the other type of PCB, such that we can use lead free solder. This might be a
little more expensive, but we could explain that to the purchaser. Keeping the costs low is one of
our goals, but as more and more people become aware of environmental issues they might even
prefer to buy a system that considers such environmental issues and therefore is a little more
expensive. We would also contact the other companies to make sure that all the parts, we use, are
RoHS compliant.
During normal use the environmental impact of the myRoom system is extremely low. In
fact the only thing that has to be considered here is the power consumption of the product. The
system might also produce some electromagnetic radiation, as it has an RFID-reader built in. But
as the reader we are using has a range of 12cm and the operation frequency of the reader is 125
kHz the intensity of the radiation should not be high enough to do harm to organisms.
The power consumption of the myRoom system is at most 3.03W. As we do not have a
sleeping mode, we assume that the system will be in use all the time. It might use less power,
when not all the parts of the circuit are active. A month has on average 720 hours such that the
board consumes 2.181 kWh of energy per month. Some organizations made estimations on how
long people use certain household appliances on average per month and how much energy that
consumes. In table 6.3.1 the results from Cornhusker [9] for the appliances that the system will
interface with are summarized.
Typical
Estimated hours
Estimated
Wattage
used per month
monthly kWh
TV
200
183
36.6
Light
75
100
7.5
VCR/DVD
21
12
2.5
Appliance
-18-
ECE 477 Final Report
Spring 2008
CD, Radio,...
250
30
15
Fan
400
71
28.4
Sum
946
-
90
Table 6.3.1 - Power consumption of certain household appliances [9]
It could be that some people do not put off all the appliances in a room when leaving it
for a short while. This would be easier with the system, because one would only have to swipe a
single card to put all the appliances off. Here are some assumptions for the amount of energy that
could be saved when using the system.
Appliance
Estimated hours
Estimated kWh
saved
saved monthly
TV
30
6
Light
15
1.125
VCR/DVD
0
0
CD, Radio,...
10
5
Fan
10
4
Sum
-
16.125
Table 6.3.2 - Assumption of energy that could be saved with the myRoom system
With these assumptions the user would save 13.94kWh per month when using the system. Some
people might sometimes even leave the TV off when entering the room, whereas they would put
it on every time they enter the room when using the myRoom system, and storing as a setting
that the TV should be on. But as the power consumption of the system itself is really low and
when leaving the room all the appliances are shut off, the environmental impact of the system
can be considered low during the in use phase.
As it will be difficult to reuse the parts of the system, once the user tries to get rid of it,
all of it will have to be disposed. We will put notes into the User Manual, to encourage the user
to recycle the product. Apart of that we might sell it for a little more money and give that money
-19-
ECE 477 Final Report
Spring 2008
to a recycle company, such that the user can recycle it for free after use. In order to reduce ewaste we can make the in use phase as long as possible. If people use the system for a long time
and do not have to buy a new one, it is obviously going to produce less waste. There are two
steps that can be taken in order to achieve this. First of all we can try to make the lifetime of the
system as long as possible. This again might affect the price of the product. Today many
companies try to save money by using cheaper parts or shorter wires and so on. But this makes
the lifetime of electronic devices shorter, because of what they will have to be thrown away
earlier. Another thing we can do is to make the system standardized. People sometimes throw
away their electronic devices, because there is a newer and/or better one on the market. If they
would be able to update the system instead of buying a new one, they might keep it for longer.
6.4 Summary
When developing a product engineers have to make sure that ethically as well as
environmentally the product they are producing has no or considerably low negative impacts.
Here the environmental issues are closely related to ethics, as it is an ethical question to what
extend we are responsible for environmental impacts of the products we are developing, and
impacts of what extend are acceptable. Focusing on the myRoom system I would consider the
environmental and ethical impacts to be low. But there are still some issues that have to be
considered and taken care of, in order to make the system able to compete against other products
on the market. These issues and a possible solution to them were outlined in this report.
7.0 Packaging Design Considerations
7.1
Introduction
The major components included in the myRoom system are a Freescale microcontroller
(MC9S12NE64V1), an ID Innovations RFID reader (ID-12), a Sharp Microelectronics IR
receiver (GP1UD26XK), and six Vishay IR transmitters (TSAL7600). These are connected to a
Printed Circuit Board (PCB) which is housed within a small plastic casing which can be mounted
on a wall, next to the entrance to a room. This casing was selected to be as small and discreet as
-20-
ECE 477 Final Report
Spring 2008
possible, durable to protect the components within, and not inhibitive of the signals that are to be
transmitted and received by the system.
7.2
Commercial Product Packaging
Although there are no comprehensive room control systems like myRoom currently on
the market, there are several RFID card readers available. These systems are relevant to the
myRoom project in that the packaging for the myRoom console shares similar design constraints.
Following is an analysis of the packaging of two RFID scanners with regard to how their design
has influenced the design of myRoom’s packaging.
7.3
Tensor T1481 access control scanner
Tensor Access is a device for managing entry to
secured locations. It uses RFID technology to determine
whether someone has permission to gain access to areas or
buildings under control[14]. Tensor Access is connected
to a network which is controlled by a Main Server PC. [14]
This PC stores Access Patterns that define which Access
Groups have permission to enter a given space depending
Figure 7.3.1 - Tensor Access T1481
day of the week, holidays, and other special times [14].
The access control scanner is small, sleek, and relatively discreet. It is packaged in a
rounded, white plastic casing, approximately 12 x 12 x 4 cm [14]. The front panel is black
transparent plastic, which the RFID scanner can receive signals through. At the top of the front
panel, there are three LEDs which display whether the user is “IN”, “INVALID”, or “OUT”
[14]. The center of the front panel displays Tensor’s logo [14].
The small size and discreet appearance of Tensor Access are aspects that will be
incorporated into the myRoom packaging design. Its small size makes it unobtrusive, similar to
a light switch or thermostat. The large black plastic panel in the front, however, makes the
console more noticeable than it has to be. The myRoom console avoided such contrast by
making the entire unit black excluding the logo.
7.4
NPS NP 4101
-21-
ECE 477 Final Report
Spring 2008
The NPS NP 4101 is quite similar to the Tensor Access. It allows RFID card carriers to
swipe in to a system which can grant access to protected areas to those with the appropriate
privileges [15]. The major difference between this and the Tensor
Access is that it also allows users to provide identification via PIN
on a 12-digit keypad [15]. It also keeps track of a log of user
accesses [15].
This console is quite a bit larger than the Tensor Access.
Its dimensions are 15.6 x 16 cm so that it can accommodate a 128
x 64 pixel screen and 12-digit keypad [15]. It is in a light grey
Figure 7.4.1 - NPS NP 4101
encasing, and features black transparent plastic over the RFID
scanner [15].
The packaging of the NPS NP 4101 is much bulkier and eye-catching than the myRoom
console. Its light grey color blends well with room walls, yet its size and its large peripherals
make it hard not to notice. Like the Tensor Access, it has a large black plastic panel in front of
the RFID scanner, which adds to its obtrusiveness. It also has an LCD screen and a keypad,
which are not necessary for the myRoom console.
7.5
Project Packaging Specifications
The myRoom console had few requirements for its packaging. It needed to be large
enough to fit a 9 x 4 cm PCB and a 4 x 5 cm breakout board, yet not much larger so as to remain
discreet. There needed to be openings in the front panel for the IR transmitters, the IR receiver,
and the red and green LEDs. There also needed to be an opening in the side panel for the
pushbutton and at the top right corner of the back panel for the
power supply cord. It could not be made of aluminum, since this
material acts as a negative inductance to the antenna of the RFID
reader [8]. With so few components on the PCB, it was highly
unlikely that the myRoom console would be unreasonably heavy.
However, since the box was intended to be mounted on a wall, the
weight limit was set at 2 lbs.
The packaging for myRoom is a simple plastic box
available from Radio Shack. The dimensions of the box are 7” x
-22-
Figure 7.5.1 - Radio Shack
Project Enclosure
ECE 477 Final Report
Spring 2008
5” x 4” [16]. It is made from durable black ABS plastic [16].
It features four ¼” high standoffs
for mounting a PCB [16]. Openings have been cut out of the bottom of the front panel for the IR
transmitters, the center of the front panel for the LEDs and IR receiver, and the center of the left
side panel for the pushbutton.
7.6
PCB Footprint Layout
The major components of the myRoom console are connected directly to a Printed
Circuit Board. These include the microcontroller (Freescale MC9S12NE64V1), the RFID reader
(ID Innovations RFID Reader ID-12), the IR receiver (GP1UD26XK from Sharp
Microelectronics), and six IR transmitters (Vishay TSAL7600). The microcontroller only had
one footprint option - an 80-pin square shape - so the only decision to be made was where it
would be placed [6]. The RFID reader has 2mm pin spacing, so a breakout board is used to
separate the pins [17]. The breakout board brings the 2mm spaced pins out to two 0.1” spaced
headers [18]. The PCB sits on the bottom panel of the box atop four 1” high feet. The IR
transmitters stand up perpendicular to the PCB in such a way that they can stick out through the
bottom of the front panel of the box. The LEDs and IR receiver are connected to the PCB by
wires so that they can reach the center of the front panel of the box, while the pushbutton is
connected by a wire so that it can reach the left panel.
The PCB footprint layout in Appendix D is 9 x 4 cm. It includes extra spacing for
passive components, padding between major components, and room for any other components
that may need to be added later in the process.
7.7
Summary
The myRoom system is meant to make life simpler for families, and its packaging is as
simple as possible, too. Like the Tensor Access control scanner, myRoom is small in size. It has
holes to allow the IR transmitters, the IR receiver, the LEDs and the pushbutton to poke through.
There are no bulky peripherals on the outside like the NSP RFID scanner. Its discreet packaging
makes it blend right in to the background, like a thermometer or light switch.
8.0 Schematic Design Considerations
-23-
ECE 477 Final Report
8.1
Spring 2008
Introduction
The final schematics for the myRoom system are attached in Appendix C. Several things
were considered when developing the circuitry. Basically four major parts make up the
schematics: the power supply, the microcontroller with its additional circuitry, the RFID reader
and the circuit to send out IR signals.
8.2
Theory of Operation
The final circuit is composed of five major subsections, the IR receiver, the power
supply, the RFID reader, the microcontroller, and an IR LED bank, as well as three minor
subsections, a crystal oscillator, Ethernet connection, and a testing subsection. The minor
subsections are defined as areas of the circuit required for the microcontroller to operate as
intended with little to no deviation possible. The testing minor subsection consists of normal
LEDs in series with a resistor placed in strategic areas of the circuit, as well as headers intended
for debugging purposes, and a pushbutton.
The RFID reader identifies an RFID tag and transmits that tag’s unique ID number. It
uses a 5V power supply and requires 30mA of current and has 3 modes of output [8]. The RFID
reader includes a pin dedicated to driving an LED, which is used for testing purposes [8]. The
only problem with the ID-12 is the lack of complete documentation; while the data sheet does
give the format that data is sent, all other factors regarding ASCII transmission, such as what
frequency the data is sent at and at what voltage level, are not available. A solution to this
problem is to power up one of the spare ID-12s, move an RFID tag near it and analyze the output
signal.
After the RFID reader reads the ID associated with the RFID tag, the signal is sent to a
microcontroller for processing, of which the internal workings will be discussed in section 8.3.
The manufacturer, Freescale Semiconductor, has listed in its datasheet a suggested physical
layout, including decoupling capacitors having a value of .22 uF, a crystal oscillator circuit used
as an external clock, and an Ethernet connection circuit [6]. An LED with an internal resistor is
placed on a generic I/O pin for testing purposes. The microcontroller can handle ±25mA of
current and requires a 3.3V DC power supply [6]. Since the voltage requirement deviates from
the 5V DC power supplied by the “wall wart”, a voltage regulator is required. The choice of an
operating voltage of 3.3V DC was determined by the fact that all microcontrollers manufactured
-24-
ECE 477 Final Report
Spring 2008
by Freescale Semiconductor with an embedded Ethernet use a 3.3V DC power supply, leaving
no other options [20]. The Ethernet transmission/reception mode is set at 10Mbps instead of
100Mbps, because the data that will be received will be very small (at most 100 ASCII
characters), and 100Mbps is unnecessary. Because of this selection, the internal clock for the
microcontroller must be at least 2.5 MHz [6]. The final clock speed is set at 12.5 MHz, in part
because the microprocessor will need to receive and store data from the Ethernet port, but mostly
due to the fact that the SCI operate at a frequency between 32 and 40 kHz (which corresponds to
the IR frequency range used by most IR receivers) [21], which is the next-most computationally
intense function. External memory is not required, so the microcontroller runs in single-chip
mode.
After the ID is processed, the microcontroller outputs to the IR LED bank consisting of 6
TSAL7600 High-Intensity IR LEDs. These LEDs have a forward voltage of 1.35V and nominal
forward current of 100mA [19]. The high current is the main problem here, as the six LEDs
require 600mA total, and the microcontroller’s I/O pins can only sink 5.5mA, and only two are
available for the SCI [6]. Therefore, a current-amplification device is needed. After comparing
several npn BJTs, the TIP120 was chosen because it’s high current gain [22], and only one is
required.
In order to transmit the correct IR signal, an IR receiver will be used to “learn” IR codes.
A pushbutton will signal the microcontroller to record anything going into its SCI, which it then
records several copies of the input. Using these samples, the microcontroller attempts to find
two matching signals, then saves the resulting match. All of the IR receivers considered are very
sensitive, and simply waving a hand near one is enough trigger an output. The selected IR
receiver, the GP1UD26XK, was chosen because it requires 3.3V for power, as well as outputs at
3.3V, and is readily available.
8.3
Hardware Design Narrative
In order to properly interface the ID-12 RFID reader with the microcontroller, the ASCII
output mode is selected by tying pin 7 of the ID-12 to ground and pin 8 [8] is connected to SCI
input pin 21 on the microcontroller. The input from this SCI input pin is sent to the MCU which
then attempts to match the ID received to one in memory, and then performs all functions
described by that ID.
-25-
ECE 477 Final Report
Spring 2008
One of the goals for this project was to allow an external website to change memory
settings in the microcontroller’s internal Flash memory. To accomplish this, both Ethernet
subsystems (EMACV1 and EPHYV2) have to be active, and together will serve as a data
receiver. This network of subsystems receives external data, then sends that data to the MCU
which places it in the appropriate memory address.
Another goal of the project is to remotely control several appliances using IR signals.
The microcontroller’s SCI subsystem has built-in support for IR output for ranges of 2.4kbs to
115.2kbs [6] and is utilized to meet this goal. Because the SCI module only has 2 output pins
[6], all six IR LEDs are connected to one pin in parallel. This increases the current draw from
the pin as discussed in section 8.2, but if the pin is somehow damaged, the other can be used
instead. The other SCI input pin will be used to interface with the IR receiver. Both of these
pins, pins 22 and 23, are set to be used as generic I/O instead of SCI.
8.4
Summary
Overall, the hardware design is straightforward. The ID-12 reads an RFID tag and sends
that tag’s unique ID to the microcontroller, which processes the ID and outputs to an IR LED
bank through its SCI output operating in IR transmission mode. The IR receiver reads IR codes
from a remote control via an input pin when the system is in “Learn” mode. At any moment, the
microcontroller may receive an external signal from its Ethernet adapter, which it then processes
and stores in memory, overwriting existing data if necessary.
9.0 PCB Layout Design Considerations
9.1
Introduction
The printed circuit board for the system neither has to be extremely small nor do a lot of
components have to be placed, so that the design is straight forward. In the following lines it will
be pointed out, which parts are mounted, and how they are placed on the PCB. Much care has to
be taken of the microcontroller, together with its clock circuit, and the RFID-reader, as these are
the main noise producing parts. The critical point with the RFID reader is the lack of
documentation, as the team doesn’t know if certain distances be hold. Additionally the common
considerations for designing a PCB are accounted for.
-26-
ECE 477 Final Report
Spring 2008
9.2 PCB Layout Design Considerations - Overall
In the block diagram the main components that have been mounted on the PCB are
highlighted dark green. The parts include an RFID-reader, the microcontroller, an IR receiver,
and a bank of IR transmitters. Apart of that an RJ-45 connection to interface with the web-page
and a power supply connection are to be located on the PCB. The complete circuit that has to be
placed can be seen in the schematics.
The packaging requires that the PCB is at most 11cm times 4.5 cm big. It is assumed that
the device will be placed on the left side of the door. As the RFID reader has a short range, it was
placed at the left side of the PCB (looking from the front side), such that a user can easily scan
his tag. The IR transmitters point to the front. They have a half intensity angle of 30°. The 6
LED’s will be mounted in pairs. Each pair points into one direction horizontally and between
each pair there will be an angle of 30° so that an area of 90° in the room can be covered, for the
user can choose flexibly where he wants to place his appliances. One LED of each pair will point
to a 50cm height and the other to a 1.20m height, as the devices may have their IR-receivers at a
different height. The IR receiver also points to the front so that the user can easily point with a
remote to it. It is important that the receiver is shielded against the other lights that would disturb
the incoming signal. A wall wart is used to supply the device with energy. That requires that the
power supply is mounted at one side of the board such that a connection to the outside of the
packaging can be made. For the same reason the Ethernet connection will have to be placed to
one side of the board.
Some considerations have to be made in order to reduce EMI [23]. The main noise
producing components are the microcontroller plus its digital clock circuitry, and the RFID
reader. They should be mounted separate from the power supply circuit which includes a
DC/DC-regulator and the connection to the wall wart. As the PCB is not extremely small it is not
a big problem to locally separate the different parts from each other.
Another consideration is the width of the power lines. The main power lines are
thicker, as more current is going through them. The same applies for the IR transmitter circuit.
The collector current of the TIP120 will be 600mA. So here the traces are also a little thicker.
Additionally to these things some basic considerations were made. When designing a
footprint, the drill should be thicker than the pin that should fit in it, as inaccuracies occur when
-27-
ECE 477 Final Report
Spring 2008
the board is printed [24]. The traces should be as short as possible, to reduce the possibility that
noise can disrupt the signal going through it [23]. There should not be any traces having a 90
degree angle as well.
9.3 PCB Layout Design Considerations – Microcontroller
The microcontroller 9S12NE64 from Freescale is used for the design of the myRoom
system. In the data sheet [6] certain requirements for integrating the microcontroller in a circuit
and for mounting the microcontroller on the PCB are listed that were considered in addition to
the basic considerations.
The microcontroller was placed in the middle of the PCB. It connects all the parts of the
design so that the center was considered being the best position, in order to keep the length of the
traces as short as possible. The clock circuit needs to be as close to the microcontroller as
possible
In the datasheet of the microcontroller [6] requirements for a successful PCB-design are
listed. Ceramic capacitors should be used to decouple every supply-pair. These decoupling
capacitors should be mounted as close to the pins as possible. They are placed under the
microcontroller in order to achieve minimum spacing. A recommended schematic for how to put
the decoupling capacitors is given in Appendix B of the datasheet. The RJ-45 connector should
be close to the microcontroller as well. This is restricted in this certain design due to the space
given and the circuit that is needed for the RJ-45 connection. Also the RJ-45 connection should
be at one side of the board to connect an ethernet wire easily. The traces should be wider than 10
mils.
Extremely sensitive for noise are the interrupts and the Reset button. If they are
influenced by noise they might send an interrupt to the microcontroller and so influence the
function of the whole circuit [6]. The team might decide to put the pushbutton a little farther
away from the microcontroller, even though the noise would have to indicate a change of around
3V at this pin. With the components used this is fairly impossible.
9.4 PCB Layout Design Considerations - Power Supply
-28-
ECE 477 Final Report
Spring 2008
As mentioned before the power connection needs to be situated at the right top of the
PCB, as the PCB is laid down in the package and we are using a wall wart to connect the device
to an outlet.
The power and the ground trace should be routed parallel to each other. The components
of this system do not require high voltage or high current. As the microcontroller works at a
supply voltage of 3.3V and the RFID-reader at a voltage of 5V a power regulator needs to be
used. Here it is important to use a decoupling capacitor at the exit of the regulator, which should
be located as close as possible. The wall wart should take care of this itself.
The wire from the power supply is routed far away from the clock circuit. This is very
critical about supply wires. They are connected to almost every part of the board and as such can
spread noise easily throughout the board [23]. A problem here is that due to the short datasheet
from the RFID-reader [8] it was difficult to decide if wires can be routed under the RFID-reader
or not.
9.5 Changes made to the original PCB
During the development process it turned out that the signal coming out from the outlet was
not smooth enough. It consistently destroyed the RFID-reader. We had to change the five volts
wall wart to a nine volts wall wart and regulate that signal down to five volts. As the five to 3.3
volts converter needed a five volts incoming signal we had to connect them in series. Apart of
that a pushbutton and two LEDs were added to the system. These did not occur in our first
design, and therefore have not been situated on the PCB.
9.6 Summary
A lot of things were taken into consideration in order to make it a well functioning board,
whereas the clock circuit is the most difficult part. Here errors in the development process were
made. Parts for a well functioning board for this system were considered too late. Additionally
we should have tested the circuits more before designing the board.
10.0 Software Design Considerations
10.1 Introduction
-29-
ECE 477 Final Report
Spring 2008
The software is flag-driven due to having a natural sequential order in which things
should occur, but it will also have to listen to interrupts to realize when an RFID tag has been
read, and when to toggle the output pin for the infrared transmitters.
10.2 Software Design Considerations
10.2.1 Memory Mapping
The microcontroller that our project is utilizing is the MC9S12NE64. The block diagram
of this particular microcontroller can be seen in Appendix C. This particular microcontroller
makes use of 64KB of EEPROM and 8KB of SRAM memory. Most of the memory we use will
be within the EEPROM section of memory making use of its non-volatile state to store the
instruction memory, and all stored variables such as the user settings, and the infrared codes
associated with those settings.
10.2.2 External Interface Mapping
The external interfaces will be mapped in the following way. The RFID reader which
utilizes RS232 as its communication protocol will be mapped to SCI0_RXD. The infrared
receiver is mapped to SCI1_RXD while the infrared transmitters are mapped to SCI1_TXD.
There are also a red LED, green LED, and two pushbuttons attached to general input pins. We
also have a pushbutton attached to the reset pin in order to implement the ability to reset the
microcontroller. The Ethernet interface is found on the EPHY ports. While the infrared receivers
and transmitters are connected to serial communication pins they do not utilize serial
communication, and the pins act as normal input/output pins.
10.2.3 Utilization of Integrated Peripherals
The software that we are developing will make use of two of the major built-in
peripherals located on-chip. These are the Serial Communication Interface (SCI) module and the
Ethernet Physical Transceiver (EPHY) module. The SCI module will need to be implemented
differently for each part that it is communicating with. For the RFID reader on port SCI0_RXD
we need to initialize it to a baud rate of 9600 with receiving enabled. The infrared receiver and
transmitters have the serial communication switched off, and are using the peripheral as a normal
input/output pin.
-30-
ECE 477 Final Report
Spring 2008
10.2.4 Organization of Application Code
The application code itself will be command driven being a mix between a state machine
and an interrupt driven implementation. The program is very sequential, but interrupts will be
necessary to determine when an RFID tag comes into range, and when the program needs to
toggle the output pin for the infrared transmitters when transmitting an infrared code.
10.2.5 Debugging
In order to accommodate some provisions for debugging our code we will be using a few
LEDs to communicate the status of our project. These same LEDs are the only direct
communication with the user for the IR code learning module as well. Through illumination
different sets of LEDs it should be possible to effectively discover what is happening within our
code. We also developed a method to output on the SCI port which enabled us to view the output
of the program on the hyper terminal such that we were able to use print statements to debug.
10.3 Software Design Narrative
Our application code is comprised of a single file that contains several functions to
accomplish the desired goals. Below is a narrative for each of the individual functions.
Flowcharts of the specific functions can be found in Appendix F as well as a hierarchal view of
the entire application code. The finalized source code is located within this same appendix.
10.3.1 Main Function
The purpose of our main function is to first initialize all of the registers to the correct
initial value for all of the onboard peripheral interfaces then enter into a program loop. Code
Warrior takes care of all of this initialization code for us. This program loop initially waits for an
interrupt to be generated indicated that an RFID tag has been read, or for a pushbutton to be
pressed. If an RFID tag is read, that particular tag ID will be stored for use. If a pushbutton is
pressed then the program will enter into the learning module for the infrared codes. The website
interface will make use of the most recent tag scanned to assist in preparing settings. The most
recent tag is also used in a lookup routine to find the associated settings for that particular user. If
there are no settings then the program will return to waiting for an RFID tag to be scanned. The
-31-
ECE 477 Final Report
Spring 2008
settings must be updated through the website before the program will continue onward. If there
are settings associated with that RFID tag then the system will check if it has the appropriate IR
codes available. If the codes are unavailable then it will enter the IR code learning module. Once
the IR learning module has completed the program will loop back to where the presence of IR
codes was checked. If there are IR codes available then the program will go through a
transmitting program that will transmit the necessary IR codes to the devices. Once this has
completed the program will begin once again waiting for an RFID tag to be scanned. This
section of code is working with the exception of the Ethernet module. At this present time, there
are variables that store settings, but due to difficulties interfacing with the Ethernet controller
there is no way to modify these variables from outside of the code.
10.3.2 IR Learning Module
The purpose of the IR learning module code is to learn the IR codes that are needed to
communicate to the devices within the room. Once a pushbutton is pressed, the code enters into
the IR learning module. This module receives two consecutive IR codes from the remote control
by holding a button, and then compares those two values. If those values match then the IR code
has been successfully learned, and the module moves onto the next code. The reason for doing
this is that the IR receiver is extremely susceptible to noise so to eliminate that the code makes
sure that it receives the same sequence twice in a row. This process repeats until all of the IR
codes have been learned. In order to tell if the code has been learned, LEDs illuminate to show
the current status. If the red LED is lit then the program is waiting for a match. Once a match
occurs the green LED is lit for one second. The IR codes are stored as an array of time
representing when the IR code changes from either high to low or low to high. By keeping track
of these times its possible to recreate the code. If the program has received all of the IR codes
neither LED is illuminated. Once all of the IR codes have been entered and saved, the function
will exit. This function is fully operational as well.
10.3.3 Website Module
The purpose of the website module is to enable the user to enter their preferred settings.
This module works by sending out an HTML form that allows the user to pick which user it
would like to create settings for. Once the user has picked the settings they hit submit button
-32-
ECE 477 Final Report
Spring 2008
which causes a CGI script to activate. This CGI script is then parsed correctly by our
microcontroller to extract the settings. Once all the settings have been applied, the module will
save those settings, and return to waiting for an RFID tag to be scanned. This process takes
lowest priority once a tag has been scanned or once the IR code learning process has began. This
function is partially incomplete. This code is working independent of the rest of the code, but
some difficulties exist in merging the two pieces of code.
10.3.4 Transmission Module
This code module is simply the output of the IR codes through the IR transmission
diodes. This module takes the times learned from the IR learning module, and reconstructs the IR
code. When the pulse is high the IR diode is actually transmitting a wave at 40KHz. Once it has
remained high long enough it returns to zero and remains there until it is time to oscillate at
40KHz again. After this completes the function will exit, and the main function will once again
be waiting for an RFID tag to be scanned.
10.4 Summary
The above outlined code works in an efficient manner due to state machine
implementation which allows the presence of an RFID tag to provide an interrupt. The overall
results allow for a smooth running implementation of our application to truly make the myRoom
into the complete room control system that is strived for.
11
Version 2 Changes
Development of the myRoom system was significantly limited by time and a lack of
funding. With more time and a greater assortment of home appliances to test on, the myRoom
system could become a highly useful and novel product.
If a second version were to be created, IR transmission and user input would be improved
upon. First, myRoom would be expanded to be compatible with more IR frequencies. This
would make myRoom compatible with most brands of electronics as well as X10 technology.
Second, user preferences input would be drastically changed from the original website design.
The program would be altered to allow the user to add any type of appliance to the list of
-33-
ECE 477 Final Report
Spring 2008
appliances in the room, and to specify what settings were available for that appliance. For
example, if a user only wanted to specify on/off and channels for their TV that would be
possible, but if they also wanted to add mute or picture in picture options, this would also be
possible. Third, since connecting a PC to the myRoom system via Ethernet turned out to be
complicated and cumbersome version 2 would probably include an LCD screen and a keypad for
user preferences input.
12
Summary and Conclusions
The creators of myRoom were able to accomplish a great deal throughout the course of
this project. The myRoom system was meticulously designed, with both professional and
technical constraints in mind. It is now capable of learning IR codes and storing them to
memory, detecting RFID cards scanned on the RFID reader, retrieving user preferences, and
transmitting IR codes. Aside from the ability to allow users to input their preferences via an
embedded website, the myRoom system does everything that it was originally intended to do.
The members of team 9 learned a variety of skills through the completion of this course.
We got practice working with different types of engineering development software, such as
OrCAD and CodeWarrior. We became more comfortable working with a microcontroller and
other circuit peripherals. We learned how to design the schematic for a complicated electrical
system and how to map that schematic to a PCB. We learned how to think about projects in
terms of its safety, environmental, and ethical impact. Each of also learned how to work on a
team and what our own personal strengths are. It was a valuable learning experience for
everyone on the team.
13
References
[1] Rabbit Semiconductor, “Rabbit RCM4000 series data sheet”
http://www.rabbit.com/products/rcm4000/rcm4000_4010.pdf
[2] P.D. Arling et al., "Home appliance control system and methods in a networked
environment," U. S. Patent 7,136,709, Nov. 14, 2006.
[3] P. Shintani, "Apparatus and method for an electronic device control system," U. S. Patent
75,646,608, Jul. 8, 1997.
-34-
ECE 477 Final Report
Spring 2008
[4] P. Krzyzanowski et al., "Method, system, and computer program product for managing
controlled residential or non-residential environments," U. S. Patent 6,792,323, Sep. 14,
2004.
[5] Department of Defense, “Military Handbook – Reliability Prediction of Electronic
Equipment,” MIL-HDBK-217F, Feb. 1990. [Online]. Available:
http://cobweb.ecn.purdue.edu/~dsml/ece477/Homework/CommonRefs/Mil-Hdbk-217F.pdf
[Accessed: April 3, 2008].
[6]
“MC9S12NE64V1 Datasheet,” [Online], [cited February 7, 2008], Available at:
http://www.freescale.com/files/microcontrollers/doc/data_sheet/MC9S12NE64V1.pdf
[7] National Semiconductors, “LM117 800mA Low-Dropout Linear Regulator,” April 2006.
[Online]. Available: http://cobweb.ecn.purdue.edu/~477grp9/documents/LM1117.pdf
[Accessed: April 3, 2008].
[8] “ID-12 Datasheet,” [Online datasheet], [cited February 7, 2008], Available at:
http://www.sparkfun.com/datasheets/Sensors/ID-12-Datasheet.pdf
[9] Cornhusker, “Operating Costs of Household Appliances,” [Online Document], 2002,
[accessed April 8, 2008], http://www.cornhusker-power.com/householappliances.asp
[10] Wikipedia, “Restriction of Hazardous Substance Directive,” [Online Document], 2008,
[accessed April 8, 2008],
http://en.wikipedia.org/wiki/Restriction_of_Hazardous_Substances_Directive
[11] Advanced Circuits, “RoHS Compliance Printed Circuit Boards,” [Online Document], 2007,
[accessed April 8, 2008], http://www.4pcb.com/index.php?load=content%20&page_id=17
[12] EPA, “Electronics Reuse and Recycling,” [Online Document], October 2000, [accessed
April 8, 2008], http://www.in.gov/recycle/3026.htm
[13] Wikipedia, “Electronic Waste,” [Online Document], 2006, [accessed April 9, 2008],
http://en.wikipedia.org/wiki/Electronic_waste
[14] “Access Control Software & Systems – Tensor plc,” [Online document], [cited February 6,
2008], Available at: http://www.tensor.co.uk/english/tensor-access.htm
[15] “NPS – soluzioni per il card management,” [Online document], [cited February 7, 2008],
Available at:
http://www.ennepiesse.com/home.php?MO=2.1.2.0.0,2.1.0.0.0,2.0.0.0.0&news=NP4101RF
ID&tab=5&IDp=375
[16] “RadioShack.com – Cables, Parts & Connectors: Component parts: Project boxes: Project
Enclosure,” [Online document], [cited February 7, 2008], Available at:
-35-
ECE 477 Final Report
Spring 2008
http://www.radioshack.com/product/index.jsp?productId=2062281&cp=&sr=1&origkw=pr
oject+box&kw=project+box&parentPage=search
[17] “SparkFun Electronics – RFID Reader ID-12,” [Online document], [cited February 7,
2008], Available at:
http://www.sparkfun.com/commerce/product_info.php?products_id=8419
[18] “SparkFun Electronics – RFID Reader ID-12 Breakout,” [Online document], [cited
February 7, 2008], Available at:
http://www.sparkfun.com/commerce/product_info.php?products_id=8423
[19] “IR LED Datasheet”, [Online Document], [Accessed February 14, 2008],
http://cobweb.ecn.purdue.edu/~477grp9/documents/tsal7600.pdf
[20] “Parts Selection Guide”, [Online Document], [Accessed February 14, 2008],
http://www.freescale.com/files/shared/doc/selector_guide/SG1006.pdf?fsrch=1&WT_TYP
E=Selector%20Guides&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_
ASSET=Documentation
[21] “IR Remote Control Theory”, [Online Document], [Accessed February 14, 2008],
http://www.sbprojects.com/knowledge/ir/ir.htm
[22] “TIP120 datasheet”, [Online Document], [Accessed February 14, 2008],
http://cobweb.ecn.purdue.edu/~477grp9/documents/tip120.pdf
[23] Motorola, “Semiconductor Application Note AN1259,” [Online Document], 1995,
[accessed February 22, 2008],
http://cobweb.ecn.purdue.edu/~dsml/ece477/Homework/CommonRefs/AN1259.pdf
[24] D.G. Meyer, “Module 9: PCB Design,” [Online Document], 2007, [accessed February 22,
2008], http://cobweb.ecn.purdue.edu/~dsml/ece477/Notes/PDF/Mod9.pdf
-36-
ECE 477 Final Report
Spring 2008
Appendix A: Individual Contributions
A.1 Contributions of Zachary Beechler:
As an electrical engineer, my contributions to the project mainly focused on the hardware
and packaging aspects. Specifically, I selected all final parts, designed the schematic and overall
circuit, made finishing touches to the PCB, populated the board, created an initial flowchart for
the software, modified the packaging, and led the team during group presentations.
During the initial design phase, I split the team up, giving each person a specific aspect of
the project to find parts for: Andrew the RFID reader, Laurie the microcontroller, Gesine the IR
emitters, and I the X10 communication as well as IR transmission code libraries. Each team
member gave me a list of parts they found and I in turn chose the final parts from their respective
lists. Afterwards, I created the schematic, which included creating new parts in ORCAD. When
we later decided to add an IR code learning function instead of an IR code library to the project I
chose the IR receiver and added it and supporting components to the schematic.
During the PCB design phase, I modified the footprint for the microcontroller, and made
the finishing touches, including “cleaning up” traces by removing unnecessary vias, shortened
the traces to the RJ45 connector, created the copper pour underneath the microcontroller in order
to accommodate its heat-dissipation flag, fixed some pad spacing problems, added the IR
receiver circuit, and sent in the final design for fabrication. However, problems later arose due
to the IR receiver footprint I selected, as the part we intended to use turned out to be out of stock
at all major vendors, requiring me to use a substitute with a different footprint. Once the finished
PCB arrived, I soldered the power supply to the board, verified that it worked correctly, then
proceeded to populate the board, one section at a time (i.e. RFID reader, microcontroller, etc.),
testing each section. Unfortunately, the first RFID reader and microcontroller were rendered
inoperational afterwards. While populating the board, other problems related to the IR receiver
arose involving not considering adding a user interface to the project, which resulted in flywiring pushbuttons and LEDs to the PCB.
At the same time I helped the programmers get started by requesting a development
board for them to use and creating an initial flowchart for our software. At this point I also
began modifying the original box we intended to use for packaging by drilling holes for the
A-1
ECE 477 Final Report
Spring 2008
power supply, IR emitters, user interface (two pushbuttons and two LEDs), Ethernet cable, and
mounting holes.
Finally, as team leader, I led the team during group presentations, answering questions
when I was able. I also proofread all presentations and homework, reminded team members of
impending notebook evaluations, and helped other members with their work to the best of my
abilities.
A.2 Contributions of Laurie Duncan:
My contributions to the project have been primarily in the areas of software,
documentation, and general organization, but I have had at least a small hand in nearly all
aspects of the myRoom system. First, I took charge of project documentation by creating our
website, writing the PowerPoint presentation and delegating responsibilities for the Design
Review, writing the ECE Senior Design Report, and assembling old work and writing all new
sections of the Final Report. Second, I spearheaded work on the user input website and worked
with Andrew on the development of the rest of the project’s code. Finally, I took a leadership
role in organizing team meetings, delegating responsibilities, and maintaining team morale.
I have written the majority of the documentation for this project. When the team had to
give a Design Review, I prepared the PowerPoint presentation for it. I wrote the entire ECE
Senior Design Report. I wrote all portions of the Final Report that had not already been written
as homework assignments, delegated responsibilities for updating old work, added the updated
work, updated references, and proofread the final product.
I created the website to serve as a resource for members of team 9 and to allow interested
third parties to keep track of our progress. I wanted the website to be visually appealing and
easy to navigate, so I started by searching for design templates to build off of. When I finally
found one that fit the feel of our project, I set about configuring it with our team’s content. For
this, I had to learn how to use CSS. I also had to work with ITaP staff to make our website
accessible. I then created the five main pages available on the website and added the appropriate
information, images, and tables to each.
The creation of the user input website was a major time investment. First, I did research
on the best way to retrieve input from users through web forms. I read a number of online
tutorials and played around with sample CGI scripts, but soon discovered that most CGI
A-2
ECE 477 Final Report
Spring 2008
scripting requires special Perl or C files and libraries that would be difficult to install on our
microcontroller. I looked at the final report of a team from a previous semester, but they had
only included the hexadecimal versions of their web files, not the original html format. Finally, I
spoke with a member of team 15 who gave me the hint that I needed in order to progress. I
updated the http server file to run a parsing function on the URL whenever a “?” was
encountered, indicating a CGI “GET” operation. I wrote the parsing function to grab the user
input information and store it in global variables that could be used in other parts of myRoom’s
code. Everything seemed to be working fine until I tried to integrate the web code with the rest
of the code. Hours were spent trying to understand why the two code modules would not work
together (all attempts at integration led to numerous cryptic errors claiming that some function
that was auto-created by CodeWarrior was incorrect). This issue has not yet been resolved.
Although Andrew had the lead role in the development of the rest of the project’s
software, I had a hand in the development of almost all of its major functions. First we worked
on storing inputs from the IR receiver. I began by figuring out how to work with
microcontroller’s timer module. I then developed an algorithm for storing codes based on the
amount of time the signal was held high and low for each cycle. Later in the project, I assisted in
debugging the IR transmission code. Our original algorithm failed to turn on the TV, so together
Andrew and I took apart the TV’s remote control and tested the signal being sent by it. Gesine
helped us figure out that the difference between the codes being transmitted and the codes being
received was that the code being transmitted had to be sent at 40kHz in order for the receiver to
interpret it as being held high. Together, Andrew and I rewrote the transmission function to send
data at a higher frequency. Coaxing the microcontroller to change its output to the SCI pin so
quickly took quite a bit of debugging, which I also participated in.
I contributed to the hardware portion of the project by researching the best
microcontroller to use, the best IR receiver to use, and the best way to program the
microcontroller. I also spent time brainstorming causes for strange behavior in our PCB, such as
the frying of two microcontrollers and an RFID reader.
Throughout the semester, I have taken the lead role in organizing team tasks, delegating
responsibilities, and keeping the team motivated and on track. I planned regular team meetings
at the beginning of the semester to brainstorm a design, write the Final Project Proposal, and
divide project responsibilities. When the team had to give a Design Review, I helped each
A-3
ECE 477 Final Report
Spring 2008
person plan how to present their portion of it. I delegated responsibilities for the User Manual
and wrote the introduction for it. I also made it my responsibility to ease tensions that arose
between teammates throughout the semester, talked anxious teammates through their worries,
and communicated to teammates the importance of their contributions to the project.
A.3 Contributions of Andrew Hampton:
My contributions to the project were significant following the design on the printed
circuit board (PCB). I did not have a hand in the design of the schematic or the PCB, but I was
responsible for a very large portion of the software development, interacting with the hardware
components from the software, project integration, and a small amount of soldering.
For the software design, I was behind the overall flow of software, and did a majority of
coding on everything except for the Ethernet controller code. I was responsible for learning how
to work within the Code Warrior environment, and created functions to allow us to understand
the code easier. One of these functions included the print function which output to the hyper
terminal. This was invaluable in debugging the software, and ensuring that everything was
operating as we expected it to. With some assistance from Laurie, I was also responsible for the
creation of the main function, the function that sends infrared codes, and the function that learns
infrared codes. The overall code is primarily flag-driven with interrupts either setting or reacting
to certain flags.
For the interaction between the software and hardware components, Gesine and I worked
hand in hand to create working circuits on the breadboard before having a working PCB. We
mainly created working circuits for the RFID reader, and the infrared receiver. These circuits
allowed us to develop software long before our PCB was working correctly, and also allowed us
to recognize if the PCB was operating correctly. This was also the stage in which we learned
how everything worked in order to make the software work coherently with the hardware. With
some assistance from Chuck, we also created a circuit on the breadboard for the infrared
transmitters, but did not make extensive use of this circuit. We didn’t make use of this circuit as
much because I disassembled the remote control that we had been using to learn infrared codes
in order to connect oscilloscope probes across the infrared transmitter to view exactly what was
coming out of the remote. This allowed the breakthrough that eventually permitted me to create
the code that successfully transmits via infrared transmitter.
A-4
ECE 477 Final Report
Spring 2008
As the project was winding down, it became apparent that we would need some additions
to our PCB in order to work well with the software. These additions consisted of two
pushbuttons and two LEDs. It was my responsibility to decide where these should be connected,
and I helped to do some of the soldering on these pieces. These additions allow the final product
to function without any view screen interface.
As can be seen, I contributed significantly to the finalized product. My focus was mainly
on the software, but in order to understand the software it was necessary to also understand the
hardware which then led me to work on the interaction between the hardware and software as
well.
A.4 Contributions of Gesine Hinterwalder:
As my area of expertise is communications my responsibility was to find out about
sending IR signals. Here I did research on how bits are coded in order to be recognized by an IR
receiver. I also chose the parts for sending the IR codes and assisted with developing the circuit
for sending them out.
The main thing I contributed to this project was the design of the PCB. I first made the
footprints that we could not find in the Cadence libraries. I also did the routing of the traces. I
had to change the design various times, as I found out about things I had not considered in the
beginning. Once the design was done I checked the footprints together with Zach and it turned
out that some still would not fit to the ordered parts. I changed these footprints and modified the
design.
After the board was printed, I did some of the soldering that had to be done. A big
problem here was that we did not test our circuits before planning the PCB. Major changes had
to be done to the design afterwards as for example to the power supply. Here we thought that the
DC signal coming out of the wall wart would be regulated and so a clear 5V DC signal. In fact it
was not and burned two RFID-readers. Another problem was the IR receiver. We added this part
very shortly before sending out the design to Advanced Circuits and when it came to ordering the
part it was out of stock. The part we actually used requires the same circuitry but has a different
pin combination. The last problem was that we thought in the beginning that all the functionality
could have been done by software. In fact we should have planned to integrate some things that
can be used for communication with the microcontroller. Here it turned out that it was much
A-5
ECE 477 Final Report
Spring 2008
more difficult to set up the Ethernet connection. But everything should have been controlled by
the web page. So we had to integrate some pushbuttons and LEDs, to communicate with the
board, late. I contributed on adding these things to the board and modifying the schematics.
As a minor contribution I see the design of the block diagram, choosing many of the parts
we used for the board and ordering them, as well as assisting Andrew when putting code on the
board and trying to find out why different things would not work with our board.
A-6
ECE 477 Final Report
Spring 2008
Appendix B: Packaging
Figure B.1 – Picture of the completed packaging.
B-1
ECE 477 Final Report
Spring 2008
Appendix C: Schematic
Power Supply
9V
J1
9V
U2
1
2
1
IN
MC1503
CON2
5V
OUT
2
U5
1
C18
100uF
IN
3.3V
OUT
MC1503
Figure C.1 – Power Supply Schematic
D-1
2
C24
100uF
C25
.1uF
ECE 477 Final Report
Spring 2008
3.3V
C22
5V
1k
R28
.1u
SW3
R8
1k
P1
Q2
2N3904
P1
P2
U3
P21
OUT
3.3V
IN
1
C21
C19 MC1503
47uF
.1u
P14
P15
R26
P14
D2
R27
R
LED
D3
0
LED
P2
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
MI_TXER/KWH6/PH6
MI_TXEN/KWH5/PH5
MI_TXCLK/KWH4/PH4
MI_TXD3/KWH3/PH3
MI_TXD2/KWH2/PH20
MI_TXD1/KWH1/PH1
MI_TXD0/KWH0/PH0
MI_MDC/KWJ0/PJ0
MI_MDIO/KWJ1/PJ1
VDDX1
VSSX1
MII_CRS/KWJ2/PJ2
MII_COL/KWJ3/PJ3
MII_RXD0/KWG0/PG0
MII_RXD1/KWG1/PG1
MII_RXD2/KWG2/PG2
MII_RXD3/KWG3/PG3
MII_RXCLK/KWG5/PG4
MII_RXDV/KWG5/PG5
MII_RXER/KWG6/PG60
P15
R
J5
1
MC9S12NE64
P21
P24
R3
11.9
R4
11.9
R5
11.9
3.3V
IR3
TSAL7600
C15
R19
RBIAS
0.22
3.3V
R24
P32
0
0.01
R6
11.9
IR4
TSAL7600
IR5
TSAL7600
470pF
3.3V
3.3V
R16
P24
IR6
TSAL7600
P36
P37
Y 1 25MHz
R17
2.2k
R18
10M
C11
3.3V
C12
R22
600
15pF
15pF
1.5k
SW PUSHBUTTON-DPST
CON1
Figure C.2 – Primary Schematic
D-2
R12
49.9
R13
49.9
R23
P32
1
2
3
4
5
6
6
5
4
3
2
1
8
P51
P50
SW2
P24
C17
C16 0.22
0.22
P53
P32 4700pF
Q1
TIP120
P51
P50
10k
P54
P34 P35
C10
C8
J6
1
C14
0.22
P54
P53
J7
P32 P34 P36
.1u
0.22
IR2
TSAL7600
3.3V
10k
C7
P23
C9
IR1
TSAL7600
60
59
58
57
56
55
54
53
52
51
50
49
48
47
46
45
44
43
42
41
3.3V
P33
R2
11.9
PL0/ACTLED
PL1/LNKLED
VDDR
PL2/SPDLED
PHY -VSSRX
PHY -VDDRX
PHY -RXN
PHY -RXP
PHY -VSSTX
PHY -TXN
PHY -TXP
PHY -VDDTX
PHY -VDDA
PHY -VSSA
PHY -RBIAS
VDD2
VSS2
PL3/DUPLED
PL4/COLLED
BKGOMODC
P33 P35 P37
C23
R1
11.9
0
P21
CON1
IR-Transmitters
GP1UD26XK
R14
49.9
R11
49.9
RCT
R+
TCT
T+
Earth
RJ-45 connector
Ethernet
connection
2
U4
80
79
78
77
76
75
74
73
72
71
70
69
68
67
66
65
64
63
62
61
11
10
9
8
7
6
1
2
3
C20
47u
R9
1k
PJ6/ KWJ6/ IIC_SDA
PJ7/ KWJ7/ IIC_SCL
PT4 TIM_IOC4
PT5 TIM_IOC5
PT6 TIM_IOC6
PT7 TIM_IOC7
VDD1
VSS1
VSSA
VRL
VRH
VDDA
PAD7/ AN7
PAD6/ AN6
PAD5/ AN5
PAD4/ AN4
PAD3/ AN3
PAD2/ AN2
PAD1/ AN1
PAD0/ AN0
GND
RES
ANT
ANT
CP
+5V
LED
D0
D1
+/FUT
P23
R25
47
0.22
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
1
2
3
4
5
LED
SW4
SCI0_RXD/PS0
SCI0_TXD/PS1
SCI1_RXD/PS2
SCI1_TXD/PS3
SPI_MISO/PS4
SPI_MOSI/PS5
SPI_SCK/PS6
SPI_SS/PS7
ECLK/PE4
VSSX2
VDDX2
Reset
VDDPLL
XFC
VSSPLL
EXTAL
XTAL
TEST
IRQ/PE1
XIRQ/PE0
ID-12
3.3V
C13
D1
C1
100uF
3.3V
CON6
RFID-reader
T1
ECE 477 Final Report
Spring 2008
Appendix D: PCB Layout Top and Bottom Copper
Figure D.1 – Printed Circuit Board Layout Top Copper
D-1
ECE 477 Final Report
Spring 2008
Figure D.2 - Printed Circuit Board Layout Bottom Copper
D-2
ECE 477 Final Report
Spring 2008
Appendix E: Parts List Spreadsheet
Vendor
Manufacturer
Part No.
Freescale
Freescale
MC9S12NE64VTUE
Digi-Key
Vishay
Semiconductor
ID Innovations
ID Innovations
TSAL7600
SparkFun
SparkFun
SparkFun
X10
X10
X10
X10
Digi-Key
Digi-Key
ID Innovations
X10
X10
X10
X10
Fairchild
Semiconductor
ROHM
Digi-Key
Digi-Key
Yageo
Yageo
Digi-Key
Digi-Key
Digi-Key
Digi-Key
Digi-Key
Digi-Key
Digi-Key
Digi-Key
Digi-Key
Digi-Key
Digi-Key
Digi-Key
Digi-Key
Panasonic
Rohm
YAGEO
Rohm
Rohm
Rohm
Rohm
Vishay
AVX
TDK Corporation
Yageo
AVX Corporation
AVX Corporation
ID-12 RFID-reader
ID-12 RFID-reader
Breakout
RFID-Tag 125kHz
X10 Mini Controller
Lamp Module
Appliance Module
Universal Remote
TIP120
RHM12ICT-ND
311-1.00KFRCT-ND
9T12062A49R9BAHF
T-ND
P604FCT-ND
RHM2.20KFTR-ND
311-10.0MFRCT-ND
RHM1.50kFTR-ND
RHM10.0KFTR-ND
RHM47.0FTR-ND
RHM12.0KFTR-ND
4238PHTB-ND
478-1542-2-ND
445-1374-1-ND
311-1167-2-ND
478-3798-ND
E-1
12065A150KAT2AND
Description
16-bit microcontroller with embedded
ethernet
Emitter IR 5MM HI EFF 950NM
Unit
Qty
Cost
$9.84
4
Total Cost
$39.36
$0.445
15
$6.68
$29.95
$0.95
4
2
$119.80
$1.90
$1.95
$12.99
$12.99
$13.99
$49.99
$0.56
4
1
1
1
1
2
$7.80
$12.99
$12.99
$13.99
$49.99
$1.12
12 ohm Resistor
$.20
20
$4.00
1k
49.9
$.08
$.13
2
4
$.16
$.52
604 ohm Resistor
2.2k
10M ohm Resistor
1.5k ohm Resistor
10k ohm Resistor
47 ohm Resistor
12k ohm Resistor
100uF Capacitor
.01uF Capacitor
4700pF Capacitor
470pF Capacitor
.22uF Capacitor
15pF Capacitor
$.02
$.04
$.12
$.24
$.01
$.01
$.04
$.96
$.05
$.10
$.02
$.21
$.22
10
1
10
1
2
1
1
3
1
10
1
10
2
$.20
$.04
$1.20
$.24
$.02
$.01
$.04
$2.88
$.05
$1.00
$.02
$2.10
$.44
RFID reader
2mm to .1” pin spacing converter for
RFID Reader ID 12
RFID Tag
X10 IR control module
Lamp Module
Appliance Module
Darlington Transistor
ECE 477 Final Report
Vendor
Digi-Key
Digi-Key
Digi-Key
Digi-Key
Digi-Key
Digi-Key
Digi-Key
Digi-Key
Spring 2008
Manufacturer
Part No.
Description
Unit
Qty
Cost
$.58
3
$.31
10
$0.63
2
Vishay
KEMET
Citizen America
Corporation
Fairchild
Semiconductor
National
Semiconductor
Sharp
Microelectronics
Panasonic
Sharp
Microelectronics
4313PHTB-ND
399-1250-1-ND
300-8513-ND
47uF Capacitor
.1uF Capacitor
25 MHz Oscillator
2N3904
Switching Transistor
$0.19
3
$.57
LM1117T-3.3
5V to 3.3V Voltage Regulator
$1.66
4
$6.64
GP1UD26XK
IR Receiver
P12354S-ND
732-1649-ND
Pushbutton
RJ-45 Connector
E-2
$1.74
$3.10
$1.26
1
$1.82
$9.66
TOTAL
Table E.1 – Parts List
Total Cost
2
2
$3.64
$19.32
$319.55
ECE 477 Final Report
Spring 2008
Appendix F: Software Listing
/** ###################################################################
**
Filename : Events.C
**
Project
: LED_Test
**
Processor : MC9S12NE64CFU
**
Beantype : Events
**
Version
: Driver 01.04
**
Compiler : CodeWarrior HC12 C Compiler
**
Date/Time : 4/4/2008, 5:42 PM
**
Abstract :
**
This events file contains interrupts that fulfill two
**
main purposes. The first of these is SCI0_RxChar. This
**
function is called whenever the RFID reader sends a
**
character. The other function is the TIM interrupt. This
**
function is called every 12.5 ms. When the oscillate flag
**
is asserted it toggles the IROut pin at 40KHz in order to
**
successfully generate the IR code.
**
**
Contents :
**
SCI0_OnError - void SCI0_OnError(void);
**
SCI0_OnRxChar - void SCI0_OnRxChar(void);
**
SCI0_OnTxChar - void SCI0_OnTxChar(void);
**
**
(c) Copyright UNIS, spol. s r.o. 1997-2006
**
UNIS, spol. s r.o.
**
Jundrovska 33
**
624 00 Brno
**
Czech Republic
**
http
: www.processorexpert.com
**
mail
: info@processorexpert.com
** ###################################################################*/
/* MODULE Events */
#include "Cpu.h"
#include "Events.h"
#pragma CODE_SEG DEFAULT
/*
** ===================================================================
**
Event
: SCI0_OnError (module Events)
**
**
From bean
: SCI0 [AsynchroSerial]
**
Description :
**
This event is called when a channel error (not the error
**
returned by a given method) occurs. The errors can be
**
read using <GetError> method.
**
The event is available only when the <Interrupt
**
service/event> property is enabled.
**
Parameters : None
**
Returns
: Nothing
** ===================================================================
*/
void SCI0_OnError(void)
{
F-1
ECE 477 Final Report
Spring 2008
/* Write your code here ... */
}
/*
** ===================================================================
**
Event
: SCI0_OnRxChar (module Events)
**
**
From bean
: SCI0 [AsynchroSerial]
**
Description :
**
This event is called after a correct character is
**
received.
**
The event is available only when the <Interrupt
**
service/event> property is enabled and either the
**
<Receiver> property is enabled or the <SCI output mode>
**
property (if supported) is set to Single-wire mode.
**
Parameters : None
**
Returns
: Nothing
** ===================================================================
*/
//
//
//
//
This event is called when SCI0 receives a character which means the
RFID reader is reading a card. Once all 15 bits of the card have
been read a flag is asserted signifying that a new card has been
received.
void SCI0_OnRxChar(void)
{
/* Write your code here ... */
SCI0_TComData test;
extern char RecentTag[];
extern int ByteCount;
extern bool TagComplete;
SCI0_RecvChar(&test);
//SCI1_SendChar(test);
if(ByteCount < 15)
{
RecentTag[ByteCount] = test;
ByteCount++;
TagComplete = 0;
} else {
TagComplete = 1;
ByteCount = 0;
}
}
/*
** ===================================================================
**
Event
: SCI1_OnError (module Events)
**
**
From bean
: SCI1 [AsynchroSerial]
**
Description :
**
This event is called when a channel error (not the error
**
returned by a given method) occurs. The errors can be
**
read using <GetError> method.
**
The event is available only when the <Interrupt
F-2
ECE 477 Final Report
Spring 2008
**
service/event> property is enabled.
**
Parameters : None
**
Returns
: Nothing
** ===================================================================
*/
void SCI1_OnError(void)
{
/* Write your code here ... */
}
/*
** ===================================================================
**
Event
: SCI1_OnTxChar (module Events)
**
**
From bean
: SCI1 [AsynchroSerial]
**
Description :
**
This event is called after a character is transmitted.
**
Parameters : None
**
Returns
: Nothing
** ===================================================================
*/
void SCI1_OnTxChar(void)
{
/* Write your code here ... */
}
/*
** ===================================================================
**
Event
: TI1_OnInterrupt (module Events)
**
**
From bean
: TI1 [TimerInt]
**
Description :
**
When a timer interrupt occurs this event is called (only
**
when the bean is enabled - "Enable" and the events are
**
enabled - "EnableEvent").
**
Parameters : None
**
Returns
: Nothing
** ===================================================================
*/
// This interrupt was used to succesfully oscillate the output of the
// IR transmitter at 40KHz.
void TI1_OnInterrupt(void)
{
extern bool Oscillate;
/* Write your code here ... */
if(Oscillate){
if(IROut_GetVal()){
IROut_PutVal(FALSE);
} else{
IROut_PutVal(TRUE);
}
}
}
F-3
ECE 477 Final Report
Spring 2008
/* END Events */
/*
** ###################################################################
**
**
This file was created by UNIS Processor Expert 2.97 [03.83]
**
for the Freescale HCS12 series of microcontrollers.
**
** ###################################################################
*/
/** ###################################################################
**
Filename : LED_Test.C
**
Project
: LED_Test
**
Processor : MC9S12NE64CFU
**
Version
: Driver 01.12
**
Compiler : CodeWarrior HC12 C Compiler
**
Date/Time : 3/18/2008, 3:37 PM
**
Abstract :
**
This file contains the main function, SendIRCode, GetIRCode,
**
and some debugging functions. The flow of the software occurs
**
within this file. Descriptions about each function have been
**
listed directly above them.
**
**
Settings :
**
Contents :
**
No public methods
**
**
(c) Copyr ight UNIS, spol. s r.o. 1997-2006
**
UNIS, spol. s r.o.
**
Jundrovska 33
**
624 00 Brno
**
Czech Republic
**
http
: www.processorexpert.com
**
mail
: info@processorexpert.com
** ###################################################################*/
/* MODULE LED_Test */
/* Including used modules for compiling procedure */
#include "Cpu.h"
#include "Events.h"
#include "SCI0.h"
#include "IRRecv.h"
#include "PB2.h"
#include "PB3.h"
#include "TI1.h"
#include "Green.h"
#include "Red.h"
#include "IROut.h"
#include "FC321.h"
/* Include shared modules, which are used for whole project */
#include "PE_Types.h"
#include "PE_Error.h"
#include "PE_Const.h"
#include "IO_Map.h"
F-4
ECE 477 Final Report
Spring 2008
// Global Variable Declarations
char RecentTag[20];
int ByteCount = 0;
bool TagComplete = FALSE;
bool Flag1;
bool Flag2;
bool Flag3;
bool Flag4;
char Tag1[13] = "0E008E77B542";
char Tag2[13] = "0E008E5DF22F";
char Tag3[13] = "0E008E880B03";
char Tag4[13] = "0E008E830E0D";
bool TV1 = TRUE;
bool TV2 = TRUE;
bool TV3 = FALSE;
bool TV4 = TRUE;
int User_Chan1[3] = {0,0,5};
int User_Chan2[3] = {0,4,2};
int User_Chan3[3] = {0,6,7};
int User_Chan4[3] = {1,1,2};
word TimeArray1[27];
word TimeArray2[27];
word IRCode[27];
word TVCodes[11][27];
bool IRPrev = TRUE;
bool IRCurr = TRUE;
bool IRDone1 = FALSE;
bool IRDone2 = FALSE;
bool IRMatch = FALSE;
bool GetIR = FALSE;
bool Oscillate = FALSE;
// This function was a debugging function that was used to print
// to the hyper terminal. All print statements have been commented
// out, but they still remain to show the debugging process.
void print(char *string) {
int Counter = 0;
SCI1_TComData test;
while(string[Counter] != '\0') {
test = string[Counter];
SCI1_SendChar(test);
while(!SCI1_GetTxComplete());
Counter++;
}
}
//
//
//
//
This function converts a integer to a string. This function was
taken from the Freescale forums as a user so helpfully offered it.
This was used in the debugging process in conjunction with the print
function in order to view recorded times.
/*Usage Number to convert, num Digits, what spot Decimal is in, string to store it */
/* Integer to ASCII */
F-5
ECE 477 Final Report
Spring 2008
void Itoa(int Number, char Digits, char Decimal, char *String){
/* Get starting position in string array */
char *PositionSave, *Position = String + Digits;
/* Negative flag */
char NegativeFlag = FALSE;
/* Charactor buffer */
char Chr;
/* Working UINT16 */
unsigned int uInteger;
/* Loop index */
int Index;
/* Number of digits converted */
int DigitCount = 0;
/* Make sure we are converting more than one digit */
if(!Digits)
return;
/* Are we working with a negative number— */
if (Number < 0) {
/* It is a negative number */
NegativeFlag = TRUE;
/* Remove the sign bit from the integer */
uInteger = ((unsigned int)(-(1 + Number))) + 1;
} else {
/* Not a negative number */
uInteger = Number;
}
/* NULL terminate the string */
*Position = 0;
/* Do the conversion */
do {
/* Decrement the digits counter */
Digits--;
/* Get the ASCII charactor */
*--Position = '0' + (uInteger % 10);
/* Divide by 10 */
uInteger /= 10;
/* Have we reached the end of the number– */
if(!uInteger)
break;
/* Increment the digit counter */
DigitCount++;
} while (Digits);
/* Do we need to add a decimal point˜ */
if(Decimal && Digits) {
/* Remove another digit position */
Digits--;
/* Do we have enough space for a leading 0™ */
if(Digits && (DigitCount < Decimal)){
for(Index = Decimal - DigitCount; Index > 0; Index--) {
*--Position = '0';
DigitCount++;
F-6
ECE 477 Final Report
Spring 2008
Digits--;
if(!Digits)
break;
}
}
/* Decrement and save the pointer */
Position--;
PositionSave = Position;
/* Move the charactors */
for(Index = DigitCount - Decimal; Index >= 0; Index--) {
Chr = Position[1];
Position[0] = Chr;
Position++;
}
/* Insert the decimal point */
*Position = '.';
/* Restore the pointer */
Position = PositionSave;
}
/* Do we need to add the negative sign? */
if (NegativeFlag && Digits) {
/* Add the negative charator */
*--Position = '-';
/* Reduce the digit count */
Digits--;
}
/* Do we need to pad any charactor positions? */
for(Index = Digits; Index != 0; Index--)
*--Position = ' ';
}
//
//
//
//
This function is called after an RFID tag is
scanned. It compares the tag to the four tags
stored in memory, and asserts a flag if the tag
is a match.
void TagCompare(){
int Counter = 0;
Flag1 = 1;
Flag2 = 1;
Flag3 = 1;
Flag4 = 1;
while(Counter < 12){
if(RecentTag[Counter+1] != Tag1[Counter]) {
Flag1 = 0;
}
if(RecentTag[Counter+1] != Tag2[Counter]) {
Flag2 = 0;
}
if(RecentTag[Counter+1] != Tag3[Counter]) {
Flag3 = 0;
}
F-7
ECE 477 Final Report
Spring 2008
if(RecentTag[Counter+1] != Tag4[Counter]) {
Flag4 = 0;
}
Counter++;
}
}
//
//
//
//
//
//
//
This function is the IR Receiving function. The
Sony remote we were working with changed from low
to high or high to low 26 different times. These
times are recorded. After it has received two codes
it compares them, and if they are a match that is
the correct code. This comparison is done in order
to eliminate noise.
void Get_IRCode(){
word Time;
int Cnt = 0;
char string[16];
IRDone1 = FALSE;
IRDone2 = FALSE;
IRMatch = TRUE;
Red_PutVal(TRUE);
//print("Getting IR Code\n\r");
while(IRDone1 == FALSE){
//IR Receiving Code
IRCurr = IRRecv_GetVal();
if(Cnt == 0){
FC321_Reset();
}
if(IRCurr != IRPrev){
IRPrev = IRCurr;
FC321_GetTimeUS(&Time);
if(Time > 5000){
Cnt = 0;
}
TimeArray1[Cnt] = Time;
FC321_Reset();
Cnt++;
if(Cnt == 26){
Cnt = 0;
IRDone1 = TRUE;
//print("IRDone1\n\r");
}
}
}
//print("Got Code 1\n\r");
while((IRDone2 == FALSE) && (IRDone1 == TRUE)){
//IR Receiving Code
IRCurr = IRRecv_GetVal();
//IROut_PutVal(IRRecv_GetVal());
if(Cnt == 0){
FC321_Reset();
F-8
ECE 477 Final Report
Spring 2008
}
if(IRCurr != IRPrev){
IRPrev = IRCurr;
FC321_GetTimeUS(&Time);
if(Time > 5000){
Cnt = 0;
}
TimeArray2[Cnt] = Time;
FC321_Reset();
Cnt++;
if(Cnt == 26){
Cnt = 0;
IRDone2 = TRUE;
//print("IRDone2\n\r");
}
}
}
//This prints out each of the time values for debugging
/*
Cnt = 0;
print("Comparing Codes\n\r");
while(Cnt < 26){
print("Printing Time ");
Itoa(Cnt,2,0,&string);
print(string);
print("\n\r");
print("Time Array 1");
Itoa(TimeArray1[Cnt],7,0,&string);
print(string);
print("\n\r");
print("Time Array 2");
Itoa(TimeArray2[Cnt],7,0,&string);
print(string);
print("\n\r");
Cnt++;
} */
Cnt = 0;
//This compares the 2 stored codes to determine if they match to filter out noise
while(Cnt < 26){
if((TimeArray2[Cnt] != (TimeArray1[Cnt]))){// || (TimeArray2[Cnt] <
(TimeArray1[Cnt] - 50))){
IRMatch = FALSE;
}
Cnt++;
}
//print("Done Comparing\n\r");
}
//
//
//
//
//
//
This function sends out the IR code that is stored within the variable
IRCode. When the signal is false, the output remains at 0. When the
signal is true, the output oscillates at a frequency of 40KHz. This
is done within the events file by toggling the pin every time a TIM
interrupt happens with the TIM scheduled to happen at an interrupt
rate of 12.5 ms which equates to 40KHz.
F-9
ECE 477 Final Report
Spring 2008
void SendIRCode(){
int cnt=0;
word Time;
char string[16];
bool IRLastVal = FALSE;
Oscillate = FALSE;
FC321_Reset();
while(cnt < 26){
if(cnt == 0){
//print("Reset\n\r");
FC321_Reset();
}
FC321_GetTimeUS(&Time);
/*Itoa(Time,7,0,&string);
print(string);
print("\n\r");*/
if(Time >= IRCode[cnt]){
if(IRLastVal == TRUE){
Oscillate = FALSE;
IROut_PutVal(FALSE);
IRLastVal = FALSE;
} else{
//IROut_PutVal(TRUE);
Oscillate = TRUE;
IRLastVal = TRUE;
}
FC321_Reset();
cnt++;
}else if(Time > 5000){
cnt = 0;
//print("Time > 5000 \n\r");
}
}
Oscillate = FALSE;
IROut_PutVal(FALSE);
//Pause for 8 ms
FC321_Reset();
FC321_GetTimeUS(&Time);
while(Time < 8000){
FC321_GetTimeUS(&Time);
}
}
// This is the main function that controls the overall
// behavior of the software.
void main(void)
{
/* Write your local variable definition here */
int i=0;
char string[16];
F-10
ECE 477 Final Report
Spring 2008
word Time;
int CodeCount = 0;
/*** Processor Expert internal initialization. DON'T REMOVE THIS CODE!!! ***/
PE_low_level_init();
/*** End of Processor Expert internal initialization.
***/
/* Write your code here */
//print("\n\rSTART\n\n\r");
// Restart the timer and ensure that the IROut pin is FALSE
FC321_Reset();
IROut_PutVal(FALSE);
// Infinite loop so that the code continuously runs.
for(;;){
// This section is the Tag Recognition and looks
// up the settings associated with each tag.
if(TagComplete){
TagCompare();
//print("User Entered Room\n\r");
if(Flag1){
//print("User 1\n\r");
//print("TV On: ");
if(TV1){
FC321_Reset();
Time = 0;
FC321_GetTimeMS(&Time);
//print("Yes\n\r");
//print("Channel Number: ");
//Itoa(User_Chan1[0],1,0,&string);
//print(string);
//Itoa(User_Chan1[1],1,0,&string);
//print(string);
//Itoa(User_Chan1[2],1,0,&string);
//print(string);
//print("\n\n\r");
/*Red_PutVal(TRUE);
while(Time < 1000){
FC321_GetTimeMS(&Time);
}
Red_PutVal(FALSE);*/
//If the TV is scheduled to be on this section of
//code turns on the TV and sends out the channel.
//Sets IRCode = Power Code
for(i=0;i<27;i++){
IRCode[i]=TVCodes[0][i];
}
//Send Power Code
for(i=0;i<10;i++){
SendIRCode();
}
//Wait 1 Sec
FC321_Reset();
F-11
ECE 477 Final Report
Spring 2008
FC321_GetTimeMS(&Time);
while(Time < 1000){
FC321_GetTimeMS(&Time);
}
//Send Code 1
for(i=0;i<27;i++){
IRCode[i] = TVCodes[User_Chan1[0]+1][i];
}
for(i=0;i<10;i++){
SendIRCode();
}
//Wait 1 Sec
FC321_Reset();
FC321_GetTimeMS(&Time);
while(Time < 1000){
FC321_GetTimeMS(&Time);
}
//Send Code 2
for(i=0;i<27;i++){
IRCode[i] = TVCodes[User_Chan1[1]+1][i];
}
for(i=0;i<10;i++){
SendIRCode();
}
//Wait 1 Sec
FC321_Reset();
FC321_GetTimeMS(&Time);
while(Time < 1000){
FC321_GetTimeMS(&Time);
}
//Send Code 3
for(i=0;i<27;i++){
IRCode[i] = TVCodes[User_Chan1[2]+1][i];
}
for(i=0;i<10;i++){
SendIRCode();
}
} else{
//This section of the code is reserved
//for if the TV is not supposed to be on.
//print("No\n\n\r");
}
} else if(Flag2){
//print("User 2\n\r");
//print("TV On: ");
if(TV2){
FC321_Reset();
Time = 0;
FC321_GetTimeMS(&Time);
//print("Yes\n\r");
//print("Channel Number: ");
//Itoa(User_Chan2[0],1,0,&string);
//print(string);
//Itoa(User_Chan2[1],1,0,&string);
//print(string);
//Itoa(User_Chan2[2],1,0,&string);
F-12
ECE 477 Final Report
Spring 2008
//print(string);
//print("\n\n\r");
/*Red_PutVal(TRUE);
while(Time < 1000){
FC321_GetTimeMS(&Time);
}
Red_PutVal(FALSE);*/
//Sets IRCode = Power Code
for(i=0;i<27;i++){
IRCode[i]=TVCodes[0][i];
}
//Send Power Code
for(i=0;i<10;i++){
SendIRCode();
}
//Wait 1 Sec
FC321_Reset();
FC321_GetTimeMS(&Time);
while(Time < 1000){
FC321_GetTimeMS(&Time);
}
//Send Code 1
for(i=0;i<27;i++){
IRCode[i] = TVCodes[User_Chan2[0]+1][i];
}
for(i=0;i<10;i++){
SendIRCode();
}
//Wait 1 Sec
FC321_Reset();
FC321_GetTimeMS(&Time);
while(Time < 1000){
FC321_GetTimeMS(&Time);
}
//Send Code 2
for(i=0;i<27;i++){
IRCode[i] = TVCodes[User_Chan2[1]+1][i];
}
for(i=0;i<10;i++){
SendIRCode();
}
//Wait 1 Sec
FC321_Reset();
FC321_GetTimeMS(&Time);
while(Time < 1000){
FC321_GetTimeMS(&Time);
}
//Send Code 3
for(i=0;i<27;i++){
IRCode[i] = TVCodes[User_Chan2[2]+1][i];
}
for(i=0;i<10;i++){
SendIRCode();
}
} else{
//print("No\n\n\r");
}
F-13
ECE 477 Final Report
Spring 2008
}else if(Flag3){
//print("User 3\n\r");
//print("TV On: ");
if(TV3){
FC321_Reset();
Time = 0;
FC321_GetTimeMS(&Time);
//print("Yes\n\r");
//print("Channel Number: ");
//Itoa(User_Chan3[0],1,0,&string);
//print(string);
//Itoa(User_Chan3[1],1,0,&string);
//print(string);
//Itoa(User_Chan3[2],1,0,&string);
//print(string);
//print("\n\n\r");
/*Red_PutVal(TRUE);
while(Time < 1000){
FC321_GetTimeMS(&Time);
}
Red_PutVal(FALSE);*/
//Sets IRCode = Power Code
for(i=0;i<27;i++){
IRCode[i]=TVCodes[0][i];
}
//Send Power Code
for(i=0;i<10;i++){
SendIRCode();
}
//Wait 1 Sec
FC321_Reset();
FC321_GetTimeMS(&Time);
while(Time < 1000){
FC321_GetTimeMS(&Time);
}
//Send Code 1
for(i=0;i<27;i++){
IRCode[i] = TVCodes[User_Chan3[0]+1][i];
}
for(i=0;i<10;i++){
SendIRCode();
}
//Wait 1 Sec
FC321_Reset();
FC321_GetTimeMS(&Time);
while(Time < 1000){
FC321_GetTimeMS(&Time);
}
//Send Code 2
for(i=0;i<27;i++){
IRCode[i] = TVCodes[(User_Chan3[1]+1)][i];
}
for(i=0;i<10;i++){
SendIRCode();
}
//Wait 1 Sec
FC321_Reset();
F-14
ECE 477 Final Report
Spring 2008
FC321_GetTimeMS(&Time);
while(Time < 1000){
FC321_GetTimeMS(&Time);
}
//Send Code 3
for(i=0;i<27;i++){
IRCode[i] = TVCodes[(User_Chan3[2]+1)][i];
}
for(i=0;i<10;i++){
SendIRCode();
}
} else{
//print("No\n\n\r");
}
} else if(Flag4){
//print("User 4\n\r");
//print("TV On: ");
if(TV4){
FC321_Reset();
Time = 0;
FC321_GetTimeMS(&Time);
//print("Yes\n\r");
//print("Channel Number: ");
//Itoa(User_Chan4[0],1,0,&string);
//print(string);
//Itoa(User_Chan4[1],1,0,&string);
//print(string);
//Itoa(User_Chan4[2],1,0,&string);
//print(string);
//print("\n\n\r");
/*Red_PutVal(TRUE);
while(Time < 1000){
FC321_GetTimeMS(&Time);
}
Red_PutVal(FALSE);*/
//Sets IRCode = Power Code
for(i=0;i<27;i++){
IRCode[i]=TVCodes[0][i];
}
//Send Power Code
for(i=0;i<10;i++){
SendIRCode();
}
//Wait 1 Sec
FC321_Reset();
FC321_GetTimeMS(&Time);
while(Time < 1000){
FC321_GetTimeMS(&Time);
}
//Send Code 1
for(i=0;i<27;i++){
IRCode[i] = TVCodes[User_Chan4[0]+1][i];
}
for(i=0;i<10;i++){
SendIRCode();
}
//Wait 1 Sec
F-15
ECE 477 Final Report
Spring 2008
FC321_Reset();
FC321_GetTimeMS(&Time);
while(Time < 1000){
FC321_GetTimeMS(&Time);
}
//Send Code 2
for(i=0;i<27;i++){
IRCode[i] = TVCodes[User_Chan4[1]+1][i];
}
for(i=0;i<10;i++){
SendIRCode();
}
//Wait 1 Sec
FC321_Reset();
FC321_GetTimeMS(&Time);
while(Time < 1000){
FC321_GetTimeMS(&Time);
}
//Send Code 3
for(i=0;i<27;i++){
IRCode[i] = TVCodes[User_Chan4[2]+1][i];
}
for(i=0;i<10;i++){
SendIRCode();
}
} else{
//print("No\n\n\r");
}
}else{
//print(&RecentTag);
//print("\n\n\r");
}
TagComplete = 0;
}
// This happens when the pushbutton is pressed
// to start the IR learning.
if(PB2_GetVal()) {
//print("Waiting for IR Code\n\r");
CodeCount = 0;
GetIR = TRUE;
Red_PutVal(TRUE);
Get_IRCode();
}
//This was used during the testing phase to
//send out the most recently received IRCode.
if(PB3_GetVal()){
//print("Sending IR Code\n\r");
i = 0;
/*print("Printing Transmission Times ");
print("\n\r");
while(i < 27){
print("IRCode Array Time ");
Itoa(i,2,0,&string);
F-16
ECE 477 Final Report
Spring 2008
print(string);
print(": ");
Itoa(IRCode[i],7,0,&string);
print(string);
print("\n\r");
i++;
}*/
SendIRCode();
}
//This is the comparison of the IR Code
//in order to avoid a recursive function.
if((IRMatch==FALSE)&&(GetIR == TRUE)){
Get_IRCode();
}else if((IRMatch==TRUE)&&(GetIR == TRUE)){
//This happens when the IR Code has been
//learned. When the IR Code is attempting
//to be learned the Red LED is illuminated
//Once a match has occured the Green LED
//is illuminated for 1 sec. This repeats
//11 times for Power then 0-9.
//print("MATCH!!!!!!!!!!!\n\r");
FC321_Reset();
FC321_GetTimeMS(&Time);
Red_PutVal(FALSE);
Green_PutVal(TRUE);
while(Time < 1000){
FC321_GetTimeMS(&Time);
}
Green_PutVal(FALSE);
i = 0;
while(i < 27){
TVCodes[CodeCount][i] = TimeArray1[i];
i++;
}
CodeCount++;
//If all codes have been received exit otherwise get next code
if(CodeCount == 11){
GetIR = FALSE;
}else{
Get_IRCode();
}
}
}
/*** Processor Expert end of main routine. DON'T MODIFY THIS CODE!!! ***/
for(;;){}
/*** Processor Expert end of main routine. DON'T WRITE CODE BELOW!!! ***/
} /*** End of main routine. DO NOT MODIFY THIS TEXT!!! ***/
/* END LED_Test */
/*
F-17
ECE 477 Final Report
Spring 2008
** ###################################################################
**
**
This file was created by UNIS Processor Expert 2.97 [03.83]
**
for the Freescale HCS12 series of microcontrollers.
**
** ###################################################################
*/
F-18
ECE 477 Final Report
Spring 2008
Appendix G: FMECA Worksheet
Table G.1 – Microcontroller Circuitry FEMCA
Failure
Failure Mode
Possible Causes
No.
A1
Microcontroller
Supply voltage
will not receive
wrong, Clock
data
circuitry failure,
burnt out pins
A2
Microcontroller
will not transmit
data
Supply voltage
wrong, Clock
circuitry failure,
burnt out pins
Failure Effects
Unable to update
IR codes, settings,
or recognize a
user
Unable to
transmit website
information or to
IR transmitters
G-1
Method of
Detection
Observation
Criticality
Low
Observation
Low
Remarks
This failure wouldn’t
allow the
microcontroller to
receive data from the IR
receiver, Ethernet
controller, or RFID
reader.
This failure would
cause the website to be
inoperable, and
wouldn’t allow the IR
transmitters to transmit.
ECE 477 Final Report
Spring 2008
Table G.2 – Power Circuitry FEMCA
Failure
Failure Mode
Possible Causes
No.
B1
V = 0V
Regulator failure,
shorted capacitor,
shorted input power
supply
Failure Effects
No operation at
all
Method of
Detection
Observation
Criticality
Remarks
Low
This failure would
completely halt all
operations, and nothing
would happen.
B2
V > 3.3V for
Microcontroller
or V > 5V for
RFID Reader
Regulator failure
Potential
overheating
hazard
Observation
High
This failure could
potentially result in
overheating causing
burns or potentially fire.
B3
Voltage is erratic
Regulator failure
Potential for over
voltage or under
voltage
Observation
High
This failure could result
in a brown out or could
result in overheating.
G-2
ECE 477 Final Report
Spring 2008
Table G.3 – Peripheral Circuitry FEMCA
Failure
Failure Mode
Possible Causes
No.
C1
RFID Scanner
Improper input
fails
voltage, RFID
Scanner failure,
shorted capacitor
C2
One or more IR
transmitter fail
C3
Ethernet
Controller fails
C4
Microcontroller fails
to transmit,
Transistor failure,
resistor failure, IR
transmitter burnt out
Microcontroller fails
to transmit, capacitor
or resistor failure,
incorrect voltage,
RJ45 failure
IR receiver failure Microcontroller fails
to receive input,
capacitor or resistor
short, incorrect
voltage, IR receiver
failure
Failure Effects
Method of
Detection
Observation
Low
This failure would
cause the device to sit
idle, and not perform
any meaningful task.
Not all of the IR
transmitters
transmitting
correctly
Observation
Low
Unable to send or
receive signals
from the internet
Observation
Low
Unable to receive
IR codes
Observation
Low
This failure could cause
the devices to receive
the wrong IR codes or
could cause some or all
the devices to be out of
range of the other
transmitters.
This failure would
result in the website not
functioning thus not
allowing the user to
update settings.
This failure would
result in the device
being unable to learn
new IR codes.
Inability to
recognize user
G-3
Criticality
Remarks