The DHT22 is a fully calibrated digital temperature and humidity sensor from Aosong that measures −40…+80 °C with ±0.5 °C typical accuracy and 0–99.9% RH with ±3% RH typical accuracy at 25 °C, both at 0.1 resolution. It speaks standard-mode I²C (100 kHz max, device address 44H) straight onto a microcontroller bus — no ADC, no signal conditioning, no per-unit calibration in firmware. With 0.2 µA typical sleep current and a 2.0 s sample period, it is built for ambient monitoring at roughly 0.5 Hz or slower, which makes it a natural fit for battery-powered logging, HVAC monitoring, and climate tracking — and an explicit no-go for safety-protection or emergency-stop roles, per the manual's own usage clause.
Most engineers meeting this part for the first time assume it's the classic single-wire DHT22 with a one-second read loop. It isn't. The datasheet describes a four-pin, I²C-style device with a hard 2.0 s sampling period, a VDD-referenced logic threshold set, and a power-up slew-rate requirement that will silently break your design if you ignore it. This post walks through the numbers that actually constrain a design — the voltage specs engineers most often misread first — then integration, testing, and troubleshooting.
DHT22 voltage range: the specs most often misread
The single most-searched DHT22 spec question is the supply voltage, so start there and work outward.
Supply: 2.8–5.5 V, with 3.3 V explicitly recommended. The datasheet states the full operating supply range as 2.8–5.5 V and calls out 3.3 V as the recommended operating point. In practice this means the part drops onto either a 3.3 V MCU rail or a legacy 5 V system without a regulator — but "valid at 5 V" is not the same as "recommended at 5 V." If your board runs at 3.3 V, feed it 3.3 V and don't overthink it.
The logic thresholds are VDD-referenced, and this is where designs break. Input high is recognized at ≥ 80% of VDD (rising edge); input low at ≤ 20% of VDD (falling edge). At 3.3 V, that means a "high" must reach 2.64 V. If you drive SCK or SDA from a 1.8 V or 2.5 V logic domain without level shifting, the sensor may simply never register a start condition — and the failure mode is total silence, not garbage data. Keep the bus swings rail-to-rail relative to the sensor's own VDD.
Output drive is weak. The low-level output is specified at a maximum of 250 mV with IO < 4 mA. That is the condition under which the VOL spec holds — sink more than 4 mA and the guarantee evaporates. Don't hang heavy loads, long unbuffered cables, or extra devices with strong pull-downs on this bus.
Power-up slew rate: ≥ 1 V/ms, and the manual requires it. This is the number nobody reads. The power-on ramp must not be slower than 1 V/ms. A rail with big bulk capacitance, a soft-start regulator, or a slowly-charging supercap can violate this and leave the sensor in a state where it never starts up properly. If your supply ramps slowly, gate the sensor's power with a load switch or a MOSFET that gives it a fast, clean edge.
Three-state off leakage is 10–20 µA. Small, but it means a high-Z pin doesn't keep the bus defined — you need a real pull-up, which brings us to wiring.
Integrating the DHT22 into a design
Four pins: VDD, SDA, GND, SCK. SDA is bidirectional data; SCK is a clock input driven by your MCU. Despite the part number, this is an I²C-style module — write your driver for I²C, not the single-wire bit-bang protocol the original DHT22 family used.
SDA needs a pull-up below 25 kΩ — this is a hard datasheet condition, not a suggestion. The high-level output spec (80–100% of VDD) is guaranteed only under the condition Rp < 25 kΩ. Exceed it and you lose the guaranteed driver-high level, which interacts badly with the 80%-of-VDD input threshold on the MCU side.
The lower bound comes from the drive spec: the pull-up current must stay comfortably under the 4 mA the pin can sink when pulling low. The math at 3.3 V:
| Pull-up (to 3.3 V) | Sink current when low |
|---|---|
| 4.7 kΩ | ≈ 0.70 mA |
| 10 kΩ | ≈ 0.33 mA |
| 25 kΩ | ≈ 0.13 mA |
Every value in that table sits far under the 4 mA limit, so the entire datasheet window is usable. A 4.7–10 kΩ pull-up to VDD is the practical pick; 10 kΩ is fine for short traces, drop toward 4.7 kΩ for longer buses or faster edges. (Note this pull-up guidance is engineering practice within the datasheet bounds — the manual doesn't publish a separate recommended-value figure.)
Decoupling: the load is tiny, so don't over-build. Supply current is 0.2 µA typical asleep and 500 µA typical while measuring, on a 2.0 s cycle. There is no switching transient to absorb. The datasheet specifies no required decoupling capacitance; a 100 nF local ceramic on VDD is standard good practice, and a bulk cap only earns its place on a long, poorly-regulated supply feed — at 500 µA the droop is negligible.
I²C protocol specifics. Device address is 44H; the sensor ACKs by pulling SDA low after the 8th SCL falling edge. The command set:
- Soft reset:
0x30A2— the datasheet lists the command but does not describe its effect on configuration (for reference, the config register's documented defaults are repeatability high and clock-stretching disabled, but the manual never states that soft reset restores them) - Trigger temperature + humidity:
2C10H; temperature only:CC44H; humidity only:CC66H - Optional coefficient/config reads: HumA high/low at
0xD208/0xD209, HumB high/low at0xD20A/0xD20B, config register0xD206
The read sequence matters: initialize/reset the sensor first, then trigger, then read. Every transmitted data value is followed by a CRC checksum — validate it on every read.
Bus speed and timing. SCL maximum is 100 kHz — standard-mode I²C only. There is no 400 kHz fast-mode figure anywhere in the manual, so don't configure your peripheral for fast mode and expect it to work. The full trigger-plus-read transaction at 100 kHz costs only about 540 µs of bus time, so bus speed is never the bottleneck — the 2.0 s sample period is.
Mounting and handling, which directly affect accuracy. Never touch the exposed sensing element; perspiration on the humidity film causes drift, and the manual directs handling with an anti-static finger cot. Store parts in original packaging at 10–50 °C and 20–60% RH — noticeably tighter than the operating window, so don't relax storage just because the part runs wide. Keep it away from solvent vapors and high-concentration chemical fumes (long exposure drifts readings), avoid volatile glue, glue tape, uncured tape, and foamed plastic packaging around it, and shade it from prolonged sunlight or UV, which accelerates aging even though the sensor isn't light-sensitive. Most importantly: mount it where its own device temperature equals the air you want to measure. Relative humidity depends heavily on temperature, and the part is factory temperature-compensated — if it sits against a hot MCU or power rail, the RH reading drifts with self-heating.
Known limitation: the manual documents resolutions and ranges but does not publish the raw-to-physical conversion formula, LSB weights, or the sign encoding for negative temperatures. The humidity value is routed through HumA/HumB coefficient registers, so the raw field is not directly %RH. Validate your conversion against a known reference condition before trusting it in firmware. The manual also contradicts itself on the humidity ceiling — the feature list says 0–100% RH while the spec table and working-conditions section say 0–99.9% RH. Design against 99.9%.
Testing the DHT22
Verify in layers, electrically first:
- Supply check: measure VDD at the sensor pins under load — confirm it's within 2.8–5.5 V and, ideally, at the recommended 3.3 V. Confirm the power-up ramp meets the ≥ 1 V/ms slew requirement with a scope on the rail at turn-on; a slow soft-start is invisible to a multimeter.
- ACK test: issue a write to address 44H and confirm the sensor pulls SDA low after the 8th SCL falling edge. No ACK at the correct address usually means a wiring, level, or pull-up problem — see the next section.
- Full transaction timing: scope SCL and confirm 100 kHz or slower with rise/fall edges ≤ 1 µs and clock pulses ≥ 5 µs. If edges are sluggish, your pull-up is too weak (too high a value).
- Data integrity: confirm a CRC byte follows every data value and that your firmware checks it. A passing CRC on repeated reads is your strongest signal the link is healthy.
- Sanity-check the physics: breathe near the sensor (humidity should rise within the < 8 s response window) and warm it gently (temperature should move within ~1 s). Readings that don't respond to real environmental steps indicate a protocol or conversion problem, not a sensor problem.
- Conversion validation: since the datasheet omits the raw-to-physical formula, compare your firmware's engineering-unit output against a trusted reference instrument at a known condition before deploying. Log raw counts alongside converted values during bring-up so you can spot scaling or sign errors (especially below 0 °C, where the sign encoding is un-documented).
Troubleshooting the DHT22
Work through these in order of likelihood:
- No ACK at address 44H: check the pull-up first — SDA needs a pull-up to VDD of less than 25 kΩ; a floating bus or a missing pull-up gives exactly this symptom. Then check logic levels: if your MCU drives highs below 80% of the sensor's VDD, the part won't see valid logic. Finally, confirm SCK is actually toggling at ≤ 100 kHz.
- Intermittent reads or CRC failures: a pull-up near the 25 kΩ limit slows edges and shrinks noise margin — drop to 4.7–10 kΩ. Also confirm bus length and that no other device is overloading the sensor's weak 4 mA drive.
- Sensor never starts after power-on: measure the supply ramp. Below 1 V/ms, the part can fail to initialize. Add a load switch for a clean fast edge.
- Stale or repeated values: you're polling faster than the 2.0 s sample period. Wait at least 2.0 s after a trigger before reading, and remember 2.0 s is the sample period, not settling time — after a real humidity step, allow the < 8 s response time before expecting the final value.
- Readings after reset are wrong or the part won't respond: the datasheet publishes no reset-recovery time for
0x30A2. Don't assume readiness after reset — retry until transactions ACK, then budget a full 2.0 s sample period before trusting fresh data. - Humidity reads biased high or drifting: check placement. Self-heating from a nearby MCU or regulator shifts RH because humidity is temperature-coupled. Also check for recent solvent exposure, condensation, or handling of the sensing element — all documented causes of drift.
- Readings drifting over months: the humidity drift spec is < 3% RH/yr and temperature < 0.2 °C/yr, so plan periodic recalibration in long deployments. Operating outside −40…+80 °C or 0–99.9% RH "may cause temporary drift" — check whether your environment exceeds the window.
- Everything checks out electrically but values look wrong: revisit the raw-to-physical conversion. The scaling, LSB weight, and negative-temperature sign encoding are not in the datasheet, and the appendix CRC/scaling code is borrowed from an SHT3x example — do not silently adopt it as this part's spec.
Two hard exclusions worth restating: the manual prohibits use in safety-protection devices or emergency-stop equipment, or anywhere a fault could cause personal injury, and prohibits use in flammable or explosive-gas environments.
Part page: DHT22.