Skip to Navigation

U3

Everything tagged "U3"

Special discounted shipping rates

We are offering two special shipping rates for continental US customers. If you buy a single U3, you may choose the "UPS Ground Single U3 Special Rate" for $9.50:

UPS Ground Single U3 Special Rate

Want to expand your project with one of our LJTicks, such as the LJTick-InAmp or LJTick-RelayDriver? Any number of ticks up to $100 can be shipped for $5. Just choose:

U.S.P.S. Priority Mail Tick Special Rate

Enjoy, and don't forget that if you have your own UPS/FexEx/Carrier pigeon account, you may always use that option:

Use my shipping account number specified in the Order comments

 

tags:

Appendix B - Enclosure and PCB Drawings

Various drawings follow.  CAD drawings of the U3 attached to the bottom of this page (DWG, DXF, IGES, STEP).

 

 

U3 OEM PCB Dimensions

Notes on U3 OEM PCB Dimensions

  1. USB, PIN1
  2. OEM 2x5 HEADER, 0.100" PITCH, PIN 1
  3. OEM 2X8 HEADER, 0.100" PITCH, PIN 1

See attached U3 PCB Dimensions.dxf for CAD drawing.

 

tags:

Appendix A - Specifications

Specifications at 25 degrees C and Vusb/Vext = 5.0V, except where noted.

tags:

4.4 - Errorcodes

All functions return an LJ_ERROR errorcode as listed in the following tables.

Table 4-1 lists the errors which are specific to a request. For example, LJE_INVALID_CHANNEL_NUMBER. If this error occurs, other requests are not affected. Table 4-2 lists errors which cause all pending requests for a particular Go() to fail with the same error. If this type of error is received the state of any of the request is not known. For example, if requests are executed with a single Go() to set the AIN range and read an AIN, and the read fails with an LJE_COMM_FAILURE, it is not known whether the AIN range was set to the new value or whether it is still set at the old value.

tags:

4.3.14 - Miscellaneous

The following are special channels, used with the get/put config IOTypes, to read/write the calibration memory and user memory:


LJ_chCAL_CONSTANTS    // x1 points to an array with 64 doubles.
LJ_chUSER_MEM    // x1 points to an array with 256 bytes.

For more information, see the low-level descriptions in Sections 5.2.65.2.8, and see the Memory example in the VC6_LJUD archive.

The following wait IOType is used to create a delay between other actions:


LJ_ioPUT_WAIT  // Channel ignored. Value = 0-4194176 microseconds.

Any value (in microseconds) from 0-4194176 can be passed, but the actual resolution is 128 microseconds (U3C = 128 us, U3B = 64 us, U3A = 128 us).

This is typically used to put a small delay between two actions that will execute in the same low-level Feedback command. It is useful when the desired delay is less than what can be accomplished through software.

For example, a 1.024 millisecond pulse can be created by executing a single Add/Go/Get block that sequentially requests to set FIO4 to output-high, wait 1024 microseconds, then set FIO4 to output-low.

tags:

4.3.13 - Watchdog Timer

The U3 (hardware version 1.21+ only) has firmware based watchdog capability. Unattended systems requiring maximum up-time might use this capability to reset the U3 or the entire system. When any of the options are enabled, an internal timer is enabled which resets on any incoming USB communication. If this timer reaches the defined TimeoutPeriod before being reset, the specified actions will occur. Note that while streaming, data is only going out, so some other command will have to be called periodically to reset the watchdog timer.

Timeout of the watchdog on the U3 can be specified to cause a device reset, update the state of 1 digital I/O (must be configured as output by user), or both.

Typical usage of the watchdog is to configure the reset defaults (condition of digital I/O and analog outputs) as desired (use the “config defaults” option in LJControlPanel V2.26+), and then use the watchdog simply to reset the device on timeout. For initial testing, “config defaults” in LJCP can be used to enable the watchdog all the time, but often it is desirable to enable/disable the watchdog in user software so it is only active while that software is running.

Note that some USB hubs do not like to have any USB device repeatedly reset. With such hubs, the operating system will quit reenumerating the device on reset and the computer will have to be rebooted, so avoid excessive resets with hubs that seem to have this problem.

If the watchdog is accidentally configured to reset the processor with a very low timeout period (such as 1 second), it could be difficult to establish any communication with the device. In such a case, the reset-to-default jumper can be used to turn off the watchdog. Power up the U3 with a short from FIO6 to SPC (FIO2 to SCL on U3 1.20/1.21), then remove the jumper and power cycle the device again.

tags:

4.3.12 - Asynchronous Serial Communication

The U3 (hardware version 1.21+ only) has a UART available that supports asynchronous serial communication. On hardware version 1.30 the TX (transmit) and RX (receive) lines appear on FIO/EIO after any timers and counters, so with no timers/counters enabled, and pin offset set to 4, TX=FIO4 and RX=FIO5. On hardware version 1.21, the UART uses SDA for TX and SCL for RX.

Communication is in the common 8/n/1 format. Similar to RS232, except that the logic is normal CMOS/TTL. Connection to an RS232 device will require a converter chip such as the MAX233, which inverts the logic and shifts the voltage levels.

