DESIGN AND DEVELOPMENT OF A BREATH-BY-
`
`BREATH ANALYSIS SYSTEM FOR
`
`USE AT LOW ALTITUDES
`
`By
`
`CHARLES T. PATTERSON
`
`Bachelor of Science in Electrical Engineering
`
`Stillwater, Oklahoma
`
`1993
`
`Submitted to the Faculty of the
`Graduate College of
`Oklahoma State University
`in partial fulfullment of
`the requirements for
`the Degree of
`MASTER OF SCIENCE
`December, 1996
`
`APPLE 1122
`Apple v. Logan Tree
`IPR2022-00037
`
`1
`
`

`

`DESIGN AND DEVELOPMENT OF A BREATH-BY-
`
`BREATH ANALYSIS SYSTEM FOR
`
`USE AT LOW ALTITUDES
`
`Thesis Approved:
`
`,- . ~\.
`
`\
`
`Dean of Graduate College
`
`11
`
`2
`
`

`

`PREFACE
`
`I found designing and developing a breath-by-breath analysis system to be very
`
`rewarding. The challenges and triumphs I experienced, will help me throughout my
`
`engineering career. I received a great deal of help on this project and would like to thank
`
`all of the people who helped make this project possible.
`
`First, I would like to thank the Federal Aviation Association for funding this
`
`project and making the facilities available for its development. A big thanks is given to
`
`Bob Garner, the team leader of the project, for his support, advice, and the opportunity he
`
`gave me to work on this project. lowe a deep gratitude to Frontier Engineering, my
`
`current employer, and Scott Phillips, my manager, for permitting me to use Frontier's
`
`facilities for this project and for tolerating my hectic schedule so that I could complete this
`
`last step of my Masters.
`
`I would also like to thank the members of my advisory committee, Dr. Louis
`
`Johnson, Dr. George Scheets, and Dr. Ramakumar. A special thank you is extended to
`
`Dr. Louis Johnson for his guidance and patience during this project and previous
`
`semesters.
`
`My parents, Tom and Marsha Patterson, deserve the greatest thanks of all, without
`
`their love and support I never could have reached this far.
`
`ill
`
`3
`
`

`

`TABLE OF CONTENTS
`
`Figure
`
`Page
`
`I. INTRODUCTION .......... ........................................................................................ 1
`
`Purpose and Motivation ........................................................................................ 1
`
`Overview of Procedure ......................................................................................... 3
`
`II. BACKGROUND ............................................................................................... .. ... 4
`
`Review of Apparatus ............................................................................................ 4
`
`InhalelExhale Flow ...... ........ ..... ...... ...... ... ................................................. 6
`
`Gas Composition of Breaths ................................................... ................... 7
`
`Pressure .................................................................................................... 8
`
`Temperature ........................ ... .... .... .......................................................... 8
`
`Relative Humidity ..................................................................................... 8
`
`Data Acquisition ............... ....... ..... ............................................................ 8
`
`Computer System ..................................................................................... 9
`
`Selection of Software Development Tool.. ............................ ............. ................. 10
`
`Introduction to Graphical Programming .............................................. .... 10
`
`Introduction to Lab VIEW ................................................................... .. .. 11
`
`Benefits of Using LabVIEW .................................................................... 11
`
`III. DESIGN AND DEVELOPMENT ........................................................................ 14
`
`Operation in Simulated Mode ...................... ................................ ................ ...... . 14
`
`Acquiring Data at Desired Rate .......................................................................... 16
`
`Error Handling ..................................... ..... ........................................ .. .... ..... ... ... 18
`
`Calibration .......................................................................................................... 19
`
`IV
`
`4
`
`

`

