Uncategorized

i2c problem 2

The Differential I2C Bus Extender is only working for 1 channel

Ask QuestionAsked 9 days agoActive yesterdayViewed 167 times1The bounty expires in 3 days. Answers to this question are eligible for a +100 reputation bounty. SDW wants to draw more attention to this 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:

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.

enter image description here
enter image description here

raspberry-pii2csparkfunShareCiteEditFollowFlagedited May 31 at 16:42asked May 26 at 14:50SDW1144 bronze badges

Add a comment

3 Answers

ActiveOldestVotes1

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.ShareCiteEditFollowFlaganswered May 31 at 18:35DamienD56133 silver badges1111 bronze badges

  • 1Thank you for your answer. I will give this a try and come back to you ASAP. – SDW yesterday

Add a comment0

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):

signal after long wire

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.

shielded cable

ShareCiteEditFollowFlagedited 2 days agoanswered 2 days agoChristianidis Vasileios82422 silver badges1717 bronze badges

  • Are you aware that GND (and VCC=3.3V) are already passed through by the Qwiic Bus and the EndPoints? And it seems like the Endpoints uses RJ-45 connectors which do not provide access to the shielding so the CAT shield (if present) is left floating by default – Will be hard to connect the shield then. However, I would assume that differential signaling should suffice for the typical lower I2C frequencies. – Christian B. 2 days ago
  • The issue is not how the signals are placed on the Qwicc/Endpoints or if they are passed through them. The issue is the signal while it is on the wire. The noise that the wire gets and how good the ground cable is (for example using twisted pairs for each data line on the cable is a good start) – Christianidis Vasileios 2 days ago
  • So you think the S/FTP (=Screened Foiled Twisted Pair) type cable mentioned in the first post is not appropiate? – Christian B. yesterday
  • It is appropriate. As I said on my last reply, it is a good start. And as a reminder, we will never know what really going on until OP shows us how the signal looks on the oscilloscope. – Christianidis Vasileios yesterday 
  • Thank you for your answer. Currently I don’t have an oscilloscope, but I will buy one right now. Is there anything else I should take into account when I want to buy a oscilloscope? After I got my oscilloscope I will post the pics! – SDW yesterday

Add a comment  |  Show 1 more comment0

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.ShareCiteEditFollowFlaganswered yesterdayDamien6,07711 gold badge99 silver badges2525 bronze badges

  • 1Thank you for your answer. I’m using a S/FTP cable. It’s recommended for the best shielded RJ45 cable. I also tried a UTP and S/UTP cable. Same problem unfortunately. – SDW yesterday

Add a comment

.END

Categories: Uncategorized

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.