Bosch Sensortec Community

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

    BME 688 Repeating Forced Mode TPH Reads without Re-Config Gives Good Temp and Press, Bad Humidity

    BME 688 Repeating Forced Mode TPH Reads without Re-Config Gives Good Temp and Press, Bad Humidity

    mjanke
    Established Member

    Hi,

    I can successfully setup a tph read using the following function call sequence as per the forced mode example:

    init_I2c (my fcn to init my i2c link)

    bme68x_set_conf (setup a config in which I am sampling 1x for temp and press and 8x for humidity, no filter or odr)

    bme68x_set_heatr_conf (with heater disabled)

    bme68x_set_op_mode (to enable forced mode read)

    bme68x_get_meas_dur (to get the read delay)

    ... wait the read delay ... about 25 mSec

    bme68x_get_data (read the data)

    All data seems valid and accurate. Temp is 21 degC, pressure is just over 100 kPa, and RH is 46 percent. This matches other sensors nearby.

    I then try and repeat forced reads every min by repeating bme68x_set_op_mode (), bme68x_get_meas_dur(), wait, bme68x_get_data() every min.

    ... and both temp and pressure data looks good, but humidity always reads 100 percent.

    If I execute bme68x_set_conf(), bme68x_set_heatr_conf() with heater still off, bme68x_set_op_mode (), bme68x_get_meas_dur(), wait, bme68x_get_data() every min, all data looks ok.

    Why do I need to set configs each time in order to get valid humidity data?

    Thanks in advance.

    Mark J

    9 REPLIES 9

    BSTRobin
    Community Moderator
    Community Moderator

    Hello mjanke,

    I tested github code forced_mode.c with several time read data, haven't see too much difference for humidity value. Have you changed the reference code?

    https://github.com/BoschSensortec/BME68x-Sensor-API/blob/master/examples/forced_mode/forced_mode.c

    Test result.png

    mjanke
    Established Member

    After reviewing your screen cap, there are a couple of points that I would make.

    1. Your RH % does change radically. The first read is 36.95 % RH, your second is 5.88 % RH which is really really low. It implies that you are located in a very dry place. This page (https://www.currentresults.com/Weather-Extremes/US/low-humidity-cities.php) shows average RH in places like Las Vegas and Pheonix (both in a desert). RH is around 20 % in late afternoon. Given this low reading and the drop from the first reading of 36.95 % RH (which is typical), I suspect that your readings after the first reading are inaccurate. Your temp and pressure values seem stable through all readings (matching my experiencce - see prev posts in this thread).

    2. In your case, the RH dropped dramatically after the first reading. In my case it went up to 100 % RH. I suspect that if you also did a re-config before your 2nd, 3rd, etc readings - you would see them closer to 37 % RH.

    So - the real questsion remains. Why does acquiring stable RH require a re-config before each reach read?

    Regards,

    Mark J

    mjanke
    Established Member

    Nothing from Bosch ....

    Maybe a bug in their Sensor API? Won't know unless someone at Bosch reviewes this thread and tries to resolve.

    Workaroung is simply to re-config before each read.

    I don't like leaving these threads unresolved, so I added this last post and will mark it accordingly.

    Mark J

    BSTRobin
    Community Moderator
    Community Moderator

    Hello mjanke,

    I'm sure the code on GitHub is verified. You can see that I've run it well.
    Correct your comment “The first read is 36.95 % RH, your second is 5.88 % RH which is really really low.”, you could see my previous test result, first humidity is 53.35%, second is 53.14%.

    mjanke
    Established Member

    My appologies, I misread your capture. My comment mistakenly referenced the column after RH. 

    The referenced code (forced_mode.c) performs successive reads without delay between calls (each iteration of the while loop). In my code, I wait 5 seconds between forced reads. That appears to be the only difference. 

    I am left wondering why the behaviour is different. At any rate, the I will work around my issue by issuing a config before each read.

    Regards,

    Mark J

     

    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