Wi-Fi may not be the first wireless technology one thinks of when considering low power IoT applications, but it should be. In this Q&A, Silicon Labs’ senior product manager for Wi-Fi products Siddharth Sundar discusses Wi-Fi's advantages and challenges that developers should keep in mind when choosing the right approach to wireless IoT.

What are the advantages to using Wi-Fi in low power IoT applications?

Being a widely deployed protocol with approximately 13 billion deployed devices means that Wi-Fi connectivity is available in most home and commercial/office environments. This avoids the need for a gateway and lets devices be cloud connected without needing new infrastructure. Wi-Fi is also highly interoperable, so you can have confidence that your devices will connect to most Wi-Fi networks out there. The higher data rates and range offered by Wi-Fi also enable a wider range of applications.

How does Wi-Fi compare to other IoT wireless communication protocols?

Wi-Fi has significantly higher data throughput than most other IoT wireless communication protocols – often 10-100x higher, allowing it to tackle higher throughput applications like audio and video. The broad deployment and range of Wi-Fi is also a significant benefit compared to many other protocols.

These benefits do come at a cost. Wi-Fi products typically have higher power consumption and higher implementation costs than IoT specific protocols like BLE and Zigbee, since the range and throughput offered by Wi-Fi demands higher design complexity. However, most of this design complexity can be managed through using pre-certified modules, and the cost and power consumption of Wi-Fi devices is decreasing to a point where it is competitive for many IoT applications.

Why implement 802.11n rather than 802.11ac for IoT platforms?

There are a few key reasons why 802.11n (Wi-Fi 4) may be better suited for most IoT applications than 802.11ac-based products (Wi-Fi 5). First, 802.11ac is based on 5 GHz versus 802.11n which supports both 2.4 GHz and 5 GHz. 2.4 GHz offers more range and better object penetration compared to 5 GHz. This is a key benefit in home environments with multiple walls and barriers.

Also, IoT Wi-Fi devices like Silicon Labs transceivers and modules are designed with enhanced RF selectivity to maintain reliable communication even in the presence of blockers such as nearby APs, 802.15.4 and Bluetooth devices. The below figure illustrates how advanced interference mitigation techniques help overcome the channel limitations related to the 2.4 GHz band. Learn more in Wi-Fi Learning Center.

One final point, the cost and power consumption of 802.11ac based systems is higher due to the higher protocol complexity. While it does provide enhanced throughput, the data rates provided by 802.11n are more than sufficient for most IoT applications including audio and security/IP camera video streaming.

What are some ways to reduce power requirements using Wi-Fi in IoT applications?

There are a number of ways to reduce power consumption using Wi-Fi:

1. Minimize the time spent in active TX and RX modes: With Wi-Fi’s high data rates, it may make sense to aggregate data and transmit/receive infrequently. It may also make sense to use higher data rates to transmit data more quickly and reduce the amount of time spent in high power transmit modes.
2. Choose the right devices: Not all Wi-Fi chipsets are made the same, so make sure you choose the devices with the lowest possible current consumption for the TX, RX, sleep and DTIM modes you are interested in. Watch out for datasheet tricks and make sure you are comparing apples to apples – this is especially important when looking at “sleep” and “associated” current definitions, as they are defined differently by vendors.
3. Think about the system level: The best power optimizations can be found at the system level, by seeing if you can turn off the radio and only power it on infrequently or using techniques like beacon skipping to reduce idle/sleep current if you are OK with tolerating latency.
4. Use the low power features available in the Wi-Fi standard: The Wi-Fi standard has a number of power optimizing features like DTIM sleep modes and Power Save that can save you a significant amount of power.

Are Wi-Fi solutions as integrated and compact as something like Bluetooth?

Wi-Fi solutions have traditionally been more complex and larger than solutions for Bluetooth. However, this gap is reducing, and there are increasingly smaller, optimized solutions available for Wi-Fi. This new class of IoT Wi-Fi devices takes advantage of Moore’s law to deliver higher performance, and eliminates size/cost adding features like MIMO. For example, Silicon Labs has a pre-certified Wi-Fi SiP module (including a Wi-Fi Radio, RF, XTAL and antenna) in a 6.5 mm x 6.5 mm package, which allows you to add Wi-Fi to small form factor devices.

 

