Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Applying a single counter pulse after detected peak

Solved!
Go to solution

Hi guys,

 

I want to generate a single counter pulse when an ecg signal is in the resting phase of the heart. This is after the small wave behind the big peak. I tried to solve this with peak detection. After detecting the big peak (r peak), the counter should wait for a specific time ('low time') and then write a TTL pulse. Basically I achieved that (see VIs attached) but the counter pulse doesn't wait for the 'low time'. It is way to early (picture: ECG_Trigger.png) and I have no idea why. I tried two solutions but none of them worked. Has anybody an idea what the problem is and how to solve it? I also tried with queues but that is the same problem

 

I don't have access to the Biomedical Tool Kit (unfortunately) and I use the DAQ 6361. 

 

Thanks for your help!

 

(In txt file are ecg samples for simulation)

 

0 Kudos
Message 1 of 5
(926 Views)
Solution
Accepted by topic author skittlesgiraffe

RE: Delay time - see point # 3 in our prior discussion.  A single pulse will use "initial delay" rather than "low time".  When you don't wire up a value for initial delay, the default value is the minimum possible, i.e.,  2 cycles of the timebase.  For an X-series that's 20 nanosec.

 

Also, you read 100 msec worth of data from your AI task and then make a software decision about pulsing.  That'll add 100 msec worth of jitter to your pulse delay time

 

I would recommend that you set up the counter as a hardware-retriggerable single pulse.  Set up the AI task to use analog triggering so that the pulse task can trigger off the Analog Comparison Event.   You may want to keep monitoring the ecg signal to estimate the heartbeat rate so you can adjust your pulse timing parameters accordingly.

 

Note: with a retriggerable pulse (or pulse train), the default behavior is to use "initial delay" instead of low time ONLY for the very first trigger.  All subsequent pulses will use low time.  X-series let's you override this and use initial delay for all retriggerings, but  you'll be better off with the default behavior.  The reason is that low time and high time can be adjusted without stopping the task but initial delay can't.

 

The downside of the hardware method is that you can't adjust your analog triggering properties on the fly.  You'd need to stop the AI task to make changes.

 

<a lot of time passes...>

Had time at the end of the day to make a few mods to your posted code to show how to set up the analog triggering and the retriggerable pulse.  Give it a try.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 2 of 5
(905 Views)

Dear Kevin,

 

thanks a lot for all your help and especially for the time you spend creating the VI.

 

You are right, I forgot the initial delay. Actually I knew that but thanks for reminding. I already managed to solve my task using the idea you suggested. The solution with the analog comparison event works quite well. However I have to correct the VI you send because you swapped the analog inputs. The first input must be the ecg input because that is the analog signal I want my analog start trigger to detect and then to generate the analog comp. event. Maybe you misunderstood that I named the second input 'trigger input'. It is because the pulse I generate is a trigger pulse for another device. 

 

My problem is that ecg signals are quite variable and if you don't filter or amplify them right before it enters the daq they have an offset and are really small (voltage range: +- 0,0002V). Actually I thought the daq is capable of this but apparently not or I made a mistake somewhere.

Amplification is no problem but filtering is so that the offset is gone.

 

I give you an example: I have two signals. Both amplified with a gain of 100 so they are in a higher voltage range. I will attach them. The first one (ECG Neuro) has a positive offset and works fine with analog comp event. The second one (ECG Thorax) has a negative offset and doesn't work. Somehow the pulse is generated continuously and doesn't wait for the next r peak to appear. My first thought was that ECG Thorax is too small but both signals have the same range of around 0,03V. Do you know what the problem could be?

 

I was hoping that I can find another solution so that I filter the signal in Lab view and then creating the counter pulse. But I see the problem with delay times because of processing. The hardware set up is way faster and accurate. Using additional filters in the loop will slow down everything right?

 

Best regards 

Sarah 

0 Kudos
Message 3 of 5
(884 Views)

Sorry, I can't come up with any good explanation for the different behavior you've seen.

 

I *do* notice that your 'analog edge trigger source' is shown to come from a channel that isn't configured to be part of the task.  I wouldn't have expected that to work, but maybe the default values on the front panel aren't the ones you actually used when running?   I noticed that the A/D ranges and analog trigger thresholds are set differently on the 2 front panels too.

 

I *think* I recall that in many devices, the analog triggering circuitry has a more limited resolution than the normal AI channels.  I wonder if that's somehow playing a role in things, particular the case where the pulses seem to get triggered but are out of sync with the ecg signal.

 

I guess I'd probably start getting down to basics.  For example: capture some examples of your AI signals and save them to file.  Then replay that same data with an AO task while you loop back the AO signals to your AI channels.   Maybe you'll want to tweak those AO signals in various particular ways so you can carefully explore the behavior under various *controlled* conditions.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 4 of 5
(874 Views)

Thank you for your quick answer and your help. 

Have a nice day!

0 Kudos
Message 5 of 5
(856 Views)