Trouble connecting to ZED-F9R unit with Raspberry Pi 4 via I2C

GPS/GNSS Development Boards
1

Summary

I am working to build a sensor bundle that includes positioning, applied force, motion sensing, etc, using a number of SparkFun and AdaFruit sensors. Using a Pi 4B as the base, I’m using a load cell sensor, 6dof IMU, and GPS breakout via Qwiic, connecting to SparkFun Qwiic HAT, and attempting to access via i2c using the python3 smbus2 package. I am having difficulty with connecting the GPS unit both at the OS level and programmatic level.

Requested Help

I need help successfully getting the GPS unit connected to the Pi, correctly detected by i2cdetect, and correctly polled by a python3 program using the smbus2 package.

Observed Behaviors

Connecting the load cell and/or IMU works just fine. i2cdetect immediately returns with an appropriately populated map. A test program is able to poll useful data from the connected module(s).

Connecting the GPS causes i2cdetect to map very slowly (1-3 seconds per address), with no address showing as occupied. Running the test program fails to connect to any device, including the load cell or IMU.

Working with the GPS unit via USB on a Windows device via U-Center works fine; the module does not seem to be faulty.

Desired Behaviors

With any combination of the three modules connected, i2cdetect correctly generates the address map. A test program correctly polls from connected devices using the smbus2 library, and correctly reports no connection for devices that are not connected.

Hardware List

Compute:

Raspberry Pi 4B 8GB

HAT:

SparkFun Qwiic HAT for Raspberry Pi

Sensors:

SparkFun GPS-RTK Dead Reckoning Breakout - ZED-F9R (Qwiic)

SparkFun Qwiic Scale - NAU7802

Adafruit MPU-6050 6-DoF Accel and Gyro Sensor - STEMMA QT Qwiic

2

Wrap Up Summary

(tongue in cheek) I’m an idiot and the issue is resolved. :slight_smile:

(actual) Hardware level testing showed that the Qwiic cable that was being used for connecting the GPS unit was faulty. A replacement of the cable with another resolved the issue.

Findings

Multiple sample bits of code for accessing i2c devices directly at the register level, and even sample code specifically for the UBlox family using the same technique, were found and tested. All worked as desired for no modules, the scale alone, the IMU alone, and the scale plus IMU. This included when the scale and IMU were connected to the Qwiic HAT directly and when in a chain. With the GPS unit connected, either directly or in chain, the above-mentioned observed behaviors occurred.

The above pointing to a hardware issue, and this happening with both my F9P and F9R, a swap out of the Qwiic cable that was being used for the GPS units was done. The observed issues resolved, bringing about the desired behavior. This included full hot-swap capability, full interoperability of the three sensor modules, and correct behavior regardless of how many devices were connected and in what arrangement (direct to HAT, chained, hybrid of the above). With the GPS connected via the replacement cable, the test code correctly pulled proper-looking byte data (lots of 0xFF, with occasional longer lengths of bytes terminating in 0x0A). The parser failed but that failure is not relevant to this particular issue.

After the swap out, close inspection of the removed cable’s connector ends shows the barely visible metal connection points on the two connectors differs in appearance. As well, one end’s black wire was tightly bent next to the connector.

Such bending could cause a stress fracture of the wire leading to electrical parameters outside the i2c acceptable range.

Root Cause Analysis

Based on the findings, it seems that the cable being used to connect the GPS was the problem. Given the visual inspection of the cable and the correction of behavior on swap out, the original cable is with very high probability the root cause.

Corrective Action

The original cable was replaced with a different cable. The original cable has been discarded to appropriate electronics recycle disposal on the very high probability that it is faulty.

Lessons Learned

Moving forward, remember to consider even basic hardware as a potential root cause. Even a straight piece of wire without connectors can have a concealed metallurgic flaw – and given a Qwiic cable has four insulated wires and eight connection points (four in each of two terminators plus the terminators themselves), a Qwiic cable then has many many more potential points of failure and should not be considered an infallible fundamental.