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>:

> 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/e2c5b4447338e48debae33b66ec742
> 7265b5af23/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>:
>
>> Sven, what code are you using on your attiny?
>>
>> > On Feb 15, 2017, at 7:27 AM, Jan Kandziora <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
>> > 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
>>
>
>
------------------------------------------------------------------------------
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

Reply via email to