AppBuilder is Ember’s tool for quickly generating ZigBee compliant applications. Revision B.

Attachment: 

120-5056-000_IntroducingAppBuilder.pdf

Under the hood gives a look at the detailed behavior of selected aspects of the ZigBee specification.

Note! It is not necessary to understand these topics to start using ZigBee. These are intended as advanced material for people with particular interest or need to understand it.

Each device has a configurable number of endpoints, with a minimum of 2. Endpoint 0 is always the ZDO (see below), and can be used to query the device about its capabilities.

Endpoints 1-240 are available to be used by the application, and they provide unique “addresses” on the same device. In the basic case, only a single endpoint is used.

Device Addresses in ZigBee

Every device in a ZigBee network has two addresses — its globally unique 64-bit address, called the EUI64 or IEEE 64-bit address, and its PAN-unique 16-bit address, or short address.

64 bit addresses

The EUI64 is uniquely allocated by the IEEE to companies which then use them on their networking devices. Ember allocates a single EUI64 address to each chip at manufacturing time — this may be overridden (though not erased) at manufacturing time if desired.

16 bit addresses

If you are comfortable with the concepts in ZigBee 101, this section introduces some additional terms and structures that are important to understand when discussing ZigBee and using ZigBee tools.

ZigBee and its underlying network layers provide a system of retries and acknowledgments that are designed to efficiently manage the uncertainty of RF communication.

We’ll discuss these retries and acknowledgments layer-by-layer:

• MAC retries and ACKs (802.15.4)
• NWK retries (ZigBee NWK layer)
• APS retries and ACKs (ZigBee APS layer)

MAC retries and ACKs (802.15.4)

The MAC layer attempts transmission 5 times.

Ember’s throughput testing provides end-to-end throughput and latency characterization for a variety of configurations: with and without APS retry, with and without security. This can be used as a starting point, but the system designer must understand the assumptions made in this model:

• Maximum payload packet — this results in the most efficient transfer – smaller packets will have less application bandwidth available.
• No retries — this data is taken when all packets are successfully transmitted without retries. Retries can reduce throughput for the individual message concerned although average throughput may remain almost the same if only one message experiences problems, for example.
• Geographic diversity — the methods below assume that the network is somewhat spread out – if all devices are in a single hop from each other, this is a “dense” network and has a different set of constraints than a “large” network. Due to implementation details in the EmberZNet stack, a network is considered “dense” if each device has (on average) more than 32 neighboring devices.

Two different analysis methods are recommended when evaluating a particular network design: total throughput and time-per-packet analysis.

A list of terms and acronyms frequently used

Definitions and Terms

Acronyms and Abbreviations

CCA: Clear channel assessment
OTA: Over The Air
ZCL: ZigBee Cluster Library

• PAN ID: 16-bit unique identifier, chosen at network formation time
• Extended PAN ID: 64-bit unique identifier, chosen at network formation time

For a given RF channel and within a given local area, the PAN ID and Extended PAN ID combination is chosen by the coordinator to be unique at the time the network is formed. While this does not completely prevent conflicts, the probability is very low.

More information about the Extended PAN ID is available in the FAQ: What is an extended PAN ID and how is it used?

Common Questions