802.11x Modules, Dev Kits Can Help Simplify IoT Wireless Design Efforts

Contributed By Digi-Key's North American Editors

Designers of Internet of things (IoT) products are using Wi-Fi-based wireless connectivity because it is widely deployed and well understood. However, RF of any sort is complex and requires regulatory compliance testing. Without the right expertise it can slow down development, especially if a designer chooses to design the RF section from scratch.

One way to accelerate the design process is to opt for one of the many available pre-certified modules. To that end, this article discusses the advantages of Wi-Fi for wireless applications before explaining how to design a product using a module and associated design tools.

Why Wi-Fi?

Wi-Fi is one of many popular short-range RF technologies for wireless communication that take advantage of the 2.4 GHz industrial, scientific and medical (ISM) license-free spectrum allocation. The technology is based on the IEEE 802.11 specification and comes in several variants with different throughputs and various digital encoding methods.

Compared with technologies such as Bluetooth low energy (Bluetooth LE) and zigbee, it is relatively power hungry, expensive, and demands considerable processor resources. However, it’s also incredibly fast. From the lowliest 802.11b version with a raw data rate of 11 Mbits/s to the impressive 600 Mbits/s of the n variant, no other open standard 2.4 GHz technology comes close. (See Digi-Key article, “Comparing Low-Power Wireless Technologies.”)

Which Wi-Fi?

A common element among the Wi-Fi variants is that all Wi-Fi operational specifications are dictated by the Wi-Fi Alliance, the custodians of the Wi-Fi brand and specifications. The alliance determines the data structures, encryption techniques, frequencies, packet configurations, and sub-protocols used by Wi-Fi local area networks (LANs).

Importantly, Wi-Fi can also take advantage of the 5 GHz spectrum allocation, further increasing throughput and reducing the potential for interference by removing communication from the crowded 2.4 GHz band. The downside is a reduction in range and poorer obstacle penetration. (See Digi-Key article “Compare 2.4 GHz and 5 GHz Wireless LAN in Industrial Applications.”)

There are several Wi-Fi protocols: IEEE 802.11b/g that operate in the 2.4 GHz band, IEEE 802.11a/ac and are designed for 5 GHz band operation, while IEEE 802.11n radios can operate in both bands.

IEEE 802.11b was adopted back in 1999 and offered data rates of 5.5 and 11 Mbits/s. It is now largely found only in legacy systems. However, support for b is built into contemporary n radios so that modern systems can operate with legacy systems.

IEEE 802.11g was adopted in 2003 and used a different modulation technique than the original protocol to achieve data rates up to 54 Mbits/s. In practical applications, the usable data rate is often halved due to forward error correction algorithms. g is backwardly compatible with b.

IEEE 802.11n was adopted in 2009 and introduced multiple input, multiple output (MIMO) antenna technology for encoding several, simultaneous “spatial streams”, boosting the data rate to 216 Mbits/s (assuming 20 MHz channel width and a transmitter employing three spatial streams). 802.11n also specifies a wider, 40 MHz channel, formed by bonding two 20 MHz channels, which boosts throughput to 450 Mbits/s. Devices which support three spatial streams are limited to high-end portable computers, tablets and access points (APs). Two spatial stream devices are more plentiful, but still limited to portable computers, tablets and the latest generation of smartphones.

IEEE 802.11a is identical in most respects to g, except it operates in the 5 GHz band. The maximum data rate is the same, 54 Mbits/s. Today 802.11a is largely considered a legacy protocol.

IEEE 802.11ac was adopted in 2013 and offers eight special streams and channel widths of up to 160 MHz to further boost throughput. Commercial products are only just hitting the market, remain expensive, and at least in the first instance, the technology is likely to be employed for only very high-end consumer products.

The 2.4 GHz band allocation allows for between 11 (in the U.S.), 13 (in most of the rest of the world) and 14 (in Japan) 20 MHz channels. The 83 MHz width of the band accommodates just three non-overlapping Wi-Fi channels (1, 6 and 11) (Figure 1).

