Detecting DS18B20

BeanieBots

Moderator
I have done many projects involving PICAXE and DS18B20s but have always had the luxury of not needing to worry about negative temperatures.
As many of these projects involve 'consequences' if there is a sensor failure, I have traditionally used the return value to determine if there is a sensor failure or disconnect.
No sensor returns Value = 0 if using ReadTemp or Value = $FFFF if using one-wire commands.
I now have a project that requires the measurement of negative temperatures.
Thanks to some code snippets by Marks, I have all the issues with handling the negative values sorted with one exception. A value of $FFFF when using one-wire commands is a legitimate value and can no longer be used to determine if the sensor is really there.
I had thought of using the command Readowsn and checking something like the family code but that uses up too many variables which I cannot afford to do. Pushing/popping all those variables might be an option but it seems a bit extreme.
Is there a simple one-wire command that can use just a single variable that I could use to reliably determine the presence of a DS18B20?
I've had a look at the Dallas datasheet but all I managed to get was a headache!
Any help much appreciated.

PS this is using a 28X2
 

hippy

Technical Support
Staff member
Could you not just use READTEMP instead of READOWSN; if OWIN returns $FFFF go check READTEMP and confirm that's not zero ?

I am sure there's some OWOUT/OWIN command which could quickly determine if a particular known device were there but not sure off-hand what it would be.
 

BeanieBots

Moderator
Unfortunately not. If the temperature is zero, READTEMP will return 0 and OWIN will return $FFFF.
These are the same values that a disconnected sensor would return. ie it is not possible to distinguish between 0'C and a disconnected sensor.
Also, my servo loop cannot afford the luxury of using READTEMP due to the lost 750mS of processing time.
I'm hoping that somebody might know how to use OWIN to read just the family code or some similar function that would confirm DS18B20 presence.
READOWSN will solve my problem but I would need to push b6 - b13 and then pop them back for the 15 sensors I'm using.
 

westaust55

Moderator
With the 1-wire commands, at power-up/reset of a DS18B20 a OWIN command to read in the temp will have a reading of 85 degrees if a Tconv command has not been sent first.

That does necessitate that you already know the device serial No.

Also only a valid test is the normal temp range does not get as high as 85 detached.

Unfortunately, while there is a broadcast capability to send arcing to all connected chips but not aware of a means of reading back from a specific device without first knowing the serial No.

One possibility is to use the 1-Wire SearchROM command but read the majority of bytes into a single byte variable and just keep the family code separate. That will only work however if there is just one device connected to the 1-wire bus.
 
Last edited:

BeanieBots

Moderator
Westy, you're thinking is along the lines of what I want to do.
This particular app has all the sensors on separate inputs because there is a real possibility that replacement might be required and providing a method of having a 'user' enter a new serial number would be excessive. I do know all the serial numbers though as this is required for the calibration certification.
The non-initialised 85'C is also within the valid operating range but that is a risk I can live with because temperatures in that range can be corroborated by other sensors. My problem is when there is a legitimate temperature of 0'C.
Use of the SearchROM command (and as you say, all bytes going into one variable) is the sort of thing I want to do. I just don't know how to do it. Reading up on it just scrambled my poor little brain.
If I knew how to do READOWSN using OWIN commands and put all the data into one byte, I could use family code to determine that a device really did exist.
 

BeanieBots

Moderator
Thanks marks. That looks like what I'm after.
I'll have a play next time I have access to the hardware. (or more probably knock up a quick test version).
Your other posts on DS18B20/OWIN/OUT have also been of great inspiration. Thanks for sharing.
 

BeanieBots

Moderator
Hi Westy,
No, don't recall it. Can't believe it didn't come up when I was searching prior to posting.
I found a lot of marks's work which helped a lot. I've only just had a quick scan through your posts and it looks like many of my questions might be answered there.
I recall having a play with CRC a few years back and it may well have been based on your work but my brain no longer functions as well as it did a decade ago.
I'll have a more thorough read in the morning with some caffeine to help digest the content.
 

hippy

Technical Support
Staff member
Unfortunately not. If the temperature is zero, READTEMP will return 0 and OWIN will return $FFFF.
There seems to be a better alternative emerging but thought I'd come back to this because I believe it should work, perhaps had not explained it well ...

-1C : OWIN/OWOUT = $FFFF, READTEMP = $81
0C : OWIN/OWOUT = $0000, READTEMP = $00
Not connected : OWIN/OWOUT = $FFFF, READTEMP = $00
 
Last edited:

BeanieBots

Moderator
Hi hippy, I had indeed missed some of that subtlety.
I can't afford the 750mS required by READTEMP but I might end up re-considering it depending on how code/variable hungry a more elegant/faster method proves to be.
Hope to play with some actual hardware soon. This is only going to be a rare issue and probably very transitional so a few missed servo loop iterations might not be too significant. It would certainly offer a very quick and easy solution. In fact, I think it will become the solution while I develop the alternative, and we all know how temporary solutions turn out.
 

inglewoodpete

Senior Member
Just a thought but you have concerns that you might not recognise that a DS18B20 is present when it is reading a temperature of 0C or 85C. I have read elsewhere that self-heating can be a problem when used with a pullup resistor of the wrong value. Could controlled self-heating be used to indicate that the DS18B20 is present due to changing readings?
 

BeanieBots

Moderator
Not really a practical solution because it would involve a significant hardware change and added complexity, but could work in theory. (I've had the self heat problem when I used a 330R instead of a 3k3)
As this is a fairly dynamic system, one thought was to simply count successive readings of suspect origin and set a trip point if not changed within that count but that would be quite a tedious task and variable consuming.
I'm going to play with a real device and some of the OWIN/OUT commands as described earlier, so hope to have a solution soon. I've also decided to work in Kelvin because these temperatures get passed around several PICAXE chips and using Kelvin will avoid passing negatives over serial and all manner of downstream calculations. It's then an easy conversion for any that need to be displayed. At the point of reading a "missing" sensor can simply report its value as some absurd high number such as 500'C and easily be spotted by those routines that need to know. The 85C problem remains but I think it is low risk.
 
Top