EM250 EM260 EM2420 EM250/EM260 - Datasheet Archive

 

Developer's Guide 27 April 2007 120-4021-000A EM250 EM260 EM2420 Ember Corporation 343 Congress Street Boston MA 02210

 

EmberZNet Application Developer's Guide 27 April 2007 120-4021-000A EM250 EM250 EM260 EM260 EM2420 EM2420 Ember Corporation 343 Congress Street Boston MA 02210 617.951.0200 www.ember.com wireless semi conductor solut ions Copyright © 2007 by Ember Corporation All rights reserved. The information in this document is subject to change without notice. The statements, configurations, technical data, and recommendations in this document are believed to be accurate and reliable but are presented without express or implied warranty. Users must take full responsibility for their applications of any products specified in this document. The information in this document is the property of Ember Corporation. Title, ownership, and all rights in copyrights, patents, trademarks, trade secrets and other intellectual property rights in the Ember Proprietary Products and any copy, portion, or modification thereof, shall not transfer to Purchaser or its customers and shall remain in Ember and its licensors. No source code rights are granted to Purchaser or its customers with respect to all Ember Application Software. Purchaser agrees not to copy, modify, alter, translate, decompile, disassemble, or reverse engineer the Ember Hardware (including without limitation any embedded software) or attempt to disable any security devices or codes incorporated in the Ember Hardware. Purchaser shall not alter, remove, or obscure any printed or displayed legal notices contained on or in the Ember Hardware. Ember, Ember Enabled, EmberZNet, InSight, and the Ember logo are trademarks of Ember Corporation. All other trademarks are the property of their respective holders. Contents Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Documentation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x Chapter 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1 Embedded Networking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-2 ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-3 Radio Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-3 Networking: Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-8 Wireless Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-8 Ember ZigBee Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-9 Network Formation and Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-10 Chapter 2 ZigBee Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-1 General Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-2 IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-2 Hardware and Software elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-3 ZigBee Network Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-3 Network Node Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-5 ZigBee Routing Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-6 The ZigBee Stack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-8 Chapter 3 Designing an Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1 The A, B, Cs of Application Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1 Basic Application Design Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-2 Scratch Built or Adapted Design? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-2 Basic Application Task Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-2 Define Endpoints, Callbacks and Global Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-2 Set Up Main Program Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-6 Manage Network Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-7 Message Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-10 Housekeeping Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-14 Chapter 4 Designing an Ember ZigBee Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1 Network Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2 EmberZNet Application Developer's Guide 120-4021-000A Contents | iv Resolving Network Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4 Network Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-5 Network Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-6 Qualifying Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-6 Environmental Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-9 Processor Utilization Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-10 Hardware Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-10 Development Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-11 EmberZNet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-11 Programming with EmberZNet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-16 Universal Design Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-23 Creating and Joining a Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-23 Forming Network Relationships (Binding) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-26 Managing Coordinator Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-26 Specific Design Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-27 Channels and Interference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-27 Battery Powered Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-28 Mobile Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-28 High Device-Count Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-28 Chapter 5 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-1 Network Layer Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-3 APS Layer Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-5 Commercial Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-5 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-5 Trust Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-7 Commercial Security Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-8 Joining a Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-9 Network Rejoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-10 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-11 Network Key Updates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-12 Implementing Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-13 New Considerations for Forming and Joining Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-13 Stack Implementation of Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-14 Commercial Security Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-15 Packet Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-16 Link Keys API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-17 Joining a Trust Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-17 Running a Network Without a Trust Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-18 Chapter 6 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-1 EmberZNet Stack Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-2 Compiler Toolchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-3 InSight Desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-4 Analyzing ISD Session Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-4 InSight Desktop Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-4 EmberZNet Application Developer's Guide 120-4021-000A Contents | v Capturing and Saving Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-5 Reviewing Capture Session Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-6 Viewing Packet Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-8 Peripheral Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-11 Bootloaders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-11 Standalone Bootloader. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-11 Application Bootloader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-11 Range Test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-11 Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-12 Token Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-12 Hex File Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-12 InSight USB Link Programmer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-13 RF Evaluation Tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-13 Chapter 7 Reconciling the HAL and Hardware Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1 EmberZNet HAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1 Supported hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-2 Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-2 Directory structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-3 Platform and Microcontroller Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-3 Compiler Header File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-3 Hardware Board File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-3 Include Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-3 Functional Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-3 Board Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-4 PacketTrace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-5 Serial Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-5 Debug Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-6 Virtual UART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-6 Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-7 Token Utility Application Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-7 Simulated EEPROM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-7 Bootloaders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-8 EM2420 EM2420 radio improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-8 Preprocessor definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-8 Required. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-8 Optional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-9 HAL Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-9 Utility Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-9 API Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-9 Chapter 8 Introduction to the EmberZNet API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-1 Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-1 EmberZNet Stack API Reference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-2 Hardware Abstraction Layer (HAL) API Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-3 Application Utilities API Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-4 EmberZNet Application Developer's Guide 120-4021-000A Contents | vi Chapter 9 Advanced Design Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1 Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-2 Neighbor Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-5 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-5 Description of Relevant Neighbor Table Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-5 Neighbor Exchange Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-6 How Two-way Costs are Used by the Network Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-6 EmberZNet 3.0 Enhancement: Rapid Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-6 EmberZNet 3.0 Enhancement: Connectivity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-7 Cluster Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-7 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-7 ZigBee Cluster Foundation: Inside Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-8 Walkthrough: Temperature Measurement Sensor Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-12 ZigBee Cluster Library: Functional Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-14 ZCL and EmberZNet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-14 Installation and Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-16 How to Use the ZCL Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-18 Extended PAN IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-21 New ZigBee Network Rejoin Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-22 The New Face of Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-23 Cluster IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-23 APS Frame. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-23 Address Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-24 Sending Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-26 Message Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-27 Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-28 Disable Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-28 Incoming Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-29 New Storage Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-29 Binding Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-29 Removed Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-30 Chapter 10 Bootloading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-1 Memory Space for Bootloading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-2 Standalone Bootloading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-2 Application Bootloading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-3 Bootloading Software Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-4 Design Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-4 Standalone Bootloading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-5 Intrduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-5 Modes - Serial / OTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-5 Serial Upload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-6 Over-the-Air Upload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-9 Hybrid Mode Uploads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-11 Upload Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-11 Bootloader Utility Library API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-12 EmberZNet Application Developer's Guide 120-4021-000A Contents | vii Manufacturing Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-18 Example Standalone Bootloading Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-19 V2 Standalone Bootloader Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-20 Other Packets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-21 Ember Bootload (EBL) File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-25 Application Bootloading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-28 EM250 EM250 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-28 Programming Bootloading into the Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-35 EM260 EM260 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-38 Chapter 11 Token System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-1 Standard (non-indexed) Tokens. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-2 Indexed Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-3 Counter Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-3 Custom Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-4 Mechanics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-4 Default Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-6 Stack Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-6 Manufacturing Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-7 Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-8 For More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-8 Chapter 12 EZSP-UART Host Interfacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-1 UART Gateway Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-1 EZSP-UART Software Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-2 Interface Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-3 Command Line Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-3 Serial Ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-4 EM260 EM260 RST/CTS Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-5 uart-test-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-5 uart-test-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-8 Host Statistics and Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-9 EM260 EM260 Debug Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-10 Chapter 13 Designing with the EM250 EM250 & EM260 EM260 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-1 Designing with the EM250 EM250 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-1 EM250 EM250 Design Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-2 RF Balun (BLN1, L1, R1, C1, and C2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-6 Harmonic Filter (L6, C24, and C25) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-8 High-Frequency Crystal Reference (Y1, C7, C8, and R11) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-9 Optional Low-Frequency Crystal Reference (Y2, C21 and C22) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-9 Extending the Range of an EM250 EM250 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-12 EM250 EM250 Layout Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-14 EmberZNet Application Developer's Guide 120-4021-000A Contents | viii Custom Devices for the EM250 EM250 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-18 Setting Manufacturing Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-18 Installing the Bootloader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-21 Designing with the EM260 EM260 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-30 EM260 EM260 Design Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-31 Debug and Programming Interface (SIF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-32 EM260 EM260 ZigBee-compliant Network Coprocessor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-33 Chapter 14 Testing and Debug Strategies for ZigBee Application Development . . . . . . . . . . . 14-1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-1 Hardware and Application Choices for Testing and Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-2 Initial Software Application Development using Development Kit Hardware . . . . . . . . . . . . . . . . . . . . . . .14-2 Transition to Custom Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-3 Initial Development and Lab Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-4 Initial Development Environment and System Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-4 Moving to Beta and Field Trials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-10 Hardware and Test System for Larger System Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-10 Reproducing Common Field Conditions or Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-11 Initial Field Deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-12 Release testing and criteria for release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-12 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Index-1 EmberZNet Application Developer's Guide 120-4021-000A Preface Purpose This document: · Describes how to design and implement a project using the Ember ZigBee compliant EmberZNet network software. · Contains introductory information on radio propagation and embedded mesh networking topologies, and details on networking that are important for understanding how the system functions and making the correct design decisions. Ember recommends that you read this document from beginning to end, because later chapters rely on information in previous chapters. You can then refer to specific chapters as necessary during your development process. Audience This document is intended for project managers and for software engineers who are responsible for building a successful embedded mesh networking solution using the Ember radio, the EmberZNet network stack, and tools. This document assumes that the reader has a solid understanding of embedded systems design and programming in the C language. Experience with networking and radio frequency systems is useful but not expected. Getting Help Developer kit customers are eligible for training and technical support. You can use the Ember website, www.ember.com, to obtain information about all Ember products and services, and to sign up for product support. You can also contact Ember technical support at support@ember.com. If you have any questions about any Ember products or services, please contact your Ember account representative at one of the following locations: EmberZNet Application Developer's Guide 120-4021-000A x United States 343 Congress Street Boston, MA 02210 Telephone: 617-951-0200 Fax: 617-951-0999 Asia/Pacific HK Spinners Industrial Bldg, Phase 5 5/F Flat D 760-762 Cheung Sha Wan Road Kowloon Hong Kong Telephone: +852-8120-5375 Europe 300 Cambridge Science Park, Milton Road Cambridge, CB4 0XL, UK Telephone: 44 (0) 1223 423322 Fax: 44 (0) 1223 423390 Documentation Conventions Notation Meaning Example Bold Node Key UPPERCASE A keyboard key ENTER | Delimits a hierarchy of menu options, which ends with the option to choose. Open | Save Courier 120-4021-000A A GUI label Identifies file names and program identifiers, such as constants and function names. EMBER_SLEEPY_END_DEVICE serial.h emberStartScan() EmberZNet Application Developer's Guide 1 1.1 Introduction O VERVIEW As embedded system design has evolved, the need for networking has become a basic design feature. Like more general purpose comuters, embedded systems have moved toward wireless networking. Most wireless networks have pushed toward ever higher data rates and greater point-to-point ranges. But not all design applications require the high end wireless networking capabilities. Low data rate applications have the potential to outnumber the classic high data rate wireless networks world wide. Simple applications such as lighting control, HVAC control, fire/Smoke/CO alarms, remote doorbells, humidity monitors, energy usage monitors, and countless others function very well with low data rate monitoring and control systems. The ability to install such devices without extensive wiring decreases installation and maintenance costs. Increased efficiencies and cost savings are the primary motives behind this applied technology. A wireless sensor network (WSN) is a wireless network consisting of distributed devices using sensors to cooperatively monitor physical or environmental conditions, such as temperature, sound, vibration, pressure, motion or pollutants, at different locations. In addition to one or more sensors, each node in a sensor network is typically equipped with a radio transceiver or other wireless communications device, a small microcontroller, and an energy source, usually a battery. The size of a single sensor node can vary from shoebox-sized nodes down to devices the size of coins. The cost of sensor nodes is similarly variable, ranging from hundreds of dollars to a few dollars, depending on the size of the sensor network and the complexity required of individual sensor nodes. Size and cost constraints on sensor nodes result in corresponding constraints on resources such as energy, memory, computational speed and bandwidth. Wireless Personal Area Networks (WPAN) have emerged as a result of the IEEE 802.15.4 standard for low data rate digital radio connections between embedded devices. The ZigBee Alliance was formed to standardize industry efforts to supply technology for networking solutions that are based on 802.15.4, have low data rates, consume very low power and are thus characterized by Ember ProductName Guide 120-4021-000A Page 1-2 Introduction long battery life. The ZigBee Standard makes possible complete and cost effective networked homes and similar buildings where all devices are able to communicate for monitoring and control. 1.2 E MBEDDED N ETWORKING While the term wireless network may technically be used to refer to any type of network that functions without the need for interconnecting wires (e.g. Ethernet cables), the term is most commonly use to refer to a telecommunications network, such as a computer network. Wireless telecommunications networks are generally implemented with radios, for the carrier or physical layer of the network. One type of wireless network is a wireless LAN, or Local Area Network. Tt uses radio instead of wires to transmit data back and forth between computers on the same network. The wireless LAN has become commonplace at hotels, coffee shops and other public places. The Wireless Personal Area Network (WPAN) takes this technology into a new area where the distances required between network devices is relatively small and data throughput is low. Wireless networks have significantly impacted the world as far back as World War II. With the use of wireless networks, information could be sent oversees or behind enemy lines easily and quickly and was more reliable. Since then wireless networks have continued to develop and their uses have significantly grown. Cellular phones are part of huge wireless network systems. People use these phones daily to communicate with one another. Emergency services such as the police department utilize wireless networks to communicate important information quickly. People and businesses use wireless networks to send and share data quickly whether it be in a small office building or across the world. In the control world, embedded systems have become commonplace for operating equipment using local special purpose computer hardware. Wired networks of such devices have become commonplace in manufacturing environments and other application areas. Like all computer networks, the interconnecting cable systems and supporting hardware are messy, costly and sometimes impossible to install. Wireless networking of embedded systems (i.e. Embedded Networking) have become commonplace. However, the costly embedded networking solutions have only been justifiable in high-end applications where the costs are a secondary consideration. For low cost applications with low data rate communications requirements, there has not been a good solution until the IEEE 802.15.4 standard for wireless personal area networking was released in 20031. The ZigBee group was formed to establish IEEE 802.15.4 implementation standards for low data rate embedded networking product applications that would allow flexibility, reliability and interoperability. Although wireless networks allow you to eliminate messy cables and enhance installation mobility, there is a downside from the potential for interference that might block the radio signals from passing between devices. This interference may be from other wireless networks or from physical obstructions that interfere with the radio communications. Interference from other wireless networks can often be avoided by using different channels. ZigBee, for example, has a channel scanning mechanism on start up of a network to avoid crowded channels. 1. The current version as of this writing is the IEEE 802.15.4-2006 standard. Ember ProductName Guide 120-4021-000A Introduction Page 1-3 Standards based sytems such as ZigBee and WiFi use channel sharing mechanisms at the medium access control layer (MAC) to allow sharing of channels. In addition, the purpose of the mesh networking within ZigBee is to provide redundant paths for data within the network that are automatically rediscovered and used to avoid interference in a local area. Another problem is that wireless networks are may be slower than those that are directly connected through a cable. Yet not all applications require high data rates or large data bandwidth. Most embedded networks function very well at reduced throughputs. the application designer needs to ensure their system data rates are within what is achievable with the system being used. Wireless network security is a unique problem since the data can easily be overheard by evesdropping devices. ZigBee has a set of security services designed around AES 128 encryption to ensure the system designer has a choice of security levels based on the needs of the application. Careful design around these standards helps maintain high levels of network security. Other networking standards exist such as Bluetooth. But each standard has its own unique strengths and essential areas of application. In the case of Bluetooth and Zigbee, the bandwidth of Bluetooth is 1 Mbps, while ZigBee's is one-fourth of this value. The strength of Bluetooth lies in its ability to allow interoperability and replacement of cables. ZigBee's strength is low cost, long battery life and simple mesh networks for large network operation. Bluetooth is meant for point to point applications such as handsets and headsets, whereas ZigBee is focused on the sensors and remote controls market and other large distributed networks. 1.3 Z IG B EE Chapter 2 provides an in-depth discussion of the ZigBee industry group and its efforts to standardize IEEE 802.15.4 based applications. 1.4 R ADIO F UNDAMENTALS Radio has been a part of our world since Marconi and DeForrest's work at the opening of the 20th Century. But what exactly is radio and what does it have to do with networking? Radio is the wireless transmission of signals, by modulation of electromagnetic waves with frequencies below those of visible light. Electromagnetic waves are, in the case of Radio, a form of non-ionizing radiation, which travels by means of oscillating electromagnetic fields that pass through electrical conductors, the air and the vacuum of space. Electromagnetic Radiation does not require a medium of transport like sounds wave. Information can be imposed on electromagnetic waves by systematically changing (modulating) some property of the radiated waves, such as their amplitude or their frequency. When radio waves pass an electrical conductor, the oscillating fields induce an alternating current in the conductor. This can be detected and transformed into sound or other signals that reproduce the imposed information. Ember ProductName Guide 120-4021-000A Page 1-4 Introduction The word 'radio' is used to describe this phenomenon and radio transmission signals are classed as radio frequency emissions. Contrary to popular belief, cell phone transmissions are classed as microwave frequency emissions because of the higher frequencies of their transmitted signals. The range or spectrum of radio waves used for communication has been divided into arbitrary units for identification. The FCC and NTIA arbitrarily define that the radio spectrum in the United States is that part of the natural spectrum of electromagnetic radiation lying between the frequency limits of 9 kilohertz and 300 gigahertz, divided into various sub-spectrums for convenience. The following names are commonly used to identify the various sub-spectrums: 3 kHz to 30 kHz 30 kHz to 300 kHz 300 kHz to 3,000 kHz 3,000 kHz to 30,000 kHz 30,000 kHz to 300,000 kHz Very Low Frequencies (VLF) Low Frequencies (LF) Medium Frequencies (MF) High Frequencies (HF) Very High Frequencies (VHF) 300,000 kHz to 3,000,000 kHz Ultra High Frequencies (UHF) 3,000,000 kHz to 30,000,000 kHz Super High Frequencies (SHF) 30,000,000 kHz to 300,000,000 kHz Extremely High Frequencies (EHF) Each of the sub-spectrums listed above are further subdivided into many other sub-portions or "bands." For example, the American AM Broadcast Band extends from 535 kHz to 1705 kHz, which is within the portion of the spectrum classified as Medium Frequencies. AM Broadcast Band stations are therefore Medium Frequency stations, but not all Medium Frequency stations transmit within the AM Broadcast Band. 1.4.0.1 Frequency Bands As mentioned, the radio spectrum is regulated by government agencies and by international treaties. Most transmitting stations require a license to operate, including commercial broadcasters, military, scientific, industrial and amateur radio stations. Each license typically defines the limits of the type of operation, power levels, modulation types and whether the assigned frequency bands are reserved for exclusive or shared use. There are three frequency bands that can be used for transmitting radio signals without requiring licensing from the Unitesd States Government: 900 MHz: The 900 MHz band was used extensively in different countires for different products including pages and cellular devices. This band was considered to have good range characteristics. However it can be less popular for products becaus eit is not a worldwide unlicensed band an products therefore need to be modified depending on where thay are being used. 2400 MHz: The 2400 MHz band is a very commonly used frequency band. This band was one of the first worldwide unlicensed bands and therefore became popular for wireless consumer products. Typical wireless technologies that use this band are 802.11b (1-11 Mbps), 802.11g (1-50 Mbps) and 802.15.4. Ember ProductName Guide 120-4021-000A Introduction Page 1-5 5200-5800 MHz: The 5200Mhz band has three sub-bands, the lowest being for indoor home use only, while the 5800Mhz frequencies can be used for long distance wireless links at very fast speeds (30 ­ 100 Mbps). A common strategy is to use 2400 MHz in residential and home environments. The ZigBee Standard endorses the use of this band. Note A detailed discussion of ZigBee and the ZigBee Standard is the subject of Chapter 2. 1.4.0.2 Signal Modulation So, we can send an electrical signal out in the air, but we must make the electrical signal behave in a way that allows it to transfer intelligent information. This process is called modulation, but you can think of it also as a way to encode information to be transmitted to a receiver that will decode, or demodulate, the information into a useful form. The basic Radio Frequency (RF) signal has a fundamental frequency that can be visualized as an alternating current whose frequency is referred to as the carrier wave frequency. The earliest method used for encoding information onto the carrier wave involved switching the carrier wave on and off is a specific time duration pattern. This was known as Continuous Wave (CW) mode. The carrier frequency can also be varied in its amplitude (i.e. signal strength) or its frequency. These two modulation methods are called Amplitude Modulation (AM) and Frequency Modulation (FM) respectively. It is possible to impose a signal onto the carrier wave using these three basic modulation techniques and creative variations of these techniques. The EM250 EM250 and EM260 EM260 use a form of Offset Quadriture Phase-shift Keying (OQPSK) to modulate the carrier wave. Phase-Shift Keying (PSK) is a digital modulation scheme that conveys data by changing, or modulating, the phase of a reference signal such as the carrier wave. PSK is a derivative of FM techniques. All digital modulation schemes use a finite number of distinct signals to represent digital data. In the case of PSK, a finite number of phases are used. Each of these phases is assigned a unique pattern of binary bits. Usually, each phase encodes an equal number of bits. Each pattern of bits forms the symbol that is represented by the particular phase. The demodulator, which is designed specifically for the symbol-set used by the modulator, determines the phase of the received signal and maps it back to the symbol it represents, thus recovering the original data. This requires the receiver to be able to compare the phase of the received signal to a reference signal - such a system is termed coherent. Note Fortunately, designing with the EM250/EM260 EM250/EM260 does not require you to be an expert with this technology; just being aware of it is enough. Ember ProductName Guide 120-4021-000A Page 1-6 Introduction 1.4.0.3 Antennas An antenna (or aerial) is an arrangement of electrical conductors designed to emit or capture electromagnetic waves. The ability of an antenna to emit a signal that can be detected by another antenna is referred to as Radio Propagation. Antennas are made to a certain size based on the operating frequencies. You can not take an antenna from a 2400 MHz radio and use it effectively on a 5800 MHz radio, or vice versa. There are two fundamental types of antennas, which, with reference to a specific three dimensional (usually horizontal or vertical) plane: · Omni-directional (radiates equally in all directions) · Uni-directional (aka Directional)(radiates more in one direction than in the other) All antennas radiate some energy in all directions in free space but careful construction results in substantial transmission of energy in certain directions and negligible energy radiated in other directions. Because of the nature of mesh networking, in general an omnidirectional antenna is desired to provide as many commuication paths as possible. 1.4.0.4 How Far Signals Travel We can tell how far a radio signal will travel, and get an idea of how much information we can transmit based on: · The amount of power the antenna is transmitting into the air. · The distance between the transmitting and receiving stations. · How much radio signal strength the receiving radio needs. · What type of physical/electrical obstructions are in the way. 1.4.0.5 Radio Transmit Power - It's all about the dB. Radio transmit power is measured in decibels, or "dB." Sometimes you may hear radio tranmit power talked about in terms of watts. Instead of using watts you can convert wattage to dB2. Doing so lets you calculate radio links using simple addition and subtraction. For example, a typical power amplified Wireless radio card transmits at 100milli-watts (or mW). Instead of 100mW, we say it has a power output of 20dBm. If 1mW, or 0dBm, is the baseline for power in decibels, then +3dBm is some power level above 1mW (2mW to be specific). This is the standard output power of the EM250/EM260 EM250/EM260 device. In Boost Mode, that can be increased to +5dBm, or 3.16mW. Using a power amplifier module can increase the transmit power to 20dBm, but requires more power to operate. 1.4.0.6 The Amount of Radio Signal Needed to "Hear" The radio also needs to be able to hear a radio signal at a certain level. As the radio signal travels through the air, it weakens (much like shouting at someone from a mile away). The minimum signal strength required for a receiver to understand the data is called the receive sensitivity. 2. dBm= 10*log10(P/ 0.001) Ember ProductName Guide 120-4021-000A Introduction Page 1-7 When a radio signal leaves the transmitting antenna your dB will be a high number (for example: 20 dB). As it travels through the air, it loses strength and will drop to a negative number. This is why the amount of power a receiver needs is often rated as low as -90 dB. The use of negative numbers can be confusing at first. Just remember, 20 is higher than 0, and -20 is lower than 0. Thus, if you can achieve a signal level of -75 dB and your radio needs -95, you have 20 dB of extra signal to accommodate interference and other issues. Note The EM250 EM250 and EM260 EM260 are typically rated for a receive sensitivity of -98dBm. 1.4.0.7 How Far Can the Radio Signal Go? Now that we know how much power we can put out, and how much we need, we can figure out how much radio signal will be available at the receiving end. The way we figure this out is to determine how much loss3 is present between the radio transmitter and receiver. For example, free space loss of a 2.4GHz signal at 5 miles is 118.36 dB. So, we can estimate the range of our network as: What Add or subtract it Transmitter power + Transmitter antenna gain + Receiver antenna gain + Transmitter's coaxial cable loss Receiver's coaxial cable loss Free Space Loss @ 5 miles Total : The value (all in dB!) 15 dBm 14 dBi 14 dBi 2 dB 2 dB 118.36 dB -79.36 dB Based on these calculations, we can guesstimate that a 15 dBm radio hooked into a 14 dBi antenna, transmitting 5 miles through free space to another radio hooked up to a 14 dBi antenna will yield approximately -79 dB of signal. however, physical obstructions such as buildings or trees would have a substantial impact on these calculations. Typical ZigBee networks use smaller lower cost antennas without the gain increase and only use power amplifiers if extended range is required. So now that you've tried the manual calculation, you'll be happy to know there are easier ways to figure this out. The Ember development kits for the EM250 EM250 and EM260 EM260 come with a range test application. The Ember RF Evaluation Kit has a pair of test devices based on the EM250 EM250 that can be used to perform empirical range testing for your embedded wireless network in virtually any environment. it is recommended basic range testing be conducted in the expected environment to evlauate if extended range is required. 3. A reference table of common Free Space Losses is available on the BC Wireless Website at . A spread sheet for Microsoft Excel and Open Office is also available from BC Wireless. Ember ProductName Guide 120-4021-000A Page 1-8 1.5 Introduction N ETWORKING : B ASIC C ONCEPTS A network is a system of computers and other devices (such as printers and modems) that are connected in such a way that they can exchange data. This data may be informational or command oriented, or a combination of the two. A networking system consists of hardware and software. Hardware on a network includes physical devices such as a computer workstations, peripherals, and computers acting as file servers, print servers, and routers. These devices are all referred to as nodes on the network. If the nodes are not all connected to a single physical cable, special hardware and software devices must connect the different cables in order to forward messages to their destination addresses. A bridge or repeater is a device that connects networking cables without examining the addresses of messages or making decisions as to the best route for a message to take. In contrast, a router contains addressing and routing information that lets it determine, from a message's address, the most efficient route for the message. A message can be passed from router to router several times before being delivered to its target destination. In order for nodes to exchange data, they must use a common set of rules defining the format of the data and the manner in which it is to be transmitted. A protocol is a formalized set of procedural rules for the exchange of data. The protocol also provides rules for the interactions among the network's interconnected nodes. A network software developer implements these rules in software applications that carry out the functions required by the protocol. Whereas a router can connect networks only if they use the same protocol and address format, a gateway converts addresses and protocols to connect dissimilar networks. Such a set of interconnected networks can be referred to as an internet, intranet, wide area network (WAN) or other specialized network topologies. The term Internet (note the capitalization) is often used to refer to the largest worldwide system of networks, also called the Worldwide Internet. The basic protocol used to implement the WorldWide Internet is called the Internet Protocol, or IP. A networking protocol commonly uses the services of another, more fundamental protocol to achieve its ends. For example, the AppleTalk Data Stream Protocol (ADSP) uses the Datagram Delivery Protocol (DDP) to encapsulate the data and deliver it over an AppleTalk network. The protocol that uses the services of an underlying protocol is said to be a client of the lower protocol; for example, ADSP is a client of DDP. A set of protocols related in this fashion is called a protocol stack. 1.6 W IRELESS N ETWORKING Wireless networking mimics the wired network, but replaces the data interconnection medium from wire to a radio signal (i.e. wireless). Protocols are essentially the same as used in wired networks, although some additional functionality has been added, so that the two types of networks remain interoperable. However, wireless networks have emerged that do not have a wired counterpart requiring interoperability. These specialized networks have their own hardware and software4 foundations to enable reliable networking within the scope of their unique environments. Ember ProductName Guide 120-4021-000A Introduction 1.7 Page 1-9 E MBER Z IG B EE D EVICES Ember has developed networking hardware (the EM2xx IC family) and software (the EmberZNet Stack and development tools) to facilitate implementation of a Wireless Personal Area Network (WPAN) of devices for sensing and control applications. The diagram in Figure 1.1 represents a typical wireless device using Ember/ZigBee techologoies. The RF Data Modem is the hardware responsible for sending and receiving data on Figure 1.1 Typical ZigBee Device Block Diagram the network. The Microcontroller represents the computer control element that originates messages and responds to any information received. The Sensor block can be any kind of sensor or control device. Such a system can exist as a node on a ZigBee network without any additional equipment. Any two such nodes, with compatible software, can form a network. Large networks can contain thousands of such nodes. The EM250 EM250 can provide both the RF and microcontroller portions of Figure 1.1. And the EM260 EM260 provides only the RF and networking part of the system, acting as a coprocessor to any microcontroller, DSP or similar device required for the application. EmberZNet 3.0 networks support the device types listed in Table 1.1. Table 1.1: EmberZNet Device Types Device type Description EMBER_COORDINATOR (ZigBee coordinator) Relays messages and can act as a parent to other nodes. Every personal area network (PAN) must be started by a node acting as the coordinator. This device is normally always powered on. EMBER_ROUTER (ZigBee router) A full-function routing device that relays messages and can act as a parent to other nodes. These devices must be always powered on. EMBER_SLEEPY_END_DEVICE (ZigBee end device with RXOffWhenIdle flag set) An end device whose radio can be turned off to save power. EMBER_MOBILE_END_DEVICE (ZigBee end device with RXOffWhenIdle flag set) A sleepy end device that can move through the network. Coordinator and router devices form the basis of hte network and route data for other devices in the network. 4. Most networking protocols are based, to some degree, on the Open Systems Interconnection (OSI) Model. Ember ProductName Guide 120-4021-000A Page 1-10 Introduction End devices send and receive messages only from their parent. This allows the end devices to sleep while their parent holds messages for them until they wake up. End devices do not relay messages for other devices. 1.7.1 Network Formation and Operation The coordinator initiates network formation. In a mesh network, after forming the network, the coordinator can function as a router. The EmberZNet libraries enable any device, including an end device, to act as a coordinator and form a network. After forming a network, the coordinator can accept requests from other devices that wish to join the network. Depending on the stack and application profile used, the coordinator might also perform additional duties after network formation. A device finds a network by scanning channels. When a device finds a network with the correct stack profile that is open to joining, it can request to join that network. A device can send its join request to the network's coordinator or one of its router nodes. If the application is using a trust center, it can control the conditions under which join requests are accepted or denied. All nodes that communicate on a network transmit and receive on the same channel, or frequency. EmberZNet uses a personal area network identifier (PAN ID) to identify a network. The PAN ID provides a way for two networks to exist on the same channel while still maintaining separate traffic flow. Note that when two networks exist in the same channel they have to share time on the air. The network layer discovers and maintains available routes so that the user application does not need to know anything about the underlying routes used to deliver a message to a destination node. Route discovery varies among networks and routing mechanisms. There are two general approaches, active and dynamic discovery: · Active route discovery tries to keep certain routes up to date at all times. This consumes additional network overhead but means that routes are available whenever a node wishes to send data. · Dynamic, or on-demand, route discovery incurs less overhead network traffic but can cause a delay when a route changes because of shifting radio frequency conditions or network rearrangements. The EmberZNet mesh stack uses on-demand route discovery. In a ZigBee tree stack, routing is initially done along the links of the network's tree topology, although this route might be indirect. For example, two nodes might be located at the same depth of the network tree-that is to say, they are the same number of hops away from the coordinator node. If they join the network through different parent nodes, they can only route messages to one another by passing the message up the tree as many levels as necessary until they find a common ancestor node. This tree routing mechanism assumes that the network tree topology is always stable-tree paths never change, so discovery is not required. Routes are deterministic and can be calculated mathematically. In an EmberZNet mesh stack, after a route between a source node and target node is discovered, the source node sends the message to the first node in the route, as specified in the source node's routing table. Each intermediate node uses its own routing table to forward the message to the next node along the route, until the message reaches the target node. The information about the route is next-hop, where each node knows what the next hop should be Ember ProductName Guide 120-4021-000A Introduction Page 1-11 for delivery to a particular destination. If a route fails, the source node must find a new route. Ember ProductName Guide 120-4021-000A Page 1-12 Ember ProductName Guide Introduction 120-4021-000A 2 2.1 ZigBee Overview I NTRODUCTION ZigBee is an alliance of companies working together to enable reliable, cost effective, low power, wirelessly networked, monitoring and control products based on an open global standard. The ZigBee Alliance is operated by a set of promoter companies that make up the Board of Directors. These currently include Ember, ST Microelectronics, Philips, Schneider Electric, Siemens, Eaton, Mitsubishi Electric, Samsung, Honeywell, Texas Instruments and Freescale. The Alliance activities are accomplished through workgroups dedicated to specific areas of the technology. These include a network group, a security group, an application profile group and several others. Business is conducted in an open manner resulting in standards available to members and then non-members for download. To use the ZigBee technology within a product, companies are required to become members of the Alliance. Ember has been a member of the ZigBee Alliance from the founding and our networking stack has been a Golden Platform for testing and certification for all new revisions of the standard to date. Ember is active in a variety of areas within the Alliance and with helping customers adopt ZigBee technology. Because ZigBee is committed to open and interoperable devices, standards have been developed from the Figure 2.1 ZigBee architecture physical layer through the application layer as shown in Figure 2.1. At the physical and MAC layer ZigBee adopted the IEEE 802.15.4 standard. The networking, security and application layers have all been developed by the ZigBee Ember ProductName Guide 120-4021-000A Page 2-2 ZigBee Overview Alliance. An ecosystem of supporting systems such as gateways and commissioning tools has also been developed to simplify the development and deployment of ZigBee networks. Extensions and additions to the standards continue to be developed and Ember is committed to supporting these as they are available. Ember provides a standard networking API based on the ZigBee specification across the different platforms (EM2420 EM2420, EM250 EM250 and EM260 EM260). Ember also provides sample applications using the ZigBee Application profiles to allow rapid development of customer applications. 2.1.1 General Characteristics ZigBee is intended as a cost effective and low power solution. It is targeted to a number of markets including home automation, building automation, sensor networks, health care, automated meter reading and personal health care monitoring. The general characteristics for a ZigBee network are as follows: · · Low data rate ­ The 2.54 GHz band supports a radio data rate of 250 kbps. Actual sustainable traffic through the network is lower than this theoretical radio capacity. As such, ZigBee is better used for sampling and monitoring applications. · Small and large networks ­ ZigBee networks vary from several devices to thousands of devices communicating seamlessly. The networking layer is designed with several different data transfer mechanisms (types of messages) to optimize the network operation based on the expected use. · Range ­ Typical devices provide sufficient range to cover a normal home and readily available designs with power amplifiers extend the range substantially. A distributed spread spectrum is used at the physical layer to be more immune to interference. · 2.1.2 Low power ­ Devices can typically operated for several years on AA type batteries using suitable duty cycles. Simple network installation, start up and operation ­ The ZigBee standard supports several network topologies and the simple protocols for forming and joining networks allow systems to self configure and fix routing problems as they occur. IEEE 802.15.4 ZigBee networks are based on the IEEE 802.15.4 MAC and physical layer. The 802.15.4 standard operates at 250 kbps in the 2.4 GHz band and 40 kbps/20kbps in the 900/868 MHz bands. A number of chip companies provide solutions in the 2.4 GHz band with a smaller number supporting the 900/868 MHz band. ZigBee adopted the 802.15.4 ­ 2003 version of the standard. The IEEE has since issued a 2006 version of this standard that has not yet been adopted by ZigBee. The 802.15.4 standard provides some options within the MAC layer on beacon networks, guaranteed time slots that are not used by ZigBee in any current stack profiles. As such, these items are not normally included in the ZigBee software stack to save code space. ZigBee also has specific changes to the 802.15.4 MAC that are documented in Annex D of the ZigBee specification. The 802.15.4 medium access control (MAC) layer is used for basic message handling and congestion control. This MAC layer includes mechanisms for forming and joining a network, a CSMA mechanism for devices to listen for a clear channel as well as a link layer retries and Ember ProductName Guide 120-4021-000A ZigBee Overview Page 2-3 acknowledgement of messages for reliable communications between adjacent devices. These underlying mechanisms are built upon by the ZigBee network layer to provide reliable end to end communications in the network. The 802.15.4 standard is available from www.ieee.org 2.1.3 Hardware and Software elements A ZigBee solution requires implementation of a ZigBee radio and associated microprocessor (together in a single chip or separately), and implementation of an application on top of a ZigBee stack. Typically a developer can purchase a ZigBee radio and software as a bundled package although there are some third party software stacks that have been developed. Typically reference designs for the hardware and sample applications for the software are provided by the hardware and software provider. Based on these, a hardware developer can customize the hardware to their specific needs. Alternatively, there are a number of module providers that can deliver compact and low cost modules that can use used. Because of the embedded nature of typical ZigBee applications, software application development is typically interrelated with the hardware design to provide an optimal solution. The software developer can develop a complete ZigBee application extending the sample application provided by the stack provider Alternatively, there are a number of third party software development firms that specialize in development of ZigBee applications and can assist in new product development. The EmberZNet stack includes a number of typical sample applications as well as some common utilities or tools. These include: · · Gateway interfaces to interface the ZigBee network to other systems · Programming tools for the microprocessor · 2.1.4 Over the air bootloaders to allow upgrading of system software after deployment Network sniffer and debug tools to allow viewing and analysis of network operations. ZigBee Network Topologies ZigBee supports a variety of network topologies. The actual topology used should be based on the network design, the individual devices that compose the network, and the data expected to flow within the system. EmberZNet supports two basic topology types: · · Ember ProductName Guide Tree Network Mesh Network 120-4021-000A Page 2-4 ZigBee Overview 2.1.4.1 Tree network The EmberZNet tree topology (see Figure 2.2) is used for address assignment and provides a routing method. Routers branch out in a tree-like fashion from the coordinator, and end devices are potential sleepy devices. The ZigBee specification supports a mesh overlaid on the tree, also known as table routing. Figure 2.2 Tree Network 2.1.4.2 Mesh network Embedded mesh networks make radio systems more reliable by allowing radios to relay messages for other radios. For example, if node A cannot send a message directly to node B, the embedded mesh network relays the message B through one or more intermediary nodes. EmberZNet supports three types of mesh network topologies, as shown in Figure 2.3: · Star Network · Full Mesh Network Star Hybrid Full Mesh Figure 2.3 Ember ProductName Guide Star, full mesh, and hybrid mesh networks 120-4021-000A ZigBee Overview Page 2-5 · Hybrid Mesh Network Note: Blue devices in Figure 2.3 are end devices and can be sleepy or, in mesh stacks, mobile. 2.1.4.3 Star network In a star network, one hub is the central point of all communications. The hub can become bottlenecked with network/processing bandwidth. This topology is not very mesh-like, and transmission is limited by the hub's communication radius. Outlying nodes can be battery powered. In EmberZNet tree and mesh stacks, this topology is formed by a group of end devices with a coordinator node as their parent. The coordinator node serves as network hub. 2.1.4.4 Full mesh network In a full mesh network, all nodes are router nodes, including the coordinator after it forms the network. Because all nodes can relay information for all other nodes, this topology is least vulnerable to link failure; it is highly unlikely that one device might act as a single point of failure for the entire network. 2.1.4.5 Hybrid mesh network A hybrid mesh network topology combines star and mesh strategies. Several star networks exist, but their hubs can communicate as a mesh network. A hybrid network allows for longer distance communication than a star topology and more capability for hierarchical design than a mesh topology. This topology is formed by the EmberZNet mesh stack, using router devices as hubs for the star subnetworks, where each hub can have end devices attached to it. 2.1.5 Network Node Types The ZigBee specification supports networks with one coordinator, multiple routers, and multiple end devices: 2.1.5.1 Coordinator A ZigBee coordinator (ZC) is responsible for forming the network. This included selection of an appropriate channel after scanning available channels and selecting a PAN ID. After forming the network, the coordinator acts as a router. If the network profile does not use mesh routing, the coordinator plays a crucial role as the root of the tree in the tree routing algorithm. NOTE Only a network coordinator can be designated as a trust center. For some applications, the coordinator may have added responsibilities such as being the trust center or network manager. These choices are up to the application developer and in some cases these choices are made by the appropriate ZigBee stack profile. For example under Home Controls the coordinator is always the trust center for the network. Ember ProductName Guide 120-4021-000A Page 2-6 ZigBee Overview 2.1.5.2 Routers Router devices (ZR) provide routing services to network devices. Routers can also serve as end devices. Unlike end devices, routers are not designed to sleep and should generally remain on as long as a network is established. 2.1.5.3 End devices End devices (ZED) are leaf nodes: they communicate only with their parent nodes and, unlike router devices, cannot relay messages intended for other nodes. Depending on the network stack, end devices can be of several types: · Sleepy end devices (EmberNodeType EMBER_SLEEPY_END_DEVICE) power down their radio when idle, and thus conserve resources. Sleepy end devices are also sometimes known as rx-off-when-idle devices. This is a standard ZigBee device type. · Non-sleepy end devices (EmberNodeType EMBER_END_DEVICE) do not route messages for other devices but they remain powered during operation. These devices are known as Rx-on-when-idle devices. This is a standard ZigBee device type. · Mobile end devices (EmberNodeType EMBER_MOBILE_END_DEVICE) is a sleepy end device with enhanced capabilities that enable it to change its physical location and quickly switch to a new parent router. This device type is an Ember modification to the basic ZigBee sleepy end device to provide added capabilities and management of mobile devices. EmberZNet tree stacks support non-sleepy and sleepy end devices; EmberZNet mesh stacks support only sleepy end devices. When joining a tree stack, an end device that intends to sleep must identify itself as a sleepy end device. 2.1.6 ZigBee Routing Concepts ZigBee has several routing mechanisms that can be used based on the network and expected traffic patterns. The application designer has choices of which mechanism to use and this selection should be made as part of the system architecture and design. In actual practice one application may use several of these routing mechanisms because some devices are performing one-to-one communications while all devices are also communicating to a central monitoring device. The types of routing discussed below are tree routing, table routing, multicast routing, broadcasts and many-to-one/source routing. In the ZigBee stack, routing is initially done along the links of the network's tree topology, although this route might be indirect. For example, two nodes might be located next to each other but at the same depth of the network tree-that is, they are the same number of hops away from the coordinator node. If they join the network through different parent nodes, tree routing of messages to one another occurs by passing the message up the tree as many levels as necessary until they find a common ancestor node. This tree routing mechanism assumes that the network tree topology is always stable-tree paths never change, so discovery is not required. Routes are deterministic and can be calculated mathematically. Table (or mesh) routing also exists in the ZigBee stack. This table routing is a derivative of AODV next hop routing. A node can send a unicast message table routing by requesting route discovery-either as needed or by force-in the APS unicast options for that message. When a Ember ProductName Guide 120-4021-000A ZigBee Overview Page 2-7 node sends a message to a destination for which a table route has been discovered, the tree stack first attempts tree routing delivery; if tree routing delivery fails and the message specifies the APS Retry option, the stack falls back on table routing. The ZigBee Pro stack never uses tree routing for message delivery because an alternate addressing schemes is used and the tree does not exist in the network. Routes are formed when one node sends a route request to discover the path to another node. After a route is discovered between the two nodes, the source node sends its message to the first node in the route, as specified in the source node's routing table. Each intermediate node uses its own routing table to forward the message to the next node (i.e. hop) along the route until the message reaches its destination. Each node uses its own routing table to determine the next hop that is required to deliver messages to any other node. If a route fails, a route error is sent back to the originator of the message who can then rediscover the route. Multicast routing provides a one-to-many routing option. A multicast is used when one device wants to send a message to a group of devices such as a light switch sending an on command to a bank of 10 lights. Under this mechanism, all the devices are joined into a multicast group. Only those devices that are members of the group will receive messages although other devices will route these multicast messages. A multicast is a filtered limited broadcast and therefore should be used only as necessary in applications because over use of broadcast mechanisms can degrade network performance. A multicast message is never acknowledged. Broadcast routing is a mechanism to send a message to all devices in a network. There are network level broadcast options to send to routers only or also to send broadcasts to sleeping end devices. A broadcast message is repeated by all powered devices in the network 3 times to ensure delivery to all devices. While a broadcast is a reliable means of sending a message, it should be used sparingly because of the impact on network performance. Repeated broadcasts can limit any other traffic that may be occurring in the network. Many-to-one routing is a simple mechanism to allow an entire network to have a path to a central control or monitoring device. Under normal table routing, the central device and the devices immediately surrounding it would need routing table space to store a next hop for each device in the network. Given the memory limited devices often used in ZigBee networks, these large tables are undesirable. Under many-to-one routing, the central device sends a single route discovery that established a single route table entry in all routers to provide the next hop to the central device. All devices in the network then have a next hop path to the central device and only a single table entry is used. However, often the central device also needs to send messages back out into the network. This would result in a similar increase in route table size. Instead, incoming messages to the central device first use a route record message to store the next hops used. The central device then stores these next hop routes in a route record table. Outgoing messages include this route record in the network header of the message. The message is then routed using next hops from the network header instead of from the route table. This provides for large scaleable networks without increasing the memory requirements of all devices. It should be noted that the central device does require some additional memory if it is storing these route records. For detailed information on message delivery, refer to the ZigBee specification available from www.zigbee.org. Ember ProductName Guide 120-4021-000A Page 2-8 ZigBee Overview 2.1.7 The ZigBee Stack ZigBee provides two separate stacks. This has been a point of confusion so the summary is as follows: · ZigBee 2004 ­ was released in 2004 and supported a home control lighting profile. This stack was never extensively deployed with customers and is no longer supported. · ZigBee 2006 ­ was released in 2006 and supports a single stack known as the ZigBee stack (explained below) · ZigBee 2007 ­ is expected to be released in Q2 2007 and will support 2 stacks: the ZigBee stack and the ZigBee Pro stack. The ZigBee and ZigBee Pro stacks are complete implementations of the MAC, networking layer, security services and the Application framework. Devices implementing ZigBee and ZigBee Pro can interoperate by acting as end devices in the other type of network. For example, if a network is formed around a ZigBee Pro coordinator it can have ZigBee Pro routers only but both ZigBee and ZigBee Pro end devices. NOTE The ZigBee 2004 stack is not interoperable with either the ZigBee or ZigBee Pro stacks. The ZigBee stack is formed around a central coordinator and uses tree addressing to establish the network. Tree routing is normally used (although table based routing can also be used). This stack supports residential security only. The ZigBee Pro stack is formed around a central coordinator but uses a stochastic addressing scheme to avoid limitations with the tree. Table routing is always used and network level multicasts and many-to-one routing are also available. This stack supports residential or commercial security. Ember does not recommend deploying systems on the ZigBee stack because the ZigBee Pro stack has a number of features that are necessary for long term network stability and reliability. The ZigBee stack is typically used for small static networks. 2.1.7.1 ZigBee Profiles On top of the basic ZigBee stack are application profiles, or simply profiles. These are developed to specify the over the air messages required for device interoperability. A given application profile can be certified on either the ZigBee or ZigBee Pro stack. The existing application profile groups are as follows: · · Commercial Building Automation (CBA) ­ defining devices for large commercial buildings and networks. · Telecom Application (TA) ­ Wireless applications within the telecom area. · Wireless Sensor Network Applications (WSN) ­ Wireless sensor networks · Ember ProductName Guide Home Automation (HA) ­ defining devices for typical residential and small commercial installations Advanced Metering Initiative (AMI) ­ For utility meter reading and interaction with household devices 120-4021-000A ZigBee Overview Page 2-9 · Personal Home Health Care (PHHC) ­ Monitoring of personal health in the home environment A ZigBee Cluster Library (ZCL) forms a generic basis for some of these application profiles. This library exists to allow reuse of simple devices such as on/off switch protocols between different profiles. Application profiles define the roles and functions of devices in a ZigBee network. There are two types of application profiles administered by the Alliance: · Public Application Profiles are developed by members of the ZigBee Alliance to assure devices from different manufacturers can interoperate. · Manufacturer Specific Application Profiles are developed by product developers creating private networks for their own applications where interoperability is not required. If you develop a product based upon your own private application profile, the ZigBee Alliance requires you to make use of a unique private profile identifier to ensure the product can successfully co-exist with other products. The ZigBee Alliance issues these unique private profile ID's to member companies upon request and at no charge. An application can also be developed using a public profile with private extensions for specific features from a manufacturer. 2.1.7.2 ZigBee Addressing Schemes ZigBee contains two network addressing schemes built into the stack. It also has the ability to assign addresses manually from a commissioning tool. The ZigBee stack uses tree addressing. Under this addressing mechanism the coordinator starts the network and initiates the network space. The number of routers and end devices are set upon start up of the network. Network addresses are assigned using a distributed addressing scheme that is designed to provide every potential parent with a finite sub-block of network addresses. These addresses are unique within a particular network and are given by a parent to its children. The ZigBee coordinator determines the maximum number of children any device, within its network, is allowed and this number of children are allocated between router children and end devices. Each child address is related to its parents address. Every device has an associated depth which indicates the minimum number of hops a transmitted frame must travel, using only parent child links, to reach the ZigBee coordinator. The ZigBee coordinator itself has a depth of 0, while its children have a depth of 1. Multi-hop networks have a maximum depth that is greater than 1. The tree addressing mechanism used under the ZigBee stack has some known limitations. These include potentially running out of addresses in a local area because the tree. Under this situation new devices cannot join the network because no suitable parent exists. The tree routing also requires rebuilding of the network, including devices receiving new addresses, to reestablish a broken parent to child link. Because of these limitations, an alternate mechanism was developed for larger networks. Ember ProductName Guide 120-4021-000A Page 2-10 ZigBee Overview The ZigBee Pro stack uses a stochastic address assignment mechanism. Under this mechanism the coordinator is still used to start the network. Each device (routers and end devices) that joins the network is given a randomly assigned address from the device it is joining. The device conducts conflict detection on this address using network level messages to ensure the address is unique. This address is then retained by a device, even if the parent address changes. Under ZigBee Pro, there is also intended to be provisions for a commissioning tool for setup and configuration of networks. These commissioning tools can be used to provide addresses manually. Under the Ember implementation of ZigBee, we recommend using ZigBee Pro with the alternate address assignment mechanism. We have more than 3 years of field experience with this system and consider it very stable and robust. 2.1.7.3 ZigBee Messaging Options Please see "ZigBee Routing Concepts" on page 6I. 2.1.7.4 ZigBee Compliance ZigBee compliance is based on a building block of compliance testing used to ensure that each layer is tested. Products that meet all compliance requirements may be branded "ZigBee Compliant" and can display the ZigBee logo. Figure 2.4 ZigBee Logo The ZigBee radio and MAC are required to have passed the applicable parts of IEEE 802.15.4 certification testing. Parts of the MAC not required for ZigBee operation are not required for this testing. ZigBee stacks are required to be built on certified IEEE 802.15.4 platforms. ZigBee stack providers are required to have the stack tested against a standard ZigBee test plan known as ZigBee Compliant Platform Testing. This testing validates the basic network, security and ZDO operations for the stack. ZigBee products are required to be built on a ZigBee Compliant Platform. The developer can choose to build a public or manufactures specific application. Those application which are manufacturer specific are tested against a specific set of tests to validate basic operation. Public profiles are more extensively tested using a standard ZigBee test for the application layer commands. Each shipping product has to be certified and substantive changes to the product after certification can require recertification. All of the ZigBee test plans are developed and tested using at least 3 members products to ensure interoperability between different implementations. Companies are required to become members of the ZigBee alliance to ship product containing the ZigBee stack. There are specific rules for use of the ZigBee logo on product that are detailed on the ZigBee web site (www.zigbee.org). Ember ProductName Guide 120-4021-000A ZigBee Overview Page 2-11 2.1.7.5 Applying ZigBee There are a set of design decisions to be made in any ZigBee implementation. While these areas of application development are covered in more detail in later chapters, the initial design choices are as follows: 1. 2. Selection of a ZigBee Platform ­ The available ZigBee platforms from Ember include the EM2420 EM2420, EM250 EM250 and EM260 EM260. The EM2420 EM2420 is not recommended for new designs but continues to be supported for legacy designs. The EM250 EM250 is a single chip implementation designed for low cost implementations. The EM260 EM260 is a ZigBee coprocessor designed for use with a host microprocessor or for those applications requiring increased memory or specialized peripherals not available on the EM250 EM250. The first design choice in applying ZigBee is to select which type of device is to be used. The Ember API for implementation of ZigBee is standard across these platforms to make switching applications simple. Many networks are mixed with EM250 EM250's in some devices and EM260 EM260 in other devices. 3. Select a Bootloader ­ There are several choices available for in the field upgrading of devices. The simplest choice is to not upgrade devices once deployed (no bootloader). However, this is not recommended as there are often issues that are found during initial field trials or beta testing that require software updates. There are two bootloaders provided by Ember and commonly used. One is a stand alone bootloader that provides for using and upgrading the entire flash contents. This bootloader is limited to one hop transfer of data. The application bootloader can be used across multiple hops under the application control but requires extra flash to store the image being bootloaded. 4. Designing the Data Flow and Message Types to be Used ­ Based on the application, the expected flow of data in the network can be determined. The use of APS level messages, multicasts, broadcasts, or many-to-one routing has to be considered. 5. Developing and Debugging the Appl