Ruben

Thanks for the answer.  Is this the defined behaviour?  Seems odd that th=
ey=20
would put in a valid checksum for an invalid result.  My application won'=
t=20
allow the sensor to be hot-swapped, but being in a (noisy) automotive=20
environment, I can expect problems like this, especially using parasite=20
power.

I see what you are doing here, but then why bother to write to the EE at =
all? =20
On startup the config register can be written to, and then read back=20
continuously.  A change there would indicate a reset, so just ignore the =
85,=20
re-write the config register and proceed.  In my existing code (which is =
sort=20
of a test/debug mode), the search rom runs at startup and the number of=20
sensors found flashes quickly on the display.  Then all sensors are=20
configured at once.  Seems like an easy change to *not* have it write the=
=20
config to the EE.  I'll have to experiment with the idea.

Still seems odd that this would be its intended behaviour though.

Cheers,
-Neil.


On Tuesday 12 July 2005 03:38 am, Ruben J=F6nsson scribbled:
> 85 deg C is the default value after power up (or reset) before a
> temperature conversion has been done. I have an application where the
> sensor can be removed during conversion so I have to know if it has bee=
n
> removed and power cycled after a temperature conversion command has bee=
n
> sent. I also use 2 wire interface (parasite power). This is how I have
> solved it and it seems to be working OK.
>
> 1. Do a recall EE to read the alarm trigger values into the scratchpad.
>
> 2. Read the scratchpad.
>
> 3. Invert the alarm trigger values and remember the values.
>
> 4. Write back the scratchpad (without copying it to EEPROM)
>
> 5. Do a temperature conversion and wait the time required by the select=
ed
> resolution.
>
> 6. Read the scratchpad.
>
> 7. If the alarm trigger values still are the same as the values written=
 to
> the scratchpad (which is the inverted value of the EEPROM) the temperat=
ure
> is good.
>
> Of course also check the CRC after every read.
>
> This is based on the fact that the EEPROM is copied to the scratchpad o=
n
> power up and if the scratchpad has changed back to the data in EEPROM a=
fter
> a temperature conversion, power is most likely cycled to the sensor and=
 the
> temperature is not valid.
>
> Regards / Ruben
>
> > I've implemented some 1-Wire code to read a DS18B20 sensor using a PI=
C,
> > using parasite power.  Still in testing on a breadboard, it sits ther=
e
> > all day with 2 sensors on the bus reading ~28 deg C.  But periodicall=
y,
> > perhaps once every few hours, I get an odd value of "85", or "-21" on=
ce
> > interpreted from the DS18B20's format.  Seemingly important, this wor=
ks
> > out to B'10101010', and even more important is that it passes the
> > checksum test.
> >
> > I can now reproduce this by removing the positive power from the sens=
or.=20
> > And it's always that magic "85".  Is there some significance to this,=
 so
> > that I can figure out how to determine it's bogus and not display 85?=
  I
> > can't find any reference to this value or bit pattern being generated
> > when power to the chip is lost or otherwise.  That it's passing the
> > checksum test is really bothering me.
> >
> > Cheers,
> > -Neil.
> >
> >
> >
> > --
> > http://www.piclist.com PIC/SX FAQ & list archive
> > View/change your membership options at
> > http://mailman.mit.edu/mailman/listinfo/piclist
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
> Ruben J=F6nsson
> AB Liros Electronic
> Box 9124, 200 39 Malm=F6, Sweden
> TEL INT +46 40142078
> FAX INT +46 40947388
> ruben@pp.sbbs.se
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D


--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist