CHAPTER 1

INTRODUCTION AND BACKGROUND

1.1 INTRODUCTION
Medical Technologies have grown rapidly over the years along with other
fields. In fact, today, access to medical care in the form of clinics and hospitals has
become a lot easier for most of the population; modern medical equipment and
advanced techniques for curing diseases have increased life expectancy all over the
world. Many maladies that were once written off as incurable are now being treated
efficiently, and people affected by these are returning to their normal lives. Yet,
Cardiovascular Diseases (CVDs) remain to be the major cause of death, globally, and
cannot be eradicated or made obsolete. More people die annually from CVDs than
from any other cause. An estimated 17.3 million people died from CVDs in 2008,
representing 30% of all global deaths [1]. Of these deaths, an estimated 7.3 million
were due to coronary heart disease and 6.2 million were due to cardiac arrhythmia
(heart stroke) [2]. Low- and middle-income countries are disproportionally affected,
over 80% of CVD deaths take place in low- and middle-income countries and occur
almost equally in men and women [1].
The most common test for a cardiac arrhythmia is an Electrocardiogram
(ECG). However, it is difficult to diagnose many arrhythmias with a standard resting
ECG, because it can only provide a snapshot of the patients cardiovascular activity in
time, as a result an intermittent arrhythmia can go unnoticed. So, physicians must rely
on self-monitoring and symptoms reported by patients to support their final diagnosis.
Although they can lead to a diagnosis and therapy that may greatly improve the
quality of life for the patient, they can be inconvenient for both the patient and the
physician. To overcome this problem, ECG data can be collected over extended
periods of time using Holter Monitors [3], which acquires the electrical activity of a
freely moving person's heart generally for one to two days. After the measurement of
the patients ECG using this device, the signal analysis is then carried out offline by
the physician. This device lacks in real time diagnosis of ECG. Another solution is to
utilize telemedical functionalities via a remote real-time monitoring system where the
ECG is extracted using Personal Digital Assistants (PDAs) and transmitted to
monitoring centre to analyse and classify the data [3]. But, this system uses more
resources and it is expensive.
A possible solution is to integrate the portability of the Holter Monitor and
real-time processing capability of the resting ECG machine using smartphones which
helps in monitoring the patients health by the physician and the patient himself [3].
This particular system enables the patient to move freely and carry on his (restricted)
daily activities as suggested by the physician.
The work described in this report is based on the above mentioned solution to
monitor a patients ECG by means of his smartphone. This work is carried out by
assuming that the patients ECG is measured by a portable device similar to Holter
Monitor and the ECG is readily available for further processing. After acquiring the
ECG, the signal is fed into a PIC16F877A microcontroller for converting it into
digital data and then transmitted to patients smartphone through Bluetooth Serial Port
Profile (SPP) communication. This data is received in real-time by an application,
installed on the Android-based smartphone. This application monitors the ECG data
using Pan Tompkins algorithm [4] and raises alerts in case of abnormalities with
respect to only the heart rate. The received data is also backed up in the external
memory of the mobile for further reference.
1.2 OVERVIEW
The report is organised as follows:
Chapter 2 gives an overview of Electrocardiogram (ECG) and ECG feature
extraction algorithm. Chapter 3 briefly explains the PIC16F877A microcontroller
concepts, namely Analog to Digital (A/D) conversion and serial communication
(USART), for interfacing the ECG extraction module to patients smartphone.
Chapter 4 deals with the Android operating system and the Bluetooth Serial Port
Profile (SPP) communication. Chapter 5 gives a detailed description of the system
implementation interfacing module, Android application and results of the modified
algorithm. Chapter 6 discusses future scope of this work and concludes the report.


















CHAPTER 2
ELECTROCARDIOGRAM
2.1 BRIEF INTRODUCTION OF ELECTROCARDIOGRAM
Electrocardiography is a transthoracic (across the thorax or chest)
interpretation of the electrical activity of the heart over a period of time, as detected
by electrodes attached to the surface of the skin and recorded by an external device.
The recording produced by this non-invasive procedure is termed an
electrocardiogram (ECG). An ECG is used to measure the rate and regularity of
heartbeats, as well as the size and position of the chambers, the presence of any
damage to the heart, and the effects of drugs or devices used to regulate the heart,
such as a pacemaker. An ECG is a way to measure and diagnose abnormal rhythms of
the heart, particularly abnormal rhythms caused by damage to the conductive tissue
that carries electrical signals, or abnormal rhythms caused by electrolyte imbalances.
In a Myocardial Infarction (MI), also known as heart attack, the ECG can identify if
the heart muscle has been damaged in specific areas.
The ECG device detects and amplifies the tiny electrical changes on the skin
that are produced when the heart muscle depolarizes during each heartbeat. At rest,
each heart muscle cell has a negative charge, called the membrane potential, across its
cell membrane. Decreasing this negative charge towards zero, via the influx of the
positive cations, Na
+
and Ca
++
, is called depolarization, which activates the
mechanisms in the cell that cause it to contract. During each heartbeat, a healthy heart
will have an orderly progression of a wave of depolarisation that is triggered by the
cells in the Sinoatrial (SA) node, spreads out through the atrium, and passes through
the Atrioventricular (AV) node and then spreads all over the ventricles. This is
detected as tiny rises and falls in the voltage between two electrodes placed either side
of the heart which is displayed as a wavy line, known as ECG, either on a screen or on
paper. This display indicates the overall rhythm of the heart and weaknesses in
different parts of the heart muscle.
2.2 PARAMETERS IN ECG SIGNAL
A typical ECG tracing of a cardiac cycle consists of a P wave, QRS complex,
a T wave, U wave which is normally visible in 50% to 75% of ECGs as shown in Fig.
2.1. The baseline of the ECG (flat segments) is portion of the tracing following the T
wave and preceding the next P wave. In a normal healthy heart, the baseline is almost
equivalent to isoelectric line.

