The Differential I2C Bus Extender is only working for 1 channel

Question

Edit: More information about this question can also be found here: https://forum.sparkfun.com/viewtopic.php?f=105&t=55786

Currently I'm working on a project where I want to use multiple scales in a fridge. When something will be taking out of the fridge the scale detects the different weight and send an event to my server. I'm really a noob to I2C and at this moment I can't figure out why it's not working...

I'm using a Raspberry Pi 4 Modal B with a pHat attached to the GPIO pins. From there I use a Qwiic cable to connect the bus to a PCA9615. Then I use a 2m S/FTP cable to connect the other PCA9615. Then the signal goes to a TCA9548A to use the bus with 8 different channels. I need the 8 channels because the I2C address of the NAU7802 is 0x2A and is hardware defined. A multiplexer/Mux is required to communicate to multiple NAU7802 sensors on a single bus.

Now the problem that I'm facing is that everything is working correctly when I don't use the I2C Bus Extender. I see all of my channels and I can change the channel to retrieve the weight of the multiple scales. But when I connect the I2C Bus Extender there is only 1 channel working and the other channels are not available. Is there any solution how to fix this problem?

Products that I use:

• SparkFun Qwiic pHAT v2.0 for Raspberry Pi
• SparkFun QwiicBus - EndPoint
• SparkFun Qwiic Mux Breakout - 8 Channel (TCA9548A)
• SparkFun Qwiic Scale - NAU7802

Images

The red lines are indicating that the connection is not working. I only see 1 NAU7802 when I use the i2cdetect command. Now when I disconnect the red lines but connect the green line, everything is working correctly. But that's unfortunately not what I want to achieve.

Answer 1

Here is a related answer: https://stackoverflow.com/questions/60191137/i2cdetect-does-not-recognize-vl6180x-sensors-behind-tca9548a-i2c-multiplexer

Basically, there is some driver magic involved in getting i2cdetect to "see" devices behind a multiplexer. It's possible that the differential i2c somehow breaks that magic.

The standard way to use the multiplexer is to send it commands to select one specific channel. Then you can see and talk to the devices on that channel only. Somehow i2cdetect does that for you when it recognizes the multiplexer.

Try to write some code that controls the mux and see if you can talk to all your sensors, even though i2cdetect can't list them.

Answer 2

Since everything is working fine when you connect the green line, it must be a 'hardware error' caused by long distance cable. If you have not checked the I2C line with an oscilloscope yet, you can only assume that your signals reach their destination safe (aka without any signal degradation).

So yes I dont trust the 'QwiicBus - EndPoint' just like that. I want to see the signal is getting there.

The signal when reaching its destination will most probably look like this (first graph):

Picture from here

The second waveform is what you want. Clean, clear transition from high to low and vise versa.

You can verify this by hooking an oscilloscope on the I2C wires close (the closer the better) to the TCA9548A in two test setups:

1. only with green wire attached and everything are working fine.

2. with your normal setup aka red wires only.

Compare the results. Most probably, they will be different. Also when testing, send the same signal, so that you can compare not only how clear the signal is, but also if you have wired everything correctly (you might have connected SDA/SCL the other way around on those QwiicBuses.

Also post the pics from the oscilloscope here so we can see them and provide extra help. (Both of the setup's pictures so we can compare)

To fix this you issue can:

1. Add a shielded cable along the way of the red wires that connects to GND of your raspberry pi and the GND of TCA9548A. This will give a GND path for the signals to return to.

2. Around the shielded grounded cable, you can add another shield, which will connect to the Earth (Not GND, Earth only!). This will work as a faraday cage and keep noise outside the cables.

3. Consider lowering the frequency of the I2C transmission speed (if possible)

Use a shielded cable like this below. The outer "large naked" wire is the shield, connect it to earth and NOT to the GND.

About the inner cables, connect the VCC, SDA, SCL as normal.

The rest of them, connect them to GND.

Answer 3

The RJ45 cable might be the culprit.

In the old days, if you connect the device to the device directly, it required a crossed RJ45 cable.

This leads to having crossed, and normal RJ45 and it's sometimes difficult to know which you actually are using. On top of that, there are different pinout standards for those cables, and additionally, you have different CAT versions where all the pins are not necessarily populated

Modern computers, routers, and such have logic that can usually handle those cases by hot remapping the pins, but certainly not in this type of chip.

Make sure what RJ45 cable you are using and whether it is the correct one.

Answer 4

The clock speed could be an issue (or actually the total delay induced by the bus components). You could try to use a lower I2C frequency. Check e.g. https://gist.github.com/ribasco/c22ab6b791e681800df47dd0a46c7c3a for how-to set the I2C clock frequency - its for RPi 2 and 3 but it mostlikely works for version 4 too.