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&#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!
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/ > > >
Thanks Rich.