Adapting BLE Protocol For
Medical Standard ECG Transmission
Sudheer Babu*, Sai Prem Shaji, Abhinay Vishwanatham,
K V Sai Sundar , Amar Sainath Reddy T , Siva Sankara Sai Sanagapati
Department of Physics,
Sri Sathya Sai Institute of Higher Learning
Prasanthi Nilayam, Andhra Pradesh, India
babu5tss@gmail.com*
Abstract—Smart solutions for cardiac monitoring are need of
the hour in tackling the devastating effects of heart diseases
that are plaguing the world today. Cardiac monitoring and
screening technologies like Electrocardiography (ECG) need to
be moved out from within the confines of hospital walls to
places within easy reach of the wider mass of the countrys
population; through remote deployment in primary care centers
and homes. Affordability, accuracy and deep penetration are
key to the success of any envisaged solution. The accuracy
of reports generated by a remotely deployed ECG monitor
primarily depend on the accuracy of the actual hardware making
the measurement, and can be guaranteed by choosing any of
the time tested bio-potential measurement ICs. The penetration
however depends on the technology deployed for remote access
of the ECG device. This technology must have the potential to
be easily integrated into the minimal networking infrastructure
existing in the rural areas and hinterlands of the country.
A combination of Bluetooth Low Energy (BLE) and cellular
networks, utilizing a smartphone, supporting minimum features,
as a common access point is a promising solution for remotely
accessing an ECG monitor deployed in rural areas. The challenge
however is in developing methods to reliably transmit ECG data
over both the BLE link and cellular networks meeting all the QoS
requirements of medical standard ECG monitoring application.
In this paper we first list out a set of QoS requirements
for ECG monitoring application, drawn from discussions with
cardiologists and from studying existing literature. We then
explore the feasibility of a BLE link meeting these requirements,
with supporting results from tests performed with a prototype
which we developed.
Index Terms—IOT, ECG, BLE(Bluetooth Low Energy).
I. INTRODUCTION
The need for remote deployment of ECG monitors is
twofold. Firstly, it transfers technology critical to tackling
heart diseases from secondary and tertiary health care cen-
ters closer to the patients - to primary care centers and to
homes thus enabling early detection and prevention.Secondly,
it paves way for real-time detection of heart diseases such as
arrhythmia or angina which may appear only several times
a week, in people having a history of such diseases (post
discharge from hospital) or people having a high risk of having
such diseases (aged people ) [1].The approach to developing
such technology is to pick any of the time-tested bio-potential
measurement ICs , and integrate them into a system that is
Bluetooth Low Energy (BLE) capable. The reason behind the
Satyabrataa Mohanty,
SmartX Connected Products PVT.LTD ,
Chennai, India
satya@damanju.com
choice of BLE is that it is supported by any smartphone
having minimum features and would therefore enable easy
adoption of the technology. Its use would also lower the
cost of technology by requiring the user to purchase only the
acquisition unit, which could be made extremely affordable,
while the application that runs on the smart phone, and handles
the data transmission could be distributed freely or with a
minimum charge and also BLE consumes extremely low power
which can run on battery power for a very long time a
feature that is very important in a rural scenario where power
cuts are very frequent [2]. However, in order for BLE to be
used in remote ECG monitoring, it must meet all the quality
requirements necessary to support such an application. In this
regard we first drew up a set QoS requirements that must be
satisfied by a diagnostic grade ECG monitor from discussions
with cardiologists and from existing literature [3].
The following requirements are to be met:
1) Error tolerance: The ECG monitor must ideally have
zero errors to prevent incorrect diagnosis. Since that is
not possible to guarantee, the monitor must at least have
a mechanism to discover errors when they occur, so
that those readings may be discarded. Errors could arise
from variety of sources,wrong measurement, improper
transmission, glitches in device such as battery failure.
2) End to End latency: The ECG monitor must ideally
have zero latency. In other words, the ECG measurement
(voltage) displayed on the physicians screen at any given
instant should be an accurate reflection of the voltage
generated by the patients heart at that instant. Since
this too is not possible to guarantee, there should be a
mechanism to measure the latency real time.
3) Bandwidth: The ECG monitor must support minimum
bandwidth required to capture all the details of ECG .
This is typically less than or equal to 50Hz, though in
certain cases more bandwidth might be required.
4) Throughput: The ECG monitor must support sufficient
throughput to support 3, 5 or 12 channels of ECG data,
of required bandwidth as per the use case.
5) Security: - Data transmitted must be secured against
snooping ,modification by a third party. There also needs
 to be a mechanism to detect accidental mix up of data.
Fig. 1. Relative Power VS Frequency
BLE specifications mention an application throughput of
270kbps and latency as 6ms which are sufficient for supporting
real time ECG monitoring, considering that the ECG signals
have a periodicity of roughly one second. For ECG monitoring
in telemedicine Alesanco and Garcia suggest 3-4 seconds
as the maximum acceptable delay for a reliable real-time
ECG transmission [5]. BLE uses FHSS because of which it
can operate in noisy environments and it also provides for
AES encryption which would satisfy security requirements.
The greatest benefit however is that owing to the Bluetooth
capability of most consumer devices, our solution can find
easy penetration into the wider mass of population.
II. STRATEGY
A. BLE stack:
Before we elaborate on the exact details of the construction
of our prototype and the approach we took for testing its
conformance to the QoS requirements, we briefly present here,
the different configurations possible in a BLE device. Figure:2
shows the different layers of the BLE protocol stack [6].
Fig. 2. BLE PROTOCOL STACK
The layers of the stack have been classified as host and
controller for historic reasons - the host layers would be
implemented on a host microprocessor while the controller
layers would be implemented on the BLE transceiver. This
configuration is now known as the dual device configuration.
The two parts of the stack communicate with each other
using a software layer called the Host Controller Interface
(HCI), consisting essentially of a set of HCI commands that
can be issued by the host and a set of HCI events that
constitute the controllers response to the host. Obviously, there
is also a single device configuration where all the layers are
implemented on the same processor. The HCI interface is still
used. Most of the BLE devices we come across today run
in this configuration. Another configuration that is possible
is the network processor configuration, where the host and
controller layers are implemented on one processor and only
the application layer is implemented on a different processor.
The two processors communicate with each other using vendor
specific HCI commands and events. These commands and
events work in a manner similar to the regular HCI commands
and events [7].
B. Device Configuration:
We now describe the configuration of our prototype, which
we implement in two parts an acquisition end and a display
end. The two parts communicate with each other over a BLE
link or connection. The acquisition end acquires ECG signals
from patient and transmits them over the BLE link in the form
of packetized digital data. The display end receives ECG data
over the BLE link, processes it and displays it as waveforms
to the user.
Fig. 3. DEVICE CONFIGURATION
The acquisition end consists of ADS1293 Texas Instruments
bio-potential measurement analog front end and CC2541 Texas
Instruments SoC BLE radio with 8051 MCU. ECG signals
acquired by ADS1293 are read by CC2541 over an SPI
interface and transmitted to the display end over a BLE
link. BLE protocol is implemented on the acquisition end by
running TI BLE stack version 1.3. The acquisition end is in
single device configuration.
The display end consists of a windows 8.1 PC running
JavaFX in JDK 8 environment and CC2540 SoC BLE radio
with 8051 MCU core, running TI BLE stack version 1.3. The
two are connected over a UART interface implemented over
a USB peripheral. The display end is configured in network
processor configuration, where the host layers and controller
layers of the stack are implemented on CC2540 and the
application layer alone is implemented on the PC.
C. Validation Strategy
Our strategy in testing the conformity of our prototype to the
QoS requirements was to tweak the parameters and features of
each of the top three layers (Application, GATT and GAP) of
the stack until the BLE link satisfied the said requirements.
Here is a summary of the procedure we adopted;The first
step was to get our hardware up and running. Once this was would aid in detecting battery induced errors. Figure:4 is a
done, we established a BLE link between the acquisition end representation of the way these characteristics appear in the
and display end, and started capturing ECG waveforms from GATT server at contiguous memory locations.
an ECG simulator. These waveforms had to be identical to
those produced by ADS1293 evaluation kit which had a
wired link to the display. To improve the quality of waveforms
captured, the capturing had to be done at higher bandwidth,
which translated to higher sampling rates or higher throughput.
While there was no limit on how much throughput a wired link
could support, we realized that there was an upper limit on the
throughput that the BLE link could support. For a given set
of BLE connection parameters, we would reach a maximum
sampling rate (or bandwidth) beyond which the waveform
displayed by our prototype and the waveform displayed by
the evaluation kit were no longer identical. By modifying the
parameters of the BLE stack,we could increase the throughput
and bandwidth supported by the BLE link. We then built
in a simple mechanism by which data loss errors could be
detected and experimentally validated the method. Though we
did not build a mechanism to detect measurement errors, we
Fig. 4. Characteristics Of GATT
describe here how such a mechanism could be built. By the
time of writing this paper, our focus had been on achieving Information contained in the ECG profile can be
a waveform that we could compare with a standard hospital read/written by the BLE client (display end), one characteristic
resting ECGs of equivalent bandwidth to prove the technology. at a time by supplying the UUID of the characteristic or one
Our prototype currently refreshes the ECG waveforms once in descriptor at a time by supplying the handle of the descriptor,
every 6.75 seconds, as opposed to displaying a continuously and then performing a read/write operation, provided that the
running ECG, as is required in ECG monitoring application. operation is permitted for that characteristic/descriptor (see the
We however describe how the latency can be reduced to GATT Server Permissions column).
display a continuously running ECG.

