Init sequence wrong?

[baskapteijn]

Found this issue on the Adafruit dht11/22 library:

adafruit/DHT-sensor-library#48

It looks valid what the issue states. You have that same initialization sequence. Maybe verify if the libary needs to be patched?

[Erriez]

Good catch: The init sequence maybe wrong. Be careful, this library has been developed independent from other non-Erriez libraries.

The suggested Adafruit bugfix in issue #48 below is incorrect and will break ErriezDHT22:

// End the start signal by setting data line high for 40 microseconds.
// digitalWrite(_pin, HIGH); <- Remove line Adafruit library
// delayMicroseconds(40); <- Remove line Adafruit library

This is the correct initialization sequence according to the datasheet:

Original ErriezDHT22 code:

    // Change data pin to output, low, followed by high
    pinMode(_pin, OUTPUT); // <- OK
    digitalWrite(_pin, LOW); // <- OK
    delay(20); // <- OK (worst case value of 20ms Tbe)
    digitalWrite(_pin, HIGH); <- Wrong: Change to INPUT_PULLUP
    delayMicroseconds(40); <- Change Tgo to 30uS typical

    // Data pin to input
    pinMode(_pin, INPUT_PULLUP); <- No longer needed
    delayMicroseconds(10); <- No longer needed

Suggested ErriezDHT22 bugfix (tested on UNO):

    // Change data pin to output, low, followed by high
    pinMode(_pin, OUTPUT);
    digitalWrite(_pin, LOW);
    delay(20);

    // Data pin to input
    pinMode(_pin, INPUT_PULLUP);
    delayMicroseconds(30);

Can you confirm this? Then I need to test it on all devices before applying this commit.

Thanks!

[baskapteijn]

Max tgo is 200us. Shouldnt you wait max, or poll until ready? Only 30us wait might not be enough. This may be true for other waits too.

Otherwise fix seems good, it at least keeps the original functionality.

[Erriez]

The Tgo (data low) timing is generated by the master (microcontroller). According to the datasheet, this must be within minimum 20us and maximum 200us. The pinMode() and delayMicroseconds() calls are also time consuming, so the typical 30us seems to be a reliable value. Next data pulses are generated by the sensor.

I'll enter the test phase...

[baskapteijn]

Will be sufficient in most cases. For ultimate robustness on all platforms, especially fast ones, polling loops would be best. But for now, have fun testing 😀

[Erriez]

Tested on:

• Uno
• Pro micro 8MHz 3.3V
• ATMega2560
• Leonardo
• WeMos D1 & R2 (80MHz and 160MHz)
• ESP12E DevKit v2 (80MHz and 160MHz)
• Could not test ESP32 OLED (Board broken)

Fixed in commit fb62275.

[baskapteijn]

Looks good, closing issue.