Introduction

If your Wi-Fi connected product is headless, then technically speaking, the obvious solution for exchanging the Wi-Fi credentials required to commission the product onto the customer’s Wi-Fi network is SoftAP.

SoftAP stands for Software Enabled Access Point. Some product manufacturers use SoftAP to create a temporary access point for the unique purpose of getting the customer’s Wi-Fi network name (SSID), security mode and password as illustrated in the following diagram:

The customer connects his smartphone to the connected product’s SoftAP, and then uses either a mobile app or web page that displays the list of Access Points available to select and enter the password.

The connected product, once it has the customer’s Wi-Fi network information (SSID, Password and Security Mode) it connects to the Access Point.

The Access Point lets the connected product join the network and gain access to the Internet.

 

SoftAP used to be the Wi-Fi commissioning solution of choice for early IoT devices, but the two fundamental problems listed below have made it an unreliable solution:

• Once the customer’s smartphone connects to a SoftAP, it will lose Internet connection.
• If the customer’s smartphone loses Internet connection, then the phone’s logic may switch to a different Access Point and thus disconnect from the product.

 

In order to improve the out-of-box experience, product manufacturers have turned to Bluetooth as a solution for commissioning. For the Wi-Fi connected products that already support Bluetooth for a different purpose (e.g. streaming audio or video) then Bluetooth is the go-to mechanism for Wi-Fi commissioning as illustrated in the following diagram:

The customer installs the product manufacturer’s BLE Mobile Application and pairs with the connected product.

The mobile application displays a list of Access Points, the customer selects one of them and enters its password.

The connected product, once it has the customer’s Wi-Fi network information (SSID, Password and Security Mode) it connects to the Access Point.

The Access Point lets the connected product join the network and gain access to the Internet.

 

Because of how important the out-of-box experience is to a product’s success, many product manufacturers should consider going to the extremes of adding a Bluetooth chip exclusively to support the Wi-Fi commissioning of the product. Silicon Labs has BLE chips such as the EFR32MG12 that not only supports BLE but also other wireless protocols in the same chip.

Whatever your case may be, this blog shows you one simple way to use Bluetooth for Wi-Fi commissioning by covering the following topics:

• BLE GATT Server Design
• BLE Mobile Application
• Theory of Operation

 

Prerequisites

It is assumed that you are familiar with Web Technologies such as HTML and JavaScript, and more important, that you are familiar with your own Wi-Fi and Bluetooth stacks regarding the following topics:

BLE Stack

• Tool to create a BLE Generic Attribute Profile (GATT) database.
• Callbacks to handle the BLE Characteristics Read and Write requests.
• API to send Notifications to BLE clients.

Wi-Fi Stack

• API to start a Wi-Fi scan
• Callback to handle the Wi-Fi scan results
• API to join an Access Point
• API to store the Access Point’s credentials in non-volatile memory

 

Hardware Requirements

• Any Wi-Fi chip/module (e.g. Silicon Labs WF200 module)
• Any BLE chip/module (e.g. Silicon Labs EFR32MG12 chip)
• Web Server to host a static web page (e.g. AWS account)

 

Software Requirements

• BLE GATT Configurator
• Google Chrome Web Browser

 

BLE GATT Server Design

Using your GATT Configuration tool, you need to create two BLE GATT Services:

Wi-Fi Scanner Service

This service allows a Bluetooth Client to initiate the scanning of visible Wi-Fi networks and its corresponding information such as SSID, Security Mode and Signal Strength.

Wi-Fi Configurator Service

Allows a Bluetooth Client to configure the connected product with the information necessary to connect to a Wi-FI Access Point (i.e. SSID, Security Mode and Password).

 

The table below shows an example of such GATT database. Notice that the UUIDs have been truncated for sake of simplicity. In reality, they should be 128-bit and it’s important you keep them documented in a table similar to this.

 

BLE GATT Configuration
Service		Characteristic
Name	UUID	Name	BLE Variable	UUID	Value Settings		Properties
					Type	Length	Read	Write	Indicate
