Challenges of Adding Connectivity to Low-Power, MCU-based Products

Designers must consider ease of use of the connectivity solution, constraints of low power MCUs, and low power characteristics of the connectivity solution – while also trying to simplify and accelerate product development and improve the end user experience.

The demand for embedded connectivity continues to grow. The requirement to connect devices or “things” to the Internet or to smartphones, tablets or PCs, for control and monitoring, is more critical than ever. New applications are emerging daily, with connectivity embedded in everything from smart energy systems to healthcare products, appliances and security devices in residential, commercial and industrial applications.

Low-power microcontrollers (MCUs) increasingly serve as the processing engines behind these connected devices – devices which are often portable and battery-powered. But adding connectivity to an 8, 16 or even 32-bit resource-constrained MCU brings with it a whole new set of challenges not encountered with traditional processors or microcontrollers found on laptops or smartphones.

User Acceptability/ Familiarity/ Ease of Connecting to the Internet
Numerous connectivity options exist for embedded products. So, the first consideration for any developer is whether to go wired or wireless.

Wireless connectivity is increasingly popular and the reasons are simple – wireless systems are generally less expensive and many applications require the convenience and mobility that they offer. Additionally, many connected devices will not be close to a power source and will operate on a battery, which needs to last anywhere from a week for personal tracking devices to several years in hard-to-reach industrial applications.
Multiple wireless technologies provide untethered connectivity, and that has created some market confusion limiting adoption of connected devices in the machine-to-machine (M2M) market. When determining which technology to use – 3G, Wi-Fi, ZigBee, Zwave or proprietary – several factors should be kept in mind: wide accessibility, easy and user-friendly Internet connection, and cost.

Cellular 3G/4G connections might be an obvious choice since they provide the widest coverage. However, cost is an issue as there is typically a subscription fee per device.

Wi-Fi is the next choice in terms of widespread coverage given the proliferation of Wi-Fi access points (AP) and increasing Wi-Fi hotspots – growing at 350 percent to 5.8 million hotspots by 2015, according to Informa Telecoms and Media. Consumers love Wi-Fi and are more familiar setting up Wi-Fi connections than other technologies. And, Wi-Fi often leverages an existing network infrastructure; thus the cost of an added connection is marginal and often free to consumers.

ZigBee, Z-Wave or proprietary technologies might offer cost or power-consumption advantages in certain applications, but additional infrastructure (e.g., gateways) will be required to connect to the Internet and none of these technologies offer the user acceptability and the widespread availability of Wi-Fi in residential, commercial, industrial applications, hotspots and smartphones.

Connecting sensors or appliances to a Wi-Fi network is quite different than connecting a laptop, PC or smartphone. Computing devices were designed to network; they have user interfaces that make connecting simple. Take the iPhone – simply select Settings, then Wi-Fi, touch the network to join, and enter the WPA/2 security password. Many “things” or sensors, however, are headless devices with no user interface – connecting them to a Wi-Fi network is more challenging.

This challenge can be addressed in several ways. The Wi-Fi Alliance’s Wi-Fi Protected Setup (WPS) can be used if the AP and client device support it. Using the PIN method, the PIN is entered in the AP, enabling the device to join a network. The push button technique is simpler. By pressing the WPS button on router and device, the device sets itself up including WPA/2 security and encryption. But WPS must be supported by the router and all devices you want to connect.

Designers can also put the device into AP mode, often referred to as soft AP. A “Limited AP mode” for client devices makes them discoverable from PCs or smartphones. Native or browser-based apps, which act as the device GUI, allow you to set Wi-Fi and network settings to join the network, including network name (SSID) and WPA/2 security. The device switches into normal client (STA) mode to securely connect to the Wi-Fi AP.

The features and capabilities of the connectivity chip or module, such as support of DHCP and DNS servers, device and service discovery, are also important in improving the user experience. DNS, common on the Internet, lets you type a normal web address into the browser instead of an IP address. The same technology works on your local network too.

Beyond simply connecting to the Internet, many devices connect to cloud-based services. Wi-Fi-enabled devices can be pre-configured with cloud service server settings; as soon as the device connects to the Wi-Fi AP and Internet, it automatically maps to the cloud server.

