Searching \ for 'Hycal Humidity Sensor' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/io/sensors.htm?key=sensor
Search entire site for: 'Hycal Humidity Sensor'.

Truncated match.
PICList Thread
'Hycal Humidity Sensor'
1998\02\05@052226 by Tim Modra

flavicon
face
Has anyone experimented with the (Honeywell) Hycal Humidity sensor eg IH
3602 - L

I have the sensor working, but have 100mv or so of noise superimposed on
the output signal. We are building a PIC based networked temp / humidity
sensor system.

Any guidance or good alternatives appreciated.

Tim Modra: spam_OUTtimTakeThisOuTspammodra.com.au

Modra Technology: http://www.modra.com.au
Custom Sensors and Embedded Control

1998\02\05@112154 by Tom Handley

picon face
  Tim, I've designed a PIC-based weather station that uses two HyCal
humidity sensors. The outdoor sensor is an IH-3602L which comes in a T0-39
can with a slotted cap. For the indoor sensor I used the IH-3605 hybrid
element. Both sensors operate from 0 - 100% and provide an output from
around 0.8V - 3.9V with a 5V supply. They require a simple low-pass filter
and need to be shielded from sources of bright light. You do need to factor
in temperature compensation so you need to measure ambient temperature near
the sensor. I used LM34's.

  This configuration has been running over a year. Portland, OR is located
