Hmm sounds like the pull up might still be the problem. 3.3V also means less current to sink to properly pull down the signal line, both through the pull-up and the lower charge on the cable capacitance.
50k to 65k sounds a little excessive. :) Never seen anything on I2C bus that high. I'm wondering if those values are for the other GPIO's. I get 1.8k from here and I've seen other specs saying the same.
Interesting. Well, 50-65k are not realy excessive, they provide some kind of pull-up, but won't overpower devices with very little pull-down capability, so it sounds like a compromise between having at leat A pull-up, while also having compatibility with weak devices. Maybe those 50-60k are the on-chip resistors and 1.8k are external on the board, that could make sense. Something to learn every day !50k to 65k sounds a little excessive. :) Never seen anything on I2C bus that high. I'm wondering if those values are for the other GPIO's. I get 1.8k from here and I've seen other specs saying the same.
Another thing: could you provide a picture or circuit diagram of the important VCC, GND, SDA, SCL lines from the PI to the PCA9507 ? I just read in the PCA9507's datasheet (first page), that you can't combine several PCA9507's A sides together, because the voltage offsets would interfere with the I2C bus' operation.
Here is the schematic of the Bus expander (the 4th channel is missing but it's the same)
I realized something, that I didn’t notice before: you have several components that provide I2C extension. Maybe I should have read more carefully or you could have stressed this a bit more.
Thank you @Sral for all your help!
That's clear enough, thanks.
Yeah maybe 50+k is better than 1.8k for I2C, that's above my pay grade. :) I've seen others complain about them being so low as well so still thinking they are 1.8k but can't be certain now, thanks. I searched that page you linked which is official and no mention of 1.8k or any other values.
I'm not trying to bring you down but It looks like you're working on a fairly large project, if you're planning to run 18 I2C devices you might need to rethink things. A few years ago I wanted my controller to expand to large levels and went down the road you are heading on and for me it didn't end well. I attempted to make it work for months, even went to the expense of getting lots of PCB's made. I tried a few buffers, the pca9507 was the best. Running multiple pca9507 like you are I was able to successfully run 22-24 devices with about 100 feet USB cable total but it wasn't reliable. Even with only a few devices connected it wasn't perfect. I hate to say it and I hated to read it when I was doing this, it's just not possible if you need reliability. For any chance of it working you would have to code a strong CRC check and figure out how to handle the bus locking up.
Hi Rob,I'm not trying to bring you down but It looks like you're working on a fairly large project, if you're planning to run 18 I2C devices you might need to rethink things. A few years ago I wanted my controller to expand to large levels and went down the road you are heading on and for me it didn't end well. I attempted to make it work for months, even went to the expense of getting lots of PCB's made. I tried a few buffers, the pca9507 was the best. Running multiple pca9507 like you are I was able to successfully run 22-24 devices with about 100 feet USB cable total but it wasn't reliable. Even with only a few devices connected it wasn't perfect. I hate to say it and I hated to read it when I was doing this, it's just not possible if you need reliability. For any chance of it working you would have to code a strong CRC check and figure out how to handle the bus locking up.
Bottom line is you need to look at other protocols such as RS-485 or CAN bus. If you really want to keep going look at the PCA9615 to split the I2C signals into differential signals, personally I haven't used this as I finally came to accept this isn't the route a person should be taking but this does sound like the best bet.
Here's a good article explaining how differential signals works.
An Introduction To Differential I²C
A few weeks back, we talked about the no-nos of running I²C over long wires. For prototyping? Yes! But for a bulletproof production environment, this practice just won’t make the cut. This mo…hackaday.com
Here's a pic with most of the stuff connected, I had 8 AC power bars connected as well at one point. All that and more went in the trash. :(
yes, at that scale go plc/scada for industrial setup, or home lab type setup with x96 and cat5/6.I'm not trying to bring you down but It looks like you're working on a fairly large project, if you're planning to run 18 I2C devices you might need to rethink things. A few years ago I wanted my controller to expand to large levels and went down the road you are heading on and for me it didn't end well. I attempted to make it work for months, even went to the expense of getting lots of PCB's made. I tried a few buffers, the pca9507 was the best. Running multiple pca9507 like you are I was able to successfully run 22-24 devices with about 100 feet USB cable total but it wasn't reliable. Even with only a few devices connected it wasn't perfect. I hate to say it and I hated to read it when I was doing this, it's just not possible if you need reliability. For any chance of it working you would have to code a strong CRC check and figure out how to handle the bus locking up.
Bottom line is you need to look at other protocols such as RS-485 or CAN bus. If you really want to keep going look at the PCA9615 to split the I2C signals into differential signals, personally I haven't used this as I finally came to accept this isn't the route a person should be taking but this does sound like the best bet.
Here's a good article explaining how differential signals works.
An Introduction To Differential I²C
A few weeks back, we talked about the no-nos of running I²C over long wires. For prototyping? Yes! But for a bulletproof production environment, this practice just won’t make the cut. This mo…
Here's a pic with most of the stuff connected, I had 8 AC power bars connected as well at one point. All that and more went in the trash. :(
Thanks for the kind words, working on bringing back that GUI. :) For the DHT22 you can run a python script like this, if you edit it so only the humidity is saved to the file you can import it in reef-pi using the file driver. If you can get away from I2C its best, I know it's tempting though with 2 wires vs 16.
pimylifeup.com
Thank you Rob, I'll give it a try :)Thanks for the kind words, working on bringing back that GUI. :) For the DHT22 you can run a python script like this, if you edit it so only the humidity is saved to the file you can import it in reef-pi using the file driver. If you can get away from I2C its best, I know it's tempting though with 2 wires vs 16.
How to Set Up a Humidity Sensor on the Raspberry Pi
Great for monitoring both temperature and humidity.
Well, judging from the Atlas Instrument datasheet, which gives some Information on working principle and calibration, I would hazard the guess that it’s similar to pH, e.g. that the „mid-value“ is supposed to be 0mV, corresponding to the ORP value of silver chloride. That probably needs to have a value of zero, but I’m not completely sure about that.
Exactly, a high resolution volt meter. The other day someone told me after running it along side his other good meter it's bang on. Heard this many times now. :) I've never tested it for ORP but a while ago someone told me to add an extra resistor and it would work with ORP so I've actually revised the board since you got yours, it's even smaller now. Currently it has a solder jumper to activate the extra resistor for ORP. I haven't really tested it yet but I bought a cheap ORP probe and some 225mV calibration solution. I don't really know how to test it properly so I'm just going to see how close it is to 225mV, figures crossed. :)
