Community
OpenEnergyMonitor

Community

DS18B20 reliability considerations

ds18b20
Tags: #<Tag:0x00007f13e6b3c0a8>

(Frogmore42) #1

Saw the stuff on DS18B20 sensors. I have had quite a few fail for various reasons and know quite a bit about the failure modes.

  1. First ones were hand soldered by me to CAT5 cable with heat shrink over each pin and then heat shrink over the assembly. They started failing in less than a few months after being buried. Was worse when it was wet. The ones that were not directly buried failed after a couple of years. Solid core CAT5 is not a good idea for this application.

  2. Next I purchased the ones that are pre-made with stainless steel covers and claim to be waterproof. They worked well for about a year in my compost pile that gets to 60C for an extended period of time. Turns out they don’t put an epoxy or sealant in many of these.

  3. Next I encased the stainless steel encased ones in epoxy. That seems to have done the trick and I now get more than a year out of a sensor pole for my aerated static compost pile.

So, the errors I saw varied. Sometimes the device doesn’t respond at all. Sometimes it gives bad readings, obviously wrong. Sometimes the readings are not obviously wrong, but are changing too quickly to be real.

Here is how I handle it:

  1. Add a questionable field and valid field to the data.
  2. Check the CRC every time
  3. Exactly 0 degrees C is questionable, since a short of data to ground at the right time will cause this and the CRC will NOT catch it.
  4. Exactly 85 degrees C is questionable if not not valid, since that is the default value and can occur if power is not sufficient (though they don’t need a lot)
  5. Always know and compare to the valid range of values for a location, ie when used for freeze protection in a normal location more than 40-50C is likely an incorrect reading.
  6. Always make sure you know what the valid range is. For a compost pile 60-80C is likely possible, though really warm and should probably trigger a cooling sequence.

Sorry for the interrupt, you can move this somewhere more appropriate.


STM32 Development
(Frogmore42) #2

So I was checking my graphs and noticed that one of my sensors was reading high, very high. Sure enough, the power pin had gotten dislodged, so the sensor was not getting any power other than from the pull-up on the data line. This particular device is using a early version of code, so does not have the check for valid temperature range, but still has the CRC check. The CRC is fine and the general shape of the graph looked really. It just has a significant offset and scale problem. I guess the measurements just don’t work well when the sensor isn’t powered :smiley:. I plugged the power line back in and the readings are back to normal.


(dBC) #3

Interesting, I get CRC errors once I pull the Red wire to my sensor, that’s with 3.3V and a 4K7 pull-up.

I’m working on a project that involves a pair of pt1000s at the moment, so I just taped together two pt1000s and two ds18b20s and let them rip.

The ds18b20s:
bus0 status: 0xe0, crc: ok, temp: 26.875C
bus1 status: 0xe0, crc: ok, temp: 26.562C

The pt1000s:
26.9C 26.9C


(stephen krywenko) #4

yeah I tired of working with ds18b20… they are quite unstable if you need accurate stable temperature measurements. I have a bunch of ntc10k from solar water heater controllers that i started using … I also have a bunch of pt1000 that I have not started using yet – do you mind if I ask what the math for them I looked quite a few times and never found one the worked for them - (mind you I have not looked lately ) or if you can point me to sketch that would be great… I simply moved to using ads1115 ( $2-$3) on esp then i can easily use 4 - 5 of these sensors on a esp then using dc18b20s

here an example showing how unstable they can be – Screenshot_20190204_131045

the orange line is an ds18b20 ( actually they are all ds18b20s) it just that one ds is so unstable I actauuly have two sensors in the same location just to demonstrate how unstable it is hence why you see 2 orange lines


(Frogmore42) #5

Here is a picture of one of DS18B20s that is outside:

The scale is degree F. It wasn’t really 175 degrees, but the red wire fell off, so the sensor wasn’t getting any power.

After I reattached the red wire, things look much better but still too cold:

Even with the red wire cut, it is still following the temperature outside. It just has significant scale and offset errors, AND it has much more variance:

So, I would say you have a defective sensor. I don’t believe I have ever had one defective from the start, but have heard of people who have. I have, however, had sensors go bad on me. In all cases it was due to effect of the environment they were in the level of protection they had from it. These sensors are cheap in price, but I have found them to be reliable and consistent within their specifications (usually quite a bit better).