Image of Wi-Fi channel allocations in the 2.4 GHz ISM band

Figure 1: Wi-Fi channel allocations in the 2.4 GHz ISM band allow for three non-overlapping 20 MHz channels (one, six, and eleven). (Image source: Cisco)

To avoid the clashes that could otherwise result from adjacent WLANs using any of the 11 to 14 channels, manufacturers typically design their equipment to communicate in just the non-overlapping ones. For example, a Wi-Fi radio experiencing excessive interference in channel 1 can be switched to channels 6 or 11 in an effort to find an interference-free environment.

To assist with spectrum sharing, Wi-Fi does include contention mechanisms that ration bandwidth fairly between access points (APs) using the same channel. An AP operating on a congested channel experiences limited airtime, affecting when it can receive or send data.

Wi-Fi for the IoT

It is important to note that Wi-Fi, based on the IEEE 802.11 specification, only defines the physical (PHY) and data link layers of a communication protocol. The data link layers comprise the media access control (MAC) and logical link control (LLC). However, such is Wi-Fi’s ubiquity for Internet connectivity that its PHY and data link layer are typically integrated into a complete TCP/IP protocol stack. This protocol stack ensures Internet interoperability and is typically (but not always) the software supplied by the Wi-Fi connectivity solution vendor. The rest of this article will discuss Wi-Fi solutions with TCP/IP stacks (Figure 2).

Image of Wi-Fi solutions with TCP/IP stacks

Figure 2: Wi-Fi defines the physical and data link layers of a stack. Typically, vendors supply firmware that integrates these layers with a full TCP/IP stack offering Internet interoperability. (Image source: International Centre for Theoretical Physics)

While Wi-Fi has carved a deep niche as the key technology for connecting smartphones, portable computers and PCs to the Internet, it is rapidly diversifying to become a foundation technology for the IoT.

Where Internet interoperability and throughput are more important than power consumption, Wi-Fi-powered IoT devices offer a compelling solution to the problem of relaying information directly from wireless sensors to the Internet. Wi-Fi IoT sensors connect directly to the Internet without recourse to complications such as additional network layers like IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN).

Wi-Fi is a good option for cost-effective “gateways,” where multiprotocol Bluetooth LE/zigbee/Wi-Fi system-on-chip (SoC)-based units aggregate data from multiple low-power wireless sensors and forward this information to the cloud.

Note that a low-power-consumption form of Wi-Fi is emerging. Based on IEEE 802.11ah and dubbed “HaLow”, the technology’s power consumption is minimized by leveraging the ultra-low duty cycle used by other low-power wireless technologies. Its power consumption is expected to be around 1 percent of that consumed by conventional Wi-Fi chips. HaLow operates in the 900 MHz ISM band which boosts its range to nearly twice that of today’s Wi-Fi. The trade-off is throughput, which is said to be comparable with Bluetooth LE’s maximum raw data rate of 2 Mbits/s.

Accelerating Wi-Fi-based designs

Designing a Wi-Fi IoT solution from scratch reduces costs and provides an opportunity to fully optimize the wireless product’s performance. But the designer needs considerable RF hardware expertise at gigahertz frequencies, familiarity with TCP/IP protocols, coupled with the tenacity to embark on a long-winded process of testing and verification to the standard’s specification for compliance certification.

Some help comes from the semiconductor vendors that provide reference designs which can be used as a basis to accelerate the development process. However, such schematics can only be considered as a starting point; slight variations in magnetics, substrates, tracks and circuit impedances can have a significant effect on performance, and it will typically entail several design iterations to get things working smoothly.

A much quicker route to a satisfactory design is to select an assembled, tested, verified, and compliance-certified module. These products can be rapidly incorporated into a Wi-Fi IoT solution, accelerating time-to-market.

