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:

Sensor and Pi 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.

  • 1
    \$\begingroup\$ Just to be clear, you're saying you tested the same cable length on your breadboard, or just the same components? \$\endgroup\$
    – PlugN'Play
    Apr 14, 2022 at 21:57
  • 1
    \$\begingroup\$ Also, is your sensor use a digital or analog output? \$\endgroup\$
    – PlugN'Play
    Apr 14, 2022 at 22:02
  • 1
    \$\begingroup\$ @PlugN'Play Just the components were tested on the breadboard. I added the length of extension afterwards. And the sensor is a digital output \$\endgroup\$
    – iiz
    Apr 15, 2022 at 9:59
  • 1
    \$\begingroup\$ @tlfong01 Thanks for those resources. I think I will try with some Cat cable at 6m and if that fails will probably try to relocate the project to reduce the cable length rather than introduce an extender. Is there a short answer as to why my current setup doesn't work? \$\endgroup\$
    – iiz
    Apr 15, 2022 at 10:01
  • 1
    \$\begingroup\$ @tlfong01 many thanks for your help. Using Cat5 as per your and Bobflux's suggestion has solved my issue and answered my question. \$\endgroup\$
    – iiz
    Apr 20, 2022 at 19:13

2 Answers 2


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.

enter image description here

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).

  • \$\begingroup\$ Using a Cat5 cable with the twisted pairs grounded as suggested now results in my sensor being visible and working well with my Pi. Thanks \$\endgroup\$
    – iiz
    Apr 20, 2022 at 19:12
  • \$\begingroup\$ Excellent, great news! \$\endgroup\$
    – bobflux
    Apr 21, 2022 at 5:32

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:passive filter

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!


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.