« Close

Datasheets and User Guides

App Notes

Software & Driver


A-1 Data Rates

Communication Modes

Communications between the host computer and the T7 occur using one of two modes:

1. Command-Response
2. Stream

Command-response mode will apply to most applications and consists of command data packet sent from the host followed by a response data packet from the T7. Stream mode relies on the T7 to carry out periodic sampling events automatically. Collected data is stored in the T7's memory until it retrieved by the host application, or if using the LJM library it moves data in a background thread from the T7 memory to computer memory. Figure A1.1.1 depicts the two operating modes for the T7.

igure A1.1.  T7 communication modes.

The use of a particular mode will depend on desired T7 functionality and the hardware response time required by the end application. Not all functionality is supported in stream mode. Please refer to the Stream Mode section of the user's manual, detailing stream mode operations.


Command Response Data Rates

All communication performed with the T7 is accomplished using the Modbus TCP protocol, thus allowing direct communication with the T7 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 and A.1.2 list expected communication overhead times associated with Modbus TCP and LJM Library communication options, performing various tasks on the T7 (LJM: 1.0706, Firmware: 1.046). 

Table A.1.1. Typical communication overhead using direct Modbus TCP.
  USB High-High USB Other Ethernet WiFi
[ms] [ms] [ms] [ms]
No I/O - Overhead 0.6 2.1 1.0 6.5
Read All DI 0.7 2.2 1.1 6.6
Write All DO 0.7 2.2 1.1 6.6
Write Both DACs 0.7 2.2 1.1 6.6

Table A.1.2.  Typical communication overhead using LJM library.

  USB High-High USB Other Ethernet WiFi
[ms] [ms] [ms] [ms]
No I/O - Overhead 0.6 2.2 1.1 6.7
Read All DI 0.7 2.3 1.2 6.8
Write All DO 0.7 2.3 1.2 6.8
Write Both DACs 0.7 2.3 1.2 6.8

Testing Procedure and Definitions:

The times shown in table A.1.2 were measured using a LabVIEW program running on Windows were 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 T7 processing time.

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

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].

Ethernet & USB:

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


The WiFi times tend to vary much more than USB or Ethernet.  With a solid connection most WiFi packets have an overhead of 3-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.  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 and the number of packets that experience retries goes up quickly.  An RSSI greater than -35 reflects a very strong connection, typically within a few feet of the access point, and also results in increasing 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, input gain, and resolution index being used.  Table A.1.3 lists the conversion times for the T7 at various gains and resolution index settings, 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 and A.1.2 added to the conversion times from Table A.1.3 (per channel being read) .  Please review tables A.1.1-A.1.3 carefully, as the listed times will determine the maximum sampling rate achievable when reading analog inputs in command response mode.

CRT (milliseconds) = overhead + (#AINs * AIN Sample Time)
Table A.1.3.  Typical milliseconds per sample.
Resolution Effective Effective AIN Sample
Index Resolution Resolution Time
  [bits] [µV] [ms/sample]
Gain/Range: 1/±10V   
1 16.0 316 0.04
2 16.5 223 0.04
3 17.0 158 0.1
4 17.5 112 0.1
5 17.9 84.6 0.2
6 18.3 64.1 0.3
7 18.8 45.3 0.6
8 19.1 36.8 1.1
9 19.6 26.0 3.5
10 20.5 14.0 13.4
11 21.3 8.02 66.2
12 21.4 7.48 159
1 15.4 47.9 0.2
2 16.0 31.6 0.2
3 16.5 22.3 0.6
4 16.9 16.9 0.6
5 17.4 12.0 1.2
6 17.9 8.46 2.3
7 18.3 6.41 2.6
8 18.7 4.86 3.1
9 19.5 2.79 3.5
10 20.5 1.40 13.4
11 21.4 0.748 66.2
12 21.5 0.698 159
Gain/Range: 100/±0.1V   
1 13.3 20.5 1.0
2 14.2 11.0 2.0
3 14.7 7.78 5.1
4 15.2 5.50 5.1
5 15.7 3.89 5.2
6 16.3 2.57 10.3
7 16.7 1.94 10.6
8 17.2 1.37 11.1
9 18.3 0.641 3.5
10 19.1 0.368 13.4
11 19.6 0.260 66.2
12 19.7 0.243 159
Gain/Range: 1000/±0.01V   
1 10.9 10.8 5.0
2 12.3 4.10 10.0
3 12.7 3.11 10.1
4 13.3 2.05 10.1
5 13.8 1.45 10.2
6 14.4 0.96 10.3
7 14.7 0.778 10.6
8 15.0 0.632 11.1
9 15.4 0.479 3.5
10 16.1 0.295 13.4
11 16.4 0.239 66.2
12 16.4 0.239 159

Streaming Data Rates

The fastest data rates on the T7 occur when operating in stream mode.  Much of the command response overhead is eliminated in stream mode because the T7 is responsible for initiating IO operations.  Collected data is stored in the T7's stream buffer it is retrieved by the host application.  The end result is a continuous data stream, sampled at regular intervals, collected with a minimum number of command response data sets [2.].  Table A.1.4 and A.1.5 provide typical stream-related performance results. The tabulated data is useful for determining what types of signals can be analyzed using a T7.  The T7 is capable of streaming analog data at regular discrete intervals.  As a result, various discrete time signal analysis tools can be utilized to interpret data.

The scan rates shown in table A.1.4 are continuous over USB or Ethernet. Ethernet can usually maintain just under 120 ksamples/second whereas 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.

Table A.1.4. Stream scan rates for stream mode over various gain, resolution index, channel count combinations.  Applies to USB & Ethernet.

    Gain : Range   Maximum Scan Rate    Maximum Sample Rate
1 Channel 2 Channels 4 Channels 8 Channels >1 Channel
[Hz] [Hz] [Hz] [Hz] [Hz]
Resolution Index = 1    1 : ±10V 100k 50k 25k 12.5k 100k
10 : ±1V 100k 4.1k 1.4k 585 8.2k
100 : ±0.1V 100k 850 315 N.S. 1.7k
1000 : ±0.01V N.S. N.S. N.S. N.S. N.S.
Resolution Index = 2    1 : ±10V 48.0k 19.8k 9.0k 4.0k 39.6k
10 : ±1V 48.0k 3.6k 1.3k 550 7.2k
100 : ±0.1V 48.0k 400 N.S. N.S. 800
1000 : ±0.01V N.S. N.S. N.S. N.S. N.S.
Resolution Index = 3    1 : ±10V 22.0k 9.9k 4.5k 2.4k 19.8k
10 : ±1V 22.0k 1.4k 500 225 2.8k
100 : ±0.1V N.S. N.S. N.S. N.S. N.S.
1000 : ±0.01V N.S. N.S. N.S. N.S. N.S.
Resolution Index = 4    1 : ±10V 11.0k 4.9k 2.2k 1.3k 9.8k
10 : ±1V 11.0k 1.3k 45 N.S. 2.6k
100 : ±0.1V N.S. N.S. N.S. N.S. N.S.
1000 : ±0.01V N.S. N.S. N.S. N.S. N.S.
Resolution Index = 5    1 : ±10V 5.5k 2.2k 990 630 4.4k
10 : ±1V 5.5k 630 23 N.S. 1.3k
100 : ±0.1V N.S. N.S. N.S. N.S. N.S.
1000 : ±0.01V N.S. N.S. N.S. N.S. N.S.
Resolution Index = 6    1 : ±10V 2.5k 1.3k 630 315 2.6k
10 : ±1V 2.5k 320 N.S. N.S. 640
100 : ±0.1V N.S. N.S. N.S. N.S. N.S.
1000 : ±0.01V N.S. N.S. N.S. N.S. N.S.
Resolution Index = 7    1 : ±10V 1.2k 650 315 N.S. 1.3k
10 : ±1V 1.2k 220 N.S. N.S. 440
100 : ±0.1V N.S. N.S. N.S. N.S. N.S.
1000 : ±0.01V N.S. N.S. N.S. N.S. N.S.
Resolution Index = 8    1 : ±10V 600 315 N.S. N.S. 630
10 : ±1V 600 200 N.S. N.S. 400
100 : ±0.1V N.S. N.S. N.S. N.S. N.S.
1000 : ±0.01V N.S. N.S. N.S. N.S. N.S.

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

A distinction between the terms scan and sample must be drawn to better interpret the data from Table A.1.4.  A sample and a scan represent two separate parameters which make up a T7 data stream.  The definitions for each parameter are as follows:

Address - You can usually also call this a "channel".  An address usually returns the value of 1 channel.
Sample - A reading from one address.
Scan -  One reading from a list of addresses (scan list).

The scan rate, by definition, 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 T7 has a maximum sample rate of 100 ksamples/second.  The stated maximum sample rate is achievable when a stream is configured with Range = +/-10V and ResolutionIndex = 0 or 1 [3.].  This maximum is reflected in the first row of data in table A.1.4 (highlighted).  The reported scan rate is simply the maximum sample rate divided by the number of channels in the scan list (within ~10%).  Note that the sample rate and scan rate for a single-channel stream are equal since the NumAddresses = 1.

The maximum scan rate will decrease at higher resolution index and range settings simply because analog conversions take longer to complete.  Table A.1.5 illustrates how analog conversion times increase at different resolution index and range settings.

Table A.1.5. Stream performance characteristics for single-channel stream over various gain and resolution index combinations.
Resolution Peak-to-Peak Interchannel
Index Noise Delay
  [16-bit counts] [µs]
Gain/Range: 1/±10V
1 ±3.0 15/8*
2 ±2.0 25
3 ±1.5 45
4 ±1.0 90
5 ±1.0 170
6 ±0.5 335
7 ±0.5 670
8 ±0.5 1,335
Gain/Range: 10/±1V
1 ±4.5 210
2 ±3.0 220
3 ±2.0 545
4 ±1.5 585
5 ±1.0 1,200
6 ±0.5 2,415
7 ±0.5 2,750
8 ±0.5 3,415
Gain/Range: 100/±0.1V
1 ±12.0 1,040
2 ±9.0 2,105
3 N.S. N.S.
4 N.S. N.S.
5 N.S. N.S.
6 N.S. N.S.
7 N.S. N.S.
8 N.S. N.S.
Gain/Range: 1000/±0.01V
1 N.S. N.S.
2 N.S. N.S.
3 N.S. N.S.
4 N.S. N.S.
5 N.S. N.S.
6 N.S. N.S.
7 N.S. N.S.
8 N.S. N.S.

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

*8 µs is used when streaming faster than 60 kSPS.

Interchannel Delay is the time between each sample within a scan.  This fixed time can be used in user software to adjust phase if those microseconds are important.  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.


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.

2.  The number of command response data sets used to retrieve stream data from the T7 depends on the number of data points allowed to accumulate in the in the T7's stream buffer

3.  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 behaves different than command response mode.  In command response mode, the default resolution index (0) is equivalent to resolution index = 8 and resolution index = 9 for the T7 and T7 Pro, respectively.


Do you have 14 AI cases for this table?

Added a new section above called "Times for different # of AIN (besides 1 or 8)".

I've got the T7-pro, and I had a look and it's using the AD7190 (http://www.analog.com/en/products/analog-to-digital-converters/ad-conver...), which states that it's a 4.8kHz ADC. How do you get the "up to 100,000ksps" that you give with that ADC?

The T7-Pro has 2 A/D converters as shown in Figure 4-2.  The hi-speed SAR converter is used for ResIndex=1-8, and the hi-res sigma-delta converter is used for ResIndex=9-12.  All ResIndex values are valid in command-response mode, as shown above, but in stream mode only the SAR converter is supported.  For more details about the hi-res converter, see post #15 of forum topic 6707.

martin beck mechatronic's picture


Is there any chance to increase the AIN sampling rates?
Especially for a gain 100 (+-0.1V range), Table A1.4. shows a really dramatic drop of performance when 2 or more channels are acquired in stream mode, even if a resolutionindex of 1 is used.
Even if the noise-rduction is done in the processor of the T7, instead of in the ADC, the dramatic breakdown in performance is not really understandable to me.

In case that an increase of sampling-rates for multichannel acquisition of signals in a gain 100 (+-0.1V range) is not feasible, I will need external amplifiers, in order to operate the T7 in gain 1 (+-10V) mode, or is there an other option that I can currently not think of?


Best regards,

LabJack Support's picture

The reason is settling time when using auto-settling.  We generally set auto-settling so the signal settles to within the noise level, and at higher gain the noise level is smaller so it takes longer to settle to that noise level … much longer.  That is why a single-channel stream can go full speed at any gain, but a multi-channel stream slows down.

One thing you could do is manually control settling to use values less than auto would use, and evaluate how low of settling you can use for your particular application.  What is the voltage range of all the different signals you will be streaming?

martin beck mechatronic's picture

Your answer helps a lot, this absolutely makes sense!

I am trying (believe it or not) to acquire 8 temperatures from Type K thermocouples with 1kHz per thermocouple. This sounds stupid, but I have pairs of superfine thermocouples (20µm and 40µm dia) and try to compute (=extrapolate) the instantaneous temperatures of a gas surrounding these pairs of thermocouples by evaluating the two signals of the two thermocouples within a pair. Preliminary results (with one pair only, sampled at 800Hz due to limitations of LabJack) look promising.

WRT voltage ranges, one TC-pair can be surrounded with gas having room-temperature (TC-voltages around 1mV), while the next pair may be surrounded by gas with 850°C (TC-voltages around 35mV). Do you think that manual setting of settling-time might help for my application? Or would you rather recommend amplification of the TC signals before feeding them to LabJack?

Best regards,


LabJack Support's picture

Since you have such a small swing, I think it is worth experimenting with manual control of setting time.  You can test using LJStreamUD.  Leave the first row set to channel 0, and set the 2nd through 10th rows to channel 1.  Jumper DAC0 (set to 0.04V) to AIN0, and jumper GND to AIN1.  Set NumChannels = 10.  Use a low scan rate such as 10 Hz so you can try a good range of settling times.  Stream with different settling times, and look at 2 things:  1)  How is the value changing from the 2nd row to the 10th row, and 2) If little change how does the value compare to the value with a very long settling time.  To get into more details email [email protected].

martin beck mechatronic's picture


Thanks for your feedback. Unfortunately, LJStreamUD is not compatible with the T7 and LJStreamM does not support setting of settling times for streaming. However, I got the gist of your proposal and will conduct some experiments along those lines.

Best regards,


LabJack Support's picture

Right, my mistake.  You need to use LJStreamM, and indeed LJStreamM does not have a control to write STREAM_SETTLING_US.  You could go back and forth using the Kipling Register Matrix to set STREAM_SETTLING_US then running LJStreamM, but if you are programming in some language then using the stream example there is probably the easiest.

jsimeroth's picture

This seems to be talking about data inputs. I am curious what the maximum rate that I can send digital output signals is. I have looked but can't seem to easily find an explicit answer. The application is for Step and Direction control of a stepper motor. 

Any help would be greatly appreciated.

LabJack Support's picture

Start by looking at the Waveform Generation App Note and post a comment there if you need more detail on anything:


Jerome's picture

Looking at Table A.1.4, why are the multi-channel tests affected by the gain level, while the single channel is not? Is this something to do with the channel switching, or is it a typo and the 1 channel rates are closer to the values in the right column?

LabJack Support's picture

The main slowdown with multiple channels at high gain is that much more settling time is required to allow the system to change from the previous channel's voltage to the new channel's voltage.  To meet specs at a gain of x1000, for example, the system must settle to within microvolts of the final value.  So with a 1-channel stream you can go full speed at any gain, but with a multiple channel stream speeds decrease as gain increases.

Jerome's picture

Thanks for clearing that up. I should have kept reading about the inter-channel delay.