« Close

Datasheets and User Guides

App Notes

Software & Driver

 

A-1 Data Rates

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. Please refer to the Stream Mode section of the user's manual for more details.

Figure A1.1.1 depicts the two operating modes.

Figure A1.1.  Communication 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 and A.1.2 list expected communication overhead times associated with Modbus TCP and LJM Library communication options.  These times are similar for all T-series devices, but the following were measured on a 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

The times shown in table A.1.2 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 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 often 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].

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:

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, and the resolution index being used.  Table A.1.3 lists the conversion times for the T7 at various gains and resolution index 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 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 C-R milliseconds per sample, T4.
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
Gain/Range:10/±1V   
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

 

Table A.1.4.  Typical C-R milliseconds per sample, T7.
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
Gain/Range:10/±1V   
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 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 then retrieves multiple scans at once.  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.
  • 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 and 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 120 1.7k
1000 : ±0.01V 100k N.S. N.S. N.S. N.S.
Resolution Index = 2    1 : ±10V 48k 19.8k 9.0k 4.0k 39.6k
10 : ±1V 48k 3.6k 1.3k 550 7.2k
100 : ±0.1V 48k 400 N.S. N.S. 800
1000 : ±0.01V 48k N.S. N.S. N.S. N.S.
Resolution Index = 3    1 : ±10V 22k 9.9k 4.5k 2.4k 19.8k
10 : ±1V 22k 1.4k 500 225 2.8k
100 : ±0.1V 22k N.S. N.S. N.S. N.S.
1000 : ±0.01V 22k N.S. N.S. N.S. N.S.
Resolution Index = 4    1 : ±10V 11k 4.9k 2.2k 1.3k 9.8k
10 : ±1V 11k 1.3k 45 N.S. 2.6k
100 : ±0.1V 11k N.S. N.S. N.S. N.S.
1000 : ±0.01V 11k N.S. N.S. N.S. N.S.
Resolution Index = 5    1 : ±10V 5500 2.2k 990 630 4.4k
10 : ±1V 5500 630 23 N.S. 1.3k
100 : ±0.1V 5500 N.S. N.S. N.S. N.S.
1000 : ±0.01V 5500 N.S. N.S. N.S. N.S.
Resolution Index = 6    1 : ±10V 2500 1.3k 630 315 2.6k
10 : ±1V 2500 320 N.S. N.S. 640
100 : ±0.1V 2500 N.S. N.S. N.S. N.S.
1000 : ±0.01V 2500 N.S. N.S. N.S. N.S.
Resolution Index = 7    1 : ±10V 1200 650 315 N.S. 1.3k
10 : ±1V 1200 220 N.S. N.S. 440
100 : ±0.1V 1200 N.S. N.S. N.S. N.S.
1000 : ±0.01V 1200 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 600 N.S. N.S. N.S. N.S.
1000 : ±0.01V 600 N.S. N.S. N.S. N.S.

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

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 channel.
  • Sample: A reading from one address.
  • Scan: One reading of a list of one or more addresses.
  • 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.

The T7 has a 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 table A.1.4 (highlighted).  The scan rates reported in table A.1.4 are the maximum sample rates divided by the number of channels in the scan list (within ~10%).

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.

 

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.

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.

15 comments

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

Hi,

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?

Thanks!

Best regards,
Martin

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,

Martin

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

Hi,

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,

Martin

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:

https://labjack.com/support/app-notes/waveform-generation

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.