BME280 failing to initialize after spikes in readings

[gogopotato]

Hi all!

I am using a Pro Mini clone (3V3, 8Mhz) with a BME280 sourced from ebay. It's got I2C interface and no SPI. When I first set this up it worked fine for about 12 hours. Then suddenly it would begin to get massive spikes in TEMP & HUM readings like over -200 F and 100% RH, where normal readings are typically ~70 F and ~35% RH.

Here's a picture of my BME280 sensor:

So I reset the arduino and now it's failing to initialize the BME280. Thought maybe the sensor died so I replaced it with another unit. But it too is failing to initialize. As for the power, I tried using both a breadboard power supply as well as two AA batteries connected in series w/ a 3V3 boost up module.

Similar spikes happened a couple of time before and normally a reset would make the readings return to normally. But now I am unable to initialize the sensor. Could this be power related? Or do I have a faulty arduino or sensor?

Here's my code (it's a simplified version of a code uploaded by another user here. I forgot his/her username...):

// Enable debug prints to serial monitor
#define MY_DEBUG

// Enable and select radio type attached
#define MY_RADIO_NRF24
 
// Hard-coding sensor node ID
#define MY_NODE_ID 11 

#include <SPI.h>
#include <MySensors.h>
#include <Adafruit_Sensor.h>
#include <Adafruit_BME280.h> // Change I2C address in Adafruit_BME280 library to "0x76" (line 32 in the library file)
#include "Wire.h"

Adafruit_BME280 bme; // I2C

#define CHILD_ID_HUM 0
#define CHILD_ID_TEMP 1

MyMessage msgT1(CHILD_ID_TEMP, V_TEMP);
MyMessage msgH1(CHILD_ID_HUM, V_HUM);

void presentation()
{
  sendSketchInfo("Nursery", "1.0");
  present(CHILD_ID_TEMP, S_TEMP);
  present(CHILD_ID_HUM, S_HUM);  
}

void setup()
{
  delay(5000);// just in case
  if (!bme.begin())
   {
    Serial.println("BME280 initialization failed!");
    while (1);
   }
  else Serial.println("BME280 initialization success!");
  ServerUpdate(); // for first data reading and sending to controler
}

void loop()
{ 
   smartSleep(60000);
   ServerUpdate();   
}

void ServerUpdate() // used to read sensor data and send it to controller
{
  double T, P, H;
  T=bme.readTemperature() * 9 / 5 + 32; // convert default Celcius reading to Fahrenheit
  H=bme.readHumidity();
  
      send(msgT1.set(T, 1));
      send(msgH1.set(H,1));
      
#ifdef MY_DEBUG
      Serial.print("T = \t"); Serial.print(T, 1); Serial.print(" degC\t");
      Serial.print("H = \t"); Serial.print(H, 1); Serial.print(" percent");
#endif
}

[DavidZH]

I have the same module, and I initially had issues to get it going.

What I did: I set the BME to single measure mode in the setup with this subroutine:

void startBME()
{
  BME.settings.commInterface = I2C_MODE;
  BME.settings.I2CAddress = BMEaddr;
  BME.settings.runMode = 1;            //  1, Single mode
  BME.settings.tStandby = 0;           //  0, 0.5ms
  BME.settings.filter = 0;             //  0, filter off
  BME.settings.tempOverSample = 1;
  BME.settings.pressOverSample = 1;
  BME.settings.humidOverSample = 1;  
  
  BME.begin();
}

And next to that I call BME.begin(); every time the sensor is read.

Nice and simple sketch by the way!

[gogopotato]

@DavidZH Thanks for your input.

So am I calling BME.begin() for each sensor reading within the loop, and your startBME() is called only once during setup? Would the sensor remember the config values set during startBME() after waking up from the sleep? As I understand the power to the sensor is cut during the sleep... maybe I'm mistaken.

Also, can you please show me how you defined I2C_Mode and BMEaddr? Looks like it's part of a different BME280 library.

Thanks!

[DavidZH]

Yes. Correct. call BME.begin() every time and the subroutine only at the beginning.

And you are also correct about the library. I use the "blue" lib, from Sparkfun. As i can recall correct (it's been over a year since I built the damn thing) I have tried both, and found the Sparkfun more stable.

And you CAN switch off power for this module, but after conversion it goes to sleep and uses less than 1uA. Hardly worth the effort, because the current can find a way over the data lines, and that's a pain in the behind to solve (I tried!).