EE 477 Final Report
ECE 477 Final Report ( Fall 2008
Team 1 ( SHU: The Running Companion
[pic]
Team Members:
#1: Kathleen Klacik Signature: ____________________ Date: 12/15/08
#2: Brian Baumgartner Signature: ____________________ Date: 12/15/08
#3: Dan Strauss Signature: ____________________ Date: 12/15/08
#4: Kyle Anderson Signature: ____________________ Date: 12/15/08
|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 |3 |
| 3.0 Constraint Analysis and Component Selection |3 |
| 4.0 Patent Liability Analysis |6 |
| 5.0 Reliability and Safety Analysis |10 |
| 6.0 Ethical and Environmental Impact Analysis |14 |
| 7.0 Packaging Design Considerations |18 |
| 8.0 Schematic Design Considerations |21 |
| 9.0 PCB Layout Design Considerations |25 |
|10.0 Software Design Considerations |28 |
|11.0 Version 2 Changes |33 |
|12.0 Summary and Conclusions |34 |
|13.0 References |34 |
|Appendix A: Individual Contributions |A1 |
|Appendix B: Packaging |B1 |
|Appendix C: Schematic |C1 |
|Appendix D: PCB Layout Top and Bottom Copper |D1 |
|Appendix E: Parts List Spreadsheet |E1 |
|Appendix F: Software Listing |F1 |
|Appendix G: FMECA Worksheet |G1 |
Abstract
Mounted on an armband, the SHU Running Companion will track distance run by utilizing GPS. It will record three waypoints and do calculations every ten seconds in order to lower the possibility of inaccuracies due to a runner running in circles and due to the possibility of recording and erroneous waypoint. SHU will have a basic stop watch function as well as a training menu. On the training menu the user will either be able to select a distance he or she would like to run and have SHU alert him or her when the run is complete or just have SHU track the distance he or she has run. It will store statistics such as miles, splits and running speed. This information will be displayed at the user’s request on an LCD screen mounted on the unit. Using SHU the user will be able to review past runs and track training progress over time.
1. Project Overview and Block Diagram
Without our project it is difficult to know the distance one has run in real time. Our project is designed to relay this information to the runner in a more convenient and timely manner due to updates every ten seconds. In addition, our project will allow the runner to track his or her progress, giving the runner added motivation for training. This project is also motivated by our team’s collective interest in GPS, running, and being in shape.
The arm band portion will be able to determine the distance the runner has traveled via GPS by recording waypoints and performing calculations every ten seconds. It will take in three waypoints every ten seconds in order to minimize the possibility of taking an erroneous waypoint. It will relay this information to the runner through an LCD screen on the device. It will also have a stop watch so that the runner can tell how long he or she has run. The handheld device will have four buttons: an up and down arrow, a back button and a select button. These buttons will allow for navigation of the menu system displayed on the screen. The device will store information for a lifetime of runs. The runner will be able to review these runs whenever he or she desires. The device screen will also have a “battery left” gauge to relay to the user how much longer the battery will be charged. In addition, the device will produce a beep to tell the user that its battery is running low. It will posses the ability to recharge through an attachment to a wall.
The SHU running companion is intended to be worn on runs in order to track a runner’s progress as well as to give real time updates as to how his or her current run is going. It will allow the runner to know if he or she is meeting his or her goals or if more work is needed. It will function by displaying the statistics of miles run, time run, and mile splits. Our menu will be navigated through our LCD and pushbuttons. The runner will be able to review his or her past progress by reviewing all of his or her past runs.
[pic]
Figure 1. Main block diagram
[pic]
Figure 2. Power block diagram
[pic]
Figure 3a. Product Photograph
2. Team Success Criteria and Fulfillment
An ability to track distance run via GPS
An ability to store/archive data on on-board flash memory
An ability to display remaining battery life as a multi-segment fuel gauge (on the LCD)
An ability to charge the integrated lithium ion battery via an AC power supply
An ability to display operational information on the user interface, utilizing the LCD and pushbuttons.
Unfortunately, we were not able to complete PSSC one by the end of the semester because our GPS receiver broke in the final days of the project. As of time of publication, we were unable to communicate with the SD card through our selected SD reader and writer. PSSCs 3-5 were all working one hundred percent on December 9. Unfortunately, as of submission of this report, some of these PSSC’s are no longer working, but we hope to get these PSSC’s functioning by the end of the semester.
Constraint Analysis and Component Selection
3.1 Design Constraint Analysis
The major design constraints we considered while picking our parts were the size and weight of the unit as well as the overall power consumption. Because our unit will be portable, size and weight are the most important concerns. The less power needed by our device, the longer the user will be able to use it without recharging and the more effective of a training device it will be.
3.1.1 Computation Requirements
Our overall design does not require that many computations. The device needs to have basic ‘stop watch’ functionality and the ability to calculate distance given 2 GPS locations. The GPS will be pinged every 10 seconds and the distance will be computed between those two points. The result will be added to the total distance as well as the total time. Our device must also have the ability to display remaining battery life. Other statistics that need to be computed are the relative speed (distance divided by time) and mile split times.
3.1.2 Interface Requirements
Since our device will be handheld, it will only need to interface with itself. As far as user input, our LCD interface has a built in 7-key keypad that the user can navigate menus with. The LCD also has built in LEDs that will be used to indicate low battery life. To display our menus, the LCD will display 5 lines of text for each menu. Our microcontroller will also interface with the SD card as well as the GPS unit.
3.1.3 On-Chip Peripheral Requirements
We will need SCI to interface our microcontroller to the LCD we have chosen. We also need SCI to interface with our GPS chip as well as the SD card reader. Because we only have two SCI ports and three devices to connect to, we will be using a multiplexer to select either the GPS or the SD card. Because we will never need to access the GPS or SD card at the same time, we can use a simple multiplexer to access one device at a time. The other SCI port will be used to communicate with the LCD the entire time. We also want to use the pulse accumulator to interface with the battery fuel gauge, and PWM to alert the user that the battery is low with a beep.
3.1.4 Power Constraints
Because our device is going to be handheld, it must to be battery powered and rechargeable. We will be using a rechargeable lithium ion battery. The battery we decided upon is a 3.8V battery made by Ultralife Battery. We chose this battery because small its flat packaging and also because it contained the most energy of any batteries we saw.
3.1.5 Packaging Constraints
Due to the nature of the device, it is important for it to be small enough to be mounted on the user’s upper arm. It must also be durable enough to sustain a drop of around 5 feet, assuming something happens during use.
3.1.6 Cost Constraints
Our product is targeted to compete with the Garmin Forerunner 205 ($267.84). We plan on limiting our product’s cost so that we may compete with the Forerunner and other various Garmin Forerunner products.
2. Component Selection Rationale
3.2.1 GPS Selection
The two GPS chips we narrowed our choice down were the EB-85A unit and the EM-406a both made by USGlobalSat. The main factor in this decision was power consumption because both devices have the same accuracy rating (within five feet). Below is a table comparing the two devices.
| |Power |Frequency |Main Power Input|Dimensions |Sensitivity |Pins Required |
| |Consumption | | | | | |
|EB-85A |59mA |1575 MHz |3.3-5V |30x30x8.6(mm) |-158dbm |8 |
|EM-406a |60mA |1575 MHz |4.5-6.5V |30x30x10.5(mm) |-159dbm |6 |
3.2.2 Microcontroller Selection
In selecting the microcontroller, we took a few things into consideration, with power consumption, on-chip peripherals, and flash memory being the main concerns. Below is a table with our selections.
| |Operating |Speed |I/O Pins |Program Memory |On-Chip |Core Size |
| |Voltage | | | | | |
|Freescale |4.3V |80Mhz |59 |256K * 8 |SPI/SCI/PWM/ 8x10b ATD |16 |
|MC9S12XDT256 | | | | | | |
|Atmel |2.7-5.5V |16Mhz |48 |128K |PWM/8x10b ATD/USB |8 |
|AT90USB1286 | | | | | | |
Based on the above chart, the Atmel MCU meets our power requirements, but lacks the necessary on-chip peripherals such as SCI. Our design right now requires about 10 I/O pads, meaning we would have plenty of I/O pins on either chip. While the USB functionality of the Atmel would be a wonderful asset to our project, the core size is too small. One key feature that we needed was multiple SCI ports while maintaining a small package size. Because the Freescale microcontroller has two SCI ports and a manageable 80 pin package, it was the device we were previously leaning towards. After further investigation, we found that the GPS requires a 16-bit controller to send and receive directions, and the Atmel would not meet that requirement for us. Given all of the above data, we decided to go with the Freescale MCU instead of the Atmel.
3.2.3 LCD Selection
The decision on which LCD screen to use was based on characteristics and ease of use instead of strictly power consumption. We tried to use the most user-friendly LCD screen we could find. The two we considered were a 2.7” (diagonal) from 411 Technology Systems and the 128x64(mm) graphical LCD screen from Matrix Orbital. Because both units have roughly the same power constraints, the decision to go with the Matrix Orbital LCD unit was based on the built in MCU as well as the fully integrated 7-key pad. Using the 411 Technology Systems LCD would not have been possible given our chosen microcontroller’s SRAM constraints, although it would have looked graphically superior. The 411 Technology Systems LCD had no interfacing components to handle any handshaking and we would have had to send everything bit by bit. Using the Matrix Orbital screen, we can simply send SCI commands to the screen and it will handle the rest. While it is quite a bit larger, we feel we made the right choice by using the Matrix Orbital screen.
3. Patent Liability Analysis
Possibly all of the functions performed by The Shu Running Companion infringe on existing patents.
Performing a basic Google product search of “GPS running watch” one will find 2,177 products [17]. All of the functions performed by The Shu Running Companion have been already been performed by existing products. The concept is not new. Many companies such as Garmin, Timex, and Suunto have created and marketed devices that display a runner’s speed and distanced traveled utilizing GPS data. Since The Shu Running Companion will be providing the runner with data that is already available through other competing products, there is great potential for patent infringement. The Shu Running companion will take in longitude and latitude points via a GPS chip and through algorithms will determine relevant running statistics. It will also display historical statistics based off of previous runs to aid the runner in training. Many products that are already on the market work in a very similar fashion. Due to this, patent liability analysis is an integral step in the design process for The Shu Running Companion.
1. Results of Patent and Product Search
Performing a patent search using the “Free Patents Online” database, it was not very difficult to find patents with potential infringement. One patent issued by Garmin seemed to cover all functions performed by The Shu Running Companion. Other patents issued by Timex and Suunto have a great potential for infringement in the vast majority of their claims.
4.1.1 Location Determining System [18]
Filed by Timex November 17, 2006, U.S. patent 2007/0067128 A1 covers many of their GPS running watches. The condensed abstract is as follows, “A location measurement system [comprised of] a GPS receiver for attachment to a person and for determining earth location of a person; a display for attachment to the person; memory for storing map data; a processor configured to process earth location and the map data to instruct display the person’s current location with a map on the display.
Key claims with infringement potential include the first claim (which is basically a summary of the abstract) and claims three, four, and seven. The rest of the claims do not apply because they have to do with altitude and accelerometer data. Claim three refers Timex’s product having the ability to take in GPS data to determine speed and having a processor configured to display this information to the user. Claim four states that the distanced traveled will also be determined from GPS data and displayed to the user from a properly configured processor. Finally, claim seven states that the housing for Timex’s product will include a display for displaying a map.
4.1.2 Personal Training Device Using GPS Data [19]
Patent U.S. 2008/0096727 A1 was filed by Garmin on December 13, 2007. Essentially, the functions described by this patent are identical to the functions of The Shu Running Companion. Although specific products (besides the Garmin Forerunner) were not disclosed, inventor Tracey L. Olivier assured that many Garmin products both on the market and in conception are and will be covered by this patent [20]. Summarizing the abstract, this patent is for a personal training device adapted to assist a user in reaching performance goals, navigating, and accumulating performance statistics. The device is comprised of a housing, an attachment mechanism, a GPS component, a user interface, a processor including a timer and memory element, a data interface, an audio component, and a power supply. The device is adapted to store goal information, monitor performance, and communicate this data to the user.
The Shu Running Companion has potential for infringement with all of the claims made by this patent. This patent covers all performance data obtained from the GPS as well as historical statistics based off of previous workouts. The patent also has a function that stops the workout timer when a set minimum speed is reached which would be covered under the doctrine of equivalents.
4.1.3 Physical Training System [21]
Filed by Suunto on September 5, 2002, U.S. patent 2004/0046692 has a very basic abstract that both Timex and Garmin must have had infringement issues with. The abstract is, “A physical training system that includes a global positioning system.” Although the abstract is extremely vague, the patent includes 36 claims that are much more specific. In short, these claims include that the device will be handheld, obtain at least a starting and ending run point using longitude and latitude measurements, include an elevation measurement, include calories burned, include a heart rate monitor, calculate data on an on-going basis, and store path data. All of the claims related to elevation and heart rate can be excluded; however, all other claims made by this patent could lead The Shu Running Companion into infringement issues.
2. Analysis of Patent Liability
4.2.1 Literal Infringement
It is probable that all of the functions performed by The Shu Running Companion will have literal infringement issues with Garmin’s patent U.S. 2008/0096727 A1. The patent describes a product that includes all of the same major components as The Shu Running Companion. Although The Shu Running Companion accurately measures and displays battery life and there is no mention of battery life monitoring in this patent, this does not in any way protect from infringement. Aside from this, The Shu Running Companion performs the same functions described in the patent. Namely, The Shu Running Companion calculates performance data, displays statistics from previous runs, and has a minimum speed for which it will operate. Since all of these functions are implemented using the same components described in the patent, there is a very good chance for literal infringement. However, the code used by Garmin may not perform in the same way as our code, so it is possible that the infringement might be under the doctrine of equivalents rather than literal. For example, Garmin may use an interrupt driven style while we use a polling style. For this, whether infringement exists or not will have to be determined by lawyers, although there is still a high probably for an infringement issue.
In the patent filed by Timex described above, there is also a high probability for literal infringement. Again, reading through the abstract and selected claims one can see that they fall in line with the overall function of The Shu Running Companion. Timex carefully describes that there will be a microprocessor configured to display performance data. In our design, the microprocessor will be taking in and sending out this same information to the LCD display. Because of this, again there is a great chance for literal infringement.
4.2.2 Infringement under the Doctrine of Equivalents
The Shu Running Companion may face infringement under the doctrine of equivalents for the patent described above by Suunto. Suunto describes a device that uses GPS data to calculate the users path and also includes a claim for calculating the calories burned by the user. Most likely, The Shu Running Companion will not have any infringement issues with calculating calories burned since it will be based on speed, distance and time run, and user input weight rather than being based off of a heart rate monitor. However, Suunto failed to describe the electrical components used to determine the user’s path from the GPS data. The Shu Running Companion will also perform this same function, but will most likely use a different method than Suunto. For this reason, there could be infringement issues by the doctrine of equivalents.
3. Action Recommended
Since the Shu Running Companion is very similar to many products already on the market, patent infringement is a very big issue. Unfortunately, this patent analysis was not conducted in the conception stage of the product. Therefore, the functions of the project are rigid and will be difficult to modify or eliminate. To use the functions that have been incorporated into the design, a royalty will have to be paid to the patent holders. Otherwise, The Shu Running Companion could be sold to Garmin since they hold the majority of the patents resulting in infringement issues.
4. Summary
The Shu Running Companion is very similar to many products that are widely available on the market today. These products have been protected by many patents that The Shu Running Companion will most likely infringe upon. The concept of using GPS data to track training and performance is very well protected. Since this is the main function of The Shu Running Companion, it is not easy to modify such that patent infringement no longer exists. For this reason, for The Shu Running Companion to reach full scale production, it will be required that a royalty be paid to all patent holders whose patents are infringed upon.
4. Reliability and Safety Analysis
Our device will be mounted on the user’s arm and, as such, has the potential to injure the user should something go very wrong. Battery failure is the most severe of possible problems—battery acid leakage or extreme overheating will definitely injure the user. High levels of heat from any other component could pose another risk. As such, heat is the most critical of safety issues.
On the other hand, privacy and security are not main concerns of our product. No personal information is stored on or transmitted from the device. Furthermore, the device would never result in death or serious injury except in the case of severe misuse.
1. Reliability Analysis
Following are the tables for choice of parameters for four components in our product. The microcontroller was chosen since it is easily the most complex and probably the most important component in our product. The boost was chosen since it is directly connected to the power source and is a part with high likelihood of failure. The inductor was chosen because it is a simple part that, if it failed, could cause the power circuit to fail and, consequently, cause the entire device to cease functioning. Finally, the Schottky diode was chosen because, again, it is a simple part that may have major effects—the complete loss of communication with the SD reader.
Microcontroller
|Parameter name |Description |Value |Comments |
|C1 |Die complexity |0.28 |16-bit device |
|C2 | |0.0318 |80 pins |
|πT |Temperature coeff. |0.5 |CMOS device |
|πE |Environment coeff. |4 |Ground, mobile |
|πL |Learning coeff. |1 |Has been in production for more than 2 year|
|πQ |Quality coeff. |5 |Estimate for nonmilitary devices |
|Entire design: |Microcontroller |1.336 |Number of failures per 106 hours |
| |MTTF |7.49E5 |Mean time (hours) until failure |
Boost Converter
|Parameter name |Description |Value |Comments |
|C1 |Die complexity |0.01 |Simple CMOS device |
|C2 | |0.0026 |8 pins |
|πT |Temperature coeff. |0.24 |CMOS device |
|πE |Environment coeff. |4 |Ground, mobile |
|πL |Learning coeff. |1 |Has been in production for more than 2 year|
|πQ |Quality coeff. |5 |Estimate for nonmilitary devices |
|Entire design: |Failures |0.172 |Number of failures per 106 hours |
| |MTTF |5.81E6 |Mean time (hours) until failure |
Inductor
|Parameter name |Description |Value |Comments |
|lamda-b |Base failure rate |0.001 |Based on estimated temperature rise, |
| | | |ambient temperature, and maximum operating |
| | | |temperature |
|πC |Construction factor |1 |Fixed construction |
|πE |Environment coeff. |12 |Ground, mobile |
|πQ |Quality coeff. |5 |Estimate for nonmilitary devices |
|Entire design: |Failures |0.06 |Number of failures per 106 hours |
| |MTTF |1.6E7 |Mean time (hours) until failure |
Schottky Diode
|Parameter name |Description |Value |Comments |
|lamda-b |Base failure rate |0.027 |Base failure for a Schottky diode |
|πT |Temperature factor |8 |Based on a junction temperature of 150 C |
|πE |Environment coeff. |5 |Ground, mobile |
|πQ |Quality coeff. |5 |Estimate for plastic transistors |
|πA |Application factor |1 |Generic diode |
|πR |Power rating |1 |Generic diode rating |
|Entire design: |Failures |5.4 |Number of failures per 106 hours |
| |MTTF |1.9E5 |Mean time (hours) until failure |
Based on these calculations, it’s obvious that the diode is at the highest risk of failure. If it does fail, the voltage converter will no longer work properly. This will, in turn, cause the SD card’s transmit signal to be cut off from the microcontroller. The device will continue to work normally until the user tries to access the memory card. This is a low risk failure.
Not many considerations can be made to increase the life of this component. The fact that it will not be in use very often will certainly help. The SD card reader is one of the least used components in the device. While it is not being used, the voltage converter will be off and the diode will have to voltage across it.
The next most likely part to fail is the microcontroller. The risk associated with this part failing is, again, low, though the inconvenience and the cost to replace make it an expensive part to have fail.
Programming power saving features into the device’s program and keeping the clock frequency low may increase its life. Proper heat dissipation will also certainly have a positive effect.
2. Failure Mode, Effects, and Criticality Analysis (FMECA)
We defined three criticality levels with respect to our device failures. Low criticality is defined as something that would cause no harm to the user, would likely be easy to repair, and would not cause complete failure of the device. A medium level failure would be more difficult to repair and would cause more widespread device failure, but would still not injure the user. High criticality is given to any failure that has the potential to hurt the user.
In general, it was assumed that high voltages (voltage greater than 5 volts) would cause damage to components and overheating, and could potentially be traced back to a problem with the battery, external power, or the AC power adaptor. This sort of failure was always given a high criticality level. Acceptable failure rates for this sort of failures would be one failure in 1E9 hours.
It was also assumed that any failure that would be likely to damage only one major component (mostly IC’s) other than the microcontroller or any minor components (resistors, capacitors, etc.) would be given minor criticality as long as it did not result in high voltages. An acceptable failure rate for this would be one failure in 1E6 hours.
3. Summary
Four components in the SHU device were chosen for safety and failure analysis—the microcontroller, the voltage boost, the inductor, and the Schottky diode. These parts were chosen due to their complexity, in the case of the first two, and their simplicity and effect on surrounding components, as in the case of the last two.
The diode was determined to have the highest failure rate but the lowest criticality. The microcontroller had the next highest rate and was much more critical to the operation of the device. Some high-criticality failures were identified, and they all had to do with high voltages and overheated due to failure of the battery or power circuit..
5. Ethical and Environmental Impact Analysis
Many of our product’s components pose an environmental impact mainly due to the non-biodegradable nature of them. Our product will post an ethical problem, only if we do not test it thoroughly enough to ensure it is a durable and safe product.
1. Ethical Impact Analysis
As was addressed in the reliability and safety analysis, a major ethical impact is the possibility of our lithium ion battery shorting and creating a lot of heat or even potentially a fire. This is a major ethical issue because it can cause injury to the user. It is important that before the device is finalized, we ensure that the probability of the battery terminals shorting is very low. This can be achieved by making sure that the capacitor that is between the positive and negative terminals has a high voltage tolerance. This will ensure that the capacitor will not be susceptible to voltage spikes from the battery or surrounding chips. We could also install a fuse so that if the battery terminals were to be shorted power would just be cut off. This is really the only place that the two terminals can be shorted together unless the actual wires were to touch. This is very unlikely because the wires are obviously rubber coated. To take extra precaution, the wires could be secured to the board with hot glue to ensure that they will not come near each other.
It is important that we test our product thoroughly to ensure that there are no other major safety issues that can occur throughout the products average lifecycle with typical use. We can address most safety issues that will come from improper use in either the user’s manual or by placing warning stickers on the back of the case. For example, we could make a section for warnings and included in these warnings could be “Please do not store this product in extremely hot temperatures. This product contains a lithium ion battery that may explode if it comes in contact with fire.”
We should do many tests on our product. The most important tests to perform would be seeing how the product performs when bouncing around because it will be placed on a runner’s arm and will be jostled around under normal operating conditions. We will need to ensure that all parts are securely fastened in place and that open metal pieces will never touch or maybe be destroyed if the runner were to trip and fall on it accidentally. A way to prevent this as was stated before is to use hot glue to secure the most vulnerable pieces in place. It is also important that we have padding in the packaging to limit movement of the PCB and components inside of the package. For this we have chosen cork due to its flame-resistant properties. Cork is not ideal because it is not as soft as we would have liked in order to dampen movement; however, it is the most readily available product. The outside of the package will have to be very durable plastic that can sustain some impacts, such as in the case of the runner tripping and falling onto the device. However, it should not be expected that our device will be able to survive a huge amount of instances of being dropped, stepped or, fallen on. Most typical electronic devices can only handle so much wear and the most important aspect of durability in this product’s case is that is can survive when being jostled around on the runner’s arm. However, it is very important that if the runner were to trip and fall onto the device, the package would be durable enough to protect the battery from any and all damage. If a lithium ion battery packs are damaged or deformed in any way it may cause acid leakage, overheating, smoking, bursting or ignition [27]. This must be avoided because it may cause damage to the user.
It will also be important for the device to operate properly when slightly moist due to the likelihood that a runner will be sweating when training and wearing our device. This could be addressed by using moisture-proof packaging and by insuring that all openings in the device case are sealed properly. If an electronic device is to get wet, there is not much likelihood of injury, but the device will probably cease working if it were to get really wet because the runner was using it in very heavy rain. We can address this issue in the user’s manual by placing a warning in the warning section saying, “Caution: Do not use device in heavy rain. Device may stop working if it gets extremely wet.” We can also manufacture the device to be water resistant so that it could withstand most contact with water but most likely not complete submersion in water.
2. Environmental Impact Analysis
When being manufactured our product will have some environmental impact. This can be seen somewhat through the fabrication of the PCB used in the product. When printed circuit boards are fabricated, many harmful chemicals are used. The main parts of the PCB fabrication process that is harmful to the environment are as follows: cleaning and surface preparation, catalyst application, pattern printing and masking, electroplating, and etching[28]. In addition, all PCBs have small amounts of lead in them. The lead in the PCB will probably not be of any major environmental impact until the recycling stage of our product.
The major manufacturing environmental impact SHU will have comes from the manufacture of the LCD screen. It has recently been found that LCD screens of all sizes put out nitrogen trifluoride, a gas that can contribute to the greenhouse effect. This gas may have an impact 17,000 times that of carbon dioxide on the environment [23]. This compound is used in the production of all LCDs and is not currently monitored by the Kyoto Protocol, a protocol that establishes commitments for the reduction of six greenhouse gasses[24]. It has been estimated that this gas will actually have more of an effect on the environment this year, than some gasses that are actually considered in the Kyoto Protocol such as PFCs and sulfur hexafluoride[23]. Unfortunately, this gas is also expected to remain in the atmosphere for approximately 550 years, and there are no ecological cycles to aid in its removal [23]. There is not much that we are manufacturers of this product can do to limit this greenhouse gas emission. Our only option would be to investigate other types of screens, but it would be impossible to eliminate our product’s dependence on a screen, as there is really no other useful way to relay information to the user.
The only major environmental impact that can come from SHU’s use is its power usage. However, our device is a pretty low power device, and we do not really foresee this as being an issue. The only real problem would be if everyone in the world used one and kept it plugged in all of the time. Our device on average will not consume more than 1.25 W at any given time. This is if the LCD screen were constantly on which is not very likely as most of the time the device is plugged into the wall the device will be charging and the user will not be using it. Obviously, this is not even one percent of most people’s daily power usage and this is why we do not see power usage as being a major environmental impact.
Most of the obvious environmental impact of our device, as with most other electronic devices, comes in the recycling stage. We have many components which pose an environmental problem. These components are as follows: LCD screen, lithium ion battery, PCB, plastic casing, and small ICs as well as all non-biodegradable plastic and metal parts.
The LCD screen is the most pressing of our environmental concerns. If not recycled properly, the LCD will just end up in a landfill. However, if an LCD is burned, toxic waste and volatile products are generated. This will contribute to global warming by creating CO due to incomplete combustion [2]. This can be avoided by putting a warning in the user’s manual asking the user to send the LCD screen back to us when done with the product so that we can recycle it or dispose of it in an environmentally friendly manner. We could even offer monetary compensation for the return of their product at the end of its lifespan.
Another environmental concern is the battery. Most lithium ion batteries last for 300 to 500 full recharge cycles, which comes out to about one to three years of use, after this they must be recycled in order to reduce environmental impact. According to the US Government, Lithium Ion batteries are not a huge environmental hazard. [22] Because of this, there are not many precautions that need to be taken aside from encouraging the consumer to send their product back to us at the end of its life cycle, so that we can recycle or dispose of the different parts as necessary.
The PCB also impacts the environment in a way. If thrown out, the PCB is not biodegradable. It can also leak lead into the environment. If lead is leaked into the environment it can end up in water and soils. Lead can accumulate in the bodies of organisms that live in, drink, or eat the water or soil. These organisms will experience health effects from lead poisoning [26]. This is particularly dangerous because it can affect not only the animal or organism that ingests it, but also animals or organisms that prey on the original organism. Thus, it can affect entire food chains.
The final two items which we perceive to have an environmental impact are the plastic casing and plastic ICs contained in the product. If the product is not recycled by being sent back to us, the plastic casing will most likely end up in a landfill. We will try to combat this by encouraging our users to send their product back to us for monetary compensation. This way, we will be able to disassemble the product and recycle the plastic case to make into a new case and possibly disassemble the ICs and recycle them for use in other industries.
3. Summary
Overall, our product will have minimal ethical impact. There is not much chance for harming the user, and most of these chances can be eliminated by taking simple precautions. We should thoroughly test our product in order to ensure that it will operate well under normal conditions. This way we will make sure that we are not shipping out a faulty product, or an easily broken product.
Our device will have the most environmental impact in the manufacturing and recycling stages. The manufacturing impact will come from the manufacturing of the LCD, which releases harmful gasses into the atmosphere. The recycling impact will come from irresponsible disposal of our device. We will combat this by encouraging our users to send their device back to us at the end of its life cycle so that we will be able to dispose of it in an environmentally friendly manner.
6. Packaging Design Considerations
The SHU will be enclosed in a black plastic project enclosure and be mounted as to prevent damage on impact. To attach the unit to the users arm, a strap similar to the iPod will be used.
1. Commercial Product Packaging
After looking through various products, we were able to narrow the field down to two. There are two types of GPS units available, a normal GPS and also a GPS trainer. The products chosen were the Garmin Forerunner 201 [15] and the Garmin GPS 40 Personal Navigator [16]
2. Product #1
The first product we compared was the Garmin Forerunner 201 as shown in figure three. This is a handheld GPS unit that attaches to the users wrist. Dimensions for unit itself are 3.26” x 1.71” x 0.7”. The size of the Forerunner is very close to ours, with our product being slightly wider (@ 3” compared to 1.71”). The only downfall to the Forerunner is the rather small LCD display (1.44” x 0.92”). It was also noted that the LCD screen was monochrome and not backlit, severely limited what can be shown on the device. There was also no mention of external memory, so either data is stored directly in the device, or no storing is allowed.
The packaging itself seems to be rather user friendly, with rounded corners and the buttons placed below the unit. When attached to the wrist, it seems easy to navigate through menus and use the device with the current button placement. The documentation also mentioned that the device is both shock and impact resistant, which leads us to believe that there must be either foam for impact or the parts are mounted to the device. When we decide on our final enclosure we will have to make sure that there are enough mounting brackets for all of our parts. Our final analysis was that the Forerunner was extremely user friendly, but with a screen slightly smaller than what we were hoping for.
3. Product #2
The second product we looked at was the Garmin GPS 40 Personal Navigator as shown in figure four. We chose this model because we had it on hand and it was more of a traditional GPS unit. While this unit was handheld, it’s considerably heavier than our model (9 oz. vs. ~4.3 oz.). The screen on this model was slightly bigger than the Forerunner, but was also Monochrome, which limited the types of things we could display. There was also no mention of memory features to save data on the device. Since this model was a little older (around 10 years), it required AA batteries. This gave it a lifespan of around 20 hours.
Like the Forerunner, this product also had shock and impact resistant construction. Our final analysis of the GPS 40, was that the packaging was bulky and not very user friendly. The buttons seem to be place in an ‘awkward’ position and it took some time to get use to all of the functions of the device.
4. Project Packaging Specifications
When determining packaging for our device, we had to pay close attention to how ‘handheld’ our device would be. This would depend strictly on the size and type of enclosure we chose. This is where we had to get creative with our enclosure chose. Since we are limited to a project enclosure, there are only a limited number of sizes available. At the moment, our product will be 3” x 3.5” x 1.3”, but that might change after all of our components come in. The one dimension we are limited in is the width. This is the one number that can’t be below 2.1”, due to the size of our LCD screen and battery. There also must be some padding as to not crack the case while it is being cut. We want the enclosure to be made out of a hard plastic, not liable to break upon a 5 foot drop. In order to insure impact resistance, we will also have to make sure everything is mounted securely to the enclosure. As far as the mounting strap, we want to find something ala iPod arm strap. The pictures in Appendix A are currently to scale given our ‘ideal’ product size. The screen and button size are drawn to scale. Our estimated weight is around 4.23 ounces given the weights of our purchased components. The breakdown is located in Appendix B.
We should not need too many tools to make our design. Aside from the soldering tools for attaching our components to the PCB, we will need a drill and a jigsaw to work on the enclosure.
5. PCB Footprint Layout
Like the rest of the design, our PCB dimensions will be limited by the size of the product. The PCB dimensions need to be large enough to fit everything, but small enough to fit the packaging. With the ideal dimensions of the case, it was determined that a PCB size of 2.7” x 3.2” should be sufficient to fit all of our components. This is the max size allowed for the PCB, it might be decreased to fit the need of the required components.
At the center of the board will be the 9s12 Freescale micro controller. This chip comes in 60-pin packages with quad surface mounting. Since the micro controller is located at the center, all of peripherals can be easily connected. The rest of the chips (Battery monitor and GPS) will be placed as far away from the 9s12 as the board will allow. This is to help with heat dissipation and also make the components less likely to short out if they touch. The GPS module only has a 6-pin surface mount package, but the chip dimensions (1.2” x 1.2” x .4”) take up the majority of the room. The rest of the products devices are not on-board, so they do not need to be mounted to the PCB. The LCD has a 22-pin package that connects to the 9s12 using SPI. Since this component is larger than the amount of space on the PCB, it will not be mounted directly. The SD Reader follows in the same way. It has a 12-pin surface mount package that connects using SPI. The LCD and the SD Reader will connect using available headers and therefore do not need to be mounted directly.
6. Summary
Given the need of our project, and taking into account being battery powered, handheld, and the PCB footprint, it was decided that a standard project enclosure will be sufficient for our design. Currently, Radio Shack and other third party companies are being investigated to find a sufficient enclosure. While the device may end up being bigger than those that were compared, the need for a TFT-LCD and external memory capabilities give it more functionality than it’s competitors.
7. Schematic Design Considerations
The SHU Running Companion is composed of 9 major components that will allow it to perform a variety of functions. These components include the microcontroller, an SD reader/writer, an intelligent LCD screen, an eight ohm speaker, a GPS chip, a boost converter, a lithium ion rechargeable battery, a battery charging IC, and a battery “fuel gauge” IC. There are many factors to consider when attempting to integrate all of these components into one printed circuit board. The most challenging obstacle is providing all of the components with the correct voltage as well as with enough current to drive them but not so much as to break them. Fortunately, the selected components (aside from the SD reader/writer) only require 5 volts. The 3.3 volt SD reader/writer will communicate to the 5 volt microcontroller through a level converter and a resistor will be used to step down the voltage from the microcontroller. This brings us to the second largest challenge in our schematic design—making sure that all of our components can communicate with each other precisely and accurately. Finally, microprocessor port pin assignment and oscillator circuit considerations were also large issues in our schematic design. Each issue will be reviewed in detail in the following paragraphs.
1. Theory of Operation
8.1.1 Microcontroller
The microcontroller will serve as the brain of our entire circuit. It will take in longitude and latitude coordinates from the GPS chip, user input from the pushbutton and optical encoder, output beeps to the speaker as the user is navigating as well as when the battery is low, read and write to the SD board, communicate with all power supply components, and output a display on the intelligent LCD. The operating frequency for the microcontroller was chosen to be 4 MHz. As the Shu Running Companion is a portable device, it is important that unit is designed to consume low power. It will also not be necessary for us to update the display very often when the runner is on a run. As the user navigates through the menus, it will suffice to have the cursor lag as long as it is less than five milliseconds. This is only 200 hertz. Adjusting for computational delays and communication between components, an operating frequency of 4 MHz is high enough to ensure that the user will not experience drastic lagging and low enough that the microcontroller will not dissipate massive power. Communication between the microcontroller and each component will be discussed in detail below.
8.1.2 SD Reader/Writer
The SD reader/writer chip will communicate with the microcontroller using SCI. Both Rx and Tx lines are connected to SCI port 0 through a multiplexing/demultiplexing PLD. The SD reader/writer chip sends and receives voltages at 3.3 volts [2]. The Tx voltage from the microcontroller being received at the Rx input of the SD reader/writer chip is stepped down using a 220 ohm resistor so as not to provide too much voltage to the SD reader/writer chip. The Tx voltage from the SD reader/writer chip will be stepped up from 3.3 volts to 5 volts before being received at the Rx input of the microcontroller.
8.1.3 Intelligent LCD Screen
The intelligent LCD screen has a serial interface with the microcontroller and will be capable of transmitting pushbutton signals back to the microcontroller. All of our user interface buttons except for power are mounted on the intelligent LCD’s PCB. The LCD inputs have been connected to SCI port 1. By placing jumps on certain locations of the intelligent LCD PCB, we will be able to select Serial/TTL communication.
8.1.4 Speaker
The selected speaker has an impedance of 8 ohms [9]. The positive terminal of the speaker has been connected to a mosfet that is controlled by a PWM output pin of the microcontroller. The mosfet is used so that the speaker can draw more current than is supplied from the microcontroller’s port pin. A 22 micro farad capacitor has been connected between the negative terminal of the speaker and ground to effectively create a low-pass filter as recommended by Freescale [3].
8.1.5 GPS Chip
The GPS chip will communicate with the microcontroller using SCI. Both Rx and Tx lines are connected to SCI port 0 through a multiplexing/demultiplexing PLD. It is powered by a 5 volt signal supply from the boost converter [4]. The GPS will send new data every second to the microcontroller; however, we will only sample it every 10 seconds. This serial interface will allow for easy communication.
8.1.6 Boost Converter
The boost converter takes the 4.35 volt output from the battery charger system output and steps it up to 5 volts [7]. A 50 micro henry inductor is used at the input to minimize the voltage ripple. The voltage measured by the IC over the 180 kilo ohm is sent to a 0.5 volt comparator that controls the output voltage from the boost. This voltage divider will include a 1.62 mega ohm resistor to set the output voltage to 5. The converter is capable of sending out low battery warnings; however, we will configure it such that this feature is disabled because we will be receiving all of the battery information that we need from the battery “fuel gauge” IC.
8.1.7 Lithium Ion Rechargeable Battery
The lithium ion battery that was chosen is single cell. Its nominal voltage is 3.7 volts, although the voltage range is between 3 and 4.2 volts [10]. It is connected directly to only the battery charging IC and to the battery “fuel gauge” IC.
8.1.8 Battery Charging IC
The battery charging IC will communicate with the microcontroller to let it know when the battery has completed charging. The termination current set pin has been tied high to allow for the fastest battery charging. Also, the USB charging option has been disabled by tying the USB suspend input high [6].
8.1.9 Battery “fuel gauge” IC
The battery “fuel gauge” IC will communicate to the microcontroller using on port t so that the pulse accumulator can be taken advantage of. As charge leaves the battery, the battery “fuel gauge” IC will send a signal to microcontroller so that the total charge can be kept track of. The IC operates from a standard 5 volt supply provided from the boost converter [9].
2. Hardware Design Narrative
The microcontroller will require three separate subsystems to complete all of the desired functions. Since many different components are being used, communication between these components is very important. The Shu Running Companion is essentially a very advanced watch and timing is very important to correctly display the run time as well as mile splits. The required subsystems include SCI, the timer module and PWM.
8.2.1 SCI
The SCI subsystem will be used to communicate between the microcontroller and the LCD, the SD reader/writer, and GPS chip. The first SCI port has been sent to a multiplexing/demultiplexing PLD along with a select signal to determine whether communication will be with the SD reader/writer and the GPS chip. The second SCI port has been dedicated solely to the LCD since it will be receiving signals most frequently. The SCI will transmit data at a baud rate of 9600 to match that of the computer.
8.2.2 Timer Module
The timer module will be used to accurately record time as the run progresses. The timer module is currently being designed to increment every tenth of a second. This is due to limitations from the LCD and the human mind. Although the data will be dynamically changed on the screen, one will not be able to discern digits less significant than one tenth of a second.
8.2.3 PWM
The PWM port will be used to send specific frequencies to our speaker. There will be at least two separate frequencies. The first will sound as the user scrolls between menus to let them know that they have reached the next item. The second frequency will be an alert to the user to inform them that the battery life is at a critical level. For sound quality, the duty cycle of the PWM signal will be set to 50%.
3. Summary
Due to the complexity of the desired product, there were many challenges that had to be addressed in the design process. The largest challenge was the power supply circuit. To be able to charge the unit from a wallwart supply and provide a display of battery life required careful planning. Another challenge that was faced was dealing with the SD reader/writer’s 3.3 volt signals. This was overcome by using a resistor to step down the voltage from the microcontroller and a level converter to step up the voltage from the SD reader/writer. Another challenge was turning two SCI ports into three, which was accomplished using a PLD. After careful design planning, the Shu Running Companion will be able to carry out all functions necessary to ensure that runners will have the information that they need for ideal training.
8. PCB Layout Design Considerations
When designing the PCB, one of our main concerns was the size of the board. SHU is supposed to be arm mounted in order to give it the desired functionality; therefore the board must be small. Unfortunately, due to time constraints we could not make the board quite as small as we had wanted. Our other main concerns were power supply placement in relation to the GPS chip and general trace length. Consideration must also be given to general chip placement in relation to other chips as well as side of the board on which chips should be placed.
1. PCB Layout Design Considerations - Overall
When designing the PCB, the first main concern is power supply placement. The power supply for SHU is relatively complex and involves three integrated circuits and a lithium ion battery. The first thing that needs to be considered when determining where to place the power supply is noise on the data lines. Because the power supply components are the noisiest on the board, it is important that these parts are placed as far away from the GPS as possible because the GPS is the most sensitive chip on the board, and therefore the most likely to be thrown off by noise coming from the power supply circuit. Continuing with this thought, the GPS chip and the SD reader/writer will need to be placed close to the microcontroller in order to eliminate the possibility of noise on the Tx and Rx lines. [3][1]
The power supply circuit will be placed on the bottom of the board while all of the other individual components are placed on the top of the board. This is because, as previously mentioned, the power supply circuit is not only the noisiest part of our layout, but also the most complex. Placing the power supply on the bottom of the board also allows more space for all of the components.
As mentioned in the introduction, another serious concern is board size. A small board size will give SHU increased functionality as it will be less bulky and more easily arm mounted. Unfortunately during the design process we had to change our selected LCD to a more bulky LCD. The made the routing of the PCB easier but made our final product much larger. Although this is undesirable, it was a necessary change in order to complete our project on time. The final size of the board will be 165 mm by 80 mm. This is the smallest size we could make because the LCD and accompanying board with controller is about this long. This will make our project bigger than we had initially anticipated but with time limitations we could not redo our whole design to fit in a smaller package.
In designing the PCB it is also important to think about the signals that will need to be brought to headers in order for debugging when programming. The important pins that are being put on headers on this board will be the LCD, SD reader/writer, and GPS pins. It will also be very important to be able to easily read the power pins when trying to debug the power circuitry.
Trace width was also a consideration. It is necessary to determine the proper trace width for the current flowing through the traces. It is estimated that no more than 250 mA will be flowing through the traces at any time. The boost will be drawing no more than 250 mA from the battery charging IC depending on whether the LCD backlight is on or not. Therefore approximately 1500 mA will be being drawn from the battery at any given time, assuming the LCD backlight will not always be in use. Looking at [14] the required trace width for this amount of current is only 1.28 mil. However, due to safety concerns and the recommendations from lecture, it is decided that 10 mil traces will be used for data signals. Because of further safety considerations, power supply traces will be 50 mil in width. This way we can be sure to avoid blowing any traces.
2. PCB Layout Design Considerations - Microcontroller
The main consideration taken when positioning the microcontroller is the placement of the oscillator circuit and bypass capacitors. Freescale’s documentation [2] lays out the recommended circuit design so the only consideration that must be taken is allotting enough space for the microcontroller , all accompanying bypass capacitors, and the crystal oscillator. It is also necessary to position it in such a way that the other components can be arranged around it in such a manner that they may all easily access their necessary port pins. In order for the board to function properly, it is necessary for the bypass capacitors to be placed as close to the microprocessor as possible because it will be operating at high switching frequencies (4 MHz). [2]
3. PCB Layout Design Considerations - Power Supply
As is previously mentioned, the power supply is the biggest consideration on SHU’s PCB. It is placed on the bottom of the board in order to reduce interference with all of the other components that are placed on the top of the board. Due to the complex nature of SHU’s power supply a lot of thought must be put into where to place the battery charging and fuel gauge ICs. They were placed in the place with the least possible interference from other parts. The boost transformer will be giving off the most noise in the circuit; therefore it is important to try to keep it as far away from sensitive components as possible.
It is also necessary to take the proximity of power lines to data lines into consideration. Because of this, every attempt was made to keep the power lines as far as possible from the important data lines on the PCB in order to reduce noise on the lines. Even though, there is a space constraint on the PCB, keeping the power circuit lines on the bottom of the board has been attempted in order to reduce their effect on the rest of the circuit. Keeping the power supply lines as short as possible was also attempted in order to keep the trace resistance low. It is very important for us to keep the resistance low in order to reduce power dissipation along the traces. It was also very important to us that we use wider power traces in order to ensure that no traces will be burnt out during standard device operation. We made the power traces 50 mil because of safety considerations.
4. Summary
In order to meet the functionality needs of SHU: The Running Companion, many different things need to be taken into account when designing the PCB. It is also important to consider placement of the different ICs and headers on the board in order to reduce the difficulty of routing the board and to reduce the effect of the board’s components on each other. The biggest challenge to SHU’s board design is the power supply which must be kept away from the rest of the circuit in order to reduce noise and guarantee signal integrity.
9. Software Design Considerations
The unit will be required to interpret incoming GPS data and record and calculate distance and speed based on that data, combined with clock data. The LCD screen will be updated in real-time to display distance, time, and other information. Data will be able to be read from and written to an internal SD memory card as well.
1. Software Design Considerations
The memory mappings for peripheral registers, EEPROM, RAM, FLASH, and everything else can be found in this document, generated by Freescale CodeWarrior, at lines 995 to 1053.
We will be using 12 general IO pins, 2 SCI input and 2 SCI output pins, and 1 PWM pin. The general IO pins used are PA1-3 for the fuel gauge, PA4-7 for the battery charger, PM5 for the SD R/W reset, PJ6 for the GPS’s PPS pin, PM3 for the multiplexer’s output enable, PM2 for the multiplexer’s select pin, and PE2 for the sync input on the boost power supply.
We will be making heavy use of the SCI peripheral. The SCI is used on the pins TX0, TX1, RX0, and RX1. TX0 and RX0 will be connected to a PLD programmed as a MUX/DEMUX. We will thusly be able to communicate with the GPS and SD R/W through the same pins. The GPS and SD card will never be accessed at the same time, so no special considerations need to be taken for frequent switching between the two.
The register SCICR2 controls the main aspects of this peripheral. Since we will not care about interrupts on the serial components, we will set all the interrupt enable bits low. The only enabled bits for this register are the transmitter and receiver reset bits. All SCI interrupts are disabled.
During early development, there were some difficulties in programming the modules that made use of the SCI peripheral. Because of this, we looked for and found pre-existing code online that would allow us to interface with the SCI easily. Details of the source of this code can be found in the references section.
The PWM will be used to control our speaker. The PWME register will enable the PWM0 port—the only one we will need to use. We will use standard polarity. Since the PWM will be used to control a speaker, it will need to divide the clock as much as possible: dividing by 128 is the best option, which will get the 8 MHz clock signal down to about 62 kHz. Different tones will be used for the speaker, so the frequency scale registers—PWMSCLA & B—will be changed to get the frequency down further to get within comfortable, audible frequencies, ranging from about 5 kHz up to a maximum of 15 kHz. The duty cycle register, PWMDTY0, will simply be set to 50%.
For communication with external components, a polling loop will be used. During each iteration of the loop, the LCD will be checked to see if any buttons have been pressed. Then, it will be updated with relevant data. If one millisecond has passed, the stopwatch will be incremented and its display refreshed. If 10 seconds have passed, the GPS will be checked and the LCD will be updated with GPS data. If one minute has passed, the battery monitor will be read. After each of these actions, the flags for the timers will be cleared and counting will start again. The SD card will only be accessible from certain parts of the loop and will not require any interrupts.
Interrupts will be needed to drive a clock function within the code. As explained above, this clock will be required to count every millisecond up to one millisecond for the stopwatch, 10 seconds for the GPS, and one minute for the battery. Interrupts will not be needed for any other purpose.
The polling loop will be further controlled by a state machine. Since our program will be using a menu-based GUI, a state machine makes the most sense. Depending on which part of the menu the user is currently viewing, different parts of the program will need to be run.
A flow chart depicting the user interface and the “main” function is seen below.
2. Software Design Narrative
Our basic code outline is described in a functional block diagram below.
The program will start with a Startup block. This will take care of initializing registers, setting the beginning states of the different blocks, and displaying a “welcome” screen on the LCD. This block will finish by starting up the user interface on the LCD screen.
The LCD Control block will take care of displaying information on the LCD as well as handling user interface (button presses). The program will wait for input to this block before continuing. It should be noted that the LCD screen has its own memory. The LCD Control block will not need to keep track of what has been output, but only what needs to be sent at any one moment.
From here, the program will be able to go into the Data Controller block, which can read from and write to the SD memory card through the SD R/W block. If the user wants to read information about previous runs at this point, the Data Controller block will communicate with the SD R/W block to get the data off of the SD card, put it into a format that can be easily interpreted by the user interface, and send it to the LCD Control block. At the end of a run, when the user tells the program to store run data, this block will extract the data from the microcontroller’s flash memory and output it to the SD R/W block in the required format.
When the user decides to start a new run through the user interface, the Data Controller block will begin reading data from the GPS Analyzer block and the Clock block. The GPS Analyzer will read the signals sent to it by the GPS. It will store the last data point read in memory and calculate the distance between successive points based on that information. It will also take Clock data and calculate instantaneous speed at each point. It will then send speed, distance, and coordinate data to the Data Controller to be sent to the controller’s flash and the LCD screen.
The Clock block will simply keep track of time, down to 1 millisecond precision. When a user starts a new run, the Clock will start incrementing a counter every millisecond and sending that counter information to the LCD Control. It will also keep a 10 second counter for the GPS Analyzer and a 1 minute counter for the battery monitor.
The last block is the Battery Monitor block. It will read from the external fuel gauge and send battery life data to the LCD Control in order to display the digital fuel gauge on the LCD. If the battery is low, the Battery Monitor will send a signal to the external speaker every minute to tell the user that the battery is in need of recharging.
10.3 Summary
SHU’s program will utilize a polling loop controlled on higher level by a state machine and controlled from within by clock interrupts.
The SCI and PWM peripherals will be used to communicate with external components. The SCI will communicate with the GPS and SD R/W through a multiplexer and with the LCD screen directly. None of these devices will generate interrupts, so the program will only need to poll the devices when necessary.
The PWM will be used to control the speaker. As such, it will need to divide the clock frequency to a frequency within a good audible range of about 5 kHz to 15 kHz.
[pic]
Figure 6. Hierarchical Block Diagram of Code Organization
[pic]
Figure 7. Flowchart/Pseudo-code for Main Program
10. Version 2 Changes
If we had the chance to do this project again armed with the knowledge we have gained from this process, we would do the following things differently: look at parts more carefully to ensure that they fit our design, have all parts on hand when it comes time to make the PCB, prototype circuits to make sure that the board will work, and get started on testing software earlier.
If we had looked at parts more carefully we could have avoided switching all of our parts halfway through the semester. This way we would not have had to rush and put together a new schematic and PCB after we had already completed it once. This is where many errors came in because we did not have the necessary amount of time to review our design and to make prototyped circuits that are necessary to ensure a working board.
If we had not had to switch our parts, we would also have had them on hand to test the footprints against the ones we had to create for the PCB. Because we did not have our parts on hand, some of our footprints did not match up. Our footprints not matching caused one of our main circuit components, our switching power supply, to not work because it was a fragile piece. This led to a lot of fly-wiring, and therefore caused our power supply to not work. We ended up having to place our whole boost power supply on a different board and attaching the inputs and outputs to the board.
If we had prototyped our circuits, it would have helped us become more familiar with the parts and we would have made sure our circuits worked and known what the footprints are supposed to look like on our PCB. This would have eliminated all of the hassle of trying to fly-wire things to make them work.
If we had gotten started on testing software other than the LCD earlier in the semester we would have had a much greater chance of getting it to work. If we had a couple more weeks we could have worked to figure out how to get the SD reader/writer to work, and we could have examined the GPS hardware to figure out why it is drawing so much current. Mostly it is important to get started as early as we can and not wait until it comes down to the wire.
Summary and Conclusions
By the end of the semester, our power circuit and user interface worked beautifully. The LCD can display all operational menus and a functioning stopwatch. The display showed battery life, GPS information, and the SHU logo. The LED's also reacted to battery life and power. The power circuit correctly boosts the voltage from 4.35v to 5v. It will also recharge the battery and check the battery's life.
On top of these accomplishments, we learned a lot. Everyone on the team learned about different software tools like CodeWarrior and Layout. We learned how to solder. Also, the amount of planning work that went into the project was a huge learning process. We needed to draw up the schematic, figure out operating conditions, create the PCB layout, order the parts, build the circuit, and finally make sure everything worked. The process had a lot of problems along the way, but most of them were solved.
In the end, we had a finished product that didn't work perfectly but still showed off our collective accomplishments.
References
1] 4D Systems Pty. Ltd., “μDRIVE-uSD-G1 USERS MANUAL,” [Online Document], unknown publication date, [accessed September 30, 2008], downloads/micro-DRIVE/uDRIVE-uSD-G1/Docs/Pdf/uDRIVE-uSD-G1_Users_Manual_ Rev1.0.pdf.
2] Freescale Semiconductor, “MC9S12XDP512 Data Sheet,” [Online Document], July, 2007, [accessed September 30, 2008], sheet/MC9S12XDP512V2.pdf.
3] Global Sat Technology Corporation, “GPS Engine Board EM-406a,” [Online Document], unknown publication date, [accessed September 30, 2008], download/46/em406a_ug.pdf.
4] Linear Technology, “Coulomb Counter / Battery Gas Gauge,” [Online Document], unknown publication date, [accessed December 10, 2008], downloadDocument.do?navId=H0,C1,C1003,C1037,C1134,P2354,D1556
5] Matrix Orbital, “GLK19264-7T-1U Technical Manual,” [Online Document], unknown publication date, [accessed December 10, 2008], GLK_series/GLK19264-7T-1U/GLK19264-7T-1U.pdf
6] MAXIM, “1.5A Dual-Input USB/AC Adapter Charger and Smart Power Selector,” [Online Document], April, 2007, [accessed September 30, 2008], /ds/MAX8677C.pdf.
7] Star Micronics, “NDT-03C Specifications,” [Online Document], unknown publication date, [accessed September 30, 2008], .
8] Texas Instruments, “96% Efficient Synchronous Boost Converter with 4A Switch,” [Online Document], April, 2004, [accessed December 10, 2008], tps61030.pdf
9] ULTRALIFE Batteries, “UBBP01 Technical Datasheet,” [Online Document], 2006, [accessed September 30, 2008], UBI-5154_UBBP01.pdf.
10] 411 Technology Systems, “TEG13752 Datasheet,” [Online Document], unknown publication date, [accessed September 18, 2008],
11] Crystal Fontz Liquid Crystal Displays, “CFAG12864C-TMI-TN,” [Online Document], unknown publication date, [accessed September 18, 2008],
12] Etek Navigation, Inc. “EB-85A User Manual, [Online Document], unknown publication date, [accessed September 18, 2008],
[13] Atmel Corporation, “AT90USB646 Data Sheet,” [Online Document], unknown publication date, [accessed September 18, 2008]
[14] Blog, “PCB Trace Width Calculator,” [Online Document], January 31, 2006, [accessed October 10, 2008], pcb-trace-width-calculator/
[15] Garmin, “Forerunner 201 Data,”[Online Document], unknown publication date, [accessed September 25, 2008],
[16 ] Retrevo, “Garmin 40 Personal Navigator Manual,” [Online Document], unknown publication date, [accessed September 25, 2008],
[17] Google, “Google Product Search,” [accessed November 4, 2008], products?client=firefox-a&rls=org.mozilla:en-US:official&channel=s&hl=en&q=GPS+ running+watch&um=1&ie=UTF-8&sa=X&oi=product_result_group&resnum=1&ct=title
[ 18] D. Darcy, P. Flentov, and C. Vock, “Location Determining System,” U.S. Patent 2007/0067128 A1, November 17, 2006.
[19] S. Brunk, D. Downey, C. Fisher, W. Lee, J. Lovitt, R. Moore, and T. Oliver, “Personal Training Device Using GPS Data,” U.S. Patent 2008/0096727 A1, December 13, 2007.
[20] Personal Communication with Tracy L. Olivier, U.S. Patent 2008/0096727 A1 Inventor, November 6, 2008.
[ 21] J. Cullen, C. Eckert, L. Freeman, A. Gifford, B. Higgins, C. Homan, J. Robson, and B. Wetter, “Physical Training System,” U.S. Patent 2004/0046692 A1, September 5, 2002.
[ 22] Battery University, “Is lithium-ion the ideal battery?” [Online Document], April 2003, [accessed November 18, 2008], .
[23] EEP European Environmental Press , “Recycling LCD screens,” [Online Document], September 20, 2007, [accessed November 18, 2008], .
[24] Daily Tech, “Study: Chemical found in LCD displays 17,000 times more warming-effective than CO2,” [Online Document], July 7, 2008, [accessed November 18, 2008], .
[25] UNFCCC, “Kyoto Protocol,” [Online Document], unknown publication date, [accessed November 18, 2008], .
[26] Lentech, “Lead (Pb),” [Online Document], unknown publication date, [accessed November 18, 2008], .
[27] Moltech Power Systems, “Lithium Ion Battery Pack Handling Precautions,” [Online Document], unknown publication date, [accessed November 18, 2008], .
[28] , “Printed Circuit Board Manufacturing,” [Online Document], unknown publication date, [accessed November 26, 2008],
Appendix A: Individual Contributions
A.1 Contributions of Kathleen Klacik:
In this project, my main area of focus was the hardware side. In the beginning, I organized our group meetings and suggested t he idea for our final project proposal. I then wrote up the project proposal and submitted it. I subsequently rewrote it for another submission. My general role as a team member was to organize when we would meet and make sure people were doing their jobs or staying on task. I kept a running list of what still needed to be done and what had been accomplished.
After submission of the project proposal, I began creating the parts spreadsheet to keep track of the parts that we have selected and various important facts about them. I also helped in picking out the parts as we did that mostly as a team. I kept a running list of the parts that still needed to be picked out.
When the parts were picked out it was time to begin looking at how they could be assembled to achieve the desired functionality of our project. Brian and I were the main people that performed this task. We spent a lot of time going through the parts’ data sheets and figuring out what the surrounding circuitry should be for each part. We put together the entire schematic through its many revisions.
Brian and I also spent a lot of time putting together the PCB. We along with Dan put together all of the footprints and the routing for the original PCB. I also did about half of the final PCB routing and submitting.
I did the environmental and ethical impact homework as well as the PCB narrative homework. I also compiled the entire final report and most of the final senior design report. As I previously mentioned I also got together the final project proposal as far as paperwork goes. For the design review I put together most of the slides and made sure everything that needed to be accomplished was.
As far as populating the PCB goes, I got all of the parts ready for Brian to solder and helped him put them on the board. When the power circuitry was on the board we tested it and discovered that the boost was not working but the battery charger was. Brian and I spent a lot of time trying to debug what could be wrong with the boost. We got the power circuit working in the end with a lot of help from Karl and Chuck.
As far as software goes, I put together a bit of the code and really worked on the fuel gauge code over Thanksgiving break. I got this working correctly all by myself. I also did the timer function’s code and the PWM speaker function’s code. I did a lot of research on interrupts and got these working on our device. I also assisted Dan and Kyle (our computer engineering) while troubleshooting what could be going wrong with their code. Brian and I tried to figure out what could be going wrong with it from the hardware side while they tried to figure it out from the software side.
A.2 Contributions of Dan Strauss:
Early on in the project, I wasn't involved all that much. There was a lot of hardware work being done which was left mostly for Brian and Katie (the EE's). As we got closer to doing the PCB layout, I got a lot more involved. I did a lot of the work for component footprint creation and did some of the routing when our schematic was finalized and we were getting close to the deadline for the layout.
After the PCB was done, my main focus was code. I took responsibility of the SD reader and GPS code. These segments went untested for most of the semester since the SD and GPS were not easily testable. After I had finished the preliminary code, I started helping Kyle with the LCD screen programming. He had most of the display (the different menu screens) finished by this point. Where I helped was with getting button presses to register correctly and with programming the stopwatch function.
For the homeworks, I was responsible for the Software Narrative and the Safety and Reliability reports. The Software Narrative was basically a summary of the software work that had been done so far, plus the plans for our upcoming software work. For the Safety report, I looked up a lot of data on some parts from our project and calculated their estimated failure rates. I also determined certain failure modes and the criticalities associated with them.
These were my main responsibilities. Aside from that I had other random jobs. I worked on getting software ported between our different test boards and finally to our own PCB. I personally ordered quite a few parts from TI. I did a few of my own small soldering jobs. I drew the SHU logo. I did my own share of website maintainance. I even ordered pizza for the team once.
Overall, I was one of the main people working on the code. I did my share of the homework and the website and did what I had to to make sure that the software worked correctly with the hardware.
A.3 Contributions of Kyle Anderson:
In the beginning of the project, I was in charge of the LCD screen and packaging. For the first few homeworks I used some CAD software and drew out some sketches of what our final project would look like. I also tried to research a few different enclosures for us to use for the final product. Once we had our first LCD picked out, I started to think about how the code would be structured. Since the first LCD we picked had not onboard controller, we would
have to make all of the bitmaps ourselves. This was a very difficult process, but Dan and me eventually came up with bitmaps for the entire alphabet and a few other characters we would need.
After creating some pseudo code for the main state code, Chuck presented with us a solution to our LCD difficulties. After we switched to the Matrix Orbital screen, things became so much easier. Since we could script all of our menus using the serial port on the computer, I was able to script around 30-40 different menus for our design. In order to communicate with our LCD via SCI, I needed to find some functions to handle the handshaking protocols. After talking it through with Chuck, I was able to find some SCI in and out functions that would handle the handshaking. Everything began to roll from there.
Once I was able to communicate with the LCD, I was able to transform the menu scripts into separate functions that send SCI
commands to the screen. With the separate menus each turned into functions, I could turn my attention to the main program. I tried to approach it from the state machine perspective.
Doing some research online, I found out about the switch statement in C, which is essentially a state machine command. With each menu as a different state, most of the code began to fall in place. To transfer between states, I was able to use the SCI_InChar() function I found online. Since the InChar function waits for a button press, it was relatively easy to change between states, since each press was returned in hex.
The next step was to add functionality to the menus. I started with the stopwatch, since that seemed to be the easiest and most important to implement. After beating my head against the wall trying to print out dynamic data, Dan ironed it out in around 20 minutes. We were able to start and pause the stopwatch once we were able to print out dynamic data.
At the completion of the project, I have menus for the main menu, stopwatch, clear data, and the main trainer menu. The buttons that worked before the Tx pin blew up were enter, up, down, function 1, and function 2. Since we were unable to package our design, I was unable to research and packaging options further. To sum up, my biggest contribution was handling the user interface and creating the main program state machine.
A.4 Contributions of Brian Baumgartner:
My primary contributions to the group included component selection, schematic design, PCB layout design, and all soldering necessary to complete the project. My role was much more hardware intensive than software. Initially, I did a lot of work deciding which components would be best for our desired functionality. I did computations to estimate the power and current consumption of each individual component used in the project. Once components with minimal complexity were selected, I read through all of the datasheets and figured out how to set up each component circuit so that it would function as desired. I created footprints in Capture for many of the components and did a lot of the PCB routing in Layout. I figured out solutions to many of the hardware challenges. Namely, I decided to use a PLD as a multiplexer and demultiplexer to effectively change one SCI port into two. I also implemented hardware to communicate between the microcontroller that operates at 5 volts and the SD reader/writer that operates at 3.3 volts.
As the project progressed and it became evident that there were errors in our schematic design, it became my role to correct the PCB and create circuits on protoboards as necessary. Since the PCB pad for the boost was not accurate, I created the boost circuit on a protoboard. Throughout the software design process, I tested each individual hardware component at times to see if there was ever a failure. For example, after realizing a short from power to ground through the microcontroller, I replaced the microcontroller. Also, after realizing that we had not included a BDM header, I soldered wires to the appropriate pins so that we could program our microcontroller.
From a documentation standpoint, I completed the hardware design narrative and the patent liability analysis. I did research on existing patents from other manufacturers and communicated with an inventor from Garmin to see whether or not our product would face infringement issues. I also represented our team to each of our component manufactures as we called them for technical support.
On the administrative side, I acted as a systems engineer to integrate all of the work done on each function. I aided in debugging the LCD and the SD reader/writer. I was also the primary lead of the power circuit. After analyzing the work done on each part of the project, I considered the component’s interaction with the rest of the components and was accurately able to identify errors to obtain product functionality.
Appendix B: Packaging
[pic]
Figure B-1. Side view of outside product packaging with view of power switch.
[pic]
Figure B-2. Side view of outside product packaging with view of AC power jack.
[pic]
Figure B-3. View of arm strap configuration
Appendix C: Schematic
[pic]
Figure C-1. Schematic view of the microcontroller circuit
[pic]
Figure C-2. Schematic view of the power supply circuit
[pic]
Figure C-3. Schematic view of the boost switching power supply circuit.
[pic]
Schematic C-4. Schematic view of all components and their respective circuits
Appendix D: PCB Layout Top and Bottom Copper
[pic]
Figure D-1. View of the Top Copper layer of the PCB with the silkscreen showing
[pic]
Figure D-2. View of the Bottom Copper Layer of the PCB with the silkscreen showing
Appendix E: Parts List Spreadsheet
|Vendor |Manufacturer |Part No. |Description |Unit Cost |Qty. |Total Cost |
|US Global Sat |US Global Sat |EM-406A (SiRF III) |GPS Receiver |$46.99 |1 |$46.99 |
|Matrix Orbital |Matrix Orbital |GLK19264-7T-1U-GW |Intelligent LCD display with buttons |$89.95 |1 | $89.95 |
|SparkFun |4D Systems |BOB-08567 |SD Card Reader/Writer |$37.95 |1 |$37.95 |
|Sandisk |Sandisk |Sandisk MicroSD |Micro SD Card |$9.99 |1 |$9.99 |
|Mouser |Ultralife Battery |UBBP01 |3.8V rechargeable lithium ion battery |$14.45 |2 |$28.90 |
|Newark |Farnell |24M5237 |Small Speaker |$3.66 |1 |$3.66 |
|Maxim IC |Maxim IC |MAX8677C |Battery Charging IC |Samples |3 |Samples |
|Linear |Linear |LTC4150 |Fuel Gauge IC |$2.02 |2 |$4.04 |
|TI |TI |TPS61030 |5V Switching boost power supply |Samples |6 |Samples |
|Digikey |CUI |T314-P6P-ND |ACDC Wallwart Adaptor |$7.38 |1 | $7.38 |
|Digikey |CUI |CP-002BPJCT-ND |AD Connecter |$0.81 |1 |$0.81 |
| | | | |TOTAL |$229.67 | |
|A1 |Output = 0 V |Complete failure of |Device is “frozen” – will not|Observation |Medium |Failure or damage to microcontroller |
| | |microcontroller, C12, C13, C14, |change from previous state | | |will be difficult to fix |
| | |C15, or failure in blocks B or C | | | | |
|A2 |Outputs don’t change |Failure or crystal, oscillator |Device doesn’t change from |Observation |Low to Medium |Failure or damage to microcontroller |
| | |circuit, or microcontroller |previous state | | |will be difficult to fix |
|A3 |Output > 5 V |Failure of blocks B or C |Potential damage to any |Observation – heat and |High |May cause overheating and potential |
| | | |component in the device |loss of functionality | |harm to the user |
Boost – Block B
|Failure No. |Failure Mode |Possible Causes |Failure Effects |Method of Detection |Criticality |Remarks |
|B1 |Output = 0 V |Failure of block C, C32, C34, or |Other components stop working|Observation |Low |No heath risk; damage to components |
| | |R37 and R38 | | | |outside this block would be minimal |
| | | | | | |at most, unless the failure comes |
| | | | | | |from block C |
|B2 |Output > 5 V |Failure of boost or block C |Damage to many components and|Observation – heat and |High |Poses a potential risk to the user |
| | | |complete failure of the |loss of functionality | | |
| | | |device itself | | | |
|B3 |Noisy output |Failure of boost, L1, C37 or |Unpredictable; depending on |Observation – random |Low |Damage to components is unlikely; |
| | |either C32 or C34 (but not both) |the noise levels, other |behavior from device | |repair should be simple |
| | | |components will behave | | | |
| | | |erratically | | | |
Power – Block C
|Failure No. |Failure Mode |Possible Causes |Failure Effects |Method of Detection |Criticality |Remarks |
|C1 |Output = 0 V |Failure of battery, charger, C23, |Most components in all blocks|Observation |Low | |
| | |SW8, or R22 and C24 |stop working | | | |
|C2 |Output > 3.7 V |Failure of adaptor or severe |Potential damage to many |Observation – heat and |High |Poses a health risk to user; |
| | |battery failure |device components |loss of functionality | |difficult to impossible to fix |
Data – Block D
|Failure No. |Failure Mode |Possible Causes |Failure Effects |Method of Detection |Criticality |Remarks |
|D1 |LCD Tx/Rx = 0 V |Failure of LCD screen |LCD screen doesn’t work as |Observation |Low |Unless failure is in another block, |
| | | |expected or at all | | |repair should be simple |
|D2 |GPS Tx/Rx = 0 V |Failure of GPS or Multiplexer |No data is received from GPS;|Observation – GPS-related |Low |Unless failure is in another block, |
| | | |distance and speed won’t be |data won’t be updated | |repair should be simple |
| | | |updated | | | |
|D3 |SD Reader Tx/Rx = 0V |Failure of SD Reader, SD card, |Data can’t be read to or from|Observation – |Low |Unless failure is in another block, |
| | |U22, D1, or Multiplexer |the SD card |communication with SD card| |repair should be simple |
| | | | |will be lost | | |
|D4 |Speaker input voltage < 5 V |Failure of Q1, speaker, or block A|Warning beeps won’t be as |Observation |Low | |
| | | |loud or will not work at all | | | |
-----------------------
Kyle Anderson
Figure 5
Brian Baumgartner
Dan Strauss
Figure 2
Figure 4
Katie Klacik
................
................
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
- project final report template
- project final summary report template
- final grant report sample
- final grant report example
- final evaluation report example
- project management final report example
- project management final report template