ee 477 final report - purdue engineering...software, pcb and schematic design process while also...

ECE 477 Final Report − Spring 2013 Team 13 − Vitalis

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

Shantanu Joshi /Aakash Lamba / Di Mo / Yi Shen

ECE 477 Final Report Spring 2013

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.................................................................... 2 4.0 Patent Liability Analysis ...................................................................................................... 6 5.0 Reliability and Safety Analysis .......................................................................................... 10 6.0 Ethical and Environmental Impact Analysis...................................................................... 13 7.0 Packaging Design Considerations ...................................................................................... 15 8.0 Schematic Design Considerations ...................................................................................... 18 9.0 PCB Layout Design Considerations .................................................................................. 20 10.0 Software Design Considerations ........................................................................................ 21 11.0 Version 2 Changes ............................................................................................................. 25 12.0 Summary and Conclusions ................................................................................................ 25 13.0 References .......................................................................................................................... 26 Appendix A: Individual Contributions ..................................................................................... A-1

A.1 Contributions of Shantanu Joshi: ................................................................................. A-1 A.2 Contributions of Aakash Lamba: ................................................................................. A-2 A.3 Contributions of Di Mo: ............................................................................................... A-3 A.4 Contributions of Yi Shen: ............................................................................................ A-5

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 ......................................................................................... D-1 Appendix F: FMECA Worksheet ................................................................................................. 1

-ii-


Abstract In this report we outline our progress in building a novel Biometric sensor using a custom built pulse-oximeter sensor. We outline our success criteria and provide an in depth view of our Software, PCB and Schematic Design process while also enumerating on other essential considerations like Component Selection, Patient Liability, Ethical and Environmental Impact and Reliability and Safety Analysis. We conclude with a discussion of improvements that can be incorporated in a second version of our device. 1.0 Project Overview and Block Diagram Our device measures a patient’s pulse, oxygen-saturation and skin temperature and also has the ability to automatically trigger an alarm upon detecting anomalous readings. We have also built a companion web-app which receives data transmitted wirelessly from the device to our servers and thus allows the doctors and other care providers to remotely monitor the patient at all times. In order to make our device more robust we have also added the ability to detect if the user has suffered a fall and appropriately raise an alarm.

Figure 1.1: A view of the completed project.

-1-


Figure 1.2: Block diagram of our project. . 2.0 Team Success Criteria and Fulfillment

1. An ability to determine pulse and Spo2 readings from blood light absorption. 2. An ability to display the user’s vital statistics on the OLED screen. 3. An ability to remotely monitor a users medical status from a website via secure login. 4. An ability to activate an alarm automatically in response to anomalous readings of vitals. 5. An ability to detect if the user has suffered a fall.

All the Success criteria were successfully achieved and demonstrated to the course staff. 3.0 Constraint Analysis and Component Selection Design Constraint Analysis There are three major design constraints that are fundamental to our project: portability, reliability, and longevity. Portability is important because the device itself sits entirely on the

-2-


user’s wrist, and thus must be compact and lightweight as not to be a hindrance. Reliability is critical because our target market is hospitals, so we need additional redundancies and a design not prone to failure. Finally longevity, specifically in regards to battery life, is tied directly with portability and needs to be long enough that the device can serve a practical purpose away from the wall socket. Interface Requirements The only general-purpose I/O functions we need are for the push-button, which requires only one. This is because all of our sensors run off various protocols or gives us analog data, and thus don’t need GPIO pins. All our other modules, including the OLED, Wi-Fi, and battery fuel gauge also run off specific protocols (UART for the OLED and Wi-Fi and I2C for the fuel gauge). As such, there isn’t much in terms of GPIO necessary for our device, and as for the push-button it’s a passive device running off line voltage and thus has negligible voltage/current constraints. On-Chip Peripheral Requirements On-chip peripherals are the main drivers behind our microcontroller selection, and thus constitute a large portion of the requirements. We need to support 2 channels of UART to facilitate communicate with the Wi-Fi and OLED module. We also need one I2C channel as both the temperature sensor and battery fuel gauge utilize the protocol. Additionally, we need 3 ATD channels with standard resolution (8-10 bit) to interface with the accelerometer. Finally, we need an external interrupt pin for the SPO2 and Pulse sensor. Off-Chip Peripheral Requirements Our entire design is focused on interfacing with various off-chip peripherals in order to collect, process, and send/display vital health statistics. Starting off with the sensors, we need a 3-axis accelerometer for fall detection, a temperature sensor to measure skin temperature, and we’re building our own SPO2 + Pulse sensor using a photoreceptor chip. In order to locally display this data, we plan on using an OLED screen mounted on the device which will also act as a redundant access to information in case Wi-Fi ever goes down. For transmission of the data we need a dedicated Wi-Fi module to handle wireless protocol and send the information to an access point (i.e. a router). We also need peripherals to handle the charging (charge controller) and monitoring (fuel gauge) of the on-board battery as well as a DC-DC converter to give us regulated 3.3 and 5 V outputs. Power Constraints Power is a huge design constraint, as the entire device will run off of battery for the majority of the time. As such, the design itself must be relatively low-powered constraining the

-3-


computational capabilities of the microprocessor (which is alright since earlier it was discussed that we have low computational requirements) as well as the number/type of dedicated peripherals on board. It also requires additional circuitry to monitor and charge the battery so that the device can perform reliably for long periods of time. Potential heat is minimized because of the necessary low-power requirement and the planned use of a switched-mode DC-DC converter meaning that losses and heat generation through voltage conversion will be minimal. Also, planned use of a high-capacity lithium battery should allow for ample battery life. Cost Constraints Currently, our prototype will cost within the range of $200 to $300 dollars per unit with the majority of the costs attributed to the OLED screen, Wi-Fi module, and sensor array. There are products similar to ours that are retailing for $300 - $400 [1] without any advanced web-monitoring. As such, we believe that if our product were to be mass produced not only would it undercut the current offerings in terms of price but also offer additional portability and features through Wi-Fi and NFC. Component Selection Rationale The most important component that we looked at was the microcontroller, and we narrowed it down to 2 which are compared in a table below:

ATmega1284 [2] PIC32MX250F128D

Supply Voltage 1.8-5.5 V 2.3-3.6 V Active current draw (8 MHz) 12 mA @ 5 V 10.5 mA @ 3.6 V I2C channels 1 2 SPI 1 2 UART 2 2 Internal Oscillator 8 MHz 8 MHz Pin count 44 44 Memory 16k RAM/ 128k flash 32k RAM/ 128k flash Additional Info Available in 40 pin PDIP built-in USB Cost $7.22 $4.81 Both microprocessors come with all of the necessary on-chip peripherals we need as well as internal oscillators (lowers part count, cost, and power consumption). They are also quite similar in terms of power draw and package size with the PIC winning slightly in the amount of RAM available. However, the availability of the Atmel processor in a PDIP package, meant that we could prototype much easier and also fully verify our design before the PCB gets populated. The

-4-


flexibility of the voltage also lends to greater freedom in overall system design. As such, even though it is pricier per unit, we decided to go with the ATmega1284 as it provides more advanced prototyping and freedom in voltage selection. Moving on, the next major part that needs to be looked at is the Wi-Fi module and the ones that looked promising are compared below:

RN-XV WiFly Module [3] MRF24WG0MA

Sleep 4 uA 250 uA Idle current 15 mA 10 mA Tx current 180 mA 240 mA Antenna Integrated wired Integrated PCB trace Mounting Header pins Surface mount

Both have an advanced TCP/IP stack and will handle a lot of the lower level Wi-Fi functions (AES encryption, Wi-Fi authentication etc.). However, the WiFly module has lower current draw (they both run at 3.3 V) during transmission and sleep which are the most important stages (the device itself will receive little to no data from the access point). Also, the header pins means easier prototyping as well as mounting as the MRF24WG0MA requires solder reflow to mount on our PCB. As such, the ease of use and lower power consumption lead us to using the RN-XV WiFly Module as our Wi-Fi module. The other sensors have relatively simple requirements and due to the length of the report it is not feasible to go through all of them. Just as well, the OLED and fuel gauge/charging units are very standard units and have much smaller tradeoffs to be compared and made Summary In summary, our design is heavily driven by a certain subset of constraints which are: portability, reliability, and longevity. We address portability by limiting parts and PCB size in order to make the device small and easily wearable on the wrist. Although there was no specific section earlier to address reliability, the design itself will feature a short BOM in order to limit failure due to components. Just as well, the modularity of the sensors means that if one malfunctions the entire device will not be compromised. Finally, should Wi-Fi be spotty or go down the OLED screen provides another point of access and being battery powered means the ability to carry spares in case of emergencies. Lastly longevity is designed for by using low-power components, an efficient switch-mode DC-DC converter for regulated voltage, and high capacity lithium cells. In the end, we believe that our current part selection and build plan meet our design and cost requirements.

-5-


4.0 Patent Liability Analysis Results of Patent and Product Search The results of our patent search and similar products in the market are listed below: 1. US patent 6,102,856 – Wearable vital sign monitoring system [4]

Date of patent: August 15, 2000 Abstract: The proposed invention in this patent is a wearable vital sign monitor which is worn around the user’s chest (below the pectoral muscles). The vital signs recorded include ECG data, respiration rate, pulse rate, oxygen uptake and body temperature. It also detects anomalous conditions in the readings of these vital statistics and based on those, sends a signal to an attendant in a remote facility who ascertains whether help is required and dispatches medical help. The device has GPS capability to locate the user. Also, the device is capable of producing periodic reports of recorded health statistics. Potential infringement exists for the following claims: - Claim 1:

A vital sign monitoring system, comprising: a skin-engaging unit carrying

vital sign sensor means for acquiring vital sign data about a user\said vital sign sensor means having an output, and

means responsive to said output of said vital sign sensor means for collecting and storing said vital sign data,

means in operative connection with said collecting and storing means for analyzing said vital sign data to detect anomalous vital sign conditions, wherein said analyzing means detects normal vital sign conditions from statistical analysis of vital sign data,

means for transmitting signals from said unit when anomalous vital sign conditions are detected by said analyzing means, and

means for receiving voice signals transmitted to said unit.

- Claim 16: A method for monitoring vital signs, said method comprising the steps of: sensing vital sign data of an individual;

collecting and storing said vital sign data;

analyzing said collected and stored data to detect nominal an anomalous vital sign conditions;

-6-


transmitting a signal to a remote central facility in the event an anomalous vital sign condition is detected; and

enabling voice communication between said user and said central facility.

2. US patent 6,314,058 B1 – Health watch [5] Date of patent: November 6, 2001 The device proposed in this patent is a health watch which has a variety of functions which includes an atmospheric air thermometer, a body thermometer, a cardiac beat meter, display and audio playback of pulse sound waves and a blood pressure meter. All the sensors are attached in contact with the user’s wrist. The display has various windows to display the measured data. All of these features are combined into a wrist watch. Potential infringement exists for the following claims: - Claim 7

A health watch for use in monitoring the health state of the user and which includes a plurality of high function integrated circuit (IC) counting elements for display of data, the health watch comprising: a watch case adapted to be worn on the wrist of a user, said watch case having a back face which lies against the user's wrist and a front face provided with a plurality of display windows including a body temperature display window, a cardiac beat rate display window, a blood pressure display window, a cardiac beat wavelength display window and a time display, window;

each of said plurality of display windows being provided with a respective one of said plurality of IC counting elements;

a body temperature sensor installed on said watch case back face, said body temperature sensor operative to input body temperature data to a respective IC counting element for display on said body temperature display window;

an adjustable watch band for securing said watch case to the wrist of the user, said watch band having a backside facing the wrist of the user;

a normally flat rubber tube secured to said backside of said watch band;

a cardiac beat and blood pressure sensor installed on said rubber tube and operative to detect pulse signals and input as electronic signals to respective ones of said IC counting elements for display on said cardiac beat rate display window, said blood pressure display window and said cardiac beat wavelength display window; and

said cardiac beat and blood pressure sensor located on said rubber tube a sufficient distance from said watch case to permit normal viewing of said front face without

-7-


substantial wrist rotation being necessary when said cardiac beat and blood pressure sensor is positioned over the blood vessel of the wrist.

3. Similar product – ViSi Mobile health monitor (developed by Sotera Wireless Inc.) [6] Patent application number: 12/762,790 (pending) Filing date: April 19, 2010 This product is quite similar to our design. It is a body-worn vital sign monitor that measure vital statistics which include blood pressure, SpO2, heart rate, respiratory rate and temperature. It also characterizes the activity state of a patient (i.e. resting, walking sleeping etc.). The device features a graphical user interface that in touch screen and provides a number of functions. Data collected by the device is transmitted wirelessly to a central server (over WLAN). Considering the patents for this device are still pending, we are currently not infringing on any of their intellectual property.

Analysis of Patent Liability

Starting with claim 1 of the first patent (6,102,856), one can see that we do under the doctrine of equivalents infringe on the claim since our device is also a skin engaging unit which acquires vital sensor data using sensors. There is a subtle difference in the fact that our sensors are external to the main device and that our device unlike the one in the patent is mounted on the users’ wrist as opposed to underneath the chest. Both devices detect anomalous conditions in the vital signs reading and transmit a signal based on the values. However, the method for transmission is substantially different. The device in question sends voice and data signals over cell phone network, while our device utilizes Wi-Fi, therefore the range of operation our range of operation is limited by the presence of a WLAN network. Claim 16 states that vital readings are sent wirelessly to a central location. As has been mentioned above, transmission methods are completely different. Also, the central location in both devices is completely different. Our device sends data to a web server, while the device in the patent calls an attendant at a remote facility over cell network [5]. The second patent that was studied was that of the health watch. Claim 7 of the patent states that the device will be an adapted watch case which will be worn around the user’s wrist. Our device is mounted in a very similar fashion. However, the packaging will be substantially different (in the sense that dimensions, display, locations of sensors etc. will all be different) and that mounting a device onto the wrist is not a novel thing. The functionality that the patented device shares with our design is the pulse measurement and the temperature sensing. For temperature sensing we used an off the shelf part which means we are not liable for it. The method that we use for measuring pulse is very different from the method used in the patented device. The health watch uses audio signals to count pulse. Beats are recorded in the form of audio which is subsequently processed for pulse values. We employ a completely optical approach where our

-8-


pulse apparatus uses an optical sensor to measure blood oxygen changes on the patient’s finger tip. We then process that information to get values for pulse [4]. As mentioned earlier, the ViSi mobile health monitor by Sotera Wireless inc. is the most similar product to our device. Our device does infringe on the form factor of the ViSi mobile health monitor (under the doctrine of equivalents). That being said the idea of mounting of a device on one’s wrist, like a wrist watch is not a novel one. The ViSi monitor transmits wirelessly using P2P communication and over 802.11 network protocols which is basically Wi-Fi. We also plan to use Wi-Fi to wirelessly send data to an online server. However, the difference lies in the fact that the ViSi operates completely within the hospital network (locally), while our server is hosted on the web which means that patient records can be accessed even when a patient’s caretaker is far away. The only commonality in the two designs is Wi-Fi which is something that Sotera cannot patent. Also, the user generated alarm is through the touch screen UI, while we use a physical button on our device. Since Sotera’s patents are still pending, technically, we are not infringing on any of their intellectual property [4]. Action Recommended Even when considering infringement under the doctrine of equivalents, the potential infringing functions, are performed substantially differently. Examples of this include the different modes of transmission used in the alarm system in the case of patent 1. Also, when considering the health watch (patent 2), our device performs the pulse measurement function very differently. Due to this we do not need to make any substantial changes to our product. However, the ViSi mobile patents have not been granted, but if they are in the future, we might have to make some changes to our design since our product is very similar to it. These changes could include changing the form factor of the device and/or changing the locations of where the sensors are mounted. Also, there are certain enhancements, which we may never make to our device. These could include adding voice alarms/commands/alerts in our device and using a touch screen UI. Summary In Summary, our design is most similar to the ViSi mobile health monitor. However, since the patents for the ViSi mobile health monitor are still pending, we are not liable to infringement of that product. The patents that are most relevant to our design are that of a wearable vital sign monitoring system and a health watch. The wearable vital monitoring system is a portable device with alarm functionality. Though our product might be infringing on the design under the doctrine of equivalents, the way we realize our design is very different in terms of both packaging and the alarm system. Also, in the case of the health watch, our detection mechanism for pulse is completely different. Due to this we currently do not need to make significant changes to our product.

-9-


5.0 Reliability and Safety Analysis Reliability Analysis The three components included in our design that are not part of premade commercially available devices are Atmel ATmega 1284 microcontroller [2] TSL230ARD-TR light to frequency converters [7] (Mouser Electronics), RN-XV WiFly Module (RN-XV WiFly Module - Wire Antenna). [3] All three components are likely candidates to fail due to their high level of complexity. Microcontroller

Model: Monolithic Bipolar and MOS Digital Microprocessor Devices λP Calculation λP = (C1πT + C2πE)πQπL [8]

Parameter Description Value Comments

C1 Die

Complexity Constant

0.14 8-Bit Microcontroller

πT Temperature Coefficient

3.1 Maximum Operating Temperature: +𝟏𝟐𝟓 (℃) [2]

Digital MOS, VHSIC CMOS

C2 Pin Number

Constant 0.021

44-pin SMT (Nonhermetic) [8] 𝑪𝟐 = 𝟑.𝟓 × 𝟏𝟎−𝟒(𝑵𝑷)𝟏.𝟎𝟖 = 𝟎.𝟎𝟐𝟏

πE Environmental

Constant 4.0 Mobile Ground Environment

πQ Quality Factor 10 Other Commercial Level

πL Learning

Factor 1 Greater than 2 years in production

λP 5.18 failures per 106 hours MTTF 22.037 years per failures

Light To Frequency Converter

Model: Monolithic MOS Digital and Linear Gate / Logic Array Devices λP Calculation λP = (C1πT + C2πE)πQπL [8]


-10-


C1 Die

Complexity Constant

0.010 Digital

Less than 100 gates


0.60 Digital MOS, VHSIC CMOS

Maximum Operating Free-air Temperature:+𝟕𝟎 (℃) [𝟕]

C2 Pin Number

Constant 0.0034 8-pin SMT (Nonhermetic) [𝟕]

πE Environmental



πL Learning



Wi-Fi Module

Model: Monolithic MOS Digital and Linear Gate / Logic Array Devices λP Calculation λP = (C1πT + C2πE)πQπL [8]


C1 Die

Complexity Constant

0.010 Digital

Less than 100 gates


0.60 Digital MOS, VHSIC CMOS

Maximum Operating Temperature:+𝟕𝟎 (℃) [3]

C2 Pin Number

Constant 0.0083

20 Pin Dual Dual In-Line Package with unknown seal type [3]

𝑪𝟐 = 𝟗.𝟎 × 𝟏𝟎−𝟓(𝑵𝑷)𝟏.𝟓𝟏 [8]

πE Environmental



πL Learning



Failure Modes, Effects and Criticality Assessment (FMECA)

-11-


Microcontroller System Given the lifetime of all the passive components (such as capacitors and resistors) on the board, it is possible that those passive components get shorted as time goes by. Microcontroller can overheat if decoupling capacitors C3, C7 and C9 get shorted. I2C bus would not work if the pull-up resistors are open-circuited. Failures can be easily detected based on the overall functionality of the system. Such failures would cause the microcontroller failing to collect data from the fuel gauge and the digital temperature. Thus both failures are considered having medium criticality. In addition, bad reset button may cause failure for the user to reset the microcontroller and entire system back to the initial state. Such failure mode should be observable from the user operation of the device. Though the failure would be considered with low criticality, it makes the device very inconvenient for the user to use. Sensors System All the sensors are premade breakout boards with relatively high reliability. They are connected with the main module by using wires. With different patient’s movements and postures, it is likely that those wires gradually wear out and lose connections with sensors or the main module. The failure would make the microcontroller unable to communicate with different sensors. Thus the microcontroller would not be able to obtain accurate readings or possibly control sensors properly. In addition, optical sensor in the SpO2 sensor may gradually wear out as users frequently use it. This could extract inaccurate readings for the pulse rate and oxygen concentration level from the patients. Failures can be easily observed through the device calibration check. Though such type of failures largely limits the device functionality, but is considered medium criticality because it doesn’t completely eliminate the entire system functionality. External Interfaces System Both OLED screen and the Wi-Fi module have good reliability. However, given decoupling capacitors shorted, Wi-Fi module would be shorted with 3.3V power and GND [3] and gets damaged. Antenna on the module can also be worn out due to user’s inappropriate postures and use. Both failures would completely eliminate the communication between the device and online server. So users wouldn’t be able to retrieve on-device data and display them on the website. However, such transmission failures can be quickly detected through checking the data stream status on the webserver. Power Management System The power management system consists of three pre-made breakout boards: charger/booster, fuel gauge and 5V step up. They are relatively reliable in terms of safety. However, they can still cause some failures with medium criticality that shut down the whole system. If the switch for the charger/booster is broken, the battery would either never get charged or keep getting charged.

-12-


If the battery is never getting charged, the overall system would not be able to sustain and provide functionality to the users for a long consistent time period. If the battery keeps getting charged, its longevity would largely get reduced. Though such failures cause a lot of inconvenience to the users, it doesn’t affect any of the main functionality for the design. Furthermore, the battery would over-heat if the charger draws too much current to the battery. Users usually would feel the heat dissipation as the device is mounted on the user’s wrist.

Summary This report outlines several reliability and safety issues. Some of the most unreliable components in the design are the microcontroller, the analog-to-digital converter module and the switch mode power supply that powers the single board computer. The microcontroller and analog-to-digital converter module are likely to fail due to their high level of complexity and the switch mode power supply is likely to fail due to the high levels of power it is required to supply. 6.0 Ethical and Environmental Impact Analysis Environmental Impact Analysis Environmental Impact [Manufacture] The manufacture of our health sensor will involve the fabrication of a custom Printed Circuit Board (PrCB) in order to increase its portability and ensure that it can function in a robust manner in a variety of environments. Apart from our custom PrCB we will also be using a small number of sensors (ADXL, Temperature sensor, SpO2 sensor and Fuel gauge) which come on their own PrCB In Asia, where three-quarters of the worlds PrCB are fabricated, manufacturers use glycol ethers as their major solvent. Additionally hazardous chemicals such as formaldehyde, dimethylformamide and lead are used in large quantities. A large number of workers are exposed to chemicals, which are known reproductive toxins and carcinogens [9]. The toxic wastes from these processes is often dumped into rivers and oceans contaminating our water supply and associated ecosystems. The custom PrCB is used to interconnect different sensor and chips together into one cohesive system controlled by a microcontroller. The different components are soldered on the PrCB. Lead is used in the soldering process in the form of lead/silver filler metals. When heated lead oxide fumes are formed, excessive exposure to which can result in lead poisoning [10]. Last but not the least, we will be using a plastic box or 3D printed plastic to package our design.

-13-


While, plastic is very cheap and convenient to use it is not biodegradable and can have undesirable effects on our environment Environmental Impact [Normal Use] Our health sensor does not have a big environmental footprint in and of itself while in operation. Our carbon footprint comes from using electricity to recharge the battery that is used to power the device and more significantly from Data centers which are used to host our web site. Recently, the entire ICT (Information Communication Technology) sector was estimated to be responsible for about 2% of global Carbon emission with datacenters accounting for 14% of the ICT carbon footprint [11]. Environmental Impact [Recycling] Printed Circuit Boards are very difficult to recycle. They contain excess heavy metals and should not be disposed of in landfills. They consist of Mercury, Bromine, flame retardant and lead which could threaten our groundwater supply if they are dumped in a landfill. The LiPo (Lithium Polymer) battery that we use can be recycled and is environment friendly but only after it has been completely neutralized. Detailed instructions of how to take care and dispose of a LiPo battery can be found here [12] and here [13].

The OLED screen contains hazardous chemicals like mercury and needs to be recycled appropriately. Many of our other peripheral sensors like accelerometer, WIFI shield, temperature sensor and custom SpO2 sensor can easily be sold for scrap or safely discarded using the same procedures as one would for a PrCB. Minimizing Environmental Impact Reducing the size of our PrCB can mitigate the environmental impact of our product. This can be accomplished by building our own sensors instead of using breakout boards and shields. We were unable to do this due to lack of time. Additionally, using RoHS (Restrictions of Hazardous Substances Directive) compliant vendors can minimize the harmful environmental impact due to PrCB manufacture. Ensuring our device has optimal power management and does not unnecessarily draw excess current can help save on power costs and lower the device’s carbon footprint. Proper disposal of the LiPo batteries as outlined in the resources above can help save the environment from further damage. Lastly, all parts that have to be disposed off should be done so in accordance with guidelines provided by WEEE (Waste Electrical and Electronic Equipment Directive)

-14-

http://www.e-fliterc.com/ProdInfo/Files/EFL%20LiPo%20Warning.pdf

http://thunderpowerrc.com/PDF/DISPOSAL-OF-LIPO-BATTERIES.pdf


Ethical Challenges As our product will be a medical device there are many ethical issues, which need to be resolved. First and foremost we must ensure the accuracy of all our sensors. Since our temperature sensor, fuel gauge and Accelerometer are commercially manufactured we have no control over their quality but have extensively tested them and found them to be reliable for our application. The same cannot be said for our custom SpO2 sensor. We have been tweaking our algorithm to ensure that it conforms to commercial standards and expected calibrations as listed here [14] In such a device having a false negative can be fatal and we need to conduct adequate testing under different circumstances and environments to ensure that the risk of not detecting a life threatening condition is minimized. Also, customers should have full knowledge of our test results while buying the product so they can make an informed decision. Currently our micro of choice is not certified for use in life critical applications. It is a design choice we made early on in the planning process and forgot to consider this detail. If we were to bring our product to market we would have to use a suitable microcontroller. Built in system redundancies like our OLED serve a dual function to make our design more robust. It serves to display the health parameters to the patient and also provides a failsafe in case the WiFi chip stops functioning. There is also a manual alarm button incase our automatic algorithms do not detect any anomalous readings. Lastly on the Software Front we would have to take adequate care to ensure the safety and security of highly sensitive and private medical data. This can be accomplished using a secure website and taking appropriate backend measures like encrypting all the sensitive data. While we have implemented a secure web site for access we have not yet encrypted the stored data and will do so if the product is taken to market. Summary The major environmental issues associated with our product stem from the manufacture of custom Printed Circuit boards, use of data centers for web hosting and proper disposal of our LiPo battery and associated circuit components. Ethical issues regarding accuracy and privacy of readings in life critical conditions have also been addressed. 7.0 Packaging Design Considerations Commercial Product Packaging Product1

-15-

http://www.mountainside-medical.com/product_downloads/h/how-can-spO2-readings-change.pdf


The IntelliVue MX40 monitor from Philips is a portable health monitor, which is hung from a patient’s neck. The device utilizes short-range radio to transmit vital health parameters and statistics [15]. However, it communicates only with IntelliVue patient monitors. This monitor is hung around a patient’s neck using a clear pouch, which is also water resistant. Water resistance is a good feature; however, hanging the device from a patient’s neck can be inconvenient for a patient since the entire package is cumbersome. The product is a bar shaped device very similar in size and shape to a modern day smart phone (exact dimensions have not been published) and has a 2.8’’ touch screen display. The touch sensitive display is a good feature as it allows ease of access and is more intuitive. The biggest drawback in this form of device is the fact that sensor wires from the device extend all over the chest since it is mounted around the neck. This is similar to how sensors are laid out over the body in conventional bedside monitors. Our device will not have any sensor wires extending up to the patient’s chest. Product2 The ViSi Mobile health monitor is a wrist-mounted health monitoring device that collects and transmits health parameters through Wi-Fi [16]. Its packaging is more in line with our product, as compared to the IntelliVue monitor (described above). A pulse oximeter sensor is placed on the patient’s finger while respiratory sensors, ECG and temperature sensors are attached to the patient’s chest which is much better than the first product (Philips IntelliVue). The device features a 160X128 pixel touch sensitive OLED display [16]. The form factor for this device makes it very convenient to use as it is small, portable and light-weight. Also, the capsule shape of the main device prevents any sharp edges. It operates using a single Li-Po battery. However, this device lacks on board recharging. As mentioned above, our device is also placed on a patient’s wrist and we plan to do so using a neoprene band with Velcro.

Figure 7.1 a) Philips IntelliVue MX40 b)ViSi Mobile monitor Project Specific Packaging

-16-


As mentioned in the introduction section, our main constraints are size, weight and portability. The device must me portable such that a patient may move around while carrying it. It should operate wirelessly so as to enable patient mobility. It must also be light weight. Since the average weight of a smart phone is 120 g (the iPhone weighs 112 grams [17]), we are targeting something on the order of 100-150g. The device needs to be small since it needs to be mounted on to the user’s wrist. We are aiming to make the breadth less than 5 cm. The average wrist is approximately 4.7cm in diameter. Our device will be placed on the patient’s wrist using a neoprene band fastened using Velcro. We plan to buy a sports armband which is used for securing smart phones/mp3 players while exercising and use it for mounting the device on to a patient’s wrist. These are relatively inexpensive and can be purchased for less than $5. On our main device the user will be able to access only the OLED and the user alarm button. The rest of the design will be housed in plastic packaging, which should also be inexpensive as we can buy plastic cases to fit our needs online. The antenna from the Wi-Fi module will be outside the plastic housing for better communication. The estimated dimensions of our main device are 45.8 X 38.1 X 18.9 mm. The battery pack will be mounted separately on the neoprene band and will add approximately 20 g to the design. This module includes the power management system i.e. recharging and fuel gauge. The pulse oximeter will be placed on the patient’s finger using a plastic clip while the accelerometer will be placed on the patient’s shoulder (by clipping on to clothing). The temperature sensor will be placed underneath the wrist band PCB Footprint Layout To save on space occupied by the microcontroller on the PCB, we plan to use the TQFP-44A packaging, which is a square, 44 pin, and 10 mm X 10 mm package [18]. The largest consumer of space on the PCB will be the Wi-Fi module, which measures 35 mm X 25mm [3]. None of the sensors will be placed on the PCB itself; therefore standard 0.1’’ headers have been added to connect the sensors to the main PCB. These sensors include the temperature sensor, the accelerometer and a custom pulse oximeter. The OLED display, which shall cover most of the PCB’s surface area, will also be connected using a standard 0.1’ header. The preliminary schematic for the device currently measures 67 mm X 47 mm which is well within design constraints. Summary In summary, the proposed packaging specifications meet our design constraints. The entire device is estimated to be less than 5 cm wide and weigh around 150 grams. Also, by mounting the device to the wrist, we eliminate the need to have sensor cables extend over the patient’s body (apart from the arm) and this greatly aids the user’s mobility. The current PCB is 4.7 cm by 6.7 cm. This size is expected to decrease since, after laying out traces extra space shall be

-17-


eliminated thereby making the design more compact. Also, packaging is expected to be relatively inexpensive as most of the parts required can be purchased for a small amount. The tooling requirements are very minimal as the only tooling required is cutting spaces in the housing to accommodate the OLED display and the user alarm button. 8.0 Schematic Design Considerations Theory of Operation There are four major subsections of the circuit: the battery monitoring system, sensors, OLED unit, and Wi-Fi module. Each of them plays a unique role in terms of communicating and interfacing with the centralized microcontroller – Atmega1284. Details for the function and operating mode of sensors, OLED and wifi module will be covered next Sensors The SpO2 sensor system consists of a regular red LED, an infrared LED and a programmable light-to-frequency converter. The red and infrared LEDs transmit light/IR through the finger. The converter receives the light that passes through the measuring site in-between and outputs a frequency corresponding to the light intensity [7]. Taking the ratio of red LED and infrared LED outputs, the oxygen concentration can be found through a lookup table. Meanwhile, the heart rate can be detected by finding the peaks of the fluctuated output from two LEDs. A triple axis accelerometer is used to detect the fall detection of the patient. The sensor has extremely low power consumption (320 uA [19] ) and a full sensing range of +/- 3g. This allows the microcontroller to sense the drastic acceleration associated with falling by reading the analog outputs from the sensor. The digital temperature sensor has a resolution of 0.0625oC and is accurate up to 0.5oC [20]. This allows microcontroller to monitor the skin temperature by building the communication with the sensor through an I2C bus. In addition, filtering capacitors and pull-up resistors are already included on the breakout board. OLED The OLED provides health data easily accessible by the patient or the health provider for quick viewing as well as a backup solution in case the Wi-Fi system goes down. The OLED is controlled through a 3.3V UART [21] interface with a custom on-board chip to process the high-level commands and display the correct information. The OLED itself requires 5V for power, which is required for backlighting. Therefore, we need a step-up DC-DC converter to convert the

-18-


3.3V coming out of the battery regulator to 5V [22]. However, we can directly communicate to the OLED module via UART through the 3.3V used by the microcontroller [2]. Wi-Fi Module The Wi-Fi module is used to transfer sensor information to our online database. It runs off 3.3V [3] and communicates with the microcontroller through a UART interface. Since it features an on-board controller to handle the lower level functions and handshaking protocol (TCP stack, encryption etc.) we can communicate it with ASCII commands and thus makes operation relatively easy. An important aspect is that transmitting information takes a much larger current draw compared to idle, so we plan on sending packets of data at specific intervals instead of a constant stream to maintain a higher battery life. We chose this module because it incorporates the antenna in the design and provides a nice framework to communicate via Wi-Fi without getting down to the intricate details. Hardware Design Narrative On the microcontroller, we plan on using the following subsystems: i. Timer module for precise timing to obtain measurements ii. I2C interface to communicate with the temperature and fuel gauge iii. 1 External interrupt pin to detect the frequency output of the Pulse Oximeter iv. 2 UART interfaces, 1 for the Wi-Fi and 1 for the OLED v. 3 Analog inputs for the accelerometer vi. JTAG for on-board debugging and programming vii. Various GPIO for controlling LED’s and other control pins Summary In summary, the design consists of two systems: power supply/management system and central processing system. Within the power/supply/management system, it includes lithium battery pack, charger/booster, 5V step-up converter and fuel gauge. The charger/booster provides stable 3.3V power supply for the microcontroller, sensors and Wi-Fi module in the main system. The 5V step-up converts the 3.3V to 5V [22] for powering up the OLED display. In addition, I2C bus was used for fuel gauge to transmit battery ‘fuel’ tank status to the microcontroller. As for the main system, there are three major subsystems: sensors, OLED and Wi-Fi module. Digital temperature sensors and oximeter will send data to the microcontroller on I2C bus. Accelerometer outputs analog signal to the microcontroller directly. Both OLED screen and Wi-Fi module communicate with the microcontroller through UART channel.

-19-


9.0 PCB Layout Design Considerations General PCB Layout Design Considerations To facilitate layout, we first organized the PCB into four distinct sections: power regulator and battery recharger, WiFi, Analog, and the section containing the microcontroller. Having the power side of the PCB be separate is due to 2 important factors: the need to minimize width so that the device will fit nicely on the wrist, and the need to keep the high current areas away from the rest of the digital and analog logic. The analog part of our design (inputs from the accelerometer) sits below and to the left of the WiFi module and connects directly to the microcontroller to minimize noise from other parts of the circuit [19]. Finally, the microcontroller and the sensor docks are kept together as they all use low-current digital circuitry should not interfere much with each other. For traces, we took two different approaches: one for the power and ground rails and another for the traces connecting the components. Because we only have 1 analog device (the accelerometer) which does not require extreme precision, the traces used for connecting between the parts are sized at 12 mils [19]. This provides ample current to drive communication as well as making the traces small enough that we can have a high density board and thus obtain as small of a board size as possible. The power and ground traces are larger to minimize resistance to increase efficiency and design longevity, and will be covered in more detail in the following sections. PCB Layout Design Considerations [Microcontroller] To ensure smooth operation when current spikes from output pins changing their values, we are using 3 surface mount decoupling capacitors situated very close to the microcontroller. The microcontroller itself also plays as the central hub of our device, with every single other component (aside from the battery charger/converter and 5V DC-DC step-up) directly communicating with it [22][23]. As such the space around our small microcontroller (44-pin package) is heavily inundated with traces. In order to accommodate all the traces and make sure that wiring can be done smoothly, we first mapped the pin-outs to try and make each trace as direct as possible (i.e. making sure that communication with devices are routed to one side of the microcontroller as much as possible). This means that the traces do not have to wrap-around the design and this not only improves noise but makes routing the traces a much easier task. Because the current used by microcontroller communication is relatively small, we decided to use a common trace size of 12 mils to make the layout uniform. PCB Layout Design Considerations [Power Supply]

-20-


Having all power related components physically separated from the logic traces removes potential noise problems and also means the design of the power board itself is simplified. On the board are the 3.3V regulator and charger for the lithium-ion battery, a coulomb counter for the fuel gauge, and a 5V DC-DC converter with its 2 requisite capacitors [22][23]. One thing to note is that because the power and fuel gauge reading is being delivered to the main board via a ribbon cable the bulk capacitor will sit on the main board’s power rails in order to maximize the current it can supply. With a predicted maximum current draw of 300 mA, we decided to use a trace size of 32 mils, which should provide minimal resistance and heat generation during operation. Summary The major constraint with the PCB layout is from the form factor of the design, namely how small it has to be in order to fit nicely on the user’s wrist. Because of this the decision was made to separate the power board from the rest of the PCB in order to maintain our width requirement as well as isolate its high current from the rest of the circuit. Our trace sizing was based off of a standard size for communication traces (12 mills) and the knowledge that our highest current draw would be roughly 300 mA (32 mills). Additionally, concessions were made for the WiFi (a copper shield beneath the antenna to reduce potential interference with the antenna), the analog accelerometer signals (by isolating them and directly connecting them to the microcontroller), and the I2C bus (isolating it to maintain high-fidelity communication). As such, the current design features a modular layout contained within a very small form factor. 10.0 Software Design Considerations Peripherals and Code Organization[Software Design Considerations] Organization The main function of the MCU(Microcontroller Unit) is to sample the sensors and update the buffers. A natural choice to implement this functionality is a polling method. However, instead of taxing the MCU by including the sampling code inside an infinite while loop, it is much more efficient to use the Interrupt Driven polling method, as this allows us, the designers, to precisely control the frequency at which the sensors need to be sampled and helps lower power consumption. We are still in the process of empirically determining the exact interrupt interval and buffer size(s) that will balance safety and reliability required of the device with the desired outcome of conserving the battery as continuously transmitting via WiFi will draw too much current too quickly from the battery. Hence, the data is stored in a buffer will be transmitted once the buffer is full. The interrupt driven polling method is implemented by using the timer module to trigger an interrupt when it counts to a specific value stored in the OCR1A register [2]. The

-21-


interrupt handler will then start the process of sampling the sensors, updating the data-buffers and if necessary transmit the data over WiFi. Peripherals Accelerometer: An accelerometer (ADXL 335)[2] located on the patients shoulder is used to sense if the patient has suffered a fall and if so automatically raise an alarm. The ADXL 335 is a 3-axis accelerometer with a sensing range of +/- 3g. It outputs analog data and thus has to be interfaced to the microcontroller, using analog to digital conversion. Port A has 8 ADC (PA0-PA7) out of which we require 3, (PA0-PA2) one for each axis. The ATmega1284 provides 2 modes of operation for ADC 8 bit resolution and 10 bit resolution. Using 10 bit resolution places restrictions on how fast the device can be clocked, whereas the 8 bit mode has no such restrictions [19]. We plan to detect a fall by looking out for large changes in successive accelerometer readings. Therefore the 8-bit mode is suitable as there is no need to have extremely accurate individual readings Temperature Sensor: The TMP102 [20] is used to report Skin temperature to the MCU. It has a great resolution of 0.0625 degrees Celsius and is extremely robust and can operate accurately between -25 degrees Celsius to 85 degrees Celsius. It is interfaced to the microcontroller using I2C (TWI ) communication protocol. The MCU will be the master and the TMP102 has one of 4 slave addresses depending upon whether the ADDR pin is connected to VCC, GND, SDA or SCL. This was a design choice by the makers of the sensor to allow 4 different sensors on the same bus. The TMP102 sensor also has inbuilt pull-up resistors(1K-ohm) to pull both the SDA and SCL lines high [20]. The SCL and SDA lines of the MCU are located in PC0 and PC1 respectively Pulse-Oximeter Sensor: We are building our own pulse-oximeter sensor using the TSL230 Light to Frequency optical sensor [7]. The concept behind the pulse-oximeter sensor is to find the ratio between the frequency of light absorbed using a Red LED and an infra-red LED when the light is passed through the patients finger. An external interrupt, associated with PD0, PD1 or PD2 is used to discern the frequency output from the TSL230. OLED Screen: The OLED [21] screen mounted on the patient’s wrist provides a summary of all the important information that the device monitors namely: temperature, pulse, SpO2, battery-status and emergency flag status. The novel function of our device is to transmit the patient data wirelessly to a central server to facilitate remote monitoring of multiple patients by a doctor at his/her convenience. However, the OLED provides an important redundancy as in the event of a failure in the WiFi chip the device is still useful and poses no risk to the patient. The OLED is updated via command sent using UART located in PD2 and PD3 on the MCU.

-22-


WiFly Shiled: The RN-171 [3] is a complete plug and play WiFi solution. It is configurable through commands sent over UART. What attracted us to this specific product is that it is an ultra low power device (4 μA sleep, 40mA Rx and 180mATx at 10 dBm) and has a built in HTML client which can be used to directly issue POST requests to our web-server. Software Design Narrative Pulse-Oximeter : We are building our own pulse-oximeter sensor using the TSL230 light to frequency converter [7]. The concept behind a pulse-oximeter is that oxygen present in the blood absorbs different frequencies of red and infra-red light, the ratio of which can be used to calculate the oxygen saturation (SpO2) and counting the peaks obtained in the data lets us determine the pulse. When light hits the TSL230 it outputs the frequency of the incident light as a pulse train. The MCU is configured such that each pulse triggers an external interrupt which updates a particular counter based on whether it was the red light or the infra-red led whose light was incident on the sensor. A timer is used to measure the frequencies for a specified amount of time before we find the ratio to determine the SpO2 reading. In addition to determining the frequency a peak detection algorithm is implemented to measure the pulse. As of now, we have a simple peak detection, which detects a peak when the incoming readings, which have been consistently increasing, start decreasing. However, due to the contraction and expansion of the heart we obtain two peaks thus the final result has to be divided by 2 (or left shifted 1 bit) to obtain the correct result. Timer Interrupt: The timer interrupt is used to implement the interrupt driven polling method of code organization. When the timer reaches a certain value an interrupt is triggered and all the sensors are sampled in its corresponding ISR. Writing a 1 to the OCIE1A bit in the TIMSK1 register enables the timer interrupt. The TCCR1B register is used to select the appropriate pre-scalar to generate the clock used by the Timer module. The TCCR1A register is used to clear the counter when it reaches the value it is supposed to count up to (specified in 16 bit OCR1A register) to trigger the timer interrupt. Finally, setting the OCF1A bit in the TIFR1 register clears the flag that is set when OCR1A reaches the value it is supposed to count to [2]. ADC [Fall Detection]:

-23-

