I've been using the OneWire library and Dallas Temperature Library mentioned in the the other recent topic on DS18B20. In the example code at MilesBurton.com, one of the comments says this:
Why "byIndex"? You can have more than one IC on the same bus. 0 refers to the first IC on the wire
Is this implying that temperature ICs can be enumerated in order along the bus? I've been unable to get this to work. I have a breadboard with two ICs on it, but no matter which order I plug them into the bus, they are always enumerated in the same order, which is not by position.
My end goal is to read the sensors in a grain bin temperature cable. I've verified that it has six DS18B20 sensors in it, and the order of the sensors is very important in order to get valid readings from the cable. So far on Linux with a usb adapter I've been unable to enumerate them in any kind of order so I'm trying with Arduino now. But as I mentioned, I'm failing to get an order. There must be a way to do this as the commercial temperature reader unit can read the cable temps in the proper order without knowing beforehand the addresses of the ICs.
As I understand it, you have to separately identify the unique ID of each sensor, then program that ID into the code that reads all of them.
Here are a couple of good tutorials:
Edit: The commands do allow remote determination of all the IDs of the devices, if more than one is on the bus, but I don't think it is possible to identify which ID is physically associated with which device in that case. Someone correct me if I'm wrong!
From the data sheet:
SEARCH ROM [F0h]
When a system is initially powered up, the master must identify the ROM codes of all slave devices on the bus, which allows the master to determine the number of slaves and their device types. The master learns the ROM codes through a process of elimination that requires the master to perform a Search ROM cycle (i.e., Search ROM command followed by data exchange) as many times as necessary to identify all of the slave devices. If there is only one slave on the bus, the simpler Read ROM command (see below) can be used in place of the Search ROM process. For a detailed explanation of the Search ROM procedure, refer to the iButton® Book of Standards at Mixed-signal and digital signal processing ICs | Analog Devices.
Yes I know that. Been through the tutorials. And I also know there are other 1-wire devices that support a sequence detection which would be ideal for an application like this. But these off-the-shelf cables use only DS1820Bs. So either there is a mapping of ids to position that I've not yet decoded, or the reader unit is sniffing out the physical order. Because I can take a brand new cable that the commercial temperature reader has never seen yet and it will pull in the temps in the correct order.
Just wondered if I missed anything because the comment on that web page I quoted suggests that devices are discovered in order of their placement on the bus, which does not seem to be correct. That was what I was asking about. Is that comment incorrect or am I just doing it wrong?
The Search ROM cycle is deterministic and will always pick up the sensors in the same order, so between power cycles, the same sensor will always be sensor one. What it can't do is map the physical arrangement of the sensors - as far as the circuit is concerned, they're all at exactly the same place.
Your commercial sensor array is relying on something else to get the position data. How many wires are there?
With six sensors I would give every sensor its own pin of the Arduino. That way you can guarantee that even if the algorithms change you will always know what sensor is where.
have done a project with a similar problem and this solution just works perfectly.
other option might be using a multiplexer, although I do not recall any such story here on the forum recently .
There really is no problem using multiple DS18xxx on one pin, if you go to the effort of finding each unique ID and label each device. Those things have been around for well over a decade and are extremely reliable. They will not go away anytime soon, either.
I found that Miles Burton stuff implies what you say it implies, and is misleading junk. I understand you are faced with a pre-existing situation, and I assume you can get at the individual cables. No amount of electronic sniffing is going to tell you where a sensor is physically located. The Hacktronics system enables you to identify the individual codes. All you have to do then is know where that sensor actually is, which you need to know regardless of the system you use, and identify it by sticky label or whatever, to make its unlikely replacement more convenient.
Spreading the sensors over multiple pins is pointless, deprives you of an advantage you have paid for, offers nothing in return, and is just a silly idea you could regret in the future.
I recognise that the value, and shortcomings, of these things may depend somewhat on where you are on the road to Damascus, but the previously-mentioned Hacktronics tutorials seem such a sensible way to go.
wildbill:
The Search ROM cycle is deterministic and will always pick up the sensors in the same order, so between power cycles, the same sensor will always be sensor one. What it can't do is map the physical arrangement of the sensors - as far as the circuit is concerned, they're all at exactly the same place.
Your commercial sensor array is relying on something else to get the position data. How many wires are there?
Right okay. So I wasn't missing anything then. Really it's a matter of just figuring out how the manufacturer is mapping ICs to position using the address.
The cable uses two wires, parasitic power configuration.
Nick_Pyner:
I found that Miles Burton stuff implies what you say it implies, and is misleading junk. I understand you are faced with a pre-existing situation, and I assume you can get at the individual cables. No amount of electronic sniffing is going to tell you where a sensor is physically located. The Hacktronics system enables you to identify the individual codes. All you have to do then is know where that sensor actually is, which you need to know regardless of the system you use, and identify it by sticky label or whatever, to make its unlikely replacement more convenient.
Thanks for confirming this. So yes now just to figure out the IC addresses map to position. The manufacturer has to have a system for putting which IC where, because each cable reads properly in order on the commercial device, even if it's a brand new cable the device hasn't seen before. Fortunately I know where the ICs are in the cable; I can just read them with the commercial handheld reader and then go see what arduino sees and correlate the temps. Fortunately the temps seem to increase (most of the time) from the bottom of the cable to the top of the silo, so it's easy to work out which ic is where. Then hopefully I can find the pattern so that a new cable can be plugged in and it also is read properly.
I just had a hunch that I'll check when the weather is a bit warmer. I bet that the 1wire's deterministic discovery algorithm is taken into account when making the cables. I'm embarrassed to say never tried my arduino on a real cable yet. Previously I used a laptop with a USB 1wire adapter and OWFS to read the real cables. Probably outsmarted myself. I bet Arduino with OneWire finds the sensors in the logical position order. And I also bet that if I had tried a bit harder with OWFS I could have got the sensors found in the right order on the laptop too.
Again, if you are making up the cables, the obvious approach is to arrange the sensors along the cable in order of increasing ID values. The ID is simply a unique 64 bit number. The only time this approach would create a problem is if you have to replace one device.
Yes, good point, although I don't plan to make my own cables. The off-the-shelf ones are decently priced, and specially-built for the application. IE they can withstand the force of thousands of bushels of grain pulling on the cable.
Nick_Pyner:
...
Spreading the sensors over multiple pins is pointless, deprives you of an advantage you have paid for, offers nothing in return, and is just a silly idea you could regret in the future.
...
I do not agree with you on this, it really depends on the requirements of your project.
I have worked on a project for which this "one pin per sensor" strategy was the only cheap and fool proof solution. Cheap as manufacturing became substantial easier as determining the addresses wasn't needed, and also foolproof as replacing a broken sensor always worked. Diagnoses which sensor failed (if any) was also deterministic this way. The internal addresses do not give any clue where they are on the 1Wire bus.
But I agree it costed additional "native" pins, and if possible using only one pin has the advantage of only using one pin.
Idea: It would be great if there was a (variation on the) one wire bus in which devices could be daisy chained so that every sensor has a data pin and a "bus through" pin. This latter would be connected to the data pin of the next sensor. And so on. Then you could implement an additional protocol to do a hop count to determine the location on the bus. Drawback could be a failing sensor breaks the bus.
I said it was a silly idea you could regret in the future because it is a silly idea you could regret in the future. This is because of the very nature of Arduinos, which may eventually look rather under under-employed just sitting there reading DS18B20s.
Since the project involves using sensors already installed, it is a fair bet that the reason for using an Arduino is that whatever it replaced was inadequate and thus the additional potential of the Arduino is likely to become apparent. This can involve displaying the readings, recording the readings, sending the readings somewhere else, and doing something as a consequence of the readings. In the light of that, you will be amazed how long it doesn't take to run out of pins, and starting out using six where one would suffice simply means wasting 25% of the stock available, which can't possibly be a good idea.
And using a Mega is not necessarily a means of avoiding the regret.
If you don't use one, or both, of the DS18B20's alarm registers you can use one to store a label. Write a sketch which stores a user-supplied character in the alarm register and then write that label on the sensor. You then write the monitoring/logging code to use these labels.
E.g. assign label 'A' to be the first one on the bus etc. If a sensor dies, label a new one with the same letter, replace it and away you go.
el_supremo:
If you don't use one, or both, of the DS18B20's alarm registers you can use one to store a label. Write a sketch which stores a user-supplied character in the alarm register and then write that label on the sensor.
God, these devices are just wonderful. Sounds like time for little lengths of heatshrink on the cables
el_supremo:
If you don't use one, or both, of the DS18B20's alarm registers you can use one to store a label. Write a sketch which stores a user-supplied character in the alarm register and then write that label on the sensor. You then write the monitoring/logging code to use these labels.
E.g. assign label 'A' to be the first one on the bus etc. If a sensor dies, label a new one with the same letter, replace it and away you go.
Turns out that's exactly what the cable manufacturer was doing. The temphigh alarm field contains a bin #, and templow alarm field contains the sensor number in the cable. So if anyone is googling on how to read the MaxStor bin temperature cables, hopefully they find this.
Nick_Pyner:
...
Spreading the sensors over multiple pins is pointless, deprives you of an advantage you have paid for, offers nothing in return, and is just a silly idea you could regret in the future.
...
I do not agree with you on this, it really depends on the requirements of your project.
I have worked on a project for which this "one pin per sensor" strategy was the only cheap and fool proof solution. Cheap as manufacturing became substantial easier as determining the addresses wasn't needed, and also foolproof as replacing a broken sensor always worked. Diagnoses which sensor failed (if any) was also deterministic this way. The internal addresses do not give any clue where they are on the 1Wire bus.
But I agree it costed additional "native" pins, and if possible using only one pin has the advantage of only using one pin.
Idea: It would be great if there was a (variation on the) one wire bus in which devices could be daisy chained so that every sensor has a data pin and a "bus through" pin. This latter would be connected to the data pin of the next sensor. And so on. Then you could implement an additional protocol to do a hop count to determine the location on the bus. Drawback could be a failing sensor breaks the bus.
I am in the same boat as the OP. Reading multiple DB18B20 sensors on the same cable is a bit unreliable.
Would you mind sharing the sketch, or part-of-the-sketch, which shows how the individual sensors connected to separate pins work?