IoT application IEEE 802.11 modules of all variants along with associated development tools are readily available from many silicon vendors. A basic module will typically integrate a WLAN baseband processor and RF transceiver support, power amplifier (PA), clocks, RF switches, filters, passives and power management.

Because a Wi-Fi-based TCP/IP stack is a complex piece of firmware to supervise, it requires the resources of a microprocessor capable of supporting a high-level operating system (OS) such as Linux or Android. Common drivers for OSs managing Wi-Fi stacks are available from the hardware providers, while additional drivers, such as those needed for WinCE and a range of real-time OSs, are supported through third parties.

Often the designer is left to source a suitable microprocessor, along with passives to form matching circuits, and 2.4 and/or 5 GHz antennas. However, some module solutions include an embedded processor, and still others comprise a complete working solution.

Wi-Fi modules for every situation

A good example of a cost-effective Wi-Fi module designed for IoT applications such as point-of-sale terminals, remote security cameras and medical sensors is the Bluegiga branded WF111 from Silicon Labs. The device provides Internet connectivity via Wi-Fi b, g, or n. The product offers 2.4 GHz operation only, a maximum data rate of 72 Mbits/s, and a 114 dBm link budget (17 dBm transmitter power output and -97 dBm receiver sensitivity). Its voltage supply is 1.7 to 3.6 V with a Tx peak current of 192 mA and an Rx peak current of 88 mA.

The WF111 includes a built-in antenna (or a connector for an external antenna) and is designed to operate with an external host microprocessor. The device is controlled by the host microprocessor using a Secure Digital Input Output (SDIO) interface operating in 1-bit or 4-bit mode. The SDIO interface allows the host microprocessor to directly access IEEE 802.11 functionality.

Because the silicon vendor anticipates the WF111 will be used in close proximity with Bluetooth LE sensors, up to six hardware control lines are handily included to manage wireless coexistence. The control lines ensure the Wi-Fi and Bluetooth devices communicate to avoid simultaneous packet transfers that typically occur when Wi-Fi and Bluetooth LE devices are in close proximity. Such transfers typically degrade link performance (Figure 3).

Image of Silicon Labs’ WF111 six control lines

Figure 3: Silicon Labs’ WF111 includes six control lines to ensure Wi-Fi and Bluetooth devices coordinate communications to improve coexistence. (Image source: Silicon Labs)

Texas Instruments’ (TI) WL1801 takes a close partnership with Bluetooth a step further by integrating IEEE 802.11 a/b/g/n and a Bluetooth/Bluetooth LE transceiver into the same device. Such a module is an ideal solution for the IoT gateway devices described above because of its built-in interoperability with both Wi-Fi and Bluetooth protocols.

The device offers both 2.4 and 5 GHz Wi-Fi operation, a maximum data rate of 54 Mbits/s, and a 115 dBm link budget (18.5 dBm transmitter power output and -96.5 dBm receiver sensitivity). The operating voltage range is 2.9 to 4.8 V with a Tx peak current of 420 mA and an Rx peak current of 85 mA. The modules are FCC, IC, ETSI and Telec certified.

The WL1801 is supplied with Wi-Fi and Bluetooth stacks, but must be paired with a suitable microprocessor, 32 kHz crystal and antenna(s) to form a complete solution. TI suggests a microprocessor from its Sitara family—such as the AM3351, an ARM® Cortex®-A8-cored device capable of supporting Linux, Android or real-time OSs, plus the Wi-Fi driver and Bluetooth LE stack. The microprocessor drives Wi-Fi operation through an SDIO interface and Bluetooth via a UART (Figure 4).

Diagram of Texas Instruments’ WL1801

Figure 4: TI’s WL1801 leaves the microprocessor choice up to the designer, although the company recommends a capable chip such as an ARM Cortex A8-based Sitara. (Image source: Texas Instruments)

Murata's LBEE5ZZ1MD module takes integration a step further by including a processor, complete with a pre-loaded Wi-Fi firmware stack. While this simplifies matters by matching the processor to the radio, the downside is that developers are committed to the module maker’s processor hardware choice, and possibly an unfamiliar development environment.

The Murata module provides Internet connectivity via Wi-Fi b, g or n. The device offers 2.4 GHz operation only, a maximum data rate of 65 Mbits/s and a 100 dBm link budget (2 dBm transmitter power output and -98 dBm receiver sensitivity). It operates off a 3.3 volt supply with a Tx peak current of 300 mA and an Rx peak current of 45 mA.

The module pairs a Wi-Fi MAC/baseband/radio with the STMicroelectronics’ STM32F412 ARM Cortex-M4-based microprocessor. The module includes on-board crystals, matching circuits and 2.4 GHz antenna. A peripheral 32.786 kHz crystal can be added. The STM32F412 processor includes UART, SPI, I2C and other interfaces (Figure 5).

Diagram of Murata’s LBEE5ZZ1MD Wi-Fi module

Figure 5: Murata’s LBEE5ZZ1MD Wi-Fi module incorporates an ARM Cortex M4-based microprocessor together with crystals, matching circuits and antenna. (Image source: Murata)

The module comes with a TCP/IP stack and an Electric Imp OS for connection to the Electric Imp cloud service. This is useful for designers who are not already familiar with a third-party cloud service provider and how to upload and access data. Development guidance is offered on the Electric Imp development center website.

u-blox’s NINA W132 is an example of how far a modular solution can take a designer. The device integrates Wi-Fi and Bluetooth LE functionality, a host processor, power management, separate 16 Mbits of flash memory and a 40 MHz crystal.

Internet connectivity is via Wi-Fi 802.11b, g or n. The device offers 2.4 GHz operation only, a maximum raw data rate of 54 Mbits/s, and a link budget of 112 dBm (16 dBm transmitter power output and -96 dBm receiver sensitivity). It runs off a 3.3 volt supply, with a Tx peak current of 320 mA and an Rx peak current of 140 mA.

The unit comes with preloaded application software. Developers need to understand up front that they are committed to using u-blox’s s-center toolbox software for configuration (via AT commands).

The NINA-W132 module provides end-to-end security of the wireless link protection using the 802.11i (WPA2) standard and enterprise security.

Take advantage of the dev kits

While modules will save considerable hardware effort and are typically supplied with a proven Wi-Fi (TCP/IP) software stack (and often application examples), the solution is not always optimized for the developer’s target application. Such optimization can often be achieved by turning to the module maker’s development kit. The development tools often take the form of assembled and tested development boards housing the module.

The development boards for modules needing a companion microprocessor can typically be connected to a development platform based on the target microprocessor. The developments kits are designed to provide an application programmer interface (API) to the host processor and in turn the Wi-Fi stack, easing additional application coding.

For example, Silicon Labs offers the WF111 Development Kit to evaluate the WF111 module described above. The development kit comprises an assembled and tested pc board with the WF111 module. It is shaped to fit into a standard SDIO card slot. Once mounted, the module can be exercised and evaluated using the target microprocessor’s evaluation tools. A useful addition is a header that allows easy access to the module debug bus for RF certification purposes.

Another example is TI’s WL1835 development board. This is a fully assembled and tested pc board comprising the WL1801 modules, all peripheral circuitry, and the antenna. It can be plugged in to the Sitara TMDSICE3359 development board, which features a suitable Sitara processor to drive the WL1801 module. Such a development set-up enables the developer to test the performance of a working Wi-Fi unit in their target application.

Conclusion

Wi-Fi holds a unique position among IoT wireless protocols because it is able to support high data rates while offering seamless interoperability with the Internet. However, Wi-Fi, like any RF technology, is complex to design in from scratch.

For many designers, especially those facing a short design cycle, a module may be a better option. It can come either with an embedded microprocessor or be combined with their favorite microprocessor, and will considerably ease and accelerate the design and certification process.

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 publisher

Digi-Key's North American Editors