Am 09.10.2015 um 07:15 schrieb Loren Amelang:
>
> I modified my Python to read the OWFS "files" more often.
>
> I hope this is interesting enough to justify its length... I believe,
> and see on my scope, that OWFS only reads at 15-second intervals. But
> in the new logs I see changes that persist for less than two seconds.
> The occasional error readings also persist for less than two seconds:
>
If you don't read /uncached/, it's pretty clear owfs will only sample
temperatures each 15 seconds, because the volatile cache timeout is 15
seconds. Please check that first.
> 2015-10-08 15:39:23.995754
> d0 01 4b 46 7f ff 10 10 db : crc=db YES
> d0 01 4b 46 7f ff 10 10 db t=29000
> d8 01 4b 46 7f ff 08 10 6b : crc=6b YES
> d8 01 4b 46 7f ff 08 10 6b t=29500
>
> 2015-10-08 15:39:25.580574
> d0 01 4b 46 7f ff 10 10 db : crc=db YES
> d0 01 4b 46 7f ff 10 10 db t=29000
> ff ff ff ff ff ff ff ff ff : crc=c9 NO
> d8 01 4b 46 7f ff 08 10 6b t=-62
>
> 2015-10-08 15:39:27.170305
> cf 01 4b 46 7f ff 01 10 5d : crc=5d YES
> cf 01 4b 46 7f ff 01 10 5d t=28937
> d8 01 4b 46 7f ff 08 10 6b : crc=6b YES
> d8 01 4b 46 7f ff 08 10 6b t=29500
> ---
> The "-62" errors always look like that - one line of all "ff" with a bad CRC,
> followed by the correct bits with a bad temperature.
>
These are from linux/drivers/w1/slaves/w1_therm.c, around line 250.
These CRC errors aren't reported to owfs. The reading is just ignored
and the old value sticks in the chip structure the w1 driver manages. So
OWFS isn't aware there was an error at all.
For that "ff ff ff ff ff ff ff ff ff", I think that's a bug in the w1
kernel driver. It just waits 750ms of conversion phase, then immediately
samples the chip, ready or not.
Well, the DS18B20 datasheet says "max. 750ms", but I'm not so sure it
couldn't be 751ms sometimes. These 750ms are hardcoded in
linux/drivers/w1/slaves/w1_therm.c, line 198. If you want to change it
to 800 or so:
Install matching kernel sources.
$ cd linux-3.xxx
$ zcat /proc/config.gz >.config
$ make oldconfig && make prepare
Change linux/drivers/w1/slaves/w1_therm.c
$ make modules SUBDIRS=drivers/w1/
$ sudo make modules_install SUBDIRS=drivers/w1/
$ sudo rmmod w1_therm
$ sudo modprobe w1_term
> I'm further mystified... How can the files change so frequently
> in-between actual reads?
>
Because other parts of the systems are polling w1. The kernel's w1
subsystem is primarily made for controlling laptop battery packs which
often happen to have a DS2438 or BQ27000 or similar chip built-in.
You have to disable the temperature monitoring in your system to disable
that polling. Not recommended. I don't know how to except w1 or a
certain bus or chip from it yet.
You owfs config seems correct.
> I don't see any clues there... As for the startup command line, I
> have never understood how that works. Instead of any of the forms
> shown in the OWFS documentation, I type:
> --> As root:
> echo w1 >/sys/devices/bone_capemgr.9/slots
>
This is loading a "device overlay" into the board configuration supplied
to the kernel. It's pretty much a description how the hardware of the
board should be configured, which GPIO pins should be connected to which
internal module of the µC.
> And everything starts running...
>
That sure is because the owfs server programs are started from a script
which tries every few seconds to start them and usually that fails
because you have specified --w1 for owserver in the owfs.conf file.
As soon the w1 hardware is there, UDEV is loading the w1 kernel driver
and the next attempt to start owserver with --w1 succeeds. In the next
try, the start of owhttpd et al also succeeds because owserver is
finally there.
Kind regards
Jan
------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
