The highest data rates are obtained in stream mode. Stream is a continuous hardware timed input mode where a list of channels is scanned at a specified scan rate. The scan rate specifies the interval between the beginning of each scan. The samples within each scan are acquired as fast as possible given the specified resolution and extra settling time if any.
As samples are collected, they are placed in a 4 Mbit FIFO buffer on the UE9, until retrieved by the host. This 4 Mbit buffer can hold over 180,000 samples. Each data packet has various measures to ensure the integrity and completeness of the data received by the host.
The table below shows the maximum streaming data rates for the UE9 versus analog input resolution (assumes no extra settling time). These rates have been tested using Ethernet and various USB configurations, but some systems might require a USB high-high configuration or Ethernet to obtain these speeds. A “USB high-high” configuration means the UE9 is connected to a high-speed USB2 hub which is then connected to a high-speed USB2 host. Even though the UE9 is not a high-speed USB device, such a configuration does often provide improved performance. For all USB configurations, the worst case continuous stream rate seen in testing is 30 ksamples/s.
Stream data rates over USB and Ethernet can also be limited by other factors such as speed of the PC and quality of the network. General techniques for robust continuous streaming include increasing the priority of the stream process, and designing an application to automatically restart the stream if needed.
Table 3.2-1. Recommended Maximum Stream Data Rates
| Max Stream | ||
| Index | Resolution | Samples/s |
| 0-12 | 12 | 50000 |
| 13 | 13 | 16000 |
| 14 | 14 | 4000 |
| 15 | 15 | 1000 |
| 16 | 16 | 250 |
Sample => A reading from one channel.
Scan => One reading from all channels in the scan list.
SampleRate = NumChannels * ScanRate
For example, if streaming 5 channels, the max scan rate per the table above is 10 kscans/second (calculated from 50 ksamples/second divided by 5).
The time between each sample within each scan, without any extra settling time, is a little less than one over the max stream rate specified in the above table.
The values in Table 3.2-1 are generally worst-case conservative values. This is particularly true for the 12-bit value. The following table shows the actual measured limits for 12-bit streaming (Comm firmware V1.40, Control firmware V1.84), reflecting the fact that stream mode is more efficient with more channels. Note again that Table 3.2-2 shows sample rates not scan rates. Divide by the number of channels to determine the scan rate.
Table 3.2-2. Actual Maximum Stream Data Rates (Resolution=12)
| Max Stream | Max Stream | |
| Samples/s | Samples/s | |
| # Channels | USB high-high | Ethernet |
| 1 | 57000 | 57000 |
| 2 | 66000 | 66000 |
| 4 | 68000 | 74000 |
| 8 | 68000 | 78000 |
| 16 | 68000 | 80000 |
When the limits in Table 3.2-2 are exceeded, an error will occur. Probably scan overlap or buffer overflow. The UE9 will not return bad data, so these max data rates can be attempted, and either valid data will be collected or an error will occur.
For information about streaming under Windows using the LabJackUD driver, see Section 4.3.7.
In general, a low-level (not using the LabJackUD driver) Ethernet stream is done as follows:
The internal scan clock normally initiates each scan in stream mode. Optionally, an external pulse (falling edge) on the Counter1 FIO line can initiate each scan. In the low level StreamConfig function, this is enabled by setting bit 6 of byte 9. In the LabJackUD Windows driver this is controlled with the put_config special channel LJ_chSTREAM_EXTERNAL_TRIGGER.
One application of external triggering is for synchronized streaming from multiple devices. In such a case, set bit 7 of byte 9 on the main unit to enable scan pulse output. In the LabJackUD Windows driver this is controlled with the put_config special channel LJ_chSTREAM_CLOCK_OUTPUT. The main unit will then use the internal scan clock to initiate each scan, and output a pulse per scan on the Counter1 FIO line. The output is normally high, goes low at the beginning of each scan, and stays low for about 6 microseconds. All other synchronized units are then configured for an external scan trigger.
Something that could be useful is the ability to define a scan with multiple samples from the same channel. So for instance, a scan could be defined as channels 0/1/0/1/0/1 or 0/0/1/1 or whatever. This can provide a small burst of samples for each external trigger. The scan list can have up to 128 channels. When using the LabJackUD driver, duplicate channels in a scan only works if reading all channels simultaneously, as channel-by-channel stream reads are specified by channel number.
One thing to consider when using external triggering is the buffering that takes place within the UE9 and PC. If the external signal is fairly continuous, such as in synchronized streaming, this is not a problem, but if the external trigger is more of a one-time pulse the buffering must be considered to get the data when desired. For instance, each UE9 stream data packet contains 16 samples, so if there is only 1 sample per scan the UE9 will not send any data until it has accumulated 16 scans. Some applications might resolve this by defining each scan as 16 samples, even if it is just 16 samples of the same channel (see previous paragraph). Another buffering issue will come into play if the LabJackUD driver is used with USB communication, as the driver reads 4 packets at a time (64 samples).
Streaming always uses Counter1 internally, and thus Counter1 is not available for counting while streaming. Additionally, if clock output or external triggering is enabled, the normal Counter1 FIO line will be claimed, which is the next FIO available after all other enabled timers/counters. If no other timers/counters are enabled, FIO0 will be used for stream clock output or input.
When using external stream clock output or input, the timer/counter configuration should not be changed after starting the stream, as that could cause a glitch or could even cause the Counter1 FIO pin number to change.
Enabling clock output causes the FIO line to be set to output when the configuration command is executed, but the clock output will not actually begin until the stream is started. Enabling clock input causes the FIO line to be set to input when the configuration command is executed, but interrupts will not occur until the stream is started.
Note that external triggering causes 1 scan per trigger pulse. It is not used where a single pulse starts a continuous stream or a burst of multiple scans, as that type of trigger is better handled in software. In software, an arbitrarily complex set of trigger conditions can be watched for in continuous stream data, and when the trigger occurs the software can “keep” a specified number of scans, “keep” all scans while the trigger is true, or whatever other behavior is desired. In addition, the software can maintain a history buffer and “keep” a specified number of scans before the trigger (pre-trigger scans). Since stream data can consist of analog, digital, and timer/counter inputs, the trigger conditions can use any or all of those.
There are special channel numbers that allow digital inputs, timers, and Counter0, to be streamed in with analog input data. Note that you must always have at least 1 AIN channel in the stream list for the UE9.
Table 3.2.2-1. Special Stream Channels
| Channel# | |
| 193 | EIO_FIO |
| 194 | MIO_CIO |
| 200 | Timer0 |
| 201 | Timer1 |
| 202 | Timer2 |
| 203 | Timer3 |
| 204 | Timer4 |
| 205 | Timer5 |
| 210 | Counter0 |
| 224 | TC_Capture |
Channel number 193 returns the input states of 16 bits of digital I/O. FIO is the lower 8 bits and EIO is the upper 8 bits. This channel is generally used to acquire digital input data in stream mode. Channel 194 is the same thing for the CIO and MIO lines (Control firmware V1.69 or higher). The CIO are in the lower byte and the MIO are in the upper byte.
Channels 200-205 and 210 retrieve the least significant word (LSW, lower 2 bytes) of the specified timer/counter. At the same time that any one of these is sampled, the most significant word (MSW, upper 2 bytes) of that particular timer/counter is stored in an internal capture register (TC_Capture), so that the proper value can be sampled later in the scan. For any timer/counter where the MSW is wanted, channel number 224 must be sampled after that channel and before any other timer/counter channel. For example, a scan list of {200,224,201,224} would get the LSW of Timer0, the MSW of Timer0, the LSW of Timer1, and the MSW of Timer1. A scan list of {200,201,224} would get the LSW of Timer0, the LSW of Timer1, and the MSW of Timer1 (MSW of Timer0 is lost).
Adding these special channels to the stream scan list does not configure those inputs. If any of the FIO or EIO lines have been configured as outputs, they will need to be reconfigured as inputs to provide proper reads. The timers/counters must be configured before streaming using normal timer/counter configuration commands.
The timing for these special channels is the same as for normal analog channels. For instance, a stream of the scan list {0,1,200,224,201,224} counts as 6 channels, and the maximum scan rate is determined by taking the maximum sample rate at the specified resolution and dividing by 6.
It is not recommended to stream timers configured in mode 2 or 3 (32-bit period measurement). It is possible for the LSW to roll, but the MSW be captured before it is incremented. That means that only the LSW is reliable, and thus you might as well just use the 16-bit modes.
Mode 11, the upper 32 bits of the system timer, is not available for stream reads. Note that when streaming with the internal scan trigger, the timing is known anyway (elapsed time = scan rate * scan number) and it does not make sense to stream the system timer modes 10 or 11. With external triggering, there might be reasons to stream the available timer mode 10.
These special channel numbers can be used in command-response also. In command response they will return 32-bit values and thus the capture channel (224) is not used. This is useful in a program set up to do command-response reads of analog inputs only, such as LJLogUD.