Wi-Fi Configurator	2b42…5ab3	State	gattdb_wifi_ cfg_state	c519…07da	user	1	Yes	Yes	Yes
		SSID	gattdb_wifi_ cfg_ssid	a4a3…5da7	user	32	No	Yes	No
		Password	gattdb_wifi_ cfg_password	1d4b…c315	user	16	No	Yes	No
		Security	gattdb_wifi_ cfg_security	0420…278c	user	1	No	Yes	No
Wi-Fi Scanner	9b51…af7d	State	gattdb_wifi_ scan_state	cc89…81c8	user	1	Yes	Yes	Yes
		AP List Part 1	gattdb_wifi_ scan_ap_list_1	d07c…d141	user	255	Yes	No	No
		AP List Part 2	gattdb_wifi_ scan_ap_list_2	7e44…99d6	user	255	Yes	No	No
		AP List Part 3	gattdb_wifi_ scan_ap_list_3	d3c1…b004	user	255	Yes	No	No
		AP List Part 4	gattdb_wifi_ scan_ap_list_4	a2a0…7ee0	user	255	Yes	No	No
		AP List Part 5	gattdb_wifi_ scan_ap_list_5	8907…2823	user	255	Yes	No	No

Table 1 BLE GATT Configuration

 

Characteristics

Both services have a characteristic called State that is used to communicate the state of the corresponding operation. Therefore, both characteristics support Read, Write and Notification.

Here are the possible states:

// Wi-Fi Scanner State Machine States
const WIFI_SCANNER_STATE_IDLE     = 0;
const WIFI_SCANNER_STATE_SCAN     = 1;
const WIFI_SCANNER_STATE_SCANNING = 2;
const WIFI_SCANNER_STATE_SCANNED  = 3;
const WIFI_SCANNER_STATE_ERROR    = 4;

// Wi-Fi Config State Machine States
const WIFI_CONFIG_STATE_IDLE      = 0;
const WIFI_CONFIG_STATE_SAVE      = 1;
const WIFI_CONFIG_STATE_SAVING    = 2;
const WIFI_CONFIG_STATE_SAVED     = 3;
const WIFI_CONFIG_STATE_JOIN      = 4;
const WIFI_CONFIG_STATE_JOINING   = 5;
const WIFI_CONFIG_STATE_JOINED    = 6;
const WIFI_CONFIG_STATE_ERROR     = 7;

Code Listing 1 Wi-Fi Scanner and Wi-Fi Configurator Service States

 

The rest of characteristics are meant to exchange the actual data. Notice that the results from the Wi-Fi Scanner need to be communicated in multiple characteristics because of limitations on the maximum length of a BLE Characteristic’s value (i.e. 255 bytes).

Here is an example of the value exchanged by one of such characteristics. It is in JSON format and it is sorted by signal strength such that the closest access point is displayed on top:

[
 {
   "ssid": "WHIFERAPPS",
   "rcpi": "156",
   "sec": "2"
 },
 {
   "ssid": "SiliconLabsMobile",
   "rcpi": "129",
   "sec": "2"
 },
 {
   "ssid": "SiliconLabsGuest",
   "rcpi": "128",
   "sec": "2"
 },
 {
   "ssid": "SiliconLabs",
   "rcpi": "118",
   "sec": "2"
 },
 {
   "ssid": "DIRECT-bc-HP M203 LaserJet",
   "rcpi": "108",
   "sec": "2"
 },
 {
   "ssid": "GLC-WESTON",
   "rcpi": "86",
   "sec": "2"
 },
 {
   "ssid": "FCAAC",
   "rcpi": "81",
   "sec": "2"
 },
 {
   "ssid": "KENGOLENDESIGNS",
   "rcpi": "67",
   "sec": "2"
 },
 {
   "ssid": "DreamPlanTrack",
   "rcpi": "60",
   "sec": "2"
 },
 {
   "ssid": "Ameriprise Guest",
   "rcpi": "60",
   "sec": "2"
 },
 {
   "ssid": "Ketamine1290",
   "rcpi": "55",
   "sec": "2"
 }
]

Code Listing 2 List of Access Points in JSON format

 

 

BLE Mobile Application

For the BLE mobile application you have the choice of creating a native BLE application to support iOS and Android as a minimum or use Web Bluetooth.

Web Bluetooth allows a web browser (e.g. Google Chrome) to see and interact directly with Bluetooth devices as illustrated in the following image:

The BLE mobile application is actually a web page (i.e. HTML and JavaScript) and it's hosted in the product manufacturer's web server. 

The customer opens a web browser (e.g. Google Chrome) and goes to the web server’s URL to download the web page.

The web page displays a list of nearby BLE devices and pairs with the BLE device you want to connect.

 

The advantages of Web Bluetooth over traditional native BLE mobile applications are:

• One single web page hosted in a web server allows much easier updates.
• One single web page can be used to support all mobile devices
• One single web page can also be used not only to connect via Web Bluetooth but also to host in the connected device in SoftAP mode for a line of products that does not support BLE.
• Developers with HTML and JavaScript skills are a lot easier to find than those with BLE Mobile App development skills for iOS and Android.

 

If Web Bluetooth is used instead of a traditional native BLE mobile app, then the revised block diagram for the Wi-Fi commissioning system using Web BLE would look like the following:

The BLE mobile application is actually a web page (i.e. HTML and JavaScript) and it's hosted in the product manufacturer's web server. The web page allows the user to select from a list of Wi-Fi Access Points and enter the Access Point’s password.

The customer opens a web browser (i.e. Google Chrome) and goes to the web server’s URL to download the web page. The web page displays a list of nearby BLE Devices and pairs with the device you want to connect.

The web page sends a scan request to the BLE device which in turn calls the Wi-Fi stack APIs to scan and get the results. Finally, the web page displays a list of Access Points, the customer selects one of them and enters its password.

The connected product, once it has the customer’s Wi-Fi network information (SSID, Password and Security Mode) it connects to the Access Point.

The Access Point lets the connected product join the network and gain access to the Internet.

 

Theory of Operation

The diagram below summarizes the way the entire system works:

Connected Product (BLE GATT Server)		Smartphone (BLE Client)
		To initiate a Wi-Fi Scan procedure, the BLE Client sends a request to write: BLE GATT characteristic: gattdb_wifi_scan_state  Value: WIFI_SCANNER_STATE_SCAN
The BLE GATT Server receives the request to write: BLE GATT characteristic: gattdb_wifi_scan_state Value: WIFI_SCANNER_STATE_SCAN
If the Wi-Fi Scanner State Machine's state is WIFI_SCANNER_STATE_IDLE then it will call the Wi-Fi API to start a scan
The Wi-Fi stack returns the scan results by calling a callback function. There, the list of access points is stored in a data structure with a global scope for general purposes
The Wi-Fi stack signals the completion of the scan procedure by calling another callback function
The embedded application prepares a multi-part JSON payload to be stored in a data structure with a global scope for BLE purposes
The embedded application sets the characteristic gattdb_wifi_scan_state to WIFI_SCANNER_STATE_SCANNED and notifies BLE clients that this characteristic has changed
		The BLE client receives the notification and sends requests to read the following BLE GATT characteristics:  gattdb_wifi_scan_ap_list_1 gattdb_wifi_scan_ap_list_2 gattdb_wifi_scan_ap_list_3 gattdb_wifi_scan_ap_list_4 gattdb_wifi_scan_ap_list_5
The BLE GATT server receives the requests to read the following characteristics and responds with the values: gattdb_wifi_scan_ap_list_1 gattdb_wifi_scan_ap_list_2 gattdb_wifi_scan_ap_list_3 gattdb_wifi_scan_ap_list_4 gattdb_wifi_scan_ap_list_5
		The BLE client receives indication that the values of the characteristics have changed and calls the corresponding event handlers
		The handler for the event characteristic value changed parses the JSON payload into a JavaScript object, merges each part into a single array of access points, sorts the array by signal strength and populates the drop-down box
		The customer selects the Wi-Fi Access Point he wants to join from the web page's drop-down box and enters the password in an input box
		The BLE client sends a request to write the following BLE characteristics: gattdb_wifi_cfg_ssid gattdb_wifi_cfg_password gattdb_wifi_cfg_security