`Circular Buffering of Data .................................................................................. 21
`
`Circular Buffer wi 2D Data Write.vi ..................................................... ... 21
`
`Convert Circular Index into Linear One. vi ............................................... 23
`
`Convert Linear Index into Circular One. vi ............................................... 24
`
`Find Signal Index and Channel. vi ............................................................ 24
`
`Recognition of Flow SignaL ................................................................................ 24
`
`Find Inhale.vi .......................................................................................... 25
`
`Find Exhale.vi ......................................................................................... 27
`
`Adjusting for Drifting Baseline ................................................................ 27
`
`Recognition of InhalelExhale Gas Fraction Signals ..................... ... ..................... 28
`
`Aligning Signals .................................................................................................. 28
`
`Processing Breath Data ..................................................... ................................. 30
`
`Displaying Data ......................................................... ......................................... 35
`
`Troubleshooting Display ......................................................................... 35
`
`Main Display ........................................................................................... 36
`
`IV. CONCLUSIONS ......................................................................................... ......... 38
`
`Verification of Program Results .......................................................................... 39
`
`Future Work ....................................................................... .. .............................. 40
`
`BIBLIOGRAPHy .................. .... ............................... ..................................................... 41
`
`APPENDIX A - CODE LISTING .................................................................................. 42
`
`v
`
`5
`
`

`

`LIST OF TABLES
`
`Figure
`
`Page
`
`I. Linear Conversion Factors .................................................................................... 32
`
`II. Curvilinear Coefficients ......................................................................................... 32
`
`T ABLE OF FIGURES
`
`Figure
`
`Page
`
`1. Schematic of instrumentation .................................................................................. 5
`
`2. Schematic of pneumotachograph ............................................................................. 7
`
`3. PC-Based Test Market Insight Study .................................................................... 12
`
`4. Example VI for buffered data acquisition .............................................................. 17
`
`5. Pneumotachograph calibration setup ..................................................................... 20
`
`6. Circular buffer VI input/output definitions ............................................................. 21
`
`7. Example of circular buffer initialization ................................................................. 22
`
`8. Example of circular buffer write ............................................................................ 23
`
`9. Double threshold detection ................................................................................... 26
`
`VI
`
`6
`
`

`

`CHAPTER I
`
`INTRODUCTION
`
`This project encompasses the acquisition and analysis of human gas exchange at
`
`different altitudes for the purpose of analyzing metabolic responses and breathing kinetics
`
`during acute exposure to altitude. All work has been performed in conjunction with the
`
`Environmental Physiology Research team within the Protection and Survival Laboratory.
`
`These facilities are located at the Federal Aviation Association's Mike Monroney
`
`Aeronautical Center in Oklahoma City, Oklahoma. This thesis describes the depth and
`
`scope of the electrical and software engineering aspects of performing and displaying
`
`breath-by-breath analysis in real-time at altitude.
`
`Purpose and Motivation
`
`The primary reason for developing this system is that current systems that perform
`
`breath analysis provide a canned solution that is not modifiable. These systems are
`
`limiting in that they do not permit the scientist to control the methods used to process the
`
`breathing data, and they do not permit additional signals to be monitored and stored along
`
`with the breathing data. This system was designed in a manner that is easily modifiable
`
`and that allows additional variables, specifically altitude, to be accounted for in processing
`
`the breathing data. In addition this newly developed system provides the user with the
`
`ability to modify the manner in which the data is displayed and logged.
`
`1
`
`7
`
`

`

`Past attempts at collecting breath-by-breath analysis have been developed, but
`
`assumptions were made which caused results to be accurate only over a group of breaths.
`
`In addition, the assumptions made about gas exchange in the lungs precluded these studies
`
`from being performed at altitude.
`
`With the data acquisition and software products available today and the high
`
`processing speeds of the current computer technologies more data can be collected so that
`
`more accurate results can be obtained at different altitudes.
`
`Although the readily available technology has reduced development time from past
`
`attempts at this type of study, the same obstacles are ever present. Finding a reliable and
`
`efficient form of calibration of the equipment is an ongoing challenge with new ideas and
`
`improvements surfacing every step of the way. Another formidable task was aligning the
`
`data collected from different sources such that calculations could be performed and results
`
`displayed on a breath-by-breath basis.
`
`Since most of the apparatus described in this project was already present, the
`
`primary topic of this thesis is the software program written to perform the data acquisition
`
`and display of data. The use of a graphical programming language specifically designed
`
`for instrumentation and data acquisition dramatically reduced the development cycle of
`
`this project and will be described in detail. Graphical programming and other innovative
`
`techniques and solutions will be covered in the body of this thesis.
`
`2
`
`8
`
`

`

