Reliability of DS18x20 temperature sensors

[mozobata]

I'm using Maxim's DS18x20 (I've actually got more than one variant) 1-Wire temperature sensors to log the temperatures in various rooms in my house once a minute. About one reading in a thousand, I get something completely bogus back. In the middle of a sequence that's gradually rising from 65F to 70F I get something like -32.1F or 15.64F.

Here is theds18b20 datesheet.


Has anyone else had that kind of problem, or is this something wrong with my setup? If this is just a known issue with these things, I'll have to do something like taking three readings and throwing out the outlier.

Just a few statements about my setup:

I'm running at 3.3V
I'm checking the checksum of the reading as it comes back to the arduino, and it matches (or I think it does - there could always be a bug in that code).
These are running off of normal power, not parasite power.
I have the 4.7K pullup resistor in place.
I'm only using a single sensor on each sensing platform.
The sensor is on a PCB attached to the arduino that's reading it.
I see the same problem reading from a variety of different arduinos (diecimilla, pro-mini, homemade custom)

[sbrazz]

I've attaced the CRC code I've been using for years, as well as my temperature reading subroutine. It reads one temperatue each time its called and initiates the next conversion for the next time. So in my case it takes 5 calls to get all my temperatures. I call it once a minute.

[attachment=0]Temperature Reading.bas[/attachment]

Actually when I try to compile my code with the current BASICTOOLS (5.56) the following line gets an error:=


j = owout(11 ,10 ,OutBytes)
-ERROR D:/OneDrive/Sisyphus/House Monitor/housemon.bas: 967: Expected numeric Function

But also when I copy and run the example given for ONEWIRE.bas it gives the same error:-

#include <ONEWIRE.bas>
'...

DIM message(20) as string
DIM response(20) as string


message = chr(&Hcc)+chr(&Hf)+chr(6)+chr(&Haa)+chr(&H55)

' write to the scratch pad of a DS2430
present = owout (7,5,message)
print present

message = chr(&Hcc)+chr(&Hf)+chr(6)

print present
owin (7, 3, message, 2, response)
print hex(response(0)),hex(response(1))


It still compiles correctly on ARMBasic 7.49

Does anyone know why?

[basicchip]

The compiler version ARMbasic is the most important, the current version is 9.36 or so. (reported in Help->About)

The file you posted is missing the #include <ONEWIRE.bas>
and does not define the byte arrays OutBytes or InBytes or the string TEMPIN.

Also if your code would ever get there, it would try to execute CRCcheck inline which would crash. You need an END before it.

I fixed those, then it fails with PrintFlags undefined, and it looks like it should be a global.

also no include of RTC>bas, or definition of i in GetTemp

... really looks like you only posted part of your program

[basicchip]

So what ARM product are you using?

What does it say in the Welcome message when it boots (that is the firmware version)

What compiler version?

The BASICtools version, is the GUI, and does not change all that often, mainly to add new features, like allowing for firmware updates, or compiled hex file uploads were the most recent.

[sbrazz]

Sorry. I should have explained more. They are only subroutines within a larger program where all the #includes are at the top of the program as well as all the variable definitions. I just posted them for Mozobata to have a look at. The program has been working for years, it runs my solar heating, heat pumps and ponds.
I am using an ARMWeb, but I can't really stop it now. I'll attach the whole program. It compiles correctly on ARMBasic 7.49 which I used to install it

[sbrazz]

But even this example from the help file on owout (i've inserted the main: and end) on ARMbasic[9.36k]

present = owout (7 ,5, outbytes)
-ERROR D:/OneDrive/Sisyphus/House Monitor/new1.bas: 12: Expected numeric Function


present = owout (7 ,5, outbytes)
-ERROR D:/OneDrive/Sisyphus/House Monitor/new1.bas: 12: Expected Operand


present = owout (7 ,5, outbytes)
-First ERROR at line :12


#include <ONEWIRE.bas>

DIM outbytes(10) as string
main:
' write to the scratch pad of a DS2430
outbytes(0)=&Hcc
outbytes(1)=&Hf
outbytes(2)=&H6
outbytes(3)=&Hbe
outbytes(4)=&H41

present = owout (7 ,5, outbytes)
print present

end




gives the error message:-
present = owout (7 ,5, outbytes)
-ERROR D:/OneDrive/Sisyphus/House Monitor/new1.bas: 12: Expected numeric Function


present = owout (7 ,5, outbytes)
-ERROR D:/OneDrive/Sisyphus/House Monitor/new1.bas: 12: Expected Operand


present = owout (7 ,5, outbytes)
-First ERROR at line :12

[sbrazz]

I Think I've found the problem - the old compiler uses and old ONEWIRE.bas - which has this Function for OWOUT which returns temp:-

FUNCTION OWOUT (pin, OUTcnt, BYREF OUTlist as string)
DIM temp as integer
DIM i as integer

INTERRUPT (0)
temp = ow_reset(pin)

i = 0
do
if OUTcnt = 0 then
if OUTlist(i) = 0 then exit
endif
ow_sendbyte( pin, OUTlist(i))
i=i+1
until i = OUTcnt

INTERRUPT (1)
return temp
END FUNCTION

whereas the new compiler uses a new version of ONEWIRE.bas which has this sub for owout:-

SUB OWOUT (pin, OUTcnt, BYREF OUTlist as string)
DIM i as integer
i = 0
do
if OUTcnt = 0 then
if OUTlist(i) = 0 then exit
endif
ow_sendbyte( pin, OUTlist(i))
i=i+1
until i = OUTcnt

END SUB

But with the former at least you get some indication that the transmission was a success.
So the call j= owout(...) gives an error.
Sure enough remove the J = and it compiles correctly

[basicchip]

Oops Sorry

We moved all the code into a git last year and looks like we grabbed the old version of ONEWIRE.bas. There is also a ONEWIRE1.bas which was the original. I'll update the setup files today.

[PericeFinco]

Hi...i am a new user here. As per my knowledge as you are logging, you'll need accurate timekeeping. Separate RTC with its own battery? Then you can have the RTC alarm feature wake the AVR periodically, solving several problems. Let's say 10uA for the deep-sleeping AVR. What is your wake current going to be? If you are going to be awake 1% of the time one second every minute or two you can draw about 10mA when awake and meet the 100uA average.

seo consultant