I have never used the PT1000, but I have used ratiometeric pressure sensors with the ADS1115. It is possible to get good results, but it requires quite a bit of care. But, if they are working for you that is great. It’s nice having so many choices, usually there is at least one that will work for most applications.


(dBC) #6

I’m rich in flash space in this application so I used a spreadsheet to build me a lookup table of tenths of a degree, along the lines of:

static const int16_t temp_lookup[4096] = {
-457,
-457,
-456,
...
1713,
1714,
1715,
1715
};

The exact values in the table are unique to my front-end so not relevant to you, but to build it I just used the standard pt1000 formula and you can find that all over the web, one example here.


(Paul) #7

Just to throw in comment (or 2) about the ds18b20’s, I’ve heard, here and elsewhere that they can be troublesome, but I have used hundreds of these and never had one fail. I cannot say i haven’t had some duff reading but they are rare and the majority get filtered out, resulting in a missing reading rather than a contaminated data feed.

This maybe because I don’t trust low DC over any real distance so I have always used 5v to stay well away from the ds18b20’s lower limit, but I always read the data line at 3.3v levels. This came about from the original emonTx v2 having an error in the PCB that powered the ds18b20 at 5v despite the ATmeag328p being run at 3.3v. It worked well and never had any issues, i have just chosen to continue that approach to this day. eg when I connect ds18b20’s to a RPi, I will power them from 5v rather than the 3.3v 50mA rail. A project last year had 80 ds18b20’s connected to one RPi this way and read every 10secs at 12bit resolution (4 buses), there was an insignificant number of “null” values which was totally acceptable.

Do not be tempted to use more than a single core (of the Cat5e) for each line and do not ground the unused conductors, I use a twisted pair for gnd and data, then a single core from another twisted pair for 5v. When connecting multiple ds18b20’s, try to keep the distance between the master and each ds18b20 unique, ie star configuration with all the sensors the same length is the worse possible configuration, when chaining sensors along a Cat5e, do not have a 1meter spur, then 50cm further along, a 50cm spur, make the second one shorter or longer so as not to clash with the first sensor distance. Personally I solder splice each sensor’s wiring into the Cat5e with glue filled heatshrink to add mechanical strength and water tightness so there is little or no chance of a bad connection (fingers crossed).


(Frogmore42) #8

all good advice.

This is what I use:
image
orange solid +5V (pin 3 of sensor, pin 1 of RJ45)

image
white/brown stripe Data (pin 2 of sensor, pin 2 of RJ45)

image
brown solid Ground (pin 1 of sensor, pin 8 of RJ45)

I follow T568B


so the pins I use will be on pairs that are less likely to be used, incase they are accidentally plugged in where they shouldn’t be.


(Paul) #9

also good advice :slight_smile:

I avoid using RJ45 if I can, but when I do I make sure they are the right type for the cable, did you know (I assume you do) the “usual” RJ45 are intended for multi-strand and not solid core? the terminals “stab in multi-strand” rather than “crimping around solid core”. Most of the RJ45 “dodgy connections” I have encountered (on non-factory fitted RJ45’s) have been due to the wrong RJ45’s used(the term doesn’t stab in, it just slips to one side of the solid core and rests against it). You can get “solid and multi-strand” RJ45’s that do both, but they tend to be a tad more expensive and not mainstream, these are the only ones I carry now to avoid accidentally fitting the wrong ones or running out of one type or the other.


(Paul) split this topic #10

2 posts were split to a new topic: Problems recognising a temp sensor on emonPi


(Paul) split this topic #11

A post was merged into an existing topic: Problems recognising a temp sensor on emonPi


(dBC) #12

So what sort of maximum cable length are you guys finding you can get to? I guess it depends a lot on the topology along the way, but maybe with just one sensor say?


(Paul) #13

I can’t say I’ve ever really pushed the distance very far. I did make up some sub-assemblies with 8 or 10 ds18b20’s across an approximate winding 10mtr cable span and left them soak testing for a month with 20mtr tails (coiled up), I have no idea what the finished length was once they installed them.


(Frogmore42) #14

There’s an app note for that:
https://www.maximintegrated.com/en/app-notes/index.mvp/id/148

I have never tried to push the distance. 3 meters is about as far as I have tried.