Timing of data acquisition on the USB 6212

[Ben__B]

I'm putting together an acoustics teaching laboratory.  The basic idea is to send out a pulsed signal that drives a speaker, then the acoustic signal travels down a waveguide where it is measured with a microphone and sent to a DAQ.  One of the important things here is that it is possible to measure the propagation time of the sound waves, so I need the data acquisition to happen at a fixed time relative to the output sound pulse.  I tried this with a sound card, but there are many milliseconds of random jitter between the writing and reading from the sound card.

So I was looking at the USB 6212.  On paper it looks ideal: 2 outputs and lots of inputs.  From what I understand it is possible to trigger the analogue data output and input so that there is no timing jitter between them.  The only question is this: I was thinking of using 2 analogue inputs: one as a reference that collects through a speaker/microphone system to use as a normalisation to the second channel that collects through the waveguide (see attached diagram).  The thing is that I need the timing on the 2 analogue inputs to be consistent and jitter free so that it possible to compare the phase of the signals that I collect.  Will this be possible using this DAQ system given that the ADC is multiplexed between the channels?  Will there be a delay between the 2 channels and if so will it be deterministic and known?

Thanks for your help........

Ben 

[aNIta B · Accepted solution]

Hi Ben,

         Cool application!  To answer your question- yes, there is a delay and it is deterministic. Something to note about the 6212  is that your multiplexing rate will be determined by the convert clock.  The convert clock will operate at the fastest rate of the device plus 10us*.  So in the case of the 6212, with it's max sampling rate of 400kS/s (aggregate), your pulses will occur every 12.5us ((1/400,000) + 10us).  

*12.5us converts to 80kHz, so at that point, the convert clock simply operates at 1/(aggregate rate). So to sum this up:

From 0-80kHz: there is a 12.5us lag multiplexing

From 80kHz-400kHz: there is a  1/(aggregate rate) lag

On top of that, you can also set that rate through the DAQmx driver.  You can simply use a DAQmx Timing property node»More»AI Convert»Rate (or Maximum Rate to determine the max).

 

If that's an issue, I'd recommend using a device that has simultaneous sampling- let me know if you have further questions.  Take care!

[Ben__B]

Thanks for you help, looks like this might be the device I am looking for since for the acoustic timescales I am working on is that I won't even notice the delay, which is great.

That said, after reading through the material on convert clocks I'm not totally clear on what happens here:

1) You say that the delay is 

  From 0-80kHz: there is a 12.5us lag multiplexing

  From 80kHz-400kHz: there is a  1/(aggregate rate) lag

 so if I set the sampling rate to 400kHz, I get a 2.5us delay?  What happened to the 10us?

2) Imagine I use 2 analogue inputs and I set the sampling rate of each to 50kHz.  That means that there will be a delay of 12.5us between the data on these channels.  Is there a way of knowing which one leads and which one lags?

cheers,

Ben 

2) If I sample on 2 channels, there will be a delay between them of 12.5us.  Is there a way of knowing which channel will lead?  

[aNIta B]

Hi Ben,

       As for your first question- the 10us is a spec that is added in as a part of an equation.  80kHz is significant because that's the maximum sample rate that allows the mux to fully settle. The convert clock is limited to the maximum sampling rate of the board-so, after 80kHz, that extra time for settling is dropped, and the board's convert clock operates as fast as possible. 

As for your second question:  If you're sampling on 2 channels, each at 50kHz, you would have an aggregate 100kHz sampling rate, giving you a 2.5us delay (unless you have set it to be something different through a property node).  If you mux say, channel 0:1, channel 0 would lead channel 1.  Otherwise, there's not a definitive (or programmatic way) to tell which channel is leading.  Let me know if you have other questions!

[John_P1]

Just to clear up a couple of points:

The convert clock rate is user-settable using the DAQmx Property node that was mentioned earlier.  The rules that were mentioned previously are simply the default rates that DAQmx chooses.  The 10 us rule is a bit arbitrary, but the idea is to ensure enough settling time between channels to minimize settling error (see settling error graph below from the specifications page).  Of course, when sampling at higher rates we don't have the luxury of adding the full 10 us between channels and the delay is reduced as necessary to evenly space convert clock edges between sample clocks periods.

Based off of your source impedance, you might decide to increase or decrease the convert clock rate as necessary.

The Scan order is user-defined by the order of the channels specified in software.  To programmatically obtain the scan order of an existing task you can use a DAQmx Task Property node, the channels will be returned in an array in the order of the scanning:

For example, Dev1/ai0:2 would scan channel 0 through 2 (in order).  The above example scans 1, 0, then  2.  The Mux on the 6212 can scan in any order (which isn't always true for some of our Legacy devices).

Best Regards,

Message Edited by John P on 02-08-2010 06:28 PM

Message Edited by John P on 02-08-2010 06:29 PM