III. TAILORING THE GATT

GATT is an acronym for Generic Attribute Profile. It is
the layer of the protocol stack that handles data exchange
between BLE devices. Data exchange is implemented through
a client server mechanism. A GATT server is implemented
on the acquisition end and GATT client is implemented on
the display end. Data on the GATT server is organized into a
profile, which is simply a collection of all the parameters/data
relevant to the application (ECG in our case), arranged as a set
of formatted units called characteristics that the GATT client
and server can transact with each other.
A. The ECG profile:
The Bluetooth SIG has developed several profiles for use
in different applications. The ECG profile is a modification
of the SIGs Heart Rate profile. The following is the list of
characteristics that are defined as a part of ECG profile in the
TI stack:
ECG MEAS: The latest sample of ECG measurement
12bytes (3 bytes per channel)
ECG NUM CHANS: How many ECG channels are being
used - 3 in our implementation
ECG SAMPLE SETS: How many samples per notification
packet - 2 in our implementation.
Apart from the above characteristics the TI stack also pro-
vides characteristics for monitoring battery parameters, which
Fig. 5. Notification packet
However, the BLE server itself can periodically send out
information in the form of notifications without the client
requesting for the same. The client must initially configure the
server to send out notifications for a characteristic by asserting
the client characteristic configuration descriptor belonging to
that characteristic.
ECG MEAS characteristic can be configured this way to send
ECG measurement/error data to the display end periodically
as notifications. Each notification contains 2 samples of ECG
measurement data and a serial number to check that packets
are received in order.
Once in every 18 data notifications, a single error notifica-
tion is sent. The error notification contains information about
the connectivity of leads to the patient and the indication of
packet loss if any.
The data and error information contained in notifications is
used by the display end to update the display real time.
B. Support for over-the-air configuration:
To the set of characteristics supplied by the TI stack,
we added the following characteristics that enable over the
air configuration of the acquisition end, while it is running,
without having to disconnect the device from the patient.
ADS ADDRESS: Address of the control register on
ADS1293 which is to be read/written
ADS READ: Current value held in the register specified by
ADS ADDRESS
ADS WRITE: Value to be written into the register specified
by ADS ADDRESS
As soon as the display end writes a value into the
ADS WRITE characteristic, the MCU on that acquisition end
writes that value, to the ADS1293 control register that is
pointed to by the address value in ADS ADDRESS character-
istic, over the SPI interface. The changes in configuration will
come into effect after a brief settling time. Such a provision is
important for the reason that ECG monitors differ in the signal
bandwidth they offer varying between 20Hz and 50Hz and
the lead configuration 3 lead or 5 lead. This feature helps us to
switch between different configurations without going through
the entire procedure of editing the settings in the firmware and
debugging each time.
IV. TAILORING THE GAP
GAP is an acronym for Generic Access Profile. It is the
layer in the stack that is responsible for functions such as slave
discovery, connection set up and connection tear down. The
application uses GAP to set up a BLE connection governed by
certain connection parameters. We must set these connection
parameters optimally in order to be able to achieve the required
throughput necessary to support real time ECG data streaming.
The following connection parameters are set:
A. Minimum/Maximum connection interval:
This value determines the min/max time for which the
acquisition end waits before sending a new notification. The
lowest and highest value supported by the TI BLE stack are 7.5
mSec and 4 Sec respectively. To achieve maximum throughput,
we need to set the minimum connection interval to the lowest
value supported by the stack - 7.5mSec. However not all BLE
devices support this connection interval. Hence, the value must
be chosen according to the capability of the BLE device at the
other end of the link.
B. Slave latency:
In order to maintain a BLE connection, the communicating
devices continuously send packets to each other, even if there
is no information to transmit. These transactions are called
as connection events. The number of connection events that a
slave can choose to skip (for saving power) without risking a
disconnection is called slave latency. To achieve maximum
throughput, we do not want to skip any connection event,
hence we set this to zero.
C. Connection supervision timeout:
The maximum time between two received valid data packets
before a connection is considered lost. We set this to a large
value so that, the connection is not broken. We work with the
following values:
Min. connection interval = 8.75ms
Max. connection interval = 11.25ms
Slave latency = 0
Max. supervision timeout = 2 sec
V. APPLICATION LAYER
A. Acquisition end
The application layer at the acquisition end has two impor-
tant routines.
1) An interrupt service routine that reads ECG measurement
data and error data from ADS1293 and loads them into
a buffer for transmitting to the display end. The block at
the left end of Fig6 depicts this routine. A single sample
of data (24 bytes) is read on each interrupt and copied
into one of two ping-pong buffers data is filled into one,
while data is transmitted from the other. A flag is asserted
when the buffer is full.
2) A notification routine that periodically checks if the buffer
that holds ECG and error data is full and transmits the
data as notification packets if it is full. The block at
the right end of Fig6 depicts this routine. A timer is
configured to rise events once in every 7 milli seconds.
If the flag corresponding to a full buffer is asserted, all
the data contained in the buffer is transmitted as BLE
notification. When all the data in the buffer has been
transmitted, the buffer full flag is de-asserted.
Apart from this two important routines that are required
to stream the ECG measurement data, the application layer
also handles display end initiated GATT reads and writes.
In the special case when the display end wants to configure
ADS1293, the MCU reads/writes ADS1293 control register
values over the SPI interface.
Fig. 6. System flow chart
B. Display End:
The application layer at the display end runs on a windows
PC in a Java environment. It performs the following tasks:
1) Setting up BLE connection with the acquisition end,
which is done in three phases:
a) Initialization phase: JVM supplies the connection pa-
rameters to the BLE stack by issuing the appropriate
HCI vendor specific commands.
b) Discovery phase: BLE stack scans for advertisements
issued by the acquisition end and forwards it to the
 JVM as a HCI event, from which the JVM discovers
the BLE address of the acquisition end.
c) Link establishment phase: JVM establishes BLE con-
nection with the acquisition end using its BLE address.
2) Enabling notification for ECG MEAS characteristic.
Once enabled, the display end starts receiving a continu-
ous stream of ECG data.
3) The application runs on multiple threads. One thread
(reader thread) continuously receives the notification data
and populates a buffer. Once 25 notification packets have Fig. 7. Demonstration of data loss at measurement stage using a 2Hz
been received, the buffer is passed on to receiver thread, sinusoidal signal
where the data is processed into floating point values and
segregated into three queues, one for each of the three
channels. The queues are passed on to a display thread
which updates the ECG waveforms on the graphical user
interface.
4) The receiver thread also extracts error information from
the notification data, and passes it on to the GUI thread.
Hence the GUI gives real time update on lead connectiv-
ity and packet drops.
5) The application layer can configure the ADS1293 con-
figuration registers by writing the register address and Fig. 8. Mismatch in the counter values, indicating data loss Counter values
in the zero packet loss scenario
register value into the GATT server on the acquisition
end.
6) The application layer can also disable the notification and VII. P ERFORMANCE OF THE PROTOTYPE
terminate the connection.
A. Throughput calculation:
The design of the application end on the two ends determines
the overall latency of the BLE link. Once a BLE connection is established between two devices,
the connection parameters control the frequency and the size
VI. MONITORING PACKET LOSS: of data that can be sent between the two devices and therefore
determine the overall throughput supported by the link. In this
The requirement from an ECG monitoring device is zero section we calculate the throughput that is supported by the
loss and zero latency in acquisition of ECG data. By this we connection parameters that we have chosen. Maximum data
mean that the ECG monitor must display the instantaneous payload size per notification packet = 20 bytes and Number
electrical voltages generated by the heart, without dropping a of notification packets that can be transmitted per connection
single sample. Therefore it is important to have a mechanism interval = 6. Though this is the number mentioned in BLE
by which we are assured that no measurement data has been specifications, the correct number must be experimentally
lost and that the voltage displayed by the device is truly determined. We found only one notification packet being sent
the voltage generated by the heart at that instant. Data loss per connection interval. We may however take 6 as the upper
can occur at different stages both at Acquisition end and limit in our calculation.
data display end. The loss was monitored by incrementing The following formula can be used for calculating max
counter for every ISR that has come during the measurement. throughput: 8 x (Bytes per packet) x (Packets per connection
One counter was added at the Acquisition end and a two interval) / (Connection interval) = Throughput i.e., 8 x 20 x
byte counter at the Data Display end. Figure7 shows how a 6 / 7.5 mS = 128 kbps which gives the upper limit on the
2Hz sinusoidal signal appears in presence of data loss. To throughput that can be achieved. Our prototype can currently
generate the signal, the ECG device was used to acquire support 21.3 kbps.
a 2Hz sinusoid from a function generator. The connection
interval was increased to such a point where the rate at B. Bandwidth calculation:
which notification were sent out was much less than the rate We now calculate the ECG signal bandwidth that can be
at which data was sampled. The vertical lines in the figure supported at this throughput:
occur at a spacing of 34 samples (the buffer size). Notice that Number of samples per notification packet = 2 (per channel)
all discontinuities occur at the vertical lines. Figure8 shows Number of samples in 6 packets = 2 x 6 = 12
the counter values of every 18th notification packet (error So, 12 samples must be acquired within one connection inter-
notification) and the counter indicating the number of packets val. Hence, the maximum sampling rate that can be supported
dropped up to that point, in a lossy scenario and in a zero loss is: 12 / 7.5 mS = 1600 samples per sec. This corresponds
scenario. to a bandwidth of 325 Hz as per ASD1293 datasheet.Our
prototype can currently support 267 samples per second, which
corresponds to a bandwidth of 55Hz.
C. Latency:
Latency of the device is determined by the way the ap-
plication layer handles ECG data. At the acquisition end, it
is determined by how many samples are collected before a
notification is sent. At the display end, it is determined by how
many samples are collected before the display is updated. We
now calculate the latency of our prototype and then describe
how it can be reduced.
At a maximum sampling rate of 267 sps supported by the
prototype, the time taken to acquire a single sample is = 1/267
= 3.745 mSec 36 samples are collected before the notification
routine is called. So, latency in passing the first sample to the
notification routine is = 3.745 x 36 = 135 mSec.
Assuming that only one notification packet is sent per connec-
tion interval, and assuming 2 samples per packet, the latency
in transmitting 36 samples is = 7.5 x 36 /2 = 135 mSec. Total
latency wrt to the first sample = 135 mS + 135 mS = 270
mS. The display end updates the display only after collecting
900 samples. So, time taken by the first sample to reach the
display = 25 x 270 mS = 6750 mS = 6.75 S
To reduce the latency, we can transmit two samples at a
time and update the display as and when these samples are
received by the display end. This would reduce the latency to
15 mS. This serves as a lower bound on the latency that can
be achieved. The implementation would of course depend on
how quickly the software is able to process the data.
VIII. M EDICAL T ESTING
• We collected ECG data from 30 patients with our pro-
totype. The selection included both normal and symp-
tomatic ECGs.
• Rest ECG reports of these 30 patients, generated by
standard devices GE MAC 600 and Mortara ELI 150c
Rx, were also collected.
• The two ECG reports were shown to a cardiologist to see
if she could decipher the same information from both the
reports.
Fig. 9. Patient ECG waveforms (PLOTS RE-SCALED)
A. Doctors comments
• The match between corresponding leads in the two re-
ports was excellent. However for diagnosis, 12 leads are
a must.
• A standardization rectangle needed to be added. The
standardization rectangle is the devices response to a
pulse of known voltage and duration generated by the
internal voltage generator on ADS1293. It not only gives
doctor information regarding the scale on horizontal and
vertical axes but also helps detecting measurement errors.
• An identifier unique to the scan needed to be inserted
into the BLE notification packets. This would avoid any
potential patient-data mismatches.
IX. F UTURE IMPROVEMENTS
This is an ongoing project, with the objective of devel-
oping an affordable diagnostic grade ECG monitor for use
in telemedicine. We have now completed the first phase of
development transmitting ECG over a BLE link, and done
some preliminary work in the second phase as well using
smart phone as an access point to transmit ECG data over
cellular networks. What has been hindering our progress in
this phase is that devices from different vendors vary in the
connection parameters that they can support. Following are
our immediate goals:
1) Cutting down the latency to support real-time ECG mon-
itoring.
2) Adding support for generating a standardization rectangle
and also adding a unique identifier for the data.
3) Increasing the number of leads to 12.
R EFERENCES
[1] Jara, Antonio J and Fern’ndez, David and López, Pablo and Zamora,
Miguel A and Ubeda, Benito and Skarmeta, Antonio G, “Evaluation of
bluetooth low energy capabilities for continuous data transmission from
a wearable electrocardiogram”. In : 2012 Sixth International Conference
on Innovative Mobile and Internet Services in Ubiquitous Computing
(IMIS), pp. 912-917.
[2] Wang, Liang-Hung and Dong, Wei-Zhong and Chen, Jian-Zhi and Wang,
Fa-Xiang and Fan, Ming-Hui. “Low-power low-data-loss bio-signal
acquisition system for intelligent electrocardiogram detection”. IEICE
Electronics Express 14.4 (2017): 20161142-20161142.
[3] Eide, Rikard Bjrstad, “Low Energy Wireless ECG-An exploration of
wireless electrocardiography and the utilization of low energy sensors
for clinical ambulatory patient monitoring”. MS thesis. NTNU, 2016.
[4] Park, Young-jin and Cho, Hui-sup, “Transmission of ECG data with the
patch-type ECG sensor system using Bluetooth Low Energy”. In: 2013
International Conference on ICT Convergence (ICTC). Oct. 2013, pp.
289-294. DOI: 10.1109/ICTC.2013.6675359.
[5] Alesanco and J Garca, “Clinical Assessment of Wireless ECG
Transmission in Real-Time Cardiac Telemonitoring”. In: IEEE
Transactions on Information Technology in Biomedicine 14.5 (Aug.
2010), pp. 1144-1152.
[6] Townsend, Kevin, Carles Cuf, and Robert Davidson. ”Getting started
with Bluetooth low energy: Tools and techniques for low-power
networking. ” O’Reilly Media, Inc., 2014.
[7] Texas Instruments, “TI BLE Vendor Specific HCI Reference Guide,
Version 2.1.0”. 2014.
[8] Sakamoto, Takuya, et al. “Remote heartbeat monitoring from human
soles using 60-GHz ultra-wideband radar”. IEICE Electronics Express
12.21 (2015): 20150786-20150786.