Thanks for that tip, I checked the logs but it was not "unplugged" until
I actually unplugged it to fix the problem.
I have a similar devd-setup (see 1) for FreeBSD conf) to solve the
device-name-jumping problem. It doesn't always change name, but
sometimes it seems to..
So, I'm quite certain that was not the case.
However, I got an off-list tip from the author of a previous thread
(http://sourceforge.net/p/owfs/mailman/message/31750321/) , which
addresses the issue that the LinkUSB has support for multiple baud
rates, but owfs only tries to init with 9600bps. The explanation would
be that the LinkUSB somehow jumps into another baudrate, and owfs then
fails to connect to it.
I cannot really say for sure that this is what happens, until I get one
of these lockups again so I can analyze it further.
A test which proves that owfs does indeed fail to handle other
baudrates, as described in the previous thread:
First tell the LinkUSB to set the speed to 19200:
$ cu -l /dev/cua-linkusb -s 9600
(write space to get "LinkUSB V1.5", write , (comma) to move to 19200)
$ cu -l /dev/cua-linkusb -s 19200
(write space again to verify 19200 is active)
Start owserver, and it won't find the device at all, since it only tries
9600bps. Only solution is to either switch back to 9600 manually, or
power-cycle the device.
I did some patching, also based on Arne's suggestions in the previous
thread, to improve the detection situation. In addition to his changes,
this tries all speeds with all flow-control modes, and also supports
Globals.baud to set the initial speed:
https://github.com/stromnet/owfs/commit/478389a97d71d76e31e4d3c913eca4397ec6a375
As the todo note indicates, I'd like to add the ability to change the
LINKs speed from within owfs. I did some speed experiments, with
interesting outcome...
This was done by manually telling the LINK to use a certain baudrate,
and then start owserver with that setting.
At 9600 bps, a full owdir (uncached) takes ~ 1700ms on my 30 devices. A
owread on one temp sensors "power" value, takes ~100ms
At 19200 bps, the owdir takes 1460ms and the owread ~80ms.
At 38400 bps, the owdir takes ~1300ms.
However, the owread fails, and renders the device inaccessible! I cannot
get it back in working shape, without pulling the USB plug.
Sending a break in any baudrate does not help, it won't give any
response at all.
I've tried both with a USB hub, and without one.
A note about USB power-cycling, I tried to power it down using usbconfig:
usbconfig -d ugen4.2 power_off
usbconfig -d ugen4.2 power_on
The kernel detects the device as disconnected, and reconnects it on
power on. But it still won't wake it up from the dead. Only unplugging
it helps in the above scenario.
To summarize:
Could my sporadic problems be related to baud-rate changes? From what I
read in the code, owfs does not change baud-rate by itself, so that
would mean it changed by some glitch. But if it is changed, owfs would
not find the device without the patch above, until it is power cycled.
On the other hand, the 38400bps test proves that the LinkUSB can go into
some kind of crashed mode, where it does not respond at all. If this is
what happens, the baud-rate patch wont help.
Using higher baud-rate between the host and the device shows some,
although small, performance improvements. ~15% on the scan, and 25% on
the read when speed was doubled. Quite strange that it crashes on 38400
though, the device advertises both 38400 and 57600bps..
Johan
1)
For the record, my /usr/local/etc/devd/linkusb.conf:
attach 10 {
device-name "uftdi[0-9]+";
match "vendor" "0x0403";
match "product" "0x6001";
match "sernum" "XXXXXXXX";
action "logger LinkUSB attached on
$cdev/$device-name/$sernum/cua$ttyname, creating symlink and setting
owner. ;
/bin/ln -fs /dev/cua$ttyname /dev/cua-linkusb;
chown owfs /dev/cua-linkusb";
};
On 6/6/14 09:20 , Stefano Miccoli wrote:
the LinkUSB is a serial over USB adapter: can you rule out USB problems?
I have a LinkUSB connected to a very old server running Linux and
sometimes the device gets "disconnected"
So here you see that once a week or so my linkUSB is disconnected and
"rediscovered", which means that I have the linkUSB bouncing between
/dev/ttyUSB0 and /dev/ttyUSB1. I have no idea who is responsible of
this behaviour (the server USB adapter? the linkUSB? the Linux kernel?)
I solved the problem with a custom udev rule, which creates a
/dev/linkUSB0 symlink to the current /dev/ttyUSBx device.
SUBSYSTEM=="tty", \
ATTRS{product}=="FT232R USB UART", ATTRS{serial}=="XXXXXXXX", \
SYMLINK+="linkUSB0", GROUP="owfs"
where of course you have to substitute XXXXXXXX with the actual serial
number. BTW I also set the group to "owfs" instead of "dialout" since
I do not run owserver as root but as a user belonging to the group,
you guess, "owfs".
S.
On 05 Jun 2014, at 13:52, Johan Ström <jo...@stromnet.se
<mailto:jo...@stromnet.se>> wrote:
Hi,
I got a LinkUSB as a master for my 1-wire net, around 80m with 30
devices.
The bus is scanned every minute and temperature sensors polled (most of
the devices). Around 3 times a second I try to scan the alarm dir for
alarms (DS2406's), and possibly handle these.
Normally this works perfectly fine, and has done so for a few years. No
re-reads or CRC errors according to the counters.
However, a few times during these years, the whole network has become
inaccessible, and the only way to get it back into working shape has
been to unplug the LinkUSB from both the 1w-network (DQ+DGND), and the
USB port.
Once doing this, it all comes back up immediately, and all devices work
fine.
If I recall correct I have also pulled the external 5V feed to the
devices too, but just disconnecting the 1w-network from the LinkUSB, and
disconnecting the 5V feed has NOT been enough, the USB port must be
disconnected as well. Restart of owserver does not help.
Anyone else with similar experiences, or ideas on what might be causing
this or how to work around it? Hard to debug since I cannot really
reproduce it at will..
Thanks
Johan
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and
their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
