Humidity sensor

Well, Honeywell make some that can be connected easily (i.e. directly) to a microcontroller A/D input.

You can get them from Farnell.

I don't know about these specific sensors, but if they are like other bare sensors that I have seen, they can be easily damaged by running too much current through them for too long - especially DC. Since you are interfacing with a uC, take advantage of that fact and provide intelligent drive to the sensor. Leave it totally unpowered most of the time. Then, when you need to take a measurement, switch on the power just for the duration of the measurement. I think they require AC drive because of the chemical reaction that takes place at the terminals. If you use DC, then electrolytic deposits build up in the sensor, and it degrades. I think this is the same for pH sensors. So keep the average current as close to zero as possible, and limit the instantaneous current too. Perhaps you should use a low-leakage .33 uF cap in series with the sensor just to ensure that the average DC current is zero.

-Robert Scott Ypsilanti, Michigan (Reply through this forum, not by direct e-mail to me, as automatic reply address is fake.)

Sensirion SHT11. Simple to drive (I2Cish interface), surprisingly accurate. IIRC, Farnell has them.

- Ville

True for resisitive (polymer) humidity sensors. Not so for pH sensors, which are DC voltage sources (with awfully high impedance).

One possible configuration for a resistive sensor is to use it as a part of an oscillator. The output is then in frequency, which makes the uC interfacing easy. In many cases a simple relaxation oscillator will do.

However, do not expect vary accurate results from a resistive pH sensor. They tend to have very high temperature coefficients, and the unit-to-unit variation is significant. If the application requires only the knowledge whether there is too much water around, resistive sensors are an inexpensive and adequate solution.

- Ville

address is fake.)

The HS12P and HS15P are not bare sensors; they consist of a small PCB with a polymer sensor and a conditioning circuit. They want regulated

--Gene

^^^

"ish" is right! Fortuitously, it will work on an I2C bus (IIC if you prefer) with other devices implementing the "real" I2C protocol as it is specified.

I have always been curious (rhetorical question) -- why the I2Cish interface instead of a "standard" implementation? Licensing? It didn't make a lot of sense to me. Oh well, it works and it talks, so I used it and moved on.

-- Dan Henry

I2C is the intellectual property of Philips. Any device sold as I2C must be registered with Philips (who will grant you a device identifier) and a royalty paid. Thus, many "pseudo" I2C implementations abound.

--Gene

We asked this question (non-rhetorically) from the Sensirion people. The answer was that they did not want to pay royalties to Philips.

I am not quite sure if they would have had to pay anything even if they had realized a full I2C. AFAIK, making something that is interoperable with I2C does not require any licence

-- as long as that something is not called I2C. TWI is a commonly used acronym for "this is I2C but we do not want to call it I2C in order to avoid Philips".

I do agree that the almost-but-not-quite I2C on the Sensirion sensors is annoying. Especially because the sensors are otherwise so good.

- Ville

Those "pseudo" I2C implementations appear to use the standard signal sequences but avoid calling it "I2C". Sensirion, on the other hand, not only avoids "I2C", but also makes use of unconventional signal sequences (e.g., their so-called "Transmisstion Start" sequence). I guess they're being extra careful.

-- Dan Henry

So there we have it. Thanks for clearing that up.

Yes, I've run across the "TWI" term with other devices.

Sensirion sure would have made life easier for all of us and probably any support staff they may have if they had simply gone down the "TWI" path to avoid paying royalties and had not taken it to the next level of messing with the signalling.

-- Dan Henry