I am developing on a Pi 1B some work with 1-wire sensors - using my own software.
My application is running as compiled C - bit-banging the GPIO.
On the current setup I have a single sensor on gpio 17 which is queried every 2 minutes (odd minutes). It's working well with my own software and is returning a valid response every time
- EXCEPT at 17 minutes past every hour.

I understand that this is a special time with regard to the fake RTC and cron.hourly tasks.
Is anyone here able to shed some light on how this may be working.
( the fail condition is testing for DS18B20 device responses to a 'reset' instruction - set to run up to 9 times or until a device response is seen )

I'd like to understand enough to be able to counter any disruptive effect such as I'm seeing with this.


  • 1
    Perhaps it is simply because the system is busy with cron jobs at 17 so your bit banging will not be so reliable. The 1-wire timings are pretty tight. Try adding a sleep 30 at the start of your cron job.
    – joan
    Aug 30 '15 at 11:13
  • Bit-banging GPIO using a user-space program is always going to be a challenge. If the devices you're communicating with are sensitive to jitter (as 1-wire is known to be sensitive) it's even more challenging. You could try upping the process priority (the 'nice' level) of the process, though I don't know how much that might help.
    – WineSoaked
    Aug 30 '15 at 21:14
  • thanks @WineSoaked - love a challenge. I've spent several hours fine tuning the bit-banging.
    – Kiwi-gee
    Aug 31 '15 at 0:55
  • @joan should probably put that comment into an answer...
    – WineSoaked
    Sep 1 '15 at 2:58

It's quite easy to use the DS18B20 temperature sensor on the Pi.

An entry in /boot/config.txt such as the following (using the non-standard GPIO24) is enough if you want to use the kernel drivers.


The following Python code will then display the temperature of any attached devices.

#!/usr/bin/env python

import glob
import time

while True:

   for sensor in glob.glob("/sys/bus/w1/devices/28-00*/w1_slave"):
         f = open(sensor, "r")
         data = f.read()
         (discard, sep, reading) = data.partition(' t=')

         t = float(reading) / 1000.0




The 1-wire protocol used by the DS18B20 does have tight timing requirements and the kernel drivers will fail to return a good result if the system is busy. This is doubly so for a userland bit bang solution which will (normally) be working at a lower priority.

The following screen shots of a DS18B20 message in detail will give an idea,

DS18B20 complete message

One temperature reading.

DS18B20 detail of first block in message

Detail of first block in message.

DS18B20 detail within first block of message

Once you zoom in to the message detail you can see how tight the timing requirements are. Events of the order of 10 µs long have to be accurately recorded.

That is why it is important to minimise system activity during a reading.

  • Hi again @Joan, Thanks for the graphs, I haven't done that yet - and also the fortuitous introduction to piscope, i hadn't found that either. I started on the bit-bang approach to try to reduce the fail count when using the 'driver' that you mention. WRT your expanded graph - I think the situation is not as tight as you claim. Each bit sent by device is preceded by a 'start window' 0 pulse by the master, the bit sent is included in the next 50us or so. This is quite easy to evaluate as timing of the master pulse is known. Need to allow for variations in device responses - multi-sample.
    – Kiwi-gee
    Sep 17 '15 at 5:10
  • It is tight for software relying on interrupts to be notified of the edges (as I think the kernel driver does). Busy waits won't have problems but will fail periodically because of reschedules. User danjperron on the raspberry pi org forums has done possibly the definitive work on the Raspberry Pi with DS18B20 bit bang. Have a look through github.com/danjperron/BitBangingDS18B20
    – joan
    Sep 17 '15 at 7:43

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.