Welcome to the Wireless Menagerie: RF Bands and Protocol Choices for Embedded Developers, Part 2

Editor’s Note: Part 1 of this two-part series discussed the various wireless connectivity options available to embedded system designers and provided some relevant examples. Here, Part 2 discusses the characteristics of wireless modules in more detail, along with insight on how to go about using them effectively.

The rapid evolution of the Internet of Things (IoT) and artificial intelligence (AI) increases the need for wireless system connectivity, making it imperative that developers make the right protocol choice and design it in quickly and at low cost. To help, there are many wireless modules available, but designers need to follow a logical selection and integration process to ensure design success.

This article discusses a 4-step process for selecting and implementing an appropriate wireless protocol and wireless module for embedded applications. The steps are:

Select a wireless interface and protocol based on bandwidth, range, and cost requirements Decide if the wireless module should include processing capability for the embedded application in addition to implementing the wireless protocol Identify the I/O requirements for the wireless module or chip Select the appropriate module or chip based on decisions made in the first three steps

The article includes descriptions of six wireless modules selected as a representative sample from the many that are available to consider when designing wirelessly connected embedded systems.

Step 1: Select the wireless protocol

Several of the most common wireless protocols are shown relative to bandwidth and range plane (Figure 1).

Conceptual diagram of range (in meters to kilometers) versus bandwidth (in bits per second to megabits per second)

Figure 1: A conceptual diagram of range (in meters to kilometers) versus bandwidth (in bits per second to megabits per second) for several wireless protocols. (Image source: Digi-Key Electronics)

This simple diagram permits quick winnowing of options based simply on range and bandwidth requirements. The protocols on the left—Wi-Fi, Bluetooth, and Bluetooth LE (low energy)—deliver hundreds of kilobits per second (Kbits/s) or megabits per second (Mbits/s) over ranges measured in tens of meters (m). These protocols are appropriate mostly for in-building networks. The protocols on the right deliver data over kilometers. These protocols are appropriate for remotely located embedded devices over a campus or a city.

Modules that implement Wi-Fi, Bluetooth, and Bluetooth LE (or a combination of these) often have on-board antennas. For example, the integrated antenna built into Adafruit’s 3320 Wi-Fi/Bluetooth/Bluetooth LE module is clearly shown (Figure 2). It’s the zigzag trace at the top of the circuit board.

Integrated antennas greatly simplify the design of wirelessly networked embedded systems because the complex work of antenna development is already done.

Image of Adafruit’s 3320 Wi-Fi/Bluetooth/Bluetooth LE Module

Figure 2: Adafruit’s 3320 Wi-Fi/Bluetooth/Bluetooth LE Module operates at speeds to 150 megabits per second. (Image source: Adafruit)

This module is designed to be mounted on a circuit board and requires additional circuitry, so it may not be the best place to start prototyping. The module is available soldered to a small circuit board as a dev kit, the Espressif Systems ESP32-DEVKITC, shown in Figure 3. The ESP32-DEVKITC breaks out all the module’s pins to 0.1 inch headers, incorporates a USB to TTL serial adapter chip, programming and reset buttons, and an on-board 3.3 volt regulator.

Image of Espressif Systems’ ESP32-DEVKITC

Figure 3: Espressif Systems’ ESP32-DEVKITC breaks out all the Adafruit 3320 module’s pins to 0.1 inch headers, incorporates a USB to TTL serial adapter chip, programming and reset buttons, and an on board 3.3 volt regulator. (Image source: Espressif Systems)

Long range wireless protocols and on-board antennas don’t mix

Long distance wireless networking communications call for external antennas and the complications that accompany them. For example, Semtech Corp.’s SX1276MB1LAS is a LoRa transceiver that incorporates two SMA connectors for attaching high and low frequency antennas (Figure 4).

Image of Semtech’s SX1276MB1LAS LoRa transceiver module

Figure 4: Semtech’s SX1276MB1LAS LoRa transceiver module has two SMA connectors for high and low band RF antennas. (Image source: Semtech Corp.)

The two antenna ports are required to allow the module to separately handle the 433 MHz and 915 MHz frequency bands used for LoRa communications in the United States. The module has a 168 dB maximum link budget, giving it several kilometers of range. However, the coaxial cabling and the SMA connectors between the module and the external antenna will consume part of that link budget.

To help get a design off the ground, Semtech also offers the SX1276DVK1JAS development kit based on the SX1276MB1LAS LoRa transceiver module. The kit includes two LoRa transceivers, two Eiger platforms, two mini USB cables, two touchscreen styluses, and dipole antennas for high and low frequency bands.

The XBC-V1-UT-001 Digi XBee cellular LTE Cat 1 modem from Digi International also requires an external antenna and takes a similar but slightly different approach to antenna connection, as shown in Figure 5.

Image of Digi International’s XBC-V1-UT-001 XBee cellular LTE Cat 1 modem

Figure 5: Digi International’s XBC-V1-UT-001 XBee cellular LTE Cat 1 modem puts an embedded system on Verizon’s cellular communications network. (Image source: Digi International)

Digi’s modem has two U.FL subminiature RF connectors for attaching primary and secondary LTE antennas. The primary antenna is required. The secondary antenna improves receiver performance in certain situations and is recommended by Digi. The antennas should be located as far as possible from the cellular modem module (and other metal objects). If both primary and secondary antennas are installed, they should be oriented at right angles to each other for best results.

Step 2: Is application processing required in the wireless networking module?

Some wireless network modules have on-board processors. Some do not. If the embedded system under development already has a processor, then another programmable processor on the wireless network module might not be needed. If the wireless module must execute the embedded system’s application code, then the available programming tools and the module’s execution capabilities become part of the decision process. Using the wireless networking modules on-board intelligence to execute the embedded application definitely saves board space. In addition, it can simplify the hardware design and reduce the bill of material (BOM) costs.

Some modules discussed above implement an entire programming environment. In the case of Digi’s XBC-V1-UT-001 XBee cellular modem discussed above, there is an on-board MicroPython environment that applies the modem’s built-in intelligence to simple applications. For example, sensors connected to the module’s digital and analog I/O pins can be read, processed, and transmitted. Actuator commands can be received and acted upon. The module has 13 digital I/O pins and four 10-bit analog input pins. MicroPython can also help manage power in battery-powered embedded systems based on the modem.

Programming is done by plugging the XBC-V1-UT-001 into a Digi XBIB-U-DEV interface board connecting a PC to the interface board with a USB cable, and firing up a terminal program. There’s a MicroPython terminal program in Digi’s XCTU configuration and test utility software. The XBC-V1-UT-001 module comes with 24 kilobytes (Kbytes) of RAM and 8 Kbytes of flash memory for storage.

It’s possible to get more performance from the on-board intelligence in other wireless networking modules. For example, the Wi-Fi/Bluetooth/Bluetooth LE module in the Espressif Systems ESP32-DEVKITC development kit, discussed in Step 1 above, incorporates two 32-bit Xtensa LX6 RISC processor cores, both running at 160 MHz. By convention, one of these processors is the “protocol” processor and the other is the “application” processor. However, both processors can access all of the on-board resources. That’s enough processing power for most embedded applications.

Step 3: Identify the I/O requirements for the wireless module or chip.

Whether or not the wireless networking module runs the embedded application internally, it will likely need to connect to something else in the embedded system. Either it will need to connect to a host CPU within the embedded system, or it will need to connect directly to sensors and actuators. Perhaps it will need to do both.

The simplest path is the plug-and-play approach. Plug in a module, load the drivers, and that’s it. Advantech Corp.’s EWM-W151H01E 802.11b/g/n Mini PCIe card plugs into a mini PCIe socket and communicates with a host CPU over PCIe (Figure 6).

Image of EWM-W151H01E 1T half-size Mini PCIe card from Advantech

Figure 6: The EWM-W151H01E 1T half-size Mini PCIe card from Advantech implements the IEEE 802.11b/g/n-based Wi-Fi standards. (Image source: Advantech Corp.)

To begin development with the EWM-W151H01E, load the Windows (7, 8, or 10) or Linux drivers and the embedded system is ready to connect to existing Wi-Fi systems at data rates up to 150 Mbits/s. The card’s plug-in Mini PCIe form factor, along with drivers for Windows and Linux, means that this card module is most suited to embedded PC (x86 processor) designs.

The discussion of the Espressif Systems ESP32-DEVKITC mentions the analog inputs and simple digital I/O pins on the module that can be used to connect to sensors and actuators. However, the module also has more complex serial interfaces including three UARTs, two I2C ports, three SPI ports, and two I2S ports. These can be used to connect to a variety of peripheral devices and can be used as an interface to a host CPU. Here are some specifics on each:

The module’s UARTs have a maximum transfer rate of 5 Mbits/s Its I2C ports support both 100 Kbits/s (standard mode) and 400 Kbits/s (fast mode) transfer rates Its I2S ports support 40 Mbits/s transfers Its SPI ports support 50 Mbits/s

If the most suitable protocol module lacks the requisite I/O capabilities, the embedded system will require the addition of an I/O expansion chip which takes up more board space, causes the power consumption to go up, adds to programming complexity, and increases the BOM cost. It’s far better to accomplish everything with one wireless networking module if possible.

Step 4: Choose and implement

At this point in the process, the selections should be narrowed to a few choices or perhaps just one. The bandwidth and range requirements should narrow the field to one or two suitable protocols. A need for on-board application processing by the wireless networking module and the amount of on-board processing should eliminate several more choices. Finally, the I/O requirements should bring the choices down to a final few. At that point the choice is either obvious, or there are a few good choices in which case the remaining selection criteria might come down to familiarity or ease of implementation.


The requirement for embedded wireless connectivity continues to increase. The large number of available protocols can be confusing to some embedded designers at first glance, but each protocol fills a range/power/data rate niche, making selection much simpler if viewed from that perspective.

This article has presented a four-step process for selecting from the many dozens, even hundreds of available wireless networking modules.

Select a wireless protocol based on bandwidth, range, and cost requirements. Decide if the wireless module should include processing capability for the embedded application in addition to implementing the wireless protocol. Identify the I/O requirements for the wireless module or chip. Select the appropriate module or chip based on decisions made in the first three steps.

Whatever the application, there’s likely to be at least one standardized wireless protocol and several associated modules that will meet the requirements well.