Manual 21027350

Manual 21027350
[2]
[3]
Anthony Ciancio – Electrical Engineer – Was in charge of the hardware design of the project, specifically the circuit
attached to the thermal sensor, as well as testing signals from the sensor and chip with an oscilloscope. Was a
contact in getting hardware that was needed from UMC. He mostly contributed to the testing portion of the final
report.
Tanisha House – Electrical Engineer – Assisted Anthony in circuit testing. Was in charge of building all hardware
required for the project. Also was in charge of getting the data for each existing device within the hospital (i.e.
specification sheets). Helped TJ in figuring out the existing wiring with anything used from the hospital. Contributed
to the sub-system and hardware design section of the paper.
Ryan Kreisberg – Optical Engineer – He was the project leader. Was in charge of the remote aspect of the project in
regards to building a system that was compatible with both Droid OS and SimpliCTi (was not able to finish). Played
the major role in organizing all papers and presentations that were due in class, as well as calling meetings. Was the
person that kept in contact with the sponser (though this was also split between TJ and David). Contributed to the
introduction, changes since the PDR,design, closing, and appendix of the paper.
David Montgomery – Optical Engineer – He was the project scribe of the team, and was responsible for creating
weekly reports required by the mentor. He was also responsible for the meeting minutes and additional notes within
the engineering notebook, and the notebook in general. Was the lone team representative for the STA (Society of
Technology in Anesthesia): 2011 Annual Conference’s engineering competition, which required supplemental work
such as writing an abstract and giving an additional presentation. He was the main contributor for the software
within the project, particularly the SimpliCTI code, and he had a minor role in the LabVIEW coding. Also did a lot of
testing in regards to the wireless connection and temperature tests. Contributed to the Requirements Review and
Acceptance Test Plan, Risk analysis and mitigation, System Requirements, and Introduction of the paper.
Sung Lin Wang – Optical Engineer –He was the finance keeper for the team, and took care of all budget related issues,
in addition to purchasing most of our main products. He was the other main contributor in coding the software by
also taking part in all the work for coding the SimpliCTI code. Was the major role in coding the LabVIEW as well.
Healso took part in testing, though mostly only the sensor testing in regards to the TI chips only, and not the
integration. He contributed to the Algorithm statement and Integration (software) section of the paper, as well as the
budget table, and acceptance test plan.
[4]
ENGR 498 – TEAM 4822
Final Project Report:
Development of Wireless Link Between Patient and
Monitor in Anesthesia Room
Members:
Anthony Ciancio
Tanisha House
Ryan Kreisberg
David Montgomery
Sunglin Wang
Mentor:
Ivar Sanders
Aero/Mechanical Engineering
Coordinator, Engineering Student Projects
University of Arizona
Sponsor:
Robert Loeb, MD
Associate Professor/Director of Anesthesiology
University of Arizona
Submitted:
4 May 2011
[5]
Abstract: In today’s hospitals, the necessity for improving system flow is increasing in order to keep up with demand.
However, it is quite limited in advancement due to the existing electronics interface that requires a myriad of wires to
be plugged in between the patient and a hospital monitor. A design that focused on improving system efficiency was
chosen from three drafts, and it implements a wireless interface that allows the sensor attached to a patient (in this
case a thermal sensor) to send a signal from within 30 feet away to a computer monitor that displays data. The
signal is identified within seconds, and easily cuts time from what a wired interface uses. In addition, a remote is also
implemented that allows hospital personnel control of which devices are to be connected. Working with existing
technology, a circuit board was created to properly format and amplify its signal, and computer software was
created utilizing National Instrument’s LabView and Texas Instrument’s Code Composer Studio. This project is meant
to be a concept design, and is no way a representation of a finalized product.
[6]
Table of Contents
1.0
Introduction......................................................................................................................................................... 10
1.1
Scope of the Document ................................................................................................................................... 10
1.2
Changes Since CDR .......................................................................................................................................... 10
1.3
Problem Statement/Background Information ................................................................................................ 11
1.4
Scope of Project: Objectives and Limitations .................................................................................................. 12
1.5
Expected Product Outcomes ........................................................................................................................... 12
1.6
Customer Description ...................................................................................................................................... 12
2.0
System Requirements.......................................................................................................................................... 13
3.0
Summary of PDR Results ..................................................................................................................................... 14
3.1
Concepts .......................................................................................................................................................... 14
3.2
Preferred Concept ........................................................................................................................................... 14
3.3
Key Differences in PDR selected design .......................................................................................................... 15
4.0
Top-Level Design of Final Design Concept........................................................................................................... 16
4.1
5.0
Overview.......................................................................................................................................................... 16
Subsystem/Sub-Assembly and Interface Design (Hardware) .............................................................................. 17
5.1
Thermometer (Thermistor) Sensors ................................................................................................................ 17
5.1.1
5.2
Characterizing the YSI-400 Thermometer (Thermistor) .......................................................................... 17
Transmitters .................................................................................................................................................... 21
5.2.1
Trade Studies (Transmitters) ................................................................................................................... 21
5.3
Circuit .............................................................................................................................................................. 21
5.4
Batteries .......................................................................................................................................................... 23
5.4.1
5.5
6.0
Trade Studies (Batteries) ......................................................................................................................... 24
Charging Station .............................................................................................................................................. 24
Algorithm Description and Interface Document (Software) ............................................................................... 24
6.1
End Device (Transmitter) Software ................................................................................................................. 24
6.1.1
Code Flow (ED) ........................................................................................................................................ 24
6.1.2
Additional Software Notes (ED)............................................................................................................... 25
6.2
Access Point (Receiver) Software .................................................................................................................... 25
6.2.1
Code Flow (AP) ........................................................................................................................................ 25
6.2.2
Additional Software Notes (AP)............................................................................................................... 26
6.3
Monitor (LabVIEW) Software .......................................................................................................................... 26
6.3.1
6.4
Code Flow (Monitor) ............................................................................................................................... 26
Remote Software............................................................................................................................................. 27
[7]
6.4.1
7.0
Pseudo-Code (Remote) ........................................................................................................................... 27
Analysis/Testing................................................................................................................................................... 27
7.1
Thermistor ....................................................................................................................................................... 27
8.0
Development Plan ............................................................................................................................................... 29
9.0
Requirements Review/Acceptance test Plan ...................................................................................................... 30
9.1
Performance/Technological Requirements .................................................................................................... 30
9.2
Testing Descriptions ........................................................................................................................................ 31
9.3
Real World Testing Simulations:...................................................................................................................... 34
9.4
Acceptance Test Plan....................................................................................................................................... 36
10.0
Summary of Risk Analysis and Mitigation Plan ................................................................................................... 38
10.1
Risk Analysis..................................................................................................................................................... 38
10.2
Risk Analysis Plan and Charts .......................................................................................................................... 40
11.0
Closure ................................................................................................................................................................. 43
11.1
Review of Final Project Report ........................................................................................................................ 43
11.2
Next Steps........................................................................................................................................................ 45
12.0
References ........................................................................................................................................................... 45
13.0
Appendix.............................................................................................................................................................. 46
13.1
Appendix A - Specialized Jargon: ..................................................................................................................... 46
13.2
Appendix B – Abbreviations: ........................................................................................................................... 48
PDR – Preliminary Design Review............................................................................................................................ 48
CDR - Critical Design Review.................................................................................................................................... 48
WDT – Wireless Development Kit ........................................................................................................................... 48
DVM – Digital Volt Meter – also known as DMM – digital multimeter................................................................... 48
SNR – Signal to noise ratio....................................................................................................................................... 48
GUI – Graphical User Interface ................................................................................................................................ 48
IR – Infrared ............................................................................................................................................................. 48
LED – Light emitting diode....................................................................................................................................... 48
ECG – Electro Cardiogram ....................................................................................................................................... 48
FDA – Food and Drug Administration...................................................................................................................... 48
FCC – Federal Communications Commission .......................................................................................................... 48
UMC – University Medical Center ........................................................................................................................... 48
13.3
Appendix C – Budget and Suppliers ................................................................................................................ 49
13.3.1
Budget ..................................................................................................................................................... 49
13.3.2
Bill of Materials........................................................................................................................................ 49
[8]
13.3.3
13.4
Suppliers .................................................................................................................................................. 49
Appendix D - Project Management ................................................................................................................. 50
13.4.1
Part Status ............................................................................................................................................... 50
13.4.1
Gantt Chart .............................................................................................................................................. 50
13.4.2
Resource Allocation ................................................................................................................................. 55
13.4.3
Major Deliverables .................................................................................................................................. 56
13.5
Appendix E – Bluetooth and Zigbee Information ............................................................................................ 57
13.5.1
Bluetooth Specifications .......................................................................................................................... 57
13.5.2
Zigbee Specifications ............................................................................................................................... 57
13.6
Appendix F – MSP430 Development Kit .......................................................................................................... 58
13.6.1
MSP430 Information (quoted from Texas Instruments): ........................................................................ 58
13.6.2
MSP430 Picture: ...................................................................................................................................... 58
13.7
Appendix G – Charging Station ........................................................................................................................ 59
13.7.1
Information:............................................................................................................................................. 59
13.7.2
Specifications:.......................................................................................................................................... 59
13.7.3
Picture: .................................................................................................................................................... 60
[9]
Final Project Report
1.0
Introduction
1.1
Scope of the Document
This Final Project Report is an in depth report of the "Development of Wireless Communications
between Patient and Monitor in Anesthesia Room" project. This report includes: the project
changes after the critical design review, a review of the requirements necessary to complete the
project, hardware and software specifications/utilization and design plans, trade studies of what
was considered for the overall design, a test and analysis assessment, a risk analysis of the
system, relevant sources, and an index providing more specifications of the technology that will
be utilized.
1.2
Changes Since CDR
There are a few key changes that have happened since the Critical Design Review in December.
As the project progressed, the team realized it would be unfeasible within the time allotted to
characterize and implement an interface that would work with the pulse oximeter sensor and
the data that it sends. There are a couple reasons for this. First, the pulse oximeter sensor turned
out to be a two-way communication device. The sensor did send its data back down the wire to
the monitor, but it simultaneously needed to be driven by a low-voltage, very high-frequency
signal in order to run the LEDs in the necessary fashion for the monitor to get any data. After
discovering the necessary frequency to drive the LEDs (on the order of megahertz) the team
realized that the microcontroller embedded on the wireless development kit would simply not
be fast enough to both drive the LEDs and to transmit data back to the monitor. The second
problem with using a pulse oximeter sensor is that it absolutely demands the use of the hospital
monitors to receive and decode the data coming from the sensor. This will be discussed
momentarily, but it turned out that using the hospital monitor would also prove to be a daunting
task that would be much too time consuming since the goal was to have a finished product by
Design Day.
A second big change since the Critical Design Review was that the output data from the patient
sensor was not able to be displayed on an actual hospital monitor. In order to interface our
system fully with the monitor, the monitor itself would have to power the Bluetooth module
attached to it. This in itself creates issues since the ports from the monitor have been built to
only supply any necessary power to the sensors themselves. The addition of power
[ 10 ]
requirements from the Bluetooth module made it so that there were two options: tear open the
monitor and direct more power through the port or decide to run a full simulation of a hospital
setting using computers as the “monitors”. Overall, the second option was the more practical
option, especially since there was such a restricted timeline for the completion of the project.
1.3
Problem Statement/Background Information
In a hospital setting, the system-wide workflow is one of the most important aspects in ensuring
that procedures are done in a timely manner. Though the system in place right now is functional,
there are many improvements that can be made by utilizing more modern technology. Currently,
at the University Medical Center in Tucson, Arizona, most of the hospital technology is wired
technology, and due to the amount of devices and measurements that are pertinent to a typical
patient-to-computer interface, wire clutter has become an increasing problem within the
hospital, specifically within the operating rooms, intensive care units, and recovery rooms. The
crux of the problem is emphasized by the fact that much of the hospital personnel, be it
anesthesiologists, nurses, surgeons, or residents, know that this is a hindrance to everyday
procedures. Although the problem is clear, there has not been much of an effort to change it
partly due to the consequences of changing the existing interface.
One question that may pop up is “Why change something that is already working?” One answer
is that wire clutter can become a nuisance in the hospital setting as there are a plethora of
devices to attach to the patient and hospital monitor, many wires to sanitize after use, in
addition to simply blocking passageways throughout operating and recovery room areas.
Nevertheless, wired technology has a more significant problem in that it severely limits the
ability to improve the efficiency in workflow of the hospital - trying to optimize a system with
outdated equipment and technologies is a tough task. As medical attention is becoming more
difficult to obtain, the need for improvement of the hospital system flow is rapidly increasing.
Though one could build more hospitals, that solution would clearly not be sustainable. Hence,
the necessity for wireless technology in order to increase the ease of work flow is starting to
increase, and with that comes the problem statement.
Today’s hospitals are in need of a change to the existing wired interface that allows for medical
sensors (e.g. a pulse oximeter, ECG, thermometer) attached to the patient to be able to send
wireless signals to a specified monitor dictated by hospital personnel. This wireless technology
should be able to connect with a monitor instantly in order to speed up the patient
transportation process, as well as be guarded from being displayed on a neighboring monitor
without consent. A sensor should only be specified for one monitor and vice versa.
[ 11 ]
1.4
Scope of Project: Objectives and Limitations
To produce an efficient, exclusive wireless interface between the patient and monitoring system
in an Operating Room or Intensive Care Unit room that will allow for removal of wiring from the
medical monitoring sensor on the patient to the monitoring hub. The main focus behind this
endeavor is the improvement of workflow within the hospital environment. A team of five
engineers will research different aspects of this project to develop and successfully construct a
working testable prototype while remaining within an accommodating budget of $3000. The
completed prototype will be confidently submitted, along with adequate information and results,
by May 3, 2011, otherwise the University of Arizona’s Engineering Design Day.
1.5
Expected Product Outcomes
The goal of this project is to not only create a wireless data link between patient and monitor,
but to facilitate large improvements in hospital workflow through the use of a remote. This
remote will enable hospital staff to move patients without having to connect or disconnect them
from the stationary monitoring systems. Current workflow patterns involve about three minutes
of time spent connecting and disconnecting a patient from wired sensors before and after they
are transported. With the remote detecting the wireless patient sensors and the wireless
receivers connected to the medical monitors, the staff should be able to connect any patient to
any monitor within seconds. For this specific design day, however, a proof of concept will be
presented. This proof of concept will involve the use of 3 laptops: one that will act as a “remote”
and the other two acting as “monitors”. The patient sensors will be thermistor sensors
connected to Bluetooth transceivers and will transmit patient temperature data to whichever
monitor the user specifies. This proof of concept should show that a dramatic improvement of
hospital workflow is indeed possible.
1.6
Customer Description
Dr. Robert Loeb, Director of Anesthesiology at the University Medical Center has a detailed and
distinguished background. After an internship in family medicine, Dr. Loeb completed his
residency in anesthesiology at the University of Virginia. In 1986 he began a research fellowship
in Dr. Dwayne Westenskow's bioengineering laboratory at the University of Utah. During his
fellowship he collaborated in the development of the Utah Anesthesia Workstation, a prototype
anesthesia system with integrated smart alarms, feedback control, and a graphical user interface.
Working his way west, Dr. Loeb joined the University of California, Davis as an Assistant
Professor of Anesthesiology in 1987. In 1991, he became the Director of Ambulatory Surgery
and in 1994 was promoted to Associate Professor. Dr. Loeb's research has focused on anesthesia
[ 12 ]
instrumentation, specifically on the user interface. He has adapted classical human factors
methodology to study operating room ergonomics. To date, his most notable contribution has
been a series of studies of anesthesia vigilance during real surgical cases. Dr. Loeb has been
funded twice by the Anesthesia Patient Safety Foundation. He is currently working on an
auditory display of physiologic data. Using this display, clinicians can continuously monitor their
patient's vital signs without having to look at a monitor screen. In September of 1996, Dr. Loeb
joined the Department of Anesthesiology at the University of Arizona. He was attracted by the
thriving residency program and the opportunities for collaborative research (Faculty Member
Bio Page Robert G. Loeb, MD).
2.0
System Requirements
A table of the system requirements, with their respective priorities, is shown below:
Number
Type
Description
1
Functional
The system shall transmit a wireless signal to a monitoring hub
Must
2
The signal of the system shall be able to be switched from monitor to monitor
Must
3
Have limited human interaction
Must
4
Read patient’s vitals at all times
Must
100
Form of wireless communication
Must
101
Power source
Must
102
Compatibility w/ monitors and medical devices
Must
Weight <2lbs
Must
201
Range ~ 30ft
Must
202
Battery Life > 8hrs
Must
203
Signal Transfer < 30s
Must
204
Signal Reconnection < 30s (reliability)
Must
205
One Patient System
Must
206
Compatibility with existing interface
Must
FDA, FCC, University of AZ Hospital, other government regulations
Must
System should not exceed $3,000
Must
200
Technology
Priority
Performance
207
300
Utilization
301
Off the shelf hardware/components
Desired
302
UMC medical equipment for testing purposes
Desired
303
Group Labor should consist of ~5hours a week
Desired
304
Finished by Design Day
400
Signal: Bluetooth vs. ZigBee
Suggest
401
Ease of Use: Individual Sensors vs. Central hub
Suggest
402
Battery: Dimensions vs. Capacity; Type of Battery
Suggest
403
Casing: Dimensions vs. Durability
Suggest
500
Trade-Off
Must
Reliability: malfunction, auto troubleshooting
Desired
501
System Test
Battery life runs at maximum usage
Desired
502
Safety (concerning Amp/Voltmeter); during malfunctions
Desired
503
Size: Weight and measurement
Desired
504
Accuracy: compare to current system’s signals
Desired
505
User-Friendly: connect, reconnect easily; timely
Must
[ 13 ]
3.0
Summary of PDR Results
3.1
Concepts
Design #1:

This design consists of individual ZigBee transmitters that interface with the existing sensors in
the operating room.

These individual transmitters encode and send their data to their respective port receivers
connected to the Tram module.

The receivers decode the received signal to the desired format so the Tram module can send the
signal to the monitor accurately.

This design is battery powered and geared with an external charger, one per sensor
Design #2:

This design consists of individual Bluetooth transmitters that interface with the existing sensors
in the operating room. Geared towards data applications

These individual transmitters encode and send their data to their respective port receivers
connected to the Tram module.

The receivers decode the received signal to the desired format so the Tram module can send the
signal to the monitor accurately.

This design is battery powered and geared with an external charger, one per sensor
Design #3:

This design consists of individual Bluetooth transmitters that connect to a central hub that lies
underneath the patient bed in the operating room.

This hub encodes and sends the data to the receiver connected to the Tram module.

The receiver decodes the received signal to the desired format so the Tram module can send the
signal to the monitor accurately.

3.2
This design is AC Powered by the hub’s power source
Preferred Concept
The preferred concept was design #2. A system utilizing Bluetooth technology and individual
sensors allows for the patient, doctors and nurses to be free of wires while the patient’s medical
data is securely transmitted to the same sort of monitor that the Anesthesiologists already use.
By ensuring that a remote will be able to choose which receivers and transmitters are connected
and transmitting data, the hospital staff will be able to effectively control the flow of patient data
no matter where the patient is in the hospital. As long as the sensor is recognized by the remote
and it is connected to a compatible monitor, the Bluetooth signal will transmit seamlessly. The
[ 14 ]
range of the sensor is about 30 feet which is about the size of an operating room or a good
walking distance within the recovery room area.
The Bluetooth chip used in this design is the CC2500 transceiver which is mounted on the
MSP430 wireless development kit chip. This chip allows for the user to effectively program how
data is received and transmitted and will allow the group to program accordingly.
By utilizing the Ipod Touch’s Bluetooth capabilities, the group is using an Ipod Touch as the
remote that will connect a receiver and transmitter. Apple provides a Software Development Kit
that will also allow for the group to make an application to fit the needs of the project. **
** Please see section 3.3
3.3
Key Differences in PDR selected design
There will be no use of the hospital monitor or TRAM as suggested in the PDR, and the Apple
Ipod will not be used as the remote in the system. Instead, another Bluetooth enabled laptop will
serve that purpose. Ideally, another laptop would be used as the remote. Due to the technical
issues of compatibility between DroidOS and SimpliCTI, the coding scheme for their integration
was way beyond our level of expertise.
[ 15 ]
4.0
Top-Level Design of Final Design Concept
4.1
Overview
Below is a top-level graphical representation of the final design concept:
Figure 4.1: System Flow Diagram
This diagram describes the following: A patient is connected to a medical sensor (in our case, a pulse
oximeter). The pulse oximeter is then connected to a transmitter, which will send out data from the
patient to the receiver. The transmitter is powered by AAA batteries, which can be recharged at the
recharging station nearby. The receiver is connected to the monitoring laptop. The data from the patient
is seen on the screen. To control where the transmitter sends its signal, a remote (smart phone) is used
to ensure that the correct transmitter is coupled with the correct receiver.
[ 16 ]
5.0
Subsystem/Sub-Assembly and Interface Design (Hardware)
5.1
5.1.1
Thermometer (Thermistor) Sensors
Characterizing the YSI-400 Thermometer (Thermistor)
The thermometer used in the system is supplied by the University of Arizona UMC. Furthermore,
the thermometer was a YSI-400 model (See Appendix ??). This type of thermometer is a long,
white, flexible tube with a thermistor embedded inside.
The first task in interfacing the thermometer was to characterize the embedded thermistor. In
general, thermistors are characterized by the following B-Parameter Equation:
Where,
By taking measurements of thermistor’s resistance at various temperatures the thermistor is
able to be characterized by the B-parameter and R0 at T0. For the YSI-400 thermistor being used,
measurements were taken and these parameters were found to be:
Using MATLAB, a plot of Resistance vs. Temperature for the specific characteristic equation,
was created, with the temperature converted from Kelvin to Fahrenheit:
[ 17 ]
Figure 5.1: Plot of
Figure 5.2: Plot of
with resistance swept
with resistance swept
.
.
[ 18 ]
Converting to Thermistor Resistance to a Measureable Voltage
Because the thermistor itself simply outputs a resistance, in order to interface this resistance
value with the module, we need to convert it somehow to a voltage value. To do this, we place
the thermistor in series with a resistor to use as a voltage divider, and then measure the voltage
across this series resistor. We select the value of this resistor based upon the midpoint
temperature of our desired range of temperature measurement. This allows a voltage ratio of
0.5 at our midpoint, where this voltage ratio is determined as:
For our purposes, a measurable temperature range of
a voltage divider resistor value of
is suitable. Therefore,
was selected.
Using MATLAB, a plot of this Voltage ratio vs. Temperature was created. In order to interface
this with the module simply, a linear approximation of this plot was created as well. This linear
approximation equation will be used on the module side in order to convert an inputted voltage
into a temperature. The linear approximation is an almost exact approximation of the calculated
Voltage ratio vs. Temperature plot; as shown below, with both overlaid on the same axis:
Figure 5.3: Linear fit between the voltage ratio of the thermistor (with
) and temperature.
[ 19 ]
From the above plot, we can see that a 0.5 voltage ratio corresponds to 100oF, as desired. It is
important to realize, however, that a resistance value of
will be very difficult to
replicate exactly. Therefore, in actuality, a resistor with value as close as possible to this value
with be used, and then post-processing calibration will be used on the module end to determine
the correct corresponding temperature. This calibration will be based upon test/measurement
results, which will reveal the proper offset needed. This calibration will be utilized in the
equation for the linear fit line, which will be used on the module end to convert an inputted
voltage ratio into a Fahrenheit temperature. An accurate equation of the linear fit line above is:
Because the spread in voltage ratio is so small, there needs to be a gain stage in order to increase
this spread so that the module can more accurately read variations in temperature.
From the previous plot, we see that the spread in voltage ratio is over our desired measurable
temperature range is,
In order to have 1 represent 110oF and 0 to represent 90oF, a gain is needed equal to,
For this gain, a non-inverting op-amp circuit design was used, where the gain is determined by,
Therefore, values of R1 and R2 were chosen to be,
The circuit parameters used to further interface with the MSP430 will be described in further
detail in the following section.
[ 20 ]
5.2
Transmitters
The transmitters to be used are a Bluetooth/microcontroller hybrid chip. The specific
development kit in which the transmitters are included is the MSP430 Development Kit,
developed by Texas Instruments.
See Appendix F for picture(s) of the development kit.
5.2.1
Trade Studies (Transmitters)
The decision to use Bluetooth transmitters as opposed to ZigBee transmitters was based upon
the following factors:
-
Compatibility with other devices
-
Data applications—Documentation indicates that Bluetooth signals are more apt for data
applications than ZigBee signals, which are slower in data rate transfer.
5.3
Circuit
Figure 5.4: Design 2: Thermistor/Bluetooth Circuit
In order to properly construct a working prototype board, the TI-TLC 251CP op-amp from Texas
Instruments was used. Ultimately, we selected the TI-TLC 251CP because of its superior characteristics.
The low-cost, low-power programmable operational amplifier is designed to operate with single or dual
supplies. The circuit was created with Cadance ORCAD 16.1 simulation software as shown in Figure 5.4.
The label MSP430, or label Vcc, present in the figure represents the constant voltage from the battery
while the MSP430 Aref is the variable input voltage from the voltage divider used to split the Vcc voltage.
The thermistor normally will have a resistance of 1.3k for the temperature at 100 degrees Fahrenheit.
The 66k resistor was a potentiometer resistor used to adjust the resistance at the mid way point at 100
degrees Fahrenheit. The value of the thermistor dictates the amount of current that flows through 1k
resistor at the output. The circuit was then assembled and tested.
[ 21 ]
TLC 251 Information (quoted from Texas Instruments):
The TLC251C, TLC251AC, and TLC251BC are low-cost, low-power programmable operational amplifiers
designed to operate with single or dual supplies. Unlike traditional metal-gate CMOS operational
amplifiers, these devices utilize Texas Instruments silicon-gate LinCMOS process, giving them stable
input offset voltages without sacrificing the advantages of metal-gate CMOS. This series of parts is
available in selected grades of input offset voltage and can be nulled with one external potentiometer.
Because the input common-mode range extends to the negative rail and the power consumption is
extremely low, this family is ideally suited for battery-powered or energy-conserving applications. A
bias-select pin can be used to program one of three ac performance and power-dissipation levels to suit
the application. The series features operation down to a 1.4-V supply and is stable at unity gain.
These devices have internal electrostatic-discharge (ESD) protection circuits that prevent catastrophic
failures at voltages up to 2000 V as tested under MIL-STD-883C, Method 3015.1. However, care should
be exercised in handling these devices as exposure to ESD may result in a degradation of the device
parametric performance.
Because of the extremely high input impedance and low input bias and offset currents, applications for
the TLC251C series include many areas that have previously been limited to BIFET and NFET product
types. Any circuit using high-impedance elements and requiring small offset errors is a good candidate
for cost-effective use of these devices. Many features associated with bipolar technology are available
with LinCMOS operational amplifiers without the power penalties of traditional bipolar devices.
Remote and inaccessible equipment applications are possible using the low-voltage and low-power
capabilities of the TLC251C series.
In addition, by driving the bias-select input with a logic signal from a microprocessor, these operational
amplifiers can have software-controlled performance and power consumption. The TLC251C series is
well suited to solve the difficult problems associated with single battery and solar cell-powered
applications.
Features of TI-TLC 251:

Wide Range of Supply Voltages

1.4-V to 16-V

True Single-Supply Operation

Common-Mode Input Voltage Range Includes the Negative Rail

Low Noise...30 nV/Hz\ Typ at 1-kHz (High Bias)

