I2C Bus Buffer and I2C Multiplexer

I am trying to extend the range of my I2C sensors using the P82B96 I2C Bus Buffer. I am using one on the Arduino side and another on the sensor side.
I am using multiple LUX sensors that share the same I2C address, so I am using the TCA9548A I2C Multiplexer from Adafruit so that I can use the same type of sensors on the I2C bus.

I can successfully read the sensors directly from the MUX just fine; however, when I try to read the sensors from the MUX to the buffer, the bus hangs.
The hardware seems to be in working order, and I can attach a schematic; however, I was just wondering if anyone might have some insight.

Is there some sort of conflict between the buffer and MUX?

Attached is a code example and schematic of the 4 I2C buffers connected to the MUX. The MUX is simply connected to the Arduino via SCL, SDA, and voltage. I'm using a class from Github that integrates with the TCA9548A to communicate with the MUX.


#include <Arduino.h>
#include "TCA9548A.h"

TCA9548A I2CMux;                  // Address can be passed into the constructor

void setup() {
  I2CMux.begin(Wire);             // Wire instance is passed to the library
  I2CMux.openChannel(0);  // this code works fine
  I2CMux.closeChannel(0); // here's where the code hangs

void loop() 

Quite some high tech. Could You provide code, in code tags, and a wiring, schematics?
You likely have experience of electronics but now and then powering, signal levels etc mismatch.. You name it.
The amount of helper questions can be kept at a minimum I hope.

How long is Your I2C bus? How many loading circuits in the perifere end? The link looks like a bus amplifier. What is the situation on the other side of the buffer "far away"?

The MUX is also kind of a buffer, so there may be conflicts. Please show a schematic picture of arrangement (data flow)
from master through buffers, cable and mux to the slaves.

Wire.endTransfer() covers the entire transmission from master to slave. Only here transmission problems can occur.

I can think of asking two questions here.


How Far?

Have you tried removing the I2C multiplexer and just communicating with just ONE sensor to prove your extension is working.

Can you please post a circuit diagram?

Thanks.. Tom.... :smiley: :+1: :coffee: :australia:

Thanks all for the feedback. I updated the original post, added the schematic, and added some code.

Right now, I do not have anything connected on the other side of the bus. It's simply the uC -> MUX -> the buffer chip. I'm just trying to open and close the channel without a hangup. I can open the channel fine, but when I close it or make calls to read the sensor (once hooked up) is when the uC hangs.

I'm using a phone cable that is around 3 feet to communicate with an I2C sensor (LUX sensor from Adafruit). No other circuits.

It's simply the uC -> MUX -> buffer on starting point -> buffer on endpoint -> slave. Right now, I only have the uC -> MUX -> buffer on starting point connected for testing, but I get the same result even after connecting the LUX sensor.

I was incorrect on that statement and updated the description. It's specifically when I am trying to close the channel or read the sensor from the MUX is when it hangs. Wire.endTransfer() is successful when opening the channel.

Yes. uC -> buffer -> sensor works.

As other helpers asked, please show the "line", controller, mux, buffer...
You posted 4 times the same circuit....
If You have nothing, no I2C device connected, I think a hanging, waiting for a respons, could be a reason.

I have uploaded a picture of my setup. I assume that's what is being asked?

Please not a photo but a schematic drawing.

Replace the pullup resistors at SDA and SCL between the MUX and the buffer to 4k7 or 10k.
Remove all the capacitors at SDA and SCL between the MUX and the buffer.
Replace all pullup resistors for the cable with more reasonable values. Perhaps 470Ω or 1k.

A twisted pair signal would be better. That is a twisted pair for SDA and a twisted pair for SCL: https://hackaday.com/2017/02/08/taking-the-leap-off-board-an-introduction-to-i2c-over-long-wires/

No buffers needed then.

I guess you didn't know page 60 when you put the signals on that phone cable ?
Look for the bold "page 60" here: https://github.com/Koepel/How-to-use-the-Arduino-Wire-library/wiki/How-to-make-a-reliable-I2C-bus.

3 feet is 91 cm. That four times ? That is still a lot. The I2C bus was not designed to go through a cable. Can you tell more about your project ? Why do you need those lux sensors at that distance ?

@czu001 I still have so little information. I would like to know for example which modules you use. I'm afraid your project is not going well and good advice is hard with so little information.

Why four times?
Each lux sensor is on a different port of the muxer.

Thanks. I didn't think about that :blush:

The project is a solar tracker that will be using light sensors to track the sun. The microcontroller will be up to 9 feet away from the sensors. Here are the light sensors I was interested in using.

Having said that, I wasn't aware of the limitations of I2C. For my usage, I could probably get by with a simpler light sensor such as this analog sensor.

Perhaps, a better question is how to receive a clean signal 10 feet away from a 3.3V uC using an analog sensor. I2C may not be the best choice.

Yep, a simple LDR quadrant (Google it) is commonly used for solar trackers.


Why such a complex sensor array, when all you need are four LDRs with each in a potential divider?

All you are looking for is differential values to keep your PV aligned with source of max radiation.

Thanks for the circuit diagrams, but they are only good for making PCBs, you need a master schematic with ALL wire connections, not ALL "netnames".
It needs to show connections and power supplies etc, for troubleshooting.

Tom... :smiley: :+1: :coffee: :australia:
PS. Please do not got back and edit major parts of earlier posts, please just put your edits, requested information in a NEW post.

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.