Stream Scan Timing

Overview

When collecting data using stream mode, software may give the appearance that stream timing is not consistent. However, LabJack devices use a top priority hardware interrupt to start each scan at the exact specified interval every time.  Each scan will start on time, or an error will be thrown if it can't for any reason.  There are a few reasons software might give a different impression:

• Transfer Size and Variability in the Host Time per Read Iteration:  Software must wait for a chunk of data to transfer and the last scan you are waiting for might not be the last scan in a given transfer.
  
• Different Clocks:  All processors have slight physical differences in their clocks. Because of this, they slowly drift apart. For more information about this, see this section about system clock scan timing within the T-series datasheet.
  
• Actual Scan Rate: Due to the finite resolution of the stream clock, the scan rate cannot be guaranteed to exactly match the desired scan rate. However, the device will set the clock to the closest available setting and the actual stream scan rate can be read from the device. In a typical LJM application the actual scan rate is returned automatically when making an eStreamStart call.
  
• Slow Software Data Acquisition Loop:  If the data acquisition loop in software consistently processes data slower than the sampling rate, the observed throughput will be lower than the actual throughput from the device. Additionally, a backlog of samples will accumulate in the LJM or device buffer and this could eventually fill the buffer, causing device auto-recovery or skipped scans.

Example

Say you are reading 5 channels at 20,000 scans/second using a LabJack T7.  Then in your stream read loop you ask for 20,000 scans each iteration.  If you look at the host time between each iteration of the read loop you may see something like the following:

1.000
1.005
1.004
0.991
1.002
0.998
...

This would be totally normal.  The average time per iteration is 1.000 seconds.

If you tell the T7 to acquire a scan every 50 microseconds, it will acquire a scan exactly every 50 microseconds.  There is no notable variability, jitter or error.  It will acquire a scan exactly every 50 us, or if it can't it will throw an error.

The timing varies for when the data gets read by your program.  In the example above, some reads took a little longer than expected and others were a little quicker than expected, but the average is 1.000 seconds.

This software timing jitter happens due to operating system scheduling.

If iterations are always slow

If we again assume an expected iteration time of 1.000 seconds, the following would indicate a problem:

1.050
1.051
1.050
1.050
1.052
1.053
...

In this case all the reads are taking too long.  The average is 1.051 seconds per iteration.  That means your program is not reading data as fast as it is collected. 

Skipped Scans

For T-series devices, the eStreamRead function returns two parameters that you should watch: DeviceScanBacklog and LJMScanBacklog.  It is normal for these to report small non-zero values, but they should not be continuously growing over time. If they are continuously growing over time, stream will eventually begin to return skipped scans. To alleviate this situation see these strategies to prevent skipped scans.