John, I think a lot of us (from beginner to very experienced) sit back in
`awe' when you, Andy, Scott, Dimitry, and many others, get into a good
discussion of algorithms ;-) Since there has been very informative
discussions of averaging in the past I thought it would be interesting to
focus on the sensor in question, HyCal's IH3602L, in a `real-world'
application. There a some interesting software issues involved. Especially
if you want to do the Dew Point and Heat Index calculations. I have already
implemented an analog front-end and data tables for math-intensive equations
but it would be interesting to look at the software alternatives.

   The HyCal sensor is similar to many others in that a change in humidity
causes a change in capacitance which changes the frequency of an oscillator.
This is converted to a voltage and is linear. Before anyone tries to hook
one up to an A/D (external or PIC) this sensor can only sink 50ua and drive
5ua so it would be a good idea to at least buffer the output. In my case I
used an LMC660 with a typical input bias current of 0.002pa. Given a buffer,
implementing an external R/C filter is trivial but for the sake of this
discussion, let's use a software filter. The low-pass filter cutoff is 1Khz.
Without the filter there is around 100-200mv AC `riding' the DC output.

   The sensor output is ratiometric with the supply voltage. With a 5V
supply the typical output span is 0.8V for 0% RH and 3.9V for 100% RH. They
are shipped with calibration data at 0% and 75.3%. In the following
examples, I'm using calibration data from my sensor and the same precision
that I use to do the math on a PIC using 32 Bit fixed-point math examples
from Microchip. I use scaling to deal with the floating point numbers.
Consider the following:

      k0  = 0.749V   Calibration at 0% RH
      k1  = 3.108V   Calibration at 75.3% RH
      m   = 0.0313   Slope of the line; k0 - k1
      t   =          Ambient Temperature at the sensor (F)
      RHs =          Sensor voltage
      RHc =          Sensor voltage compensated for Calibration.
      RHt =          RHc compensated for Temperature.

            (RHs - k0)
      RHc = ----------
                m

                     RHc
      RHt = ----------------------
            (1.093 - (0.0012 * t))

   First, assume the temperature "t" is conditioned and is available via
another A/D channel without additional processing. Since we are measuring
ambient relative humidity, let's assume that we are logging RH data once per
hour and displaying RH once per minute. During that minute, we read the RH
sensor once per second. The software filter should reduce the residual 1Khz,
100-200mv AC, to less than 1 LSB for an 8-Bit A/D with a 5.12V reference and
20mv resolution. Note, the 1 sec update relates to my system where I measure
a variety of sensors and have a lot going on in the background. If you
ignore the 1 min display update, you can read 256 samples for filtering but
I recommend using the 1 second A/D update. This would be typical for a
weather station application.

   If this topic generates any interest, I'll add the Dew Point and Heat
Index calculations which are very math-intensive. I finally went with the
`brute strength and ignorance' method which moves the result of those
calculations to external NVSRAM which also stores historical weather data
for up to a year.

   - Tom

At 05:08 PM 2/5/98 -0600, John Payson wrote:
[snip]
>There are many situations where the inputs do in fact change quite slowly;
>in one application, for example, I had to read a pot which was attached to
>a system that took over 30 seconds to move end-to-end.  Taking 100 readings
>per second gave me a maximum slew rate well above anything the system would
>actually see.  For things like thermometers and such, a filter like this
>can be useful if there are enough readings available that slew rate isn't
>a problem.
[snip]
>With any kind of filtering application, it's necessary to characterize the
>noise and the desired "real signal"; for cases where the input signal changes
>very slowly, the +/- filter can work well relative to the effort required.
>For cases where the input signal may change quickly, other types of filters
>may be better; my "other favorite" easy filtering method, btw, is Gaussian
>FIR (e.g. OUT(n) = IN(n-4)/16 + IN(n-3)/4 + 3IN(N-2)/8 + IN(N-1)/4 + IN(N)/16)
>It turns out this filter is very easy to compute, but can produce some very
>nice smoothing properties.  More on that later.