example

[Lily]

Is there anyone who has the example program to separate two low
frequency signals and get the frequencies from the signals( For
example, ECG signal and respiration signal)?

Thanks,

Lily

[Labviewguru]

Lily,

Tellling us that the two signals are respiration and ECG does no good. Most of us don't work in the medical field, and even if we did (and for those who do), just that information isnt' enough.

How are these signals generated. From what equipment? Are they analog signals? Are they two separate signals?

In order to solve the problem, we first have to know the problem. You need to look at the signals. If you have some way to determine the exact nature of the signals, then perhaps someone can be of more assistance.

Please provide as much detailed information about these signals as possible.

[DougD]

Labviewguru:

My last job was with a biomed company. Our machine measured heart
rates as part of it's function and it assumed that they top out at 255
beats/minute. It didn't measure respiration but a reasonable guess is
that they would top out at 50 respirations/minute. I don't think that
it is possible to separate two such low frequency signals that are
highly variable and unpredictable as these are.

The usual scheme of a high-pass filter and an low-pass filter to
separate the two signals probably won't work here given the problems
involved (low frequencies, high signal variability.)

I think that the best course of action is to redesign the system to
use two separate transducers, one for HB and the other for
respiration.

Doug De Clue
ddeclue@
bellsouth.net

Labviewguru wrote in message news:<50650000000500000060920000-1027480788000@exchange.ni.com>...
> Lily,
>
> Tellling us that the two signals are respiration and ECG does no good.
> Most of us don't work in the medical field, and even if we did (and
> for those who do), just that information isnt' enough.
>
> How are these signals generated. From what equipment? Are they
> analog signals? Are they two separate signals?
>
> In order to solve the problem, we first have to know the problem. You
> need to look at the signals. If you have some way to determine the
> exact nature of the signals, then perhaps someone can be of more
> assistance.
>
> Please provide as much detailed information about these signals as
> possible.

[Labviewguru]

Okay, now I am starting to get an understanding of the signals, I think.

If this person is trying to measure the electrical signals that come directly from the electrodes and go into a single DAQ channel, then I would suggest that trying to save money by using only one channel is a serious mistake. There may be a way to separate these two signals, but the software work required to do it just doesn't make economic sense.

I recently worked on a project that is a good example of throwing money and software at a problem that was better solved with hardware, setup, and a little common sense, not to mention only a few cents (okay, a couple thousand bucks, but when we bill out at $125/hour, its not long before software overtakes any expense t
hat hardware could have easily solved...)

I'm not sure how these two signals are being combined, but if it is a matter of the same electrode picking up two signals, then the primary signal for one can be used to filter out the other, which can be done through hardware easier than through software I think.

If I just had more information, or perhaps a sample file of the data, I could probably offer better advice.

[Scott Seidman]

Labviewguru wrote in news:50650000000500000099920000-
1027480788000@exchange.ni.com:

> Okay, now I am starting to get an understanding of the signals, I
> think.
>
> If this person is trying to measure the electrical signals that come
> directly from the electrodes and go into a single DAQ channel, then I
> would suggest that trying to save money by using only one channel is a
> serious mistake. There may be a way to separate these two signals,
> but the software work required to do it just doesn't make economic
> sense.
>
> I recently worked on a project that is a good example of throwing
> money and software at a problem that was better solved with hardware,
> setup, and a little common sense, not to mention only a few cents
> (okay, a couple thousand bucks, but when we bill out at $125/hour, its
> not long before software overtakes any expense that hardware could
> have easily solved...)
>
> I'm not sure how these two signals are being combined, but if it is a
> matter of the same electrode picking up two signals, then the primary
> signal for one can be used to filter out the other, which can be done
> through hardware easier than through software I think.
>
> If I just had more information, or perhaps a sample file of the data,
> I could probably offer better advice.

Most likely, the scenario is something like a respiratory artifact lying on
top of the ECG signal, and someone is trying to recover both signals.
Sounds more like a class project than a practical app to me. In a clinical
environment, they'd measure the ECG if that's what they needed, or use a
pulse oximeter to tell you if the heart is beating and the blood is
oxygenated (that's the output of respiration, and the real bottom line
anyway). The tacit assumption here, in any case, is that for some reason
you can't just take both measurements. Maybe they need to measure 17
signals, and don't want to support an additional A/D board for one channel.
Maybe the measurement is remote, and they are out of telemetry channels.
Maybe they are trying to make the measurement on a space shuttle astronaut,
and anyone who has ever worked with them knows that there are only so many
transducers they have time to properly apply. If they are already wearing
ECG electrodes for some high-priority assessment, can respiration
information be recovered for free? Maybe the data in some very expensive
experiment has already been collected, and the original poster is trying to
recover some information offline that they neglected to collect earlier!

There are many practical scenarios where you might want to do such a task.
The most compelling reason I can think of, though, is that a student in a
Biomedical Instrumentation course has been told to do so!

Sometimes it's easier to do something with hardware, but if its going
anywhere near a patient new hardware must be UL listed and rigorously
safety checked, and sometimes FDA approved as a medical device, making
software the more viable (i.e., cheaper and faster) option, even at
$125/hour for two months of programming.

