How to maximise battery life in dual-mode WiFi/Bluetooth IoT designs

Further stretching already constrained power limits is the growing demand for both Bluetooth 5 and WiFi connectivity in the same device. Although WiFi 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 WiFi/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 WiFi/Bluetooth IoT devices capable of continuous connectivity and longer battery life.

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

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 WiFi 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 WiFi 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.

Reducing power

In normal operation, WiFi receiving stations (STAs) save power by powering down most of their WiFi 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 later.

Above: Figure 2. Built into the Cypress PSoC 62S2 WiFi 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)

Bluetooth low energy (BLE) lets devices reduce power consumption by optimising 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 behaviour 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 WiFi 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.

Dual-mode connectivity

These methods help reduce the duration and frequency of full power operation in WiFi 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 WiFi BT Pioneer Kit. Along with jumper wires and a USB cable, the Cypress kit includes the PSoC 62S2 WiFi 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).

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

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 150MHz Arm Cortex-M4, which serves as the primary application processor, and a 100MHz Arm Cortex-M0+, which handles low-power operation. Along with integrated flash and static RAM (SRAM), the PSoC6 includes a cryptography engine, programmable analogue and digital peripherals, CapSense touch sensing support, and multiple system interfaces (Figure 2).

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

Above: 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)

The module supports 2.4GHz and 5GHz 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 20MHz channels in the 5GHz 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 WiFi and Bluetooth subsystems, respectively. Although it is not available for customer code, the Arm Cortex-M3 processor runs Cypress firmware that supports WiFi operations and additional functionality, including offload functionality described later. 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).

Power saving methods

Designed to minimise 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 WiFi 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.

Above: 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)

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 WiFi 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).

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).

Menu-based implementation of power saving

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 pre-built 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).

In the tool’s WiFi 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).

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 WiFi packet filtering and deal with other common types of network operations. This same approach even allows an IoT device to perform the WiFi TCP keep alive protocol needed to maintain WiFi 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 re-establish connections.

Above: Figure 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)

As with ARP offloading, developers can use the 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).

Although Cypress recommends the 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 WiFi, Bluetooth and the PSoC 6 microcontroller, along with other features beyond those mentioned here.

Above: 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)

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.

Conclusion

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 WiFi 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 WiFi BT Pioneer Kit allows designers to meet their IoT wireless connectivity and low-power requirements.