Problems in owserver with USB and longer cables

[ekgnkb3d ()]

Hi all,
probably I've found a funny bug in the owserver in relation to USB Bus-Master and longer cables. This was mentioned before in this posting very fuzzy, but now I was able to reproduce it in my lab:

1. Install OWFS 2.8p13 or p14 on an ARM9 400MHz
2. Connect one DS9490R USB Bus-Master
3. To provoke the error to appear fast, use an extra long cable of about 200m
   (28nF, e.g. SFTP, see simulation tool below)
4. Connect one DS18B20 to the cable, with Vcc powered to +5V
5. Start owserver with "-uall"
6. Start a client polling for the temp 2 times a second, eg owread or an owcapi application

This works fine for about 2 to 20 minutes. If cable is shorter, 2.8p14 is used or other quirks are done (see remarks below) it can last for days and weeks.
But suddenly it don't return the temp and don't show an error, even the device is not shown in owdir anymore

One workaround:
Restart the owserver, than it works again for 2 - 20 minutes until it suddenly don't return any temp.

Another workaround by keeping the owserver-process alive:
Truncate the cable to about 170m (25nF), than it works again for about 2 to 20 minutes.
But suddenly it return an errno=22, the device disappears again in owdir.
Truncate the cable again to 50m (8nF), this now works forever, I've checked at least for several month :-)

Some remarks:
- To simulate the long cables and the different length I made a capacity-cascade of 8 parallel
  capacities (0.1nF, 0.22nF, 0.47nF, 0.82nF, 1.5nF, 3.3nF, 6.8nF, 15nF and an 8-pol DIP switch
  between pins OWDATA and OWRETURN) this allows simulating cable length of 1m to 200m.
- Beside the simulation, exactly the same behavior appears every week, at a real installation
  with a real cable of about 100m.
- It have nothing to do with star- or other bad network topology, even
  a single cable with a single device at the end is enough to reproduce it
- Disconnecting the cable and wait for minutes, or shorting the device don't solve the problem,
  only restarting the owserver or truncate the cable.
- This is not dependent from dedicated pieces of hardware, it is reproducible with several DS9490R,
  several DS18B20, several ARMs and several types of cable.
- In case several devices are connected to the bus, they all get the problem exactly at the same time,
  or came back when reducing the capacity/restart owserver together
- I've tested also networks via I2C DS2482-100, this works fine since month, no problem here.
  I've not tested serial bus masters
- It looks like the communication capabilities of the USB bus-master is reduced in stages:
  0. After owserver restart it is able to drive 28nF at extreme.
      The statistics counter grow slowly, except the 3 search_errors which stay at 0
  1. Error stage:  Now it can only drive up to 25nF, but the change is not smooth, it is an abrupt state
      change. This is stable for a while, no drifting, I've tested this with my cascade, reproducible for
      meanwhile dozens of tests: NOK >= 25.2nF, OK <= 25nF.
      Now the statistics counter stays at the last value, they don't grow further, even if the
      capacity is above 25nF.
  2. Error stage: Now it can only drive 8nF, again no smooth transition, it is an abrupt state change.
      This seems to be stable forever, NOK >= 8.2nF, OK <= 8nF.
      Now the statistics counter stays, except the 3 search_errors they grow fast if the capacity
      is above 8nF.
- The steps to reproduce, mentioned above, are aimed to see the error as fast as possible. There a
  several methods to delay the problem appearance, which is helpful when needing the OW-network,
  but none of them really solve it:
  - Use shorter cables from beginning onwards, start with 100m cable will cause the problem to
    appear after 3 to 14 days. Maybe below an dedicated length the problem completely disappear,
    but I need this length
  - Using 100 Ohm serial resistors after the bus-master, before the cable will shift the problem
    further by about 50%
  - Use parasitic power of the DS18B20 with Vcc to GND and remove the +5V from the cable.
    This will reduce the capacity and therefore allows longer cable or delays the error appearance.
  - Use the version 2.8p2, according last test this is much more reliable as 2.8p14 for longer cables
  - Daily restart the owserver via cron-job  :-(

[Roberto Spadim]

HIS PAUL READ THIS TOO, MAYBE A BETTER SOLUTION FOR BUS MASTER SPECIFIC
:D i found this too with ds2480b!
maybe a single workaround (ugly, but works) is a counter at device
for example after 10 reads, close and open device (/dev/ttyUSB0 or other device)
this works like cron restart, but it's faster and don't need user to
configure a cron server (in ARM this must be compiled on some distros
or in android devices)
maybe a command line could help a lot (in another post i talked to
paul to add a force bus master type at command line, maybe this could
work too, but this one is another option) for example:
--device-reconnect-counter=0   (don't use reconnect)
--device-reconnect-counter=100   (after 100 complete(send/receive, or
send/timeout) commands reconnect)
this could be good for  rfc2217 devices with a noise internet/ethernet
network too =D
i don't know if we should execute a bus master auto identification
after reconnection (check if we are using a ds2480 or a bit bang
serial por for example...) maybe the other command (force a bus
master) could help here

2012/1/27 ekgnkb3d <achimrs@...>:

>
> Hi all,
> probably I've found a funny bug in the owserver in relation to USB
> Bus-Master and longer cables. This was mentioned before in
> http://old.nabble.com/Re%3A-How-to-enable-statistics--p33202282.html this
> posting very fuzzy, but now I was able to reproduce it in my lab:
>
> 1. Install OWFS 2.8p13 or p14 on an ARM9 400MHz
> 2. Connect one DS9490R USB Bus-Master
> 3. To provoke the error to appear fast, use an extra long cable of about
> 200m
>   (28nF, e.g. SFTP, see simulation tool below)
> 4. Connect one DS18B20 to the cable, with Vcc powered to +5V
> 5. Start owserver with "-uall"
> 6. Start a client polling for the temp 2 times a second, eg owread or an
> owcapi application
>
> This works fine for about 2 to 20 minutes. If cable is shorter, 2.8p14 is
> used or other quirks are done (see remarks below) it can last for days and
> weeks.
> But suddenly it don't return the temp and don't show an error, even the
> device is not shown in owdir anymore
>
> One workaround:
> Restart the owserver, than it works again for 2 - 20 minutes until it
> suddenly don't return any temp.
>
> Another workaround by keeping the owserver-process alive:
> Truncate the cable to about 170m (25nF), than it works again for about 2 to
> 20 minutes.
> But suddenly it return an errno=22, the device disappears again in owdir.
> Truncate the cable again to 50m (8nF), this now works forever, I've checked
> at least for several month :-)
>
> Some remarks:
> - To simulate the long cables and the different length I made a
> capacity-cascade of 8 parallel
>  capacities (0.1nF, 0.22nF, 0.47nF, 0.82nF, 1.5nF, 3.3nF, 6.8nF, 15nF and
> an 8-pol DIP switch
>  between pins OWDATA and OWRETURN) this allows simulating cable length of
> 1m to 200m.
> - Beside the simulation, exactly the same behavior appears every week, at a
> real installation
>  with a real cable of about 100m.
> - It have nothing to do with star- or other bad network topology, even
>  a single cable with a single device at the end is enough to reproduce it
> - Disconnecting the cable and wait for minutes, or shorting the device don't
> solve the problem,
>  only restarting the owserver or truncate the cable.
> - This is not dependent from dedicated pieces of hardware, it is
> reproducible with several DS9490R,
>  several DS18B20, several ARMs and several types of cable.
> - In case several devices are connected to the bus, they all get the problem
> exactly at the same time,
>  or came back when reducing the capacity/restart owserver together
> - I've tested also networks via I2C DS2482-100, this works fine since month,
> no problem here.
>  I've not tested serial bus masters
> - It looks like the communication capabilities of the USB bus-master is
> reduced in stages:
>  0. After owserver restart it is able to drive 28nF at extreme.
>      The statistics counter grow slowly, except the 3 search_errors which
> stay at 0
>  1. Error stage:  Now it can only drive up to 25nF, but the change is not
> smooth, it is an abrupt state
>      change. This is stable for a while, no drifting, I've tested this with
> my cascade, reproducible for
>      meanwhile dozens of tests: NOK >= 25.2nF, OK <= 25nF.
>      Now the statistics counter stays at the last value, they don't grow
> further, even if the
>      capacity is above 25nF.
>  2. Error stage: Now it can only drive 8nF, again no smooth transition, it
> is an abrupt state change.
>      This seems to be stable forever, NOK >= 8.2nF, OK <= 8nF.
>      Now the statistics counter stays, except the 3 search_errors they grow
> fast if the capacity
>      is above 8nF.
> - The steps to reproduce, mentioned above, are aimed to see the error as
> fast as possible. There a
>  several methods to delay the problem appearance, which is helpful when
> needing the OW-network,
>  but none of them really solve it:
>  - Use shorter cables from beginning onwards, start with 100m cable will
> cause the problem to
>    appear after 3 to 14 days. Maybe below an dedicated length the problem
> completely disappear,
>    but I need this length
>  - Using 100 Ohm serial resistors after the bus-master, before the cable
> will shift the problem
>    further by about 50%
>  - Use parasitic power of the DS18B20 with Vcc to GND and remove the +5V
> from the cable.
>    This will reduce the capacity and therefore allows longer cable or
> delays the error appearance.
>  - Daily restart the owserver via cron-job  :-(
> --
> View this message in context: http://old.nabble.com/Problems-in-owserver-with-USB-and-longer-cables-tp33213551p33213551.html
> Sent from the OWFS - Dev mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Owfs-developers mailing list
> Owfs-developers@...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>

--
Roberto Spadim
Spadim Technology / SPAEmpresarial

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Owfs-developers mailing list
Owfs-developers@...
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Roberto Spadim]

maybe another option should be added
--device-reconnect-time=0 (don't use recoonect timeout)
--device-reconnect-time=10 (reconnect after 10 seconds)

2012/1/27 Roberto Spadim <roberto@...>:

> HIS PAUL READ THIS TOO, MAYBE A BETTER SOLUTION FOR BUS MASTER SPECIFIC
> :D i found this too with ds2480b!
> maybe a single workaround (ugly, but works) is a counter at device
> for example after 10 reads, close and open device (/dev/ttyUSB0 or other device)
> this works like cron restart, but it's faster and don't need user to
> configure a cron server (in ARM this must be compiled on some distros
> or in android devices)
> maybe a command line could help a lot (in another post i talked to
> paul to add a force bus master type at command line, maybe this could
> work too, but this one is another option) for example:
> --device-reconnect-counter=0   (don't use reconnect)
> --device-reconnect-counter=100   (after 100 complete(send/receive, or
> send/timeout) commands reconnect)
> this could be good for  rfc2217 devices with a noise internet/ethernet
> network too =D
> i don't know if we should execute a bus master auto identification
> after reconnection (check if we are using a ds2480 or a bit bang
> serial por for example...) maybe the other command (force a bus
> master) could help here
>
> 2012/1/27 ekgnkb3d <achimrs@...>:
>>
>> Hi all,
>> probably I've found a funny bug in the owserver in relation to USB
>> Bus-Master and longer cables. This was mentioned before in
>> http://old.nabble.com/Re%3A-How-to-enable-statistics--p33202282.html this
>> posting very fuzzy, but now I was able to reproduce it in my lab:
>>
>> 1. Install OWFS 2.8p13 or p14 on an ARM9 400MHz
>> 2. Connect one DS9490R USB Bus-Master
>> 3. To provoke the error to appear fast, use an extra long cable of about
>> 200m
>>   (28nF, e.g. SFTP, see simulation tool below)
>> 4. Connect one DS18B20 to the cable, with Vcc powered to +5V
>> 5. Start owserver with "-uall"
>> 6. Start a client polling for the temp 2 times a second, eg owread or an
>> owcapi application
>>
>> This works fine for about 2 to 20 minutes. If cable is shorter, 2.8p14 is
>> used or other quirks are done (see remarks below) it can last for days and
>> weeks.
>> But suddenly it don't return the temp and don't show an error, even the
>> device is not shown in owdir anymore
>>
>> One workaround:
>> Restart the owserver, than it works again for 2 - 20 minutes until it
>> suddenly don't return any temp.
>>
>> Another workaround by keeping the owserver-process alive:
>> Truncate the cable to about 170m (25nF), than it works again for about 2 to
>> 20 minutes.
>> But suddenly it return an errno=22, the device disappears again in owdir.
>> Truncate the cable again to 50m (8nF), this now works forever, I've checked
>> at least for several month :-)
>>
>> Some remarks:
>> - To simulate the long cables and the different length I made a
>> capacity-cascade of 8 parallel
>>  capacities (0.1nF, 0.22nF, 0.47nF, 0.82nF, 1.5nF, 3.3nF, 6.8nF, 15nF and
>> an 8-pol DIP switch
>>  between pins OWDATA and OWRETURN) this allows simulating cable length of
>> 1m to 200m.
>> - Beside the simulation, exactly the same behavior appears every week, at a
>> real installation
>>  with a real cable of about 100m.
>> - It have nothing to do with star- or other bad network topology, even
>>  a single cable with a single device at the end is enough to reproduce it
>> - Disconnecting the cable and wait for minutes, or shorting the device don't
>> solve the problem,
>>  only restarting the owserver or truncate the cable.
>> - This is not dependent from dedicated pieces of hardware, it is
>> reproducible with several DS9490R,
>>  several DS18B20, several ARMs and several types of cable.
>> - In case several devices are connected to the bus, they all get the problem
>> exactly at the same time,
>>  or came back when reducing the capacity/restart owserver together
>> - I've tested also networks via I2C DS2482-100, this works fine since month,
>> no problem here.
>>  I've not tested serial bus masters
>> - It looks like the communication capabilities of the USB bus-master is
>> reduced in stages:
>>  0. After owserver restart it is able to drive 28nF at extreme.
>>      The statistics counter grow slowly, except the 3 search_errors which
>> stay at 0
>>  1. Error stage:  Now it can only drive up to 25nF, but the change is not
>> smooth, it is an abrupt state
>>      change. This is stable for a while, no drifting, I've tested this with
>> my cascade, reproducible for
>>      meanwhile dozens of tests: NOK >= 25.2nF, OK <= 25nF.
>>      Now the statistics counter stays at the last value, they don't grow
>> further, even if the
>>      capacity is above 25nF.
>>  2. Error stage: Now it can only drive 8nF, again no smooth transition, it
>> is an abrupt state change.
>>      This seems to be stable forever, NOK >= 8.2nF, OK <= 8nF.
>>      Now the statistics counter stays, except the 3 search_errors they grow
>> fast if the capacity
>>      is above 8nF.
>> - The steps to reproduce, mentioned above, are aimed to see the error as
>> fast as possible. There a
>>  several methods to delay the problem appearance, which is helpful when
>> needing the OW-network,
>>  but none of them really solve it:
>>  - Use shorter cables from beginning onwards, start with 100m cable will
>> cause the problem to
>>    appear after 3 to 14 days. Maybe below an dedicated length the problem
>> completely disappear,
>>    but I need this length
>>  - Using 100 Ohm serial resistors after the bus-master, before the cable
>> will shift the problem
>>    further by about 50%
>>  - Use parasitic power of the DS18B20 with Vcc to GND and remove the +5V
>> from the cable.
>>    This will reduce the capacity and therefore allows longer cable or
>> delays the error appearance.
>>  - Daily restart the owserver via cron-job  :-(
>> --
>> View this message in context: http://old.nabble.com/Problems-in-owserver-with-USB-and-longer-cables-tp33213551p33213551.html
>> Sent from the OWFS - Dev mailing list archive at Nabble.com.
>>
>>
>> ------------------------------------------------------------------------------
>> Try before you buy = See our experts in action!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-dev2
>> _______________________________________________
>> Owfs-developers mailing list
>> Owfs-developers@...
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>
>
>
>
> --
> Roberto Spadim
> Spadim Technology / SPAEmpresarial

--
Roberto Spadim
Spadim Technology / SPAEmpresarial

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Owfs-developers mailing list
Owfs-developers@...
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[ekgnkb3d]

Hi all experts,

Roberto Spadim wrote:

> :D i found this too with ds2480b!
OK, I expected this!

> maybe a single workaround (ugly, but works) is a counter at device
> for example after 10 reads, close and open device (/dev/ttyUSB0 or other device)

I'm not an expert with the OWFS, but here my 2ct:
Why do you think anything on the Linux device can help here?
So far I've tested, the Linux device stays stable connected over all the error stages. If you reduce the capacity / length of the cable far enough, you can still access the 1-Wire devices forever, so I see no need to reconnect the Linux device, it works.

It looks like some counter unintentionally reduces the "power" of the 1-Wire sender/receiver, so it is not able anymore to communicate with long cables. Using short ones (below about 60m) works fine without any problems.

Hopefully my steps-to-reproduce and the cable-length-simulator help solving this...

Achim

[Roberto Spadim]

with ser2net and ds2480 i could reduce this problem, turning ser2net
down, wait a moment and restart ser2net

ser2net is a serial-tcp program i'm running it at ARM device (android
with linux 2.6.29)
and at server (x86-64) i'm running owhttpd with command option: -d
172.16.0.22:5331

with some time (like you told) the ow disapear
solution for me (i can't cut the cable since i can't change phisical
cable path):
restart owhttpd (works)
restart ser2net (works, but i wait more than restart owhttpd)

running owhttpd at arm device with -d /dev/ttyUSB0 give the same problem

i think that's a problem with ser2net and owhttpd when using usb-serial devices
at ser2net code is easy to put a 'reconnection like algorithm' (since
i can close tcp port and owhttpd disconnect)
but at owhttpd i don't know where to change it

i don't know if you are using usb-serial-ds2480 bus master
but if you are using it, could you try to run it with ser2net??

run ser2net on same computer
and use -d 127.0.0.1:ser2net_port
to connect with owhttpd program

--------------------

> Roberto Spadim wrote:
>>
>>> :D i found this too with ds2480b!
>> OK, I expected this!
i'm using a USB-serial-ds2480b solution not serial-ds2480b (maybe a
problem at USB devices and linux?)

> Roberto Spadim wrote:
>>
>>> maybe a single workaround (ugly, but works) is a counter at device
>>> for example after 10 reads, close and open device (/dev/ttyUSB0 or other
>>> device)
>>
> I'm not an expert with the OWFS, but here my 2ct:
> Why do you think anything on the Linux device can help here?
> So far I've tested, the Linux device stays stable connected over all the
> error stages. If you reduce the capacity / length of the cable far enough,
> you can still access the 1-Wire devices forever, so I see no need to
> reconnect the Linux device, it works.
>
> It looks like some counter unintentionally reduces the "power" of the 1-Wire
> sender/receiver, so it is not able anymore to communicate with long cables.
> Using short ones (below about 60m) works fine without any problems.

no no it's not a problem of eletrical power and a software program,
i think that's a problem at USB devices stop working without notices
(maybe don't sending the BREAK command to ds2480b, or maybe just a
linux problem, or maybe a problem without notices, or maybe a time
problem with USB converter)

the reconnection do restart ds2480 initial state that's the nice part
and this works (i think the problem with usb device is the
communication)


> Hopefully my steps-to-reproduce and the cable-length-simulator help solving
> this...
yes this works but my problem is: i can't change cable path, and i
don't know if add a resitor or add a capacitor could help, i must
check in plant with a scope to check diferences, but your experience
is very nice to check this problem (maybe it's not only a usb problem,
but my cable problem... i checked statistics and it don't show shorts,
but i can't see more my device, and restart works nice to get it back)

>
> Achim
> --
> View this message in context: http://old.nabble.com/Problems-in-owserver-with-USB-and-longer-cables-tp33213551p33214966.html
> Sent from the OWFS - Dev mailing list archive at Nabble.com.
>
>



--
Roberto Spadim
Spadim Technology / SPAEmpresarial

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Owfs-developers mailing list
Owfs-developers@...
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[ekgnkb3d]

Hi Roberto

>i don't know if you are using usb-serial-ds2480 bus master
>but if you are using it, could you try to run it with ser2net??
sorry, I don't have an usb->serial adapter here and also no DS2480

It looks like restarting owhttpd is equivalent to restarting owserver

> i'm using a USB-serial-ds2480b solution not serial-ds2480b (maybe a
> problem at USB devices and linux?)
No, I don't think so, because the connection to the USB device within Linux stays stable, once you cut down your cable (or reduce the capacity), it works endless through the Linux device.
That's the reason, why some installations (which had short cables from beginning onward) don't drop the 1-Wire network, even not after month.

>> It looks like some counter unintentionally reduces the "power" of the 1-Wire
>> sender/receiver, so it is not able anymore to communicate with long cables.
>> Using short ones (below about 60m) works fine without any problems.
> no no it's not a problem of eletrical power and a software program,
> i think that's a problem at USB devices stop working without notices
I've prooven that the USB-device stays connected over month (if the capacitiy is below 8nF)

> I can't change cable path,
Of course, that's normal :-) That's why I build by capacity-array to simulate different cable length

> and i don't know if add a resitor
this only delays the error, don't solve it!

>or add a capacitor could help,
No, adding a capacity is contraproductive, you should remove capacitiy from your cable, e.g by using better ones, unconnect wires or shield, or shortening it.

curently I'm testing older versions of OWFS, hopefully they work better. I will post results, once finished

Achim

[ekgnkb3d]

Hi Paul, Roberto and all other 1-Wire freaks,
during some further tests I found out, that until version 2.8p2 the OWFS was not afflicted by this problem, from my viewpoint this is OK and runs stable!
It looks like the problem was introduced with 2.8p3 and 2.8p4 versions, see here:

- The 2.7p33 works fine, without this problem
- The 2.7p39 works fine, too
- The 2.8p2 as well, works fine
- The 2.8p3 showed a different problem behavior:
                it completely hangs after a while, no chance to get it back to work by reducing the cable length /capacity.
                But a owserver restart still helps.
- The 2.8p4 was the first version showing the problem as described in my first posting
- Some versions between 2.8p4 and 2.8p14 all are tested showing the same problem

Further tests with the 2.8p2 are ongoing, but they are fine since 33h now, whereas the other versions reproducible hang after some minutes (with the provoking capacity load of 28nF described in the first posting). So it's at least an improvement of about factor 500

Hopefully this is a good basis to search for the problem....

Thanks also to Andrey giving me the initial hint!
   Achim

[promy2]

Some parts of this message have been removed. Learn more about Nabble's security policy.

I have a similar problem, with owfs 2.7p32-2 and 2.7p38-1 on an nslu2 running unslung: when using temploggerd and a script, owfs crashes

The script now checks if everything is ok, and does a restart if not, but the temploggerd graphs look all messed up.

Someone suggested to use a serial based device as a solution, but solving this problem would be nicer ;-)

thanks in advance.

 

PS: all my ds18s20 and ds18b20 are running in parasite mode but with the 1wire data connected to 5V and battery backup as done by hobbyboards.

 

Jan

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Owfs-developers mailing list
Owfs-developers@...
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Roberto Spadim]

yes, here is the same problem but i couldn't test with rfc2722 since it's a new feature, but with -d /dev/ttyUSB0 this problem occur in the same situations that you showed

>- The 2.8p2 as well, works fine
>- The 2.8p3 showed a different problem behavior:

2012/2/1 Jan Sennesael <Jan.sennesael@...>

I have a similar problem, with owfs 2.7p32-2 and 2.7p38-1 on an nslu2 running unslung: when using temploggerd and a script, owfs crashes

The script now checks if everything is ok, and does a restart if not, but the temploggerd graphs look all messed up.

Someone suggested to use a serial based device as a solution, but solving this problem would be nicer ;-)

thanks in advance.

 

PS: all my ds18s20 and ds18b20 are running in parasite mode but with the 1wire data connected to 5V and battery backup as done by hobbyboards.

 

Jan

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Owfs-developers mailing list
Owfs-developers@...
https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
Roberto Spadim
Spadim Technology / SPAEmpresarial

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Owfs-developers mailing list
Owfs-developers@...
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Michael Markstaller]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 01.02.2012 14:10, schrieb ekgnkb3d:
>
> Hi Paul, Roberto and all other 1-Wire freaks, during some further
> tests I found out, that until version 2.8p2 the OWFS was not
> afflicted by this problem, from my viewpoint this is OK and runs
> stable! It looks like the problem was introduced with 2.8p3 and
> 2.8p4 versions, see here:

Just a short note, after reading your tests: I can fully confirm that..
If some testing in bigger environments is needed let me know, so far
I'm stuck with 2.8p2 as anything newer failed..

best regards

Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8pepsACgkQaWRHV2kMuALaKgCgsef9RJj+dVo5VEg38ijRcLvL
Hg0AoPIxTsBX27FCXAbI3MuGNb9gTw1b
=Iy9Q
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Owfs-developers mailing list
Owfs-developers@...
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Michael Markstaller]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Just to further specify:

- - BTW: this isn't ARM-specific IMHO, I experience exactly the same on
x86/Debian lenny (though: other cabling, not that long but worse; will
try to reproduce in testbed with capacitors tomorrow)

- - fully agreed, this is no "cabling" or topology problem, adding
resistors etc. only shifts the issue a little left or right in time..

- - adding a "hard" reset after N reads like Roberto suggested is IMHO
still a big quirk: ow* should detect and recover the problem (which
should be possible as a restart of owserver resolves also)

Reason: I'd get into troubles with that probably on very short, very
clean 1-Wire structures where iButtons are to be detected 100%
reliable&ASAP, though another bus (lokal or remote owserver) might run
"leaky" with 10 sensors on 100meters (where short outages are no issue
at all)

- -> 50% of my "reader-code" is just to detect if owserver lost a
busmaster (only using DS9490/USB) and restart it to recover, I'd
really want to get away from this ;)


I digged through the owfs-code a little today and found DEBUG_DS2490
and ds2490status in ow_interface.c which might help to track this down
but been unable to make it speak so far :(


best regards

Michael


P.S.: I'm after this because it's a problem bugging me for quite a
while now, and I think it's pretty close to getting traced down here..
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8rA6YACgkQaWRHV2kMuAJCSwCePFYDrDPOsF6Qlp8Y+OpW7GwK
+iAAn1zEgm4lQLs/up1szwwTvoXGoC7X
=3JfP
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Owfs-developers mailing list
Owfs-developers@...
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Roberto Spadim]

well must check source code and see if it´s a time problem on communications, im a bit busy here, with time i can check, if anyone can check what changed in this versions that worked and that don´t work could be nice
 i will be out for 1 month +- with a big work

2012/2/2 Michael Markstaller <mm@...>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Just to further specify:

- - BTW: this isn't ARM-specific IMHO, I experience exactly the same on
x86/Debian lenny (though: other cabling, not that long but worse; will
try to reproduce in testbed with capacitors tomorrow)

- - fully agreed, this is no "cabling" or topology problem, adding
resistors etc. only shifts the issue a little left or right in time..

- - adding a "hard" reset after N reads like Roberto suggested is IMHO
still a big quirk: ow* should detect and recover the problem (which
should be possible as a restart of owserver resolves also)

Reason: I'd get into troubles with that probably on very short, very
clean 1-Wire structures where iButtons are to be detected 100%
reliable&ASAP, though another bus (lokal or remote owserver) might run
"leaky" with 10 sensors on 100meters (where short outages are no issue
at all)

- -> 50% of my "reader-code" is just to detect if owserver lost a
busmaster (only using DS9490/USB) and restart it to recover, I'd
really want to get away from this ;)


I digged through the owfs-code a little today and found DEBUG_DS2490
and ds2490status in ow_interface.c which might help to track this down
but been unable to make it speak so far :(


best regards

Michael


P.S.: I'm after this because it's a problem bugging me for quite a
while now, and I think it's pretty close to getting traced down here..

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8rA6YACgkQaWRHV2kMuAJCSwCePFYDrDPOsF6Qlp8Y+OpW7GwK
+iAAn1zEgm4lQLs/up1szwwTvoXGoC7X
=3JfP

-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!

The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!

http://p.sf.net/sfu/learndevnow-d2d

_______________________________________________
Owfs-developers mailing list
Owfs-developers@...
https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
Roberto Spadim
Spadim Technology / SPAEmpresarial

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Owfs-developers mailing list
Owfs-developers@...
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Michael Markstaller]

Am 02.02.2012 22:58, schrieb Roberto Spadim:
> well must check source code and see if it´s a time problem on
> communications, im a bit busy here, with time i can check, if anyone can
> check what changed in this versions that worked and that don´t work
> could be nice
>  i will be out for 1 month +- with a big work

I'll try to find as much as possible, because to be honest I think there
more than one thing wrong using DS9490, it also isn't perfect with 2.8p2..

Short conclusion: If my assumptions are right, reading a DS18B20
(parasite OR powered doesnt matter) switches the DS2490 from flexible to
regular-speed and disables Strong pullup..


-> As a first step I added some more debugging, to see whats going on;
patch attached
It's all inside OW_SHOW_TRAFFIC enabled with configure ...
--enable-owtraffic so it shouldnt hurt..

Though I'm not sure it's right, I used the DS2490 datasheet and while
typing it I found some discrepancies to at least existing comments in
the source..


My findings so far:
- One thing I came across reading sources and datasheets: recommended
for longer buses is a Pulldown Slew Rate of 1V/us (0x4), default and
used is 0.83V/us (0x5)

- Speed goes from initial flexible to regular (0x0) after reading a
DS18B20 sensor? And Strong Pullup is disabled then?


Started:
  DEBUG: ow_usb_msg.c:(212) USB status registers EFlags:7->SPU:1
Dspeed:1,Speed:1,SPUdur:0, PDslew:5, W1lowtime:4, W0rectime:4,
DevState:32, CC1:253, CC2:72, CCState:0, DataOutState:0, DataInState:8
(same after reading a DS2438)

After first read of a DS18B20:
  DEBUG: ow_usb_msg.c:(212) USB status registers EFlags:0->SPU:0
Dspeed:0,Speed:0,SPUdur:32, PDslew:5, W1lowtime:4, W0rectime:4,
DevState:32, CC1:117, CC2:8, CCState:0, DataOutState:0, DataInState:9


best regards

Michael

[patch_2490_debugging.diff]

---

--- owfs-2.8p14/module/owlib/src/c/ow_usb_msg.c 2011-11-20 22:39:51.000000000 +0100
+++ module/owlib/src/c/ow_usb_msg.c 2012-02-04 14:59:14.556483753 +0100
@@ -196,6 +196,46 @@
  if (buffer[8] & STATUSFLAGS_IDLE) {
 #if OW_SHOW_TRAFFIC
  _Debug_Bytes("USB status registers ---- idle ----", buffer, ret) ; // debugging
+ //FIXME: if the line below really works we dont nee the line above ;)
+ LEVEL_DEBUG("USB status registers EFlags:%u->SPU:%u Dspeed:%u,Speed:%u,SPUdur:%u, PDslew:%u, W1lowtime:%u, W0rectime:%u, DevState:%u, CC1:%u, CC2:%u, CCState:%u, DataOutState:%u, DataInState:%u",
+    buffer[0], (buffer[0]&0x01), (buffer[0]&0x04 ? 1 : 0),
+    buffer[1],
+    buffer[2],
+    buffer[4],
+    buffer[5],
+    buffer[6],
+    buffer[8],
+    buffer[9],
+    buffer[10],
+    buffer[11],
+    buffer[12],
+    buffer[13]    );
+ /*
+        Datasheet DS2490 page 29 table 16
+        0: Enable Flags: SPUE=1(bit0) If set to 1, the strong pullup to 5V is enabled, if set to 0, it is disabled.
+        bit1 should be 0 but is 1 ?! SPCE = 4(bit2) If set to 1, a dynamic 1-Wire bus speed change through a Communication command is enabled, if set to 0, it is disabled.
+        1: 1-Wire Speed
+        2: Strong Pullup Duration
+        3: (Reserved)
+        4: Pulldown Slew Rate
+        5: Write-1 Low Time
+        6: Data Sample Offset / Write-0 Recovery Time
+        7: reserved
+        8: Device Status Flags: bit0: SPUA if set to 1, the strong pullup to 5V is currently active, if set to 0, it is inactive.
+            bit3(8): PMOD if set to 1, the DS2490 is powered from USB and external sources, if set to 0, all DS2490 power is provided from USB. FIXME: expose this to clients to check!
+            bit4(16): HALT if set to 1, the DS2490 is currently halted, if set to 0, the device is not halted.
+            bit5(32): IDLE if set to 1, the DS2490 is currently idle, if set to 0, the device is not idle.
+            bit5(64): EPOF: Endpoint 0 FIFO status, see: If EP0F is set to 1, the Endpoint 0 FIFO was full when a new control transfer setup packet was
+                received. This is an error condition in that the setup packet received is discarded due to the full
+                condition. To recover from this state the USB host must send a CTL_RESET_DEVICE command; the
+                device will also recover with a power on reset cycle. Note that the DS2490 will accept and process a
+                CTL_RESET_DEVICE command if the EP0F = 1 state occurs. If EP0F = 0, no FIFO error condition exists.
+        9: Communication Command, Byte 1
+        10: Communication Command, Byte 2
+        11: Communication Command Buffer Status
+        12: 1-Wire Data Out Buffer Status
+        13: 1-Wire Data In Buffer Status
+ */
 #endif /* OW_SHOW_TRAFFIC */
  if (*readlen > 0) {
  // we have enough bytes to read now!
@@ -210,6 +250,20 @@
  } else {
 #if OW_SHOW_TRAFFIC
  _Debug_Bytes("USB status registers ---- Not idle -----", buffer, ret) ; // debugging
+ //FIXME: if the line below really works we dont nee the line above ;)
+ LEVEL_DEBUG("USB status registers EFlags:%u->SPU:%u Dspeed:%u,Speed:%u,SPUdur:%u, PDslew:%u, W1lowtime:%u, W0rectime:%u, DevState:%u, CC1:%u, CC2:%u, CCState:%u, DataOutState:%u, DataInState:%u",
+    buffer[0], (buffer[0]&0x01), (buffer[0]&0x04 ? 1 : 0),
+    buffer[1],
+    buffer[2],
+    buffer[4],
+    buffer[5],
+    buffer[6],
+    buffer[8],
+    buffer[9],
+    buffer[10],
+    buffer[11],
+    buffer[12],
+    buffer[13]    );
 #endif /* OW_SHOW_TRAFFIC */
  }
  // this value might be decreased later...

---

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Owfs-developers mailing list
Owfs-developers@...
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Michael Markstaller]

Am 04.02.2012 16:42, schrieb Michael Markstaller:
> Short conclusion: If my assumptions are right, reading a DS18B20
> (parasite OR powered doesnt matter) switches the DS2490 from flexible to
> regular-speed and disables Strong pullup..

While doing further tests: I *think* I narrowed it down further: the
(unwanted) switch from flexible to regular-speed happens when a
reset_error occurs.

With 2.8p2 I don't see that much reset_errors, so less problems.
With 2.8p14 reset_errors occur pretty quick after 1-5 conversions and
then the problems start..

So the root-cause might be the reset_error which also happens on very
short and clean bus with 2.8p14 which is likely also related to the
other problems I have..


Michael

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Owfs-developers mailing list
Owfs-developers@...
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Roberto Spadim]

hum.... with ds2480 how reset_errors is incremented? maybe it occur with a serial break command?

2012/2/4 Michael Markstaller <mm@...>

Am 04.02.2012 16:42, schrieb Michael Markstaller:

> Short conclusion: If my assumptions are right, reading a DS18B20
> (parasite OR powered doesnt matter) switches the DS2490 from flexible to
> regular-speed and disables Strong pullup..

While doing further tests: I *think* I narrowed it down further: the
(unwanted) switch from flexible to regular-speed happens when a
reset_error occurs.

With 2.8p2 I don't see that much reset_errors, so less problems.
With 2.8p14 reset_errors occur pretty quick after 1-5 conversions and
then the problems start..

So the root-cause might be the reset_error which also happens on very
short and clean bus with 2.8p14 which is likely also related to the
other problems I have..


Michael

------------------------------------------------------------------------------
Try before you buy = See our experts in action!

The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!

http://p.sf.net/sfu/learndevnow-dev2

_______________________________________________
Owfs-developers mailing list
Owfs-developers@...
https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
Roberto Spadim
Spadim Technology / SPAEmpresarial

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Owfs-developers mailing list
Owfs-developers@...
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Michael Markstaller]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 04.02.2012 23:53, schrieb Roberto Spadim:
> hum.... with ds2480 how reset_errors is incremented?
2490! (better known as DS9490 which has this inside.) Nothing serial..

But thats where I'm stuck, why the reset_errors occur and where to
search in the source for.

The other thing, setting the right flags after a reset should be
easier, guess I already found some clue what goes wrong but have to
test..

But thats (wrong speed-flags after reset) IMHO not the main problem,
I'm pretty sure in the meantime!
owfs 2.8p14 looses DS9490-busmasters even in the simplest case locally
attached with multiple DS9490 and 1 sensor and 10cm cabling, it just
happens faster with long cables..


Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8txeoACgkQaWRHV2kMuAKfIACgmYpAcSD72LYxAEUxkrVPfAMH
6BoAoLGcHXt3tukCS0bnpxFFjrLcIFeE
=5J6y
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Owfs-developers mailing list
Owfs-developers@...
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Michael Markstaller]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ok, digging some deeper today.

Preface: these were found&analyzed using 2.8p14 on my Ubuntu
11.04/32-Desktop, one DS9490, 5cm cable a parasite DS18B20 and one
DS2438 (similar MS-TH). NOTHING else on the USB, i7..
Should say: it is also very unstable on very short buses right now. I
also added a ton of debugging-output to get this picture a little
clearer..


My current assumptions:
#1) The source-problem: reset_errors:
These happen due to timeouts ("never got idle") in DS9490_getstatus
doing an POR of the DS2490 which leads to problem #2 then.
The reason (again assumed!)

- - DS9490_HaltPulse isnt working always (or accepted, delivered,
whatever) in lets say at least 10% of the cases; simply doubling the
call makes the trouble appear just 50% later..
(Question: why is an infinite SPU-period (0) and not the builtin
SPU-duration of the chip used? Maybe there's a good reason for, but I
wondered..)

- -> The DS2490 stays in SPU then (measured) and owfs thinks of a
timeout due to it's never saying "idle" anymore)


#2) no initialization of MODE registers and speed etc. is done after
this reset.
(I don't know where this code should go but it surely needs to be done
after a full Power-on-reset..)


#3) I'm still investigating, now with long lines, is then probably the
initially reported problem:
(but it makes no real sense to troubleshoot, as long as it fails
within minutes with the above, simple setup)
The reconnect doesn't do anything at all as far as I can see when the
bus is getting into a "zero-ID" state (Attempting RESET on null bus):
Just a log-excerpt:
- --- cut ---
  DEBUG: ow_reset.c:(48) Reset error. Reconnection 3/2
  DEBUG: ow_transaction.c:(84) select = 1
  DEBUG: ow_cache.c:(956) 28 C5 0E EC 01 00 00 38 size=4
  DEBUG: ow_cache.c:(1083) Search in cache sn 28 C5 0E EC 01 00 00 38
pointer=0xb7746c64 index=-2 size=4
  DEBUG: ow_cache.c:(1119) Value not found in cache
  DEBUG: ow_select.c:(66) Selecting a path (and device)
path=/28.C50EEC010000/temperature10 SN=28 C5 0E EC 01 00 00 38 last
path=00 00 00 00 00 00 00 00
  DEBUG: ow_select.c:(79) Continuing root branch
  DEBUG: ow_ds9490.c:(513) Attempting RESET on null bus
  DEBUG: ow_reset.c:(48) Reset error. Reconnection 4/2
- --- cut ---

My programming skills are limited but as far as I can see DS9490_reset
returns BUS_RESET_ERROR on (Attempting RESET on null bus) then and
nothing else happens to really recover or simply delete (?) a lost one
and maybe let the usb-scanner rediscover it..

And again: as already said: the core symptom (recovery/reconnect) also
happens with 2.8p2 already but *much less frequently*
(though still dozens times a day, an external process restarting
owserver on disappearing DS9490 after one minute does the job so far
but thats: a big quirk..)


and on another thing:
Am 07.02.2012 14:45, schrieb Mark Richards:
> Yours is not a new idea.. however there are good reasons for
> making physical adjustments to the one wire net.
I agree. But I'm trying to run 1-Wire in many "unknown" environment ;)
And we're really talking about a software-problem about recovery here,
otherwise it wouldn't work for hours after an owserver-restart..


best regards

Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8xvUkACgkQaWRHV2kMuAIlwQCeNo8GGVzFvzhdEvekulwfOQcC
QwIAoKOKhqEOUEy0VLNiz3PELlt49IOp
=yv2Q
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Owfs-developers mailing list
Owfs-developers@...
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Michael Markstaller]

Err, referring to
http://article.gmane.org/gmane.comp.file-systems.owfs.devel/9120
Current owfs is really unusable with DS9490 and the older ones have some
issue with libusb under OpenWRT, I'm stuck a little here; tried many
things but when I touch code usually afterwards it's more broken than
fixed ;(

Nobody using it that way ?

best regards

Michael

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Owfs-developers mailing list
Owfs-developers@...
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Paul Alfille-2]

To hunt this down, you find that heavy USB activity causes communication failures and puts owfs is an unusable state? I need to create a test bed to mimic and correct this.

Paul

On Thu, Mar 15, 2012 at 5:52 PM, Michael Markstaller <mm@...> wrote:

Err, referring to
http://article.gmane.org/gmane.comp.file-systems.owfs.devel/9120
Current owfs is really unusable with DS9490 and the older ones have some
issue with libusb under OpenWRT, I'm stuck a little here; tried many
things but when I touch code usually afterwards it's more broken than
fixed ;(

Nobody using it that way ?

best regards

Michael

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure

_______________________________________________
Owfs-developers mailing list
Owfs-developers@...
https://lists.sourceforge.net/lists/listinfo/owfs-developers

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Owfs-developers mailing list
Owfs-developers@...
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[greentux]

I Think it should be easy for Michael to organize something like a
remote access to a testbed. He has a lot of devices :)

regards


Am 16.03.2012 14:49, schrieb Paul Alfille:

> To hunt this down, you find that heavy USB activity causes communication
> failures and puts owfs is an unusable state? I need to create a test bed
> to mimic and correct this.
>
> Paul
>
> On Thu, Mar 15, 2012 at 5:52 PM, Michael Markstaller <mm@...
> <mailto:mm@...>> wrote:
>
>     Err, referring to
>     http://article.gmane.org/gmane.comp.file-systems.owfs.devel/9120
>     Current owfs is really unusable with DS9490 and the older ones have some
>     issue with libusb under OpenWRT, I'm stuck a little here; tried many
>     things but when I touch code usually afterwards it's more broken than
>     fixed ;(
>
>     Nobody using it that way ?
>
>     best regards
>
>     Michael
>
>     ------------------------------------------------------------------------------
>     This SF email is sponsosred by:
>     Try Windows Azure free for 90 days Click Here
>     http://p.sf.net/sfu/sfd2d-msazure
>     _______________________________________________
>     Owfs-developers mailing list
>     Owfs-developers@...
>     <mailto:Owfs-developers@...>
>     https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
>
>
>
> _______________________________________________
> Owfs-developers mailing list
> Owfs-developers@...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Owfs-developers mailing list
Owfs-developers@...
https://lists.sourceforge.net/lists/listinfo/owfs-developers