The BLE GATT server receives the requests to write to the following characteristics: gattdb_wifi_cfg_ssid gattdb_wifi_cfg_password gattdb_wifi_cfg_security
The BLE GATT server updates the variables only if there is not any Wi-Fi configuration in progress
The BLE GATT server changes the state of the Wi-Fi Configuration state machine to WIFI_CFG_STATE_ONGOING and sends notification to the BLE client that this state has changed
		The BLE client receives the notification and to save the Access Point credentials in non-volatile memory, it sends a request to write:  BLE GATT characteristic: gattdb_wifi_cfg_state Value: WIFI_CFG_STATE_SAVE
The BLE GATT server receives the request to write: BLE GATT characteristic: gattdb_wifi_cfg_state Value: WIFI_CFG_STATE_SAVE and if not saving process in progress, it calls the API to store variables in non-volatile memory
The BLE GATT server changes the state of the Wi-Fi Configuration state machine to WIFI_CFG_STATE_SAVED and sends notification to the BLE client that this state has changed
		The BLE client receives the notification and to restart the Wi-Fi interface and connect to the new Access Point, it sends a request to write:  BLE GATT characteristic: gattdb_wifi_cfg_state Value: WIFI_CFG_STATE_JOIN
The BLE GATT server receives the request to write: BLE GATT Characteristic: gattdb_wifi_cfg_state Value: WIFI_CFG_STATE_JOIN and calls the Wi-Fi API to join a network

Figure 5 Flow Diagram

 

Source Code

To keep the blog relevant to any Wi-FI and BLE stack, the source-code-level details on how to perform the different functions outlined in the previous flow diagram have been omitted. 

The following Wi-Fi and BLE APIs are better described in their corresponding documentation and are beyond the scope of this blog:

• Callbacks to handle the BLE Characteristics Read and Write requests.
• API to send Notifications to BLE clients.
• API to start a Wi-Fi scan
• Callback to handle the Wi-Fi scan results
• API to join an Access Point
• API to store the Access Point’s credentials in non-volatile memory

The web page that makes the actual BLE mobile application however, is provided as an attachment (web_ble.zip) and if you like this approach, feel free to modify it and use it under the terms of the Apache License.

 

Security Considerations

Because of the sensitive nature of the information exchanged, you should consider using the security features of your Bluetooth stack:

• Pairing
• Bonding
• Device Authentication
• Encryption
• Data Signing

Check your Bluetooth stack documentation for more information on  these security features.

 

 

Further Reading

• Silicon Labs GATT Configurator User's Guide: https://www.silabs.com/documents/login/user-guides/ug365-GATT-configurator-users-guide.pdf
• Silicon Labs BLE API Reference: https://www.silabs.com/documents/login/reference-manuals/bluetooth-api-reference.pdf
• Silicon Labs Non-Volatile Data Storage Fundamentals: https://www.silabs.com/documents/public/user-guides/ug103-07-non-volatile-data-storage-fundamentals.pdf
• Silicon Labs Wi-Fi Solutions: https://www.silabs.com/products/wireless/wi-fi
• Web Bluetooth Samples: https://googlechrome.github.io/samples/web-bluetooth/
• Interacting with Bluetooth devices on the Web: https://developers.google.com/web/updates/2015/07/interact-with-ble-devices-on-the-web

Wireless technology plays a major part in the Internet of Things (IoT) but deploying this technology can involve a good bit of programming. Applications must address a range of issues including features like secure over-the-air (OTA) updates.

In this Q&A, Silicon Labs’ senior product manager for Xpress devices Parker Dorris discusses some of the questions that come up when talking about the programming burden of wireless applications.

What are some wireless IoT applications that Silicon Labs is targeting?

We’re targeting Bluetooth Low Energy-enabled sensors, smartphone-controlled smart home devices, white goods, and machine-to-machine applications, especially those requiring the additional option of phone configuration and connectivity. We’re already seeing an extremely diverse mix of applications evaluating and developing with these zero-programming IoT solutions, and the common theme in these designs is a need for wireless connectivity without the steep learning curve. The wireless component just works, which enables companies to focus resources on the aspects of a design that will make the product innovative and successful
in the market.

What is zero-programming, and why is it important to IoT developers?

The goal of our Wireless Xpress portfolio is to lower the barriers of entry for IoT end node design by providing easy to use hardware and software solutions that require zero-programming. These Wireless Xpress module products are all about enablement in a few key respects.