Connecting to 8/16 or 32-bit Resource-Constrained MCUs
As machine-to-machine and Internet of Things (IOT) gain traction, microcontroller vendors are introducing energy-efficient microcontrollers. Some are built on the ARM® Cortex™-M0+ processor 32-bit platform, such as Freescale’s Kinetis L series, while others use a 16-bit CISC architecture, like Renesas’ RL78 . These microcontrollers serve a new wave of connected devices requiring ultra-low power consumption, low price and small footprint while maintaining peripheral support and performance.

The flash and RAM of several of these MCUs is quite small: 8 to 64 Kbytes of flash, 4 to 8 Kbytes of RAM. Adding Wi-Fi to a PC or smartphone requires little more than a Wi-Fi RF transceiver, as the powerful host processor of the device can handle the networking functions and some Wi-Fi functions. But adding Wi-Fi to this new wave of IOT devices is more challenging. Given the host MCU’s small memory size and processing power, the Wi-Fi chip must handle Wi-Fi functions plus networking stack and services.


GainSpan’s stack running on Wi-Fi chip

With networking functions handled by the Wi-Fi chip, the MCU primarily handles the application and a small (no more than a few Kbytes) driver or reference code for the connectivity solution.


GainSpan provided reference design code for MCU support

Embedded designers face another challenge– enabling communication between a resource-constrained MCU and an application running in the cloud or on a smartphone through a Wi-Fi module. Embedded designers might not be familiar with XML used in web and smartphones applications or even with the connectivity solutions. Web/app developers might not be familiar with MCU embedded code. The connectivity solution must be simple to bridge the communication gap between these worlds. The connectivity module must interface to the MCU using AT commands and simple data strings, include an XML parser and communicate with the mobile device or web-hosted applications using XML format and HTTP(S) commands.

Designing for Battery-Operated Devices
Adding Wi-Fi to low-power or battery-operated applications presents different challenges than adding Wi-Fi to PCs or smartphones. Conventional designs and Wi-Fi chips are generally optimized for high data rates and fast response; they actively listen to the channel even when no data is transmitted to provide good response and low latency.

But this methodology doesn’t optimize for power consumption and is not suitable for battery operated devices that require months or years of battery life. When designing battery-operated devices, the designer must carefully select low-power Wi-Fi chips or modules with low standby current and fast wake up from standby. The module should remain in its lowest powered state and be able to quickly wake up, connect to the network, send or receive data and go back to sleep in order to minimize energy consumed. In several applications, such as sensors, this cycle is often repeated at periodic intervals (once every 30 sec in the example shown). Power consumption in this lowest powered state has a big impact on overall battery life, as 99 percent of the operational time is spent in this state.


Typical low-power Wi-Fi operation

In other applications, the Wi-Fi chip or module can be awakened from low-power mode using ALARM inputs triggered by the MCU or other events. For example, in access control or security monitoring, the device wakes up only on an event, but wakes up fast, connects and sends information with minimum latency. The system remains in the lowest power state until some event causes an ALARM, saving power and increasing battery life.

Overall average power can be further reduced by using other power save modes – deep sleep or IEEE PS-POLL – during active periods, where the receiver is kept off in between AP beacons or skips beacons to conserve power. Use of PS-POLL tells the Wi-Fi AP to buffer data for the device if needed; the device requests the data from the AP when it awakes. Power is conserved when the device waits for a response, say from a server, by keeping the receiver off and turning it on close to the beacon requesting data, lowering average power while maintaining connectivity.

In summary, designers adding connectivity to low-power MCU-based products must consider ease of use of the connectivity solution, constraints of low-power MCUs, and low-power characteristics of the connectivity solution. The connectivity chip or module should be designed to operate in a low-power state and wake up quickly, but it also has to handle capabilities and features that simplify and accelerate product development while improving the end user experience.



Bernard Aboussouan leads the company’s marketing and application engineering functions. Previously, he was vice president of marketing and business development at Sequans Communications, where he was instrumental in building the company into the leading WiMAX chipmaker and where he was also in charge of Sequans’ expansion in the United States.





David Cohen, director of product management, has more than 20 years of experience in wireless, networking and security technologies, and in building industry alliances. An industry leader and respected authority in Wi-Fi wireless LAN, David is founder and former chairman of the Wi-Fi Alliance. Prior to GainSpan he was with Quantenna Communications.

Share and Enjoy:
  • Digg
  • Sphinn
  • Facebook
  • Mixx
  • Google
  • TwitThis

Tags: ,