DS18B20 temp sensor addressing issue

[Seekonk]

I've just started working with the DS18B20 temp sensor.  One of the good things is the addressing, it is also the bad thing.  Entering addresses is fine for a hobby project, entering addresses in a production environment is not.   And then there is that sensor that has to be replaced in the field.  My project would only have four sensors so I could devote a pin to each one.  There are lots of addressable things out there so there must be a plug and play method out there and I'm just having a brain cloud.  There must be a method to put sensors in a string and have a first come first served, RC on power buss?  Is this a case where 90% of the code will be devoted to sensor selection?  Looking for a clue.

[DmitryL]

I've just started working with the DS18B20 temp sensor.  One of the good things is the addressing, it is also the bad thing.  Entering addresses is fine for a hobby project, entering addresses in a production environment is not.   And then there is that sensor that has to be replaced in the field.  My project would only have four sensors so I could devote a pin to each one.  There are lots of addressable things out there so there must be a plug and play method out there and I'm just having a brain cloud.  There must be a method to put sensors in a string and have a first come first served, RC on power buss?  Is this a case where 90% of the code will be devoted to sensor selection?  Looking for a clue.

Am I missing something here ?
http://www.maximintegrated.com/en/app-notes/index.mvp/id/187

On the other hand... Ok, you put all your sensors on the same 1-wire bus and using search algorithm find that they have UIDs N1, N2, N3, N4. Then how do you tell which UID  has  the _physical_ sensor chip you are looking at, even if you know that it is one of N1, N2, N3 or N4  ?

[mikerj]

I went through this a few years ago.  The solution I implemented was a semi-automated sensor selection.  At power on the firmware checked an EEPROM for the existence of (checksummed) sensor addresses. If the checksum failed (i.e. new unit or corrupted EEPROM) it went into set up mode.

First it ran the discovery algorithm and checked for the presence of the required number of sensors. It then worked though each address and via the display instructed the user to warm the sensor whilst polling the temperature of all the sensors.  The one with the increasing temperature is assigned the appropriate sensor ID, saved to EEPROM with checksum and then the firmware moved onto the next address.

Might not be very useful for production purposes though.  Would it be possible to fit one sensor at a time and power up the module after each one has been fitted so it can discover the address of the next sensor in the sequence?

[LabSpokane]

Another option is to try mikerj's discovery scheme but with hot plugging the sensors into the bus. As long as one builds in some protection to the bus with TVSS devices or such, I don't think there is much hazard in this. I've hot plugged my DS18B20s and been able to incrementally discover them.

[Seekonk]

In all their great wisdom, this was likely designed for a market I don't fully understand.  It does seem like an obvious problem for production.  It would be nice to set a bit to use an address supplied by the customer into the scratchpad.    A simple test jig would allow programming the sensor to be #15.  That seems more useful than the high temperature limit.  Isn't that what the micro is supposed to do?  You could put a pseudo address in the high temp, then have the micro find all the sensors and assign a location based on that. 

[Kjelt]

Yeah the one wire multiple device protocol is not very friendly. As long as the number of sensors is limited < 10 why not use a GPIO per device. Much easier.