`Overview of Procedure
`
`Breath by breath measurement of gas exchange consists of the following
`
`quantities: inhale and exhale volumes, gas composition of inhale and exhale volumes,
`
`pressure, temperature, and relative humidity. The flow samples are integrated to calculate
`
`the inspired and expired volumes of Oxygen (02 ), Carbon Dioxide (C02), Nitrogen (N 2),
`
`Argon (A), and Water (H20). Atmospheric conditions such as temperature, pressure, and
`
`relative humidity of the air are used in calculations to normalize volumes to a standard
`
`atmospheric condition of air referred to as Standard Temperature and Pressure Dry
`
`(STPD), and to a standard condition of bodily measurement termed Body Temperature
`
`Pressure Saturated with water (BTPS). Cardiopulmonary measurements are used to
`
`determine the physical activity of the subject during the test.
`
`3
`
`9
`
`

`

`CHAPTER II
`
`BACKGROUND
`
`The Mike Monroney Areonautical Center houses an altitude chamber which was
`
`very well equipped for this project. Prior to the software development, the hardware
`
`required to perform breath-by-breath analysis had already been assembled by Bob Garner.
`
`This section addresses the existing hardware and the software tools selected for the
`
`development.
`
`Review of Apparatus
`
`The physical apparatus required for breath-by-breath analysis included a pentium(cid:173)
`
`based personal computer; a data acquisition card; a breathing tube; a two-way breathing
`
`valve; and several specialized instruments to collect inhale and exhale flow, gas
`
`composition of the air, temperature, relative humidity, and pressure. All of the
`
`instruments involved produced voltages to represent the physical quantity being measured
`
`and these voltages were wired directly to the data acquisition card housed in the
`
`computer. Since many of the instruments either had probes or tubes that need to be
`
`hooked up within the altitude chamber, the associated wires and tubes were fed into the
`
`chamber through access ports which were sealed with clay during operation at altitude.
`
`Figure 1 provides a system-level schematic of the apparatus. The folowing sections
`
`describe each of the necessary devices.
`
`4
`
`10
`
`

`

`Inhaled
`air
`
`Triple-screen
`pneumotachographs
`
`Mouthpiece
`
`Signal(cid:173)
`demodulator
`IAmplifier
`
`Signal(cid:173)
`demodulator
`IAmplifier
`
`Pentium(cid:173)
`based
`PC
`
`l2-bit
`A toD
`converter
`
`Mass
`spectrometer
`
`A
`
`Digital
`thermometer
`
`Relative
`humidity meter
`
`Pressure
`Transducer
`
`Figure 1: Schematic of instrumentation
`
`5
`
`11
`
`

`

`InhalelExhale Flow
`
`The inhale and exhale flow signals were measured using pneumotachographs.
`
`Pneumotachographs are devices that measure airflow against a fixed resistance and may be
`
`found in respirometers, mechanical ventilators, incentive breathing devices, diagnostic
`
`spirometers, and other pulmonary function testing instruments. Although several designs
`
`exist, a triple screen type pneumotachograph made by Hans Rudolph, Incorporated, was
`
`selected for this system. This design was selected because it has slightly better frequency
`
`response, less dead space, and is easier to disassemble for cleaning than other designs.
`
`The device consists of an air flow tube, three metal screens with mesh sizes of 400
`
`wires per inch, a heating element, two pressure tubes, and a differential pressure
`
`transducer (see figure 2). The heating element heats the metal screens to prevent water
`
`condensation on the screens. The three screens form two chambers and pressure tubes
`
`from each chamber are connected to a differential pressure transducer. A signal
`
`demodulator and amplifier are connected to the differential pressure transducer in order to
`
`convert the signal into a voltage linearly dependent on the flow.
`
`6
`
`12
`
`

`

