Hi,
several fhem users are plagued by spontaneous disconnects/reconnects of USB devices. This is most probably not a issue of fhem but a problem of hardware and/or USB drivers.
I would like to summarize my findings so far. They are taken from my experience as well as from other fhem user's and from a web research. This is written for Linux users.
Regards,
Boris
A. Problem description
--------------------------
USB devices spontaneously disconnect from the bus. They are reconnected after some time ranging from zero to many seconds. fhem global log shows messages like
2009.01.12 19:22:14 1: USB device /dev/elv_fhz1300pc disconnected, waiting to reappear
2009.01.12 19:22:19 1: USB device /dev/elv_fhz1300pc reappeared
A look into the kernel message log with
grep usb /var/log/messages | tail -n 100 | less
shows messages like
Jan 12 19:22:14 bunkertor kernel: usb 10-2.1: USB disconnect, address 59
Jan 12 19:22:14 bunkertor kernel: usb 10-2.1.1: USB disconnect, address 61
Jan 12 19:22:14 bunkertor kernel: usb 10-2.4: USB disconnect, address 60
Jan 12 19:22:14 bunkertor kernel: usb 10-2: reset full speed USB device using uhci_hcd and address 2
Jan 12 19:22:14 bunkertor kernel: usb 10-2.1: new full speed USB device using uhci_hcd and address 62
Jan 12 19:22:15 bunkertor kernel: usb 10-2.1: not running at top speed; connect to a high speed hub
Jan 12 19:22:15 bunkertor kernel: usb 10-2.1: configuration #1 chosen from 1 choice
Jan 12 19:22:15 bunkertor kernel: usb 10-2.1: New USB device found, idVendor=04b4, idProduct=6560
Jan 12 19:22:15 bunkertor kernel: usb 10-2.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Jan 12 19:22:15 bunkertor kernel: usb 10-2.4: new full speed USB device using uhci_hcd and address 63
Jan 12 19:22:15 bunkertor kernel: usb 10-2.4: configuration #1 chosen from 1 choice
Jan 12 19:22:15 bunkertor kernel: usb 10-2.4: FTDI USB Serial Device converter now attached to ttyUSB0
Jan 12 19:22:15 bunkertor kernel: usb 10-2.4: New USB device found, idVendor=0403, idProduct=e0ef
Jan 12 19:22:15 bunkertor kernel: usb 10-2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jan 12 19:22:15 bunkertor kernel: usb 10-2.4: Product: ELV EM 1010 PC
Jan 12 19:22:15 bunkertor kernel: usb 10-2.4: Manufacturer: ELV AG
Jan 12 19:22:15 bunkertor kernel: usb 10-2.1.1: new full speed USB device using uhci_hcd and address 64
Jan 12 19:22:16 bunkertor kernel: usb 10-2.1.1: configuration #1 chosen from 1 choice
Jan 12 19:22:16 bunkertor kernel: usb 10-2.1.1: FTDI USB Serial Device converter now attached to ttyUSB1
Jan 12 19:22:16 bunkertor kernel: usb 10-2.1.1: New USB device found, idVendor=0403, idProduct=e0e8
Jan 12 19:22:16 bunkertor kernel: usb 10-2.1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 12 19:22:16 bunkertor kernel: usb 10-2.1.1: Product: ELV FHZ 1300 PC
Jan 12 19:22:16 bunkertor kernel: usb 10-2.1.1: Manufacturer: ELV AG
Jan 12 19:22:16 bunkertor kernel: usb 10-2.1.1: SerialNumber: xxxxxxxxxxx
B. Possible reasons and remedies
--------------------------------------
1. Not enough power on the bus
FHZ1300PC directly connected to the computer's built-in USB ports does not work at all or seizes to work after short time. This is likely due to the USB's inability to provide sufficient power to the connected
devices. Use of a powered hub seems to cure the problem in some cases (confirmed, see [6]).
2. Mixture of USB 1.1 and USB 2.0 devices
Use of an USB 1.1 hub to connect USB 2.0 devices and vice versa might lead to timing problems (see [3]). Consistent use of either USB 1.1 or USB 2.0 devices might be a cure (unconfirmed).
3. Timing problems
It was suggested that late answers from a device make the driver think that it has gone away. This would lead to a disconnect. followed by a reconnect when the device's reply arrives. Changing the timeouts
might be a cure. It is not known how to achieve this (see [5]).
3. Electromagnetic interferences
Bad shielding of cables or devices might lead to interferences with electric devices nearby (fridges, light switches, ...). A computer can cope with this problem better or worse. Changing the computer's
hardware helps (confirmed, see [7]). If this is not feasible, use a ferrite ring (see [8] for instance) or two around the ends of the cable (unconfirmed).
4. USB Power management
The linux kernel USB driver supports power management. If there is no activity on the USB for a certain time, the port is switched to powersaving which leads to a disconnect of the device (see [3]). Details on
linux power management are found in [4]. In short, you can turn off power management in general if you do
echo -1 >/sys/module/usbcore/parameters/autosuspend
or, for a specific device,
echo on > /sys/bus/usb/devices/DEVICEID/power/level
with DEVICEID substituted by the device's ID.
C. Suggested reading
-------------------------
[1] http://www.mikrocontroller.net/topic/116263
[2] http://www.ti.com/sc/docs/apps/msp/intrface/usb/emitest.pdf
[3] http://forum.soft32.com/linux/solution-usb-disconnect-proble ms-usb-ftopict345989.html
[4] /usr/src/linux/Documentation/usb/power-management.txt
[5] Google group FHZ1000 users on Linux, Message-ID:
[6] Google group FHZ1000 users on Linux, Message-Id: <200812241129.01819.omega@online.de>
[7] Google group FHZ1000 users on Linux, Message-ID: <930a1555-3eda-49ce-82d9-3ecc617f5e9c@a26g2000prf.googlegroups.com>
[8] http://www.reichelt.de/?;ACTION=3;LA=4;GROUP=B522;GROUPID=31 87;ARTICLE=7674;START=0;SORT=preis;OFFSET=1000;SID=26j@QMWaw QARoAAFcmBVM2b30b32eb7a0d90a6833475d294db8c2
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-