Bluetooth Low Energy / BLE chipsets continue to evolve, with vendors constantly releasing new devices. We want to share some of the top trends we’ve seen in the chipsets that we’ve seen from vendor announcements, customer needs and our own experience developing products.
Here are the top 5 trends in BLE chipsets you should know are happening:
[NOTE] Last Update: May 2, 2015
We’re updating this article as some vendors release updated figures for their parts, and other changes from vendors.
Many of the BLE SoCs announced have reduced power consumption. A couple years ago, the best you could find were devices that drew around 15mA to 20mA. Today, most parts offered are in the 5mA to 8mA range. Here is the power consumption of a few recently announced parts:
| Part | Current RX/TX (0dBm) | Year Released |
| Texas Instruments CC2640 | 5.9mA/6.1mA | 2015 |
| Nordic Semiconductor nRF52832 | 5.0mA / 4.6mA | 2015 |
| Freescale KW40Z | 6.5 mA / 8.4 mA | 2015 |
| Silicon Labs Blue Gecko | 7.5mA / 8.3mA | 2015 |
| Cypress PSoC 4 BLE | 15.6mA / 16.4mA | 2014 |
Note: We have revised the nRF52832 Power consumption numbers after an update from Nordic Semi that their power consumption is lower than initially reported.
In general, power consumption has gone down by about 40% to 60%, which means that products run twice as long from the same battery (all other things being equal). The smaller current peaks also means battery is less stressed (and effective capacity is larger).
Cypress is still catching up to the rest of the pack as far as power consumption is concerned. We have not accounted for Dialog semiconductor with their 3.9mA current above because their device has no Flash memory.
Vendors are constantly improving the RF performance of their devices. Better RF means better range, which is important in almost all applications. The two big parameters to note are the Transmit Power and the Receive Sensitivity. The first tells you how strong you can transmit, the second how low the signal can be before you can’t get any data. Good RF performance can be a difficult thing to get right, and even the right chip won’t guarantee it. But, if you do your job (or get help from us to do it right), your range will be better.
Here’s a summary of the performance for some of the latest and top chipsets:
| Part | TX Power | Receive Sensitivity | Year Released |
| Texas Instruments CC2640 | +5dBm | -97dBm | 2015 |
| Nordic Semiconductor nRF52832 | +4dBm | -96 dBm | 2015 |
| Freescale KW40Z | +5dBm | -91 dBm | 2015 |
| Silicon Labs Blue Gecko | +10dBm | -95dBm | 2015 |
| Cypress PSoC 4 BLE | +3dBm | -92dBm | 2014 |
| TI CC2540/CC2541 | +4dBm | -89dBm/ –94 dBm | 2010/2011 |
| nRF51822 | +4dBm | -93dBm | 2012 |
| CSR CSR101x | +7.5dBm | -92.5dBm | - |
TI and Nordic have both increased their sensitivity by about 3-4 dB. Note that most power outputs are limited to +5dBm or less. Silicon Labs has a long history of Radio integration and are able to reach to 10dBm in their device. This is very helpful in applications where the BLE sensors are located far away, for example.
It’s possible to add a front end chip to most of these devices which will amplify the RF signal, but only the power output will increase. Unless the device specifically supports an RF switch capability (CC2540/CC2541), you’ll gain TX power but lose a little in receive sensitivity.
Both of these parameters give you range, but increasing the output power (and sometimes sensitivity) also increases current consumption. Most of the numbers quoted above are for 0dBm and will be higher for +5dBm or +10dBm.
By the way, +10dBm is the practical limit due to ETSI regulations.
Single Chip BLE SoCs have always had limited processing capabilities. The first couple generations of devices used the main processor for running the BLE Stack and the user application. This is still the case but is shifting towards isolating the BLE stack separately to give developers more breathing room.
Most processors in the first generations were older architectures, with ARM Cortex cores taking over almost completely as you can see below:
| Part | CPU Core | Year Released |
| Texas Instruments CC2640 | Cortex-M3 | 2015 |
| Nordic Semiconductor nRF52832 | Cortex-M4F | 2015 |
| Freescale KW40Z | Cortex-M0+ | 2015 |
| Silicon Labs Blue Gecko | Cortex-M3/M4F | 2015 |
| Cypress PSoC 4 BLE | Cortex-M0 | 2014 |
| TI CC2540/CC2541 | 8051 | 2010/2011 |
| nRF51822 | Cortex-M0 | 2012 |
| CSR CSR101x | Proprietary 16-bit | - |
M4F denotes Cortex-M4 with a Floating Point unit.
Older architectures include 8051 and proprietary processors. Most vendors provide a Cortex-M core that customers love because it is becoming standard in the industry.
The Cortex-M0 is a relatively limited processor. It’s designed for low power and it’s great for collecting sensor data, but not that good at processing it with algorithms. When you have a BLE stack using the same Cortex-M0 or 8051, you’re limited at how fast you can process data. Some peripherals may also not be available.
Most vendors are looking to capture the wearable market which requires more processing on board, along with a small form factor. The solution is a SoC with more power processor and BLE. As you can see, TI, Nordic and Silicon Labs have all moved from 8051 or Cortex-M0 cores to the more powerful Cortex-M3 and Cortex-M4 cores, including Floating point support for these processing intensive applications.
There’s a big increase in the number of peripherals in the SoCs including more communication peripherals, low power sensor peripherals and a lot of Analog.
Vendors initially offered 64kB and 128kB parts as they were the cheapest parts that could fit the BLE stack. BLE stacks typically take about 70kB to 90kB of space, so this left very little to the user application. As BLE applications evolved, processors had to do more and more processing, so they needed more code and more RAM. Chip Manufacturers began introducing 256kB parts. Recently, Nordic introduced their nRF52832 device with 512kB of Flash which is the largest device as far as we know. We expect other vendors to follow suit soon.
RAM capacity is similar. 16kB is very limiting in all but the most basic applications, so parts with large memory 20kB, 32kB, and 64kB are appearing.
The user’s application is not the only reason for more space. The features in Bluetooth Low Energy have increased. Many products need to use both Peripheral + Central role combination which together take a lot of space. The same happens when running multiple protocols at the same time, like BLE and Zigbee. IPv6 support also makes large RAM a necessity.
The Flash and RAM numbers below are total and don’t take into account the amount of memory used by the stack, but you can see that the companies are upgrading their devices:
| Part | Flash | RAM |
| Texas Instruments CC2640 | 128kB | 20kB |
| Nordic Semiconductor nRF52832 | 512kB | 64kB |
| Freescale KW40Z | 160kB | 20kB |
| Silicon Labs Blue Gecko | 256kB | 32kB |
| Cypress PSoC 4 BLE | 128kB, 256kB | 32kB |
| TI CC2540/CC2541 | 128kB, 256kB | 8kB |
| nRF51822 | 128kB, 256kB | 16kB, 32kB |
Flash and RAM take significant space on the die, so to keep cost low vendors must continue to use smaller and smaller processes.
Freescale recently released the KW40Z part, and although it has its limitations as far as power and Flash/RAM, it does support Thread along BLE. Texas Instruments has the CC2650 which supports BLE, Zigbee, 6LoWPAN and RF4CE. Nordic has devices supporting BLE and ANT. Some of these parts support proprietary 2.4GHz protocols as well. Obviously, vendors are leveraging the fact that the radio layer in many of these devices are similar, and the only significant change is in the software.
BLE is one of the most if not the most popular connectivity protocol, but it isn’t the only one. Because it doesn’t officially have any Mesh capability, Zigbee (and by extension Thread) are still contenders for connecting products. It may be that no protocol completely takes over the ecosystem. After all, there are already some legacy systems, and each protocol has its own strengths. Customers developing products want to futureproof their design and integrate with Nest’s ecosystem using Thread, making multiprotocol parts more appealing.
A part supporting multiple protocols is better than two separate parts. This is true due to cost, but also to coexistence. Coexistence is the ability of the radio to help the two protocols to “coexist” by ensuring that the protocols do not collide and interfere with each other. Interference causes lost packets which means more current consumption since the devices have to retransmit the data.
Here are the protocols supported by various devices:
| Part | Protocol Support |
| Texas Instruments CC2650 | BLE, Zigbee, RF4CE, 6LoWPAN |
| Nordic Semiconductor nRF52832 | BLE, ANT, 2.4GHz Proprietary, NFC |
| Freescale KW40Z | BLE, Thread |
| Silicon Labs Blue Gecko | BLE |
| Cypress PSoC 4 BLE | BLE |
| TI CC2540/CC2541 | BLE, |
| nRF51822 | BLE, ANT, 2.4GHz Proprietary |
| CSR CSR101x | BLE |
TI and Nordic lead the pack, with Freescale recently joining them. Expect more vendors to add support for various protocols, at least until one begins to dominate.
Enter your email address to subscribe to this blog and receive notifications of new posts by email.
