Sensirion RH sensor Temp Compensation using an 8 bit PIC

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

-- Walter Banks Byte Craft Limited

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 does the "(ADC value)" represent? How is it represented? The second "." in "0.00008.(ADC value)" is an asterisk?

Scaled, fixed-point arithmetic.

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.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
            Try the download section.

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.

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.

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

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

Represented how? You're making it sound as if you're getting four BCD digits.

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

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]: 
            Try the download section.

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.

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.

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.

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

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

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:

and who knows how to write a parser:

and a PIC compiler:

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

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

messagenews: snipped-for-privacy@mojaveg.lsan.mdsg-pacwest.com...

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