2
\$\begingroup\$

Duplicate of https://raspberrypi.stackexchange.com/questions/91781/dht22-bad-readings-on-long-cable, I figured there is chances people here have a solution for me.

Hi,

I'm preparing a setup with a long wire separating the sensors and the rpi. Wire is a cat6 RJ45 (ethernet) cable of 100ft (30m), that i'm using 6/8 wires. I randomly choose the wires, I figured as long as I take the same one at the other end, it should work. And it does, for the most part.

I've drawn my wiring to fitzing to explain it. See below. Some notes to take into consideration:

  • For the RJ45 in the drawing, assume the white wire is partially colored of the closest wire on it's left. For exemple, the first wire is orange, and the second one is white-orange.
  • For the resistor, horizontal ones are 10k and vertical ones are 1k.
  • white-green and white-blue are not used, so i merged them on one end and put them to GND on the other end. Before doing that, I had interference between IRLed and button switches

fritzing schema schematics

DHT22 readings are done in python, every minutes, using Adafruit_Python_DHT 1.4.0. Exact code for DHT22 in this public repo: https://github.com/Ericmas001/hq-dht22-reader-docker/blob/master/exec/hq_dht22_reader.py

My problem is: DHT22 readings are 99% wrong. I'm reading 10.3°C (50°F) and 3288.7% humidity most of the time. Correct readings would be around 24°C (75°F) and 21% humidity. Funny enough, I get correct reading somethign like twice an hour.

Currently, it's a 100ft (30m) cable but it's only as a proof of concept, PI and sensors are really no more then 10ft (3m) appart.

I've tried switching wires (to rule out that the problem was bad wiring within the RJ45) but result is always the same.

I've also tried using a 10ft (3m) jumper wire for the yellow wire (bypassing RJ45) and then, everything works fine.

So the problem seems to be because of the length of the wire.

I've done some research, and found out that there was similar problems for other people with the library

Unfortunately, those problem have all been resolved with recent 1.4.0 release, that I happen to be using in my setup.

Does somebody knows how to resolve my issue. ?

Also, you can assume this:

  • Electric & electronic knowledge are very limited on my part. I'm learning using the internet and doing this as a hobby.
  • I would prefer if solution is on the pi-side of the RJ45, since the sensor-side would be in the wall
  • For the proof of concept, RJ45 and jumperwire are twisted together with wire caps.

enter image description here

Thanks, have a nice day !

\$\endgroup\$
  • \$\begingroup\$ Have you thought about using a remote microcontroller (Arduino, ESP32, ESP8266 or Wemos) with the sensor so that you don't exceed the spec'd range for the DHT22. If you use an ESPxx or Wemos it can connect with WiFi (only requirement is power at the remote end). You could even run your Raspberry as an access point for that. \$\endgroup\$ – Dougie Dec 9 '18 at 21:06
  • \$\begingroup\$ If that's not possible you're going to have to test whether adding some noise suppressing capacitors at the Raspberry end of the long wire will clean up the signal from the DHT22 to make it reliable. \$\endgroup\$ – Dougie Dec 9 '18 at 21:07
  • \$\begingroup\$ I'm not familiar with capacitors. Where would I put it on the wiring schema, and what would be the correct µF to use for my use case ? \$\endgroup\$ – ericmas001 Dec 9 '18 at 21:14
  • 3
    \$\begingroup\$ While the wiring setup is nice to show how a mess this is to wire up on breadboard, it's really hard to follow. Please also supply a schematic. \$\endgroup\$ – Marcus Müller Dec 9 '18 at 22:49
  • 1
    \$\begingroup\$ @MarcusMüller I've added schematics, I hope I got it right. \$\endgroup\$ – ericmas001 Dec 10 '18 at 4:04
2
\$\begingroup\$

Your sensor isn't meant to drive meters of cabling. That's simply not what it was designed for.

The idea to use Cat6 cabling is good, and I can see that it comes from the realization that ethernet over such cable works over long distances, too.

However, in ethernet, the twisted pairs of the signal lines are driven differentially (i.e. the current on one conductor is the opposite of that on the other, and at the receiving end, the difference between potentials is evaluated), and great care is taken to ensure the signal is robustly read and reconstructed.

