One thing I am doing is dropping a low going pulse onto another GPIO pin in my
slave implementations, and hooking that up to the logic analyser as well as the
1wire line. That way, I can tell if a pulse originated from my slave
implementation, or elsewhere on the bus.
From: Sven Giermann [mailto:sven.gierm...@gmail.com]
Sent: Friday, 24 February 2017 8:21 PM
To: OWFS (One-wire file system) discussion and help
<owfs-developers@lists.sourceforge.net>
Subject: Re: [Owfs-developers] Fine-tune timing against disappearing slaves
Just to report back my results:
I still have no idea, why it was a difference between ARMEL and i386.
But none of my efforts showed any advantage... I ended up with a plain bus,
even dropped the Cat.5 part completely and was unable to communicate with my
client nodes.
And then I realized, that I used different implementions of the mentioned
OneWireHub library!
I switched back to an older release and my clients were visible everywhere,
even with the worst star topology I could imagine.
So, sorry guys for confusion.
I'll now try to find the source of the problem of the client implementation,
even if it might be complicated without a proper oscilloscope and/or
bidirectional analysis to see, which device pulls the bus low...
Cheers,
Sven
2017-02-16 7:46 GMT+01:00 Sven Giermann <sven.gierm...@gmail.com
<mailto:sven.gierm...@gmail.com> >:
Jan, thanks for the detailed explanation!
My main problem was/is, that even when I disconnect 2 branches and only have
branch "B" or "C", it won't make a difference. But there's another change, I
did not remember:
Colin, I use OneWireHub: https://github.com/orgua/OneWireHub
The difference is, that the first 2 (still functioning) slaves use an older
code base. OneWireHub changed it's timing in some November commits. I guess, I
uses an intermediate version for the 2 slaves that worked first and do not any
more.
I'll do some tests and compare the timing with a logic analyzer to see, if they
behave different. The only obvious change I found is the length of a written
zero. But this decreased from 35µs to 30µs, which still might be too long:
https://github.com/orgua/OneWireHub/blob/e2c5b4447338e48debae33b66ec7427265b5af23/src/OneWireHub.h#L78
https://github.com/orgua/OneWireHub/blob/master/src/OneWireHub_config.h#L39
(I guess it should be even shorter, so it makes no sense that the old ones are
working)
But apart from this implementation, I was not able to talk to a DS1820 at the
end of branch "C", so I'll follow Jans advise and build a lobe with the Cat.5 -
I always tried to keep the length short, but this indeed might make more sense!
And, Jan: yes, I use DS9490 on both machines. I even exchanged those, using the
"working" one on my ARMEL box and the "not working" on i386, but it didn't
change: i386 worked, the other didn't.
On this point thanks again for the detailed explanation, how to install OWFS
3.1p5!
Even if I'm not on a Raspberry and currently use emDebian, I'll try and install
the armel binary from the official repositorys!
I'll report back with my results...
Sven
2017-02-15 17:48 GMT+01:00 Colin Reese <colin.re...@gmail.com
<mailto:colin.re...@gmail.com> >:
Sven, what code are you using on your attiny?
> On Feb 15, 2017, at 7:27 AM, Jan Kandziora <j...@gmx.de <mailto:j...@gmx.de>
> > wrote:
>
>> Am 15.02.2017 um 08:25 schrieb Sven Giermann:
>>
>> I have several temperature sensors and 1 DS2423 counter in one room. All
>> are connected with a Cat.5 network cable (about 30 meters) in a single bus
>> that ends in another room with a small embedded Debian ARM (armel) server
>> that runs OWFS 2.8p15-1.
>>
> Please update to 3.1p5. No one wants to hunt bugs fixed for years.
>
>
>> Everything fine up to here. Let's call this branch "A".
>>
>> I then started to connect some software programmed ATTiny85 custom 1-wire
>> slaves, drawing another branch (branch "B") from my server. That way, the
>> first star-alike topology was built, currently a single bus, but with the
>> master in the middle.
>> This also worked for the first 2 devices, about 7 meters distance to the
>> master (remember the additional 30 m to the other sensors). I used simple
>> electric cable (NYM-J 3x1.5mm²) for this second branch, because I needed
>> the third wire for some higher currents.
>>
> I would suspect the ATtiny slaves are a more picky about the timing then
> the Dallas/Maxim ones.
>
>
>> Well... some months later I added 2 more custom slaves on a third branch
>> ("C"), having a typical star topology now with the master in the middle.
>> Again, those are connected with NYM-J as well, with about 4 meters distance
>> and..... yes, it worked!
>>
>> My problems started when I expanded the last branch by another 4 meters
>> trying to connect a third slave on that branch!
>> Suddenly all 3 slaves on that branch disappeared from the bus.
>>
> Yes. That could happen and it is likely to happen. The star topology is bad.
>
>
>> I could not get them back, whatever I tried: removing the 4 meters
>> extension, disconnecting the other 2 branches, only connect a single slave
>> - nothing helped.
>> (But they showed up and worked for weeks before I added the extension!)
>>
>> I then finished my setup first - having a total of 3 slaves on branch "B"
>> and 7 slaves on branch "C". Branch "B" has a total length of 12 meters,
>> branch "C" about 30 meters:
>>
>> Master (DS9490R)
>> |--()--()--...--() "A", 30 meters Cat.5, 8 slaves
>> |--()--()--() "B", 12 meters NYM-J1.5, 3 slaves
>> |--()--()--...--() "C", 30 meters NYM-J1.5, 7 slaves
>>
>> Still, only all slaves of branch "A" and the the first two of branch "B"
>> show up on the bus. For testing purpose I went and connected my laptop
>> running a virtualized Debian installation and OWFS to that bus - and: ALL
>> devices showed up and responded to read and write commands. It took some
>> seconds and maybe 3-4 runs of 'owdir /uncached' to see all devices, but
>> finally it worked.
>>
> No, it didn't. What you have is an extremely brittle setup which may or
> may not work, depending on moon phase and other non-insightful
> parameters. This is impossible to debug.
>
>
>>
>> Now... does anyone have any advice what to change/try next?
>> Should I try to compile OWFS 3.1?
>>
> You should install the Rasbian package from the testing repository.
>
> Testing(Stretch) has owfs-3.1p5. You can use the owfs packages
> from the Raspbian testing repository. Edit (or create) your
> /etc/apt/preferences to contain:
> --------------------------------------------------------------------------
> Package: *
> Pin: release o=Raspbian,a=stable
> Pin-Priority: 500
>
> Package: *
> Pin: release o=Raspbian,a=testing
> Pin-Priority: 300
> --------------------------------------------------------------------------
> This is important so you keep stable (Jessie) for all packages but the ones
> explicitly taken from testing (Stretch).
>
>
> Then, add a line
> --------------------------------------------------------------------------
> deb http://mirrordirector.raspbian.org/raspbian/ testing main contrib
> non-free rpi
> --------------------------------------------------------------------------
> to your /etc/apt/sources.list to get access to the Raspbian testing
> repository.
>
> Do an
>
> $ sudo apt-get update
>
> to read the package metadata, then check
>
> $ sudo apt-cache policy
>
> whether the testing repo is there with priority 300. Then
>
> $ sudo apt-get update -t testing owserver ow-shell
>
> That should install all you need, including the startup files and
> systemd units.
> Note you have to edit /etc/owfs.conf again to contain (this and only this)
> --------------------------------------------------------------------------
> !server: server = localhost:4304
> server: w1
> --------------------------------------------------------------------------
> Restart the owserver service after that.
>
>
>> Is there any configuration (defines?) that can cause different timing on
>> the bus - making it work on i386 and fail on armel?
>>
> Do you use the DS9490 on both?
>
>
>> Any advise to change the bus? Different cable? Different master (I have
>> another LinkUSB)?
>> Again: I already disconnected branches "A" and "B" resulting in no slaves
>> at all - with a single bus/branch.
>>
>> Hope somebody can help me out...
>>
> First, get rid of the star topology. Make a lobe with the help of the
> additional wires in the Cat.5 cable. Replace the 12m NYM-J1.5 stub by
> another lobe cable with at least 4 wires. Connect your 30m NYM-J1.5 stub
> to the far end of that lobe.
>
> If you can't do that or don't want to do that, use multiple host
> adaptors or a host adaptor with built-in switch e.g. the DS2482-800. Or
> try to get two DS2409 switches.
>
> Kind regards
>
> Jan
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> <mailto:Owfs-developers@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
<mailto:Owfs-developers@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/owfs-developers
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
