QWIIC Endpoint and Midpoint Extenders. Cut the I2C pull-up jumpers or not?

Apparently this is a common cause for confusion. What is the best practice for cutting the I2C pull-up jumpers when using the QWIIC CAT6 endpoint and midpoint bus extenders? I have the following very simple hardware arrangement:

One endpoint with a single QWIIC GPIO board on its I2C bus,

Two midpoints, each with a single QWIIC GPIO board on its I2C bus,

One endpoint connected to a Raspberry Pi4 via QWIIC Phat 2.0,

That’s it, no other hardware. I have not cut any of the I2C jumpers yet (neither on the endpoints/midpoints, nor on the GPIO boards), and the hardware seems to be working fine. The endpoints/midpoints are connected together with about 90 feet total of CAT5E cable (approximately 20 to 30 feet between each extender). This seems to be the limit, anything beyond that and I get communication errors from the last device on the chain.

I was expecting to get a little more distance than this. I’m wondering if I should cut the I2C jumpers on the GPIO boards since there are pull-up resistors (I think, can’t figure out if those are for the CAT side or not) on the endpoints/midpoints. The website documentation on this is not very clear, as others have pointed out. What is the best practice in this scenario?

Would there be any advantage as far as being able to use longer cable runs if the pull-up jumpers are cut on the GPIO boards, or is voltage drop the limiting factor here?

100 feet was our practical limit during experiments…Each case is different, though…it depends on where in your circuit the noise is occurring

The major advantage of removing the pull-ups is that it is very easily reversible - you could try removing the pull-ups and seeing if that allows more transmission distance, and if not, you can always toss a blob of solder back onto the pads to undo it

For those interested, I did cut the I2C jumpers on the GPIO boards. This made no difference at all. Further investigation has revealed this is definitely a voltage drop problem. I took voltage measurements with 80 feet of CAT6 connected. The 3.3 VDC was down to 3.1 VDC with no active inputs on any of the GPIO’s. Communication errors begin when you have too many GPIO inputs active at the same time. In this particular case the limit is three. With three GPIO inputs held closed, the voltage drops to 2.3VDC. Everything still works at this point, but as soon as you close another GPIO input, the voltage drops down to about 2.1VDC, at which point everything crashes.

I’m going to try powering the endpoints/midpoints with 5 VDC and see how much improvement I get. Anybody contemplating use of these endpoints/midpoints in all but the lightest duty applications should be aware that 3.3VDC probably isn’t going to cut it if you’re running more than about 30 feet of CAT6 or have more than two or three I2C devices attached.

Again, posting this for the benefit of others. I used a 12VDC power supply to power my two midpoints using the “Alternate 2” method (3.8-36VDC). With 4 inputs closed on the GPIO, the buck regulator was able to keep the voltage up to about 3.08VDC, down from the starting point of 3.32VDC at the farthest midpoint, and everything worked. This was with 80 feet of CAT6 connecting everything together. I’m willing to bet though, that if you had two GPIO’s on a single midpoint, and you needed to monitor 16 normally closed inputs, the GPIO’s would probably drag the voltage back down below the 2.3 volt operating threshold. Haven’t tried it, just extrapolating.

As an experiment, I also tried putting current limiting resistors in series with the contact closures on the GPIO inputs in an attempt to reduce the load and keep the voltage up. I discovered The GPIO inputs will not tolerate any series resistance above 100 ohms or so, not enough to make any appreciable difference in the voltage drop.

I’d like to say to Sparkfun that you need to a better job documenting the endpoint/midpoint products. When I made the changeover to the Alternate 2 power method, nothing would communicate. I finally figured out that IN ADDITION to using the 3.8-36VDC, you ALSO need to power to power the VCC1 circuit with 5VDC, or otherwise get 3.3-5VDC to the final endpoint, so it will power up. The midpoints DO NOT take care of this. All they do is pass the 3.8-36VDC down the line to the next extender. But when it gets to the endpoint, it doesn’t do anything. NOWHERE in the documentation or the product web pages is this mentioned. The power LED not illuminating on the final endpoint was the clue. To fix this, I just took the endpoint and connected it to the last midpoint with a 6" CAT cable and powered it from the spare I2C plug on the midpoint. It’s just serving as a dummy terminator now, no I2C devices connected. Once I did this, everything worked fine.

Come on guys, you need to make it clear that using the 3.8-36VDC method ALSO REQUIRES THE 5VDC connections at the head-end. The Hookup Guide webpage makes it sound as if you can use one or the other. An endpoint with an onboard buck regulator, same as the midpoints have, that could take advantage of the higher voltage coming down the line would be a handy thing to have (product suggestion). Otherwise, the endpoint isn’t much good for anything at the end of a long CAT6 run since it can’t really power much on it’s own. And why wouldn’t the endpoint be designed to power up from an upstream midpoint using Alternate 2 power? Seems like that should be a built-in option. Alternately, how about a combination midpoint/endpoint with onboard terminating resistors that could be disabled by cutting traces if it wasn’t the last extender?

To make this story even more interesting, I’ve been experimenting with this hardware for about three months now. I was always aware of the “requirement” for an endpoint to terminate the CAT6 circuit, but in practice I discovered that it didn’t matter if an endpoint was the last device when connecting everything with the stock 3.3VDC arrangement. I never had any communication problems until voltage drop became an issue as I experimented with longer cable lengths. After I switched over to the alternate power method however, I discovered that the CAT6 bus ABSOLUTELY WILL NOT WORK without a powered endpoint to terminate the circuit. Other folks using these devices should keep this in mind if they find they need to convert to alternate power and weren’t being too particular about using endpoints.

Not to be too hard on you, Sparkfun, but your claims of: “In our testing using two EndPoints, four MidPoints, at least one Qwiic device on each node and over 200 feet of Ethernet cable, we were able to use all devices with nearly no signal integrity loss!” and “build ridiculously long, wired I2C circuits to your heart’s content!” and “create a vast sensor network in your home or office” seem to be just a bit optimistic. But if the endpoint had that buck regulator…maybe.

I’m also looking at how to use the Differential Midpoint and Endpoint in my I2C projects. By any chance, do you know if it’s possible to power the whole thing with +5 volts instead of 3.3V? I made a [post about it, but it seems you might have the same idea I did. The thing is, the endpoint module is revolved around 3.3V through the VCC net on their schematic. However, you could use 5 volts instead and everything would be fine, right? (and following the use of a midpoint, assuming that everything is powered by VCC_1, the midpoint would also be 5 volts if you don’t use the buck regulator)](Integrating Sparkfun's I2C Modules with Adafruit I2C Modules - SparkFun Electronics Forum)