EE 477 Final Report - Purdue University
ECE 477 Final Report ( Spring 2008
Team 9 ( myRoom
[pic]
Andrew Hampton, Zach Beechler, Laurie Duncan, Gesine Hinterwalder
Team Members:
#1: ____________________________ Signature: ____________________ Date: _________
#2: ____________________________ Signature: ____________________ Date: _________
#3: ____________________________ Signature: ____________________ Date: _________
#4: ____________________________ Signature: ____________________ Date: _________
|CRITERION |SCORE |MPY |PTS |
|Technical content |0 1 2 3 4 5 6 7 8 9 10 |3 | |
|Design documentation |0 1 2 3 4 5 6 7 8 9 10 |3 | |
|Technical writing style |0 1 2 3 4 5 6 7 8 9 10 |2 | |
|Contributions |0 1 2 3 4 5 6 7 8 9 10 |1 | |
|Editing |0 1 2 3 4 5 6 7 8 9 10 |1 | |
|Comments: |TOTAL | |
| |
TABLE OF CONTENTS
|Abstract |1 |
| 1.0 Project Overview and Block Diagram |1 |
| 2.0 Team Success Criteria and Fulfillment |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 |
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. Project Overview and Block Diagram
[pic]
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 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.
[pic]
Figure 1.2 – Block Diagram of myRoom
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 on-chip Ethernet component, where it hosts the myRoom website for user preference control.
2. Team Success Criteria and Fulfillment
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.
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.
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.
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 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.
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.
Constraint Analysis and Component Selection
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.
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 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. 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.
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.
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 need for such a device was situational. If an on-chip Ethernet adapter was not available, an off-chip version would have been required.
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.
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.
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.
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 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.
10. Summary
The major design components chosen, the Freescale MC9S12NE64VTUE microcontroller, the RFID Reader ID-12, the GP1UD26XK IR receiver, and the TSAL7600 IR 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.
3. Patent Liability Analysis
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.
2. Results of Patent and Product Search
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 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.
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.
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
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.
3. Analysis of Patent Liability
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 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. 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.
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.
4. Reliability and Safety Analysis
1. 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.
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 [pic] Failures/106 Hours. The first parameter for the equation,[pic], 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,[pic], 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 [pic]to be equal to 3.1. The next parameter to evaluate is[pic], which is the package failure rate. Provided that the packaging is non-hermetic, then [pic] will be equal to 0.041 because the version of the MC9S12NE64 that is being used has 80 pins. The environment factor, [pic], 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,[pic], is assumed to be 10 as the screening levels is unsure, and it is a commercial product. The final parameter is the learning factor,[pic], 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 [pic] = 9.5 Failures/106 Hours. This failure rate results in a mean time to failure, MTTF, of 12.0 years.
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 [pic] Failures/106 Hours. The value of the Die Complexity Failure rate,[pic], 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, [pic]to be equal to 180 due to it being linear MOS. The package failure rate,[pic], assuming that it is non-hermetic would be 0.0012 due to the presence of three pins. The environmental factor,[pic], would be 2.0 which is the same as the microcontroller. The quality factor,[pic], 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,[pic], 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 [pic] = 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 ID-Innovations. 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, [pic], 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 [pic] will be used. TC is assumed to be 45°C due to the fixed ground environment. The junction-to-case thermal resistance,[pic], 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, [pic]to be equal to 0.71. The package failure rate,[pic], assuming that it is non-hermetic would be 0.0053 due to the presence of eleven pins. The environmental factor,[pic], would once again be 2.0. The quality factor,[pic], remains at 10 as this is also a commercial product. The final parameter for this component is once again the learning factor,[pic], which would be 1.0 because the device has been manufactured for longer than two years. This results in a final failure rate of [pic] = 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 [pic] ( 10-9 Failures/Hour in order to be acceptable. The other criticality level is Low. This level indicates that the system may have partial or total failure resulting in inconvenience to the user. An acceptable failure rate for this type of failure is if [pic] ( 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.
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.
5. Ethical and Environmental Impact Analysis
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.
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 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.
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 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.
|Appliance |Typical Wattage |Estimated hours used per |Estimated monthly kWh |
| | |month | |
|TV |200 |183 |36.6 |
|Light |75 |100 |7.5 |
|VCR/DVD |21 |12 |2.5 |
|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 saved |Estimated kWh 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 to a recycle company, such that the user can recycle it for free after use. In order to reduce e-waste 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.
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.
6. Packaging Design Considerations
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 possible, durable to protect the components within, and not inhibitive of the signals that are to be transmitted and received by the system.
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.
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 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.
4. NPS NP 4101
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 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.
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 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.
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. 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.
7. Schematic Design Considerations
1. 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.
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 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.
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.
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.
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.
8. PCB Layout Design Considerations
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.
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 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.
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.
4. PCB Layout Design Considerations - Power Supply
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.
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.
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.
9. Software Design Considerations
1. Introduction
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.
2. Software Design Considerations
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.
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.
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.
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.
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.
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.
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 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.
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.
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 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.
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.
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.
10. 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 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.
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.
References
1] Rabbit Semiconductor, “Rabbit RCM4000 series data sheet”
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.
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: [Accessed: April 3, 2008].
6] “MC9S12NE64V1 Datasheet,” [Online], [cited February 7, 2008], Available at:
7] National Semiconductors, “LM117 800mA Low-Dropout Linear Regulator,” April 2006. [Online]. Available:
[Accessed: April 3, 2008].
8] “ID-12 Datasheet,” [Online datasheet], [cited February 7, 2008], Available at:
9] Cornhusker, “Operating Costs of Household Appliances,” [Online Document], 2002, [accessed April 8, 2008],
10] Wikipedia, “Restriction of Hazardous Substance Directive,” [Online Document], 2008, [accessed April 8, 2008],
11] Advanced Circuits, “RoHS Compliance Printed Circuit Boards,” [Online Document], 2007, [accessed April 8, 2008],
12] EPA, “Electronics Reuse and Recycling,” [Online Document], October 2000, [accessed April 8, 2008],
13] Wikipedia, “Electronic Waste,” [Online Document], 2006, [accessed April 9, 2008],
14] “Access Control Software & Systems – Tensor plc,” [Online document], [cited February 6, 2008], Available at:
15] “NPS – soluzioni per il card management,” [Online document], [cited February 7, 2008], Available at:
16] “ – Cables, Parts & Connectors: Component parts: Project boxes: Project Enclosure,” [Online document], [cited February 7, 2008], Available at:
17] “SparkFun Electronics – RFID Reader ID-12,” [Online document], [cited February 7, 2008], Available at:
18] “SparkFun Electronics – RFID Reader ID-12 Breakout,” [Online document], [cited February 7, 2008], Available at:
19] “IR LED Datasheet”, [Online Document], [Accessed February 14, 2008],
20] “Parts Selection Guide”, [Online Document], [Accessed February 14, 2008],
21] “IR Remote Control Theory”, [Online Document], [Accessed February 14, 2008],
22] “TIP120 datasheet”, [Online Document], [Accessed February 14, 2008],
23] Motorola, “Semiconductor Application Note AN1259,” [Online Document], 1995, [accessed February 22, 2008],
24] D.G. Meyer, “Module 9: PCB Design,” [Online Document], 2007, [accessed February 22, 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 fly-wiring 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 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 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 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.
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 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.
Appendix B: Packaging
[pic]
Figure B.1 – Picture of the completed packaging.
Appendix C: Schematic
[pic]
Figure C.1 – Power Supply Schematic
[pic]
Figure C.2 – Primary Schematic
Appendix D: PCB Layout Top and Bottom Copper
[pic]
Figure D.1 – Printed Circuit Board Layout Top Copper
[pic]
Figure D.2 - Printed Circuit Board Layout Bottom Copper
Appendix E: Parts List Spreadsheet
|Vendor |Manufacturer |Part No. |Description |Unit Cost |Qty |Total Cost |
|Digi-Key |Rohm |RHM47.0FTR-ND |47 ohm Resistor |$.01 |1 |$.01 |
|Digi-Key |Rohm |RHM12.0KFTR-ND |12k ohm Resistor |$.04 |1 |$.04 |
|Digi-Key |Vishay |4238PHTB-ND |100uF Capacitor |$.96 |3 |$2.88 |
|Digi-Key |AVX |478-1542-2-ND |.01uF Capacitor |$.05 |1 |$.05 |
|Digi-Key |TDK Corporation |445-1374-1-ND |4700pF Capacitor |$.10 |10 |$1.00 |
|Digi-Key |Yageo |311-1167-2-ND |470pF Capacitor |$.02 |1 |$.02 |
|Digi-Key |AVX Corporation |478-3798-ND |.22uF Capacitor |$.21 |10 |$2.10 |
|Digi-Key |AVX Corporation |12065A150KAT2A-ND |15pF Capacitor |$.22 |2 |$.44 |
|Vendor |Manufacturer |
Table E.1 – Parts List
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 :
** mail : info@
** ###################################################################*/
/* 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 method.
** The event is available only when the property is enabled.
** Parameters : None
** Returns : Nothing
** ===================================================================
*/
void SCI0_OnError(void)
{
/* 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 property is enabled and either the
** property is enabled or the
** 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 method.
** The event is available only when the 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);
}
}
}
/* 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 :
** mail : info@
** ###################################################################*/
/* 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"
// 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 */
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++;
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;
}
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();
}
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.
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];
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 ................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- final maturity of ee savings bonds
- final maturity date for ee bonds
- calculate ee bond final value
- ee savings bonds final maturity
- final cost report nysed
- purdue university plagiarism checker
- purdue university salaries
- project final report template
- project final summary report template
- final grant report sample
- project management final report example
- project management final report template