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.