DS18B20 reliability considerations

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.

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

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

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.

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.

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).

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.

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.

2 Likes

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

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

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?

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.

1 Like

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.

1 Like

Do you need a level converter on the data pin in that case? What strength pull-up do you use with 5V?

EDIT - or do you power it at 5V but pull the data line to 3.3V?

Theoretically I guess so, but no, I don’t use any level matching.

The usual 4K7 or sometimes a 5K0 depending what I have to hand.

No, just power at 5V, pullup to 5V and read via a standard 3V3 IO pin, usually a Pi or Atmel ATmega328p running at 3V3.

This isn’t that uncommon to OEM kit, it’s just not widely known to be the case.

It all started with the emonTx V2 pcb v2.2 (Changlog) and a minor fault on the PCB, if you look at the schematic there is SJ2 solder bridge pads to allow the user to select a 3V3 or 5V supply, but the board was made with a permanent link to 5V (see picture below, the left and centre pads linked in red) so unless that track was broken, all emonTx v2 temp sensors were 5V powered but the MCU was 3V3.

image

This was my first encounters with using ds18b20’s so when I started using them else where I just stuck with what I knew worked, perhaps because of my background of working with automotive 12VDC electrics for many years and rarely, if ever, did you get the expected voltage at the other end of a cable, voltage drops were unavoidable and now working 3-5V, I came to believe this might be the reason so many people report issues with ds18b20’s whilst I had not experienced any issues at all. That and the fact I make sure every connection is 110%, again from the automotive background, 99% of all vehicle electrical faults basically end up being a problem with 1 of 3 things, connections, connections or connections.

I’ve never done the theoretical maths or taken any exact measurements as I haven’t really needed to do any debugging of ds18b20 circuits, but I’d come to the conclusion that by giving it 5V it probably ends up performing nearer to 3V3 levels than 5V levels once it’s travelled several metres and passed through a few connectors too, but your question about pulling up to 3V3 rather than 5V now raises some doubt as at rest the pullup to 5v must result in a >3V3 level? But there are no reports of damaged MCU’s (that I’m aware of) and I certainly haven’t had any issues. (so cheers for that @dBC ignorance was bliss for a while :thinking:)

Although the emonTx v3.4 ds18b20 connections via the RJ45 are 3V3 not 5V and the pullup is to 3V3 too, the emonPi’s RJ45 pin 2 is 5V (not 3V3 like the emonTx v3.4) and it uses a 4K7 pullup to 5V like the old emonTx v2.

The emonPi also powers the optical pulse sensor with 5V and reads at 3V3, it’s performance differs to the emonTx v3 optical pulse counter input (identical sensor) as it is all 3V3 on the emonTx v3. The only difference to the way the circuit compares to the ds18b20 connections on these devices is that the pulse counter uses an internal pullup/down on both, so the pulse counter is pulled to 3V3 even when powered via the emonPi’s 5V RJ45p2.

Especially the corroded ones! :wink: :grin:

1 Like

I thought that was deliberate?

Maybe it was retrospectively deliberate (accidentally done on purpose) :smile:

From the emonTx v2 build guide “voltage selection notes”

On the latest version of the emonTx PCB, two solder jumpers have been added near the IRQ I/O and temperature (DS18B20) ports. They enable the user to decide what voltage to use on these ports. The emonTx runs at 3.3V. More details can be found in this blog post. Connection is made by joining the middle pad the either of the outer pads with solder.

If you look carefully, the solder jumper above the temperature port is connected to 5V (small PCB trace). This was an error, but actually work out well. The temperature sensors always use 5v (which is good) and when the emonTx is powered by 2 x AA’s the the 5V rail becomes 3.3V anyway. Therefore, you can ignore this solder jumper, it will disappear in the next generation of emonTx PCBs. However the pulse counting voltage selection jumper (pictured) above must be connected to either 3.3V/5V.

Found a reference to the data pin being 3.9v when connected this way with pullup and power to 5v on the old forum (ref DS18B20 temperature sensing | Archived Forum)

1 Like

Using a pull-up to 5V on a 3V3 MCU can be just fine if the MCU is designed for that. Some are rated for it and some have a design the will work okay. Since it is a pull-up, when the MCU input protection circuit goes active it will be able to lower the voltage without needing to disapate too much current.

I used to use 5V for the power pin and didn’t have problems. I now use 3V3, since the esp8266 is not rated for 5V on the input pins (there is some debate on this, but it isn’t clear that it is 5V tolerant). I have not had any more problems since I switched, so I don’t believe 5V is necessary if runs are short. The datasheet does recommend using 5V for both pull-up and power when you need maximum range, ie 100m or so.