Sensirion RH sensor Temp Compensation using an 8 bit PIC

<snipped>

>> >>
>> >>
>> >> From the data sheet for a 12 bit RH measurement:
>> >>
>> >> Temp Comp in %RH = (Temp - 25)[0.01 + 0.00008.(ADC value)] +
>> >> RHuncompensated
>> >
>> > What does the "(ADC value)" represent?
>> > How is it represented?
>>
>> 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)
>
> Represented how?  You're making it sound as if you're getting
> four BCD digits.


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.

>
> If, as is more likely, the ADC value is something in binary,
> what magic incantation is used to convert it to RHuncompensated?


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.

>
>
> I have just developed a complete temp/humidity sensor with this part
> and have all the code in C, so I thought  I would respond. By the way,
> they work very nicely and its easy to check their accuracy at various
> humidities  with pure chemical salts, one of which harmless table
> salt. Google up "salts humidity". You could also use a 30,000 dollar
> Thunder Scientific chamber.


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.


>
> If you have the time, do it right. That means
> 1. Establish the accuracy and precision of the humidity result
> your micro will report or use to make a decision. (Do you really need
> to temp comepensate the humidity, or can you ignore the uncertainty
> due to temperature)

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.


> 2. Getting the correct sequence of calculations on a piece of
> paper without regard to resolution.
> 3. Determine the size of the variable  and signed-ness (ie
> signed or unsigned)  needed to implement step 2.
> 4. Juggle it around-- maybe  its better to replace a second or
> third order polynomial calculation with a piecewise linear fit to that
> polynomial.


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.



>  5. Implement the math with the prewritten assembly routines
> provided in the microchip app notes, such as
> X*X signed or usigned addition, subtraction, multiplication,
> division
> They have assembly routines for X=8 to 32 bits, including 24
> bits. ( I would avoid 24)
>


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



> Oh, and always assume the sensor is going to fail and make sure your
> math responds like you would want it to.



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. 

On Sun, 26 Oct 2008 13:26:49 +0900, "K Ludger" <kjhi@hjhk.org> wrote:

>
>
>>
>>
>> I have just developed a complete temp/humidity sensor with this part
>> and have all the code in C, so I thought  I would respond. By the way,
>> they work very nicely and its easy to check their accuracy at various
>> humidities  with pure chemical salts, one of which harmless table
>> salt. Google up "salts humidity". You could also use a 30,000 dollar
>> Thunder Scientific chamber.
>
>
>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 would be really careful. These things are calibrated in the Thunder
Scientific cal chamber (according to Thunder and Hoerst from
Sensiron). They calibrate that to a NIST traceable standards with a
chilled mirror unit. Everyone I talked to swears by the Thunder
chamber and swears AT the GE chamber. 

I got a quote for $1000/day to use a chamber in the northeast to gain
some confidence in the devices...but we never had problems with the
salts which we purchased from a chemical house.

The salts have to be a really good paste, not too dry and not too wet.
Of course you will want to use the purest water.  As they get exposed
to the atmosphere they will pull water in or release water out
depending on the salt.  They have to be pure, and free of pollutants.

Just fyi, I have seen 10 megaohm distilled water drop to 1 megaohm in
a few hours as ionic pollutants got absorbed in the beaker. So I
always used a fresh batch of salts in a sealed container to evaluate
sensor accuracy.

>
>
>>
>> If you have the time, do it right. That means
>> 1. Establish the accuracy and precision of the humidity result
>> your micro will report or use to make a decision. (Do you really need
>> to temp comepensate the humidity, or can you ignore the uncertainty
>> due to temperature)
>
>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.
>
>
>> 2. Getting the correct sequence of calculations on a piece of
>> paper without regard to resolution.
>> 3. Determine the size of the variable  and signed-ness (ie
>> signed or unsigned)  needed to implement step 2.
>> 4. Juggle it around-- maybe  its better to replace a second or
>> third order polynomial calculation with a piecewise linear fit to that
>> polynomial.
>
>
>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.
>
>
>
>>  5. Implement the math with the prewritten assembly routines
>> provided in the microchip app notes, such as
>> X*X signed or usigned addition, subtraction, multiplication,
>> division
>> They have assembly routines for X=8 to 32 bits, including 24
>> bits. ( I would avoid 24)
>>
>
>
>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......
>
>
>
>> Oh, and always assume the sensor is going to fail and make sure your
>> math responds like you would want it to.
>
>
>
>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. 
>

Yes- assume all data is stuck at 1 or 0. This can happen with any of
the CE Immunity tests for surges, esd, or eft which give a good
starting point for whats going to happen out in the 'real world'..

The sensor had  CRC but I never used it. Anytime I use a micro to
report a transducer result, I usually include  a validity bit for the
reported data, something I learned from my days in avionics.

