TABLE OF CONTENTS
LIST OF FIGURES .................................................................................................................................... III
LIST OF TABLES ...................................................................................................................................... IV
LIST OF DEFINITIONS ............................................................................................................................. V
INTRODUCTION ........................................................................................................................................ 1
EXECUTIVE SUMMARY ............................................................................................................................... 1
ACKNOWLEDGEMENT ................................................................................................................................. 2
PROBLEM STATEMENT................................................................................................................................ 2
OPERATING ENVIRONMENT ........................................................................................................................ 2
INTENDED USER(S) AND INTENDED USE(S) ................................................................................................ 3
ASSUMPTIONS AND LIMITATIONS ............................................................................................................... 3
Assumptions .......................................................................................................................................... 3
Limitations ............................................................................................................................................ 4
EXPECTED END PRODUCT AND OTHER DELIVERABLES .............................................................................. 4
APPROACH AND RESULTS ..................................................................................................................... 5
FUNCTIONAL REQUIREMENTS ..................................................................................................................... 5
DESIGN REQUIREMENTS AND CONSTRAINTS ............................................................................................... 5
APPROACHES CONSIDERED ......................................................................................................................... 6
DETAILED DESIGN ...................................................................................................................................... 7
Process Walkthrough: ........................................................................................................................... 7
The Detector: ........................................................................................................................................ 8
Data Acquisition: .................................................................................................................................10
IMPLEMENTATION PROCESS .......................................................................................................................13
END-PRODUCT TESTING .............................................................................................................................14
PROJECT END RESULTS ..............................................................................................................................15
RESOURCES AND SCHEDULES ............................................................................................................16
RESOURCE REQUIREMENTS........................................................................................................................16
SCHEDULES ...............................................................................................................................................18
CLOSURE MATERIALS ...........................................................................................................................20
PROJECT EVALUATION ...............................................................................................................................20
COMMERCIALIZATION ...............................................................................................................................21
Cost of Production ...............................................................................................................................21
Selling Price .........................................................................................................................................21
Potential Market: .................................................................................................................................21
RECOMMENDATIONS FOR ADDITIONAL WORK ..........................................................................................22
LESSONS LEARNED ....................................................................................................................................22
What went well .....................................................................................................................................22
What didn’t go well ..............................................................................................................................22
Technical Knowledge Gained ..............................................................................................................23
Non-technical Knowledge Gained .......................................................................................................23
What to do differently...........................................................................................................................24
RISK AND RISK MANAGEMENT ..................................................................................................................24
Anticipated Potential Risks ..................................................................................................................24
Anticipated Risks Encountered ............................................................................................................24
Unanticipated Risks Encountered ........................................................................................................25
Resultant Changes in Risk Management ..............................................................................................25
PROJECT TEAM INFORMATION ...................................................................................................................26
Client: ..................................................................................................................................................26
Faculty Advisor:...................................................................................................................................26
-i-
Team Members: ...................................................................................................................................26
Closing Summary: ................................................................................................................................27
- ii -
LIST OF FIGURES
Figure 1. System Schematic ............................................................................................... 7
Figure 2. Process Hierarchy ................................................................................................ 8
Figure 3. The Configurator ................................................................................................ 9
Figure 4. Acquisition Hierarchy ....................................................................................... 10
Figure 5. Acquisition Module .......................................................................................... 11
Figure 6. Setup Module.................................................................................................... 12
Figure 7. Graphing Module.............................................................................................. 12
Figure 8. Example of Output ........................................................................................... 13
Figure 9. Original Schedule ............................................................................................. 18
Figure 10. Revised Schedule............................................................................................ 18
Figure 11. Actual Schedule .............................................................................................. 19
- iii -
LIST OF TABLES
Table 1. Parts List ............................................................................................................... 7
Table 2. Estimated and Actual Cost ................................................................................. 17
Table 3. Final Project Cost with Labor ............................................................................. 17
- iv -
LIST OF DEFINITIONS
PDA:
Mobile DAQ:
LabVIEW:
Bluetooth:
EKG sensor:
VI:
NI:
FDS:
Personal digital assistant, a lightweight consumer electronic device
that looks like a hand-held computer but instead performs specific
tasks; can serve as a diary or a personal database or a telephone or
an alarm clock etc
The Mobile Data Acquisition is designed exclusively for
computers and PDAs that support Bluetooth wireless
communication.
Laboratory Virtual Instrument Engineering Workbench
(graphically programmed computer language for real-time
instrumentation LabVIEW is the host application development
environment for MobileDAQ applications.
A specification for short-range radio links between mobile
computers, mobile phones, digital cameras, and other portable
devices.
Electrocardiogram or ECG sensor, measures cardiac electrical
potential waveforms (voltages produced during the contraction of
the heart).
Virtual Instrument
National Instruments.
Full development suite
-v-
INTRODUCTION
Executive Summary
Purpose
The purpose of this project is to develop a mobile solution for acquiring EKG data.
Current EKG technology is quite large and very expensive. Often times schools would
like to use EKG machines for educational purposes; however money and space available
can pose problems for allowing this to happen. A mobile solution would allow EKG data
acquisition to occur in many new situations, such as in a classroom or at a swimming
pool. The smaller cost of the solution would also make the device more available for the
public to purchase and own, and also the very compact size of the completed system is
very appealing when compared to the bulky EKG machines currently being used.
Project Activities
The project is divided into two phases—a research phase and a development phase.
During the research phase, the team spent much of the time studying LabVIEW and
working with the various hardware components. Research time was put into studying
how EKG graphs worked and what data needed to be displayed. The team also needed to
learn about the EKG sensors themselves as it was essential to find out what type of data
these sensors would be physically measuring.
In the development phase, the group successfully integrated the hardware and tested the
Bluetooth connection. Then work began on the development of the necessary LabVIEW
VI’s. National Instruments was kind enough to provide the team with several module
examples for data acquisition, Bluetooth detection, and Bluetooth connection; so several
weeks were spent studying these examples, running the modules through tests, and
verifying how different components worked together. Work then began on the VIs which
would be needed to successfully graph the EKG data, and eventually these VIs were
combined and tested.
Final Results
Currently, our project is very near completion. All of the necessary VI’s have been
created to take EKG data and display it on the PDA in either a continuous flow or as a set
period of time. The testing of these functions has been successfully tested. The only
work remaining is to put a few finishing touches on the VI’s in order to make them more
user friendly and to write the manual for the users of this system.
-1-
Acknowledgement
Thank you to National Instruments for supplying the Mobile DAQ, electronic copies of
the Mobile DAQ manual, two Bluetooth enabled PDA’s, and the software that is
necessary to design the module.
Thank you to Vernier for supplying the EKG sensor and information on how it functions.
Problem Statement
The current problem that this project is trying to solve has to do with current EKG
technology. In today’s hospitals, the machines used to monitor heart activity are large
and bulky. They must be pushed around from room to room on wheels, or the patients
must be brought to them. These machines are also highly expensive, which makes them
unavailable for classroom and other purposes.
The solution to this problem lies in the use of the NI MobileDAQ, the Vernier EKG
sensor, and a Bluetooth enabled PDA. This project has successfully combined these
three elements into a system that is capable of taking EKG measurements. While this
system is not currently capable of replacing current technology in all cases, it does
provide an alternative for those people who would like access to EKG measurement
technology but don’t have the budget. It is also extremely portable and very easy to carry
and quickly set up.
Operating Environment
The risks in the expected environment for this module are relatively few. If used in an
ambulance, a risk would be that it would probably be dropped or vigorously shaken
around. However, if used in a nursing home or a classroom, it is unlikely that any
seriously damaging situations would occur on a regular basis.
-2-
Intended User(s) and Intended Use(s)
This module has several different applications and could be used by many people. Some
possible users are paramedics, lifeguards, or even teachers. It should be able to be used
by high school students or any adult with a high school education. A user will need to
have some knowledge of how to use a computer and operate a PDA.
This module will be used in a variety of situations. Its main application will be in
situations where it is useful to monitor heart activity, but the bulky machines used in
hospitals are not available. This could include use in an ambulance or at a nursing home.
The MobileDAQs could be used to monitor many patients on a single machine to allow
operators to respond more quickly when there is an emergency. The device is not
accurate enough to be relied on in real medical diagnoses. Current EKG systems use 12
different sensors throughout the body, while this module only uses 3. Another possible
use of this device is in the classroom. A teacher could use the system to teach students
about EKG and different heart activities.
Assumptions and Limitations
There are many assumptions and limitations the product needs to adhere in order to
operate safely and correctly. These assumptions and limitations are presented to the best
of the team’s knowledge, when other limitations and assumptions are needed it will be
updated in a timely manner.
Assumptions
The list below is not all inclusive; it states the necessary conditions that ensure proper
working conditions for the Mobile EKG sensor. New found assumptions will be added in
a timely manner.
 The MobileDAQ is able to interpret information from the EKG sensor.
 The PDA and MobileDAQ are both able to communicate through Bluetooth.
 The PDA has the necessary LabVIEW libraries to run the VI.
 The PDA interface will be clear and easy to use.
 All necessary EKG data will be displayed in the PDA interface.
 The manual will explain the proper use of the sensor and the PDA interface.
 The Mobile DAQ is powered by two AA batteries.
 The user will supply storage devices such as memory card or hard drives for data
collection.
 Assume the default memory for PocketPC 2003 PDA is 32MB – Applications.
 Assume the default memory for PalmOS PDA to be 30MB – Applications.
-3-
Limitations
The list below is not all inclusive; it states the physical limitations of the Mobile EKG
sensor. New found limitations will be added in a timely manner.
 The MobileDAQ must stay within Bluetooth range of the PDA (about 10 meters).
 Device is not to be use for serious medical situations.
 PDA’s have limited battery life before they need recharging.
 Bluetooth’s maximum data rate is 750 kbps.
 MobileDAQ’s analog-to-digital converter has a 16 bit resolution.
 The MobileDAQ has a maximum continuous sampling rate of 5 kHz.
 The MobileDAQ’s maximum working voltage is +/- 42 V.
 User must be able to run LabVIEW modules on their PDA.
 Devices cannot operate underwater.
 Devices cannot operate outside of the temperature range 0˚ to 50˚ C.
 Devices cannot operate above altitude of 2000 meters.
 Length of testing will be restricted to the available memory of the collection
device.
 This device is not accurate enough to be used for real medical diagnoses.
Expected End Product and Other Deliverables
The final product that will be presented to NI will include the LabVIEW module as well
as the EKG sensor and Mobile DAQ. Also included will be an in-depth manual on how
to use the sensor and the LabVIEW module.
-4-
APPROACH AND RESULTS
The following section entails the approach of building the Mobile EKG sensor using the
National Instrument MobileDAQ and the Vernier’s EKG sensor. It also states the
necessary steps that were taken to perform a task.
Functional requirements
1. Display Data:
The data taken by the EKG sensor should have the capabilities of being
displayed graphically on either a Bluetooth enabled PDA or a Bluetooth
enabled laptop.
2. Portable:
The collective end product including the EKG sensor, MobileDAQ, PDA, and
laptop should all be portable and functional in any location.
3. Accurate:
The end product should be able to take data which is accurate when measuring
someone’s heart rate.
4. Communicate Wirelessly:
The MobileDAQ should be able to communicate wirelessly (through
Bluetooth) with the Bluetooth enable PDA or laptop.
Design requirements and constraints
1. Distance:
A Bluetooth equipped device can only communicate wirelessly with another
Bluetooth equipped device if the 2 devices are within a certain range of each
other. The end product demonstration maximum range between the
MobileDAQ and the PDA is 10 metters.
2. Connection to Host:
The EKG sensor will not take any data if not connected to a host (something
with a heart beat).
3. Operating Conditions:
The MobileDAQ setup can only be used in certain physical conditions, see the
list of limitations in the above section for a general description of the
operating conditions.
4. Detect Multiple MobileDAQs:
The PDA should be able to detect all MobileDAQs operating within Bluetooth
range of the palm pilot. User should be allowed to choose which MobileDAQ
they would like to connect to.
-5-
Approaches considered
The section below discusses the available approaches and which methods were chosen.
1. LabVIEW vs. C++ or Visual BASIC:
Just about any code languages could have been used to program the modules
into the PDA. LabVIEW, C++, and Visual BASIC are just a few. C++ and
Visual BASIC require lines of code to be written out, and would result in
many pages of advanced code. LabVIEW uses graphically interfaced building
blocks to write programs, making it much easier to create the necessary
modules for the PDA to interact with the MobileDAQ. LabVIEW was also
provided to the team by National Instruments along with some sample coding
to be used along the way. The team’s choice was to use LabVIEW.
2. PDA vs. Laptop:
The MobileDAQ can connect wirelessly to either a Bluetooth enabled PDA or
a Bluetooth enable laptop. The team found that a Bluetooth enabled laptop
would be very expensive to purchase, and that National Instruments was
willing to provide two Bluetooth enable PDAs for the purpose of the project.
Because the PDA was determined to have no limiting capabilities over a
laptop, the team chose to use the PDA.
-6-
Detailed design
Figure 1. System Schematic
Please refer to the general system schematic above for guidance regarding the data
collection progress. While the main design lies within the LabVIEW module, it is often
helpful to see the source and data channels of the system to fully understand the module
design. The process is as follow.
Process Walkthrough:
1.
2.
3.
4.
5.
6.
EKG Sensors are applied onto the instructed body parts.
Sensor collects data through wires and sends it toward the MobileDAQ.
MobileDAQ sends data through airwaves via Bluetooth technology.
Bluetooth enabled PDA/Laptop picks up the signal.
The signal is processed via a custom designed LabVIEW module.
The signal is displayed on the device’s screen and a set of data is stored for future
analysis.
Qty
1
1
1
1
Parts
Table 1. Parts List
Manufacturer
EKG Sensor
Vernier Technology
MobileDAQ
National Instruments
Bluetooth Enabled PDA
HP/Palm
LabView for PDA
National Instruments
The development of the LabVIEW module was developed on a Pentium 4 2.8 GHz
running Windows 2000 Professional with the latest updates and service pack. Two PDAs
were used for the development—IPAQ 4155 for the Pocket PC 2003 platform and Palm’s
Tungsten T2 for the PalmOS platform.
-7-
The development of the LabVIEW has two main components. The MobileDAQ detector,
which handles the initiation and handshaking, and the data collecting/graphing module
which collects data and presents it in a graphical form.
The Detector:
There are many instances in which there may be multiple MobileDAQs present. For
example, a classroom experiment may have a different MobileDAQ for each group. It is
therefore imperative that the PDA connects to the correct MobileDAQ of the respective
group. It may also be the case that each MobileDAQ is connected to a different data
collecting device, it is then crucial to connect to the correct MobileDAQ to ensure correct
data collection. The following diagram shows the hierarchy of the detection module.
Figure 2. Process Hierarchy
What are of interest in this diagram is the BT discover devices and the configurator
module. The BT discover devices scans the surrounding for MobileDAQ presence and
the configurator would extract the address and the alias of the MobileDAQ and save that
to memory for later usage. If no device is found, the “0 dev” module would display a
message to the user that there are no devices found. The technicality of the BT discover
devices module and the configurator module does not need to be totally understood,
because it is supplied through the MobileDAQ library. The designer would only need to
properly connect the two modules in LabVIEW. Below is the diagram of the
configurator.
-8-
Figure 3. The Configurator
-9-
Data Acquisition:
The data acquisition process is also separated into two parts, the connecting process and
the acquisition and graphing. Below shows the schematic of the acquisition process:
Connection
Acquisition
Figure 4. Acquisition Hierarchy
The connection process involves connecting to the chosen MobileDAQ via its alias.
Before data transaction link is established it is necessary to first establish a general
connection link. Bluetooth technology does not allow multiple connections. So for other
devices to connect to same Bluetooth module, the current device must first end its
connection. By the same token, by establishing a connection it prevents other device
from connecting to the Bluetooth model. After successfully establishing the connection,
the subsequent module is executed, which is the acquisition module.
- 10 -
Connection Module
Acquisition Module
Figure 5. Acquisition Module
The connection module is also given in the MobileDAQ library so its implementation is
straightforward. The acquisition module has two subparts, the data acquisition itself and
the graphing block. In the MobileDAQ, data are stored in the buffer as they are
collected. It is the responsibility of the PDA to request the data. As the data are
received, it must be graphed. During this process, the data are also stored for future
review. The graphing occurs first to eliminate any further time delay. In order for
proper graphing of the data, the graph must be setup. This is achieved by the setup
module. The setup module asks the user to input the necessary parameters to setup the
graph.
- 11 -
Figure 6. Setup Module
The parameters include the range of the graph, the input channel, sampling rates, and
number of samples. Once the parameters are received, it is sent to the graphing block to
set up the graph and begin data acquisition and graphing.
Figure 7. Graphing Module
After the parameters are taken and the graph has been setup, data is then acquired and
directly graphed. After the process is finish, the buffer is cleared.
- 12 -
Figure 8. Example of Output
Implementation process
1. Software Installation:
Several software is needed to be installed to begin the implementation
process. National Instruments provided the team with all of the essential
software required. To install the software, the CSG group was contacted to
meet with the team and install the software because of administrative
privelages not being given to students. A problem arose when the Palm
Desktop software required admin privelages even to run the program, but the
team was able to work around this with the help of the CSG group and
eventually the problem was fixed.
2. LabVIEW Modules:
The team found that the most efficient way to create the modules required for
the end-product would be to model them after the sample code available from
National Instruments. By making changes to the sample code, the team was
able to develop a working module to accept EKG data for both the PalmOS
and the PocketPC and correctly display the data in graphical form for the user
to see.
- 13 -
End-product testing
1. MobileDAQ Detection:
The first intermediate test was done on the MobileDAQ detection module in
the senior design lab in Town Engineering. The purpose of the test was to see
if the palm pilots were successfully able to detect all Bluetooth devices within
range of the PDA. After the module was opened up, the next step was to click
“Detect Bluetooth Devices”. After the PDA finished searching, it returned
with both MobileDAQs which were in the vicinity. The test was a success.
2. MobileDAQ Connection:
The MobileDAQ connection test required the palm pilots to successfully
connect to one of the Bluetooth enabled MobileDAQs. This test took place in
the senior design lab in Town Engineering. First the detection module was
run to detect the MobileDAQ. After the connection module was opened up,
and the button “Connect” was pressed, the MobileDAQ displayed a screen
which read “Connecting to Bluetooth Device”. After a few seconds, the PDA
was successfully able to connect to the MobileDAQ.
3. Voltage Graph Test:
This test was completed in the senior design lab in Town Engineering. With
the EKG sensor connected to the MobileDAQ, the detection module was run
to detect the MobileDAQ. Next the connection module was run in order to
connect to the MobileDAQ. The voltage graph module was opened up, while
the EKG sensor was not connect to anything. This test was not testing the
accuracy of the voltage sensors, but was testing whether the module would
display any data and represent it in a graphical form. The test was successful
in that it was able to graph a fairly constant voltage line for the user to see.
4. Final Product Test:
The final test was required to make sure that all the modules worked together
correctly, and the EKG data was correctly displayed for the user to see in
graphical form. This test took place in the senior design lab in Town
Engineering. The team connected the EKG probes to a test subject to see if
the heart rate would be measured. After the detection module was run to
detect the MobileDAQ, and the connection module was run to connect to the
MobileDAQ, the voltage graph module was run. After inputting the desired
time for the test of 2 seconds, the team clicked on “Run”. The graph correctly
displayed the heart rate of the test subject. The collection of EKG data was
tested repeatedly, varying testing time and sampling rate, and was always able
to successfully graph and display the EKG data from the test subject.
- 14 -
Project end results
1. MobileDAQ Detection Module:
The PalmOS and PocketPC2003 are both successfully able to detect any
Bluetooth device within the Bluetooth range of the PDA.
2. MobileDAQ Connection Module:
The PalmOS and PocketPC2003 are both successfully able to connect to a
Bluetooth enabled device with the Bluetooth range of the PDA. More
specifically, they are able to correctly connect to the MobileDAQ.
3. Graphing Module:
The PalmOS and PocketPC2003 are both successfully able to display data
taken from the MobileDAQ in graphical form for the user to see.
4. Final Product:
The PalmOS and PocketPC2003 are both successfully able to measure and
display a subjects EKG data in graphical form for the user to see.
- 15 -
RESOURCES AND SCHEDULES
Resource requirements
The chart below shows the personal efforts put forth by our members. There are three
different table reflecting our course of action as the project progressed. The hours were
equally divided at the planning stage. But that proves to be false later on, and different
stages of the project require different amount of effort.
Members
Duc Vu
Daniel Hyndman
Matt Goedken
Amber Vo
TOTAL
Table 2. Efforts
Original Efforts (hours) Revised Efforts
180
173
175
164
692
150
142
150
145
588
- 16 -
Actual Efforts
139
132
128
130
529
Cost:
Due to the nature of the project the cost estimate was not change. This was because most
of the items were donated so no purchase needed to be made.
Table 2. Estimated and Actual Cost
Estimated Project Cost
ITEMS
Cost
SOFTWARE:
a. PocketPC 2003
Donated ($350)
b. Palm OS
Donated ($229)
c. LabVIEW FDS
Donated ($2395)
d. LabVIEW for Palm OS Donated ($995)
e. LabVIEW for Pocket PC Donated ($995)
HARDWARE:
a. MobileDAQ
Donated (not purchasable yet)
b. EKG Sensor
Donated ($140)
c. Bluetooth PocketPC
Donated ($350)
d. PalmOS PDA
Donated ($320)
OTHER:
Poster and Printing
$50
TOTAL
$50
Table 3. Final Project Cost with Labor
Final Project Cost with Labor
ITEMS
SOFTWARE:
a. PocketPC 2003
b. Palm OS
c. LabVIEW FDS
d. LabVIEW for PDA
e. LabVIEW for Pocket PC
HARDWARE:
a. MobileDAQ
b. EKG Sensor
c. Bluetooth PocketPC
d. PalmOS PDA
OTHER:
Poster and Printing
LABOR AT $10.00
Duc Vu
Daniel Hyndman
Matt Goedken
Amber Vo
TOTAL
Cost W/O Labor
Cost W/ Labor
Donated ($350)
Donated ($290)
Donated ($2395)
Donated ($995)
Donated ($995)
Donated
Donated
Donated
Donated
Donated (N/A)
Donated ($140)
Donated ($350)
Donated ($320)
Donated
Donated
Donated
Donated
$50
$50
$50
$1,390
$1,320
$1,280
$1,300
$5,290
- 17 -
Schedules
The original, revised, and actual schedules are very similar; although there still exists
some slight differences. The team anticipated that the development stages would take
much less time then it actually did; however, creating the user manual went much faster
than anticipated. The team was still able to complete all tasks on the schedule, despite
some small adjustments in task management.
Figure 9. Original Schedule
Figure 10. Revised Schedule
- 18 -
Figure 11. Actual Schedule
- 19 -
CLOSURE MATERIALS
Project evaluation
This section contains a list of the milestones set forth in the original project plan, and
evaluates them based on the following scale: exceeded, met, almost met, partially met, do
not meet.
1. Project Plan: exceeded. The team determined exactly what the problem was, and
created a solution based on the intended users and the intended uses. The amount
of time for each task based on the estimation of the task’s difficulty. It turned out
that what the team planed matched nicely with the actual process.
2. Project Poster: exceeded. Project poster was the next task of the team after the
project plan. It was a good way for the team to describe to viewers what the
project was about, what the team supposed to accomplish in given time periods.
3. Technology selection: met. Devices and tools for completing the project were
successfully chosen. Software and hardware that needed for the project were also
selected wisely by the team and provided by National Instruments.
4. Research EKG properties: met.
5. EKG Sensor Testing: met.
6. MobileDAQ Testing: met
7. LabVIEW development: met. all team members learned how to program using
LabVIEW to collect, display EKG data on the PDA, convert the EKG data into a
graphical form for the user.
8. Pocket PC development: met.
9. Pocket PC module- PalmOS module testing: met.
10. PalmOS development: almost met.
11. End product testing: met. The end product was thoroughly tested. The team has
successfully taken EKG measurements using a PalmOS and a Pocket PC PDA. A
users’ manual is about to be completed which will direct users how to use the
system to take realistic EKG measurements. The manual will also include how to
connect the EKG sensors to the MobileDAQ, how to connect the PDA to the
MobileDAQ using the Bluetooth technology, how to start taking EKG
measurements, and how to read out the EKG results.
12. Project reporting: met. All necessary documents were completed, the group’s
web site was updated often and all weekly reports were sent.
Overall, the project is a success. All the milestones were met. The team accomplished
all the tasks nicely. Even though the team faced some problems in developing phases but
team-work and positive attitude of each member was a significant thing that helped the
team to the success.
- 20 -
Commercialization
The project was developed using free development tools and software that were donated
by National Instruments. Therefore, commercialization of the project would be fairly
cheap. However, some software used in the project may be copyrighted. Those issues
would need to be resolved before any commercialization could take place.
Cost of Production
Assuming the above copyright issues were resolved, production of the product could be
done cheaply. A commercial package would contain the following products:
Production Costs
Item
PDA
Approximate Cost
$350
EKG Venier Sensor
$140
MobileDAQ
N/A
User’s manual
N/A
A commercial package could be produced for around $490
Selling Price
Without knowing where future groups will take the project and upgrade it to a higher
level, it is not feasible to determine a price or a cost at this time. But for teaching and
researching purposes, the products do have selling prices which would be the addition of
the production costs and the labor.
Potential Market:
Customers in the medical industry have already been using PDA devices built using
LabVIEW PDA and these devices are more precise and specialized for medical purposes.
Due to the level of accuracy of the device, this Mobile EKG Measurement Solution is not
used for serious medical situation. It aims to non-serious medical users such as school
teachers, lifeguards, and nurses.
- 21 -
Recommendations for Additional Work
There is no additional work is required for this project. All goals of this project
apparently will be completed by the end of this semester.
Lessons Learned
By the end of the year, the team has put a lot of time and effort into completing this
project. Several tasks turned out extremely well; while some things just seemed to be
very difficult to accomplish.
What went well
Here is a look back at a few things which helped guide the team to success.




Everyone was a team player, and consistent updates via email were the key to
keeping everyone on the same pace. Assigning individual tasks and holding each
team member responsible for delivering were also important keys to the team’s
success. In addition to that, team’s morals and willingness to co-operate have
been excellent and a low stress factor for the group dynamic.
Process of the project. All team members had ideas for the final product, and
good amount of debate before refinements went into the final design. The final
design incorporated ideas from all team members, and was appropriate for solving
the problems defined in the project plan.
Software development – This was completed successfully, right on track.
Research of components – All publicly available information that was necessary
for the project was located quickly.
What didn’t go well
There wasn’t much during this project that gave the team problems, but that doesn’t mean
everything went as planned.

Due to security issues, the team had trouble installing the necessary software
needed to complete the project. Even after a computer administrator had installed
some software, the programs were still unable to be accessed by the team
members.
- 22 -
Technical Knowledge Gained
Throughout the completion of this project, many new technologies needed to be studied.
These new technologies broadened the teams’ ability to use more advanced computing
software.


The team was able to learn the language of LabVIEW and use it for the project.
At the beginning of the project, none of the team members had any experience
with LabVIEW but during the process, the team learned the basics of creating an
interface in LabVIEW, collecting the data, graphing the data to a PDA.
LabVIEW was exactly the right software for the project since it delivers a
powerful graphical development environment for signal acquisition, measurement
analysis, and data presentation measurement analysis, and data presentation,
giving programmers the flexibility of a programming language.
Non-technical Knowledge Gained
The team was also able to end the project with experience outside of the technology
aspect; here are a few benefits of the project’s success.





Group programming experience. Though all team members had experience
coding in groups, none had programmed a group project this large. Each team
member refined his group programming skills and is better prepared for future
group programming projects.
The team was able to develop time-management skills to make certain that all the
deadlines for the project were met. Division of labor, knowing the goals, and be
able to achieve the goals are important.
As none of the members of the team had prior relations with each other before the
conception of the team, each individual member was given the opportunity to
work together not only designing and creating the final end product, but molding
as a unified team.
Brainstorming sessions provided insight into what others were thinking
When working with a broad project, break down parts of the project and make
sure to better define them
- 23 -
What to do differently
Although the project was a complete success, there are some factors which could have
made the project easier to complete.


The team had problems with the software administration settings when installing
it. It would be better if each member had the authority to use the installed
software him/herself in order to save time for the project development phase. In
the end the team and the administrators found a way around this problem, but it
took several weeks to solve.
More computers for Senior Design Lab will be a solution for the team to
accomplish the job. For quite many times, the team could not access to the Senior
Design Lab computers due to the fact that the computers were occupied by
different senior design groups. Although the senior design lab is frequently
empty, there are only a few computers in the lab; meaning when another team is
in the lab, all the computers are taken and the team is behind another day.
Risk and Risk Management
The risks involved in this project were minimal. The following is a list of some risks
involved.
Anticipated Potential Risks
This section lists possible risks the team considered in the project plan, as well as
techniques for minimizing these risks.
 Loss of an advisor – Loss of a team member: To minimize this risk, all team
members were made aware of each others’ tasks and roles, to assume and
distribute those tasks should make the loss as critical.
 Loss of data/code – All data was backed up in multiple sites, on multiple systems.
 Over-proposed project – To minimize this risk, the team consulted the faculty
advisor before and discussed inside group before the final design was submitted.
Anticipated Risks Encountered
This section lists which anticipated risks listed above were encountered, and how they
were handled.
 Over-proposed project – Though the faculty advisor was consulted before the
final design was completed, there were still more features than the team was able
to implement in the time given. To ensure that the project could still be
considered successful, the team devoted attention to the more important aspects of
the project.
- 24 -
Unanticipated Risks Encountered
This section lists encountered risks which were not anticipated in the project plan, and
details how those risks were handled.
 Incompatibility of development software. It was discovered that code compiled
with LabVIEW would run on machines with certain library files included. To
cope with this risk, the necessary libraries were included with the final product.
Resultant Changes in Risk Management
This section lists the changes made in the team’s risk management strategy due to the
encountered risks.
 Future users were not able to understand the code. Management will be providing
a well-explained comments and documents of the theory to allow easy and
seamless transition between the current team and the future teams.
- 25 -
Project Team Information
The following list the contact information of the parties involved in this project.
Client:
National Instruments Corp.
Building C
11500 N Mopac Expwy
Austin, TX, 78759-3504
ATT: Marius Ghercioiu
Tel: 512-683-8828
marius.ghercioiu@ni.com
Faculty Advisor:
Professor Morris Chang
Dept. of Electrical & Computer Eng. Iowa State University
Office: 391A Durham Center
Phone: (515) 294-7618
Fax: (515) 294-8432
morris@iastate.edu
Team Members:
Matt Goedken
Electrical Engineering
1400 Coconino Rd. #109 Ames, IA 50014
Phone: 515-441-0349
mattgoe@iastate.edu
Dan Hyndman
Computer Engineering
125 Campus Ave. #3 Ames, IA 50014
Phone: 712-261-0888
dhyndman@iastate.edu
- 26 -
Amber Vo
Electrical Engineering
3526 Lincoln Way Apt #83 Ames, IA 50014
Phone: 515-292-7628
ambervo@iastate.edu
Duc Vu
Electrical Engineering
707 Kellogg Apt #2 Ames, IA 50012
Phone: 515-451-3521
dhvu@iastate.edu
Closing Summary:
In closing, the current project is one that is unique and will results in many benefits to the
intended audiences. From school teachers to non-serious medical users such as
lifeguards and nurses. The team hopes that the success of this project will prove to be
beneficial to others. The team would like to see a more sophisticated sensor developed
for mobile EKG acquisition. A change in sensor would not necessarily require a change
in software. So the result of this project will prove to be much more useful in the future
where it can be applied to serious health situations.
The team would like to thanks Marius Ghercioiu at National Instruments for his relentless
effort in helping the team succeed.
- 27 -