0
$\begingroup$

I need to preprocess raw ecg data in R, here is a sample already standardized. I'm not an expert in signal processing nor experienced in working with medical data, so I need concrete answers ideally with code.

Below is a plot of how the data looks like, so perhaps this can give an idea of the problems present.

enter image description here

Question 1) What strategy is needed in terms of subsampling, filtering to preprocess the data to clean get a clean ECG signal (google how it should look).

Question 2) Would this strategy work for EMG data also?

$\endgroup$
  • $\begingroup$ You'll have to add more detail to your question to get a good answer. For instance, pre-processing is done with some goal in mind. What do you want to achieve -- what is wrong with the signal you present, that you need fixed? $\endgroup$ – MBaz Feb 17 '17 at 22:19
  • $\begingroup$ The question is extremely clear, you just need to know about the topic to answer it. If you don't and are interested in the question, you can use a popular search engine to see how a proper ECG signal should look like. e.g google. The question even has sample data, so you can actually give it a try. $\endgroup$ – marbel Feb 18 '17 at 7:23
  • $\begingroup$ I would not go as far as to call this question "extremely clear" but it is also not too difficult to improve it. Can I please ask you to add your comment to Laurent Duval's response to the question? If you did not mention it, the first thing I would tell you is that you have a problem with your electrode contact, which makes perfect sense given the context. Another thing that could be mentioned is what is the purpose (?) $\endgroup$ – A_A Feb 18 '17 at 8:11
4
$\begingroup$

I need to preprocess raw ecg data in R, here is a sample already standardized. I'm not an expert in signal processing nor experienced in working with medical data,...

Not being an expert on how the heart works and how its phases manifest themselves on the ElectroCardioGram (ECG) is not a problem. But it would help immensely if you mentioned what is the purpose of this, i.e what do you want to do, what are your specifications and constraints?

For example "We put the driver in the car, they go through the track a few times and then we want to know what was their heartbeat at a specific point in the track".

Excellent, then, do not even use ElectroCardioGraphy (ECG) because:

  1. The electrical environment of the racing car is incredibly noisy already. For comparison, you are trying to measure a signal that has a max amplitude of a few mV through long leads that have to run from the chest of the driver to the ECG box. Just a short distance away from this long electrical loop, you have sparks going on and off, relays turning big loads on and off, electrical motors or stepper motors turning. All of these things create fields that the loop will pick up and they will contaminate your signal.

  2. ECG measures the electrical activity of the heart via contact electrodes. Which means that the skin of the driver would have to be prepared, ideally shaved, cleaned with alcohol, then have a conductive gel applied to it and finally apply the electrodes and fix them with medical tape. Throughout the track, I would not expect the driver to pay attention to the electrodes or, to not sweat. Even in controlled conditions, if you tap the electrodes with your hand, you can observe changes in the signal.

Instead, use Pulse Oximetry. This is the way that most gadgets (e.g. smart watches, fitness wrist bands, etc) obtain Beats per Minute from the heart today. Pulse oximetry needs to have contact with the skin, but not because it measures electricity. Very briefly: It measures the attenuation of light that is proportional to the blood flow below it. Because the heart is pumping blood in a rythmic way, the flow is rythmic as well and this signal can be used to derive a relatively accurate BPM count.

It will also be much easier to cross reference this with the rest of the telemetry because it will simply be a time series of BPM measurements. Pulse oxymeters for people to manage their heart conditions are more accurate than gadget type instruments. But then again, they might get a bit of getting used to by the driver. (For an example, see this)

Below is a plot of how the data looks like,

No way.

Here (and here ) is what typical ECG signals look like.

To extract BPM, you need to "detect" those spikes which correspond to heart contractions and then measure the timing between them (also known as R-R interval, because the main spike of the ECG is the R peak).

Very briefly: QRS Detectors work by Pre-filtering -> Rectification -> Integration -> Thresholding -> QRS Complex pulse sequence -> R interval extraction -> Beat Detection. For much more detailed information about this, have a look at Moody's work.

What is depicted in the plot is saturation and possibly lots of noise from the contact. There is no trace of "typical" ECG complexes to work with.

Question 1) What strategy is needed in terms of subsampling, filtering to preprocess the data to clean get a clean ECG signal (google how it should look).

Why subsample? The signal is already in a bad state, why make it even worse? You could try a bandpass filter between 0.1 - 100Hz. This would reduce DC and cut out any high frequency noise but you have a lot of spikes which means that most of time times you will be "hearing" the ringing of the filter.

Question 2) Would this strategy work for EMG data also?

EMG is even worse because it picks up signals at higher frequencies. What is the application?

If you are trying to see the timing of the driver as to WHEN do they start to accelerate (i.e. leg muscles start working) versus when the car actually accelerates or brakes (i.e. break signal from telemetry), then maybe you can get away with very simple processing using thresholds. But if you are trying to make more fine measurements, you might be back into the same problem of lots of noise from various sources. In the case of EMG you will have to work around those, which means, twisted pair wires, shielding, as short lengths as possible, very good contact with the driver's skin, very good preparation of the driver's skin, perhaps even slightly different electrodes that attach on to the skin rather than simply be in contact with it.

Hope this helps.

EDIT:

I am sorry, this is an unsalvageable situation. I have a couple of comments only,but I do not believe they will be very much of help.

So, here is the full signal you shared (thank you, by the way):

Full signal plot showing high saturation

