Well, after a long time away from experimenting with microcontrollers (haven't touched them since the Basic Stamp 2sx came out!), I've been bitten by the Arduino bug... and hard.
Anyways, I'm working on a little something involving a Sensirion SHT15 temperature and humidity sensor. I've been experimenting with the library provided by Jonathan Oxer and Maurice Ribble, but I've discovered a bug that's preventing me from getting the proper readings for humidity (my temperature is still a bit off, but I'll get to that when I can).
Basically, the error comes from converting the sensor data to real-world values. The code pulls in a 12-bit value for humidity (though anything over about decimal 2500 would be above 100%RH), which fits nicely into the int
data type. To convert from the sensor data to Relative Humidity, you use the formula as follows:
RHlinear = c1 + c2*SORH + c3*SORH2
Where RHlinear is the Relative Humidity, SORH is the sensor output,c1 is -2.0468, c2 is 0.0367, and c3 is -.0000015955.
The code ends up looking something like this:
float readHumidity() {
int val;
float humidity;
const float C1 = -2.0468;
const float C2 = 0.0367;
const float C3 = -0.0000015955;
val = get_SO_RH();
humidity = C1 + C2 * val + C3 * val * val;
return humidity;
}
The first thing I notice is we are multiplying some rather small floats
with some large int
s. If I return val
and manually figure out the correct value, my sensor is dead-on (I have it in a special cigar bag with a "Humidipak" that's calibrated to 69% RH; the sensor is showing 68.6 which is well within the 2% margin of error). My concern is that multiplying val * val
may be causing an overflow (as it's well above a 16-bit number) and therefor throwing my numbers off (or it could be the mix of all these datatypes or the limitation of Arduino's handling of float
).
Even though that value for C3 may be small, since it's being multiplied by a rather large number, it significantly affects the output- around 5% at 70%RH. If worse comes to worst, there's an alternate method that should work, but that comes at the expense of precision and thus something I am trying to avoid.
Any insight? Your help is greatly appreciated!