Description
Dear all,
there is an mistake in your DHT11 init sequence. Admittedly, the DHT11 datasheet is not very clear here. Anyhow, after you pulled the data line low for the at least 18 milliseconds to signal the DHT11 a start, you should NOT actively pull it up. As soon as the DHT does see the low-high transition on the data line ( Well "as soon is around 12 usec later ) it tries to pull it down. If the data line is still held "high" by the uC at that time, you have more or less a short circuit on the data line with the uC pulling up and the DHT pulling down.
This can clearly be seen on an oscilloscope if your lib is used "as is".
You need to change the uC pin state to "INPUT" after the initial >18 msec LOW phase right away, without actively pulling up before.
Luckily this bugfix is as easy as commenting out two lines, see below:
'''
// End the start signal by setting data line high for 40 microseconds.
// digitalWrite(_pin, HIGH);
// delayMicroseconds(40);
// WEB: This is an error. DHT tries to pull the line low as soon as it came back to high.
// therefore the low-high transition after the start signal "low" needs to be realised by
// the pullup resistor only, uC pin must already be in INPUT mode.
'''
See attached before-after scope screenshots
after, with fixed startup sequence:
With best regards,
Wolfgang Ebersbach
Activity
asetyde commentedon Dec 2, 2015
Which platform do you use ?
This bug influence quality of reading ,?
You speak about last build ?
Sent from my iPhone
W-E commentedon Dec 4, 2015
Hi asetyde,
I do use ESP8266 with the arduino ESP package, Arduino V1.6.5 but that does not matter. The code is just wrong. DHT11 tries to pull the data line low as soon as it went up after the >18msec LOW phase. This is not uC related but DHT11 related. The issue likely came from the unclear wording in the DHT11 datasheet.
Anyhow, as soon as you end the >18msec LOW phase, the uC pin has to go to INPUT or HIGH-Z (high-z does not exist in Arduino).
Wolfgang
W-E commentedon Dec 4, 2015
Oh, and yes, it DOES influence the quality of the readings. At least if connected to the ESP8266 GPIO #2, the original lib returned "NAN" about every 10th read. The modified lib now performed around 50.000 reads with zero errors ( I added success/fail counters to the code ).
Even if it would not change the readings: Do not drive one physical line with two output drivers at the same time. You just don't.
Wolfgang
asetyde commentedon Dec 5, 2015
I ask to you because my nodemcu sometime it block itself and I don't know why , I try to restore library to 1.1.1 but i don't know how can I do .. I can not records with ide many hours of serial .. But block it showed in MySQL table .. Often after 3h or 7h many times, tomorrow I try to cut sensor and isolate issue , but if it dht ? I change many sensor but it mustn't block device !
Sent from my iPhone
krzychb commentedon Dec 20, 2015
Hi Wolfgang,
Thank you for posting this fix together with detailed test results including sexy waveforms 😄 👍
I am writing a tutorial on automatic humidity control using ESP8266 and after longer testing discovered similar issue. I like to use adafruit library as it is slick and mature, very well commented in code and available for installation right out of Arduino IDE. For these reasons I was reluctant to replace it and started searching for issue reports and luckily found your post!
I was observing random DHT22 / AM2302 read failures using this library together with Arduino Due and now with ESP8266. I do not observe so big failure rate like you, but still see one
nan
/Failed to read from DHT sensor!
per couple of dozen measurements. I guess the actual failure rate may depend on value of pull up resistor, power supply quality or on particular sensors itself that I am using.Anyway, after applying your fix the issue vanished 💨
Thank you again for contribution of this fix 👍
Krzysztof
Removed "End the start signal by setting data line high for 40 micros…
W-E commentedon Dec 20, 2015
Dear Krzysztof,
welcome.
I use Arduino if I have a small non-professional project that I need to slap together in no time. This is because I discovered that many Arduino libraries have a poor quality, including the "official integrated" ones like the LCD lib.
The Arduino IDE / toolchain also is not super reliable. E.g. the LCD lib does output different bitstreams to the connected LCD depending on if it is compiled with the OSX version of the toolchain or the windows version. I did not take the time to track down if it's the compiler or some compiler options or the library itself.
Many libs have poor or no error checking, are not protected against buffer overflows and so on.
Just as a rule of thumb: If you do something that later "goes public as a product" either do not use Arduino or check any used library for mistakes.
To bring that above complaining to the right perspective: I think the Arduino project is GREAT. They found the right balance between hiding hardware ( register ) complexitivity and making things too simplified ( and therefor to much constrained ). I also like the business model of financing this entire thing with sold hardware. So, yes I like Arduino. No, I do not recommend it for professional product development. I mostly like that there is plenty of overall good documentation.
Regards,
Wolfgang
Am 20.12.2015 um 12:07 schrieb krzychb:
Koepel commentedon Feb 7, 2016
I agree with W-E, the MCU should never make the pin output and high. After investigating most known DHT datasheets, I think it is obvious that it will cause a "more or less" shortcut between the MCU and the microcontroller inside the DHT. Thank you for the pictures of that shortcut W-E.
At this moment a forum topic is about that : http://forum.arduino.cc/index.php?topic=377413.0
greggubben commentedon Feb 13, 2016
Thank you Wolfgang for posting this fix. After following your advice to add the pull up resistor and comment out the 2 lines, I am getting much cleaner reads from the DHT-11.
I was able to reproduce your before and after scope screenshots with my ESP8266 and DHT-11. This really needs to get into the main library. In the mean time I have made the changes in my fork.
Thanks again,
Gregg
renno-bih commentedon Feb 16, 2016
Thanx @W-E , before this modification I couldn't get good reading most of the time. After fix it works noticeable better but sill get
Failed to read from DHT sensor!
every 5-10 readings.What pull up resistor do you use? Do you use third parameter in
DHT dht(DHTPIN, DHTTYPE);
W-E commentedon Feb 17, 2016
Hi Renno,
I did use 4k7 pullup. I believe ( I do not have the code here now ) that
the DHT lib documentation says there are three parameters: DHTPIN,
DHTTYPE , TIMING where Timing is a value that influences the DHT bus
timing and should be set to 11 at the ESP.
At the other hand, if you look into the lib, it seems the lib now
calculates it's own timing, so this third parameter seems to be obsolete.
Oh, I just looked at Github and now the example is adapted:
// Initialize DHT sensor.
// Note that older versions of this library took an optional third
parameter to
// tweak the timings for faster processors. This parameter is no longer
needed
// as the current DHT reading algorithm adjusts itself to work on faster
procs.
DHT dht(DHTPIN, DHTTYPE);
So, no, no additional parameter.
Regards,
Wolfgang
Am 16.02.2016 um 14:05 schrieb renno-bih:
renno-bih commentedon Feb 17, 2016
I tried with 4k3 resistor and without third parameter but still can see lot of bad readings. ( I read
2147483647
value every 5-10 readings.)Only way to deal with this is to reject all readings that contain that value.
Also tried another DHT11 sensor and DHT22 sensor, both give some false readings.
It only happens with my ESP12-E module, with Arduino Uno it always show good values.
If sensor is not faulty there must be something to do with ESP8266.
krzychb commentedon Feb 17, 2016
@renno-bih,
Do you see false readings on bare example sketch?
Krzysztof
renno-bih commentedon Feb 17, 2016
Yes, here are some readings:
44 remaining items