The plethora of wireless sensor network development solutions offeredtoday is overwhelming. It is not possible in any way to give acomprehensive coverage of the market.
Depending on your selection criteria this could be an easy choice orcould be a difficult process. I spent more than a month looking atsolutions from different vendors before jumping into the depths of newhardware, APIs and mountains of documentation. Since all thesestandards are evolving, the updates from the vendors are exacerbatingthe already steep learning curve.
Navigating the proprietary and official standards is difficult,depending on the marketing flavor experiences at some of the web sites.Another difficulty is that different hardware/software solutions arehard to compare, because there is no metric.
It is too hard to determine quantitatively how much better iscertain technology compared to another. The best alternative is to relyon common sense and some guiding principles, such as open source versusproprietary code, open communication standard versus one companysolution, etc. This article will present the problems a designer willface when implementing a wireless sensor network and the factors thatare important in deciding which development platform to select.
Design Challenges for WirelessSensor Networks
There are some specifics as far as wireless sensor networks areconcerned. These make the deployment and maintenance of such networksvery different than other widespread network technologies. We need tobe aware of these specific characteristics in order to do a better jobwhen developing our engineering solutions. Here is a brief descriptionof the major challenging facts about wireless sensor networks.
Cost. Itis possible, depending on the application, to have hundreds orthousands of sensor nodes deployed in a single site. That makes theproject cost sensitive. For some trivial uses like light switches andtire pressure control the expected price is also very low to makingtheir use economically feasible.
Scalability. The number of sensor in a deployment may be in the thousands of node,even millions. With such high numbers new network management issuesarise. This will have a significant impact on maintenance anddiagnostics and will necessitate the widespread use across theapplication of new network diagnostic tools.
Fault Tolerance. Since sensors can be deployed everywhere – on bridges, industrialsites, homes, farms, etc. – they will be subjected to harshenvironmental conditions and may vandalized, stolen or damaged. Whatyou want is a network configuration that continues to operate even ifone or more node in the network fails, is stolen or is damanged.
Localization. In some applications the sensors are deployed sporadically in ageographical location and thy have to organize them selves and find outwhere they are in relation to each other.
Routing. Traditionalrouting schemes are not designed to be energy and processing efficientand are of little use in sensor networks. The approach that should bepursued in this case is to keep the routing to a minimum, and activatedonly when absolutely necessary.
EnergyEfficiency Constraints. Energy efficiency is a very seriousconcern, because the sensor nodes have small and limited energy sourcesuch as batteries. Very rarely device will be able to be plugged intoan electrical power outlet. There are software solutions that canoptimize the consumption of the device by switching to energy savingmodes. These solutions take advantage of the hardware features of thesmart sensor chips available today.Factors in Development PlatformSelection
The factors you need to keep in mind during the selection processinclude the physical layer, transmit power, antenna types, the datalink layer, the network and transport layers.
Physical Layer. I am pretty much concentrating on the IEEE 802.15.4 compliantdevices in this article. The RF chip manufacturers typically come withjust chips or complete RF modules that have the chip, the antennae andthe necessary layout to make it all work. The modules are prettyconveniently designed to be integrated into a PCB and save some timeand research efforts in the specialized RF world. The offered modulesdiffer in their transmission power and antennae type.
Tx Power .Some of the devices a came upon browsing through vendors' web sites hadofferings of standard modules and high power modules. The standardmodules covered standard distances for 802.15.4 ” up to 100 m. The highpowered modules offered much more transmission power and covered 5 or 6times the distance of the normal power modules. Depending on theterrain and visibility the distances of the high power devices couldreach up to 500 meters or more. If this is something important for yourapplication then it is worth looking into.
Antenna Types. The integrated antenna is a small chip directly mounted on the module'sPCB. It could be implemented as a PCB trace. This type of antenna savesspace, but has more requirements for the surrounding surfaces and maynot provide sufficient power for your application. The other type ofantenna is an externally mounted antenna, which is a separate unitconnecting to the module through an RF connector of some type, forexample SMA connector.
|Figure1. Data Link Layer|
Data LinkLayer. As shown in Figure 1,above, the data link layer, is composed of the MAC sub-layer andthe LLC sub-layer. The MAC sub-layer is the one that really counts for802.15.4 applications. The MAC sub-layer has the followingresponsibilities:
* Associates and de-associates devices with the network
* Provides access control to channels used by different devices on thenetwork(s)
* Generates beacon frames
* Guaranteed timeslot management
|Figure2. Network and Transport layer|
Network and Transport Layer. The network and transport layers of concern in the wireless sensorconfigurations considered include Zigbee and Z-wave, as well as severalother newer, and less widely deployed alternatives. The basic structureof the Zigbee protocol is shown in Figure2 above.
The highest level is the application and the lowest is thePhysical/Data link level. The Zigbee stack is in the middle andprovides network structure, security and routing. It is interestingthat the Zigbee specification, which is available for download tocompanies and individuals, specifies also application profiles forZigbee devices.
A Zigbee profile is a description of types of devices and interfacesneeded for a particular application. This is a serious attempt instandardizing future offerings of products from differentmanufacturers.
For more information the reader is encouraged to visit the
One of the more interesting parts of the software layers in awireless sensor network is the Zigbee software stack. Texas instrumentoffers a free version of the stack called Z-Stack. Z-Stack is compliantwith the Zigbee 2006 specification and several platforms. A link toTI's offering is given here:
Z-wave. Z-wave is atechnology coming from the Danish-American company Zensys, whichprovides the protocols and a single chip solution as well asdevelopment kits. The technology is more light weight in terms ofsoftware and hardware and is geared more toward home automation.
There is a Z-wave alliance with many companies participating. Thetechnology uses special MAC layer, transfer and routing layer. Thedevice class specification ensures interoperability. Controllers,routing slaves and slaves are supported in a mesh network.
There are other vendors that have chosen a different path to addressthe design of the upper layers of the OSI 7 layer model. These are veryinteresting products and are all worth looking into. Some examplesinclude Sensinode,Synapse Wireless and
The possible network topologies are star, tree and mesh for sensornetworks. The network consists of two or more devices, with one of thedevices acting as a PAN (Personal Area Network) coordinator.
Star. The star network topology is the simplest one. The central node is thePAN coordinator. Each end device can communicate only through the PANcoordinator.This is the simplest topology, which can be realized only with 802.15.4and no higher software components.
Tree. Thetree network topology is more complicated. Each node in this networktopology can have a parent and one or more children. There is stillonly one PAN coordinator, but there are many other coordinator devices.
Mesh. The mesh network topology is providing alternative paths for routingbetween nodes. There is still only one PAN coordinator and all othernodes are identical. They can pass messages form node to node until thefinal destination is reached. Different routes are possible for thesame destination, which improves the availability of the network givena link failure.
Because building a wireless sensor product involves so many layers ofsoftware, some considerations can be useful. Is the code that shipswith the board proprietary or is it open source? Can you modify itfreely in the development of your product?
What is the software road map of the vendor? Are they planning tokeep up with newer revisions of the standards? Some vendors have someparts of their code offered as open source. An example is
Royalties and Source Code
Royalties for all layers of software are very important to researchbefore a decision is made. I have noticed that the network andtransportation layer come in the form of a library and the developer isnot able to see the source code. How are these layers used whendeployed in a product and an issue needs to be resolved is what isreally interesting. Your end customer is not going to care if theproblem is at the networking layer of the software libraries that yourvendor shipped to you. It is going to be your responsibility to resolveit.
Compliance to standards
Some standards are being updated every year or so, as in the case ofZigbee, so how compliant the solutions are is very important. Howcompliant they will be one year from now is even harder to find out.One way to have more confidence is to find proof of certification forstandard compliance.
RTOS or simple scheduler
A smaller application can pretty much do without a RTOS. Using aforever loop with ISR is the low end of the scale, but for sensordevices is often all one needs. When building a bigger device like agateway, then a RTOS would be indispensable. In order to build supportfor TCP/IP, USB mass storage devices or provide parallel execution ofsoftware tasks one needs to resort to a RTOS. A good free one forsensor devices is Tiny OS. For more information the reader isencouraged to visit the following web sites:
Depending on the real time requirements a version of Linux could beanother choice. For really small devices a proprietary scheduler can dothe job just fine.
IDE and compilers
IDE and compiler choices are as personal as selecting an emailapplication or a web browser. Some of us are in favor of well designedand slick proprietary applications from established vendors and some ofus are more in favor of platforms like Eclipse. I find myself not veryreligious about the type of IDE as long is it is good enough to do thejob. Beware of some Open Source IDEs bundled with the shipped software.By and large they are okay, but I'm not sure they are quite there yetforsome users.
To debug these devices in the middle of their operation is a difficulttask.. Part of it is because they are embedded. But it is also becausethey are in a network and in a network things happen all the time,packets fly from device to device.
In order to take a “stepping through the code” approach one needssome debugging agent running on the device communicating with the IDErunning on the development PC. There is a problem with this approach,since the code downloaded has to contain this debugging agent and hasto be synchronized with the debugger all the time. There is alsopotential for speed problems which impact how the user feels about thedebugging experience in general.
An alternative is to use a packet sniffing device and software forthe wireless network under development. One example for Zigbee and802.15.4 development solutions can be seen at
I found that simple printf likestatements through the UART of mydevelopment kit can be very useful, since a simple Hyper Terminal willdisplay them and help me figure out what is happening.
The majority of the development kits used C/C++ as a developmentlanguage. There is though an interesting offering from Sun, called SunSPOT (Small Programmable Object Technology) which uses a special JVMcalled Squawk. The hardware for the Sun SPOT is pretty impressive witha 180MHz 32-bit ARM920T core processor with 512K RAM and 4M Flash. Thedevelopment is done in Java and one can use popular IDEs like NetBeansto debug and deploy the application.
This in my opinion is the fastest prototyping platform available atthe moment. The only thing that I did not like is that the kit comeswith 802.15.4 and no Zigbee stack or anything that can handle meshnetworking. This kit really delivers a lot for the money. The web sitefor the development kit is at www.sunspotworld.com
Two chipsolutions. Many offerings are based on well establishedplatforms for their CPUs like: 8051, Arm, PIC or Rabbit. They use thewell established IDEs, compilers and debuggers as well as familiarityof the user with the hardware and software for these chips. The RFcomponent is used for a coprocessor handling the Physical and MAClayers in some cases or handling also the networking and the transportlayers in others.
Depending on the RF chip the connection between the main CPU and theRF chip is through some kind of bus, for example SPI. The two chipsolution is a little bit of a pain, since the two chips may come fromdifferent manufacturers and need two different sets of tools forfirmware upgrades and software download. Depending on the applicationtwo sets of development environments may be needed if changes in the RFchip firmware are needed.
Single chipsolutions. The single chip solution is based on a IC with a CPUcore and all standard I/O peripheral units, plusthe RF components to realize the physical and the MAC layer. Thesechips can do it all and seem to be gaining momentum. The adventure hereis the new tools, the new CPU architecture and the single vendor model.Typical configurations of this sort are available from
There are many things to look for when selecting the evaluation boardsof your choice. Amounts of RAM, ROM, CPU core, instruction set come tomind at first, but things like UARTS, available sensors, switches andLEDs are also very important features. LCD displays, Ethernet ports,ADCs and DACs and push buttons are also very useful features to have.
Luckily almost all kits offer a good number of digital and analoginputs and outputs as well as some form of visualization on the boardstaring from LEDs through 7 segment LED display to LCD panels withpretty good resolution. If Ethernet is supported then a TCP/IP stack orRTOS with TCP/IP stack will be needed to enable Ethernetcommunications. If Ethernet is not available then normally USB orserial is the link from the wireless world to a PC.
Another thing to look for are reference designs from the chipmanufacturers to jump start your product development.
During development a frequent operation is downloading your modifiedcode to the board and trying out the new behavior. The downloadingsoftware, the cable and the connectors on the development board allcontribute for better experience during this frequent operation. Thespeed is hardly going to be an issue, since the developed binaries arerelatively small, in the order of several Kbytes to several tens ofkilobytes.
Link to a PC
The link to a PC is useful not only for development when we can senddebug strings to terminal emulation software, but is also used when weneed to visualize data from the network and send control commands tocontroller board, connected to the PC. This scenario is shown in Figure3, below.
One important parameter is the speed of this link, compared to theone the wireless network can achieve. A serial connection may besatisfactory for many applications, but may be inadequate for others.Keeping in mind that this link is used for control and periodic sensordata, it seems to me that 115200 baud rate would be sufficient for anetwork with 250Kbps maximum rate.
|Figure3. Wireless link to a PC|
One important parameter is the speed of this link, compared to thespeed that our wireless network can achieve. A serial connection may besatisfactory for many applications, but may be inadequate for others.Having in mind that this link is used for control and periodic sensordata it seems to me that 115200 baud rate would be sufficient for anetwork with 250Kbps maximum rate.
Jennic's Development Kit
The cost of the development kits I ran across varied from severalhundreds to several thousands. It is hard to judge, though, which oneis going to be cheaper for your project without seeing the software,the development tools and determining the learning curve that will benecessary before a product is ready for the market.
Since I was paying for the kit myself, I had to be cost conscious.With everything else I wanted to have it turned out that Jennic had thebest option for $499.. The cheaper 802.15.4 only solution did not havethe Zigbee stack.
Buying the Zigbee version gave me the opportunity to have access tothe Zigbee stack from the 2006 specification and to get an eventualupgrade to Zigbee Pro when released in the future. The Zigbee Alliancereleased the Zigbee Pro specification on October 2, 2007 while I wasworking on this article.
The main features I liked in the Jennic kit include:
* Free compiler and IDE
* One chip solution with sufficient versatility and power
* Support of 802.15.4 and Zigbee
* Different types of Antennas in two of the boards
* Available high power modules
* Easy connection from controller board to a PC
* Decent documentation
* Support from web forums and FAEs in the US
* Excellent price for 1 coordinator and 4 sensor boards and all of theabove
Not everything has been ideal though. I had some trouble with theintegrated debugger, although I have to admit that printing debugstatements to a HyperTerminal is more practical, especially if one doesnot want to stop the execution of the applications.
The value to me of everything else, though, offsets the growingpains dealing with the multitude of APIs the company has created tosupport their silicon.
With the pace everything is developing in this field it is hard tocover all possible kits offered nowadays. I have tried to mention thevendors that attracted my attention in my search of development kit. Itis possible that there are other solutions that are as good or they maybe even better than what was covered here.
At this moment, I am still very excited about the development kit Igot, but have my eyes open for others as they appear.
Some of my references for thisarticle:
1) Archana Bharathidasan,Vijay Anand Sai Ponduru, Sensor Networks ” An Overview
2) Ian F. Akyildiz, Welian Su,Yogesh Sankarasubramaniam and Erdal Cayirci, A Survey on SensorNetworks, IEEE Communications Magazine, August 2002
3) IEEE 802.15.4 Wireless Networks UsersGuide at www.jennic.com/support
4) Zigbee Stack User Guide.
5) Mikhail Gallev, Catching theZ-Wave, Embedded Systems Design, Oct 02,2006
6) Freescale Semiconductor,IEEE 802.15.4/Zigbee Software Selector Guide, 09/2007
7) Z-Wave Alliance Daytechnical Seminar, June 14, 2005
Some Vendor Links I found useful:
Anton Hristozovis a senior embedded software engineer at Union Switch &Signal in Pittsburgh,PA. He is currently involved in developing software forcommunications-based train control. He can be reached email@example.com