WARNING: Raspberry pi GPIO is designed for 3.3V: five volts will damage GPIO.

A short 20cm cable and 3.3V powered a successful DHT11 test. I would like to reproduce this effort with 3 DHT22 sensors at distances of 20cm , 12m and 24m.

Goals include:

  • measure temperatures at a distance from 12 and 24 meters from the rPi via DHT22
  • wire (CAT5E) to power and receive data from two DHT22s per CAT5E cable to the rPi
  • ensure the sensors are provided enough voltage, despite the voltage drop across the 12m and 24m CAT5E cable
  • minimize (eliminate) the use of level converters (3.3v <=> 5.0V)

To clarify, two cables of 12 and 24 meters, each endpoint will have two temperature sensors.

I seek to avoid:

  • damaging GPIO and stay by ensuring that it is not driven by greater than 3.3V


DHT22 sensors are powered by 12m and 24m ethernet cables:

  1. Will the sensors have enough voltage if powered at 5V?
  2. Will the data voltage returned to the rPi be at a safe 3.3V?
  3. If not, what can be done to ensure a safe 3.3V data return to the pi?
  4. The calculations below show no voltage drops at 0.1 A What (if any) flaws are in the calculation?

Any references to the topic or experience is appreciated.

Voltage drop calculations

CAT5 voltage drop calculations:

25 meter with 2-twisted pair calculation:

enter image description here

12 meter with 1-twisted pair calculation:

enter image description here


DHT11 DHT22 Electrical timing diagrams

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat. Please cut out the anecdotes.
    – Ghanima
    Feb 13, 2020 at 12:57

1 Answer 1


Voltage drop due to wire resistance is usually a non-issue unless a significant current is involved. The factor that typically leads to issues first is the capacitance of your cable.

An estimated capacitance of 10pF/feet for a twisted pair gives a value around 750pF for your longest cable. Together with the 10 kOhm pullup (inside the DHT11 sensor) the cable will effectively form a low-pass filter with a characteristic frequency of 21 kHz. The shortest pulse from DHT11 is about 25us, which will need at least 40 kHz of bandwidth to be reliably transmitted, so your cable is roughly two times too long.

You may be able to work around the issue by providing an additional external 10kOhm pullup, which DHT11 may just tolerate. This will drop the total pullup resistance to 5kOhm and increase the bandwidth, at the expense of bigger internal current in the sensor (which will likely affect precision).

  • Thanks for the analyzing the DHT11 I would appreciate your insight with similar DHT22 analysis.
    – gatorback
    Feb 13, 2020 at 14:18
  • The goal is to use the more accurate sensor: DHT22
    – gatorback
    Feb 13, 2020 at 15:08
  • @gatorback AFAIK there is no difference between the two as far as the digital signal is concerned. I have seen sites claiming that DHT22 already has a 5kOhm internal pullup, but I wouldn't trust any such value, considering if it can be trivially measured. Feb 13, 2020 at 15:41
  • If the bandwidth is insufficient should I expect to see the majority of readings to fail or be obviously incorrect, or is the symptom insidious where it is difficult to detect (i.e. only one bit is flipped per reading). I ask because I would like to understand how confident one can be when testing and reading seem good. What is the longest DHT22 distance measurement in your projects?
    – gatorback
    Feb 13, 2020 at 15:56
  • DHT sensors send a checksum with every measurement, so I fail to see the difference between "reading obviously incorrect" and " one bit flipped". Both will have a wrong checksum. Personally would aim to have a good margin and not design the system to be on the edge of that's possible, and I would consider finding a sensor which actually supports long wires (e.g. current loop / CAN interface) or wireless operation, seeing how close to the limit you are with DHT. Feb 14, 2020 at 8:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.