Re: [Owfs-developers] Odd 85 deg temperature readings again
Eric Vickery wrote: I disagree. 85 is a valid reading since the chip can read from -10 to You disagree with what...? If with It's inconsequential in the scheme of things. I meant to say in the scheme of things in my software. It *may not* be inconsequential for engineers who are trying to work with the device. This last statement is yet to be shown true, IMHO. +125 and nowhere in the spec document does it state that 85 cannot be a valid reading. It just states that 85 is the power-on reset value. My guess is that discerning the POR value is done by comparing the returned value out to a certain precision. (In my code I just check for 85.0 which paints a broader bruch). For example 85.000 may well indicate POR whereas 85.125 would not, of course. I haven't worked it out. This point may be worth a little math. Where is Dan Awtrey when you need him? :) I think it would have been better for Dallas to have the power-on value something on the extreme high or low end to make it easier to tell when an error occurred. I agree, but my guess is that that they chose this value because it's at the end of the chip's normally-designed range of -10 +85C. At this range the chip is good to 0.5 degrees C. Outside of this range the chip is good to +/- 2.0 degrees C which may be useful to only a few. /m - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Odd 85 deg temperature readings again
Perhaps there are some hints here. You are using external power (non-parasytic) and a DS18S20? The code is supposed to lock the device (use a mutex to exclude other threads from that chip) issue a CONVERT command, wait 1sec, then read results. If it's functioning correctly, the only reason that 2 threads should create a problem would be the increased frequency of temperature conversions. Perhaps there is a rest time needed? Can you run a type loop on a single thread reading one chip and see if you get an error? The other thought is that multiple simultaneous reads causes sags in the power line that occasionally interfere with readings. In that case 2 threads, each in a tight loop, each reading a different temperature sensor would show an error. Paul Alfille On 12/5/06, Darryl [EMAIL PROTECTED] wrote: Not sure what's going on behind the scenes BUT the error only occurs when I have two separate scripts trying to read the devices BOTH through owserver. -darryl -- http://randomthoughts.vandorp.ca - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Odd 85 deg temperature readings again
Yes, the die trim values and all that are exposed in OWFS. Paul Alfille On 12/6/06, Mark Richards [EMAIL PROTECTED] wrote: Here. David Lissuk who maintains 1wire.org has published a list of chips identified to have the POR problem. Check over there for more details. I've snatched it from his page below: 06/02/04 - All DS18X20's B7 die chips identified List of Chips with the B7 Die 1. Read the 18X20's ROM code. Look at only the serial number portion of the ROM code: 0xCC0SSSFF where CC is the CRC 0 is the customer code SSS is the serial number FF is the family code DS1822 Starting ROM code of rev B7 4A0008978A22 Ending ROM code of rev B7 3B000CB81922 Starting ROM code of rev C2 62000CB81A22 DS18S20 Starting ROM code of rev B7 E800591D2010 Ending ROM code of rev B7 AB00080080885F10 Starting ROM code of rev C26200080080886010 DS18B20 Starting ROM code of rev B7 060054501028 Ending ROM code of rev B7 5E00662B4F28 Starting ROM code of rev C22100662B5028 - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Hobby Boards questions
Am Mittwoch, 6. Dezember 2006 01:14 schrieb Paul Alfille: Currently, the only aggregate we support is the TAI-8570 barometer, which uses 2 DS2406. In that case, the DS2406 memory is used to point to the partner chip, so the aggregate can be autodiscovered. There is certainly an appeal to autodiscovery. The barrier to entry and use is much lower. As Eric pointed out, there aren't so many chips with EPROM or EEPROM on board, and I don't like the idea to incorporate such a chip into any design I do. They are fairly expensive (e.g. DS2406 costs €1.92+VAT per chip if you take 500pcs), and this price has to be payed by the end user. (That is why humidity is present for the DS2438, even though not all chips are part of such a device). Same with LCD_x for the DS2408. The database of aggregates needs 1. unique ID 2. vendor/type 3. component IDs (Perhaps in some specific order) 4. Optional parameters/calibration constants There is some appeal to having the database accessible/modifiable/savable within OWFS, though that is a design decision that can go either way. If we use e.g. an sqlite database, we won't need the ability to modify the database in the owlib code. There are many tools out there which could handle sqlite databases. Plus, it's an SQL database engine with many language bindings, so helper programs could be scripted easily. The database engine is a small-footprint one, so it could be incorporated even in NSLU2 type devices. If Eric favours this approach for the hobby-boards, too, we have at least two vendors which will support a global aggregate database, so the inconvenience for the user could be quite low. We also need a policy on whether components can be seen/addressed/changed outside of the aggregate. Having both would be straightforward, but I think there will be additional problems with aggregate states if the chips could be addressed outside the aggregate. I would put a note like If you mix both modes, results may be undefined and leave it to the user. And there has to be some indicator whether the aggregate is detected as a whole or some chips are missing. For the multi-level design of OWFS (owfs - owserver for example) it becomes a little more complex as to which process needs to know about the aggregate. The level with the actual physical adapter might make the most sense. As a final goal, aggregate routines may offer timing or simple if-then decisions within the same aggregate, or even different aggregates. That would help much in simplifing the software on top of owfs. I favour a plugin concept for such aggregate routines, so the aggregate logic could be separated from the owlib core. Kind regards Jan -- We are Pentium of Borg. Division is futile. You will be approximated. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Odd 85 deg temperature readings again
On 12/6/06, Paul Alfille [EMAIL PROTECTED] wrote: Perhaps there are some hints here. You are using external power (non-parasytic) and a DS18S20? No, some of the DS18S20's are parasitic some are not. Only 2 are throwing the error. If I remember correctly one is parasitic and one isn't The code is supposed to lock the device (use a mutex to exclude other threads from that chip) issue a CONVERT command, wait 1sec, then read results. If it's functioning correctly, the only reason that 2 threads should create a problem would be the increased frequency of temperature conversions. Perhaps there is a rest time needed? Can you run a type loop on a single thread reading one chip and see if you get an error? Tight loop? The way I was doing my test was reading 4 sensors in a tight loop and then starting another process to read the same sensors. I'll modify the script to just hammer one of the sensors that throws the error. The other thought is that multiple simultaneous reads causes sags in the power line that occasionally interfere with readings. In that case 2 threads, each in a tight loop, each reading a different temperature sensor would show an error. Paul Alfille -darryl -- http://randomthoughts.vandorp.ca - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Odd 85 deg temperature readings again
Curiouser and curiouser. So your tests are A -- single loop against DS18S20 sensor A A+A -- two processes against sensor A AB -- single loop against sensors A and B AB+AB -- two processes each AB style Only AB+AB fails? And the failure is after a number of readings? Are A and B different? One parasytic and the other powered? If so, is B and B+B also ok? And A+B? I also assume that Vdd on the parasytic is properly grounded. And these are uncached readings. This is sorta fun -- a little logic game. Credit to the person who first figures it out! Paul Alfille On 12/6/06, Darryl [EMAIL PROTECTED] wrote: The way I was doing my test was reading 4 sensors in a tight loop and then starting another process to read the same sensors. I'll modify the script to just hammer one of the sensors that throws the error. Ok. in owpython i just did: while 1: temp = mySensor.temperature print temp if float(temp) == 85.0 sys.exit(1) And the loop would run indefinitely without any error values. I started another process and ran two copies of the script with no error values. I expanded the loop to read two sensors. It also would run indefinitely without error values. Finally I ran two copies of the script reading two sensors and that's when the error starts occurring. Hope that narrows something... -darryl -- http://randomthoughts.vandorp.ca - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
[Owfs-developers] I can't build with alternate python 2.4.3
I just did a csv co, bootstrap, and now I run configure with ./configure --disable-owphp --disable-owperl --with-python=/usr/local/bin/python2.4 But python doesn't get enabled. I know I've mentioned this problem on the list a while back, and finally resorted to hacking configure. But, has anyone looked at why this doesn't work yet? Current configuration: Deployment location: /opt/owfs Compile-time options: Caching is enabled USB is enabled I2C is enabled HA7Net is enabled Multithreading is enabled Parallel port DS1410E is enabled TAI8570 barometer is enabled Thermocouple is enabled Zeroconf/Bonjour is enabled Debug-output is enabled Profiling is DISABLED Module configuration: owfs is DISABLED owhttpd is enabled owftpd is enabled owserver is enabled owcapi is enabled swig is enabled owperl is DISABLED owphp is DISABLED owpython is DISABLED owtcl is enabled I have an x86-64 machine. Python is compiled as a 64 bit executable. from config.log configure:22161: checking if owpython is enabled configure:22194: result: yes (default) configure:2: result: Looking for location of Python executable configure:22298: checking for Python prefix configure:22301: result: /usr/local configure:22303: checking for Python exec-prefix configure:22306: result: /usr/local configure:22313: checking for Python version configure:22319: result: python2.4 configure:22324: checking for Python lib dir configure:22331: result: lib64 configure:22336: checking for Python header files configure:22346: result: -I/usr/local/include/python2.4 -I/usr/local/lib64/python2.4/config configure:22350: checking for Python library configure:22360: result: Not found configure:22398: WARNING: Cannot find python library. Install python-devel package. configure:22400: WARNING: OWPYTHON is disabled because python library is not found The actual location for PYLIB is /usr/local/lib/python2.4/config/libpython2.4.a On my system /usr/local/lib64 is empty and Python 2.4.3 (#1, Aug 22 2006, 17:41:07) [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2 Type help, copyright, credits or license for more information. import sys sys.lib Traceback (most recent call last): File stdin, line 1, in ? AttributeError: 'module' object has no attribute 'lib' I try setting PYLIB directly on the command line, but that doesn't work UNLESS I comment out this line in configure line 22230. PYLIB= It seems to me (other than upgrading to python 2.5) that there should be a way to set the PYLIB path explicitly on the configure command line, and then only do all the lib checking if the user hasn't specified it. however my configure-foo is low.. so I resort to commenting out the above line. -- Brad Clements,[EMAIL PROTECTED](315)268-1000 http://www.murkworks.com AOL-IM or SKYPE: BKClements - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
