How to calculate the small changes in a signal?
Show older comments
Hi all,
I have an ECG signal and would like to know what minor amplitude changes I can recognize. The goal is to see if I'm able to get the resolution that's provided by the recording system or not. I use the gradient function to calculate the derivative and look at the minimum value to determine the resolution. I would like to know if this is the best approach to take or not. The signal is attached here. Any suggestions would be appreciated.
Fs = 1024; % sampling rate
Ft = gradient(data, 1/Fs)
min(Ft) % the smallest change in the signal's amplitude
Accepted Answer
Iam not certain what result you want, however to get the smallest amplitude change, using gradient on the original signal is likely not going to produce the result you want, since the minimum gradient is going to be the minimum of the entire record, likely returning the value of the deepest Q- or S-deflection. Taking the gradient of the abolute value instead may do what you want.
Try this —
LD = load(websave('A','https://www.mathworks.com/matlabcentral/answers/uploaded_files/1112930/A.mat'));
data = LD.A;
Fs = 1024;
L = numel(data)
t = linspace(0, L-1, L)/Fs;
Ft = gradient(data, 1/Fs);
[minFt,idx] = min(abs(Ft)) % the smallest change in the signal's amplitude
minidx = find(Ft == min(abs(Ft)))
Ft2 = gradient(Ft); % Second Derivative
resolution = diff(data);
min_resolution = min(resolution(resolution>0))
figure
subplot(2,1,1)
plot(t, data, 'DisplayName','Data')
hold on
plot(t(minidx), data(minidx), '+r', 'DisplayName','Gradient = 0')
hold off
grid
title('Original')
legend('Location','best')
xlim([0, 10])
subplot(2,1,2)
plot(t, Ft, 'DisplayName','Gradient')
grid
title ('Derivative')
xlim([0, 10])
That returns several values of a flat gradient, all representing inflection points in the EKG trace. Calculating the second derivative will allow the determination of the inflection points being a minimum, maximum, or saddle point. This may be helpful, however I am not certain what you want.
The minimum resolution appears to be equal to 1, however that likely needs to be calibrated with respect to the actual voltage values of the EKG (the R-deflection is normally about 1±0.2 mV) to be useful. It will likely be necessary to check the gain on the instrumentation.
.
71 Comments
Susan
on 31 Aug 2022
Star Strider
on 31 Aug 2022
My pleasure!
I am not certain what sort of ‘interference signal’ you want to use. Gaussian white noise (for example the output of the randn function) could completely obscure the EKG if the amplitude is great enough. A sinusoidal signal creating a varying baseline could preserve the EKG morphology and still cause problems with, for example, machine interpretation.
‘Based on the manual, I should be able to recognize the changes in the amplitude that are less than 20 microvolts.’
If one increment then is 20 µV, then multiply the observed values by 2E-5 to get the values in Volts. Looking at the posted trace, that means that the R-deflection maximum is 3.5E+4 x 2E-5 = 700 mV. (That is unphysiologically high, so check that. A calibration of 2E-6 instead would make that 70 mV and physiologically appropriate.) That also will convert the integer values to floating-point values, making any other calculations easier.
The data in the file appear to be integer data, so it may be necessary to use a calibrated voltage with your instrumentation to determine what the output for the known voltage. (I would use several voltages betweeen -2 mV to +2 mV to get the calibration values and also confirm linearity.) I hope you have some sort of voltage standard available externally or within the instrumentation that will allow you to do this.
What is the ‘NSR signal’? I may have encountered it previously, however likely by a different name.
"That returns several values of a flat gradient..."
Which are almost all at the extremes both directions that indicates the signal was clipped in all likelihood.
LD = load(websave('A','https://www.mathworks.com/matlabcentral/answers/uploaded_files/1112930/A.mat'));
data = LD.A;
u=unique(data);
numel(u)
size(data)
[max(data) min(data)]
Shows the discrete nature of the inputs -- that there are only 15,528 unique values out of the 86,549 total samples and that the min/max values are, indeed at the limit of the 16-bit signed integer.
Since these data are
all(data==fix(data))
all integer-valued (pretty much a given since are reading the 16-bit integers from the data files), the minimum difference in values between samples is, by definition, 1.
There's nothing to be learned here by this exercise until have the absolute scaling to relate the values back to what is the input -- and whether these represent the raw inputs to the device or whether they have been processed before being written out in 16-bit signed integer format.
Susan
on 31 Aug 2022
Star Strider
on 31 Aug 2022
@Susan — The ‘NSR signal’ leads me to believe that the EKG is synthetic. No worries about that, however it would be helpful to know.
‘Assuming one increment is 0.1 µV, and the input signal amplitude is 0.05mV’
This leads me to believe that would be the resolution. I’m now a bit confused. The normal EKG should have an R-deflection amplitude of about 100 mV. I have no idea what the gain is on your amplifiers. You would need to determine that calibration with a known voltage reference, as I mentiioned earlier.
Susan
on 31 Aug 2022
@Star Strider hmm.. I don't know. For the normal ECG with the amplitude of 0.05mV, this is what I got from their software, plotting the attached B.mat data,
with the y-axis 160mm/mv and x-axis 25mm/s, which the R-deflection amplitudea of it are pretty small.
Star Strider
on 31 Aug 2022
Edited: Star Strider
on 1 Sep 2022
Something isn’t correct, since there are also no P- or T- deflections in that trace, at least that I can see. In a normal lead II EKG in a reasonably healthy person, the R-deflection should be between about 70 mV and 110 mV. The amplitudes of the other deflections (other than the QRS complex in which all are significant, especially Q-deflections) aren’t as important as the intervals (deflection widths, and intervals between deflections).
EDIT — (1 Sep 2022 at 10:40)
If the instrumentation itslef is ginving you problems, and if the dicumentation for it is available online (the URL would be necesary), I might be able to help with this.
Well, you've kept that hidden -- there's all the data you asked for -- the resolution of the device is that the least significant bit is 19.53 uV.
What that is in output then will depend on the gain you set -- it gives the scaling of mm/V. So, the only thing yet to determine is just what parameter it is that is being written to the data file -- if it were the processed waveforms, you should be able to overlay your plots directly on theirs with some scaling factor; if these are the raw data before any other processing and the waveforms presented are somehow preprocessed, then they won't match identically and you've still the Q? to answer about what happens to the recorded values with known inputs.
@Star Strider probably knows enough about the medical instrumentation field to be able to help as far as what is normally done with raw data collected to present to the trained professional as a polished ECG to give at least some guidance. That may (or may not?) include proprietary algorithms to differentiate one product from another? Or, are there required standards in medical field that everybody has to do the same thing; only user interface/convenience/price differentiates one product from another in market place? I've no idea on that score.
It also confirms the other point made elsewhere that the -3 dB upper frequency is 100 Hz so anything you try to put into it in the kHz or above range thru the input channels simply isn't going to ever be seen.
dpb
on 1 Sep 2022
"...should be able to recognize the changes in the amplitude that are less than 20 microvolts."
That would be "greater than", not "less than" 20 uV would be resolvable.
Sure that's what you meant, just correcting the record of what was written.
But, back to the subject of just what your research goal here is regarding the proposed noise injection -- just what is the stated project objective? If it is, indeed, something about detecting stray electrical field noise contaminating a recorded ECG, it would seem you're going to need more sophisticated data collection instrumentation than this commercial product that has that protection from such extraneous sources built into it.
Without a stated research goal/hypothesis we certainly can't design an experimental setup here and it's not the MATLAB forum's place really to do so, but to me it doesn't appear that you can realistically do anything about what you've described with this device, even if you do finally figure out its internals.
You can test this hypothesis with a signal generator on one of the inputs -- do the experiment I outlined before for the DVM -- I'm pretty sure you'll find that if you put a sine wave in at 1 kHz, you'll just get a near zero flat line for that channel recorded, really no different than if you had just grounded that input.
I would suggest you should do these rudimentary tests to see if you've got any chance at all of making this work before investing a great deal more time on other details on the assumption the device will be able to record these presumed corrupted signals when you get there.
From the .pdf it looks like the full-scale deflection in lead II is 100 mV, and the recording is 10 mm/mV.
This appears to be appropriate —
LD = load(websave('data1','https://www.mathworks.com/matlabcentral/answers/uploaded_files/1113930/data1.mat'))
VL = compose('V%d',1:6);
VN = {'I', 'II', VL{:}};
EKG8 = array2table(LD.data1, 'VariableNames',VN)
CF = 1E-2/(max(EKG8.II(end-100:end)) - min(EKG8.II(end-100:end))) % Calibration Factor (V/Increment)
EKG8_V = array2table(table2array(EKG8)*CF, 'VariableNames',VN) % Convert Values To Volts
Fs = 1024;
L = size(EKG8,1);
t = linspace(0, L-1, L)/Fs;
figure
plot(t, EKG8_V.II)
grid
xlabel('Time (s)')
ylabel('Amplitude (V)')
xlim([20 30]+0.25)
Each increment then is about 7.74 µV, at least as I calculate it on the basis of the information provided.
No worries about the URL, since I could probably find it online now, however I doubt that’s necessary at this point.
.
dpb
on 1 Sep 2022
". I wonder if I can get this ~20uV resolution on the data I am collecting. "
The data sheet says it's a 24-bit A/D so that's the best resolution you can get is the 20uV LSB.
But, the data you have in the data files has been written as sixteen-bit signed so you have only 64k values out of the possible 16384k values the A/D can sample -- iow, the data available to you have only 256*20uV --> 5mV resolution available. That's the best you can get by reading the data files.
Susan
on 1 Sep 2022
Susan
on 1 Sep 2022
Star Strider
on 1 Sep 2022
My pleasure!
‘... you mean the peak-to-peak value in the lead II is 100 mV, right?’
In that section of it (after the transients are gone), yes.
‘Why has the calibration factor been calculated based on the lead II?’
That’s the lead I usually calibrate with, since it tends to be the most representative. It also represents the amplitude information in the .pdf file that I’m using as a source of information, so I’m matching those data.
‘It seems that each lead thas different calibration factor, am I right?’
They shouldn’t. The deflections in an EKG are actually projections of an excitation (or repolarization) loop onto each lead. As such, the amplitudes may not be the same as in Lead II.
‘And could you please tell me what is the rational behind calculating the calibration factor in this way?’
It depends on the instrumentation. Since I cannot interact with it to calibrate it, I am using the available information, gleaned from the .pdf file and the data. So it’s largely empirical inb my analysis. My calculation and use of the ‘CF’ variable faithfully reproduces the .pdf file results. That’s the best I can do.
.
If the LSB is 20 uV for a 24-bit A/D, but the device is only writing 16-bit signed integers, you can't put 24 bits of resolution into 16 bits -- they don't fit. So
>> 2^24/2^16
ans =
256
>>
is the ratio of how many bits were digitized over how many were written -- if 24 bits --> 20 uV, then the LSB for 16-bits is 256X that amount. That's for the granularity of the output data waveforms you have available to you to read; the internal software may still have used more, but I'd guess it's probable they're using a 16-bit microprocessor so it fits the word size. If they were using a 32-bit micro, then they could have done all the internal stuff with full precision and then just written the results to the data file as 16-bits.
If it is only actually using an 18-bit A/D instead of 24, then the LSB would be 2^18/2^16 ==> 2^2 --> 4X 20uV or LSB is 80 uV in the actual instrument it would seem then, not 20. The end result would be the same.
The actual resolution in V is then that 1/2^Nbits precision applied to the input range. See a more complete description at <ADC_and_Resolution>
Susan
on 1 Sep 2022
Star Strider
on 1 Sep 2022
Edited: Star Strider
on 1 Sep 2022
@Susan — The ‘CF’ value does not change with respect to the leads. The EKG as I mentioned previously is the projection of a loop onto the various leads. This is like looking at a ring in 3D at an angle, angled at about 45°, so it appears to be an ellipse. The distance across the ring will appear to change at various angles although the ring itself does not. The Lead II values are like looking along the ring in its maximum, along the 45° axis.
The normalisation over the last 100 data samples is to be certain that no transient effects remain in the signal, since there is an initial decaying exponential transient. They should all be minimal at the end of the vector.
Susan
on 1 Sep 2022
@Star Strider Thank you SO much! I just got what you mentioned previously.
I promise it will be my last question in this thread :)
The way I read the output waveform from the software was based on this figure.
But it seems the vertical part of each small box is equal to 10mV, right (I considered it as 0.1mV)? Then how to read the horizontal part in terms of sec? I'm confused
Star Strider
on 1 Sep 2022
As always, my pleasure!
That’s correct (1 mV/10 mm), and the correct ‘CF’ calculation is then:
CF = 1E-1/(max(EKG8.II(end-100:end)) - min(EKG8.II(end-100:end))) % Calibration Factor (V/Increment)
I checked that in Braunwald to be sure. I have no idea how I could have remembered it incorrectly and been off by an order of magnitude.. My apologies.
The time is 25 mm/s, so the time vector is correct.
Susan
on 1 Sep 2022
My previous statement ‘1±0.2 mV’ is correct. I don’t know what I was thinking otherwise. (Maybe just fatigued.)
LD = load(websave('data1','https://www.mathworks.com/matlabcentral/answers/uploaded_files/1114355/data1.mat'))
VL = compose('V%d',1:6);
VN = {'I', 'II', VL{:}};
EKG8 = array2table(LD.data1, 'VariableNames',VN);
CF = 1E-4; % Calibration Factor = 100 µV/Quantization Step
EKG8_V = array2table(table2array(EKG8)*CF, 'VariableNames',VN) % Convert Values To Volts
Fs = 1024;
L = size(EKG8,1);
t = linspace(0, L-1, L)/Fs;
figure
plot(t, EKG8_V.II,'.', 'MarkerSize',2.5)
grid
xlabel('Time (s)')
ylabel('Amplitude (mV)')
title('II')
xlim([20 21]+0.25)
This one seems to have significantly lower voltage, however the axis is normal (76°) and there is normal R-progression in the precordial leads. The R-peak is about 0.5 The ‘CF’ value here is set at 100 µV/quantization step. This appears to be correct and essentially matches the trace in the .pdf file, however not with the previous data set (follows), since the trace had a Lead II amplitude of only about 0.8 mV while that ‘CF’ value produces an R-amplitude of about 1.1 mV here.
Something is clearly not consistent. I am not certain what that ‘something’ is.
LD = load(websave('data1','https://www.mathworks.com/matlabcentral/answers/uploaded_files/1113930/data1.mat'))
VL = compose('V%d',1:6);
VN = {'I', 'II', VL{:}};
EKG8 = array2table(LD.data1, 'VariableNames',VN);
CF = 1E-4; % Calibration Factor = 100 µV/Quantization Step
EKG8_V = array2table(table2array(EKG8)*CF, 'VariableNames',VN) % Convert Values To Volts
Fs = 1024;
L = size(EKG8,1);
t = linspace(0, L-1, L)/Fs;
figure
plot(t, EKG8_V.II,'.', 'MarkerSize',2.5)
grid
xlabel('Time (s)')
ylabel('Amplitude (mV)')
xlim([20 21]+0.25)
I am not certain that there is any one value for ‘CF’ that would be uniformly applicable here.
.
Star Strider
on 2 Sep 2022
Edited: Star Strider
on 2 Sep 2022
As always, my pleasure!
The EKGs should all be recorded with the same gain and other parameters in order to be certain that the records are comparable (that is, if you want to compare them at some point). It may be difficult to normalise the amplitudes otherwise.
EDIT — (2 Sep 2022 at 15:28)
Not a dumb question at all. I just don’t kolnw enough about the instrumentation you’re using to respond to it.
EDIT — (2 Sep 2022 at 15:50)
There shouldn’t be any interference if the right leg common reference is used. The EKG instrumentation uses differential amplifiers to subtract any common-mode signals (detected by the common reference) from the EKG leads.
Susan
on 2 Sep 2022
dpb
on 2 Sep 2022
Unless there's some other post-processing in the data written to the file as opposed to the raw input signals, one should be able to compensate "after the fact" for gain differences exactly as that is simply linear scaling.
OTOH, changes in filter corner frequencies and the like affect phase and amplitude nonlinearly and so will have non-compensatable effects that.
@Star Strider -- up earlier you wrote about the EKG being "...the projection of a loop onto the various leads." I have no klew what that means -- is there a layman's outline that shows what you're talking about here? I just presumed we were looking at simple simultaneously sampled time traces, here.
Star Strider
on 2 Sep 2022
Edited: Star Strider
on 2 Sep 2022
‘All I want to do is that for each data set, the Matlab plot that I get by plotting the data set be matched with the software plot’
If you’re estimating parameters in order to match them (although I’m not certain what is being matched), this becomes a much easier problem. If I understand it correctly, it is then essentially a linear regression, providing that none of the parameters are time-dependent or otherwise vary.
@dpb — Several years ago, I posted an elaborately detailed answer on this topic. The best I can currently come up with is this Wikipedia secton: Limb leads and electrical conduction through the heart. One of my Answers relevant to this that I just now found is how can I get cardioid graph from the ecg QRS complex? This Comment plots it in the frontal plane using Lead I and Lead 
. It is possible to plot it in the transverse and saggital planes, as well as in 3D. (This approach is termed vectorcardiography.)
. It is possible to plot it in the transverse and saggital planes, as well as in 3D. (This approach is termed vectorcardiography.)
Star Strider
on 2 Sep 2022
@Susan — I was thinking of something like regressing one version of the EKG against the other (although I’m not certain what you are comparing). This would result in a scaling term (essentially ‘CF’) and an offset term (likely close to zero).
Also, ideally the gain should be 10 mm/mV for the most consistent results. I don’t completely understand the posted table, so I’m not certain how to interpret it.
dpb
on 2 Sep 2022
@Star Strider -- Thanks...that'll take some study, obviously. :) Like everything, there's a lot more to the field than appears on the surface -- what I learned when transitioned to supporting the fossil-fired (aka coal) utilities from the nuclear side.
@Susan -- Is there some way to get the actual plotted data from their software or are you forced to just use visual comparisons? If so, that would be the way as @Star Strider suggests. Clearly, given the background info and even just a most cursory scanning of the Wikipedia article, there's a lot that's gone on behind the scenes from having collected the raw A/D sampled waveforms and producing the shown ECGs.
Susan
on 2 Sep 2022
What I thought -- bummer! So, you're left with some very tedious manual method to try to do that or seeing if you can figure out a way to digitize those traces by capturing them electronically and image processing to extract the traces.
Or, simply forget about them; use the data you can read from the device and see if you can introduce this conjectured signal contamination into the device first to see if there's any point continuing down this path, even.
Star Strider
on 2 Sep 2022
It’s apparently not possible to get them from the PDF either. I opened my PDF editor to see, and couldn’t, although that may remain an option with other editors, since the information is obviously somewhere in it. The only thing I could extract was the background grid.
Are there any other options other than the PDF and the raw data?
dpb
on 2 Sep 2022
I'd guess the pdf doc embedded the images themselves and the data as tabular data are not in the doc at all is why.
Susan
on 2 Sep 2022
dpb
on 2 Sep 2022
"...Star was able to plot the tabular data in a way that matched the plot in the pdf file..."
Down to the details match identically? I know any/all of the plots match in general characteristics; I thought the whole point of this sidebar discussion was how to determine if could match those up with the actual ECG traces precisely. If the data are those final results scaled to the 16-bit integers, then you should be able to take any one of them with the input gains for that data acquisition and reproduce the output identically.
My understanding of where you were was that you have to fudge the scaling from one to the next to make it work even on overall amplitude and it hadn't been ascertained if the whole trace actually overlays one to the other???
Susan
on 2 Sep 2022
" seems that they applied a Notch filter to the data before plotting them"
Who's "them"? You're not doing these?
When I tried opening the .pdf file, Windoes system thought the font was some Chinese thingie; did these come from somewhere other than US that uses 50 Hz AC, maybe, and this might be reflective of attempting to remove any powerline artifacts? Just a guess given the particular frequency number.
On Fig 2, what is available from the "Tabular" tab -- that wouldn't have numeric values by any chance, would it? It's probably just a summary of the results in a tabular format, but...
Star Strider
on 3 Sep 2022
@Susan — Just now looked at the .PNG files. I don’t see anything in them that gives me any insight into the instrumentation. The 50 Hz notch filter just elliminates 50 Hz line noise, although this shouldn’t be necessary using the right leg common reference electrode, since all that should be subtracted out. In any event, there’s not much of interest in the EKG at 50 Hz, so nothing is lost. It seems to be reasonably sophisticated otherwise, marking the E-point at the end of the P-deflection, the J-point at the end of the QRS complex, and the S-T interval. There’s not much to say otherwise about it. I still don’t understand not being able to get the actual recorded EKG information out of it (scaled to produce the actual voltages) rather than only the raw data.
There’s nothing in the .mat files that I can see that hints at any of the settings used to record the signal, scaling factors, or anything else. If those are actually in any of the files the instrumentation produces, it would be extraordinarily helpful to have them.
I still don’t understand the initial decaying exponential transient at the beginning of the recording. That could be a filter transient, although I’ve never seen anything similar in anything I’ve done. (It‘s not due to an anti-aliasing filter, since that occurs before the A/D converter, and in any event is a Bessel filter so there should be no transients due to it.)
"I still don’t understand the initial decaying exponential transient at the beginning of the recording"
See the Analog Devices datasheet on their chipset -- they specifically talk about it -- it's from the way the high-pass filter is built into their device...which is part of what makes me think the sensor @Susan has is essentially identical.
" that hints at any of the settings used to record the signal, scaling factors, or anything else"
There's an associated .inf file with a few hints but nothing that really helps more than what little already know; the previous long thread discussed those at some length, including trying to decipher the 512-byte .dat-file header. So far, we've been unable to actually figure out what most of the data in it are...
Part of the exercise @Susan was going to do was to see if could build a table of those header files with varying controllable parameters -- the .inf files I've seen from that exercise had no discernible changes; I'm not sure if she was able to decipher anything else from the headers or not.
Susan
on 6 Sep 2022
dpb
on 6 Sep 2022
"didn't see any changes in the waveforms before and after using this filter."
Two possibilities at least--
- If the data were collected in US, the powerline frequency is 60 Hz, not 50 and if the notch filter is very tight, there would be little for it to do, or
- There was good ground and the signal wasn't contaminated noticeably to begin with...
Susan
on 6 Sep 2022
Star Strider
on 7 Sep 2022
I looked at those yesterday. I still cannot figure out what is going on with them.
Susan
on 7 Sep 2022
There does not appear to be anything in the ‘EVT.DAT’ or ‘LEADINFO.DAT’ files, however it is possible to read the last two (fourth and fifth) files in the cell arrays. The 'int16' precison appears to be correct for the EKG file.
If ‘Record Gain=2’ translates to 2mV full-scale gain, the voltages are still really strange.
Uz3 = unzip('https://www.mathworks.com/matlabcentral/answers/uploaded_files/1118395/RecordGain2mVECGamp1mV.zip')
Uz4 = unzip('https://www.mathworks.com/matlabcentral/answers/uploaded_files/1118560/In.zip')
Uz5 = unzip('https://www.mathworks.com/matlabcentral/answers/uploaded_files/1118565/Out.zip')
Uz33 = Uz3{3}
type(Uz33) % Empty?
Uz42 = Uz4{2}
type(Uz42) % Empty?
Uz43 = Uz4{3}
type(Uz43) % Empty?
fidi = fopen(Uz4{4})
v4 = fread(fidi,'int16');
fclose(fidi);
FullScaleGain = 0.002; % Volts (From 'Uz4{5}')
vs = v4 * FullScaleGain;
L = numel(vs);
Fs = 1024;
t4 = linspace(0, L-1, L)/Fs;
figure
plot(t4, vs)
grid
xlim([2 2.5]*1E+2)
Uz45 = Uz4{5}
type(Uz45)
fidi2 = fopen(Uz5{2})
v5 = fread(fidi2,'uint8'); % A Binary File (How To Read It?)
fclose(fidi2);
char(v5).'
% figure
% plot(v5)
% grid
Any meaningful information on how to scale them appears to be missing.
.
Susan
on 7 Sep 2022
Star Strider
on 7 Sep 2022
As always, my pleasure!
It would be helpful to know how the ‘20mm/mV’ scales in terms of the MATLAB plot. If we were to infer that ‘20mm’ was the same as the ylim value being [-20 20], or something equally as deterministic, that could help solve the scaling problem. That might simply require some experimentation until the MATLAB plot has the same values as the printed plot. It would be extremely helpful if the 1mV square wave calibration signal at the left of the EKG trace could be realised as a separate deflection in the record. That would completely solve the scaling issue. So far, I’ve not found it in any of the records.
Susan
on 7 Sep 2022
Star Strider
on 7 Sep 2022
I have no idea. It will be necessary to experiment to figure this out, so that’s definitely worth trying.
dpb
on 7 Sep 2022
The previous datasheet you posted has available output scalings "Gains" of 5, 10, 20 mm/mV. The user-settable gain factor is 0.5, 1, 2 to provide those scale factors; it's that user setting that is recorded in the .dat header and the .inf file.
If you can introduce identically the same input signals into the device at the different gains, the results should be scaled in that ratio as to their output amplitudes.
Again, we're back to if one could simply input known sine waves from a signal generator of a given amplitude and freguency one would be able to have a know reference from which to work.
I'm still led to wonder if there's any real point in continuing to try to reverse-engineer this product, however. If the purpose of the experiment is to determine the effects of the supposed external RF/EMI on the results; can't that just as well be determined by comparing the results with/without the interference and simply observing the difference? That again, of course, presupposes one can actually manage to introduce this interference into the device and get it by the lowpass filtering and actually manage to corrupt the data signal in the first place...
It would seem a device more along the lines of the Analog Devices evaluation board would be far more amenable to experimentation of this purpose unless the research grant is specific about the use of a given commercial device.
$0.02, imo, ymmv, etc., etc., etc., ...
Star Strider
on 7 Sep 2022
@dpb — The problem is that we cannot automatically infer millimitres in the y-direction to y-axis limits in the plot. If you see that somewhere in the existing information, please share it! That could solve this!
dpb
on 7 Sep 2022
I don't see it written explicitly, no, but inferred that the results presented to the end user would be consistent with what the datasheet says.
But, then again, it's an imported device and we've all had experience with those sources of documentation... :)
Star Strider
on 8 Sep 2022
Yes! That can definitely be frustrating!
dpb
on 8 Sep 2022
But, as a clinician, does it really matter all that much what the actual scale is; aren't ECGs read by pattern recognition of the general waveform and not by any absolute magnitude (other than frequencies)?
It doesn't seem to me that it would matter all that much what their plotting scaling was/is, although if one were able to use the previous suggestion to digitize those and scrape the traces from them, one should be able to scale the .dat data to match IF the data being saved are the same as those being plotted -- seems to me that that's where the real uncertainty lies; it's not clear we even know that, for sure, at this point.
I just noted on the datasheet had overlooked that the A/D sampling rate is said to be 25.6 kHz whereas the data rate in the data file is supposed to be 125 Hz. I'm wondering now if this is even a sample/hold A/D or if they're just sampling round-robin from one channel to the next. The curious thing then would be how are resampling down to the 125 Hz and if making phase adjustments for channel skew, etc., etc., ...
Star Strider
on 8 Sep 2022
‘But, as a clinician, does it really matter all that much what the actual scale is; aren't ECGs read by pattern recognition of the general waveform and not by any absolute magnitude (other than frequencies)?’
Voltages matter. For example, a 1 mm (0.1 mV) or greater Q deflection is significant, usually indicating a transmural myocardial infarction. Also, an R deflection of 12 mm (1.2 mV) or greater in lead II generally is interpreted as left ventricular hypertrophy (usually attributed to hypertension or a stenotic — narrowed — aortic valve). The absolute amplitude of ST-T interval voltages, positive or negative, are also important, for different reasons and with different interpretations. The segment from the end of the P deflection to the beginning of the QRS complex is generally considered to be isoelectric, and for that reason a reference.
The information I was able to recover listed the sampling frequency as 1024 Hz. When I used that to create a time vector, and plotted it with the EKG trace, the intervals and heart rate were appropriate.
I still can’t figure out how to translate the EKG data to absolute voltages.
Susan
on 8 Sep 2022
dpb
on 8 Sep 2022
My bad recollection on the data frequency, sorry, you're right...I was confounding another topic and didn't go look.
On voltages, then it would appear one is back to the first-mentioned ideas of using calibrated inputs to then try to match to outputs...
But, if there's no indication in the vendor software of what the voltage ranges on the plots are from their processing/preparation of those plots, from your above assessment it would appear the device itself would be worthless. It MUST be in the output available somewhere then...
Star Strider
on 8 Sep 2022
It outputs correctly to .pdf files and can output a full 12-Lead EKG. It just hides how it does that conversion.
Susan
on 8 Sep 2022
Star Strider
on 9 Sep 2022
@Susan — If you have a calibrated signal generator available, and a way to calibrate its output precisely, one option would be to put a 1 mV signal (measured peak-to-peak, RMS 0.0707 mV sine wave preferably) across one of the leads, and then record the output. The frequency should be about 25 Hz, although the frequency does not have to be precisely calibrated, only the amplitude.
Susan
on 9 Sep 2022
Star Strider
on 9 Sep 2022
As always, my pleasure!
It’ill be interesting to see the results, and I hope they’ll lead to some insight into this. I suggest recording the same signal with different instrumentation parameters in different runs in order to understand how they relate to the recorded signal. (I wish I’d thought of that a few days ago!)
This may be the information we need. If not, well, at least we considered that approach.
Susan
on 9 Sep 2022
More Answers (1)
We've elsewhere determined the data are recorded as signed 16-bit integers which span +/-32K which is a 64K range. A default double has approximately 15 decimal digits of precision (53 bits in the significand) so it can easily hold all the precision available from the instrument without any loss.
Given the number of possible inputs from the device is only the 64K unique values, any more than that number of unique values in a processed input signal will have come only as artifacts during the calculations as long as the calculations are on a per channel basis.
14 Comments
Susan
on 31 Aug 2022
As we discussed before and he brings up again, the answer to that Q? is still dependent upon figuring out "whatcomesoutta" with a given known "whatgoesinna" signal.
As far as "interference", that also will depend wholly upon just what that interference is in amplitude and frequency content as far as what it will mean in interpretation.
What is the source of this supposed interference; where is it entering the signal chain? If it's external RF or somesuch modifying the inputs of the instrument, it'll have the same gains and filtering applied to it as to the real data and its relative effect will be exactly proportional to the signal as is its magnitude in comparison to the input signal at the point it is picked up.
IOW, you can't tell the difference once you've sampled the waveform; if it's significant, it'll undoubtedly wreak havoc on the interpretation, but unless you have some way to characterize it, it'll be difficult at best to know what it is. I don't see that some definition of "resolution" in the instrument has any real bearing on the problem of identifying signal corruption; as above, the instrument itself has an N-bit A/D and is outputting 16-bit signed integers of the scaled magnitude of the inputs. As of yet, we here don't yet know what has been applied to those values -- are they the raw outputs of the A/D scaled to some input voltage range or the actual trace magnitudes scaled back to a 16-bit output range? We dunno until have the results of the tests or you can find (so far missing) documentation of the real content of the data files.
Susan
on 31 Aug 2022
Again, it will depend upon how this interference is actually introduced into the system and where that occurs -- if it is an induced voltage in the leads before it gets to the analog input anti-alias and low-pass filtering modules, then it should be pretty-much taken care of -- that's their purpose. Since those kinds of signals are in the MHz and higher frequencies and this device has analog low pass filtering somewhere around 60 Hz, I'd not expect it (the device) to have any appreciable sensitivity in those frequencies. (You can illustrate the effect with an ordinary digital volt-meter and a signal generator -- input the output of a signal generator sine wave at 1V RMS into the DVM on AC volts at 60 Hz, say, then raise the frequency slowly. By the time you get to several kHz and beyond, the meter will have dropped in its shown reading significantly, just how much depending on the specific meter, but by probably 20 kHz it'll read essentially 0 V. The input circuitry simply doesn't have the bandwidth to pass higher frequencies; the device is designed for low frequency inputs. An oscilliscope, otoh, depending on the model, may have bandwidths up into the GHz range.)
I would strongly suspect you'll see the same effect with this device but at much lower frequency inputs -- it simply won't "know" the high-frequency components of the signal are there by the time the signal gets to the A/D to be digitized.
But, if you somehow manage to corrupt the data aftewards, you've got the problem before that you can't really tell anything about what is/is not noise from some "resolution" number; it'll all be mixed up together and present itself in some form of distortion of a waveform that otherwise would have resulted.
As to the Q? you raised about resolution -- the resolution of the sampled data is 1X the input scalling factor; the inferred scaling if they are raw waveforms would seem to be of the right order of magnitude based on @Star Strider's physiological knowledge presuming the digitized waveforms represent those signals and haven't been otherwise normalized internally first.
Again, until can determine just what those data are in relationship to a known input, it's not possible to know with absolute certainty.
Susan
on 1 Sep 2022
dpb
on 1 Sep 2022
The proposed interference is not an induced voltage in the leads, so I don't think it gets to the analog input anti-alias and low-pass filtering modules. While the recorder is connected to the leads to collect data, there is a Wi-Fi signal in the environment that may interfere with the EKG signal, ..."
How is that interference postulated to get to the device if not through induced voltage variations in the input leads (which are also probably shielded, besides)????
It certainly isn't sufficient to cause hardware errors in the computations after the data are digitized and the device is digitizing only what it sees internally at the input to the A/D which has to be after the analog filters and coming into it on those leads. The A/D can't digitize from the air, only what it's physically connected to and I'd be quite sure those areas of the device will be well shielded from EMI as well.
Since there is now a veritable plethora of personal monitoring devices on the market, it dawned on me somebody must be making chipsets -- the first I found was (almost of course) from Analog Devices. They even have an evaluation board kit. Something of this sort might be more suitable for the kind of project you've embarked upon. <AD8232 Product Evaluation Kit> is a link to the documentation set for the chipset and the evaluation board plus links to other useful information for data acquisition. The Designer's Guide for instrumentation amplifiers is a gold mine of "gotcha's" and "how-to's" to get through the snake pit of low-level signal acquisition.
The data sheet for the AD8232 chipset does, in fact, have a section on the issues with RFI and it has built into it right on the board filtering specifically for the problem (as I'd wager will the product you're using) .
While this is "just" a three-lead setup, from the description I'd venture the sensors for the Holter device are very much similar if not based on the specific chipset -- I did not do an extensive search for more channel devices but they're bound to be out there. It wouldn't seem that there would be any need of having more channels for your purposes of investigation of noise contamination of signals.
Good luck...
Susan
on 2 Sep 2022
Unless the device gets saturated at/on the sensor board circuitry itself, I can't see how the analog lowpass filters can't help but prevent such high frequency components from ever showing up.
I don't know for absolute certainty, but from the AD datasheet theory section,the bias voltage simply provides a common reference "ground" on which the actual signal (the output of the differential amplifier @Star Strider mentioned above) "rides" -- it simply moves the overal signal to be sampled by the A/D converter to be in the mid-range of its scale; it's not directly related to the signal level about that reference other than to ensure the pk-pk amplitudes are within the sampling range of the A/D scale. Study the AD datasheet; I'll bet $$ to donuts your device uses virtually the identical circuitry given the descriptions do have, it might even be built around the given chipset or its bigger brother/cousin.
One thing that I didn't understand before is now clear to me though -- the initial transients are real and simply artificacts of the low cutoff frequency of the highpass filter after the leads are connected and the device comes out of saturation. Initially I had figured those artifacts would not be present in that one wouldn't record data until a steady-state base level had been reached. Hence, "back in the beginnng" of this exercise I was doubtful we were actually reading the data file correctly. Clearly, that isn't so; we're pulling the data as it is; there's still some uncertainty as to whether it was written before, during, or after all the internal processing to create the plotted outputs. That's going to be difficult to do really well if you can't find a way to digitize them or get to the actual plot data itself.
Susan
on 2 Sep 2022
It has certainly been through the anti-aliasing filters already, yes.
I don't know that we yet know for sure about whether what is written is raw, partially processed or finally processed waveforms, though, do we?
All (at least I) know is they are writing out 16-bit signed integers that reflect the general shape/pattern of the processed results you get for the same dataset -- but you've not yet been able to prove that you can reproduce those by a consistent, unique linear transformation of the those values. But, then again, you haven't yet demonstrated that can't be done, either.
We're back to the original suggestions that need to put the known voltages and waveforms in and see if get identically those voltages out to really be able to determine if those are raw data values or whether they may have been processed and then the output waveforms of the plots converted to 16-bits and written out -- or somewhere in between. One would presume it is either the input or the final output and not someplace on the way between home and the forum they chose to stop and write, but "ya' never know!" what they may have been thinking.
I don't suppose the user manual says anything at all more about what the actual data are, does it? The very short blurb you posted previously only had a (very incomplete) description of the header and that it was 16-bit signed integer, but what those integers represent wasn't mentioned.
Susan
on 8 Sep 2022
dpb
on 9 Sep 2022
As @Star Strider commented above, start simple with sine wave of known amplitude and frequency. What you have for test gear will control the "how" and what can be done easily, of course. I'm such an old guy and been out of consulting gig for 20+ years now and what I had then was easily 10 years out of being current I really don't have a handle on any of the current stuff on the market; either from the traditional vendors like Tektronix nor any of the now-ubiquitous miniature stuff built around the PC or a standalone device.
The signal generator doesn't even have to be a calibrated source, precisely, if you have a scope or a DVM -- you can tee the signal into it as well as into the device to measure the voltage...
Susan
on 9 Sep 2022
Categories
Find more on Signal Integrity Kits for Industry Standards in Help Center and File Exchange
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!
