Difficulty logging from BME280 with v1.11

[adamgarbo]

Subject of the issue

Hey @PaulZC, I've noticed that my OLA is having a hard time logging data from a SparkFun Qwiic BME280. I recently left it logging for a couple of weeks and discovered that no data was actually recorded. It's been a while since I've worked with the OLA, and wasn't sure if v1.11 (and v2.x of the Apollo3 Core) introduced some quirks that I may not be aware of.

Your workbench

• Are you using a microSD card? If so, what size? How is it formatted (FAT, FAT32, or exFat)?
  • 32 GB FAT32
• At what frequency are you logging? For example, 10Hz, 1Hz, once every 5 seconds, etc.
  • 10 s
• What version of firmware are you using? This is shown at boot, for example: "Artemis OpenLog v1.10"
  • v1.11
• How is OpenLog Artemis wired to your sensor(s)?
  • Qwiic cable
• How is everything being powered?
  • 4.2V LiPo
• Are there any additional details that may help us help you?
  • I tested both enabling/disabling power to the Qwiic bus between measurements

Steps to reproduce

• Connect BME280
• Configure OLA to record once every 10 seconds
• Disconnect USB-C and press reset button to create a new log file.

Expected behaviour

• Data should be logged.

Actual behaviour

• Sensor is detected:
  Autodetect complete
PHT-BME280 online at address 0x77

• The collected data (see below) looks to just be the default values from the registers or whatever was in memory.

• It seems that the sensor is read from correctly while connected to Serial Monitor, but no dice when not connected to Serial.

• Logging also doesn't work when disabling power to Qwiic bus while connected to Serial Monitor:
  1) Turn off Qwiic bus power between readings (>2s): Yes

• I suspect that there may be a simple solution and there's something I've missed (or forgotten)!

rtcDate,rtcTime,VIN,pressure_Pa,humidity_%,x,temp_degC,count,
11/28/2021,11:50:59.73,3.99,71554.79,94.99,2839.12,19.66,18400,
11/28/2021,11:51:09.73,3.99,71554.79,94.99,2839.12,19.66,18401,
11/28/2021,11:51:19.74,3.98,71554.79,94.99,2839.12,19.66,18402,
11/28/2021,11:51:29.74,3.99,71554.79,94.99,2839.12,19.66,18403,
11/28/2021,11:51:39.74,3.98,71554.79,94.99,2839.12,19.66,18404,
11/28/2021,11:51:49.72,3.99,71554.79,94.99,2839.12,19.66,18405,
11/28/2021,11:51:59.72,3.99,71554.79,94.99,2839.12,19.66,18406,
11/28/2021,11:52:09.72,3.99,71554.79,94.99,2839.12,19.66,18407,
11/28/2021,11:52:19.73,3.98,71554.79,94.99,2839.12,19.66,18408,
11/28/2021,11:52:29.73,3.98,71554.79,94.99,2839.12,19.66,18409,
11/28/2021,11:52:39.73,3.98,71554.79,94.99,2839.12,19.66,18410,
11/28/2021,11:52:49.73,3.98,71554.79,94.99,2839.12,19.66,18411,
11/28/2021,11:52:59.73,3.99,71554.79,94.99,2839.12,19.66,18412,
11/28/2021,11:53:09.73,3.99,71554.79,94.99,2839.12,19.66,18413,
11/28/2021,11:53:19.73,3.99,71554.79,94.99,2839.12,19.66,18414,
11/28/2021,11:53:29.72,3.98,71554.79,94.99,2839.12,19.66,18415,
11/28/2021,11:53:39.72,3.98,71554.79,94.99,2839.12,19.66,18416,
11/28/2021,11:53:49.72,3.98,71554.79,94.99,2839.12,19.66,18417,
11/28/2021,11:53:59.72,3.99,71554.79,94.99,2839.12,19.66,18418,

[adamgarbo]

Hi @PaulZC,

Here's some sample output when disabling power to I2C. The BME280's LED turns on and off, but my suspicion is that the sensor isn't initializing fully. Adjusting the minimum power-up delay doesn't appear to have any effect.

13:58:51.693 -> rtcDate,rtcTime,VIN,pressure_Pa,humidity_%,temp_degC,count,
13:58:51.764 -> 12/09/2021,13:59:18.17,5.23,31792.82,0.00,21.15,1,
13:58:51.872 -> ⸮12/09/2021,13:59:18.59,5.24,71723.91,95.17,19.66,2,
13:58:52.289 -> ⸮12/09/2021,13:59:23.58,5.24,71554.79,94.99,19.66,3,
13:58:57.301 -> ⸮12/09/2021,13:59:28.58,5.24,71554.79,94.99,19.66,4,
13:59:02.300 -> ⸮12/09/2021,13:59:33.58,5.24,71554.79,94.99,19.66,5,
13:59:07.308 -> ⸮12/09/2021,13:59:38.57,5.24,71554.79,94.99,19.66,6,
13:59:12.268 -> ⸮12/09/2021,13:59:43.57,5.24,71554.79,94.99,19.66,7,
13:59:17.282 -> ⸮12/09/2021,13:59:48.57,5.24,71554.79,94.99,19.66,8,
13:59:22.294 -> ⸮12/09/2021,13:59:53.58,5.24,71554.79,94.99,19.66,9,
13:59:27.343 -> ⸮12/09/2021,13:59:58.58,5.24,71554.79,94.99,19.66,10,
13:59:32.284 -> ⸮12/09/2021,14:00:03.58,5.23,71554.79,94.99,19.66,11,
13:59:37.282 -> ⸮12/09/2021,14:00:08.58,5.24,71554.79,94.99,19.66,12,
13:59:42.304 -> ⸮12/09/2021,14:00:13.58,5.24,71554.79,94.99,19.66,13,
13:59:47.288 -> ⸮12/09/2021,14:00:18.58,5.24,71554.79,94.99,19.66,14,
13:59:52.301 -> ⸮12/09/2021,14:00:23.59,5.24,71554.79,94.99,19.66,15,

[PaulZC]

Hi Adam (@adamgarbo ),

I'm beginning to suspect this is linked to the mux detection code. The BME280's address is 0x76 or 0x77 and that's mux territory...

Can you please try changing the split pads to change the board's address to 0x76 and see if that's makes a difference?

Why? I added some extra code to testMuxDevice for 0x76 to allow the MS5637 / MS5837 / MS8607 to be detected before attempting to detect a mux. The same code should also detect the BME280 and prevent multiplexerBegin from being called. I think it might be the multiplexerBegin which is causing the problem.

For 0x77, testMuxDevice always does a multiplexerBegin. multiplexerBegin does some writing and reading to check if a mux is connected and maybe that sometimes confuses the BME280 so it fails to be detected?

If my hunch is correct, the solution will be to replicate these lines in the case 0x77.

Thanks!
Paul

[adamgarbo]

Hi Paul,

I think you hit the nail on the head! I didn't have access to my soldering iron to change the I2C address, so I went ahead and added the code you mentioned and uploaded new firmware.

I did a quick test with power to the Qwiic bus being disabled between measurements at a logging rate of 10 seconds. So far, so good!

Cheers,
Adam

11:05:24.990 -> rtcDate,rtcTime,pressure_Pa,humidity_%,altitude_m,temp_degC,count,
11:05:25.167 -> 12/13/2021,11:05:56.21,100224.05,30.79,92.05,22.41,276,
11:05:25.673 -> 12/13/2021,11:05:56.71,100256.27,30.61,89.81,22.28,277,
11:05:36.013 -> 12/13/2021,11:06:07.05,100252.97,30.23,89.39,22.12,278,
11:05:45.970 -> 12/13/2021,11:06:17.03,100240.27,30.07,90.69,22.08,279,
11:05:55.987 -> 12/13/2021,11:06:27.04,100247.43,29.93,90.55,22.01,280,
11:06:05.982 -> 12/13/2021,11:06:37.04,99695.36,73.79,136.55,25.37,281,
11:06:15.996 -> 12/13/2021,11:06:47.04,100354.34,84.14,81.58,24.72,282,
11:06:25.997 -> 12/13/2021,11:06:57.04,99886.42,89.08,119.98,26.97,283,

Cheers,
Adam

[adamgarbo]

Whoops, forgot to include the code I added to autoDetect.ino:

    case 0x77:
      {
        //Ignore devices we've already recorded. This was causing the mux to get tested, a begin() would happen, and the mux would be reset.
        if (deviceExists(DEVICE_MULTIPLEXER, i2cAddress, muxAddress, portNumber) == true) return (DEVICE_MULTIPLEXER);

        qwiic.beginTransmission((uint8_t)i2cAddress);
        qwiic.write((uint8_t)0xA0);
        uint8_t i2c_status = qwiic.endTransmission();

        if (i2c_status == 0) // If the I2C write was successful
        {
          qwiic.requestFrom((uint8_t)i2cAddress, 2U); // Read two bytes
          uint8_t buffer[2];
          for (uint8_t i = 0; i < 2; i++)
          {
            buffer[i] = qwiic.read();
          }
          if ((buffer[0] != 0xA0) || (buffer[1] != 0xA0)) // If we read back something other than 0xA0A0 then we are probably talking to an BME280, not a mux
          {
            return (DEVICE_PHT_BME280);
          }
        }

        
        //Confidence: Medium - Write/Read/Clear to 0x00
        if (multiplexerBegin(i2cAddress, qwiic) == true) //Address, Wire port
          return (DEVICE_MULTIPLEXER);
      }
      break;

[PaulZC]

Thanks for reporting @adamgarbo - corrected in v2.1
Best wishes,
Paul