Sensirion RH sensor Temp Compensation using an 8 bit PIC

I'm trying to implement temperature compensation on a Sensirion SHT11 RH
sensor.

I've got most of it up & going using a 16F628 + *assembler* but I am having
a hard time wtih the temp compensation - in particular - all of it!

While I'm not looking for an exactly correct calculation, it'd be nice to be
in the ball park. (Yes I know, how long is a piece of string....)


From the data sheet for a 12 bit RH measurement:

Temp Comp in %RH = (Temp - 25)[0.01 + 0.00008.(ADC value)] + RHuncompensated



I've done the RGH calcs based on a x10 calculation to get resolution to 0.1%
etc. Multiplying the above by 10 gives:

Temp Comp in %RH x 10 = (Temp - 25)[0.1 + 0.0008.(ADC value)] +
10.RHuncompensated



I've done a heap of searching and can only find information on the
linearisation process, not temp compensation. What's going to be the
simplest approach to doing this in assembler on an 8 bit pic?

All suggestions greatfully received!

 

You don't need dynamic range you are looking for precision. The first question
you need to ask is

What do you want to know about RH?
How much precision?

The result is always between 0..100 (one byte is good to .5%)

The compensation is a two term polynomial dominated by temperature.
1% of the temperature change from 25 degrees.

What will your working temperature range be?

The second term has two parts 8 parts/ 100K of reading value
with a little adjustment for temperature.

Is this adjustment going to affect your requirements?

Answer these questions and implementation will be a lot easier to design.


Regards

 

0.1% precision, I've used a modified (multiplied by 10) version of
Sensirions 2 segment linearisation and this seem work ok.

Working temp range is 0C - 50C (32F - 120F)

At 50% RH the TC is ~0.12%/C. Over a temp range of say 10-->40C this would
be ~3% which would be significant as the SHT11 sensor is good for around 3%

 

What you have to handle is the math, not the language. In general
these things follow an S shaped curve, which can be nicely fitted
to a 3rd order polynomial. I have no idea whether your system
varies sufficiently that you will need to fit to the individual
sensor. At any rate, look up the literature on least squares fits.

 

True - the math is the problem, I mentioned that I was doing it in assembler
as I need to any/all math long hand. It's only a 1st order linear
calculation needed, I thought someone may have "been there, done that".
Thanks.

 

Sorry - I was unclear, the ADC value is the value returned from the sensor,
it is used to calculate RHuncompensated (0/1000 in 2 x 8 bit bytes
representing 0-->100.0% RH)

Yes the second "." represents "*" or multiplication.

 

Yes, I have. The math is simple. And believe me, you do want to
fit a 3rd order polynomial of the form y = ax*x +bx +c. The
problem is to select the optimum values for a, b, and c. When you
have them correct the 1st derivatives will all be zero. The
operations consist of forming some summations and then solving
three simultaneous equations. You want at least 4 experimental
points, 5 or 6 up is better.

I am far too old and retired to work it all out, but it is all in
the literature. Has been for about 200 years. I think Margenau
and Murphy's book is probably the clearest.

 

Well almost....

The RHuncompensated value is calculated using a formula from the data sheet,
the result is a value 0 - 100 (0x00-0x64). I've multiplied the linearisation
formula by 10 to get a result range of 0 - 1000. I've written a bin to ascii
routine that spits out the result in the required ascii format. ie 654
(0x28E) --> "6" "5" "4", I add a "." between the "5" & "4".

I've got all of this working fine.

The formula is straight from the SHT11 data sheet, the ideal formula is a
polynomial, several piecewise linear functions are given as simpler though
less accurate alternatives.

 

Yeah, the saturated salts work well, I've got a couple of sensors that seem
to have drifted a bit (ones I've played with fitting the sensirion filters
to). I plan to try the sensirion reconditioning procedure and try to
revitalise them.

I did a few quick sums and found the variation due to temp could be
significant. The intended application temp range is from 0C to 50C+. At
around 50% RH over a temp ranges of 5C to 45C the sensor temp dpendence is
aorund 5% (2.5% either side of 25C). Maybe not a problem for aircon or
horticulture applications but it may be for mine.

YES - I learnt that the hard way! I'm now using a 2 piece fit with
clip/clamp for the extreme low/top end values.

One day I'll get around to doing a C course and get away from having to
collect basic math routines or do it long hand......

Mmmm - what fail modes do you think could occur. An output of all 0's or all
1's. It'd be hard to detect a sensor with the output stuck at a particular
value without storing sample doing a rolling check to see if it changes at
all with time.


Thanks for your reply.

 

Thanks Rich.

 

Hi Frank-Christian, that's the sort of help I need! I had just been spread
sheeting a range of compensated values and was imagining a similar solution.

Danke schön!

 

I assume you don't need fast calculation for your temperature calculation,
so you can use floating point. Should be possible to implement some
floating point operations in a PIC16F628. Then on top of it a bytecode, for
smaller programs and a compiler on PC side, if you like to use some higher
level language. I think could be done in a weekend for a good programmer,
who have already implemented floating point algorithms in some language,
like I've done some time ago:

http://groups.google.de/group/de.comp.lang.java/msg/15af4a69a890408e

and who knows how to write a parser:

http://www.frank-buss.de/formula/index.html

and a PIC compiler:

http://groups.google.de/group/comp.arch.embedded/msg/0e2e982580a2bde0

Unfortunately I don't have the time at the moment for it. Maybe next year,
when I plan to start programming for my PLC system.

 

If I were implementing this I would implement

Temp Comp in %RH = (Temp - 25)[0.01 + 0.00008.(ADC value)] + RHuncompensated

in 8:16 fixed point. The reason for using fixed point is you need precision
and not dynamic range that is provided by floating point. I would
use 8:16 for all variables to reduce the conversion issues and keep
code size reasonable.

The only major library call would be to a 24*24 mult with a
48 bit result. With care the mult can be unsigned. All three +/- can be
done inline.

Regards

 

12 bits at 3% accuracy is quite meaningless. You can just use the
highest 7 bits with a lookup tables.

 

Thanks Steve.

PS - you have 4 x w's in your sig.

 

I agree that the result is reasonable to be 8.8 however
the polynomial has one term (0.00008) that is 8 parts in
10^6. This is needs at least a 16 bit fract to be relavent.

Yes. RH in air below freezing exists. The air at that
temperature is dry but not completely so.

There is a parallax app note for the Sensirion SHT11
sensors with example code in basic.

I went to the Sensirion site and it appears that there are
two polynomials needed to get accurate readings. The first
to get RHuncompensated and the second to compensate
for temperature variances.

Regards

w..