Relative Humidity always an integer %

[PaulRB]

In SparkFunBME280.cpp, function readFloatHumidity():

return (float)((var1>>12) >> 10);

is truncating result to integer. Comment above says there are 10 fractional bits. I changed this in my copy to:

return ((float)(var1>>12)) / 1024;

and confirmed this now yeilds 3 decimal places.

I am a newbie at github and have never performed a "pull request", which is what I assume I should be doing. First of all can someone please confirm my change is appropriate?

[mgrusin]

Thanks for your work on this! At first glance your change looks correct; we'll check with the library author. My first thought was that as the accuracy of the RH sensor is +/-3%, three decimals can be misleading. But the manufacturer's example code is written the same way, and extra precision can be useful for filtering, so I think it's a valid change. You're correct that a pull request is the normal way to do this, feel free to go ahead and do so. Thanks again!

[PaulRB]

Performing a pull request will be good experience for me. But i will wait until the library author confirms my change is best way.

Precision and accuracy are slightly different concepts, though. The sensor may be able to reliably detect a 0.1% change, even if it is 2~3% out in absolute terms.

[torntrousers]

Thanks PaulRB, this has been bugging me too.

[JamesWebb73]

This is correct. readFloatPressure is similarly losing precision:

p_acc = p_acc >> 8; // /256
Would be better as
return (float)p_acc / 256.0;

PR raised

[floresta]

I came across this problem yesterday and independently came up with the same solution that PaulRB did.

The source of the code in this function is in section 6 of the Bosch BME280 datasheet and their code is essentially the same complete with the lead comments that say:

// Returns humidity in %RH as unsigned 32 bit integer in Q22.10 format (22 integer and 10 fractional bits).
// Output value of “47445” represents 47445/1024 = 46.333 %RH

The Sparkfun library as well as most of the others that I can find do the final conversion (from 47445 to 43.333) in the 'read humidity' function itself whereas Bosch does not.

Although the other libraries that I have looked at end with the 'divide by 1024' technique shown in the original post, Sparkfun has chosen to use shifting to accomplish this division and it looks like this is where the problem lies.

When I run the Sparkfun examples with the Sparkfun library I get humidity values such as 48.00 and 49.00 where the value after the decimal point is always 00.

When I change the code as shown below I get get humidity values such as 48.43 and 48.62 as expected.

// return (float)((var1>>12) >> 10);     // original
return ((float)(var1>>12))/1024.0;       // corrected

I initially thought that adding a pair of parentheses would fix things up and even posted the following 'solution' here for several hours until I checked again leter in the day. I thought I had checked it out but I see that this gives a compile error also shown below.

// return (float)((var1>>12) >> 10);     // original
return ((float)((var1>>12)) >> 10);      // corrected

C:\Users\Don\Documents\Arduino\libraries\SparkFun_BME280\src\SparkFunBME280.cpp:227:33: error: invalid operands of types 'float' and 'int' to binary 'operator>>'

  return ((float)((var1>>12)) >> 10);

I'm also a newbie at github (not to mention C programming) and I wonder if it always takes this long to get things verified and fixed. If Paul's observations had been followed up I could have saved a bunch of time. On the other hand I did learn a bit about how github works.

Don

[JamesWebb73]

Bit shifting a floating point number has interesting semantics.