How to get rock solid readings and avoid the 85°C and the -127°C problems

[sebitnt]

Hello everybody! I am sorry if this is not be the correct place to share my experience. I think this could help others. I was searching for a way to get around the problems with the DS18B20 giving wrong readings on dodgy wire connections and stumbled about this page with some info on how to distinguish between good an bad readings. After all I was not very satisfied with the information I found about these problems. After some testing I got my own solution, which seems to work quite good for my needs. My final solution was to evaluate the conversion time for the temperature conversion of the sensor. The reading is only processed if the conversion time is higher than a given minimum. This seems to be a good way to determinate if the reading was correctly processed by the sensor. Here is my example code. I hope this helps. The limit has to be changed according to the sensor's resolution.

#include <OneWire.h>
#include <DallasTemperature.h>

#define ONE_WIRE_BUS D3

OneWire oneWire(ONE_WIRE_BUS);
DallasTemperature sensors(&oneWire);
DeviceAddress address;

void setup(void)
{
  Serial.begin(115200);
  sensors.begin();

  if (!sensors.getAddress(address, 0)) Serial.println("Unable to find address for Device 0");
  sensors.setResolution(address, 12);//set to 12 bit
  sensors.setWaitForConversion(true);

  Serial.print("Device 0 Resolution: ");
  Serial.print(sensors.getResolution(address), DEC);
  Serial.println();
}

void loop(void) { 
  unsigned long start;
  unsigned long duration;
  float temp;

  start = millis();       
  sensors.requestTemperatures();
  duration = millis() - start;
  if (duration >= 550) //Conversion should at least take this long. Experimental Values are 9-bit: 70; 10-bit: 140; 11-bit: 300; 12-bit: 550
  {
    temp = sensors.getTempCByIndex(0);
    if(temp == DEVICE_DISCONNECTED_C) {
      Serial.println("Error: Could not read temperature data");
    }
    else //We have a valid conversion
    {
      Serial.print(duration);
      Serial.print(": ");
      Serial.println(temp);
    }
  }
}

[cpetrich]

Thanks. Just meant to share a couple of observations in this regard.

To get this out of the way: I'm actually not familiar with the DallasTemperature.h but meant to point out that the value of "-127 °C" looks like a quirk of the library rather than a reading produced by the chip itself. Not that it matters to the point you're making.

As for undocumented behavior, in my experience, genuine DS18B20 with bad power supply may produce valid readings, incorrect readings, 0x0550 (+85 °C) "start-up" readings, or undocumented 0x07ff (+127.9375 °C) or 0xffff (-0.0625 °C) readings. The details are complicated by the fact that they depend on (a) the number of sensors on the bus and (b) whether the data line is being polled during temperature conversion (i.e., whether conversion time is measured) (--> temperature measurements with slightly poor power may still be doable if the sensor is not polled for completion but rather read after a default time of, say, 630 ms). But basically, if power is bad, a 0x07ff is likely and if power is really bad the reading will probably be a 0x0550.

I can support and add to your observation regarding the timing: we measure the conversion time of the sensors in our probes routinely to determine whether the chip gets insufficient power (typically the result of a poor connection at the Vcc pin). With a slightly bad power supply the reported conversion time increases, even going past 1000 ms (12 bit conversion), but if it gets really bad the reported conversion time is actually 0 ms. I.e., in addition to your test against a lower limit we're also testing against an upper limit. I would call everything outside the 570-630 ms bracket suspect at "normal" temperatures.

Anyways, our use case is different from yours: we want to identify problems before deploying a string of sensors while you want to quality control readings from an already deployed string of sensors.

All of the above applies to genuine sensors with time measured by polling the data line and default 12 bit conversion.

[sebitnt]

Thank you for your answer! You are totally right about the value of "-127°C". You would get this reading from the DallasTemperature library if the device's scratch pad could not be read successfully. The problem with dodgy wiring often is, that the scratchpad can be read nicely but it did not contain a new or an incorrect value due to the delivered power being not good enough to process the temperature conversion. Therefore simply checking against this value does not really work in most cases.

I have never experienced bad reading with conversion times to be higher than the maximum of 750 ms, but that might also be caused by the used library which simply reads out after "MAX_CONVERSION_TIMEOUT" of 750 ms . A check against higher times seems to be easy to integrate and would probably deliver even less bad readings. Thank you for pointing that out!

[cpetrich]

for future reference, in case anybody would like to reproduce increased timing, this is what I did (I do not mean to imply that this is representing a failure mode commonly observed, and in particular not the failure mode you are referring to):

5 V   ---o----[ R_test ]--------- DS18B20 Vcc
         |
         -----[ 1.2 kOhm ]---o--- DS18B20 data
                             |
data  ------------------------

GND   --------------------------- DS18B20 GND

With a single sensor on the data bus (results differ when multiple sensors are connected at the same time):

• With R_test <= 4.7 kOhm, apparently no problems.
• At R_test = 8.2 kOhm polling indicates around 800 ms conversion time and temperature reading is bogus. However, the temperature reading is correct if the temperature is read without polling after like 620+ ms.
• Increasing R_test from 12 kOhm toward 33 kOhm increases conversion time further but the result is 0x07ff or 0x0550.
• Beyond 33 kOhm the conversion time is 0 ms and the result is 0x0550.