Delays: reference triggers and analogue software triggers.

[KNY]

Hi,

I have a few questions I am hoping someone can help me with. For reference, I am using two cards, a DaqCard6715 (analogue output card) connected to a BNC2110 breakout box, and a DaqPad NI 6015 BNC. I use DAQmx and programme in visual c++.

1) I have recently set up a finite AI read task that uses a digital reference trigger (rising edge). It is working fine, but one aspect is surprising. I have set it up so that pre-trigger samples = half of the total samples acquired. However, I consistently find that the digital trigger does not coincide with the half way point through my recorded array of values. Instead there is an additional delay, so that for example when I collect 10,000 samples at 5,000 Hz, the digital trigger occurs around sample 5490. Is this normal, and is there something I can do about it?

2) In a different task, I have tried to implement a software analogue start trigger (as my kit doesn't have a hardware option for this). Unfortunately, there is once again a large delay. At the moment I am using DAQmxReadAnalogScalarF64 in a software loop. This function grabs a single analogue sample, allowing me to exit the loop when a threshold is exceeded. The problem is that this function takes 23 ms to return. As far as I can tell, it samples at the beginning of this period, then returns the sample at the end of this period, so that the actual software delay is 23-46 ms. This is no good: It is too long, and too variable. Is there a better option?

3) Finally, I have a hardware question about triggering. I generally use BNCs to connect my digital trigger signals to PFI lines. They work fine when I only connect the active wires, but stop working when the surrounding (ground) is also in contact. I think this may have something to do with tri-state impedance on the PFI lines. Does anyone have any suggestions relating to this, as it seems a rather unstable way to make my connections.

Ta!

[rsw]

Hi,

I'm unsure about the reference trigger, it does seem a little higher in terms of count from the expected value, the finite samples task will collect a set amount and return (possibly in chunks if it can't offer enough RAM), as those ms are quite high you could try taking it as a single value each time, while this does have additional overhead it shouldn't be anywhere near what you're seeing.

Regards,

[John_P1]

Hi KNY,

How are you measuring when the digital reference trigger occurs?  In your example, there should be exactly 5000 samples before and after the digital trigger.

As far as implementing a software analog start trigger, I think you would be better off running a continuous acquisition and throwing away all of the data until the first point when your input signal exceeds the desired threshhold.  This is assuming you are trying to trigger the analog acquisition.  If you're trying to trigger another task then you'd probably be better off using an external comparitor and using a digital trigger (USB is inherently non-deterministic and has relatively high latency compared to other busses).

What is the the ground in contact with?  I'm not sure if I understand the issue you are experiencing with the BNC connections.  What is the source of your trigger signal?

Best Regards,

[KNY]

Thanks for your responses.

To measure when the digital trigger occurs, I am simply sending the digital trigger signal (via a split lead) to one of the analogue channels that is being triggered, i.e. feeding it back. The behaviour you described is what I expected (i.e. the trigger to come exactly half way through) but that is not what gets recorded. I guess I just won't assume this is the case for any triggered reads from now on?

The analogue trigger is to trigger a different task (an analogue write) so I guess I am stuck with a slow response. I've switched to a digital trigger for this which seems to be immediate, although isn't quite as flexible as I'd like for my application.

The BNC/Trigger issue seems to have resolved, which probably means I was just doing something stupid!

Thanks again.