DS18B20 on Raspberry Pi – Read failed CRC check [solved]

In a previous post I described the connection and usage of DS18B20 temperature sensors on a Raspberry Pi that serves my ADSB receiver. This setup was running for a while now and I have seen randomly read errors in /var/log/messages looking like this:

Jan  2 06:57:06 adsbreceiver kernel: [662143.679719] w1_slave_driver 10-000800507da4: Read failed CRC check
Jan  2 07:04:06 adsbreceiver kernel: [662563.782949] w1_slave_driver 10-000800507da4: Read failed CRC check
Jan  2 07:05:04 adsbreceiver kernel: [662622.182977] w1_slave_driver 10-000800507da4: Read failed CRC check
Jan  2 08:22:06 adsbreceiver kernel: [667243.852720] w1_slave_driver 10-000800507da4: Read failed CRC check
Jan  2 08:23:05 adsbreceiver kernel: [667303.023337] w1_slave_driver 10-000800507da4: Read failed CRC check
Jan  2 08:33:06 adsbreceiver kernel: [667903.780663] w1_slave_driver 10-000800507da4: Read failed CRC check
Jan  2 09:22:06 adsbreceiver kernel: [670843.967159] w1_slave_driver 10-000800507da4: Read failed CRC check
Jan  2 10:09:04 adsbreceiver kernel: [673662.309653] w1_slave_driver 10-000800507da4: Read failed CRC check
Jan  2 10:31:05 adsbreceiver kernel: [674983.100512] w1_slave_driver 10-000800507da4: Read failed CRC check

First of all, there was only one sensor affected, out of the two connected. Always the same sensor serial. Second, the errors apparently let to false readings and in two case caused the reading locked to the same value forever until next reboot. So I was digging around the web and this problem seems to very common. A sensor replacement was no solution and a lower pull-up resistor value didn´t help. The I found this article http://claudiodabbicco.blogspot.de/2015/05/raspberry-pi-w1-linux-raspian-kernel.html

It seems the cause of the problem is the priority that the w1_bus_master kernel driver is running with, which is 0 by default. 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. So the promising solution for read failures is to raise the priority of the w1_bus_master kernel driver to a higher, or even highest level. The following command will do that (run as root):

# renice -n -20 -p $(ps -aux | grep w1_bus_master | grep -v "grep" | sed -n 1p | awk ´{print $2}´);

Do check the effect of priority change with the following shell loop:

while (true); do cat /sys/bus/w1/devices/10-*/w1_slave; sleep 1; done

I will keep the ADSB receiver running for some time now and report back the result.

Update 04.01.2017

Jan  3 20:58:19 adsbreceiver kernel: [  136.464017] w1_slave_driver 10-00080050e537: Read failed CRC check
Jan  3 23:00:38 adsbreceiver kernel: [ 7475.838646] w1_slave_driver 10-00080050e537: Read failed CRC check
Jan  3 23:12:38 adsbreceiver kernel: [ 8195.512747] w1_slave_driver 10-00080050e537: Read failed CRC check
Jan  3 23:13:38 adsbreceiver kernel: [ 8255.560671] w1_slave_driver 10-00080050e537: Read failed CRC check
Jan  3 23:21:37 adsbreceiver kernel: [ 8734.686459] w1_slave_driver 10-00080050e537: Read failed CRC check
Jan  3 23:50:38 adsbreceiver kernel: [10475.736763] w1_slave_driver 10-00080050e537: Read failed CRC check
Jan  3 23:57:38 adsbreceiver kernel: [10895.544587] w1_slave_driver 10-00080050e537: Read failed CRC check
Jan  4 00:40:38 adsbreceiver kernel: [13475.886280] w1_slave_driver 10-00080050e537: Read failed CRC check
Jan  4 07:39:37 adsbreceiver kernel: [38615.069358] w1_slave_driver 10-00080050e537: Read failed CRC check
Jan  4 08:20:38 adsbreceiver kernel: [41076.168410] w1_slave_driver 10-00080050e537: Read failed CRC check
Jan  4 09:03:38 adsbreceiver kernel: [43655.909280] w1_slave_driver 10-00080050e537: Read failed CRC check
Jan  4 10:34:36 adsbreceiver kernel: [49114.350359] w1_slave_driver 10-00080050e537: Read failed CRC check

Well, it´s not the priority. 🙁 Same behavior as before. I´m now back to priority 0 but disabled the automated search for new 1-wire devices on the bus, using this command:

# echo "3" > /sys/bus/w1/devices/w1_bus_master1/w1_master_search

The 1-wire bus will be searched 3 times, when the count reaches 0 searching stops. Let´s see if that helps.

Update 06.01.2017

Jan  6 05:30:36 adsbreceiver kernel: [57990.173898] w1_slave_driver 10-00080050e537: Read failed CRC check
Jan  6 05:35:36 adsbreceiver kernel: [58289.836810] w1_slave_driver 10-00080050e537: Read failed CRC check
Jan  6 05:40:37 adsbreceiver kernel: [58590.978158] w1_slave_driver 10-00080050e537: Read failed CRC check
Jan  6 05:55:01 adsbreceiver kernel: [59454.483723] w1_master_driver w1_bus_master1: w1_search: max_slave_count 64 reached, will continue next search.
Jan  6 06:40:37 adsbreceiver kernel: [62191.099569] w1_slave_driver 10-00080050e537: Read failed CRC check
Jan  6 06:45:36 adsbreceiver kernel: [62489.905557] w1_slave_driver 10-00080050e537: Read failed CRC check
Jan  6 07:06:37 adsbreceiver kernel: [63750.798715] w1_slave_driver 10-00080050e537: Read failed CRC check
Jan  6 07:10:36 adsbreceiver kernel: [63990.231698] w1_slave_driver 10-00080050e537: Read failed CRC check
Jan  6 07:40:37 adsbreceiver kernel: [65791.103494] w1_slave_driver 10-00080050e537: Read failed CRC check

Still not working. I have no glue what the problem is. Above at 05:55:01 a sensor lock up occured. Since then the sensor is reading the same temperature or read fails. I tried to remove and add the sensor manually to the w1_bus_master, without success. Obviously a reboot or power cycle is required. How the reading looks:

1-wire sensor lock

Raspberry Pi operating at low temperatures nicely. Thinking to use I2C sensors in the future…

Update 09.01.2017 – Problem solved!

Obviously the problem is solved. First, I upgraded my ADSB receiver to a Raspberry Pi 2B while it was running on a 1B+ before. Second, I shortened one sensor wiring from 20cm to 10cm and chained the wiring of both sensors to create a real linear topology. Either change, or the combination of both solved the read failed CRC check for me. The receiver is running for some hours now without a single read fail. Excellent!

On the left is the down time during board upgrade and sensor wiring change. Since then temperature is plotted nicely.

Leave a Reply

Your email address will not be published. Required fields are marked *

Comments will be moderated! Spam deleted immediately!
Before you submit form:
Human test by Not Captcha