Adafruit_DHT_Driver incorrect readings on long wires (10m) using DHT11 + possible code fix

[the-red-o]

Adafruit_DHT_Driver incorrect reading on long wires.

I had a problem reading the temperature and humidity from the DHT11 connected to the Raspberry Pi using wires of 10 meters. The temperature reading was way too small and the humidity was in the 120-150% ranges. Various DHT11 was tested all with the same problem.

I then used Saleae Logic 16 logic analyser to inspect the signals coming into the rapberry pi. The signals coming from the DHT11 was correct. Due to a very short pulse high created by the DHT11 after the 500ms high and 20ms low and timing issues in the current driver software the error occurs. The code appends a high bit (1) to the data stream and drops the last bit which causes the error. The short high pulse is 19us for the long wires and 12us for the DHT11 directly connected to the raspberry pi.
I was able to correct the problem by adding 7 usec sleep to Adafruit_DHT.c:
…
data[0] = data[1] = data[2] = data[3] = data[4] = 0;
// inserted to compensate for long driving lines
usleep(7);

// wait for pin to drop?
while (bcm2835_gpio_lev(pin) == 1) {
usleep(1);
}
…

I hope that the above information might be helpful to others experiencing the same issue. If the above solution can be tested, adjusted and verified for the DHT22 and AM2302 it might even be included in the source.

[talkleasy]

Great piece of detective work! Solved the problem I was having on a 20 metre cable to the sensor.

Thanks very much for posting the solution.

[tdicola]

Thanks for raising the issue and apologies that it couldn't be reviewed earlier. We've actually deprecated this Adafruit_DHT_Driver code and refactored the DHT sensor reading C code into the Adafruit_Python_DHT library here: https://github.com/adafruit/Adafruit_Python_DHT The timing functions in the new library are slightly refactored to use nanosleep for longer delays and busy waiting for shorter delays. I'm curious if this helps with stability over long wires. I'll close this issue for now, but it's great to have as a reference to point folks towards if they are also using very long wires. Thanks again for raising the issue.

[gunkl]

@tdicola Fail, the new code in 1.3.1 also doesn't work for DHT11 over a long cable, in my case a rasp pi 1.

I made these changes and fixed it:
// Set pin at input.
pi_mmio_set_input(pin);
// Need a very short delay before reading pins or else value is sometimes still low.
//for (volatile int i = 0; i < 50; ++i) {
for (volatile int i = 0; i < 500; ++i) {
}

[etatus]

Thank you very much @gunkl!!!. Your fix worked like a charm for DHT22 over long cable in my RaspPi 1. (Adafruit_Python_DHT version 1.3.1)

[travc]

@tdicola, This should be reopened and @gunkl's fix (or something based on it) adopted.

[gunkl]

created pull request adafruit/Adafruit_Python_DHT#98

[bayshorebeachboy]

First thanks for this thread it seems to address the issue I am having with the dht-22, however; a question.

I made the changes to pi_2_dht_read.c and assume that this should be compiled but am unclear what (executable) to compile it to.

Or if it is compiled at runtime e.g. I am not getting the desired result i.e. I still get the same bad data on a long cable

[etatus]

@gunkl approach stopped working for me and I find a new solution here: #161