DHT Humidity Sensing - Raspberry Pi with Google Docs logging

[adafruit]

DHT Humidity Sensing - Raspberry Pi with Google Docs logging

Time to start exploring more sensors with the Raspberry Pi! Here's a fun tutorial using DHT11, DHT22 and AM2302 humidity and temperature sensors.

In this tutorial we’ll be showing how to utilize C for high-speed GPIO polling to handle bit-banged sensor output. Many low cost sensors have unusual output formats, and in this case, a “Manchester-esque” output that is not SPI, I2C or 1-Wire compatible must be polled continuously by the Pi to decode. Luckily, the C GPIO libraries are fast enough to decode the output.

http://youtu.be/Skr2uPZzviM

http://learn.adafruit.com/dht-humidity- ... cs-logging

[NewPi]

Awesome, thanks for posting this. I was looking for something like this to get started with my first electronics hobby project - a basic temperature and humidity sensor using Rpi.

Can we use this instead of DHT11/22 - http://www.adafruit.com/products/381, if yes do we need to change anything ?

[adafruit]

see:

http://learn.adafruit.com/dht-humidity- ... the-c-code

"First up, we'll test the C code to verify it works. Wire up a DHT sensor connected up so the data line is on GPIO #4, and powered to 3.3V and ground. If you are using a DHT11 or DHT22 you should add a 4.7K - 10KΩ resistor between the Data pin and the VCC pin.

Then run

sudo ./Adafruit_DHT type pin#"

cheers!

[NewPi]

see:

http://learn.adafruit.com/dht-humidity- ... the-c-code

"First up, we'll test the C code to verify it works. Wire up a DHT sensor connected up so the data line is on GPIO #4, and powered to 3.3V and ground. If you are using a DHT11 or DHT22 you should add a 4.7K - 10KΩ resistor between the Data pin and the VCC pin.

Then run

sudo ./Adafruit_DHT type pin#"

cheers!

Thanks, but my question was will adafruit "Waterproof DS18B20 Digital temperature sensor" work the same way or will there be any changes needed, or could there be any compatibility issues ?

[adafruit]

Thanks, but my question was will adafruit "Waterproof DS18B20 Digital temperature sensor" work the same way or will there be any changes needed, or could there be any compatibility issues ?

sorry, it was unclear that "this" meant you wrote:

Can we use this instead of DHT11/22 - http://www.adafruit.com/products/381, if yes do we need to change anything ?

if this="Waterproof DS18B20 Digital temperature sensor", then no - completely different sensor.

cheers!

[NewPi]

if this="Waterproof DS18B20 Digital temperature sensor", then no - completely different sensor.

cheers!

Oops should have linked http://www.adafruit.com/products/381 right after the word "this". Having a waterproof temperature and humidity sensor communicate with rpi would have definitely been more tempting for external environment data logging (imagine cheap weather data collecting rpi's scattered all across the globe uploading real-time environment data to internet).

Would hope you would post something related in near future

[adafruit]

stay tuned, we have a few hundred tutorials on the way...

[RaspberryGeek]

hi adafruit,

I'm stuggling to get the code working

sourced my adafruit parts from the UK (skpang) code appeared to install fine.

I can get my pi to talk happily to a BMP085 and have used the skpang traffic lights program, so i know that generally it can communicate fine.. here's what i get:

Code: Select all

pi@raspberrypi ~/dev/adafruit/DHT_Driver $ sudo ./Adafruit_DHT 22 4
Using pin #4
Data (0): 0x0 0x0 0x0 0x0 0x0

What steps should I take to debug ensure that the drivers are working?

Thanks
Gordon

[adafruit]

hmm, try another a pin just in case - make sure you have a pull resistor... a scope' is the best tool to help troubleshoot too!

[monirul.pathan]

I'm getting the same result as RaspberryGeek with an RHT-03 which is essentially the same as the DHT-22. Have tried other pins as well but no luck.

Code: Select all

