DS18x20_Temperature example gives wrong temperature with DS18B20 but not DS18S20 with 4.7k resistor (2.7k resistor required for 3.3V)

[marcmerlin]

I installed OneWire 2.3.5 on a recent enough arduino IDE (1.8.6) and trying to use this on ESP8266 (need wifi, so I can't use my teensies for this).

I tried powering the Vcc pin but it didn't really make a difference. I went back to shorting the Vcc and Gnd pins, using parasitic power on a wire length of 30cm, and I have the 4kOhm resistor. The readings seem ok, CRC checks out so I'm assuming that I'm not seeing any analog transmission issues, but the two DS18B20 are wrong. All 3 sensors are plugged in parallel with very short wire length between them.

I was able to plug two of them in my laptop with a USB DS2940 adaptor, and they gave a correct and equal enough temperature:

1080BAED010800EA : DS1820/DS18S20/DS1920 Temperature Sensor
28D813060200000F : DS18B20 Temperature Sensor
ROM #0 : 1080BAED010800EA
ROM #1 : 28D813060200000F
Wrote .digitemprc
saruman:~# digitemp_DS2490 -a
Found DS2490 device #1 at 001/115
Mar 25 17:15:57 Sensor 0 C: 22.69 F: 72.84
Mar 25 17:15:58 Sensor 1 C: 22.50 F: 72.50

The code works, the temperatures are consistent, but the two DS18B20 are wrong by 5 to 10F

ROM = 10 80 BA ED 1 8 0 EA
  Chip = DS18S20
  Data = 1 2A 0 4B 46 FF FF C 10 15  CRC=15
  Temperature = 21.00 Celsius, 69.80 Fahrenheit
ROM = 28 D8 13 6 2 0 0 F
  Chip = DS18B20
  Data = 1 2B 1 4B 46 7F FF 5 10 0  CRC=0
  Temperature = 18.69 Celsius, 65.64 Fahrenheit
ROM = 28 25 F6 AF 2 0 0 5
  Chip = DS18B20
  Data = 1 BA 1 4B 46 7F FF 6 10 D0  CRC=D0
  Temperature = 27.62 Celsius, 81.72 Fahrenheit
No more addresses.

ROM = 10 80 BA ED 1 8 0 EA
  Chip = DS18S20
  Data = 1 2A 0 4B 46 FF FF C 10 15  CRC=15
  Temperature = 21.00 Celsius, 69.80 Fahrenheit
ROM = 28 D8 13 6 2 0 0 F
  Chip = DS18B20
  Data = 1 2B 1 4B 46 7F FF 5 10 0  CRC=0
  Temperature = 18.69 Celsius, 65.64 Fahrenheit
ROM = 28 25 F6 AF 2 0 0 5
  Chip = DS18B20
  Data = 1 B9 1 4B 46 7F FF 7 10 D1  CRC=D1
  Temperature = 27.56 Celsius, 81.61 Fahrenheit
No more addresses.

[PaulStoffregen]

Can you reproduce the problem on Teensy or any Arduino board with AVR or SAMD chip?

[marcmerlin]

I just tested another lib and it had the same problem, bug: https://github.com/milesburton/Arduino-Temperature-Control-Library/issues/159 Let me try a teensy and report back

[marcmerlin]

So, I have about $200's worth of your chips around my house, but most are in use :) I found a teensy LC, which promptly had one of those ever vexing problem with serial that it only works for a few seconds before it stops working (the chip continues, but serial is dead). I managed to get one data sample out. It's still far enough that it's not great, but then again, not as bad either.

ROM = 28 25 F6 AF 2 0 0 5
  Chip = DS18B20
  Data = 1 7E 1 4B 46 7F FF 2 10 25  CRC=25
  Temperature = 23.88 Celsius, 74.97 Fahrenheit
No more addresses.

ROM = 28 D8 13 6 2 0 0 F
  Chip = DS18B20
  Data = 1 60 1 4B 46 7F FF 10 10 B5  CRC=B5
  Temperature = 22.00 Celsius, 71.60 Fahrenheit

I removed a B20 and put an S20. Temps are still off by a bit. The S20 is correct. Strangely serial just worked with those 2 sensors

ROM = 10 80 BA ED 1 8 0 EA
  Chip = DS18S20
  Data = 1 2D 0 4B 46 FF FF 4 10 B3  CRC=B3
  Temperature = 22.50 Celsius, 72.50 Fahrenheit
ROM = 28 25 F6 AF 2 0 0 5
  Chip = DS18B20
  Data = 1 87 1 4B 46 7F FF 9 10 48  CRC=48
  Temperature = 24.44 Celsius, 75.99 Fahrenheit
No more addresses.

I then added a 3rd sensor, and it made serial fail again. I'm using pin 12 for 1wire FWIW. With a bunch of reboots/reflashes I got it working once (arduino-1.8.9-teensyduino-1.47 although this serial problem has been with all versions of teensyduino, I've filed bugs in your forum over 2Y ago IIRC). Anyway, let's not get sidetracked. The one sample I got before serial died, was good enough. The sensors are literally 5cm apart.

ROM = 10 80 BA ED 1 8 0 EA
  Chip = DS18S20
  Data = 1 2D 0 4B 46 FF FF 7 10 E6  CRC=E6
  Temperature = 22.31 Celsius, 72.16 Fahrenheit
ROM = 28 D8 13 6 2 0 0 F
  Chip = DS18B20
  Data = 1 68 1 4B 46 7F FF 8 10 5  CRC=5
  Temperature = 22.50 Celsius, 72.50 Fahrenheit
ROM = 28 25 F6 AF 2 0 0 5
  Chip = DS18B20
  Data = 1 79 1 4B 46 7F FF 7 10 A  CRC=A
  Temperature = 23.56 Celsius, 74.41 Fahrenheit
No more addresses.

[marcmerlin]

ESP32 actually seems fine enough, same as teensy, too much of a range, but the disparity is not as outrageous:

ROM = 10 80 BA ED 1 8 0 EA
  Chip = DS18S20
  Data = 1 2C 0 4B 46 FF FF B 10 E8  CRC=E8
  Temperature = 22.06 Celsius, 71.71 Fahrenheit
ROM = 28 D8 13 6 2 0 0 F
  Chip = DS18B20
  Data = 1 64 1 4B 46 7F FF C 10 1  CRC=1
  Temperature = 22.25 Celsius, 72.05 Fahrenheit
ROM = 28 25 F6 AF 2 0 0 5
  Chip = DS18B20
  Data = 1 7C 1 4B 46 7F FF 4 10 9  CRC=9
  Temperature = 23.75 Celsius, 74.75 Fahrenheit
No more addresses.

scratch that, I tried again later by adding a 3rd DS18B20, and 2 of them read off.

ROM = 10 80 BA ED 1 8 0 EA
  Chip = DS18S20
  Data = 1 3B 0 4B 46 FF FF 6 10 E5  CRC=E5
  Temperature = 29.37 Celsius, 84.87 Fahrenheit
ROM = 28 D8 13 6 2 0 0 F
  Chip = DS18B20
  Data = 1 60 1 4B 46 1F FF 10 10 25  CRC=25
  Temperature = 22.00 Celsius, 71.60 Fahrenheit
ROM = 28 25 F6 AF 2 0 0 5
  Chip = DS18B20
  Data = 1 80 1 4B 46 1F FF 10 10 56  CRC=56
  Temperature = 24.00 Celsius, 75.20 Fahrenheit
ROM = 28 95 7 B0 2 0 0 CB
  Chip = DS18B20
  Data = 1 C9 1 4B 46 7F FF 7 10 64  CRC=64
  Temperature = 28.56 Celsius, 83.41 Fahrenheit
No more addresses.

Seems that one of the 20B sensors is outputting not great data, so that may be a different problem

and now linux agreed for a short time too

saruman:~# digitemp_DS2490 -a
DigiTemp v3.7.2 Copyright 1996-2018 by Brian C. Lane
GNU General Public License v2.0 - http://www.digitemp.com
Found DS2490 device #1 at 001/029
Mar 25 19:59:14 Sensor 0 C: 20.69 F: 69.24
Mar 25 19:59:15 Sensor 1 C: 28.00 F: 82.40
Mar 25 19:59:16 Sensor 2 C: 27.06 F: 80.71

and by adding another sensor, it went back to normal and stayed normal

ROM #0 : 1080BAED010800EA
ROM #1 : 28D813060200000F
ROM #2 : 2825F6AF02000005
ROM #3 : 289507B0020000CB
Mar 25 20:33:06 Sensor 0 C: 20.69 F: 69.24
Mar 25 20:33:07 Sensor 1 C: 20.50 F: 68.90
Mar 25 20:33:08 Sensor 2 C: 21.00 F: 69.80
Mar 25 20:33:09 Sensor 3 C: 21.06 F: 69.91

this makes no sense... even more so that when I put it back in the ESP32, it's looking great again:

ROM = 10 80 BA ED 1 8 0 EA
  Chip = DS18S20
  Data = 1 2A 0 4B 46 FF FF 10 10 B4  CRC=B4
  Temperature = 20.75 Celsius, 69.35 Fahrenheit
ROM = 28 D8 13 6 2 0 0 F
  Chip = DS18B20
  Data = 1 48 1 4B 46 1F FF 8 10 3D  CRC=3D
  Temperature = 20.50 Celsius, 68.90 Fahrenheit
ROM = 28 25 F6 AF 2 0 0 5
  Chip = DS18B20
  Data = 1 58 1 4B 46 1F FF 8 10 69  CRC=69
  Temperature = 21.50 Celsius, 70.70 Fahrenheit
ROM = 28 95 7 B0 2 0 0 CB
  Chip = DS18B20
  Data = 1 52 1 4B 46 7F FF E 10 FF  CRC=FF
  Temperature = 21.12 Celsius, 70.03 Fahrenheit
No more addresses.

Given that this is a digital protocol with CRC, is it fair to assume that I should be able to rule out analog problems being the cause of some DS18B20 sensors returning incorrect temperatures?

[marcmerlin]

Oh, weird, just saw a garbage data point on ESP32, and somehow the CRC didn't help detect it. Is that expected?

ROM = 10 80 BA ED 1 8 0 EA
  Chip = DS18S20
  Data = 1 2C 0 4B 46 FF FF A 10 2C  CRC=2C
  Temperature = 22.12 Celsius, 71.82 Fahrenheit
ROM = 28 D8 13 6 2 0 0 F
  Chip = DS18B20
  Data = 1 FF FF FF FF FF FF FF FF FF  CRC=C9
  Temperature = -0.06 Celsius, 31.89 Fahrenheit
ROM = 28 25 F6 AF 2 0 0 5
  Chip = DS18B20
  Data = 1 7A 1 4B 46 7F FF 6 10 B  CRC=B
  Temperature = 23.62 Celsius, 74.53 Fahrenheit
No more addresses.

[marcmerlin]

https://github.com/milesburton/Arduino-Temperature-Control-Library/issues/159 similary returns correct enough data on ESP32, so I'm guessing both libs are using some common algorithm that fails on ESP8266.

[marcmerlin]

Ok, as one last test, I replaced the esp8266 mini lite (1MB flash) with a mini R2 (4MB flash) and I'm getting reliably wrong but equal temperatures across all 3 sensors. I tried to set the CPU speed to both 80Mhz and 160Mhz, made no difference.

Does that make any sense? All data samples look like this:

ROM = 10 80 BA ED 1 8 0 EA
  Chip = DS18S20
  Data = 1 FF 0 4B 46 FF FF 1 10 45  CRC=45
  Temperature = 127.69 Celsius, 261.84 Fahrenheit
ROM = 28 D8 13 6 2 0 0 F
  Chip = DS18B20
  Data = 1 FF 7 4B 46 7F FF 1 10 2F  CRC=2F
  Temperature = 127.94 Celsius, 262.29 Fahrenheit
ROM = 28 25 F6 AF 2 0 0 5
  Chip = DS18B20
  Data = 1 FF 7 4B 46 7F FF 1 10 2F  CRC=2F
  Temperature = 127.94 Celsius, 262.29 Fahrenheit
No more addresses.

I got it working half way a bit later, but it's still not working right. See the bottom of https://github.com/PaulStoffregen/OneWire/issues/91#issuecomment-604212998

[PaulStoffregen]

one of those ever vexing problem with serial that it only works for a few seconds before it stops working

Any chance you're using Linux? That problem sounds like ModemManager. Ubunbu (and probably others) changed the default ModemManager filter policy some time ago, triggering a bug where ModemManager again interferes with some types of USB serial devices (mistaking them for modems), even through udev rules explicitly tell ModemManager to ignore those devices. Installing the updated udev rules fixes the problem. So does deleting ModemManager, but it's surprisingly difficult to remove and keep it from coming back when you update or upgrade.

[marcmerlin]

@PaulStoffregen for serial, good call on modemmanager, I had that piece of .... Nope, it's long gone, and I have 0 problems with other chips (real arduinos, or ESP8266, or ESP32). It's only been teensies, 3.1/2 or 3.5/6 (and now lc) that have this problem.

[marcmerlin]

Ok, now I'm going to go crazy. I plugged the same 4 sensors from this updated comment ( https://github.com/PaulStoffregen/OneWire/issues/91#issuecomment-604178638 ) back in the esp8266 lite I started with, and now they work the same. I changed pretty much nothing except moving wires around

ROM = 10 80 BA ED 1 8 0 EA
  Chip = DS18S20
  Data = 1 29 0 4B 46 FF FF 8 10 EB  CRC=EB
  Temperature = 20.25 Celsius, 68.45 Fahrenheit
ROM = 28 D8 13 6 2 0 0 F
  Chip = DS18B20
  Data = 1 38 1 4B 46 1F FF 8 10 88  CRC=88
  Temperature = 19.50 Celsius, 67.10 Fahrenheit
ROM = 28 25 F6 AF 2 0 0 5
  Chip = DS18B20
  Data = 1 50 1 4B 46 1F FF 10 10 D9  CRC=D9
  Temperature = 21.00 Celsius, 69.80 Fahrenheit
ROM = 28 95 7 B0 2 0 0 CB
  Chip = DS18B20
  Data = 1 50 1 4B 46 7F FF 10 10 49  CRC=49
  Temperature = 21.00 Celsius, 69.80 Fahrenheit
No more addresses.

Is there any analog problem that can be causing this in any way?

Ah, maybe I just got a clue, I used another 8266 lite from the same batch. One returns good temperatures, and the other ones, not as much. Given that we're doing digital communication, can per chip variances cause this in any way? Maybe a slightly different crystal?

ROM = 10 80 BA ED 1 8 0 EA
  Chip = DS18S20
  Data = 1 28 0 4B 46 FF FF A 10 39  CRC=39
  Temperature = 20.12 Celsius, 68.22 Fahrenheit
ROM = 28 D8 13 6 2 0 0 F
  Chip = DS18B20
  Data = 1 28 1 4B 46 1F FF 8 10 DC  CRC=DC
  Temperature = 18.50 Celsius, 65.30 Fahrenheit
ROM = 28 25 F6 AF 2 0 0 5
  Chip = DS18B20
  Data = 1 58 1 4B 46 1F FF 8 10 69  CRC=69
  Temperature = 21.50 Celsius, 70.70 Fahrenheit
ROM = 28 95 7 B0 2 0 0 CB
  Chip = DS18B20
  Data = 1 53 1 4B 46 7F FF D 10 E9  CRC=E9
  Temperature = 21.19 Celsius, 70.14 Fahrenheit
No more addresses.

And I just got an ESP8266 mini D1 R2 working with the same bus, and 2 sensors are reporting garbage.

ROM = 10 80 BA ED 1 8 0 EA
  Chip = DS18S20
  Data = 1 AA 0 4B 46 FF FF C 10 87  CRC=87
  Temperature = 85.00 Celsius, 185.00 Fahrenheit
ROM = 28 D8 13 6 2 0 0 F
  Chip = DS18B20
  Data = 1 38 7 4B 46 1F FF 8 10 6  CRC=6
  Temperature = 115.50 Celsius, 239.90 Fahrenheit
ROM = 28 25 F6 AF 2 0 0 5
  Chip = DS18B20
  Data = 1 50 1 4B 46 1F FF 10 10 D9  CRC=D9
  Temperature = 21.00 Celsius, 69.80 Fahrenheit
ROM = 28 95 7 B0 2 0 0 CB
  Chip = DS18B20
  Data = 1 4F 1 4B 46 7F FF 1 10 CF  CRC=CF
  Temperature = 20.94 Celsius, 69.69 Fahrenheit
No more addresses.

there is definitely a subtle problem I'm not seeing, and I can't tell if it's hardware, or software...

[uzi18]

Are you sure connections were solid? We have also lots of fake dallases on the market lots of issues, just google it.

[marcmerlin]

@uzi18 thanks for the questions. https://github.com/cpetrich/counterfeit_DS18B20/ says my serial numbers do follow the '28-xx-xx-xx-xx-00-00-xx ' pattern, so they are hopefully not clones? The connections might not have been solid, they were on my desk using alligator clips for testing, and wires going through board holes without soldering.

I realize a non solid connection would have affected an analog sensor, but given that this is a digital protocol, if the connection isn't good, I'll get nothing back, or the typical 85C error temps, won't I?

I was also surprised by this one sample I got back. It looked like bad data on the wire, but somehow the CRC didn't guard against it, so I assume the data had to be bad when it got sent? ROM = 28 D8 13 6 2 0 0 F Chip = DS18B20 Data = 1 FF FF FF FF FF FF FF FF FF CRC=C9 Temperature = -0.06 Celsius, 31.89 Fahrenheit

Would anything cause a sensor to return a temperature that's let's day 5C off if it's not fake? (which I hope mine aren't)

[RobTillaart]

If the communication of the bitstream misses 2 bits 000 instead of 101 you have a difference of 5. Missing a bit can be caused by the 3V3 (or lower?) voltage of the ESP8266

CRC is only 8 bit so a faulty CRC has a chance of 1 in 256 to be correct by chance.

[marcmerlin]

I had a look at the etching with a magnifying lens, and it looks legit. @RobTillaart: at this point I agree that it may be an issue with the 3.3V output on the digital pins, being marginal. @PaulStoffregen does the library return back a CRC error, or does it silently drop the return packet? If I were getting CRC errors, I'd have expected to see some, but I've seen none being output, just bogus temperatures, including the occasional 85C which is an error sent by the sensor itself

[uzi18]

@marcmerlin for 3v3 you should consider 2k7 resistor.

[uzi18]

85 deg. means you have power issues, check 3v3/gnd connections

[marcmerlin]

@uzi18 thanks for the hint on the other resistor, I'll swap that. Well, sure enough, it helped a sensor that was returning bogus data. Everywhere I read said 4.7k referring to 5V, I never thought about swapping the resistor, thank you.

Ok, for the rest of my problems, I'm going to assume that the DS18S20 work better in marginal power conditions tan the DS18B20, which explains what what I've seen. I now have 3 DS18B20 sensors returning virtually the same temperature.

I've done a last test where I added 2 more sensors at the end of a wire, and those two are returning bad data. This seems to verify that if the power is not quite right, sensors can work but return incorrect values. The top 2 sensors are at the end of the line:

ROM = 10 80 BA ED 1 8 0 EA
  Chip = DS18S20
  Data = 1 2F 0 4B 46 FF FF 7 10 60  CRC=60
  Temperature = 23.31 Celsius, 73.96 Fahrenheit
ROM = 28 D8 13 6 2 0 0 F
  Chip = DS18B20
  Data = 1 78 1 4B 46 1F FF 8 10 C1  CRC=C1
  Temperature = 23.50 Celsius, 74.30 Fahrenheit
ROM = 28 B1 96 4D 2 0 0 37
  Chip = DS18B20
  Data = 1 5D 1 4B 46 7F FF 3 10 8C  CRC=8C
  Temperature = 21.81 Celsius, 71.26 Fahrenheit
ROM = 28 25 F6 AF 2 0 0 5
  Chip = DS18B20
  Data = 1 60 1 4B 46 1F FF 10 10 25  CRC=25
  Temperature = 22.00 Celsius, 71.60 Fahrenheit
ROM = 28 95 7 B0 2 0 0 CB
  Chip = DS18B20
  Data = 1 60 1 4B 46 1F FF 10 10 25  CRC=25
  Temperature = 22.00 Celsius, 71.60 Fahrenheit
No more addresses.

[marcmerlin]

@PaulStoffregen , first congrats, you have the most reliable library of the 3 I've used. The other 2 are still having issues on ESP8266 returning bogus data. I've now treied your library with 2 ESP8266 (one mini, one lite) with better wiring and the correct resistor, and it works great. The 2 other libraries aren't working well, but I'll followup with those. Sorry for bothering you for what ultimately was user error (although to be fair, I didn't see the resistor value for 3.3V mentioned anywhere, and turns out it's super important)

