hi there i have a DS18B20 sensor about 100m away from the Arduino all works fine took a bit of playing with the hardware but works fine but every now and then it will flash up 85 and -127 which i think is a connection failure (correct me if I'm wrong), so what i have done to over come this is this:
so if the reading is outside 2 and 50 it will wait for a bit and if it is still outside it will display error.
this seems to work fine i don't see the 85 anymore but the -127 still show up, why is this what have i done wrong??
The sensors1.getTempCByIndex(0) returns a float number, you request that twice, and the values could be different. Get the temperature just once, and check that temperature.
float t = sensors1.getTempCByIndex(0);
if (t >= 2.0 && t <= 50.0) {
I prefer to compare the float variable "t" with "2.0" and "50.0", since that are float values, the "2" and "50" are integer values.
I was just about to post a question concerning the DS18B20 when I saw Joes post.
I don't know the answer and perhaps I misunderstand but wouldn't it be a good idea to sort the connection out first? There has to be something more to this question I guess.
Personally I have found no problems developing my project as far as the DS18B20 is concerned.
What I wanted to know is where to find a list of the Dallas Temperature Library commands. There are several example sketches in the IDE but the commands have no explanation and it's left me confused (as usual). I gather, perhaps wrongly, that the wire and oneWire Libraries are no longer preferred.
I agree, Joes should try to fix the cause, instead of a fix in code. What if the temperature is 100 degrees or -20 ?
The DEVICE_DISCONNECTED_C of -127 degrees is when the sensor is not connected or the checksum failed. I don't know why sometimes a value of 85 is returned.
Well, they lack good documentation.
On the pjrc.com page is some documentation, and the library does not have many function. But the depower() function is not explained very well.
The DallasTemperature explains it usage with the many examples, but for all the functions only the source code provides all information.
What do you mean that the Wire (I2C) and OneWire (1-Wire) libraries are no longer preferred ? (Almost) everyone uses those libraries. Of course they are preferred, what else do you want to do ?
I have not had a chance to play with the DS18B20 yet (have parts but not the time yet -- soon !!), but doesn't the part also return a CRC that you can check? That was one of the reasons I liked it from reading the specs a while back - with an analog sensor that I have used in the past, if you have a poor connection (due to rain etc getting in the connector), you don't know if it is off or not. When you have a digital sensor that provides a CRC, you know if you read the data correct or not.
Well Koepel, this is how it has gone so far: when I started this project I adapted code from LadyAda (or whatever) and it was really a bodge job because I didn't look hard enough for some guidance on what the commands meant. It worked however, pro tem.
I took a break and when I managed to come back I found the examples of code seem to have changed quite a lot. In looking for further help I have read that the wire libraries are buggy, (I think on the pjrc website) - I'm a novice and so, easily misled.
I was used to commands begining ds.XXXXX Now it seems the commands are without the ds. Is this down to the Dallas Temperature Library?
I know I can find the keywords in a library but they don't explain their function do they? I have found an explanation of LCD commands on the arduino site (LiquidCrystal - Arduino Reference) but have failed to find something similar for the DS18B20.
I agree, Joes should try to fix the cause, instead of a fix in code. What if the temperature is 100 degrees or -20 ?
The DEVICE_DISCONNECTED_C of -127 degrees is when the sensor is not connected or the checksum failed. I don't know why sometimes a value of 85 is returned.
if the reading is smaller than 2 and bigger than 50 i have a issue, in my application, i agree that i should fix the cause but i don't think I'm going to get it perfect as the cable length is about 100m and it is clipped with a load of 3 phase cables, not ideal i no but not much i can do, and yes it is in screened cable (cy) and the screened is connected at one end to earth.
Adrifran39,
The OneWire library is not buggy. However, the 1-Wire protocol requires specific timing, and that might interfere with other specific timing things.
Please to not use the term "Wire", that is the library for I2C.
The ds.XXXX or sensors.XXXX is just a name. The examples use sensors.XXXX.
You don't need the DallasTemperature library. With the OneWire libraries is an example sketch for low level DS18B20 code. That is often enough to get the temperature. In my projects with a single DS18B20, I use that OneWire example, and I remove all the debug info.
The DS18B20 is explained well, but the OneWire and DallasTemperature are specific Arduino libaries. They could use better documentation indeed.
This explaines the scratchpad : Arduino Playground - OneWire
The Arduino (and user written libraries) are changing now and then. That means that sometimes a update/rewrite of the code is needed. That's just how it is with an ongoing open source project.
Joes, okay, I get your point, you are using such a long cable. I have a project myself in which the DS18B20 is constantly read in the "background" (when nothing else needs to be done), and only the last valid data is stored
Joes:
if the reading is smaller than 2 and bigger than 50 i have a issue, in my application, i agree that i should fix the cause but i don't think I'm going to get it perfect as the cable length is about 100m and it is clipped with a load of 3 phase cables, not ideal i no but not much i can do, and yes it is in screened cable (cy) and the screened is connected at one end to earth.
You can't have your cake and eat it too. Can you see that any software fix is going to be flakey? What I would do, is put a Pro Mini at the measurement location and have it send the data back in a protocol that is reliable on a 100m cable.
When you have things working at the edge of spec, all it takes is a change of the phase of the moon or a grumpy gremlin to make it fail again.
When you have things working at the edge of spec, all it takes is a change of the phase of the moon or a grumpy gremlin to make it fail again.
hehe yes agree
You can't have your cake and eat it too. Can you see that any software fix is going to be flakey? What I would do, is put a Pro Mini at the measurement location and have it send the data back in a protocol that is reliable on a 100m cable.
i could, but the location gets very wet (if it gets hit by the pressure washer 1000psi (very wet)) at times and can get knocked about and some time ripped out, if its just a sensor its not to bad to replace.
i could, but the location gets very wet (if it gets hit by the pressure washer 1000psi (very wet)) at times and can get knocked about and some time ripped out, if its just a sensor its not to bad to replace.
It's not about sensor failure. It's about an unreliable connection. Why would replacing the sensor help?
A software solution requires understanding the problem very well. For example, if you decide to take 10 consecutive readings and reject it if they don't all agree. But what if the errors come in that way, like 10 consecutive bad readings?
I'm just saying, think about the time you're using to apply chewing gum and band aids. It might exceed the time it takes to fix it.
Another thing to consider is a partway relay, like an interface 5m or 10m from the sensor, and 90m or 95m of cable to go the rest of the way.
The sensor need some time to measure correct value. If you try measure too fast temperatures it send this kind of error data. Also some little error can effect that it sends 85.
tolerance_zero:
"every now and then it will flash up 85"
The sensor need some time to measure correct value. If you try measure too fast temperatures it send this kind of error data. Also some little error can effect that it sends 85.
Some little error, as could be caused by the capacitance and noise on a 300 foot long cable when trying to clock a 5k impedance at 20KHz.
Koepel:
I agree, Joes should try to fix the cause, instead of a fix in code...............
I don't know why sometimes a value of 85 is returned.
I submit the code could be a cause and should be addressed first. Being a bit more forthcoming with the intent would be helpful, as the code is incomplete but probably slack-arsed and
}
delay(100);
}
is probably unreasonable.
Far more important is the word "sometimes", but the cause is probably the same.
The 85 is returned when the sensor has not had time to do its job, and there is an implication therein that there is nothing wrong with the circuit. The most common time to see it is at power-on with a simple programme with a short setup, when you get it just once, and it will go away when it is given more to do, like an SD card check.
The -127 indicates bad connection. The intermittency indicates the whole thing is flakey and possibly subject to the phases of the moon, as Aarg suggests.
Sure, first thing I would do is run an example sketch to verify the hardware. Divide and conquer. But if the errors are intermittent, it might have to be modified to log them.
Very good topic Joes, as I'm fighting with DS18B20+Quantity(12)+Distance(100m) I would like to know the hardware "improvments" that you implement to allow the sensor reading at your distance.
Thanks!!!!
keep the bus without the stubs or if any, it should be shorter than 2.5cm
avoid of star topology
as the bus is longer, decrease the value of pullup, normally it is about 5k, it can go down to 2k7 for 100m (?).
I am using ~70m with 4k7 pull-up, 8 sensors, STP cable, without problems.
