How to Maximize Battery Life in Dual-Mode Wi-Fi/Bluetooth IoT Designs

By Stephen Evanczuk

Contributed By Digi-Key's North American Editors

Designers of battery-powered Internet of Things (IoT) devices and other connected products are being asked to meet the conflicting requirements of continuous wireless connectivity and extended battery life. Further stretching already constrained power limits is the growing demand for both Bluetooth 5 and Wi-Fi connectivity in the same device. Although Wi-Fi and Bluetooth protocols provide standard protocols to help reduce power consumption, more direct support comes in the form of an architecture that combines radio subsystems that can offload network processing tasks with a low-power microcontroller.

This article will outline the importance of dual-mode Wi-Fi/Bluetooth connectivity and how it complicates IoT designs. It will then show how a development board and associated software from Cypress Semiconductor can be used for development of dual-mode Wi-Fi/Bluetooth IoT devices capable of continuous connectivity and longer battery life.

The growing need for dual mode Wi-Fi/Bluetooth continuous connectivity

Bluetooth connectivity is considered a standard requirement for many IoT devices designed to interact with users through Bluetooth-enabled smartphones and other mobile devices. For many IoT applications, however, IoT devices need Wi-Fi connectivity to access a wireless local area network (WLAN) to reach the Internet directly, or to interact with other peer devices and host systems on the same network.

In many ways, developers' ability to extend battery life would be much more straightforward if these IoT devices only needed to connect to the WLAN or Bluetooth host when they needed to transmit their data or other messages. Because the active duty cycle for many IoT devices is typically low, these devices could stretch battery life by operating predominately in low-power sleep mode, waking long enough to perform sensor measurements, complete related processing tasks, and transmit the resulting data before returning to low-power mode. In reality, most IoT devices need to respond rapidly to asynchronous incoming commands and data from peer devices, host systems and end users.

To remain responsive, IoT devices need to provide the appearance of continuous connectivity, remaining alert to incoming traffic so they can respond within an acceptable period of time. If developers attempt to satisfy this fundamental requirement by repeatedly waking their devices to receive incoming traffic, their device's battery will quickly become depleted. In fact, radio receivers in battery-powered Wi-Fi devices will typically consume more power over time than radio transmitters, despite the higher power consumption associated with an individual transmission operation. Of course, the power consumed by the device's host processor for its part in each receive operation adds its own substantial load to the power budget. Fortunately, wireless standards define protocols that let developers reduce power while still maintaining the illusion of continuous connectivity.

How wireless connectivity standards help devices reduce power consumption

In normal operation, Wi-Fi receiving stations (STAs) save power by powering down most of their Wi-Fi subsystem. Because access points (APs) buffer frames for sleeping STAs, no messages are lost. As part of their normal network management operations, APs regularly transmit beacons that contain a bitmap, called a traffic indication map (TIM), which indicates if the AP has waiting traffic for each STA. APs also periodically transmit a beacon that contains a delivery traffic indication map (DTIM), which indicates the availability of buffered multicast or broadcast data. STAs are expected to wake up regularly within the DTIM period value, which is some multiple of the normal beacon interval. An IoT network configured with a high DTIM period value would enable devices in its network to reduce power consumption because they could sleep longer before waking their receiver to receive a beacon indicating that the AP is holding frames for it. This is the fundamental approach behind the standard 802.11 power save poll mechanism discussed below.

Bluetooth low energy (BLE) lets devices reduce power consumption by optimizing its Bluetooth advertising frequency and payload. By increasing the advertising interval, IoT devices can delay transmitter operations; by decreasing the payload, IoT devices can reduce the duration of transmitter events. Of course, not every application can tolerate long advertising intervals or minimal payloads. In an audio or real-time sensing device, for example, long advertising intervals mean delayed connections that could adversely affect the behavior of the application as a whole.

Peripheral devices can use another BLE feature called slave latency which allows the peripheral to skip connection events. As with Wi-Fi DTIM, BLE slave latency allows devices to remain in low-power mode for a longer period of time. Rather than simply increasing the connection interval, this special mode allows the peripheral device to skip connection events with a host, but nevertheless wake and send data as needed without incurring additional latency.

Support for dual-mode connectivity and extended battery life

These methods help reduce the duration and frequency of full power operation in Wi-Fi and Bluetooth devices, but developers can do much more to extend battery life using hardware and software capabilities demonstrated in the Cypress Semiconductor CY8CKIT-062S2-43012 Wi-Fi BT Pioneer Kit. Along with jumper wires and a USB cable, the Cypress kit includes the PSoC 62S2 Wi-Fi BT Pioneer board, which provides a comprehensive development platform and a full-featured hardware system for implementing low-power IoT designs. Used with Cypress software, the Cypress kit allows developers to immediately evaluate and rapidly deploy a variety of sophisticated power management capabilities.

Along with multiple interface connectors, buttons and LEDs, the kit's board integrates a CY8C5868LTI-LP038 PSoC 5LP device that provides Cypress KitProg3 onboard programming and debugging. For additional onboard storage, Cypress integrates its S25FL512S 512 megabit (Mbit) serial NOR flash memory device and its CY15B104 4 Mbit serial ferroelectric random access memory (FRAM) (Figure 1).

Diagram of Cypress PSoC 62S2 Wi-Fi BT Pioneer board (click to enlarge)Figure 1: The Cypress PSoC 62S2 Wi-Fi BT Pioneer board provides a comprehensive set of system features built around a carrier module that integrates a PSoC 6 microcontroller and a Wi-Fi/Bluetooth wireless connectivity module. (Image source: Cypress Semiconductor)

At the heart of the board, a carrier module integrates a Cypress Semiconductor PSoC 6 microcontroller and a Murata Electronics Type 1LV LBEE59B1LV wireless connectivity module with passive components. A radio frequency (RF) switch and a dual-band 2.45 gigahertz (GHz)/5 GHz mini chip antenna round out the support devices.

Designed specifically to eliminate the conventional tradeoff between processing performance and power consumption, the PSoC 6 integrates a 150 megahertz (MHz) Arm® Cortex®-M4, which serves as the primary application processor, and a 100 MHz Arm Cortex-M0+, which handles low-power operation. Along with integrated flash and static RAM (SRAM), the PSoC6 includes a cryptography engine, programmable analog and digital peripherals, CapSense touch sensing support, and multiple system interfaces (Figure 2).

Diagram of Cypress PSoC 62S2 Wi-Fi BT Pioneer board's carrier module (click to enlarge)Figure 2: Built into the Cypress PSoC 62S2 Wi-Fi BT Pioneer board's carrier module, a PSoC 6 microcontroller uses a multicore architecture to meet requirements for both application processing and low-power real-time execution. (Image source: Cypress Semiconductor)

The Murata LBEE59B1LV module provides a complete radio subsystem in a 10.0 x 7.2 x 1.4 millimeter (mm) package that holds a Cypress CYW43012 Wireless Internet Connectivity for Embedded Devices (WICED) Wi-Fi + Bluetooth device, reference clock and filters (Figure 3).

Diagram of Murata Type 1LV LBEE59B1LV wireless connectivity moduleFigure 3: The Murata Type 1LV LBEE59B1LV wireless connectivity module provides a complete, pre-certified Wi-Fi + Bluetooth radio subsystem built around a Cypress CYW43012 WICED device. (Image source: Murata Electronics)

The module supports 2.4 GHz and 5 GHz wireless connectivity with Bluetooth 5.0 and Wi-Fi 802.11a/b/g/n. In addition, the module provides an 802.11ac-friendly mode, which supports 802.11ac’s 256 quadrature amplitude modulation (QAM) for the 20 MHz channels in the 5 GHz band, offering higher throughput and lower energy per bit than 802.11n-only products. Designed to speed development, the Murata LBEE59B1LV module is pre-certified in multiple regions, eliminating the lengthy delays associated with compliance testing and certification.

Within the module, the Cypress WICED device integrates an Arm Cortex-M3 processor and Arm Cortex-M4 processor in the Wi-Fi and Bluetooth subsystems, respectively. Although it is not available for customer code, the Arm Cortex-M3 processor runs Cypress firmware that supports Wi-Fi operations and additional functionality, including offload functionality described below. The Arm Cortex-M4 in the Bluetooth subsystem runs Bluetooth controller firmware, Bluetooth stack, and profiles. In addition, this core can run customer code programmed using the Cypress WICED software development kit (SDK).

Using power saving methods in wireless IoT designs

Designed to minimize power consumption, the PSoC 6 and wireless connectivity module feature a comprehensive set of power modes and power reduction capabilities. Cypress backs this power efficient hardware platform with a substantial software complement designed to simplify use of power saving methods in wireless IoT designs. For example, developers can easily implement the power save poll method mentioned earlier using the independent embedded Wi-Fi host driver (WHD) library.

Developers simply call the WHD application programming interface (API) function whd_wifi_enable_powersave() to enable power save poll and whd_wifi_disable_powersave() to later disable it in the device. When enabled, the STA notifies the AP that it has gone to sleep. As mentioned earlier, the AP buffers any frames intended for the sleeping STA and configures its periodic beacon to indicate that frames are available. When the STA wakes to check the beacon, it begins a standard process to retrieve those frames.

Although the power save poll mechanism is intended for STAs with low duty cycles, a similar method, called power save without poll, supports STAs with higher throughput requirements. Here, the STA transmits a null function data frame, which initiates frame transfer from the AP.

Power save poll and power save without poll allow devices to reduce receiver operations but do not help eliminate unneeded transactions related to network operations overhead. For example, any network including an IoT WLAN will carry unwanted packet traffic when connected to an external network, particularly the public Internet. The ability to filter out those packets within the communications subsystem without involving the IoT device's host processor would allow the host processor to remain in low-power sleep mode.

Besides unwanted packets, legitimate network traffic could cause the host processor to wake needlessly. For example, the Wi-Fi standard address resolution protocol (ARP) uses broadcast packets as part of its function to map an IP address associated with a device to the device's media access control (MAC) address. This operation is essential for normal WLAN function, allowing devices to reach others in their network, detect duplicate IP addresses, and notify other devices if an IP address is changed for any reason.

ARP request and response packets are so fundamental to network operations that an IoT device's host processor can become overburdened simply processing ARP requests and responses. If the device's WLAN interface simply passes requests and responses between the host and the network, each ARP request will wake the host, sometimes unnecessarily.

In contrast, the Murata wireless connectivity module intervenes in this exchange, offloading ARP request handling from the PSoC 6 microcontroller. When the PSoC 6 is otherwise engaged in its primary IoT application functionality, this capability preserves processor cycles for application execution. If the PSoC 6 is in sleep mode, this capability helps reduce overall IoT device power consumption. By enabling ARP offload with peer auto reply, the Murata module will only wake the PSoC 6 if an incoming ARP request cannot be satisfied by entries cached in the Murata module (Figure 4, left).

Diagram of ARP offloading intercepts ARP requests from the network or host processor (click to enlarge)Figure 4: When enabled, ARP offloading intercepts ARP requests from the network (left) or host processor (right), automatically responding when cache satisfies the request (top) and only waking the processor on cache misses (bottom). (Image source: Cypress Semiconductor)

This same approach can also help reduce WLAN power consumption. In normal operation, the Murata module can monitor (snoop) network traffic and cache IP:MAC pairs from other ARP responses. Using host auto reply, the Murata module can reply to ARP requests from the PSoC 6, invoking its radio subsystem only if the PSoC 6's request cannot be satisfied from ARP cache (Figure 4, right).

Simple menu-based implementation of power saving features

Implementing ARP offloading with the Pioneer kit is remarkably simple. Included in the Cypress ModusToolBox (MTB) integrated development environment (IDE), the Cypress Device Configurator tool allows developers to deploy this capability with a few menu selections. Cypress provides prebuilt configuration files that allow developers to quickly select different configurations including ARP offloading.

Using the Device Configurator tool to explicitly define configurations is nearly as straightforward. Developers use the tool's menu options to enable the host wake pin, name the pin (CYBSP_WIFI_HOST_WAKE), and set the pin parameters (Figure 5).

Image of Cypress Device Configurator tool (click to enlarge)Figure 5: The Cypress Device Configurator tool allows developers to use menus to set power saving options available with the Pioneer board. (Image source: Cypress Semiconductor)

In the tool's Wi-Fi tab, developers enable host wake and set the interrupt pin to the name entered earlier (CYBSP_WIFI_HOST_WAKE). Additional menu entries enable ARP offloading, set the feature to peer auto reply, enable network snooping, and set the cache entry expiration time (Figure 6).

Image of additional menu tabs in the Cypress Device Configurator toolFigure 6: Using additional menu tabs in the Cypress Device Configurator tool, developers can enable ARP offloading and specific features such as peer auto reply. (Image source: Cypress Semiconductor)

After saving the configuration, developers simply generate source files, build the modified project and program the Pioneer board. Using a similar procedure, developers can configure the Murata module to offload Wi-Fi packet filtering and deal with other common types of network operations. This same approach even allows an IoT device to perform the Wi-Fi TCP keep alive protocol needed to maintain Wi-Fi connectivity—all without waking the IoT host processor.

In normal WLAN operations, a client device and host server maintain TCP connections by exchanging keep alive packets. If either side of this exchange does not receive a response after a few tries, it terminates the connection. Even in power-constrained IoT devices, the host processor must continually wake up to participate in this exchange or use even more power to continually reestablish connections.

As with ARP offloading, developers can use Device Configurator tool to enable TCP keep alive offloading. Once this feature is enabled, the Murata module automatically executes the keep alive protocol without waking the PSoC 6 (Figure 7).

Diagram of WLAN device automatically performing the keep alive protocol (click to enlarge)Figure 7: When TCP keep alive offload is enabled, the wireless connectivity module (WLAN device) automatically performs the keep alive protocol, permitting the host processor to remain in low-power sleep mode. (Image source: Cypress Semiconductor)

Although Cypress recommends use of the Device Configurator tool as the easiest path to implementation, developers can also manually implement the Cypress platform's power saving features including ARP offloading, packet filtering, TCP keep alive offloading, and others.

Underlying both approaches is Cypress's Low Power Assistant (LPA) middleware which supports these power saving features for Wi-Fi, Bluetooth and the PSoC 6 microcontroller, along with other features beyond those mentioned here.

After the developer defines configurations using menus or by adding configuration code manually, the LPA firmware operates transparent to the application, automatically orchestrating use of low-power hardware features and software capabilities.


The need for continuous wireless connectivity and extended battery life in IoT devices presents conflicting requirements for designers that are only exacerbated by the need to support both Wi-Fi and Bluetooth. As shown, by combining a radio subsystem able to offload network processing tasks with a low-power microcontroller, the Cypress Semiconductor CY8CKIT-062S2-43012 Wi-Fi BT Pioneer Kit allows designers to meet their IoT wireless connectivity and low-power 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