1.

INTRODUCTION
Using computers to perform circuit simulation is very common in both universities and industry. These computer simulations usually involve entering a data file from the keyboard into the computer and having it calculate results on predefined parameters. These simulations have proven very useful for saving both time and money, but have limitations in not analyzing data in real time and not being able to operate indefinitely. Circuit emulation is a simple variation on the theme of simulation where the computer system operates in real time receiving data continually, processing it as if the computer is an instrument, and outputting results immediately. These emulation systems are sometimes referred to as virtual instruments so as to avoid confusion between the words simulation and emulation. This paper presents examples of how virtual instruments can be created using object-oriented programming and applied to Biomedical Instrumentation systems. A course using these concepts has been taught at California State Polytechnic University, Pomona (Cal Poly Pomona).

The need for electronic instrumentation in the medical field(5W has been expanding at a rapid pace. Hospitals, laboratories, and physician offices are all becoming dependent upon fast high quality data from electronic instruments in the treatment of patients. This data may be basic raw data or may be interpreted results. Much of the data needed for interpretations are measurements of basic electronic parameters such as voltage, current, frequency, and resistance. Measurement of these parameters is well within the capability of undergraduate engineering students. Cal Poly Pomona has an undergraduate program in biomedical instrumentation first started in 1972. This program has attempted to stay current with the needs of students and industry. The examples presented here are a result of our latest updating of that program. The biomedical instrumentation program at Cal Poly Pomona is made up of three components: The Instrumentation, Simulation, and Control(7) (ISC) Laboratory (the most recent), The Physiology Minor (a university wide minor), and the Biomedical Instrumentation course.

AIET/DOAEI/2011-12/SP/01

2. SIMULATION AND EMULATION

Simulation is the imitation of the operation of a real-world process or system over time. The act of simulating something first requires that a model be developed; this model represents the key characteristics or behaviors of the selected physical or abstract system or process. The model represents the system itself, whereas the simulation represents the operation of the system over time. Simulation is used in many contexts, such as simulation of technology for performance optimization, safety engineering, testing, training, education, and video games. Training simulators include flight simulators for training aircraft pilots to provide them with a lifelike experience. Simulation is also used with scientific modelling of natural systems or human systems to gain insight into their functioning. Simulation can be used to show the eventual real effects of alternative conditions and courses of action. Simulation is also used when the real system cannot be engaged, because it may not be accessible, or it may be dangerous or unacceptable to engage, or it is being designed but not yet built, or it may simply not exist. Key issues in simulation include acquisition of valid source information about the relevant selection of key characteristics and behaviors, the use of simplifying approximations and assumptions within the simulation, and fidelity and validity of the simulation outcomes.

Emulation refers to the ability of a computer program in an electronic device to emulate (imitate) another program or device. Many printers, for example, are designed to emulate Hewlett-Packard LaserJet printers because so much software is written for HP printers. If a non-HP printer emulates an HP printer, any software written for a real HP printer will also run in the non-HP printer emulation and produce equivalent printing. A hardware emulator is an emulator which takes the form of a hardware device. Examples include the DOS-compatible card installed in some old-world Macintoshes like Centris 610 or Performa 630 that allowed them to run PC programs and FPGA-based hardware emulators. In a theoretical sense, the Church-Turing thesis implies that any operating environment can be emulated within any other. However, in practice, it can be quite difficult, particularly when the exact behavior of the system to be emulated is not documented and has to be

AIET/DOAEI/2011-12/SP/02

deduced through reverse engineering. It also says nothing about timing constraints; if the emulator does not perform as quickly as the original hardware, the emulated software may run much more slowly than it would have on the original hardware, possibly triggering time interrupts that alter performance.

Figure2.1: showing carrying out body measurements

AIET/DOAEI/2011-12/SP/03

3. BIOMEDICAL INSTRUMENTS: AN INTRODUCTION

Instrumentation is defined as the art and science of measurement and control of process variables within a production, or manufacturing area. An instrument is a device that measures and/or regulates physical quantity/process variables such as flow, temperature, level, or pressure. Instruments include many varied contrivances that can be as simple as valves and transmitters, and as complex as analyzers. Instruments often comprise control systems of varied processes such as refineries, factories, and vehicles. The control of processes is one of the main branches of applied instrumentation. Instrumentation can also refer to handheld devices that measure some desired variable. Diverse handheld instrumentation is common in laboratories, but can be found in the household as well. For example, a smoke detector is a common instrument found in most western homes. Output instrumentation includes devices such as solenoids, valves, regulators, circuit breakers, and relays. These devices control a desired output variable, and provide either remote or automated control capabilities. These are often referred to as final control elements when controlled remotely or by a control system. Transmitters are devices that produce an output signal, often in the form of a 4 20 mA electrical current signal, although many other options using

voltage, frequency, pressure, or ethernet are possible. This signal can be used for informational purposes, or it can be sent to a PLC, DCS, SCADA system, Lab View or other type of computerized controller, where it can be interpreted into readable values and used to control other devices and processes in the system. Control Instrumentation plays a significant role in both gathering information from the field and changing the field parameters, and as such are a key part of control loops.

AIET/DOAEI/2011-12/SP/04

Figure3.1: showing high-tech biomedical measurements and operations

3.1 Biomedical Instruments

It deals with wide spectrum of Life sciences i.e. plants, animals, Insects or in nutshell all living organisms. Study of only human being out of these is Called Medical Science. If we want to study Engineering principles in medical science the resulting subject will be Medical Engineering. If we wish to cover more animals on the earth, the science will be Bio- Medical Engineering. Engineering or Instrumentation is defined as science of using measurements. The study of Engineering principles from Biomedical Engineering involves following interests: To understand mechanisms, efficiencies & physical changes of various subsystems of the body. To evolve an instrumentation system for diagnosis, therapy and supplementation of body function.

AIET/DOAEI/2011-12/SP/05

To obtain qualitative & quantitative knowledge through different instruments which can help for analysis of disorders, and further the Biomechanics of the cure process.

Figure 3.2: showing body ph measurement through portable device

Engineering Classification of Biomedical Instrumentation 1. 2. 3. 4. 5. 6. 7. 8. 9. Measuring Instruments Audiometer Blood cell counter Blood Pressure meter Blood PH meter Blood flow meter Digital BP meter GSR meter Stethoscope

AIET/DOAEI/2011-12/SP/06

3.2 Biomedical instruments bifurcation

The Biomedical Instrumentation course is structured into four parts:

(1) Living systems: the structure and function of the major body systems (2) Transducers: the patient instrument interface (3) Signal processing: LabVIEW and instrument emulation; (The use of LabVIEW and ISC lab is a major change) (4) The user: the instrument-user interface

1. Living systems It has three major sections: (a) An overview of major body systems in terms of structure, function, and measurable parameters (e.g. Muscular system - muscle cell structure - relationship between skeletal and nervous systems - movement reflex). (b) An overview of current measurement techniques and instruments (e.g. electrical and mechanical - electromyograph and reflexometer). (c) A more detailed discussion on the Cardiovascular (blood pressure = heart rate x cardiac output), Respiratory (Volume 8 BTPS =[volume collected 8 T "C] x [273+37/273+T] x [PB P H ~ O/P B - 47]), and Sensory systems (eyes and ears optical sound pressure characteristics).

2. Transducers The patient-instrument interface is divided into three basic sections. (a) An overview of major transducer types as related to the above measurable parameters (e.g. strain gauges and electrodes). (b) Patient-transducer interface (mechanical, electrical, and chemical). (c) Safety and device regulations.

AIET/DOAEI/2011-12/SP/07

3. Signal processing With the advent of software like LabVIEW by National Instruments (NI) it has become possible to design and emulate actual instruments from input terminals to output display with a PC type computer. This part of the course is divided into three major sections: (a) An overview of basic medical signal processing techniques and requirements (e.g. response times, units, and noise reduction), (b) An introduction to Lab VIEW and virtual instruments (VI's), (c) VI development and applications.

4. The user The instrument-user interface, the final part of the course, has three major parts. (a) An overview of user interface requirements (e.g. user operating requirements, maintenance requirements, and operating environment).

(b) Use of VI's to develop better user interfaces (a new innovation not previously possible). (c) Self-test and calibration requirements.

AIET/DOAEI/2011-12/SP/08

4. OBJECT ORIENTED PROGRAMMING

Object-oriented programming (OOP) is a programming paradigm using "objects" data structures consisting of data fields and methods together with their interactions to design applications and computer programs. Programming techniques may include features such as data abstraction, encapsulation, messaging, modularity, polymorphism, and inheritance. Many modern programming languages now support OOP, at least as an option. Simple, non-OOP programs may be one "long" list of statements (or commands). More complex programs will often group smaller sections of these statements

into functions or subroutines each of which might perform a particular task. With designs of this sort, it is common for some of the program's data to be 'global', i.e. accessible from any part of the program. As programs grow in size, allowing any function to modify any piece of data means that bugs can have wide-reaching effects. In contrast, the object-oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. Instead, the data is accessed by calling specially written functions, commonly called methods, which are either bundled in with the data or inherited from "class objects." These act as the intermediaries for retrieving or modifying the data they control. The programming construct that combines data with a set of methods for accessing and managing those data is called an object. The practice of using subroutines to examine or modify certain kinds of data, however, was also quite commonly used in non-OOP modular programming, well before the widespread use of object-oriented programming. An object-oriented program will usually contain different types of objects, each type corresponding to a particular kind of complex data to be managed or perhaps to a real-world object or concept such as a bank account, a hockey player, or a bulldozer. A program might well contain multiple copies of each type of object, one for each of the real-world objects the program is dealing with. For instance, there could be one bank account object for each realworld account at a particular bank. Each copy of the bank account object would be alike in the methods it offers for manipulating or reading its data, but the data inside each object would differ reflecting the different history of each account.

AIET/DOAEI/2011-12/SP/09

Figure 4.1: showing features of object oriented programming

Objects can be thought of as wrapping their data within a set of functions designed to ensure that the data are used appropriately, and to assist in that use. The object's methods will typically include checks and safeguards that are specific to the types of data the object contains. An object can also offer simple-to-use, standardized methods for performing particular operations on its data, while concealing the specifics of how those tasks are accomplished. In this way alterations can be made to the internal structure or methods of an object without requiring that the rest of the program be modified. This approach can also be used to offer standardized methods across different types of objects. As an example, several different types of objects might offer print methods. Each type of object might implement that print method in a different way, reflecting the different kinds of data each contains, but all the different print methods might be called in the same standardized manner from elsewhere in the program. These features become especially useful when more than one programmer is contributing code to a project or when the goal is to reuse code between projects. Object-oriented programming has roots that can be traced to the 1960s. As hardware and software became increasingly complex, manageability often became a concern. Researchers studied ways to maintain software quality and developed object-oriented programming in part to address common problems by strongly emphasizing discrete, reusable units of

AIET/DOAEI/2011-12/SP/010

programming logic. The technology focuses on data rather than processes, with programs composed of self-sufficient modules ("classes"), each instance of which ("objects") contains all the information needed to manipulate its own data structure ("members"). This is in contrast to the existing modular programming that had been dominant for many years that focused on the function of a module, rather than specifically the data, but equally provided for code reuse, and self-sufficient reusable units of programming logic,

enabling collaboration through the use of linked modules (subroutines). This more conventional approach, which still persists, tends to consider data and behavior separately. An object-oriented program may thus be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. In OOP, each object is capable of receiving messages, processing data, and sending messages to other objects. Each object can be viewed as an independent "machine" with a distinct role or responsibility. The actions (or "methods") on these objects are closely associated with the object. For example, OOP data structures tend to "carry their own operators around with them" (or at least "inherit" them from a similar object or class) - except when they have to be serialized. Now that there are new open architectures for building instruments and computers with powerful software tools, how efficient can you be in this new virtual instrumentation era? With the computer and virtual instrument revolutions changing technology so rapidly, how can the average user avoid being totally swamped when he or she puts together a new system? The answer is object-oriented software technology that packages everything a user needs to build virtual instruments and hardware into an integrated, user friendly environment. We are witnessing an industrial revolution that will see virtual instruments become a mainstream technology. Several environments are already recognized as the industry-standard for building virtual instruments. Future versions of many computer operating systems feature object-oriented architecture and file system in which modular applications all communicate using object linking and embedding language such as COBOL and write your own program, or you could hire someone to write the program for you. The spreadsheet was a major breakthrough because now anyone can use this framework for financial analysis. The main software utilized in the ISC Laboratory is LabVIEW.

AIET/DOAEI/2011-12/SP/011

5. LAB VIEW

LabVIEW (short for Laboratory Virtual Instrumentation Engineering Workbench) is a system design platform and development environment for a visual programming language from National Instruments. The graphical language is named "G" (not to be confused with G-code). Originally released for the Apple Macintosh in 1986, LabVIEW is commonly used for data

acquisition, instrument control, and industrial automation on a variety of platforms including Microsoft Windows, various versions of UNIX, Linux, and Mac OS X. The latest version of LabVIEW is version LabVIEW 2011, released in August 2011.

Figure 5.1: showing block diagram of power spectrum with labview LabVIEW ties the creation of user interfaces (called front panels) into the development cycle. LabVIEW programs/subroutines are called virtual instruments (VIs). Each VI has three

AIET/DOAEI/2011-12/SP/012

components: a block diagram, a front panel and a connector panel. The last is used to represent the VI in the block diagrams of other, calling VIs. Controls and indicators on the front panel allow an operator to input data into or extract data from a running virtual instrument. However, the front panel can also serve as a programmatic interface. Thus a virtual instrument can either be run as a program, with the front panel serving as a user interface, or, when dropped as a node onto the block diagram, the front panel defines the inputs and outputs for the given node through the connector panel. This implies each VI can be easily tested before being embedded as a subroutine into a larger program. The graphical approach also allows non-programmers to build programs by dragging and dropping virtual representations of lab equipment with which they are already familiar. The LabVIEW programming environment, with the included examples and documentation, makes it simple to create small applications. This is a benefit on one side, but there is also a certain danger of underestimating the expertise needed for high-quality G programming. For complex algorithms or large-scale code, it is important that the programmer possesses an extensive knowledge of the special LabVIEW syntax and the topology of its memory management. The most advanced LabVIEW development systems offer the possibility of building stand-alone applications. Furthermore, it is possible to create distributed applications, which communicate by a client/server scheme, and are therefore easier to implement due to the inherently parallel nature of G. The image above is an illustration of a simple LabVIEW program showing the dataflow source code in the form of the block diagram in the lower left frame and the input and output variables as graphical objects in the upper right frame. The two are the essential components of a LabVIEW program referred to as a Virtual Instrument.

5.1 Benefits of Lab View

Interfacing A key benefit of LabVIEW over other development environments is the extensive support for accessing instrumentation hardware. Drivers and abstraction layers for many different types of instruments and buses are included or are available for inclusion. These present themselves as graphical nodes. The abstraction layers offer standard software interfaces to communicate

AIET/DOAEI/2011-12/SP/013

with hardware devices. The provided driver interfaces save program development time. The sales pitch of National Instruments is, therefore, that even people with limited coding experience can write programs and deploy test solutions in a reduced time frame when compared to more conventional or competing systems. A new hardware driver topology (DAQmxBase), which consists mainly of G-coded components with only a few register calls through NI Measurement Hardware DDK (Driver Development Kit) functions, provides platform independent hardware access to numerous data acquisition and instrumentation devices. The DAQmxBase driver is available for LabVIEW on Windows, Mac OS X and Linux platforms. Although not a .NET language, LabVIEW also offers an interface to .NET Framework assemblies, which makes it possible to use, for instance, databases and XML files in automation projects.

Code compilation In terms of performance, LabVIEW includes a compiler that produces native code for the CPU platform. The graphical code is translated into executable machine code by interpreting the syntax and by compilation. The LabVIEW syntax is strictly enforced during the editing process and compiled into the executable machine code when requested to run or upon saving. In the latter case, the executable and the source code are merged into a single file. The executable runs with the help of the LabVIEW run-time engine, which contains some precompiled code to perform common tasks that are defined by the G language. The run-time engine reduces compile time and also provides a consistent interface to various operating systems, graphic systems, hardware components, etc. The run-time environment makes the code portable across platforms. Generally, LabVIEW code can be slower than equivalent compiled C code, although the differences often lie more with program optimization than inherent execution speed.

Large libraries Many libraries with a large number of functions for data acquisition, signal generation, mathematics, statistics, signal conditioning, analysis, etc., along with numerous graphical interface elements are provided in several LabVIEW package options. The number of advanced mathematic blocks for functions such as integration, filters, and other specialized

AIET/DOAEI/2011-12/SP/014

capabilities usually associated with data capture from hardware sensors is immense. In addition, LabVIEW includes a text-based programming component called MathScript with additional functionality for signal processing, analysis and mathematics. MathScript can be integrated with graphical programming using "script nodes" and uses a syntax that is generally compatible with MATLAB.

Code re-use The fully modular character of LabVIEW code allows code reuse without modifications: as long as the data types of input and output are consistent, two sub VIs are interchangeable. The LabVIEW Professional Development System allows creating stand-alone executables and the resultant executable can be distributed an unlimited number of times. The run-time engine and its libraries can be provided freely along with the executable. A benefit of the LabVIEW environment is the platform independent nature of the G code, which is (with the exception of a few platform-specific functions) portable between the different LabVIEW systems for different operating systems (Windows, Mac OS X and Linux). National Instruments is increasingly focusing on the capability of deploying LabVIEW code onto an increasing number of targets including devices like Phar Lap or VxWorks OS based LabVIEW Real-Time controllers, FPGAs, PocketPCs,

PDAs, Wireless sensor network nodes, and even Lego Mindstorms NXT.

Parallel Programming With LabVIEW it is very easy to program different tasks that are performed in parallel by means of multithreading. This is, for instance, easily done by drawing two or more parallel while loops. This is a great benefit for test system automation, where it is common practice to run processes like test sequencing, data recording, and hardware interfacing in parallel.

Ecosystem Due to the longevity and popularity of the LabVIEW language, and the ability for users to extend the functionality, a large ecosystem of 3rd party add-ons has developed through contributions from the community. This ecosystem is available on the LabVIEW Tools Network, and is a marketplace for both free and paid LabVIEW add-ons.

AIET/DOAEI/2011-12/SP/015

User community There is a low-cost LabVIEW Student Edition aimed at educational institutions for learning purposes. There is also an active community of LabVIEW users who communicate through several e-mail groups and Internet forums.

AIET/DOAEI/2011-12/SP/016

6. VIRTUAL INSTRUMENTS

Virtual instrumentation is the use of customizable software and modular measurement hardware to create user-defined measurement systems, called virtual instruments. Traditional hardware instrumentation systems are made up of pre-defined hardware components, such as digital multimeters and oscilloscopes that are completely specific to their stimulus, analysis, or measurement function. Because of their hard-coded function, these systems are more limited in their versatility than virtual instrumentation systems. The primary difference between hardware instrumentation and virtual instrumentation is that software is used to replace a large amount of hardware. The software enables complex and expensive hardware to be replaced by already purchased computer hardware; e. g. analog-todigital converter can act as a hardware complement of a virtual oscilloscope, a potentio stat enables frequency response acquisition and analysis in electrochemical impedance spectroscopy with virtual instrumentation.

Figure 6.1: showing virtual instrument module The concept of a synthetic instrument is a subset of the virtual instrument concept. A synthetic instrument is a kind of virtual instrument that is purely software defined. A

AIET/DOAEI/2011-12/SP/017

synthetic instrument performs a specific synthesis, analysis, or measurement function on completely generic, measurement agnostic hardware. Virtual instruments can still have measurement specific hardware, and tend to emphasize modular hardware approaches that facilitate this specificity. Hardware supporting synthetic instruments is by

definition not specific to the measurement, nor is it necessarily (or usually) modular. Leveraging commercially available technologies, such as the PC and the analog-to-digital converter, virtual instrumentation has grown significantly since its inception in the late 1970s. Additionally, software packages like National Instruments' LabVIEW and other graphical programming languages helped grow adoption by making it easier for non-programmers to develop systems.

AIET/DOAEI/2011-12/SP/018

7. APPLICATION OF VIRTUAL INSTRUMENTS

Virtual Instrumentation Applications Design Signal and Image Processing Embedded System Programming (PC, DSP, FPGA, Microcontroller) Simulation and Prototyping Control Automatic Controls and Dynamic Systems Mechatronics and Robotics Measurements Circuits and Electronics Measurements and Instrumentation

Virtual instrumentation is applicable in many different types of applications, starting from design to prototyping and deployment. The LabVIEW platform provides specific tools and models to solve specific applications ranging from designing signal processing algorithms to making voltage measurements and can target any number of platforms from the desktop to embedded devices with an intuitive, powerful graphical paradigm. With version 8, LabVIEW scales from design and development on PCs to several embedded targets from ruggedized toaster size prototypes to embedded systems on chips. LabVIEW streamlines system design with a single graphical development platform. In doing so, LabVIEW encompasses better management of distributed, networked systems because as the targets for LabVIEW grow varied and embedded, you will need to be able to more easily distribute and communicate between various LabVIEW code pieces in your system.

AIET/DOAEI/2011-12/SP/019

8. Division of Virtual Instruments

8.1 Front Panel

How the user interacts with the VI, this can be determined by front panel. The front panel is the user interface of the VI. You build the front panel with controls and indicators, which are the interactive input and output terminals of the VI, respectively. Controls are knobs, pushbuttons, dials, and other input devices. Indicators are graphs, LEDs, and other displays. Controls simulate instrument input devices and supply data to the block diagram of the VI. Indicators simulate instrument output devices and display data the block diagram acquires or generates. In this picture, the Power switch is a boolean control. A boolean contains either a true or false value. The value is false until the switch is pressed. When the switch is pressed, the value becomes true. The temperature history indicator is a waveform graph. It displays multiple numbers. In this case, the graph will plot Deg F versus Time (sec).

Figure 8.1: showing front panel of lab view

AIET/DOAEI/2011-12/SP/020

8.2 Block Diagram

The code that controls the program is determined by block diagram. The block diagram contains this graphical source code. Front panel objects appear as terminals on the block diagram. Additionally, the block diagram contains functions and structures from built-in LabVIEW VI libraries. Wires connect each of the nodes on the block diagram, including control and indicator terminals, functions, and structures. In this block diagram, the subVI Temp calls the subroutine which retrieves a temperature from a Data Acquisition (DAQ) board. This temperature is plotted along with the running average temperature on the waveform graph Temperature History. The Power switch is a boolean control on the Front Panel which will stop execution of the While Loop. The While Loop also contains a Timing Function to control how frequently the loop iterates.

Figure 8.2: showing block diagram of lab view

AIET/DOAEI/2011-12/SP/021

8.3 Icon/Connector
Means of connecting a VI to other VIs is determined by Icon/connector. In LabVIEW, you build a user interface by using a set of tools and objects. The user interface is known as the front panel. You then add code using graphical representations of functions to control the front panel objects. The block diagram contains this code. In some ways, the block diagram resembles a flowchart. Users interact with the Front Panel when the program is running. Users can control the program, change inputs, and see data updated in real time. Controls are used for inputs such as, adjusting a slide control to set an alarm value, turning a switch on or off, or to stop a program. Indicators are used as outputs. Thermometers, lights, and other indicators display output values from the program. These may include data, program states, and other information. Every front panel control or indicator has a corresponding terminal on the block diagram. When a VI is run, values from controls flow through the block diagram, where they are used in the functions on the diagram, and the results are passed into other functions or indicators through wires.

LabVIEW features graphical programming and VI'S that execute at speeds comparable with compiled C programs. A virtual instrument is simply a software module packaged graphically to have the look and feel of a physical instrument. A front panel serves as an interactive interface for inputs and outputs. The block diagram determines the functionality of the VI. By connecting executable blocks the student would draw the diagram thereby programming in a graphical language. Because of LabVIEWs conceptual simplicity, students can concentrate on the basic content of the experiment performed not losing valuable time on busy work and manual data logging. Our experience shows that the object-oriented programming of LabVIEW is both simple to use and powerful in operation. Students have participated in developing VI's for different applications Figure 1 shows a pH and temperature data acquisition and control system.

AIET/DOAEI/2011-12/SP/022

9. TEMPERATURE MEASUREMENT AND CONTROL

9.1 Conventional Method

The Infrared Measuring System

An IR thermometer can be compared to the human eye. The lens of the eye represents the optics through which the radiation (flow of photons) from the object reaches the photosensitive layer (retina) via the atmosphere. This is converted into a signal that is sent to the brain. Fig. shows an infrared measuring system process flow.

Figure 9.1: showing conventional method for temperature measurement

9.2 Labview Method

The project was to design an instrument to measure and control the heat of a standard carbon resistor. The project consisted of an LM35 a temperature sensor from National Semiconductor, a Macintosh IIci computer running LabVIEW with an NI DAQ board, an electric fan, and 1/2 watt carbon resistor. The LM35 sensed the temperature of the resistor. The sensor output was acquired by the interface unit and sent to the LabVIEW instrument emulation, which corrected the reading from the sensor, displayed the current and average

AIET/DOAEI/2011-12/SP/023

temperature. A high temperature limit which controlled the fan which was used to keep the resistor's temperature at a set point.

Figure 9.2: showing system block diagram

There are three main divisions of lab view technology which are as follows:

1. Block Diagram The block diagram contains this graphical source code. Front panel objects appear as terminals on the block diagram. Additionally, the block diagram contains functions and structures from built-in LabVIEW VI libraries. Wires connect each of the nodes on the block diagram, including control and indicator terminals, functions, and structures. In this block diagram, the subVI Temp calls the subroutine which retrieves a temperature from a Data Acquisition (DAQ) board. This temperature is plotted along with the running average temperature on the waveform graph Temperature History. The Power switch is a boolean control on the Front Panel which will stop execution of the While Loop. The While Loop also contains a Timing Function to control how frequently the loop iterates.

AIET/DOAEI/2011-12/SP/024

Figure 9.3: showing block diagram for temperature measurement with lab View

2. Front Panel

The front panel is the user interface of the VI. You build the front panel with controls and indicators, which are the interactive input and output terminals of the VI, respectively. Controls are knobs, pushbuttons, dials, and other input devices. Indicators are graphs, LEDs, and other displays. Controls simulate instrument input devices and supply data to the block diagram of the VI. Indicators simulate instrument output devices and display data the block diagram acquires or generates. In this picture, the Power switch is a boolean control. A boolean contains either a true or false value. The value is false until the switch is pressed. When the switch is pressed, the value becomes true. The temperature history indicator is a waveform graph. It displays multiple numbers. In this case, the graph will plot Deg F versus Time (sec).

AIET/DOAEI/2011-12/SP/025

Figure 9.4: showing front panel of labview during temperature measurement

3. Data flow programming

Node executes when data is available to ALL input terminals Block diagram executes dependent on the flow of data; block diagram does NOT execute left to right Nodes supply data to all output terminals when done

LabVIEW follows a dataflow model for running VIs. A block diagram node executes when all its inputs are available. When a node completes execution, it supplies data to its output terminals and passes the output data to the next node in the dataflow path. Visual Basic, C++, JAVA, and most other text-based programming languages follow a control flow model of program execution. In control flow, the sequential order of program elements determines the execution order of a program.

AIET/DOAEI/2011-12/SP/026

Figure 9.5: showing data flow strategy of lab view Consider the block diagram above. It adds two numbers and then subtracts 50.0 from the result of the addition. In this case, the block diagram executes from left to right, not because the objects are placed in that order, but because one of the inputs of the Subtract function is not valid until the Add function has finished executing and passed the data to the Subtract function. Remember that a node executes only when data are available at all of its input terminals, and it supplies data to its output terminals only when it finishes execution. In the code to the right, consider which code segment would execute firstthe Add, Random Number, or Divide function. You cannot know because inputs to the Add and Divide functions are available at the same time, and the Random Number function has no inputs. In a situation where one code segment must execute before another, and no data dependency exists between the functions, use a Sequence structure to force the order of execution.

AIET/DOAEI/2011-12/SP/027

10. HEART RATE MONITORING

9.1. Conventional Method

The project was to design an instrument to measure the heart rate of an infant following standard medical specifications. The project consisted of a pair of ECG electrodes connected to an Instrumentation amplifier, and a single stage 0.05 to l00 Hz band-pass filter. The input stage of the Instrumentation amplifier consisted of a dual Bifet Op- Ap integrated circuit (IC) and the last stage and bandpass filter consisted of another dual Op-Amp IC. The output of the amplifier was displayed on an oscilloscope (Note the ECG waveform was displayed only not the heart rate. The students did not have time to add rate signal processing).

Figure 10.1: showing circuit of conventional method of heart rate monitoring

AIET/DOAEI/2011-12/SP/028

9.2. Lab View Method

The project was to design an instrument to measure heart rate following standard medical specifications. The project consisted of an IR emitter-detector pair (Figure 8) and a Macintosh IIci computer running LabVIEW with an NI interface. The emitter-detector pair sensed the change in blood flow in the finger. This signal was acquired by the interface and made available to LabVIEW. Using LabVIEW a virtual instrument was created that sensed the incoming signal, determined when a true peak had occurred, counted the number of peaks in a 15 second period, multiplied by 4 to get beats per minute, and displayed the rate. Also there was a display of the actual waveform from the sensor.

Figure 10.2: showing front panel of heart rate monitoring with lab view

AIET/DOAEI/2011-12/SP/029

Figure 10.3: showing block representation of heart rate monitoring with lab view

AIET/DOAEI/2011-12/SP/030

CONCLUSION

1. We have started the process of developing a greater insight and more creativity in the design process. It is hoped that students will have better feeling for the interaction of all parts of a biomedical system as well as interaction with other systems both living and not.

2. The ability to deliver effective engineering education can be greatly enhanced by laboratories equipped with computer hardware and software, virtual-reality simulators, and physical systems.

3. Even sophisticated software can not completely replace physical systems in undergraduate biomedical instrumentation education. Comparing software models and virtual instruments to physical hardware can demonstrate important topics such as the effects of noise and nonlinearities.

4. Used appropriately, modeling techniques can be very helpful in meeting the challenge of balancing the breadth and depth of material coverage in undergraduate biomedical instrumentation education.

AIET/DOAEI/2011-12/SP/031