# DHT21 / AM2301 sensor not measuring humidity

I am trying to use a DHT21 with a Lamobo R1 aka Banana PI R1 to read temperature and humidity, with Armbian/Jessie and a 4.5.2 kernel. A Lamobo R1 is basically an A20 board raspberry pi compatible, with an inverted compatible raspberry pi 2 bus.

I have setup it up in GPIO5, raspberry pin compatible 24, WirinPi 5, physical pin 18, according to a table here, plus the GND and +5V pins.

I tried to read the temperature and humidity with and without the recommended resistor. While the temperature is reading fine, and is also corroborated by a DS18b20 sensor connected to GPIO2, the humidity is always at 99.9%.

I have installed the WiringPi compatible library from WiringBP repository.

However, using for instance DHT21-AM2301 or lol_dht22 I have got always the output of Humidity as 99.9% or 99.90%

A custom kernel module for this chip, am2301 simply hangs the machine.

What I have found until now is:

• It seems to work with Raspberry and Arduino;
• The DHT21 is highly sensitive to timings, even in the original raspberry;
• Some people did report it only worked in GPIO1 and GPIO2 in the original raspberry, whilst the other GPIOs had much greater latency;
• There is a much more complicated hardware setup to connect it to a I2C, in which I am not particularly interested;
• Some people also theorise it only works with kernel 3;
• The Lamobo R1 seems to have a pullup pin bus by default;
• Readings can be done only every second due to chipset limitations;
• The physical implementation of the R1 bus compared to the rpi allows me to get by without the resistor;
• The limit of cable seems to be 25m, and there are anecdotal tales of people achieving 60m with UTP cable. Mine is no longer than 20cm;
• It cannot be exposed to direct sunlight due to maintaining the chemical balance;
• Said chemical balance degrades over time (2-3 years?).

Does anyone has anything else to add?

• Humidity comes first than temperature;
• As @ChrisStratton correctly theorised, humidity bits are all 1;
• I have already tested two DHT21 sensors with the same results.

The output of

gpio readall


is

+----------+-Rev3-+------+--------+------+-------+
| wiringPi | GPIO | Phys | Name   | Mode | Value |
+----------+------+------+--------+------+-------+
|      0   |  17  |  11  | GPIO 0 | IN   | Low   |
|      1   |  18  |  12  | GPIO 1 | IN   | High  |
|      2   |  27  |  13  | GPIO 2 | IN   | Low   |
|      3   |  22  |  15  | GPIO 3 | IN   | Low   |
|      4   |  23  |  16  | GPIO 4 | IN   | Low   |
|      5   |  24  |  18  | GPIO 5 | OUT  | High  |
|      6   |  25  |  22  | GPIO 6 | IN   | Low   |
|      7   |   4  |   7  | GPIO 7 | IN   | Low   |
|      8   |   2  |   3  | SDA    | ALT5 | High  |
|      9   |   3  |   5  | SCL    | ALT5 | High  |
|     10   |   8  |  24  | CE0    | IN   | Low   |
|     11   |   7  |  26  | CE1    | IN   | Low   |
|     12   |  10  |  19  | MOSI   | ALT5 | Low   |
|     13   |   9  |  21  | MISO   | ALT5 | Low   |
|     14   |  11  |  23  | SCLK   | ALT5 | Low   |
|     15   |  14  |   8  | TxD    | ALT0 | Low   |
|     16   |  15  |  10  | RxD    | ALT0 | Low   |
|     17   |  28  |   3  | GPIO 8 | IN   | Low   |
|     18   |  29  |   4  | GPIO 9 | ALT4 | Low   |
|     19   |  30  |   5  | GPIO10 | OUT  | High  |
|     20   |  31  |   6  | GPIO11 | ALT4 | Low   |
+----------+------+------+--------+------+-------+


• Trying to bit-bang a serial bus from application software under a multi-tasking operating system can be difficult, as it is hard to achieve precise timing. You would generally be better off delegating the task to a hardware engine (like the I2C block, though this chip is not natively I2C) or a kernel mode driver. Debugging the kernel driver could be a worthy project - get printk's in there and see what is happening. You may also want to use a scope on the data line. In many cases a cheap cy7c68013 based logic analyzer will help, but this signal could have analog issues that need a scope. – Chris Stratton May 26 '16 at 15:05
• If you get desperate and just want results, you could use some cheap MCU as a delegate to read the sensor and then report back to the embedded linux board via a UART, I2C, SPI, whatever - this also gives you an easy point of compatibility to change out systems on either side of, a single point for any voltage conversion needed, etc. – Chris Stratton May 26 '16 at 15:06
• You might also try to work backwards through the code and see what sort of raw bit pattern from the sensor would be responsible for an alleged 99% humidity. Patterns like all ones or zeroes are highly suspect as communication issues. – Chris Stratton May 26 '16 at 17:51
• @ChrisStratton I have indeed followed the code. Interesting tidbit, humidity comes first, and temperature last. It seems to be a all ones situation indeed. I will be testing in the next couple of days another DHT21 to see if it is by chance a broken device, or some timing problem. I also know Lamobo as pullup bus by default...maybe a line of code, or some setup. will first try another DHT21. – Rui F Ribeiro May 27 '16 at 7:28

As per the datasheet, the DHT21 timings are shorter with 3.3V and longer with 5V. I switched it from 5V to 3.3V and now it reads the humidity properly. It seems that while in the Arduino you have it at 5V, the software side/routines for the banana pi and raspberry are assuming it is connected at 3.3V.

From the software mentioned in the question, the fastest seems to be lol_dht22. I am using a slightly changed version of it (by myself), that creates files in /var/run aprox every 9-10 seconds to feed rpimonitor.

As @ChrisStratton correctly says, this method of bit banging/polling is highly prone to errors, especially when running in user land.

The simple protocol checksum implemented by the DHT21 is clearly not strong enough to weed out most of the errors/spikes (and there are many). I had to add simple software correction routines to ignore out of place values, and even then there are spikes.

The code for reading the DHT11/DHT21/DHT22 sensors is at my github https://github.com/ruyrybeyro/rdht .

I was also in doubt wether I would need to touch the R1 device tree configuration, as I did to configure the 1Wire protocol with another temperature sensor. It was not needed.

As an additional note, care must be taken when following blindly schematics online. While the Arduino bus operates at +5V, raspberry and compatibles operate at +3V; while apparently it is not the case of the DHT21 (I stress apparently as the R1 bus is more resilient than the rpi bus), feeding at random devices/sensors from +5V connected to an rpi bus can be potentially harmful to your SBC.

The measured temperature(s) also seems consistently to be higher +2 Celsius than what they should be, and these temperature inconsistencies are reported by many others using DHT21 devices.

• I'm glad to hear you had some success, however I would continue to in general caution against trying to bit-bang something with specific timing requirements from user-mode code that is subject to variable behind-the-scenes delays. You risk a system which fails some of the time, or one that may fail substantially when something seemingly unrelated changes - for example, it might not work when on a network with a lot of broadcast packets the kernel must consider. – Chris Stratton May 27 '16 at 19:41
• @ChrisStratton Thanks for all the insights and for your time. – Rui F Ribeiro May 27 '16 at 19:54

Humidity reading is 99.9% when you supply the sensor with 5V. Try supplying it with 3,3V and it will work. I tested a circuit with an MCU on 5V and only when the AM2301 is on 3,3V, does it work as expected.

• That what my own answer says in the 1st paragraph. There might be more to it, it depends on the characteristics of the sensor, the equipment, and how much the CPU is loaded with this method of reading. – Rui F Ribeiro Nov 18 '16 at 9:59