Delay of DAQ device in real-time

Hi, everyone!

I'm using NI's DAQ USB device for measuring the signal of loadcell.

I want to measure the exact force point, but MATLAB plot always shows me a graph with some delays.

I use callback function and my code commands if the value goes to under 4.8, stop plotting immediately.

However, the MATLAB plot reads values under 4.8.

My MATLAB code is here, and the plot will help you understand my problem.

Thank you!

global data_stack time_stack d
d = daq("ni");
d.Rate = 100;

ch = addinput(d,"Dev1","ai1","Voltage");
ch.TerminalConfig = "SingleEnded";
ch.Range = [-5 5];  

d.ScansAvailableFcn = @plotSample;  
start(d,"Continuous");

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
function plotSample(obj, evt)
global time_stack data_stack d
[data_buff,timeStamp_buff] = read(obj,obj.ScansAvailableFcnCount,"OutputFormat","Matrix");
if isempty(data_stack)
    time_stack = timeStamp_buff;
    data_stack = data_buff;
else
    time_stack = [time_stack ; timeStamp_buff];
    data_stack = [data_stack ; data_buff];
end

if data_stack(end) < 4.8
    stop(d)
end

plot(time_stack, data_stack);
end

Answer 1

[Walter Roberson]

You are reading a buffer full of samples, which might be more than one sample at a time. You issue the stop if the endpoint is below the threshold, but still plot all of the samples in the buffer.

USB is a controller / device configuration.

For USB 3.0 and earlier, in every case, the controller repeats cycles over and over in which the controller

1. asks whether there are any new devices on the bus, listens for response, and if it gets some, asks each new device to list its capabilities

2. For each device the controller knows about, it asks the device the device individually whether it has anything it wants to send. The device sends back either a No or a description of what is to be transferred rather than the data itself, except that if the data is really small it can bundle it in the response to the controller

3. Each kind of data to transfer has a priority, and particular bandwidths might have been negotiated. The controller prioritizes the transfer requests and if the total requests would exceed the amount that can be transferred in one cycle, drops the less important ones from the queue. Then it steps through the queue telling each device in turn to transfer the specific data.

4. Because of the way that priority allocations are made, "real-time" data is never thrown away on a cycle: at the time that a device asks to set up a real-time transfer, the controller will deny permission to set up the transfer if there is potential for the bandwidth to be oversubscribed (if all the devices simultaneously asked to talk when they had real-time reservations. And any virtual connection that is not configured as real-time, by definition pending packets can be deferred for later cycles where not every device wants to talk at full reserved capacity. The controller does not have to specifically tell the device that it is rejecting transfer of a pending deferrible packet: it simply never asks to transfer it, and the device still has it in stock when the controller polls for work the next cycle.

5. The controller has a fixed maximum poll rate (that can depend on the mix of protocols supported by the attached devices.)

Put this all together and there are some important implications:

• devices do not send data as soon as they have it available. They do not send it until the next time the controller asks what they have to send and then the controller gets around to telling them to send it.
• data to be sent is not divided into separate transmissions with boundaries each time the device software has some data ready. Instead, as data becomes available, the device queues the data in a buffer, and at the time the controller asks for work, the device reports back how big the buffer is, and the controller tells the device how much to send. The data in the buffers is converted into maximum-length packets for transmission. Thus if reading A is available now, yes it gets buffered. But if reading B also becomes available before the controller asks for work, then A and B will be transferred, including potentially part of a reading if that is what worked out for the hardware buffer or bandwidth availability.
• so if the time between controller cycles exceeds the interval between samples then multiple samples will end up buffered together.
• for at least some purposes, the limit of controller polling is 1000 events per second.

[Walter Roberson]

And of course, it takes time for MATLAB to tear down the connection once the stop() is done -- time during which more data is going to accumulate in the device buffers.

In short: Yes, you should expect these kinds of issues to occur.

[Walter Roberson]

Now, National Instruments makes a couple of very low end USB analog to digital cards, and also makes more expensive USB A/D cards.

I have not been able to verify, but in the past I have gotten the impression that their very low end NI USB A/D cards use the "Serial over USB" protocol to send data. That protocol is not considered a real-time protocol. The control methods for that protocol require some command-and-response, and with the controller cycle being fixed, you just cannot do real-time control over starting and stopping the data flow.

Devices such as arduino that use "serial over USB"... it is common that the highest effective rate you can get for sample-by-sample transmission, turns out to be on the order of 40 samples/second. You can get higher throughputs if you are willing to bundle more samples per packet

If I understand correctly, the higher end NI USB A/D cards know how to reserve bandwidth to send data to the host, which allows them to deliver high bandwidths with less latency and more consistency. But, the control channel for those kinds of devices is implemented as a second virtual device on the same hardware... one that effectively uses the serial command protocols (but often can avoid a bit of the buffering that is common with "Serial Over USB"). So no instant stops there either... but when well designed can be a comparatively low-latency stop compared to when pure serial-over-USB is used.

All in all... getting some packets after you detect the stop conditions is almost certain with USB devices. The amount of delay can depend on Quality of Impementation.