Asychronous Data Acquistion with the data acquisition toolbox and NI PCI-e 6320

I'd like to run an Asychronous background acquistion via the data acquistion toolbox session based interface using a NI PCI-e 6320.

I have a usb device which I command via matlab. I want to sychronise this device's actions like so:

• activate the device
• wait a user defined period (20 - 100 ms)
• software trigger a background acquistion (5ms - 1s)
• run matlab function attached to a listener which again activates the usb device
• repeat

I cannot find a way to do this efficiently. I currently have two work-arounds, both with their disadvantages:

• ForeGround Acq. This is great in that i can be sure the usb device has finished it's task before acquiring more data. The problem is the lag time! The code i have goes something like:

%%Prepare DAQ for foreground sessions
acquisition = daq.createSession('ni');
acquisition.addCounterInputChannel('Dev1','ctr0','EdgeCount');
acquisition.addAnalogOutputChannel('Dev1', 'ao0', 'Voltage');
acquisition.Rate = sampling;
outPattern = zeros(1e5,1);

for iAcq = 1:nAcq
        acquisition.queueOutputData(outPattern);

          acqData = acquisition.startForeground();

          photonCounts = diff(acqData);

          % Here i put an arbitrary function to process 
 % 'photonCounts' which is rapid (< 10ms) and this computes the 
 % next command for the usb device 
  end

but the time for each iteration in the for loop is ~400ms longer than the acquisition itself. This wait time is SOLELY induced by the function to load the buffer and start the acquisition, not what i do with the data after. So when my acquistion is 10 ms i have a massive wait time for the next set of data

• *Continuous background acquistion*i don't have the time to put the code in for this method, in short:
• start a continuous background acq
• in the listener function for the available data; activate the usb device and start a timer (tic)
• in subsequent calls to the listener function I if the timer values is too short i throw away the data.

In this case i have very little synchronisation. I don't know if the data available arrived immediately or if it was sitting on a buffer. The timer has to be much longer to account for this and the fact that the usb device is activated at an unknown time during the susbsequent acquistion.

I'd prefer a solution with a software trigger. If not, is there a solution with a hardware trigger?

many thanks

Joe

Answer 1

[Walter Roberson]

• Would it make sense to log the data and count it later?
• pre-calculate the zeros() and store them in a variable instead of having the zeros() inside the loop
• You appear to have only one input channel. In that case,

mean(diff(acqData))

is going to be identical to

(acqData(end) - acqData(1)) / (length(acqData) - 1)

If your length() is going to be constant then to optimize you could just save the difference in the counter and do the division later.

[Joseph Gallagher]

Thank you for your response. I've edited the question as i think I was perhaps not clear:

• The data for each iteration is used to calucalate the new command for the usb device
• The variable for the Input data for the acquistion is declared before the loop, consistant with good coding practice
• You are correct but the calculation i put (e.g mean(diff(acqData))) is arbritrary, my fault for not being clear. The point i wanted to make is that this calcualtion is simple and fast, an order of magnitude faster than the delay between acquistions. However, the next command for the usb device is determined from this calculation and hence why i need the calculation at each iteration.