Low temperature reading in specific conditions

[Bolukan]

I operate a BME280 with a ESP8266 on a bare board, with a 1000uF capacitator connected between VCC and ground and a LiFePo4 battery of currently 3,4V. The BME280 is also connected to the same LiFePo4 battery.

The code is optimised for low energy shutting off WiFi, doing one measure each minute, storing them in RTC memory and applying deep sleep. After some measurements (6 currently) it connects to WiFi and sends all data. Now my problem: Each first measurement (60 seconds after the last measurement and sending all data using WiFi) is 0,2 to 0,5 degree too low compared to the others, and also influencing the pressure measurement calculations.

I intend to use the "Weather monitoring" settings: Sensor mode: forced mode, 1 sample/minute. Oversamplings settings: 1x, IIR filter off.

BME280I2C::Settings settings( BME280::OSR_X1, BME280::OSR_X1, BME280::OSR_X1, BME280::Mode_Forced, BME280::StandbyTime_1000ms, BME280::Filter_Off, BME280::SpiEnable_False, BME280I2C::I2CAddr_0x76 // I2C address. I2C specific. );

Anyone an idea how this behaviour occur?

[coelner]

0.2 up to 0.5 °C is within the range of the sensor. bosch released the datasheet version 1.6, read chapter 1.4.

To sum it up.

• Do not use the esp8266 for absolute measurement because it heats up the environment, the power stabilisation is not that easy and influences sensors (watch this: https://youtu.be/HmXfyLyN38c)
• the BME280 tends to heat up
• use the IIR filter
• 1000uF is needed to stabilize the RF parts, whats about short peaks?
• low power esp8266 info: https://blog.voneicken.com/projects/low-power-wifi-intro/

[Bolukan]

Thx for your reply.

It is not random noise of some degree, but a significant deviation on each first measurement of a serie of 6. Devices can deviate but the BME280 is specified to have a Root-Mean-Square (RMS) noise of only 0.005 °C. Furthermore, I attached a capacitator as I mentioned in the introduction, and 60 seconds sleep after last WiFi use should be enough for stable power.

However, I will try some delay after the initial code and just before each measurement to see whether the code did not shut down the WiFi as I expected.

14,86 <- 1
15,43 <- 2
15,42 <- 3
15,39 <- 4
15,36 <- 5
15,40 <- 6 after measurement, WiFi starts and sending 6 measurements via WiFi and enters deep sleep
14,94 <- 1
15,47 <- 2
15,49 etc
15,51
15,46
15,47
14,91 <- 1
15,46
15,47
15,48
15,53
15,50
14,95 <- 1
15,48
15,53
15,56
15,56
15,52

[coelner]

Yeah, I see the problem. With every deep sleep you reset the i2c bus and with it all devices.

I'm not sure but I guess the sensor needs a single measurement to do things. Maybe your problem is solved by forcing a single measurement in before. @finitespace #91 ?

[Bolukan]

That could be an explanation: it reports the last (60 seconds before) measurement combined with unstable voltage during the WiFi operations. 1.000uF should be enough, but I could try adding a smaller ceramic one. @finitespace, hope you can spare some time coming weeks to accept some pulls. I would be glad to help you to adjust any code proposals to your coding standards.

Other option to test, is to start the measurement after the WiFi operations, just before deep sleep. Or to pause the start of WiFi with 10ms to allow the measurement to finish. For logging purposes a permanent minimum delay of 60 seconds is acceptable. I don't think the use of the i2c bus terminates any reading of the BME280. I am not killing the power for the BME280 with a transistor. It is powered continously.

Waiting for a fresh measurement (with 1 sample) takes about 10ms do you agree? (Appendix B of datasheet BME280). That could also be an option to consider, but I guess it will cost battery juice as the code execution without WiFi is very fast.

[coelner]

you reset all I2C devices within your setup() because you configure them again. I'm not sure if the state of the sensor gets lost by that. Yes, for the first measurement it should take less then 10ms. (maybe this one is related too: #61 )

[Bolukan]

Adding a delay(10) before starting WiFi - but after polling the BME280 - did the trick. I will keep looking for other solutions, but at least I got a base-solution. Thx @coelner.

[Bolukan]

@coelner. delay(10) is not enough. Now my humidity reading got the fever. Looking at figure 4 of paragraph 3.3.3 of the Bosch pdf, I need to add a little more. (Or use some kind of interrupt.) I calculated 8,075 ms for the reading, of which 2,575 ms for humidity. I will add 5 and see what happens.