I2C Resources (App Note)
I2C communications involve many small details that must be managed with care. Most I2C communication issues are due to the negligence of one or more implementation details. I2C configuration and troubleshooting should test and confirm that every sensor specific implementation detail is handled.
When we refer to “U-Series” devices in subsequent sections we are referring to the U3, U6, and UE9. The U12 uses different software and it does not support I2C.
I2C Basics
We consider I2C an advanced topic. It is important to understand the protocol before working with I2C sensors. The following resources are useful to get started with I2C:
TI's Understanding the I2C Bus by Jonathan Valdez and Jared Becker is a high quality resource
I2C-bus specification by NXP
Using the I2C Bus by Robot Electronics
I2C Bus Specification by i2c.info
LabJack I2C Configuration
Once you are comfortable with the I2C protocol, there are several additional resources to help get started with I2C via LabJack hardware. To get started, go through your device Quickstart Tutorial then see the following resources.
You will need a real I2C sensor to do any meaningful I2C configuration with a LabJack. If you do not have an I2C based sensor, or if you are having issues with your sensor, we recommend testing I2C with the LJTick-DAC.
T-Series Devices
The Communications section of the T-Series datasheet describes how you can control and communicate with a T-Series device.
The I2C section of the T-Series datasheet describes all of the device configurations necessary to perform an I2C transaction.
LabJack offers several pre-made Lua Script I2C Examples.
Most LJM Software Example Packages include one or more I2C example, typically using the LJTick-DAC.
U-Series Devices
The U-Series I2C App Note describes how you can control and communicate with a U-Series device.
LabJack offers High-level (UD library) I2C Pseudocode for all U-Series devices:
The Low-level I2C Function Reference describes the low-level I2C transaction function for U-Series devices.
Most UD Software Example Packages include one or more I2C example, typically using the LJTick-DAC.
Simple Test
Before trying to read sensor data, it is best to verify that your sensor is responding to the LabJack requests with a basic test: write one byte and check for ACKs. If your sensor is configured properly, it should respond to any write command with one ACK per byte written.
For example, if you send the header byte with the slave address and read/write bit (sent automatically by the LabJack in all I2C commands) and one write byte you should see two ACKs.
If you see any ACKs, the SCL, SDA, slave address, and physical wiring are all likely correct.
If you do not see ACKs, then something is misconfigured. See the additional troubleshooting steps below.
This basic test can also be leveraged to discover the sensor slave address programmatically. Start at some slave address, send a single byte in a write command, and if you do not see ACKs then there is not a valid sensor configured at that address. Iteratively test different slave addresses until you receive ACKs or test all possible addresses (0-127).
Basic Settings
Make sure pull-up resistors are installed from SCL to Vsupply and SDA to Vsupply. Not all sensors have built-in pullup resistors. If external pullup resistors are required, a general rule to select the correct resistor size is to start with 4.7kΩ and adjust down to 1kΩ as required. If necessary, an oscilloscope should be used to ensure proper digital signals are present on the SDA and SCL lines.
Make sure the correct I/O lines are being used. For example, check that your SCL pin configuration in software matches the hardware connection and that SCL and SDA are not flipped. When possible, we recommend doing I2C communication on EIO/CIO/MIO lines instead of the FIO lines due to the larger series resistance (ESD protection) implemented on the FIO lines of most LabJack devices.
Make sure your sensor is being properly powered. The VS lines of LabJack devices are ~5V and the DIO lines use 3.3V logic. This can cause issues with I2C edge detection when the sensor logic high threshold is something like 0.9*Vsupply. Consider buying a LJTick-LVDigitalIO or powering the sensor with a DIO line or DAC channel.
Check that your sensor slave address is correct and that it is configured properly in software. U-Series devices expect an 8-bit address to their low level I2C command whereas T-Series devices expect the 7-bit address for their I2C interface. It is common to mix up which address you need and which address your sensor datasheet provides. Also note that all LabJack devices automatically set the read/write bit for I2C commands. If necessary, you can use a logic analyzer (some oscilloscopes have this functionality) to verify the correct slave address is being used. See this EEVblog post on budget-friendly options.
Bus Speed and Signal Integrity
When the I2C bus has excessive capacitance and series resistance, a low-pass filter is created, which can cause notable signal degradation and communication failure. An oscilloscope can be used to confirm that the SDA and SCL lines produce square waves rather than being arched or resembling a shark tooth. These deformities would indicate that there is significant filtering on the bus.
Try slowing down the I2C bus. Not all I2C sensors can communicate at the full speed of the LabJack: check the I2C sensor datasheet. Further, if there is substantial filtering at the default bus speed then lowering the bus speed may reduce the filtering effects.
Try to determine whether your sensor is still functioning correctly. For example, test the sensor using an Arduino.
The LJTick-DAC uses I2C; try to establish communications with an LJTick-DAC to verify proper DIO operation and to help verify that you are configuring I2C properly in software.
Receiving ACKs but not the Expected Sensor Data
If you are receiving ACKs in the basic test described above but you are still unable to get proper data from the sensor, there is likely some issue with the way you are framing your commands.
Read the sensor datasheet very closely. Everything you need for the sensor communications should be documented in the datasheet, but it is easy to accidentally gloss over important implementation details.
Check if your sensor needs a delay between the write and read command. Some sensors require a short (sampling time) delay before data can be read.
Check if there needs to be a stop bit on command restart. LabJack I2C interfaces support both options (stop on restart and no stop on restart).
Probe SCL and SDA with a logic analyzer while you send your I2C command. This will verify whether the LabJack is sending the data you expect and the sensor is returning the data you expect. If the data on the analyzer looks good but you do not get good data from the LabJack, there could be some issue with the way you are reading data in software. There may also be a power/logic-level issue. See the basic settings section above.
Make sure that your program variables that hold your write and read data buffers are properly allocated and defined within the execution scope when you try to use them.
Double check the code that is configuring your I2C read and write buffers on the LabJack.
I2C Simulator
We have a useful I2C simulation tool to help visualize the I2C bus with common LabJack configurations.
This tool was designed for T-Series devices and the U-Series I2C interfaces are slightly different. U-Series devices expect an 8-bit address for their low-level I2C interface whereas the simulation tool (and T-Series devices) assumes you enter the 7-bit address. The bit-mask value for "I2C Options" also has its bits ordered differently on U-Series devices.