Introducing powerful development and debugging tools for BLE mobile apps.
Bluetooth devices are being developed for just about anything these days, typically as companion products linked with a more powerful platform like a PC or smartphone/tablet.
With such a wide variety of applications, developing and debugging a Bluetooth interface can be a difficult process. For example, configuring a device for a GATT server can be challenging if the designer is unable to visualize the data and verify it on the receiving end. The EFR Connect BLE App by Silicon Labs allows for BLE testing across any BLE chip, and this article will briefly explore some debugging tools associated with testing/reading out receive data, monitoring frequency and update rate, measuring average power consumption of the BLE module, as well as how to test firmware updates by using an over-the-air device firmware update (OTA DFU).
A link to a more detailed article can be found at the end.
Use Case Example
Let us set up this example with a very standard design and set of specifications: a DFU OTA–enabled remote temperature sensor that reads once per second when connected to a smartphone app and twice per second when advertising (at less than 25-µA average current consumption). Now, let us say that the firmware developer doesn’t have access to the associated app yet, as it’s being developed in parallel. The goal here is to use a set of tools to test and debug firmware while verifying that the specifications can be met.
The first requirement consists of reading out temperature data on the GATT server and making sure it’s consistent and accurate. The EFR Connect BLE Mobile App contains two sides: demo and developer. While the demo view allows for out-of-the-box designs and pre-built sample applications, the developer view allows the firmware engineer to quickly search for all nearby discoverable BLE devices and then test their connections. See Figure 1 for a demonstration of the app in developer view. Once the user is able to identify and connect to the device, GATT info will be shown and temperature readout can be confirmed.
Figure 1: Develop view and process of discovering and testing BLE devices with GATT service
When designing with wireless systems-on-chip (SoCs) from Silicon Labs, developers typically have access to a peripheral called Packet Trace Interface (PTI). The PTI outputs all raw data and can be used with a board controller on Silicon Labs’ Pro Kit connected to a PC running a network analyzer program for further analysis. This allows for complete visualization of all BLE activity to and from the module, including indications of temperature measurements and their timestamps. These timestamps can be used to verify all data transactions and the frequency at which they occur. This example contains two over-the-air packets: one for sending data from the SoC (GATT server) to the mobile phone and a second packet sent from the phone to the SoC acknowledging that it has been received. Figure 2 demonstrates the readout of the network analyzer and the interval of transactions, which does indeed occur at about 1 second. If needed, a full decoding of the data can be observed on the right-hand side of the table to assist with troubleshooting.
Figure 2: Simplicity Studio’s network analyzer for analysis of BLE packets
Meeting a specific energy footprint can be critical to the application, and wireless transmission can draw a very wide range of power based on the configuration. Measuring and verifying these values are not always straightforward. In this example, the requirement is to stay under 25 µA when advertising at twice per second (2 Hz). While the timestamps recorded with the network analyzer can verify the transmission rate, another useful feature of the Silicon Labs Pro Kit is called Advanced Energy Monitoring. This program allows for direct measurement of current of the target device, which can be relayed to Simplicity Studio and visualized using the Energy Profiler. Figure 3 shows the initial readings for this example.
Figure 3: Initial current consumption plot for advertising
The plot shows both baseline (sleep) current and peak (radio) current corresponding to the advertisements. It also reveals that the advertising rate for this example is observed to be roughly every 100 ms, or 10 Hz. At this rate, current is averaging about 125 µA, much higher than the target of 25 µA. When the advertising interval is lowered to twice per second via a firmware change while also lowering the Tx power from 6 dBm to 0 dBm, it can be observed (in Figure 4) that current is lowered to less than 25 µA. This method of pulling levers in firmware and configuring settings to fit an energy footprint is a quick and easy approach when coupled with visualizing a plot for direct verification.
Figure 4: Final optimized current consumption plot for advertising
Finally, the last requirement consists of performing remote firmware updates when needed. The OTA firmware updates should be included by default when designing based on the Silicon Labs GSDK, and can be tested via the EFR Connect BLE App. Once the remote device and its OTA service has been detected, the app allows for firmware updates via the “OTA DFU” option in the top right (see Figure 5).
Figure 5: OTA DFU testing with EFR Connect BLE App
Conclusion
Silicon Labs’ EFR Connect BLE Mobile App and Simplicity Studio software bring powerful development and debugging tools for testing and troubleshooting applications while allowing for both quantitative and qualitative verification of the system requirements.
Click here for a full version of this article.