Bosch Sensortec Community

    Showing results for 
    Search instead for 
    Did you mean: 

    BME680 - unrealistic eCO2 Values

    BME680 - unrealistic eCO2 Values


    As described in

    we use an example application with a precompiled bsec library for data evaluation (BME680 sensor): 

    This time we test the BME680 sensor with a rasperry pi zero and the SEN-BME680 eval board (Joy-it) - so we can exclude hardware failures on our side (since the raspberry is used in many other I2C-Applications without any problems ....)

    Again, the measured eCO2 trendline contains unrealistic jumps and measurement results (eCO2):



    - Is it possible, that there is a bug in the bsec-library?
    - Is there a physical explanation for such unrealistic jumps in the trendline?
    - Maybe the firmware on the BME680 is buggy? Is an update available?

    Our customers expect somehow realistic eCO2 - values .... I know, it's just an estimation for CO2, and I may expect errors in the range of 100-200 ppm ....
    But jumps in the range of 600ppm for no reason? Or values in the range of 5000 ppm in a normal office room
    (I think I should be dead if the values are correct 😉 )?

    Any help would be great - Thanks in advance!

    Best regards,
    Bernhard Mathias

    7 REPLIES 7

    Community Moderator
    Community Moderator

    Such outputs and especially these steps/jumps don't look like expected behavior. A few things I would check in such conditions:

    • Do all timestamps look as expected?
    • Does BSEC return any warning/error message?
    • How does the raw data (esp. gas resistance) look like?
    • If one was previously stored, did you try clearing (or temporarily disabling) your state file?
    • Do you still see the same behavior if you uncomment this line from the sensor API (i.e. enabling floating-point compensation)?

    Monitoring the IAQ accuracy output could also provide further hints on the behavior/status of the library. I would suggest to confirm the points above are all working as expected first, then I would also recommend letting the library run for some time/making sure it had time to calibrate itself before comparing the output to your reference sensor.

    Thanks for the quick response,


    - the timestamps look ok
    - not sure about warning/error messages at the moment since I only logged stdout and not stderr 😕
    - gas values (I will attach data-files too):


    - in this testruns I didn't delete the state files - it's possible that the state files were not empty at time of teststart...

    We will try to do further tests with enabled floating-point compensation, log stderr and also additional some i2c-logging on the raspberry pi

    Thank-you for providing the datalogs as well, this is always helpful 🙂

    A few comments from this extra data:

    • The raw gas data in "bme_rasp_8_peakAtBeginning.xlsx" (bottom plot in your post) looks very smooth, and so does the IAQ output for the same dataset.

      On the other hand even the raw gas signal in "bme_rasp_erroreCO2.xlsx" looks odd (top plot in your post) with jumps to zero and large spikes/noise in the signal. These spikes are also seen in the temperature/humidity and even in the pressure singal. From a raw data perspective, this behavior is not expected from the sensor.

    • For reference I also ran BSEC over your datasets (i.e. both from scratch with no state file/history!):
      • Based on raw data from "bme_rasp_8_peakAtBeginning.xlsx"  I get the following sIAQ output:


      • Based on raw data from "bme_rasp_erroreCO2.xlsx" I get the following sIAQ output:


        Note: For this run I received 16 times the error -2 (BSEC_E_DOSTEPS_VALUELIMITS) corresponding to the 16 samples with zeroed gas resistance values, but no steep steps as in your output.



    Ok, new testrun and a peak to 1400 ppm in eCO2 occured:


    this time

    - stderr was logged -> no error messages
    - state-file was deleted before the testrun
    - floating point compensation was enabled
    - i2c communication was logged ( , trigger at peak + 500 seconds pre-buffer)

    Strange here is a break in the gas trendline the same time the eCO2 value jumps:



    What can be the reason for the strange gas / eCO2 values?

    I will attach the bsec output as well as the I2C-log.

    Best regards,