802.11n and CC3000 - isn't this a big issue?

Hardware
1

OK - I completely acknowledge that it clearly states the CC3000 works on 802.11b/g only in both:

But I’d missed this. It was only when playing with my CC3000 device that I noticed that I could configure it fine from my old Linux laptop but not from my newer Macbook Air - the difference being one was connected to my AP using 802.11g and the other with 802.11n.

If I switch my AP to support only 802.11g then both the Linux and Mac laptops play well with the CC3000 (it was easy to switch off 802.11n in my AP, I didn’t find an obvious way to just force my Mac to 802.11g).

So even though this was clearly stated is it not a serious limitation?

802.11n has been around since at least 2009 (many manufacturers we’re producing APs before the standard was finalized in Oct 2009) and it’s been supported in iPhones since the iPhone 4 was released in Jun 2010.

So there are a lot of devices (smartphones, laptops, etc.) that are connected using 802.11n to their APs.

Is this not a serious issue for any device that targets non-tech savy end users? It seems a serious proportion will be unable to configure their devices - or am I missing something?

I think most consumers just about know what wifi is - but even if you stuck a massive sticker on your device saying “802.11b/g only” I don’t think it would mean much to many people.

I don’t know if Android or iOS provide an easy mechanism to force the current wifi connection to a particular variant of 802.11 but I certainly don’t see any obvious way to do this in a standard way on desktop OSes (e.g. Mac OS X, Windows or Linux).

At the moment the limitation that it does not support 802.11n would seem to me to limit the CC3000 to a more tech savvy market segment, i.e. one that will be a bit stoical when they notice that they really should have read the data sheet for once when they work out why the device isn’t getting it’s configuration data.

Note: my current CC3000 device isn’t a Spark Core rather it’s an Adafruit CC3000 breakout board, but I value the quality of the discussion here :slight_smile:

/George

2

@ghawkins all very good thoughts and questions. The CC3000 does work with most 802.11n networks without putting them in 802.11g only; we’ve done so on a number of networks without any problem. What router are you using? It may be an issue with your particular router, or a particular set of routers. That’s not to say it’s not a problem - if it affects any group of people, it will cause tech support challenges - but hopefully it’s at least a relatively limited one.

Also, you said that it was configuration that wasn’t working; how are you configuring the CC3000? Are you talking about using Smart Config through TI’s Java Smart Config app?

3

Sorry @zach - I probably wasn’t clear enough.

My problem isn’t at all with the CC3000 working with an AP that supports 802.11b/g/n.

It’s the initial SmartConfig phase.

If the device that I use to specify the SSID, password etc. is using 802.11n rather than b or g then the CC3000 will not pick up the configuration data.

In my posting above I just forced my AP into b/g mode only because I couldn’t find an easy way to just force my Mac to use b or g rather than n. And I was using running the SmartConfig client from my Mac.

If the device running the SmartConfig client is using b or g then the CC3000, once it has received the setup data, happily connects to an AP that supports b/g/n.

If you look at what the CC3000 is doing then it’s kind of obvious that the machine running the SmartConfig client has to use a variant of 802.11 that the CC3000 understands (the CC3000 effectively goes into monitor mode and looks out for packets containing the configuration data - encryption and other factors mean there’s a lot more involved on top of this).

Note: I’ve actually written my own Java SmartConfig client using the TI SmartConfig library as the the TI applet based one is pretty terrible. My client works fine if the machine running it is connected to the AP using b or g, I’ve tested on Ubuntu 12.04 , Mac OS X Mountain Lion and Windows 8. I will post the client code to github at some stage as it’s really far nicer IMHO to use than the applet version.

4

I have the following:

  • A Linux laptop that can definitely only talk b or g.
  • A Macbook Air and a 1st generation iPad that can talk b, g or n.

I’m using OpenWrt on my AP. From the CLI on the AP I can’t work out how to directly see which 802.11 protocol each is actually using, but I can see from the TX/RX rates that the iPad and the Macbook can achieve TX/RX rates higher than 54 MBit/s so I guess that means both of them really are using n.

However if I run the iOS SmartConfig client on the iPad the CC3000 device will pick up the configuration data. However if I run the SmartConfig client on the Macbook then the CC3000 device will only pick this up if I force the Mac to use b or g (at the moment I do this by flipping the whole AP to just accept b or g connections).

So why should things work differently between for the iPad and Macbook when both are on n?

I don’t know enough about the differences between 802.11 g and n to know if it’s possible for n traffic to look similar to g traffic under certain circumstances (I know in mixed mode n traffic is embedded in an 802.11g transmission) and somehow the iPad traffic looks OK but the Macbook traffic somehow looks different.

In short the Linux laptop, that can only talk b or g, can be used to run the SmartConfig client without issue, as can the iPad even if it’s connected to the AP using n, but if the SmartConfig client is run on the Macbook Air the setup will only succeed if I force the connection between the Macbook and the AP to be b or g, not n.

5

Sorry -- just joining in. I think we have a similar setup here we can test, an access point running OpenWRT that we can pop into 'n'. I'll check that out over the weekend and see what I can find out.

It's possible the CC3000 isn't seeing the transmissions over 802.11n in the 5Ghz range, but there might be a workaround.

6

@Dave In short, you rock. You of course don't have to, but if you do come in this weekend, you have my sincerest and humblest appreciation.

That's dedication, people.

@ghawkins Thanks for the feedback; it's great to hear that TI's iOS app works correctly over 802.11n.

If you could do the following, it would be super helpful. Since SmartConfig is successful over 802.11n when you use TI's iOS app but not when you use your Java app on the MacBook, please try TI's Java applet on the MacBook and let us know whether you see the same behavior.

Agreed their Java applet isn't the best. :smile: You, however, are the best! I can't wait to see your SmartConfig Java client code!

As promised during Kickstarter, our iOS and Android apps will be open source as well. With you making and sharing a Java app that everyone can use on their computers (including on Linux!) that means even more people will have Free & Open Source solutions for setting up their Spark Cores! I know this excites the whole Spark team, so THANK YOU! :thumbsup:

Keep passing test results our way, and the more you can help out other folks asking questions here in the Spark Community the better! We really appreciate it!

7

I’ve disabled the 5MHz radio on my AP so it isn’t a 5MHz issue.

@zachary - you guys are so positive - I really hope Spark Core is a super success for you :smile:

I’m not really sure everyone will be happy with an open source implementation of the client as it becomes extremely obvious how easy it is for a 3rd party to recover the transmitted passwords if you’re not using AES (something I discussed before on these forums - but didn’t go into in detail).

I’m going to be pretty cautious about posting my Java client - I’ll post some initial code, without the password encoding (note I say encoding, not encryption) mechanism, then some discussion of the idea behind the encoding and see what reaction that gets before going further.

8

I’ve tested with the TI Java applet and get the same behavior as with my app, i.e. the CC3000 only gets successfully setup if I force the Macbook Air not to use n with the AP before running the SmartConfig client :frowning:

9

@ghawkins, what is the make and model of your AP? All 11n AP can be configured to run in mixed mode - i.e. combination of 802.11g and 11n clients (down side is slower speed for the 11n clients).

@zach Any roadmap on where next for SparkCore? 11n ?

10

@pko - I’m using a Netgear NDR3700v2 running OpenWrt 12.09.

It’s very important to be clear here and I’m sorry if I wasn’t in my original post.

There is no problem with running a CC3000 with a mixed mode (i.e. b/g/n) AP.

The problem I’m seeing is during the initial setup phase, i.e. when using the Smart Config setup application to communicate the AP SSID and password to the CC3000.

If I run the TI Java applet Smart Config application on a Macbook Air - then the CC3000 will only pickup the setup data if the machine running the Smart Config application is using one of the 802.11 variants that the CC3000 understands, i.e. b or g.

In my previous posts I’ve mentioned switching my AP to b/g mode only in order to force my Macbook Air to use g, and not due to any issue with the CC3000, once configured, working with a mixed mode AP. If you look on StackOverflow etc. it seems there’s no easy way to force a Mac to use g if n is available.

The odd thing now, and what @Dave says he will look at, is that this only seems to be an issue for the TI applet client (and an open source client I’m developing). If I run the iOS client on my iPad, apparently connected to my AP using n, then the CC3000 enabled device does pick up the setup data.

Unfortunately at the moment I do not have another machine with n support capable of running wireshark (I have an old Linux laptop in addition to my Macbook Air, but it only supports b/g). I will try to borrow another machine so I can use wireshark to compare the setup traffic from my iPad with that from my Macbook Air when both are connected to my AP using n.

To me it’s actual surprising (and obviously good for CC3000 owners) that the CC3000 can pickup setup data when the device, e.g. my iPad, running the Smart Config application is connected to the AP using n.

This is because the CC3000 picks up the setup data by going into monitor mode and looking out for the setup packets as they are broadcast by the client application. Note: the clever thing is that the CC3000 can do this even though the packets contain the WEP/WPA/WPA2 passphrase that the CC3000 does not yet have and would need if it wanted to decrypt the packets. How this is all done is clever and at the same time surprisingly simple - I will discuss this in a latter post.

PS @pko - I don’t think 802.11n for the CC3000 in day-to-day operation is that important - is a CC3000 enabled device really that likely to want more than the 54Mbs available using g?

11

Hey All,

I spent some time looking into Smart Config this weekend, I think I found some good insights on what might be going on, but I wanted to fact check it with the team here, in case I got something wrong. :slight_smile: These guys know a lot more about Smart Config than I do, so that’s a safer bet. It’s possible this has something to do with minimum MTU’s, or MIMO on the Macbook Air, but I’d need to know what version Air it is. I’ll try to get my hands on an Air here and see if we can test it more fully. Details to follow!

Thanks,
David

12

@ghawkins Yes, it is not very likely that we need high speed for the SparkCore. It is more the inconvenient of either to run a separate 11g only access point for the SparkCore, or use a 11n access point in mixed mode and accept the speed degradation to all the 11n devices. The degradation may be an issue when I started to stream full HD video across the wifi network - will try to do some test once I can get my hand on a few Spark Core.

13

@pko - it’s a very widespread belief that mixed mode imposes a high cost in terms of speed (for devices capable of using 11n when sharing an AP with devices that use say 11g) but I think that this is in fact just a remarkably persistent urban legend.

I’ve seen the speed degradation claim many times and seen it rebutted almost as often.

Unfortunately I can’t find any great reference, this superuser.com answer backs up what I’m saying but doesn’t quote any definitive sources:

Hopefully someone else can find a better link?

14

@Dave - yes I was wondering about MIMO, I presume something like a Macbook Air does have the multiple antennas needed for this while an iPad does not (although my iPad seems to be able to hit speeds of more than 54Mbs and I thought most of the speed increase between 11g and 11n was down to MIMO, so this may imply I’m wrong).

I don’t know how you’d confirm this was the issue though? I don’t think it’s something that would be visible via wireshark and I’d be surprised if it’s easy to disable MIMO directly, while still using 11n, or to do it indirectly by somehow disabling all but one of the antennas.

I was thinking of getting a little 802.11b/g/n USB dongle, which presumably doesn’t have multiple antennas (and so can’t do MIMO) and seeing if I could force my Macbook Air to use that in preference to it’s inbuilt wifi and see how that affected things.

As to MTU - I don’t think this can be the issue - some of the clever stuff going on in the Smart Config logic depends on a minimum MTU of 1500 so I’d already checked this. But double checking is always good.

Edit 1: I just tried setting htmode to ‘HT20’ for the radio that I’m using on my AP in the OpenWRT /etc/config/wireless settings - which I thought might in effect disable MIMO but it didn’t affect the behavior I’ve been seeing (and may have nothing to do with MIMO - it’s not entirely clear to me what changing htmode will achieve from a MIMO perspective).

Edit 2: And it seems that even the tiniest USB wifi dongles (e.g. the ASUS USB-N10) have at least 2 antennas so that doesn’t seem to be a way to avoid MIMO while still using 11n - which also makes me doubtful that even 1st generation iPads don’t also have multiple antennas and so use MIMO (but maybe I’ve got this whole MIMO thing all confused?).

15

Hey ghawkins,

Thanks for posting your progress thus far, here is some of what I found:

The Smart Config process can go awry for a variety of reasons. Network-wise: you can get signal fragmentation (MIMO, etc.) or IP fragmentation (MTU, etc.). Firmware-wise: TI periodically releases updates for the CC3000 that always come in pairs—the host driver source code to include in firmware, and a patch programmer application for upgrading drivers on a the module itself. These two items must be kept in sync. TI is in the process now of releasing 1.11.1. The new Cores we’re shipping are patched with the latest updates, but it would make sense to check the service pack version of your CC3000 if you’re using a development board.

More info about host driver / CC3000 driver versions in the release notes:
http://processors.wiki.ti.com/index.php/CC3000_Release_Notes

If you’re working on building your own Smart Config app, TI has a wiki page here:
http://processors.wiki.ti.com/index.php/Smart_Config_Application_development_information_-_Java_Applet

There is also some discussion of newer / older smart config software here:
http://e2e.ti.com/support/low_power_rf/f/851/t/282218.aspx