around two major rivers and there are a lot of `micro-climates' but my
sensors, and the resulting Dew Point calculation, have closely tracked the
National Weather Service at Portland's airport (PDX) which is about 3 miles
from here.

   In my application I provide a separate +5V reference to the sensors and
buffer their output with a unity-gain buffer, a low-pass R/C filter, and
another unity-gain buffer. These outputs go to a MAX186 12 Bit, 8-channel,
A/D converter. I used an LMC660 quad Op Amp for the buffers. The R/C values
are 100K and 0.1uf. If you don't have HyCal's data book, contact them at:

     (818) 444-4000

  - Tom

At 09:32 PM 2/5/98 +1100, you wrote:
{Quote hidden}

1998\02\05@124635 by Gary T. Pepper

flavicon
face
At 09:32 PM 2/5/1998 +1100, you wrote:
>Has anyone experimented with the (Honeywell) Hycal Humidity sensor eg IH
>3602 - L
>
>I have the sensor working, but have 100mv or so of noise superimposed on
>the output signal. We are building a PIC based networked temp / humidity
>sensor system.
>
>Any guidance or good alternatives appreciated.
>
>Tim Modra: timspamKILLspammodra.com.au
>
>Modra Technology: http://www.modra.com.au
>Custom Sensors and Embedded Control
>
>
Hi Tim,

Just a thought...

Although you could low-pass filter the output of the sensor to reduce the
noise, you can also take another approach, if your PIC is "idling around"
waiting to take a reading every few seconds - or whenever.  Instead of
using an op-amp to implement a low pass filter before the A/D conversion,
if the noise is random, you can implement a low-pass filter in software!
Simply take a large number of A/D samples in a given time period (say, for
the sake of arugment, in 5 seconds) and average them.  If the noise is
randomly distributed (in amplitude), then this will have the same effect as
low-pass filtering.  This works when the actual signal is a slowly varying
one w.r.t time, as is the case of the humidty sensor.

Another approach along the same lines:
If you are using an 8 bit A/D converter, you can take 256 consecutive
samples, accumulating the result in a "16 bit" register (i.e. in two
single-byte registers, one for the high byte of the sum and one for the low
byte of the sum).  After you accumulate 256 samples, simply discard the
low-byte register in the 16 bit sum.  The high-byte of the 16-bit
"register" will contain the averaged (i.e. low pass filetered) 8 bit A/D
value.

The same approach can be used to obtain 65536 averaged samples, using a "24
bit register" and so on.  The upper byte of the summation will always
contain the averaged 8-bit A/D value.

This approach is very easy to implement in software, since division is not
required, just addition!

Some food for thought....

Regards,

Gary Pepper
e-mail: .....gpepperKILLspamspam.....capitalnet.com
Ottawa, Ontario, Canada

1998\02\05@140903 by Ray Gardiner

flavicon
face
>Gary Pepper Wrote:-

>If you are using an 8 bit A/D converter, you can take 256 consecutive
>samples, accumulating the result in a "16 bit" register (i.e. in two
>single-byte registers, one for the high byte of the sum and one for the low
>byte of the sum).  After you accumulate 256 samples, simply discard the
>low-byte register in the 16 bit sum.  The high-byte of the 16-bit
>"register" will contain the averaged (i.e. low pass filetered) 8 bit A/D
>value.
>
>The same approach can be used to obtain 65536 averaged samples, using a "24
>bit register" and so on.  The upper byte of the summation will always
>contain the averaged 8-bit A/D value.
>
>This approach is very easy to implement in software, since division is not
>required, just addition!
>

Hi Tim,
Continuing on with the above idea..
If you need to convert your ADC value to engineering units, and
are oversampling to do the low pass filtering, you can make the
oversampling do the multiply portion of the scaling calculation.

ie: suppose, Humidity = ADC_VALUE * 1.73  ( or whatever) then
just accumulate 173 samples, saves doing the scaling calculation.

If you need more or less low pass filtering, just use some
power of 2 times the scaling factor. (ie 2* 4* etc) then
all you need is shift/rotates to get back to engineering units.

Ray Gardiner (DSP Systems) EraseMErayspam_OUTspamTakeThisOuTdsp-systems.com http://www.dsp-systems.com
private email to:- rayspamspam_OUTnetspace.net.au

1998\02\05@142258 by John Payson

picon face
> Although you could low-pass filter the output of the sensor to reduce the
> noise, you can also take another approach, if your PIC is "idling around"
> waiting to take a reading every few seconds - or whenever.  Instead of
> using an op-amp to implement a low pass filter before the A/D conversion,
> if the noise is random, you can implement a low-pass filter in software!
> Simply take a large number of A/D samples in a given time period (say, for
> the sake of arugment, in 5 seconds) and average them.  If the noise is
> randomly distributed (in amplitude), then this will have the same effect as
> low-pass filtering.  This works when the actual signal is a slowly varying
> one w.r.t time, as is the case of the humidty sensor.

Averaging is in many cases a less-than-ideal filtering method.  There are
some easy FIR and IIR methods that can work better.

Alternatively, you could generate a simple median filter by running the
following procedure many times a second:

 read sample
 if sample > myvalue
   myvalue = myvalue+1
 else
   myvalue = myvalue-1

This method will not respond terribly quickly to changes in the input signal
(it's sharply slew-rate limitted) but it has the advantage that a one-cycle
noise glitch will affect the output by at most one count.

1998\02\05@150519 by Andrew Warren

face
flavicon
face
John Payson <@spam@PICLISTKILLspamspamMITVMA.MIT.EDU> wrote:

> you could generate a simple median filter by running the following
> procedure many times a second:
>
>   read sample
>   if sample > myvalue
>     myvalue = myvalue+1
>   else
>     myvalue = myvalue-1
>
> This method will not respond terribly quickly to changes in the
> input signal (it's sharply slew-rate limitted)

John:

I don't think you can call this a "median filter"... Median filters
aren't slew-rate limited at all, since they only SELECT samples from
the input stream.

-Andy

=== Andrew Warren - KILLspamfastfwdKILLspamspamix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499

1998\02\05@150524 by Andrew Warren

face
flavicon
face
Gary Pepper wrote:

> >If you are using an 8 bit A/D converter, you can take 256 consecutive
> >samples, accumulating the result in a "16 bit" register (i.e. in two
> >single-byte registers, one for the high byte of the sum and one for the low
> >byte of the sum).  After you accumulate 256 samples, simply discard the
> >low-byte register in the 16 bit sum.  The high-byte of the 16-bit
> >"register" will contain the averaged (i.e. low pass filetered) 8 bit A/D
> >value.

and Ray Gardiner <RemoveMEPICLISTTakeThisOuTspamMITVMA.MIT.EDU> wrote:

> Continuing on with the above idea..
> If you need to convert your ADC value to engineering units, and are
> oversampling to do the low pass filtering, you can make the
> oversampling do the multiply portion of the scaling calculation.
>
> ie: suppose, Humidity = ADC_VALUE * 1.73  ( or whatever) then
> just accumulate 173 samples, saves doing the scaling calculation.

   Ray:

   Maybe I'm missing something, but it seems to me that summing 173
   samples and discarding the low byte will give you

       ADC_VALUE * 173/256,   NOT   ADC_VALUE * 1.73.

   If you really want to scale your input by 1.73, you'll need to
   sum 443 samples (i.e., 256 * 1.73 samples) before discarding the
   low byte.

   -Andy

=== Andrew Warren - spamBeGonefastfwdspamBeGonespamix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499

1998\02\05@153940 by John Payson

picon face
> > you could generate a simple median filter by running the following
> > procedure many times a second:
> >
> >   read sample
> >   if sample > myvalue
> >     myvalue = myvalue+1
> >   else
> >     myvalue = myvalue-1
> >
> > This method will not respond terribly quickly to changes in the
> > input signal (it's sharply slew-rate limitted)
>
> John:
>
> I don't think you can call this a "median filter"... Median filters
> aren't slew-rate limited at all, since they only SELECT samples from
> the input stream.


If the real median voltage of the input signal is stable, this method will
return it; if it changes slowly this method will track it.  The only way
the returned value can be stable (oscillating between k-1 and k) is if half
of the input signal values are >=k and half are <=k.  For slowly-changing
input signals, then, k is an excellent approximation of the median.

1998\02\05@170407 by Michael S. Hagberg

flavicon
face
>
>  read sample
>  if sample > myvalue
>    myvalue = myvalue+1
>  else
>    myvalue = myvalue-1
>

close, but if sample = myvalue skip the if statement.

michael

1998\02\05@170607 by Andrew Warren

face
flavicon
face
John Payson <TakeThisOuTPICLISTEraseMEspamspam_OUTMITVMA.MIT.EDU> wrote:

> If the real median voltage of the input signal is stable, this
> method will return it; if it changes slowly this method will track
> it.  The only way the returned value can be stable (oscillating
> between k-1 and k) is if half of the input signal values are >=k and
> half are <=k.  For slowly-changing input signals, then, k is an
> excellent approximation of the median.

John:

Yeah, but it's not what most people would call a "median filter".

The only thing that your filter has going for it, in my opinion, is
that it's real easy to implement; its performance is otherwise
pretty poor, especially -- as you've mentioned -- for all but the
slowest-changing inputs.

Personally, I don't like the fact that its output is ALWAYS pulled
one way or the other by even the smallest amount of noise... Even
though it may only jitter by one or two counts, that's less than
ideal for lots of applications.

When I hear the term "median filter", I think of a filter that moves
a window across the input data and selects the median value within
each window-position.  Since the output ONLY contains numbers that
actually appeared in the input, it doesn't slow any edges or
introduce filtering artifacts... And if your noise is of a high
frequency, that noise doesn't affect the output AT ALL.

It works like MAGIC for filtering noise from digital pulse-streams;
it pulls pulses right out of the noise even at signal-to-noise
ratios as low as 3 dB, and even with very high signal-to-noise
ratios, the pulse edges are always sharp as can be... Not slowed as
they would be by a normal low-pass filter, or REALLY slowed as they
would be with your +1/-1 filter.

-Andy

=== Andrew Warren - RemoveMEfastfwdspamTakeThisOuTix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499

1998\02\05@182957 by John Payson

picon face
> Yeah, but it's not what most people would call a "median filter".
>
> The only thing that your filter has going for it, in my opinion, is
> that it's real easy to implement; its performance is otherwise
> pretty poor, especially -- as you've mentioned -- for all but the
> slowest-changing inputs.

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.

> Personally, I don't like the fact that its output is ALWAYS pulled
> one way or the other by even the smallest amount of noise... Even
> though it may only jitter by one or two counts, that's less than
> ideal for lots of applications.

There are some easy ways of handling that; for example, if the input sample
rate is fast compared to the maximum slew rate, it's possible to change the
+/- one count to +/- 1/16 count, and round the results suitably when report-
ing.

{Quote hidden}

There are some circumstances where the +1/-1 filter works very poorly; there
are others where it works very well.  One of the problems with a median filt-
er is that its performance degrades instantly as the length of noise spikes
approaches half the median window; the noise spikes will be passed through
completely unfiltered in that case.  By contrast, the +/- filter will limit
the effect of noise spikes to be proportional to their width.

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.

1998\02\05@204233 by Ray Gardiner

flavicon
face
{Quote hidden}

Correct, however, depending on signal characteristics it's
probably not nessessary to discard all of the low byte.
However much you right-shift by needs to be included in the scaling.


A simple filter algorithm that provides "RC type" low pass filtering
that is easy to implement.

              Totalizer + Input - Previous_Output
 Output =   ------------------------------------
                           N

Notes:
1. Choose a value for N = 2^X ( ie 128,256,512 etc) makes the
  division fast and simple.

2. Sample input at equal time intervals. (probably not critical)
3. Initialize Totalizer to Input*N, or Zero ( application dependant)


Ray Gardiner (DSP Systems) rayEraseMEspam.....dsp-systems.com http://www.dsp-systems.com
private email to:- EraseMErayspamnetspace.net.au

1998\02\07@012123 by Russell McMahon

picon face
The method described is effectively "delta modulation".
An "improvement" of this incremental method would be to
increase the step size after "myvalue" failed to catch up
with the slewing input signal after a pre-selected number of
iterations. That doesn't sound very clear, does it?

Something like:

StepValue=1
Misses = 0
MissLimit = 4
Direction = 1

If MyValue <  Sample then
   MyValue = MyValue + StepValue
   If Direction = 1 then Misses = Misses + 1
   If Misses > MissLimit then
       Misses = 0
       StepValue = StepValue +1
   endif
else
   ; Slewing downward ...
   ...
endif

This is out of my head and SURE to be wrong but the
intention is that if the slew rate can't keep up with the
input signal then the step size is increased.
This can get quite complex if you don't want to overshoot
with a vengeance.
This is of course time honoured Adaptive Delta Modulation.


{Original Message removed}

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...