Can it be done? Probably (and it's probably already done and published!).
The amount of difficulty involved would depend on what the user is trying
to do with the info. If all you need from the ECG signal is a recovery of
heart rate, and you don't care what the waveform looks like, piece of
cake-- high pass filter at somewhere in the neighborhood of 80 Hz to pick
up the spike of the QRS complex. Life gets more difficult if you want an
ECG waveform that you can hand to a cardiologist for diagnostic purposes.

ECG and respiration signals also "look" different, thus wavelet techniques
might be of some help to separate them. Other possible approaches--
Respiratory signals are largely sinusoidal, and would thus yield a sinusoid
of the same frequency when differentiated, but think for a moment what
differentiation of the ECG signal would do.

I'd try a search in IEEE Transactions BME to start.


--
Scott
Reverse first field of address to reply

[wiebe@CARYA]

Hi,

Some kind of neural net could work. I know of aNN's (artificial neural
networks) splitting a sound signals into two seperate sources.

Don't know if this will ever will be used in medical environments. aNN are
hard to validate (calculations like input response etc. do not apply to
aNN's).

Such a aNN would need training. Give it a combined signal, and the two
'learning' signals (original). do this a lot of times, with a lot of
different cases (patients).

Fiddle around (layers, weights, neurons, etc.) with the aNN (or make a
genetic algorithm to do it for you) and you've got a signal splitter.

Have fun...

Wiebe.



"Scott Seidman" wrote in message
news:Xns92635AA79FD74ScottSeidmanmindspri@130.133.1.4...
> Labviewguru wrote in news:50650000000500000099920000-
> 1027480788000@exchange.ni.com:
>
> > Okay, now I am starting to get an understanding of the signals, I
> > think.
> >
> > If this person is trying to measure the electrical signals that come
> > directly from the electrodes and go into a single DAQ channel, then I
> > would suggest that trying to save money by using only one channel is a
> > serious mistake. There may be a way to separate these two signals,
> > but the software work required to do it just doesn't make economic
> > sense.
> >
> > I recently worked on a project that is a good example of throwing
> > money and software at a problem that was better solved with hardware,
> > setup, and a little common sense, not to mention only a few cents
> > (okay, a couple thousand bucks, but when we bill out at $125/hour, its
> > not long before software overtakes any expense that hardware could
> > have easily solved...)
> >
> > I'm not sure how these two signals are being combined, but if it is a
> > matter of the same electrode picking up two signals, then the primary
> > signal for one can be used to filter out the other, which can be done
> > through hardware easier than through software I think.
> >
> > If I just had more information, or perhaps a sample file of the data,
> > I could probably offer better advice.
>
> Most likely, the scenario is something like a respiratory artifact lying
on
> top of the ECG signal, and someone is trying to recover both signals.
> Sounds more like a class project than a practical app to me. In a
clinical
> environment, they'd measure the ECG if that's what they needed, or use a
> pulse oximeter to tell you if the heart is beating and the blood is
> oxygenated (that's the output of respiration, and the real bottom line
> anyway). The tacit assumption here, in any case, is that for some reason
> you can't just take both measurements. Maybe they need to measure 17
> signals, and don't want to support an additional A/D board for one
channel.
> Maybe the measurement is remote, and they are out of telemetry channels.
> Maybe they are trying to make the measurement on a space shuttle
astronaut,
> and anyone who has ever worked with them knows that there are only so many
> transducers they have time to properly apply. If they are already wearing
> ECG electrodes for some high-priority assessment, can respiration
> information be recovered for free? Maybe the data in some very expensive
> experiment has already been collected, and the original poster is trying
to
> recover some information offline that they neglected to collect earlier!
>
> There are many practical scenarios where you might want to do such a task.
> The most compelling reason I can think of, though, is that a student in a
> Biomedical Instrumentation course has been told to do so!
>
> Sometimes it's easier to do something with hardware, but if its going
> anywhere near a patient new hardware must be UL listed and rigorously
> safety checked, and sometimes FDA approved as a medical device, making
> software the more viable (i.e., cheaper and faster) option, even at
> $125/hour for two months of programming.
>
> Can it be done? Probably (and it's probably already done and published!).
> The amount of difficulty involved would depend on what the user is trying
> to do with the info. If all you need from the ECG signal is a recovery of
> heart rate, and you don't care what the waveform looks like, piece of
> cake-- high pass filter at somewhere in the neighborhood of 80 Hz to pick
> up the spike of the QRS complex. Life gets more difficult if you want an
> ECG waveform that you can hand to a cardiologist for diagnostic purposes.
>
> ECG and respiration signals also "look" different, thus wavelet techniques
> might be of some help to separate them. Other possible approaches--
> Respiratory signals are largely sinusoidal, and would thus yield a
sinusoid
> of the same frequency when differentiated, but think for a moment what
> differentiation of the ECG signal would do.
>
> I'd try a search in IEEE Transactions BME to start.
>
>
> --
> Scott
> Reverse first field of address to reply

[JRA]

You can do this. It depends upon how accurate you want the filtering. The best way would probably be to use bandpass and bandstop filters. These only allow signals with certain frequencies to pass through. For example, if your signals were 10Hz and 20Hz, you could use a bandpass filter with cutoffs of 15Hz and 25Hz, and this would allow only the signal with the 20Hz signal to pass through. With a bandstop filter of the same value, it would only allow the 10Hz signal to pass through (it would "stop" the 20Hz signal). I would suggest trying these. There is an example which shows this on NI's website. I'm attaching it to this discussion. You may want to take a look at this. There are also quite a few examples which come with LabVIEW. Search through th
ese and they give excellent examples of how to apply software filters to your signals.