A-1 Data Rates [T-Series Datasheet]

Communication Modes

Communication between the host computer and a T-series device occurs using one of two modes:

1. Command-response

Command-response mode is appropriate for most applications. In command-response mode, the host sends a command data packet, to which the T-series device sends a response data packet.

2. Stream

Stream mode is when the device collects periodic sampling events automatically. Collected data is stored in the device's memory until it retrieved by the host application. The LJM library stream functions simplify data collection from T-series devices. Not all functionality is supported in stream mode.

For more information about command-response and stream, see 3.0 Communication.

Note: These specs are generated using a LabVIEW program that reads data from a device in a simple while(1) loop.  Additionally, we used a PC running Windows with a fairly average Intel CPU.  We have found the performance of LabVIEW to be very similar to C, C++, and other compiled languages and have therefore chosen LabVIEW to collect these data rates.  If an application requires precise timing of CR packets we suggest doing additional research and replicating these results for the system being used.

Figure A1.1depicts the two operating modes.

The use of a particular mode will depend on functionality and the hardware response time required by the end application.

Command-Response Data Rates

All communication performed with T-series devices is accomplished using the Modbus TCP protocol, thus allowing direct communication with the device via low-level TCP commands. As an alternative, the LJM library may be used as a higher level communications layer for added convenience and minimal additional overhead. Tables A.1.1 to A.1.3 list expected communication overhead times associated with Modbus TCP and LJM Library communication options.  Tables A.1.1 and A.1.2 times are the same on the T4/T7, and were measured on a T7. Communication times for the T8 can be found in Table A.1.3.

Table A.1.1. Typical communication overhead using direct Modbus TCP with the T4/T7.

Table A.1.2. Typical communication overhead using the LJM Library with the T4/T7.

Table A.1.3. Typical communication overhead using the LJM Library with the T8.

The times shown in tables A.1.2 and A.1.3 were measured using a LabVIEW program running on Windows where all read and write operations are conducted with a single LJM_eNames() call.  The LJM_eNames() functions is used to minimize the number of Modbus packets sent from the host (one packet per command/response set).  The test program executes one of the listed tasks within a loop for a specified number of iterations, over a 1-10 second period.  The overall execution time is divided by the total number of iterations, providing the average time per iteration for each task.  The execution time includes LabVIEW overhead, LJM library overhead, Windows overhead, communication time (USB/Ethernet/WiFi), and device processing time.

A "USB high-high" configuration means the T-series device is connected to a high-speed USB2 hub which is then connected to a high-speed USB2 host. Even though the Tx is not a high-speed USB device, such a configuration does often provide improved performance. Typical examples of "USB other" would be a Tx connected to an old full-speed hub (hard to find) or more likely the Tx is connected directly to the USB host (your PC) even if the host supports high-speed.

For more information, see this app note: High Speed Command-Response Sample Rates

Preemptive Operating Systems and Thread Priority

It is important to understand that Linux, Mac OS X, and Windows are generally "best-effort" operating systems and not "real-time", meaning that the listed CR speeds can vary based on each individual computer, the hardware inside of it, its currently enabled peripherals, current network traffic, strength of signal, design of the application software, other running software, and many more variables [1].

USB and Ethernet

These times are quite predictable.  Software issues mentioned above are important—but, in terms of hardware, the times will be consistent.  The device communication does not consume a major portion of total USB or Ethernet bandwidth.  Therefore, the overhead times listed are typically maintained even with substantial activity on the bus.

WiFi - T7-Pro

WiFi latency tends to vary more than USB or Ethernet latency.  With a solid connection, most WiFi packets have an overhead of 3 to 8 ms, but many will take longer.  For example, a test was done in a typical office environment of 1000 iterations that produced an average time of 7.0 ms.  The results were:

• 92% of the packets took 3-8 ms,

• 99% took < 30 ms,

• and 3 packets took 300 ms.

All WiFi tests were done with an RSSI between -40 (very strong) and -70 (good).  An RSSI less than -75 generally reflects a weak connection, causing a greater number of packets retries.  An RSSI greater than -35 reflects a very strong connection, typically within a few feet of the access point. This also results in a greater numbers of retries due to saturation of the RF signal. 

ADC Conversions

Analog to digital conversions (ADC) will increase the command-response time depending on the number of channels, the input gain (T7), and the resolution index being used.  The tables linked in the sections below list conversion times for various settings when reading a single analog input channel.  The total command-response time (CRT) when reading analog inputs is equal to the overhead time from tables A.1.1, A.1.2 and A.1.3 added to the conversion times for the requested channels:

CRT (milliseconds) = overhead + (#AINs * AIN Sample Time)

T4 AIN Sample Time

See the tables in Section A-3-1-2: T4 Noise and Resolution.

T7 AIN Sample Time

See the tables in Section A-3-2-2: T7 Noise and Resolution.

T8 AIN Sample Time

See the tables in Section A-3-3-2: T8 Noise and Resolution.

Streaming Data Rates

The fastest data rates on T-series devices occur when operating in stream mode.  Much of the command-response overhead is eliminated in stream mode because the device is responsible for initiating IO operations.  The device collects scans in its stream buffer, then the host application retrieves multiple scans at once.  The end result is a continuous data stream, sampled at regular intervals, collected with a minimum number of communication packets [2.].

There is an important distinction between scans and samples. Definitions are as follows:

• Address: Also called a channel.  An address usually returns the value of 1 input connection.

• Sample: A reading from one address.

• Scan: One reading from every address in the scan list.

• Scan list: The list of one or more addresses in a scan.

The scan rate is the rate at which scans are collected. It is a fraction of the sample rate, where the fraction is the inverse of the number of channels being read in a single scan.  The scan rate is defined as:

ScanRate = SampleRate / NumAddresses

The sample rate and scan rate are equal when the NumAddresses is 1.

Interchannel Delay - T4/T7

Interchannel delay is the time between each sample within a scan.  For example, say 3 channels are streamed at 1000 scans/second with ResolutionIndex=1 and Range=10.  That is a sample rate of 3000 samples/second, so from the table above the interchannel delay is 15 μs.  The stream interrupt will fire every 1000 μs, at which time it takes about 5 μs until the 1st channel is sampled, then 15 μs later the 2nd channel is sampled, then 15 μs later the 3rd channel is sampled, and then about 965 μs later the next scan starts. 

What if in the above example we wanted the 8 μs delay rather than 15 μs?  The sample rate must be greater than 60 ksamples/second for that, so the solution is increase sample rate by scanning more channels (channels can be repeated in the scan list) or scanning faster and discarding the extra data.

The interchannel delay is a fixed time with little jitter, so the known time can be accounted for in user software to adjust phase if those microseconds are important.  As an alternative to using the table above, the user can measure interchannel delay on their device by using a scope to look at the SPC timing output described in the Stream Mode section.

Notes

1. Various software issues need consideration when implementing a feedback loop that executes at the desired time interval.  Some considerations are: thread priority, logging to file, updating the screen, and other programs running on the machine.

1. The number of packets used to retrieve stream data depends on the number of data points allowed to accumulate in the stream buffer.

1. Setting the resolution index to 0 (default) in stream mode is equivalent to a resolution equal to 1.  The default resolution index in stream mode behaves different than command-response mode.

T4 Stream Rates

The T4 has a typical maximum sample rate of 50 ksamples/second.  This maximum is reflected in the first row of data in the following table (highlighted).  The scan rates reported are the maximum sample rates divided by the number of channels in the scan list (within ~10%).

The scan rates in the following tables are continuous over USB or Ethernet.

The scan rate is defined as (see "Streaming Data Rates" above):

ScanRate = SampleRate / NumAddresses

The minimum scan rate is 0.0157 Hz.

Table A.1.5. T4 Stream: Scan rates for different values of resolution index.  Applies to USB and Ethernet.  Applies to all streamable addresses including low-voltage and high-voltage analog inputs.

* Default stream Resolution index for the T4.

Table A.1.6. T4 Stream: Typical noise and interchannel delay values depending on resolution index.

* Default stream Resolution index for the T4.

** 40 µs for sample rate <= 20k.  13 µs for sample rate > 20k.

T7 Stream Rates

• Ethernet can usually maintain just under 120 ksamples/second.

• USB generally maxes out right around 100 ksamples/second.

• When using WiFi, the device can acquire data at the fastest rates, but transfer of data to the host is limited to about 1 ksamples/second, so the fastest stream rates cannot be maintained continuously. In this case, stream-burst can be used rather than continuous stream, where each stream is limited to a specified number of scans that fits in the device's stream buffer.  For high-speed wireless streaming, use the Ethernet connection with an external Ethernet-WiFi bridge.

The T7 has a typical maximum sample rate of 100 ksamples/second.  This maximum sample rate is achievable when a stream is configured with RANGE = ±10V and RESOLUTION_INDEX = 0 or 1 [3.].  This maximum is reflected in the first row of data in the following table (highlighted).  The scan rates reported are the maximum sample rates divided by the number of channels in the scan list (within ~10%).

The scan rates in the following tables are continuous over USB or Ethernet.

The scan rate is defined as (see "Streaming Data Rates" above):

ScanRate = SampleRate / NumAddresses

The minimum scan rate is 0.0157 Hz.

Table A.1.7. T7 Stream: Scan rates over various gain, resolution index, channel count combinations.  Applies to USB and Ethernet.

N.S. indicates settings not supported in stream mode.

* When streaming one channel, the maximum sample rate is not affected by range because the signal chain does not need to settle.

** The default stream resolution index for the T7.

The maximum scan rate decreases at higher resolution index and range settings simply because analog conversions take longer to complete. Single-channel stream is a slight exception—its maximum scan rate decreases at higher resolution indices but not according to range settings because it does not need to settle.

Table A.1.8. T7 Stream: Typical noise and interchannel delay values depending on range and resolution index.

N.S. (Not Supported) indicates settings not supported in stream mode.
* The default stream resolution index for the T7.
** 15 µs for sample rate <= 60k.  8 µs for sample rate > 60k.

T8 Stream Rates

The T8 has a maximum scan rate of 40 ksamples/second. Unlike other T-series devices, the scan rate does not depend on how many addresses are sampled per scan since all analog inputs are sampled simultaneously.

The scan rates in the following table are continuous over USB or Ethernet. For reliable streaming, refer to the T8's Maximum Stream Speed section in the Stream Mode documentation.

Table A.1.9. T8 Stream: Scan rates for different values of resolution index. Applies to USB and Ethernet, and all streamable addresses.

The maximum scan rate decreases at higher resolution index simply because analog conversions take longer to complete.

Typical noise values depend on range and resolution index. Command-response noise is the same as stream noise. The T8 does not have interchannel delay. Refer to Section A-3-3-2: T8 Noise and Resolution for details.