`flow - - - .....
`
`Air
`
`3 Metal
`screens
`
`Pressure
`tubes
`
`Differential
`pressure
`transducer
`
`Flow
`signal
`
`To signal
`demodulator/
`amplifier
`
`Figure 2: Schematic of pneumotachograph
`
`Two triple screen pneumotachographs were used to measure the flow signals
`
`needed for this system. One was placed on the input side of the two-way breathing valve,
`
`for inhale flow, and the other was placed on the output side of the valve, for exhale flow.
`
`Gas Composition of Breaths
`
`A thin capillary tube carries a small sample of air from the breathing mask to a
`
`device called a mass spectrometer where the gas composition is determined. The mass
`
`spectrometer continuously samples the air carried through the tube and determines the
`
`fractions of O2 , CO2 , Nz, A, and H20. Each gas fraction has a corresponding voltage
`
`output which is proportional to the reading.
`
`7
`
`13
`
`

`

`Pressure
`
`The altitude chamber located on the Mike Monroney Aeronautical Center
`
`simulates different altitudes by controlling the air-pressure inside the chamber. The
`
`relationship between air-pressure and altitude is relatively linear, and thus a simulated
`
`altitude can be determined from an air-pressure reading. Several pressure gauges are
`
`present in the chamber, but in order to make this reading automatically, an Omega brand
`
`pressure transducer was placed in the chamber and connected to the data acquisition card.
`
`Temperature
`
`Two different thermometers are used to acquire the temperature readings
`
`necessary for breath-by-breath analysis. An Omega 871A digital thermometer measures
`
`the temperature of the air being breathed in and out, while a Hewlett Packard thermometer
`
`measures the ambient temperature of the chamber.
`
`Relative Humidity
`
`An Omega Relative Humidity meter (DP 205-E) performed the relative humidity
`
`measurements for the system. The voltage output from this device was wired directly to
`
`the data acquisistion card.
`
`Data Acquisition
`
`All of the instmments needed for this system are wired into a National Instmments
`
`data acquisition card, the AT-MIO-64F-5. This card's selection was based on the
`
`8
`
`14
`
`

`

`following criteria: it is capable of a fast sample rate, in case higher frequency signals are
`
`added to the analysis; it contains plenty of channels for single-ended or differential
`
`measuements; and it is easy to interface with the selected software language.
`
`The AT-MIO-64F-5 performs a 12-bit analog-to-digital conversion on the present
`
`voltage signals, can sample up to 1000 samples a second per channel, and provides 64
`
`single-ended AID channels where pairs of these channels may be used to perform
`
`differential measurements. The pneumotachograph signal is wired into a signal
`
`conditioner which provides a single ended output with a common ground with the data
`
`acquisition board. In order to reduce signal noise introduced by long cabling, the mass
`
`spectrometer, pressure transducer, relative humidity, and temperature signals are all
`
`connected in differential mode. All signals present on this board range from 0 to 10 volts.
`
`The signals are sampled simultaneously at 200 Hz and are buffered to the computer's
`
`memory using a Direct Memory Access (DMA) channel.
`
`Computer System
`
`A Pentium-based personal computer with a 166 Mega Hertz processor, 64 Mega
`
`bytes of Random Access Memory (RAM), and a two Giga-byte hard-drive was selected
`
`for the acquisition system so that plenty of processing speed and storage room were
`
`available. Microsoft Windows 95 was selected as the operating system to take advantage
`
`of 32-bit processing and the plug-n-play technology existing in the hardware add-in cards
`
`selected for this and future projects.
`
`9
`
`15
`
`

