Why does this fix work for DS18B20 error code 85

This is kind of a hack solution for the DS1B820 error 85. An exhaustive web search seems to indicate this value is reported after reading the sensor, it is apparently related to improper wiring, or noise, or something else, but that I don't think that is the entire story. If it was, my "fix" wouldn't work. ("fix" is in quotes because it is really more of a hack... I think the real fix lies somewhere in a library... you may not agree, but that is my best guess given what I have learned through trial and error. I guess it could also be something in the DS18B20 firmware)

I would like to know if anyone else has encountered this, and why my "fix" solves the problem.

In my case, here is what was happening.

  • I get the correct values back at first
  • Next, unplug the sensor while the sketch is running and it reports 127 (as expected)
  • Plug the sensor back in, and it reported 85 (so far, not a surprise)
  • Reset the sketch by closing the serial monitor and reopening it and it still reports 85
  • Download an example sketch from the web, and upload it (the link to the example is below]
  • When the example sketch runs, it begins reporting correctly again
  • Load my original sketch, upload it and it reports correctly again until I unplug, replug the sensor
  • It doesn't matter how many times I reset my sketch or upload it again, the 85 persists
  • Now, the wierd part, upload the example sketch and all is fine.
  • Upload my sketch, and all is fine until I unplug and replug the sensor, then I get the 85
  • Every time I upload the example sketch, the problem corrects until I load my sketch and unplug, replug, etc...
  • This cycle repeats no matter how many times I try

The way I "fixed" it is I added a line in my sketch immediately after the sensors.begin() to request the temperatures, e.g. sensors.requestTemperatures();

That's it!! I have repeated the steps above over and over, unplugging and replugging the sensor, but now, with that one line immediately after the sensors.begin(), it always works. Go figure...

This link takes you to the example sketch that restores the sensor to properly reporting temperatures: DS18B20 (Digital Temperature Sensor) and Arduino - Arduino Project Hub

Again, if I remove the sensors.requestTemperatures() statement in the code snippet below, the problem comes back. This makes me think there is some kind of obscure problem somewhere in either the sensor firmware, hardware, or OneWire or DallasTemperature library, or perhaps in the Arduino IDE.

Here are the versions I am using:
OneWire 2.3.4
DallasTemperature 3.8.0
Arduino IDE 1.8.3

The sensor I am using can be found here: Waterproof 1-Wire DS18B20 Compatible Digital temperature sensor : ID 381 : $9.95 : Adafruit Industries, Unique & fun DIY electronics and kits

My entire sketch is far too long to upload, but anyway, the thing that worked is in the setup() section below. The one thing I will say about the the code in my void loop() section is that I do some things before I read the DS18B20 sensor, but I don't think it is anything unusual. I've eliminated the possibility of such things as buffer overflows such as as writing beyond the end of an array.

  Serial.begin(9600);
  delay(1000);  //added to give the onewire stuff time to initialize.
  
  DBS1820ReadCycleBegan = millis();
  if (SSRDBS1820PRESENT) {
    sensors.begin();
  }
  delay(1000);

  sensors.requestTemperatures();

An exhaustive web search seems to indicate this value is reported after reading the sensor, it is apparently related to improper wiring, or noise,

Did you read the datasheet? It explains why a DS18B20 will give a temperature of 85C.

When it is first powered up, a DS18B20 sets its temperature registers to read 85C. In order to read a valid temperature when using the Dallas library, you must first call the requestTemperatures function. If you don't, you will get the 85C because a temperature conversion hasn't taken place.
Nothing to do with wiring errors or noise. In fact, the wiring must be correct to get 85C.

Pete

1 Like

elliott954:
This is kind of a hack solution for the DS1B820 error 85.

There is no hack, you just need to go about the job properly, and this s a matter, rather than a problem that is essentially self-fixing anyway.

An exhaustive web search seems to indicate this value is reported after reading the sensor, it is apparently related to improper wiring, or noise, or something else, but that I don't think that is the entire story.

It isn't the story at all. It is reported when it the sensor hasn't had time to do its conversion. This can take as long as 750ms.

If it was, my "fix" wouldn't work. ("fix" is in quotes because it is really more of a hack... I think the real fix lies somewhere in a library...

No, it doesn't. It lies in understanding how the sensor works, i.e. reading the data sheet, or the various tutorials.

. I guess it could also be something in the DS18B20 firmware

Correct

my "fix" solves the problem.

I submit the only fix you need is this line
delay(1000);  //added to give the onewire stuff time to initialize.which you apparently have done.

The one thing I will say about the the code in my void loop() section is that I do some things before I read the DS18B20 sensor, but I don't think it is anything unusual

It isn't. Indeed, as your code gets more comprehensive, you don't even need the delay. It is pretty normal to cover things in the setup with preliminary displays, SD checks, etc., whereby it takes more than 750 ms to start reading DS18B20 in the loop.

Next, unplug the sensor while the sketch is running and it reports 127 (as expected)
Plug the sensor back in, and it reported 85 (so far, not a surprise)

It is quite an extremely bad idea to unplug and plug parts back in to an active circuit, and then expect them to work properly afterwards.

Do this with a motor driver and you will destroy it instantly.

Thanks to everyone who responded.

el_supremo was the one who nailed it. Thanks, dude. I did read the datasheet, but silly me, I had commented out the request temperatures line, all the while thinking it was there.

That was my bad... at least I thought I had it in there...

jremington, if you read my post, I clearly said I expected it to quit working when I unplugged it. What should have happened (if I hadn't comment out my request temps line) was for a reset to restore proper operation. It is not a bad thing to unplug a sensor. A motor driver, yep that's bad. This is not driving a motor.

It is not a bad thing to unplug a sensor.

Yes, it is. Do not repeat such nonsense on this forum. You will confuse beginners like yourself.
.

This is not just a thermistor, but a sensor with some processing power inside.

"Reset the sketch by closing the serial monitor and reopening it and it still reports 85"

That will only reboot the MCU, not remove power to the MCU or sensor.
The sensor does not have a reset pin, so must be power-cycled to reset.
Leo..

The comments on any forum should focus on the the question being asked, and not provide ancillary or irrelevant comments.

I wrote up an excellent problem description, and asked a question that had nothing to do with whether plugging and unplugging a sensor is bad. In the future, I would like you to focus on what I ask, and not on your opinions about something unrelated. If you can't do that, then don't respond.

As to whether plugging or unplugging a sensor hurts it, all I can say is I've been doing this stuff for 30 years, and if what you say is true, I would have destroyed thousands of sensors by now. Sensors I have unplugged 10+ years ago are still running today in some places.

If you want to believe it is always bad, that's ok with me. Go ahead and believe it, I don't care.

But the real issue here is not about whether plugging or unplugging a sensor is bad.

Wawa, that is a subtle, but absolutely accurate point you make.

It wasn't clear in my description, but unplugging also power-cycled, and therefore, as you say, reset the sensor.

el_supremo:
When it is first powered up, a DS18B20 sets its temperature registers to read 85C. In order to read a valid temperature when using the Dallas library, you must first call the requestTemperatures function. If you don't, you will get the 85C because a temperature conversion hasn't taken place.
Nothing to do with wiring errors or noise. In fact, the wiring must be correct to get 85C.

Nick_Pyner:
It is reported when it the sensor hasn't had time to do its conversion. This can take as long as 750ms.No, it doesn't. It lies in understanding how the sensor works, i.e. reading the data sheet, or the various tutorials.CorrectI submit the only fix you need is this line

 delay(1000);  //added to give the onewire stuff time to initialize.

This thread is extremely useful.
Everywhere online you read reading 85 is symptom of a wiring problem, while as you correctly pointed out it is mostly a timing problem.

It was extremely frustrating to keep checking and redoing wiring. I wish I had found your posts earlier! (or read earlier the datasheet, of course! Lesson learned).

Thank you very much guys!!

That's good, but it's entirely a timing problem. It is easily fixed but often goes away by itself in more comprehensive projects, where the sensor is given more time to do its job.

jremington:
Yes, it is. Do not repeat such nonsense on this forum. You will confuse beginners like yourself.
.

I suspect people don’t realize that unplugging can involve lots of contact bounce unless done really
fast, which can cause chaos. Plugging in is obviously going to crowbar the supply and have issues,
unplugging feels like it would be benign (which it can be, but in general isn’t)

Wawa:
The sensor does not have a reset pin, so must be power-cycled to reset.

1. Does power-up/power-down/power-up RESET the DS18B20 sensor?
The answer is NO. To RESET the sensor, the following information (Fig-1) must be exchanged between the Master (the host) and the sensor. The RESET is a function which essentially brings the 1-Wire Interface (Fig-2) of the sensor into a state so that it can communicate with the Master. The RESET signal of Fig-1 is created by the Master by executing the ds.reset(); method of OneWire.h Library.


Figure-1: Reset timing for DS18B20 sensor


Figure-2: Conceptual view of the 1-Wire Interface of DS18B20

2. What does power-up do for the DS18B20 sensor?
The power-up event initializes the scratchpad memory (Fig-2) with some known values.


Figure-3: Scratchpad memory map of DS18B20 sensor extracted from data sheets

3. When does the temperature reading show 850C?
In Fig-3, we observe that the BYTE0 and BYTE1 hold the temperature signal of the sensor, and the power-up value is 850C. The power-up value does not come from the sensor; it is arbitrarily loaded, and it can be used as a test signal.

The temperature registers are updated when the Master issues the following temperature conversion command(s); therefore, the conversion command must be issued before acquiring each sample of temperature; else, acquisition process will always collect the last updated value default value (the 850C). Edit: deletion/addition is done in respect of Post#13.

(1) If using OneWire.h Library

ds.reset();
ds.select(dsAddress);
ds.write(0x44);     //actual convert command
delay(1000);         //wait until conversion is done

(2) If using DallasTemperature.h Library

sensors.requestTemperatures();

else, acquisition process will always collect the default value (the 85C).

Not quite true. It is true if there hasn't been a valid conversion since the sensor was powered up. But if it has previously done a successful conversion since power up and then the software reads the temperature without issuing a temperature conversion command or without giving that command enough to complete, then the sensor will return the last temperature reading from the temperature registers.

Pete

el_supremo:
Not quite true. It is true if there hasn't been a valid conversion since the sensor was powered up. But if it has previously done a successful conversion since power up and then the software reads the temperature without issuing a temperature conversion command or without giving that command enough to complete, then the sensor will return the last temperature reading from the temperature registers.

I have to paraphrase/edit my Post#12 to include what (contents of your quoted post) I had in my mind, but it did not come in the writing. Thanks a lot with p... for so meticulous scrutiny of my Post#12.

Hi Golam Mostafa,

Your post #12 seems me to be very valuable. But for some reason I cannot see the figures between your lines of text. I see only blank spaces, subtitled with “Figure-1”, “Figure-2” etc.
Is it a problem of my browser (Chrome on iMac) or outdating of this thread/post?

@elliott954: thnx for starting this topic. I encounter same problems with my ESP32 and 3 x DS18B20 on one oneWire-pin (13). One of these 3 sensors - always the last one in the cycle of 3 - is giving sometimes right temperature value but sometimes this 85.00 (averaged once in 3 samples).

Another problem I have sometimes is that sensors.getDeviceCount() (from #include <DallasTemperature.h>) is giving 0, instead of 3. When this happens also the timings of sensors.requestTemperatures() are not correct, i.e. far too low (2 or 3 millis). At such time also my sensor 3 is giving always 85.00 degrees.

Thnx guys for all info here.

Regards,

Jop

I am missing the pictures too, your browser is probably fine.