Connectivity Architecture and Protocol Options for Wireless Sensor Deployment

As more people embrace the concept of cloud-based connectivity for infrastructure monitoring and control, chip and module makers are stepping up to the plate to introduce point-to-point, aggregated, and mesh network connections for distributed sensors and remote access.

These higher-level building blocks allow engineers and companies to create and introduce products at a much quicker pace than ever before. No longer is there the need to research and learn the intricacies of several 100-page-plus network topology specifications. No longer is there the need to repeat PCB layouts and tweak component values to find that just right combination that maximizes performance while minimizing space, power, and cost.

What’s more, there is a closely knit relationship between finished OEM and eval modules/kits that let you reference a pre-developed design, modify it, experiment a bit, and reproduce the results in your constrained system. In most cases, source code for the communications and protocol stacks are available (usually under NDA) so you can modify the native functionality of an OEM device, and, often, share the same processor.

This article looks at several new entries in the wireless sensor arena as well as the development kits and demo units that support them. It discusses some of the choices we can make concerning connectivity architectures and protocols, and examines the pros and cons of each solution. All parts, data sheets, tutorials, and development systems referenced here can be found on the Digi-Key website.

Architectural choices

Every new product idea carries with it its own set of constraints. The building-block standards that are in place will dictate protocols, frequency bands, modulation techniques, and so on. However, the diversified needs of the rapidly expanding push to put everything online can make it difficult to know which specific solution is best; you can fit a square peg in a round hole if you hit it hard enough. However, a streamlined and elegant solution is always preferred.

Simple sensors and actuators that function in proximity, and independently of any web presence, can take advantage of low-cost narrow-band transmission schemes. This can include non-web-enabled alarm systems, video links, energy management systems (like solar tracking in a remote area), and so on.

These architectures can typically be point-to-point, master-slave, peer-to- peer, or client-server architectures as long as they are relatively simple. Keeping protocols simple allows lower-cost microcontrollers that typically do not contain the processing power and memory resources to manage higher-level networking functions like dynamic re-routing and data integrity verification. Security also is a concern and many simple processors do not include encryption features. A benefit with point-to- point is that you can easily create your own communications link since they are very simple and impose very little overhead.

However, more applications such as environmental sensing, animal tracking, traffic sensors, threat detectors (chemical, radiation, biological), and more are creating larger mesh networks that need higher levels of processing power and resources. The goal is to find your way to the web, and dynamic-mesh architecture can weave its way to an access point when an intermediate node drops out. This allows cloud connectivity and remote processing to take place.

ZigBee

Some protocols and parts for ZigBee are inherently a mesh-network architecture right out of the box. Several low-cost and low-power peripheral transceiver chips like the Atmel AT86RF233-ZUR are ideal candidates for wireless sensors that need low-power 2.4 GHz ZigBee (or RF4CE or 6LoWPAN), connectivity (Figure 1). As an SPI-accessed bolt-on peripheral chip, it supports up to 2 Mbit/sec data rates and can be driven by almost any external processor. It can also be placed further away from the processor, possibly providing better reception with less local noise.

Figure 1: Bolt-on transceiver chips can be very comprehensive and complete, but the vendor-provided code may need to be ported to the specific external processor used in your design.

On the other hand a ZigBee solution is a software-intensive solution that requires more processing than some simpler protocols. The built-in arbitration and mesh re-rerouting capabilities and tables may prove very beneficial for very large networks deployed over very large areas.

If you do not use an Atmel processor, you may have to port the stack software to use the resources and architecture of the specific microcontroller you choose. Details are provided in the Introduction to IEEE 802.15.4 Low Power Wireless Networks product training module.

As a result, the single-chip radios with embedded micros often provide the best quality coupling with software for integrated solutions. This can help speed up design and test significantly. For example, consider the Freescale Kinetis W Series MCUs with on-chip radios. The series features parts like the MKW01Z128CHN 1 GHz single-chip radio with ARM Cortex-M0 processor and can be used for UHF and VHF 300 MHz to 1 GHz frequency bands. Its cousin, the Freescale KW2x series boosts this to a more powerful ARM Cortex-M4 processor with more flash, RAM, and USB as well. Parts like the MKW22D512VHA5 combine both high-performance, low-power processors with good mixed signal (12-bit A/D, 16-bit D/A, and on-chip analog comparators) capability and a fully-compliant 2.4 GHz 802.15.4 (governs ZigBee) standard (Figure 2).

Figure 2: Higher-performance low-power processors integrated within the single-chip radio can provide the tightest coupling between hardware and software, especially with vendor-supplied protocol stack software. The benefits of high-performance mixed-signal functionality, encryption, and advanced debug interfaces are other key features.

Time savers

Comprehensive-, flexible-, and modular-development systems such as the Freescale Tower System Development Platform can be very important to a successful design. These dev systems can allow early stage testing and speed-up designs. What’s more, a comprehensive development environment like this also allows integration of other technologies the supplier may offer. However, where the radio is concerned, there is nothing quicker than fully functional OEM solutions. 

The fastest way to move a design to production comes in modular and OEM form coupled with a flexible development environment. Take, for example the XKA2C-Z7T-U ZigBee-to-cloud development system from Digi International.

This kit includes an Xbee gateway, a Pro module, and a development board. It comes ready to test for low-power, remote control, and access of the rudimentary temperature sensor and potentiometer. LEDs, buzzer, and I/O lines are also accessible for digital I/O. A Cloud Kit Video shows how to control street lights using the company’s Xbee version of ZigBee.

Direct connectivity to the cloud

With public and widespread availability of Wi-Fi a global trend, the possibility exists to make devices with direct connectivity to the cloud. Wi-Fi chips and modules are the best choice for these types of systems. With many sensor systems, size usually matters and smaller is better. The 3.3 V general-purpose Econais EC19W-R2 Wi-Fi IoT modules claim to be the world’s smallest self-contained module with an embedded antenna (clocking in at 16 mm x 14 mm x 2.8 mm).

As a member of the WiSmart Series of transceivers and development systems, they feature a host-less mode for standalone applications, as well as a very useful UART or SPI-to-Wi-Fi functionality using a command-set-based approach. The low-power integrated 32-bit processors support point-to-point client and group-owner modes and feature impressive data rates of up to 20 Mbits/sec (UDP) or 13 Mbits/sec (TCP-STP).

A key element in allowing rapid test and development is the Econais EC19W01DK, which exploits the module’s full TCP/IP stack and soft-AP functionality. Cloud-integration services are built in so these parts are ideally suited to connect directly to back-end servers, data accumulators, or remote-controlling machines.

Another fully functional Wi-Fi surface-mountable module comes via a partnership between Murata and Electric IMP. The Murata LBWA1ZV1CD-716 Wi-Fi Network controller with software houses an STMicroelectronics STM32F405 32-bit ARM Cortex-M4 processor that can be programmed and developed using the LBWA1ZV1CD-TEMP-A for both evaluation and test (Figure 3). Both digital I/O, as well as analog functionality, are on-board including an accelerometer, audio in and out, color sensing, temperature sensing, and more.

Figure 3: Modular test platforms aid in rapid development of new boards as well as OEM versions for quick time-to-market.

Reducing throughput needs through distributed processing

When sensor arrays are deployed over a specific area, it can be more effective to aggregate them using a centrally located hub. This allows better range since end-to-end distances double, and permits the hub to do some rudimentary processing which can reduce the amount of data sent to the cloud. Using Wi-Fi everywhere in this case would just cause unnecessary crowding on the same band and protocol that the aggregator would typically be using. This means protocols and standards like Bluetooth Low Energy have their place in the world of distributed wireless sensors.

Smart Bluetooth modules from Anaren include the Integrated Radio (AIR) modules like the A20737AGR. These are low-cost surface-mount radio modules that directly target wireless sensors. Key is the company’s Multi-Sensor Development Kit (MSDK). Mixed-signal sensors like an accelerometer, magnetomer, temp sensors, and more are included and an online development tool called Atmosphere lets designers create code to allow connection of Bluetooth to smart mobile devices

Bluetooth Mesh-based development kits from CSR like the DB-CSR1010-10185-1A also can use PCs, smartphones, or tablets as a means of aggregating or taking control of potentially hundreds of Bluetooth “Smart Things,” individually or simultaneously. The CSR Mesh Network Kit uses a simple direct-connect scheme that does not require hubs, routers, or other access-point directing devices. This can allow Bluetooth LE-distributed sensors to use a cellular-based aggregator instead of a Wi-Fi-based aggregator for direct connect to cloud-based back-end services. Each module can run its own application above the lower level network administrative tasks (Figure 4).

Figure 4: User application layers ride above the wireless communications administration controlled by the dedicated on-chip firmware.

There are other protocols and parts taking aim at distributed wireless-sensor arrays, both web-enabled and isolated. Do not discount the possibility of new protocols and bands opening up as well. Today, well-supported devices and modules are ready for use and resources are available to help speed the learning, prototyping, certification, and debugging of your designs.

The bottom line is that distributed closed and cloud-connected IoT sensor arrays are going to become more common going forward. As we have discussed, several good choices and options exist that let you rapidly test and deploy these systems. The data is out there waiting to be gathered.

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