`

`Selection of Software Development Tool
`
`Choosing a good software development tool for this system proved to be critical
`
`to the project's successful completion. This section addresses the decision to use the
`
`graphical programming language known as Lab VIEW as opposed to a text based language
`
`like C, Basic, or FORTRAN.
`
`Introduction to Graphical Programming
`
`Graphicalprogramrning is a relatively new type of programming language which
`
`dramatically reduces software development time. This is possible through the use of
`
`diagrammatic symbols rather than syntax-intensive text-based command sets. A paradigm
`
`shift is required when learning this new form of programming, but the learning curve is
`
`considerably less steep than those for other text based languages such as C, Basic, and
`
`FORTRAN. Many engineers prefer to think in diagrams and visual images rather than
`
`words so this new language seems to be a natural choice.
`
`In the beginning phase of any software development, block diagrams and flow
`
`charts are used to represent the structure and design of a program, and a well designed
`
`graphical language permits the program to simply become an expanded flow chart. The
`
`key advantage of graphical programming is that commands and operations are represented
`
`by icons which are easier to remember than a set of text commands.
`
`10
`
`16
`
`

`

`Introduction to Lab VIEW
`
`National Instruments developed one of the first graphical programming languages
`
`called LabVIEW. LabVIEW was originally developed as a tool to support
`
`instrumentation in an effort to make interfacing with hardware a simpler task, but now
`
`after a number of revisions, Lab VIEW has evolved into a robust language comparable to
`
`the graphical equivalent of C. Lab VIEW has replaced the complex driver sets required for
`
`instrumentation with icons that could be wired together to direct data flow.
`
`The Lab VIEW User Manual states, "Lab VIEW programs are called virtual
`
`instruments because their appearance and operation imitate actual instruments," but in
`
`most cases the finished product goes far beyond the instrument level. Virtual Instruments,
`
`(from here on referred to as VIs) are comprised of afront panel that provides an
`
`interactive user interface with knobs, push buttons, graphs and other controls and
`
`indicators, and a block diagram that acts as the source code constructed by wiring icons
`
`together. VIs can be broken down into sub-programs called sub-VIs. Sub-VIs are
`
`represented as icons in the block diagram and can be passed data and return data through
`
`connectors created on the sub-VI' s icon.
`
`Benefits of Using Lab VIEW
`
`A survey performed last year showed that Lab VIEW's usage among Test
`
`Equipment Developers using PCs has surpassed BASIC and is rapidly gaining on C and
`
`C++. (Test & Measurement World, September 1995)
`
`11
`
`17
`
`

`

`Software Currently Used
`
`c++
`
`C
`
`LabVIEW
`
`Basic
`
`LabWindows
`
`Vendor X
`
`0%
`
`10%
`
`20%
`
`30%
`
`40%
`
`50%
`
`60%
`
`(%of respondents)
`
`Figure 3: 1995 PC-Based Test Market Insight Study
`
`This trend can be attributed to the many benefits of using Lab VIEW. Development times
`
`associated with Lab VIEW are simply smaller. The graphical user interface is built in, and
`
`is simple to modify for a great number of displays and controls. Lab VIEW is a real
`
`programming language and has few intrinsic limitations. Lab VIEW provides convenient
`
`VI libraries for performing many high-level operations. The debugging tools provided
`
`with Lab VIEW permit the user to watch the data flow at all levels. Complex problems
`
`can be prototyped in a very short amount of time, and the hideous syntax errors which
`
`many programmers find so frustrating have been eliminated. The learning curve for
`
`becoming a proficient Lab VIEW programmer is not steep, because of the many examples
`
`provided and the tutorial. Memorizing syntax and a list of commands is not necessary
`
`because everything is visual and is provided at the fingertips of the programmer. Overall,
`
`the most commonly heard reason for choosing Lab VIEW is that it is fun to use.
`
`12
`
`18
`
`

`

`As with any programming language, Lab VIEW does have its drawbacks. The
`
`software package is priced at about three times higher than most full blown C
`
`development packages, but the reduction in development time makes it well worth it. Due
`
`to the fact that the language is graphical, there are some performance limitations in that
`
`the processing speeds are a little slower than programs written in C. These limitations can
`
`mostly be attributed to the graphical user interface. Lab VIEW is a one vendor product so
`
`thus far there is no ANSI standard, however Lab VIEW has been accepted by the
`
`Department of Defense (DoD) for many automatic test equipment designs. This is due in
`
`part to the paper "Diagrammatic-Graphical Programming Languages and DoD STD-
`
`2167 A" written by two engineers at Frontier Engineering, Steve Bragg and Carl Driskill.
`
`The paper establishes processes for developing programs with Graphical Languages and
`
`making those developments meet standards written when text-based languages were the
`
`only ones in existence. DoD STD-2167A was the all encompassing software development
`
`standard for military products and has sub-sequently been replaced with a similar standard.
`
`13
`
`19
`
`

`

`CHAPTER III
`
`DESIGN AND DEVELOPMENT
`
`The software program for this project was developed using an iterative
`
`prototyping technique where individual quantities were measured and tested for accuracy.
`
`After measuring each quantity successfully, the prototype was incorporated into the
`
`overall system. The following paragraphs discuss the key areas of interest in designing
`
`and developing this software application.
`
`This program was designed in a modular fashion such that individual parts could
`
`be tested as they were developed. All setup parameters and constants are stored in a
`
`global variable VI. Two other global variables VIs are used to update the main display
`
`and a troubleshooting display. The main user interface is menu-based and permits the
`
`operator to modify setup parametes and necessary file locations. The operator may also
`
`begin a calibration and a test from this menu. After the system is configured, all
`
`acquisition and processing takes place within a calibration loop and then a main test loop.
`
`Operation in Simulated Mode
`
`Since testing the code often involves troubleshooting, it is a good practice to leave
`
`print statements or indicators in the code and control them with a global Boolean variable
`
`or compile flag. Setting this variable true enables the troubleshooting statements or
`
`displays. In addition to simple displays and indicators, support of a simulated mode may
`
`expedite the troubleshooting process. A simulation mode permits a large portion of the
`
`14
`
`20
`
`

`

`code proofing and troubleshooting to be performed on a development station rather than
`
`requiring the entire system by mimicking hardware or apparatus dependent interfaces with
`
`a simulated data file. Values in the simulated data file may be changed to meet the various
`
`test cases. Turning on the simulated mode simply requires setting a global variable or
`
`compile flag true.
`
`The apparatus for this project resides on a government facility with limited access
`
`therefore much of the development was performed away from the hardware. In order to
`
`eliminate the hardware dependency from the development stage of this project, a
`
`simulated mode was developed. The first step was to create a VI that simply collected
`
`raw data for all the channels at the desired rate and saved the data to a spreadsheet file.
`
`Subsystems for the program were designed by using the associated channels of data, or
`
`columns of data. Once a concept for the data processing had been proved with the data
`
`file, the process was converted to operate in a real-time mode.
`
`When attempting to develop a simulated mode a VI was created to operate in a
`
`manner that duplicates this buffered acquisition, but the data is acquired from a file rather
`
`than a data acquisition board. The VI designed to accomplish this uses the number of
`
`scans to read at a time to determine how many points in the file to read for each iteration
`
`of the main loop. To run the program in a simulated mode the user must only set a
`
`simulation flag to true and specify the calibration data and the test data files to be used for
`
`the simulation.
`
`15
`
`21
`
`

`

`Acquiring Data at Desired Rate
`
`A majority of the signals needed to perform breath-by-breath analysis must be
`
`collected at a rate of at least 200 samples per second while the rest must be collected at
`
`least once per breath (approximately once every 3-5 seconds). The fastest observed rise
`
`times of flow and mass spectrometer signals were on the order of 20 milliseconds, this
`
`translates into a frequency of 50 Hz. The selected sample rate is four times this highest
`
`anticipated frequency, so the Sampling Theorem is satisfied. The AT-MIO-64F-5 is
`
`capable of sampling data at well above 200 Hz and buffering data to a circular buffer
`
`automatically through a DMA channel. This buffered data can be accessed while still
`
`collecting new samples. The blocks of data are transferred from the buffer by an Acquire
`
`Data Routine which loads the data into a second circular buffer for processing. The
`
`second circular buffer was created in Lab VIEW and will be discussed later in this thesis.
`
`The VI designed for collecting raw data was based on an example VI provided
`
`with LabVIEW shown in Figure 4. This VI uses AI Config.vi to set up a circular buffer in
`
`memory where the AT-MIO-64F-5 board can dump data and configures the data
`
`acquisition with the following parameters: device to scan (which data acquisition board if
`
`multiple boards exist), input high and low limits for each channel, channels to scan, and
`
`buffer size. AI Config. vi configures the data acquisition and assigns a task ID that other
`
`VIs use to access the associated resources.
`
`16
`
`22
`
`

