> Ruben
>=20
> Thanks for the answer.  Is this the defined behaviour?  Seems odd that =
they=20
> would put in a valid checksum for an invalid result.  My application wo=
n'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.

Yes, this is defined behaviour according to the datasheet.

>=20
> I see what you are doing here, but then why bother to write to the EE a=
t 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 th=
e 85,=20

I don't write to the EEPROM. The whole idea is to make sure that the scra=
tchpad=20
is different from the EEPROM and if it is still different after a tempera=
ture=20
conversion there has been no (power on) reset. Note that this is not the =
1-wire=20
reset pulse. You could also use the config register but then you must mak=
e sure=20
that it is different from the value in the EEPROM.=20

> re-write the config register and proceed.  In my existing code (which i=
s 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 t=
he=20
> config to the EE.  I'll have to experiment with the idea.

But you still have to make sure that the value in the EEPROM is different=
 from=20
what you are actually using (in the ram config register).

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

Yes, it would make more sence to have a bad CRC for the temperature regis=
ters=20
at power up before any temperature conversion is done. But I guess that t=
he CRC=20
is made on the fly and only appended after all other bytes have been sent.

Regards / Ruben

> Cheers,
> -Neil.
>=20
>=20
> 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 b=
een
> > removed and power cycled after a temperature conversion command has b=
een
> > sent. I also use 2 wire interface (parasite power). This is how I hav=
e
> > solved it and it seems to be working OK.
> >
> > 1. Do a recall EE to read the alarm trigger values into the scratchpa=
d.
> >
> > 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 sele=
cted
> > resolution.
> >
> > 6. Read the scratchpad.
> >
> > 7. If the alarm trigger values still are the same as the values writt=
en to
> > the scratchpad (which is the inverted value of the EEPROM) the temper=
ature
> > 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=
 on
> > power up and if the scratchpad has changed back to the data in EEPROM=
 after
> > a temperature conversion, power is most likely cycled to the sensor a=
nd the
> > temperature is not valid.
> >
> > Regards / Ruben
> >
> > > I've implemented some 1-Wire code to read a DS18B20 sensor using a =
PIC,
> > > using parasite power.  Still in testing on a breadboard, it sits th=
ere
> > > all day with 2 sensors on the bus reading ~28 deg C.  But periodica=
lly,
> > > perhaps once every few hours, I get an odd value of "85", or "-21" =
once
> > > interpreted from the DS18B20's format.  Seemingly important, this w=
orks
> > > 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 se=
nsor.=20
> > > And it's always that magic "85".  Is there some significance to thi=
s, so
> > > that I can figure out how to determine it's bogus and not display 8=
5?  I
> > > can't find any reference to this value or bit pattern being generat=
ed
> > > 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
>=20
> --=20
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>=20

=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