We did some hacking on the source code. With a very basic hack to change the delay on a simultanous temperature command, alarming on bus-powered 18b20's now work. I think this hack is not production-ready, but it does appear to be a fairly easy fix.
--Jim On Tue, Jan 4, 2011 at 3:34 PM, Jim Kusznir <[email protected]> wrote: > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/owfs-developers
