Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Temperature offset and humidity issue #20

Open
giampiero7 opened this issue Feb 4, 2019 · 6 comments
Open

Temperature offset and humidity issue #20

giampiero7 opened this issue Feb 4, 2019 · 6 comments

Comments

@giampiero7
Copy link
Contributor

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!

@Gadgetoid
Copy link
Member

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.

@giampiero7
Copy link
Contributor Author

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...

@Gadgetoid
Copy link
Member

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 #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.

@giampiero7
Copy link
Contributor Author

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...

@Gadgetoid
Copy link
Member

Gadgetoid commented Feb 15, 2019

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.

@aluchuk
Copy link

aluchuk commented Jan 5, 2020

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.
image

temp/hum was ok for the past 30 days, but went nuts just now:
Screenshot from 2020-01-04 23-34-10

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants