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.
Solved! Go to Solution.
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?
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?
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.