TI Announces WiLink 8 Family - WiFi, GNSS, NFC, BT, and FM Combo Chip

15 Comments

View All Comments

• 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 integration

• Kobaljov - 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