Bluetooth and Bluetooth Low Energy (BLE) are rapidly making their way to all kinds of new products. Because they’re integrated into smartphones, they allow a user to talk to any enabled product easily without any external adapter.
Apple added support for Bluetooth v4.0 beginning with the iPhone 4S in October 2011. An important part of Apple’s decision was to avoid using the authentication processor that is needed for data communications using Classic Bluetooth. This means anyone with a BLE chipset and an iOS application can control devices and exchange data.
This opened the floodgates to a slew of new devices. No longer were you required to use expensive authentication processors, which lowered costs. Between the low cost and BTLE’s low power, new applications like key-chain finders were born, products that weren’t practical before due to Bluetooth’s high power consumption.
Developing products and gadgets depends on getting the right chipset and ecosystem because:
We’ve decided to put together much of the information we have learned from working with multiple customers developing BLE and Bluetooth products, and the keys to getting your product developed right.
The first question we ask our clients, and you should ask yourself, is what kind of information you are looking to transfer. Bluetooth Smart (as the Bluetooth Special Interest Group likes to call it) was designed for low power and low latency. The Bluetooth specifications prior to v4.0 focused on sending large amounts of data such as audio. This causes them to have a high connection latency and high power consumption. BTLE, on the other hand, sacrifices high throughput to achieve low power. So, BLE can’t be used to stream audio or music, but it’s perfect for small amounts of data sent infrequently such as sensor data. Look at the table below to try and see some of the differences between the two:
|Feature||Bluetooth LE||Bluetooth Classic|
|Audio/Headset Support||Low quality compressed audio||Yes|
|Authentication for Apple||Not Required for Data||For Non-Audio Only|
|Smartphone Support||Major Support Since 2011-2012||Mid 2000’s|
There are several considerations on whether to use just BLE (called Single Mode), Just Bluetooth, or both Bluetooth + BLE (called Dual Mode). The first one is cost. Supporting Bluetooth EDR (Classic) is usually more complex and costly. Usually you will go this approach in two cases:
On the other hand, the reasons to use BLE are:
Most developers today are using Single Mode devices supporting BLE only. A large number of vendors specialize in these chipsets as well because of the number of applications and the Internet of Things. For example, a smart light bulb only needs BLE to send on/off or color commands which allows it to be cheaper.
Let’s get an overview at some of the chipsets and vendors out there:
|Mode||Integrated Processor||Flash||RAM||Current Consumption BLE (RX/TX)||Average Current 1 sec / 4sec connection interval|
|TI CC2540/CC2541||Single Mode v4.0||8051||128kB/256kB||8kB||17.9mA / 18.2mA to 14.7mA / 14.3mA||24uA / 6.8uA|
|Texas Instruments CC256x||Dual Mode Classic + BLE/ANT||No - External||None||None||-||-|
|Texas Instruments CC26xx||Single Mode BLE v4.1||Cortex-M3||128kB||20kB||5.9mA||-|
|Nordic Semiconductor nRF51822||Single Mode v4.1 / ANT||Cortex-M0||128kB / 256kB||16kB / 32kB||9.7mA / 8mA||15.5uA / 5.6uA|
|Nordic Semiconductor nRF8001||Single Mode v4.0||None||None||None||14.6mA/12.7mA||-|
|Dialog Semiconductor DA14580||Single Mode BLE v4.1||Cortex-M0||32kB OTP||42kB + 8kB||4.9mA / 4.9mA||-|
|Cypress Semiconductor PSoC 4 BLE / PRoC BLE||Single Mode BLE v4.1||Cortex-M0||128kB / 256kB||16kB / 32kB||15.6mA / 16.4mA||18.9uA / 6.2uA|
|CSR CSR101x||Single Mode BLE v4.1||16-bit RISC||64kB||64kB||16mA||28uA / 10.8uA|
You’ll first notice that most of the devices in the table a Single Mode only, and that most of those run v4.1 of the Bluetooth Specification. Bluetooth v4.2 hasn’t made it yet to the market completely because it requires updated hardware and because it requires support on both sides of the link. Dual Mode devices are not as popular in new applications because of cost and the complexity of supporting Bluetooth BR/EDR (Classic).
Power consumption, which is often a critical factor in the decision, is always a complex question and you should look at more than just the BLE peaks. Looking at the Peak BLE current in the table above gives some information about how long the solution will last. This is because in Coin Cell battery designs (which are very common), having large peaks actually reduces the capacity further. But, this is only part of the story. Every application is different and in some cases the peaks make less difference than the current draw in shutdown mode. This is the case for applications where the system is asleep waiting for an even to occur, or when advertising and connections are relatively rare.
Most of the devices are offered in two packages: QFN and WLCSP. QFN is the standard Quad Flat No Leads package that is easy to use in products. Chip Scale Package (CSP) or Wafer Level Chip Scale package (WLCSP) is basically the silicon die with solder balls, very similar to a BGA.
Let’s look at the differences:
Although you may try and pick WLCSP because of price, the PCB design for WLCSP devices requires much tighter tolerances and usually more than 2 layers, so it is more expensive. Ultimately what you save by using WLCSP may end up being offset by higher PCB costs.
It’s critical to get the design and manufacturing right because a bad design or manufacturing issues could cause issues such as cracks in the balls. This is one of the main causes with low yields. WLCSP is good for very small products or modules where QFN won’t fit, but requires more effort in getting it right.
Next we’ll discuss some of the pros and cons of each device that’s available. We’ve tried to provide as much of the relevant information and what makes parts special, which may be relevant in your design, but as you can imagine there’s a lot of other aspects. If you feel you still need some help, drop us a line and we’ll be happy to discuss.
The CC2540 and its improved version, the CC2541, have been very popular for several years. Both devices feature an 8051 processor that enables your application to run without external microcontroller, so the total system cost is lower. This also has a downside that is common with most integrated solutions. Your application will be tied to the 8051 processor, for better or for worse. In many applications this won’t be an issue, but in some cases your product will require more performance.
Here are some more detailed specs for the part:
You can see this device is full of peripherals which cover a lot of products.
One important aspect that needs to be considered with the CC2540 and CC2541 is the development toolset. Most single chip BLE devices actually are small software defined radios. It is actually this firmware that manages some of the low level BLE functionality. This flexibility can be a blessing and a curse. On the one hand, software defined means that TI can provide new and improved firmware. On the other hand, the BLE library needs to be integrated in your software by the linker, which means it has to be linked for your particular compiler. TI currently provides the BLE software for IAR’s 8051 IDE. After a 30 day evaluation period, you basically have to pay $3k-$4k. IAR is a very good compiler, but many hobbyists cannot afford the tool.
The CC2541 is not just a BLE radio, but can run proprietary protocols as well, which the CC2540 is not capable of doing. Among the other changes are:
More Information on the CC2541
The nRF8001 is a standalone device that requires an external microcontroller, but it runs the BLE stack internally, so much of the low level tasks are already managed. It is controlled by sending Commands and Data, as well as receiving Events from the device. SPI is a very common interface, so its easy to connect it to most microcontrollers. The benefit of using such a device are that you can use your favorite microcontroller, as long as it meets all your application requirements, and the toolset which you already have. However, using an external microcontroller can mean a more expensive solution. Here are some of the specs:
Because of the external microcontroller, there is bigger burden on the developer because of the need to port and deal with the low level drivers, as well as port example software.
Another thing to note about the nRF8001 is that it cannot send iBeacon packets due to limits on manufacturer specific data.
Nordic Semiconductor released the nRF51822 after the nRF8001, and it is one of the most popular BLE devices. It’s an integrated solution that appeals to developers because of its small size. It integrates a Cortex-M0 CPU, which means there are many compiler options for development. In fact, Nordic explains how to setup a development environment using an ARM GCC compiler, Eclipse and a few other tools. This can enable any developer to use the RF51822 with free tools. For product development it is usually recommended use a vendor toolchain such as IAR or Keil. Some of the distinguishing values of the nRF51822:
Remember that TI had software defined radio in their chipset? Nordic’s BLE chipset is very much a multi-protocol device. It supports support standard 2.4GHz proprietary radio functionality with three different data rates up to 2Mbps. This can help you future-proof your product if you ever need some proprietary communication. It’s completely compatible with Nordic’s nRF24L radios, which have been used in quite a few products.
Nordic recently announced the nRF51822 running IPv6 which opens the door to control products with the nRF51822 over the internet, as opposed to using Wi-Fi (and at a much lower cost). This can become extremely appealing to product developers.
One advantage of the nRF51822 is that it is a mature device currently in its third revision, so you know that Nordic has worked out many of the earlier issues to make your product more reliable.
You can find more information on the nRF51822 here
Dialog is a relative newcomer to the BLE scene, and they’ve take a different approach. Their DA14580 chipset has no integrated flash memory. Because of this, they can lower their device cost and power consumption. Flash memory requires both specialized circuitry as well higher voltages. Dialog’s device can work right off an Alkaline battery. Let’s see what is different about it:
One-Time programmable memory is just that, programmable once. For development the user application and stack are loaded into memory via JTAG. The device can connect to an external memory via SPI or I2C to load firmware. Although not as flexible as having Flash on-chip, it can alleviate issues with firmware updates.
A nice advantage of the device is that its RF output is already matched to 50 Ohm, so no external components are needed. Even the crystal loading capacitors for the High Speed clock are integrated.
As one of the parts with the lowest current consumption currently on the market, it is very attractive for low power products needing to run for many years.
The Cypress PSoC 4 BLE and PRoC 4 BLE devices are unique devices that don’t just integrate BLE and an ARM Cortex-M0 core, but adds programmable Analog and Digital blocks unique to Cypress. PSoC 4 BLE also includes Cypresses CapSense controller that is the top Capacitive Touch solution sold.
There are several advantages to PSoC 4 BLE devices:
We’re big fans of the PSoC 4 BLE for applications that need a lot of analog parts, where you can save money by avoiding external parts. A lot of products we’ve worked on benefit from the ADC and OpAmps, including medical and industrial products.
Here’s the general specs for the part:
Out of all the we discussed, the CC256x is the only one capable of supporting what is typically called Classic Bluetooth in a Dual Mode configuration. This enables it to stream audio and support the functionality you typically think of when you think of Bluetooth. The CC256x is readily available to anyone, since TI has made Evaluation and Development kits, as well as software, available. Dual Mode solutions from other vendors are not as accessible to small manufacturers.
One of the major considerations when doing a BLE design, aside from picking a chipset itself, is whether to use a Bluetooth Module, or whether to do a discrete Bluetooth design.
Bluetooth requires FCC and Bluetooth SIG certification. Using a pre-certified module avoids you having to certify, and is usually faster to market. But, modules sold by various vendors cost more. The right decision depends usually on the product volume.
In some cases a mix of the approaches is best. Doing your own module will take some time but can be used in multiple products and will amortize quicker over time.
A few of the important things to look at when selecting a module are:
Whether you’ve selected a discrete design or a module, RF design is critical to ensure your system achieves the best link and range.
The output of BLE Radios usually require a Balanced to Unbalanced (Balun) network to convert the output impedance to the standard 50Ω impedance.
Once converted, the PCB must maintain the 50Ω impedance to ensure that all the power coming from the Bluetooth radio reaches the antenna. If the impedance does not match, the output power will be lower and you may have errors (and possibly FCC certification issues).
Achieving 50Ω impedance is a combination of geometry of the traces and the reference ground plane used. Two common designs are used, Microstrip and Stripline. Which one is better depends on the specific layout, and stackup needed.
Achieving good range usually means using a good antenna and following best practices. In very small products, the antenna has to be small. Cost is also a factor, leaving PCB trace antennas as a very attractive alternative. But, chip antennas are usually slightly more expensive but smaller.
It’s important to clear any metal around the antenna except for the designated ground plane. If there is metal around the antenna where it shouldn’t, the will be reduced and connections may become unreliable.
Even when vendors refer to their devices as implementing a certain version of the Bluetooth Specification, there can be many features that are limited or left out. The Bluetooth Spec has many optional parts that vendors may not implement because of time or technical considerations. For example, Nordic offers a 32kB version of their nRF51822 part specifically to take advantage of new Bluetooth features such as IPv6 support. Vendors with smaller RAM sizes are technically limited from some features.
Another issue may be the number of simultaneous connections supported. Each connection requires more memory, so some vendors limit the number of BLE connections that can be made.
Because of this, it’s important to understand what the stack can and can’t do. Companies with more mature devices such as TI and Nordic have more robust features, but other vendors are catching up.
For example, the nRF8001 can only support 2-3 packets per BLE connection event, as opposed to the 6 the nRF51822 supports. This makes the nRF51822 higher throughput device, which can be very important in some cases like Over-The-Air Download. The limit comes down to memory. The nRF8001 is just a network processor so it doesn’t have much of it.
Although we’ve talked extensively about the BLE features and the processor, the reality is that a good system designer looks on the peripherals that are available on the devices. Peripherals require little to no software, speeding up development. They also offload the CPU to perform other tasks which can lead to higher performance, and they can also result in lower power consumption overall since the CPU can remain in sleep mode.
Always look at how you can take smart advantage of peripherals, even in cases where other specifications may seem appealing. We’ve worked with clients where a certain peripheral meant an extra year of operation from a battery.
|CC26xx||4||10, 15, 31||2x SSI||Comparator, Current Source||12-bit 200ksps||I2S, RTC, Sensor Controller|
|nRF51822||3||Up to 31||1x I2C UART RTC||Temperature Sensor||10-bit||Quadrature Decoder|
|DA14580||2||12, 22, 32||2x UARTS SPI I2C||ADC||10-bit||Quadrature Decoder, Keyboard Controller|
|PSoC4 BLE||4||Up to 36||2x Comm Blocks||4x OpAmps 2x Comparators||12-bit 1Msps||CapSense Controller|
Some devices come with more analog capabilities which is helpful in very small devices. But these analog features also cost more, especially in the C26xx and PSoC BLE devices which are more expensive.
Most BLE devices have only 10-bit ADCs, and only the higher end parts have 12-bit ADCs. Some applications like medical devices can take better advantage of this, but it really depends on the application.
The CC26xx line includes a sensor controller that can offload the CPU, as well as a 12-bit ADC, along with more complete features like an RTC.
The PSoC 4 BLE line from Cypress has programmable digital and analog features that can make it very useful in products that need very high integration, but they also come at an expense.
One of the biggest issues with integrated BLE chipsets is the limited number of GPIOs. In some cases, there’s very few and they need to be shared with LCD, buttons, LEDs, digital interfaces, and analog. Before you start your design you should go through all the requirements and make sure there’s enough. In some cases it’s easy to replace parts with digital interfaces like SPI or I2C that can use less pins. I/O Port expanders are expensive but are sometimes unavoidable.
Depending on your product, raw performance could be critical. BLE chipsets with Cortex-M0 devices have limited processing capabilities. If you’re looking for a high performance integrated solution, the CC26xx from TI could be it given the Cortex-M4F solution.
You can also pick your own microcontroller and pair it with a network processor such as the nRF8001, or even a device such as the nRF51822. Using an external processor takes more space and can be more expensive, but it also has some advantages. The first is that you can pick the right device for the performance you need. You can also reuse code for your processor. You also avoid the limitations imposed by the chipset manufacturer like limited number of GPIOs or lack of peripherals, memory, flash, etc. One downside is that you will have to rely more on your technical expertise to get the solution working since there’s less sample code.
If you’re comparing devices, make sure to look at the fine print regarding RAM and Flash/ROM. In some cases, RAM is being used for the BLE stack or for other purposes and you will have less space than you thought.
We’ve covered some of the most popular BLE and Bluetooth devices, their specifications and some of the key aspects to keep in mind when making a decision.
As always, there are many details and concerns that come into play when creating a BLE product. We’re committed to help you get it done right, so feel free to get in touch with us to discuss.
Enter your email address to subscribe to this blog and receive notifications of new posts by email.