Date: Fri, 29 Apr 2016 22:14:03 +0200
From: Jan Kandziora [email protected]
...
schrieb John Bass:
...
>> So Passive mode, /sys/bus/w1/DEVICE/temperature returns correct
>> temperature, however owserver with owread return 85c, thus I would
>> surmise that owserver is not handing passive devices correctly.
> When you read from the sysfs node, the w1 temp class driver activates the
> strong pullup, overriding your "too weak" pullup. This is done
> automagically within microseconds. However, that function isn't exposed in
> the w1 kernel<->userspace interface.
That is the w1 function broken in my Ubuntu 14.04 distro install of 2.8p15
owfs. No matter how the configuration is set the strong pullup does not get
enabled by w1. (I can enable the pullup for that GPIO manually with sysfs for
testing and it is fully functional there.)
> Instead, usespace programs like owserver have to use another transaction
> for activating the strong pullup. Depending on process scheduling, this
> may be delayed a few milliseconds, and in the meantime, your DS18B20 runs
> low on power and power-cycles, which gives you the 85?C reading.
> So, the solution is to choose a "weak pullup" of 1k instead of 4.7k.
> That way the DS18B20 never runs out of power.
> Am 30.04.2016 um 10:35 schrieb John Bass:
>> OK, just had a read around the good old internet, and found other
>> people with the same issue, down to power yet again..
>>
>> So popped another 1k in parallel thus 500ohms and now it works :-),
>> but not reliable :-( getting the odd 85
>>
>> There is the issue is 500ohms too low for the bus etc...??
I found that for some DS18B20 chips, even 1K is not low enough. As reported in
my past posts here, their temperature readings gradually get higher as the
pullup gets larger, from maybe 0.5C to 8C high at 4.7K. With a sub-1K pullup
calculated to just avoid exceeding the chip specs, one of my test sensors is
pretty close to accurate, the other always at least 0.5C high - by both routes:
ubuntu@arm:~/Lpkg$ cat /sys/devices/w1_bus_master1/28-0000008847d6/w1_slave
59 01 4b 46 7f ff 07 10 a2 : crc=a2 YES
59 01 4b 46 7f ff 07 10 a2 t=21562
ubuntu@arm:~/Lpkg$ cat /sys/devices/w1_bus_master1/28-000000884d88/w1_slave
51 01 4b 46 7f ff 0f 10 fe : crc=fe YES
51 01 4b 46 7f ff 0f 10 fe t=21062
ubuntu@arm:~/Lpkg$ python /home/ubuntu/Lpkg/OWFStsvPyownetUncachedBoth.py
/28.884D88000000/
/28.D64788000000/
2016-04-30 11:58:04.490529 21 21.625
2016-04-30 11:58:06.640850 21.0625 21.625
2016-04-30 11:58:08.832395 21.0625 21.625
2016-04-30 11:58:11.058841 21.0625 21.625
(One second per read shows it really is reading uncached...)
from pyownet.protocol import OwnetProxy
proxy = OwnetProxy()
...
temp[0] = proxy.read('/uncached/28.884d88000000/temperature')
temp[1] = proxy.read('/uncached/28.D64788000000/temperature')
Two more DS18B20 sensors physically bundled with the previous two, but read by
a 5V system with active pull-up/down:
Test_One = 69.69 = 20.938 Test_Two = 69.91 = 21.061
So a question for Jan:
If owserver uses "another transaction for activating the strong pullup", I
guess it must fail just like the w1 activation of the pullup fails in my 2.8p15
Ubuntu distro version. Does it work by telling w1 to set the pullup? Which in
my old version it can't seem to do? Or does it try to bypass w1 somehow?
And back to John's issue, I suspect this works differently in the 3.1.p1
version, both on the w1 side and on the owfs side. But do you get exactly the
same readings from both, or are some chips slightly higher by one route? If you
still absolutely need a sub-1K pullup, somebody must not be enabling the GPIO
strong pullup properly.
And... I just noticed my test readings aren't quite the same! How can it be
that w1 shows "59 01 4b 46 7f ff 07 10 a2 t=21562" when the ownet proxy returns
"21.625"? And where does the proxy get "21.0625" if the raw data returned by w1
is just "21062"? Curious...
| Loren Amelang | [email protected] |
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Owfs-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