[uzi18]

@marcmerlin for ESP/ESP32 you should use this OneWire lib: https://github.com/stickbreaker/OneWire If you power sensors from 3v3 usually it is recomended to use also lower resistor like 2k7 Ohm or less depend on communication problems.

[marcmerlin]

@PaulStoffregen FYI https://www.pjrc.com/teensy/td_libs_OneWire.html mentions 4.7k and 5V when most of your chips are also 3.3V, and some will burn if you send back a 5V signal to them. Maybe somehow their 3.3V is a bit stronger, so they seem to work with the 4.7K resistor, but the signal must be very marginal, and as I found out with all this fun, even if you get an undamaged signal back, the sensor can compute the wrong temperature if they aren't happy with the voltage, and it seems DS18B20 is more affected by this than DS18S20. I'll re-open this bug and let you close it since you may want to update your webpage accordingly.

[marcmerlin]

@uzi18 duly noted, thank you. Now that I have the right resistor, Paul's library works fine, but I can have a look at the ESP version too.

[marcmerlin]

@uzi18 and just to be clear, a huge thank you for the resistor value. I lost almost a day pulling my hair swapping cables and chips and getting marginal results and not figuring out what was going on. Without your help, I might still be doing this :)

[PaulStoffregen]

Since there does not seem to be an software bug here, I'm closing this issue.

I am planning website updates later this year, but not right now.

Please do not tag me for more messages unless there is a confirmed software defect needing my attention. I am very busy with a special project right now. If there really is a software defect, I want to know. But otherwise, I really don't have time for more conversation here.

[uzi18]

It is because Maxim-Integrated prefer to power their 1wire sensors from 5V.

[marcmerlin]

If anyone ends up here with google later: as another thing I found out, my sensors were giving me incorrect temps (10F too high, if not more), when then were attached to the board directly, with the sensor pointing away from the board and not on top of other chips. I'm virtually certain it was not due to heating from the board which honestly is quite limited on an ESP8266 mostly sitting in delay(), but some other weird wiring/signal level issue.

[uzi18]

esp needs high impulse of current make sure you have a large 2000-4000uF capacitor on the 3v3 / gnd module contacts as close as possible

[hallard]

I'm using this lib on STM32 3.3V with 4K7 pullup (no issue so far unless on 1 device lock after days in production but not sure this is the issue) but I'm surprised because this article indicate it should work with internal pull up (of the cpu) up to 50K
https://wp.josh.com/2014/06/23/no-external-pull-up-needed-for-ds18b20-temp-sensor/ So I'm surprised that 4.7K with 3.3V devices could be an issue? Anyone confirm?

[RobTillaart]

The article looks very decent to me, however at least one parameter is not in the equation.

• capacity of a wire also scales with diameter.

Cannot confirm, but I had trouble with other sensors on 3V3 using "5V adviced resistors" and definitely had problems using no pull up's, with I2C in the past.

[hallard]

@RobTillaart Trouble with many sensors with long wires or just 1 with short wire?

[RobTillaart]

@hallard e.g. 4 sensors with 1~3 meters wire or more;
do not recall problems with wire < ~50 cm;

[hallard]

interesting, got 3 sensors on each device 2 with 1 meters and 1 with 2 meters, customer needs 3 meters I need to check that point, thanks.

[marcmerlin]

@hallard in the end my ESP8266 solution did not work if I put the sensor directly on the board (I got the wrong temperature readings and not due to heating from the board), even with a smaller resistor. There seems to be a capacitance issue indeed. By having a 1m wire and putting it at the end of it, I started getting correct temperatures. I didn't look more into it after that since I had already sunk an entire day into something that should have taken 30mn :)

[RobTillaart]

@hallard An option to consider is to use a single pin per sensor. Makes it easier to debug if a sensor breaks down.

[hallard]

Correct for sure it's a good idea, but I'm lack of GPIO and space for connectors. But I'm powering the sensors with a GPIO only when I need to measure, like that no consumption of sensors in sleep mode, this is working pretty good and permit a sleep consumption of 1.5uA instead of 5uA with 3 sensors.