something like this: | adafruit | Page 1

midnight bobcat Sep 10, 2025, 6:53 PM

#

That makes sense here, as that is where they are connected, TY for clarity.

eager lotus Sep 10, 2025, 6:57 PM

#

so once you get the i2c initialized,

# ...
import busio, adafruit_scd4x, adafruit_bme680, adafruit_scd4x
from adafruit_pm25.i2c import PM25_I2C

i2c = busio.i2c(mySCL, mySDA)
pm25 = PM25_I2C(i2c, reset_pin)
bme680 = adafruit_bme680.Adafruit_BME680_I2C(i2c)
scd4x = adafruit_scd4x.SCD4X(i2c)
# ...

midnight bobcat Sep 10, 2025, 7:00 PM

#

eager lotus so once you get the i2c initialized, ```python # ... import busio, adafruit_scd4...

Thanks! I figured I'd thread this to keep it out of main chat.

#

And Yeah, I only put in the frequency thing because it was in the example code, I wasn't sure what to make of it...

eager lotus Sep 10, 2025, 7:02 PM

#

Normally you only have one I2C bus. You can, on some controllers, have more, but then each one has another pair of pins (for SDA/SCL) and you have to keep track of which "bus" each of your target devices is riding

midnight bobcat Sep 10, 2025, 7:02 PM

#

I have all 3 devices on GP4, and GP5 in this case.

eager lotus Sep 10, 2025, 7:05 PM

#

midnight bobcat And Yeah, I only put in the frequency thing because it was in the example code, ...

100K is (ususaly?) the default frequency, so you can leave that off. You can optionally set it faster - typically 200K or 400K - BUT not all I2C devices support higher speeds. And it can make things less reliable, especially for longer distance I2C chains.

midnight bobcat Sep 10, 2025, 7:06 PM

#

Yes, I would like to keep this as RELIABLE as possible, if I just omit the frequency line, what is the default behavior? Does it just go with the fastest frequency that all devices on the bus will handle?

#

Or the slowest?

eager lotus Sep 10, 2025, 7:09 PM

#

midnight bobcat I have all 3 devices on GP4, and GP5 in this case.

That's usually how it's down. I have had to use multiple I2C buses a few times though - some I2C target devices don't play well together so I had to keep them separate (although I still had several I2C targets on each bus)

eager lotus Sep 10, 2025, 7:10 PM

#

midnight bobcat Or the slowest?

Default should be 100K, which is the slowest and should be the most reliable. Probably. Don't quote my on that, but I think that's the way it is.

midnight bobcat Sep 10, 2025, 8:45 PM

#

Darn it, maybe frequency is a thing for the PM 2.5 sensor, after a few minutes I get this error: Unable to read from sensor, retrying

eager lotus Sep 11, 2025, 2:19 AM

#

That could be the sensor, or loose wiring, or ... ??? I'm not quite up to guru status on I2C, but I've done quite a bit (especially including C/C++ embedded stuff) and I don't recall anything unable to keep up with 100K. However, you can run it slower - shouldn't hurt anything to try 50K and see if it helps.

#

Also be aware that AFAIK those air quality sensors aren't meant to be continuously "polled", and if you read it to frequently (regardless of the I2C frequency) it might cause problems?

eager lotus Sep 11, 2025, 2:40 AM

#

Some I2C devices which take a while to complete a "reading" have drivers which let you take things one step at a time, i.e. start the measurement, check if it's complete/ready, then read the results. This lets you get updates fairly close to as fast as the device is capable of providing, without being stuck and blocking everything else (like your beautifully blinking NeoPixels) while waiting for the whole cycle to complete. I don't see anything like that in adafruit_pm25 though. But given how similar "slow" devices work, along with "The I2C data stream updates once per second" on the PMSA003I Air Quality Breakout product page, I wouldn't be surprised if calling read() more than once a second on an adafruit_pm25.i2c.PM25_I2C could get it confused. Maybe leave the I2C at 100K, but try reading the PM2.5 sensor once every 2 seconds (or maybe even slower - some of the stats will take longer to stabilize)

#something like this: