Yes, but the Bluetooth High Speed is not mentioned, so maybe it's not a full 4.0 implementation just the Bluetooth Classic and the Bluetooth Low Energy integration
I'm wondering if anybody is working/researching the use of the headphones as a second antenna?
I know that some phones use the headphone's cable as an antenna for FM reception. I wonder what would keep them from doing the same with the Wifi antenna configuration.
I'd also think that some ear piece or an additional antenna I could wear in my clothing and communicates over some distinct channel with the phone could be an interesting alternative for a second antenna to a cell phone. I would not mind having a thick check card sized secondary device in my pocket, that contains a battery and a smart antenna doubling my streams.
Feel free to educate me why those things are ludicrous ;-)
The wavelength difference between frequencies used for WiFi versus FM is why you won't see headphone wires being used for antennas. This and matching different types of headphone wires/lengths back to WiFi chip would create quite the challenge.
Broadcom already ships several SoCs with GLONASS support that are used in smartphones. ST-Ericsson also has a chip that should be in production by now.
In future when you review (or even mention) WiFi equipment, can you give details on what OPTIONAL parts of the spec are supported.
40MHz and the number of spatial streams are the headline numbers, but just as amateurs argue tactics while professionals argue logistics, so people who really understand WiFi know that what really determines your performance is the MAC features --- the PHY numbers mean nothing without MAC support.
Since (for reasons I do not understand) most of the various features that are essential to make an 802.11n device give goodput higher than 802.11g are optional, this is not a small matter. Things like: - EDCA (is that still optional, or is it, in practical terms, everywhere?) - Block acknowledge (ideally without delay). - Aggregation at both the MAC and PHY levels to the maximum allowed size.
Even beyond that it would be nice to know something about how well the various "algorithmic" parts of the spec are supported by various vendors. - Do they make a considered decision (based on recent traffic levels and the size of data to send) whether to use RTS/CTS or do they just always do it? - How do they determine when to change modulation+coding? - Do they intelligently switch between spatial multiplexing and ST-diversity for stations that are at the very edge of the base station's range? - What intelligence are they using to decide between MAC aggregation, PHY aggregation, or both?
Right now basically what we learn from these announcements is: Woohoo we support some spec (where by "support" is possibly meant we do the absolute bare minimum necessary to function on such a network and not damn thing more).
The alternative is we get reviews giving something like goodput numbers. But it is never clear from such reviews if numbers are bad because one or other side of the connection (the mobile device or the base station) simply doesn't support large parts of the spec, or supports it in a half-assed fashion. In other words, if the laptop has worked really hard to support aggregation well (rather than going for something flashier but probably of less value in real life, like 3x3:3) but is paired with a crappy base station than does the bare minimum to support aggregating clients and not a damn thing more, that is unfair in some sense to the laptop.
The only way I see around this sort of issue --- it's not ideal but it's better than nothing --- is for journalists like yourselves to be a lot more hardass about asking vendors EXACTLY which optional parts of the spec they do and don't support, and about the performance of the algorithms they are using. This is especially true (and especially shameful) in the case of aggregation where, as far as I can tell it is simultaneously true that - this is an essential part of the n spec (and the ac spec) to get decent goodput, - yet it is also commonly handled very poorly by many devices, - and no reviewer event comments on it or understand that it is the reason so many devices behave like crap under 802.11n, not some random "wireless sucks and you can't trust the iEEE"
This is a really really good point, and especially with 802.11ac combo chips and as we start talking more with the combo vendors, I intend to ask those kinds of questions. Absolutely :)
It's not that simple though. There's what the silicon does, there's what the baseband processor firmware provided by TI does (that's a binary blob, generally), and then there's what the driver does. Go look at the WiLink 7 drivers for Android and Linux and see just how much of the spec-compliant behavior is implemented on the host side. And a lot of other factors that are actually implemented in the BBP firmware can be pushed out of spec or made to underperform simply by tweaking the wrong control registers in the chip.
So, even if the device vendor provides a reference driver that only does the bare minimum, many practical fielded embedded applications are going to try and improve on that just in order to differentiate. And THAT is why two vendors using the same OS and same chipset can show radically different performance.
We’ve updated our terms. By continuing to use the site and/or by logging into your account, you agree to the Site’s updated Terms of Use and Privacy Policy.
Facebook
Twitter
RSS
15 Comments
Back to Article
Kobaljov - Monday, February 13, 2012 - link
The "Bluetooth technology" is not too informative from technical view, so which version exactly?RU482 - Monday, February 13, 2012 - link
Well, considering it also says Bluetooth Low Energy Technology, I'd say Bluetooth 4.0.Kobaljov - Monday, February 13, 2012 - link
Yes, but the Bluetooth High Speed is not mentioned, so maybe it's not a full 4.0 implementation just the Bluetooth Classic and the Bluetooth Low Energy integrationKobaljov - Monday, February 13, 2012 - link
4.0, in the source's detailed spec it is written (but why just there?)Brian Klug - Monday, February 13, 2012 - link
It's Bluetooth 4.0-Brian
Conficio - Monday, February 13, 2012 - link
I'm wondering if anybody is working/researching the use of the headphones as a second antenna?I know that some phones use the headphone's cable as an antenna for FM reception. I wonder what would keep them from doing the same with the Wifi antenna configuration.
I'd also think that some ear piece or an additional antenna I could wear in my clothing and communicates over some distinct channel with the phone could be an interesting alternative for a second antenna to a cell phone. I would not mind having a thick check card sized secondary device in my pocket, that contains a battery and a smart antenna doubling my streams.
Feel free to educate me why those things are ludicrous ;-)
Gorgonesh - Monday, February 13, 2012 - link
The wavelength difference between frequencies used for WiFi versus FM is why you won't see headphone wires being used for antennas. This and matching different types of headphone wires/lengths back to WiFi chip would create quite the challenge.AndreMalm - Monday, February 13, 2012 - link
Broadcom already ships several SoCs with GLONASS support that are used in smartphones. ST-Ericsson also has a chip that should be in production by now.name99 - Monday, February 13, 2012 - link
Hi Brian,In future when you review (or even mention) WiFi equipment, can you give details on what OPTIONAL parts of the spec are supported.
40MHz and the number of spatial streams are the headline numbers, but just as amateurs argue tactics while professionals argue logistics, so people who really understand WiFi know that what really determines your performance is the MAC features --- the PHY numbers mean nothing without MAC support.
Since (for reasons I do not understand) most of the various features that are essential to make an 802.11n device give goodput higher than 802.11g are optional, this is not a small matter. Things like:
- EDCA (is that still optional, or is it, in practical terms, everywhere?)
- Block acknowledge (ideally without delay).
- Aggregation at both the MAC and PHY levels to the maximum allowed size.
Even beyond that it would be nice to know something about how well the various "algorithmic" parts of the spec are supported by various vendors.
- Do they make a considered decision (based on recent traffic levels and the size of data to send) whether to use RTS/CTS or do they just always do it?
- How do they determine when to change modulation+coding?
- Do they intelligently switch between spatial multiplexing and ST-diversity for stations that are at the very edge of the base station's range?
- What intelligence are they using to decide between MAC aggregation, PHY aggregation, or both?
Right now basically what we learn from these announcements is:
Woohoo we support some spec (where by "support" is possibly meant we do the absolute bare minimum necessary to function on such a network and not damn thing more).
The alternative is we get reviews giving something like goodput numbers. But it is never clear from such reviews if numbers are bad because one or other side of the connection (the mobile device or the base station) simply doesn't support large parts of the spec, or supports it in a half-assed fashion. In other words, if the laptop has worked really hard to support aggregation well (rather than going for something flashier but probably of less value in real life, like 3x3:3) but is paired with a crappy base station than does the bare minimum to support aggregating clients and not a damn thing more, that is unfair in some sense to the laptop.
The only way I see around this sort of issue --- it's not ideal but it's better than nothing --- is for journalists like yourselves to be a lot more hardass about asking vendors EXACTLY which optional parts of the spec they do and don't support, and about the performance of the algorithms they are using. This is especially true (and especially shameful) in the case of aggregation where, as far as I can tell it is simultaneously true that
- this is an essential part of the n spec (and the ac spec) to get decent goodput,
- yet it is also commonly handled very poorly by many devices,
- and no reviewer event comments on it or understand that it is the reason so many devices behave like crap under 802.11n, not some random "wireless sucks and you can't trust the iEEE"
Brian Klug - Thursday, June 14, 2012 - link
This is a really really good point, and especially with 802.11ac combo chips and as we start talking more with the combo vendors, I intend to ask those kinds of questions. Absolutely :)-Brian
larwe - Friday, April 18, 2014 - link
It's not that simple though. There's what the silicon does, there's what the baseband processor firmware provided by TI does (that's a binary blob, generally), and then there's what the driver does. Go look at the WiLink 7 drivers for Android and Linux and see just how much of the spec-compliant behavior is implemented on the host side. And a lot of other factors that are actually implemented in the BBP firmware can be pushed out of spec or made to underperform simply by tweaking the wrong control registers in the chip.So, even if the device vendor provides a reference driver that only does the bare minimum, many practical fielded embedded applications are going to try and improve on that just in order to differentiate. And THAT is why two vendors using the same OS and same chipset can show radically different performance.
jmcb - Monday, February 13, 2012 - link
So THATS where my FM Radio went...lol.I never realized how much I liked it until I went from a Droid X1 to a RAZR....
Devo2007 - Monday, February 13, 2012 - link
Same. It's a shame that even though the processor supports it, companies still don't always offer support for it (Galaxy Nexus, for example).BadCommand - Tuesday, February 14, 2012 - link
Would like to see WiDi included as well.hingfingg - Thursday, February 16, 2012 - link
** {{w w w }} {{proxy4biz }} {{ com}} *****