If you are building a weather station, greenhouse monitor, or HVAC controller, the sensor DHT22 (also sold as the AM2302) is likely on your workbench. Unlike analog sensors that require ADC scaling, the DHT22 outputs a strictly digital serial signal over a single data wire. It operates on a supply range of 3.3V to 5.5V, requires a 4.7kΩ pull-up resistor on the data line, and demands a strict 2-second polling interval. This guide bypasses the generic library overviews and breaks down the exact hardware physics, bit-level math, and failure modes you need to deploy this sensor reliably in the field.
How the DHT22 Actually Measures the Air
The DHT22 relies on two distinct physical transducers housed inside its white plastic shell. For humidity, it uses a capacitive sensor consisting of a moisture-holding polymer dielectric sandwiched between two metal electrodes. As ambient water vapor absorbs into the polymer, the dielectric constant changes, increasing the capacitance proportionally to the relative humidity. Simultaneously, an internal NTC (Negative Temperature Coefficient) thermistor measures ambient heat; as temperature rises, the thermistor's electrical resistance drops predictably.
Rather than outputting raw analog voltages from these elements, the DHT22 contains an internal 8-bit ASIC (Application-Specific Integrated Circuit). This microchip continuously samples the capacitance and resistance, applies factory-calibrated linearization to the non-linear NTC curve, and stores the final digitized values in its internal registers. When your microcontroller triggers a read command, the ASIC shifts this data out serially, meaning you never have to deal with analog noise or ADC reference voltage drift on your host board.
Wiring the DHT22 to an ESP32 or Arduino
The physical pinout of the bare DHT22 component is straightforward, but the omission of the pull-up resistor is the number one reason prototypes fail on the bench. The sensor uses a single-bus protocol that requires the host microcontroller to pull the line low to initiate communication, and the sensor to pull the line low to transmit bits. A pull-up resistor is mandatory to return the line to a HIGH state between bits.
| Pin Number | Label | Connection Target | Notes & Constraints |
|---|---|---|---|
| 1 | VCC | 3.3V or 5V Supply | Operating range is 3.3V to 5.5V. Use 5V for wire runs over 2 meters to overcome voltage drop. |
| 2 | DATA | MCU GPIO Pin | Must have a 4.7kΩ resistor tied between DATA and VCC. Do not use internal MCU pull-ups; they are typically 30kΩ-50kΩ and too weak for this protocol's rise-time requirements. |
| 3 | NC | Not Connected | Leave floating. Internally unconnected. |
| 4 | GND | System Ground | Must share a common ground plane with the MCU. |
Decoding the Output: From Raw Bits to Celsius and %RH
The DHT22 output is entirely digital. It does not output an analog voltage, nor does it use standard I2C or SPI. It uses a proprietary single-bus serial protocol. A successful read yields exactly 40 bits (5 bytes) of data. Understanding the raw-to-unit math is critical for debugging when a library throws a 'Checksum Error' or returns impossible values like 32,000% humidity.
The 40-bit packet is structured as follows:
- Byte 1 & 2: Humidity (16-bit integer)
- Byte 3 & 4: Temperature (16-bit integer)
- Byte 5: Checksum (8-bit integer)
The Raw-to-Unit Math
Factory calibration is baked into the ASIC, so no user scaling matrices are required. You simply apply a divide-by-10 operation to the raw decimal values.
Humidity Calculation:
The 16-bit humidity value is always positive. Combine the two bytes and divide by 10.
Example: Raw bytes are 0x02 and 0x8B. Combined hex is 0x028B, which is 651 in decimal.
651 / 10 = 65.1% RH.
Temperature Calculation:
The first bit (Bit 15) of the temperature word is the sign bit (0 = positive, 1 = negative). Bits 0-14 represent the magnitude. Strip the sign bit, convert to decimal, and divide by 10.
Example (Positive): Raw bytes are 0x01 and 0x1A. Bit 15 is 0. Combined magnitude is 0x011A (282 decimal).
282 / 10 = 28.2°C.
Example (Negative): Raw bytes are 0x80 and 0x65. Bit 15 is 1 (negative). Stripping the sign bit leaves 0x0065 (101 decimal).
101 / 10 = -10.1°C.
Checksum Verification:
Add the first four bytes together and keep only the lowest 8 bits (bitwise AND with 0xFF).
(0x02 + 0x8B + 0x01 + 0x1A) = 0xA6. If Byte 5 is 0xA6, the packet is valid. For deeper protocol timing and bit-shifting logic, refer to the Adafruit DHT Guide.
Real-World Interference and Failure Modes
While the DHT22 is robust in controlled environments, field deployments frequently encounter specific interference sources that corrupt the single-bus protocol.
- Wire Capacitance and Rise-Time Degradation: The protocol relies on microsecond-level timing. A 5V logic HIGH is achieved via the 4.7kΩ pull-up resistor. If your data wire exceeds 5 meters, the parasitic capacitance of the wire forms an RC low-pass filter with the pull-up resistor. This slows the voltage rise time, causing the ESP32 or Arduino to misinterpret bit boundaries. Fix: Use 3.3V logic level shifters or drop to a 2.2kΩ pull-up resistor for long runs to charge the wire capacitance faster.
- Electromagnetic Interference (EMI): Because the data line is high-impedance when floating HIGH, running the sensor cable parallel to AC mains wiring or near inductive loads (like relay coils or AC motors) will inject voltage spikes. These spikes mimic the sensor's 'LOW' pulses, resulting in corrupted checksums. Fix: Use shielded twisted-pair cable (like CAT5) and tie the shield to GND at the MCU end only.
- Polymer Membrane Saturation: If exposed to direct condensation or submerged in water, the capacitive polymer becomes fully saturated. The sensor will lock at a reading of 99.9% RH and may take hours or days to dry out and return to baseline. Fix: Mount the sensor in a louvered radiation shield or use a PTFE membrane cap if high-moisture environments are expected.
- Polling Rate Violations: The DHT22 ASIC requires roughly 1.5 seconds to sample the environment and update its registers. If your code polls the sensor every 500ms, you will either get stale data or trigger a timeout state in the sensor's state machine. Always enforce a strict
delay(2000)or non-blocking 2-second timer between reads.
Frequently Asked Questions
Why is my DHT22 sensor reading 99.9% humidity constantly?
A locked 99.9% reading almost always indicates that the internal capacitive polymer has absorbed liquid water, not just vapor. This happens when the sensor is placed in an environment where the temperature drops below the dew point, causing condensation directly on the sensor element. Move the sensor to a dry, room-temperature environment for 24 hours to allow the polymer to off-gas the moisture. If it remains stuck at 99.9% after drying, the dielectric layer is permanently compromised and the unit must be replaced.
Can I wire multiple DHT22 sensors to the same ESP32 data pin?
Technically, the single-bus protocol allows multiple devices on one wire, but unlike Dallas DS18B20 temperature sensors, the DHT22 lacks a unique 64-bit ROM serial number. It has no way to address a specific sensor on the bus. If you wire three DHT22s to one pin, they will all attempt to drive the data line low simultaneously when polled, causing a collision and a checksum failure. You must assign one dedicated GPIO pin per DHT22 sensor.
DHT22 vs DHT11: Is the upgrade worth the extra cost?
Yes, for almost all practical applications. The DHT11 costs around $1.50 but is limited to a 0-50°C range, 20-80% RH range, and offers poor 1.0°C / 1% resolution. The DHT22 (approx. $4.50) expands the range to -40°C to 80°C and 0-100% RH, with a much tighter 0.1°C / 0.1% resolution and ±0.5°C accuracy. For indoor comfort monitoring, the DHT11 is acceptable; for outdoor weather stations, incubators, or greenhouse control, the DHT22 is the absolute minimum viable component. For a visual breakdown of the internal ASIC differences, see this DHT22 hardware teardown.
Why do I get 'Checksum Error' or 'Timeout' in my Arduino/ESP32 code?
These errors mean the microcontroller successfully initiated the start pulse, but the 40-bit return packet was either missing, truncated, or mathematically invalid. The top three culprits are: (1) You forgot the external 4.7kΩ pull-up resistor, leaving the line floating and susceptible to noise. (2) Your code is polling the sensor faster than the 2-second hardware limit, causing the sensor's internal state machine to ignore the start pulse. (3) You are powering the sensor from the ESP32's 3.3V pin, but your wire run is too long, causing the voltage at the sensor's VCC pin to droop below the 3.1V brownout threshold during the high-current transmission phase.
