Open giampiero7 opened 5 years ago
Since the offset is adjusting the raw temperature value used in the humidity compensation, I don't believe these results can be incorrect. But they're awfully unintuitive to rationalise.
It might stand to reason that a device sensing a warmer ambient temperature would compensate the %RH measurements up if we assume that the temperature variation has no affect on the raw value read by the sensor. Or perhaps even an inversely proportional relationship.
I'm not sure how the sensor fundamentally operates, but it doesn't seem crazy to suggest that warmer air holding more moisture would also yield less of that moisture to the sensor thus requiring a proportional increase in the %RH measurement to compensate.
If that is a mere compensation and not a calculation of the RH based on temperature (which implies a decrease in RH when T increases), then, maybe, the offset should not be used in this calculation, since the compensation should in fact be based on the temperature measured by the sensor, not the "offsetted" one. What do you think? Hope I made myself clear...
That's a pretty good point- but I think we're still on the right track. The offset exists purely for compensating the humidity calculation- it serves no other purpose.
In many cases the temperature read by the sensor will be incorrect for the surrounding air temperature since it's directly heated by the Pi. If it's the temperature of the air that affects the reading, and not the temperature of the sensor itself then that would suggest this offset calculation is correct.
The discussion here https://github.com/pimoroni/bme680-python/issues/11 suggests that BOSCH recommend direct temperature compensation, and supply an API entry point for it. I'm reasonably comfortable our approach is correct.
If you want to offset only the temperature, you can just add a value to the converted output in degrees C and Humidity readings will remain unchanged.
If it's the temperature of the air that affects the reading, and not the temperature of the sensor itself
This is what I'm not sure about and cannot find any information on... do you have any reference?
If that was the case, I would expect their library to include a user defined offset in the calculation too, as it is done here...
I believe that their library does not- but their unified sensor API does- it’s a separation of concerns that we can’t really implement since their sensor API is closed-source and can’t be ported to Python.
I believe temperature compensation isn’t strictly necessary for humidity and serves only to convert it from “absolute” humidity (the amount of moisture in the air) to “relative” humidity (what this humidity feels like to a person). IE: hot, humid air feels more humid than cold, humid air.
I have the Gravity: I2C BME680 from dfrobot and DHT22 both providing readings. Recently I tried calibrating humidity using a saturated salt solution, and had to move the breadboard around... needless to say some things were disconnected. After some troubleshooting the reading from BME680 are way off! I'm going trough Bosch literature and all the Google results, but keep coming back here. I hope some of you can offer a clue. This doesn't look like a simple offset.
here is the past 6 hours. AQ is off because I reduced initial burn-in.
temp/hum was ok for the past 30 days, but went nuts just now:
Hi, Pull request #13 adds the possibility to set a temperature offset. In the first comment of the PR you can see that setting a positive offset results in an increased %RH, while a negative offset decreases the %RH. As far as I know, it should be the other way around, plus the difference should be much greater... Am I missing something? Thanks!