pi@raspberrypi ~/Adafruit-Raspberry-Pi-Python-Code/Adafruit_DHT_Driver $ sudo ./Adafruit_DHT 22 4
Using pin #4
Data (0): 0x0 0x0 0x0 0x0 0x0

[danpeirce]

stay tuned, we have a few hundred tutorials on the way...

I am curious about the Google doc's side of the project using the python package. Can you point out where we can find more documentation on that? Any security issues?

[adafruit]

http://learn.adafruit.com/dht-humidity- ... oogle-docs

[RaspberryGeek]

Yep have got a pull up resistor installed, no access to a a scope (got a FLUKE multi-tester )

Have tried different pins, same answer - could it be the DHT22 ?

Scope arriving tomorrow - ho to use it?

[RaspberryGeek]

OK, got a scope - DSO Nano V2 , uprgraded to BenF 3.64
And the scope works just fine.
I can connect the probe leads to the data and grnd,

What settings should I use on the scope (TD, TriggerAuto / Scan, etc) and what am I looking for?

Also got a couple more DHT22's which turned out to be RHT03's - allegedly the same but see here:
https://www.sparkfun.com/products/10167
should we connect pin 3 to 4 to ground?

[RaspberryGeek]

OK, so the data pin goes low and then high when running the code sudo ./Adafruit_DHT
here are the Oscilloscpe traces:

https://picasaweb.google.com/1132605127 ... directlink

[RaspberryGeek]

OK so there's a bug in the C codeing

I wrote a litlle python routine to set the pin high and low, and if i run that in between trying to run the C routing, it gives me the reading everytime!

So £80 spent on an oscilloscope .... - Lesson learnt!

I'll spend some time over the weekend finding out just what the bug is!

[lcd15000]

Any chance on getting a dht python library?

[RaspberryGeek]

Problem is apparently the speed of access via python hence the C application,

According to Adafruit:

Since the DHT sensors use a low-level "Manchester-esque" timing protocol to send data, we need to be able to read the pin they are connected to at very high speeds. The python libraries aren't fast enough, but the low level C libraries are! The code we wrote is a good example of how to deal with bitbang in user space, without the need to write a kernel driver

Except the code doesn't work 'out of the box' ...

[discovery]

I'm also getting the same result as RaspberryGeek and monirul.pathan with an DHT22. This is not working.

[lcd15000]

I am seeing that the driver does not work as well

pi@raspberrypi ~ $ uname -a
Linux raspberrypi 3.2.27+ #102 PREEMPT Sat Sep 1 01:00:50 BST 2012 armv6l GNU/Linux

root@raspberrypi:/home/pi/adafruit-Adafruit-Raspberry-Pi-Python-Code-1495781/Adafruit_DHT_Driver# while true; do ./ Adafruit_DHT 2302 4;sleep 10;done
Using pin #4
Data (0): 0x0 0x0 0x0 0x0 0x0
Using pin #4
Data (0): 0x0 0x0 0x0 0x0 0x0
Using pin #4
Data (0): 0x0 0x0 0x0 0x0 0x0
Using pin #4
Data (0): 0x0 0x0 0x0 0x0 0x0
Using pin #4
Data (0): 0x0 0x0 0x0 0x0 0x0
Using pin #4
Data (0): 0x0 0x0 0x0 0x0 0x0
Using pin #4
Data (0): 0x0 0x0 0x0 0x0 0x0
Using pin #4
Data (0): 0x0 0x0 0x0 0x0 0x0
Using pin #4
Data (0): 0x0 0x0 0x0 0x0 0x0
Using pin #4
Data (0): 0x0 0x0 0x0 0x0 0x0
Using pin #4
Data (0): 0x0 0x0 0x0 0x0 0x0
^C

[lcd15000]

I tried the Occidentalisv02 image and got the same responses as well

Linux raspberrypi 3.1.9adafruit+ #10 PREEMPT Thu Aug 30 20:07:05 EDT 2012 armv6l GNU/Linux


