4 pin GY-BME280 sensor I2C

[Hans Braakmann]

Today I tested my new 4 pin GY-BME280 sensor. In the Arduino IDE when I scan for it's I2C address I get 0x76 as response. When I scan for the sensors I2C address from within Microblocks it returns nothing and breaks the MicroBlocks connection so I have to reconnect my USB connection. Below the response from the Arduino Serial monitor.

‌

[John Maloney]

I'm guessing Arduino and MicroBlocks may be using different pins for I2C.

What board are you using? To which pins are you connecting SDA and SCL?

Also, could provide a link to the Arduino test program you are using?

[Hans Braakmann]

Im using a Raspberry Pi Pico/W on a Mac Book Air 15” with pin GP4 (SDA) and pin GP5 (SCL). The Link for the I2C scanner.

The website: https://randomnerdtutorials.com/solved-could-not-find-a-valid-bme280-sensor/

[John Maloney]

Thanks. I think those are the correct pins. I'll investigate...

[Hans Braakmann]

The Adafruit Arduino BME280 Library has a I2C test file. This test file doesn’t recognize the GY-BME sensor. The above test script from randomnerdtutorials does recognize the sensor at 0x76 .

[Hans Braakmann]

When following this explanation I get relevant readings from the GY-BME280 sensor. LINK

‌

[John Maloney]

I did a quick test with a different I2C board and I'm seeing the same failure mode that you report -- board becomes unresponsive. Sorry that I didn't think it was a MicroBlocks bug at first! I'll investigate...

[John Maloney]

Looks like I2C sensor I used to test may itself have been defective. I tested with an I2C OLED display and GP4 (SDA) and pin GP5 (SCL) and that works perfectly.

Try decreasing the i2c speed to normal speed. MicroBlocks normally runs i2c at 400 kHz ("fast mode") since nearly every i2c device we use supports that but it's possible your BME280 chip needs the slower 100 kHz speed. You can use this block to change speed:

This block is in the Other/System/sensorPrims library but you can add it to your project just by saving the .png file and then dropping onto the MicroBlocks editor. (That will load the library automatically.)

Hope that solves it...

[Hans Braakmann]

Thank you for the quick response, I tried your suggestion but it didn’t work. I get the same response [no bme or bmp connected]. And yes the OLED works fine. 🥴

[John Maloney]

Well, this is quite a mystery!

Something must be different between the Arduino I2C code that is working and the MicroBlocks code. It is interesting that one version Adafruit Arduino code also fails:

The Adafruit Arduino BME280 Library has a I2C test file. This test file doesn’t recognize the GY-BME sensor.

On my end, I tested with the bare Pico-W board that is not plugged into any sort of expansion module with the latest pilot firmware, v233. I am using GP4 = SDA and GP5 =SCL. I've tested two known-good I2C sensors and both work with that configuration. A third I2C module I tried failed, but that module requires 5v power to work. (It worked with another board that has a 5v pin.)

Since your board is working on 3v with at least one Arduino program, I don't think it requires 5v to work (the specs say it works on either 3v or 5v but specs can be wrong).

Could you provide a direct link to the Arduino code that works? It must be doing something a little differently than MicroBlocks or the Adafruit Arduino code that doesn't work.

[John Maloney]

By the way, here is an i2c scanner script in MicroBlocks:

That may be a quick way to see if the sensor is detected or not. If it sees the sensor it will show it's i2c address (in decimal).

[Hans Braakmann]

Thanks, I often used the Microblocks I2C scanner code without any result on the 6-pin and 4-pin GY-BME 280 sensor. For me the standard Arduino Adafruit BME 280 library does not work. This library returns [no BME 280 found]. What works for me is what I described in the links above. You first have to manually install the Adafruit Unified Sensor Driver in the Arduino libraries folder. Run the scanner code to check if I2C is available, which I my case returns I2C channel (0x76). Then run this code below to get reasonable sensor data from the GY-BME 280 sensor.

/*
   BME280 Test Program

   Connect I2C interface to BME280
        SCL connects to A5 or dedicated SCL pin
        SDA connects to A4 or dedicated SDA pin
   Connect BME280 Vcc to 3.3 or 5V and GND to ground
   Need to install library Adafruit_BME280
   Need to manually install library Adafruit_Sensor
*/
#include <Adafruit_Sensor.h>
#include <Adafruit_BME280.h>
#include <Wire.h>

float temperature;
float humidity;
float pressure;
float altitude;

float const ALTITUDE = 81.0;              // Altitude at my location in meters
float const SEA_LEVEL_PRESSURE = 1013.25; // Pressure at sea level

