What's Bluetooth Development?
Bluetooth Low Energy (BLE) is the most popular wireless connectivity technology for IoT products, with 5.4 billion devices expected to ship in 2023 – including connected toys, smart insulin pumps, smart home accessories, wireless light switches, and many other types of devices. Despite their limited functionality, developing Bluetooth-enabled products is not trivial. These devices are typically developed around a wireless System on Chip (SoC) running an embedded Bluetooth stack and application firmware. Due to the limited I/O capabilities of the SoCs, these IoT products are configured as companion devices, leveraging the capabilities of more powerful devices such as a smartphone, tablet, or PC for configuration and control. For example, a smartphone functions as a user interface for a BLE-enabled toothbrush or power-drill.
Bluetooth development, including the firmware for such constraint devices, may sound easy because of their simple features and limited use cases. This couldn't be farther from the reality, though. Testing the GATT interface with a BLE client or OTA DFU (Over-the-air Direct Firmware Update) capability, optimizing energy consumption, and troubleshooting issues at the application or Bluetooth protocol level are typically complicated processes, requiring highly advanced debugging tools.
How can developers accelerate the firmware development and reduce the risks of ending up going down a blind alley in the process? For the firmware development effort of BLE applications, the embedded developers must be equipped with the best development and debugging tools. That doesn't necessarily mean expensive and specialized lab bench instruments. Sometimes all you need is a powerful set of simple tools that can run on your smartphone and PC, coupled with well-designed hardware kits.
Example Bluetooth Development Scenario
Let's imagine an IoT device with the following requirements:
- It must read the temperature sensor once per second and report the value to a smartphone app if it is connected
- If a smartphone is not connected, it must advertise twice per second to ensure low connection latency, with an average current consumption target of <25uA
- TX Power can be dialed down in favor of the current consumption target because the smartphone will always be in close range of the device
- It must be OTA DFU enabled
On the IoT product, the BLE client will be a mobile app, but the firmware developer doesn't have access to that yet because the mobile app development is behind schedule, so there is no clear way of testing whether some of these requirements are being fulfilled and operating according to spec.
A second kit would be a way to introduce a BLE client for testing, but that is not a feasible option for many developers. Some developers don't want to pay the extra cost of a second kit, while others don't want to write code in two places, which slows down their development process. How do you test the firmware without writing more code on a second device?
How about verifying that the device advertises twice a second and that the average current reaches the target? It sounds like some expensive equipment might be needed here because a simple digital multimeter has a limited ability to measure fast transients such as those caused by the Bluetooth radio activity.
The Four Advanced Debugging Tools for Bluetooth Development
If the SoC used in this application is part of the Silicon Labs EFR32 family, it's likely that the application is being developed around one of the Pro Kits. Also, Simplicity Studio is being used to write the code, and EFR Connect BLE app has been installed during the kit unboxing to demo some of the sample apps. In that case, the firmware developer is already in possession of all the development tools they need to implement and test the given requirements.
1. No-code Mobile App for BLE Testing
Let's start with the first requirement: reading a temperature sensor and reporting once per second to a smartphone app. The development scenario is so that the mobile app companion to the end product is behind schedule. The firmware developer does not want to write more code on a second BLE SoC just to test that their first device is operating as expected.
Using the EFR Connect BLE Mobile App, this is much simpler than it sounds, and it doesn't require writing any code. The mobile app has two very distinct sides:
- A demo side focused on the kit unboxing and getting started experience that offers demos directly mapping to pre-built sample applications on Silicon Labs GSDK, offered through Simplicity Studio
- A develop side with features focused on BLE firmware development, which allows searching for devices using a variety of filters, as well as connecting, discovering, and interacting with the remote GATT server, and more
Using EFR Connect, the firmware engineer can quickly search and find their device, then connect and subscribe to indications to receive the temperature sensor data, as depicted below.
- In the Develop view of EFR Connect, select the browser to search for all nearby discoverable BLE devices
- To quickly narrow down on a specific device, pull down the filter
- The engineer knows that "thermometer" is in the device name, so they can input that as a filtering criteria
- Additionally, they also know that the device is connectable, so they can add that as an additional filtering criteria
- Just based on those two filters, they can quickly display only their device of interest and connect to it
- Once connected, the BLE app will read and display the entire GATT, and the engineer knows that the Health Thermometer service is where they can find the temperature measurement characteristics
- No temperature is immediately displayed because it's sent using indications which the engineer subscribes to from the app
- Once indications are enabled, the embedded device will start sending the temperature readings
With this simple sequence of steps using EFR Connect, the firmware engineer has tested that the device is sending the temperature measurements as per the requirement. An additional requirement was that the measurements should be sent once per second (1Hz frequency). Based on the refresh rate of the temperature value within the app, the engineer concludes that it "seems" to be about 1 second, but there are better ways to get more accurate data on that requirement.
2. Network Analyzer
The wireless SoCs from Silicon Labs include a peripheral called Packet Trace Interface (PTI), which outputs all the raw data that passes through the radio, both from RX and TX operations. The board controller on Silicon Labs' Pro Kit is capable of capturing the PTI data and sending it over USB or Ethernet to Simplicity Studio's Network Analyzer for analyses.
Network Analyzer is an extremely powerful tool that decodes the PTI raw data according to the protocol used in the SoC. When the firmware engineer brings up Network Analyzer, they will capture and visualize all the BLE activity on the EFR32 wireless SoC. After subscribing to indications for the temperature measurement characteristic (step 8 in EFR Connect in the above sequence), it will provide a clear picture of how often these indications are being sent based on their capture timestamps, as depicted below.
The Time column (first on the left-hand side) provides an accurate timestamp when the Pro Kit board controller captured the PTI data from the SoC. This screenshot is showing all data transactions, which in this particular case represent a sequence of two over-the-air packets: one for sending the data through an indication operation from the SoC (GATT server) to the mobile phone, and a second packet sending the indication acknowledgment back from the mobile phone (GATT client) to the SoC. As depicted above, the transactions are logged with approximately one-second intervals. The jitter in the interval is expected because the transmissions need to align with BLE connection intervals which can be 7.5ms at the minimum. On the right-hand side of the network analyzer, it is possible to see the full decoding of any selected packet, divided into its different protocol layers (Radio, L2CAP, attribute protocol, etc.) for additional insight or for troubleshooting Bluetooth protocol issues shall any of those arise during the development.
3. Energy Profiler
Now that the engineer has verified the temperature reading requirement, it is time to move on to additional requirements. Next on the list pertains to the device behavior when it is not connected to a BLE central device: it must advertise twice per second with an average current consumption of <25uA. An option is given to lower TX Power to achieve the desired energy footprint.
The first part of this requirement can again be verified using the network analyzer, similarly to how the temperature sending was checked for the previous requirement. Instead of indication events, the engineer will see advertisement events. The timestamps will indicate when those were captured to verify that they are being sent at 2Hz frequency (twice per second).
But how to verify the current consumption target? Another feature of the Silicon Labs Pro Kits is called Advanced Energy Monitoring (Energy Profiler) which simply put is the ability to measure the current consumption of the target board. Those measurements can then be relayed to Simplicity Studio to be displayed graphically using Energy Profiler. This is what the advertisement profile looks like for the device that the engineer is working with.
Apart from the trace itself, the critical data pieces are the scale (bottom right) and the average current (top right). There are two major current consumption signatures in the trace, the baseline current from the sleep periods and the peaks from radio activity which correspond to the BLE advertisements. From the scale of 100ms, it becomes evident that the device is advertising roughly once every 200ms, which is five times more often than what is stated in the requirement. Those extra advertisements also impact the average current consumption, which is averaging 124.23uA, and that is 5x higher than the target of <25uA.
Once the engineer is aware of their firmware's current status, they can go back to the code base and make the necessary changes to comply with the requirements. Namely, they can modify the advertisement interval to 500ms instead of 100ms so that the device sends two advertisements per second, and they can also bring down the TX Power to 0dBm instead of the 6dBm that they currently have. Since the device is meant to interface with smartphones typically within 5m-10m distance, 0dBm TX Power still ensures excellent signal strength for a robust RF link between the devices.
Once those two code changes are done, and new firmware is built and flashed into the device, the engineer can bring up Energy Profiler to verify that the device is now meeting the requirements after their changes.
Looking again at the scale (500ms), it can be observed that the advertisements are spaced by ~500ms, and on the top right, it can be observed that the current consumption reaches the target of >25uA by a good margin.
4. Over-the-Air Device Firmware Update
The last piece of requirements was having support for over-the-air device firmware update (OTA DFU). If the engineer started building their code based on the Silicon Labs GSDK, then the OTA service is included by default. Ultimately the OTA capability will likely be built-in to the device's companion mobile app. Still, since it was earlier stated that the app wasn't available, we can revert to EFR Connect BLE app to test OTA DFU.
EFR Connect mobile app will detect the Silicon Labs OTA service in the GATT server of a removed device upon connection. It automatically makes the OTA option available on the top-right menu within the connection view.
Once the OTA DFU option is selected, the user is presented with a few options associated with the solution, uploads their new firmware file, and starts the operation.
Conclusions – Bluetooth Development with Advanced Tools
Developing BLE firmware for IoT devices will require a small but powerful arsenal of development tools that allow the firmware developer to test and troubleshoot their application when moving along with development. To ensure that customers have all the advanced development tools by default, Silicon Labs provides them as part of its more comprehensive toolset, from the hardware kits to Simplicity Studio suite, as well as a generic BLE mobile app.