Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

USB 6002 - triggering accuracy?

Solved!
Go to solution

I've got a USB 6002 and a relatively simple voltage acquisition task: sample an analog input signal until an external digital IO changes. The speed isn't that high, if I can reliably capture at 100Hz I'm fine as long as I can reliably tell what the analog value was when the digital signal changes state. I will be running a C# .Net application using DAQ Mx.

 

My question: on the low-end USB DAQs like the 6001 and 6002, is the acquisition, buffering and triggering done on the device or on the PC? I'm concerned that the latency might be high if some process is hogging the CPU or USB bus.

 

Thanks,
Andrew

 

0 Kudos
Message 1 of 3
(1,148 Views)
Solution
Accepted by topic author zwieback

Triggering and acquisition happen on the device in hardware.  Latency and timing consistency will be fine for analog acquisition.

 

Buffering is typically split.  The hardware device has a small-ish buffer while the task buffer that resides on the PC is typically larger.  The hardware buffer gives the DAQmx driver a little time to move samples from the device to the task buffer on the PC.   Then your app needs to retrieve data from the task buffer fast enough that it "keeps up with" the acquisition.

 

I typically define task buffers that are 1-5 seconds long and read 1/10 sec worth of samples per call to DAQmx Read.  It works reliably across many devices, many sample rates, and apps that may run for hours (or even days).

 

All that said, those cheaper USB devices do *not* support hardware-based sampling of digital signals.  You'll be better off wiring the digital signal into another analog channel that you include in your task.  Then you can search through the data for the digital transition as you read it from your task.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 2 of 3
(1,136 Views)

Kevin - thanks for the response. Yeah, I was wondering about treating the trigger (really more of a "marker") signal as another analog input. I'll give that a shot. Right now we only have a single voltage reading from a transducer so if I can acquire two analog values side-by-side I'll be fine.

 

Andrew

 

0 Kudos
Message 3 of 3
(1,123 Views)