USB 6218 hardware synchronous sampling/multiplexing query

[jcannon]

Hi all,

I have a hardware related question regarding the USB 6218 multifunction DAQ device...

I have 10 AI channels that I would like to sample at 2kHz.... These channels ideally should be sampled synchronously... Given that the 6218 uses multiplexing and does not perform simultaneous sampling, it is possible to determe the time delay between contiguous samples?...

That is to say, is the 0.5ms duration between samples sufficient to permit all samples within a given scan to be performed without interfering with the acquisition of subsequent samples? I would be looking at using a scan length of 100 (so 20 scans per second)

http://www.ni.com/white-paper/4105/en/

Any comments appreciated.

Thanks,

Jack

[AgentAstronaut]

Hi jcannon,

If you look at the specification sheet (http://www.ni.com/pdf/manuals/371932f.pdf) you can see that the maximum sample rate on AI is 250 kS/s for multichannel (aggregate). That means, for your application of 10 channels, you can sample at 25 kS/s (essentially the same as 25 kHz) per channel. So you can meet your 2 kHZ sample rate.

The other spec you want to look at is "Settling Time for Multichannel Measurements". Depending on the accuracy you want you have different settling times. For instance, the most accurate reading requires 7 us of settling time. With 10 channels you need at least 70 us between each sample clock tick.

Finally, if all the readings are on the same task using channel expansion then you will know that at least all the measurements are one-to-one (each measurement  cooresponds to a single sample clock cycle). You can use a property node to set the convert interval (not exactly the settling time for the multiplexer, but a useful description for now). If you set the convert interval, you can predict the exact phase difference between the measurements on each channel.

regards,

Michael

[jcannon]

Hi Michael,

Many thanks for your detailed reply... Could you please clarify what you mean by channel expansion? All channels are being sampled through the same task.

Regards,
Jack

[AgentAstronaut]

"All channels are being sampled through the same task."

That's channel expansion. Perfect.

Here is a KB for more information.

http://digital.ni.com/public.nsf/allkb/B7E7C6A92467E5438625792E0067ED80

[AgentAstronaut]

By the way, you can set the convert rate with a property.

http://zone.ni.com/reference/en-XX/help/370469AA-01/daqmxprop/attr1848/

[jcannon]

Ok...

"With 10 channels you need at least 70 us between each sample clock tick."

So based on this there should be issue with sampling the 10 channels at a rate of 2kHz (or 4kHz at most) given the 250-500 us between sample clock ticks?

Regards,

Jack

[AgentAstronaut]

Hi Jack,

Since 250-500 us is greater than the required 70 us, it will be fine. The read line will have enough time to settle between each reading that it will be able to read your data accurately.

Regards,

Michael

[jcannon]

Is the 70us independent of the number of "read samples" programmed in the DAQ assist or low-leve read vi? Or is the 70 us settling time applied to every data sample point?

I currently sample with by reading in 100 samples each scan (50ms blocks of data at 2kHz)?

Thanks,

Jack

[John_P1]

The time between consecutive channels is very easily quantifiable--it is the inverse of the convert clock rate.  The convert clock rate can be set via a DAQmx Timing Property node.  If you want to minimize the delay between channels, you should set the convert clock to the highest rate (250 kHz on the 6218 according to the spec).  If your signal sources have a high impedance or you have high accuracy requirements you might consider a slower rate to minimize settling error between channels (the convert rate of course must be >= sample rate * number of channels):

If you don't explicitly set a convert clock rate, DAQmx will pick one for you.  The idea of the DAQmx algorithm is to split the difference between reducing settling error and minimizing time between channels.  If you have specific requirements I'd suggest explicitly picking a convert clock rate that meets them.

Best Regards,