1 sample/minute?

[swilsonnc]

Shouldn't this line in BME280_Modes.ino read 1 sample/second or is it really 1 minute? I am using this mode and seeing 1 sample/second.

//BME280I2C bme; // Weather Monitoring : forced mode, 1 sample/minute

[swilsonnc]

To clarify. I understand that was based on the Bosch BME280 datasheet because this conflicts.

BME280I2C bme; // Default : forced mode, standby time = 1000 ms
// pressure ×1, temperature ×1, humidity ×1, filter off

/* Based on Bosch BME280I2C environmental sensor data sheet. */

//BME280I2C bme; // Weather Monitoring : forced mode, 1 sample/minute

I guess I am curious how to really get 1 sample/minute using this library.

[kvoit]

I guess I am curious how to really get 1 sample/minute using this library.

The BME280 starts in the suggested settings for weather monitoring, which is forced mode without filter and oversampling.
In forced mode it is your job to perform one measurement per minute (or e.g. per second for the following humidity sensing example). So, put one measurement per minute into your Arduino loop.
There is no register setting to give the BME a 60000ms standby time. Longest standby in normal mode is one second.

A new reading is triggered by enabling the forced mode again. After the reading, the sensor will go to sleep by itself. The read function of the library does enable forced mode by itself, reads the registers immediately afterwards, so I THINK if will return the values from the last reading. Might not be important when reading every 500ms, but for a sensor that reads once per hour, it certainly matters.

[whatsupskip]

I am trying to understand how this relates to the self heating issue the BME280 suffers from. This is mentioned here (http://www.esp8266.com/viewtopic.php?f=13&t=8030&start=28) and here (https://www.kandrsmith.org/RJS/Misc/Hygrometers/calib_many.html).

I have been trying to adjust the code in this project (https://www.hackster.io/s-wilson/nodemcu-home-weather-station-with-websocket-7c77a3) to solve the problem with the self heating, but I am having no luck.

[swilsonnc]

The chip itself takes a sample every second when you use BME280I2C bme; in your code. If you choose 1 minute in your loop it doesn't change the fact that the chip is still sampling every second. What we are trying to accomplish here is to have the chip sample slower than every 1 second to combat overheating. So far with this library I don't know how that can be done and that is what I am trying to figure out.

[whatsupskip]

Thanks for clarifying.

Are the suggested changes made to the ADAFruit code of any assistance?
(http://www.esp8266.com/viewtopic.php?f=13&t=8030&start=28)

[swilsonnc]

Looking at the library in bme280.h I saw this.

public:
/* ==== Constructor used to create the class. All parameters have default values. ==== */
BME280(uint8_t tosr = 0x1, uint8_t hosr = 0x1, uint8_t posr = 0x1, uint8_t mode = 0x1,
uint8_t st = 0x5, uint8_t filter = 0x0, bool spiEnable = false); // Oversampling = 1, mode = forced, standby time = 1000ms, filter = none.

The uint8_t St = 0x5 could actually mean 5ms. Wonder if we change it to say 0x5000 if it would change the rate to 5 sec for example. Won't get a chance to try it for a few days.

[kvoit]

The datasheet says in section 5.3.2 that sleep mode is the default mode. So
BME280I2C bme; should NOT cause a update every second in the chip. Rather, the function of this library set the chip to forced mode, which takes one sample and then goes back to sleep mode.

The uint8_t St = 0x5 could actually mean 5ms. Wonder if we change it to say 0x5000 if it would change the rate to 5 sec for example. Won't get a chance to try it for a few days.

0x5 is HEX for b101 (BIN). It doesn't make any sense to change this to 0x5000, which would be 20480 in decimal. Rather, looking at the datasheet b101 means 1000ms sleep time according to table 27. This is the highest standby time offered by the sensor. If you want to sample more often, you need to do it by setting forced mode manually in that interval, I think.

I don't really understand what your issue is. This library directly passes the values to the register, which are very clearly documented in the datasheet.

I ran this directly next to a DHT22 with one sampling per hour, and the values are read identical to .1°C.

[finitespace]

The library starts the sensor in forced mode. These issues are only valid in normal mode. Standby time is only used in normal mode. In forced mode, the sensor takes a measurement when the command is sent to the sensor. Any overheating in forced mode would be a result of how often you, the user, issue the read command.

For further clarification, here is what the datasheet says on this matter:

5.3.3 Forced mode
In forced mode, a single measurement is performed in accordance to the selected measurement and filter options. When the measurement is finished, the sensor returns to sleep mode and the measurement results can be obtained from the data registers. For a next measurement, forced mode needs to be selected again. This is similar to BMP180 operation. Using forced mode is recommended for applications which require low sampling rate or host- based synchronization.

5.3.4 Normal mode
Normal mode comprises an automated perpetual cycling between an (active) measurement period and an (inactive) standby period.
The measurements are performed in accordance to the selected measurement and filter options. The standby time is determined by the setting t_sb[2:0] and can be set to between 0.5 and 1000 ms according to Table 27.
The total cycle time depends on the sum of the active time (see chapter 11) and standby time tstandby. The current in the standby period (IDDSB) is slightly higher than in sleep mode. After setting the measurement and filter options and enabling normal mode, the last measurement results can always be obtained at the data registers without the need of further write accesses. Using normal mode is recommended when using the IIR filter. This is useful for applications in which short-term disturbances (e.g. blowing into the sensor) should be filtered.

Tyler

[swilsonnc]

OK, so that makes sense the way you stated that. If that is correct then the loop on a 1 minute timer would solve the heating problem. If this takes care of the heating issue I will be surprised though. Will try to test this later. Scott

…

On Mon, May 1, 2017 at 9:22 AM, Tyler G ***@***.***> wrote: The library starts the sensor in forced mode. These issues are only valid in normal mode. Standby time is only used in normal mode. In forced mode, the sensor takes a measurement when the command is sent to the sensor. Any overheating in forced mode would be a result of how often you, the user, issue the read command. For further clarification, here is what the data sheet says on this matter: 5.3.3 Forced mode In forced mode, a single measurement is performed in accordance to the selected measurement and filter options. When the measurement is finished, the sensor returns to sleep mode and the measurement results can be obtained from the data registers. For a next measurement, forced mode needs to be selected again. This is similar to BMP180 operation. Using forced mode is recommended for applications which require low sampling rate or host- based synchronization. 5.3.4 Normal mode Normal mode comprises an automated perpetual cycling between an (active) measurement period and an (inactive) standby period. The measurements are performed in accordance to the selected measurement and filter options. The standby time is determined by the setting t_sb[2:0] and can be set to between 0.5 and 1000 ms according to Table 27. The total cycle time depends on the sum of the active time (see chapter 11) and standby time tstandby. The current in the standby period (IDDSB) is slightly higher than in sleep mode. After setting the measurement and filter options and enabling normal mode, the last measurement results can always be obtained at the data registers without the need of further write accesses. Using normal mode is recommended when using the IIR filter. This is useful for applications in which short-term disturbances (e.g. blowing into the sensor) should be filtered. Tyler — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#23 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AWdJlu0sxePShTvMoROx7eO24OcZwZo5ks5r1dyAgaJpZM4Mwgg4> .

[whatsupskip]

I have done some more testing. I found one major factor with the heating problem was not the BME280 itself, but heating or interference from the NodeMCU ESP8266. The BME280 was about 15 to 20mm horizontally from the antenna of the ESP8266. I have relocated it around 100mm from the ESP8266.

I was having major heating problems with more than 2°C.

I have now increased the sampling time on the BME280 to 15 seconds. With these two changes have now have the BME280 reading within 0.5°C of a AM2302 module. The testing conditions for this are far from ideal, so the result might be even better.

[kvoit]

I can confirm this. An ESP8266 has massive influence on temperature in direct vicinity to the sensor. I don't think it has to do with the antenna. It just gets quite warm.

[whatsupskip]

I was just very surprised it would have such an impact when it was on the same plane (horizontal) from the ESP8266. I can understand if it was vertically above or in an enclosed space. That is why I was wondering if the were some induced currents. I will need to do more testing.

[kvoit]

I had the exact same issues with a DHT22, AFAIR horizontally next to a Wemos D1 Mini, mounted vertically on a wall without enclosure.

[idesignstuff]

Guys, I know this is a bit of a tangent, but relating to heat on the ESP8266 boards: The power consumption and heat generation can be drastically reduced by putting the radio to sleep in between measurements. I've built several copies of a Wemos D1 mini with a single addressable LED, some switches and a vib motor for a wearable device, and was able to power it for over 12 hours from a single "AAA" sized lithium ion cell with a rated capacity of 400 mAh. With the radio on, the ESP8266 can draw over 250mA, most of which ends up being turned into heat. TL/DR: The heat problem can pretty much be eliminated if you only fire up the radio right before you communicate, and then turn it off again after you're done. Christian

…

On Wed, May 3, 2017 at 3:45 AM, kvoit ***@***.***> wrote: I had the exact same issues with a DHT22, AFAIR horizontally next to a Wemos D1 Mini, mounted vertically on a wall without enclosure. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#23 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQBjGZzJ5epTFeZffu48Ns1LKi_39Qdkks5r2D69gaJpZM4Mwgg4> .

[kvoit]

Sure. If your ESP is doing nothing else. In my case, however, the device also reacts to MQTT messages to control the lighting.
If you are JUST measuring, you can turn of the whole ESP. I have one of those running in the wine cellar, taking a measurement once an hour, powered by a 18650 LiPo with about 2000mAh. From the voltage curve, I expect between 6 and 12 MONTH runtime. (It has been running for 1 month now, and the tendency of the voltage is quite clear.)