Request to Reopen issue #94 'ESP8266 and DHT22: NAN errors using libraries >= 1.2.0'

I kindly request to reopen the issue #94 "ESP8266 and DHT22: NAN errors using libraries >= 1.2.0" as I do not find it is resolved yet and I have a justified reason for it. I am working on a Wemos D1 R2 board's interfacing with DHT22 sensor and as usual I have been getting the NaN errors using the given libraries. I went through all the given solutions given for issue #94 individually as well as combining, but no solution is working out for me. My Wemos D1 R2 board has nothing wrong as I have already accomplished a Data Acquisition with IoT project on it. I am not kind of a person who asks random questions. I try to solve the issue myself first. If I really find myself stuck up, I ask a question. I am being advised in issue #94 to go with other forums, but actually I would like to inform that this issue is studied, analyzed and approached the best way compared to other forums. Github has taught me never to give up, so I kindly request to reopen the issue #94 as I am the one who is still to be answered.

Shaunak Agastya Vyas

[SergiuToporjinschi]

I think I have a similar issue. I'm using an ESP8266-01 and DHT22, the esp should send the values over mqtt; After one or two days is sending only the fail of DHT reading message.
It only works if I power off the entire circuit and plug it back.

[andrewlalis]

I would just like to say that I face a similar issue with a brand new DHT22 tested with versions 1.3.0 and 1.2.3 so far, both of which return nan for the simple dhtTester sketch.

[geofbaum]

@SergiuToporjinschi please see if the information at the following link helps
https://github.com/RobTillaart/Arduino/issues/102

@andrewlalis are you only seeing the error messages from the NaN values being returned or are you seeing some valid readings interspersed with valid ones. Also have you done any of the suggested fixes from #94 ? All of these problems especially with the ESP8266 or Wemos boards probably stem back to something inherent with those boards like a clockspeed and read timing issue especially with sensors like the DHTs which are well known to be slow and very particular about how and when you read them.

[Kentric]

Same problem here. Wemos D1 R2 + DHT22. The nan errors come intermittently. I am taking readings every 5mins and some times they are fine. Fortunately my readings are not critical so I ignore the errors and continue. Seems like the nan error is mostly from the humidity sensor. I have tried everything recommended to eliminate these errors but nothing helps.

[Jaipharma]

last library version 1.3.1 is still has problem with NAN error .
because of sensor signals are vary too much from data sheet .
sensor response too fast than define in data sheet.
As I inspected in raw signal.
first low pulse from sensor come is 23-55 us
duration of first low pulse is 13-38 us (80 us (75-85) in data sheet)
seconds high pulse duration is about 35-73 us (80 us (75-85) in data sheet)

look! sometime first low signal come in 23 us and duration of pulse is 13 us.
if you use delayMicroseconds(60); 23 + 13 = 36 us , you will step over first low pulse from sensor.
then NAN reading occur.

I have modified few codes in lastest libray 1.3.1 to fix this problem like here.

