[Bug] DHT.h : Incorrect COUNT value for Arduino Uno R3 (16 MHz) causes sensor communication failure

[SNT-RABELAIS]

The latest version of the Grove_Temperature_And_Humidity_Sensor library (via DHT.h) does not work correctly with an Arduino Uno R3 (16 MHz). The DHT11 sensor fails to return valid data, which appears to be caused by an incorrect COUNT macro value for 16 MHz microcontrollers.

The latest version of the Grove_Temperature_And_Humidity_Sensor library (via DHT.h) does not work correctly with an Arduino Uno R3 (16 MHz). The DHT11 sensor fails to return valid data, which appears to be caused by an incorrect COUNT macro value for 16 MHz microcontrollers.

The DHT11 sensor should work correctly with an Arduino Uno R3, as it did with previous versions of the library.

Actual Behavior:
Communication with the sensor consistently fails.

Root Cause :
In the DHT.h file, the COUNT value for 16 MHz microcontrollers is set to 2 (line 17):
#elif (F_CPU >= 15400000UL) && (F_CPU <= 19000000L)
#define COUNT 2
This value is incorrect for the Arduino Uno R3. In previous versions of the library, COUNT was set to 6 for 16 MHz, which allowed proper operation.

Proposed fix:
Change the COUNT value for 16 MHz microcontrollers in DHT.h:
#elif (F_CPU >= 15400000UL) && (F_CPU <= 19000000L)
#define COUNT 6

Additional Information:
The previous version of the library (with COUNT = 6 for 16 MHz) works correctly.

[baorepo]

Hi @SNT-RABELAIS,

Thanks for the detailed report. You're correct — this is a real bug introduced by commit 69cabab9, which reduced all COUNT values across the board without proper validation.

Root Cause

The COUNT macro serves as a pulse-width threshold in the DHT bit-banging read loop:

while (digitalRead(_pin) == laststate) {
    counter++;
    delayMicroseconds(1);
}
// ...
if (counter > _count) {
    data[j / 8] |= 1;  // '1' bit
}

On 16 MHz AVR, each loop iteration takes ~4-5µs due to digitalRead() overhead. A DHT '0' bit pulse (~26µs) yields counter ≈ 5-6, while a '1' bit pulse (~70µs) yields counter ≈ 14-17. With COUNT=2, even a '0' bit exceeds the threshold, so all bits are incorrectly read as '1'.

The previous value of COUNT=6 was correct and had been working for years.

Fix

I've opened PR #28 which restores all the previously working COUNT values. This affects not just 16 MHz but all CPU frequencies, as the bad commit reduced them all incorrectly.

Thanks again for catching this!