Bosch Sensortec Community

    Showing results for 
    Search instead for 
    Did you mean: 

    BME680 Compensation not working on sIAQ output

    BME680 Compensation not working on sIAQ output

    Established Member

    We have checked the sIAQ behavior on different temperature and humidity levels inside a calibrated environmental chamber. The sIAQ output is very unstable (not compensating temperature and humiditiy) which causes de sensor to self calibrate quite often.

    The code used is the "basic_config_state" included in the Examples, with this configuration:


    STATE_SAVE_PERIOD UINT32_C(360 * 60 * 1000)

    The code was modified only enable PWM outputs on Arduino Mega for temperature, humidity and sIAQ in order to register the signals in a external logger.

    Before the test the sensor had been exposed to both clean and very polluted environment, the state 3 had been reached and saved into Arduino Mega 2560 EEPROM. 

    The sequence of the chamber sitting was this:

    20 ºC / 60% RH

    30 ºC / 60% RH

    40 ºC / 60% RH

    50 ºC / 60% RH

    20 ºC / 60% RH

    10 ºC / 60% RH

    0 ºC /  RH not controlled

    20 ºC / 70% RH

    20 ºC / 80% RH


    This is the result (sIAQ is a 0 to 5 V signal mapping 0 to 1000 sIAQ BSEC output):


    As you can see every change in temperature causes a change in humidity, as expected, but also in sIAQ, with values from 0 to 380 and undergoing frequent calibration (2) states.

    My questions:

    - Can the sIAQ behaviour be explained by BSEC algorith not responding fast enough to the sudden changes in enviromental conditions?

    - The period was set to 28 days because I read in this forum this is recommended for sIAQ output, but the sensor history did not reach 28 days yet. May changing the setting to 4 days can improve the sIAQ stability in this case?

    Thank you.





    8 REPLIES 8

    In default mode I believe it is the "4d" config string. 4 days or 28 days is really just a time constant, the algorithm does not work using a fixed time window, rather a single state blob, and new data. No matter how long the sensor has been on, or the time constant, the state file is always the same size.

    Indeed the baseline tracking (25 ~ best air so far) speed is dictated by this time constant. Let's say the sensor is static in an office building, then there is a long weekend, let's say Easter. A longer time constant will prevent the sensitivity increasing due to the lack of stimuli.


    Established Member

    " A longer time constant will prevent the sensitivity increasing due to the lack of stimuli."

    But sensitivity is fixed for sIAQ. Then, can we ignore this time constant when using sIAQ output?


    "But sensitivity is fixed for sIAQ." Yes.
    "Then, can we ignore this time constant when using sIAQ output?" No.

    The time constant will equally affect the baseline tracking, or offset. Therefore if the sensor stays in relatively bad air for multiple days, then this "bad air" will become the new zero sIAQ over time.

    The recommendation stays the same, for static applications, you usually want the 28d time constant and sIAQ together. But for your characterization, feel free to log the raw data instead, compute BSEC in your host from the log file.

    handytech shared a nifty little application some time ago.


    Established Member

    Thank you for the very clear explanation.