Using pin #4
Data (0): 0x0 0x0 0x0 0x0 0x0

Using pin #4
Data (0): 0x0 0x0 0x0 0x0 0x0

Using pin #4
Data (0): 0x0 0x0 0x0 0x0 0x0

Using pin #4
Data (0): 0x0 0x0 0x0 0x0 0x0

Using pin #4
Data (0): 0x0 0x0 0x0 0x0 0x0

Using pin #4
Data (0): 0x0 0x0 0x0 0x0 0x0

[lcd15000]

after messing around with it for a little while and adding a 10k resistor, I can sometimes get it to respond, but I can not figure out why, it will only work once then not:


$ sudo ./test.py
Using pin #4
Data (40): 0x1 0x86 0x1 0x16 0x9e
Temp = 27.8 *C, Hum = 39.0 %

Temperature: 27.8 C
Humidity: 39.0 %
Using pin #4
Data (0): 0x0 0x0 0x0 0x0 0x0

Using pin #4
Data (0): 0x0 0x0 0x0 0x0 0x0

Using pin #4
Data (0): 0x0 0x0 0x0 0x0 0x0

Using pin #4
Data (0): 0x0 0x0 0x0 0x0 0x0

Using pin #4
Data (0): 0x0 0x0 0x0 0x0 0x0

Using pin #4
Data (0): 0x0 0x0 0x0 0x0 0x0

Using pin #4
Data (0): 0x0 0x0 0x0 0x0 0x0

Using pin #4
Data (0): 0x0 0x0 0x0 0x0 0x0

Using pin #4
Data (0): 0x0 0x0 0x0 0x0 0x0

^CTraceback (most recent call last):
File "./test.py", line 16, in <module>
time.sleep(3)
KeyboardInterrupt

[alex25]

Same as for lcd15000
Most of the time only 0x0 data from the sensor. Only very rarely the correct values.

OK so there's a bug in the C codeing

I wrote a litlle python routine to set the pin high and low, and if i run that in between trying to run the C routing, it gives me the reading everytime!

@RaspberryGeek. Can you share your solution?

Thanks

[lcd15000]

@alex25 and @RaspberryGeek I took a look at the C code from the DHT library and found this, not sure what the purpose is to set the pin high sleep then set it low. I am not a programer by any means, but when I get a few min I may try to hack this up a bit to see what happens. After all that is what this platform is supposed to inspire right?

Code: Select all

 77   // Set GPIO pin to output
 78   bcm2835_gpio_fsel(pin, BCM2835_GPIO_FSEL_OUTP);
 79   bcm2835_gpio_write(pin, HIGH);
 80   usleep(100);
 81   bcm2835_gpio_write(pin, LOW);
 82   usleep(20000);
 83   bcm2835_gpio_fsel(pin, BCM2835_GPIO_FSEL_INPT);
 84 
 85   data[0] = data[1] = data[2] = data[3] = data[4] = 0;

[alex25]

@alex25 and @RaspberryGeek I took a look at the C code from the DHT library and found this, not sure what the purpose is to set the pin high sleep then set it low. I am not a programer by any means, but when I get a few min I may try to hack this up a bit to see what happens. After all that is what this platform is supposed to inspire right?

Code: Select all

 77   // Set GPIO pin to output
 78   bcm2835_gpio_fsel(pin, BCM2835_GPIO_FSEL_OUTP);
 79   bcm2835_gpio_write(pin, HIGH);
 80   usleep(100);
 81   bcm2835_gpio_write(pin, LOW);
 82   usleep(20000);
 83   bcm2835_gpio_fsel(pin, BCM2835_GPIO_FSEL_INPT);
 84 
 85   data[0] = data[1] = data[2] = data[3] = data[4] = 0;

Indeed. If I set the waiting time between the HIGH and LOW phase to 500ms (500'000us) the sensor replies with the correct values most of the time. However, from time to time I still get faulty values. But great progress so far. Thanks