2.1 - USB [UE9 Datasheet]

For information about USB installation, see Section 1.

The UE9 has a full-speed USB connection compatible with USB version 1.1 or 2.0. This connection can provide communication and power (Vusb), but it is possible that some USB ports will not be able to provide enough power to run the UE9 at all speeds. Certain low power USB ports can be limited to 100 milliamps, and some power modes of the UE9 use more than 100 milliamps. A USB hub with a power supply (self-powered) will always provide 500 milliamps for each port.

USB ground is connected to the UE9 ground, and USB ground is generally the same as the ground of the PC chassis and AC mains. In this case, the UE9 is not electrically isolated when the USB cable is connected.

The details of the UE9 USB interface are handled by the high level drivers (Windows LabJackUD DLL), so the following information is really only needed when developing low-level drivers.

The LabJack vendor ID is 0×0CD5. The product ID for the U3 is 0×0009.

The USB interface consists of the normal bidirectional control endpoint 0 and two bidirectional bulk endpoints: Endpoint 1 and Endpoint 2. Endpoint 1 consists of a 16 byte OUT endpoint (address = 0x01) and a 16 byte IN endpoint (address 0x81). Endpoint 2 consists of a 64 byte OUT endpoint (address = 0x02) and a 64 byte IN endpoint (address = 0x82).

Commands can be sent on either endpoint, and the response will be sent on the same endpoint, except that stream data is always transferred on IN Endpoint 2, regardless of whether the stream start command was sent on OUT Endpoint 1 or 2.

Commands can be sent on both endpoints at the same time, but as with any connection on the UE9, do not send a second command on an endpoint until after receiving the response to the first command.

Except for reading stream data, always write and read the actual number of bytes in the command and response. If the size is not an even multiple of the endpoint size a short packet will be transferred. In general, small transfers will be faster on Endpoint 1 and large transfers will be faster on Endpoint 2, but the time differences are small if any, and it is normal to do all communication besides reading stream data on Endpoint 1. The main reason for the different endpoints is to simplify calling command/response functions while a stream is in progress.

USB stream data is a special case where each 46-byte data packet is padded with 2 zeros on the end (not part of the protocol), and then 4 of these 48-byte blocks are grouped together and sent in 3 transfers over the 64-byte endpoint. The host will generally read stream data over USB in multiples of 192 bytes (64 samples). This means that at low scan rates there could be a long time between reads and latency will be high, but this can be improved by oversampling.

The USB transceiver on the UE9 has a 128 byte hardware buffer on Endpoint 2. If the UE9 stream data buffer has one or more StreamData packets available, they are moved to the USB buffer to await a read by the host. Once placed in this USB buffer, the data cannot be removed (e.g. by a FlushBuffer command). To avoid confusion on future communication on Endpoint 2, this buffer should always be emptied after streaming.

One way to empty this buffer is to continue reading data after StreamStop, until there is no more (the read times out). This should not require a long timeout as the data is not being acquired, but simply waiting to be retrieved from the UE9 FIFO buffer.

Another option is to follow the StreamStop command with a FlushBuffer command. Then just try to read the last 128 bytes that could still be in the USB buffer.

A third option is to do a StreamStop (and a FlushBuffer if desired), and then do not attempt to empty the USB buffer, but always discard the first two StreamData packets after StreamStart.