Hi everyone. I am having some trouble getting my Pimoroni Badger to consistently talk to the PiicoDev BME280 sensor board.
I have connected the piicodev BME280 sensor to the Pimoroni Badger via the Qw/ST connector. I am finding that the connection is very intermittent and I often (more often than not) get the following error:
PiicoDev could not communicate with module at address 0x77, check wiring
Traceback (most recent call last):
File "<stdin>", line 6, in <module>
File "PiicoDev_BME280.py", line 32, in __init__
File "PiicoDev_BME280.py", line 29, in __init__
File "PiicoDev_BME280.py", line 64, in _read16
OSError: [Errno 5] EIO
I am initialising the sensor with the following micropython:
sensor = PiicoDev_BME280(sda=4, scl=5, iir=1)
as per:
I am confident that there is not an obvious issue with the address etc as it does sometimes work and I have tested and can confirm the presence of the sensor at 0x77.
I am fairly new to i2c programming and would appreciate any ideas.
Thanks for including the error messages you got and confirming the code you were trying to run.
Can you send us a photo of how the BME280 is connected? Since it is working sometimes and not others it may be something small to do with the wiring and a second set of eyes may be able to spot it.
Otherwise, if we can’t spot anything simple there we may need to look into what the differences are between the Badger and the regular Pi Pico firmware.
Yes the badger is fantastic - it’s perfect for my project as it requires a cheap low power display that works in a bright environment. It’s also keeping me busy while I wait for supply chain issues with other boards to work themselves out.
That said, I haven’t seen any difference from adjusting the above settings as you suggested. I will keep looking. Just as way of proof of life I took the following photo as it’s decided to work again - don’t you just love intermittent bugs?!
The scan code works every time and I have included it into my fork of PiicoDev_Unified.py now.
That can happen if the connector is wobbled. If the device is going to be moved around during use, it might be best to use the solderable breakouts.
Or, wrap the request with Try & Except so that you can catch the intermittent error and then re-initialise the sensor before trying again (to be on the safe side).
I’ve confirmed the bug and havent got a working solution at the moment, still working through some possible workarounds
EDIT: It looks like this one might be a bit deeper Andrew! Redefining the I2C through the Unified library leads to some unexpected results on the RP2040, an issue on GitHub has been raised and we’ll update you when we have a solution!