First, because a developer is interfacing with Wireless Xpress through a high-level network coprocessor (NCP)-style interface called the Xpress command API, and communicating with a device that takes on as much responsibility for wireless connection and communication as possible, developers don’t have to become Bluetooth or Wi-Fi experts to get to market quickly.

While you don’t have to write code for these module devices, we expose configurable parameters to tweak performance features. Developers don’t have to learn the intricacies of stack APIs and getting a module to some configured state; they just set a variable. This command API feature helps developers avoid some of the more common challenge points that can snag developers new to a wireless protocol.

Wireless Xpress takes advantage of Silicon Labs’ Gecko OS, an intuitive, simple-to-use IoT operating system. Wireless Xpress devices also focus on enablement in the sense that because the device handles wireless-related responsibilities so comprehensively with the Gecko OS firmware running under the hood, developers don’t have to choose an MCU that will be able to handle low-level wireless maintenance, or granular monitoring through a lower-level NCP protocol. Developers can choose the MCU that’s right for their application, rather than choosing the MCU that’s right for their NCP.

What hardware platforms does Silicon Labs offer for IoT end node designs?

We’ve launched Bluetooth Xpress modules in PCB module and system-in-package (SiP) module options, called BGX13P and BGX13S, respectively. We also offer two zero-programming Wi-Fi Xpress modules, the AMW007 and AMW037.

What is involved on the software side to get a mobile app running?

For Bluetooth Xpress, we’ve launched the Xpress framework for both iOS and Android. Developing mobile apps can sometimes be a challenge for product developers, and developing a BLE-connected app is its own specialized skillset. With the Xpress framework, we abstract low-level mobile OS core Bluetooth APIs behind a few easy-to-use APIs.

This is really helpful to developers for two reasons. First, the Xpress framework handles all the Bluetooth-specific scanning and discovery, interrogation, connection and GATT table communication. For instance, to scan, you call startScan, and the framework delivers a list of discovered devices. To connect, you call connectToDevice, and the framework handles the rest.

Second, the framework looks largely the same for both iOS and Android, unifying an interface that really works quite differently between the two OSes. So if a developer learns to connect to Bluetooth Xpress in iOS, those same function calls are going to work identically in Android. For Wi-Fi Xpress, we’re offering a web app that is served by a Wi-Fi Xpress device and provides a RESTful API to control the module and access a file system.

What type of tools are available to developers to take advantage of Wireless Xpress?

One great thing about these module products is that the Xpress command API is human-readable, and so developers can evaluate the product and fully exercise features with a simple terminal program running on a PC.

We’ve launched two evaluation kits, the Wireless Xpress BGX13P kit and the AMW007-E04 kit, each offering a serial to USB bridge so access to the board looks like a COM port. For developers that want a more context-rich evaluation experience and a graphical interface, we offer the Xpress Configurator tool in Silicon Labs’ Simplicity Studio development environment. Xpress Configurator logically groups different configurable parameters, validates configurable settings, and displays documentation for each parameter. All of this configuration results in one or more Xpress commands getting sent to the Wireless Xpress module through a terminal interface built into the tool.

Developers have access to network management and mapping tools. The tools provide a high-level view of the system. The network analyzer tracks wireless node activity in real time proving insights for debugging and system optimization.

What about connecting to the cloud?

For Bluetooth Xpress, we offer over the air (OTA) support through the Xpress framework. If Silicon Labs releases a firmware update to Bluetooth Xpress, this signed, encrypted update can be pulled from our cloud with a single framework API. Wi-Fi Xpress products can access the cloud directly to receive firmware updates. Developers can also use this built-in cloud connectivity to perform device health checks in the field and retrieve other key, application specific metrics as well.

There is a huge demand today for adding Wi-Fi connectivity to IoT applications because of the many advantages over other wireless protocols (Zigbee, Bluetooth, etc.) such as longer range, native IP connectivity, and high bandwidth. For millions of IoT applications, including industrial machines and sensors, Wi-Fi is often the best choice for connectivity because of its robust infrastructure and global reach- Wi-Fi exists almost everywhere in the world today.

 

