- Wed Sep 14, 2016 4:05 pm
#55114
I have a lot to say on this topic as I did a lot of research getting it all to work for me. Here are two threads that will tell you more than I can write here:
viewtopic.php?f=153&t=10190&start=0viewtopic.php?f=43&t=10279&start=0Let me address some of your questions more directly.
What about distance? You can go further than you think if you are not using parasitic mode (no resistors required that way). As I looked at the code, I didn't find parasitic mode supported in the first place nor could I get it to work. Distance depends on a lot of factors, including bit rate. My hallucination is that the DS18B20 is using something around 16kbps. I've run RS232 at 9600 for about 1500 feet but we are dealing with lower voltage and suspect loading. Instead of predicting how far you can go, use best practices. For long runs, do not use parasite mode (which I don't think is an option here anyway). Use your data and ground on twisted pair. Your Vcc can be on anything. I'd be surprised if you had trouble going more than 20 feet and who knows, you might get a couple hundred feet.
Device number and ROM code correlation? Each DS18B20 has a unique ROM code. When a string of sensors is put on the wire and queried with an "all call" (as the TEMP() function does) each begins transmitting its response while watching the wire. They proceed bit by bit in unison but when they send differing bits, one of them prevails (I forget whether it's a 1 or a 0). When a device sees that it did not prevail, it stops transmitting and waits for the transmission to finish before trying again. Since the ROM code is part of the response, you will never have two devices thinking that they both succeeded. So if there are three devices on a wire, the "all call" starts them all responding. If "Fred"completes successfully, the TEMP() function calls him #0 (regardless of his ROM code). If "Barney" is next to succeed (because Fred saw that he succeeded earlier and quit) then the TEMP() function calls him #1. Now "Wilma" responds, getting a #3 designation. Because the ROM codes (which we don't know) are set, the device numbers will correlate as long as the collection of sensors does not change. However, if a rat chews through Barney's wires and he drops out, the TEMP function will now call Wilma #2 because it does NOT store device id numbers between calls. If we add "Betty" to the wire, we have no idea what her device number will be and who she might bump down the list but it will depend on where her ROM code lands in the order of those already present. You can see how this may be a serious problem especially since it is almost undetectable!
Regarding max numbers of sensors? The way the library is used in the interpreter, as many as you like. Thousands even! This is because NO data is stored on each sensor and they are addressed by an "all call."
Practical limits? Last I checked, you could not use ROM codes in the sensors to address them one at a time. The function is doing an "all call" so that every sensor reports. They report in order of ROM code and by using TEMP(N) the function just discards the first N responses to get you the desired device. Note that it is addressed by relative device number in the collection on that wire, NOT by ROM code. This presents a problem in that EVERY device will respond and tie up the wire for what could be quite a while. Worse, if you want to query ALL your sensors, you repeat the whole parade N times! So the time it costs is N squared times response time. YIKES! I have one application where I need to address many sensors and this is going to be an issue. If you wanted to use 1000 sensors and want to address them all, you start with a 1,000,000 multiplier to the time it takes to get a single response. You don't want to wait that long!
Work-around? I can multiplex the wire so that each sensor is on an independent path to the wire. So I address each path one at a time, do the "all call" via TEMP() but only one response comes in instead of the whole collection. This makes the time penalty just N times response time (and a little switching of the multiplexer). Ugh! If sensors could be addressed by ROM code, all sensors can stay on the same wire. There is slightly more time spent by the ESP8266 broadcasting the ROM code in the request, but then ONLY that device replies. The time penalty is again about N times response time and you no longer have to worry about failing devices because you always identify positively. I have been absent for a while and if the interpreter has already been modified to handle ROM codes, please forgive me for going on about the matter. If not, I think the necessary change to the interpreter would be as follows in this post:
viewtopic.php?f=43&t=10279&start=6I almost forgot! Perhaps the most helpful thing I can lend is this. When you are trying to get a DS18B20 to work, there are two telltale values to watch for. If you get a -127 this means something went wrong and there was no response for that device number. Check your wiring and don't try to use parasite mode with the interpreter as it is now. If you get a return value of 85 (and you're positive that you are not measuring something close to the boiling point of water) this means that the sensor did respond but it sent its default temperature register value because it did not do an analog to digital conversion. The TEMP() function essentially sends out a reset command, then tells all connected sensors to convert the temperature to digital, then it tells all of them to send their results. I found a bug in Branch 2 where the TEMP command did not send the conversion request but the TEMP() function did. If you use Branch 2, ALWAYS use the function!
