Wireless IoT Connectivity: Many Choices, Many Trade-offs

The Internet of Things (IoT) is getting a lot of well-deserved attention due to the many potential benefits it offers. While the number of IoT-connected nodes installed in five, ten, or more years is the subject of much speculation and market research (and much guesswork, as well), one thing is clear: the numbers will be huge. The IoT is closely associated with its industrial sibling of machine-to-machine (M2M) applications, so there are many technical similarities and implementation overlaps between the two categories.

From a high-level perspective, an IoT node consists of three system-function blocks (Figure 1):  1) the sensor or transducer (temperature, flow, open/close door position, as examples); 2) the digital-processor unit (microcontroller) which captures the sensor data and does the processing and analysis; and 3) the connectivity port, which can be wired or wireless. The former is an option if there is an available low-cost network or one is being installed, if security is a critical consideration, if the setting is a severe EMI/RFI area, or if only a few points are being connected. However, for most IoT installations, a wireless link is the preferred option due to ease of installation and overall flexibility in initial placement and even relocating the IoT node if needed.

Figure 1: The high-level system block diagram of an IoT or M2M node shows the three primary functions: sensor, processor, and connectivity interface.

Choosing a standard wireless link does not mean that the design decisions are done and the design process is trivial. Wireless links must adhere to industry and regulatory standards, and regional approval in many cases. There are many wireless IoT options which designers may have to consider. In some installations, the decision is already made due to a mandate or existing network. In others, the designer can evaluate the options and make a choice based on the trade-offs and priorities of performance, network type (mesh, WLAN, point-to-point), range, power, frequency band(s), robustness and, of course, cost. There are also major issues of security, authentication, and encryption.

Choices can easily become bewildering

If all or most wireless IoT connectivity options are available for consideration, the design analysis can be challenging due to the near-overwhelming number of viable possibilities. In addition to industry-standard interface options, there is always the option of designing a proprietary link if standard ones are inadequate or some sort of "lock-out" is desired for competitive or security reasons. As a general rule, unless there is a strongly compelling reason to use a proprietary wireless approach, it's much easier, less risky, less costly, and faster to get to market with a standard technology. Even among these standard versions there are many variations and versions; again, it’s usually best to choose a more-common one, for the same practical reasons that the non-proprietary approach was selected.

Among the contenders for IoT wireless connectivity are Wi-Fi, Bluetooth (including Bluetooth Smart, formerly Bluetooth Low Energy), ZigBee, Z-Wave, DECT, and ANT+. Each has proponents and adherents, of course, as well as varying degrees of vendor support for hardware, software, and compliance. Table 1 shows the primary attributes of each of these standards, but note that standards are always evolving, so the table is just a rough guide. In general, IoT applications do not need much range or high-data rates, and keeping those attributes low results in far-lower power requirements at both the supply and RF stage.

Table 1: Primary attributes of wireless standards.

Implementation is the next step

Once the wireless-connectivity decision is made, the next step is to decide how to actually implement the node. The choices fall into three major groups:

1) Design and build a design from scratch. This is the usually the least-attractive alternative, because it requires considerable RF experience and skills, along with expertise in software protocol and stack management (some of which may be available on the market from third-party sources). Do-it-yourself may be a necessary approach for a proprietary wireless link.

2) Build a wireless node using a reference design (hardware and software) from a reputable, validated IC vendor who also offers development tools. This requires less skill and fewer resources than the option above, but still has many potential risks. It may be the lowest-cost option if the volumes are high enough and the feature set can be stripped back to a minimum. Be aware that any changes, even small ones, to the reference design in BOM or layout may affect performance; RF is always tricky in that respect.

3) Use a complete, ready-to-go module available with necessary software tools. In theory, this is the fastest, least risky approach, and may be very cost-effective compared to option #2, if the vendor's volume is high. It also brings with it some additional certifications to various regulatory standards.

Regardless of the option chosen, there are always regulatory standards and limits to meet related to frequency use, bandwidth, in-band and out-of-band power, distortion and spillover, and other parameters when dealing with RF links. Using a pre-certified module is a major step towards doing this, but it is only a first step. The final product which incorporates the module will need its own certification, as using a certified module is not a guarantee that the final design will meet functional and regulatory requirements. Issues such as antenna type and placement, module arrangement, crystal details, nearby components, and packaging are part of the final certification and approval process.

ICs grow into modules

Many vendors offer complete RF modules based on hybrid, multi-chip, and even single-chip implementations for different IoT wireless standards. In addition to performance and price, power use in various modes is a key consideration, as most IoT applications are battery powered with inaccessible (with impossible or difficult replacement), or use-scavenged (harvested) energy.

A Bluetooth Smart (formerly Bluetooth Low Energy) IC and associated module illustrate how designers can go assess their options and best solution, depending on their application and priorities. Texas Instruments offers the CC2541 family of 2.4 GHz Bluetooth V4.0 low-energy SOCs (such as the TI CC2541F256) which differ primarily in on-board memory, not in RF, data link, or I/O performance. The devices support data rates of 250 kbps, 500 kbps, 1 Mbps, and 2 Mbps, with a variety of very-low-power modes and protocols, including active-mode receive as low as 17.9 mA, active-mode transmit (0 dBm) at 18.2 mA, power-mode 1 with 4-μs wake-Up at 270 μA, power-mode 2 (sleep timer on), and power-mode 3 (external interrupts) at 0.5 μA, operating from a supply of 2 to 3.6 V.

The 6 × 6 mm SOC (Figure 2), integrates an extensive list of other functions and features, including an 8051 microcontroller, a hardwired formatting and protocol stack, considerable RAM, three timers, 23 general-purpose I/O (GPIO) pins, an eight-channel A/D converter, a watchdog timer, a battery monitor, a temperature sensor, and I²C/SPI, and UART interfaces. The device targets—but cannot assure—compliance with worldwide radio frequency regulations such as ETSI EN 300 328 and EN 300 (Europe), FCC CFR47 Part 15 (US), and ARIB STD-T66 (Japan).

Figure 2: Devices in the CC2451 family of Bluetooth Smart SOCs from Texas Instruments are highly integrated, with many features and functions beyond the basic requirements, to simplify design, minimize space, save power, and reduce cost.

Along with the IC, TI offers a range of product-development tools, such as an Evaluation Module Kit (CC2541EMK), a Mini Development Kit (CC2541DK-MINI), SmartRF Software, and more. A typical application circuit for the CC2541 (Figure 3) shows the external components needed.

Figure 3: In a typical application scenario, only a few external passive components are needed to provide complete Bluetooth Smart functionally for the CC2451 devices.

Even with this powerful and highly integrated Bluetooth IC, the multifaceted challenges of successfully incorporating this SOC into their end product is more than many OEMs wish to accept. For these situations, a module such as the TDK SESUB-PAN-T2541 offers an alternative (Figure 4). It uses the TI CC2541F256 SOC but is actually smaller (about 4.6 × 5.6 mm) because it is based on the unpackaged die, and it also includes the crystal, RF filters, bypass capacitors, and some other discrete components of the application circuit (Figure 5). The user must still add an antenna of a size, type, and location which is compatible with the end-product’s specifics.

Figure 4: Despite the completeness of the CC2451 SOC family, some designers prefer not to deal with any challenges of RF-circuit layout, and instead want a complete, certified module such as the SESUB-PAN-T2541 from TDK.

Figure 5: The completely enclosed SESUB-PAN-T2541 module is about 5 mm square, and needs DC power and an external antenna, as well as software drivers and interface stacks.

IoT is one of those fortuitous applications where constituent components and market opportunities conveniently support each other in a positive-feedback relationship—ironically, a relationship which engineers are generally reluctant to see. Vendors of the necessary RF-connectivity components are investing in new products to support the application and drive its growth; in turn, the application growth is causing both existing and new vendors to enter the market and produce new components. This is especially beneficial in the RF area, where new components and software tools are needed to streamline the challenge that designers face when trying to effectively interact with the new and often mysterious world of successful, standard-compliant design.

Summary

An Internet of Things node has three primary functions: sensor, processor, and connectivity interface; the latter is usually a wireless link. Deciding which wireless standard to use, if any, and then how to effectively implement it are closely paired challenges designers must face. There are technical, performance, power, and cost trade-offs, as well as choices of using basic ICs, a chipset plus reference design, or complete module, along with depth of vendor software support, which is a critical consideration for this application area.

For more information about the parts discussed in this article, use the links provided to access product information pages on the DigiKey website.