DHT-22 and Beaglebone

GoogleGroups
1

Hi,

You’re right: the Adafruit code does look odd.

As you say, to initiate communication with the DHT11/DHT22, you’re supposed to pull the signal low for > 18 ms, then high, then wait for the signal to be pulled low again. Their code appears to skip the pull-high part. I can only assume that the Pi stops pulling the signal low when it switches to input mode.

The only possible problem I can see in your code is that you might not be pulling the signal low for long enough: perhaps the usleep(2000) should be usleep(20000)? Also, trying to catch that 40 microsecond signal that begins the DHT22’s response is tricky - that’s probably why the Pi’s code doesn’t pull the line high explicitly. Perhaps dropping the digitalWrite(HIGH) from your code would have the same effect?

I have my doubts about whether reading data from the DHT22 can work reliably from Linux code, given the tight timing involved. Apparently the Adafruit code is managing to do it on the Pi, but there is a warning at the beginning of their tutorial saying it may not work, and perhaps the library they are using is more optimized than what is available for the Bone.

Personally, I wimped out and use a separate processor to read the DHT22. I actually use a .Net Micro Framework processor for this (which surprisingly is able to handle the timings) and serial I/O, but something like the ATTiny2313 and I2C would be a better design.

Dan.

2

Hi,

You're right: the Adafruit code does look odd.

As you say, to initiate communication with the DHT11/DHT22, you're supposed
to pull the signal low for > 18 ms, then high, then wait for the signal to
be pulled low again. Their code appears to skip the pull-high part. I can
only assume that the Pi stops pulling the signal low when it switches to
input mode.

The only possible problem I can see in your code is that you might not be
pulling the signal low for long enough: perhaps the usleep(2000) should be
usleep(20000)? Also, trying to catch that 40 microsecond signal that begins
the DHT22's response is tricky - that's probably why the Pi's code doesn't
pull the line high explicitly. Perhaps dropping the digitalWrite(HIGH) from
your code would have the same effect?

I gave both of these a whirl, and they did not work. I am able to see
the signal on my oscilloscope, though I'm new to using the
oscilloscope, so I'm not 100% sure.

I have my doubts about whether reading data from the DHT22 can work reliably
from Linux code, given the tight timing involved. Apparently the Adafruit
code is managing to do it on the Pi, but there is a warning at the beginning
of their tutorial saying it may not work, and perhaps the library they are
using is more optimized than what is available for the Bone.

Yes, I read that. I'm starting to have the same doubts as well.

Personally, I wimped out and use a separate processor to read the DHT22. I
actually use a .Net Micro Framework processor for this (which surprisingly
is able to handle the timings) and serial I/O, but something like the
ATTiny2313 and I2C would be a better design.

I'm starting to think I might need to do the same. I'll give the Pi a
try, and I've got an Electric Imp on the way, so I'll probably try it
too.

I've built a meat curing fridge, and I'm trying to build an internet
enabled controller. I've built a monitor for it using the TI
Launchpad, and I'd like to build something that will post the
information to the internet (without hooking up to my laptop and
reading from a TTY). I suppose I could try XBee, but everything seems
much harder since I'm not using an Arduino. :frowning:

Anyway, thanks for the response. If I can't get the Pi or the Imp to
work out, I'll hook the Launchpad up to the Bone via UART.

Again, thanks for your time. I appreciate the response!

3

> Hi,
>
> You're right: the Adafruit code does look odd.
>
> As you say, to initiate communication with the DHT11/DHT22,
> you're supposed to pull the signal low for > 18 ms, then
> high, then wait for the signal to be pulled low again.
> Their code appears to skip the pull-high part. I can only
> assume that the Pi stops pulling the signal low when it
> switches to input mode.
>
> The only possible problem I can see in your code is that you
> might not be pulling the signal low for long enough: perhaps
> the usleep(2000) should be usleep(20000)? Also, trying to
> catch that 40 microsecond signal that begins the DHT22's
> response is tricky - that's probably why the Pi's code
> doesn't pull the line high explicitly. Perhaps dropping the
> digitalWrite(HIGH) from your code would have the same
> effect?

I gave both of these a whirl, and they did not work. I am
able to see the signal on my oscilloscope, though I'm new to
using the oscilloscope, so I'm not 100% sure.

> I have my doubts about whether reading data from the DHT22
> can work reliably from Linux code, given the tight timing
> involved. Apparently the Adafruit code is managing to do it
> on the Pi, but there is a warning at the beginning of their
> tutorial saying it may not work, and perhaps the library
> they are using is more optimized than what is available for
> the Bone.

Yes, I read that. I'm starting to have the same doubts as
well.

> Personally, I wimped out and use a separate processor to
> read the DHT22. I actually use a .Net Micro Framework
> processor for this (which surprisingly is able to handle the
> timings) and serial I/O, but something like the ATTiny2313
> and I2C would be a better design.

I'm starting to think I might need to do the same. I'll give
the Pi a try, and I've got an Electric Imp on the way, so
I'll probably try it too.

That would appear to be an overkill to toss in another processor.
Prehaps a different part would be more appropriate?

FWIW, I recently got a humidity sensor working on the classic
Beagle. This is the SHT-15 part. Everything pretty much was drop
in. Hookup. The setup was:

SHT-15 - <Level Converter, 3.3V source> - Beagle Classic.

Driver for it was all upstream. It is built on top of the GPIO
subsystem. The level converter and 3.3V are option on the
beaglelcd board. Write up for it will be posted as time permits.

Since IO on the bone is 3.3V, the level converter won't be
needed.

4

Yes, the SHT-15 is a good Beaglebone-compatible replacement for the DHT22, and it’s more accurate too. However, it is considerably more expensive, especially if you need a breakout board for the SMT chip: https://www.sparkfun.com/products/8257.

Another Beaglebone-compatible temperature chip is the BMP085 (it also has a kernel driver): less expensive than the SHT-15, but no humidity reading. (But you’ll know how far above sea level your meat locker is!) https://www.sparkfun.com/products/8257

The cheapest Beaglebone-compatible temperature sensor is an analog thermistor like the TMP36 (https://www.sparkfun.com/products/10988), but it also doesn’t support humidity, and is less accurate than the others.

Dan.

5

I recently adapt the adafruit DHT22 code for beaglebone : https://github.com/lhuet/beaglebone-project/tree/master/DHT22
I succeed to read Temp and Humidity with this test code.
For performance reason, GPIO have to be accessed via mmap.
The following C++ code is used for GPIO access : https://github.com/majestik666/Beagle_GPIO

Laurent

6

Hey, that’s excellent! I’ll try it out this weekend.

What error rate have you been getting in your testing?

The Raspberry Pi DHT22 code (http://learn.adafruit.com/dht-humidity-sensing-on-raspberry-pi-with-gdocs-logging/overview) has about a 5% error rate on my Pi, with the DHT22 running at 5V. The DHT22 doesn’t seem as reliable at 3.3V

Thanks,

Dan.

7

I modified my code with a checksum and add a timestamp (instead of a counter value) for detecting each bit value.
The spec give 26-28 us for a bit data ‘0’ and 70us for a bit data ‘1’.
I use the same threshold (40 us) than the arduino code : http://playground.arduino.cc/Main/DHTLib

With the counter threshold (from adafruit code), I have around 12% error rate.
With the timestamp threshoid, I have around 8/9 % error rate.
I think the counter threshold is more
I haven’t investigate more to find the reason of checksum errors.
I’m not sure that it is due to the 3.3 V.
Perhaps, these errors are due to the very short time and the lack of accuracy of the time calculation.

If I have some time, I will test the same sensor with my Rasperry Pi and with a 5V VCC (via a level shifter).

Laurent

8

Hi Laurent,

Your code works very well on my Beaglebone.

The error rate is actually a little lower than what I was seeing on the Raspberry Pi: about 4%. It’s being invoked from a Python application every 15 seconds. My Beaglebone doesn’t much CPU load: no GUI, just some Python scripts and a shell session.

I’m powering it with 5V, but you might find that yours works the same with 3.3V or 5V. Based on the comments on this Sparkfun page (https://www.sparkfun.com/products/10167), there seems to be some variation in the manufacturing quality. Mine got a much higher error rate at 3.3V, about 50%.

Thanks again for the code,

Dan.

9

Hi,
How do you specify the gpio pins for clk and data with modprobe?
Thanks,
Greg

10

Hi Greg,

There is no clk pin on the DHT22 sensor.
You don’t need to load a module with modprobe with the adafruit code or mine.
For pin wiring, you can go here : http://learn.adafruit.com/dht/connecting-to-a-dhtxx-sensor or here : http://learn.adafruit.com/dht-humidity-sensing-on-raspberry-pi-with-gdocs-logging
To specify the gpio pin, you can modify my code : https://github.com/lhuet/beaglebone-project/blob/master/DHT22/Beagle_GPIO_dht22.cc
On line 30, the gpio pin is hard-coded :


	unsigned short pin = Beagle_GPIO::P8_3;

I wrote this code to test the feasability : only a main method with hard-coded parameters.

Laurent

11

Hi Hunyue,

I am trying to get the SHT15 working on a classic Beagle.
I realise this is an old thread, but I am struggling a bit with the code.
Do you still have a code example that you could share?
Did you just connect clock and data to standard GPIO and 3.3 and ground?

Thanks,
CJ

12

You can modify this code http://www.acmesystems.it/?id=89

I have and it works on my Beaglebone black. :slight_smile:

13

Hi,

I am trying to use this code with an Adsong dht22 (am2302) temp/rh sensor running on the BBB. I haven’t used C for a number of years so I am kind of rusty. What modifications did you make to compile it with g++ on the BBB? How does portG map to the pinout on the BBB? Or what pin do I connect the data line to on the BBB?

Thanks!

14

Latest Kernel has DHT11 and DHT22 drivers under IIO subsystem. We shall see it working on BBB very soon.

regards,
Benito.

15

Could you tell me more? When and how would I get dht22 working on the BBB? Thanks!

16

What modifications did you make and would you be able to forward source code for this? Thanks.

17

no modifications needed, just follow the guide/library at adafruit

https://learn.adafruit.com/dht-humidity-sensing-on-raspberry-pi-with-gdocs-logging/overview

18

I’d Ideally like to just use C code for the DHT22 to BBB as opposed to the python library based tutorial.