Adafruit_BME280 bme; // I2C

//===============================================================================
//  Initialization
//===============================================================================
void setup(void) {

  Serial.begin(9600);
  Serial.println("Reading sensor");

  bool status;

  // default settings
  status = bme.begin(0x76);  // The I2C address of the sensor is 0x76
  if (!status) {             // Loop if sensor not found
    Serial.print("Error. Check Connections");
    while (1);
  }
}
//===============================================================================
//  Main
//===============================================================================
void loop() {

  getPressure();   // Get sensor data and print to serial monitor window
  getHumidity();
  getTemperature();
  getAltitude();

  delay(2000);     // Update readings every 2 seconds
}
//===============================================================================
//  getTemperature - Subroutine to get and print temperature
//===============================================================================
void getTemperature()
{
  temperature = bme.readTemperature();
  temperature = temperature * 9 / 5 + 32; // Convert C to F
  String temperatureString = String(temperature, 1); // One decimal position
  Serial.print("Temperature: ");
  Serial.print(temperatureString);
  Serial.println("F");
}
//===============================================================================
//  getHumidity - Subroutine to get and print humidity
//===============================================================================
void getHumidity()
{
  humidity = bme.readHumidity();
  String humidityString = String(humidity, 0);
  Serial.print("Humidity: ");
  Serial.print(humidityString);
  Serial.println("%");
}
//===============================================================================
//  getPressure - Subroutine to get and print pressure
//===============================================================================
void getPressure()
{
  pressure = bme.readPressure();
  pressure = bme.seaLevelForAltitude(ALTITUDE, pressure);
  pressure = pressure / 3386.39;    // Convert hPa to in/Hg
  String pressureString = String(pressure, 2);
  Serial.print("Pressure: ");
  Serial.print(pressureString);
  Serial.println("in");
}
//===============================================================================
//  getAltitude - Subroutine to get and print temperature
//===============================================================================
void getAltitude()
{
  altitude = bme.readAltitude(SEA_LEVEL_PRESSURE);
  altitude = altitude * 3.28084;  // Convert meters to feet
  String altitudeString = String(altitude, 0);
  Serial.print("Altitude: ");
  Serial.print(altitudeString);
  Serial.println("ft");
}

‌

[Hans Braakmann]

My temporary solution for the GY-BME 280 sensor. First disconnect USB then connect OLED I2C screen and search for its I2C address. (60) Then connect the GY-BME 280 sensor and again scan for the sensors I2C address, in my case it returns (118). Now Microblocks recognises this sensor and you can collect temp, hum and pressure data. Don’t ever disconnect the USB-connection or you have to start from the beginning…=> disconnect USB, connect OLED…etc…

‌

[John Maloney]

There seems to be something strange about those GY-BME 280 sensor clones; they are clearly not 100% compatible with the original Bosch BME 280. They may be initially powered down in a way that makes them not respond to a scan. However, something that is done by Adafruit Unified Sensor Driver code or by your process of first searching for the OLED I2C screen seems to work around the issue.

I wonder if you actually need to have the OLED connected for your work-around to be effective? Maybe the trick is to that you must do a scan on the I2C bus (with any I2C device connected to provide pull up resistors) before plugging in the GY-BME 280.

If you want to dig deeper, you might use a multimeter or logic analyzer to look at the voltage on the I2C pins right after plugging in the USB cable (i.e. board just powered up) and then after running an I2C scan. You should probably do this with the OLED display plugged in, since that is what you do for your work-around.

With the OLED plugged in, I'd expect to see a high voltage level both before and after running the scan due to the pullup resistors in the OLED display.

You could then do that same sequence with a GY-BME 280 plugged in along with the OLED display. You should see the same voltages but it would be a big clue if you did not.

A final test would be the same sequence with only the GY-BME 280 plugged in. If either the clock or data line gets stuck in a low state that would indicate a problem.

No worries if you don't have a meter or don't want to bother with these tests. In any case, I think this is clearly a problem with the GY-BME 280 sensors, not with MicroBlocks. (The fact that it doesn't work with the standard Arduino program supports that theory.)

If we can find a work-around I'd be happy to add it to the BME 280 sensor library. (I took a quick look at the Adafruit Unified Sensor Driver but that's a big piece of code and I didn't immediately see anything helpful.)

[Hans Braakmann]

John, thank you for the helpful suggestions. I did check them all and more. There were no strange voltage values across the I2C pins. I also checked all my wiring, which seems to be around 50 ohms for the wires. I have used multiple I2C devices to try to get the GY BME 280 running, but only when the OLED display is connected to Microblocks does it return a valid I2C address for the sensor. So, I am back to where I started with the strange behavior of the GY BME 280 sensor. I still don't know if it is a hardware or software issue? I made some progress by taking the next steps.

• I breadboarded only the GY BME sensor without a USB connection to my computer.
• Then, I made the USB connection with MicroBlocks. MicroBlocks did not return the green USB connection.
• I repeated this process, but now with VCC and GND disconnected, and now the MicroBlocks connection is made, and the USB connection turns green.
• Then, I connected the VCC and GND of the sensor, and voila! At last, the GY BME 280 sensor is recognized. I tried this with different GY BME 280 sensors, and they all worked.

My conclusion: connect the sensor without VCC and GND connected, then connect USB to the computer and start MicroBlocks, and finally connect the sensor's VCC and GND. Again, whether this is a hardware or software issue, I really don't know. I have ordered an Adafruit BME 280 sensor, so this story will be continued.

‌

[John Maloney]

These symptoms point to an i2c bus handling issue. In particular, if the GY BME sensor holds the clock line low indefinitely then it will not only prevent I2C communication, it will also hang the processor. That would explain why you don't get the green USB connection.

However, I'm puzzled about two things:

1. Why does it work with the Adafruit Unified Sensor Driver but not the standard Arduino Adafruit BME 280 sensor library?
2. Why does it work if you connect the GY BME sensor after doing a bus scan for the OLED display?

If you power up the board with both the GY BME sensor and the OLED display connected, can the MicroBlocks IDE connect to the board (i.e. USB connection turns green)? If so, you might try doing a I2C reset (an "all call" command):

Then do a bus scan to see if the GY BME responds. If that works, it could be used as a workaround.

I'm glad you are getting an Adafruit BME 280 sensor to test. That will give us some additional information.

[Hans Braakmann]

This “If you power up the board with both the GY BME sensor and the OLED display connected, can the MicroBlocks IDE connect to the board (i.e. USB connection turns green)? If so, you might try doing a I2C reset (an "all call" command)” also seems to work as a workaround.

‌

[John Maloney]

That's good to know. Maybe that's what the Adafruit Unified Sensor Driver is doing.

[John Maloney]

I've built two VM's to test, if you're willing.

The first one disables the OLED startup code, which I think might be the reason the Pico is hanging on startup when the GY BME is connected.

https://microblocks.fun/mbtest/tmp3/vm_pico-w_noOLED.uf2

The second one has the OLED startup code enabled, but adds a 50 millisecond wait before it tries to access the I2C bus. The hypothesis is that the GY BME chip needs some time to fully power up and become stable before the I2C bus can be used.

https://microblocks.fun/mbtest/tmp3/vm_pico-w_50msecs.uf2

You can install these virtual machines by holding down the BOOT SEL button on the Pico while plugging in the USB cable, then dragging the .uf2 file to the RPI-RP2 USB drive that appears.

In both cases, we want to see if the MicroBlocks IDE is able to connect to the board when the GY BME sensor is connected to the Pico when the Pico powered up (i.e. the USB cable is plugged in). You can try both with and without the OLED display connected. Ideally, it will work either way.

[Hans Braakmann]

I tested both VM’s and they both work with the GY BME 280 sensor fully connected. They also work with sensor and OLED display fully connected. Only when VM noOled.uf2 installed the TFT library doesn’t seem te work anymore. Which seems reasonable because TFT is not OLED. When VM 50msecs.uf2 installed the TFT library works fine. Today I will be testing the Adafruit BME 280 sensor on the Microblocks stable VM release.

[John Maloney]

Hooray! We are on the path to a MicroBlocks workaround!

when VM noOled.uf2 installed the TFT library doesn’t seem te work anymore

That is expected. The OLED display depends on the low-level TFT graphics primitives, which are disabled in the "noOLED" version.

Today I will be testing the Adafruit BME 280 sensor on the Microblocks stable VM release.

Great! I'll be curious to know if the Adafruit BME 280 board has the same issues as the GY BME 280. I realize that I've only tested the BME 280 sensor in the context of other boards; I've never tested one as the only I2C device connected to a Pico board.

[Hans Braakmann]

This issue of a 'hanging I2C bus' also applies to the TCS34725 color sensor. I think that's good news; we're making progress, and it deserves a 'Hooray!' x3. After installing the VM noOled.uf2, the TCS34725 sensor also works fine. I also tried the MAX30102 but accidentally switched VCC with GND, so it got fried. I'm still waiting for the Adafruit BME to arrive.

‌

[John Maloney]

We have a workaround, but I'd like to decrease the delay to minimize the Pico startup time. If you have the patience for a few more tests, could you try the following:

https://microblocks.fun/mbtest/tmp3/vm_pico-w_10msecs.uf2

https://microblocks.fun/mbtest/tmp3/vm_pico-w_20msecs.uf2

https://microblocks.fun/mbtest/tmp3/vm_pico-w_30msecs.uf2

I'm looking for the shortest delay that works with only the GY BME 280 connected. So, if the 10 msecs version works then you don't need to test the 20 and 30 msecs versions.

All of these have the TFT primitives enabled, so the TFT library should work when the OLED display is connected.

Thanks!

[John Maloney]

I also tried the MAX30102 but accidentally switched VCC with GND, so it got fried

Oh no! I'm sorry to hear that!

[Hans Braakmann]

I tested VM 10msecs, 30msecs and 50msecs, all three VM’s do not recognize the GY BME 280 and TCS34725 color sensor. The sensors are only found when the Oled display is fully connected. Update: When using VM noOled.uf2 the sensors works fine until I connect only the OLED display SDA and SCL channels (no VCC and GND) then sensors are no longer recognized. Connecting VCC and GND with the OLED re-established the sensor communication. I think there is an issue with the Oled display library connecting sensors to the Pico/W only works when OLED display is fully connected or you have to use the VM noOLED.uf2 with the sensors but then with a disconnected OLED Library.

‌

[John Maloney]

Thank you for doing those tests. I will keep the 50 millisecond wait in the code. That workaround will be in the next pilot release.

[Hans Braakmann]

John thank you for your help and support. Through this process of figuring things out I did learn a lot. If I were you regarding this GY BME 280 sensor I wouldn’t change anything in the VM Pilot release. It is not all clear regarding this sensor on what really is going on. As repo owner I leave it up to you on what to do. Keep you informed regarding the Adafruit sensor. Thanks again.

[John Maloney]

Just wanted to verify that:

https://microblocks.fun/mbtest/tmp3/vm_pico-w_50msecs.uf2

allows you to:

• use the GY BME 280 and the TCS34725 color sensor
• does not hang on power up when the GY BME 280 and/or TCS34725 color sensor are connected
• does not require that the OLED display be connected for the sensors to work
• however, the sensors also work when the OLED display is connected

In addition, that version also supports the TFT library if the OLED is connected to the board when it is powered up. (MicroBlocks only checks for the OLED display at power-up time).

In short, vm_pico-w_50msecs.uf2 allows you to work with the GY BME 280 and TCS34725 sensors more easily, right?

[Hans Braakmann]

It changes with the hour, reasonably I know what I am doing. The VM 50msec.uf2 only works in the same manner like the stable release VM. You have to disconnect VCC and GND => Open MicroBlocks => connect VCC and GND. The workings are now different from the previous days experimenting.

In short:

• Sensor standalone does not work anymore. Not in VM stable and 50msec.uf2. To get it working disconnect VCC and GND => Open MicroBlocks => lastly connect VCC and GND
• Sensor and OLED fully connected now works in the Stable MicroBlocks release.

I’m eager to test the Adafruit sensor, hope the sensor will arrive tomorrow.

‌

[John Maloney]

Thanks for checking again.

It appears that adding even a 50 msec delay does not work around the problem. Having the OLED attached does work around the problem, and that solution now works even in the stable MicroBlocks release. You don't need to disconnect VCC and GND for it to work, right?

[Hans Braakmann]

That’s right John.

[John Maloney]

If you happen to have a couple of resistors (2k to 10k), you might try connecting them between the SDA and SCL lines and VCC. Those might allow the board to start up with only GY BME 280 connected -- no OLED display.

[Hans Braakmann]

I already tried your suggestion with 10k and 4.7k ohm resistors. It had no success.

[John Maloney]

My theory is that the I2C lines are not being properly pulled high by the GY BME 280 at startup. Thus, the firmware hangs when the Pico firmware checks to see if an OLED display is attached.

I'd hoped it would help to wait 50 msecs to give the GY BME 280 a chance to initialize itself, possibly by configuring some internal pull up resistors.

If the Adafruit BME280 works reliably without the OLED display attached it would support the theory that the GY BME 280 is misbehaving.

The "noOLED" version doesn't fail because it doesn't try to detect the OLED display at startup -- but then you can't use the OLED display if there is one.

[John Maloney]

Here is one last attempt to wait for the I2C bus to stabilize. This one waits a full half second:

https://microblocks.fun/mbtest/tmp3/vm_pico-w_500msecs.uf2

If this one does not allow you to start up and use the GY BME 280 without the OLED display connected then I suspect no amount of waiting will be a workaround.

[Hans Braakmann]

	Adafruit-BME280	GY-BME280	OLED1306	TFT	GY-BME280 + OLED	Adafruit-BME280 + OLED	Comments
VM noOLED.uf2	❌	✅	✅	❌	✅	❌	Oled library works TFT library does not work.
Stable VM MB uf2	❌/✅ varying with wrong readings	❌	✅	✅	✅	❌	Stable when sensor and OLED are connected. Problems when using the sensor as standalone device

When Stable MB uf2 used with GY-BME280 sensor in column 1 row two from the table above, MicroBlocks hangs. even when you disconnect the sensor. You have to reset Flash memory with flash_nuke.uf2 from here and then reinstall MicroBlocks VM to establish a new connection with the Pico/W.

Tested on MAC/OSX and Raspbian

Update: No problems when using the Micro:bit

[John Maloney]

Thanks for making that table; it helps keep everything straight.

How does vm_pico-w_500msecs.uf2 fit into the table?

I'll be curious to see if the Adafruit BME280 fails in the same way as the GY-BME280.

So far, the problem appears to be specific to the Pico board in combination with the GY-BME280.

I did a test with the Pimoroni enviro:bit board, which has a BME-280 on it in combination with a pico:ed board from Elecfreaks, which is an Pico board with a micro:bit edge connector. That did not fail on startup but there too many variables to draw any definite conclusions.

[Hans Braakmann]

Wanted to let know that I did a test with the Adafruit BME280 sensor. This sensor did worse then the GY-BME280 sensor, see table above. Still working on it…

[John Maloney]

Wow, that is unexpected! I don't see a table entry for the Adafruit BME280 yet; will be curious to see the results when you have them.

I'll be traveling May 5-15. If we haven't found a solution by the time I return I will get either a GY-BME280 or an Adafruit BME280 so I can do some testing. Assuming I can reproduce the issue, I want to attach an oscilloscope and try to capture exactly what's happening on those I2C bus lines...

[Hans Braakmann]

Happy traveling, I have updated the table and the same test results on Raspbian. Curious what the oscilloscope readings will bring.

[John Maloney]

For some reason I am not seeing your table updates. Tried in both Safari and Chrome and did a page refresh in both. Could you paste the update table into a new comment when you get a chance?

[Hans Braakmann]

	Adafruit-BME280	GY-BME280	OLED1306	TFT	GY-BME280 + OLED	Adafruit-BME280 + OLED	Comments
VM noOLED.uf2	✅	✅	✅	❌	✅	✅	Oled library works TFT library does not work.
Stable VM MB uf2	❌	❌	✅	✅	✅	✅	Stable when sensor and OLED are connected. Problems when using the sensor as standalone device.

When Stable MB uf2 used with GY-BME280 sensor in column 1 row two from the table above, MicroBlocks hangs. even when you disconnect the sensor. You have to reset Flash memory with flash_nuke.uf2 from here and then reinstall MicroBlocks VM to establish a new connection with the Pico/W.

Tested on MAC/OSX and Raspbian

Update: No problems when using the Micro:bit

[John Maloney]

I'm seeing the Adafruit results in the tables now. Thanks!

I'm puzzled by the Adafruit results. There may be a different issue with that since it's not working with the noOLED version.

[Hans Braakmann]

My temporary conclusion: there seems to be an OLED/TFT library software issue in combination with the I2C Pico bus failing. The standalone sensor GY-BME280 works fine with MicroBlocks VM noOLED.utf2, Micropython, and Arduino. The issues arise when the OLED display, and especially the TFT library, are implemented. The workaround for the stable VM is to daisy-chain the sensors with an OLED display. The question I have is this: why the OLED library has to be preloaded in the Microblocks IDE, or are all libraries preloaded? If so, wouldn’t it be more useful to only load the libraries that are needed in a project you are working on?

[John Maloney]

I agree, there's something about initializing the TFT/OLED library at startup that is interacting badly with the GY-BME280. I'm thinking about possible work-arounds, but first I want to understand the problem.

When I get back from Spain, I will get a GY-BME280 and dig into the problem with an oscilloscope.

OLED support for the TFT library is compiled into the virtual machine for the Pico/Pico-W. It is included because some boards that we support, such as the PicoBricks board, have a detachable OLED display. Also, users often attach third party OLED displays to Pico and micro:bit boards.

As you discovered, you can use the OLED library, which is written entirely in MicroBlocks, without that built-in support. However, the OLED library is very large and it significantly increases the time it takes to download a project to the board. The TFT library is much smaller since it simply calls the graphics code compiled into the VM.