`

`Read & chart data until an error occurs, or the stop button pressed.
`
`transposed
`waveform
`chart
`
`l [sGt.] !
`
`scan rate
`(1000 scanslsec)
`
`scans to read
`at a time (1 000)
`
`Figure 4: Example VI for buffered data acquisition
`
`In this example, the acquisition is started with a call to AI Start.vi and passing this
`
`VI the task ID, the mode of operation (continuous acquisition in this case), and the
`
`desired scan rate. Once the acquisition is started a loop continually grabs blocks of data
`
`from the circular buffer by calling AI Read. vi and passing it the task ID and the number of
`
`scans to read during the current iteration. The number of samples read may differ from
`
`iteration to iteration depending on the backlog in the buffer. If processing or displaying
`
`the data takes longer than it does to access the desired number of samples then a backlog
`
`will be present in the buffer and on the next iteration the number of points to read will be
`
`the larger of the backlog and the number of points specified. After a block of data is
`
`accessed from the circular buffer the data is passed to a dummy VI (look for MY DATA
`
`PROC in figure 4) where any processing may be performed.
`
`17
`
`23
`
`

`

`To create a VI to store raw data, a VI to store data to a spreadsheet file is
`
`substituted for the dummy VI. The loop continues to collect data and only stops iterating
`
`when the operator presses a stop button located on the front panel or if a critical error is
`
`encountered. After the loop stops executing, AI Clear. vi is called and passed the task ID
`
`to stop the data acquisition and release the associated resources.
`
`Accessing the data in this fashion provides a pseudo real-time acquisition where
`
`data can be acquired continuously even if process times differ from iteration to iteration.
`
`It is especially important to keep this in mind when considering the overall system where
`
`breaths are processed after they have been detected. The time necessary for processing a
`
`breath is far greater than that required to perform the detection since the detection only
`
`considers one block of data from one channel. For this reason this VI was also used as the
`
`foundation for the complete breath-by-breath system. The VI used to write data to a file
`
`was later replaced with the logic to detect a breath and then process and display the results
`
`after detection.
`
`Error Handling
`
`The example VI also provides a convenient demonstration of the error handling
`
`scheme implemented in the final system. An error cluster made up of status, a Boolean
`
`variable indicating whether an error was encountered; code, an integer variable containing
`
`the error code associated with the encountered error, and source, a string variable
`
`specifying the VI where the error was encountered and the call chain for this VI. The
`
`error cluster is passed from one VI to the next as they are called in succession. If a VI
`
`18
`
`24
`
`

`

`encounters an error the VI updates the cluster to notify all successive VIs of this
`
`condition. If the error is critical, successive VIs will not execute and the error will
`
`eventually be passed to the error handler where the error is reported to the operator. The
`
`AI Clear. vi operates regardless of an error condition, so that the card can be reinitialized.
`
`Calibration
`
`All of the instruments involved in this project need only be calibrated once every
`
`few months, except for the pneumotachographs. The pneumotachographs must be
`
`calibrated before every test run because the carrier demodulator's zero and gain tend to
`
`drift between tests. For this reason, the calibration was incorporated into the main test
`
`program.
`
`Several papers address the complexity of calibrating pneumotachographs, but the
`
`approach used in this development proves to be relatively simple and quick. Calibrating
`
`the pneumotachograph requires the determination of four factors: offset voltage for
`
`inhale, offset voltage for exhale, inhale voltage to flow conversion factor, and exhale
`
`voltage to flow conversion factor. Determining the offset merely requires that the signal
`
`be read with zero flow, but the scale factors must be determined by measuring known
`
`volumes.
`
`A calibrated syinge