Searching \ for 'Hycal Humidity Sensor - IH3602L Application' in subject line. ()
Help us get a faster server
FAQ page: techref.massmind.org/techref/io/sensors.htm?key=sensor
Search entire site for: 'Hycal Humidity Sensor - IH3602L Application'.

Truncated match.
'Hycal Humidity Sensor - IH3602L Application'
1998\02\06@104222 by

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.
On Fri, 6 Feb 1998 07:40:51 -0800 Tom Handley <thandleyTELEPORT.COM>
writes:

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

Can you get a sample of the oscillator frequency out of the sensor?  It
is simple to count with a PIC, much harder to deal with analog.  You'd
need calibration data in terms of frequency too.

_____________________________________________________________________
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]
Mike, you could extract the frequency but it would defeat the
purpose of using a sensor with a linear DC output. This would
require extracting a ~100-200mv signal riding the DC. For low-cost
applications, you could use a basic sensor element such as Philip's
but you would need much more support circuitry for the oscillator.
I'm sure there are conditioned, calibrated, sensors with a frequency

- Tom

At 01:04 PM 2/6/98 -0500, you wrote:
{Quote hidden}

At 07:40 AM 6/2/98 -0800, you wrote:
>   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.
>       .... <snip>

Please carry on. Its definately very interesting.

Rajnish.
At 02:16 AM 7/2/98 -0800, you wrote:
>   Mike, you could extract the frequency but it would defeat the
>purpose of using a sensor with a linear DC output. This would
>require extracting a ~100-200mv signal riding the DC. For low-cost
>applications, you could use a basic sensor element such as Philip's
>but you would need much more support circuitry for the oscillator.
>I'm sure there are conditioned, calibrated, sensors with a frequency
>
>   - Tom

Hi,

I am having problem sourcing the Philips Humidity Sensor. If you are using
them I would be obliged if you could suggest a source. I wrote to the
undermentioned company. They initially told me it was ex-stock after which
when I asked them to send me a quote they backed out. I feel they do not
have it. BTW I need 25 Pcs.

>>>Cliff Parkinson
>>>
>>>PO Box 100-544 NSMC Auckland New Zealand
>>>Sales Tel: +64-9-443 9500
>>>           +64-4-915 9500
>>>Facsimile: +64-9-443 9502

Thanks,

Rajnish.
Rajnish, I've never used the Philip's sensor. I have only looked at
the data sheets when I was specifying sensors for my project.

- Tom

At 12:22 PM 2/7/98 -0500, you wrote:
>At 02:16 AM 7/2/98 -0800, you wrote:
[snip]
>>For low-cost
>>applications, you could use a basic sensor element such as Philip's
>>but you would need much more support circuitry for the oscillator.
[snip]
{Quote hidden}

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