3.1 - Command/Response [U3 Datasheet]

Everything besides streaming is done in command/response mode, meaning that all communication is initiated by a command from the host which is followed by a response from the U3.

For everything besides pin configuration, the low-level Feedback function is the primary function used, as it writes and reads virtually all I/O on the U3. The Windows UD driver uses the Feedback function under-the-hood to handle most requests besides configuration and streaming.

The following tables show typical measured execution times for command/response mode. The time varies primarily with the number of analog inputs requested, and is not noticeably affected by the number of digital I/O, DAC, timer, and counter operations.

These times were measured using the example program “allio.c” (VC6_LJUD). The program executes a loop 1000 times and divides the total time by 1000, and thus include everything (Windows latency, UD driver overhead, communication time, U3 processing time, etc.).

Table 3.1-1. Typical Feedback Function Execution Times (QuickSample=0, LongSettling=0)

Table 3.1-2. Typical Feedback Function Execution Times (QuickSample=1, LongSettling=0)

Table 3.1-3. Typical Feedback Function Execution Times (QuickSample=0, LongSettling=1)

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

The analog inputs have a QuickSample option where each conversion is done faster at the expense of increased noise. This is enabled by passing a nonzero value for put_config special channel LJ_chAIN_RESOLUTION. There is also a LongSettling option where additional settling time is added between the internal multiplexer configuration and the analog to digital conversion. This allows signals with more source impedance, and is enabled by passing a nonzero value for put_config special channel LJ_chAIN_SETTLING_TIME. Both of these options are disabled by default, so the first table above shows the default conditions.

The first row in each of the above tables (# AIN = 0) includes a write and read to all I/O on the U3 besides analog inputs (digital I/O, DACs, timers, and counters). The times in other rows basically consist of that fixed overhead plus the time per analog input channel, so times can be interpolated for other numbers of channels.

How about for 2 analog input channels with QuickSample=0 and LongSettling=0? You know that 1 channel takes about 1.0 ms and 4 channels takes about 2.4 ms. That means it takes about (2.4-1.0)/(4-1) = 0.46 ms/channel plus overhead of about 0.6 ms, so 2 channels would take about (2*0.46)+0.6 = 1.5 ms.

How about for 20 channels? This is a little different because the commands and/or responses for 20 channels can’t fit in one low-level packet. From Section 5.2.5, the Feedback command has room for 57 bytes of command data and 55 bytes of response data. From Section 5.2.5.1, the AIN low-level IOType has 3 command bytes and 2 response bytes. That means the low-level Feedback command can hold 19 commands and 27 responses. Thus the commands are limiting and 19 channels is the most we can get into 1 low-level Feedback packet. The timing for 20-channels can then be calculated as a 19-channel read plus a subsequent 1-channel read. If you do an Add/Go/Get block with 20 channels the UD driver will split it like that.

The tables above were measured with U3 hardware version 1.21 which started shipping in late August of 2006. The times could be up to twice as long with hardware version 1.20 or less.