Page 2 of 2

Re: Question about the dht module (and maybe some more)

Posted: Sat Nov 30, 2019 4:17 pm
by Roberthh
The data sheet (at least the one I have) shows an Pull-Up resistor of 1KOhm. That is good for longish wires. The internal pull-up of the ESP8266 has a value of at least 30kOhm. That is good for a desk test, but not sufficient for longer wires. So adding an external pull-up is recommended.

Re: Question about the dht module (and maybe some more)

Posted: Sat Nov 30, 2019 7:18 pm
by MostlyHarmless
To summarize, first commit 033c32e fixed a glitch in i2c by switching the pin to IN when OPEN_DRAIN+HIGH is requested, which apparently broke some use cases of DHT22s. Then commit 18d3a5d brought back the previous behavior of mp_hal_pin_od_high() as mp_hal_pin_od_high_dht().

Note that since commit 033c32e the esp8266 port's behavior of mp_hal_pin_od_high() is identical to pin_set() when in OPEN_DRAIN mode . Note also that the esp32 port behaves different right now as it really uses OPEN_DRAIN mode and just toggles the pin's output value without changing IN/OUT at all.

I think it would be bad to leave the two ports in incompatible default behavior. My proposal is to make the esp8266 port use mp_hal_pin_od_high() by default and add a flag that lets the user specify to use mp_hal_pin_od_high_dht() instead. Something like flags=ALT_HIGH. More flags can be added if we encounter more DHT22 flavors in the future.

Going to create a new branch with that implemented.


Regards, Jan

Re: Question about the dht module (and maybe some more)

Posted: Sat Nov 30, 2019 7:52 pm
by MostlyHarmless
Roberthh wrote:
Sat Nov 30, 2019 4:17 pm
The data sheet (at least the one I have) shows an Pull-Up resistor of 1KOhm. That is good for longish wires. The internal pull-up of the ESP8266 has a value of at least 30kOhm. That is good for a desk test, but not sufficient for longer wires. So adding an external pull-up is recommended.
The one I am using had an on-board 5K1 pull-up, which I since removed for testing purposes. Works with or without it. These things really seem to be all over the map. Using two different boards and two different sensors one apparently gets 5 different behaviors.


Regards, Jan

Re: Question about the dht module (and maybe some more)

Posted: Sat Nov 30, 2019 9:32 pm
by MostlyHarmless

Re: Question about the dht module (and maybe some more)

Posted: Sun Dec 01, 2019 7:27 pm
by MostlyHarmless
MostlyHarmless wrote:
Sat Nov 30, 2019 9:32 pm
How about this?

https://github.com/wieck/micropython/tr ... stom-delay
Forget that.

I combined it all into one commit, added the necessary documentation changes and create a pull request.

https://github.com/micropython/micropyt ... 49f5ef85dd


Best Regards, Jan

Re: Question about the dht module (and maybe some more)

Posted: Sat Apr 02, 2022 12:05 am
by random-builder
Another solution for a similar problem (random timeout errors in DHT):
re-implement driver in viper for total control of DHT protocol parameters.
https://github.com/micropython/micropyt ... 1086420730