General Clinical Research Center
Using PDA’s to Automate Vital Signs Acquisition
and Storage
(UPAVAS)
EECE 296
Spring 2005
Submitted April 29, 2005
Client:
Dr. Paul Harris
Supervisor:
Dr. Andrew Dozier
Team Members:
Chris Heath
Adam Nagel
Chris Nash
Brendan Soar
Table of Contents
1. Project Summary: .................................................................... 4
1.1.
1.2.
Project History .................................................................................................... 4
Summary of Progress .......................................................................................... 4
2. Requirements: .......................................................................... 6
2.1.
2.2.
Operational Requirements: ................................................................................. 6
Physical Requirements: ....................................................................................... 6
3. System Description .................................................................. 7
3.1.
Operational Concept ........................................................................................... 7
3.2
System Diagrams ................................................................................................ 7
3.2.1
System Overview ........................................................................................ 8
3.2.2
PDA/Dinamap Interface.............................................................................. 9
3.2.3
PDA/User Interface ................................................................................... 10
3.2.4
PDA/MySQL interface ............................................................................. 10
3.3
LabVIEW .......................................................................................................... 12
4.0 Hardware Detailed Design .................................................... 13
4.1
4.2
4.3
4.4
PDA................................................................................................................... 13
AirCable ............................................................................................................ 14
Wireless Network.............................................................................................. 15
Web Server/MySQL server............................................................................... 15
5.0 Software Detailed Design ...................................................... 16
5.1
Labview Overview ............................................................................................ 16
5.2
Dinamap BP_HR Study Overview ................................................................... 16
5.2.1
Logic ......................................................................................................... 16
5.2.2
Dependencies ............................................................................................ 17
5.3
Showing and Hiding Controls/Indicators.......................................................... 18
5.4
Dinamap BP_HR Study Details ........................................................................ 18
5.4.1 ID Acquisition/Verification ............................................................................ 18
5.4.1
Create Local Save Files/Directories .......................................................... 19
5.4.2
Establish Bluetooth Communication ........................................................ 19
5.4.3
Main Acquisition Loop ............................................................................. 20
5.4.3.1 Wait Loop ............................................................................................. 21
5.4.4.2 Acquiring a Measurement ..................................................................... 22
5.4.4.3 Obtaining a Comment ........................................................................... 23
5.4.4.4 Uploading and Writing Data ................................................................. 23
5.4.4.5 Resubmit Data ....................................................................................... 24
5.4.4.6 Re-establish Bluetooth Communication ............................................... 25
5.4.4.7 Resubmit Failed Data and Close Communication ................................ 25
5.5
GCRCDataSubmit_min.vi ................................................................................ 26
2
5.5.1
Variables ................................................................................................... 26
5.5.2
Algorithm .................................................................................................. 26
5.6
gcrcHTTPGetUrl............................................................................................... 27
5.7
dinamap model poll........................................................................................... 28
5.7.1
Parameters ................................................................................................. 28
5.7.2
Algorithm .................................................................................................. 28
5.8
dinamap to pda talk ........................................................................................... 28
5.8.1
Parameters ................................................................................................. 28
5.8.2
Algorithm .................................................................................................. 29
5.9
dinamap serial acquire ...................................................................................... 29
5.9.1
Parameters ................................................................................................. 29
5.9.2
Algorithm .................................................................................................. 29
5.10 dinamap port determination .............................................................................. 30
5.10.1
Parameters ................................................................................................. 30
5.10.2
Algorithm .................................................................................................. 30
5.11 GCGC_Parser ................................................................................................... 31
5.11.1
Parameters ................................................................................................. 31
5.11.2
Algorithm .................................................................................................. 31
5.12 dinamap resubmit data_v3 ................................................................................ 31
5.12.1
Parameters ................................................................................................. 32
5.12.2
Algorithm .................................................................................................. 32
5.13 dinamap write.................................................................................................... 32
5.13.1
Parameters ................................................................................................. 32
5.13.2
Algorithm .................................................................................................. 33
6
Test/Evaluation Procedure ................................................... 34
6.1
Bluetooth Communication ................................................................................ 34
6.2
Server Communication ..................................................................................... 35
6.3
File I/O .............................................................................................................. 35
6.3.1
File Write .................................................................................................. 35
6.3.2
File Read ................................................................................................... 36
6.4
Product Testing ................................................................................................. 36
6.4.1
Initial Testing ............................................................................................ 36
6.4.2
Secondary Testing ..................................................................................... 37
7
Conclusion .............................................................................. 38
8
Recommendations For Future Work .................................. 39
3
1. Project Summary:
The goal of our project was to design and implement a portable device that would
automate the data acquisition from a vital signs monitor (Dinamap Pro 1000). Our client,
the General Clinical Research Center (GCRC), brings in hundreds of patients each year
for various research goals. Some have rare conditions that are of interest to researchers.
Many are brought in by pharmaceutical companies for the testing of new medicines.
Study subjects are flown in from around the world, at great expense to the center and the
study's sponsor, and are only at Vanderbilt’s medical center for a short period of time.
During each study, a series of serial blood pressure and heart rate readings are taken of
the patients to track their responses to medicines or procedures.
The vital signs monitor that is used to measure all vital signs of the patient is able to
trigger, retrieve, and store a minimal amount of measurements for each patient. The
problem we faced was to trigger/retrieve the measurements from the Dinamap monitor,
and upload the data wirelessly to a server so that the measurements could be seen “live”
from anyone with access to the MySQL server or its PHP front-end. Our solution had to
be durable enough to not crash under any “reasonable” condition, and ensure that all data
that was acquired was saved in multiple locations to ensure no loss of critical
information.
1.1. Project History
Before our solution was implemented, nurses were required to trigger the
measurements manually, at every time interval. Since each patient is brought in at
great cost, any loss or corruption of results is unacceptable. The studies that are
performed often last from one to eight hours with measurements every three to five
minutes. Once the study is concluded then the data is uploaded manually by a
nurse, often using a floppy disk. On some occasions, a computerized system is not
available, and nurses must manually trigger and record vitals signs measurements.
This introduces a large potential for timing and transcription errors. Each time that
an error is introduced into the study the research data becomes less useful,
potentially costing the GCRC thousands of dollars. To ensure that such data
corruption doesn’t occur, an inexpensive automated solution is needed that will run
the studies without consistent monitoring by an operator and that will be able to
upload the data to the MySQL server in a reliable manner.
1.2. Summary of Progress
Our handheld solution is able to trigger, retrieve, and upload all vital signs
data reliably. We have implemented our solution on a PocketPC running LabVIEW
for PocketPC. The PocketPC uses its Bluetooth connection to talk to an AirCable
(a Bluetooth-to-serial adaptor) connected to the Dinamap Pro 1000. The PocketPC
first triggers a measurement, and then polls the device for the data from the last
4
acquisition. Once the data is received from the monitor, the PocketPC tries to
upload the data via the IEEE 802.11b wireless network by sending the data to a web
page running a PHP script. The PHP script takes the vital signs data from the URL,
parses it, and stores the data into the appropriate database. If the data was
successfully uploaded we will receive the proper return codes, if not then we will
not receive the proper return codes. If the upload failed, then we simply put the
data into a separate file on disc. We keep trying to upload all data that wasn’t
uploaded originally during our wait time between measurements. If, at the end of
the study, there remains data that hasn’t been uploaded, then the operator is
informed of the condition and is instructed to proceed to a designated point where
the wireless network is known to be sound. If the data still can’t be uploaded then
we pop up another screen for the operator to inform them that they need to hand
over the PDA to an administrator so that he/she can use a program running on
desktop to upload the data. With three different levels of data uploading checks, we
feel confident that all data will be uploaded after each study. If for some unknown
reason all data couldn’t be uploaded to the server, at least all the data will be stored
locally on the PDA ensuring no data will ever be lost.
5
2. Requirements:
Our solution requirements can be broken down into two distinct categories,
operational and physical. The operational requirements deal with how the solution will
work, and what specs it must meet. The physical requirements are more general are
relate to the size and cost of the solution.
2.1. Operational Requirements:
Due to the sensitive nature of each measurement we needed to make sure that we
always triggered and recorded all the vital signs data at every interval! Therefore our
solution had to meet specific timing requirements and be extremely stable.