This serial link is not an alternative to the USB connection. Rather, the host application will write/read data to/from the U3 over USB, and the U3 communicates with some other device using the serial protocol. Using this serial protocol is considered an advanced topic. A good knowledge of the protocol is recommended, and a logic analyzer or oscilloscope might be needed for troubleshooting. Also consider that a better way to do RS232 communication is with a standard USB<=>RS232 adapter/converter/dongle, so the user should have a particular reason to not use that and use a U3 instead.

There is one IOType used to write/read asynchronous data:


LJ_ioASYNCH_COMMUNICATION

The following are special channels used with the asynch IOType above:


LJ_chASYNCH_ENABLE  // Enables UART to begin buffering rx data.
LJ_chASYNCH_RX      // Value= returns pre-read buffer size. x1= array.
LJ_chASYNCH_TX      // Value= number to send (0-56), number in rx buffer. x1= array.
LJ_chASYNCH_FLUSH   // Flushes the rx buffer.  All data discarded. Value ignored.

When using LJ_chASYNCH_RX, the Value parameter returns the size of the Asynch buffer before the read. If the size is 32 bytes or less, that is how many bytes were read.

tags:

4.3.11 - I²C Serial Communication

The U3 (hardware version 1.21+ only) supports Inter-Integrated Circuit (I²C or I2C) communication as the master only. I²C is a synchronous serial protocol typically used to communicate with chips that support I²C as slave devices. Any 2 digital I/O lines are used for SDA and SCL. Note that the I²C bus generally requires pull-up resistors of perhaps 4.7 kΩ from SDA to Vs and SCL to Vs, and also note that the screw terminals labeled SDA and SCL (if present) are not used for I²C.

This serial link is not an alternative to the USB connection. Rather, the host application will write/read data to/from the U3 over USB, and the U3 communicates with some other device using the serial protocol. Using this serial protocol is considered an advanced topic. A good knowledge of the protocol is recommended, and a logic analyzer or oscilloscope might be needed for troubleshooting.

There is one IOType used to write/read I²C data:


LJ_ioI2C_COMMUNICATION

The following are special channels used with the I²C IOType above:


LJ_chI2C_READ      // Value= number of bytes (0-52). x1= array.
LJ_chI2C_WRITE     // Value= number of bytes (0-50). x1= array.
LJ_chI2C_GET_ACKS

The following are special channels, used with the get/put config IOTypes, to configure various parameters related to the I²C bus. See the low-level function description in Section 5.2.19 for more information about these parameters:


LJ_chI2C_ADDRESS_BYTE
LJ_chI2C_SCL_PIN_NUM   // 0-19. Pull-up resistor usually required.
LJ_chI2C_SDA_PIN_NUM   // 0-19. Pull-up resistor usually required.
LJ_chI2C_OPTIONS
LJ_chI2C_SPEED_ADJUST

The LJTick-DAC is an accessory from LabJack with an I²C 24C01C EEPROM chip.

tags:

Comments

No comments yet. Speak up. We're listening.

4.3.10 - SPI Serial Communication

The U3 (hardware version 1.21+ only) supports Serial Peripheral Interface communication as the master only. SPI is a synchronous serial protocol typically used to communicate with chips that support SPI as slave devices.

This serial link is not an alternative to the USB connection. Rather, the host application will write/read data to/from the U3 over USB, and the U3 communicates with some other device using the serial protocol. Using this serial protocol is considered an advanced topic. A good knowledge of the protocol is recommended, and a logic analyzer or oscilloscope might be needed for troubleshooting.

There is one IOType used to write/read data over the SPI bus:


LJ_ioSPI_COMMUNICATION // Value= number of bytes (1-50). x1= array.

The following are special channels, used with the get/put config IOTypes, to configure various parameters related to the SPI bus.

tags:

4.3.9 - Easy Functions

The easy functions are simple alternatives to the very flexible IOType based method normally used by this driver. There are 6 functions available:


eAIN()       //Read 1 analog input.
eDAC()       //Write to 1 analog output.
eDI()	        //Read 1 digital input.
eDO()        //Write to 1 digital output.
eTCConfig()  //Configure all timers and counters.
eTCValues()  //Update/reset and read all timers and counters.

In addition to the basic operations, these functions also automatically handle configuration as needed. For example, eDO() sets the specified line to digital output if previously configured as analog and/or input, and eAIN() sets the line to analog if previously configured as digital. Passing a -1 to any of the configuration parameters (resolution, range, etc) will use the driver's current value instead of having to specify it. This is useful so that you can use the driver's default values for those properties, which will work in most cases.

The first 4 functions should not be used when speed is critical with multi-channel reads. These functions use one low-level function per operation, whereas using the normal Add/Go/Get method with IOTypes, many operations can be combined into a single low-level call. With single channel operations, however, there will be little difference between using an easy function or Add/Go/Get.

The last two functions handle almost all functionality related to timers and counters, and will usually be as efficient as any other method. These easy functions are recommended for most timer/counter applications.

Following is example pseudocode:

tags: