Still can't get RTL8188CUS chip going

Has anyone gotten this wifi chip (RTL8188CUS) to work on the BBB?

I’ve posted my full specs here

https://groups.google.com/d/msg/beagleboard/lKjxmSaxR1I/QbNRT1xOkrUJ

I’m beating my head against the wall. I’ve gotten it to connect brieflly (30secs) but then I can’t get it back up. I’m thinking power issues?

I have the dongle plugged in to USB port and I’m supplying the BBB with 5v, 2a via wall wart and micro usb.

I’ll take any answers, even if they’re yelled at me.

–Thomas

I’ve absolutely no experience with that device, but is it poswsible that it could be going to sleep ? 30 seconds seems rather suspect.

It was high on my list of suspects. Any suggestions on trouble shooting?

I know; so very strange. Most recent I had the dongle up for about 30 seconds, but at one point I had it up for 35 minutes (yes, I was timing). Strange, it’s the incosistency that bewilders me.

My B^3 won’t take any of my USB hubs (albeit, they are cheap). This lends me to belief there is a function of the chip the B^3 doesn’t like, which the USB doesn’t translate to the B^3? Does that sound plausible to anyone? This would fit with the going to sleep theory Hermans mentioned.

Are you plugging in the hubs before you apply power to the board?

Gerald

Yes. Tried before boot, after boot, during boot...though, I've not tried when Mars and Venus align. :slight_smile:

Honestly, they are the cheapest hubs eBay has to offer, so I don't blame the Bone or current SW. Though, I'll keep buying cheap peripherals and fiddle on them to get them working. I've more time than money.

http://www.ebay.com/itm/Black-USB-2-0-Hi-Speed-4-Port-Splitter-Hub-For-PC-Notebook-/200838985545?pt=US_USB_Cables_Hubs_Adapters&hash=item2ec2efb749

--Thomas

Debian
http://www.mattwind.com/2013/05/how-to-get-wireless-on-beaglebone-a5.html
Angstrom
http://www.shibuvarkala.com/2013/06/how-to-install-rtl8192cu-based-wifi-on.html

Haven’t tried either - just about to.

I have similar issues with a BBB and a EdiMax EW-7811Un (rtl8192cu). At home, it seems to connect ok, although if you reset the connman settings it can take a few reboots to connect (restarting connman with servicectl panics usually). Note that at home, the BBB is about 6ft from the AP.

However, over the weekend I tried it on a different network and couldn’t get it to connect. It did briefly for a few minutes, but then disassociated. At this site, the BBB is probably 30ft away from the AP, although the AP has a +10db omni antenna and has excellent range.

Mostly, I get the “timed out” errors when trying to associate, occasionally, I see a “reason 2” when it drops the connection. I was thinking power too, I am running the BBB on a 5V 1A supply, I ordered a 2A one from Digikey the other day to see if that helps the issue.

Didn’t work for me :frowning:

Haven’t managed to get it working on Debian OR Arch. Adapters work on the Pi though.

Guys,

I have always experienced some wierdness when using the online recipes for getting wifi working on the BBB. I have three cards, and I’ve seen the exact procedure “sort of” work on one of them, but not the others. I suspect some kind of timing issue with the start-up of wpa_supplicant during card boot-up. I can’t rigorously defend or prove it, but I can tell you what has worked for me and what has not.

With the various procedures on the net, I have experimented with the rtl8192cu, ath9x, and UWN200 dongles. I started with the ath9 dongle before there was real angstrom kernel support, and got it to work intermittently. I moved on to the rtl8192cu, since it was the only really supported chipset at the time. I had intermittent results with that, too. I found that in all cases, if I could get the darn thing to connect, I had to do a manual dhcp initiation also.

Then I made a discovery…

  1. I don’t know what led me to this experiment, but I did a:
    #pgrep wpa
    …then I killed any processes that were displayed.
  2. Then I manually started a new copy of wpa_supplicant:
    #wpa_supplicant -B -Dwext -iwlan0 -c/etc/wpa_supplicant.conf
    …of course, things need to be all well with your wpa_supplicant.conf file!
  3. Next, I did a:
    #wpa_cli status
    …and repeated as necessary, but I found that association would now occur almost immediately!
  4. I have never to this day seen dhcp occur automatically, so I needed to:
    /sbin/udhcpc -iwlan0

…and things worked perfectly every time when I did these MANUAL steps.
I now have a python service that runs and does this for me. I’ve got rock solid rtl8192cu wifi now.

The UWN200 dongles are good product too. I have a card configured as per their process, but I still needed to do the manual stuff (or use the script) with that configuration.
Note that the device is not wan0 with the UWN200 card. It is something else which does not come to mind right now – the point is that the commands will need adjustment for this card.

I’ve seen some interaction with router configuration also. For some reason, TKIP/CCMP configuration was more problematic than TKIP/TKIP. In fact, I thought that going to TKIP/TKIP had fixed things, but that turned out to be a red herring – and the killing and late start of wpa_supplicant has been my go-to strategy.

There is a related thread at:

RTL8192CU WIFI — Actual Progress!

Don

At the end of this thread, there’s a comment from Matthew Witherwax about the Wifi connection failing because the clock isn’t set:

http://beagleboard.org/Community/Forums?place=msg%2Fbeagleboard%2FOWzltk648UE%2Fz1ITy5iY9j0J

(you might have to scroll down, it’s at the end).

Sure enough, I boot my BBB, no wifi. I run the following (after having set my timezone):

date -s "2013-08-26 15:29:12"

And lo-and-behold I get connected!

Maybe it’s just coincidence, perhaps the Wifi is slow to connect after booting, but I’ve tried this several times … and it seems to always work. If I don’t set the date, it doesn’t connect (to be fair, I only gave it about 5 mins).

Could this really be it?

-W.

The issue could very well be related to system time. I found some interaction in my earlier struggles which caused me to add “fixing ntp” ahead of fixing wifi on my board bring-up workflows. BUT, you don’t get time from ntp until the network is running…

The big problem is that for most embedded applications, manually setting the time after each boot is not desirable, and may not even be acceptable. Things just need to come up on their own after power-up. My work-around accomplishes this, though some may think it is kind of crude. I’m still learning too…

Strange – is that some people are using those rtl8192cu dongles, have used the cookbook procedures – and are not having a lick of trouble. I guess they must live right.

Don