Rapidly Prototype Bluetooth IoT Applications with a Development Kit and Off-the-Shelf Add-On Boards

By Stephen Evanczuk

Contributed By Digi-Key's North American Editors

Demand for smart connected products offers broad opportunities for developers who are able to quickly turn concepts into working Internet of Things (IoT) applications. The availability of energy-efficient processors, wireless connectivity options, and a broad array of hardware peripherals offers a robust foundation for implementing suitable low-power, production-ready designs.

In the early stage of product definition, however, developers need a flexible development platform for building rapid prototypes based on the same class of processors, connectivity subsystems, and peripherals. The ability to quickly build working prototypes and easily add functionality is essential for providing early proofs of concept and for supporting custom software development.

This article shows how developers can use hardware and software from Silicon Labs to quickly build specialized energy-efficient connected IoT device prototypes using a broad selection of readily available off-the-shelf add-on boards.

Enabling rapid prototyping

When exploring new possibilities for battery-powered wireless IoT devices, developers can find themselves bogged down by the many details involved in creating a working development platform. With their integrated subsystems, advanced system-on-chip (SoC) devices can provide the core of such a platform, but developers still need to build a complete system around them.

To build a suitable development platform for these devices, developers not only need to meet fundamental requirements for robust performance and extended battery life, but they also need to build in flexibility to support the specific requirements of each application. The Silicon Labs BGM220-EK4314A Explorer Kit meets this combination of needs, allowing developers to focus on rapidly prototyping new design concepts rather than deal with the details involved in building their own development platform.

Flexible rapid development platform

Offering a low-cost platform for Bluetooth-based application development, the BGM220-EK4314A Explorer Kit combines SiLabs’ BGM220P Wireless Gecko module (BGM220PC22HNA), an on-board SEGGER J-Link debugger, a push button, a light-emitting diode (LED), and multiple expansion options (Figure 1).

Image of SiLabs BGM220-EK4314A Explorer KitFigure 1: The SiLabs BGM220-EK4314A Explorer Kit provides the combination of processing performance, energy management, and configuration flexibility needed to quickly build prototypes and evaluate different peripheral hardware configurations. (Image source: Silicon Labs)

The BGM220P module serves as a complete solution for small battery-powered IoT devices. Its integrated EFR32BG22 Blue Gecko SoC features ultra-low power consumption, Bluetooth angle of arrival (AoA) and angle of departure (AoD) capabilities, and sub-one-meter location accuracy—all needed across a growing array of popular Bluetooth applications including asset tracking tags, smart door locks, fitness, and more.

Capable of operating as a standalone system, the BGM220P module combines the EFR32BG22 SoC with 512 Kbytes of flash, 32 Kbytes of random access memory (RAM), high frequency (HF) and low frequency (LF) crystals (XTAL), and a 2.4 gigahertz (GHz) matching network and ceramic antenna for wireless connectivity (Figure 2).

Diagram of SiLabs BGM220P moduleFigure 2: Capable of serving as a standalone system, the SiLabs BGM220P module combines the EFR32BG22 Blue Gecko SoC with additional components needed to implement a Bluetooth-enabled device. (Image source: Silicon Labs)

Besides its ability to serve as a standalone host for small footprint IoT designs, the module can also serve as a network coprocessor (NCP) for a host processor connected through the module's UART interface. Its integrated Bluetooth stack executes wireless services for applications running on the module in standalone designs, or processes commands received from the host when running in NCP designs.

Energy-efficient wireless SoC

The BGM220P module’s EFR32BG22 Bluetooth wireless SoC integrates a 32-bit Arm Cortex-M33 core, a 2.4 GHz radio, security, energy management subsystems, and multiple timers and interface options. Designed specifically for ultra-low power, battery-powered designs, the EFR32BG22 SoC uses multiple energy management features that can enable coin cell battery operation for up to ten years.

Operating from a single external voltage source, the SoC uses its internal energy management unit to generate internal supply voltages. During operation, the energy management unit controls transitions between the SoC’s five energy modes (EMs). Each mode further reduces power consumption by maintaining progressively fewer active functional blocks as the SoC transitions from active mode (EM0) to sleep mode (EM1), deep sleep mode (EM2), stop mode (EM3), or shutoff mode (EM4) (Figure 3).

Diagram of Silicon Labs EFR32BG22 SoC (click to enlarge)Figure 3: The EFR32BG22 SoC’s energy management unit controls transitions between energy modes EM0, EM1, EM2, EM3, and EM4 (color code at bottom of image). (Image source: Silicon Labs)

In active mode (EM0) at 76.8 MHz and 3 volts, using its internal DC/DC converter, the SoC draws 27 microamps per megahertz (μA/MHz). EM0 is the normal operating mode and is the only one where the Cortex M33 processor core and all peripheral blocks are available.

All peripherals are available in sleep mode (EM1), with fewer remaining active as the system enters even lower power modes. In its lower power modes, the reduction in active clocks and functional blocks results in significantly lower power consumption levels:

  • 17 μA/MHz in sleep mode (EM1)
  • 1.40 μA deep sleep mode (EM2) with 32 Kbytes RAM retention and real-time clock (RTC) running from LFXO
  • 1.05 μA stop mode (EM3) with 8 Kbytes RAM retention and RTC running from the SoC’s integrated ultra-low frequency 1 kilohertz (kHz) resistor-capacitor (RC) oscillator (ULFRCO)
  • 0.17 μA shut off mode (EM4)

Some battery-powered devices need more than the ability to operate the processor in low-power operating modes. Many Bluetooth-enabled applications will typically exhibit extended periods of little or no activity, but require low-latency responsiveness when activity resumes. In fact, even if an application has more lenient latency requirements, a slow wake up time wastes power because the processor performs no useful work as it completes the wake-up process and enters active mode (or completes the process of entering a lower power mode from a higher power mode).

As the time between active periods shrinks, the use of a low-power sleep mode can even become counterproductive when a slow wake-up or power-mode entry time uses more energy than would be consumed if the processor remained in a higher power mode during the inactive period. As a result, developers working to optimize battery life will sometimes maintain a processor in a higher power mode than required by the processing needs of the application.

By using a processor with faster wake up and entry times, developers can more fully take advantage of the processor’s lower power modes. In EM1, the EFG32BG22 wakes up in three clocks/1.24 microseconds (µs) and has an entry time of 1.29 µs, rising to 8.81 milliseconds (ms) and 9.96 µs, respectively, in EM4 (Table 1).

Energy mode Wakeup (executing from RAM/Flash) Entry (executing from Flash)
EM1 3 clock / 1.24 μs 1.29 μs
EM2 5.15 / 13.22 μs 5.23 μs
EM3 5.15 / 13.21 μs 5.23 μs
EM4 8.81 ms (Flash only) 9.96 μs

Table 1: Wake up and power mode entry times for the EFG32BG22 SoC. (Table source: Silicon Labs)

The method used to wake the processor when activity resumes can also significantly affect battery life. Although some applications—such as industrial—require systems to use polled processing to ensure strict periodic timing, many applications in consumer areas use event-based processing to respond to specific activity. Using polling methods for event-based applications, for example, can significantly erode battery life when the processor repeatedly wakes up needlessly.

In the same way as many sensor-based designs use wake-on-interrupt functionality to avoid repeatedly waking the processor just to check for activity, a wake-on-RF feature built into the EFG32BG22 SoC’s radio subsystem enables a similar interrupt-driven approach. This allows developers to maintain the processor in a lower power energy mode until radio frequency (RF) activity occurs.

In practice, developers place the EFG32BG22 wireless SoC in an ultra-low-power EM2, EM3, or EM4 mode and rely on the wake-on-RF capability to wake the SoC when RF energy is detected. When simply detecting energy above threshold, the RFSENSE capability consumes 131 nanoamperes (nA). A more selective RFSENSE mode consumes slightly more current at 138 nA, but in this mode, RFSENSE filters incoming RF signals to avoid waking on RF noise rather than a valid RF signal.

In some cases, the EFG32BG22 SoC might not need to wake the processor core at all to respond to external events: The SiLabs’ Peripheral Reflex System (PRS) enables peripherals to respond to events and operate without waking the processor core. Peripherals can communicate directly with each other, and their functions can be combined to provide complex functionality. By using PRS capabilities with lower energy modes, developers can substantially reduce power consumption without compromising critical functionality such as sensor data acquisition.

