USB 6351 digital streaming output rate

[harsh.mathur@iiap.res.in]

Hi,

Thank you for the insightful response.

I have a USB 6351, and my requirement is to update the two channels of analog output every 0.5 ms. As you have mentioned about the absence of DMA in USB devices. Thus, my observation is for me to use the DAQmxWriteAnalogF64 function, it requires 1 / 0.5 per sec = 2000 * 64 = 128000 bits/sec = 16 MB per sec.

My question is:

There are two ways of using the NiDAQ analog output:

1. Without Buffer (hardware-timed), I use DAQmxCfgOutputBuffer(taskHandle, 0). Benchmarking with google benchmark framework, this function returns in 1.5 ms. But there is a guarantee that the voltage is actually applied on the board.

2. With Buffer size (I use size=1),  I use DAQmxCfgOutputBuffer(taskHandle, 1). Benchmarking to update many samples, gave an average time of execution of this function to be 0.001 ms per sample, i.e. 1 million samples per second. My question here is what is the actual analog output updation rate I am getting? Is it overwriting buffer before it gets updated  in the hardware in the call to DAQmxWriteAnalogF64? or I am getting the advertised 1 million samples per second rate?

Let me know.

Thank you.

Regards,

Harsh

[Kevin_Price]

While the earlier thread you attached to does indeed have some really helpful information, *some* of the details and specs are specific to digital generation.  The specs and constraints will be a little different for your situation with analog generation.

First off, a 2 kHz sample rate is only going to require 32 kB/sec bandwidth from your app to the task (2000 samples/channel/sec * 8 bytes per float * 2 channels), a rate that should be easily sustainable with your device.  Besides that, I'm pretty sure this actually gets reduced by DAQmx into 8 kB/sec bandwidth over the USB bus because the driver manages the conversion from 8-byte float to 2-byte int before transfer.

 Since bandwidth shouldn't be an issue, that leaves latency as the other big consideration.  Do you intend to react to developing conditions and calculate your AO outputs on the fly as the system runs?  If so, how much latency can you accept between calculating a value and having it show up at the output?

At the extremes, there's always a tradeoff between bandwidth and latency.  The lowest latency comes from unbuffered tasks, but in unbuffered tasks the sample rate and bandwidth are limited.  (And usually the sample rate is inconsistent too, unless you're using a device that supports hardware-timed single point mode.  And USB devices don't.)

    Higher bandwidth needs require buffering which necessarily introduces latency.  In the case of USB devices, there are 3 buffer layers: the task buffer which is what you write into directly with calls to DAQmxWrite, a USB transfer buffer, and a hardware FIFO onboard the device itself.  So if you need a buffer to manage your bandwidth needs, you will also get stuck with some latency as the data needs to work its way through these buffers before turning into real world signals.

-Kevin P