Your circuitry has no measures whatsoever to fulfill the same role, so it simply doesn't work over a long distance of cabling, where you simply lose a lot of voltage to ohmic drop over distance, where you get the full length as antenna or secondary winding to a parasitic transformer with the power grid, and, most importantly here, where you take no steps to help the transmitter drive the capacitive and inductive load that the long wire represents.

For this to work, you'd need to change a few things:

  • long runs of twisted pair really aren't good for low-voltage power transfer. Use transformers to step up your voltage at the feeding end, and step down at the receiving end.
  • You'll need single-ended-to-differential conversion at the sensor end, and the opposite at the receiver end.
  • You'll need to match the impedances.
  • Not quite sure what the voltage divider in the sensor's data line does – but it does look to me like unnecesary load to the sensor. However, this will be obsolete by itself when you use the differential transceivers
  • I don't know what speeds you need from the IR transmitter – but it was a good idea to use something to increase the drive strength of your Pi. However, instead of using a transistor at the transmitting end only, you'll want a schmitt-trigger buffer + drive transistor at the receiving end, or go for differential transceiver + driving transistor right away
  • This all considered, it's usually simpler to go and have a small microcontroller at one end of such a long line that does all the local interfacing, and only needs a single link over the long distance. If you go that route, you could probably even just use I²C instead of differential transceivers; low-speed I²C is relatively robust, and all non-least-cost microcontrollers come with I²C masters integrated, and the Pi can also act as I²C device; there's even kernel drivers.
  • If you want to try I²C: there's actually sensors other than the slightly underdocumented DHT22 (where do people even find these things?!) that speak I²C themselves (example temperature sensor, example humidity + temperature sensor). That would save you quite a bit of trouble, as you could, without any further ado (actually: maybe a pull-up resistor) attach that thing to the Pi.
  • If you actually want to do it like the "big kids": Industrial sensors typically are just supplied with a constant current (somewhere in the 4–20 mA range), and you'd read out the value by the voltage drop across sensor + cabling. Current loops are insensitive to cabling resistance.
\$\endgroup\$
  • \$\begingroup\$ Thanks for the detailed answer, I will look into everything you just said see what I can implement. Also, you never mentionned capacitors. I've seen them used in different scenarios close to mine, and some suggested on the other thread that it could help me. Could it ? For the voltage divider on the sensor, i'm not sure either, this was my last attempt to make it work, the original wiring was only the 10K resistor, with no 1K->GND. \$\endgroup\$ – ericmas001 Dec 10 '18 at 4:27
  • \$\begingroup\$ About I²C, i've read a little and i'm confused. You talk about a single link, but is'nt it 3 wires (GND, SDA, SCL) ? And were you suggesting I replace ALL the setup by placing a micro controller on the sensor-side (ex: arduino nano) and then communicating to the pi, or replacing only the DHT22 part of the setup ? If it's all, i'm confused since the pi would be the communication trigger for the IR and the DHT, but the switch on the sensor side would be another communication trigger, would it still work ? \$\endgroup\$ – ericmas001 Dec 10 '18 at 4:49
  • \$\begingroup\$ @ericmas001 yep, "hide" all the remote things behind the microcontroller. You're right, the master would typically have to poll or you'd need another interrupt line. \$\endgroup\$ – Marcus Müller Dec 10 '18 at 9:14
  • \$\begingroup\$ Actually @joan 's PIGPIO library can be set to use an additional arbitrary pair of GPIO pins to provide a second I²C bus SCL/SDA wires which can be set to run at a slower clock rate - and be thus more resistant to timing errors and other effects from driving long-distance buses, whilst retaining the existing bus for local (to the RPi) stuff. Also, transceiver devices, such as the P82B715PN are specifically designed to send and receive I²C over longer distances - they provide the grunt needed to drive the longer lines (and the terminating resistors at the ends to damp down reflections)... \$\endgroup\$ – SlySven Dec 13 '18 at 4:24
  • \$\begingroup\$ See also: electronics.stackexchange.com/q/109631/124900 electronics.stackexchange.com/questions/106265/… ! \$\endgroup\$ – SlySven Dec 13 '18 at 4:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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