PRODUCT HOW-TO: Mesh Networks for Portable Products

By David Ewing

Courtesy of Embedded.com  (02/10/2009 2:25 PM EST)

In addition to "heavy-duty" applications like industrial control and machine communication, wireless capabilities are increasingly required in portable products, such as hand-held units used for medical monitoring applications. There are a variety of different wireless topologies that may be employed depending on the requirements of the application. The most robust and resilient is known as a mesh topology. In this case, wireless nodes that are in radio range of each other will communicate directly. When nodes are not in direct radio range, intermediate nodes will automatically forward any messages to their intended destinations. With some wireless network deployments, it is possible for all of the physical nodes to be externally powered ("plugged into a wall socket"). In this case, power consumption is generally not a major issue and all of the nodes can be active " "talking"/transmitting and/or "listening"/receiving " all of the time. By comparison, in the case of many portable applications, it is necessary for the wireless nodes to be powered by batteries, in which case power consumption can be a significant problem. Even in the case of a power-efficient Radio Frequency (RF) module, an active module will typically consume an average of 50 milliamps (mA). If a node is constantly active ("talking" and "listening"), two AA batteries supplying say 2,500 milliamp-hours (mAh) will be capable of powering it for only 2,500 / 50 = 50 hours, which is a little over two days. For the vast majority of installations, this is simply not acceptable in terms of resource requirements (someone changing the batteries) and expense (batteries aren't cheap). The solution is for the wireless nodes to alternate between being "awake" for a short amount of time and then entering a "sleep" mode in which they consume dramatically less power. In fact, in some "sleepy mesh" implementations, a wireless node can run on two AA batteries for as long as the specified shelf life of the batteries! The Best Cure for Insomnia... As the great American comedian and actor W. C. Fields (1880-1946) once famously remarked: "The best cure for insomnia is to get a lot of sleep." The problem is that some wireless network software protocols and hardware implementations do not easily support this ability. A popular misconception with regard to conventional wireless networks is that the end devices (that is, the wireless nodes with the sensors and actuators that interface with the real world) are able to act as routers to forward traffic through the network. In reality, however, the end devices and routers in a typical network are implemented as distinct nodes. In this typical implementation, the end devices cannot forward traffic through the network; instead, each end device has to communicate with a local router. If a router fails, any end devices associated with the failed node have to be able to access another router in close enough proximity, which means routers have to be located artificially close together. There's also the problem of range, because many end device nodes are limited to only around 0.5 miles line-of-sight (this range falls dramatically when in a building like a hospital or a factory). Another consideration with traditional networks is that, although it may be possible to power-down the end devices, the router nodes have to stay active all of the time as illustrated in Figure 1. In turn, this means that these nodes have to remain on external power. Figure 1. In a conventional wireless network, End Devices (E) and Routers (R) are implemented as distinct nodes; also, Router nodes cannot be put to sleep and therefore have to be externally powered And yet another issue involves the way in which the end devices eventually "wake up." Depending on the network implementation, it may be that specific end devices have to be associated with (tied-to) specific routers. This is obviously a major consideration in a deployment scenario in which potentially hundreds of people are carrying portable products containing wireless end device nodes, because if the nodes wake up "confused" as to where they are and who they can talk to, the network is going to fail in a catastrophic manner.

A number of other concerns associated with traditional wireless networks can be summarized as follows:

1) Depending on the particular implementation, it may be that when an end device enters its sleep mode, all of its output pins are placed in a "floating state". In many cases, this means that external circuitry has to be added to maintain the pre-sleep values on the outputs.

2) Depending on the particular implementation, it may be that when end device enters its sleep mode, it is rendered completely out-of-action; that is, it cannot respond to any external events such as a "mission-critical" button being pressed.

3) Depending on the particular implementation, it may be that when an end device exits its sleep mode, it has to be completely rebooted, which means that it forgets all knowledge of its previous state.

Wakey Wakey Rise and Shine! 
In order to address these issues, Synapse has created a wireless stack " the Synapse's Wireless Mesh Network Protocol " from the ground up. Known as Synapse's SNAP' network protocol, this high-performance stack is designed to run efficiently on cost-effective 8-bit microprocessors.

SNAP-based mesh networks offer an innovative solution to the problem of placing the entire mesh in sleep mode. First, all SNAP Nodes support peer-to-peer communication, which means that they form the mesh network themselves without requiring additional router nodes as illustrated in Figure 2(a) below.

Figure 2. A SNAP-based mesh network; no special router nodes are required.

SNAP Nodes can act individually as "sleepy nodes" or in concert to form a "sleepy mesh". In this latter case, all of the nodes can be instructed to enter their sleep modes simultaneously as illustrated in Figure 3(b) below.

After some pre-determined delay, all of the nodes will automatically wake up again, communicate with each other as required, and then go back to sleep.

Of particular interest with regard to a sleepy mesh comprising tens, hundreds, or even thousands of nodes resident in portable devices, all of which are potentially moving around, is that a SNAP-based network is self-forming.

When the nodes "wake up", they are automatically integrated into the network. (SNAP-based networks are also self-healing; if a node fails for any reason " such as its operator inadvertently damaging it " other nodes will automatically route signals around the failed node.)

There are several additional advantages associated with SNAP nodes implementing a sleepy mesh that can be summarized as follows:

1) Prior to SNAP node entering its sleep mode, it can be instructed to monitor one or more input pins. For example, the node can be instructed to wake up if an operator presses a button or a sensor switch is opened or closed.

2) When a SNAP node enters its sleep mode, all of its output pins maintain their pre-sleep values.

3) When a SNAP Pro-based node exits its sleep mode, it does not need to automatically reboot itself; instead, it remembers its pre-sleep state and can continue executing its application script from the point it left off when it went to sleep.

Due to the fact that Synapse RF Engine modules consume less than 2 micro-amps while in sleep mode, the power savings provided by sleepy nodes in a sleepy mesh can be truly amazing. For the purposes of these discussions, let's assume that the mesh wakes up only once a minute and stays active for 300 milliseconds.

Let's also assume that the active current for a node is 50 mA, the sleep current is 2 microAmperes, and the battery capacity is 2,500 mAh. In this case, the average current will be only 252 microAmperes, resulting in a battery life of almost 10,000 hours, or a little less than 14 months!

So You Have a Network ... Now What? 
One last very important point concerns creating applications for the network. There is an increasing trend for end users to require the ability to modify existing applications or to create new applications themselves.

Applications for traditional wireless networks have to be created in C/C++ or assembly language, and they require a significant amount of wireless and embedded programming expertise.

In order to make wireless technology available to a broader audience, it has to be truly easy to create, deploy, and debug applications. The solution is a software tool called Synapse Portal, which runs on a PC and can be used to develop applications and deploy them "over-the-air" to SNAP-based wireless nodes.

User applications are created in the form of easy-to-understand Python scripts, which are composed of one or more functions. The combination of SNAP and Python is known as "SNAPpy." Clicking on a node in Portal displays the application script that is running on that node.

The user can easily make a modification to the existing script (or create an entirely new script), and upload the new code into the target node over-the-air " all in a matter of seconds.

Furthermore, debugging can be performed by means of 'print' statements in the code, which provides almost instantaneous edit-compile-download-run-debug cycles.

The end result is that SNAP-based nodes are an ideal solution when it comes to implementing a wireless mesh network for almost any application scenario " but especially with regard to networks involving portable, battery-powered devices.

David Ewing is Vice President of Engineering for Synapse Wireless Inc.and brings over 18 years of professional expertise in building and managing software teams. He can be contacted at David.Ewing@synapse-wireless.com.

Original Link