Could my choice of cable be why my DS18B20 sensor isn't found?

Question

I'm building a project with the DS18B20 temperature sensor and a Raspberry Pi (among other things) This temperature sensor needs to be a little distance from my Pi as it is an weatherproof external sensor for my project. I have this version of the sensor: https://www.adafruit.com/product/381

In order to extend the cable from the sensor to my Pi I have attached (by braiding the wires) a typical (for the UK) 3 core cable that was previously used for a plug extension. It is approximately 6 meters long and being a max 240v/13amp cable has quite thick gauge wire compared to the very small gauge wire I'm using for the microcontroller work. The sensor is wired to my Pi according to this schematic:

In my breadboarding stage without the extension this was fine and I could read from this sensor. However now my Pi does not detect any sensor attached via the 1 wire interface. I has assumed that the thick gauge wire would have a lower resistance and not cause issues to the low power 3.3v Pi power supply to the sensor. However am I mistaken?

It is possible that the use of this length of a thick gauge wire could be the issue? How could I verify that this wasn't an issue? (would reading the voltages at the end of the extension prove anything?) If the cable is the problem what could be a better alternative? (using 3 lines from an ethernet cable?)

If the cable is not a theoretical issue then I will have to debug by disassembly and a process of elimination of faults on the line. Thanks for helping with my lack of electrical theory.

Answer 1

I've got a lot of 1wire sensors in the house running without trouble. The longest cable is about 20m, and I get about one error per million reads. The micro sits next to a heat pump with a big three phase motor, and there are DS18B20 sensors inside the heat pump, taped to the pipes to measure temperatures. Apparently it is not bothered by the EMI from the motor.

I use Cat5 cable. 1wire is not a differential protocol, but it is still possible to exploit twisted pair to get a bit of noise reduction. I use one pair for data/ground, and another pair for VCC/ground.

Each sensor has a decoupling cap between VCC and GND, which is whatever electrolytic I had lying around, a few tens of µF. I also added a 5V TVS between data and ground.

The micro is an ESP32, which runs on 3V3, so I added a MOSFET to translate the voltage to 5V on the data line, for better noise immunity.

There is also a 75R source termination resistor on the output, not shown on the schematic (and probably unnecessary), and a 5V TVS on connector on the micro board. The TVS is not about signal integrity, it is to protect both the micro and sensors in case of lightning-induced voltage spikes on the line.

The signals look good, it works fine.

Most of the read errors came from bad software. In fact, I had to rewrite the 1wire arduino library. 1wire requires accurate timing, and on ESP32 the provided delayMicroseconds() function is not usable, because it adds a few microseconds to the requested delay, and this added delay is not constant. This means the official library does not work. It works fine on other platforms that have a working delayMicroseconds() function, of course. So I would recommend a close investigation of the timings.

Note that the dodgy software worked fine with short cables, because the timing was marginal, close to failure, but it still worked. With long cables, if the software has dodgy timing, it won't work.

One thing you can do is probe it at both ends with a scope, and check the timings and signal shape, comparing to the recommendations from DS18B20 datasheet and 1wire appnotes. If you see a lot of timing jitter during the write phase, when the micro controls the bus and the device only listens, then this means you have a software problem, most likely inaccurate delays or interrupts getting in the way.

Note bit-banging 1wire requires turning interrupts off to get accurate delays. This is fine on a small micro, but it is not ideal on a Pi, where you have a powerful micro multitasking and doing many other things. If it is running a webserver, or handling network traffic, you really don't want to freeze the cpu by disabling interrupts to get accurate delays. To solve this problem, you could use a small micro, like an arduino (or DS2482), that would be dedicated to 1-wire and talk to the Pi using serial (or serial over USB).

Answer 2

The likelihood is that there's too much noise in your line to transmit a good signal over such a (relatively) long distance. Those wires are basically acting like big antennas and are likely obscuring any data sent across.

At minimum, you could try adding a small inductive load (like a ferrite bead) to get rid of any high-frequency noise.

Another option is to add a low-pass filter. If you're only using a single data line, a passive filter should be a fairly simple circuit:

An active filter is a little more involved, though it likely would improve the signal even more. Here's a video series that covers how to make one.

If you end up choosing a passive filter, here's an article that covers how to calculate the values of the resistor and capacitor you'll need to get the cutoff frequency you want. Make sure first determine what your clock speed / sample rate is on your data line so that you don't end up cutting off actual data!

Edit: as mentioned in the comments, you might be better off using a shielded cable, like USB or Cat5. the internal shielding blocks out most of the noise and makes it a lot more reliable for data transmission. Make sure you ground off the shielding, though!