I’m really interested to see what happens with the TI’s Java version of the Smart Config app. I had some trouble here getting the current version to work on my windows box, so I wonder if they’re not working on an updated version. If you’re in a hurry, the best bet here might be to go to the source and check on their forums. It sounds like you have enough data (wireshark captures, etc) and a repeatable test case, you could try opening a ticket on TI’s E2E community. http://e2e.ti.com/ The SimpleLink forum is also very active: http://e2e.ti.com/support/low_power_rf/f/851.aspx

Thanks for working on this, please let us know if the TI E2E community leads you to any answers. Fortunately the iOS and Android setup experiences have proven themselves to be solid. Every day closer to delivery we get more excited here at Spark! We can’t wait to see what everyone will build!

16

Hi @Dave - thanks for the feedback about firmware etc.

I’ve spent way too long looking at what’s going on in the TI Smart Config Java library :smile:

I’m planning to post a lot of information on what exactly it’s doing in the next week or so.

I have written my own much cleaner implementation.

However while doing so I looked at the bytecode of the original TI implementation.

I think it would be nice if someone could do a clean room reimplementation based off a description of what it does rather than how it’s actually done in TI’s particular implementation.

To that end I’ll write up the behavior in the form of requirements for an implementation and provide tools to test any given implementation.

Reimplementing the core of the TI library is extremely simple - my implementation is around 200 lines of code.

The bulk of the TI implementation is not taken up with the transmitting of the SSID etc. or detecting that the device has connected to the network - it is taken up with the OS specific calls needed to retrieve SSID, default gateway and a few other similar network related values. But even this just takes up space - it’s actually extremely simple stuff for anyone who has minimal CLI networking experience on a given platform and can use Google.

E.g. my implementation of this logic for Mac OS X just takes up 50 lines - TI’s implementation for Windows and Linux is much larger but this reflects (please forgive me TI developers) inexperience with Java more than anything else.

17

Question 1 - does anyone know what the SmartConfig iOS app red-button that needs to be check-marked actually does? Does it truly need to be checked (just curious)?

I’m having a heck of a time getting my beta Core connecting at all now (it did a few weeks ago but now no matter what I do, no such luck)… I was thinking the my iPhone was connecting on n and forced the Belkin ap to b (only) and still no luck … but you guys seem to think connecting on n on the iPhone has no bearing on connecting the CC on a or g… sigh … the troubleshooting continues.

What I’d really like is a better iOS app that actually shows what the heck is going on - ditto on the Core.

Question 2 - I put the Core in config mode (LED1/2 alternating = left most LEDs with USB at the top) … start the SmartConfig app … LED1 goes dark … LED2 continues to flash. So I gather this means that WIFI is not connecting (doh - why? SSID? abgn? pwd? device id wrong?) and LED2 flashing means the Core is still looking for the Spark cloud even tho there is no WIFI — Have I got that correct?

18

Hey @dbm - yes the checkmark needs to be checked, and that text box needs to have the content “sparkdevices2013”. This enables AES encryption of your Wi-Fi credentials.

I’m guessing either it’s not working because of the above, or you’re facing one of two issues that we’ve fixed in more recent firmware updates. They are:

  1. There was an issue with DHCP not being cleared correctly, which was fixed about two weeks ago
  2. There was a bug in TI’s firmware that kept the Core from connecting to networks with a 10.X.X.X subnet. This has been fixed but requires running the patch programmer, which can only be installed with a JTAG programmer at the moment, and not over USB.

If you’re interested in re-programming to upgrade to more recent firmware releases we can probably help you work through these issues, or your fresh Cores coming in early November will have the latest and greatest!

19

thanks @zach - understood on the checkbox … I always checked it but wondered why. Maybe I should try without WPA and see that happens (ie open).

My Core did work … so it’s a mystery what happened … when I find out it will be obvious no doubt (haha). I’m not JTAG equipped so I’ll tough it out… and I’m almost at the point where I can build and bypass all the CC3000 config stuff.

On 2 - interesting since that’s all [some ? most ?] of the AirPorts on 10.x.x.x and that would explain that.

You say the CC3000 were tough to line up (lead time) in volume … is that because they are in demand (good) or because there are at the end of production and TI moves to a revised module? Mouser has some stock …

20

Difficult to line up because it’s a very new component, and there aren’t yet a lot of people buying them in large quantities. Mouser has a few hundred, but we needed 13,000 :wink:

1 Like