https://github.com/joshi4/ECE477/blob/master/accel_laptop.c

https://github.com/joshi4/ECE477/blob/master/accel_laptop.c


The Analog to Digital Conversion module is used to interface the Accelerometer with the MCU. The ADC is initialized by writing a 1 to the ADLAR bit to the ADMUX register, which sets the ADC to 8bit mode. There is no pre-scalar required as we are operating in 8bit mode. Next, setting the ADIE bit to 1 in the ADSCRA register enables the interrupts. Finally, ADEN bit is set in the ADSCRA register to turn the ADC module on. Setting the ADCSC bit high in the ADSCRA register starts the conversion. The ISR (Interrupt Service routine) reads the final digital value stored in ADCH and changes the ADC channel sampled using a switch case statement which ensures that all three channels ADC0 to ADC2 are sampled before returning to the Timer ISR to sample the next sensor [2]. Two Wire Interface (I2C): The I2C communication protocol [2] is used to interface the temperature sensor and Fuel gauge to the MCU. I used a library provided by Sparkfun to initialize all the correct registers and abstract away all the low level functions. The library provides high-level functions like Start, Stop, SendByte, WaitForCompletion GetReceivedByte etc. Using, these abstractions it was very easy to set up the TWI with the MCU as Master and the TMP102 sensor as a slave. I connected the ADDR pin to VCC and thus the temperature sensor had a slave address of 0x93. The TMP102 sensor returns a 16bit value, which is acquired by reading twice in succession. The two results are then combined by shifting the higher order 8 bits to the left by 8 bits and then performing a bitwise or of the result with the lower order 8 bits. A similar approach is used to read the battery status from the fuel gauge. Web Application The web-application is written in Node.js [24], which is a highly scalable asynchronous single-threaded non-blocking framework for writing both web servers and clients. It is relatively new tool which has been actively adopted by the industry and hence quite a supportive community. The server I have written interacts with a MongoDB [25] database and is capable of adding, deleting and modifying the records of existing patients. Also stored in the database are credentials of doctors to ensure there is no unauthorized access. Once a doctor or primary care giver navigates to the relevant URL to view the patients data the client makes a request to the server which responds with an array of the patients latest readings which are then plotted using a charting library called Smoothie.js [26] Emergency Flag The MCU continuously monitors the incoming data and can immediately alert the patient and doctor incase of an emergency. There is also a provision for the user to press an emergency button as a call for attention.

-24-

https://github.com/joshi4/ECE477/blob/master/tmp102.c

https://github.com/joshi4/ECE477/blob/master/i2c.h


Fall detection is based on the successive readings of the accelerometer and if there is a large spike then it is assumed to correspond to a fall, which will set the emergency flag. Pulse, SpO2 and Temperature above and below certain thresholds (yet to be determined) will also set the emergency flag. Once the emergency flag is set then the data in the buffers is immediately sent along with the emergency flag to the web server so that the doctors can immediately resolve the emergency Summary Our embedded microcontroller code and remote web app work together to continuously monitor the patient and immediately provide knowledge and feedback during emergencies. The system is robust and has some built in redundancies so that the safety of the patient is not threatened in the event of some components failing. 11.0 Version 2 Changes In the next iteration of our sensor we would fix the issue with the I2C bus that prevented the fuel gauge from operating successfully. This would help us provide more useful feedback to the patient. We would also implement a start up test sequence so that we can detect equipment malfunction very easily and address it immediately. Our device did end up being pretty small and light but it can always be made smaller and lighter. In order to accomplish this we would have to design more of our sensors ourself (like the temperature sensor and Fuel gauge) so that we can reduce the PCB area. After seeing how many wires we had on the device and the discomfort it caused the wearer we would have to implement some sort of wireless transmission of information (perhaps via Bluetooth) from the sensors to the microcontroller. Another great addition would be the NFC chip and its accompanying android app. A smaller and more powerful battery would also be great as the Wi-Fi drains the battery pretty quickly. With regards to packaging we tried our hand with 3D printing and came up with a decent case but the packaging had some tolerance errors. This could be taken care of in the next iteration along with the possibility of exploring other packaging methods. On the Software front, the Web-app can be spruced up and made more aesthetic. As of now, it has no CSS styling which should definitely be fixed if we were to take our product public. 12.0 Summary and Conclusions In this report we have meticulously outlined all our constraints and considerations while designing this health sensor.

-25-


We were very careful in our early planning and as a result did not face too many issues later on. With diverse team members who specialize in different things no one member of the team was burdened with the entire project and the different parts fit together smoothly. Great teamwork also contributed to our ultimate success. Keeping our Software and Hardware extremely modular helped us quite a bit. We were able to make whole scale changes to our software in a matter of minutes. On the hardware front, separting the power board and main pcb for this initial prototype turned out to be a great idea as we did not have to deal with the noise coming out of the power board and failures on one board were isolated and did not propogate through the design. This was especially important for us as towards the end our DC-DC power supply was damaged with no major consequences to the rest of our design. Simply swapping out the relevant part restored our design to full functionality. Lastly, we were very realistic with regards to what we wanted to achieve: A prototype device that focused on core functionality (Pulse,Spo2,WiFi,WebApp,OLED) above all else. As a result we were able to quickly prioritize what features to implement thoroughly and which features (NFC, CSS, Fuel Gauge) to incorporate in our next iteration. This line of thinking ensured we spent our time wisely and finished all our objectives well in advance. 13.0 References

[1] Libelium. E-Health Sensor Platform Complete Kit [Online]. Available: http://www.cooking-hacks.com/index.php/ehealth-sensors-complete-kit-biometric-medical-arduino-raspberry-pi.html

[2] "ATmega1284," [Online]. Available: http://www.atmel.com/Images/doc8272.pdf. [3] "RN171," 2 October 2012. [Online]. Available:

http://www.rovingnetworks.com/resources/download/12/RN_171. [Accessed 21 Feburary 2013].

[4] C.P. Groff and P.L. Mulvaney, “Wearable Vial Sign Monitoring System”, U.S. Patent 6102 856, August 15, 2000

[5] Byun Hoon Lee, “Health Watch”, U.S. Patent 6 314 058 B1, November 6, 2001 [6] Overview, ViSi Mobile | A Product by Sotera Wireless Inc., [online]

2013 http://www.visimobile.com/overview (Accessed: 3 February 2013). [7] "Mouser Electronics," [Online].

Available: http://www.mouser.com/ds/2/588/TSL230RDTSL230ARDTSL230BRD-P-198494.pdf

[8] MIL-HDBK-217D Military Handbook: Reliability Prediction of Electronic Equipment, Washington DC: The United States of America Department of Defense, 1991.

[9] LaDou J. “Printed Circuit Board Industry” International Journal of Hygiene and Environmental Health [Online] vol 209. pp 211-219. May 2006.

-26-

http://www.cooking-hacks.com/index.php/ehealth-sensors-complete-kit-biometric-medical-arduino-raspberry-pi.html

http://www.cooking-hacks.com/index.php/ehealth-sensors-complete-kit-biometric-medical-arduino-raspberry-pi.html

http://www.atmel.com/Images/doc8272.pdf

http://www.visimobile.com/overview

http://www.mouser.com/ds/2/588/TSL230RDTSL230ARDTSL230BRD-P-198494.pdf

http://www.mouser.com/ds/2/588/TSL230RDTSL230ARDTSL230BRD-P-198494.pdf


Available: http://www.sciencedirect.com/science/article/pii/S1438463906000204 [April 11th 2013]

[10] Sentry Air Systems.“The Hazards of Solder Fumes” Internet: http://www.sentryair.com/solder fume.htm [April 11th 2013]

[11] Adcock J. (2008) “ Smart2020 Enabling the low Carbon Economy in the information age” [Online]. Available: http://www.smart2020.org/_assets/files/03_Smart2020Report_lo_res.pdf

[12] “E-Flite LiPo Warning!” Internet: http://www.e-fliterc.com/ProdInfo/Files/EFL%20LiPo%20Warning.pdf [April 11th 2013]

[13] “Disposal of LiPo Batteries” Internet: http://thunderpowerrc.com/PDF/DISPOSAL-OF-LIPO-BATTERIES.pdf [April 11th 2013]

[14] “How can SpO2 readings differ from manufacturer to manufacturer” Internet: http://www.mountainside-medical.com/product_downloads/h/how-can-spO2-readings-change.pdf

[15] IntelliVue MX40 wearable patient monitor, Philips Healthcare, [online] 2013, http://www.healthcare.philips.com/us_en/products/patient_monitoring/products/intellivuemx40/index.wpd (Accessed: 3 February 2013).

[16] Overview, ViSi Mobile | A Product by Sotera Wireless Inc., [online] 2013, http://www.visimobile.com/overview (Accessed: 3 February 2013).

[17] Apple – Iphone 5- View all Technical Specifications, Apple, [online] 2013, http://www.apple.com/iphone/specs.html (Accessed: 7 February 2013).

[18] Package Material Data Declaration Sheet, Atmel Home, [online] 2013, http://www.atmel.com/Images/TQFP-44-AIX.pdf (Accessed: 7 February 2013).

[19] "Triple Axis Accelerometer Breakout - ADXL335," Sparkfun Electronics, [Online]. Available: https://www.sparkfun.com/products/9269.

[20] “Digital Temperature Sensor Breakout - TMP102," Sparkfun Electronics, [Online]. Available: https://www.sparkfun.com/products/9418.

[21] "1.7” microOLED GOLDELOX Display," 4D Systems, [Online]. Available: http://www.4dsystems.com.au/downloads/microOLED/uOLED-160-G2/Docs/uOLED-160-G2-Datasheet-REV1.pdf.

[22] "NCP1402-5V Step-Up Breakout," Sparkfun Electronics, [Online]. Available: https://www.sparkfun.com/products/10968

[23] "Power Cell - LiPo Charger/Booster," Sparkfun Electronics, [Online]. Available: https://www.sparkfun.com/products/11231.

[24] “Node.js” [Online]. Available: http://nodejs.org/api/ [25] “Data Modeling Considerations for MongoDB Applications”, MongoDB, [Online].

Available: http://docs.mongodb.org/manual/core/data-modeling/ [26] “Ten Minute Tutorial”, Smoothie Charts, [Online].

Available http://smoothiecharts.org/tutorial.html

-27-

http://www.sciencedirect.com/science/article/pii/S1438463906000204

http://www.sentryair.com/solder%20fume.htm

http://www.sentryair.com/solder%20fume.htm

http://www.smart2020.org/_assets/files/03_Smart2020Report_lo_res.pdf







http://www.healthcare.philips.com/us_en/products/patient_monitoring/products/intellivuemx40/index.wpd

http://www.healthcare.philips.com/us_en/products/patient_monitoring/products/intellivuemx40/index.wpd

http://www.visimobile.com/overview

http://www.apple.com/iphone/specs.html

http://www.atmel.com/Images/TQFP-44-AIX.pdf

https://www.sparkfun.com/products/9269


http://www.4dsystems.com.au/downloads/microOLED/uOLED-160-G2/Docs/uOLED-160-G2-Datasheet-REV1.pdf

http://www.4dsystems.com.au/downloads/microOLED/uOLED-160-G2/Docs/uOLED-160-G2-Datasheet-REV1.pdf



http://nodejs.org/api/

http://docs.mongodb.org/manual/core/data-modeling/

http://smoothiecharts.org/tutorial.html


Appendix A: Individual Contributions

A.1 Contributions of Shantanu Joshi: My contribution to the project was mainly on the Software side along with some help during the packaging phase and I also helped debug some hardware issues. I was solely responsible for creating the web-app. Since I had no experience in web development prior to this it was a steep learning curve added to which, I could not afford to spend too much time on the web site development, as I had to also work on programming the microcontroller. First off, I did a lot of research on which platform to use for creating the website, eventually it came down to a choice between Django and Node.js. I chose Node.js because of its excellent community, clear documentation and thriving third party support. Using the express framework I had a bare bones web-app up and running in seconds. After, choosing to use Node.js I followed along with a lot of tutorials to get a hang of the language and implement some basic get requests. From here on, I was able to draw on my experience of other programming languages and quickly made progress on various aspects of the web-app. The trickiest bit was hosting the website on the internet and after a false start with AppFrog I got it hosted using Heroku. I worked with MoDi to program our wi-fi chip and after much testing and reading of documentation we realized that the wifi chip was failing to transmit data to my web-app because Heroku did not accept incoming TCP connections. In order to get around this I created another website that was hosted on my Computer using PHP which accepted incoming TCP connections from the WiFi chip and forwared it to Heroku. This required me to use MAMP framework which has an Apache server programmed in PHP. The intermediate website worked beautifully. While I was working on the web-app I also worked on prototyping the ADC for our Accelerometer. I ran into some issues with the Dev board we had but the code worked perfectly fine on our PDIP board. From there I extended the code to work for 3 axis and then Aakash helped me calibrate the ADXL for fall detection on our actual PCB. I was also responsible for implementing the I2C bus for our temp sensor and fuel gauge. I found a helpful library online which I was able to tweak to work for our use cases. I had successfully tested both components individually but we ran into some issues when we tried to get both of them to work. MoDi and Aakash helped me debug this issue but we eventually settled for ensuring our project worked and removed the fuel gauge. I also expanded upon the UART functions MoDi had implemented and wrote functions that would transmit all relevant

A-1


information the OLED and Wi-Fi. MoDi and I worked together to write and test the code that detects anomalous readings of vitals. On the packaging front, I helped Aakash with the soldering of our ADXL and temperature sensors (but he did the actual soldering). During the initial stages of prototyping I provided MoDi with the idea that our spo2 sensor was reading random noise due to interference from outside light and once he covered it with a makeshift case we were observed a drastic decrease in noise. However, there was still a lot of tweaking calibration and software algorithms required for the Spo2 sensor, which was accomplished by MoDi. While debugging our hardware, I always worked with other team members and was able to help in identifying some issues , like when the clock was accidentally divided by 8 and when our DC-DC power supply burned out. In summary, I was involved with all of the SW except for the Spo2 sensor and UI interface for OLED and helped other team members in packaging and debugging the circuits. I feel that all of us worked well together and each of us made a significant contribution towards the success of our project.

A.2 Contributions of Aakash Lamba: I was involved in a very diverse set of activities associated with our project. This included programming the android application for our project, hardware design and debugging, assisting with software debugging and packaging our final device. During the initial phase of the project (once our idea had been finalized), I was involved closely with conducting research on the components that were most apt to our design needs. Since I had some experience with developing android, I took the responsibility of developing the android application of our project. This app would allow a medical professional to retrieve patient data onto his/her android smart phone. The main features of the app were secured login, an ability to communicate with the web-app that Shantanu had built and NFC to access patient records by simply touching an NFC enabled smart phone onto our device. Setting up NFC was by far the hardest part of building the app. Another critical aspect of the project of the project that I was involved with was packaging. I completed the Packaging Specification and Design TCSP and report for our team. As part of this assignment, I prepared a preliminary PCB of our intended design which had footprints and approximate locations of the components we would be using. This preliminary PCB helped us gauge the approximate size of our device and allowed us to set goals for our packaging. Once our prototyping phase was nearly complete, I began looking into cases for packaging our device. I had shortlisted some cases which after some tweaking would house our design quite

A-2


well. However, these cases were unnecessary, since Mo Di got the housing for our project 3D printed. The 3D printed box was a bit small, due to which I spent some time filing it to fit our PCB. Apart from this, I created the mount for our accelerometer and did the final soldering for some of our sensors. In the end our final packaging was very similar to what we had presented in the packaging specifications and design report which was prepared in the first few weeks of the semester. Since, the dev board we had was not the micro we were going to use, we decided to do our prototyping using the PDIP package of our micro i.e. Atmega 1284. The good thing about this was that we could easily prototype all of our project components on a bread board. I was responsible for setting up the JTAG for our PDIP packaging. I wired all of the wires for JTAG by referring to our PCB and the pin out for the PDIP package. There were some bugs related to the setting on Atmel which were fixed with Mo Di and Shantanu’s help. Once all of our power related components arrived, I tested all of them on a breadboard. I also verified the recharge capabilities of our power components. Once these had been verified, Yi soldered the components on the power PCB. However, upon testing the power PCB, we realized that some of the connections were incorrect (the output voltage was incorrect). I was able to find a least intervention solution which involved cutting a trace and fly wiring two connections (Yi soldered the wires for fly wiring). I also worked on the patent liability analysis section of our project, which involved extensive research on existing patents and a detailed analysis of whether we were infringing on any intellectual property. I worked closely with Shantanu in testing Wi-Fi and debugging our final PCB. Shantanu and I, also set up fall detection in our project (he handled the software bit and I tested and soldered the hardware). I also assisted Mo Di and Shantanu in debugging the issues we were having with our I2C bus. Finally, I created the final video for our project, along with Shantanu’s help. All in all, I feel that I contributed significantly to the success of our project. Also, I would like to mention that everyone worked very well together and worked as a cohesive unit.

A.3 Contributions of Di Mo: My main contributions to the project is focused on the initial parts selection, packaging, OLED programming, and the SPO2 sensor. Additionally, I worked on the software that ran on the microcontroller and how/how often our sensors would be sampled. These contributions are described below. In regards to the initial parts selection, I researched and submitted the order forms for many of the key components used on the board. My main focus was on which microcontroller and the various costs/benefits between the different types. Since our project is portable and small, a low-power small profile microcontroller was a must. Due to this, I looked for low pin count (44 or

A-3


less) microcontrollers with ideally a large pool of memory (around 64 Kb of flash and 8 Kb of SRAM). Ideally it would run off of its internal oscillator, and based on our application it seemed that we needed at least 8 MHz from it. Just as well, low power consumption was key and thus I looked for ones that operated at less than 20 mA. From there, I decided that the ATmega1284 suited all of our needs and also had a great Integrated Development Environment in the form of Atmel Studio and also a PDIP package for rapid and easy prototyping. The other parts included the OLED display, which was chosen for its low power consumption (< 20 mA) and ease of programming via a high-level language. I also chose the light sensor used in the SPO2 based off of another project that used the same sensor for their custom SPO2. As for packaging, I worked on initial mock-up for size comparisons and parts layout before the PCB was fabricated and later the 3-D printed design that is currently our final case. I built a to-scale mockup of our PCB in Computer Aided Drafting software so that we knew where each component would exist and whether they would fit nicely or not. Afterwards I decided to 3D print our final case, which consisted of a bottom and top for the main board as well as the enclosure for our SPO2 sensor. I did all of the programming for the OLED screen which includes setting up the data headers, reading in the information via UART, and showing an alarm status by changing the background of the screen to red. Thus I had to learn and implement 4DGL, the high-level code made by the OLED’s manufacturers, in order to get the screen to show what we desired. I designed the SPO2 test bed and performed all duties needed to get it working. These included setting up the proper LED’s for the best luminescence, calibrating the sensor and parsing the data, and analyzing the data in order to extract the information used to calculate the heartbeat of the user. I also wrote and integrated all of the code needed for the SPO2 sensor to function, and the various conversions and data processing necessary to take the raw light information into useful values such as heart rate and SPO2 saturation (the latter also required an empirical look-up table which I found and implemented in the code). On the software front, I implemented a lot of the policy regarding how our code would be executed. I implemented the API’s we required for the UART, external interrupts, and internal timer systems (Shantanu took care of I2C and ADC implementation). I also abstracted away the microcontroller timing scheme in favor of triggering a timer interrupt in variable quantas of time (we used 10 milliseconds in our final code). This hid the internal timer and provided an easy interface to change sampling rate by varying how many quantas pass between each sample. Finally, I worked on setting up the debug environment starting with the STK600 that changed to the dragon board when testing on our test bed/PCB

A-4


A.4 Contributions of Yi Shen:

My contributions to the project were centered on my previous Co-op experience working on medical devices and knowledge with both hardware design and mechanical system. I utilized my prior knowledge of electrical components and applications from the beginning when the team started to brainstorm the design ideas and formalize the high-level block diagram and methods for accomplishing different modules. I also provided some important suggestions for the initial project idea and design based on my clinical-systems knowledge that I gained from my Co-op. At the beginning of the semester, I was the one who set up the team website. While my knowledge of microcontroller features is not as complete as others, I actively seek opportunities to help and collaborate with the team during the parts selection phase. I learned during several team meetings. Furthermore, I initially came up with the solution of how to properly design the power board for our project. So the design has the capability of charging and monitoring the battery simultaneously. Without any prior experiences of designing PCBs, I was able to learn to use EagleCAD very quickly by checking tutorials online during the design phase of our circuit board. I spent a lot of time researching the hardware components and refining the schematic based on the high-level block diagram that we agreed on at the beginning of the semester. I also manually created some parts and added to the Eagle library based on the some special hardware components that we ordered. Later, I spent lots of nights completing the layout for the PCB until the final submission date. This helped us to create a relatively densely packed circuit board that fits in a relatively small packaging design size that can be mounted on the wrist. Once the boards arrived, I began to assemble the PCB. The main board was laid out primarily with connectors, 0805 and 1006 surface-mounted parts. I first started to assemble and test the power board. Unfortunately, there was a design error discovered during the testing phase when the board was expected to output 3.3 V. After I carefully reading the data sheet for the components on the power board, it turned to be that wrong pins were connected. But I was able to fix the problem very easily by cutting one trace and fly wiring between two other pins on the board. After another set of test for the power board, everything worked as we expected. Then I assembled and tested the main board with different individual hardware components soldered on to ensure that they all run properly as a system. Luckily, we didn’t have to install a single fly wire on the main PCB. The overall hardware design turned out to be fairly robust without a lot introduced noises. Once the PCBs were populated, I turned my attention to implementing the customized SpO2 sensor for the team. With the other teammate’s help, we were able to work together and make a SpO2 sensor work by simply assembling the light sensor chip, red/infrared LEDs and regular resistors on a small breakout board. The final product output very accurate readings for heart rate and oxygen concentration level. Later, I was also able to adjust the sensitivity of the customized SpO2 sensor to work properly with the existing packaging that we had. The output turned to be

A-5


very stable and accurate. The infrared LED didn’t blink too fast and cause any false-positive detection to the light frequency sensor. Finally, I helped the team to make the poster for the design show case. It was these contributions that helped the team project run very smoothly and robust in hardware.

A-6


Appendix B: Packaging

Figure B-1: Illustration of Product Packaging

Accelero

OLED

Alarm

Sp02

Batte

Wi-Fi chip

B-1


Figure B-2: Preliminary PCB Footprint Layout.

Figure B-3: Mockup of the finished PCB

67 mm

47 m

m

Wi-Fi module

Micro

OLED

Sensor break-outs

B-2


Figure B-4: Bottom half of our 3D printed case

Figure B-5: Top half of packaging case.

B-3


Appendix C: Schematic Figure C-1: Schematic design of biometric sensor.

C-1


Appendix D: PCB Layout Top and Bottom Copper

Figure D-1 : PCB Layout Copper Top

D-1


Figure D-2: PCB Layout Copper Bottom

D-2


Figure D-3: PCB Layout Silk Screen.

D-3


Appendix E: Parts List Spreadsheet

Vendor Manufacturer Part No. Description Unit Cost

14.0

Total Cost

Digi-Key Atmel ATMEGA1284-AU-ND

Atmel Processor (TQFP) 7.22 1 $7.22

Mouser 4D Systems 971-UOLED-160-G2

OLED display 60.00 1 $60.00

Sparkfun Roving Networks

WRL-10822 Wi-Fi module

1

Sparkfun Sparkfun SEN-09418 Temperature sensor 5.95 1 $5.95 Sparkfun Sparkfun SEN-09269 Accelerometer 24.95 1 $24.95 Mouser ams 856-TSL230ARD Optical sensor 4.66 1 $4.66 Sparkfun Sparkfun SEN-11574 Pulse sensor 24.95 1 $24.95 Sparkfun Sparkfun DEV-09717 FTDI cable (for programming

OLED) 18.00 1 $18.00

Undecided Undecided Battery Fuel Gauge + Charger + Battery

~20.00 1 $20.00

TOTAL $200.68

E-1

ECE 477 Final Report

Appendix F: FMECA Worksheet Failure

No. Failure Mode

Possible Causes

Failure Effects Method of Detection

Criticality Remarks

A1 Over-current

Decoupling capacitors C3, C7, C9 are shorted

Microcontroller is no longer operable

Inspection ICD3 debugger

High

A2 Failure of I2C bus

Pull-up resistors R2 and R3 are open

Microcontroller is unable to retrieve data from the temperature sensor and fuel gauge

Voltmeter ICD3 debugger

Medium

A3

Failure to Reset

Reset Pushbutton Failure

Loss of ability to reset microcontroller and the entire system

Inspection Voltmeter ICD3 debugger

Low

Table F-1: Microcontroller System FMECA Worksheet Failure

No. Failure Mode

Possible Causes

Failure Effects Method of Detection

Criticality Remarks

B1 Wires worn-out

wear and tear microcontroller would not obtain accurate readings and communicate with sensors properly


Medium

1


B2 Optical sensor worn-out

repeated use lowers the sensitivity of the measurement

inaccurate readings for the pulse rate and oxygen concentration level

Calibration Check

Medium

Table F-2: Sensors System FMECA Worksheet Failure

No. Failure Mode

Possible Causes

Failure Effects

Method of Detection

Criticality Remarks

C1 Over-current

C6 is shorted Wi-Fi gets shorted and is no longer operable


Medium

C2 Antenna Failure

wear and tear

unable to transmit data to the website

Webserver check

Medium

2


Table F-3: External Interfaces System FMECA Worksheet Failure

No. Failure Mode

Possible Causes

Failure Effects

Method of Detection

Criticality Remarks

D1 Unable to turn/off the charger

Switch failure

shorten the battery longevity

Inspection User feedback ICD3 debugger

Medium

D2 Over-heat Too much current

damage battery

User feedback Voltmeter

Medium

Table F-4: Power and Battery Management System FMECA Worksheet

3

ee 477 final report - purdue engineering...software, pcb and schematic design process while also...

Documents