Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

MATLAB DAQ Analog Output using USB-6251 (BNC) : startBackground(s) 240 ms latency!!!

Hello,

i ve got a latency issue with a USB-6251 (BNC): The device is connected via USB with a PC running a MATLAB script.

I have a problem with the command startBackground(s). When I execute this command it takes of about 240 ms until it is done, i.e. until the signal leaves the NIDAQ. I find the same latency by measuring the command itself within my script as follows:

latency=GetSecs() 

startBackground(s)

latency=GetSecs()-latency

 

My aim is to generate a sinusoidal voltage signal using a NI-USB 6251 (BNC) and the Data Acquisition Toolbox from MATLAB.

WHY is latency a problem for me? Because this signal has to be synchronized, i.e. in phase with another signal that i am processing in real time.

 

Part of my code:

 

daqreset;                                 % In case there was still an open session, reset the NiDAQ

s = daq.createSession('ni');              % open session

addAnalogOutputChannel(s,deviceID,[0 1], 'Voltage'); % Opens two output channels. Note: first channel is designated "0"

set(s, 'Rate', fs);

queueOutputData(s,[0 5;0 0]);      %For demonstration purpose i only take two samples and use them as a trigger signal which i am able to record using an      

                                                      %EEG Ampflifier + Recorder

prepare(s);

outp(addressOut,2);                     %Direct Trigger signal via parallel port (LTP) with a lag of 2-3 ms. I use this as a reference to determine the lag in my record file

t3=GetSecs();

startBackground(s);                   % 240 ms latency

t3=GetSecs()-t3;

outp(addressOut,0);

s.stop();

 

 

queueOutputData(s,[0 5;0 0]);

prepare(s);

outp(addressOut,2);                     %Direct Trigger signal via parallel port (LTP) with a lag of 2-3 ms. I use this as a reference to determine the lag in my record file

t3=GetSecs();

startBackground(s);                   % 35-55 ms latency

t3=GetSecs()-t3;

outp(addressOut,0);

s.stop();

 

 

The latencyoccurs once when initially start my script and is decreased for subsequent execution of startBackground(s). If I reset MATLAB workspace and DAQ connection, i.e. Control+C, clc, clear all and daqreset, the initial time lag of about 240 ms reappears. And again, subsequent executions are again processed faster ( time lag of about 35-55 ms). The short latencies are still problematic because they vary in a large range, such that i cannot cope with it e.g. by involving it in my calculations of my desired signal.

I added the command prepare(s) which is proposed in the online description of DAQ. This reduces the initial latency to about 160 ms but has no influence on subsequent executions of startBackground(s).

 

In summary, i found a non-systematic, wide varying either about 240 ms  or 35-55 ms time lag of the function startBackground(s), maybe it is a more general problem related to the Data Acquisition Toolbox. I tested it in both 32- and 64- bit version of MATLAB. In comparison a direct signal transmission using parallel port takes 2-3 ms until it is detected by my EEG recorder.

 

Have you got any idea?

0 Kudos
Message 1 of 3
(3,898 Views)

Hi,

 

just out of curiosity: Do you see the same latency when you run the session in the foreground?

Did you try to output a signal via MAX? Is there a problem?

 

right now I don't see any problems with your code.

 

Best,

 

Anna

Anna Vogl
Certified LabVIEW Developer
0 Kudos
Message 2 of 3
(3,862 Views)

Hello,

My guess is that it's coming from the compliation time and or initialisation of the session from MATLAB.

The first time you start a script/function it need to be compilated, so the starting delay will be higher at the first start than at the second and subsequent. 

By reseting MATLAB workspace, it will force him to recompile on next use of your script/function, so the starting delay will be higher.

For the synchronisation, i think I saw a few functions who would allow to synch different devices on same hardware of cpu clock.

You may check the use of the event.TimeStamps to generate your signal accordingly to the time you want it to follow, but this is just a wild guess.

0 Kudos
Message 3 of 3
(2,414 Views)