As you can see, there is nothing usable here. My perception is that the ECG amplifier is either saturating (because of induced voltage) or the contact with all three electrodes is not stable. If you notice a Holter monitor, which is used to "catch" abnormal heart functioning wherever it may happen, you will see that the leads are as short as possible with the device being mounted ON the chest. If we were to use the same device in an application similar to yours, we would have to use shielded leads and make sure the pads are firmly attached on the body.

Going a bit closer, it almost looks like "reversed bits"

enter image description here

What I mean by this is: Say for instance, you created your own ECG circuit. So, take an off the shelf instrumentation amplifier, set the gain and then feed that to an "Arduino"ish type of board with some 10bit Analog To Digital (ADC) converter that establishes a serial like channel to a pc or stores values internally. Because you have 10bits (or more) and you would have to send two bytes over the wire (or store two bytes) you would have to decide if they are sent/stored/received/retrieved Big Endian or Little Endian.

So, when you read a binary file from the disk and you get the endianess wrong, your integer values, the levels recorded by the ADC, would look a little like this second figure right here. There are glimpses of what looks like a signal inter dispersed with wild swings from the minimum to the maximum value. Also, your "zero" is not at 0, but maybe you used just two ECG leads.

I am just leaving this here as a comment in case it is what is going on, though I doubt it.

If you look more closely, the signal is just all over the place:

enter image description here

In fact, if you have telemetry from the rest of the car, try to plot together the RPM of the engine and the ECG signal that you have. What I would expect to see is the "density" of disturbances in the signal to correlate with the RPM of the engine, assuming that most of this interference is coming from the electrical system of the car (ignition, injection, throttle stepper motors, etc).

Hope this helps.

$\endgroup$
  • $\begingroup$ a) I can't change how the data is collected. b) The use is just exploratory for now, for example to correlate with g-force, etc. Of course it's important to measure the heart rate or any feature. I though that was sort of obvious. Thanks $\endgroup$ – marbel Feb 18 '17 at 19:48
  • $\begingroup$ @marbel Can you post 5 minutes of signal, preferably from when the car is going around the track, rather than some "dead" time outside of it? In the meantime, you might want to have a general look at this link too. $\endgroup$ – A_A Feb 18 '17 at 19:57
  • $\begingroup$ Here is a bit more data $\endgroup$ – marbel Feb 18 '17 at 20:34
  • $\begingroup$ @A_A was wondering if one of these (relatively) modern Doppler-based "stethoscopes" (not really a stethoscope if you synthesize a heartbeat sound from an ultrasound-based doppler estimation of relative movement, if you'd ask me) taped very eagerly to the thorax might work better. You'd filter out a lot of fast movement, and would look amidst the remaining noise for periodicities of 0.75 – 3 Hz (or however exciting car driving gets). $\endgroup$ – Marcus Müller Feb 19 '17 at 22:39
  • $\begingroup$ @MarcusMüller Because they are measuring very small displacements, they are very sensitive to noise. Every bump and exhaust burst would get into the signal. $\endgroup$ – A_A Feb 20 '17 at 7:42
2
$\begingroup$

I do not have a lot of experience in analysing ECG data. However, it does not look, to me, like any ECG I have seen, or the patient is stone dead. I would at least expect a "regular" baseline, and some periodicity.

The seemingly flat plateaux, above and below and around zero, the thin and large spikes, plus the small fluctuations, look like noisy saturations. Those fast jumps suggest a non-bandlimited signal, and apparently prevent any subsampling. The signal is quite unsteady, apparently very non stationary, and few standard processing options. The time-frequency analysis (short-term Fourier) performed below at least exhibits some structure, but one should understand first how it is related to the clipped and spiky data.

STFT

I would try to trace a seemingly clean part of the data and perform time-frequency or time-scale decompositions to see if there is something meaningful to start from. In the following picture, a crop is performed in the time-frequency plane, and inverted back to the time domain. It gives your the signal in red. Such a processing should be assisted by some information on the bandwidth you are interested in.

STFT inverted

This looks like a real signals a little more. But does it make sense?

Without more hints, if the EMG looks bad, the same strategy could be applied, without much chance of success.

The rare cases in which I have seen data like this were:

  • sheer problems in the sensor/amplifier chain (loose contact, outer disturbances),
  • wrong decoding of binary files: little/big endian swap, reading 8 bit words instead on 16 bit, etc.

My only suggestion: is there any way you can check whether the signal has been properly decoded from the raw binary file?

$\endgroup$
  • $\begingroup$ thanks for your comment. The data was recorded while running a race car at so there is some noise because of that. $\endgroup$ – marbel Feb 18 '17 at 7:25
  • $\begingroup$ How do you explain the flat parts? $\endgroup$ – Laurent Duval Feb 18 '17 at 8:38
  • $\begingroup$ I have tried a time-frequency thing $\endgroup$ – Laurent Duval Feb 18 '17 at 8:48
  • 1
    $\begingroup$ @Laurant Thanks, already to see someone experience trying to clean this and it still looks odd, helps understanding it's still too noisy. Is there anything else I can tell you to help improve it? $\endgroup$ – marbel Feb 18 '17 at 19:57
  • $\begingroup$ If you have sensors or measurements related to the car movements (accelerometers, instantaneous speed), I would select the lowest speed/vibration time interval, and process ECG in these zones first, with hope it is more usable $\endgroup$ – Laurent Duval Feb 18 '17 at 20:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.