Able to trigger/receive measurements every 60 seconds
Easy to use
Take a measurement at any time, as well as at specified intervals
Easy to use by untrained nurses
Allow setting of measurement intervals
Program easily modifiable to accommodate future technology
Electrically Isolated from vital signs monitor
Multiple levels of redundancy to prevent data loss
At least 5 year life cycle
2.2. Physical Requirements:
The physical requirements of the system related to the size, power, and cost of the
solution. These requirements are as easily quantifiable as the operational requirements,
thus the reason for the distinction.





Easily carried in one hand
Stored/mounted on the Dinamap stand
Should not rely on batteries
Battery power needed for emergency situations
Cost between $400 - $500 per unit
6
3. System Description
Our system was designed to be a handheld, data acquisition system that can be
easily modified and customized. The device will be used by nurses to automate the
process of triggering, retrieving, and uploading all the vital signs data taken by the
Dinamap. The device needs to be extremely user friendly for operation by non-technical
nurses. Once the nurse initiates the test, the device should be able to run on its own and
not require supervision.
The device will be used in near-ideal conditions, operating at room temperature
with a power supply attached. Since the patients will not want to be in a room that is
terribly uncomfortable we can assume that the temperature in the room will be between
60 – 80 degrees Fahrenheit. The power to the PocketPC and Bluetooth-to-serial data
converter will be connected to the same outlet that the Dinamap is connected to. If for
some reason there is a loss of power the converter will no longer operate, but both the
Dinamap and PocketPC will. This means that we will no longer be able to take
measurements but we will not lose any data that is stored on the PocketPC because all
measurements will be stored in the device's ROM.
3.1. Operational Concept
We decided that to keep the cost of this project down we would use a few PDAs
to interface with multiple Dinamap monitors, since only a few monitors are ever in use at
a single time. To allow a PDA to communicate with one of several monitors, we knew
that a basic setup process would be needed. So we assigned an AirCable Bluetooth-toserial adaptor to each vital signs monitor, with a specific channel that the AirCable would
listen to. Then the PDA can choose which monitor it will interface to by simply selecting
the correct name, thus creating a dedicated channel between the two devices.
Once the operator has created a direct link between the PDA and Dinamap then
they will proceed to the study identification screen. The user will enter a study number,
which will be verified, and the user will then be shown the measurement screen. Once at
the measurement screen, the first measurement will begin. The user can then set the rate
at which measurements will be taken. Then the program will trigger and receive the data
from the Dinamap monitor, store the data locally, and then try to upload the data to the
web server. If the data can’t be uploaded then the data is stored into a separate data file
and will be uploaded when the wireless network is available again.
3.2 System Diagrams
The most challenging part of our project was the systems integration aspects. We
essentially took off the shelf products, such as the PocketPC, and integrated them into a
single package. The reasoning behind using only off the shelf products was simple, we
knew that these products had been tested and debugged previously. So we knew that the
products we were using worked, so all we had to do was get them to work together.
7
3.2.1 System Overview
Figure 1: Top level diagram of the solution.
As seen in the above diagram, our PDA/PocketPC has three major interfaces. Our
first major interface was to the Dinamap monitor, via the AirCable Bluetooth-to-serial
adaptor (explained in section 3.2.2). The second major interface was with the user, thus
the reason why we choose to use a PocketPC. PDAs already have an easy-to-use user
interface built in, so all we had to do was design an easy-to-use graphical user interface
(GUI). Thus one of the major requirements for our development software was the ability
to create GUIs relatively easily (explained in section 3.3). The third interface that we had
to worry about was the PDA to MySQL server interface. The server interface had to
upload the data in a reliable way over the wireless network, and provide feedback so that
we would know if the data was uploaded correctly.
8
3.2.2 PDA/Dinamap Interface
Since we wanted our solution to be as portable as possible, we wanted it to have
as few wires attached to our device as possible. So we decided that using the bluetooth
connection on the PDA to connect to the Dinamap monitor via the AirCable adaptor
would make our solution as mobile as possible.
Figure 2: The interface between the PDA and the Dinamap monitor.
Another major reason for using the adaptor is because our solution is supposed to
have at least a 5 year life cycle. PDAs today have a serial port that could be connected to
the Dinamap monitor and communicated perfectly, but port is being phased out. To
ensure that our solution would be viable for over five years, we decided to communicate
via Bluetooth.
As can be seen from the above diagram our PDA will use its built-in Bluetooth
capability to talk to a Bluetooth-to-serial adaptor. The adaptor will connect directly to
the Dinamap’s serial port, separating our device from the Dinamap and maintaining
electrical isolation.
Diagram 2 also shows how each interface connects to the PDA in more detail then
our previous diagrams. First, the user interface (UI) will communicate directly with the
PDA OS. Then the PDA OS will interface with all other aspects of the system according
to the instructions given from the user interface. Diagram 2 also shows how the data
storage system will operate. The data storage system will receive all the information
9
from the PDA OS where it will send the data to two distinct locations, local storage and
network storage. The local storage will be used to make sure that we always have a copy
of all the data, ensuring that we don’t lose any data. The network storage system will be
explained in greater detail in section 3.2.4.
3.2.3 PDA/User Interface
One of our main requirements was for our system to be easy to use, since nontechnical people will most likely be operating the device. To fulfill this requirement we
decided that giving the user an environment that they were most used to would be best,
thus we decided to make a GUI.
Figure 3: Screenshot of the GUI.
As seen from the above diagram, the UI is very intuitive. All the operator has to
do is type in the patient ID, measurement interval, any comments that they want to enter,
and click run. Each of these inputs has a field clearly labeled with drop down menus that
can be operated through the stylus associated with the PDA. Thus everything is very
visual and only requires the nurse to touch the screen to operate, making our UI very
intuitive.
3.2.4 PDA/MySQL interface
The PDA interface to the MySQL network server will take place via the IEEE
802.11b network. The reason we choose to use the wireless network, as opposed to a
cradle solution, was because the wireless network allows for real time updates. Thus a
doctor could be sitting in his office and pull up the current results for patient X, and see
to the minute how the patient is reacting.
10
Figure 4: Overview of the web upload interfaces
The above diagram shows how the data will be transmitted from the PDA to the
MySQL server. Once the data is acquired, our program will then send the information to
our communication function. Our communication function will access a URL that
includes both the address of the PHP script and variables appended to the end of the
string. The server that the script is running on will decode the information embedded in
the URL, parse it, and send it to the MySQL server. Once the data has been received and
processed the web server will send a return code specifying whether or not the data was
processed correctly. If the data was processed correctly then the job is done; if it wasn’t
received or processed correctly then we must save the data locally. Once the data is
stored locally we will perform routine checks to try to reload the data. If by the end of
the study we have any data that hasn’t been uploaded then we will have a designated spot
where we know the wireless access is sound, and have the nurses upload the data at that
point. If the wireless network is down then we also have a function running on a desktop
that will be able to upload the data, in the same manner as our PDA except using an
Ethernet rather than wireless communication. Our very last fail safe to make sure that no
data is lost is to store all the data locally, and mark all the data that hasn’t been
successfully uploaded. So once the program director realizes his/her data wasn’t
uploaded correctly they can go get the information right off the PDA. So we essentially
built in a lot of redundancy into our data storage process because we wanted to make sure
that we met our requirement of not losing any data.
11
3.3
LabVIEW
We choose to write all of our software using National Instruments LabVIEW
software. LabVIEW is programming software that allows the user to drag and drop
functions (called virtual instruments or VI’s) into a window. Then you simply connect
different VI’s and sources together via control lines, and run your program. A typical
program has two different levels, the user and program level. The user level is where the
GUI that the user will see is implemented. The program level is where all the logic
controlling the program is located.
One of the major reasons we choose to use LabVIEW was because of how easy it
makes programming GUI’s. Essentially all we had to do to create our GUI was drag and
drop buttons onto the user level screen. So we could just add all the appropriate buttons
and maneuver them around in an easy to use UI.
Another reason why we choose to use LabVIEW was because it had a whole suite
of communication VI’s already created, so we could essentially just modify code that
National Instruments had already created. A prime example of a communication VI that
we used was the TCP/IP communication VI that we used to upload data to the PHP
webpage. So essentially we just modified the number of different fields which we were
uploading to a webpage and just used their TCP/IP protocol handler VI. We knew that if
we could just modify existing code then we wouldn’t have to reinvent the wheel, thus
freeing our time up to perform more important task.
12
4.0
Hardware Detailed Design
All of the hardware that we used for this data acquisition project was off the shelf
hardware, thus you could easily go online and order any products that we used. The
reason why we used off the shelf products was because we knew that these were working
products, had already been field tested, and would prevent us from having to recreate the
wheel. By using these off the shelf products we were able to save considerable amounts
of time and provide a better hardware solution to our problem.
4.1
PDA
The main piece of hardware for our project was our handheld device,
PDA/PocketPC. We choose to use a PDA because it was mobile, could run on battery
power under dire conditions, didn’t need cables, could store mega bytes of data, and
could operate fast enough to take all of our measurements.
The mobile device that we chose to use was the Dell Axim 50, which was
essentially the size of your palm (see table below).
Dimensions
Le
W
H
W
ngth
idth
eight
eight
4
2.
5.
.7 in
9 in
9 oz
Table 1: Dimensions of Dell Axim 50
Our PDA is approximately 5.9oz. One of the requirements of our system was that it
was to be small enough to be easily carried around by an examiner. Since both the size
and weight of our solution are very reasonable, we can expect everybody to be able to
carry around our solution.
The next major spec of the PDA is the power. The PDA will normally run off of
AC power, drawn from the same source as the Dinamap monitor. So under normal
operating conditions the PDA will be able to run for an almost infinite amount of time. If
however the power was to go out for any reason the PDA would be able to run off of its
battery. The standard battery in the Dell Axim 50 is a 1100 mAh Lithium-Ion. So even
if there is a power outage, our PDA will be able to run for a considerable amount of time.
Even though we will not be able to obtain measurements, because the bluetooth to serial
adaptor will not work, we will not lose any data. All the data will be stored on the PDA
and the PDA will continue to try to make a connection to the AirCable until the power
turns back on. So if the power goes out but then quickly comes back online, the PDA
will be able to reconnect to the Dinamap and continue with the study.
The next major benefit of the PDA was its lack of cables. The Axim 50 has both
IEEE 802.11b and Bluetooth communication ports built into its design. Both wireless
communication protocols are necessary for our design because we need this solution to
be mobile and achieve a 5 year life cycle. We also needed to be able to upload data in
13
real time so the only way that we would be able to accomplish this would be to use the
802.11b wireless network.
Another requirement for our system was to have enough local memory to be able to
store all the data from a test locally. The technical specs for the Axim can be found
below in table 2.
Performanc
e Specs
Clo
R
R
ck
AM
OM
520
6
1
MHz
4 MB 28 MB
Table 2: Technical specs for the Axim 50
As you can see above the Axim has 128MB of ROM storage. Each data
measurement that is uploaded correctly will take up approximately 70 bytes of data. So if
all the data is uploaded correctly and we only had 100MB’s to store data, then we could
store over 1.42 million data entries! Since a very long study would consist of 160
measurements we could run over eight and a half thousand studies and still not run out of
storage space under ideal conditions. If the conditions were not ideal then, and no
measurements could be uploaded, each data measurement would take up 470 bytes. So if
we weren’t able to upload any measurements we would be able to store locally over
210,000 measurements, or essentially 1300 studies. So even under the worst possible
conditions we will be able to maintain a level of performance that is more than acceptable
to our client, in terms of data storage. Also by storing the data locally we will have a
duplicate data set stored, allowing for operators a check to ensure data consistency.
The last major spec of the PDA that we needed to ensure that our program would
operate was the clock speed of the device. We wanted to have a device that would be
able to run our program at a rate of at least 200 Hz, or to be able to take a measurement
every 5 ms. The reason why we needed a piece of hardware that could run our program
so fast was for future upgrades, someone might want to obtain ECG information which
needs to be taken every 5 ms. Since our PDA operates at 520MHz, we knew that we
could at easily take measurements every 60 seconds, and still allow room for future
upgrades that would involve recording of ECG data.
Also do to the disproportionate rate of our clock to the rate of our measurements we
knew that we’d have a lot of time to perform error checking and data uploading. So we
could build into our solutions features that would ensure that the program wouldn’t crash,
and features that would handle erroneous data upload.
4.2
AirCable
14
Figure 5: The Bluetooth – serial adaptors
The AirCable is the Bluetooth to Serial adaptor that is connected to the Dinamap’s
serial port, as seen in diagram 5. We use the converter so that we can use the PDA’s
Bluetooth communication port to talk to the vital signs monitor. The AirCable conforms
to both serial and Bluetooth standards, and is electrically isolated from the Dinamap
monitor. Thus it draws no power from the serial port of the Dinamap, so it needs to be
connected to an external power supply. If the power ever failed at the GCRC during a
study, the study would have to stop because the converter would no longer operate.
Though this is a serious draw back to using the converter, it is a necessity due to hospital
regulations requiring all medical equipment to be electrically isolated.
4.3
Wireless Network
The GCRC is equipped with a standard IEEE 802.11b wireless network. The
system runs throughout the clinical research center, but requires a standard SSID to
authenticate to access the network. We plan on using the wireless network to transmit all
of our data to a web server that will transmit our data to the MySQL server. We know
that using Bluetooth in conjunction with IEEE 802.11b will significantly reduce the
bandwidth of the data transfer to the server, but we don’t need a lot of bandwidth since
we will only be transmitting a few bytes of information at a time. Since we only had to
transmit a few bytes of data at a time we were able to perform all of our data transmission
even with the signal degradation that Bluetooth introduced.
4.4
Web Server/MySQL server
The web server that we will be working with will be running a web page, which our
program will communicate with. The web server is an already existing server used by the
GCRC and thus didn’t require us to purchase or evaluate anything. We knew that it
would work fine for our purpose because it's already dedicated to running as a web
server, and thus one more application wouldn’t affect it.
The MySQL sever that we are using is located over in Vanderbilt’s medical center,
and is just loaning us space. So once again we didn’t have to evaluate the system since
all our project had to do was upload the data to the web server. Once the data is uploaded
on the web sever, our sponsor Dr. Harris will then handle the transferring of the data.
15
5.0
Software Detailed Design
This section attempts to document the Labview PDA programs written as part of
the solution. In order to best understand these descriptions, it is highly recommended to
have the referenced source code available when reviewing this section.
5.1
Labview Overview
The software for this program is written in National Instruments LabView PDA
Module development software. This development suite was created to allow for a userfriendly, visual method of creating software. A Labview program is referred to as a
virtual instrument (VI) and consists of two screens, the front panel and the block diagram.
The front panel displays the interface as the user will see it when the VI is run. It contains
the different inputs (controls) and outputs (indicators) that the user will interact with as
part of the VI. The block diagram contains the logic that runs as part of the code. It
consists of blocks that act as functions and wires that represent the passing of
information. Wires have different colors and styles to represent different data types.
A VI, once created, can be used within another VI by making the first VI a sub-VI.
This consists of tying specific controls and indicators to nodes on the VI’s icon. After
placing the icon of the sub-vi in the second VI’s block diagram, running wires into the
nodes completes the integration of the sub-VI.
Labview ships with many tutorials and help files to allow the user to become
familiar with its operation and the website www.ni.com contains commonly used
troubleshooting methods as well as an extensive forum to help the user in development.
5.2
Dinamap BP_HR Study Overview
This section provides a brief overview of the program Dinamap BP_HR Study.
This particular program is the top-level program that will provide our solution and is
therefore rather large.
5.2.1 Logic
The main acquisition program (titled Dinamap BP_HR Study) consists of a linear
progression with a main acquisition loop during the progression. It has 13 steps
numbered 0-12 on the block diagram that execute sequentially. Figure 6 displays an
overview of the program stages in a schematic manner.
Figure 6: A very wide overview of the BP_HR Study Program.
16
5.2.2 Dependencies
The successful compilation and execution of Dinamap BP_HR Study.vi is
dependent on several other programs. Figure 7 presents a hierarchical representation of
this dependency tree. The graphics in this diagram are the icons associated with the
various programs. These programs are those VIs that have been created or edited
specifically for Dinamap BP_HR Study and must be imported to the PC on which the
main program is being edited from the CD.
Figure 7: The hierarchy of programs required for successful compilation of the program.
The required programs in Figure 1.2 are:
1.
dinamap write.vi
2.
dinamap model poll.vi
3.
dinamap to pda talk.vi
4.
dinamap serial acquire.vi
5.
dinamap port determination.vi
6.
dinamap resubmit data_v3.vi
7.
GCRCDataSubmit_min.vi
8.
gcrcHTTPGetUrl.vi
9.
GCRC_Parser.vi
10.
gcrcRead HTTP 1.0 Response.vi
Changing the input or output connectors will cause the VI directly above in the
hierarchy to contain errors. It must be edited to accommodate these changes.
17
5.3
Showing and Hiding Controls/Indicators
In order to increase the utility of the GUI and to reduce any opportunities for errors,
it is necessary to hide or reveal the controls and indicators at certain points in the
program. To achieve this goal, the “Show or Hide Control” VI is utilized.
Figure 8: The icon associated with the Show or Hide Control vi.
The above VI has two inputs and zero outputs associated with it. It inputs an array
of integers that correspond to the “Tabbing Order” number of the controls/indicators that
will be displayed or hidden and a Boolean value that indicates whether to show the
corresponding items (TRUE) or to hide them (FALSE).
The “Tabbing Order” is set on the front panel by choosing Edit>>Set Tabbing
Order. This displays the tabbing order of the existing controls and indicators and allows
the user to change their values if desired.
5.4
Dinamap BP_HR Study Details
The following sections detail the various stages of Dinamap BP_HR Study.vi as
described in Figure 1.1. The beginning of each of these sections includes a table that lists
the main program steps executed, controls visible, the sub-VIs used, and the variables
taken and passed during the stage. If a variable is used at all in a stage, it is listed under
the “Output” category, but if it is not it is placed under the “Passes Through” category.
5.4.1 ID Acquisition/Verification
Program Steps
Controls/Indicators
Visible
0, String
1, Boolean
2, Boolean
Sub-VIs Utilized
GCRCDataSubmit_mi
n.vi
Inputs
None
Outputs
Boolean
String
Passes Through
None
1-4
Description
ID
Exit
Continue
Description
Sends data to the GCRC
network
Description
n/a
Description
Exit the program?
ID
Description
n/a
18
This stage requires the user to input the confirmation code acquired during creation
of the study into the ID string control. The user then must press button 1, Exit, or button
2, Continue. If Exit is pressed, the stage exists and the Boolean output passes out a
TRUE.
If Continue is pressed, the ID is submitted to the network - using mode 1 - with the
GCRCDataSubmit_min subVI. If this subVI outputs a 1, the stage finishes. If it ouputs a
0 (no wireless available) or 2 (bad ID), the program prompts the user whether or not he
wants to continue to the next stage or input a different ID. When the stage ends. The
Boolean passes out a FALSE, and the String passes out the ID.
After exiting the stage, a text box appears indicating that the study will start after
pressing OK. The user must hit OK to go to the next stage.
5.4.1 Create Local Save Files/Directories
Program Steps
Controls/Indicators
Visible
None
Sub-VIs Utilized
None
Inputs
Boolean
String 2
Outputs
Boolean
String 1
String 2
File Path
Passes Through
None
5
Description
n/a
Description
n/a
Description
Exit the program?
ID
Description
Exit the program?
Failed file directory
ID
All measurement
text file
Description
n/a
This stage creates a new text file and a directory. Both the file and directory are
placed in the \My Documents\din trials\ directory. The text file is named
“<<ID>>_<<month>>_<<day>>_<<hour>>_<<minute>>.all.txt” and will contain all the
measurements taken during the study. The different time strings are acquired through the
“Format Data/Time String” block. The directory is named ‘ID_<<ID>> and will contain
the files of the measurements that are not uploaded to the network correctly.
5.4.2 Establish Bluetooth Communication
Program Steps
Controls Visible
6-8
Description
19
None
Sub-VIs Utilized
dinamap port
determination.vi
Inputs
Boolean 1
Outputs
Boolean 1
Boolean 2
String 3
Integer
Passes Through
String 1
String 2
File Path
n/a
Description
Opens Bluetooth
communication port
Description
Exit the program?
Description
Exit the program?
Port find failed?
Model Number
Port Number
Description
Failed file directory
ID
All measurement text file
If the Boolean value “Exit the program” is TRUE, no code is executed at this stage.
If the Boolean value “Exit the program” is FALSE, this stage will run the dinamap port
determination VI. This sub-VI requires no inputs and outputs an integer, Boolean value,
and string. The integer that is passed out is the port number on the PDA that corresponds
to the Bluetooth communication port. The string that is outputted is the model number of
the Dinamap machine being utilized. The Boolean value is a FALSE if communication
with the Dinamap via Bluetooth was achieved while it’s a TRUE if communication was
not established.
5.4.3 Main Acquisition Loop
The main acquisition loop is where the program will reside for the majority of its
execution. All of the logic that oversees the acquisition and uploading of measurements,
the uploading of comments, the timing of the program, re-submission of measurements
which failed to upload properly, the writing of measurements to file, and re-establishment
of lost Bluetooth communication resides in this stage. Figure 1.3 provides a logical
diagram of the process.
If “Exit the Program?” OR “Port Find Failed” is TRUE, the main acquisition loop
is skipped completely. However, if this value is FALSE, the program enters into the
stage. Before entering the stage, however, the program sets two variables. First, it sets
the variable “Clock” to the current millisecond clock value. Second, it initializes the
integer “Index” to zero. Because this stage is so complicated, it has been broken up into
sub-stages for easier explanation. Additionally, those variables that are simply passed
through a step are neglected in this documentation. Examination of the code will reveal
these variables.
20
5.4.3.1
Wait Loop
Program Steps
Controls
Visible
5, Boolean
7, Boolean
8, Boolean
9, Integer
10, Boolean
17, Integer Ring
Sub-VIs
Utilized
None
Inputs
Integer Local
Variable
Outputs
Boolean 1
Boolean 2
9.1 – 9.3
Description
Pause
Insert Comment
Exit
Minutes Wait
Take Measurement
Choose Comment…
Description
n/a
Description
Clock Reference
Time
Description
Insert Comment?
Insert Comment OR
Exit?
Integer
Comment Choice
The purpose of the wait loop is to wait for any of several conditions before it will
begin any sort of calculation. As seen in Figure 1.3, a TRUE value found in any of
several Boolean variables will kick the program out of the wait loop and through the
other stages of the main acquisition loop. Firstly, if the user presses “Insert Comment”,
“Exit”, or “Take Measurement”, the loop will exit. Secondly, if the timer expires, the
loop will exit. When the loop is initially entered, the Boolean indicator “Ready to
Acquire” is set to TRUE. When it is exited, this value changes to FALSE.
There is not timer in a traditional sense; rather, the loop compares the current
clock time to the reference clock time. Both of these values are integers representing the
number of milliseconds since some arbitrary time. This difference is then divided by the
amount of time the user sets between measurements. The user sets this time in minutes
through control #9. Therefore, this integer is converted into milliseconds through
multiplication by 60000 before division. If the remainder of the division is less than 100
milliseconds, the loop exits. The reason for the arbitrary comparison with 100
milliseconds is to ensure that the loop exits immediately upon the first time the loop is
entered.
A further complication to the timing is the requirement that the countdown must
stop while the program is paused. Pausing the loop simply amounts to entering a loop
that cannot be exited until the user presses the pause button a second time. To stop the
21
countdown, the number of milliseconds that the program spends in the pause program is
added to the reference clock value. To protect against the case that the user hits “pause”
multiple times between measurements, shift registers are used to add these lengths of
time together for a total “amount of time paused” value.
After the loop is exited, the “Insert Comment OR Exit?” value is examined. If this
value is FALSE, the program enters the “Acquiring a Measurement” stage (Section
5.4.4.2). Else, if the value is TRUE, it enters “Obtaining a Comment” stage (Section
5.4.4.3).
5.4.4.2
Acquiring a Measurement
Program Steps
Controls Visible
18, Boolean
19, Boolean
Sub-VIs Utilized
dinamap serial
acquire.vi
dinamap to pda
talk.vi
Inputs
Integer
String
Outputs
Boolean 1
Boolean 2
Boolean 3
String 1
String 2
String 3
String 4
9.4
Description
Abort Acquisition 1
Abort Acquisition 2
Description
Runs algorithm to obtain all
measurement values
Writes the input string to the Bluetooth
port
Description
Bluetooth Port Number
Dinamap Model Number
Description
Bluetooth Communication Failed?
Boolean 1 OR BP Measurement Error
Abort Acquisiton
Heart Rate
Systolic Pressure
Diastolic Pressure
Mean Arterial Pressure
The stage sends those ASCII text strings using “dinamap to pda talk.vi” to the
Dinamap machine that tell it to start a measurement, find if the measurement is finished,
and to obtain the resulting measurements. First, the program tells the Dinamap to start an
acquisition. Then, the stage waits for 36 seconds or for the user to press “Abort
Acquisition 1”. The 36-second wait is to allow for the cuff to inflate. Additionally, it
allows for the hard-coded 30-second minimum time between acquisitions that the
Dinamap machine imposes on itself. Next, the program polls the Dinamap to determine
if the measurement has finished. It continues polling until the measurement finishes or
the user presses “Abort Acquisition 2”. Finally, the program calls the sub-VI “dinamap
serial acquire.vi”, which returns all of the measurements.
22
The stage uses two different Abort Acquisition controls to allow for the fact that
Labview PDA module does not allow for the output of a control to be used in more than 1
location.
The strings sent to the machine are hard-coded as constants. If the code is edited
to accommodate more than the Dinamap Pro 1000, case statements along with the
Dinamap Model Number string should be used to choose the appropriate strings to send.
The program now enters the “Uploading and Writing Data” stage (Section
5.4.4.4).
5.4.4.3
Obtaining a Comment
Program
Steps
Controls
Visible
20, String
9.4
Description
Write
Comment Here
21, Boolean
OK
22, Boolean
Cancel
23, Boolean
Clear
Sub-VIs
Description
Utilized
None
n/a
Inputs
Description
Integer
Comment
Choice
Outputs
Description
String
Comment
Boolean
Cancel
This stage passes the desired comment to the next stage for uploading and writing
to file. If the “Comment Choice” integer is a 0, “Cancel” is set to TRUE. If it is a 1 or 2,
the stage passes out a string identical to the choice on the ring control and a FALSE value
for “Cancel”.
If the user selects “Other” on the ring control, it passes a 2 as the “Comment
Choice”. The user is then given the chance to type in any desired comment into “Write
Comment Here” with the stylus. If the user presses “Clear”, the text in “Write Comment
Here” is deleted. If “Cancel” is pressed, the stage outputs a TRUE for “Cancel”. If
“OK” is pressed, the stage outputs the string found in the “Write Comment Here” control
and a FALSE for “Cancel”.
5.4.4.4
Uploading and Writing Data
Program Steps
Controls Visible
None
Sub-VIs Utilized
9.1 - 9.3
Description
n/a
Description
23
dinamap write.vi
GCRCDataSubmit_
min.vi
Inputs
Boolean 1
Boolean 2
String 1
String 2
String 3
String 4
String 5
String 6
File Path
Integer
Outputs
Boolean
String
Integer 1
Integer 2
Writes data to text file
Sends data to the GCRC network
Description
Comm Failed OR BP Measurement
Error/Cancel
Abort Acquisition
Comment
Systolic Pressure
Diastolic Pressure
Mean Arterial Pressure
Heart Rate
Failed File Directory
All Measurement File Path
Index
Description
Attempt Resubmission?
Fail File Directory
Index
Clock Reference Value
There are two instances of the stage in the code based off of whether a comment or
measurement stage immediately preceded this. If “Cancel” is TRUE, “Attempt
Resubmission?” is set to FALSE. If “Comm Failed OR BP Measurement Error” is
TRUE, a string indicators lets the user know if the measurement failed or was aborted
based on the state of the Boolean value “Abort Acquisition” and “Attempt
Resubmission?” is set to FALSE.
If “Cancel”/”BP Measurement Error” is FALSE, the stage executes. The program
uploads the comment/measurement data along with the current date and time to the server
using the sub-VI GCRCDataSubmit_min.vi. If a comment is being uploaded, mode 3 is
used, while mode 2 is used for uploading measurements. The sub-VI outputs a
confirmation code. Together with the data and current date, the confirmation code is
placed in a bundle structure. This bundle is then passed to “dinamap write.vi”. This
function will write the data to file locally. It will write it to the text file if the
confirmation code is a 1, and both the text file and a data file in the directory if it is not a
1. The directory of the files that failed to upload is then passed out of the sub-VI.
Additionally, the index is incremented.
5.4.4.5
Resubmit Data
Program Steps
Controls Visible
None
Sub-VIs Utilized
dinamap resubmit
9.4
Description
n/a
Description
Resubmits data that failed to upload to
24
data_v3
Inputs
Sting
Boolean
Outputs
String
server
Description
Failed upload directory
Attempt Resubmission?
Description
Failed upload directory
This stage will execute only if “Attempt Resubmission?” is TRUE. This stage
simply calls the sub-VI “dinamap resubmit data_v3” and passes it the string “Failed
upload directory” and a TRUE constant to “Time Limit?”.
5.4.4.6
Re-establish Bluetooth Communication
Program
Steps
Controls
Visible
None
Sub-VIs
Utilized
None
Inputs
Integer
9.5
Description
n/a
Description
n/a
Description
Bluetooth Communication
Port
Boolean
Outputs
None
Bluetooth Communication
Failed?
Description
n/a
This stage only executes if “Bluetooth Communication Failed?” is TRUE. The
program closes the communication port indicated by the integer then attempts to open it
again. If this step fails to work, a dialog prompts the user to choose whether or not he
wants to attempt to establish Bluetooth communication again or quit the program.
5.4.4.7
Resubmit Failed Data and Close Communication
Program Steps
Controls Visible
None
Sub-VIs Utilized
dinamap resubmit
data_v3.vi
Inputs
10-12
Description
n/a
Description
Resubmits data that failed to upload to
server
Description
25
Integer
String
Outputs
None
Passes Through
None
Bluetooth Communication Port
Failed upload Directory
Description
n/a
Description
n/a
This stage closes the Bluetooth port passed to it in by the integer. It also calls the
sub-VI “dinamap resubmit data_v3” and passes it the string “Failed upload directory” and
a FALSE constant to “Time Limit?”.
5.5
GCRCDataSubmit_min.vi
This function uses a network connection to upload measurement data, comments,
and to verify ID codes entered by the user. This function accesses a PHP page via HTTP
and receives an error code from the script-generated page that the server creates.
5.5.1 Variables
Variable
Name
Mode
I/O
Format
Description
I
Int
Time
I
String
Date
I
String
HR
DP
SP
MAP
Comment
Returned
I
I
I
I
I
O
String
String
String
String
String
String
Specifies the mode for the
submission (see interface
specifications)
The time of the measurement or
comment (24 hour scale).
Format: HH:MM:SS
The data of the measurement or
comment.
Format: YYYY-MM-DD
Heart rate
Diastolic blood pressure
Systolic blood pressure
Mean arterial pressure
Comment entered by user
Error code returned by web script
(see interface specifications)
5.5.2 Algorithm
26
The function first sends the domain name of the server where the PHP script resides
to the "HTTP:// get url" function (staging.mc.vanderbilt.edu at the time of this writing).
Next, the function concatenates a longs sequence of strings to form the URI that
will accomplish the submission. First is the path of the PHP page
(/gcrc/dev/dmap/dmapin.html at the time of this writing), which is followed by the '?'
character to indicate that the variables are to follow.
Next, each variable is specified in capital letters and the values passed in to the VI
are included. Some string characters are run through the GCRC_Parser VI, which
replaces special characters (such as '&' and '?') with their "URL-safe" ASCII codes.
These two strings are now combined and sent as the URI variable into the "http://
get url" function. Also in this frame, a 3000 millisecond delay is added to take care of
some latency issues that appeared in early testing phases.
The output from the "http:// get url" function is parsed for the string "ecode=",
which is the location on the server-generated page of the error code returned. The
following character in the response (the error code) is run through a case structure
statement.
The only purpose of the case structure statement is to pass through the error code if
it is a value of 1 or above, and to pass through a 0 if there was no response from the
server. An error code of 0 indicates to the program that the network connection has
failed.
5.6
gcrcHTTPGetUrl
This function takes a domain name and URI string input and forms an HTTP GET
for that address. The version used in this program is virtually identical to the function
HTTPGetUrl supplied by NI in their LabVIEW PDA package, so this description will not
go into great detail.
The only difference between this function and the NI function is that the parsing
functionality that separates "content" from "headers" has been removed so that the entire
TCP response is passed out of the function.
This was changed due the varying size and nature of headers across web servers
that caused content data to be lost in some instances. Now, the parent function
(GCRCDataSubmit_min) parses the entire TCP response for the string "ecode=" in order
to determine the script's response. This eliminates the header formatting problem
mentioned above.
27
5.7
dinamap model poll
This function polls a connected Dinamap machine for its model number.
5.7.1 Parameters
This function has one input: Port Number. This is the serial port number of the
PDA that is connected to the Dinamap machine.
This function has two outputs: Comm Failed and Model Number. Comm Failed is
a Boolean that is TRUE when a proper response is not received from the monitor. Model
Number contains the identifying model information of the Dinamap monitor if the
communication was successful.
5.7.2 Algorithm
The function passes the Port Number input to the dinamap to pda talk function as
Port Number. The string “*? L”, followed by a carriage return, is passed as send-buf.
dinamap to pda talk returns a Boolean value for Comm Failed, which is returned as
Comm Failed for this function as well. The response from the machine is parsed, with a
4-character string starting at an offset of 3 being returned as Model Number. This action
removes the header characters that lead the response from the monitor.
5.8
dinamap to pda talk
This function sends the incoming string to the serial port specified by Port Number
and returns the response by the connected device. A Boolean variable Comm Failed is
also set to indicate success or failure of the operation.
5.8.1 Parameters
This function takes two input parameters. Port Number is the number of the serial
port that is to be accessed. The unnamed string input is the string that is to be sent via the
serial port.
This function has two output parameters. Comm Failed is a Boolean value that is
set to true if no response is received from the connected device. The unnamed string
output is the response received by the serial port.
28
5.8.2 Algorithm
This function is framed by a while loop which repeatedly attempts the
communication if no response was received in the previous attempts. Communication
can be retried up to five times.
A flat sequence structure with four components forms the main functional
component. First, the Port Number variable and the input string are sent to the serial port
using a LabVIEW function. Then there is a 250ms wait period to give the machine time
to respond. Next, the serial port is polled to determine the length of the response.
Finally, a number of bytes equal to the length of the response is requested from the serial
port and passed to the string output.
The Comm Failed variable is asserted if the main while loop has executed five
times without a successful reading. The main while loop is exited either when a response
of non-zero length is received or when the loop has executed five times.
5.9
dinamap serial acquire
This function polls the Dinamap monitor for the results of the previous
measurement. It can also be used to abort a measurement operation by the monitor.
5.9.1 Parameters
This function has two inputs. Model Number is the model number of the Dinamap
machine being used. This parameter is currently unused by the function. Port Number is
the port number of the serial port being used. The unnamed Boolean variable specifies
whether the function will also cause and "abort" operation on the monitor.
This function has six outputs. Error Code is a value that indicates the reason for a
determination failure on the Dinamap if the measurement fails. Systolic, Diastolic, Mean
Arterial, and Heart Rate are those respective values that were gathered in the last
determination. Comm Failed returns a TRUE value when communication with the
device has failed.
5.9.2 Algorithm
The function is framed by a flat sequence structure with 5 frames. The first frame is
simply a wait period of 500ms.
The second frame sends the command to retrieve blood pressure data from the
Dinamap machine via the dinamap to pda talk function. The Comm Failed variable is
passed through to an OR gate in front of the Comm Failed return value for this function.
29
The response from the machine is sent to the next frame. The third character of the
response is extracted and sent to the case sequence structure in the next frame
The third frame uses the third character of the machine response to determine
whether the previous determination was successful. If successful, then the response is
parsed into the three blood pressure values. If unsuccessful then an appropriate error
code is passed to the calling function. This code indicates the reason why the
determination failed.
The fourth frame sets the Error Code returned by the function, as determined in the
previous frame. The Dinamap machine is polled for the heart rate measurement from the
last determination. The Comm Failed variable is passed to an OR gate with the Comm
Failed value obtained from the poll in the second frame. The response from the machine
is parsed and the heart rate measurement is passed to the Heart Rate indicator.
The fifth frame sends an "abort" command to the Dinamap monitor if the unnamed
Boolean variable is set to true.
5.10 dinamap port determination
This function is used to automatically determine the port number of the serial port
that is connected to the Dinamap machine. The determined value is saved to a file on the
PDA to reduce redundancy.
5.10.1
Parameters
This function has no input parameters.
This function has three output parameters. Port # is the port number to which the
monitor is connected if the determination process was successful. Port Find Failed? is
set to true if no port seems to be connected properly to the machine. Model Number is
the model number returned by the Dinamap machine if the polling was successful.
5.10.2
Algorithm
The function first opens the portinfo file residing on the PDA to see if a port
number has already been determined by a previous iteration of the function.
If an error is returned when opening the file, then the file does not exist and the port
number must be determined. If the file exists, then the port number specified within is
verified. If the machine cannot be polled from that port, then the port is determined
again.
30
Within the true frame of the first case structure, the function begins with a while
loop. This scans ports 6-10, sending a model number polling command to each port until
a response is received. If communication was successful, then the serial driver is closed
and the model number and port number are passed to their respective indicators. If there
is an error on the port when it is opened, then the polling step is bypassed. If all of the
ports are scanned and there are no successful responses, then Model Poll is left blank and
Port Find Failed? is asserted TRUE. In the case of a successful determination of the
port number, the value is saved to the portinfo file on the PDA.
Within the false frame of the first case structure, the function breaks into a fourframe flat sequence structure. The first frame reads the port number that has been saved
in the portinfo file. The second frame closes the file and opens the specified port and
checks to see that there is no error. In the third frame, if there is no error, then the port is
polled to determine the machine model number. If there was an error in opening the port,
then these fields are left blank.
If the Dinamap was not successfully polled, then the port determination algorithm
described for the true frame (above) is used to re-determine the correct serial port.
5.11 GCGC_Parser
This function converts all of the special characters in a string into "web-safe"
ASCII-equivalent characters.
5.11.1
Parameters
This function has one input, the Comment string variable. This function has one
output, the Output string variable.
5.11.2
Algorithm
The input variable Comment is sent through a sequence of "replace within string"
functions that will replace special ASCII characters with a notation that can be used in
URL strings. The '%' character is replaced first because that character is also used in the
alternate notation.
5.12 dinamap resubmit data_v3
This function attempts to submit those measurements that failed to upload upon the
original measurement. The measurements that do upload are then deleted.
31
5.12.1
Parameters
This function has two inputs, a string and a Boolean. The string, Fail_Directory
should contain the directory of the .dat files that will be uploaded. The Boolean, Time
Limit? indicates whether or not the function will time-out after 5 uploads.
The function also has two outputs of the same types. The string,
dup_Fail_Directory contains the same string as the input Fail_Directory. The Boolean
All files uploaded? indicates whether or not all of the files were uploaded.
5.12.2
Algorithm
This function first creates an array of all the files within the passed directory that
are of the .dat type. The size of this array is then determined and passed to a FOR loop as
the number of iterations to complete. An exception to this rule is, if the size of the array
is greater than 5 and Time Limit? is set to TRUE, the FOR loop is passed the number 5.
Once in the FOR loop, the ith file in the array is opened and the 1st (and only) data
element is read and unbundled into its separate elements. These elements are then passed
into the GCRCData Submit_min sub-VI. Finally, if the error code is good, the file is
deleted.
Once out of the while loop, an array of Boolean values that indicate whether each
data file was uploaded successfully is examined. If this array contains no FALSE
elements, a TRUE value is passed out of the function as All Files Uploaded?, while a
FALSE is passed out if even a single FALSE is encountered.
5.13 dinamap write
This function records the measurement or comment to a local file on the PDA. If
the data failed to upload originally, it is written to both a .dat file and a .txt file. If the
data uploaded correctly, the measurement is only written to the text file.
5.13.1
Parameters
This function has four inputs: a cluster, a string, a data path, and a Boolean. The
cluster, data cluster contains the measurement data. It must be 11 elements consisting
entirely of strings, except for the 1st and last element, which are long integers. The data
path All data path should contain the text file under which every measurement is being
recorded. The string Fail Directory should contain the directory of the .dat files that
failed to upload. Finally, the Boolean value Submit Failed? indicates whether or not the
data was successfully uploaded to the server.
32
The function also has two outputs, a string and a data path. These are identical to
the input string and data path.
5.13.2
Algorithm
This function first unbundles the data cluster into its components. The integer
values are changed to strings, and the entire cluster is concatenated into a string separated
by tab constants. A new line character also added to the end of the string. This string is
appended to the end of the passed text file.
If the Boolean Submit Failed? Is TRUE, a new datalog file is created within the
passed directory. The file is named with the current month, day, hour, minute, and
second and is of the .dat type. The data cluster is then written to the created file, which is
then closed.
33
6
Test/Evaluation Procedure
To test our product we tried to break everything down to as small of subunits as
possible, and then test each subunit. Once we were sure that we had the subunits working
properly then we tried integrating each unit together one at a time. By breaking each task
down to its smallest part we were able to identify problems and track them down faster,
since we were limiting the number of locations the problems could be in. Then once we
had the subunits working properly we simply had to debug the problems that come from
trying to integrate them together, a task much harder than most people would believe.
6.1
Bluetooth Communication
The first major step that we performed in our testing of our product was the
communication between the PDA and the Dinamap monitor. We first started small, just
trying to figure out the communication protocols needed. Initial test were performed with
a serial to serial hyper terminal connection on a PC connected to the Dinamap. After
discovering how to communicate with the monitor through a PC, we then moved to
communicating through a VI running on a PC, as seen from the diagram below.
Figure 9: Picture of a VI that works very similar to hyperterminal
This VI allowed us to test all of the commands and check sum codes associated
with these commands, on the Dinamap. So we could test every single command, make
sure that we knew how to use each command, before we had began implementing on the
PDA.
The VI we created, diagram 6, then could easily be ported to a PDA. With a few
slight modifications we were able to communicate via the Bluetooth connection instead
of a serial connection. Thus we broke the task of communicating to the monitor into
34
small steps that were relatively easy to debug. Then through small steps we were able to
build up our functionality to a working Bluetooth communication VI.
6.2
Server Communication
To communicate with the MySQL database all we had to do was send our data to a
website running a PHP script. We started by taking an example VI that didn’t essentially
the same thing and then adjusting it to our needs. To debug the VI we first ran the
example VI for its original purpose. Then we took the TCP/IP protocol handler out of the
program and adjusted the fields that it required to fit our needs, namely submitting heart
rate and blood pressure information. Once we had modified our program we simply
changed the web address that we would be accessing and then uploaded our information.
To upload the data we simply created a file full of bogus data and tried to upload
that file, similar to what we do with real data. Once we had opened the file and read the
data, we encoded the data into the URL. We were able to check the URL encoding by
having the output of the URL encoder appear in our GUI, so we could always be sure that
our program was at least trying to upload the correct data. Once the data was encoded
properly we opened up a web browser and attached our data to the URL for our web
page.
We had to methods to determine whether or not our data was uploaded correctly.
The first method involved checking a web page that was created to show our uploaded
data. If the data was uploaded to the web page then we would be able to see the
information almost instantaneously after submission. If the data never reached the web
server then the data wouldn’t show up on the web page and we would know that the data
hadn’t been submitted correctly. The second method we used to debug our data
submission was through return codes from the web server. The return codes would
specify whether the data received by the server was decoded correctly. We built into our
VI a window that would display the return codes after every submission, so that we
would always know whether the data had been handled properly. Thus we were able to
easily build in all of our error handling to make sure that any data that wasn’t uploaded
properly was saved in a special directory for that patients un-uploaded data.
6.3
File I/O
Our file I/O was tested in conjunction with our Bluetooth communication and
server communication VI’s. We essentially used each of these communication VI’s to
create, write to, open, and read from data files.
6.3.1
File Write
The initial test of our file I/O involved having our Bluetooth communication
protocol obtain data from the Dinamap. Once the data was received from the monitor we
then created a file and wrote the data to that file. To test that the data was actually
35
written the file we would acquire a single reading and check to see if the data was written
to the file. If the file was created but no data was written then obviously we knew that we
were acquiring the data, since it would appear on our GUI, but weren’t writing it
properly. Since we had implemented and tested our data acquisition Bluetooth VI
previously, we knew exactly where the error was.
6.3.2
File Read
To test the file read all that we had to do was open the file and read the data to a
field in our GUI. We already knew that the file had been created and that valid data was
in the file. So we simply created a program to read the data and print the information to
the screen. If the nothing was printed to the screen then we knew that we hadn’t opened
the file correctly. If the wrong information was printed to the screen then we knew that
we hadn’t read the data correctly. Once we were able to perform a file read we simply
sent the data to our server communications VI to make sure that we would also be able to
submit the data that was read.
6.4
Product Testing
The last level of testing that we performed was entire system test. We performed
several test with all the elements of the product integrated together, so the bluetooth
communication was connected to the file I/O and the both were connected to the server
communication VI. We first perform some basic initial test, to make sure that there
weren’t any major problems with our program. Then we moved onto secondary test
which involved running our program for a long study period, running our program for
eight hours taking a measurement every five minutes.
6.4.1
Initial Testing
In our initial testing our goals were to eliminate any problems that would prevent us
from running long term test. So we wanted to make sure that steps like patient
authentication, data acquisition, and data storage were all working properly. Since we
debugged our VI’s separately we essentially had few critical errors to debug in this
section of the program.
The most significant error that we discovered was our inability to perform file I/O
on data that had failed to upload originally. When we tried to read from the file
containing all data that wasn’t uploaded correctly we kept running into memory errors
that required us to shut down the PDA. The reason why we were getting these errors was
because the end of file function (EOF) in LabVIEW wasn’t working properly. We
believe that the reason the EOF function wasn’t working properly was because we were
constantly opening and closing that single file so that we could write all the data that
hadn’t been uploaded yet into it. So we figured that at some point a pointer was losing
36
track of the memory locations, and causing a problem with the EOF function. To correct
this problem we simply created a directory for each patient with a list of files each
containing only one measurement that hadn’t been uploaded. This is obviously not the
most elegant solution to the problem and can be improved upon, but we will leave that to
future implementations of the program.
6.4.2
Secondary Testing
Our secondary testing involved running our program under actual study conditions,
for eight hours taking a measurement every five minutes. Essentially this was the final
testing procedure, ensuring that our system would perform to specs under normal
operating conditions.
The biggest problem that we had during this test was once again dealing with
memory allocution. After running our program for several long term studies we
sometimes would run into memory failures that would cause our program to crash. We
believe that the reason for this has something to do with Windows Mobile Edition and
how it handles memory allocution. Our reasoning behind our conclusion is because we
tried running our program on an upgraded versions of Windows Mobile Edition and
found that we rarely received such memory allocution errors anymore. To ensure that
there is never a memory allocution problem while the program is running we have
specifically stated in our user manual that before each study the PDA such be manually
reset, thus clearing the memory. We noticed that we never had a problem with memory
allocution after two or three studies, but as we performed more studies without resetting
we noticed that memory allocution errors occurred more rapidly. So the operator should
reset the PDA before every test, but if for some reason they forget for a single study to
not reset the program should still operate perfectly.
37
7
Conclusion
Based on our recent field test we can conclude that we met all of our project
requirements. We can trigger a measurement and receive data via the Bluetooth
connection. Such tasks are set up through an easy to use GUI that has been approved by
our project sponsor. Once the data has been received we store the data locally and
attempt to store the data on the SQL server. If the data can’t be uploaded immediately
onto the server then our program will continually try to upload the data during periods of
inactivity. If at that end of the study there is data that hasn’t been uploaded we have two
different solutions to ensure that all of our data will be uploaded. First the operator will
go to a designated point where the wireless network is known to be solid, and running a
VI that will uploaded all of the data that hasn’t been uploaded. If for some reason the
wireless network is down then the final solution will be to hand the PDA to an
administrator who will transfer each directory of un-uploaded data to a desktop and run a
separate VI that will attempt to upload the data over the local Ethernet connection. With
three steps of redundancy to make sure that all the data will be uploaded, we feel
confident that all data will be uploaded in the vast majority of cases. If for some
unknown reason the data can’t be uploaded then at least all the data will be stored locally
on the PDA. So there is virtually no way that any data will be lost, barring some
unforeseeable catastrophe.
38
8
Recommendations For Future Work
For future work there are two major areas to be modified, system testing and web
server control. System testing would encompass handing our program to the operators,
namely the nurses, and letting them use the system. Since these will be the people using
our device and they have little technical training, they will undoubtedly find errors that
we couldn’t even imagine. Once the nurses find errors in our program then it would be
up to the group taking over our project to determine the cause of the error, and then
implement a solution. Since our program is fairly large, trying to track down the problem
would take a fair amount of time. Then the implementation will need to be tested to
ensure that the fix didn’t affect any other portion of the program. Since we have tested
our program we don’t expect there to be an egregious amount of errors, we do recognize
the fact that in any software project of this size their will undoubtedly be errors. So the
amount of time to fix our program should be minimal, but it still needs to be done.
The major part of this project that could be implemented would be to add web
server control. The concept of web sever control is very simple, what the group would
need to do was implement all the controls that are running on the PDA on the web server
workstation. From the workstation the user would be able to setup and run the
experiment without ever leaving their workstation. To accomplish this level of control
the group would have to port our entire interface from the PDA to the desktop. Then a
program would have to be written on the PDA to receive commands via the PHP
webpage, essentially modifying our existing IEEE 802.11b communication program.
Then they would have to write code for the PDA to analyze what the command given
was, use our Bluetooth communication VI to perform the action, and then use our IEEE
802.11b program to submit the data. Essentially the group implementing this future
functionality would need to modify a lot of our existing code to fit a new purpose. By
adding this web server control functionality would allow all the studies to be controlled
by a single person, instead of by multiple nurses. So that way a single expert will always
be in control as opposed to untrained nurses.
39