Original Title：Add Continuous Wi-Fi Connectivity Without Compromising Battery Life

　　Offering high bandwidth and ubiquity, Wi-Fi remains a primary connectivity requirement for many Internet of Things (IoT) devices. However, for wearables and other battery-powered IoT devices, the power requirements of conventional Wi-Fi solutions have made continuous Wi-Fi connectivity impractical, typically requiring developers to compromise some aspect of device functionality, performance, or battery life.

　　While designing a custom Wi-Fi solution to optimize for low power might be an option for some teams, this can be an expensive and time-consuming undertaking, especially given the scarcity of qualified RF designers. A more complete solution is required that also makes continuous Wi-Fi practical for low-power IoT devices.

　　This article shows how developers can implement continuous Wi-Fi connectivity using low power features built into a wireless system-on-chip (SoC) device from Dialog Semiconductor.

　　The challenges of supporting Wi-Fi connectivity for mobile devices

　　Wi-Fi typically provides the combination of ubiquitous presence and performance characteristics required in a wide range of IoT applications built around personal mobile products, smart home devices, and building automation systems, just to mention a few. In the past, however, the relatively high current consumption of Wi-Fi subsystems forced developers to compromise battery lifetime or signal strength in battery-powered IoT devices.

　　The high power requirements of traditional Wi-Fi solutions bring additional challenges to IoT developers. For example, requirements for both Wi-Fi connectivity and extended battery life can add to design size and complexity to accommodate larger batteries. For wearables or many IoT devices where larger batteries might not be an option, attempts to extend battery life by reducing Wi-Fi signal strength (and associated power consumption) might not be feasible.

　　Along with these concerns, IoT developers face practical limitations of the typical Wi-Fi signal environment where signal strength can vary significantly due to multipath interference and other radio frequency (RF) signal characteristics. In applications such as laptops, a consumer can simply move a laptop to a different location with a better Wi-Fi signal. In contrast, a smart lock or home appliance needs to maintain reliable connectivity and robust performance, regardless of where it is installed.

　　To support both extended battery life and robust Wi-Fi signal strength, developers typically take full advantage of low-power sleep modes available in most advanced processors, radios, and other complex hardware components. By maximizing the amount of time power-hungry devices spend in their respective low power modes, developers can implement designs that extend the battery life of their system designs, typically with little impact on system functionality. In these designs, a low-power timer might periodically wake the system briefly to read sensors and wirelessly transmit sensor data before returning to sleep mode.

　　For some IoT applications, however, the IoT device needs to maintain a continuous connection to the Wi-Fi network to ensure a quick response to user commands issued through mobile apps, desktop software, or even other devices. For example, smart locks, lights, and switches found in smart homes need to stay connected to provide an instant response to user commands. Waiting for a timer-based device to eventually wake, detect the command, and finally unlock a door or turn on a light would simply be unacceptable to users.

　　Dialog Semiconductor's DA16200 SoC and associated modules provide an effective low-power solution able to support requirements for both continuous Wi-Fi connectivity and extended battery life.

　　Implementing Wi-Fi connectivity with a wireless SoC

　　Designed specifically for battery-powered IoT designs, the DA16200 SoC combines an Arm® Cortex®-M4F with a complete Wi-Fi radio subsystem running a full network stack, eliminating the need for an external network processor or a host processor to provide stack functionality. Along with the radio subsystem, the device integrates a full set of functional blocks and interfaces typically required in IoT designs (Figure 1).

　　Figure 1: The Dialog Semiconductor DA16200 SoC provides a complete Wi-Fi solution capable of delivering continuous Wi-Fi connectivity while consuming minimal current. (Image source: Dialog Semiconductor)

　　Along with multiple standard interfaces, the device includes a 4-channel 12-bit successive approximation register (SAR) analog-to-digital converter (ADC) to support analog signal acquisition.

　　For application execution, the DA16200 contains multiple internal memories including:

　　Read-only memory for a boot loader, system kernel, network stack and drivers.

　　Static random access memory (SRAM) for program data. Program code executes in place (XIP) on serial flash memory accessed through the device's external serial flash memory interface.

　　One-time programmable (OTP) memory used to store device information as well as cryptography keys and a secure boot loader. OTP data remains secure because it can only be accessed through the OTP controller and otherwise remain invisible to normal data access through the system bus.

　　To help developers meet the growing demand for connected device security, the DA16200 SoC integrates a wide set of security mechanisms including a cryptography engine for Advanced Encryption Standard (AES), Secure Hash Algorithms (SHA), and other ciphers as well as support for the Transport Layer Security (TLS) protocol. The device also includes the Arm TrustZone CryptoCell-312 (CC312) security intellectual property (IP). Designed for low-power devices, CC312 supports secure boot and enables a root of trust for secure applications.

　　The device simplifies Wi-Fi connectivity thanks to a comprehensive RF block. Along with built-in 802.11 media access control (MAC) and 802.11b/g/n physical (PHY) layers, the radio subsystem includes an on-chip transceiver with integrated power amplifiers (PAs) and low-noise amplifiers (LNAs) that eliminate the need for external active components. In operation, the DA16200's Arm Cortex-M4F processor executes an embedded transmission control protocol/Internet protocol (TCP/IP) stack to offload connectivity operations from a system's host processor.

　　To power its various blocks, including the RF block, the DA16200 SoC integrates a DC-DC converter, low dropout (LDO) regulators, and power switches. Managed by the device's real-time clock (RTC) block, the converter and LDOs generate all the required supply rails from a single VBAT battery supply. While the DC-DC converter generates 1.4 volts for the RF block and digital LDO from VBAT, the I/O LDO generates the 1.8 volts required for external flash and the device's general purpose I/O (GPIO) (Figure 2).

　　Figure 2: The DA16200 SoC's power management unit controls the device's integrated power components supplying voltage to its separate power domains. (Image source: Dialog Semiconductor)

　　The DA16200 SoC's power management unit controls the supply to these separate power domains as part of its function in managing the device's three low-power (sleep) modes:

　　Sleep 1 offers the lowest power operation at 0.2 microamperes (μA): In this mode, the device is largely powered off but wakes within 150 milliseconds (ms) in response to an external trigger delivered to the SoC's two wake-up pins or to one of several digital I/Os, or when an analog input signal exceeds a predefined threshold.

　　Sleep 2 consumes only 1.8 μA while retaining RTC functionality: In this mode, the SoC wakes in less than 100 ms in response to external wake up events or at the completion of a programmed internal timer.

　　Sleep 3 provides a unique continuously connected Wi-Fi mode that can consume minimal current and wakes in less than 2 ms upon detection of incoming Wi-Fi data packets: As described below, use of Sleep 3 with conventional TCP keepalive functionality provides the basis for implementing a continuous Wi-Fi connectivity capability that consumes less than 50 μA average current.

　　Dynamic power management technology enables continuous Wi-Fi connectivity

　　Underlying these low-power sleep modes is Dialog Semiconductor's proprietary Dynamic Power Management (DPM) technology which shuts down unused on-chip micro elements, resulting in minimal power consumption when the device is not transmitting or receiving data. During Wi-Fi operations, DPM minimizes power consumption during transmit and receive radio operations using advanced algorithms to wake needed micro elements just when they are needed.

　　Dialog Semiconductor's DA16200 software development kit (SDK) abstracts the details of power management and DPM operation with its DPM Manager application programming interface (API). For custom software development, the SDK provides access to the DA16200 software stack of application and system services (Figure 3).

　　Figure 3: The DA16200 SoC's software architecture provides a full set of system and application services required to support standard Wi-Fi connectivity in IoT devices. (Image source: Dialog Semiconductor)

　　Implementation of continuous Wi-Fi connectivity combines use of the DPM Manager and the NetX Duo TCP/IP library. The NetX Duo library provides a TCP keepalive feature that sends a TCP packet with no data to a Wi-Fi router, ensuring that the router keeps the Wi-Fi connection active. Developers invoke this feature simply by setting the current TCP socket option, keepalive_enabled, to true, and provide the number of seconds, keepalive_timeout, between keepalive packets. NetX Duo automatically transmits the keepalive frames as needed.

　　While the keepalive packets maintain the network connection with a router or other host, the DA16200's ability to wake from Sleep 3 mode relies on detection of standard Traffic Indication Map (TIM) or Delivery Traffic Indication Map (DTIM) information elements embedded in 802.11 management frames, and is used to notify network stations such as a DA16200-based system that network traffic is available for it. When the DA16200 is placed in Sleep 3 mode, the DA16200's DPM technology ensures that the radio subsystem uses minimal power looking for TIM/DTIM elements. When the DA16200 radio subsystem detects TIM/DTIM elements, it wakes the SoC to begin processing normal Wi-Fi traffic, like any network station.

　　Using the DA16200 DPM Manager API, developers need only make a few intuitive calls to implement this functionality. After defining the required DPM configuration, including parameters and callbacks, developers use DPM Manager API function calls to invoke and otherwise interact with the DPM Manager. Entry into and exit from Sleep 3 is handled transparently by the DA16200 DPM's technology.

　　Sample applications included in the SDK illustrate the basic design patterns required to implement this sequence of operations (Listing 1).

　　Copy

　　#define TCP_CLIENT_KA_DPM_SAMPLE_DEF_KEEPALIVE_TIMEOUT 55

　　[lines deleted]

　　void tcp_client_ka_dpm_sample_wakeup_callback()

　　{

　　PRINTF(GREEN_COLOR " [%s] DPM Wakeup " CLEAR_COLOR, __func__);

　　dpm_mng_job_done(); //Done operation

　　}

　　[lines deleted]

　　void tcp_client_ka_dpm_sample_recv_callback(void *sock, UCHAR *rx_buf, UINT rx_len,

　　ULONG rx_ip, ULONG rx_port)

　　{

　　int status = NX_SUCCESS;

　　//Display received packet

　　PRINTF(" =====> Received Packet(%ld) ", rx_len);

　　tcp_client_ka_dpm_sample_hex_dump("Received Packet", rx_buf, rx_len);

　　[lines deleted]

　　dpm_mng_job_done(); //Done operation

　　}

　　[lines deleted]

　　void tcp_client_ka_dpm_sample_init_user_config(dpm_user_config_t *user_config)

　　{

　　[lines deleted]

　　//Set DPM wakeup init callback

　　user_config->wakeupInitCallback = tcp_client_ka_dpm_sample_wakeup_callback;

　　[lines deleted]

　　//Set Recv callback

　　user_config->sessionConfig[session_idx].session_recvCallback =

　　tcp_client_ka_dpm_sample_recv_callback;

　　[lines deleted]

　　//Set KeepAlive timeout

　　user_config->sessionConfig[session_idx].session_ka_interval =

　　TCP_CLIENT_KA_DPM_SAMPLE_DEF_KEEPALIVE_TIMEOUT;

　　[lines deleted]

　　}

　　[lines deleted]

　　void tcp_client_ka_dpm_sample(ULONG arg)

　　{

　　[lines deleted]

　　//Register user configuration

　　dpm_mng_regist_config_cb(tcp_client_ka_dpm_sample_init_user_config);

　　//Start TCP Client Sample

　　dpm_mng_start();

　　return ;

　　}

　　Listing 1: Using the DA16200 SoC, developers can implement continuous Wi-Fi connectivity using configurations and a few DPM API function calls. (Code source: Dialog Semiconductor)

　　As shown in Listing 1, developers implement this capability largely using only an initialization function (tcp_client_ka_dpm_sample_init_user_config()) that sets various configuration parameters including the keepalive interval (TCP_CLIENT_KA_DPM_SAMPLE_DEF_KEEPALIVE_TIMEOUT), and provides various callbacks including those for DMP wakeup (tcp_client_ka_dpm_sample_wakeup_callback()) and for processing incoming data packets (tcp_client_ka_dpm_sample_recv_callback()). To begin the TCP keepalive and DPM wakeup sequence, a separate function (tcp_client_ka_dpm_sample()) simply invokes a configuration routine (dpm_mng_regist_config_cb(tcp_client_ka_dpm_sample_init_user_config)) and the DMP Manager (dpm_mng_start()).

　　As mentioned earlier, this entire sequence, including standard TCP keepalive packets and DA16200 DPM-enabled Wi-Fi monitoring, results in a continuous Wi-Fi connectivity capability that typically consumes less than 50 μA average current.

　　This same design pattern can be used to wake the SoC from its sleep modes to handle other operations. For example, a sample application shows use of the DA16200's RTC to wake the SoC to process data (Listing 2).

　　Copy

　　#define SAMPLE_FOR_DPM_SLEEP_3 // Sleep Mode 3

　　#define MICROSEC_FOR_ONE_SEC 1000000

　　#define RTC_TIMER_WAKEUP_ONCE 5 // seconds

　　#define RTC_TIMER_WAKEUP_PERIOD 10 // seconds

　　static void rtc_timer_dpm_once_cb(char *timer_name)

　　{

　　[lines deleted]

　　static void rtc_timer_dpm_periodic_cb(char *timer_name)

　　{

　　/*

　　*Caution : Don't spend a lot of time in the calback function called by timer.

　　*/

　　dpm_app_sleep_ready_clear(SAMPLE_RTC_TIMER);

　　PRINTF(" Wakeup due to Periodic RTC timer!!! ");

　　tx_thread_sleep(10);

　　dpm_app_sleep_ready_set(SAMPLE_RTC_TIMER);

　　}

　　[lines deleted]

　　void rtc_timer_sample(ULONG arg)

　　{

　　[lines deleted]

　　/* Periodic timer */

　　status = dpm_timer_create(SAMPLE_RTC_TIMER,

　　"timer2",

　　rtc_timer_dpm_periodic_cb,

　　RTC_TIMER_WAKEUP_PERIOD,

　　RTC_TIMER_WAKEUP_PERIOD);

　　[lines deleted]

　　dpm_app_sleep_ready_set(SAMPLE_RTC_TIMER);

　　[lines deleted]

　　}

　　while (1)

　　{

　　/* Nothing to do... */

　　tx_thread_sleep(100);

　　}

　　}

　　Listing 2: Developers can implement low-power timer-based functionality with the DA16200 using a few DPM API function calls to ensure minimal power consumption during DA16200 sleep periods. (Code source: Dialog Semiconductor)

　　As shown in Listing 2, the developer calls a DPM Manager API function (dpm_timer_create()) to create a timer (SAMPLE_RTC_TIMER) and another DPM Manager API function (dpm_app_sleep_ready_set()) to indicate that the system is ready to go back to sleep. The DPM engine will then determine how quickly the system can return to low-power sleep mode based on current activity. Later, when the timer runs out, the system executes the developer's callback function, rtc_timer_dpm_periodic_cb(), which performs the required operations—in this case, simply printing a notification to the console. When the operation has completed, the same callback function performs the dpm_app_sleep_ready_set() to notify the DPM engine that the system is ready to go back to sleep. As before, the DPM engine completes the transition to sleep mode when appropriate.

　　Drop-in modules simplify Wi-Fi design

　　While the DA16200 SDK simplifies software design, the device's extensive on-chip functionality translates into a relatively simple hardware interface design. Using the DA16200 SoC along with an external flash device, such as Winbond Electronics' W25Q16JVSNIQ 16 megabit (Mbit) NOR memory IC and only a few additional components, developers can implement a Wi-Fi-enabled secure IoT design (Figure 4).

　　Figure 4: With its extensive integrated functionality, the Dialog Semiconductor DA16200 SoC requires only an external serial flash and minimal additional components to implement a complete Wi-Fi system. (Image source: Dialog Semiconductor)

　　Developers looking to speed development of their own designs based on the DA16200 SoC can turn to Dialog Semiconductor modules that eliminate the need for them to implement the SoC's hardware interface. Along with the DA16200 SoC, the modules include 4 megabytes (Mbytes) of flash, RF components, and choice of an on-board chip antenna (DA16200MOD-AAC4WA32) or u.FL connector for an external antenna (DA16200MOD-AAE4WA32). Fully certified by the FCC, IC, CE and other regulatory bodies, the 13.8 x 22.1 x 3.3 millimeter (mm) modules provide a drop-in hardware solution for implementing low-power continuous Wi-Fi connectivity.

　　Developers looking to explore continuous Wi-Fi connectivity and rapidly prototype IoT designs based on the DA16200 SoC can take immediate advantage of the Dialog Semiconductor DA16200MOD-DEVKT development kit. This kit combines a DA16200MOD module with a USB interface, keys, and connections to help speed development and debugging of DA16200-based designs.

　　Conclusion

　　The ability to maintain continuous Wi-Fi connectivity is a routine feature of laptops and other connected products. For wearables and other battery-powered IoT devices, however, the power requirements of conventional Wi-Fi solutions have made continuous Wi-Fi connectivity impractical, typically requiring developers to compromise some aspect of device functionality, performance, or battery life.

　　A SoC from Dialog Semiconductor provides a complete Wi-Fi solution able to deliver continuous Wi-Fi connectivity while consuming minimal current. As shown, using the SoC or its associated modules, developers can rapidly implement secure battery-powered devices able to provide users with the advantages of continuous Wi-Fi connectivity while meeting their expectations for extended battery life.