Choosing the best wireless monitoring and control technology
Max explains how SNAP-based networks stack up against ZigBee.
| By |
|
Like any networking technology, wireless sensor networks depend on an implementation euphemistically known as "the stack." Stacks aren't all created equal, and designers will opt for smaller and more portable stacks in some situations. Max examines one such self-forming network stack – Synapse's Wireless Mesh Network Protocol (SNAP) – and discusses how it compares to ZigBee.
When it comes to designing embedded computing applications that feature wireless capability, the choice of which underlying wireless architecture and wireless software stack are used affects two groups: embedded module creators and embedded module end users.
On the one hand, module creators are interested in the technical details and thus ask questions about specific technology features: What is the stack's memory footprint? How much memory will be left over for user applications? Does the stack's provider tie it to a particular microcontroller? How much time and what kind of resources will be required to integrate this wireless technology into the modules and get the underlying network architecture up and running?
On the other hand, end users focus more on the bottom line, asking questions related to practical concerns: How much will this cost? How easy will it be to create, debug, and deploy monitoring and control applications using this technology?
Wireless standards
As for determining which wireless standard embedded computing modules should use, a quick Internet search returns several potential technologies that may be of interest, with the main contenders being SNAP, ISA100, WirelessHART, and ZigBee.
The latter three technologies are designed by committees that face the usual challenges involved in standardization working groups. Multiple contributions and compromises have left these standards unable to take full advantage of the limited bandwidth provided by the IEEE 802.15.4 physical layer. Furthermore, both ISA100 and WirelessHART are just now coming to market.
For these reasons, this article will focus on comparing SNAP and ZigBee in more detail.
Porting the stack
The ZigBee specification is captured in thousands of pages of PDF documents. Taking this specification and creating a unique wireless protocol stack implementation would require many engineer-years of effort.
Alternatively, designers can turn to other engineers who have already performed this task. However, these engineers likely implemented the stack on the microcontroller of their choice, which is not necessarily the microcontroller that the designers wish to use. Re-porting such a stack to a different microcontroller is a nontrivial task because some services in the stack need access to the underlying hardware (timers, I/O pins, and so on), and this access might be hard-coded into the stack.
Figure 1 compares the ZigBee and SNAP stacks. Observe that the SNAP stack includes a Python virtual machine. The combination of SNAP and Python is referred to as SNAPpy. Wireless applications are compiled into processor-independent byte code that runs on the SNAPpy virtual machine. This means that the same application can be run on any processor without the need for recompilation.
 |
| Figure 1 (click image to zoom by 2.3x) |
The most recent incarnation of the ZigBee stack, known as ZigBee PRO, consumes more than 64 KB (the actual value depends on the implementation), thereby forcing module developers to use a more expensive 128 KB microcontroller, which is a significant consideration in cost-conscious deployment scenarios. By comparison, even though it provides full mesh capabilities, SNAP has a very small memory footprint of only 40 KB, thereby leaving more than enough space for user applications.
Written in optimized, portable, industry-standard ANSI C code, the SNAP software stack was designed from the ground up for portability. In particular, the Hardware Abstraction Layer (HAL) provides a layer of abstraction between the main body of the software stack and the physical world. This means that the process of porting the stack to a new processor requires modifications only to the "thin slice" of the HAL. The SNAP stack is already available on multiple processors.
Another fine mesh ...
In the case of mesh routing, network nodes in direct range of each other will communicate directly; when nodes are not in direct radio range, intermediate nodes will automatically forward messages to their intended destinations. If a node catastrophically fails for any reason, other nodes should automatically route signals around the failed node.
ZigBee end devices (the nodes with sensors and actuators) cannot forward traffic through the network. Instead, each ZigBee end device has to communicate either with the main coordinator or a local router (Figure 2). If a router fails, end devices associated with the failed node must be able to access another router in close proximity, which means routers must be located artificially close together. In contrast, all the wireless nodes in a SNAP-based network are peer-to-peer, and there is no need for special coordinator or router nodes (Figure 3).
|
| Figure 2 (click image to zoom by 1.3x) |
 |
| Figure 3 |
Furthermore, it is often necessary for network nodes to be powered by batteries, in which case power consumption can be a significant problem. The solution is for the 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. Unfortunately, ZigBee coordinator and router modules must remain awake all the time, which means they must be powered externally (Figure 4). On the contrary, a SNAP-based network can be configured to implement a sleepy mesh that can extend each node's battery life up to the battery's shelf life (Figure 5).
|
| Figure 4 (click image to zoom by 1.3x) |
 |
| Figure 5 |
Creating and deploying applications
In the case of a ZigBee network, end users must create their applications in C/C++ or assembly language. This involves low-level communications with the stack via an API. Whenever a change is made to an application, it must be recompiled and then physically loaded into the target node(s). The end result can be seemingly endless iterations of laborious edit-compile-embed-run-debug cycles using a variety of special hardware and software tools. All of this requires a substantial amount of wireless and embedded programming expertise that most users simply do not have. The only alternative is to use an additional microprocessor (and memory) for sending AT commands to the ZigBee module, but this is an expensive option.
Conversely, SNAP-based networks are complemented by a software tool called Portal, which can be used to develop applications and deploy them over the air to the wireless nodes. Small, fast, and extremely efficient, Portal is seen by the network as just another node. The PC-running Portal may be physically connected to any SNAP node, which subsequently acts as a bridge to the network.
User applications are created in the form of easy-to-understand Python scripts, which comprise one or more SNAPpy functions. Any SNAPpy function in any node on the network can be called from Portal or any other node on the network. Similarly, any node on the network can invoke a SNAPpy script running on Portal.
Clicking on a node in Portal displays the application script running on that node. The user can then call up the source for that script, make a modification, 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 users can create applications and administer a SNAP-based network without actually having to know anything about wireless networks. This approach makes wireless technology accessible to a much broader range of embedded system module creators and users.
Clive (Max) Maxfield is the president of TechBites (www.TechBites.com), a marketing consultancy with clients ranging from small businesses to high-tech corporations, including Synapse Wireless. Max received his B.Sc. in Control Engineering in 1980 from Sheffield Polytechnic (now Sheffield Hallam University), Sheffield, England. Since that time, Max has designed everything from silicon chips to PCBs, and his articles have appeared in technical magazines around the world. Max is the author and coauthor of several books, including Bebop to the Boolean Boogie: An Unconventional Guide to Electronics, The Design Warrior's Guide to FPGAs: Devices, Tools, and Flows, and How Computers Do Math.
Synapse Wireless
256-852-7888
support@synapse-wireless.com
www.synapse-wireless.com
Posts
