Bosch Sensortec Community

    cancel
    Showing results for 
    Search instead for 
    Did you mean: 

    BME 680 Gas resistance adc reading 0

    BME 680 Gas resistance adc reading 0

    The_DudE
    Established Member

    Hello,

    I'm using the BME680 and I'm facing a problem with GAS Resistance measurements.

    Here is my setup:

    • - custom board, 3v3, I2C connection
    • -  BSECv1.4.7.3 used within barebone ARM-M4F/GCC environment
    • - main code mimicking "bsec_iot_example", using "LP" or "ULP" measure rate

    I first thought everything worked fine as I'm getting Temp,Pressure and RH values nicely correlating with measured environment, but even after a few days (weeks) of running measurements, I could still not make any sense of IAQ values.

    It turns out that the GAS_RAW value is stuck to a high value corresponding to an adc reading of zero (gas_r=0 and gas_range =0).

    I checked requested heater temperature and time (given by BSEC) and it looks correct (320 C/ 197ms in 3 seconds "LP" setup).

    When fetching results I always get gas_valid and heat_stab bits set, thus the measurement seems to be correctly performed.

    I traced the first seconds of measurements of a brand new BM680 and I saw that adc reading are actually moving:

    18:46:07:642 [DRV 3] calc_gas_resistance: adc:392 range:11 -> 4291.02
    18:46:10:634 [DRV 3] calc_gas_resistance: adc:960 range:9 -> 11720.93
    18:46:13:633 [DRV 3] calc_gas_resistance: adc:379 range:8 -> 34713.96
    18:46:16:635 [DRV 3] calc_gas_resistance: adc:413 range:7 -> 68053.58
    18:46:19:638 [DRV 3] calc_gas_resistance: adc:616 range:6 -> 116028.30
    18:46:22:641 [DRV 3] calc_gas_resistance: adc:619 range:5 -> 229796.34
    18:46:25:643 [DRV 3] calc_gas_resistance: adc:839 range:4 -> 401811.03
    18:46:28:646 [DRV 3] calc_gas_resistance: adc:309 range:4 -> 588290.75
    18:46:31:648 [DRV 3] calc_gas_resistance: adc:879 range:3 -> 785630.88
    18:46:34:651 [DRV 3] calc_gas_resistance: adc:533 range:3 -> 984626.62
    18:46:37:653 [DRV 3] calc_gas_resistance: adc:310 range:3 -> 1176727.88
    18:46:40:659 [DRV 3] calc_gas_resistance: adc:187 range:3 -> 1318627.50
    18:46:43:658 [DRV 3] calc_gas_resistance: adc:80 range:3 -> 1473165.38
    18:46:46:661 [DRV 3] calc_gas_resistance: adc:860 range:2 -> 1588895.38
    18:46:49:664 [DRV 3] calc_gas_resistance: adc:687 range:2 -> 1769736.62
    ....
    18:48:22:741 [DRV 3] calc_gas_resistance: adc:825 range:0 -> 6489747.00
    ....
    18:49:34:803 [DRV 3] calc_gas_resistance: adc:366 range:0 -> 8974145.00
    ....
    18:50:13:837 [DRV 3] calc_gas_resistance: adc:221 range:0 -> 10208728.00
    ....
    18:56:32:915 [DRV 3] calc_gas_resistance: adc:0 range:0 -> 12946861.00

    but after a few minutes the values reaches 0 and stays stuck. I understand ther is a "burn-in" phase for MOX sensors, but I guess it should not "burn" down to zero...

    After unplugging/unpowering the BM680 for a while and restarting, I get back some "life" on adc measurements (starting lower than the very first time though), but following the same steep curve to zero. I tried 4 different boards with same result.

    Does it ring a bell to anyone ? What could be my problem here ? I can give more detailed info about registers setup (even though I'm just following BSEC requests).

    Regards,

    Laurent

    22 REPLIES 22

    handytech
    Community Moderator
    Community Moderator

    Although we found some small changes compared to our sample code, nothing seems to justify the observed behavior. If this behavior is seen on multiple sensors as described in your first post and you have bought these samples from an official supplier, we would suggest that you contact them to replace these devices, and possibly have them run a deeper investigation about this failure as well.

    JohnRob
    Established Member

    I'm out of my area here but if it were me;

    I'd run the BME680 on an arduino board (or whatever) and use the supplied BME680 sample code (I use the "basic_data_logging.ino").

    You might also check the soldering profile used when assembling your board.

     

    The_DudE
    Established Member

    Hello,

    thanks for your time checking my code and logs. For this proto batch I bought BME from Digikey, and all cards tried so far exhibits same behavior.

    As JohnRob suggested, I'll try "cross-checking" my board with arduino+original demo-code, and may be try my code with an EVB if i manage to get one.

    I'll also ask my PCBA about the reflow profile. Is there any assembly 'steps/method' that should be prohibited (I'm thinking about possible cleaning steps) ?

    The_DudE
    Established Member

    Hello,

    I've eventually put a hand on a evaluation board with a BME680, plugged it in place of my daugthercard and it seems to be working (with my code): after an hour running in LP mode my "GAS" reading stabilized around 160K (ADC =~ 200 / range 6), and readings are actually moving with environmental changes.

    So my issue seems definitely due to badly stored/handled/assembled BME680s, even if I'll likely never find the culprit...

    Thanks for your support,

    Laurent

    handytech
    Community Moderator
    Community Moderator

    @The_DudE wrote:

    I've eventually put a hand on a evaluation board with a BME680, plugged it in place of my daugthercard and it seems to be working (with my code): after an hour running in LP mode my "GAS" reading stabilized around 160K (ADC =~ 200 / range 6), and readings are actually moving with environmental changes.

    So my issue seems definitely due to badly stored/handled/assembled BME680s, even if I'll likely never find the culprit...


    Thanks for the feedback!


    @The_DudE wrote:
    I'll also ask my PCBA about the reflow profile. Is there any assembly 'steps/method' that should be prohibited (I'm thinking about possible cleaning steps) ?

    I would recommend going through the BME680's HSMI manual (Handling, Soldering & Mounting Instructions), hopefully this could provide some leads to what could have caused the behavior on your custom PCBs.


    @The_DudE wrote:
    As JohnRob suggested, I'll try "cross-checking" my board with arduino+original demo-code, and may be try my code with an EVB if i manage to get one.

    Just a last few comments about the provided code:

    • Lines 289/290: I believe these were most likely added for debugging purpose, therefore if not needed I would suggest to remove them going forward.
    • Line 324: I believe the value you want to write via I2C is tmp_pow_mode rather than I2C_DATA[0] (that being said, you have nevered entered this code section based on your debug trace).
    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