# I have three DS18B20's. I can't tell if any of them are working correctly

I have three DS18B20's (or I believe at least two of them are DS18B20's). I am currently reading them through an embedded Linux board (Raspberry Pi in this case).

I have two of the sensors in a breadboard, they give seemingly accurate temperatures. The third one is one of those DS18B20's enclosed in a "waterproof" cable from Ebay like this:

pi@raspberrypi:~ \$ cat /sys/bus/w1/devices/28-*/w1_slave
45 01 4b 46 7f ff 0b 10 84 : crc=84 YES
45 01 4b 46 7f ff 0b 10 84 t=20312
57 01 4b 46 7f ff 09 10 c7 : crc=c7 YES
57 01 4b 46 7f ff 09 10 c7 t=21437
60 01 80 80 1f ff 80 80 2e : crc=2e YES
60 01 80 80 1f ff 80 80 2e t=22000


So what this command does is simply get all the sensors and read from them. Pretty simple. Divide t=20312 by 1000 and you get 20.312°C

But the odd thing is that the third sensor will only ever give temperature measurements that are to within 0.5 degrees, whereas the other two are capable of measuring down to what seems to be 0.1 degrees. At first I thought that the third one was broken, but when I checked the datasheet it clearly specifies that the part is accurate to ~0.5 degrees.

I have made a table of the values I'm getting:

Breadboard Sensor #1 | Breadboard Sensor #2 | Cable Sensor
21.937                 21.562                 22.00
21.812                 21.562                 22.00
20.468                 20.478                 22.50
19.584                 20.201                 27.00
19.625                 19.687                 28.00


So now I'm totally confused. Are the breadboard sensors broken, or is the cable? If they are all working, they why is that two of them seem to have a higher resolution?

Edit: I've been searching around more and it seems that there a few people who have encountered this, and other people have suggested that they might be fake chips!

Update: The device driver for the sensors (https://www.kernel.org/doc/Documentation/w1/slaves/w1_therm):

The driver also doesn't support reduced precision (which would also reduce the conversion time).

• Why does your cable sensor not have the same sensitivity as your breadboard sensors? Are you sure its a DS18B20? Your signal chain is not equivalent, and by signal chain I mean digital comm and maths. Debug your chain, list the differences, eliminate the differences or explain them. – Voltage Spike Feb 10 '16 at 22:10
• "Why does your cable sensor not have the same sensitivity as your breadboard sensors?". Well, that's what I'm trying to find out by posting here. The 28-* means list any sensors that are of the "0x28" device family which is the DS18B20 so technically they are DS18B20's. – user9993 Feb 10 '16 at 22:15
• Do you know if the device driver actually sets the device resolution to maximum, or does it just assume it is already set at max and leave it there? – brhans Feb 10 '16 at 22:25
• You might want to plug the cable version into the breadboard and do the comparison. – Voltage Spike Feb 10 '16 at 22:37
• Just a comment on your sentence "they give seemingly accurate temperatures". This is what is known as false precision. All the sensors gives an accurate temperature. The extra random noise at the end of the numbers isn't valid data just because it's non-zero. – pipe Feb 11 '16 at 4:59

Looking at w1_therm's source code, it doesn't ever touch the configuration register, therefore relying on the programmed precision setting in EEPROM.

Indeed your own data dump shows that the configuration byte is 0x7F for two of your sensors and 0x1F for one of your sensors. This corresponds to 12 bits and 9 bits of precision respectively.

So all you need to do is initialize the configuration of your low-precision temp sensor once, store to EEPROM and then you can use the original driver again. Of course, a contribution of some cleaned-up code to set precision would probably be welcomed by the Linux community ;)

• how would one "only" change the precision setting and write it to the EEPROM with a raspberry pi? – x29a Apr 3 '16 at 16:44

The datasheet says on page 2, Overview:

... and the 1 - byte configuration register. The configuration register allows the user to set the resolution of the temperature - to - digital conversion to 9, 10, 11, or 12 bits. The $T_H$ , $T_L$ , and configuration registers are nonvolatile (EEPROM), so they will retain data when the device is powered down.

Page 8 shows the configuration details. You need to set these bits to the resolution you want.

• See my update about the resolution, I believe the device driver only supports maximum resolution. – user9993 Feb 10 '16 at 22:19
• then the device driver is broken. – William Brodie-Tyrrell Feb 11 '16 at 0:08

I would guess that the there's something strange about it, but it's not downright broken.

The DS18B20 has several "moving parts": analog front end, A/D, 1-wire transmitter. Usually, when an IC like that is broken, it either goes quiet (doesn't put out any readings at all), or outputs ridiculous values that are off the charts.

DS18B20 has an adjustable resolution setting, which is stored in DS18B20's non-volatile memory (see Configuration Settings on p.8 of the datasheet). The reduced resolution 9-bit reading occupies most-significant bits of the 12-bit temperature register (see last paragraph on p.3 in the datasheet). I would guess that these sensors came from the factory with different settings.
[disclaimer: I haven't used DS18B20 myself. I'm just reading the datasheet.]

• See my update about the resolution, I believe the device driver only supports maximum resolution. – user9993 Feb 10 '16 at 22:19
• The DS18B20 stores resolution configuration on-board in its own nonvolatile memory. With that in mind, what does the software driver do when it faces a DS18B20 that happens to be configured for low resolution? Does it try to reconfigure the sensor for high resolution? Does it thrown an exception? (On a different note, it's not inconceivable that the cable assembly from eBay has got a counterfeit IC. You might as well ask the eBay seller for help with troubleshooting.) – Nick Alexeev Feb 10 '16 at 22:27

Do you know the provenance of the odd sensor?

It's not unheard of for manufacturers to intentionally degrade by hard programming something like this. Maybe the sensor is a lower bin device, perhaps higher noise or less linear, so has lower resolution fixed to mask this. It can be DS18 compatible, without being one. Perhaps it has been sold more cheaply to a contract and so been 'crippled' to fit the price.