Reply by Steve at fivetrees●October 28, 20082008-10-28
"K Ludger" <kjlkj@kljl.org> wrote in message
news:4906c055$0$22624$5a62ac22@per-qv1-newsreader-01.iinet.net.au...
>
> Thanks Steve.
>
> PS - you have 4 x w's in your sig.
I did, didn't I? (Confession: I type the sig, rather than paste it. Bad
habit. I typo'ed. D'oh!)
Steve
--
http://www.fivetrees.com <- that's the chap!
Reply by Walter Banks●October 28, 20082008-10-28
"Everett M. Greene" wrote:
> > 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.
>
> This suggestion is quite reasonable, but it's overkill.
> An 8:8 format would suffice as it's stated above that
> the sensor itself is only accurate to 3%. Numerical
> analysis 101 says that the result can't be more
> accurate than the data with which one starts.
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.
> If the accuracy of the sensor is as stated, a table
> lookup is probably quickest and easiest. It can
> probably be a one-point table at that.
>
> BTW: Is RH meaningful at or below freezing?
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..
Reply by K Ludger●October 28, 20082008-10-28
"Steve at fivetrees" <steve@NOSPAMTAfivetrees.com> wrote in message
news:PrSdnV-pqOfwx5vUnZ2dneKdnZydnZ2d@pipex.net...
> "K Ludger" <kjhi@hjhk.org> wrote in message
> news:49016bad$0$10566$5a62ac22@per-qv1-newsreader-01.iinet.net.au...
>>
>> I'm trying to implement temperature compensation on a Sensirion SHT11 RH
>> sensor.
>>
> <snip>
>
> Yep, been there.
>
> Forget about polynomials at runtime. Use a LUT. Devise a best-fit utility
> which will allow you to define a sequence of straight lines which fit the
> curve within the accuracy you need. Will certainly take less const data
> memory space than the difference in code.
>
> Steve
> --
> http://wwww.sfdesign.co.uk
>
Thanks Steve.
PS - you have 4 x w's in your sig.
Reply by Everett M. Greene●October 28, 20082008-10-28
Walter Banks <walter@bytecraft.com> writes:
> K Ludger wrote:
> > "Walter Banks" <walter@bytecraft.com> wrote
> > > K Ludger wrote:
> > >
> > >> I'm trying to implement temperature compensation on a Sensirion SHT11 RH
> > >> sensor.
> > > 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.
> > 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.
This suggestion is quite reasonable, but it's overkill.
An 8:8 format would suffice as it's stated above that
the sensor itself is only accurate to 3%. Numerical
analysis 101 says that the result can't be more
accurate than the data with which one starts.
If the accuracy of the sensor is as stated, a table
lookup is probably quickest and easiest. It can
probably be a one-point table at that.
BTW: Is RH meaningful at or below freezing?
> 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.
Reply by Steve at fivetrees●October 27, 20082008-10-27
"K Ludger" <kjhi@hjhk.org> wrote in message
news:49016bad$0$10566$5a62ac22@per-qv1-newsreader-01.iinet.net.au...
>
> I'm trying to implement temperature compensation on a Sensirion SHT11 RH
> sensor.
>
<snip>
Yep, been there.
Forget about polynomials at runtime. Use a LUT. Devise a best-fit utility
which will allow you to define a sequence of straight lines which fit the
curve within the accuracy you need. Will certainly take less const data
memory space than the difference in code.
Steve
--
http://wwww.sfdesign.co.uk
Reply by linnix●October 27, 20082008-10-27
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.
Reply by Walter Banks●October 26, 20082008-10-26
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
Reply by Frank Buss●October 26, 20082008-10-26
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
Reply by K Ludger●October 26, 20082008-10-26
"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�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��en
>
> Frank-Christian Kr�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�n!
Reply by K Ludger●October 26, 20082008-10-26
"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/
>
>
>