ESD Protection Exceeds 2000 V Per MIL-STD-833C, Method 3015.1
[ 22 ]
TI-TLC 251 Picture:
5.4
Batteries
The battery pack to be used is included with the development kit. The battery pack requires 2
AAA batteries: 2.4V, 1200mAh. Integrated into this battery pack will be an on/off switch which
will allow the hospital staff to have control over the state of the transmitters and receivers. This
allows for the battery life to be saved when the units are not in use and it will also reset any
active connections.
The life expectancy of the batteries in the system is determined based upon the below graph:
Figure 5.5: Battery Life Expectancy
This graph is based on a sample study that Texas Instruments has supplied as an example
application of the MSP430 Bluetooth Wireless Chip. In this example, the chip is used to transmit
information from a temperature sensor. This is a very similar amount of data to be transmitted
as the application we will be using. Perhaps the only exception is that the two LEDs in the sensor
will have to draw power from the batteries as well. The group estimates that by using
rechargeable batteries, even when the LEDs have to be powered, the lifetime of the batteries will
be about 2 or 3 months depending on the amount of consistent use and time of recharge.
[ 23 ]
5.4.1
Trade Studies (Batteries)
The decision to use the battery pack contained in the development kit (with AAA batteries) as
opposed to using Blackberry batteries with a custom battery pack was based upon the following
factors:
-
Ease of use—By using the developer supplied battery pack, it eliminates the need to alter the
power chip of the development kit in order to adapt it to a Blackberry battery /battery pack.
-
Efficient charging station—By using AAA batteries, more batteries are able to be charged
simultaneously. Only one Blackberry battery is capable of being charged per outlet, whereas
4 (and as many as 20) AAA batteries can be charged simultaneously per outlet.
5.5
Charging Station
The charging station can actually be selected based upon consumer preference.
However, the projected charger is to an array of a four battery/charger hubs. Thus, a projected
total of 20 batteries can be simultaneously charged at each station.
See Appendix G for picture(s) of the charging hub.
6.0
Algorithm Description and Interface Document (Software)
6.1
6.1.1
End Device (Transmitter) Software
Code Flow (ED)
The software for the end device is to perform the following function:
1. Upon powering on, the ED will continue to try joining a network with an access point until
successful joining has occurred.
2. While in idle state after connection, the ED starts up the radio making it ready for
transmission.
3. The analog to digital on the ED conversion is turned on and a converted voltage value is
saved from a register on A4 of the 16 input pin registers to the flash memory on the ED.
4. The analog to digitally converted voltage value that powers the ED is saved as a value to the
flash memory on the ED.
5. The analog to digital converter is turned off after 3 and 4.
6. The digital values saved in 3 and 4 are converted to usable values.
a. The value saved in part 3 is kept as is with no calibration done until LabVIEW [6.4].
b. The value saved in part 4 is converted to the correct voltage with an addition or
subtraction of the sensor ID number chosen by the user.
[ 24 ]
i. A sensor ID number from 2 to 6 can be subtracted from the voltage in a worst case
scenario where there is only 2.0 volts of battery left.
ii. A sensor ID number from 7 to 28 can be added from the voltage in a best case
scenario where there is 3.6 volts on the battery.
iii. Note that the sensor ID number gets treated as the value divided by 10, i.e. 2 to 6
becomes 0.2 to 0.6 and the same is true for 7 to 28.
iv. The values chosen are chosen since the voltage saved by the ED saturates at a
minimum of 1.4 and a maximum of 6.4 volts.
7. All usable values are then compiled into one giant string and sent.
8. The ED waits for received confirmation from the access point before turning the radio back
off.
9. The ED waits a quarter of a second, 250 milliseconds, before looping back to 2.
6.1.2
Additional Software Notes (ED)
Step 6b is used because it was the easiest way to append two different sensor ID numbers
chosen by the user. A more elegant solution should be feasible and would improve the overall
functionality of the system such as increasing the number of end devices. The ED code also
creates a random device address which could be utilized.
6.2
6.2.1
Access Point (Receiver) Software
Code Flow (AP)
1. Upon power on, the access point clears space in the memory to allow for maximum possible
peer link ID’s.
2. The AP will look for joining ED’s after the network is started up.
3. The AP will save any messages from the ED’s in flash memory.
4. While looking for joining ED’s, the AP will read in its own temperature and the voltage
received from the USB dongle which should read 3.5 to 3.6 volts.
5. The information is compiled in a message string and saved to flash.
6. The AP then sends both its own message string as well as any ED’s message string that it has
through the USB dongle.
a. The message strings are in similar format which if read by another program such as
LabVIEW displays as $aaaa,bbb.bF,c.c,ddd,N#.
i. The 4 a’s is either HUB0 or 000x in which x is an increasing integer value starting
from 1 which is given to the ED that joined the network in that order. HUB0
represents the AP itself.
ii. The b’s is a temperature reading in Fahrenheit.
iii. The c’s is the voltage value.
[ 25 ]
iv. The d’s is RSSI of the ED’s in % with the AP reading an RSSI value of 000%.
7. The AP waits for 250 milliseconds before looping back to 2.
6.2.2
Additional Software Notes (AP)
The AP code doesn’t read in the random device address created in the ED. If this step is added, it
would be a more elegant solution of identifying the sensors.
6.3
6.3.1
Monitor (LabVIEW) Software
Code Flow (Monitor)
1. At start up, the program reads configures and opens a serial port number inputted by the
user corresponding to the COM port used by the USB dongle. This value is listed as a MSP430
UART device in the device manager.
2. The code then reads in 60 bytes from the port.
3. The bytes are compiled string referenced in part 6a of the AP code.
4. A VI then identifies only the ED’s isolating and converting the temperature and voltage into
their respective numbers with a double bit precision format. The VI looks for the two
modified voltage values with the sensor ID added or subtracted and correctly separates the
two values into actual voltage and sensor ID number.
a. Note that the user has to know what these ID numbers are beforehand.
5. Another VI then calibrates the temperature to the actual temperature using a linear
relationship.
6. This temperature is then sent to another VI which figures out what color the thermometer
should be with it being blue when the temperature is below or at 90° F, green when the
temperature is at 100° F, and red when the temperature is at or above 110° F in a rainbow
scale.
7. At the same time, a drop down menu containing the known sensor ID numbers allow for the
user to select which sensor to display.
8. Indicators then display the temperature in thermometer and digital form. There is additional
code that shows the Celsius temperature in digital form.
9. The drop down menu is shown along with the sensor ID and the battery power.
10. The indicators display shift register values so as not to be choppy when the code takes in a
value that isn’t the correct sensor ID number.
11. The GUI display also has some decorations on top of a stop button which stops the while
loop before closing the COM port.
[ 26 ]
6.4
Remote Software
6.4.1
1.
Pseudo-Code (Remote)
The remote should utilize both a computer program such as LabVIEW and the MSP430 module
on a USB dongle connected to the computer.
2.
The LabVIEW or other program will open up the COM port and write a byte to it which
corresponds to the sensor ID we want to look at on the monitor.
3.
The MSP430 module should have a register which can be called up and save the byte as a digital
value to flash memory.
4.
The remote would act as an ED to the AP.
5.
The remote would have an internal sensor ID as well as monitor ID’s.
6.
These ID’s would then tell the monitor of each AP which sensor ID to display allowing for the AP
to be uniquely identified.
7.0
Analysis/Testing
7.1
Thermistor
The first step in testing was to confirm our linear relationship between the thermistor
temperature and the output voltage of the op-amp on the circuit. Using a hot plate to regulate
temperature of water, a beaker to hold this water, and a thermometer to test, the following
measurements were taken by submerging the thermometer into the heated water:
Op-Amp Output Voltage vs. Temperature
TEMP
V(OUT)
110
1.150
109
1.110
108
1.035
107
0.961
106
0.890
105
0.853
104
0.789
103
0.721
102
0.689
101
0.641
100
0.559
99
0.523
98
0.444
97
0.411
96
0.315
95
0.276
94
0.212
93
0.161
[ 27 ]
92
91
90
0.110
0.052
0.000
Table 7.1: Output voltage measured at the output of the circuit (i.e., input voltage to MSP430).
Figure 7.1: Plot of data from Table 7.1 (BLUE) overlaid with the ideal (RED) relationship.
The above plot shows that the output voltage corresponds with the relationship between voltage
and temperature that we are coding into the software conversion on the MSP430. Furthermore,
the error induced is increased due to inevitable measuring error (caused by using a standard
mercury thermometer for temperature measurement). Therefore, our presumed relationship
between output voltage and temperature is confirmed to be very accurate.
Relating the above relationship to a direct temperature accuracy (i.e., converting the voltage
output to a temperature, and plotting this temperature vs. the actual temperature), yields the
following:
[ 28 ]
Figure 7.2: Plot of temperature accuracy, with the outputted temperature (BLUE) compared to the
theoretical (i.e., software-coded) (RED) temperature.
From the above plot, we can see that the temperature outputted is always within 0.5% (or about
1 degree) of the actual temperature.
A similar test was done using both thermistors to ensure consistency. The second thermistor
outputted similar results. From this, we can determine that our system outputs a temperature
that is within our accuracy needs.
8.0
Development Plan
Our development plan is based mainly on the Gantt chart created (Appendix C). We started
ordering and receiving parts in late December and early January, including the batteries, the
battery charger, and the transmitter/ receiver kit from Texas Instruments. Once these parts
came in we started building our system.
The first step was to develop the software. This entailed first establishing a communication
between the receiver and transmitter in order to ensure that stable, effective connections could
[ 29 ]
be maintained with ease. Next, distinguishing between channels became the goal; this is
important as multiple transmitters and receivers in the hospital environment would be utilized.
This means the generated signals need to have unique identifiers so the signals could be routed
to the appropriate receiver. This portion of the project proved to be quite simple since we were
able to assign specific ID’s to each module that the hub could recognize. After that was finished,
we needed to ensure that the data sent from the transmitter could be interpreted once it
reached the receiver which is connected to a monitoring hub laptop. This was vital as accurate
data plays a crucial role in determining a patient’s vitals.
After the connection step was finished, we needed to integrate the thermistor sensor. This
entailed many of the same steps from before, except the transmitter was connected to a
thermistor sensor.
Next was the integration of the receiver which was one of the easier steps involved since the
receiver directly interfaced with a laptop running a LabView GUI. Once fully integrated, we
could enclose the system with an appropriate covering and test.
9.0
Requirements Review/Acceptance test Plan
9.1
Performance/Technological Requirements
The table below shows the essential performance and technological requirements for the project.
The description simply characterizes the different requirements. The priority reiterates that all
of these requirements are of high priority. The requirement status defines whether the group
has been able to verify each requirement as of yet – a requirement that hasn’t been tested will
read “not achieved” though items that are defined by manufacturers specifications will read
“achieved.” The verification source is an indication of where or who will verify that the product
has met the requirement. Certainty refers to how certain the project team is that the
requirement will be met by the end of the project – the team foresees that all of the design
requirements are attainable with a high certainty. Finally, the test column refers to the
individual tests that will define a “pass” or “fail” for each part. The more specific test plan is
below.
[ 30 ]
Description
Weight <2lbs
Range ~ 30ft
Battery Life > 8hrs
Signal Transfer < 30s
Signal Reconnection < 30s
(reliability)
One Patient System
Compatibility with existing interface
FDA, FCC, University of AZ Hospital,
other government regulations
Performance Requirements
Priority Requirement Verification Certainty Test
Status
Source
Must
Achieved
Team
High
Added all the given weights of
the components
Must
Achieved
Customer
High
Transceiver distance given by TI
at 30 ft
Must
Achieved
Customer
High
Run the system continuously for
over 8 hrs
Must
Achieved
Customer
High
Compare wire to wireless data
and calculate SNR over 10 dB
Must
Achieved
Customer
High
Connect and disconnect
repeatedly, time connection
Must
Achieved
Customer
High
Defined by requirements
Must Not Achieved Government
High
Test with hospital simulation
room and equipment
Must
Achieved
Government
High
Measure voltage and Ampere
with oscillscope and DMM
Technological Requirements
Description
Priority Requirement Verification Certainty Test
Status
Source
The system shall transmit a signal to Must
Achieved
Customer
High
Connect receiver and
a monitoring hub
transmitter with SNR of 10 dB
The signals of the system shall be
Must
Achieved
Customer
High
Connect system, then move
able to be switched from monitor to
transmitter into range of
monitor
another receiver
Read patient’s vitals at all times
Must
Achieved
Customer
High
Test reconnection reliability
Patient Safety
Must
Achieved
Use Case
High
Defined by government
regulations
9.2
Testing Descriptions
To reduce bulkiness and any possible accidents, the system needs to be lightweight. Anything
over 2 pounds in weight that is either resting on a patient or hanging off a patient would feel
uncomfortable. To test this requirement, all of the known weights were added together to get a
rudimentary weight. To fully test this requirement, after the transmitter and receiver box has
been fully made, they will be weighed without any of the sensors attached to them. Generally the
lighter the system is the better. The size of the system is mostly dependent upon the wireless
development board and chip from Texas Instruments.
One major concern when switching from a wired to a wireless communications system is the
strength and reliability of the signal. For instance, if the signal were to be lost when a person was
to step in between the transmitter and receiver, the system would not be very reliable. To
address this issue, first the system has to be able to hold a strong connection within 30 feet
between the transmitter and receiver regardless of any interference. This requires that our
signal to be quite strong, rating at about 10 dB. To test this, the signal strength would be
[ 31 ]
measured while connected under stress. The transmitter and receiver will be separated from as
little as 1 foot to more than 40 feet. The best way to test this would be to field test this in the
University Medical Center in which there exists many interfering signals.
A long lasting system would be able to sustain itself for quite a long time. The average extensive
surgery length is about 8 hours. The surgeon and anesthesiologist would have to be able to read
the patient’s vitals at all times during these 8 hours. To test battery life, the system will be
connected and run continuously. A correlation between battery charge and how long a battery
charge can power the system can be determined by independently varying the battery charge
while dependently measuring the time. If necessary, the data transfer rate may have to be
reduced to compensate for an increase in battery life.
Another concern related to the signal reliability is how fast the system can transfer data. The
data line should be fairly smooth and containing enough data points to recreate the signal. To
test the reliability of the signal, a comparison of the bit error rate (BER) should be done with the
existing hospital system. A good BER would be something less than 0.3 though idealistically, if
the BER can be lowered to 0.2, the better. A way to decrease BER would be to include multiply
layers of check sums to make sure that the system is sending the correct data. This will, however,
obviously slow down the system and a compromise will have to be reached.
Since a patient’s vitals need to be monitored almost all the time, any loss of the signal can be
disastrous. The Bluetooth communications boards will have to be able reconnect fairly quickly
by themselves. A battery life display will inform the end users of the hospital of when they might
need to switch batteries. This will ensure any downtime will be a result of software as opposed
to hardware which is harder and more time extensive to fix. Bluetooth technology inherently
tries to repair with whatever connection it was last paired with. This reconnection time will
have to be measured multiple times to determine the replicability and ease of reconnection. Also,
code will have to be written so that a patient sensor transmitter can be quickly reconnected to a
monitor receiver. An ideal time for reconnection in the hospital is less than 30 seconds.
Encryption of data is very important. The hospital can’t have a random person walking nearby
the hospital be able to pick up and steal and possibly corrupt patient vital information. Bluetooth
technology inherently encrypts data using frequency-hopping in its basic protocol layer. The
main issue rests in how to prevent another monitor receiver from picking up the wrong patient
sensor transmitter. Computer software will be written to be biased towards the signals that are
stronger and much closer. A graphics user interface, GUI, will also aid the end users in
establishing a reliable one patient system.
[ 32 ]
Since hospital use many proprietary technologies, a major overhaul in their basic equipment is
unnecessary and expensive. The system designed will have to be able to easily interface with the
existing hospital system. Mostly this can be done using hardware as the analog data transferred
through the wires are mostly the same. Any differences can be accounted for using software. To
test this, the receiver should be first hooked up into a computer before being connected to the
simulation workstations in the UMC. Finally, the last test would be to test the system
compatibility with hospital operation and recovery room interfaces.
Since the system is indeed electronic and operates on electricity, there is an inherent danger of
electronic shock that might occur to the patient or hospital personnel. The three basic
information of a circuit is voltage, amperage, and impedance. The human body in this case would
be the impedance. The human body is actually much more susceptible to the current shock as
opposed to voltage shock. If the human body experiences a shock with a current higher than 15
mA they may feel anywhere from a muscle tension all the way to respiratory paralysis. The main
issue is what the contact completes with circuit is and how quickly the shock is pulsed. If
directly bypassing the skin, a current of only 10 μA is enough to send the heart into fibrillation.
In order to stop this random spastic contraction of the heart, defibrillators often apply short
pulses of voltages up to 10 kV to restore normal coordinated heart muscle pulses. Keeping this in
mind and knowing that the battery back uses two AAA batteries, the maximum voltage that
could be applied to a patient is 3 V. The amount of current passing through the patient is the
question. Tests should be performed to make sure that possible exposures to voltage and
current don’t exceed 3 V and 1 mA. Without bypassing the skin, direct contact of 1 mA is just
perceptible as an electric shock to the patient and the issue can be addressed.
For the technological requirements, the signal strength received by the receiver shouldn’t have a
SNR any lower than 10 dB. To test this, the sent signal strength will be compared the received
signal strength. A loss of more than 3 dB is a cause for concern as that means that already half of
the signal is being lost. Interference with signal needs to be looked at and if need be, the
transmitted signal strength may have to be increased to increase the SNR if there is no way to
decrease signal attenuation.
The system should be able to easily disconnect and reconnect with another system. Currently,
the design utilizes a remote program to connect transmitters and receivers together. To test this,
multiply systems will be developed and signal properties will be compared as transmitter and
receiver pairs are connected, disconnected, and reconnected. Ideally the system will eventually
be able to connect with minimum guidance of the remote program.
[ 33 ]
The technological requirements of reading patient vitals at all times and patient safety have
already been addressed in the performance requirement acceptance test plan.
9.3
Real World Testing Simulations:
The performance and technological requirements will be tested with the following various tests
to ensure optimal performance: Connection and Basic Operation Test, Data Test,
Controls/Remote Test, and Theoretical Operation Room Test.
Connection and Basic Operation Test:
The receiver (known as the access point within CCS) will be inserted into a laptop that will
represent a monitor location within the hospital (e.g. the intensive care unit or the operating
room). Simultaneously, the transmitter (or the end point within CCS) will be connected to a
medical device (in this case a thermistor) and be held by something that emits an ideal
temperature (i.e. a cup of water around internal human body temperature). The laptop,
representing the monitor, will carry a LabView GUI in which will display a temperature between
90 to 110 degrees Fahrenheit. At this point, the monitor should be able to detect a temperature
once the patient attached device is turned on. If the LabView GUI shows a response by changing
color and temperature within the displayed thermometer, a connection between the medical
device and the ‘hospital monitor’ is deemed successful (Note that a connection between the
transmitting and receiving ends can be clued in by the way the red and Green LEDs blink on the
respective chips; however, this does not mean a true connection has been established since the
serial ports do come into play here). Next, the medical device should be moved about 30 feet
away in order to check whether the patient data is able to be read on the monitor from an
appropriate distance (as hospital personnel will need to start seeing the data within an
appropriate time). In addition, the patient will return back to original area, and be asked to
repeatedly disconnect and reconnect the patient device connection to transmitter, carefully
observing the time connection of the signal. Calculating the SNR over 10dB will compare the
wire and wireless data. Finally the system will run continuously, the transmitter will be left on,
placed near the receiver to test battery life.
Data Test:
To ensure that the correct data is being read after creating the appropriate conversions within
the LabView GUI, one must test the thermistor reading with the reading of a thermometer.
Basically, one must gather a variety of cups with water of different temperatures (around the
region of 80-120 degrees Fahrenheit). Once this is done, one can take a thermometer and
measure the temperature of one of the cups. Then, allow the thermistor to sit in the cup with the
[ 34 ]
thermometer and compare the temperature value read. Though error is expected, one should
note that it should be more accurate around 95 to 105 degrees as that is a temperature attune to
functioning humans (though the ends may indicate sickness). Do this for a variety of cups with
different temperatures to gain sufficient data.
thermometer thermistor
95
94.4305
99
98.8803
96
95.5934
94
94.2197
91
91.8688
90.5
91.4297
90
91.0332
Table 9.1: Thermometer vs. Thermistor Sensor (Actual Data)
Controls/Remote Test:
Depending on whether a remote or controls within the LabView GUI are created, the overall
scheme for both is similar. To test whether a control mechanism works, one must have two
temperature sensors on and sending signals separately. First, take one monitor (laptop) and
ensure both signals from the end points can be read (this can be done with either the GUI or the
provided sensor monitor from TI). Once this is done, place both sensors next to a temperature
that is distinct (i.e. one cold, one hot). Using the GUI, flip between the sensors and see whether
the temperature read in the GUI is different as each switch is made. If so, the control/remote
works. To further verify the system, add another monitor in the mix, and ensure that both
sensors can be read by both monitors, and that the switching between sensors works for both.
(Note that each device at this point should be identified by a distinct number. This allows one to
know who the patient is, and is the mechanism that is switched).
Theoretical Operation Room Test:
The receiver will be inserted into the monitor and the transmitter will be switched on and
connected to the thermal sensor. The transmitter and receiver will be selected from list of
Bluetooth options available on monitor. The receiver and transmitter will agree to communicate
with each other and establish a connection. The transmitter will be connected to the thermal
sensor attached inside the patient’s mouth. The monitor will indicate the measurements taken
from the thermistor, confirming transmission. The patient will then be asked to walk exactly 29
feet away from receiver confirming transmission of patient’s vitals. The patient will be asked to
walk 31 feet away from receiver confirming no transmission of patient’s vitals. The patient will
return back to original area, and be asked to repeatedly disconnect and reconnect connection to
[ 35 ]
transmitter, carefully observing the time connection of the signal. Calculating the SNR over 10dB
will compare the wired and wireless data. Finally the system will run continuously, the
transmitter will be left on, placed near the receiver to test battery life.
9.4
Acceptance Test Plan
Acceptance Test Sheet
Description
Observation of Test
Test Score
1-Failure
3- Satisfactory
5-Exceeds
Standards
Date (01/01/2011)
Necessary or Possible
Improvements
Weight < 2lbs
1
2
3
4
5
Signal Range ~
30ft
Battery Life >
8hrs
Signal Transfer <
30s
Signal
Reconnection
(Reliability)
One Patient
System
Compatibility
with existing
interface
FDA, FCC,
University of AZ
Hospital, other
government
regulations
1
2
3
4
5
1
2
3
4
5
1
2
3
4
5
1
2
3
4
5
1
2
3
4
5
1
2
3
4
5
1
2
3
4
5
Table 9.2: Acceptance Test Plan from the CDR report
This is the test plan used to carry out the testing procedures necessary to determine the success
of the project. With each test, the ability of the product to meet each of the requirements is
tested on a scale from one to five. A score of one means the test for the system is a failure at that
time, while a score of five would deem that requirement as exceeding expectations. A three
would be a passing score, but going beyond the standards is definitely something that the group
is aiming for as part of the engineering aspect in the project is not to settle for what works, but
for what is the most efficient and workable for the sponsor. Looking at the aforementioned
requirements cited in the assessment description above, the chart is able to cover all the bases
that would deem the project a success. A date box has been added to ensure all tests are dated.
This is also helpful in the case when a certain requirement had a higher score in a previous test.
This would allow backtracking in the testing phase to figure out what happened to adjust a
requirement’s score either positively or negatively. An observation column was added to allow
pure observations to be made about a requirement during the testing phase. Another column for
[ 36 ]
improvements was added to allow for notes regarding what worked, what did not, as well as
how any one of the requirements could be better developed. Below are a couple of acceptance
test plan forms filled out. Bolded numbers indicate the score given.
Acceptance Test Sheet
Description
Observation of Test
Test Score
1-Failure
3- Satisfactory
5-Exceeds
Standards
Date (04/28/2011)
Necessary or Possible
Improvements
Weight < 2lbs
Success: Not an important
variable as this was more of a
concept based design. However,
the sensor itself was very light.
1
2
3
4
5
Signal Range ~
30ft
Success: Signal for the most part
left range at about 25-30ft. Long
distance transmission is not
wanted, and does not work.
Success: The battery was tested
for over 8 hours, and did not
give up. It should be added
though that the batteries were
never changed for the most part
throughout the entire duration
of the project.
Success: Connection established
within seconds
Signal never really dropped
once established with an access
point.
1
2
3
4
5
1
2
3
4
5
Voltage drop as more of the
battery is used is something to
consider as the sensor is
voltage driven.
1
2
3
4
5
N/A
1
2
3
4
5
Fail: Code has not been able to
carry a control. Remote function
not working
Fail: Compatible with sensor,
but not with hospital monitor.
1
2
3
4
5
1
2
3
4
5
However, as more access
points are added, a crashing
did occur a couple of times.
Seeing as the code did work
with the set up in mind, this is
kind of a phenomena.
Need to look oat code and find
some help in regards to tech
support
This will need to be looked at in
the future.
This was a concept, so it was
not ready to be used in a
hospital setting. However, the
chip chosen did obey rules for
frequency setting.
1
2
3
4
5
Battery Life >
8hrs
Signal Transfer <
30s
Signal
Reconnection
(Reliability)
One Patient
System
Compatibility
with existing
interface
FDA, FCC,
University of AZ
Hospital, other
government
regulations
Housing was not implemented,
as we used the provided static
bags. However, it is assumed
that a light plastic would be
best.
Not much improvement needed
as it is dictated by the chip we
purchased.
Will become more of a factor as
its implementation draws
closer to hospital use.
Figure 9.3: Acceptance test April 28
Acceptance Test Sheet
Date (05/01/2011)
[ 37 ]
Description
Observation of Test
Test Score
1-Failure
3- Satisfactory
5-Exceeds
Standards
Weight < 2lbs
Success: Not an important
variable as this was more of a
concept based design. However,
the sensor itself was very light.
1
2
3
4
5
Signal Range ~
30ft
Success: Signal for the most part
left range at about 25-30ft. Long
distance transmission is not
wanted, and does not work.
Success: The battery was tested
for over 8 hours, and did not
give up. It should be added
though that the batteries were
never changed for the most part
throughout the entire duration
of the project.
Success: Connection established
within seconds
Signal never really dropped
once established with an access
point.
1
2
3
4
5
1
2
3
4
5
Voltage drop as more of the
battery is used is something to
consider as the sensor is
voltage driven.
1
2
3
4
5
N/A
1
2
3
4
5
Success; with the controls in
place, one can dictate which
monitor is seen depending on
patient number.
Compatible with sensor, but not
with hospital monitor.
1
2
3
4
5
However, as more access
points are added, a crashing
did occur a couple of times.
Seeing as the code did work
with the set up in mind, this is
kind of a phenomena.
A remote would have been nice
that allows one to switch from
afar.
1
2
3
4
5
This will need to be looked at in
the future.
This was a concept, so it was
not ready to be used in a
hospital setting. However, the
chip chosen did obey rules for
frequency setting.
1
2
3
4
5
Will become more of a factor as
its implementation draws
closer to hospital use.
Battery Life >
8hrs
Signal Transfer <
30s
Signal
Reconnection
(Reliability)
One Patient
System
Compatibility
with existing
interface
FDA, FCC,
University of AZ
Hospital, other
government
regulations
Necessary or Possible
Improvements
Housing was not implemented,
as we used the provided static
bags. However, it is assumed
that a light plastic would be
best.
Not much improvement needed
as it is dictated by the chip we
purchased.
Figure 9.4: Acceptance Test May 1
10.0 Summary of Risk Analysis and Mitigation Plan
10.1
Risk Analysis
The risk analysis, formed during the compilation of the critical design review presentation, was
an assessment done to categorize the possible risks the wireless system we plan to integrate
could cause. Being that this device would be in the hospital device and eventually have to deal
with human subjects, there were many things to consider when analyzing what could possibly
demerit the usability of our device. The chart below reflects the possible things that could go
wrong with our device during the design, testing, and application phases, with the most
[ 38 ]
emphasis on the latter. As seen from the scores given, there were not many probable things that
occur, mostly because our device is not too intuitive concerning its danger in its application, in
addition to the fact that the worst possible thing that could happen (mostly regarding to faulty
connections within the wireless path) do not provide any significant danger due to being
covered properly. Other problems we must consider are found within the design and testing
stages, such as not meeting design specs, hardware not working, and faulty connection.
Because of the changes made to our design since the CDR, there has been much variability in the
aforementioned stages, and as such, the preconceived scores and predictions for such risk were
not applicable, though new ones we have come to think about and discover have been
documented. Items that were once documented, yet not really perceived up to the time leading
to Design Day will be strike through. New items will be listed in italics
When looking at the severity score, we scored them relatively high compared to the probability
side. Again, because this is a hospital environment, there were many things to be considered
when something goes wrong, especially if a faulty connection occurs. The point of our device
was to alleviate an already complex system. If a connection problem does occur, it immediately
makes our device’s purpose null, and severely demerits what we were told to do. Therefore,
once completing the scoring of our risk analysis, we found most problems to be unlikely, but if
they did occur, the consequences would be detrimental.
Design & Testing Phases
Design Problems
Do not meet specs
Incorrect Connection with Circuits
Incorrect software code
Lack of separate remote control
Testing Problems Reserving a simulation room in UMC
Hardware is not working properly
Software not working properly
Faulty control of the program
Normal Usage
Electrical Safety
Incorrect connection with plug-in
for receiver or transmitter
Inserting incompatible battery
Battery Failure
Loose Circuitry
Physical Safety
Medical device’s transmitter is
uncomfortable for patient
Other Hazard
Operating error concerning
identifying the correct patient
number
Code Probability Severity
RA-1
1.0
10.0
RA-2
1.0
3.0
RA-3
3.0
5.0
RA-6
8.0
2.0
RA-3
0.0
3.0
RA-4
3.0
5.0
RA-5
6.0
5.0
RA-7
4.0
5.0
Code Probability Severity
RB-1
2.0
4.0
Score
10.0
3.0
15.0
16.0
0.0
15.0
30.0
20.0
Score
8.0
RB-2
RB-3
RB-4
RB-5
0.0
2.0
3.0
3.0
7.0
6.0
6.0
1.0
0.0
12.0
18.0
0.0
RB-6
4.0
7.0
28.0
[ 39 ]
Operating error on how medical
device is attached
Signals sent are inaccurate or are
going to the wrong receiver
Failure to connect to any device
Fault Condition
Electrical Safety
Physical Safety
Other Hazard
Operating error within the main hub
Accidental excessive liquid exposure
Patient Transfer
Accident/Impedance
Physical damage (dropping,
slamming)
Device within system breaks
Misplacement
RB-7
0.0
5.0
0.0
RB-8
4.0
7.0
28.0
RB-9
2.0
10.0
20.0
Code Probability Severity
RC-1
1.0
1.0
RC-2
1.0
8.0
RC-3
1.0
3.0
Score
1.0
8.0
3.0
RC-4
1.0
3.0
3.0
RC-5
RC-6
1.0
1.0
8.0
0.0
8.0
0.0
Table 10.1: Risk Analysis Probability and Severity Scoring
Score from 0-100 (0 being none and 100 being catastrophically extreme)
Concerning the changes to our project, not many things were changed. Because this project
ended up becoming more of a proof of concept by the end, consideration of patient risks were
not really taken in to account, though it should be a factor considered in future iterations of the
project. New additions that were somehow not conceived during the CDR report was software
risks, which we ended up facing a lot of throughout the creation of this project. Looking back,
they were actually quite probable and came with much severity since a software problem
usually meant that the entire thing would not work. However, once the code of the chip (not the
GUI) was conceived with a full-proof code, it worked splendidly. Most of the future problems
came with implementing the GUI, which would have bouts of working and not working though
nothing was actually changed within the actual code. There may have been some inherent
compatibility problems, though the real reason has never been solved. Other risks included
involve remote implementation, which changed significantly as the project evolved due to the
importance of project flow. A few notes to include that we never completed a test within the
hospital as we came to find out that the implementation of a hospital monitor for the time
allotted would be cumbersome (In addition to having up to three different portable ones with
different interfaces and having few manufacturer’s specification sheets with them did not help at
all). Most of the testing and date gathering was done at sites that did carry the technology we
needed (e.g. oscilloscope). Also, the monitor we ended up using was our personal laptops
installed with a LabView code.
10.2
Risk Analysis Plan and Charts
The next step to the risk analysis included making a mitigation plan, which is provided in the
table below. After computing scores for each of the problems and charting them within a table
[ 40 ]
(found in the appendix section), we came up with ways to reduce either the probability or
severity of each of the problems. It should be noted though that the wireless system produced is
not replacing something that does not work (it is definitely more of a conceptual design),
meaning if a failure in connection does occur, for instance, there is ultimately something to go
back to that has been working for years within the University Medical Center. In addition, much
of the mitigation relies on making a reliable connection, which is definitely something to
consider seeing as that basically composes the purpose of our project. As always, some of the
fault conditions do rely on people being safer or less clumsy, as well as being educated about our
device; this is something that kind of falls out of our control if the design is implemented.
Design & Testing Phases
Design Problems
Do not meet specs
Incorrect Connection with Circuits
Incorrect software code
Lack of separate remote control
Testing Problems
Hardware is not working properly
Software not working properly
Faulty control of the program
Normal Usage
Electrical Safety
Incorrect connection with plug-in for
receiver or transmitter
Inserting incompatible battery
Battery Failure
Loose Circuitry
Physical Safety
Medical device’s transmitter is
Code
Mitigation
RA-1 Revise Design until
constraints are met or
exceeded
RA-2 Reconfigure wiring and try
again; ask for advice
RA-3 Talk with customer support;
seek advice of someone who
is more familiar with coding
interface; try again
RA-7 Implement controls within
the LabView GUI as a backup
RA-4 Reorder part/ talk with
customer support
RA-5 Check if correct serial port is
connected to the GUI; read
error to understand what is
wrong; check to see control
variable is set to something
and not blank in GUI
RA-7 Check to see if control is set to
an actual distinct device
rather than nothing.
Code
Mitigation
RB-1 Ensure that the plugs are
labeled so on knows what
device is the receiver and the
transmitter
RB-2 Provide only one type of
battery; because they are
rechargeable, using a
different type would be hard
to do
RB-3 Provide more batteries than
there are devices
RB-4 Ensure all circuits are fitted
well and fitted
RB-5 Place the transmitter off
[ 41 ]
Other Hazard
Fault Condition
Electrical Safety
Physical Safety
Other Hazard
uncomfortable for patient
Operating error concerning
identifying the correct patient
number
RB-6
Operating error on how medical
device is attached
RB-7
Signals sent are inaccurate or are
going to the wrong receiver
RB-8
Failure to connect to any device
RB-9
Operating error within the main hub
Accidental excessive liquid exposure
Patient Transfer
Accident/Impedance
Physical damage (dropping,
slamming)
Device within system breaks
patient
Ensure receiver is
programmed so that it knows
what patient’s data to take in
before the actual patient
arrives
Check to make sure pertinent
devices are on patient
correctly
Make sure receivers and
transmitters are going to
correct places
Reboot; Training
Code
Mitigation
RC-1 Tech Support within hospital
RC-2 Make sure device is not near
liquids
RC-3 Be careful
RC-4
Decrease clumsiness
RC-5
Replace accordingly; provide
spares
Misplacement
RC-6 Try to keep it in the same
place.
Table 10.2: Risk Assessment Mitigation Plan
A diagram was made at the end of the analysis to show a more visual mapping of where the
probabilities and severities lie for each problem. The diagram accentuates the fact our
prediction of risks mostly lie along the line of unlikely but rather severe if the problem does
appear (all problems lie along the guarded risk and high risk sections). Conversely, neither
elevated risks nor severe risks were common in our project according to our scoring. This is
good to hear due to the fact we do not expect any extremely large problems with the overall
project besides the software aspect.
[ 42 ]
Figure 10.1: Risk Analysis Diagram
11.0 Closure
11.1
Review of Final Project Report
The Final Project Report served as an avenue for us to compile our thoughts, research, and
analysis of the project we completed for the University of Arizona Engineering Design Day in
May 2011. Our project, “Development of Wireless Link between Patient and Monitor in
Anesthesia Room” has evolved rapidly within the past few months. Starting with our System
Requirements Review and Preliminary Design Review, our team had the impression that our
project was solely based on creating wireless connections between a patient connected to
various medical devices, such as an EKG or pulse oximeter, to a monitoring hub due to the vast
amounts of wire clutter in a typical operating room inside the University Hospital. Unfortunately,
this original scope seemed rather broad, especially since wireless technologies are utilized in
hospitals already, making us question our projects innovation and sense. However, after our
preliminary design review and talking to our sponsor, we narrowed our focus and are aiming to
develop a wireless device that will ease the work flow of day to day operations within the
hospital environment (including the recovery room, the operating room, and the intensive care
unit). With this in mind, we have come up with an idea that we think will definitely accomplish
this.
[ 43 ]
The system itself utilizes a Bluetooth connection between the transmitter, which is connected to
the medical sensor (in this case a thermistor) attached to the patient, that will go to the receiver,
which is connected to the tram module that is installed within the monitoring hub, the medical
component that displays the data of the patient. Between the transmitter and receiver, a remote
(in this case, a laptop, but it could be a smart phone or any number of other devices), can be
utilized to ensure the proper transmitter is going to the correct receiver, allowing for less error
within the entire system. We feel that this system will be conducive for hospital work flow as the
remote is portable and will easily allow for hospital employees to select channels in a timely
fashion when compared to rewiring everything to a new monitoring hub.
Included in the system are rechargeable AAA batteries which will be the power source for the
transmitter, a housing that protects the patient from the device electronics (the actual housing is
not important to the design since it is more of a design of concept than implementation). Also
included would be a battery charging station and a charging station for the phone, as well as
other helpful implementations discussed earlier in this report.
After a thorough analysis of other options to use for things such as the connections or type of
batteries, we feel that the design chosen works best as it utilizes resource that are not foreign to
us, in addition to meeting the requirements easily without too much consequence. Though other
options exist that may have been slightly better for the system itself, some of the components we
chose to buy came with certain limitations (i.e. the transmitter bought could be powered easily
through AAA batteries since it was built in). Zigbee also played a large part in our original
thought process, but we decided to stick with Bluetooth due to familiarity within our group
(though for the signal required, it did not really matter which one we picked). Other options
picked were discussed in the report.
User interaction was a key player to our design, since a lot of the focus of our project deals with
the work flow. After being given the opportunity to go around University Hospital and talk to
different hospital workers, we figured the biggest partakers in using the system would be nurses,
anesthesiologists, and residents. The anesthesiologist, as well as the resident, is usually
responsible for setting up the monitoring hub inside the operating room. Hence, with that
responsibility, they would be working with the wireless component a lot as they would be
hooking up the pertinent medical device to the patient and making sure the data could be read
by the monitor. Nurses, found in the recovery room and intensive care unit, would be working
mostly with the controls of the smart phone; as patients transfer from the operating room to
either of the other two rooms, the nurse would be responsible in making sure the proper
transmitter is being connected to the new receiving hub.
[ 44 ]
Overall, we were able to successfully demonstrate the concept that using a wireless transmitting
system in a hospital setting would drastically improve hospital workflow efficiency. Staff would
be able to use a remote to choose which monitor they would like to see patient data and can do
so almost instantaneously instead of waiting for the physical wired connections to be completed.
11.2
Next Steps
This section is dedicated to the exploration of the possibilities regarding the future of this
project and where it may lead. As it stands right now the project is a working proof-of-concept.
That means that the system, though it is functional and demonstrates the concept that efficiency
with monitoring systems in the hospital can be streamlined, the system itself cannot be
implemented in a hospital setting. That being said, since this project is a proof-of-concept and it
has been demonstrated that overall hospital efficiency and workflow have improved, this project
could be expanded in the future to be interfaced to real hospital equipment. In addition, different
types of sensors could also be used to demonstrate that this could be a system-wide change that
could really streamline the entire process. An entire group of sensors could be associated with
one another so that the hospital staff need only hook them up once and connect that group all at
once to prepare the patient – something that used to take 4 to 5 minutes would then only take 30
seconds. Overall, this is an exciting and promising frontier in the field of medicine and
streamlining the patient’s journeys through the hospital.
12.0 References
MSP430 Website - http://focus.ti.com/docs/toolsw/folders/print/ez430-rf2500.html
Application example - http://focus.ti.com/lit/an/slaa378c/slaa378c.pdf
Faculty Member Bio Page Robert Robert G. Loeb, MD . 2008 Department of
Anesthesiology . Retrieved December 3,2010, from
http://www.anesth.medicine.arizona.edu/faculty/facultyBio.cfm?ID=53
Pulse Oximetry (SpO2). 2006 by ZOLL Medical Corporation. Retrieved
Decemeber 3, 2010, from http://www.zollcanada.ca/9650-0202-01.pdf
MSP430x2xx Family User's Guide_SLAU144G. Dallas, TX: Texas Instruments Inc., Mar. 2011. PDF.
eZ430-RF2500 Development Tool User's Guide_SLAU227. Dallas, TX: Texas Instruments Inc., Apr.
2009. PDF.
MSP430x22x2/MSP430x22x4 Mixed Signal Microcontroller_SLAS504B. Dallas, TX: Texas
Instruments Inc., Jul. 2007. PDF.
[ 45 ]
Wireless Sensor Monitor Using the eZ430-RF2500_SLAA378B. Dallas, TX: Texas Instruments Inc.,
Sep. 2008. PDF.
TRAM® 451, 451M, 451N and 851, 851M, 851N Modules Service Manual. GE
Medical Systems Information Technologies, 2002. Retrieved October 18,
2010.
http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=05189592
http://www.floridaits.com/SEMP/Files/PDF_Report/ApxR.pdf
http://electronics.howstuffworks.com/bluetooth5.htm
http://www.bluetooth.com/English/Technology/Building/Pages/Specification.aspx
http://www.zigbee.org/Products/DownloadZigBeeTechnicalDocuments.aspx
http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/PostmarketRequirements
/QualitySystemsRegulations/default.htm
http://www.fda.gov/MedicalDevices/Safety/MedSunMedicalProductSafetyNetwork/ucm12781
3.htm
http://www.fda.gov/downloads/MedicalDevices/Safety/MedSunMedicalProductSafetyNetw
http://www.advindsys.com/ApNotes/YSI400SeriesProbesRvsT.htm
13.0 Appendix
13.1
Appendix A - Specialized Jargon:
Anesthesiologist:
An anesthesiologist is a physician specially trained in anesthesia and perioperative medicine.
The physician is in charge of monitoring a patient’s vitals before, during, and after surgery. They
are the ones responsible for delivering anesthesia safely to patients to ease comfort or reduce
potential pain during and after surgery.
Operating room:
[ 46 ]
An operating room is a sterile room that is about 30 by 30 square feet in which anesthesiologists,
surgeons, and other doctors as well as residents or nurses, help carry out surgical procedures on
a patient.
Bluetooth:
Bluetooth is a proprietary open wireless technology developed for exchanging data over short
distances, i.e. replacing the cable between a computer and one’s printer. Part of the IEEE
802.15.1 standard protocol, Bluetooth utilizes frequency-hopping spread spectrum to encrypt its
data and maintain pairing between master and slaves.
Zigbee:
Similar to Bluetooth, Zigbee is another proprietary open wireless technology. However, Zigbee
was developed for industry use with much larger ranges and longer battery life in mind.
Applications of Zigbee tend towards the remote control side of an industry or company building.
Part of the IEEE 802.15.4 standard protocol, one of the main differences between Bluetooth and
Zigbee is that Zigbee uses direct-sequence spread spectrum as opposed to FHSS.
[ 47 ]
13.2
Appendix B – Abbreviations:
PDR – Preliminary Design Review
CDR - Critical Design Review
WDT – Wireless Development Kit
DVM – Digital Volt Meter – also known as DMM – digital multimeter
SNR – Signal to noise ratio
GUI – Graphical User Interface
IR – Infrared
LED – Light emitting diode
ECG – Electro Cardiogram
FDA – Food and Drug Administration
FCC – Federal Communications Commission
UMC – University Medical Center
CCS – Code Composer Studio
[ 48 ]
13.3
Appendix C – Budget and Suppliers
13.3.1 Budget
This project is funded through the University of Arizona in conjunction with the sponsor, Dr.
Robert Loeb. Dr. Loeb is the Director of Anesthesiology at the University Medical Center in
Tucson, Arizona. He has allocated money for this project from his own research funds. This
project is cleared to use up to $3000 to accomplish the established goals.
13.3.2 Bill of Materials
Material
Price
MSP430 WDT
$49.00 3
6.60%
$0.00
Free 2
0.00%
$0.00
$2.04 5
6.60%
$2.41
Sensor (pulse oximeter)
Plastic housing 1551LGY
Quantity Tax
Small nuts and bolts
$10.00 1
(pack.)
Wiring and solder (pack.) $10.00 1
Oscilloscope, DVM, etc.
Rechargeable AAA
Batteries (4 pack)
Energizer Rechargeable
15 Minute Charger
Total Material Cost
Free 1 each
Shipping Total Price Vendor(s)
$156.70 TI
Lead time
Ordered
Free Hospital (Dr.
Loeb)
$13.28 Digi-Key
Ordered
3-7 days
-
-
$10.00 ACE
1 day
-
-
$10.00 ACE
1 day
0.00%
$0.00
$13.09 2
6.60%
$0.00
Free Borrow from 1 day
UA
$27.91 Amazon.com Ordered
$28.39 1
6.60%
$5.79
$36.05 Amazon.com Ordered
$253.95
Total Budget
$3,000.00
Leftover Budget
$2,746.05
Longest Lead
1 week
Time
13.3.3 Suppliers
Possible suppliers of materials include: Texas Instruments, Digi-Key, the sponsor – Dr. Loeb, ACE
Hardware, the University of Arizona, and various online retailers similar to Amazon.com
13.3.3a
Long-lead-time Items
The longest lead time for all of the materials required in this project is about a week.
Considering most of the parts necessary to make progress on this project have already
been ordered, this lead time will likely not be any issue.
[ 49 ]
13.4
Appendix D - Project Management
13.4.1 Part Status
The chart above is the current status of parts for our project. As of now, everything pertaining to the success of the
project has passed the acceptance stage.
13.4.1 Gantt Chart
WBS
Task Name
Duration
Start
Finish
1
Project Management
1 day?
Mon 8/23/10
Mon 8/23/10
1.1
Formulate Project Management Plan
1 day?
Mon 8/23/10
Mon 8/23/10
1.2
Progress Reports
1 day?
Mon 8/23/10
Mon 8/23/10
2
Requirements Development
29 days
Wed 9/8/10
Mon 10/18/10
2.9
Draft Concept of Operations
10 days
Wed 9/8/10
Tue 9/21/10
2.1
Develop Concept of Operations
5 days
Wed 9/22/10
Tue 9/28/10
2.2
Draft Requirements
13 days
Wed 9/22/10
Fri 10/8/10
2.2.1
I/O Functional Requirements
3 days
Wed 9/22/10
Fri 9/24/10
2.2.2
Technology Requirements
3 days
Wed 9/22/10
Fri 9/24/10
2.2.3
I/O Performance
3 days
Mon 9/27/10
Wed 9/29/10
[ 50 ]
2.2.4
Utilization of Resources
4 days
Mon 9/27/10
Thu 9/30/10
2.2.5
Trade-Off
3 days
Fri 10/1/10
Tue 10/5/10
2.2.6
System Test (ATP)
6 days
Fri 10/1/10
Fri 10/8/10
2.3
Submit Draft Requirements for Review
1 day
Thu 9/30/10
Thu 9/30/10
2.3.1
Submit Draft Requirements
1 day
Thu 9/30/10
Thu 9/30/10
2.3.2
Requirements Review Meeting
1 day
Thu 9/30/10
Thu 9/30/10
2.4
Revised Requirements
1 day
Fri 10/1/10
Fri 10/1/10
2.4.1
I/O Functional Requirements
1 day
Fri 10/1/10
Fri 10/1/10
2.4.2
Technology Requirements
1 day
Fri 10/1/10
Fri 10/1/10
2.4.3
I/O Performance
1 day
Fri 10/1/10
Fri 10/1/10
2.4.4
Utilization of Resources
1 day
Fri 10/1/10
Fri 10/1/10
2.4.5
Trade-Off
1 day
Fri 10/1/10
Fri 10/1/10
2.4.6
System Test (ATP)
1 day
Fri 10/1/10
Fri 10/1/10
2.5
Submit Revised Requirements
2 days
Mon 10/4/10
Tue 10/5/10
2.6
Respond to Comments
3 days
Wed 10/6/10
Fri 10/8/10
2.7
Freeze Requirements
1 day
Mon 10/11/10
Mon 10/11/10
2.8
Final ATP Acceptance
5 days
Tue 10/12/10
Mon 10/18/10
3
System Design
31 days
Mon 10/4/10
Mon 11/15/10
3.1
High Level Design
8 days
Mon 10/4/10
Wed 10/13/10
2 days
Mon 10/4/10
Tue 10/5/10
3.1.1
Design Concept #1: Individual
Sensors/Zigbee Transmission
3.1.1.1
Identify Derived Requirements
0 days
Mon 10/4/10
Mon 10/4/10
3.1.1.2
High Level Functional Design
1 day
Mon 10/4/10
Mon 10/4/10
3.1.1.3
High Level Physical Design
1 day
Mon 10/4/10
Mon 10/4/10
3.1.1.4
Submit High Level Design for Review
1 day
Tue 10/5/10
Tue 10/5/10
4 days
Wed 10/6/10
Mon 10/11/10
3.1.2
Design Concept #2: Individual
Sensors/Bluetooth Transmission
[ 51 ]
3.1.2.1
Identify Derived Requirements
1 day
Fri 10/8/10
Fri 10/8/10
3.1.2.2
High Level Functional Design
2 days
Wed 10/6/10
Thu 10/7/10
3.1.2.3
High Level Physical Design
2 days
Wed 10/6/10
Thu 10/7/10
3.1.2.4
Submit High Level Design for Review
1 day
Mon 10/11/10
Mon 10/11/10
4 days
Wed 10/6/10
Mon 10/11/10
Identify Derived Requirements
1 day
Fri 10/8/10
Fri 10/8/10
3.1.3.2
High Level Functional Design
2 days
Wed 10/6/10
Thu 10/7/10
3.1.3.3
High Level Physical Design
2 days
Wed 10/6/10
Thu 10/7/10
3.1.3.4
Submit High Level Design for Review
1 day
Mon 10/11/10
Mon 10/11/10
3.1.4
Modeling and Simulation
6 days
Wed 10/6/10
Wed 10/13/10
3.1.4.4
Simulation Model Development
3 days
Wed 10/6/10
Fri 10/8/10
3.1.4.5
System Experimentation
3 days
Mon 10/11/10
Wed 10/13/10
3.9
Formulate Development Plan
2 days
Tue 10/12/10
Wed 10/13/10
3.3
Preliminary Design Review (PDR)
1 day
Tue 10/19/10
Tue 10/19/10
3.4
Revise High Level Design
5 days
Wed 10/20/10
Tue 10/26/10
3.5
Detail Design (Design Concept #2)
8 days
Wed 10/27/10
Fri 11/5/10
3.5.2
Components 1: Sensor Design
3 days
Wed 10/27/10
Fri 10/29/10
3.5.5
Component 2: Receiver Design(s)
5 days
Wed 10/27/10
Tue 11/2/10
3.5.6
Component 3: Sensor Software
5 days
Wed 10/27/10
Tue 11/2/10
3.5.6.1
Listen and Read
5 days
Wed 10/27/10
Tue 11/2/10
3.5.6.2
Determine Signal to Transmit
1 day
Wed 10/27/10
Wed 10/27/10
3.5.6.4
Format and Send Message
3 days
Wed 10/27/10
Fri 10/29/10
3 days
Wed 10/27/10
Fri 10/29/10
3.1.3
3.5.6.7
Design Concept #3: Sensors to Patient
Hub/Bluetooth Transmission
Receive Data/Format Data to Match Monitor
Requirements
3.5.4
Component Interface Definition
5 days
Mon 11/1/10
Fri 11/5/10
3.7
Critical Design Review
1 day
Mon 11/8/10
Mon 11/8/10
[ 52 ]
3.8
Revise Detailed Design
5 days
Tue 11/9/10
Mon 11/15/10
4
System Construction
77 days
Mon 11/22/10
Tue 3/8/11
4.1
Acquire/Order Hardware
1 day
Mon 11/22/10
Mon 11/22/10
4.1.2
Bluetooth Modules
1 day
Mon 11/22/10
Mon 11/22/10
4.1.3
Batteries
1 day
Mon 11/22/10
Mon 11/22/10
4.1.4
Cables
1 day
Mon 11/22/10
Mon 11/22/10
4.1.5
Connectors
1 day
Mon 11/22/10
Mon 11/22/10
4.1.6
Monitor
1 day
Mon 11/22/10
Mon 11/22/10
4.1.7
Sensors
1 day
Mon 11/22/10
Mon 11/22/10
4.1.8
Electrical Components
1 day
Mon 11/22/10
Mon 11/22/10
4.2
Construction Builds
38 days
Mon 1/10/11
Wed 3/2/11
4.2.1
Build 1 - software
5 days
Mon 1/10/11
Fri 1/14/11
4.2.1.1
communicate between receiver and transmitter
1 day?
Mon 1/10/11
Mon 1/10/11
1 day?
Mon 1/10/11
Mon 1/10/11
1 day?
Mon 1/10/11
Mon 1/10/11
1 day?
Mon 1/10/11
Mon 1/10/11
5 days
Mon 1/31/11
Fri 2/4/11
1 day?
Mon 1/31/11
Mon 1/31/11
1 day?
Mon 1/31/11
Mon 1/31/11
4.2.1.2
4.2.1.3
4.2.1.4
4.2.2
4.2.2.1
4.2.2.2
distinguish the specific channel of
communication
send real data/receive data
ensure that there is no cross-talk between two
pairs of sensors on different channels
Build 2 - integrate sensor
build plug device that interfaces with sensor and
bluetooth chip
format data from sensor to be send by the
transmitter
4.2.2.3
send data/receive data
1 day?
Mon 1/31/11
Mon 1/31/11
4.2.2.4
characterize the received signal
1 day?
Mon 1/31/11
Mon 1/31/11
4.2.3
Build 3 - integrate receiver
5 days
Mon 2/21/11
Fri 2/25/11
1 day?
Mon 2/21/11
Mon 2/21/11
3 days
Mon 3/14/11
Wed 3/16/11
4.2.3.1
4.2.4
create bluetooth receiver module that integrates
with monitor
Build 4
[ 53 ]
4.2.4.1
full system troubleshoot
1 day?
Mon 3/14/11
Mon 3/14/11
1
Test Build 1
5 days
Mon 1/17/11
Fri 1/21/11
2
Test Build 2
5 days
Mon 2/7/11
Fri 2/11/11
3
Test Build 3
5 days
Mon 2/28/11
Fri 3/4/11
4
Test Build 4
5 days
Thu 3/17/11
Wed 3/23/11
5
System Test and Acceptance
15 days
Mon 3/28/11
Fri 4/15/11
5.1
Execute full ATP
3 days
Mon 3/28/11
Wed 3/30/11
5.2
Problem Resolution
8 days
Thu 3/31/11
Mon 4/11/11
5.3
Re-Test ATP
2 days
Tue 4/12/11
Wed 4/13/11
5.4
Burn-in test
2 days
Thu 4/14/11
Fri 4/15/11
6
Customer Action
5 days
Mon 4/18/11
Fri 4/22/11
6.1
Review Requirements
3 days
Mon 4/18/11
Wed 4/20/11
6.2
Review Design
2 days
Thu 4/21/11
Fri 4/22/11
7
Poster Board Presentation
3 days
Mon 4/18/11
Thurs 4/21/11
7.1
Review Requirements
3 days
Mon 4/18/11
Wed 4/20/11
7.2
Mock Design Day Presentation
1 day
Thurs 4/21/11
Thurs 4/21/11
7.3
Respond to Comments
1 day
Thurs 4/21/11
Thurs 4/21/11
7.4
Order/ Acquire Poster Board
3 days
Sat 4/30/11
Mon 5/01/11
8
Hardware Test
13 days
Mon 4/18/11
Mon 5/01/11
8.1
Execute full hardware ATP
2 days
Mon 4/18/11
Wed 4/19/11
8.2
Trouble shoot and Problem Resolution
6 days
Wed 4/20/11
Tues 4/26/11
8.3
Re-Test hardware ATP
3 days
Wed 4/27/11
Sat 4/30/11
8.4
Burn-in hardware test
2 days
Sat 4/30/11
Mon 5/01/11
8.5
Data collection from hardware test
1 day
Sat 4/30/11
Sat 4/30/11
9
Sensor Software Test
20 days
Tues 4/12/11
Mon 5/02/11
9.1
Execute full software ATP
4 days
Tues 4/12/11
Sat 4/16/11
[ 54 ]
9.2
Trouble Shoot and Problem Resolution
10 days
Sat 4/16/11
Tues 4/26/11
9.3
Re-Test ATP
3 days
Wed 4/27/11
Sat 4/30/11
9.4
Burn-in software test
3 days
Sat 4/30/11
Mon 5/02/11
10
GUI Software Test
12 days
Mon 4/18/11
Mon 4/30/11
10.1
Execute full hardware ATP
2 days
Mon 4/18/11
Wed 4/19/11
10.2
Trouble Shoot and Problem Resolution
6 days
Wed 4/20/11
Tues 4/26/11
10.3
Re-Test hardware ATP
3 days
Wed 4/27/11
Sat 4/30/11
10.4
Burn-in hardware test
2 days
Fri 4/29/11
Sat 4/30/11
11
Complete System Test and Acceptance
3 days
Sat 4/30/11
Mon 5/01/11
11.1
Execute full ATP
3 days
Sat 4/30/11
Mon 5/01/11
11.2
Problem Resolution
3 days
Sat 4/30/11
Mon 5/01/11
11.3
Re-Test ATP
3 days
Sat 4/30/11
Mon 5/01/11
11.4
Burn-in test
3 days
Sat 4/30/11
Mon 5/01/11
12
Senior Design Day
1 day
Tues 5/03/11
Tues 5/03/11
13
Final Project Report
1 day
Wed 5/4/11
Mon 5/4/11
13.4.2 Resource Allocation
This project, given its relatively straightforward nature, has most of the cost directed at
hardware that will be used in the building, testing, and implementation of the design. Even with
these costs though, there will still be an ample amount of money left in the budget, which is
demonstrated more precisely in the Bill of Materials. This extra money will be treated as a buffer
to ensure that if something goes wrong with the building and testing in the Spring, there will be
a pool of money to pull from to aid the group.
Time allocation is very important in the building and testing phases of this project as each of the
group members will need to be actively involved to ensure project success. A minimum of 10
hours per week in testing and building modes will be necessary from each member.
[ 55 ]
13.4.3 Major Deliverables
13.4.3a
Monday January 10th to Friday, January 14th 2011 – Build 1
This Build will focus on establishing communication between the receivers and
transmitters. More specifically, a successful build 1 will show that a specific channel can
be set for each transmitter/receiver pair. In the latter stages of this build, the group will
ensure that there is no cross-talk between neighboring channels or sensors that are near
each other.
13.4.3b
Monday January 31st to Friday February 4th 2011 – Build 2
This week of building will focus on the pulse oximeter sensor connection. This will
include fabrication of the plastic clip and pin contacts that will interface with the
existing sensor. With system software, the group will be developing code to format the
data received by the pulse oximeter so that it can be sent by the Bluetooth module and
received then decoded on the other end. The focus here is making sure that the received
signal is compatible with the TRAM module.
13.4.3c
Monday February 21st to Friday February 25th 2011 – Build 3
This week focuses on the receiver module and making sure that it interfaces correctly
with the TRAM module. If the interface is correct, then the week will be focused on
making sure that the received signal is of the correct format and of high enough quality.
13.4.3d
Monday March 14th to Friday March 16th 2011 – Build 4
This build is focused on full-system troubleshooting and extreme-case testing where the
group will test the limits of the product to make sure it can withstand real use.
[ 56 ]
13.5
Appendix E – Bluetooth and Zigbee Information
13.5.1 Bluetooth Specifications

Geared towards data applications

Data Rate: 3 Mbps (peak)

Range: Class II ~ 30ft

Able to penetrate solid objects

Connection Time: 3 s

Operating Frequency: 2.4GHz

Cost: ~$3.00/chip
13.5.2 Zigbee Specifications

Geared towards low power applications

Data Rate: 250 kbit/s

Range: 30ft-300ft

Connection Time: 30ms

Extremely low power consumption

Operating Frequency: 2.4GHz

Cost: ~$5/chip
[ 57 ]
13.6
Appendix F – MSP430 Development Kit
13.6.1 MSP430 Information (quoted from Texas Instruments):
The eZ430-RF2500 is a complete wireless development tool for the MSP430 and CC2500 that
includes all the hardware and software required to develop an entire wireless project with the
MSP430 in a convenient USB stick. The tool includes a USB-powered emulator to program and debug
your application in-system and two 2.4-GHz wireless target boards featuring the highly integrated
MSP430F2274 ultra-low-power MCU. Projects may be developed and instantly deployed using the
included battery expansion board and AAA batteries. All the required software is included such as a
complete Integrated Development Environment and SimpliciTI, a propriety low-power star network
stack, enabling robust wireless networks out of the box. The eZ430-RF2500 uses the MSP430F22x4
which combines 16-MIPS performance with a 200-ksps 10-bit ADC and 2 op-amps and is paired with
the CC2500 multi-channel RF transceiver designed for low-power wireless applications.
The eZ430-RF emulator interface may be used with any Spy Bi-Wire enabled MSP430, such as the
F22xx and F20xx series, and is fully compatible with the eZ430-F2013 and eZ430-T2012 target
boards. The emulator interface can be used to download and debug your target applications, and can
transmit serial data to your PC while in or out of a debug session.
Source: http://focus.ti.com/docs/toolsw/folders/print/ez430-rf2500.html
13.6.2 MSP430 Picture:
[ 58 ]
13.7
Appendix G – Charging Station
13.7.1 Information:
This charging station is equipped with a smart Charger that individually monitors cell condition and goes
to trickle charge when low rate charge to retain charge level that would otherwise be lost
due to self-discharge and storage. Illuminated LED monitoring light: green, red, and flashing red. Also a
built-in safety timer and temperature sensor with charge status indicator alerting when batteries are
ready.
13.7.2 Specifications:
Energizer CHVCWB2 Overnight NiMH AA/AAA Charger Kit
Charges two AA or AAA NiMH batteries overnight
Cardboard card for peg hook
Includes two AA, 1700mAh NiMH batteries
Length
9.00 inch / 22.86 cm
Width
4.00 inch / 10.16 cm
Height
4 inch / 10.16 cm
Color
Gray
Weight
1 lb / 0.45 Kg
[ 59 ]
13.7.3 Picture:
13.8
Appendix H – LabVIEW Code and Utility
13.8.1 Front Panel Display
[ 60 ]
13.8.2 Block Diagrams
Main Block Diagram
‘Temp_Volt_id’ SubVI (false is empty in case structure)
Temp_Calib SubVI
Fill_Calib Sub VI
[ 61 ]
[ 62 ]
13.9
Appendix I – SimpliCTI Code (Texas Instruments)
We started with a free ware program from TI as the base, and added many modifications to it to support our
needs.
13.9.1 Access Point Device
//******************************************************************************
// THIS PROGRAM IS PROVIDED "AS IS". TI MAKES NO WARRANTIES OR
// REPRESENTATIONS, EITHER EXPRESS, IMPLIED OR STATUTORY,
// INCLUDING ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS
// FOR A PARTICULAR PURPOSE, LACK OF VIRUSES, ACCURACY OR
// COMPLETENESS OF RESPONSES, RESULTS AND LACK OF NEGLIGENCE.
// TI DISCLAIMS ANY WARRANTY OF TITLE, QUIET ENJOYMENT, QUIET
// POSSESSION, AND NON-INFRINGEMENT OF ANY THIRD PARTY
// INTELLECTUAL PROPERTY RIGHTS WITH REGARD TO THE PROGRAM OR
// YOUR USE OF THE PROGRAM.
//
// IN NO EVENT SHALL TI BE LIABLE FOR ANY SPECIAL, INCIDENTAL,
// CONSEQUENTIAL OR INDIRECT DAMAGES, HOWEVER CAUSED, ON ANY
// THEORY OF LIABILITY AND WHETHER OR NOT TI HAS BEEN ADVISED
// OF THE POSSIBILITY OF SUCH DAMAGES, ARISING IN ANY WAY OUT
// OF THIS AGREEMENT, THE PROGRAM, OR YOUR USE OF THE PROGRAM.
// EXCLUDED DAMAGES INCLUDE, BUT ARE NOT LIMITED TO, COST OF
// REMOVAL OR REINSTALLATION, COMPUTER TIME, LABOR COSTS, LOSS
// OF GOODWILL, LOSS OF PROFITS, LOSS OF SAVINGS, OR LOSS OF
// USE OR INTERRUPTION OF BUSINESS. IN NO EVENT WILL TI'S
// AGGREGATE LIABILITY UNDER THIS AGREEMENT OR ARISING OUT OF
// YOUR USE OF THE PROGRAM EXCEED FIVE HUNDRED DOLLARS
// (U.S.$500).
//
// Unless otherwise stated, the Program written and copyrighted
// by Texas Instruments is distributed as "freeware". You may,
// only under TI's copyright in the Program, use and modify the
// Program without any charge or restriction. You may
// distribute to third parties, provided that you transfer a
// copy of this license to the third party and the third party
// agrees to these terms by its first use of the Program. You
// must reproduce the copyright notice and any other legend of
// ownership on each copy or partial copy, of the Program.
//
// You acknowledge and agree that the Program contains
// copyrighted material, trade secrets and other TI proprietary
// information and is protected by copyright laws,
// international copyright treaties, and trade secret laws, as
// well as other intellectual property laws. To protect TI's
// rights in the Program, you agree not to decompile, reverse
// engineer, disassemble or otherwise translate any object code
// versions of the Program to a human-readable form. You agree
// that in no event will you alter, remove or destroy any
// copyright notice included in the Program. TI reserves all
// rights not specifically granted under this license. Except
// as specifically provided herein, nothing in this agreement
// shall be construed as conferring by implication, estoppel,
// or otherwise, upon you, any license or other right under any
// TI patents, copyrights or trade secrets.
//
// You may not use the Program in non-TI devices.
//
//******************************************************************************
//
eZ430-RF2500 Temperature Sensor Access Point
//
[ 63 ]
//
Description: This is the Access Point software for the eZ430-2500RF
//
Temperature Sensing demo
//
//
//
L. Westlund
//
Version
1.03
//
Texas Instruments, Inc
//
August 2009
//
Built with IAR Embedded Workbench Version: 4.20
//******************************************************************************
//Change Log:
//******************************************************************************
//Version: 1.03
//Comments: Added support for SimpliciTI 1.1.0
//
Added support for Code Composer Studio
//
Added security (Enabled with -DSMPL_SECURE in smpl_nwk_config.dat)
//
Added acknowledgement (Enabled with -DAPP_AUTO_ACK in smpl_nwk_config.dat)
//
Based the modifications on the AP_as_Data_Hub example code
//Version: 1.02
//Comments: Changed Port toggling to abstract method
//
Removed ToggleLED
//
Fixed comment typos/errors
//
Changed startup string to 1.02
//Version: 1.01
//Comments: Added support for SimpliciTI 1.0.3
//
Changed RSSI read method
//
Added 3 digit temperature output for 100+F
//
Changed startup string to 1.01
//Version: 1.00
//Comments: Initial Release Version
//******************************************************************************
#include <string.h>
#include "bsp.h"
#include "mrfi.h"
#include "bsp_leds.h"
#include "bsp_buttons.h"
#include "nwk_types.h"
#include "nwk_api.h"
#include "nwk_frame.h"
#include "nwk.h"
#include "virtual_com_cmds.h"
//#include "app_remap_led.h"
#ifndef APP_AUTO_ACK
#error ERROR: Must define the macro APP_AUTO_ACK for this application.
#endif
void toggleLED(uint8_t);
/**************************** COMMENTS ON ASYNC LISTEN APPLICATION
***********************
Summary:
This AP build includes implementation of an unknown number of end device peers in
addition to AP functionality. In this scenario all End Devices establish a link to
the AP and only to the AP. The AP acts as a data hub. All End Device peers are on
the AP and not on other distinct ED platforms.
There is still a limit to the number of peers supported on the AP that is defined
by the macro NUM_CONNECTIONS. The AP will support NUM_CONNECTIONS or fewer peers
but the exact number does not need to be known at build time.
[ 64 ]
In this special but common scenario SimpliciTI restricts each End Device object to a
single connection to the AP. If multiple logical connections are required these must
be accommodated by supporting contexts in the application payload itself.
Solution overview:
When a new peer connection is required the AP main loop must be notified. In essence
the main loop polls a semaphore to know whether to begin listening for a peer Link
request from a new End Device. There are two solutions: automatic notification and
external notification. The only difference between the automatic notification
solution and the external notification solution is how the listen semaphore is
set. In the external notification solution the sempahore is set by the user when the
AP is stimulated for example by a button press or a commend over a serial link. In
the
automatic scheme the notification is accomplished as a side effect of a new End
Device
joining.
The Rx callback must be implemented. When the callback is invoked with a non-zero
Link ID the handler could set a semaphore that alerts the main work loop that a
SMPL_Receive() can be executed successfully on that Link ID.
If the callback conveys an argument (LinkID) of 0 then a new device has joined the
network. A SMPL_LinkListen() should be executed.
Whether the joining device supports ED objects is indirectly inferred on the joining
device from the setting of the NUM_CONNECTIONS macro. The value of this macro should
be non-zero only if ED objects exist on the device. This macro is always non-zero
for ED-only devices. But Range Extenders may or may not support ED objects. The macro
should be be set to 0 for REs that do not also support ED objects. This prevents the
Access Point from reserving resources for a joinng device that does not support any
End Device Objects and it prevents the AP from executing a SMPL_LinkListen(). The
Access Point will not ever see a Link frame if the joining device does not support
any connections.
Each joining device must execute a SMPL_Link() after receiving the join reply from
the
Access Point. The Access Point will be listening.
*************************** END COMMENTS ON ASYNC LISTEN APPLICATION
********************/
/************
************/
THIS SOURCE FILE REPRESENTS THE AUTOMATIC NOTIFICATION SOLUTION
/* reserve space for the maximum possible peer Link IDs */
static linkID_t sLID[NUM_CONNECTIONS] = {0};
static uint8_t sNumCurrentPeers = 0;
/* callback handler */
static uint8_t sCB(linkID_t);
/* received message handler */
static void processMessage(linkID_t, uint8_t *, uint8_t);
/* Frequency Agility helper functions */
static void
checkChangeChannel(void);
static void
changeChannel(void);
/* work loop semaphores
static volatile uint8_t
static volatile uint8_t
static volatile uint8_t
*/
sPeerFrameSem = 0;
sJoinSem = 0;
sSelfMeasureSem = 0;
[ 65 ]
#ifdef FREQUENCY_AGILITY
/*
************** BEGIN interference detection support */
#define INTERFERNCE_THRESHOLD_DBM (-70)
#define SSIZE
25
#define IN_A_ROW 3
static int8_t sSample[SSIZE];
static uint8_t sChannel = 0;
#endif /* FREQUENCY_AGILITY */
/* blink LEDs when channel changes... */
static volatile uint8_t sBlinky = 0;
//data for terminal output
const char splash[] = {"\r\n--------------------------------------------------\r\n
****\r\n
****
eZ430-RF2500\r\n
******o****
Temperature Sensor
Network\r\n********_///_****
Copyright 2009\r\n ******/_//_/***** Texas Instruments
Incorporated\r\n ** ***(__/*****
All rights reserved.\r\n
*********
SimpliciTI1.1.0\r\n
*****\r\n
***\r\n-------------------------------------------------\r\n"};
volatile int * tempOffset = (int *)0x10F4;
__interrupt void ADC10_ISR(void);
__interrupt void Timer_A (void);
/*
************** END interference detection support
#define SPIN_ABOUT_A_QUARTER_SECOND
*/
NWK_DELAY(250)
void main (void)
{
bspIState_t intState;
memset(sSample, 0x0, sizeof(sSample));
BSP_Init();
BCSCTL3 |= LFXT1S_2;
TACCTL0 = CCIE;
TACCR0 = 12000;
TACTL = TASSEL_1 + MC_1;
//
//
//
//
LFXT1 = VLO
TACCR0 interrupt enabled
~1 second
ACLK, upmode
COM_Init();
//Transmit splash screen and network init notification
TXString( (char*)splash, sizeof splash);
TXString( "\r\nInitializing Network....", 26 );
SMPL_Init(sCB);
// network initialized
TXString( "Done\r\n", 6);
/* green and red LEDs on solid to indicate waiting for a Join. */
if (!BSP_LED2_IS_ON())
{
toggleLED(2);
}
if (!BSP_LED1_IS_ON())
{
toggleLED(1);
}
[ 66 ]
/* main work loop */
while (1)
{
/* Wait for the Join semaphore to be set by the receipt of a Join frame from a
* device that supports an End Device.
*
* An external method could be used as well. A button press could be connected
* to an ISR and the ISR could set a semaphore that is checked by a function
* call here, or a command shell running in support of a serial connection
* could set a semaphore that is checked by a function call.
*/
if (sJoinSem && (sNumCurrentPeers < NUM_CONNECTIONS))
{
/* listen for a new connection */
while (1)
{
if (SMPL_SUCCESS == SMPL_LinkListen(&sLID[sNumCurrentPeers]))
{
break;
}
/* Implement fail-to-link policy here. otherwise, listen again. */
}
sNumCurrentPeers++;
BSP_ENTER_CRITICAL_SECTION(intState);
sJoinSem--;
BSP_EXIT_CRITICAL_SECTION(intState);
}
// if it is time to measure our own temperature...
if(sSelfMeasureSem)
{
char msg [6];
char addr[] = {"HUB0"};
char rssi[] = {"000"};
int degC, volt;
volatile long temp;
int results[2];
ADC10CTL1 = INCH_10 + ADC10DIV_4;
// Temp Sensor ADC10CLK/5
ADC10CTL0 = SREF_1 + ADC10SHT_3 + REFON + ADC10ON + ADC10IE + ADC10SR;
for( degC = 240; degC > 0; degC-- ); // delay to allow reference to settle
ADC10CTL0 |= ENC + ADC10SC;
// Sampling and conversion start
__bis_SR_register(CPUOFF + GIE);
// LPM0 with interrupts enabled
results[0] = ADC10MEM;
ADC10CTL0 &= ~ENC;
ADC10CTL1 = INCH_11;
// AVcc/2
ADC10CTL0 = SREF_1 + ADC10SHT_2 + REFON + ADC10ON + ADC10IE + REF2_5V;
for( degC = 240; degC > 0; degC-- ); // delay to allow reference to settle
ADC10CTL0 |= ENC + ADC10SC;
// Sampling and conversion start
__bis_SR_register(CPUOFF + GIE);
// LPM0 with interrupts enabled
results[1] = ADC10MEM;
ADC10CTL0 &= ~ENC;
ADC10CTL0 &= ~(REFON + ADC10ON);
// turn off A/D to save power
// oC = ((A10/1024)*1500mV)-986mV)*1/3.55mV = A10*423/1024 - 278
// the temperature is transmitted as an integer where 32.1 = 321
[ 67 ]
// hence 4230 instead of 423
temp = results[0];
degC = (((temp - 673) * 4230) / 1024);
if( (*tempOffset) != 0xFFFF )
{
degC += (*tempOffset);
}
temp = results[1];
volt = (temp*25)/512;
msg[0] = degC&0xFF;
msg[1] = (degC>>8)&0xFF;
msg[2] = volt;
transmitDataString(1, addr, rssi, msg );
BSP_TOGGLE_LED1();
sSelfMeasureSem = 0;
}
/* Have we received a frame on one of the ED connections?
* No critical section -- it doesn't really matter much if we miss a poll
*/
if (sPeerFrameSem)
{
uint8_t
msg[MAX_APP_PAYLOAD], len, i;
/* process all frames waiting */
for (i=0; i<sNumCurrentPeers; ++i)
{
if (SMPL_SUCCESS == SMPL_Receive(sLID[i], msg, &len))
{
ioctlRadioSiginfo_t sigInfo;
processMessage(sLID[i], msg, len);
sigInfo.lid = sLID[i];
SMPL_Ioctl(IOCTL_OBJ_RADIO, IOCTL_ACT_RADIO_SIGINFO, (void *)&sigInfo);
transmitData( i, sigInfo.sigInfo.rssi, (char*)msg );
BSP_TOGGLE_LED2();
BSP_ENTER_CRITICAL_SECTION(intState);
sPeerFrameSem--;
BSP_EXIT_CRITICAL_SECTION(intState);
}
}
}
if (BSP_BUTTON1())
{
SPIN_ABOUT_A_QUARTER_SECOND; /* debounce */
changeChannel();
}
else
{
checkChangeChannel();
}
BSP_ENTER_CRITICAL_SECTION(intState);
if (sBlinky)
{
if (++sBlinky >= 0xF)
{
[ 68 ]
sBlinky = 1;
toggleLED(1);
toggleLED(2);
}
}
BSP_EXIT_CRITICAL_SECTION(intState);
}
}
void toggleLED(uint8_t which)
{
if (1 == which)
{
BSP_TOGGLE_LED1();
}
else if (2 == which)
{
BSP_TOGGLE_LED2();
}
return;
}
/* Runs in ISR context. Reading the frame should be done in the */
/* application thread not in the ISR thread. */
static uint8_t sCB(linkID_t lid)
{
if (lid)
{
sPeerFrameSem++;
sBlinky = 0;
}
else
{
sJoinSem++;
}
/* leave frame to be read by application. */
return 0;
}
static void processMessage(linkID_t lid, uint8_t *msg, uint8_t len)
{
/* do something useful */
if (len)
{
toggleLED(*msg);
}
return;
}
static void changeChannel(void)
{
#ifdef FREQUENCY_AGILITY
freqEntry_t freq;
if (++sChannel >= NWK_FREQ_TBL_SIZE)
{
sChannel = 0;
}
freq.logicalChan = sChannel;
[ 69 ]
SMPL_Ioctl(IOCTL_OBJ_FREQ, IOCTL_ACT_SET, &freq);
BSP_TURN_OFF_LED1();
BSP_TURN_OFF_LED2();
sBlinky = 1;
#endif
return;
}
/* implement auto-channel-change policy here... */
static void checkChangeChannel(void)
{
#ifdef FREQUENCY_AGILITY
int8_t dbm, inARow = 0;
uint8_t i;
memset(sSample, 0x0, SSIZE);
for (i=0; i<SSIZE; ++i)
{
/* quit if we need to service an app frame */
if (sPeerFrameSem || sJoinSem)
{
return;
}
NWK_DELAY(1);
SMPL_Ioctl(IOCTL_OBJ_RADIO, IOCTL_ACT_RADIO_RSSI, (void *)&dbm);
sSample[i] = dbm;
if (dbm > INTERFERNCE_THRESHOLD_DBM)
{
if (++inARow == IN_A_ROW)
{
changeChannel();
break;
}
}
else
{
inARow = 0;
}
}
#endif
return;
}
/*-----------------------------------------------------------------------------* ADC10 interrupt service routine
------------------------------------------------------------------------------*/
#pragma vector=ADC10_VECTOR
__interrupt void ADC10_ISR(void)
{
__bic_SR_register_on_exit(CPUOFF);
// Clear CPUOFF bit from 0(SR)
}
/*-----------------------------------------------------------------------------* Timer A0 interrupt service routine
------------------------------------------------------------------------------*/
#pragma vector=TIMERA0_VECTOR
__interrupt void Timer_A (void)
{
sSelfMeasureSem = 1;
}
[ 70 ]
13.9.2 End Point Device
//******************************************************************************
// THIS PROGRAM IS PROVIDED "AS IS". TI MAKES NO WARRANTIES OR
// REPRESENTATIONS, EITHER EXPRESS, IMPLIED OR STATUTORY,
// INCLUDING ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS
// FOR A PARTICULAR PURPOSE, LACK OF VIRUSES, ACCURACY OR
// COMPLETENESS OF RESPONSES, RESULTS AND LACK OF NEGLIGENCE.
// TI DISCLAIMS ANY WARRANTY OF TITLE, QUIET ENJOYMENT, QUIET
// POSSESSION, AND NON-INFRINGEMENT OF ANY THIRD PARTY
// INTELLECTUAL PROPERTY RIGHTS WITH REGARD TO THE PROGRAM OR
// YOUR USE OF THE PROGRAM.
//
// IN NO EVENT SHALL TI BE LIABLE FOR ANY SPECIAL, INCIDENTAL,
// CONSEQUENTIAL OR INDIRECT DAMAGES, HOWEVER CAUSED, ON ANY
// THEORY OF LIABILITY AND WHETHER OR NOT TI HAS BEEN ADVISED
// OF THE POSSIBILITY OF SUCH DAMAGES, ARISING IN ANY WAY OUT
// OF THIS AGREEMENT, THE PROGRAM, OR YOUR USE OF THE PROGRAM.
// EXCLUDED DAMAGES INCLUDE, BUT ARE NOT LIMITED TO, COST OF
// REMOVAL OR REINSTALLATION, COMPUTER TIME, LABOR COSTS, LOSS
// OF GOODWILL, LOSS OF PROFITS, LOSS OF SAVINGS, OR LOSS OF
// USE OR INTERRUPTION OF BUSINESS. IN NO EVENT WILL TI'S
// AGGREGATE LIABILITY UNDER THIS AGREEMENT OR ARISING OUT OF
// YOUR USE OF THE PROGRAM EXCEED FIVE HUNDRED DOLLARS
// (U.S.$500).
//
// Unless otherwise stated, the Program written and copyrighted
// by Texas Instruments is distributed as "freeware". You may,
// only under TI's copyright in the Program, use and modify the
// Program without any charge or restriction. You may
// distribute to third parties, provided that you transfer a
// copy of this license to the third party and the third party
// agrees to these terms by its first use of the Program. You
// must reproduce the copyright notice and any other legend of
// ownership on each copy or partial copy, of the Program.
//
// You acknowledge and agree that the Program contains
// copyrighted material, trade secrets and other TI proprietary
// information and is protected by copyright laws,
// international copyright treaties, and trade secret laws, as
// well as other intellectual property laws. To protect TI's
// rights in the Program, you agree not to decompile, reverse
// engineer, disassemble or otherwise translate any object code
// versions of the Program to a human-readable form. You agree
// that in no event will you alter, remove or destroy any
// copyright notice included in the Program. TI reserves all
// rights not specifically granted under this license. Except
// as specifically provided herein, nothing in this agreement
// shall be construed as conferring by implication, estoppel,
// or otherwise, upon you, any license or other right under any
// TI patents, copyrights or trade secrets.
//
// You may not use the Program in non-TI devices.
//
//******************************************************************************
//
eZ430-RF2500 Temperature Sensor End Device
//
//
Description: This is the End Device software for the eZ430-2500RF
//
Temperature Sensing demo
//
[ 71 ]
//
//
L. Westlund
//
Version
1.02
//
Texas Instruments, Inc
//
November 2007
//
Built with IAR Embedded Workbench Version: 4.09A
//******************************************************************************
//Change Log:
//******************************************************************************
//Version: 1.03
//Comments: Added support for SimpliciTI 1.1.0
//
Added support for Code Composer Studio
//
Added security (Enabled with -DSMPL_SECURE in smpl_nwk_config.dat)
//
Added acknowledgement (Enabled with -DAPP_AUTO_ACK in smpl_nwk_config.dat)
//
Based the modifications on the AP_as_Data_Hub example code
//Version: 1.02
//Comments: Changed Port toggling to abstract method
//
Fixed comment typos
//Version: 1.01
//Comments: Added support for SimpliciTI 1.0.3
//
Added Flash storage/check of Random address
//
Moved LED toggle to HAL
//Version: 1.00
//Comments: Initial Release Version
//******************************************************************************
#define I_WANT_TO_CHANGE_DEFAULT_ROM_DEVICE_ADDRESS_PSEUDO_CODE
#include "bsp.h"
#include "mrfi.h"
#include "nwk_types.h"
#include "nwk_api.h"
#include "bsp_leds.h"
#include "bsp_buttons.h"
#include "vlo_rand.h"
#ifndef APP_AUTO_ACK
#error ERROR: Must define the macro APP_AUTO_ACK for this application.
#endif
void toggleLED(uint8_t);
static void linkTo(void);
static linkID_t sLinkID1 = 0;
#define SPIN_ABOUT_A_SECOND
NWK_DELAY(1000)
#define SPIN_ABOUT_A_QUARTER_SECOND
NWK_DELAY(250)
/* How many times to try a Tx and miss an acknowledge before doing a scan */
#define MISSES_IN_A_ROW 2
void createRandomAddress(void);
volatile int * tempOffset = (int *)0x10F4; // Temperature offset set at production
char * Flash_Addr = (char *)0x10F0;
// Initialize radio address location
__interrupt void ADC10_ISR(void);
__interrupt void Timer_A (void);
/* work loop semaphores */
static volatile uint8_t sSelfMeasureSem = 0;
void main (void)
[ 72 ]
{
addr_t lAddr;
BSP_Init();
if(Flash_Addr[0] == 0xFF && Flash_Addr[1] == 0xFF &&
Flash_Addr[2] == 0xFF && Flash_Addr[3] == 0xFF )
{
createRandomAddress(); // set Random device address at initial startup
}
lAddr.addr[0] = Flash_Addr[0];
lAddr.addr[1] = Flash_Addr[1];
lAddr.addr[2] = Flash_Addr[2];
lAddr.addr[3] = Flash_Addr[3];
SMPL_Ioctl(IOCTL_OBJ_ADDR, IOCTL_ACT_SET, &lAddr);
/* Keep trying to join (a side effect of successful initialization) until
* successful. Toggle LEDS to indicate that joining has not occurred.
*/
while (SMPL_SUCCESS != SMPL_Init(0))
{
toggleLED(1);
toggleLED(2);
SPIN_ABOUT_A_SECOND;
}
/* LEDs on solid to indicate successful join. */
if (!BSP_LED2_IS_ON())
{
toggleLED(2);
}
if (!BSP_LED1_IS_ON())
{
toggleLED(1);
}
BCSCTL3 |= LFXT1S_2;
TACCTL0 = CCIE;
TACCR0 = 12000;
TACTL = TASSEL_1 + MC_1;
//
//
//
//
LFXT1 = VLO
TACCR0 interrupt enabled
~ 1 sec
ACLK, upmode
/* Unconditional link to AP which is listening due to successful join. */
linkTo();
while (1) ;
}
static void linkTo()
{
uint8_t
msg[3];
uint8_t
misses, done;
/* Keep trying to link... */
while (SMPL_SUCCESS != SMPL_Link(&sLinkID1))
{
toggleLED(1);
toggleLED(2);
SPIN_ABOUT_A_SECOND;
}
/* Turn off LEDs. */
if (BSP_LED2_IS_ON())
[ 73 ]
{
toggleLED(2);
}
if (BSP_LED1_IS_ON())
{
toggleLED(1);
}
SMPL_Ioctl( IOCTL_OBJ_RADIO, IOCTL_ACT_RADIO_SLEEP, 0);
while (1)
{
__bis_SR_register(LPM3_bits+GIE);
// LPM3 with interrupts enabled
if (sSelfMeasureSem) {
volatile long temp;
int degC, volt;
int results[2];
uint8_t
noAck;
smplStatus_t rc;
/* get radio ready...awakens in idle state */
SMPL_Ioctl( IOCTL_OBJ_RADIO, IOCTL_ACT_RADIO_AWAKE, 0);
ADC10CTL1 = INCH_0 + ADC10DIV_4;
// Temp Sensor ADC10CLK/5
ADC10AE0 = 1;
ADC10CTL0 = SREF_1 + ADC10SHT_3 + REFON + ADC10ON + ADC10IE + ADC10SR;
for( degC = 240; degC > 0; degC-- );
// delay to allow reference to settle
ADC10CTL0 |= ENC + ADC10SC;
// Sampling and conversion start
__bis_SR_register(CPUOFF + GIE);
// LPM0 with interrupts enabled
results[0] = ADC10MEM;
ADC10CTL0 &= ~ENC;
ADC10CTL1 = INCH_11;
// AVcc/2
ADC10CTL0 = SREF_1 + ADC10SHT_2 + REFON + ADC10ON + ADC10IE + REF2_5V;
for( degC = 240; degC > 0; degC-- );
// delay to allow reference to settle
ADC10CTL0 |= ENC + ADC10SC;
// Sampling and conversion start
__bis_SR_register(CPUOFF + GIE);
// LPM0 with interrupts enabled
results[1] = ADC10MEM;
ADC10CTL0 &= ~ENC;
ADC10CTL0 &= ~(REFON + ADC10ON);
// turn off A/D to save power
// oC = ((A10/1024)*1500mV)-986mV)*1/3.55mV = A10*423/1024 - 278
// the temperature is transmitted as an integer where 32.1 = 321
// hence 4230 instead of 423
temp = results[0];
degC = ((temp - 673) * 4230) / 1024;
if( (*tempOffset) != 0xFFFF )
{
degC += (*tempOffset);
}
/* message format, UB = upper Byte, LB = lower Byte
------------------------------|degC LB | degC UB | volt LB |
------------------------------0
1
2
*/
temp = results[1];
volt = (temp*25)/512;
[ 74 ]
msg[0] = degC&0xFF;
msg[1] = (degC>>8)&0xFF;
msg[2] = volt;
done = 0;
while (!done)
{
noAck = 0;
/* Try sending message MISSES_IN_A_ROW times looking for ack */
for (misses=0; misses < MISSES_IN_A_ROW; ++misses)
{
if (SMPL_SUCCESS == (rc=SMPL_SendOpt(sLinkID1, msg, sizeof(msg),
SMPL_TXOPTION_ACKREQ)))
{
/* Message acked. We're done. Toggle LED 1 to indicate ack received. */
toggleLED(1); // Toggle On LED1
__delay_cycles(2000);
toggleLED(1);
break;
}
if (SMPL_NO_ACK == rc)
{
/* Count ack failures. Could also fail becuase of CCA and
* we don't want to scan in this case.
*/
noAck++;
}
}
if (MISSES_IN_A_ROW == noAck)
{
/* Message not acked. Toggle LED 2. */
toggleLED(2); // Turn On LED2
__delay_cycles(2000);
toggleLED(2);
#ifdef FREQUENCY_AGILITY
/* Assume we're on the wrong channel so look for channel by
* using the Ping to initiate a scan when it gets no reply. With
* a successful ping try sending the message again. Otherwise,
* for any error we get we will wait until the next button
* press to try again.
*/
if (SMPL_SUCCESS != SMPL_Ping(sLinkID1))
{
done = 1;
}
#else
done = 1;
#endif /* FREQUENCY_AGILITY */
}
else
{
/* Got the ack or we don't care. We're done. */
done = 1;
}
}
/* radio back to sleep */
SMPL_Ioctl( IOCTL_OBJ_RADIO, IOCTL_ACT_RADIO_SLEEP, 0);
}
}
}
[ 75 ]
void toggleLED(uint8_t which)
{
if (1 == which)
{
BSP_TOGGLE_LED1();
}
else if (2 == which)
{
BSP_TOGGLE_LED2();
}
return;
}
void createRandomAddress()
{
unsigned int rand, rand2;
do
{
rand = TI_getRandomIntegerFromVLO();
// first byte can not be 0x00 of 0xFF
}
while( (rand & 0xFF00)==0xFF00 || (rand & 0xFF00)==0x0000 );
rand2 = TI_getRandomIntegerFromVLO();
BCSCTL1 = CALBC1_1MHZ;
DCOCTL = CALDCO_1MHZ;
FCTL2 = FWKEY + FSSEL0 + FN1;
FCTL3 = FWKEY + LOCKA;
FCTL1 = FWKEY + WRT;
// Set DCO to 1MHz
// MCLK/3 for Flash Timing Generator
// Clear LOCK & LOCKA bits
// Set WRT bit for write operation
Flash_Addr[0]=(rand>>8) & 0xFF;
Flash_Addr[1]=rand & 0xFF;
Flash_Addr[2]=(rand2>>8) & 0xFF;
Flash_Addr[3]=rand2 & 0xFF;
FCTL1 = FWKEY;
FCTL3 = FWKEY + LOCKA + LOCK;
// Clear WRT bit
// Set LOCK & LOCKA bit
}
/*-----------------------------------------------------------------------------* ADC10 interrupt service routine
------------------------------------------------------------------------------*/
#pragma vector=ADC10_VECTOR
__interrupt void ADC10_ISR(void)
{
__bic_SR_register_on_exit(CPUOFF);
// Clear CPUOFF bit from 0(SR)
}
/*-----------------------------------------------------------------------------* Timer A0 interrupt service routine
------------------------------------------------------------------------------*/
#pragma vector=TIMERA0_VECTOR
__interrupt void Timer_A (void)
{
sSelfMeasureSem = 1;
__bic_SR_register_on_exit(LPM3_bits);
// Clear LPM3 bit from 0(SR)
}
[ 76 ]
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement