How to handle DallasTemperature 85 °C

Hi,

I'm about using DallasTemperature lib for hot water measurement application.

85 °C is in the range, and I don't see a support in the lib for changing the default value.

I'm using the poll reading only. Many example codes has this 85-comparison as an illegal value, so it seems that libarary can returns this without any error signalling.

I'm browsing the library code but if someone has handled this already clever way or can give instructions to re-program the boot-up value outside the functional area, I'd appreciate.

Or am I safe if polling, and setting setWaitForConversion() as TRUE?

I have used both 18B20 and DS1820 -sensors.

Can I do this by:

writeScratchPad(deviceAddress, TEMP_LSB);
writeScratchPad(deviceAddress, TEMP_MSB);

The 85 is telling you that the sensor has not had time to do its conversion. The maximum time required is 750ms. The time it is most often seen is right on startup and you only see it once.

This is fixed by either putting a delay(1000): in Setup or by giving the programme something to do, like checking an SD card or drawing a splashscreen.

If you are seeing it more frequently, the problem is essentially the same and is fixed by increasing the loop time to something more appropriate.

If you really need very frequent readings, you are probably using the wrong sensor, but you might get a satisfactory result by decreasing the resolution to 9 bit.

No real comment on "18B20" sensors, but I guess they are just a no-name version and probably work to the same principles.

Nick, thank you for your answer.

I think the risk here is that for example a damaged wiring makes Dallas to boot up just before reading the value.

On the other hand, can someone tell if the default TRUE for waitForConversion flag actually ensures the real values in my (polling) case?

But I think writescratchpadding a new value to TEMP_LSB, TEMP_MSB (if I get the msb and lsb decoding right for both families and all resolutions) will do the thing. Maybe I just warm up the chips near 125 °C (or anything out of my expected range) , and copy the extracted raw value.

I'll let you know after a try.

corcovado:
damaged wiring makes Dallas to boot up just before reading the value.

"bad" might be a better way of describing it but, if it only happens once, it isn't really a problem and, if you get up more ambitious code, it will probably go away. I'm sure all this conversion flag, scratchpad, and warming the chips stuff is just nonsense. There are a few ways to use the DS18B20, some of them pretty bad, and I rather suspect you are using some obsolete, i.e. junk, code. Please don't tell us you have been reading Instructables.....

Nick,

I'm confused of your comments.

85 °C is in my expected operating range, and if TI has decided to signal an error or whatever state by sending a default temperature of 85 °C, I need to do something for it. Of course I want my software and meters to react this, and I can't make them react to 85.

I haven't seen values like this but I want my things to work sound and proof when they are not on my desk anymore. I have no FOTA arrangement for the shipped thing :-(.

I'm using ESP8266, and it will boot up in loops all it's life, and I have no slightest idea what happens in I/O and external 3 v during that. Hopefully I don't need to. I'm using three-wire connection.

Library version used is #define DALLASTEMPLIBVERSION "3.7.7", hopefully that works.

Warming or cooling the sensors somewhere outside the operating range was an idea of putting a correct suitable value to registers without calculating it backwars (maybe wrong).

Actually it helped me a bit that after crosschecking all my sensors are of type #define DS18B20MODEL 0x28, so according to my current (volatile) understanding by looking at DallasTemperature::calculateTemperature() -function it holds the temperature in scratchPad[TEMP_MSB] and scratchPad[TEMP_MSB] only, so plain

int16_t fpTemperature =
(((int16_t) scratchPad[TEMP_MSB]) << 11) |
(((int16_t) scratchPad[TEMP_LSB]) << 3);

should apply.

How do I code here for example 125, it's not too clear to me.

EDIT: actually in datasheet there is fortunately couple of raw value example values, and 125 is presented there.
Still I'm confused of the resolutions (mine is 12 by default) and shiftings I need to do with my desired default temperature.

I was also worried if I need to calculate CRC, but I think _wire->write(COPYSCRATCH, parasite) in ::writeScratchPad takes care of it.

Hopefully we get in tune with this.

The DallasTemperature library does all the fancy footwork for you.
You don't need to do anything with the scratchpad registers. You tell the library to start a conversion (requestTemperatures) and then get the temperature (getTempC or getTempF). There are other variations on these functions (e.g. getTempCByIndex) but that's the basics. Have a look at the code for the library. There are also plenty of example code in these forums if you dig around.

Pete

corcovado:
I'm confused of your comments.

#define DALLASTEMPLIBVERSION "3.7.7", hopefully that works.

#define DS18B20MODEL 0x28

Not nearly as confused as I am. Your last bit of code even seems to imply that a DS18B20 is a device for use on the I2C bus, which it isn't - to the point where I wonder if you are really using a DS18B20.

If you are, reply #5 and the link in reply #3 is the best advice you will ever get on this, and I suggest you read them again. As I said, there is more than one sensible way to use the DS18B20 within the Arduino realm, but all of them "getting in tune" and using the Miles Burton library, without which you are simply wasting your time re-inventing the wheel, and clearly getting a square one.

I'm confused of the resolutions (mine is 12 by default) and shiftings I need to do with my desired default temperature.

If you read the data sheet, you will see that the conversion time increases with the resolution, hence my previous comment. It is quite OK to do nothing and use 12bit by default.

Library version used is #define DALLASTEMPLIBVERSION "3.7.7", hopefully that works.

This does not look like Arduino code, so, unless you are using some programming method I know nothing about, it probably won't.

el_supremo:
The DallasTemperature library does all the fancy footwork for you.
..
Pete

So you guys are saying I'm using a sledgehammer to crack a nut?

My application is in no hurry, just measuring boiler, and doing no control.

I just saw in various forums people telling about their agony with that 85, which is a sort of indication something going wrong. My problem is that 85 is on my operating range, so I'd really like to change that default value to not having to worry about it.

Nick,

Thank you for your contribution to my challenge.

Nick_Pyner:

Your last bit of code even seems to imply that a DS18B20 is a device for use...

This does not look like Arduino code, so, unless you are using some programming method I know nothing about, it probably won't.

The code snippets and copied symbols are ALL from Burton's DallasTemperature library, version 3.7.7 :smiley:

Nick_Pyner:

If you read the data sheet, you will see that the conversion time increases with the resolution, hence my previous comment. It is quite OK to do nothing and use 12bit by default.

Yes, there's no hurry, there's no control or tuning involved (only slow measurements), so 12 bit is fine.

Thanks, folks, I think I'll manage..

corcovado:
My problem is that 85 is on my operating range, so I'd really like to change that default value to not having to worry about it.

It is not a problem, you simply need to properly understand what's happening and why, and the means of avoiding the event are explained in reply #1, q.v.

You also need to understand the purpose of a library, which is strongly hinted at in reply #5. It is a really good idea to do that before you start fiddling with it.

#define DS18B20MODEL 0x28

This is correct. If you print out the ROM address of a DS18B20, you will get for example:

0x28, 0x6E, 0xDD, 0xA4, 0x05, 0x00, 0x00, 0xEE

The first byte identifies the device type, with 0x28 identifying a DS18B20. If instead the first value is 0x10 then the sensor is a DS18S20.

#define DALLASTEMPLIBVERSION "3.7.7"

Also not a problem. It just identifies the current version of the library and is the version I'm using right now.

The value of 85 isn't a problem if you use the Dallas library. It handles the sensors correctly and will (in theory) not return a value of 85 unless it is the correct value.

Pete

So, both of you Nick and el_supremo have no checking of value 85 in your application code?
You just include 85 as accepted value to your data if it appears?

I haven't used a DS18B20 in a project where 85C was a valid temperature. So, if 85C occurred, it was an error - but then, anything above about 45C would have been a problem too.
In your application I would probably read the sensor once in the setup() function and ignore the result. That way if 85C occurs at power up, I ignore it. After that, I would trust the Dallas library to get it right.

Pete

corcovado:
You just include 85 as accepted value to your data if it appears? Oh man...

Well, yes, but it's not what you are implying. What we did say is that it isn't a problem, and it never appears, other than legitimately, anyway - unless you don't know what you are doing. Any illegitimate reading of 85 is a either coding problem, or a bad power wiring problem, both of which you should fix before the device goes into use. Two ways of ensuring it never appears due to coding are explained in reply #1, which you apparently refuse to read. I can't remember when I last saw an 85, I guess it was about five or six years ago, and, if I ever do see it, I know exactly what I am seeing - a legitimate reading of 85.

You are just trying to see difficulties that are not really there. You will sleep a lot better if you stop fartarsing around with libraries, treat them for what they are, and just get on with the job of reading temperatures. A means for doing so is quoted in reply #3, and there are plenty of others like it.

Nick,

  1. Wirings can fail during their expected life-time, and I want the gadget be aware if it ever happens.

  2. My challenge was being able to separate the default value from real one without a hassle. I tackled that by changing the default value.

Thanks for participating.

corcovado:
85 °C is in my expected operating range, and if TI has decided to signal an error or whatever state by sending a default temperature of 85 °C

Its just that the value of the temperature register is set to 85C at power up, and will read that until the
first conversion is complete.

Just arrange to wait for the first conversion to complete before reading the register and all will be well.

Ooops!

I tried, then found out from datasheet it's not possible. Only three bytes are written to EEPROM.. :frowning:

When I don't trust a readout of a DS18B20 (e.g in the 85 C range), I compare with a DHT11 or (better) with a BMP280. The BMP80 is a reliable I2C barometric pressure / air temperture sensor, and does not express '-127' and '85' errors.

If one new or existing device does not work, compare with a known device <<
Succes !

Photoncatcher,

Thanks, I try to live with Dallas now. Fortunately I have several sensors doubles, and I do the intelligent parts in web server, so my ESP8266 code remains clear.

I managed to get 85 degree values appearing by some connector cranking. While not really knowing what could have been the costs of having this configurable, I really see this something Maxim hopefully re-designs some day, or releases a new family.