Re: Raspberry Pi Jessie owfs-3.1.p1 w1-driver = 85c (119:11)

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Raspberry Pi Jessie owfs-3.1.p1 w1-driver = 85c (119:11)

Loren Amelang
Date: Fri, 29 Apr 2016 22:14:03 +0200
From: Jan Kandziora [hidden email]
...
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 | [hidden email] |




------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Raspberry Pi Jessie owfs-3.1.p1 w1-driver = 85c (119:11)

Jan Kandziora
Am 01.05.2016 um 22:12 schrieb Loren Amelang:
>
> 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?
>
It's set using the w1 subsystem.

Kind regards

        Jan

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Raspberry Pi Jessie owfs-3.1.p1 w1-driver = 85c (119:11)

Stefano Miccoli
In reply to this post by Loren Amelang

On 01 May 2016, at 22:12, Loren Amelang <[hidden email]> wrote:

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...  

All the magic happens inside owserver, not pyownet…

The DS18B20 temperature register format is 12 bit, so “59 01 …” or “LSB MSB” is converted (by owserver) as 0x159 / 2**4 or 21.5625 

Notice that the least significant bit of the register is 2**-4 or 0.0625 °C which means that the w1 kernel readout (10**-3 °C) has not enough resolution to represent exactly the binary raw data. (But who cares about half a mK difference?)

As a side note:

if you upgrade to pyownet v0.9.0 or greater (latest version is v0.10.0) instantiating directly the OwnetProxy class is deprecated, use instead the factory function 

Your example should be 

import pyownet.protocol
proxy = pyownet.protocol.proxy()
...
       temp[0] = proxy.read('/uncached/28.884d88000000/temperature')
       temp[1] = proxy.read('/uncached/28.D64788000000/temperature')
 

or 

from pyownet.protocol import proxy as proxyfactory
proxy = proxyfactory()

or
… whatever you like better.


The reason for dropping the OwnetProxy class is that in recent versions persistent connections are supported (i.e. a single socket for more than one transaction) so that now there are two different types of proxy objects: persistent and non persistent ones, see 

Bye

S.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers