Hi all:

I've been reporting for a while that alarming was not working with
DS18B20 temperature chips.  Today we have finally gotten the traces
and compared to the Dallas data sheets to figure out exactly why
they're not working.

Thanks to the relatively new bus traffic debug feature, we were able
to get this.

It appears that all the alarming setup stuff works.  We did find a bug
in the reading of the alarm values: owfs only reads from the
scratchpad; it does NOT first copy from the alarm EEPROM to the
scratchpad.  Therefore, unless you just set the alarm value, the value
OWFS reads out is actually not correct.

After setting Thigh and Tlow, we entered into a loop of echo "1" >
simultaneous/temperature followed by a ls of the alarm directory.  In
our case, the temperature chip always shows up in the alarm directory,
even when it should not.  However, if we cat fasttemp for a chip, it
will disappear from the alarm directory.

Today's research revealed that the issue is that OWFS is NOT handling
the bus powered situation correctly.  It looks like the alarming
function would work perfectly if all of our DS18B20s were externally
powered.  However, we run all of ours parasitic.  I suspect that some
logic needs to be added to OWFS to "know" if it has at least one
bus-powered chip (there's a simple OW command that can be run to do
this, IIRC), and then it would need to execute the strong pullup after
a convert command.

Thanks!

(BTW: our test version of OWFS 2.8p3 with owtraffic, used with the
dallas USB bus master blows up randomly with cannot reconnect errors;
2.8p2 worked stably.  We did not check 2.8p4.)

--Jim
CASAS Lab Manager @ Washington State University

------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Reply via email to