Image: bone-debian-8.7-iot-armhf-2017-02-05-4gb
Sensor: Aosong AM2302
I’m trying, without success, to setup a Temperature/Humidity on my brand new BBGW.
I tried to follow several tutorials (https://learn.adafruit.com/dht-humidity-sensing-on-raspberry-pi-with-gdocs-logging/software-install-updated) and this is my wiring:
I tried to give 5V or 3.3V.
I tried to change GPIO (even on P9)
I tried with and without resistance.
I tried the same sensor on a UDOO Neo and it works, even without resistance.
I’m using th Adafruit_Python_DHT library and it returns errors:
`
root@beaglebone:~/Adafruit_Python_DHT/examples# ./AdafruitDHT.py 2302 P8_11
Failed to get reading. Try again!
root@beaglebone:~/Adafruit_Python_DHT/examples# ./AdafruitDHT.py 22 P8_11
Failed to get reading. Try again!
root@beaglebone:~/Adafruit_Python_DHT/examples# ./AdafruitDHT.py 11 P8_11
Failed to get reading. Try again!
`
What’s missing? Any suggestion?
Thank you!!
On Sat, 11 Feb 2017 10:38:18 -0800 (PST), Davide Aguiari
<gorghino@gmail.com> declaimed the following:
root@beaglebone:~/Adafruit_Python_DHT/examples# ./AdafruitDHT.py 2302 P8_11
Failed to get reading. Try again!
root@beaglebone:~/Adafruit_Python_DHT/examples# ./AdafruitDHT.py 22 P8_11
Failed to get reading. Try again!
root@beaglebone:~/Adafruit_Python_DHT/examples# ./AdafruitDHT.py 11 P8_11
Failed to get reading. Try again!
What's missing? Any suggestion?
Well, the first thing is directly from the web page:
Yes I read about it, but I tried several times without success.
I will try again tomorrow, but It’s supposed to work 3 times of 4, not 1 of 10…
I’m trying to figure out if the other steps (wiring, os, configs…) are fine.
Have I set something to use the GPIO before installing the library?
On Sun, 12 Feb 2017 02:54:10 -0800 (PST), Davide Aguiari
<gorghino@gmail.com> declaimed the following:
Yes I read about it, but I tried several times without success.
I will try again tomorrow, but It's supposed to work 3 times of 4, not 1 of
10..
Note that the article originally came out in 2012, and was last updated
2015. Are you running Wheezy or Jessie? It's possible Jessie has changed
things enough to affect the timing -- especially if you are entering the
demo program command at the console each time (the process start-up may be
reproducing similar system timing, resulting in failure).
Try modifying the demo program to loop internally -- maybe counting how
many failures it gets before a successful read.
Try running the demo at a higher priority level
I tried with the latest stable image too. Fresh flash with dd.
cat /etc/dogtag
BeagleBoard.org Debian Image 2016-11-06
uname -a
Linux beaglebone 4.4.30-ti-r64 #1 SMP Fri Nov 4 21:23:33 UTC 2016 armv7l GNU/Linux
cat /etc/debian_version
8.6
I installed the Adafruit library (Log: http://pastebin.com/53K438mP).
I put a while in the demo script and I run it with nice --10 without success.
The problem is that it NEVER gets a value. It always fails. 
I also change the wires with new ones.
Is my board broken?
The problem is here, in bbb_dht_read.c
// Record pulse widths for the expected result bits.
for (int i=0; i < DHT_PULSES*2; i+=2) {
// Count how long pin is low and store in pulseCounts[i]
while (!bbb_mmio_input(pin)) {
if (++pulseCounts[i] >= DHT_MAXCOUNT) {
// Timeout waiting for response.
set_default_priority();
printf(“PulseCounts[i]: %d \n”,pulseCounts[i]);
return DHT_ERROR_TIMEOUT;
}
}
bbb_mmio_input(pin) returns 0 too much time and it returns DHT_ERROR_TIMEOUT.
On Mon, 13 Feb 2017 04:57:49 -0800 (PST), Davide Aguiari
<gorghino@gmail.com> declaimed the following:
The problem is here, in bbb_dht_read.c
// Record pulse widths for the expected result bits.
for (int i=0; i < DHT_PULSES*2; i+=2) {
// Count how long pin is low and store in pulseCounts[i]
while (!bbb_mmio_input(pin)) {
if (++pulseCounts[i] >= DHT_MAXCOUNT) {
// Timeout waiting for response.
set_default_priority();
printf("PulseCounts[i]: %d \n",pulseCounts[i]);
return DHT_ERROR_TIMEOUT;
}
}
bbb_mmio_input(pin) returns 0 too much time and it returns
DHT_ERROR_TIMEOUT.
At this stage I'd recommend either: a) try the sensor on something
without an OS -- an Arduino, for example (I'm sure AdaFruit have a library
for those); or b) tap into the lines with an oscilloscope (or logic
analyzer) to check for 1) the "wake-up" signal sent by the BBB to the
device and 2) the variable width return data from the device. {Worst case,
tap into the signal line with a transistor driving an LED -- you might be
able see the LED flicker during the pulse train}
If you don't see the "wake-up" pulse, you likely have a misconfigured
output GPIO pin. If you see that pulse but nothing coming back you have a
faulty sensor. If you see the return pulse sequence you likely have a
misconfigured input GPIO pin. As I recall, these sensors use the same pin
for both, which means being able to toggle the pin from output to input
during the short period after the "wake-up" and before the device starts
responding. I'd hope the library does that -- but if it didn't set
pull-up/pull-down you may have the wrong state on the line.
I can confirm the sensor works with a Cortex M4 microcontroller (Udoo neo full) with an Arduino sketch with Adafruit Arduino library.
Same wires, same jumpers.
On Mon, 13 Feb 2017 07:36:31 -0800 (PST), Davide Aguiari
<gorghino@gmail.com> declaimed the following:
I can confirm the sensor works with a Cortex M4 microcontroller (Udoo neo
full) with an Arduino sketch with Adafruit Arduino library.
Same wires, same jumpers.
Well, since you've verified the sensor works, that leaves checking for
activity on the pin(s): oscilloscope, logic analyzer, etc. to see if the
wake up goes out, and if the sensor is sending a pulse train in response.
Based on a datasheet for a DHT-11, the device uses active-low logic.
That means there should be a pull-up resistor somewhere on the data pin (as
I recall, these can be configured internal to the BBB when setting up the
pin mode). This can be checked with a DVM -- when the program is NOT
running, the data pin should show 3.3V IF there is a pull-up on it
(unfortunately, DVMs and VOMs are too slow to detect the wake-up -- when
the data line is set to 0V, nor the pulse train response [a VOM may
register a voltage between 0 and 3.3V during the response -- as it
"averages" the high and low periods])
While it won't read the device, you could use the DVM with the sysfs
GPIO access to confirm you have the proper pin... P8_11 is "gpio45"; set to
output, and then set to 1 or 0 and check the voltage for each.
I SOLVED. The problem was that eMMC was taking the gpio control while I’m using a SD card.
I decommented this in /boot/uEnv.txt
dtb=am335x-bonegreen-overlay.dtb
and now I get values on gpios!
Thank you 