Challenges for developers: The biggest challenge for developers has been the high-power consumption of Wi-Fi in IoT systems. Wi-Fi protocols were designed primarily to optimize bandwidth, range, and throughput, not power consumption. This makes it a poor choice for power-constrained applications that rely on battery power. Of the various cons of using standard Wi-Fi protocols, high power consumption is the most impactful (range limitations and busy networks are cons as well). Until today, developers have avoided adding Wi-Fi to their IoT applications as there hasn’t been a viable option for adding Wi-Fi connectivity to battery operated devices that didn’t require high power consumption.

These are the four key challenges when adding Wi-Fi connectivity:

• selecting the appropriate Wi-Fi protocol for energy efficiency
• costly compared to other protocols
• more time and resources needed compared to other wireless protocols
• form factor constraints

Power consumption in Wi-Fi varies dramatically across various modes of operation and it’s important to understand the different modes and optimize them to reduce overall power consumption. One strategy is to stay in the lowest power mode as much as possible and transmit/receive data quickly when needed.

 

RF performance: Unlike many wireless protocols, Wi-Fi power consumption is significantly impacted by RF performance and network conditions. This is a significant problem with the increasingly crowded Wi-Fi networks today. A busy network leads to many retries/retransmissions which consumes a high level of power. Developers must focus on reducing retransmissions and controlling link budgets to be successful.

Wi-Fi devices typically consume significant power in both Transmit (Tx) and Receive (Rx) modes. There are several ways to reduce power consumption and optimize Tx and Rx modes. First choose devices with high selectivity/out of band rejection. Also, choose devices with high Rx sensitivity, and if possible, choose uncrowded channels for device operation. This might mean using channels not used by chatty connections such as video streaming.

 

Applications: Power consumption is highly dependent on the application and use case. IoT applications typically fall into one of three categories:

Always on/connected-these devices are always on which allows users to access the device remotely at any time via cloud or mobile application.  A Wi-Fi video camera is a good example of this use case. Latency is a critical factor in these applications and power consumption is dominated by the transmit power mode (the highest power consumption), as the device is transmitting data and it would be detrimental to be inactive or inaccessible.

 

Periodically connected - These devices are connected to a remote server or cloud platform and only need to transmit occasionally. A good example is a temperature or humidity sensor that sends data every few minutes and it can tolerate the small amount of time it takes to become active. Latency is not a major concern and the power consumption is dominated by receive and sleep currents. It stays in intermediate power levels so it’s never completely awake or asleep so it wakes up faster.

 

Event-driven - An online shopping order button is a good example of event-driven Wi-Fi connectivity. It’s almost always inactive/asleep, meaning there is no data transmission. It wakes up infrequently, and it takes longer to wake up from this mode. An event occurs that triggers wakeup such as when a user selects the order button. This mode is dominated by the lowest sleep current and is best when needing to use the least amount of power possible for an IoT application.

 

Design issues -  Lowering Wi-Fi power consumption is also a design system issue and is a critical challenge for developers today. Power management and extended battery life are major factors when developing IoT applications. Although standard Wi-Fi protocols weren’t designed initially for low power operations, there are many techniques to help significantly reduce power consumption. These techniques include optimizing Rx and Tx modes, optimizing power-saving modes (sleep modes, WMM, DTIM, shutdown/standby), choosing the right hardware, using built-in specifications, optimizing RF performance, and system level optimization. Developers must understand all the contributing factors to overall energy consumption in IoT devices.

They must also understand both system-level factors and deep application factors in order to achieve low energy consumption in their applications. Finding the right mix of power-saving Wi-Fi modes and selecting the right hardware are the keys to dramatically reducing power consumption. Leveraging hardware and software designed specifically for IoT devices and low power consumption can reduce long term costs, overcome development challenges, extend battery life, and potentially enhance the life of products and customer satisfaction.

 

We solve the power management issues for IoT developers by providing drop-in Wi-Fi solutions, including pre-programmed modules (WF200 and WGM160) that can cut power consumption in half. These solutions are designed proactively with low power IoT applications in mind and work in a wide range of applications from home automation to commercial, retail, security, and consumer health-care products. Pre-programmed modules provide a prototype quickly which helps developers get products to market faster.

 

To read the full whitepaper on this topic. click here: