Forum: Hardware

Randy -

I've always wondered how much precision is needed for an ADC applied to sampling EKG waveforms - is 12 bit precision adequate or something higher?

> Could the open source Arduino board be a starting point in developing our ECG?

Hi to everyone!
My name is Robert and me and two other colegues in my school are interested in building an arduino based ECG. The general scheme has an amplifier stage, a circuit to base the level of the signal, and then, the semi-processed signal is connected to the arduino via one of its analog inputs, an then a filtering processing in the inside, using IIR filters as necessary (which we haven't designed yet), and finally, the arduino board is connected to the computer and the ECG visualized using the 1-channel arduinoscope (((http://code.google.com/p/arduinoscope/wiki/Usage))).

Until now, we got the circuits for the amplifier and the one to level the signal designed and tested, but still working on the filters and the interfacing with the arduinoscope. We are having in mind Randy's advices on what to consider to build our ECG. Soon we will share the schematics and any other work done until now.

(apologies for my poor english, it's not my native language)

That is incumbent to accomplish a greatest level thesis when scholars are studying at the high school. Thence, your superior topic just about this post can be a very good issue for the graduate thesis composers.

Thanks a lot that you made the useful knowledge just about this good post. But, to choose the experienced writing services, all students suppose read about papers for money.

Kodar, why dont you share your ecg with us. It would be interesting to see your work. I suggest that you write a new wiki page under Hardware>DIY ECGs (http://www.open-ecg-project.org/tiki-index.php?page=Hardware)




> I have build an ecg with the ardiuno. But I use it only for its ADC module and to send data to pc. There is impossible to build an ecg only with arduino without an analog front-end.

> Could the open source Arduino board be a starting point in developing our ECG?

I have build an ecg with the ardiuno. But I use it only for its ADC module and to send data to pc. There is impossible to build an ecg only with arduino without an analog front-end.

My thesis is "ECG signal generator"? Can you help me?

I just over christmas built my ecg according to Jason Nguyen (only with the LM324 as op-amp) :) As I had an arduino laying around, I tried the atmega's ADC to get a digital signal over USB. It works ok, but not great. Here's the resulting graph:



As you can see, there's a lot of 50Hz noise and also some lower frequency noise as well (around 3-4Hz). The blue line is the original, the black one the trendline with the median of (I think) 3 values.

> Could the open source Arduino board be a starting point in developing our ECG?

From a past experience on making a computer based ECG, arduino will probably not make it, because of the amount of data it would need to deal with, and surelly, the amount of noise from the electric network and from the USB port.

A good option (but not so cheap) are the Texas Instruments DSPs, which are made for real time applications (like a ECG).

You're much more experienced than I & I look forward to working on this project with such capable people.

I have not had a chance to play with PICs as yet, although this is very much on the to do list for the future.

Taking the path of least resistance is a characteristic I share with electricity, and to me, if a PIC/araduino style solution has done the work we can piggy back it (the latter, as you have explained, is insufficient).

I like your spec for the ECG, however, banana plugs? I initially planned to use banana plugs, but found the 50Hz noise levels to be substantially lower with shielding connected to case ground on RCA plugs. I know this is a very minor point!

A criticism of the solution proposed earlier has also been the consumables problem - i.e. the electrodes. I note with interest that my oldest ECG came with both clamp and suction electrodes. If reinvented a little, these have significant promise for patients, although only the former could be useful for long term monitoring. There's no point making a fancy 12 lead ecg if the hospitals can't get their reddot electrodes.

Often the smallest problems can have easy solutions and yet a big impact for health care systems.

I don't know if I am exactly following your statement re legalization. I am aware that hospital equipment (and all med equipment) has to pass a number of safety checks, starting with CE and moving right through to immersion & cross current checking (e.g. from a defib) etc etc. Is there any way to sidestep these, or will they have to be combated every step of the way?

Even a single $50K compliance cost would sink this project beyond help, so if we can avoid this it would be wonderful.

My original avoidance of recertification was to use the retired equipment and sidestep the regulation. This is more 'OK' using the oscilloscope output than soldering directly to the PCB, however.

Many of these compliance costs, I suspect, could be reduced by creating the ecg as a computer dependent accessory rather than a stand-alone piece of diagnostic equipment.

As with all physicians and physicians-to-be, I am very concerned about the efficacy of diagnostic software, and don't see this as a great solution. I would assume that automated defibs have a very high specificity and a very low sensitivity (comparatively) to avoid the risk of shocking a healthy heart. Hence, also, the negative predictive value would be quite high.

This is OK for a defib, but not so OK if a piece of software is being used as a diagnostic tool. Hence, as I think you are suggesting, telemedicine is probably the answer with auto diagnosis of common problems, e.g. Vfib (sometimes emulated by noise), Vtach and asystole (also problematic if connection problems).

Hi mhandmer...You're exactly right - noise and safety are indeed of great importance. Your use of the ECG machine and reverse engineering was very impressive - all done without schematics! Yes, I've worked for several companies as an ECG/cardiology product manager/consultant. I've had a hand in the development and manufacturing of a number of ECG/stress machines, plus I like build things myself. I'm more into PICs and have done a couple of 68HC11 projects which have a little more power than the arduino (which I admittedly haven't tried yet).

You are also exactly right about isolation - it would either have to be either battery powered or use an isolation transformer plus defib protection in front of the op-amps on the front-end. If you're planning to use in a clinical setting and want to get certification this would be necessary. Unfortunately these certifications and testing such as high pot can be quite expensive.

If I were to give my opinion as to what a universal open ECG system would look like - it would be:

1. 12 lead - might as well go ahead and add the extra op-amps and a mux to switch the leads as. 3 leads would be easier, but as long as you're going to the trouble...
2. 500 samples per second digitization
3. 0-150 Hz bandpass high frequency filter .05 Hz low freq
4. Module with 4mm banana jacks - could make your own leadwires - 4mm plug to alligator leads
5. optically isolated USB interface so that you could use any Linux device with USB/LCD display such as the Nokia/pepperpad etc
6. Shared AutoCad/Gerber drillplot files with BOM
7. Use of readily available IC's to allow duplication.

Maybe Phase 1 - display/ print
Phase 2 - store/transmit - DICOM/jpg format
Phase 3 - meassurement/diagnosis
Phase 5 - MySQL database - add bluetooth SPO2/NIBP module - telemedicine

There are a large number of PC compatible 12 lead modules already on the market. I've been associated with a couple of them in my career. They just aren't Linux based, but the layout is pretty standard.

Following these thoughts would create something that could actually be used in a hospital setting that could legally be used on a patient versus just a hobby project. It might be alot to bite off but again would be the difference between a certifiable clinical device and a hobby project.


Here is a good ECG reference - note that Kligfield,Wagner,Childers,Macfarlane, et al recommend at least 1000 sps digitization. These days everyone does except GE - the AM6 acquisition unit still digitizes at 500 sps.

Just my opinion!


> Randy, you clearly know your stuff.
>
> As I discovered in this project, 50Hz (or 60Hz) filtering can make or break an ECG design. Without a good notch/pass filter installed from the start noise is going to be frustratingly present.
>
> I appreciate the difficulties with optoisolation and sampling rate- particularly with the current approach which is sound card coupling. This presents both filtering and sampling challenges that would be best avoided by designing around them to start.
>
> I also appreciate the inelegance of old equipment as the base, however it is cost effective and a good stop gap for now.
>
> Ultimately, like others, I see a purpose built device free of the problems encountered to date.
>
> It is good to see that others are interested and involved in this worthwhile task.
>
> Randy, what do you see as the next step in this process?
>
>
> > > Could the open source Arduino board be a starting point in developing our ECG?
> >
> > A noble but I'm afraid implausible task...to be able to acquire/display/measure ECG there are several issues which dictate architecture:
> >
> > # Isolation: As mentioned previously, opto-isolation. IEC60601 dictates leakage current more than 100 microamps. Using an old ECG device is one way to cover that base but won't solve your other problems. Keeping the front-end all DC (battery) powered all the way to the computer interface is required, and then opto-isolation must be employed in order to preclude one from building a defibrillator as well.
> > # Sampling: To have diagnostic quality ECG, it is required to have >250 khz sampling rate, most modern ECG devices are 1kHz sps, GE is still 500 sps. From what I understand the Arduino can only support sampling to 77 kHz...and this is only a single channel. To sample multiple leads, one would then require multiplexing and thus faster buss requirements.
> > # Filtering: QRS complexes have a median response of 33hz. You must filter out 50 or 60 hz electrical noise given the low amplitude of the ECG signal (common mode rejection). Most ECG devices have a front-end bandpass of 0-150 Hz. Using an old EKG machine covers that base but is much less than elegant.
> > #Multiple Leads: In order to have different "views" of the conduction signal from the SA node traveling through the Bundle of His and ultimately contracting the ventricles requires multiple leads to evaluate location of anomalies. A single lead can give you heart rate, rhythm information and ST segment data but for more precise interp, more leads and electrodes are required. This then requires more than a single microphone input to a sound card. A 12 lead machine requires leads: I, II, II, and precordial leads V1-V6?. Leads aVR, aVL, aVF are algebraicly derived by a resistive network using Wilson Terminal. There is good data to support 12 lead synthesis using orthagonal lead placement of five electrodes and the use of the Dower Transform. Philips's trade name for this is EASI . This however requires much proprietary software.
> > #Measurement: To measure important landmarks, one must find landmarks on the QRS complex ("fiducial points"). To measure a QRS complex, you must first acquire a representative beat either by averaging or (GE) incremental updating. You can do some easy stuff like measuring heart rate in realtime by passing the QRS complex through an op-amp peak detector. This produced a tach pulse output. QRS measurement requires finding isolectric point (PQ junction), R wave, nadir of the S wave, T wave onset, T wave offset, p wave onset. This would give you QRS duration and the ability to measure ST segment.
> >
> > Long story short: There are single IC solutions for single lead ECG that offer single lead ECG acquisition solutions which include a common mode rejection and in some cases A/D and even measurement as is the case with the Freescale IC.
> > There are some really cool implementations of the single chip solution including the little "Read My Heart" ECG device which lets you put two fingers on two sensors, the unit acquires 10 seconds of ECG, filters, and even measures ST segment albeit with poor accuracy. But it also outputs the file in a jpg (shown here), all for around $150USD. The point being however that a single chip solution is viable and available but probably better suited for an embedded application with a ASIC (application specific IC)/LCD display running embedded Linux
> > There are a plethora of open source initiatives not only for scalar ECG but also ambulatory Holter ECG as well. To that point, I'm going to assemble a post covering this very interesting topic myself in the next few days...

Randy, you clearly know your stuff.

As I discovered in this project, 50Hz (or 60Hz) filtering can make or break an ECG design. Without a good notch/pass filter installed from the start noise is going to be frustratingly present.

I appreciate the difficulties with optoisolation and sampling rate- particularly with the current approach which is sound card coupling. This presents both filtering and sampling challenges that would be best avoided by designing around them to start.

I also appreciate the inelegance of old equipment as the base, however it is cost effective and a good stop gap for now.

Ultimately, like others, I see a purpose built device free of the problems encountered to date.

It is good to see that others are interested and involved in this worthwhile task.

Randy, what do you see as the next step in this process?


> > Could the open source Arduino board be a starting point in developing our ECG?
>
> A noble but I'm afraid implausible task...to be able to acquire/display/measure ECG there are several issues which dictate architecture:
>
> # Isolation: As mentioned previously, opto-isolation. IEC60601 dictates leakage current more than 100 microamps. Using an old ECG device is one way to cover that base but won't solve your other problems. Keeping the front-end all DC (battery) powered all the way to the computer interface is required, and then opto-isolation must be employed in order to preclude one from building a defibrillator as well.
> # Sampling: To have diagnostic quality ECG, it is required to have >250 khz sampling rate, most modern ECG devices are 1kHz sps, GE is still 500 sps. From what I understand the Arduino can only support sampling to 77 kHz...and this is only a single channel. To sample multiple leads, one would then require multiplexing and thus faster buss requirements.
> # Filtering: QRS complexes have a median response of 33hz. You must filter out 50 or 60 hz electrical noise given the low amplitude of the ECG signal (common mode rejection). Most ECG devices have a front-end bandpass of 0-150 Hz. Using an old EKG machine covers that base but is much less than elegant.
> #Multiple Leads: In order to have different "views" of the conduction signal from the SA node traveling through the Bundle of His and ultimately contracting the ventricles requires multiple leads to evaluate location of anomalies. A single lead can give you heart rate, rhythm information and ST segment data but for more precise interp, more leads and electrodes are required. This then requires more than a single microphone input to a sound card. A 12 lead machine requires leads: I, II, II, and precordial leads V1-V6?. Leads aVR, aVL, aVF are algebraicly derived by a resistive network using Wilson Terminal. There is good data to support 12 lead synthesis using orthagonal lead placement of five electrodes and the use of the Dower Transform. Philips's trade name for this is EASI . This however requires much proprietary software.
> #Measurement: To measure important landmarks, one must find landmarks on the QRS complex ("fiducial points"). To measure a QRS complex, you must first acquire a representative beat either by averaging or (GE) incremental updating. You can do some easy stuff like measuring heart rate in realtime by passing the QRS complex through an op-amp peak detector. This produced a tach pulse output. QRS measurement requires finding isolectric point (PQ junction), R wave, nadir of the S wave, T wave onset, T wave offset, p wave onset. This would give you QRS duration and the ability to measure ST segment.
>
> Long story short: There are single IC solutions for single lead ECG that offer single lead ECG acquisition solutions which include a common mode rejection and in some cases A/D and even measurement as is the case with the Freescale IC.
> There are some really cool implementations of the single chip solution including the little "Read My Heart" ECG device which lets you put two fingers on two sensors, the unit acquires 10 seconds of ECG, filters, and even measures ST segment albeit with poor accuracy. But it also outputs the file in a jpg (shown here), all for around $150USD. The point being however that a single chip solution is viable and available but probably better suited for an embedded application with a ASIC (application specific IC)/LCD display running embedded Linux
> There are a plethora of open source initiatives not only for scalar ECG but also ambulatory Holter ECG as well. To that point, I'm going to assemble a post covering this very interesting topic myself in the next few days...

> Could the open source Arduino board be a starting point in developing our ECG?

A noble but I'm afraid implausible task...to be able to acquire/display/measure ECG there are several issues which dictate architecture:

1. Isolation: As mentioned previously, opto-isolation. IEC60601 dictates leakage current more than 100 microamps. Using an old ECG device is one way to cover that base but won't solve your other problems. Keeping the front-end all DC (battery) powered all the way to the computer interface is required, and then opto-isolation must be employed in order to preclude one from building a defibrillator as well.
2. Sampling: To have diagnostic quality ECG, it is required to have >250 khz sampling rate, most modern ECG devices are 1kHz sps, GE is still 500 sps. From what I understand the Arduino can only support sampling to 77 kHz...and this is only a single channel. To sample multiple leads, one would then require multiplexing and thus faster buss requirements.
3. Filtering: QRS complexes have a median response of 33hz. You must filter out 50 or 60 hz electrical noise given the low amplitude of the ECG signal (common mode rejection). Most ECG devices have a front-end bandpass of 0-150 Hz. Using an old EKG machine covers that base but is much less than elegant.
4. Multiple Leads: In order to have different "views" of the conduction signal from the SA node traveling through the Bundle of His and ultimately contracting the ventricles requires multiple leads to evaluate location of anomalies. A single lead can give you heart rate, rhythm information and ST segment data but for more precise interp, more leads and electrodes are required. This then requires more than a single microphone input to a sound card. A 12 lead machine requires leads: I, II, II, and precordial leads V1-V6?. Leads aVR, aVL, aVF are algebraicly derived by a resistive network using Wilson Terminal. There is good data to support 12 lead synthesis using orthagonal lead placement of five electrodes and the use of the Dower Transform. Philips's trade name for this is EASI . This however requires much proprietary software.
5. Measurement: To measure important landmarks, one must find landmarks on the QRS complex ("fiducial points"). To measure a QRS complex, you must first acquire a representative beat either by averaging or (GE) incremental updating. You can do some easy stuff like measuring heart rate in realtime by passing the QRS complex through an op-amp peak detector. This produced a tach pulse output. QRS measurement requires finding isolectric point (PQ junction), R wave, nadir of the S wave, T wave onset, T wave offset, p wave onset. This would give you QRS duration and the ability to measure ST segment.

Long story short: There are single IC solutions for single lead ECG that offer single lead ECG acquisition solutions which include a common mode rejection and in some cases A/D and even measurement as is the case with the Freescale IC.
There are some really cool implementations of the single chip solution including the little "Read My Heart" ECG device which lets you put two fingers on two sensors, the unit acquires 10 seconds of ECG, filters, and even measures ST segment albeit with poor accuracy. But it also outputs the file in a jpg (shown here), all for around $150USD. The point being however that a single chip solution is viable and available but probably better suited for an embedded application with a ASIC (application specific IC)/LCD display running embedded Linux on a device that supports multiple channel A/D.
There are a plethora of open source initiatives not only for scalar ECG but also ambulatory Holter ECG as well. To that point, I'm going to assemble a post covering this very interesting topic myself in the next few days...

> Could the open source Arduino board be a starting point in developing our ECG?

I'm interested in the arduino board, although I am concerned about simplicity. The 'KIS' (Keep it Simple) principle is often best for medical hardware, as otherwise there are pointless failable components.

That said, 99% of the work is done for us with the arduino, and if it works even better.

In terms of making a usable ECG, optical isolation would have to be included and this is not provided for in the arduino.

Are there any other alternatives worth considering?