Why are untriggered DAQmx reads synced to 10 msec intervals?

[tbronez]

I am programming an application in C# with DAQmx 7.4 on Windows XP with an NI 6036E Multifunction DAQ.

I am acquiring a substantial number (about 100) of short multichannel bursts (8 channels with 100 to 1000 samples per channel) at a sample rate of 20 Ksamples per second per channel. After setting up the Task accordingly and with FiniteSample collection and no sort of triggering, I run this basic code:

AnalogUnscaledReader reader = new AnalogUnscaledReader(task.Stream);
reader.SynchronizingObject = null;
short[][,] data = new short[this.numberOfBursts][,];
for (int i = 0; i < this.numberOfBursts; i++) {
    data[i] = reader.ReadInt16(this.samplesPerChannel);
}

I have determined that the time taken for consecutive reads is almost always a multiple of 10 msec (did this by using a ramp input waveform and analyzing the jumps in the acquired data). That is to say, if the data length of each read is, say, 4 msec, then there will be a delay of 6 msec between reads. Or, if the data length is 12 msec, there will be a delay of 8 msec.

If find this to be true whether I run the code in a console app, in a Windows Form app, in the app main thread, in a separate thread, with or without a SynchronizingObject, etc. I would like to be free of this hidden 10 msec timer that seems to be clocking everything, because I would like to shorten the turnaround delay between reads.

I've tried changing the DaqStream ReadWaitMode from its default setting of SLEEP, as well as explicitly starting and stopping the task, etc. But the modifications either don't execute or have no effect.

Can anyone advise?

[TheWoost]

Hi tbronez,

Because you have set this input task up as a finite acquisition with a sample rate of 20kHz, the acquisition of samples should be a buffered operation.  Based upon your description, it sounds like you are missing a certain number of samples between successive calls to the read function (i.e. when reading 4ms of data, the following 6ms of data is completely missed).  Is this the behavior that you are seeing?
What should be happening at the hardware level is samples fill a circular buffer in PC RAM (this buffer is allocated during the configuration of the task), and calls to the read function pull a block of samples defined by "this.samplesPerChannel" out of that circular buffer.  If you run one of the shipping examples for analog input acquisition, particularly the example AcqVoltageSamples_IntClk, do you see similar results with the read functions?  To find the examples on your system, please refer to the KnowledgeBase article here.

As a side note, it wouldn't hurt to upgrade to the latest version of the NI-DAQmx driver found here (version 8.6 is currently the latest version).

Regards,
Andrew W
National Instruments