I’ve been frustrated by the difficulty in getting reliable USB wifi up and running on the bone. There have been a quite a few threads where people have reported similar problems, but I also get the impression that others haven’t experienced my difficulties.
In particular I reference this thread, which talks about the need to use an extension cable when using a wifi dongle. Can someone comment as to whether Nonoo’s observations have merit?
I have found that my connections are much more reliable if I use a cable that’s a foot or longer. If I connect the dongle directly to the bone it either doesn’t register at all, causes a kernel panic or just refuses to connect. If I use a six inch extension cable it won’t connect for five minutes or more, and I see the following in dmesg:
[ 61.986000] wlan0: authenticated
[ 62.002037] wlan0: associated
[ 62.002238] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 66.002533] wlan0: disassociating from xx:xx:xx:xx:xx:xx by local choice (reason=3)
[ 66.059657] wlan0: deauthenticating from xx:xx:xx:xx:xx:xx by local choice (reason=3)
[ 430.043698] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 431.772858] wlan0: authenticated
[ 431.807408] wlan0: associated
I’m currently using dongle with an rtl8192cu chipset. It’s only when I use an extension cable of a foot or more that I get anything approaching reliability, although it still isn’t reliable enough for me to count on. One suggestion was to investigate whether I have a power supply or ground loop problem, which I will follow through on. If that fixes things for me I’ll report back. In the meantime I’d love to hear if there’s an acknowledged problem with USB on the bone.
I have seen where short cable, 6", helps the connection on some WIFI devices. This is not the case on all of them.
We have not determined exactly why this makes a differences, it is only six inches in length, It is not adding that much capacitance nor resistance. It may be an impedance issue of some sort.
Gerald - thanks for your response. I have found that six inches doesn’t quite do the job for me, and longer cables still don’t completely solve the problem. Were any steps taken in the boneblack design to mitigate this issue? Can we expect the same behavior with this board?
We changed the routing, added a Ferrite bead filter on the power, and upgraded the processor to a different revision. There was an errata on the USB that was fixed. I do not know if that is related to this issue, but it may be. We will have to see how it holds up.
The USB system does indeed seem to have some issues.
I had the opposite problem. When I connected an Alpha 8187 series WiFi dongle to a cable I would get all kinds of spurious interrupts.
When I connected it directly to the Bone the interrupts went away.
To be concise, there is a MIL connector on the cable to the Alpha and the mating four pin version on the chassis.
So the ground/shield may not be continuous. The next rev of the hardware uses a hub to connect to the Alpha, so I will post
the results to the list …
On what revision of the board was that ?
I notice that my hub has the ferrite beads …
Ian - Thanks for the suggestion - I will give that a try!
I don’t have better news to report about getting reliable USB WiFi running on the bone. I tried Ian’s suggestion to solder a cap across the USB supply pins, and while that did improve things somewhat, I still have dodgy WiFi connections. I have tried many different Angstrom versions, including the latest 3.8.8 kernel. I am still unable to get a connection if the dongle is connected directly to the USB port, and the kernel generally crashes after a while. Things are slightly better if I use an extension cable. The kernel doesn’t crash, and my WiFi connection will stay up for several minutes working well until the connection gets jittery and I see the following in the dmesg log:
[ 958.954772] lun0: unload attempt prevented
[ 958.954832] gadget: sending command-failure status
At this point I don’t know what to conclude except that there is a serious problem with USB on the bone. I really hope this is fixed in BeagleBone Black, since I’ll be looking for other hardware alternatives if it isn’t.
Ian, in case you’re wondering I tried using this capacitor (datasheet). Someone who knows more about hardware design than I do can perhaps comment if that was a appropriate capacitor.
Do you think these hardware changes to usb host on the BBB will fix the timeout problems encountered when interfacing USB webcams? If I remember correctly It was a problem with isochronous USB transfers used to run UVC compliant cameras. Could this spiking be the culprit and put an end to these partial symtom treating workarounds https://groups.google.com/forum/?fromgroups=#!topic/beagleboard/sgCwaP5RVUo?
Maybe. maybe not. The more likely benefit with this could be from using a newer version of the processor where some USB issues were fixed…