Electrocardiography (ECG) Starter Kit Application Software

Publish Date: Jul 27, 2017 | 4 Ratings | 4.75 out of 5 | Print


The Electrocardiography (ECG) Starter Kit Application Software utilizes LabVIEW, LabVIEW RealTime, and LabVIEW FPGA to create a multi-layered application for acquiring electrocardiogram signals. This article outlines the interactions between the different layers.

Table of Contents

  1. Introduction
  2. LabVIEW RealTime Host VI and LabVIEW FPGA VI
  3. LabVIEW Host VI: User Interaction
  4. LabVIEW Host VI: Behind the Front Panel
  5. Related Documentation
  6. Testing Your ECG (EKG) Products to ANSI/AAMI EC13

1. Introduction

The ECG Starter Kit Application Software has three main components: the LabVIEW Host PC VI, the LabVIEW RealTime VI, and the FPGA VI.  The role and interaction of the components can be seen in Figure 1.

Figure 1: The ECG Starter Kit consists of 4 pieces of hardware (TI ECG Analog Front End Board, Adapter Board, Single-Board RIO, and a PC) and 3 software components. Communication between the software components includes SPI protocol, FIFOs, and network published shared variables.

On the lowest level, the TI ECG Analog Front End Module converts the analog signals from the electrodes connected to the patient or simulator into a digital signal.  The signal is sent to the NI Single-Board RIO 9631 using SPI communication through the NI sbRIO Adapter to the Texas Instruments Electrocardiogram (ECG) Analog Front End Module.  For more detailed information on the TI ECG Analog Front End Module see ECG Implementation on the TMS320VC5505 DSP Medical Development Kit (MDK) user manual.  Furthermore, additional information about the SPI Engine and the driver for the ADC is available in the application notes SPI Protocol and LabVIEW FPGA IP for Texas Instruments ADS1258 16-Channel, 24-Bit ADC, respectively.


Back to Top

2. LabVIEW RealTime Host VI and LabVIEW FPGA VI

On the Single-Board RIO, there are two software components: the LabVIEW RealTime Host VI and the LabVIEW FPGA VI.  The LabVIEW FPGA VI contains the SPI Engine and is a slight modification of the LabVIEW FPGA IP for TI ADS1258, which includes communication with the RealTime host.  The modification for the ECG Starter Kit Application Software is the addition of a loop to perform filtering on the acquired ECG signal (Figure 2).

Figure 2.  Filtering is performed on the FPGA to improve filtering performance.  The ECG data is passed from the RealTime Host to the FPGA, filtered, and the sent back to the RealTime Host through DMA FIFOs. 

The LabVIEW RealTime Host VI is also based heavily on the  LabVIEW FPGA IP for Texas Instruments ADS1258 16-Channel, 24-Bit ADC.  For example, it uses the same Start, Read, Configure, and Stop VIs (the VI icons and names have been changed to fit with the application).  However, the LabVIEW RealTime Host VI contains a few changes to accommodate the nature of the ECG application.  Among the changes is transforming into a state machine to allow for reconfiguration.  The state machine architecture better suits the need to reconfigure the ECG Leads.  

Figure 3: The LabVIEW RealTime Host VI is a state machine and controls the timing of commands sent to the FPGA VI.

The state machine begins in the Initialize state, where shared variables are set to their start-up values.  The state machine quickly moves to the Idle state where it polls the Start network published shared variable waiting for the command from the LabVIEW Host VI on the PC.  

The Configure state is executed next.  Within the Configure state, the Channel Configuration array is created by inserting three array elements which contain user selected information about which channels will be read.  The channel Configuration array is sent to the FPGA for use in the SPI Engine.  In addition, an array of string is created corresponding to the acquisition channels.  This string array is then searched for Lead II and the index of the string "Lead II" is sent into a shift register to be used in the Read state.

Figure 4: The Configure state compiles the Channel Configuration array and checks that Lead II is actively being acquired from.

The Read state is responsible for starting the SPI Engine, reading the ECG data, passing and retrieving data to and from the FPGA for filtering.  In addition, there are four leads (Lead III, aVR, aVL, and aVF) that must be calculated from the data acquired as stated in the ECG Implementation on the TMS320VC5505 DSP Medical Development Kit (MDK).  This calculation is performed in the Calculate Leads subVI in the Read state shown in Figure 5.   Furthermore, the heart rate is calculated in a subVI within the Read state using peak detection.   

Figure 5: The Read state of the LabVIEW RealTime Host VI starts the SPI Engine, reads the ECG Data, passes data to be filtered, calculates lead data, and determines the heart rate of the ECG signal.

The data queued in the Read state is dequeued and passed into a network published shared variable in a parallel while loop.  The parallel while loop takes advantage of LabVIEW's ability to multithread and maintains the deterministic behavior of the timed loop. 

The Reconfigure and Stop states both send commands to the FPGA to stop acquisition. However the difference between the states is that the Reconfigure state sends the state machine to the Initialize state next, and the Stop state writes a true to the loop condition to stop the execution of the state machine and end the program.


Back to Top

3. LabVIEW Host VI: User Interaction

 The user interfaces is multifaceted. The first screen the user sees, the LabVIEW RealTime sbRIO ECG Launcher, allows the user to select to acquire data, playback previously acquired data, or analyze previously recorded data.   Each component of the user interface is discussed in this article.  


LabVIEW RealTime sbRIO ECG Launcher

The LabVIEW RealTime sbRIO ECG Launcher is the main application of the ECG Starter Kit Application Software.  It allows the user to choose to acquire ECG data, playback recorded data, or process recorded data.  The launcher runs VIs or applications depending on whether the LabVIEW development environment or the LabVIEW Run-Time Engine is hosting the launcher.

Figure 6: From the RealTime sbRIO ECG Launcher, the user can choose to acquire live data, process recorded data, playback recorded data, or exit.


Acquire ECG Data 

The Acquire ECG Data window appears when the user clicks the Acquire button on the launcher.  First, the user is prompted to verify the appropriate ECG leads are connected for the signals the user would like to read. The window that appears is shown in Figure 7.

Figure 7: The Check ECG Leads VI requires the user to 1) choose the signals to be read, 2) select the leads that are physically connected, 3) press the Check Leads button to verify the required connections for the chosen signals are made.


Checking the ECG Leads

First, the user selects the desired signals by checking the box next to Lead I, Lead II, etc.  Next, the user presses the buttons corresponding to the physical connections on the subject (or ECG Simulator).  By clicking the Check Leads button, the VI will cross reference the signals and the connected leads to ensure that all the required connections are made.  If the required connections were not selected, then the user will be prompted to select the missing connections.   The connection information will update on the Acquire ECG Data front panel under the Lead Status section as blue LEDs. This functionality could easily be adapted to include automatic lead detection using I2C, which is supported by the Texas Instruments ADS1258 16-Channel, 24-Bit ADC.


Acquiring ECG Data

Once the leads are verified, the charts on Acquire ECG Data front panel will begin plotting live data. In addition to the lead status, the heart rate is also displayed at the top of the window.  The user has the option of reconfiguring the leads, exporting the data to file, freezing the display, processing the displayed data, or quitting the application and returning to the launcher.  Each of the features are discussed in more detail below.

Figure 8: Leads Left Arm (LA), Right Arm (RA), Left Leg (LL), and Right Leg (RL) are connected and indicated by the Lead Status LEDs.  The Heart Rate is currently 0 because no data is being acquired.


Playing and Pausing ECG Data

After 15 seconds, the Play/Pause button will activate, so the display can be frozen to study a trace.  Once the plots are frozen, the Process button also becomes enabled.  Should user choose to process the displayed data, the 15 second delay provides time to collect sufficient data for processing. Pressing the Play/Pause button a second time will resume plotting of data.  


Processing Displayed ECG Data

When the Process button is pressed, a processing window is launched. The window is very similar to the ECG Feature Extraction application, which is discussed in more detail later and can be launched from the launcher. The main difference is that the data to be processed, the 7500 points stored in the chart history, is automatically imported. The ECG Feature Extractor locates the R peaks of the QRS complex as well as runs statistics on the data set.


Exporting ECG Data

Many times the signals being acquired will need to be recorded.  If this is the case, then the user can press the Export Data button.  A prompt will appear, so a file name and save location can be selected.  Once the file name and location is determined, the data will be streamed to the TDMS file.


Playback Recorded ECG Data

From the Launcher screen, there is an option for playback.  The playback option will prompt the user to choose the TDMS file that stores the previously recorded ECG data.  Once the file is selected, the playback VI will begin running.  The user can slow down or speed up the rate of playback by moving the slide control labeled Speed.  At the top of the window, there is a progress bar that shows the percentage of the file that has been read.  The heart rate information that was stored in the file is also displayed as the signals plot across the charts.  When the user is finished playing back any or all of the data, the quit button will exit the application and reveal the launcher.

Figure 9: The user interface of the playback feature includes all 12 plots, a playback speed moderator, a percent complete indicator and the heart rate display.


Process Recorded ECG Data

If the user would like to process previously recorded data, they can do so by pressing the Process button on the launcher.  A window will appear titled ECG Feature Extractor.  First, the user needs to press the Import button to select the TDMS file which contains the data to be processed.  Once the file is imported, the user can configure the processing to be done by clicking on the Set Extractor… button.  After the desired processing configuration is selected, the user runs the processing by pressing the green arrow button.  The processing can be halted by pressing the red stop button.  Upon completion of the processing, the processed data will appear in the chart; and, depending on the process configuration, the QRS complex may be highlighted in red. Statistical result can be displayed by pressing the Statistics... button, which will launch a results window.  Clicking the Export... button will export the RR Intervals to a TDMS file.  The ECG Feature Extractor is a component of the NI Biomedical Startup Kit.

Figure 10: The QRS complex is highlighted in red after the data has been imported and processed.


Back to Top

4. LabVIEW Host VI: Behind the Front Panel

Now that you have seen the application from the user perspective, let’s take a look from the developer’s perspective. 


LabVIEW RealTime sbRIO ECG Launcher

The launcher’s functionality is actually quite simple.  It uses an event structure within a loop to acknowledge button presses on the front panel.  Once a button is pressed, the launcher executes code that opens and runs either a VI or an application, depending on the launcher itself is a VI or application.  This prevents needing to change the code for the development environment or the run-time environment.

Figure 11: The block diagram of the Launcher is nothing more than an event structure with an event case for each button on the front panel.  All cases will launch a VI or application corresponding to the button except the quit button, which closes the launcher.


Figure 12: The case with the AppKind being the Development System uses VI Server to open and run the VI corresponding to the button pressed.


Acquire ECG Data

Unlike the launcher, the Acquire ECG Data VI is multifaceted.  It contains three parallel loops: one for handling user interface operations, one for retrieving data from the sbRIO, and one for displaying or saving data.

Figure 13:  The block diagram of the Acquire ECG Data contains three parallel loops for user interface handling, retrieving data from the sbRIO, and display and saving data.


The User Interface Loop

The User Interface loop is a state machine with five states: Initialize, Check Leads, Generate Channel Indices, Read ECG, and Stop.  The Initialize state ensures that the global variables containing the states for the Display and Save state machines are in the correct start-up state.  In addition, the Play/Pause and Process buttons are initialized to be disabled and grayed out before the state machine is sent into the Check Leads state.

The Check Leads state loads the Check Leads VI in which the user selects the signals to be read as well as the connections made.  This state also updates the blue Lead Status LEDs on the front panel of the Acquire ECG Data VI before the state machine transitions to the Generate Channel Indices state.

The purpose of the Generate Channel Indices state is to create an array of indices corresponding to the leads from which data is being acquired.  This array is necessary because the user may not always have the same leads connected and the data must be distributed to the appropriate chart or channel of the TDMS file.  The array is stored in a function global variable.  This state also signals the FPGA to begin acquisition by passing a True value to the Start network-published shared variable. 

The majority of time is spent in the Read ECG state which contains an event structure.  The event structure has cases for value change events for each of the buttons on the front panel: Reconfigure, Save Data, Pause, Process and Stop. The reconfigure event will send the user interface state machine back to the initialize state, which will then lead to the check leads state where the user will be able to reconfigure the signals to be read and the current connections.  The save data and the pause events set the appropriate states for the save state machine and the display state machine, respectively.  These two state machines will be discussed in more detail below.  The process event runs the ECG Feature Extraction VI.  Lastly, the stop event will send a stop to the save and display state machines, send a stop signal to the FPGA, and send the user interface state machine to the stop state.  The stop state of the user interface state machine simply sets the loop condition to true.


The Acquisition Loop

Because the FPGA is acquiring data at 500 Hz, the acquisition loop must run as quickly as possible when retrieving the live data from the FPGA.  Therefore, reading from the ECG Data network-published shared variable occurs in a loop by itself.  The timeout indicator is checked on the network published shared variable to determine if the data is new or old.  If the data is new, it is put into a queue, which temporarily stores the data to be used in the display/save loop.  The acquisition loop is halted by reading the value property of the stop button and writing it to the loop condition.


The Display and Save Loop

The third loop serves two purposes: exporting the queued data to a TDMS file and displaying the queued data in the appropriate chart on the front panel.  Both of these functions are implemented through a state machine controlled by a global variable containing an enumeration. 

The display state machine has four states: Freeze, Unfreeze, Do Nothing, and Quit.  Unfreeze is the default state and contains the terminals of the charts that display the acquired data.  The Unfreeze state first rearranges the queued data in the appropriate manner, so it can be displayed properly.  Then the data is changed into a waveform data type before being sent to the charts.   The Freeze state gets the chart history data from all of the charts on the front panel and saves them to a TDMS file, so the data is ready if the user would like to process the data.  The process button is only enabled when the charts are frozen, so the disabled property of the process button is changed to enabled in this state as well.   Once the Freeze state has executed, the state machine goes into the Do Nothing state, which continuously executes until the user interface loop changes the global variable to the Unfreeze or Quit states.  The Quit state will stop the loop by sending a true constant to the loop condition.

The save state machine has five states: Do Nothing, Open File, Stream to File, Close File, and Quit.  The Do Nothing state is the default state and only passes wires through.   However when the user interface loop updates the save enumeration in the global variable to begin exporting data, the Open File state executes.  The user is prompted to choose or create a TDMS file in which to save the data, and the properties and channel names of the file are set in addition to the File Flag boolean.  The save state machine is then sent into the Stream to File state by writing to the global variable.  Within the Stream to File state, the data is rearranged and sent to the appropriate channel in the TDMS file.  This state will continue to execute until the user presses the export button again to stop saving, at which point the Stop Save state executes closing the TDMS file and sending the state machine back into the Do Nothing state.  The Quit state only executes when the user interface loop sets the global variable to Quit.  The Quit state will close out the file if the File Flag was set to true in the Open File state.  A true is also sent to the loop condition to stop the save/display loop.


Check Leads

Before discussing the execution of the Process and Playback VIs, let’s take a look at the Check Leads VI block diagram.  The main Check Leads VI operates using a state machine with four states: Select Leads, Wait for Okay, Check Leads, and Exit.  The Select Leads state initializes the controls on the front panel and is a place where a welcome message or instructions could be placed.  The Exit state writes a true to the loop condition so the subVI can be closed.  The Wait for Okay state polls the Check Leads button, and once the button is pressed, the Check Leads state executes.  The majority of the functionality is within the Check Leads subVI, which cross-checks the signals-to-be-read with the leads connected. 

Figure 14: The Check Leads VI is a state machine that messages the user on the status of the leads.

The first order of business within the Check Leads subVI is to create two arrays, one containing references to the buttons representing the lead connections, and another containing the values of the controls.   The array of values is converted into a cluster for easy reading.  Both arrays are passed into a case structure within a for loop.  The value cluster is used to update the Still to be Connected cluster, which will be passed out to notify the user which required connections are not made.  In addition, the array of references is used to update the Blinking property of the button to true if it corresponds to a missing connection. The Connections Good? boolean is also passed out and is used to determine the next state of the Check Leads state machine. 


Figure 15: The Check Leads subVI cross-checks the signals the user wants to read with the connections made to ensure all the required connections are present.  

If the connections are good, the user receives a message and the VI exits. If the connections do not pass the cross-referencing, a message appears asking the user to make the appropriate connections.  In addition, the buttons that represent the missing leads are now blinking which helps the user quickly determine which connections need to be made.  After the missing connections are corrected, the user presses the Check Leads button again forcing the Check Leads subVI to execute once again and then, hopefully, exit if the cross-referencing proves to be satisfactory. 



The Playback Recorded ECG Data VI is not as complex as the Acquire ECG Data VI.  The first step in the playback VI is to retrieve the data from a TDMS file.  After the user selects the file to be read, the properties are extracted from the file as well as the channel data.  The 2-D array of channel data is sent to a queue.  The rate at which the data is enqueued is determined by the loop rate of a for loop, which is dependent on the value of the Speed slide control.   Inside a while loop, the data is dequeued and displayed as quickly as possible. Therefore, the playback speed is determined by how quickly elements are queued.  The event structure on the block diagram of the Playback ECG Data VI waits until the quit button changes value at which point the VI is closed. 

Figure 16: The Playback ECG Data VI retrieves the data from the user specified file and queues the data in order to control the display rate.



The ECG Feature Extractor VI that loads when the Process button is pressed is a component of the Biomedical Start-up Kit.  For more information refer to the NI Biomedical Startup Kit page.


Back to Top

5. Related Documentation

Refer to the following documents to learn more about ECG measurements and the application of Graphical System Design using the NI sbRIO with the TI MDXMDKEK1258 Electrocardiogram (ECG) Analog Front End (AFE) module:

Back to Top

6. Testing Your ECG (EKG) Products to ANSI/AAMI EC13

Learn how to test and validate any Electrocardiography (ECG) (EKG)  based medical device to ANSI/AAMI EC13.  

In this document, you will learn how to automate and reduce time required to test and validate any ECG based device using NI PXI modular instruments and NI software.

Originally Authored By: Greg Crouch, National Instruments

Back to Top

Bookmark & Share


Rate this document

Answered Your Question?
Yes No