Bosch Sensortec Community

    cancel
    Showing results for 
    Search instead for 
    Did you mean: 
    SOLVED

    BME680 state_save / state_load problem

    BME680 state_save / state_load problem

    micha_pr
    Established Member

    using Arduino 1.88 / 1.85 with ESP8266 (lib 2.50 / 2.42) and two BME680 sensors.

    Final goal is to use these sensors in portable devices, but at first in normal mode without sleeping process.

    If using the config_state sample I can see that the state_save and state_load will not work correct.

    what is going on:
    1) BME starts - after some time will get right values as expected with accuracy=1
    2) some time later have still valid values with accuracy=2, sometimes is falling back to accuracy=1
    3) auto save procedure (with accuracy=2 (?) or even 1 (!) ) will be done
        (have canged this in code that I allow autosave only if accuracy >=2 - maybe "3" is correct? )
    4) After autosave to EEPROM with accuracy=3  reboot the ESP (power loss...)

    -> Load values from EEPROM

    5) BME start and show at first minutes no valid values and accuracy=0  (maybe correct ?)
    6) After some minutes accuracy=2 but IAQ is still 0 - for a very long time (hours).
        Resistance is in normal range (as before restarting) - so no changes.

    The only way is erase the EEPROM and start at new - then all is fine again (until next restart).

    I already made some control procedures - but not sure how to get a valid config_load after restarting.

    BTW: I have compared the saved and loaded values before - identical.

    Any idea?

    Thanks!

    Michael

    36 REPLIES 36

    Great, I would love to share my use case. Thanks.

    Setup:

    • ESP-12f device, Arduino Toolchain
    • I²C devices: 1 x BME680, 1 x DS3231 Real Time Clock (and some more devices not shared to this forum)
    • 1 x 10000 mAh battery
    • 4 MB additional flash storage

    Use Case:

    1. The device is planned to measure environmental values
      - every 1-5 minutes
      - in places, where a constant power supply by a grip is not present and
      - over time periods of 1-2 weeks
    2. The devices will try to connect to a secure wifi network every 5-20 minutes. If the network is present, data will be uploaded to some server.

     

    --> In order to fullfill this task, the device has to enter deep sleep in times without measurements. The I2c devices will be connected to a 3,3V power source all time. Only the ESP-12f will go to sleep.

    • Trigger a BME680 measurement e.g. ever minute is not only acceptable, but required.
    • By the real time clock we can also garantee to sample BME680 measurements frequently (with a certain inaccuracy by the RTC, of course).

    ??> The challenge for us right now is to recover a BME680 connection after letting the ESP-12f sleep for e.g. 30, 59 or 59,91 seconds. THe sleep is triggers by a commad like system_deep_sleep_instant(_sleepTime_us);.

    A code example like the following dummy would be great, that lead to a setup, that can achieve IAQ state "3" like the "normal example code:

     

    #include <everything-necessary.h>
    
    setup() {
      // do magic init here
      allTheInit();
    }
    
    loop() {
      // measure BME680 sensor
      measureBme680();
    
      if (iaqSensor.iaqAccuracy < 3) {
        _sleepTime_s = 60 * __s2us; // sleep for 1 minute
      }
      else {
        _sleepTime_s = 5 * __s2us; // sleep for 5 s or whatever
      } 
      system_deep_sleep_instant(_sleepTime_us);
    }

     

     

    For the BME680 to perform optimally, BSEC should run in a fixed operating mode (either LP or ULP) consistently. Therefore we would recommend not to perform the 'if' condition in your pseudo-code (which should otherwise be reported by BSEC), and add that it is expected for the accuracy to drop at least to 2 indicating that the library is performing a calibration.

    Regarding power saving, it should be possible to put your MCU in deep-sleep between measurement, as long as you can save and restore in time BSEC's state file and your system timestamp between each read-out.


    @handytech wrote:

    For the BME680 to perform optimally, BSEC should run in a fixed operating mode (either LP or ULP) consistently. Therefore we would recommend not to perform the 'if' condition in your pseudo-code (which should otherwise be reported by BSEC), and add that it is expected for the accuracy to drop at least to 2 indicating that the library is performing a calibration.

    Regarding power saving, it should be possible to put your MCU in deep-sleep between measurement, as long as you can save and restore in time BSEC's state file and your system timestamp between each read-out.


    Great to get a response after two weeks. Nice to hear from you! Regarding the first section of your response: That's fine. Let's assume the MCU awakes every minute or very 4 minutes as a fixed interval. Unfortunately,

    1. we need a setup with more than a gas sensor connected to our MCU and
    2. our MCU needs to enter deep sleep like the BME680 self. 

    I am a little bit suprised that this was no considered use case for Bosch regarding a low powers IoT sensor (especially #1). I would have assumed that at least a scenario with 1 MCU and several sensors was considered. 

    But, let us try to find a solution. Regarding your last post in the last section you say "as long as you can save and restore in time BSEC's state file and your system timestamp between each read-out.":

    • So loading and restoring a state is already in your example. So we can pu a check sign on this.
    • Question 1: What does "in time" mean?
    • Question 2: How is my "system timestamp" involved in all this?

    Some more explanation and a code example would be appreciated!

    Hi Bastian,

    I did a little research and found that your specific MCU has 512 bytes of RAM that is preserves even trough deep sleep.

    https://github.com/esp8266/Arduino/blob/master/libraries/esp8266/examples/RTCUserMemory/RTCUserMemor...

     

    Here's what I would therefore recommend:

    1. Buffer the data (timestamp, temperature, pressure, humidity, raw gas resistance) in the IoT device using the RTC memory. Assumin you don't need the memory for other purposes, you can buffer more than 2h of data (ULP), more if you optimize your memory usage.
    2. When your IoT device connects, send the entire raw data over WiFi, and create a BSEC instance in the cloud for each connected BME680. Assuming that your cloud server has hundreds of MHz processor, Megabytes of RAM, and a multithreaded operating system like Linux or Windows, then it can easily handle dozens, if not hundreds of sensors.

     

    BSEC does not have to run in real time. It can be easily fooled by calling the API repeatedly with increasing timestamps.

    This will work as long as you:

    • Sample at the right frequency
    • Use the right sensor settings for the mode you are in
    • Do not use the ULP+ mode. This mode does not use constant settings for measuring the data, hence the need for the BSEC to run in real-time.

    Dear  ,

    thank you for you answer, but I think you have not completely read my setup description. The device (and BME680 sensor connected to an ESP12f) will have to run on a batterie for more than 1 week. The storage is no problem, but the power. For this time span, the device needs to enter sleep for 1-5 minutes, then only wake up quickly to measure and then sleep again.

    Your proposal is not solution here. Sorry.

    Icon--AD-black-48x48Icon--address-consumer-data-black-48x48Icon--appointment-black-48x48Icon--back-left-black-48x48Icon--calendar-black-48x48Icon--center-alignedIcon--Checkbox-checkIcon--clock-black-48x48Icon--close-black-48x48Icon--compare-black-48x48Icon--confirmation-black-48x48Icon--dealer-details-black-48x48Icon--delete-black-48x48Icon--delivery-black-48x48Icon--down-black-48x48Icon--download-black-48x48Ic-OverlayAlertIcon--externallink-black-48x48Icon-Filledforward-right_adjustedIcon--grid-view-black-48x48IC_gd_Check-Circle170821_Icons_Community170823_Bosch_Icons170823_Bosch_Icons170821_Icons_CommunityIC-logout170821_Icons_Community170825_Bosch_Icons170821_Icons_CommunityIC-shopping-cart2170821_Icons_CommunityIC-upIC_UserIcon--imageIcon--info-i-black-48x48Icon--left-alignedIcon--Less-minimize-black-48x48Icon-FilledIcon--List-Check-grennIcon--List-Check-blackIcon--List-Cross-blackIcon--list-view-mobile-black-48x48Icon--list-view-black-48x48Icon--More-Maximize-black-48x48Icon--my-product-black-48x48Icon--newsletter-black-48x48Icon--payment-black-48x48Icon--print-black-48x48Icon--promotion-black-48x48Icon--registration-black-48x48Icon--Reset-black-48x48Icon--right-alignedshare-circle1Icon--share-black-48x48Icon--shopping-bag-black-48x48Icon-shopping-cartIcon--start-play-black-48x48Icon--store-locator-black-48x48Ic-OverlayAlertIcon--summary-black-48x48tumblrIcon-FilledvineIc-OverlayAlertwhishlist