-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Jan,
I have some questions on your comments. The issue of the w1 drivers is new to me, and sounds like it may be an explanation of what I'm seeing, though I still don't understand why there should be a temperature dependence. I'm running Debian Linux on a Beaglebone Black. I've done nothing special for a kernel build, and I've built owfs using defaults, so the configure output indicates that W1 is enabled. My application starts at boot and runs as root with full permissions. The OWFS information on the W1 linux kernel module states there is a conflict between W1 and OWFS "without OWFS 1-wire support". Given the owfs default config supports W1 this seems to imply there should be no conflict. Is that correct? Also, if having W1 enabled in the configuration does not avoid conflicts there are two workarounds mentioned. The second is to run as root, which I'm doing. The first is to disable ds9490.ko using udev. I can find no information on how to do this. Checking dmesg I can find no instance of w1 (or W1) when the LinkUSB device is registered or at any other time. Is there anything you'd recommend I do to ensure no conflicts with W1 considering the above? I've never had any problem with power-on-reset issues such as you mention. Why would I need to assume that any device on the bus might reset without cause at any time? Thanks for the help. Paul Panish Jan Kandziora wrote: > Am 29.04.2015 um 18:35 schrieb Paul W Panish: >> Thanks for that, I'll implement the verification on write, I >> didn't realize that I could read from the output register without >> affecting state. This may be enough to get the levels of >> reliability I need. >> > Actually, the DS2408 PIO write command has the verification step > already built-in, see the datasheet, pp. 32-33. OWFS checks the 0xAA > byte the chip sends. You get an EINVAL if the verification fails. > > But that isn't enough as the chip may have been power-cycled at any > moment. > > So verifing the chip's state any few seconds or so is required. In > my host programs, I have a (minimal) state representation of each > chip and there's a function which checks the correct state of the > real device against this model from time to time and reapply it if > something failed. For some chips as the DS2408 it's easy as the have > a POR flag, for some chips (like the DS182x) you have to simulate a > POR flag by setting a custom mode which is reset to default on > power-cycle. > > You know you want that, right? Because it gets you rid of the > irritating 85°C reading - that's the power-cycle default of the > temperature register on the DS182x. > > > I cite myself again: > -------------------------------------------------------------------------- > > For other applications where 85°C may be a valid readout, I once posted > a way to tell the valid value away from the POR case: > > * don't do 12-Bit conversions. This is the default in EEPROM, so it > acts as our POR flag. > > a) do a 9, 10 or 11 bit conversion. b) check the value returned c) > !=85 -> valid reading, return temperature otherwise check further: d) > read scratchpad c) byte 4 != 0x7f -> no POR -> valid reading, return > temperature otherwise e) Power-On-Condition, need to repeat > conversion. > > > If you really *need* to do 12-Bit conversions, you'll have to change > the default configuration register value in the EEPROM. There is > currently no way to do this with owfs, bus we could change that. > -------------------------------------------------------------------------- > > > >> Note that the only element in the system that gets hot, or even >> warm for that matter, is the DS18B20. Heating of connectors isn't a >> problem. When I first discovered this issue I replaced all the >> wiring, connectors, and devices to make sure everything was well >> connected and working properly. The results were identical. >> > Hmm, that's where I'd switch the chip and see if the problem > magically disappears. > > >> The HobbyBoards I/O board is where I'm inserting power for the bus. >> It also grounds pins 1, 2, 5, and 8 on the RJ45. I could ground the >> rest, but it doesn't seem likely that this would cause a >> temperature sensitivity such as what I'm seeing even if it >> introduces some additional noise through capacitive coupling. >> > The problem when powering the components through the bus is ground > lift, that's worse than the additional noise. But if your only loads > powered through the bus are a couple of DS182x, it shouldn't be the > problem. > > > >> I'm not doing anything programmatically with owcapi that would scan >> the bus other than at initialization when I read the directory. >> However, I don't know what owfs is doing in the background. >> > Nothing, really. As far as you don't use the kernel's w1 interface. > That one system may scan automatically, depending on its settings. > > > AS A SIDE NOTE, you have DISABLED the kernel's w1 drivers if you > don't use them? If not, you'll get a conflict between the kernel > driver and OWFS accessing the host adaptor at the same time, leading > to exactly the scenario you've described (magically disappearing > chips). > > >> The BAE0911 sounds interesting, but seems to be severe overkill for >> the purpose, especially if I want to commercialize any of this. >> > Well, I use the BAE0911 commercially. Pascal has moderate prices, > ask him - he needs these commercial projects. And you don't have to > use all the functions of the BAE, it "just works". > > Would be a pity if we had such a good onewire homebrew slave chip > and everybody is still playing around the limitations of the crappy > DS2408 et al. > > >> It also doesn't seem to be available from distributors as a chip or >> board in the US, and I can't find anything on the RailBox Board >> availability anywhere. The only reference is the Brain4home.eu site >> which appears to be down. >> > Pascal is reading on this list. Or just ask him directly: > pascal.baer...@gmail.com > > > Kind regards > > Jan > > ------------------------------------------------------------------------------ > > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable > Insights Deep dive visibility with transaction tracing using APM > Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ Owfs-developers > mailing list Owfs-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/owfs-developers -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVQh/nAAoJEG+gBufEaU3Y/5cH/1IfdFVNiJoIqzEbpcQ/3j5x CT0DMUDmTmXrX5KYoMXsMxgSw+e1oIFyajkIEmzNk3HP4uROANt4kl0mL5YxFw4V BDvQWIHeOoqLhBhe13zC/+G53mqRgfJJrGxCOTaV0c4Dr4K65tOLBveYRr2VzpXB KIsAJqnneyPsTWmjf3nmCSdhWcxGjC76QTGujRqRasyzlfcZ42Ncq4JdWqAGjuxR 8dgSNrNYxsdT386PPeGROMbMQD0FLWfdv+GF4osvBIlPgBk5KTde+g8LPRw+ttzd EYkZU0uBoyoPCwfAwDYDwvjnbEgrFde6A35O4tw2kQPQ2VZg85TKZ4oKSAjyQ/U= =pMSw -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
