On Tuesday, October 06, 2015 at 5:05 AM, Jan Kandziora j...@gmx.de wrote: >> My errata display showed the same Trim value the time it said >> "invalid" as it did all the times it said "valid". >> > That may be because the errata/trimvalid node does its own chip read > without updating the cache value of the errata/trim node. I've suspected each item in the lists is read independently. I often see lower resolution temperatures that don't quite match the 12-bit value currently showing on the web page.
> If you do bitbanging, it is sufficient to unload the w1-gpio driver to > have the bus unpowered. Part of its cleanup routine is to float the GPIO > pin. I don't think there is another reason but an (unlikely) bug inside > w1-gpio to have the bus unpowered. Lost me there. If my 1K pullup is constantly present, and the GPIO pin is floating, seems the bus is powered. >> When I added the resistor to make >> 1K, I just clipped it onto the existing resistor with the system >> "live" and operating. >> > Hmm, there shouldn't change the behaviour then. That's where I'm mystified! >> Does OWFS issue POR commands while it is >> running? >> > This "POR command" 0x64 David mentioned in his post is actually the > "apply trim 2" command. It is only sent when writing something to the > errata/trim node I went back and read the data sheet... DS18B20 Programmable Resolution 1-Wire® Digital Thermometer (Marked "043001", no date.) --- If the bus is held low for more than 480 µs, all components on the bus will be reset. Reset Time High tRSTH 480 µs 1 Reset Time Low tRSTL 480 µs 1,2 NOTES: 1. Refer to timing diagrams in Figure 18. 2. Under parasite power, if tRSTL > 960 µs, a power on reset may occur. <-- Aha!!!!!! --- Reset Time High tRSTH follows the Reset Time Low tRSTL pulse; it is reserved for the presence pulses from the responding chips. My scope shows ~12 mS of interaction, followed by the 480 uS reset, then ~4 mS of bus high, then another ~16 mS of interaction, then the 15 second pause with bus high; no other 480 uS resets. But randomly, maybe once in 5 minutes, totally unrelated to this pattern, I see a separate ~4 mS low pulse with no associated interaction. Sometimes it looks like two of them almost together, but separate scope triggers so at least 50 mS apart. So that random hit seems to qualify as a power-on reset. As best I can see on my old analog scope, it has clean sharp edges, like the GPIO is doing it intentionally. Hard to tell if it correlates with my 0C or 85C readings. But since OWFS seems to be counting on the information setup from 15 seconds ago remaining valid during the pause, that would certainly mess things up. But still... The 0C and 85C readings show up as exact discrete values in my temperature logs, and do not seem to affect any other readings. I checked the logs taken during my scope tests, and while the resistor was un-clipped, the recorded temperatures jumped back up to their old offsets. Jumped exactly back down with the resistor restored. Totally mystifying! Clipping and unclipping the added "make 1K" resistor changes the rise time of response pulses from almost 5 uS to under 2 uS. No change in the overall pattern. Current versions: ubuntu@arm:~$ dpkg --list | grep owfs ii owfs 2.8p15-1ubuntu4 all Dallas 1-wire support ii owfs-common 2.8p15-1ubuntu4 all common files used by any of the OWFS programs ii owfs-doc 2.8p15-1ubuntu4 all Dallas 1-wire support: Documentation for owfs ii owfs-fuse 2.8p15-1ubuntu4 armhf 1-Wire filesystem >From my old notes, in Ubuntu 12.04 (looks like ow-2.8-13), each 15 sec. read >"on scope takes just over 20 mS, pause 0.5 - 4 mS; pulses 5 or 25 uS". Sounds like the initial 12 mS interaction period before the 480 uS reset that I'm seeing now is new... > Honestly, power the sensors (with 3.3V) and see if you get rid of the > 85?C bug. I'd have to go dig, but I don't believe I have any loose 18B20 sensors that aren't already wired up and sealed as parasitic. And it wouldn't solve my real problem anyway - this BBB and OWFS project needs eventually to work with all my currently installed sensors and cabling. They are all parasitic, and it would be a huge task to replace them. If I'm going to try something, it would be to change to a USB bus connection, which would probably be required to drive my dozen sensors and hundreds of feet of cable anyway. This 3.3V w1 test was just to learn about OWFS. Any thoughts on which USB master would be best for parasitic sensors scattered all over my solar hot water equipment, in-between motors and electric valves and PV panels? Appreciate your help thinking through this! Loren ------------------------------------------------------------------------------ Full-scale, agent-less Infrastructure Monitoring from a single dashboard Integrate with 40+ ManageEngine ITSM Solutions for complete visibility Physical-Virtual-Cloud Infrastructure monitoring from one console Real user monitoring with APM Insights and performance trend reports Learn More http://pubads.g.doubleclick.net/gampad/clk?id=247754911&iu=/4140 _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
