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

[mjanke]

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

[BSTRobin]

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

[BSTRobin]

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

[mjanke]

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 · Accepted solution]

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 · Accepted solution]

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 · Accepted solution]

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