ENGR 499: Wireless ECGMichael Atkinson

Patrick CousineauJames Hollinger

Chris RennieBrian Richter

Introduction and Project HistoryOur 499 project is to design and build the hardware and software for a wireless

Electrocardiogram device, and to create a corresponding Android application. The envisionedend product is one that a person with known heart problems can use for twenty­four­hour ECGmonitoring and feedback.

This project is based on several 399 projects from fall 2012 ­ one detailed the hardware,and another the software specifics for this device. We think that the hardware portion is going tobe straightforward, and not large enough on its own to be a 499 project, while the softwareportion is complex enough that pieces can be worked on independently and in parallel.

ElectrocardiogramsElectrocardiograms (ECGs) are used by medical professionals to monitor the heart of a

patient. These devices usually operate with 12 leads connected to the patients skin in aprescribed pattern. An ECG can be used to detect abnormal cardiovascular symptoms,measure heart rates, and monitor heart diseases. The most common non­medical application ofan ECG is to measure a heart rate during a workout, however, the aim of this project is toprototype a device that could aid remote monitoring and feedback.

The most important components of the ECG that the device needs to report include Pwave, QRS interval, and the T wave. These waveforms have the inherent issue that themeasurable signals have amplitudes in the range of 0.1mV to 10mV. Another issue with thesesignals is that the smallest time components last as little as 50ms(The PR segment), or 80ms(The entire QRS complex). This short time means that the sample speed for the signal needs tobe significantly less than 25ms to ensure adequate sampling.

The device will not offer any medical opinions, but could valuable in monitoring fornon­continuous heart conditions and heart condition triggers that are not replicated in a hospitalor clinical setting. As a result, the user would not need to continuously monitor the device, butcould save and send abnormal conditions as they are encountered. This functionality has not yetbeen implemented, but is part of future plans.

Hardware - building an ECGThe original hardware proposal was to build the circuit using a series of amplifiers and

filters. The figure below shows the proposed block diagram for the hardware components.

LeadsThe current prototype has a three lead system. The prototype leads were made by

soldering pennies onto a long wire to create a receiver for the small signal produced by the heart.Pennies were used due to their availability, low cost and high conductivity. Unfortunately, themagnitude of the signal produced by the heart is in the 0.1­10mV range, and is very susceptibleto noise from motion, other body functions, and background noise. Two of the leads areconnected across the heart to detect a signal, while the third is placed on the body to create aground reference.

AmplifierThe current design uses a single instrumentation amplifier with a high gain. An

instrumentation amplifier was chosen because the heart signal has a floating reference. Themodel number of the chip used is the Texas Instruments INA126P. Using a total gain of around1000, the signal will be in the range of 100mV to 1V. However, this signal will contain a largeamount of noise that needs to be filtered out. The primary sources of noise will behigh­frequency noise and 60Hz power line interference due to our long leads. The diagram belowshows the internal configuration of the instrumentation amplifier.

High-Pass FilterThe first stage in the filter network is a passive high pass filter with a 0.1Hz corner

frequency. This filter removes the DC offset in our signal, and the corner frequency is set verylow due to our signal components residing near 1Hz. The diagram below shows the designedhigh­pass filter.

Notch FilterThe second stage is a 60Hz passive notch filter. This filter is crucial due to the leads

used by the ECG. These function as antennas and pick up the 60Hz noise from power lines.

The diagram below shows the designed notch filter.

This passive filter network may be replaced in the future with an active filter to increase the Qfactor of the filter.

Low-Pass FilterThe low pass filter is designed with a corner frequency of 400Hz. This removes the

unwanted high frequency noise from the waveform. As well, removing unnecessaryhigh­frequency portions of the signal will decrease signal bandwidth. A passive filter networkwas chosen as it is significantly easier to implement than an active filter. In the future, a secondgain stage will directly precede this low­pass filter. This is because we do not want to amplifythe 60Hz noise as well. The diagram below shows the designed dual low­pass filter.

ADCThe ADC is a critical component of the ECG module. It takes the received ECG signal

from the electrode circuitry and digitizes it for transmission to the mobile phone application. Atthis stage of the project, we have chosen to use a Raspberry Pi microcomputer in order to fill theroles of ADC and bluetooth modules. Running a distribution of Debian Linux, the Raspberry Pi iscapable of both the analog input and digital bluetooth transmission components of the ECGsystem. In the future, we would like to utilize an application­specific microcontroller for this

portion of the project. For our prototyping stage, however, the Raspberry Pi is easy to use andimplement.

Raspberry Pi

Bluetooth/FirmwareAt this stage of the project, we chose to utilize a Raspberry Pi linux­based computer in

order to handle the firmware side of the ECG. Utilizing a Python program, the Raspberry Pi willpair with and connect to the phone­based android application using a USB bluetooth radio.

RTOS vs non RTOSStandard operating systems focus on doing as much computation in the shortest time

where real time operating systems put an emphasis on having a predictable response times. Toensure a predictable response time in the ECG it would be ideal to be using a real time operatingsystem. For the prototype we are building we will be using a standard linux distribution. In light ofthis, the prototype ECG, running off of a Raspberry Pi, should meet any real time constraints thatwe have since the processor is overpowered for our application. We believe that the overheadfrom running a linux distribution should not significantly affect the sampling rate.

Why not Arduino?We decided against using a widely available programmable microcontroller (such as

Arduino) because of budgeting and complexity concerns. It creates a level of complexity whentrying to send data over bluetooth. Using the Raspberry Pi with an attached usb module is trivial.The bluetooth library can be installed onto the Pi with a simple package installation.

Software ProgressThe Android application portion of the project is progressing steadily, although we have

had to deviate from the timeline. The timeline put major emphasis on the Bluetooth readingsoftware component, as it blocked other tasks and components. However, we were not able todevelop a hardware prototype as quickly as we planned, and thus had no device to transmitBluetooth to test the Bluetooth server. Another false assumption we had made was that Android

would have a very simple Bluetooth wrapper library which would be as simple as Android’sBluetoothAdapter object with which we had previous experience. Unfortunately, the Bluetoothconnection involves setting up a listening Bluetooth server, and then servicing the connection ­and while this is not terribly difficult, it was more than we were expecting for this segment, andthe increased complexity means more testing is required once we have a Bluetooth device totest. Bluetooth being blocked did not stop work on the whole application though: with somesample ECG data we created manually from a signal­generator we were able to work on thesignal­charting component, making substantial progress.

Deviation from original design

As we put work into the software, it became apparent that the three application goalsfrom the project’s outset were large in and of themselves, let alone reading the Bluetooth data.We decided to focus on displaying the chart to the user and saving the data, and to not focus onthe “user notification/signal analysis” portion. No group member is particularly well­versed insignal analysis, or of ECG analysis, and testing of the feature would be involve simulating a heartattack from the Bluetooth data. This feature may be added in the future, but for now we willfocus on just those two goals.

We feel both goals are manageable: saving the data should be simple ­ if Bluetooth datacan be read properly, then it can be stored in a temporary data structure and saved in parallel.Displaying the chart gives the most feedback to a user, but is more difficult than saving: how“real­time” should the display chart be? What amount of lag is acceptable? Should sensor datamore than X seconds old be thrown out? What sampling rate should the hardware use toensure the phone can process it in time? These questions will have to be addressed as theBluetooth reading module is completed and we can test the app with an actual adjoining ECGsensor. Also, since this chart is the most user­facing section of the application the UI will haveto be carefully crafted to give the best look and feel possible. The toned­down project design isreflected in the adjoining figure.

Figure 1.1 Android Application design without Notification Module

Timeline

Date To be completed

March 1, Friday Last month: time to re­evaluategoals/progress and set a new meeting

schedule to meet our needs.

March 6, Wednesday ­Progress Meeting, ECS­124, 18:00­18:50

­Progress Report #2 submitted to Supervisor,copied to Coordinator and TA

March 11, Monday Software­ Finish “data saving” module­ Add a link from MainActivity to view datahistory.­Some work done with Raspberry Pi andBluetooth reading moduleHardware­Replace broken instrumentation amplifierand debug circuit

March 13, Wednesday Software­Have Bluetooth reading module finishedHardware­insert amplifier stage between notch andlow­pass filter stage

March 15, Friday Software­Chart module should be displaying streamingBluetooth dataHardware­Duplicate amplification and filtering stages toensure 5 leads

March 20, Wednesday Final Presentation­Preliminary presentation designSoftware­UI and overall “look and feel” should beacceptable quality.­Layout/transitions should be finalized.

March 25, Monday Equipment Loan List for Project Demo totechnical support staff

Final Presentation­Poster design completed

March 27, Wednesday Final PresentationPoster printing (at ZAP?)

March 29, Friday Poster Presentations starts at 16:00;Engineering Lab Wing Lobby; Setup starts at13:00

April 5, Friday Last day of classes, Final Report submitted toSupervisor (grade penalty may be applied tolate submissions), project URL submitted tothe Coordinator and TA

April 11, Thursday Coordinator receives grades fromSupervisors for Progress Reports and FinalReport and Website evaluations from panel ofjudges