Paul,
> As I understand, you are using the w1 interface and Beaglebone Black, but
> I'm not sure what the bus-master is. A gpio pin?
I pretty much followed these:
<https://groups.google.com/forum/#!topic/beagleboard/YPgbKxd2mRU>
<https://groups.google.com/forum/#!topic/beagleboard/LF8Vd8i3MpM>
<https://groups.google.com/forum/#!msg/beagleboard/zQ039ckqp3E/xKs_mp-GQtMJ>
Except I ended up with a 10K resistor in parallel with the suggested 4.7K
pullup, for 3197 ohms, before I actually got real readings.
The hardware connection for 1-Wire:
--> 8_11 is GPIO1_13 on schematic
--> "name": "GPIO1_13",
--> "gpio": 45,
"mux": "gpmc_ad13",
"eeprom": 29,
--> "key": "P8_11",
P8-11 is on the heartbeat LED side connector, sixth pin from the ethernet end:
[ ] <-- ethernet connector
1 2
3 4
5 6
7 8
9 10
11 12
... ...
> -62 is not familiar to me. How often does it happen, and does the system
> continue to work with occasional glitches or does it need reset? Note that
> w1 errors might be reported by the system (dmesg).
Looks like roughly once a day, and it goes right back to working. The owfs file
gets read every five minutes by a chron injector in Node-RED.
Here are the recent events from my Node-RED output file:
(I tried to work backwards from "uptime" to the dmesg events below to get the
logged times - somehow I ended up a stable 58 minutes off, but it does look
like the dmesg events match the output file...)
---
Thu Jul 03 2014 22:20:02 GMT-0700 (PDT)
ff ff ff ff ff ff ff ff ff : crc=c9 NO
cd 01 4b 46 7f ff 03 10 4a t=-62
Fri Jul 04 2014 14:00:02 GMT-0700 (PDT)
ff ff ff ff ff ff ff ff ff : crc=c9 NO
c8 01 4b 46 7f ff 08 10 3f t=-62
Sat Jul 05 2014 17:35:02 GMT-0700 (PDT)
ff ff ff ff ff ff ff ff ff : crc=c9 NO
fd 01 4b 46 7f ff 03 10 b6 t=-62
Sat Jul 05 2014 20:25:02 GMT-0700 (PDT) = 7/5/2014 19:27:34 PM
ff ff ff ff ff ff ff ff ff : crc=c9 NO
ef 01 4b 46 7f ff 01 10 f5 t=-62
Mon Jul 07 2014 08:15:02 GMT-0700 (PDT)
ff ff ff ff ff ff ff ff ff : crc=c9 NO
86 01 4b 46 7f ff 0a 10 5e t=-62
Mon Jul 07 2014 13:45:02 GMT-0700 (PDT)
50 05 4b 46 7f ff 0c 10 1c : crc=1c YES
50 05 4b 46 7f ff 0c 10 1c t=85000 <-- the only 85C report in this time
period
Mon Jul 07 2014 21:30:02 GMT-0700 (PDT)
ff ff ff ff ff ff ff ff ff : crc=c9 NO
ec 01 4b 46 7f ff 04 10 cf t=-62
Tue Jul 08 2014 12:55:01 GMT-0700 (PDT)
ff ff ff ff ff ff ff ff ff : crc=c9 NO
bb 01 4b 46 7f ff 05 10 c6 t=-62
Wed Jul 09 2014 04:30:01 GMT-0700 (PDT) = 7/9/2014 3:32:45 AM
ff ff ff ff ff ff ff ff ff : crc=c9 NO
83 01 4b 46 7f ff 0d 10 66 t=-62
-----
$ dmesg |grep "w1"
[ 185.216244] bone-capemgr bone_capemgr.9: part_number 'w1', version 'N/A'
[ 185.216352] bone-capemgr bone_capemgr.9: slot #7: 'Override Board
Name,00A0,Override Manuf,w1'
[ 185.217476] bone-capemgr bone_capemgr.9: slot #7: Requesting part
number/version based 'w1-00A0.dtbo
[ 185.217498] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware
'w1-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
[ 185.219060] bone-capemgr bone_capemgr.9: slot #7: dtbo 'w1-00A0.dtbo'
loaded; converting to live tree
[ 9323.285544] w1_slave_driver 28-000000884d88: 18S20 doesn't respond to
CONVERT_TEMP. = 7/5/2014 19:27:34 PM
[138328.444927] w1_slave_driver 28-000000884d88: 18S20 doesn't respond to
CONVERT_TEMP.
[155728.922350] w1_slave_driver 28-000000884d88: 18S20 doesn't respond to
CONVERT_TEMP.
[186030.560605] w1_slave_driver 28-000000884d88: 18S20 doesn't respond to
CONVERT_TEMP.
[241532.000358] w1_slave_driver 28-000000884d88: 18S20 doesn't respond to
CONVERT_TEMP.
[297634.120407] w1_slave_driver 28-000000884d88: 18S20 doesn't respond to
CONVERT_TEMP. = 7/9/2014 3:32:45 AM
As I said above, I tried to convert these to logged times, and they do seem to
match, if I include the one 85C event among them.
Interesting that there is a second DS18B20 in parallel, and it shows no dmesg
events. It is not being automatically polled or logged by Node-RED, but it
works if I manually query it so it must be actively read by owfs. The two
matched exactly when read by a different 5V bus system, but on the BBB the
second one reads 3C to 5C higher. Have not figured that out yet... And the
first one actually reads 2C higher than it should, so the second one is 5C to
7C high! I'm hoping a proper 5V USB interface will fix this...
Obviously the -62 errors are not a big problem for my actual project, but I'm
just really curious how they happen. I've never seen them in any other 1-wire
system.
> I have a BBB and can try to see if I get the same errors if you describe
> your setup a little more.
More details available if needed...
Loren
> On Sat, Jul 5, 2014 at 8:32 PM, Loren Amelang <lo...@pacific.net> wrote:
>
>> My problem with 12-bit reads degenerating to half-degree steps seems to
>> be hiding since I built a new system with Ubuntu 14.04. I've only seen a
>> few individual readings that looked "stuck" at the previous value since
>> then, never full days of half-degree steps.
>>
>> But I still get two kinds of rare, occasional errors. There are the
>> expected 85C errors, and these:
>> ---
>> Thu Jul 03 2014 22:15:01 GMT-0700 (PDT)
>> cd 01 4b 46 7f ff 03 10 4a : crc=4a YES
>> cd 01 4b 46 7f ff 03 10 4a t=28812
>> Thu Jul 03 2014 22:20:02 GMT-0700 (PDT)
>> ff ff ff ff ff ff ff ff ff : crc=c9 NO
>> cd 01 4b 46 7f ff 03 10 4a t=-62
| Loren Amelang | lo...@pacific.net |
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