uint32_t cycles[80];
{
//modified by jaipharma//
// Turn off interrupts temporarily because the next sections
// are timing critical and we don't want any interruptions.
InterruptLock lock;

// End the start signal by setting data line high for 40 microseconds.
pinMode(_pin, INPUT_PULLUP);

// Now start reading the data line to get the value from the DHT sensor.
//delayMicroseconds(60);  // Delay a bit to let sensor pull data line low.
//don't use delay
//waiting for start signal low pulse.
if (expectPulse(HIGH) == TIMEOUT) {
	DEBUG_PRINTLN(F("DHT timeout waiting for start signal low pulse."));
	_lastresult = false;
	return _lastresult;
}
//**modified by jaipharma**//

// First expect a low signal for ~80 microseconds followed by a high signal
// for ~80 microseconds again.
if (expectPulse(LOW) == TIMEOUT) {
  DEBUG_PRINTLN(F("DHT timeout waiting for start signal low pulse."));
  _lastresult = false;
  return _lastresult;
}
if (expectPulse(HIGH) == TIMEOUT) {
  DEBUG_PRINTLN(F("DHT timeout waiting for start signal high pulse."));
  _lastresult = false;
  return _lastresult;
}

.............................

full code is here https://github.com/jaicurx/DHT-sensor-library-jai

it works fine for me but sometime sensor will stop working (signal always high)
fixed by turn power off , wait a few seconds then turn power on again.
sensor will start working again.
I think DHT22 is not good enough, unstable sensor. try to use SHT3x instead.

[jotunskij]

Having the same issue here. Nodemcu/ESP8266 with brand new DHT22 just giving NaN all the time.

[ladyada]

are any of the people in this threading using both Adafruit ESP8266 board and Adafruit DHT sensors?

[khjoen]

//modified by jaipharma//
// Turn off interrupts temporarily because the next sections
// are timing critical and we don't want any interruptions.
InterruptLock lock;

// End the start signal by setting data line high for 40 microseconds.
pinMode(_pin, INPUT_PULLUP);

// Now start reading the data line to get the value from the DHT sensor.
//delayMicroseconds(60);  // Delay a bit to let sensor pull data line low.
//don't use delay
//waiting for start signal low pulse.
if (expectPulse(HIGH) == TIMEOUT) {
	DEBUG_PRINTLN(F("DHT timeout waiting for start signal low pulse."));
	_lastresult = false;
	return _lastresult;
}
//**modified by jaipharma**//

PR #70 has this kind of trick.

[mrzino]

I also had lot of issues with DHT22 and ESP8266-01. Used a 5.1k Pullup resistor. I was only getting readings from the sensor every 20th try, else just getting NAN.
I also tried the code-changes suggested by jaipharma, but that also didn't help.

I am using the same ESP8266-01 with DHT22 also with nodemcu-firmware, and there it worked nicely. Therefore I have compared their implementation (starting in line 250) with the one in this library and made few changes. Now it works nicely for me (haven't seen NAN since).

`
uint32_t cycles[80];
{
// Turn off interrupts temporarily because the next sections
// are timing critical and we don't want any interruptions.
InterruptLock lock;

// End the start signal by setting data line high for 40 microseconds.
digitalWrite(_pin, HIGH);
delayMicroseconds(40);
pinMode(_pin, INPUT);

if (expectPulse(LOW) == TIMEOUT) {
  DEBUG_PRINTLN(F("DHT timeout waiting for start signal high pulse."));
  _lastresult = false;
  return _lastresult;
}
if (expectPulse(HIGH) == TIMEOUT) {
  DEBUG_PRINTLN(F("DHT timeout waiting for start signal low pulse."));
  _lastresult = false;
  return _lastresult;
} `

I think there is a error in the sensor data-sheet. I says, that the sensor will pull up bus's voltage within 20-40us, but I think the sensor expects the MCU to do that (also also shown by the color in the chart).

Hope this helps.

[PaintYourDragon]

@mrzino Changed delay to 40 uS in latest release.

Did some further testing, ESP8266 just seems extremely finicky. You might want to try connecting the DHT sensor to a different pin and see if it helps (added some comments in the examples regarding pin selections on the Feather HUZZAH ESP8266).

[JmBelisle]

I second this request but also propose a fix.
Summary
The code of V1.3.2 occasionnally misses the first LOW DHT signal of the 80us LOW/80us HIGH signal pair that preceeds the 40 bit information data stream. This is because occasionnally, the DHT takes more that 40us (line 174) to pull the line down and thus the DHT.cpp code expecting a LOW (line 182) but reading the trailing edge of the priorly ESP generated HIGH (line 187), gets out of sync with the bit stream and interprets the trailing edge as the HIGH signal of the 80us/80us pair. When the DHT finally sends the 80usLOW/80usHIGH pair, the code incorrectly interprets it as the first data bit, thus adding a bit and throwing the ESP computed checksum out of balance with the DHT computed checksum.

The fix (tested on ESP8266 NodeMCU)
Increase the wait time before reception of the 80usLOW/80usHIGH start signal from the DHT from 40us to 50us (minimum) at line 174 in DHT.cpp.

Supporting evidence
Using V1.3.2 of the library with NodeMCU ESP8266 and Adafruit DHT22 modules.
I got 4%-8% of calls returning NAN. By going to debug mode (#define DHT_DEBUG) in dht.cpp I found that ALL errors were of type "DHT checksum failure" such as below (Italics : my program; Bold produced by dht debug mode) :
JMB : Read# 000087
Received from DHT:
80, C0, 80, 67, 28 =? 27
DHT checksum failure!
JMB : Read# 000088
Received from DHT:
1, 81, 0, CE, 50 =? 50
Looking at the 40 bit pattern of the bytes received in these 2 consecutive calls (3 seconds apart), I realized they were the same but shifted by one bit: The correct call bit pattern was the same as the Checksum failure one but shifted one bit left. As below:
80,C0,80,67,28 == 10000000,11000000,10000000,01100111,00101000
01,81,00,CE,50 == 00000001,10000001,00000000,11001110,01010000

From these observations, I surmised that the DHT22 had transmitted the right information in both cases but that somehow a leading "additional bit" had been read ahead of the correct binary sequence thus explaining the shift. Not having a scope to look at the bit stream in realtime, I modified the DHT.cpp library to :

1. capture the (duration) of the two LOW and HIGH level data pin signals (from the DHT22) that preceed the 40 bit data stream (measured in lines 182 and 187 of DHT.cpp).
2. print the duration of the 80 LOW and HIGH level data content that provide the 40 bits of data (captured in array "cycles" in lines 202 and 203). The output became :

Received from DHT:
80, C0, 80, 67, 28 =? 27
DHT checksum failure!
000 009 correspond to 80usLOW/80usHIGH start signal pair from DHT
118 80 83 82 83 83 82 83 83 103 82 83 ... LOW signal of bit signal pair
123 39 40 40 39 40 40 39 113 115 40 39 ... HIGH signal of bit signal pair
1 0 0 0 0 0 0 0 1 1 0 0 ... Resulting bit
Received from DHT:
01, 81, 00, CE, 50 =? 50
090 121
75 79 83 83 83 83 83 83 103 83 83 ... LOW signal of bit signal pair
40 40 39 39 40 39 39 113 115 39 39 ... HIGH signal of bit signal pair
0 0 0 0 0 0 0 1 1 0 0 ... Resulting bit

One reads/interprets the info as follows:
000 is the calculated duration (by DHT.cpp) of the 80usLOW part of the start signal pair
009 is the calculated duration (by DHT.cpp) of the 80usHIGH part of the start signal pair
118 is the calculated duration (by DHT.cpp) of the LOW part of the LOW/HIGH signal for the first bit
123 is the calculated duration (by DHT.cpp) of the HIGHpart of the LOW/HIGH signal for the first bit
(and given that 123 > 118) that bit is a "1".)
Note that from the read that did not generate a checksum error we see:
090 is the calculated duration (by DHT.cpp) of the 80usLOW part of the start signal pair
121 is the calculated duration (by DHT.cpp) of the 80usHIGH part of the start signal pair
Also note that 90us and 121us are larger than the 80us spec.... but this information is NOT generated from a scope so it's accuracy is not total. Suffice it to say 121 is still 50% larger than 80 and thus specs are not quite met.

Likely explanation: say the DHT pulled the line low 49us (and not 40us) after ESP relinquishes control after going to input mode; then after a 40us delay (line 174) when the ESP expects the LOW part of the start pair, the line is still HIGH from the ESP command at line 171. The code thus registers a zero LOW duration (because the line is HIGH, not low). The duration of the HIGH portion is 9us, which corresponds to difference in time between the 40us wait on part of the ESP and the 49us of actual time the DHT took to take the line down. The DHT.cpp code then begins the information bit read loop (line 201) and mistakes the now incoming start signal LOW/HIGH pair as the first bit... thus adding a bit and shifting the bit stream as we observe in the printed Debug data..

Conclusion
The fix is simply to increase the 40us delay to 50us, assuming that the 9us delay for the DHT in starting the LOW/HIGH start signal is the maximum time the DHT will ever go over the 40us spec (no certainty here).
I did that modification (50us) and ran 10000 successive reads on each of 3 DHT sensors from ADAFRUIT and got 0,35% errors over those 30000 reads. I ran the same tests with a delay of 55us and got ZERO errors over the 30000 reads. Fix is I believe simple and effective. .

Lacking a scope and a larger sample set of sensors, the 55us looks like a sound and better choice of delay. I also believe, because these errors are timing related, that the fix may not work for other platforms since I have not performed such tests. I intend to forward my proposed changes in both the debug capture and printouts, and the timing delay increase through a pull request.

jmb

[khjoen]

@PaintYourDragon and @ladyada
Please consider having a look at the line 154 to 182 of ba8cd46 in PR #70 that are mostly comments.

If @JmBelisle is right, this PR hold a solution variable waiting times from one sensor to another and/or times for the each MCU to pull the line LOW. Solution may not be ideal, but I plan on reviewing once I receive the ESP01 I ordered so I can test.

Datasheet is clear about the time to wait for a response from the sensor after the start signal is variable. Thus, no constant will work for all.

[PaintYourDragon]

1.3.3 changes the pullup time to 55 microseconds by default, which you can optionally override by passing a different value to begin(). Also added yield() immediately before and after the interrupt-disable period.

@khjoen No plans to merge PR #70 as written because the loop count will be highly variable by architecture (requiring a huge collection of #ifdefs to handle, and may change with compiler and core library updates without or knowledge). IIRC micros() typically has a 4 usec resolution which should be sufficient. But it all seems kind of moot since one of the two expectPulse() calls that follow should catch a timeout themselves anyway.