# Reliability of DS18x20 temperature sensors

I'm using Maxim's DS18x20 (I've actually got more than one variant) 1-Wire temperature sensors to log the temperatures in various rooms in my house once a minute. About one reading in a thousand, I get something completely bogus back. In the middle of a sequence that's gradually rising from 65F to 70F I get something like -32.1F or 15.64F.

Has anyone else had that kind of problem, or is this something wrong with my setup? If this is just a known issue with these things, I'll have to do something like taking three readings and throwing out the outlier.

Just a few statements about my setup:

• I'm running at 3.3V
• I'm checking the checksum of the reading as it comes back to the arduino, and it matches (or I think it does - there could always be a bug in that code).
• These are running off of normal power, not parasite power.
• I have the 4.7K pullup resistor in place.
• I'm only using a single sensor on each sensing platform.
• The sensor is on a PCB attached to the arduino that's reading it.
• I see the same problem reading from a variety of different arduinos (diecimilla, pro-mini, homemade custom)

I have see this with occasionally with the DS18B20. For my application, it was simple enough to filter out the spurious results with code.

• It's good to hear that someone else has seem something like it. What was your filtering algorithm? – edebill Dec 5 '09 at 18:43
• I would suggest you did what you said, take 3 reading, 5 would be better, 7 better than that, but if there is an error of something around 1/1000 then you just need 3. Take the median. Problem will be solved. if you take 5 it will take a freak occurrence to have a problem. – Kortuk Dec 5 '09 at 22:08
• I'm doing 5 now. I tried just taking the higher of 2, but an error still crept in last night (I've got 3 sensors reading every minute, so I get thousands of datapoints a day). – edebill Dec 6 '09 at 19:50

If you can't find the source of the erroneous readings it should be easy to filter them out and extrapolate from previous readings, or interpolate between readings if hindsight is important. Since you're sampling once per minute you may even just copy the last reading; room temperature will hardly change in one minute.

This can be due to the controller mis-reading one or more bits of the temperature response under certain high-load conditions, or due to electrical interference corrupting one or more bits.

Take a close look at the data sheet here http://www.rentron.com/Files/ds18b20.pdf

On page 5, it shows that the exact binary sequence for 85C is:

+85°C 0000 0101 0101 0000

Likewise, for 25C, it is:

+25.0625°C 0000 0001 1001 0001

In some cases, if the controller misses a bit, you'll get a value that is the actual temperature, expressed in binary and bit-shifted. Often this is 1/2x the target value in C.

Sometimes you can get electrical interference on the line, and the controller reads an entire nibble of 1s, In that case, you'll get some number like 15.64, which expressed in binary is actually very close to numbers between 65 and 70F, except with a bunch of 1s at the beginning.

For what it's worth, I did a bit of work with the DS18B20 a few months back. I shot a short video and did a write-up on my blog, which has links to examples and sample code. Hope this may help a bit! http://dailyduino.com/archives/552

I have 13 of them running in my house since about four years now. The database is hard to handle anymore (I kept track of all samples). But, I didn't see this kinda behavior. Instead, every now and than one sensor freezes and blocks all the others, the only way out of this (that I found) was to shut down supply voltage for a few seconds. So I added a tiny relay to my board and whenever the micro senses this behavior it resets the whole chain of sensors. That happens a few times a week.

• Hmm. Maybe I should only power them up when I'm about to do a reading. – edebill Dec 7 '09 at 13:59