Fig 2.1 Representation of ECG signal
The P wave and the QRS complex tell us about the atria and ventricles
respectively. The T wave evaluates the recovery stage of the ventricles while they are
refilled with blood. The time it takes for electric charge to travel from the SA node to
the AV node is measured by the PR interval. The QRS interval measures electric
charge travel time through the ventricles and the QT interval measures how long it
takes for the ventricles to recover and prepare to beat again. The number of P-QRS-T
sequences gives the heart rate.
Certain facts about these parameters are as follows:
Table 2.1 List of features used in ECG diagnosis
FEATURES DESCRIPTION DURATION
RR Interval
The interval between an R wave and the next
R wave is RR interval. This gives us the heart
rate.
0.6 to 1.2s
P wave
During normal atrial depolarization, the
electrical ion is directed from the SA node
towards the AV node, and spreads from the
right atrium to left atrium. This turns into P
wave on the ECG.
80ms
PR interval
The PR interval is measured from the
beginning of the P wave to the beginning of
the QRS complex. The PR interval reflects the
time the electrical impulse takes to travel from
the sinus node through the AV node and
entering the ventricles. The PR interval is,
therefore, a good estimate of AV node
function.
120 to 200ms
PR segment
The PR segment connects the P wave and
QRS complex.
50 to 120ms
QRS complex
The QRS complex reflects the rapid
depolarization of the right and left ventricles.
They have a large muscle mass compared to
the atria, so the QRS complex usually has
much larger amplitude than the P-wave.
80 to 120ms
ST segment
The ST segment connects QRS complex and
T wave. It represents the period of ventricles
depolarized and it is isoelectric.
80 to 120ms
T wave
The T wave represents the repolarization of
the ventricles.
160ms
ST interval
It is measured from end of QRS complex to
the end of the T wave.
320ms
QT interval
It is measured from the beginning of the QRS
complex to end of T wave. A prolonged QT
interval is a highly risk factor for ventricular
tachyarrhythmia and sudden death.
Up to 420ms
in heart rate
of 60bpm

ECG analysis is mostly carried out by detecting the QRS complex as it gives
information regarding the heart rate which is a necessary condition in determining a
patients cardiac health. There are few existing QRS detection algorithms, of which
Pan Tompkins algorithm [4] is chosen to carry out the work described in this report
because of its low computational complexity and reliability under ambulatory
conditions.
2.3 QRS DETECTION ALGORITHM
QRS detection is difficult because various types of noise can be present in the
ECG signal. Noises include muscle noise, power-line interference, baseline wander
and T waves with high frequency characteristics similar to QRS complexes. The most
popular algorithm for ambulatory ECG QRS detection is the Pan-Tompkins
Algorithm [4] mainly because it is computationally efficient and is accurate enough to
check for abnormal heart activity. Also, certain measures are incorporated for
reducing influence of noise sources, and thereby increasing the signal-to-noise ratio.
We detect the QRS complexes using this algorithm in real-time and measure various
parameters of the ECG like the heart rate, RR interval, number of R peaks to sense
abnormalities in the heart activity of the individual being monitored.
The Pan-Tompkins QRS detection algorithm includes three different types of
processing steps: linear digital filtering, nonlinear transformation and decision rule
algorithm [4]. Linear processes include a band-pass filter, a derivative and a moving
average filter. The nonlinear transformation uses signal amplitude squaring. The
decision rule algorithm deals with adaptive thresholds.
2.3.1 BAND-PASS FILTER
First, the signal is fed into an integer coefficient digital band-pass filter, which
is a linear digital filtering process, composed of cascaded low-pass and high-pass
filters. The band-pass filter reduces the influence of muscle noise, 60 Hz interference,
baseline wander and T-wave interference. The desirable passband to maximize the
QRS energy is approximately 5-15 Hz.
Low-Pass Filter:
The transfer function of the second-order low-pass filter is
()
(

The difference equation of the filter is
() ( ) ( ) () ( ) ( )
where, T is the sampling period and the cutoff frequency is about 11 Hz and the gain
is 36. This filter has a processing delay of 6 samples.
High-Pass Filter
The design of the high-pass filter is based on subtracting the output of the low
pass filter from the all-pass filter which is delayed by 16T ( i.e. z
-16
) to compensate
the low-pass filter delay.
The transfer function of the high-pass filter is
()

The difference equation of the high-pass filter is
() ( ) () ( ) ( ) ( )
where, the cutoff frequency is about 5 Hz. This filter has a processing delay of 16
samples.
2.3.2 DERIVATIVE
After the filtering, the signal is processed using a derivative function, another
linear digital filtering process, in order to extract the QRS complex slope information.
A five-point derivative is used with transfer function
() ()(

)
The difference equation is
() () ( ) ( ) ( ) ( )
A delay of two samples occurs at the end of this derivative function.
2.3.3 SQUARING FUNCTION
After differentiation, the signal is squared point by point. The equation of this
operation is
() ()
The squaring function makes all the data points positive and does nonlinear
amplification of the output of the derivative, emphasizing the higher frequencies (i.e.,
predominantly the ECG frequencies).
2.3.4 MOVING-WINDOW INTEGRATION
The main objective in using moving-window integration is to obtain waveform
feature information in addition to the slope of the R wave. It is calculated from
() () ( ( )) ( ( )) ()
where, N is the number of samples in the width of the integration window.
The number of samples N in the moving window is important. If the window
is too wide, the integration waveform will merge the QRS and T complexes together.
If the window is too narrow, some QRS complexes will produce several peaks in the
integration waveform which are known as false peaks.
2.3.5 MODIFIED DECISION ALGORITHM
The original Pan-Tompkins algorithm includes two thresholds to detect the R
peak. Initially, the higher threshold is used for the first analysis of the signal. The
lower threshold is used if no QRS complex is detected in 166 percent of the current
RR interval i.e. the algorithm back traces the signal to detect the missing QRS
complex using the lower threshold. But, since such back tracing will overload the
Android device, a simple and relaxed version of the above mentioned algorithm is
employed as follows:
Firstly, we normalize the output of the moving window integrator. Then, we
set the mean of the signal as our threshold for detecting the R peak. Then, we find the
interval in which all the signal values cross this threshold and decide the local
maximum in the interval as the R peak. This simplifies the computations involved and
is accurate enough for mobile ECG monitoring.


















CHAPTER 3
INTERFACING MODULE PIC MICROCONTROLLER
3.1 OVERVIEW
The interfacing module between the ECG extraction module and the patients
smartphone consists of a PIC microcontroller (PIC16F877A) and Bluetooth device
(Rhydolabz Technologies Bluelink). Microcontroller is used to convert the analog
ECG signal to digital form which requires the in-built Analog-to-Digital conversion
module (A/D). This digital ECG signal is then transmitted to the Bluetooth device
serially using the in-built UART communication module of the microcontroller. This
chapter deals with the concepts of A/D conversion and the serial communication.
Bluetooth Serial Port Profile will be explained in section 4.2.
3.2 ANALOG TO DIGITAL CONVERISON
The analog-to-digital (A/D) converter on PIC16F877A microcontroller has 5
input pins. The A/D conversion of the analog input signal by this module results in a
corresponding 10-bit digital number. This means that when it measures an incoming
voltage, it compares that voltage to a reference voltage, and gives us the comparison
represented as a 10-bit number (0-1023).
The A/D module has four registers. These registers are:
A/D Result High Register (ADRESH)
A/D Result Low Register (ADRESL)
A/D Control Register 0 (ADCON0)
A/D Control Register 1 (ADCON1)
The ADCON0 register controls the operation of the A/D module. The
ADCON1 register configures the functions of the port pins. The result obtained after
the conversion is stored in ADRESH and ADRESL.
The ADRESH and ADRESL registers contain the 10-bit result of the A/D
conversion. When the A/D conversion is complete, the result is loaded into this A/D
result register pair, the GO/ DONE bit is cleared and the A/D interrupt flag bit ADIF
is set.


The steps for doing an A/D Conversion are as follows:
1. Configure the A/D module:
Configure analog pins/voltage reference and digital I/O (ADCON1)
Select A/D input channel (ADCON0)
Select A/D conversion clock (ADCON0)
Turn on A/D module (ADCON0)
2. Configure A/D interrupt (if desired):
Clear ADIF bit
Set ADIE bit
Set PEIE bit
Set GIE bit
3. Wait the required acquisition time
4. Start conversion:
Set GO/ DONE bit (ADCON0)
5. Wait for A/D conversion to complete, by either:
Polling for the GO/ DONE bit to be cleared (with interrupts enabled);
OR
Waiting for the A/D interrupt
6. Read A/D result register pair (ADRESH:ADRESL), clear bit ADIF if required
7. For the next conversion, go to step 1 or step 2, as required
3.3 SERIAL TRANSMISSION (USART)
The Universal Synchronous Asynchronous Receiver Transmitter (USART)
module is one of the serial I/O modules in PIC16F877A. USART is also known as a
Serial Communications Interface or SCI. The USART can be configured as a full-
duplex asynchronous system that can communicate with peripheral devices, such as
CRT terminals and personal computers, or it can be configured as a half-duplex
synchronous system that can communicate with peripheral devices, such as Analog-
to-Digital (A/D) or Digital-to-Analog (D/A) integrated circuits, serial EPROMs, and
so on. The USART can be configured in the following modes:
Asynchronous (full duplex)
Synchronous - Master (half duplex)
Synchronous - Slave (half duplex)
The following registers are used in serial transmission of data (USART):
Transmit Status and Control Register (TXSTA)
Receive Status and Control Register (RCSTA)
USART Transmit Register (TXREG)
Baud Rate Generator Register (SPBRG)
Interrupt Registers like INTCON, PIR1, PIE1
When setting up an Asynchronous Transmission, follow these steps:
1. Initialize the SPBRG register for the appropriate baud rate. If a high speed
baud rate is desired, set bit BRGH
2. Enable the asynchronous serial port by clearing bit SYNC and setting bit
SPEN
3. If interrupts are desired, then set enable bit TXIE
4. If 9-bit transmission is desired, then set transmit bit TX9
5. Enable the transmission by setting bit TXEN, which will also set bit TXIF
6. If 9-bit transmission is selected, the ninth bit should be loaded in bit TX9D
7. Load data to the TXREG register (starts transmission)
8. If using interrupts, ensure that GIE and PEIE (bits 7 and 6) of the INTCON
register are set.























CHAPTER 4
ANDROID PLATFORM
4.1 WHAT IS ANDROID?
Android is a Linux-based Operating System (OS) designed
for touchscreen mobile devices such as smartphones and tablet computers. Google
was the first to release Android Application under the Apache License. This License
allows the software to be freely modified and distributed by the device manufactures.
Google currently uses their Google Bouncer malware scanner to watch over and scan
the Google Play store apps. Android is written in the customized version of the Java
programming language using the Android Software Development Kit (SDK). The
SDK performs various operations such as debugger, software libraries, a handset
emulator based on QEMU, documentation, sample code etc. Other development tools
are also available, including Native Development Kit for Applications or extensions
in C or C++. The first Android phone was sold in October 2008. Since 2008, Android
has seen many updates which have improved the operating system, adding new
features and fixing bugs. The latest release is 4.2 Jelly Bean. Androids user interface
is based on direct manipulation using touch inputs that perform operations like
swiping, tapping, pinching etc. Android devices boot to the homescreen, the primary
navigation, and information point on the device are similar to the desktop found on
PCs. Android applications run in a sandbox, an isolated area of the system that does
not have access to the rest of the system's resources, unless access permissions are
explicitly granted by the user when the application is installed. Android smartphones
have the ability to report the location of Wi-Fi access points, encountered as phone
users move around, to build databases containing the physical locations of hundreds
of millions of such access points. These databases form electronic maps to locate
smartphones, allowing them to run apps like Foursquare, Google Latitude, Facebook
Places, and to deliver location-based ads. Multi-threading, a concept which helps in
running several processes simultaneously, is exploited in the android applications.
This helps in reducing the overall time required for executing all processes.
4.2 BLUETOOTH SERIAL PORT PROFILE (SPP)
The Serial Port Profile defines the protocols and procedures that shall be used
by devices using Bluetooth for RS232 (or similar) serial cable emulation. A profile is
dependent upon another profile if it re-uses part of that profile, by implicitly or
explicitly referencing it. Setting up virtual serial ports (or equivalent) on two devices
(e.g. PCs) and connecting these with Bluetooth emulates a serial cable between the
two devices. Any legacy application may be run on either device using the virtual
serial port, as if there were a real serial cable connecting the two devices (with RS232
control signalling). Only one connection at a time is dealt with in this profile. Also,
only point-to-point configurations are considered. For the execution of this profile,
use of security features such as authorization, authentication and encryption is
optional. Establishment of this communication with reference to Android is dealt with
next to provide a better understanding of the project flow description in Chapter 5.
The interface for Bluetooth socket is similar to that of TCP sockets: socket and
Server socket. On the server side, a BluetoothServerSocket object is used to listen for
any incoming connections. In Android, this is implemented using the
listenUsingRfcommWithServiceRecord(NAME,SERIAL_UUID) method where
NAME refers to any name by which the server application is to be called and
SERIAL_UUID is a unique identity for communication between the two peer
applications. Once Bluetooth is turned on, the application starts the thread to listen for
incoming connections using this method. This is a blocking call where the rest of the
code is executed only after receiving a connection. A sample code is given below:
try {
tmp = mBluetoothAdapter.listenUsingRfcommWithServiceRecord("SPP",
SERIAL_UUID);
}catch (IOException e) {
System.out.println("Listening Failed");
}
mmServerSocket = tmp;
where, mBluetoothAdapter is the BluetoothAdapter object used to handle all
Bluetooth related operations of the Android phone and mmServerSocket is the final
established ServerSocket object; it will be null if no incoming connections were
present. Once another peer requests connection through this ServerSocket, the socket
(of the client) is accepted to acknowledge and establish the connection. As and when
this socket is accepted, the peers are said to be connected and data exchange can
now take place over the serial Bluetooth link established for this communication. The
following code is self-explanatory; it refers to accepting the socket from the device:
if (mmServerSocket != null) {
try {
socket = mmServerSocket.accept();
device = socket.getRemoteDevice();
} catch (IOException e) {
System.out.println("Socket not received");
break;
}
The object device can be used to get all essential information (related to
Bluetooth SPP) of the client device Ex. Devices Bluetooth Name, address. Having
established the connection, the sockets input and output streams need to be accessed
to transmit and receive data over the serial link. This is done as follows:
InputStream tmpIn = null;
OutputStream tmpOut = null;
try {
tmpIn = socket.getInputStream();
tmpOut = socket.getOutputStream();
} catch (IOException e) {
}
mmInStream = tmpIn;
mmOutStream = tmpOut;
The last two assignments ensure that reliable InputStream and OutputStream
are available with the final objects mmInStream and mmOutStream. Data can be
received as bytes through the input stream, grouped using characteristic delimiters and
used elsewhere in the application. Ideally, delimiters arent required; data can be
received every time as a set of bytes (ASCII values) and converted back into the
required datatype. But, this works only for applications like chat where the human
typing speed is slow compared to the processing speed. But, for real-time data
reception, data often gets chopped out due to synchronization issues. Thus, delimiters
help in grouping data reliably and processing them.


















CHAPTER 5
SYSTEM IMPLEMENTATION DETAILS
6.1 OVERVIEW
The following block diagram gives a complete recap of what has been
discussed separately in the previous three chapters. The subsequent sections will
explain the logical flow of our project providing intermediate results to give a good
understanding of how the complete system was successfully developed.

















6.2 BLUETOOTH MODULE
Given that the ECG extraction system is available, it must be interfaced with the
PIC microcontroller for data sampling and ultimately transmitted to the Bluetooth
Assumed to be available as input to our system
Electrodes (attached
to the patient)
ECG Extraction
Circuit
PIC Microcontroller ADC
(using internal RC Clock)
PIC Microcontroller
USART Module (9600 bps)
Bluetooth Module
USART Rx
Bluetooth Module
(SPP) Transmitter
Android Bluetooth
(SPP) Receiver
Android
Application
Dynamic Graph Plot &
Data Backup in SD card
Monitoring & Alerting System
using Pan-Tompkins Algorithm
Band Pass
Filter
Differentiator
Sample
Squaring
Moving Window
Integrator
R-peak detection
using our (modified)
thresholds
Heart Rate
(HR)
Calculation
Average HR
over 5
R peak pairs
Raise
alarm if
abnormal
Fig 5.1 Block Diagram
module for further transmission to the Android phone over the serial Bluetooth link.
For this to be successfully established, a reliable and convenient Bluetooth module is
required. The choice of such a module for our project is the BLueLINK Bluetooth
module manufactured by Rhydolabz Technologies Private Limited. This module
supports only the Serial Port Profile (SPP) feature of the Bluetooth technology. It has
essentially five pins for establishing communication with any Bluetooth SPP enable
device or application: Vcc (5V) and Ground pins, UART transmit and receive pins,
and a RESET pin.

The datasheet provided along with the module gives a good description of the
working of the module. A separate file also lists the set of external AT (Attention)
commands used to configure the module. Once the module is powered up, it returns
\r\nOK\r\n, where \r\n represents Carriage Return and Line Feed (CRLF). The
module then sets a 60sec. timer within which it expects the command LLL to enter
command mode. Once it successfully enters command mode, it can be configured
using the provided AT commands. Essential commands alone are listed below to
provide a sense of completion:
LLL Enter command mode
\r\nAT+MODE=1\r\n Set the device in master mode (only transmit over the link)
\r\nAT+BPAIR=?\r\n Obtain details of the currently paired device
\r\nAT+CON\r\n Connect with this paired device (to start data transmission)
For each of these commands, there is a characteristic reply from the module,
the details of which are given in the external commands list provided by Rhydolabz.
All these commands, and subsequently data, are input to the module using the UART
Fig 5.2. Bluelink Bluetooth Module
(Universal Asynchronous Transmitter Receiver) pins. Once the device has been
successfully connected to a SPP supported application, data is also transmitted using
wired, serial UART link. The module, when operated in the master mode, blindly
transmits the data received through UART over the serial Bluetooth link established
with its peer application. An important point here is that the data rates of both the
UART and Bluetooth serial link have to be synchronised to avoid data loss.
Understanding the Bluetooth module:
The crux of interfacing the Bluetooth module for data transmission has been
provided above. The experiments conducted to understand this communication
perfectly will be described next.
To prevent any hardware mistakes from interfering with our experiment, a
laptop was used to serially connect with the module, provide commands and transmit
data reliably. But, the problem with directly interfacing with a laptop is the difference
in power logic implemented i.e. the laptop supports only USB communication while
the module supports only 5V serial TTL. To overcome this mismatch and establish a
proper interface, a USB to RS232 converting cable was used to connect with the
laptop. At the other end, a MAX232 IC was used to convert RS232 logic to 5V TTL
and thus interface with the Bluetooth module. Having established connections, the
application called AccessPort137 (similar to the standard HyperTerminal application
but a freeware and also better than it in a few aspects) was used in the laptop end to
transmit and receive data via UART communication. The well-known loopback test
was executed (by shorting the Tx and Rx pins of the RS232 cable) to ensure proper
connections. Having done the wiring perfectly, the port (where the USB side of the
cable was connected) was opened in the application and subsequently, the Bluelink
module was powered-up. As expected, the module returned \r\Nok\r\n thereby
confirming proper working. Then, various commands were tested with the module
and with time, the modules working was comprehended accurately. To determine the
status of the module, a green LED is also provided; it glows when powered-up
confirming SPP support and is put off when data transmission takes place.
Once powered-up, the module is detectable by any other Bluetooth-enabled
device. To keep things simpler, the laptop itself was chosen to be the SPP receiver for
the module. Firstly, the module was paired with the laptop using its default passcode
after which two dedicated virtual COM ports was assigned by the laptop for
communicating with the module once for transmission and the other for reception.
Since the requirement is to just receive data transmitted via the module, the virtual
COM port assigned for SPP reception was opened in another AccessPort137 window.
The following steps were executed sequentially to receive data in this port:
1. As an example, assume that COM9 is the port in which the USB side of the
cable is attached and COM24 is the virtual COM port for SPP reception.
2. Open COM9, power-up the module and give command LLL.
3. Command the module to be in master mode.
4. Check if the laptop is the currently paired device; else pair with it
5. Open COM24 in a separate window and give Connect command via COM9.
6. Check if the green light is not glowing to ensure that data can now be sent via
the module. Once this is done, proceed to the next step.
7. Transmit any data via COM9 and see it being received via COM24.
8. This ends the series of steps to establish data communication via the module.
Interfacing Bluelink with PIC Microcontroller:
Once the Bluetooth module was mastered using the previously described
experiment, the same procedure was automated using the PIC16F877A
microcontroller. The module was directly connected to RC6 and RC7 (Pins 6 & 7 for
USART Tx and Rx) of the controller as there is no power logic conversion required
between the module and the microcontroller. As the replies from the module (for
various commands) need to be checked before providing subsequent commands,
assembly language coding would be tedious and unsuited for the microcontroller.
Hence, the codes were written in C language using the MikroC Pro for PIC
software developed by MikroElektronika Inc. and tested using Proteus 7
Professional simulation software developed by Labcenter Electronics Inc. before
being implemented in hardware. Even though the Proteus simulation worked well, the
communication was not as expected in hardware. It was observed that, the command
were executed perfectly and data were also received properly. But, the code didnt
end there and it started transmitting the command strings as data through the module.
This was debugged to understand that the main( ) program in MikroC is always put in
an infinite loop and executed. So, once connection is established via commands, the
data is transmitted and that ends only the first iteration. Then, the main( ) program is
executed again which is when all the commands sent via UART are interpreted as
data by the module (since its already connected) and sent to the receiver application.
As the simplest possible solution, an infinite while loop was put at the end of data
transmission. To assist in debugging, LEDs were also extensively used.
Finally, the same process was repeated by setting the SPP receiver as the
Android application. This will be explained in more detail after the next section.
6.3 ANDROID APPLICATION
The most challenging aspect of the project was undoubtedly the development
of an Android application tailored to the requirement in hand. As a first step in this
venture, the exposure to a one day workshop on Android App Development
conducted by Gatik Solutions Private Limited was very useful and effective in
providing a clear roadmap for developing a good application on the Android platform.
The knowledge gained from the workshop is consolidated as follows:
Basic knowledge on the Android framework
Installation of the popular software Eclipse and integration of the Android
Software Development Kit (SDK) with Eclipse
Elementary Java coding for Android applications
Creating and developing an Android application using Eclipse
Some conventions and structured Android programming
Exporting the application as an Android Application Package (APK)
Installing the application on an Android phone and working with it
Some online communities and forums for discussion related to Android
With the insight got into Android application development as a result of this
workshop, a simple chat application was developed to familiarize with this new
knowledge. In the process of developing this very basic application, some
fundamental concepts of Java and Android were mastered which include but are not
limited to: layout design, setting permissions for the application, accessing external
memory, Java libraries for Android.
The experience gained from developing this application provided the
confidence to start the ultimate application required for the ECG monitoring system.
But, it required more features in addition to those already stated. These are listed as
follows along with the methodology adopted for enabling them
1
:
5.3.1 STATIC GRAPH PLOT
To retrieve previously backed up ECG data of the patient and plot it. Since this
is done offline (with respect to the real-time Bluetooth communication), it is termed
as a static graph plot.

The primary tool for plotting any kind of graph on Android platform is the
Canvas class. It provides sufficient resources for plotting graphs of various types
like line graph and bar graph. As line graph perfectly suited the requirement, it was
chosen for graph plotting. The idea of plotting is very simple: the screen is taken as a
two dimensional space, each point represented using x and y coordinates. The only
peculiar thing of this Canvas is that the origin (0,0) is taken as the top left corner
instead of the conventional bottom left corner of the screen. Initially, this led to some
confusion while coding but through practice it was familiarized. The method called
drawLine(start_x, start_y, end_x, end_y, paint) provides an easy way of drawing a
simple line segment given the coordinates of two points to be joined. Here, paint is a
variable which has associated characteristics like line thickness, line colour etc. Then,
the y axis of the screen was divided in both axes based on the minimum and
maximum entries of the data matrix to be plotted. For convenience, the x axis was
chosen to be representing the sample index of each data value in the data matrix.
(Ultimately, since the sampling frequency for the ECG data is known, these indices
can be directly mapped to time values). All these are coded as a separate class which
is then instantiated in the code running the main application. When a valid file is
selected for plotting, the values present in the file are extracted into one matrix and
fed into this class to obtain the graph for that particular set of ECG data. As will be
explained later, the Pan-Tompkins algorithm is applied over this data, peaks are
detected and the average heart rate for the dataset is calculated and displayed along
with the graph plot.




1
The online community called Stack Overflow was of immense help in developing the application
5.3.2 DYNAMIC GRAPH PLOT
ECG data have to be received in real-time over the Bluetooth SPP link with
the Bluetooth module and be plotted incessantly. As this refers to a dynamically
changing graph, its termed as a dynamic graph plot.
The logic used for dynamic graph plotting is the same as that for static graph
plotting. The only change is that, while graph plotting only takes place once for the
static plot, it is executed repetitively as more and more data becomes available for
plotting. The graph is shown moving the same way as a series of photos are
converted into a video. This is done as follows: the whole screen is divided equally by
7200 lines and the data matrix size is also fixed as 7200 (a number decided upon for
better visual appearance). This matrix is firstly initialized with zeros. As and when
new data is available over the SPP link, it is appended to the end of matrix and a left
shift is executed to keep the size constant at 7200. Each value of the matrix is plotted
on each vertical line and the height is decided by comparing it with the vertical labels
(data values dynamically decided using the current entries in the data matrix). Also,
the Pan-Tompkins algorithm is applied on every (refreshed) data matrix to determine
average heart rate and analyse it for abnormal behaviour. In real-time, this is
accomplished using the concept of multi-threading which will be explained next.

5.3.3 MULTI-THREADING
In the application that is required, there are two main tasks to be carried out in
parallel and that too in real-time. In Java terminology, such multi-tasking is called as
multi-threading, where each of the tasks are implemented as threads (which is
essentially just another Java class). The two parallel tasks that need to be run are:
dynamic graph plotting and data backing up in external memory; and, data monitoring
using the Pan-Tompkins algorithm (which will be explained later).
For the required application, once Bluetooth SPP communication is
established (which by itself requires two threads), the graph plotting and monitoring
threads are turned on. Backing up of data is done in the graph plotting thread itself. A
Boolean variable is associated with each thread to have control over it i.e. only if the
variable is set to true, the thread is allowed to run. When the application is
terminated, all threads are cancelled.

5.3.4 BLUETOOTH SPP COMMUNICATION
All Android phones will support Bluetooth but they need not have a Serial
Port Profile supported application running in them to enable this feature of the
Bluetooth technology. Since the Bluelink module supports only SPP communication,
it is required that this is enabled in the phone through the application so as to
successfully establish connectivity with the module. Preliminary testing of this
communication was done by pairing the phone with a laptop. Then, to obtain a virtual
COM port for the phone, the application was run (on the phone) by which the laptop
acknowledged the SPP capability of the phone. Once assigned the COM port, data
was transmitted through this port (using AccessPort137 software) and received in the
Android application. This experiment provided the knowledge of establishing this
communication. The complete explanation of how SPP communication is established
has already been explained in section 4.2 of this report.
The explanation for every feature of the application is described below
supplemented with snapshots to provide better understanding and appeal.

Home Screen:
The screen shown below (left) is the one loaded when the application is run.


Fig 5.3 (left) Home Screen; (right) Home Screen after enabling Bluetooth
The files present in the applications folder in external memory are retrieved as
a list and displayed. Here, the file ecg_csv.csv has been chosen. The button names
Plot Graph is used to perform Static Graph Plot with the chosen file. Once
Bluetooth is enabled and the button Access your devices is pressed, the devices
already paired with this phone are displayed as a list as shown in the figure (right).
Since the need is to communicate only with the Bluelink module, communication has
been restricted only to this module in the code running this home screen. The button
named Dynamic Signal will start SPP communication with the module and plot real-
time ECG data incessantly.

Static Graph:
The following figure shows the screen where ECG data is retrieved from the
sample file ecg_csv.csv and plotted.


The x axis represents the sample index while the y axis represents the ECG
strength (voltage) as received from the SPP link. It can also be observed that the blue
lines represent the R-peaks detected by running the Pan-Tompkins algorithm on the
chosen dataset. The average heart rate is calculated (as explained in section 2.2 of this
report) and displayed too for diagnosis. Some more features have also been
incorporated for better user interface (which is of paramount importance according to
the Android community). The graph can be zoomed using two-finger gesture to look
into intricate details. (Two-finger gesture: press screen with two fingers and drag the
Fig 5.4(a) From sample file
fingers in opposite directions to each other to zoom in; drag them towards each other
to zoom out). The axes auto-adjusts during zoom-in and zoom-out.



Dynamic Graph:
A screenshot of dynamic data reception is given below in the figure.


Once connection has been established (as described in section 4.2) with the
Bluelink module, the thread for dynamic graph plotting is triggered. As and when data
Fig 5.4(b) From dynamically backed up data
Fig 5.5 Dynamic Graph Plot
is received, the screen is updated with the new value and refreshed. This provides the
moving feeling for the user. The Pan-Tompkins algorithm is run in real-time which
detects the R-peaks, measures RR intervals and updates the heart rate as the average
of five successive heart rates. This is done to ensure that there is no erroneous heart
rate displayed since it can change by a high margin for two consecutive R-peak pairs
i.e. the heart rate measured using two consecutive R-peaks can be very different from
the one obtained from the next two consecutive R-peaks. The heart rate measured is
continuously updated on screen. It is important to note that this is the only parameter
being monitored for abnormality.
The results of the modified algorithm, tested using MIT-BIH Arrhythmia database are
discussed below:
Table 5.1 Results of Modified Pan Tompkins Algorithm
Sample
ID
Actual
number of
R peaks
Number
of R peaks
detected
Actual
average RR
interval (sec)
Calculated
average RR
interval (sec)
Error
%
100 13 13 0.7606 0.7056 -7.23
102 12 12 0.7808 0.7807 -0.01280
105 14 14 0.7565 0.7125 -5.8
112 14 14 0.6701 0.6757 0.83
114 9 9 0.9011 1.1030 22.4059
118 12 12 0.7785 0.7858 0.937
121 10 10 0.9389 0.93944 0.0574
123 8 8 1.1315 1.1415 0.88
201 14 14 0.6885 0.6888 0.0551
203 19 20 0.5065 0.48083 -5.06811
205 15 14 0.7564 0.6699 -11.43
207 10 10 0.9325 0.92722 -0.56621
209 15 15 0.6276 0.58537 -6.7288
210 16 16 0.6012 0.6063 0.845
212 15 15 0.657 0.6564 -0.091
215 18 18 0.5244 0.5248 0.0762
219 13 130 0.7385 0.7388 0.0406
221 13 13 0.7530 0.7536 0.07968
223 12 12 0.7875 0.7365 0.06793
228 12 12 0.7875 0.7877 0.02539
231 10 10 0.9501 0.9502 0.010525
232 8 11 1.0646 0.7747 -6.7288
234 15 15 0.5956 0.6416 7.7233

The original Pan Tompkins algorithm detects 99.3% of QRS complexes when
tested with standard 24 hours MIT-BIH arrhythmia database but has the disadvantage
of back tracing ECG data if no R peak is detected within 166% of the current RR
interval. This increases complexity when implemented for real time systems. But, the
modified algorithm sets simple thresholds to detect R peaks which have produced the
above mentioned results. Moreover, these results are obtained when tested with 10
second samples from the MIT-BIH arrhythmia database. When compared with results
obtained with 24 hour samples the error will definitely be higher as the number of R
peaks (used for calculating average RR interval) is lesser. But it is found that the
accuracy is still 93.75% which is satisfactory for preliminary ECG monitoring in
ambulatory conditions.


















CHAPTER 6
FUTURE SCOPE AND CONCLUSION
6.1 FUTURE SCOPE
The work described in this report is just a first step towards developing a
concrete system for continuous surveillance of cardiac patients. There is a lot of scope
for research in various aspects of the described system which include but are not
limited to the following:
1. The Bluetooth communication protocol is not very suitable for biomedical
applications as the frequency of operation is very high (2.4 2.45 GHz) which
could itself be injurious to the patients health as signals are continuously
transmitted over this frequency range.
2. The Serial Port Profile communication is not very reliable for continuous data
transmission. As explained earlier in section 4.2, a delimiter is appended to
every sample when transmitted from the microcontroller. At the receiver end,
bytes of data are combined until a delimiter is reached. This works fine for
applications like chat where user input is far slower than the processing speed.
But, for real-time data transmission, the issue of speed synchronization causes
critical problems with respect to data integrity. For example, if a value
0.69542 is transmitted, there is a good possibility that the SPP receiver
decodes it as 0.69 and 542 separately even when delimiters are used. For an
application like ECG monitoring, such issues are impermissible. However, this
could be overcome by slowing down the speed of transmission which in turn
implies that the data sampling rate gets affected. This could result in loss of
critical values and ensuing alarms could be erroneous. Thus, a dedicated
communication protocol needs to be established for reliable reception of data,
especially for such short range biomedical applications. Evidently, this is a tall
task which could spawn a lot of research areas.
3. The Pan Tompkins algorithm implemented in this system is a good start
towards developing an efficient ECG feature extraction algorithm but need not
be the best. Algorithms specific to ambulatory ECG monitoring could be
devised as a result of which the processing speed could be increased.
4. PIC16F877A microcontroller is one of the simplest options chosen here to
provide just a proof of concept. Advanced controllers could be manufactured
tailor-made to such biomedical applications so that problems such as
customized sampling rate and data transmission could be avoided making the
system more robust, convenient and also commercial.
5. This work assumes that an ECG extraction module is already available for
ambulatory conditions. Ultimately, the whole system depends on the accuracy
of this module. Since it needs to be attached permanently to the patient, the
module needs to be compact, accurate and user-friendly thereby not causing
much inconvenience to the patient while engaging in daily activities.
6. Android platform has been chosen for receiving and monitoring ECG data in
real-time. Efficient coding techniques could be employed to improve the
performance of the application. Moreover, research could be carried over other
such Operating Systems to enhance the effectiveness of the application.
7. Cloud storage technology could be incorporated into this system to provide
speedier treatment to the patient under abnormal conditions i.e. in addition to
storing data in the phones external memory, data could be synced online with
the patients medical account (whenever abnormal conditions occur) to which
his/her physician has free access. Once an abnormality is conveyed to the
physician, a virtual appointment could be fixed with the patient and recent
ECG data could be analysed by the physician even before the patient arrives to
the clinic/hospital. This would greatly improve the efficiency of time
management in providing immediate treatment.

6.2 CONCLUSION
Cardiac diseases have become common even among youngsters today. So, for
minor risk patients, it is infeasible to be admitted in the hospital for continuous
monitoring. Thus, a system is required to continuously monitor such patients and
provide virtual communication between the physician and the patient.
The work described in this project is an attempt towards developing such a
system. As a proof of concept, simple communication modules have been employed
which need to be replaced with sophisticated ones for commercial implementation.
Assuming that ECG extraction system is available for mobile conditions of the
patient, a system has been shown to be working satisfactorily by transmitting sampled
version of the continuous ECG signals to the patients Android phone via Bluetooth
Serial Port Profile communication. The modified ECG monitoring algorithm has been
proven to produce 93.75% accuracy under worst case testing condition using 10
second samples from the standardized MIT-BIH Arrhythmia database.