USB-9234 Available sampling rate question

[Jason93]

I have a cDAQ chassis and within it I have a number of modules. One is a USB-9205 AI module and also a USB-9234 accelerometer module. There are a few others too. Digital IO, Current AI...  I have used it for a number of years but wanted get a definative answer from the community. I understand that the 9234 buffers data likely because of the internal anti-alias filtering. This will result in the input to the 9324 being delayed behind the 9205. I can tell this by sending in a square wave from a function generator and looking at the two signals. From testing it seems to be 40 samples delay. In the documentation for the 9234 it gives sampling rates with a formula. I am fine with using these sample rates for all of my signals. In fact I select 25.6kHz. Then I put in the 40 sample delay in my labview code to sync my two AI measurements (9205 and 9234) I can tell this sync works because I again plot a square wave together and they align. So as long as I use values like 12.8kHz, 6.4kHz, this delay works great.

My question is that I can select something more "round" like 20kHz. Labview allows for this but my 40 sample delay would have to be recalculated to sync the signals. (not worth it to me) However Labview doesn't say No to using 20kHz. It seems like it would when the 9234 gives very prescribed sample rates and 20kHz is not one of them.  When I collect data at 20kHz with the cDAQ for 10 seconds I get the correct number of data points for 20kHz so it is collecting at that rate. Putting in a DAQmx Timing block after the DAQmx Control Task block that will output SampClk.Rate to an indicator does report 25.6kHz even if I select 20kHz. So it tells me sampling is 25.6kHz but the data collected reflects 20kHz. Why? 

So my question is what is the reason for the prescribed rate in the 9234 documentation when Labview will collect it at the rate you pick. I do understand about the buffering of points the 9234 needs to do but I can account for that.

At this point I will just use one of the prescribed rates and account for the buffering and be done with it but I would like to be a more knowledgeable user.  I can always interpolate the date post-process to get the data at the rate I want anyway. 

Thanks!

Jason

[GerdW]

Hi Jason,

---

@Jason93 wrote:

So my question is what is the reason for the prescribed rate in the 9234 documentation when Labview will collect it at the rate you pick.

---

The reason is the way the ADC is built in this specific module: it only allows to divide the master clock by an integer number of limited range…

---

@Jason93 wrote:

My question is that I can select something more "round" like 20kHz.

---

Yes you can do that. It's also described in the manual for that module: use an external clock signal of your choice!

[Kevin_Price]

A few quick thoughts:

- No, your device doesn't actually sample at 20 kHz.  It samples at the 25.6 kHz rate that both DAQmx's SampClk.Rate and the device manual tell you.  I don't know how you tested and came to the conclusion that the actual sample rate was 20 kHz, but you must have done something wrong or made a wrong assumption about your interpretation of things.

- the amount of delay tends to be dominated by "# samples" term which is independent of the sample rate.  I'm not sure I'm technically correct but I think of the # samples part to be the delay caused by a digital bandwidth-limiting filter stage while the rate-dependent part is the delay caused by the (analog?) anti-alias filter.   Normally I've seen the rate-dependent part contribute less than 1 sample worth of delay.

- are you using channel expansion to put channels from both modules into a single task?  If not, I'd suggest giving it a try.  DAQmx can handle at least *some* of the sync-related details for you automatically.  (I don't think it'll compensate for the filter delay automatically.  I believe there exist devices that support a non-default option for doing such compensation, but IIRC they aren't cDAQ devices.

-Kevin P