Built-in debug and easy expansion

Built into the BGM220 Explorer Kit board, the BGM220P module brings the full set of energy management and processing capabilities of the EFR32BG22 SoC to battery-powered Bluetooth designs. When there is a need to rapidly build prototypes to explore new design concepts, other features of the board help speed development.

Accessed through the board’s USB Micro-B connector, an on-board SEGGER J-Link debugger enables code download and debugging, as well as a virtual COM port for host console access. The debugger also supports SiLabs’ packet trace interface (PTI) capability for analyzing packets transmitted or received over a wireless network.

For rapid prototyping, the board’s support for multiple expansion options offers the flexibility to explore new design ideas that need different combinations of sensors, actuators, connectivity options, and other peripherals. Drawing from the extensive variety of available mikroBUS add-on boards and Qwiic Connect System hardware from multiple vendors, developers can rapidly configure a development platform for each application.

Plugged into the board’s mikroBUS socket, a mikroBUS board connects to the BGM220P module through I2C, SPI, or UART interfaces. The Qwiic connector provides the Qwiic system’s I2C interface for connecting one or more Qwiic boards over distances up to about four feet (ft.). For connections over longer distances, developers can use the SparkFun QwiicBus EndPoint board (COM-16988), which uses differential signaling to maintain I2C signal integrity at distances up to about 100 ft.

Rapid application development

SiLabs applies the concept of rapid expansion to application software development. Along with board support packages, drivers, libraries, and headers for custom development, the company offers several sample applications bundled in its Simplicity Studio development environment, as well as additional projects available from SiLabs’ GitHub repositories. In fact, developers can begin exploring sensor application development with a bundled sample temperature application that uses the EFR32BG22 SoC’s internal temperature sensor as a data source.

Built around the standard Bluetooth Health Temperature service, the temperature application offers an out-of-the-box demonstration of the processing flow through a generic Bluetooth IoT application built on the SiLabs software architecture. The application calls a series of initialization routines for system services and application services that set up interrupt handlers and callbacks. After completing initialization, the application settles into an endless loop to wait for events (Listing 1).

int main(void)
  // Initialize Silicon Labs device, system, service(s) and protocol stack(s).
  // Note that if the kernel is present, processing task(s) will be created by
  // this call.

  // Initialize the application. For example, create periodic timer(s) or
  // task(s) if the kernel is present.

  // Start the kernel. Task(s) created in app_init() will start running.
  while (1) {
    // Do not remove this call: Silicon Labs components process action routine
    // must be called from the super loop.

    // Application process.

    // Let the CPU go to sleep if the system allows it.
Listing 1: SiLabs’ Bluetooth sample applications use a generic execution framework where an endless loop allows callbacks and event handlers to process system and application actions following initialization. (Code source: Silicon Labs)

In this application, when a timer set during initialization counts down, an associated callback routine performs a temperature measurement. After developers build the application and flash the board, they can use the SiLabs EFR Connect app—a generic Bluetooth mobile app that works with all Silicon Labs Bluetooth kits and devices. Along with providing the framework for custom apps, the app aids development by providing a view of supported characteristics associated with a Bluetooth service such as the Bluetooth Health Thermometer service used in this sample application (Figure 4).

Image of SiLabs EFR Connect appFigure 4: The SiLabs EFR Connect app displays characteristics of Bluetooth services used in an application, not only speeding prototype development but also providing a framework for development of custom apps. (Image source: Silicon Labs)

In Simplicity Studio, developers can import a number of different Bluetooth application examples that demonstrate various usage scenarios including designs built with Qwiic or mikroBUS boards, separately or in combination. For example, a sample application that demonstrates the use of the standard Bluetooth Heart Rate (HR) and Bluetooth Pulse Oximeter (SpO2) services in combination with MikroElektronika’s MIKROE-4037 Heart Rate 2 Click mikroBUS board, containing Maxim Integrated’s MAX86161 biosensor. The MAX86161 provides a complete low-power subsystem able to provide accurate HR and SpO2 measurements to a host processor connected through its I2C interface. (For more on using the MAX86161, see Build a True Wireless Fitness Hearable—Part 1: Heart Rate and SpO2 Measurement).

With its need for an additional driver and a more demanding processing algorithm than in the temperature application, this application provides a more complex demonstration of an IoT device software application architecture (Figure 5).

Diagram of HR/SpO2 applicationFigure 5: Sample projects such as an HR/SpO2 application help speed prototype development while demonstrating a typical process flow for low-power Bluetooth sensor applications. (Image source: Silicon Labs)

As with the temperature application mentioned above, this application relies on a series of initialization routines to set up the system and application services. Where the routine app_process_action is empty in the temperature application, this application adds a call to a routine, hrm_loop, in app_process_action. This results in a call to hrm_loop on each pass through the top-level endless loop shown earlier in Listing 1. In addition, a software timer is used to periodically update HR and SpO2 data.

The hrm_loop routine in turn calls maxm86161_hrm_process, which pulls samples from a queue maintained by helper functions and hands them off to a sample process routine. This, in turn, calls a pair of routines, maxm86161_hrm_frame_process and maxm86161_hrm_spo2_frame_process, which execute algorithms to validate and generate HR and SpO2 results, respectively. Developers can view the results along with other service characteristics using the EFR Connect app mentioned earlier.

Another sample software application shows how developers can build on a complex application such as this HR/SpO2 application when they extend their hardware platform. Using the BGM220-EK4314A Explorer Kit board and the SiLabs software ecosystem, building on existing hardware and software is relatively straightforward. SiLabs demonstrates this approach with a sample application that adds an OLED display to the hardware/software platform used for the HR/SpO2 application above. In this example, a SparkFun OLED display Qwiic add-on board (LCD-14532) is attached to the board’s Qwiic connector, while the MikroElektronika Heart Rate 2 Click add-on board stays in place from the previous HR/SpO2 sample application (Figure 6).

Image of Silicon Labs BGM220-EK4314A Explorer Kit board with OLED displayFigure 6: Developers can quickly add functionality to an existing design built on the BGM220-EK4314A Explorer Kit board—here adding an OLED display to an existing HR/SpO2 prototype. (Image source: Silicon Labs)

Other than the addition of a driver and support services for the OLED board, the software application remains largely the same for this extended version of the HR/SpO2 application. The software timer mentioned earlier for the HR/SpO2 application adds a call to the function hrm_update_display, which displays the HR and SpO2 data (Listing 2).

    /* Software Timer event */
    case sl_bt_evt_system_soft_timer_id:
      /* Check which software timer handle is in question */
      if (evt->data.evt_system_soft_timer.handle == HEART_RATE_TIMER) {
      if (evt->data.evt_system_soft_timer.handle == PULSE_OXIMETER_TIMER) {
      if (evt->data.evt_system_soft_timer.handle == DISPLAY_TIMER) {
Listing 2: Using the kit and software ecosystem, developers can add display functionality to an existing HR/SpO2 application by connecting a display board and making minimal software changes beyond adding a function call, hrm_update_display, to the existing application’s software timer handler. (Code source: Silicon Labs)

This extensible hardware and software approach allows developers to quickly build working IoT applications. Because both hardware and software can be easily added or removed, developers can more easily explore new design solutions and evaluate alternative configurations.


Battery-powered Bluetooth-enabled IoT devices lie at the heart of popular applications and provide the key enabler to meet continuing demand for more functionality and longer operating life. For developers, meeting these conflicting demands effectively requires the ability to rapidly explore new designs and evaluate alternative design concepts. Using a development kit and associated software from Silicon Labs, developers can rapidly build prototypes, adding and removing hardware as needed to meet specific application requirements.

Disclaimer: The opinions, beliefs, and viewpoints expressed by the various authors and/or forum participants on this website do not necessarily reflect the opinions, beliefs, and viewpoints of Digi-Key Electronics or official policies of Digi-Key Electronics.

About this author

Stephen Evanczuk

Stephen Evanczuk has more than 20 years of experience writing for and about the electronics industry on a wide range of topics including hardware, software, systems, and applications including the IoT. He received his Ph.D. in neuroscience on neuronal networks and worked in the aerospace industry on massively distributed secure systems and algorithm acceleration methods. Currently, when he's not writing articles on technology and engineering, he's working on applications of deep learning to recognition and recommendation systems.

About this publisher

Digi-Key's North American Editors