DS18B20 return 0.00°C

michinyon: as you have apparently demonstrated,

Well, there is nothing apparently about this, it works, has done so for a long time, and has never been a problem.

Having said that I have now found two things out

  1. I have evangelised about the original Hacktronics programme over the years but have only recently realised that I have moved away from it somewhat myself. The subroutine in that programme does not merely get the temperature, it gets the tgemperature and immediately prints it. Hence no value is returned.

  2. While the programmes I am currently using only imply a return command, and deliver, my archived files show a return.

So I'm not going to quibble about this and I have edited the above code to show the extra line and, yes, I have tested that too. I don't think this has anything to do with OP. I imagine the problem is in the code he hasn't shown, which isn't mine.

I notice odd readings from my ds18b20 devices from time to time, perhaps it is inevitable

I don't think so - I've been running one logging temperature every 90 seconds for three years now - the only time I see any discontinuity in the data is when there's been a power outage. Early on I did have problems, especially when trying to use parasitic power, but since it started working, it's been flawless.

I have reported a bug in the Dallas lib a few month ago - https://github.com/milesburton/Arduino-Temperature-Control-Library/issues/16 -

It describes a case in which the Library returns 0.00C A patch is proposed but it is not included yet.

You can check if it matches your problem and try the patch

Well, thanks for all those answers ! Regarding the bug in the Dallas library, it seems to be quite exactly what I experienced... But I believe I have to wait for a new release of the lib including the patch ?

Michinyon : about this RAM problem... does the "print" function consume RAM all the time, or only when there is something to receive the information (like my PC connected all the night) ? Because the biggest part of the "display" part of my prog (after the "else" in the code I posted) was there since the beginning, and run for several months without a PC to receive (except for one minute every month or so to retrieve min and max values)...

About the heater causing the problem, I did not explain it entirely : in order to control the fan, electric heater or dehumidifier, the arduino is using 3 electromagnetic relays. As those relays use an electromagnet to switch on and off, I believe they draw some power from the arduino... In my debug test, when I turned the heater manually on (always using the EM relay) and the temp fell down to 0, the heater wasn't even plugged to the EM relay ! So my thought is : may the power drainage from the heater's EM relay disturb the sensors ? And in this case, why does the problem never occur with the fan's or dehumidifier's relays ? I you have any idea, please let me know ! I will try to fix as well as I can the software part of the problem, but if there is a hardware part... might as well try to correct it too !

Thib

wildbill: I don't think so - I've been running one logging temperature every 90 seconds for three years now - the only time I see any discontinuity in the data is when there's been a power outage. Early on I did have problems, especially when trying to use parasitic power, but since it started working, it's been flawless.

Which library are you using ? Could you post the part of your code where you set up the sensors and get the temperatures ?

michinyon: ...So, as far as I know, there isn't an issue with the one-wire code. But if you originally followed the same bad advice or bad example as the other poster did, you may have the same issue. There are a lot of very bad examples of how to access sensors on the internet, on youtube, github, instructables, etc. So you might want to check your part of the code, to see if you had the same issue.

Here is the code I got from the internet (or maybe directly from the examples of the Dallas library, I don't remember) to set up the sensors :

Serial.begin(9600);
    // Start up the library
  sensors.begin();
  // locate devices on the bus
  Serial.print("Locating devices...");
  Serial.print("Found ");
  Serial.print(sensors.getDeviceCount(), DEC);
  Serial.println(" devices.");
  // report parasite power requirements
  Serial.print("Parasite power is: "); 
  if (sensors.isParasitePowerMode()) Serial.println("ON");
  else Serial.println("OFF");
  if (!sensors.getAddress(insideThermometer, 0)) Serial.println("Unable to find address for Device 0"); 
  if (!sensors.getAddress(outsideThermometer, 1)) Serial.println("Unable to find address for Device 1"); 
  // show the addresses we found on the bus
  Serial.print("Device 1 Address: ");
  printAddress(insideThermometer);
  Serial.println();
  Serial.print("Device 2 Address: ");
  printAddress(outsideThermometer);
  Serial.println();
  // set the resolution to 11 bit
  sensors.setResolution(insideThermometer, TEMPERATURE_PRECISION);
  sensors.setResolution(outsideThermometer, TEMPERATURE_PRECISION);
  Serial.print("Device 1 Resolution: ");
  Serial.print(sensors.getResolution(insideThermometer), DEC); 
  Serial.println();
  Serial.print("Device 2 Resolution: ");
  Serial.print(sensors.getResolution(outsideThermometer), DEC); 
  Serial.println();

I've checked my versions of the Dallas and OneWire libraries, and I already had the last one... I've also checked the RAM available when receiving all those serial.print function, and it stayed at 898 for about one minute (I didn't check longer). I will log the same data again tonight (along with the available RAM) to see if I get another problem or if I can see a memory leak ;) I'll keep you updated

TIbzor: Regarding the bug in the Dallas library, it seems to be quite exactly what I experienced...

Is it?

Judging by the title this is about a bug when the wire is broken and

running SINGLE.INO with no DS18B20 connected to the pin does return 0C and 32F

implies this happens when only one sensor is being used.

If this is really what you are experiencing, it might be simpler and quicker to fix the wire than wait for a new library.

There's no point in blaming the library, it has worked too well for everybody else. There's not much in blaming the sensors either. They are very reliable, and (trust me on this) they can take a lot of abuse. I have had three of them giving readings at one second intervals more or less continuously for over two years, without the faintest suggestion of a problem.

This tends to point the bone at your code. I said before that I assumed yours was derived from the same tutorial as mine. It isn't, but you might look there.

http://www.hacktronics.com/Tutorials/arduino-1-wire-tutorial.html

My code is attached here: http://forum.arduino.cc/index.php?topic=69165.0

Libraries would have been whatever was current at the time.

However, although I haven't seen zeroes in the data, I discovered that I do actually get them but the sql I use to get the values for graphing deliberately drops them. Looking in my database, there was a period of some days when I got nothing but zero, apparently only resolved by a power outage causing the system to reset.

So not quite as flawless as I thought.

Regarding the bug in the Dallas library, it seems to be quite exactly what I experienced... But I believe I have to wait for a new release of the lib including the patch ?

Never wait for a patch if you need it ... just apply it yourself (after making a copy of the original code of course)

Hi. I do not use DallasTemperature library with DS18B20, just OneWire library and some functions extracted from the former one to read the sensors, but have been able to reproduce the problem when both the sensors and pullup resistor are disconnected. Can it be that since the arduino pin now floats during the read cycle then OneWire::Reset function does not properly detect the absence of the sensor? For example after issuing "skip rom" and "convert temperature" commands and then after delay attempting to read temperature from multiple sensors gives 0.00 C for the first sensors, remaining ones are properly detected as missing. I am not really able to follow the OneWire library code but it looks like OneWire::Reset function checks first that the bus is high before pulling it low, then checks it again after delay assuming now that the slave has pulled the bus low. If the pin floats high before reset and remains low after the pulldown then missing sensor is not detected and following command reads all the data bits and CRC as 0.

Concerning all the verbose Serial print function calls, it is my understanding that when the linker sets up the code and ram images for your sketch, the default behaviour is that effectively variables are created in the ram space which hold all of the text strings that you are printing there. It does this unless you specifically force it not to, by putting those text strings into the flash memory where the machine code of your program goes. On the arduino, most users run out of ram before they run out of flash space for their program. That is why there are so many threads explaining how to use progmem and F ( ) macros to put the text into the flash memory.

Nick_Pyner: If this is really what you are experiencing, it might be simpler and quicker to fix the wire than wait for a new library.

There's no point in blaming the library, it has worked too well for everybody else. There's not much in blaming the sensors either. They are very reliable, and (trust me on this) they can take a lot of abuse. I have had three of them giving readings at one second intervals more or less continuously for over two years, without the faintest suggestion of a problem.

This tends to point the bone at your code. I said before that I assumed yours was derived from the same tutorial as mine. It isn't, but you might look there.

http://www.hacktronics.com/Tutorials/arduino-1-wire-tutorial.html

I don't really see how that can be a problem with the wire itself : if it was damaged or not properly plugged, it would not work at all, would it ? Instead of that, both sensors works perfectly fine nearly all the time, but return wrong values sometimes... However, here is a new wire-related lead : is it possible that the power drainage due to the activation of the heater, or the proximity between the data wire and 220V cables can disturb the data sent by the sensors ? Regarding the code, I seem to have the same as everyone else : apart from the difference that I use 2 sensors instead of one, I have exactly the same code as Wildbill (thanks, Wildbill !)...

robtillaart: Never wait for a patch if you need it ... just apply it yourself (after making a copy of the original code of course)

Even if I can understand most of the advice and code given here, I don't know if I can mess with some library code ! But maybe it's quite simple ?

michinyon: Concerning all the verbose Serial print function calls, it is my understanding that when the linker sets up the code and ram images for your sketch, the default behaviour is that effectively variables are created in the ram space which hold all of the text strings that you are printing there. It does this unless you specifically force it not to, by putting those text strings into the flash memory where the machine code of your program goes. On the arduino, most users run out of ram before they run out of flash space for their program. That is why there are so many threads explaining how to use progmem and F ( ) macros to put the text into the flash memory.

I've logged all sensors data since 1pm yesterday, and the available RAM stayed at exactly 822... Sadly, the computer manage to lose the serial connection during the night ! So, even if the system seems to have worked fine for all the night, I don't have any trace of it after around 1am :/ Maybe the serial port is not made to do any "long" data logging after all...