Protocol selection example - Datalogger
To get a better idea about how to apply the selection criteria discussed earlier to particular applications it is useful to look at sample example implementations.

The first example is for a system that will log humidity and air pressure data every five minutes for a manufacturing monitoring system. In this case, the data must be maintained for at least five years per regulatory requirements but a missing sample every few hours is not critical. The data should remain confidential.

The system will be installed to replace mechanical monitoring methods and a wired system would be impractical. The factory lines vary in length but could be up to 27 meters long and regulations require a sensing station every 7 meters. There is a tight design schedule and the system needs to be released in six months.

From the requirements listed above the design criteria are as follows:

Applications considerations
    " System is designed to capture humidity, air pressure data every 5 minutes
    " Up to five sensing stations
    " Base station must communicate data to PC network
    " System is for retrofitting factories, replaces mechanical logging methods
Robustness & Reliability
    " Factory data should remain confidential
    " Not critical but data logged during factory processing must be maintained per regulatory requirements for five years
Ease of Use
    " System released to market in six months
Hardware & RF Considerations
    " Battery operated -must last minimum of two years

The recommendation in this case is to use SimpliciTI, primarily due to the design schedule and the non-complex nature of the system.

Protocol selection example - Home Security Network
Two other examples show how a slight change in requirements lead to different protocol selections. One is a home security network made to be installed in an existing home so re-wiring is cost prohibitive.

Several different sensors can be optionally installed including smoke, glass breakage, and motion as well as access control. Each sensor communicates to a base station that then communicates to a home security company.

The system should interoperate with other sensors and allow, for example, a smoke detector to be purchased from one company and the motion detector from another. The network must be secure against eavesdropping or tampering. The design schedule can accept a learning curve for engineers to come up to speed on the network protocol.

Application Considerations
    - Home security network
Smoke, glass breakage, motion, occupancy detection
    - Base station must communicate data to home security company
    - User interface must be intuitive
    - Requires faith in an industry standard
    - Should benefit from interoperability with & support of various vendors***
Robustness & Reliability
    - A key design criteria
    - System must remain secure against tampering, eavesdropping
Ease of Use
    - Require standardized, implemented schemes for reliability and security***
    - Plan to integrate home security apps into overall home automation network
    - Willing to take the time to learn and leverage a more complex API
Hardware & RF Considerations
    - Most network devices are battery powered

The conclusion in this case would be to use ZigBee. This is driven by the need to operate with different vendor equipment as well as the standardized reliability and security requirements.

If the requirements for this system were changed so that the requirements listed with asterisks (***) were removed the recommendation would change from ZigBee to 802.15.4.

In other words, the need for a standardized reliability and security implementation as well as the interoperability requirement would drive the protocol to ZigBee. Relax or remove these requirements and the optimum network would be 802.15.4.

Conclusions
Low power wireless networks hold great promise for improving lives and increasing functionality. By focusing first on high-level application considerations and then moving to more specific criteria such as robustness and reliability, ease of use, and hardware criteria, a designer can apply a framework for selecting the proper protocol for his or her application and join the increasing number of products with low power wireless capability.

To read Part 1, go to "Wireless network protocol basics."
To read Part 2, go to "Additional selection criteria"

Miguel Morales is MSP430 Applications Engineer and Kevin Belnap is MSP430 Product Marketing Manager at Texas Instruments, Inc.