On Sat, 3 Oct 2015 01:15:10 +0200, Jan Kandziora <j...@gmx.de> wrote: --- If the sensor tells it has a different temperature, it actually has a different temperature. These are calibrated devices so their readout can be trusted.
However, your outer setup may actually heat up the sensor. Without knowing the actual circuit and mechanical setup, it's hard to tell what may be the culprit. ... A question: are these temperature values *single* readouts, or are they averaged over a greater number of readouts? If the latter, I would first check if the 85?C power-on-reset readout is properly sorted out before averaging. Because if you have some small mistake in your circuit, it may still work most of the time but power-on-reset may be a little more likely at 3.3V than at 5V. --- Jan, Thank you so much for the best explanation I've seen of the pull-up issue! My circuit is extremely simple - two sensors, ground, buss connected to BBB I/O pin, and resistor to 3.3V. I just clipped in another parallel resistor to make the total 1K, and my readings instantly changed to reasonable values! Meaning they dropped suddenly and conclusively by 3 and 9 degrees F, as shown in the logs below. If internal heating was a problem, I'd expect more current to raise the readings. I have four DS18B20 test sensors (with heatshrink over the chips and cable ends) rubber-banded together and slipped under an insulating mat against the interior floor near an interior wall. I'd expect them to see the same temperature. Two are on the 3.3V BBB, two are on a 5V buss with active pull-up/down. My fancy thermocouple thermometer reads 26.3 C in that spot. One 3.3V and one 5V 18B20 now read 26.375 C. The other 3.3V sensor reads 26.9375 C, and the other 5V sensor reads 26.1 C. Still a bit more variation on 3.3V than I'm used to seeing on 5V, but much better. I was watching OWHTTPD (http://10.1.1.4:2121/) which shows OWSERVER in the top line (OWFS on localhost:4304) for those direct human readings. The logged readings are from Python reading the OWFS: Sensor1="/sys/bus/w1/devices/28-000000884d88/w1_slave" Sensor2="/sys/bus/w1/devices/28-0000008847d6/w1_slave" They are in Fahrenheit: 2015-10-04 12:24:51.308490 78.35 85.55 <-- the day is warming up 2015-10-04 12:29:51.404838 78.8 86.0 2015-10-04 12:34:51.498028 79.25 86.5616 2015-10-04 12:39:51.574288 79.5866 86.9 2015-10-04 12:44:51.650472 76.775 77.7866 <-- new resistor added 2015-10-04 12:49:51.732814 80.375 81.275 <-- I was messing with the sensors, 2015-10-04 12:54:51.808572 79.1366 80.15 probably warming them with my hands 2015-10-04 12:59:51.869041 79.3616 80.4866 Later, stable readings: 2015-10-04 14:29:53.276277 83.75 84.65 2015-10-04 14:34:53.351849 83.975 84.875 2015-10-04 14:39:53.353841 84.2 85.1 2015-10-04 14:44:53.429619 84.2 85.325 2015-10-04 14:49:53.482740 84.425 85.55 In the past, I've verified the logged temperature matches the reported 1-Wire bits. Unless there is some complexity in the OWFS code I'm not able to imagine, I really don't believe any 85C error values could be getting averaged in. If they were, they would have to be absolutely consistent and regular, because my offset temperatures tracked each other and reality smoothly. I tried the "uncached" options in OWHTTPD/OWSERVER, and saw the same results. I noticed in "28.D64788000000/errata": --- up directory die C2 trim 48077 <-- trimblanket trimvalid NO (0) <-- but uncached or reload showed YES... --- While in "28.884D88000000/errata": --- up directory die C2 trim 48117 <-- trimblanket trimvalid YES (1) --- I have no idea what that means. It offers to let me change the trim, so it must be an OWFS parameter rather than something read from the chip. If it is applied to the temperature reading, maybe that explains my remaining difference? Except the 48077 factor reads higher than the 48117 factor... Statistics -> Errors shows: NET_connection_errors 1 But bus.0 -> Statistics -> Errors shows: CRC8_errors 11 CRC8_tries 409 The bus.0 page also shows both sensors, so I assume it is the active buss. While I've been writing this, "tries" has gone from 409 to 427. The system has been up since Feb 2015, so maybe those numbers are not all-time cumulative? Maybe just since the HTTPD was connected? But in any case, they are not evenly spaced in time - that jump happened all at once, and 427 has remained since. (Later it is 449.) If error values were being averaged in, would they show in the Statistics? I guess the other option is that some internal part of a DS18B20 is actually analog, and influenced by marginal bus power. Loren | Loren Amelang | lo...@pacific.net | ------------------------------------------------------------------------------ _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
