I didn't know there is a variety of libraries but you might as well replace them using the link I posted above, if only to be sure you are using what everybody else uses, and I understand Hacktronics take pains to keep up-to-date.
I recall the DS18B20 examples left a bit to be desired, but you are past that anyway.
You can hardly go wrong by sticking a in delay and seeing how you go. Besides, how frequently do you really need to read the temperature for a sensible result? Just put it in the last line of the loop and adjust it as you need. I have delay(850); which gives me time-stamped recordings to SD at one second intervals. Note that the number of sensors has no bearing on the delay.
By the way I wasn't saying don't add an extra delay but the DallasTemperature library should take care of it for you.
With a wireless sensor I've made I switch off the power to the temp sensor between reads and it does need more than 750ms to get a proper read. I had to experiment with different delays otherwise I was getting 85 every time.
But if you don't use DallasTemperature and just use OneWire this won't apply anyway.
Actually my sensor sleeps between calling requestTemperature and getting the value. You can switch off the DallasTemperature delay() call and do other stuff instead.
hello all
right for some feed back, it is better but still get 85.0 on the display every now and then so think it is just the length of the cable, so what i was thinking if i limit the temp from -30 to 50 and when it is outside that range it would just display error with a time delay
but if i short the temp pin to gnd it display 0.0, so was wondering if we could do it if we don't get a sig back it will display error instead of a temp range?
I guess you can verify that the long length of cable is the problem by temporarily replacing it with a short length.
The 85 is the power on reset value, with accent on the words "power" and "on". This clearly tells you when you should see the 85, if you see it at all, and implies how often - namely, only after the power is turned off.
If you see it "every now and then", I think it suggests the power is going off when it shouldn't, i.e. the problem is mechanical. Neither your code nor your workround procedure sound like a good idea, principally because nobody else needs to do it and I can't see why you should be the first, and they are probably not the way to solve a mechanical problem.
You can also verify the voltage at the sensor end, but I think the data sheet says they can run on a very low voltage. I therefore guess the problems with long cables are more down to the signal wire, interference etc.
I guess you can verify that the long length of cable is the problem by temporarily replacing it with a short length.
dun that and 85 goes away
If you see it "every now and then", I think it suggests the power is going off when it shouldn't, i.e. the problem is mechanical. Neither your code nor your workround procedure sound like a good idea, principally because nobody else needs to do it and I can't see why you should be the first, and they are probably not the way to solve a mechanical problem.
power supply at arduino end if fine on oscilloscope and i have a battery backup using MCP73871
but yes the power at the other end of the cable mite not be any good i no but the only way i could over come that would to put a power supply at the sensor end but that is not a option unfortunately
i don't think other people have this problem because they don't have a sensor so far from the arduino, others seem to wireless or somthing
don't for get this cable is clip with about 30-40 3phase cable (not ideal i no)
You can also verify the voltage at the sensor end, but I think the data sheet says they can run on a very low voltage. I therefore guess the problems with long cables are more down to the signal wire, interference etc.
I don't think I explained myself very well. I guess no voltage is not the same as low voltage, and I believe the "85" suggests periodic "no voltage". I believe it doesn't take much to get grief with long cables, just three metres was enough for me, but I took the coward's way out and moved the Arduino. Your problem may be exacerbated by the very long length, and the local electrical environment.
Joes:
so why can i not get this to work?
I can't comment on the code, other than that I would never use it.
I don't think I explained myself very well. I guess no voltage is not the same as low voltage, and I believe the "85" suggests periodic "no voltage". I believe it doesn't take much to get grief with long cables, just three metres was enough for me, but I took the coward's way out and moved the Arduino. Your problem may be exacerbated by the very long length, and the local electrical environment.
yes i do understand, but i can not move anything and wireless is not a sensible option for me, so for that 10-20% of the time my voltage is to low i was thinking of getting the arduino to ignore the reading and wait for a sensible reading to come in.
this is what i was trying to do on post 23 what seems to be working at mo, but when you get 0.0 it does not seem to work, just display 0.0 this is by i was asking on post 26. any ideas?
While I don't think your approach is a good one, I'm afraid I don't have any better ideas other than to use better cable. I can't help but feel that you might have an intermittent problem that might get worse, thereby making the wait for a decent result intolerable, but using a decent cable will at least reduce the count of potential villains.
I do hope you are not using parasitic power for this.....
