I have been using the nerdkit for a couple of months now and have the temp sensor working. Now I want to be able to read humidity as well. I think there are some analog humidity sensors I could use - much like the temp sensor. However, I think I want to go with something a little more robust and accurate. Ultimately I want to be able to collect indoor and out door weather conditions and use the data to control my house exhaust fans - basically to economize my heating and air.

So the sensor I am considering is the sensirion SHT15 - I think it will do what I need (though I could be convinced otherwise). This sensor has a digital two wire out output. My problem is how to communicate with the ATmega168? I see this board from sparkfun.com uses the same sensor with the atmega8 MCU, so I assume this can be done. http://www.sparkfun.com/commerce/product_info.php?products_id=8311

There is a lot of info on-line about how to communicate with digital sensors, but that is actually part of my problem, there is to much info. I am having trouble focusing in on what I need.

I think I can use the digital input/output pins (PD0, PD1, and PB5 for clock) on the ATmega168 but then I assume I would I have to switch the pins when I need to communicate with my PC? Or is there better way using the Serial Peripheral Interface? I am not sure the sensor is I2C compliant, or if this matters, or exactly what this means, but there is a lot of talk on-line about I2C around the SPI. Ultimately I would like to have multiple temp/humidity sensors all talking to one MCU. I assume this requirement will influence how I setup communication from the sensors to the MCU.

I am looking for someone to validate this sensor is the right direction to go, that it will work with the ATmega168, and point me in the right direction in terms of communicating with the sensors.

Hi Dana,

Glad to hear you have the temperature sensor project working!

The house exhaust fan project sounds great. I was thinking of doing something similar where we had fans already mounted to circulate outside air through a closed attic space (or shut the windows to it), but then I moved before implementing it.

One thing I will point you to is that another customer asked about analog humidity sensors on our forums a little while ago. This uses a Honeywell sensor that appears to be in the ~$15 range. I don't know what came of that project, but I can try to contact that NerdKits user for you if you're interested! (You do have 6 analog inputs, so you could easily read 6 different analog sensors with one ATmega168.)

But the SHT15 looks fine too.

As far as communicating with the sensor: a quick glance at the datasheet tells me that the protocol does not appear to really be SPI or I2C. It's a custom, but simple, digital protocol. I think you could pick any two microcontroller pins and talk to it -- don't try to use the PD0 and PD1 pins because they'll be useful for PC communications as you mention. Say you pick PB1 for the "SCK" clock line, and PB2 for the "DATA" line. (Be aware of the note in the datasheet that says "the microcontroller must only drive DATA low. An external pull-up resistor (e.g. 10kΩ) is required to pull the signal high – it should be noted that pull-up resistors may be included in I/O circuits of microcontrollers.") I think you would then write little helper functions, that just set the pins high or low (or in the case of DATA, turn it into an input or not as well) with delays to send each bit by bit, just following along with the timing diagrams on pages 6 and 7 of the SHT15 datasheet. Does that make sense?

As far as communicating with multiple sensors: if you have enough free pins, then just allocate two pins per sensor, implementing the above for each of them. If not, it appears that you could share the DATA line between multiple sensors, and just run an individual SCK line to each one -- using (n+1) pins for n sensors.

Mike

I'm not sure if this could work, but if it just needs to be simply sent data, then possibly a I2C connection could be used. Just right to the bus, then see if there is any response from it, possibly try to read from the I2C the specific response, and not expect ACK/NAK responses. Or use "bit bashing" like in the wiring example on different data ports to do the same thing. Good Luck though, and post if you get it :)