IIRC, the biggest  issue is when moisture actually condenses on the
sensor--- I think it reports ~0 percent instead of 100%- a very bad
situation. My spec was for a non-condensing environment, so I ignored
it. Fortunately, the device has a heater if its a problem.

"CBFalconer" <cbfalconer@yahoo.com> wrote in message 
news:4903AD07.AAF094FB@yahoo.com...
>K Ludger wrote:
>> "CBFalconer" <cbfalconer@yahoo.com> wrote:
>>> K Ludger wrote:
>>>
>>>> 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....)
>>>
>>> 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".
>
> 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.
>
> -- 
> [mail]: Chuck F (cbfalconer at maineline dot net)
> [page]: <http://cbfalconer.home.att.net>
>            Try the download section.

Here is a handy website I use a LOT for curve fitting - navigate your way to 
the polynomial/quadratic section, enter data points from your curve and it 
will calculate the coefficients for you - and tell you the likely fitting 
error ...

http://pythonequations.appspot.com/

On Fri, 24 Oct 2008 14:27:46 +0800, "K Ludger" <kjhi@hjhk.org> wrote:

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

Table lookup. Try a 5 deg increment for the temperature and a 16 digit
increment f&#4294967295;r the adc readout, prepare an excel sheet with the results and
tray to use the symmetry around 25 deg. (halves the required space). 8 bit
table values should be enough. I don't know the ADC range and number of bits
and can't decide if resolution and memory requirement fits in your project,
but at least it's a start.

If a full table gets too big, try at least to implement the term
(0.1+0.0008*ADC) by table lookup.

Mit freundlichen Gr&#4294967295;&#4294967295;en

Frank-Christian Kr&#4294967295;gel

"Richard Head" <rich.head@richoshay.com> wrote in message 
news:F7KdnRPRcZl7zZnUnZ2dnUVZ8qGdnZ2d@posted.plusnet...
>
> "CBFalconer" <cbfalconer@yahoo.com> wrote in message 
> news:4903AD07.AAF094FB@yahoo.com...
>>K Ludger wrote:
>>> "CBFalconer" <cbfalconer@yahoo.com> wrote:
>>>> K Ludger wrote:
>>>>
>>>>> 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....)
>>>>
>>>> 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".
>>
>> 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.
>>
>> -- 
>> [mail]: Chuck F (cbfalconer at maineline dot net)
>> [page]: <http://cbfalconer.home.att.net>
>>            Try the download section.
>
> Here is a handy website I use a LOT for curve fitting - navigate your way 
> to the polynomial/quadratic section, enter data points from your curve and 
> it will calculate the coefficients for you - and tell you the likely 
> fitting error ...
>
> http://pythonequations.appspot.com/
>
>
>

Thanks Rich. 

"Frank-Christian Kruegel" <dontmailme@news.invalid> wrote in message 
news:kuk8g4p0h5ls9bf43cvurrh2on5llev5v5@4ax.com...
> On Fri, 24 Oct 2008 14:27:46 +0800, "K Ludger" <kjhi@hjhk.org> wrote:
>
>>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?
>
> Table lookup. Try a 5 deg increment for the temperature and a 16 digit
> increment f&#4294967295;r the adc readout, prepare an excel sheet with the results and
> tray to use the symmetry around 25 deg. (halves the required space). 8 bit
> table values should be enough. I don't know the ADC range and number of 
> bits
> and can't decide if resolution and memory requirement fits in your 
> project,
> but at least it's a start.
>
> If a full table gets too big, try at least to implement the term
> (0.1+0.0008*ADC) by table lookup.
>
> Mit freundlichen Gr&#4294967295;&#4294967295;en
>
> Frank-Christian Kr&#4294967295;gel


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&#4294967295;n! 

K Ludger wrote:

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

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.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

K Ludger wrote:

> "Walter Banks" <walter@bytecraft.com> wrote in message
> news:4901C9E7.5B82ABC3@bytecraft.com...
> >
> >
> > K Ludger wrote:
> >
> >> 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?
>
> 0.1% precision, I've used a modified (multiplied by 10) version of
> Sensirions 2 segment linearisation and this seem work ok.
>
> >
> > 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?
> >
>
> Working temp range is 0C - 50C (32F - 120F)
>
> > 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?
> >
>
> 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%
>

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

--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com

On Oct 24, 11:58 pm, "K Ludger" <k...@hjhk.org> wrote:
> "Everett M. Greene" <moja...@mojaveg.lsan.mdsg-pacwest.com> wrote in messagenews:20081024.79D07D0.6B32@mojaveg.lsan.mdsg-pacwest.com...
>
>
>
> > "K Ludger" <k...@hjhk.org> writes:
>
> >> 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:

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