Today’s Bluetooth microcontrollers are tiny marvels of integration. Optimized for even the most space-constrained embedded designs, they pack in a CPU, memory resources and peripherals, along with the necessary elements for radio functionality. But Bluetooth MCUs come in a dizzying array of variants – or shades of blue, if you will – and that can make it hard to know where to begin when making a selection.
To help narrow the options and find the right shade of blue for your design, it’s useful to think about two different categories of parameters: device functionality and radio performance. Let’s take a closer look at each.
This covers what the Bluetooth MCU can and cannot do. The key differences to consider are the Bluetooth version supported, the use of proprietary protocols and the MCU’s connectivity resources.
Within each version of the Bluetooth SIG’s standard, there are mandatory and optional features. The mandatory features ensure certified devices meet a minimal set of functionality, while optional features are, as the name implies, features that can be included to help do things like improve power consumption, extend range or support new use cases. There are, for example, optional features for long-range connectivity, direction finding and advertising extensions. It’s important to note that most optional features only work when they’re present on both sides of the wireless connection. To understand which optional features are available for a given MCU, it helps to take a closer look at the product specs. In the current NXP portfolio, for example, we have Bluetooth MCUs the implement versions 4.2 to 5.0. The KW38 is a Bluetooth 5.0 device that supports all the optional features for 5.0, including long range (this video shows you how it works).
A number of Bluetooth products let you access and control the radio, so you can support proprietary receive and transmit scenarios. This is helpful if you want to communicate in specific bands that offer lower latency and lower power. These proprietary Rx/Tx scenarios aren’t covered by standards, so it may be difficult to know what supporting the protocol entails. NXP’s KW family and the QN908x supplement the Bluetooth stack software with a separate, generic Frequency-Shift Keying (FSK) link layer. A set of software APIs, validated with the product, simplifies the task of developing a proprietary protocol.
Several parameters fall into this category, but the most common are the number of peripherals the device can support, the size of the acceptance or paired device list, and the number of resolvable private addresses. In general, Bluetooth MCUs with more compute performance provide more connection resources. The simplest devices typically support up to three connections. NXP’s Bluetooth MCUs support from eight to 16 devices across the portfolio.
This category covers how well a given Bluetooth MCU performs radio-related functions. The key characteristics to consider are receiver sensitivity, transmitter output power and transmitter/receiver power consumption.
This measures how strong the signal needs to be for the Bluetooth MCU to detect and process data coming over the air. It’s a general indication of how robust the performance will be in challenging environments, and the range supported. The more sensitive the device, the longer the range. Rx sensitivity is typically given with a particular modulation and bit rate, such as 1 Mbps for Bluetooth Low Energy (LE). Note that sensitivity measurements use a logarithmic scale, so small differences can have an impact on performance. For example, ratings can range from -93 dBm to -98 dBm, which is more than twice as good. The specified sensitivity is usually a starting point for consideration, since it indicates a best-case scenario. Other factors to consider are the antenna, the PCB and even the device package (wafer-scale packages often perform better). Highlights of the NXP portfolio include the QN908x system-in-package (SiP0 with NFC, which is specified at -92.7 dBm, and the KW38 Bluetooth 5.0 MCU, which can reach -98 dBm.
This measures how much power can be applied to RF transmissions. To reduce the need for external power amplifiers (PAs), Bluetooth MCUs sometimes integrate their own PAs, so they can boost the RF power to higher levels. Higher output power is used to extend range and overcome environmental effects on the transmission. Today’s integrated transmit power ratings range from 0 dBm to nearly 20 dBm. Adding an external PA can take levels beyond what’s possible using just integrated functionality. In the NXP portfolio, Tx output power ranges from 2 dBm to the recently announced K32W041A, which supports 15 dBm of output power.
This measures the amount of power it takes for the Bluetooth MCU to enable the radio for receiver or transmit modes. It’s an important parameter for battery-operated applications. It’s typically represented as a current at a specific voltage level. Transmit power is usually represented at a nominal transmit output power (0 dBm), which makes it easier to understand how energy-efficient the Bluetooth radio will be. Lower peak currents for Tx and Rx may lead to longer battery life, but this depends to a large degree on what the application needs to accomplish. State-of-the-art Bluetooth MCUs achieve less than 12 mW for Tx and Rx scenarios. Non-optimized Bluetooth MCUs can require up to 40 mW , which is not ideal for smaller batteries, but can be a good choice for wall powered applications, such as light bulbs. The NXP portfolio includes the highly optimized QN908x, which supports Tx and Rx of less than 12 mW, and other solutions that are closer to 20 mW, which is still a good choice for battery operation.
Beyond functionality and performance, there are other factors, relating to embedded design, that can influence your choice. For example, the specific MCU features, such as the amount of memory, the number of peripherals, and support for power-saving modes, play an important role in the selection process.
From a broader perspective, also consider what will help simplify development and differentiate the design. Software enablement, technical support and complementary products come to mind. This is one of the areas where NXP really stands out. We cover a broad spectrum of industry-proven security solutions, combine Bluetooth with other connectivity technologies, such as Wi-Fi and NFC, and have an extensive portfolio dedicated to edge solutions. Simply put, no other company provides the same breadth and scale of technology for embedded systems. We help address every aspect of Bluetooth operation, from end node to the cloud.
Did you know that the light, robin-egg blue used by the New York jeweler, Tiffany & Co., is a registered trademark? It’s called Tiffany Blue. That may be an extreme version of what I think of as “owning your blue,” but it’s a nice example of how the right color – or the right product variant – can make all the difference. And, with so many Bluetooth MCUs to choose from, it’s possible, with a bit of careful evaluation, to find your signature blue, too.
For an overview of NXP’s Bluetooth MCU products, with key parameters in a summary table, visit this page of the NXP website.
Donnie Garcia began his semiconductor career as an applications engineer for 8- and 16-bit MCUs. He has helped define and design low-power MCUs for consumer and industrial applications and currently works as a Product Manager for wireless MCUs. Donnie has authored nearly 20 technical publications (webinars, whitepapers, articles, application notes, engineering bulletins). He spends his weekends enjoying the outdoors around Austin.
