I have a BME688 pimoroni breakout board that I cut the I2C trace on to get a 0x77 I2C address. During operation in isolation, it works just fine. When I hook it up to an I2C line with other components, like a BME280 addressed at 0x76, things get weird. At first there are no issues, and then eventually on the order of 2 - 20min, the BME280 readings go to a non-BME280 temperature reading (very slight variance, might be taking it from the BME688 0xFA-0xFC registers) and 0% humidity while the BME688 readings no longer exist (nor does the 0x77 address). During troubleshooting I noticed that when I remove the BME280, there is still a device on the I2C line under 0x76 and it’s the BME688. When I power cycle (unplug->replug) the BME688 it comes back in as 0x77. Is there a hardware issue with this board?
My SDO line is pulled up to 3.3V via the 47kOhm resistor on the board (verified never any dropouts on the 3.3V) and there is a clean cut at the I2C ADDR+1 trace. The issue only happens eventually when a BME280 at 0x76 is on the same I2C line. What could be wrong here? Nothing in the datasheet says there is any caveat to operating the device with that I2C address when it is operating at 0x77.
Picture since everyone loves a graph (BME280 warming up is an enclosure issue I need to resolve, the issue happens with the BME688 regardless of if I have a fan going):
This is indeed strange. Two possible issues (just speculating): maybe you have a thermal problem. Or, you have too many pullups on your I2C-line (well, it is not the count but the total R-value that can cause problems).
Can you please describe your complete setup? Are you operating this from a Pi? What BME280 breakout are you using?
Thermal problem realistically could be an issue, I will test again with a fan directly on the BME688 board for an hour and see how repeatable it is if it can sustain readings.
This is on a RPi CM4 with a dozen I2C devices but the total I2C bus resistance is 1.57kOhm (only I2C resistors being the RPi and BME688, verified measured). I also tested it with the BME280 and BME688 in isolation with each other so the other devices are a non-issue.
The BME280 board is one of the cheapo GY-BME280 (like this one), but the only issues with it until I connected it up with the BME688 was the typical first-read issues it gives.
The BME688 had issues where on first couple of reads it consistently does things like this in isolation that I had to fix with adding a 20sec delay after first read before logging it:
1.57kΩ is a very strong pullup on the I2C line (low resistance = strong pullup) at the end of the recommended range (rule of thumb: 1K to 10K). But this depends on many parameters. See section 6.5. of https://www.ti.com/lit/an/sbaa565/sbaa565.pdf?ts=1738300163482
You could hook up logic analyzer of oscilloscope to gain more insights.
The GY-BME280 is fine. I tested many of them in a large scale test and they perform very well. I have not found a single device outside of specs.
Some other thoughts: I also tested the BME688 and I think it is basically useless unless you want to detect decaying organic materials. As soon as you turn on the heater for gas measurements, you can throw away temperature and humidity readings. Without gas measurements, the sensor is as good as a much much cheaper BME280.
Otherwise, the BME280 is only fine if operated correctly, i.e. in on/off mode. Even with a MCU like the Pico powered by USB the readings will be wrong over time due to heat-creep. And the Pico will only draw 30mA compared to a CM4 with something like 300mA. Most of this is converted to heat and copper (wires) are a good thermal conductor.
Internal pullup on RPis is 1.8kOhm so not really much of a choice, only extra resistor I have on there is the BME688 since didn’t feel like cutting the traces on it.
Agreed that BME688 and most gas sensors are basically gimmicks but only in relation to deterministic gas testing, AQI, eCO2 readings; they are useful for temporal data at the very least.
Bosch has lost a lot of credibility with me dealing with these sensors. I am only forced mode with the BME280 every 1 sec and the sensor needing to be read twice on boot up with the first reading being bad shouldn’t be normalized. Readings have a good number of dropouts (temperature randomly dropping to negative, pressure offsetting down to ~700 hPa randomly) and the sensor going about its day happily is something I have no issue with on other manufacturers, the only thing Bosch wins out on is hobby market availability.
Regarding a solution to the issue, I just reset the i2c bus in software when it detects the BME688 getting lost or BME280 values drop out. Not ideal but it works. Also got to the point where the only way to manage it a bit more is to just go through the sensor setup on every single read. Although I can say “if the pressure drops out 30kPa in 1 second, reset”, the fact that it will continually push out bad data on different measurement lines until a reset occurs gets in the way of real life values if the sensor is planned for use in an environment spanning the entire measurement range.
