Streaming Vs C&r Timing With Two U6's

[cragjumper]

The Overall Question:

Is there a difference in how DAQFactory or the Labjack hardware assigns timestamps during streaming vs. command/response mode?  For example, if I were to record a single square wave input (20 Hz) on two different labjacks, one streaming data and the other using C&R with both labjacks collecting data at the same frequency (250 hz), would I not only see the same frequency square wave but have the square waves line up fairly close to each other (within 1/250 s) if I were to plot them using the data and respective timestamps provided by each labjack?  

 

The Context:

I'm currently streaming data from one Labjack U6 (let's call it LJ1_stream) and using command/response to collect data on another U6 (LJ2_CR).  The reason for this is that a) I need 6 timers, hence 2 different labjacks and one of the timers is to record a rotary quadrature encoder that rotates too quickly for streaming (due to the 1 edge/33 usec processing limitation).  Therefore, 4 rotary encoders using duty cycle timing (mode 4) are read by LJ1_stream and 2 quadrature rotary encoders using quadrature timing (mode 8) are read by LJ2_CR.  I've set the streaming to 250 hz and the C&R timing to 0.004 seconds (which I realize is faster than recommended for C&R and could be part of the issue as discussed further below) to also provide 250 hz measuring.  A common 20 hz square wave generated by a function generator is also being recorded on both labjacks, as well as an experiment start signal and a valve command signal, which both start low and go high when respective buttons are pushed.

 

Data is collected and exported (not logged) using expressions of the form Channelx_Data[Experiment_startTime,Experiment_endTime] where Experiment_startTime = systime() at the beginning of the experiment based on a button press and similarly for Experiment_endTime.

 

The data from LJ1_stream and LJ2_CR are exported as two separate export sets, with All data points (aligned) and zero align threshold.  Channel histories are 3000 for LJ1_stream and 4000 for LJ2_CR, since my experiments only run for ~2-3 seconds at a time.

 

LJ1_stream, in addition to the 8 channels being occupied by the four timers and the three common digital input signal channels, also has 5 analog signal channels and one other digital input, for a total of 17 streamed channels.  According to the 50000 max sample rate, 17 channels should correspond to a max scan rate of 2941, or a minimum of 0.00034 seconds between scans, so running at 250 hz should be slow enough.  LJ2_CR has the 4 channels for the 2 quadrature timers, and the three common digital inputs. 

 

The Detailed Problem:

There are experiments where the common signals are being recorded at very different timestamps from LJ1_stream compared to LJ2_CR.  For example, in one experiment, the experiment start signal went high at -0.193 seconds on LJ2_CR vs. at 0 for LJ1_stream (obviously using the LJ1_stream experiment start signal time as the basis for subtracting the DAQFactory time into useable time for both LJ1_stream and LJ2_CR).  There are other experiments where the effect is less pronounced, but still off by >2 timesteps (e.g. experiment start signal goes high at +0.009s on LJ2_CR but is recorded at 0 for LJ1_stream).

 

Some Thoughts:

1) Running LJ2_CR at 250 hz is too fast?  According to the labjack specifications (sec 3.1 and 3.2 of labjack U6 manual), one complete scan of 6 channels (2xquadrature timers and 2 digital inputs) in C&R mode would take about 8.5 ms, which corresponds to roughly a max record rate of 117 hz.  However, in examining the quadrature encoder data recorded at 250 hz using C&R on LJ2_CR, there doesn't appear to be any major issues other than some occasional data dropouts that occur.  The data still looks fairly smooth and uninterrupted.  Is it possible that the timer channels are recorded more accurately because they're interrupt driven rather than the digital signals (are they polled?)?

 

2) Is this an issue with using export rather than logging?  

 

Any other suggestions or thoughts would be greatly appreciated as to why timestamps aren't lining up, and I'm happy to clarify anything as I realize this is a very specific and detailed question that may not be as applicable to the general public.

 

 

[AzeoTech]

The only way to truly align data is to stream all data on one LabJack.  Here's the issue: it takes somewhere around 4ms to query the LabJack.  It doesn't matter if we are querying one channel or 5.  Its just the latency in the USB and Windows.  The problem is that its not necessarily consistent.  DAQFactory records the time stamp when the LabJack returns the reading, so there could be as much as 4ms of slop there.  For streaming, DAQFactory records the time when the stream start is acknowledged by the LabJack.  It then takes the actual stream rate returned in that call, and increments the time for each new data point in the stream.  That means that DAQFactory is actually only measuring time once in stream mode, and calculating from then on.  In poll mode, it records the time with each reading.  The accuracy of these measurements is basically whatever the latency between when the LabJack takes the reading, and when the response gets back to DAQFactory and the time is read.  Same goes for stream.  There is a latency between when the stream actually starts, and when DAQFactory gets the acknowledgement.

 

That all said, you really just need to test this yourself, and it sounds like you've done much of this by putting a single square wave on both LabJacks.  You should then be able to plot the square wave reading from both LabJacks and see how much variation there is.  

 

As for your final thoughts:

1) 250hz is usually too fast for Windows to do polling, but with multicore systems you can often get away with it as DAQFactory will run that query loop on one core, leaving the others for everything else.  The problem comes if you do too many things at high speed in different threads, because you run out of cores, and Windows needs some processor power to do basic stuff like move the mouse or draw the screen.  If you are reading timers or counters its important to remember that they sample at a much higher rate, so you won't see time related noise on the line.  For example, lets say you had a constant frequency going into a counter so that if you plot counts vs time you get a straight line.  Since DAQFactory connects the data points when graphing, the graph will look the same if you sample exactly every 0.1 seconds, or if you sampled at 0.1 seconds, then 0.2, then 0.09, etc.  The points would be scattered on the line, but the line would still look like a line assuming the actual count rate was much higher than your sample rate.

 

2) export and logging work the same except that export is done after the fact.  Make sure your align threshold is 0.  Also consider two other things: a) select the Include Time with All option, which gives a time stamp for each column instead of one time stamp for the whole row.  Then even if the data points are aligned, they'll show the different time stamp.   create a separate logging set for each LabJack, then combine the data after the fact in whatever data analysis tool you are using.

 

Also, the best is to simply keep the data in DAQFactory and look at it from there.  Set long histories, or use Persist on your channels.  Then your time stamps remain independent and precise to the microsecond.

[cragjumper]

Thank you so much for the thorough and quick reply - I suspected there had to be something with latency in getting the data and assigning a timestamp.  That clears up a lot.

I am a little confused as to your last comment, however, about looking at all the data in DAQFactory.  Is the data presented in each channel history table different than what gets exported?  With streaming channels, would the table history timestamps be identical for all channels, or would they differ slightly by the latency of scanning between channels, which then is eliminated when the data is logged/exported and placed all under one set of timestampts with zero align?  Also, looking at the data in DAQFactory doesn't change the main issue that streaming and C/R timestamps aren't aligned, correct?

 

Thanks again!!

[AzeoTech]

Its only different if the logging / export is modifying it.  For example, non-zero alignments or snapshot mode.  The data itself isn't modified, but some of the time information is lost in the alignment.

 

For streaming, the time stamp is the same for all channels being streamed.  DAQFactory knows nothing of the latencies involved in the scans, nor even what order the LabJack is scanning the channels.