Fine-tune timing against disappearing slaves

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Fine-tune timing against disappearing slaves

Sven Giermann
Hi all,

I guess I need some help getting my devices up on my 1-wire bus.
The topology is not really perfect, but a similiar setup used to work in the past and I even tried to create a single branch, which didn't help.

So - what's my setup?

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

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.

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.

I switched back to my embedded Debian with the same result as above - only 2 and the temp sensors. :-(
I switched the DS9490R (I have 2 different ones) with the same result.

It works on OWFS 2.8p15-1 in a i386 VMware machine (Debian 7.9, kernel 3.2) and it fails on OWFS 2.8p15-1 armel (Debian 7.1, kernel 3.8.4).


Now... does anyone have any advice what to change/try next?
Should I try to compile OWFS 3.1?
Is there any configuration (defines?) that can cause different timing on the bus - making it work on i386 and fail on armel?

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

Sven

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Fine-tune timing against disappearing slaves

Jan Kandziora
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Fine-tune timing against disappearing slaves

CReese
Sven, what code are you using on your attiny?

> On Feb 15, 2017, at 7:27 AM, Jan Kandziora <[hidden email]> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Fine-tune timing against disappearing slaves

Sven Giermann
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 <[hidden email]>:
Sven, what code are you using on your attiny?

> On Feb 15, 2017, at 7:27 AM, Jan Kandziora <[hidden email]> 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
> [hidden email]
> 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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Fine-tune timing against disappearing slaves

Sven Giermann
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 <[hidden email]>:
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 <[hidden email]>:
Sven, what code are you using on your attiny?

> On Feb 15, 2017, at 7:27 AM, Jan Kandziora <[hidden email]> 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
> [hidden email]
> 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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Fine-tune timing against disappearing slaves

Alastair D'Silva

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:[hidden email]]
Sent: Friday, 24 February 2017 8:21 PM
To: OWFS (One-wire file system) discussion and help <[hidden email]>
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 <[hidden email]>:

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 <[hidden email]>:

Sven, what code are you using on your attiny?


> On Feb 15, 2017, at 7:27 AM, Jan Kandziora <[hidden email]> 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
> [hidden email]
> 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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers