Eric Vickery wrote:
I disagree. 85 is a valid reading since the chip can read from -10 to
You disagree with what...? If with It's inconsequential in the scheme
of things. I meant to say in the scheme of things in my software. It
*may not* be inconsequential for engineers who are trying to
Perhaps there are some hints here.
You are using external power (non-parasytic) and a DS18S20?
The code is supposed to lock the device (use a mutex to exclude other
threads from that chip) issue a CONVERT command, wait 1sec, then read
results. If it's functioning correctly, the only reason that
Yes, the die trim values and all that are exposed in OWFS.
Paul Alfille
On 12/6/06, Mark Richards [EMAIL PROTECTED] wrote:
Here.
David Lissuk who maintains 1wire.org has published a list of chips
identified to have the POR problem. Check over there for more details.
I've snatched it from
Am Mittwoch, 6. Dezember 2006 01:14 schrieb Paul Alfille:
Currently, the only aggregate we support is the TAI-8570 barometer, which
uses 2 DS2406. In that case, the DS2406 memory is used to point to the
partner chip, so the aggregate can be autodiscovered. There is certainly
an appeal to
On 12/6/06, Paul Alfille [EMAIL PROTECTED] wrote:
Perhaps there are some hints here.
You are using external power (non-parasytic) and a DS18S20?
No, some of the DS18S20's are parasitic some are not. Only 2 are
throwing the error. If I remember correctly one is parasitic and one
isn't
The
Curiouser and curiouser.
So your tests are
A -- single loop against DS18S20 sensor A
A+A -- two processes against sensor A
AB -- single loop against sensors A and B
AB+AB -- two processes each AB style
Only AB+AB fails?
And the failure is after a number of readings?
Are A and B different? One
I just did a csv co, bootstrap, and now I run configure with
./configure --disable-owphp --disable-owperl
--with-python=/usr/local/bin/python2.4
But python doesn't get enabled. I know I've mentioned this problem on the list
a
while back, and finally resorted to hacking configure. But, has
