Overview
We’ve been developing Bluetooth devices for a long time, and BLE products since the specification was released back in 2010. Over the years of developing devices we’ve managed to put together a list of items to consider and best practices These ideas, tips and tricks are battle tested and follow years of experience, both good and bad, working with Bluetooth Low Energy.
We’ve seen many design patterns emerge, and project of all kinds experience common problems regardless of the specific product. As part of our goal to share our expertise, we want to go over these recommendations so you can build a better product and avoid reinventing the wheel.
Use the latest Bluetooth Specification
Few people really understand the Bluetooth Specification process, and some have been caught off guard by issues during the qualification process.
When a Bluetooth Specification is adopted, it will typically last for about 15 years. There is a 10 year period during which the specification is active. After this it is typically withdrawn. This will force you to pay $25,000 in fees to qualify a product with that particular specification. After an additional 5 years the specification will be deprecated, after which you can’t qualify at all.
Using the latest specification gives you the most amount of time for development. For example, Bluetooth 5.2 was adopted in 2020, which means that in 2030 it will be withdrawn. Bluetooth 5.0 was adopted in 2016 and the specification will be withdrawn soon in 2026.
Using old chipsets that support an old specification, like 5.0, can be risky. Some vendors will try and sell them at low prices to get rid of inventory. This can lead to problems down the road. Sometimes chips can be upgraded via firmware patches, but sometimes they can’t.
Using the latest Bluetooth specification allows you to take advantage of the latest features and fixes. Since Specifications are backwards compatible and roll new features in, you also get to make a better product.
Note that there’s no limit to how long you can sell a product once qualified. The issue is the qualification itself.
Bluetooth Stacks and SDKs are not all the same
The Bluetooth Specification defines the behavior of the Bluetooth Controller and Host parts. Even though the specification itself is over 2000 pages, it leaves the actual implementation and many other decisions up to the Stack developer. This means there can be large variability in the stacks. Features and even performance can vary.
In most cases, Bluetooth stacks are provided by the chipset vendors. It doesn’t make sense for customers to develop the Bluetooth stack, and the effort in qualifying a stack would prevent developers from using that chip.
One example of how a stack can impact your behavior is ST Micro’s stack. This stack has several variants, including a full stack, one with extended advertising, and a lite version with many features stripped for Peripheral only functionality. On one project for a client, because there was no specific Central/Scanner feature, we were forced to use the larger Full stack variant that took over most flash. Because of the large flash utilization we couldn’t fit the application itself, resulting in a redesign (we didn’t pick the chipset).
The quality of stacks varies, and even the best ones can have bugs and missing features. Several years ago, Nordic Semiconductor’s SoftDevice (the name they give their stacks) had an issue with a particular phone in Asia. The manufacturer of that phone used a stack that implemented a link layer in a certain way that would reject all connections with that particular SoftDevice. Because of business considerations, Nordic decided not to fix the issue.
This issue shouldn’t happen, since Bluetooth is supposed to be interoperable. But sometimes there are issues.
Another factor in using a Bluetooth stack is that the actual features implemented may vary. Many Bluetooth features are actually optional, and you need to contact the vendor and check about whether they support a particular feature, especially if it’s new.
You can find out more information about a stack’s feature support by looking at the ICS document for that stack which is available on the Bluetooth SIG’s website.
Even though a vendor may publicly state they support a particular feature, it may have limitations. We ran into that with OnSemi’s RSL15, where some features were still being developed.
It’s not just about the stack itself. There’s a lot of features on an application layer where a vendor can make your life harder or easier. Some SDKs have APIs and libraries to help you control the stack and avoid the boilerplate. For example, Nordic’s SDK will allow you to manage advertising relatively simply and allow for multiple advertising intervals out of the box. In other stacks you will need to implant that yourself.
Another great example is advertisement filtering. The ST Micro Stack sends you Advertising Reports, and the rest is up to you. Nordic’s SDK provided easy to use APIs with the ability to filter out of the box.
You may not realize it at first, but having great support and documentation are critical. You can tell a lot about software by the documentation it provides and how easy it is to understand and use. Good documentation often implies a good architecture.
As important as it is to pick a good chip, picking a good stack is often more critical. Stacks from vendors with a long history in the market tend to be more reliable and have more features, one of the reasons for Nordic’s popularity.
Don’t use BLE Connections unnecessarily
One of the most critical decisions when designing a device with BLE is whether to allow connections or leverage advertising. Sometimes the decision is clear, and sometimes it takes a bit of analysis.
It doesn’t have to be a binary decision, but there are many devices that can benefit from just advertising data without supporting connections. Anything that sends data out but doesn’t need any data in or to be configured can just use advertisements. Sensors, tags and many other devices are great examples where the lowest power that can be achieved
If there’s not enough space in regular Adverting and Scan Response packets, leveraging Periodic Advertising can be done.
Use Dynamic Advertising
The Bluetooth LE spec lets you control a single advertising interval. But in most cases, a single advertising interval is not enough. Advertising rates control the power consumption of your device when it’s advertising, which can be a huge percentage of its operational lifetime, and optimizing it depending on conditions can make a big difference for your power consumption.
When a user gets a new product, they often download a mobile app and expect immediate connections. If you are targeting low power and set your advertising interval to be high (so advertisements come out slowly), that initial connection will take time. That’s not a very good user experience.
Instead, your advertising should speed up when a user interacts with a product and slow down later when they’re done and most things are done in the background. This is typically Fast Advertisement followed by Slow Advertisement. After a specific timeout (120s for example), you can slow down the advertising rate.
Design Connection Parameters Carefully
The Bluetooth Specification allows a huge latitude in choosing the Connection Parameters. As a Peripheral, you can request certain parameters, and the central device will likely accept them. The problem is that since most BLE products are battery powered, power consumption is critical. In some medical devices we’ve worked on, every microamp is critical.
You may think that Slave Latency will save you, just make the interval really small and add slave latency. But the issue is that a high Slave Latency is that it can delay messages from the Central to the Peripheral (the Peripheral will send immediately in most cases). There’s also a limit to the latency that can be used, and having a high interval will still experience moments of higher consumption.
Imagine you’re trying to download data from the device. If your Slave Latency is high and your protocol requires some kind of acknowledgement (as most do), it will still delay your overall transmission.
We recommend dynamically adjusting the Connection Parameters to deal with these cases. It adds complexity, especially because if not properly handled it could result in extra power, but done properly it will allow you to save power when possible while speeding up transfers when you need to.
Follow Apple’s Recommendations for Compatibility
Apple publishes a guide called the Accessory Design Guidelines with a lot of recommendations, several of them applicable to Bluetooth Accessories. If you need to support getting advertising or running connections with iOS devices, following the guidelines is critical to success. We’ve seen many products running into issues until we followed the recommendations
For example, if you don’t follow the recommendations about the advertising interval, your advertisements can take longer to receive if they don’t follow the advertising interval guidelines.
Focusing on Android? We’ve had products that were originally designed to be Android only, only for Marketing to later ask for iOS support, causing additional work and risk.
It’s best to try and follow these recommendations as much as possible, even if you don’t now intend to support Apple devices. You may thank yourself later.
PDU Length is not Guaranteed
The Original Bluetooth LE specification 4.0 defined a packet that gives you 20 bytes of data. Bluetooth 4.2 Data Length Extensions added the ability to negotiate a larger packet size. But it’s critical to understand that the packet size is a negotiation, and one challenge you often run into when testing is that the PDU length will negotiate to the maximum size. Then in the field you can run into issues.
Whether a Central accepts a large PDU, and what amount is actually chosen depends on a few parameters and the Bluetooth stack itself. Things like multiple connections, the connection rates, could all impact the PDU choice.
It’s critical that your code accounts for this variability. Get the negotiation results and make sure to limit your data. Some stacks, like RivieraWaves that runs on OnSemi’s RSL15 for example quietly discards extra bytes above the limit. Thankfully our validation caught this early enough.
Don’t hard code the values for the packet sizes, and split data as necessary to fit in the available space.
Consider Using Limited Advertising
Most BLE developers don’t realize it, but there’s a flag in every advertisement packet that indicates General or Limited advertising. Think of Limited advertising as a flag that makes your device stand out from the crowd. When you enable it, scanners will often prioritize these devices.
Products that need a quick connection because, for example, they’re being set up for the first time, should consider enabling Limited Advertising (which is time limited) to speed up the initial connection for the user.
Use Channel Selection Algorithm #2 (CSA#2)
Adopted in Bluetooth 5.0 and often ignored, Channel Selection Algorithm #2 makes the channel hopping much more random and better. It adds a bit of difficulty to any sniffer trying to capture it, but more importantly it avoids channels with issues much better.
This is especially critical for low latency/high throughput applications or when dealing with a lot of interference, where CSA#2 performs better than CSA#1 (the original selection algorithm specified in Bluetooth 4.0).
We’ve often found that developers won’t enable it or will ignore it completely for things that aren’t LE Audio. Almost all modern chipsets support it, for a reason.
Delay Connection Interval slowing after discovery
When a Central device connects to a Peripheral device, it will almost always start a discovery of the GATT server (unless for example it has cached the information). This means that initial connection intervals with the Peripheral will be busy and you can’t communicate. Because of this, it’s best for the initial connection to be quick enough to go through this point. Only after the discovery and other initial actions are done should the connection interval be slowed.
Do you really need that name or serial made public?
One thing we’ve seen consistently when developers design their advertising is that they’ll include the device name or a serial number in advertisements. The advantage is that it makes development easier because you can find a device easily. On the other hand it gives away a lot of information about your device and increases power consumption.
Have you ever scanned for BLE devices and seen a huge number of “Unknown devices”? Apple does not usually include the device’s name in the advertisement. This is both to make it harder to find devices and track them, but also because it wastes power.
Even worse, the whole scanning and connection of products tends to center around this name or serial.
We recommend using names and other such information only during development, and removing them when going to production (or developing a better approach altogether). Otherwise, the use of Privacy features is useless.
Understand MAC Address
Another topic that gets confused often for developer is MAC addresses. Developers often thing they own the MAC address of a device.
In reality Bluetooth devices use two major type of addresses – Public Addresses and Random.
Public MAC Addresses are allocated from the IEEE and need to be purchased. You purchase a block of addresses and use them.
Random MAC addresses are either static or private. Static MAC addresses are often programmed by manufacturers of the BLE SoC to make MAC assignment. They can also be randomly assigned at power up. If you’re using MAC addresses to find and connect to devices you need to be careful and understand where the MAC address comes from.
Private addresses are used by the Bluetooth Privacy features and they cycle periodically, usually every 15 minutes.
By the Bluetooth Specification, the MAC address of a device cannot be changed except when the device powers on for cases besides Private addresses.
BLE Privacy is harder than you think
One of the issues with Bluetooth Classic is that it used a fixed MAC address that never changed. This allowed other devices to scan and track Bluetooth Classic devices. In fact that’s still the case with Dual Mode devices.
Because BLE was envisioned as a way to track everything, preventing devices from being tracked was a point of the Bluetooth 4.0 specification and BLE in particular. The problem is, that just having the MAC cycle isn’t enough.
We’ve run into products that implement LE Privacy and transmit their name or serial in the clear. This completely defeats the purpose of LE Privacy. If Privacy is important for your product, you need to look at the advertisement holistically and make sure that the data your sending can’t be easily tracked.
While Device Name is a common element to include, even data in the Manufacturer Specific Data field can give you away. UUIDs for services can make tracking easier. There’s just no way to completely make privacy happen without taking a lot of drastic steps.
One such approach we’ve found useful is to change the advertising data – when doing an initial setup of a device, advertise the information you need to find it (or use proximity or NFC). Then, change the advertising data.
Think this will solve everything? It’s still possible to fingerprint devices on an RF level by measuring things like the unique RF fingerprint.
Like any security measure, the idea is to make the cost to the attacker so high it simply doesn’t make sense. But for a determined enough attacker, tracking is possible.
Guard against attackers and errant connections
Bluetooth LE devices advertise publicly and people and other devices can connect to your product. Because a Peripheral will often allow only one connection, someone connecting randomly or otherwise to your product will block a legitimate central device.
Adding a mechanism that disconnects undesirable devices is a standard part of every product. it protects against attackers wasting power and achieving a Denial of Service attack. This mechanism can be as simple as expecting a specific command to authenticate, or using encryption to authenticate.
This of this as a watchdog – as soon as you connect you have a certain amount of time to authenticate or perform some operation. If you don’t, you get disconnected.
Bluetooth Doesn’t Authenticate
Following up on the previous recommendation, it’s important to realize that while Bluetooth provides security even against Man-In-The-Middle attacks (if you have the I/O to support it), that it’s possible for any device to connect. A user can use any device to connect, and potentially even use the Passkey. If your product needs to connect exclusively to only one app or one custom Central device then you’ll need to implement authentication, ideally using encryption.
2Mbps PHY shortens range
The laws of physics apply to everything in our world. One such rule is that higher modulation rates require better signal to noise ratios. This means that when you use the 2Mbps PHY you will get shower range.
You can compensate for this with extra output power, but that will drain a battery faster. On the other hand, 2Mbps PHY gives you the ability to transfer more quickly, and the system can go to sleep more quickly.
We recommend you use the 2Mbps PHY (or the new PHYs) carefully and not simply enable them by default. Since the switch is dynamic, consider enabling it when you’re transfer significant amounts of data. Telling the user to keep the devices close is also effective.
Be careful of peak currents
A BLE SoC draws the most current when either the CPU is active or the radio is active. High TX Output power can cause power draws in the 10’s of mA or even over 100mA for +20dBm output.
These peak currents can impact the design in various ways. For coin cell batteries that have a high resistance, the voltage will drop. This can result in problems during sampling or even cause a system reboot.
Validate your Bluetooth RF Design
Just putting a BLE chipset on your board isn’t enough, even if everything appears to work. Too often we’ve been called in to check for range and performance issues when the design is in the final stages. Sometimes they discover this when actually doing the Bluetooth of FCC/IC/RED testing. Other times it’s even after that, when you need to make major changes.
Designing a wireless radio and Bluetooth specifically requires proper RF and antenna design. And there’s no way to know how everything performs without actually measuring and testing. Simulations can be expensive and won’t cover everything, though they can cover scenarios that are difficult to address in practice.
You need to check the design performance. Everything from the output power, to the accuracy of frequencies and signals, to the antenna and range. This needs to be done over temperature and even humidity, including any special conditions, and over multiple
Consider this – even Apple had issues with their antenna design for the iPhone 4, which led them to spend over $100M on test equipment to validate their products. You don’t need to spend this amount, but you do need to take steps to validate your product at labs and in other ways.
At Argenox we’ve been helping launch BLE products for over a decade and can help you get your product tested and performing at its best.
You can almost never have too much FLASH or RAM
As BLE became popular for product developers, they’ve added more and more features. Want Over the Air updates (OTA or DFU as it’s often called)? Be ready to give up half your flash or put an external chip.
On some products we developed we ran into Flash size limitations. Usually this happened after the client already chose the chip. TI chips like those in the CC26xx family have relatively limited flash compared to other vendors, and this becomes a problem especially if you want to do firmware updates. That’s improved in recent years as they introduced larger flash devices, but you’ll find close to 2M of flash in new devices.
256kB Flash was the norm at the beginning. With a BLE stack taking about 100kB for Peripheral functionality, this made it only possible to use the chips for Beacons and simple decides.
512kB Flash is the start of something practical but leaves little to no DFU capability. We recommend trying to get 1MB if you are building a moderately complex product.
There’s a downside to choosing larger devices. Cost is the first issue. Flash and RAM take physical space, making the die more expensive due to smaller number of chips coming out of the wafer. The other downside is that additional RAM requires more static current. Even in sleep, RAM retention takes power. The good news is this is controllable.
We talked about Flash, but RAM is also an important consideration. Most of the devices out there building moderately complex products use some form of RTOS, typically FreeRTOS, but Zephyr becoming popular due to Nordic’s involvement.
So what should you do? First of all, try and put in all the features you can and account for the Flash size. It’s important to periodically check the amount nof used flash during development. For some reason some tools are terrible at making this easy. The Segger IDE does a great job at showing you Flash and RAM utilization at every compilation.
There’s a lot of tweaking you can do as far as features for BLE. You can control the number of connections, the packet sizes, etc. There will be tradeoffs but sometimes you can’t do anything.
One other solution is to use the BLE SoC as a Network Processor, where it manages the BLE connection and little else. Essentially you’re offloading the Bluetooth Stack and other items to a separate chip. Sometimes that’s the only solution to get everything to work.
Careful with TX Output power
The slew of BLE SoCs capable to +14dBm and even +20dBm that have been released in the last few years, and the Front End PAs that can deliver the top +20dBm makes product developers think that the sky is the limit. But actually getting to use high output power in products is complex because of regulatory rules.
Up to +10dBm you should have no issue in both the US, Europe and practically every other jurisdiction. However, above +10dBm gets tricky. That’s because Bluetooth LE is not really an Adaptive Frequency Hopping protocol. But it changes channels you say?
Well, during advertising only 3 advertising channels are used. This is less than the 15 channels mandated by the FCC to classify a system as frequency hopping. During a connection you typically get much more than 15 channels, but that’s not always the case. one has to be careful not to drop below 15 channels. The problem is that if you can’t increase output power during advertising, then the other device won’t hear you and you can’t even establish a connection to it to increase the output power. It’s a chicken and egg problem that can be solved but typically gets complicated.
Another issue is that the FCC requires Adaptive Frequency Hopping (emphasis on Adaptive). What does this mean? The system has to dynamically avoid channels that are experiencing interference, because those channels are essentially other wireless devices. The FCC and other regulatory bodies want you to be a good neighbor and avoid that. While the Bluetooth specification provides for this mechanism using the Channel Map Update feature, it doesn’t always get used.
Smartphones, for example, typically support that as Central devices. So if you’re connecting to an iPhone, it will periodically send out Channel Map Updates that comply with the adaptive requirements. But many embedded stacks, like Nordic’s SoftDevices, don’t implement this feature at all (remember our recommendation that not all stacks are the same?). Meanwhile, Silicon Lab’s stack has this feature.
There’s some more issues with a high output power. The first one is that it requires a lot of power. How much? You can find find in the 100mA-120mA peak current if you’re running at +20dBm – this can be a challenge for coin cell battery designs. Part of the problem is that BLE SoCs are developed in Silicon technology, which becomes inefficient at high frequencies and with a lot of power. External Front Ends using GaAs are more efficient, but require an external device and have more complicate software.
Another issue is that while one device can use a high output power, the other device may not, and since you’re not improving sensitivity, you’re only improving the link in one direction. It’s as if one person is shouting while the other one is whispering – makes it very hard to carry on a conversation. Most devices don’t support +20dBm or anywhere near that, with up to +10dBm being the usual limit, but usually around 4-5dBm being standard.
What’s the solution? Design a good RF circuit and antenna, test it and make sure it works well. A good antenna helps improve the efficiency of radiation, meaning more power goes out and more power comes in. Oftentimes you have to figure other tricks to make this work.
Understand the limitations of Reference Designs
Vendors of BLE chipsets want you to take their chipsets, make a design, and send them a check, the bigger the better. You can’t blame them, to get a BLE chipset out, especially given the amount of money they invest means they want to recoup those costs. And there’s a lot of competition in the market.
To speed this up, most will give you a reference design for their chipset. This can even include the reference design in Altium, OrCAD or some other popular package. Worse, some vendors only give you Gerber files or make you jump through hoops to get them (apparently they seem to not want to make much money).
One challenge with these reference designs is that they’re only good if you copy them EXACTLY. Small deviations from the design, in routing, stackup, ground plane, components, etc. will change the performance. Sometimes this change is minor, but sometimes it’s enough to cause the design not to pass regulatory testing. Typically you could fail to meet the performance metrics in the datasheet.
Duplicating a reference design is often impossible. Need a thinner PCB? You’ve just changed the stackup. A board that’s smaller than the reference design? Your ground plane is smaller and the antenna will be less efficient.
If you’re doing a custom design (sometimes called chip down design because you’re putting chips instead of modules), then you can’t avoid testing the design without risking potential issues.
There’s one other reason to do this – while BLE chipset vendors do the best job they can to provide you with a ready to use design so you can launch your product (and buy their chips), they can sometimes make mistakes or be unable to account for unique aspects of your design.
Passing FCC Testing isn’t the end all
Many product developers believe that the FCC/IC/CE testing is a seal of approval that the design is good. In reality, the FCC and other regulatory bodies test your product to make sure it’s limited in its ability to interfere and cause problems for others (it’s a shared spectrum after all). Their tests don’t tell you much about performance. Over the years, we’ve seen a lot of design problems. One design from a large multinational conglomerate (that shall remain nameless) had the engineer put the antenna under a metal can. That design definitely had no issues passing FCC testing!
It’s possible to pass FCC and related testing with a 50 ohm dummy load. You’ll actually pass with flying colors, because instead of the power radiating (as you want it to), it will be lost in the board. The FCC will be happy you don’t interfere, but your end users won’t like the product not working. Bad antennas essentially do the same.
The key to FCC/IC/CE testing is to be able to transmit as much as possible, to get close to the limits (if you can or need), but to never to exceed them. Remember that TX and RX are duals of each other – where you have TX issues you will have RX issues and decreased sensitivity.
Even the Bluetooth SIG testing doesn’t necessarily check performance. Some of the Bluetooth SIG tests check whether your radio is better than -70dBm sensitivity, where a good modern BLE receiver should achieve better than -95dBm. 25dB difference is huge. There are a few tests that the Bluetooth SIG does to check co-channel interference, but for the most part this should be fine if you’re following the manufacturer recommendations.
It’s the job of the RF and system designer to validate the radio and parameters and to never rely on passing FCC/IC/CE testing as a sign that the product can perform. Our rule at Argenox is that by the time we send a design to the Certification Lab to get the official test report to be submitted, that we already know the design passes and performs as expected. Never leave to the lab what should be done. Labs are not in the business of improving your design. It’s not a critique of labs. It’s just their business – get as many products tested in the shortest amount of time.
Don’t forget RF Debug in the Design
If you’re doing a custom design, it’s a good idea to add the ability to test units, both at the factory and during development. Having connectors makes it easy to connect instruments to validate the RF design without having to hack a unit together. We often have to do that when testing units and sending them out to be tested at a lab.
At the factory, having a low cost connector or pad that can be used can help you test the radio during production can be critical to make sure everything is working well.
Consider Having a Non-Form Factor Design for Development
One challenge you run to often with BLE products is that they’re small, and they’re designed to be as small as possible. This makes debugging them much more difficult. Accessing JTAG, Trace, UARTs, I/O pins can sometimes be very hard for miniature product.
One solution is to create a design that’s non-form factor. This means it’s a large board, with all the same chips an same design, but a lot more space, test points, and the ability to measure. JTAG is broken out to convenient headers. You can connect a Logic Analyzer to the signals.
The purpose of this board is to make it easy for developers to capture information, debug and even automate product testing by allowing easy connections to instrumentation.
The downside to this approach is that you are building another board. There’s also physical differences in the board that means it won’t properly represent the RF performance of the real board. That’s OK. As long as you understand that there are differences and account for them, the board is useful.
We mostly use this approach for small designs, often wearables or medical devices that are very dense and require a lot of validation and justify the cost of the additional design and board build.
One other advantage of this approach is that you can avoid putting as much debug accessibility on the real design to frustrate attempts to reverse engineer the product, and you can deadbug (or bluewire) and fix issues as well as test ideas on that board more easily.
Our recommendation for these boards include:
- Make debug port access easy – Standard ARM JTAG 10-pin or 20 pin header works well. Use the same connector as that in development board of the manufacturer to make your board compatible with their tools.
- Enable injecting power from power supplies – developing with a board using batteries can be frustrating. You want to be able to use power supplies, but also batteries for some testing.
- Test points – Add test points that can be instrumented easily. For Ground connections we use 5010 from Keystone while for the signals themselves we may use Keystone 5019 or other colored test points. It’s important to have a nice solid connection so they’re mechanically sturdy. Be careful that you don’t impact the signal integrity for high speed signals when adding test points.
- Add RF ports for antenna investigation – if you’re still considering various options, an RF port such as a u.FL connector can help make testing of antennas faster
Summary
We hope you’ve found this guide useful. It contains some of our most important experience in developing real products with BLE and other technologies. As with any guideline, you will need to account for the realities of particular product. But in most cases, we’ve found that following these recommendations can save a project from major problems. When applied early and carefully by an engineering team, you will increase the odds of launching a product with less issues.
If you have any questions or are looking for help getting your product launched as we’ve done for Fortune 100 to startups, you can contact us.
