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:
- 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.
raspberry-pii2csparkfunShareCiteEditFollowFlagedited May 31 at 16:42asked May 26 at 14:50SDW1144 bronze badges
- 1Nice pictures but where is the schematic you promised, frizzy things do not count? – Gil May 26 at 18:07
- please, do not crosspost … delete duplicates … raspberrypi.stackexchange.com/questions/125049/… – jsotola May 26 at 23:59
- what i2c clk frequency are you using? Because it seems that your MUX is not getting the commands correctly it seems. – Christian B. May 31 at 17:26
- @SDW you mentioned in the forum that yout tried it with a LCD screen as well. Can you give us the corresponding datasheet or product number? – Christian B. yesterday
3 Answers
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
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:
- only with green wire attached and everything are working fine.
- 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:
- 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.
- 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.
- 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.
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
.END
Categories: Uncategorized
tlfong01.blog 