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

    I do not understand the power concern here. In your previous post, you mentionned 10000mah battery.

    Assuming costs constraints prohibit the use of switching power supply (which could 1.5x battery life easily if the whole system runs at 1.8v), we can do the whole calculation in amps rather than watts.

     

    So (10000mAh )/ (168h in a week) = 59.5 mA <- that is the current consumption budget. You can of course add some buffer for various innefficiencies and battery degradation as you want.

     

    The average current consumption of BME680 in ULP mode is 0.1mA (0.16% of your budget) and in LP mode 1mA (1.6% of your budget).

     

    I really do not understand how the sensor can be limiting the overall battery life.

    Dear ,

    you did way to optimistic calculations and did not comply with the constrains. Yes, you can calculate some numbers that seem fit and the suggest something that does not fit to our problem. But why?

    See:

    1. I mentioned time periods of 1-2 weeks on a batterey charge. So your nice current consumption budget got down to 30mA.

    2. Yes, the BME680 has some pretty low power modes, but (as I wrote) there are more sensors attached to our ESP12f, so there are some more consumers on the battery. AND, using some ULP mode in the BME680 does not help anything, as other sensors need to be handles by the ESP12f too. How does and infinite, BME680-only ULP loop helps here?

    3. Nobody said that "the sensor can be limiting the overall battery life". You got that wrong. But the lifetime (with one battery charge) of our system is limited. To overcome a discharged battery after 2-4 days some sleep for 1-3 minutes (between measuring) is necessary. The BME680 can go to sleep or not during that time. But the ESP12f will have to do.

    in ULP mode, the BME60 will require a command to trigger a measurement every 5min. The measurement takes about 2sec, but the result could be read at the next cycle, before triggering the next measurement.

     

    Therefore the requirement to communicate with the BME680 and collecting the data for BSEC is only a few miliseconds every 5 minutes. You can optimize your system to sleep in between, it will not cause any issue. (BME680 will automatically go back to sleep, and memory is not lost after each measurement)

    Let us asume I take what is in

    void bsec_iot_loop(sleep_fct sleep, get_timestamp_us_fct get_timestamp_us, output_ready_fct output_ready,
                        state_save_fct state_save, uint32_t save_intvl)

    and put this into my code, so that I can work with other sensors and not only the BME680.
    But instead of calculating the sleep interval in the end of the while loop and sleep, I exit, save the state with something like

    state_save(bsec_state, bsec_state_len);

    and go to sleep ... to deep sleep of an ESP ... for 3 seconds or 3 minutes. Then we wake up. The state is loaded, the config is loaded and we continue. Right?

    So ... I tried this and the IAQ accuracy stay's 0.

     

    This routine gives me a acucracy of 3 after a while:

    setup() {
       initBme680andLoadConfig(generic_33v_3s_4d);
    loadBme680StateFromEepromIfThereIsSome();
    initMyOtherStuff(); } loop() { readOtherStuff()
    readBme680();
    saveStateAfterReachingAccuracy3();
    readMoreOtherStuff(); sleep(3s); }

    But this does only keep my value for the IAQ accuracy at 0:

    setup() {
       initBme680andLoadConfig(generic_33v_3s_4d);
    loadBme680StateFromEepromIfThereIsSome();
    initMyOtherStuff(); } loop() { readOtherStuff()
    readBme680();
    readMoreOtherStuff();
    saveBme680StateToEeprom(); deepSleep(3s); }

     

    I am willing to believe you that it is possible. But please tell me what is missing here after a wakeup from deep sleep? What config, what calibration, what value, which set function do I need to let my system know that it just rebooted after a deep sleep but that there is a BME680 sensor which's state we know.

    From your pseudo-code, I can see the following.

    3min data rate is not supported. only 3s or 5min is supported. In any case, when you resume from deep sleep, you need to provide the correct timestamp to BSEC (pevious timestamp + 5min)

     

    We need a bit of time to investigate this issue. Since the entire instance is re-initialized at every data point, there may be some workaround needed beyond simply reloading the state.

    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