Hi all, since a few months I’ve a PEW and I’m playing with it. The intent was/is to build a meteo-station to be placed on a terrace very open to winds (up to 80Km/hr) and to share the readings (temperature, humidity, pressure and wind info) on the home WLAN. In other words, a simpler stuff than the Enviro Weather with its original FW and all its possible connections, MTTQ, HTTP, etc. Starting from such FW I’ve started semplifying it and now I’ve something that creates a web server and provides the BME280 readings plus wind direction and speed to any client connected to its IP address, actually only a Pi 4 with a 7" touch screen mounted in a frame, in house. Unfortunately it turned out that the BME280 readings are quite different from what I see from other sensors and I believe that the other sensors are more correct. I’ve then set up a little test environment based on :
Arduino Nano with a DHT22, a DS18B20 and an OLED screen
A Pi Pico W standalone with a BME280 placed in free air a few cm from the Pi Pico PCB and an OLED screen
The PEW, inside a Stevenson Screen, connected by WLAN to the Pi 4, running the latest version of Raspbian and using Chromium to access the web server on the PEW
An Oregon Scientific hygrometer - thermometer remote sensor, placed on the same desk where all this stuff is mounted.
What I found is that the temperature readings of the PEW are not compensated enough by the TEMP_OFFSET_IFUSB = -4.5 present in the config.defaults.py file . I had to increase the value to -6.5
The humidity reading is completely wrong, today is a rainy day, humidity is above 50% and the BME280 gives 36%
Pressure is always lower , 10 to 15 hPa less, than real time data available from the local airport meteo data…
The weird thing is that even the stand alone Pi Pico, which is running on Micropython 1.21, shows a similar behavior : the temperature needs to be compensated but less than the case of the PEW, the pressure is low (again 10-15 hPa) and humidity is a little bit higher that the one measured by the PEW but still well below the real ambient one.
Now I wondering if I stumbled into defective BME280 sensors, if the PEW set up isn’t the most apt to allow the PEW to take the decent readings and, finally, if I should add corrective factors for pressure and humidity in the FW. In this latter case which values? Please note that I believe, erroneously maybe, that the BME280 measurements are related to its temperature by a non-linear relation and that, instead of a a single compensation value a curve should be needed.
My apologies for the very long post but I’m a bit frustrated and besides help I needed to give vent to it
Complains about the BME280 tend to pop up on a regular basis. I think most of them are because the sensor is not operated correctly. I did a lot of tests with many sensors, and I think the BME280 does well (even cheap China clones). You do not need an offset of any kind if you operate the sensor correctly. And even in you setting you will see that the offset is not a constant, but will vary with many factors (including temperature). All this offset-stuff tries to hide some fundamental problem of the hardware-design.
You can read about my tests here: GitHub - bablokb/sensor-test: Test of various temperature/humidity sensors
Just take a look at the plots directory, and there especially the diff-plots. They show the sensor difference to the mean of all sensors. And you will see that most sensors are within the specs of their datasheets, which is near ± 1 °C.
Some hints:
the Pimoroni drivers initialize the BME280 with wrong settings that are not meant for weather monitoring
you should operate sensors in off/on/off mode. Not only because of heat creap, but because the sensors deteriorate if they are always on
output of pressure has to be manually scaled to get the (normal) sea-level pressure. I posted the formula a few times on this forum. The BME280 are very exact regarding pressure.
sensors should never be directly on a hat. With the exception of one case: if you also turn off the MCU between measurements and your duty-cycle is low.
I believe I mostly agree with you about the BME280 even if, in the data sheet it’s also written that the "BME280 temperature sensor (a diode?) output is used for temperature compensation of the pressure and humidity sensors and can also be used for estimation of the ambient temperature.
Said that I agree that it should not be mounted on the PCB near the Pi Pico but, unfortunately, the Pimoroni Enviro Weather has te BME280 mounted on the PCB, almost under the Pi Pico, enjoying a warm and cosy environment, particularly when mounted inside a Stevenson Cover.
Not having a great experience in Python, or MicroPython, I didn’t date to criticize the BME280 drivers. I just had the doubt that they could be not the best.
On the other hand, I built a barometric station based on an ESP8266, the BME280 (floating in the air, far from the PS and the MPU) and sporting a simple web server . It’s always on, since 3-4 years, it works fine and the temperature error is in the 0.5 - 0,7 Deg. C range. Here the BME280 drivers are in C++, provided through Arduino IDE.
At this point in time I can drop the Pimoroni Enviro Weather, at the end of the day just a little more than a toy, and go with a Pi Pico W, the BME280 and an RJ11 connector for Wind-vane and Anemometer.
Being the whole powered by a solar cell and a LiPo battery and running a web server I cannot go for any sort of on/off mode. It will be always on.
In addition I don’t know what to do with the BME280 drivers. The main program is written in MicroPython and which drivers should I use?
(I’m not capable of taking a C++ driver and embed it into a MicroPython environment)
Any suggestion?
Your ESP8266 works fine since the BME280-driver from Arduino is very good. They even provide different presets for different use-cases (e.g. indoor navigation needs other parameters than weather monitoring).
For MicroPython, you don’t have to change the driver itself. The driver creates a software-object and I think you can just configure it during or after initialization. The most important change is using “forced mode” instead of “normal mode” for the BME280 and to not use oversampling.
Many thanks bablokb, I’ll give it a try, even if my set up is currently driving me mad.
I’ve dropped the PEW, mounted another Pi Pico W with an independent BME280 module and saved the main.py and the bme280.py module in the flash. When I run the main I’ve an error:
OSError: [Errno 5] EIO. in line 99, that is
dig_88_a1 = self.i2c.readfrom_mem(self.address, 0x88, 26).
If I load an I2C scan script the BME is regularly found at 0x76 address so it is not a matter of not finding the sensor. I believe I’ll go and watch some TV or read a book for the rest of the day, before resuming everything tomorrow. I may be overlooking a stupid mistake and a fresh mind might help. Thanks for the advice
Hm. Have you wired your independent BME280-module correctly? These modules usually support I2C and SPI, and it is very important to wire up some of the non-I2C pins correctly to GND or VCC. It is all in the datasheet, but that datasheet is long so it is easy to miss this information. I myself wasted hours with my BME280 and after correct wiring everything worked fine. The main point is that without the wiring it sometimes work and sometimes does not work, so this could explain your observation.
I had that doubt as well but, as I wrote, I’ve loaded an I2C scanner script and the BME280 is found where it had to be, address 0x76. There must be something else basic, stupid that I overlook.
The other weird point is that, in the bme280.py, there are a few lines, before starting to read the calibration values in the BME ROM, that are supposed to verify the presence of an I2C device print a message if the BME device is not there. Well… that check is OK. Bah… I’m really perplexed.
Have you wired CSB to VDD and SDO to GND? As I explained, the result of the scanner script is not relevant: without this wiring it sometimes works and sometimes does not work, so the scanner script might have just had luck.
I’ve a tiny BME board, Chinese I guess, with only VDD GND, SCL and SDA. It works because , with a different main.py, same BME driver and same wiring, it measures temp., humid. and press. and print them in the terminal area (Thonny).
Please note that I2C and BME objects are created exactly in the same manner. This is driving me crazy. I’m tempted to utilize the working script and copy and paste the wind-vane, anemometer and web server definitions into it and see if it works.
I’ve started copying and pasting, block after block, the definitions (e.g. wind_speed, wind_direction, etc.) from the working main.py to the Pi Pico W which was initially running the BME values reading and printing to the terminal. So far so good.
The point here is WHY? What it is not working doing it the other way ? I may end with a main.py+ bme280.py performing the meteo station and web server as was the other (PEW with identical main and BME driver, only difference the I2C pins, from 4 & 5 to 8 & 9) without having the faintest idea about why I had to follow such a cumbersome method.
I’ve to confess that this is a bit annoying. Perhaps an exorcism might help…
Or you could post somewhere your complete code. Maybe it is something so simple that your eyes and brain can’t see it anymore. Tends to happen while programming, as I know from experience.
I must be as you say. Actually, I’ve just completed the copy and paste sequence and the Pi Pico W with the BME280 plus anemometer and wind-vane is now working again.
As the two main.py and bme280.py should be identical, with the exception of the I2C pins, I’m tempted to run a compare between the two couples of files to dig out the differences.
Right now there still are the two original issues :
atmospheric pressure is 10-15 hPa lower than what reported in real time from the local airport (approx 6-7 Km from here, out of town)
client reconnection after a stop (for whatever reason) is irregular. The AP assigns an IP address to the Pico W and it starts listening on such address but Chromium gives the address as unreachable
This latter problem is OT and I think is not appropriate to deal with it here.
For the first one, I believe I’m overlooking something, out of ignorance, as I’ve only verified that in bme280.py the sea_level value is correct but I don’t know what else to do
Which bme280.py are you referring to? In my measurements (4 different BME280, 4 different BMP280) my pressure is always within 1-2hPa compared to what Open-Meteo.com reports. Pressure does not change a lot within a few km, so the value from the airport should be correct. But maybe check against some other source to make sure they don’t add their own conversion.
We’ll, you’re right. I found a few bme280.py on GitHub. I picked up one of them mostly using as a choice criterion the date of the latest update. Actually, the airport is at 108 meters above the sea level and my home is at 130 meters. The airport meteo web page provides the atmosphere pressure adjusted to the sea level. If I interpret correctly what it means it makes sense that the BME measures an absolute 1006 hPa and the airport gives 1021 hPa. Did I get it right?
Many thanks! I’ll use it and see if the measured value aligns itself to the value provided by the airport.
My driver returns an array and the pressure is bme.values[2] so it’s matter of modifying what you gave to me accordingly.
Many thanks again. I’ve modified the bme280.py to embed the pressure calculation related to the altitude and now it’s always identical to what the airport reports.
I’ve definitely abandoned the Pimoroni Enviro Weather and opted for a Pi Pico W standalone + a tiny BME280 breakout board, an RJ11 plug ( for anemometer and wind vane) , a LiPo battery and a LiPo battery charger. This latter, when the meteo station will be in place, will be connected to a solar panel
A normal LiPo charger won’t work well with a solar panel. You need a special charger-chip for that. I would suggest Adafruit’s ADA4755 (available from Pimoroni). On the product-page, there is a link to a technical description that explains why this is so.