XBee is not ZigBee. Did you know the word “ZigBee” refers to a troll from a Norwegian legend?!
Many use Xbee & ZigBee interchangeably, but it's wrong.
ZigBee is a wireless communications protocol for low-power, wireless mesh networking, a registered trademark of the Zigbee Alliance.
XBee is a family of radio modules of Digi International. It supports a variety of communication protocols, including ZigBee, 802.15.4, WiFi, and even LTE!
The Norwegian legend of ZigBee:
A Norwegian legend speaks of a little troll by the name of ZigBee, who lived in the village of Vik far inland on the fjord of Sogn. Now, Norwegian trolls aren’t the big, nasty and smelly, hard-as-rock variety often told of in other tales, at least not always.
ZigBee was a kindly, quiet little troll, who didn’t speak much, but when he did speak it was always reliable. A person could count on ZigBee.
To read what Bob Heile, Chairman of the ZigBee Alliance has to say about this story, check out here: https://lnkd.in/d9pqKpUX
This is just a fun introduction to my ZigBee Insights Series. More technical posts coming from Monday onwards.
A ZigBee Network is similar to a Sports Team. Each Player specializes in specific types of roles. In ZigBee it can be either a Coordinator, Router, or an End Device.
Before we get into the 3 main types of devices, let's learn some basics.
Each unit in a ZigBee network can be called nodes. A node generally consists of a microcontroller, a transceiver, and an antenna. A single node can be used for various applications, such as lighting control, smoke-detector, and home security monitoring.
There are two types of Nodes in a ZigBee Network. A node can operate as a Full Function Device Or as a Reduced Function device.
An FFD can perform all the tasks that are defined in the ZigBee Standard, While an RFD being optimized for consuming less power, operates within a limited set of the IEEE 802.15.4 MAC layer.
Thus based on these two categories, a node in a ZigBee network can play 3 roles. They are
1. Coordinator - FFD
2. Router - FFD
3. End Device - RFD
Coordinator:
A Coordinator is responsible for forming any ZigBee network, handing out addresses to nodes, managing the network, securing it, and keeping it healthy. A ZigBee network must have only a single coordinator device and no more than 1. A coordinator cannot sleep, thus it will always be powered on. It will be able to buffer wireless data packets for sleeping end device children.
Router:
A router can join existing networks, send information, receive information, and route information. A router is like a messenger that helps communicate between end devices that are too far apart, using a technique called multi hopping. A ZigBee network can have multiple routers, but just like the coordinator, they should always be powered.
End Device:
An End Device, as its name suggests, signifies the termination or the endpoint of a ZigBee Network. These devices need to be work with very constrained resources to reduce power consumption. End Devices are essentially stripped-down versions of routers. They can join networks and send and receive information. They can also power themselves down to save energy. It needs a coordinator or a router as a parent device, to help join the network and store messages for them when they are asleep.
A ZigBee network can be composed of one coordinator, multiple end devices, and no routers at all.
ZigBee or Bluetooth or Wi-Fi? - Which should I use in my application?
Comparing the ZigBee standard with Bluetooth and Wi-Fi helps us understand how ZigBee differentiates itself from existing established standards as shown in the figure below.
ZigBee has the lowest data rate (Max 250 K bits per second) and complexity among these three standards and thus provides significantly longer battery life & range.
From the waveform graph below, it's clear that there are very high chances of interference between these three wireless standards.
So how does ZigBee Overcome Interference and Coexist in a world bathed in Wi-Fi and Bluetooth Signals?
Coexistence with Wi-Fi:
A Wi-Fi transmitter output power is typically between 12 to 18 dBm , but nodes may have output power as high as 30 dBm. The ZigBee nodes have lower output power, duty cycle, and signal frequency bandwidth compared to Wi-Fi systems; therefore, a ZigBee system is expected to have very little effect on the operation of a Wi-Fi system. A ZigBee signal is considered a narrowband interferer to Wi-Fi.
Coexistence with Bluetooth:
Bluetooth operates in the 2.4 GHz band and uses the frequency hopping spread spectrum method to spread their signal. If the nearby Bluetooth device is using all 79 channels for frequency hopping, the maximum chance of interference between a single ZigBee node and a Bluetooth node is 3 out of 79 hops, which is approximately 4%. Thus Bluetooth devices might not even notice the presence of the ZigBee network due to the low duty cycle and low power of typical ZigBee nodes.
One of the most useful & important features of ZigBee is its Self-Forming Self-Healing Network. Why is ZigBee called as “Self-Forming” & “Self Healing” Networks?
Why Self Forming?
A ZigBee network starts its formation automatically as soon as devices become active. In a ZigBee mesh network, the first device that starts communicating can establish itself as the ZigBee coordinator, and other devices then join the network by sending association requests. As no additional supervision is required to establish a network, ZigBee networks are considered self-forming networks.
Why Self Healing?
Once a ZigBee Mesh network is established, there is more than one way to relay a message from one device to another. It can multi-hop multiple devices before reaching the intended destination. ZigBee protocol is intelligent to automatically route the messages through the optimum path. Even if one of the routers on route to destination, stops functioning due to exhaustion of its battery or if an obstacle blocks the message route, the network can select an alternative route. Thus ZigBee Networks are self-healing.
Self Forming and Self Healing are done automatically without any explicit developer input. Which is why ZigBee is very reliable.
Around 4 BILLION ZigBee devices can exist inside a ZigBee Solution!
How is this possible?! Let's discuss device addressing in ZigBee to understand this.
Each ZigBee Radio that is physically manufactured will have a 64 bit MAC ID. This is a unique number, meaning only 1 device with that ID exists.
While it's important to know this 64 bit number, it is not practical to use such a large address space (~18 quintillion range), as ZigBee radios need to have more on-chip memory to handle this.
To make device addressing more manageable, there is a Dynamically assigned 16 bit address, that is assigned to each radio by the coordinator when it forms a ZigBee network. This allows for addressing 65,536 ZigBee devices.
This Address is unique only within a given network. The shorter size of this dynamically assigned Address enables the ZigBee chips to work with low memory size on-chip.
ZigBee Protocol provides yet another addressing method. Each Digi XBee(TM) radio can be assigned a node identifier. It is a short string of text which allows the radio to be addressed with a more human-friendly name. This allows for easy management of devices if there are hundreds of them.
So in Short we discussed 3 addressing methods -
1.MAC ID,
2.Dynamic Address, and
3.Node Identifier.
But still where did the 4 BILLION number come from?!
What if we are managing multiple ZigBee networks, each with its own coordinator. In such cases, there are chances of the same 16-bit Address being used in different networks. It's just like two or more cities having the same street name.
For this, we use something called a Personal Area Network ID or PAN ID. If multiple ZigBee networks are operating within range of each other, each should have unique PAN IDs. PAN ID is also a 16 Bit Address.
Thus considering both PAN ID & Dynamic Address inside a Network, we can handle 4 Billion ZigBee devices. (2 raised to 32 = four billion two hundred ninety-four million nine hundred sixty-seven thousand two hundred ninety-six)
Do share this post if you like it. Comment your insights or questions too!
ZigBee has 2 Operating Modes - Transparent Mode & API Mode. There is also AT Command Mode. Beginners often get confused on choosing the right mode for communication. Let me solve this confusion for you.
We will explain with the help of 2 Digi XBee(TM) Modules that are communicating with each other. XBee modules are just ZigBee Transceivers. Meaning it uses UART to send & receive data to and from a microcontroller. The operating mode determines how this data is packaged and sent serially.
Transparent Mode: This is the default mode. In this mode, the 2 XBees are connected serially meaning all data received through the serial input is immediately transmitted over the air. When the XBee module receives wireless data, it is sent out through the serial interface to the microcontroller exactly as it is received.
Pros of Transparent Mode:
1.Operation is very simple & easy to get started
2.What you send is what the other module receives (no additional info)
3.Compatible with any device that has a serial interface
Cons of Transparent Mode:
1.Advanced Features like network diagnostic, remote firmware updates are not supported
2.Can’t Identify the source of received data or reasons for failure
3. Can’t set or read configuration of remote XBee modules without switching back and forth the AT Command Mode
Often people use AT Command Mode and Transparent Mode Interchangeably. This is plain wrong.
AT Command Mode is a standalone CONFIGURATION mode in which the incoming letters are interpreted as commands and these are used to configure XBee modules.
API Mode: API mode provides a structured interface where data is communicated through the serial interface in organized packets and in a determined order. This enables you to establish complex communication between devices without having to define your own protocol unlike Transparent mode.
API Mode Provides different packet frames like MQTT for different communication and configuration operations.
Pros of API Mode:
1.Presence of Configuration Packet Frame enables configuration change of local and remote XBees without using AT Mode.
2.Source Address of each packet can be found
3.Can receive success or failure status of each packets
4.Can decode signal strength of any received packets
5.Perform Advanced Network Management, Diagnose, Remote Firmware updates and more
Cons of API Mode:
1.Interoperability is harder to achieve
2.System Complexity increases
3.Packets may end up being bigger than needed for a simple transmission of data
Digi XBee ® Modules from Digi International can work without a microcontroller for simple digital & analog operations! It can do simple sensor reading as well as simple actuations too, all without any microcontroller.
You might have wondered, why such a simple transceiver has 20 pins! It is because, other than the configuration pins, power pins and Rx-Tx pins, there are analog, digital and dedicated PWM pins on the XBee Modules.
XBee modules use a feature called Pin Pairing or I/O Line Passing to achieve this microcontroller-less operation.
Pin pairing virtually links the pins of one XBee directly to the pins of another XBee. So whatever signal is given to the Pin Paired IO of one XBee is mirrored or comes as output to the other XBee’s Pin Paired IO, as illustrated in the doorbell example in the below image.
The main advantage of pin pairing is that as output is directly linked to input you can change the value of the output without using a computer or microcontroller.
Want to try out? Check out Digi’s great blogs on this:
Output Node Setup: https://lnkd.in/d3FmbvRj
Input Node Setup: https://lnkd.in/dbB7TZj3
Please do share my post if you find my series interesting. Feel free to input any of your insights or questions in the comments.
Let's Discuss Security in ZigBee. ZigBee introduces an application called a ZigBee Trust Center that either runs on the Coordinator or as a separate device assigned by the Coordinator.
So What is a ZigBee Trust Center?
ZigBee Trust Center is an application that runs on the device trusted by other devices within the ZigBee network to distribute keys for the purpose of network and end-to-end application configuration management. Just like a Coordinator, a Network can only have 1 Trust Center.
So what are these Keys that are handled by ZigBee Trust Center?
There are 3 types of symmetric keys, each of length 128-bit used in the ZigBee standard.
Master Keys: They are pre-installed in each node. Their function is to keep confidential the Link Keys exchange between two nodes in the Key Establishment Procedure (SKKE).
Link Keys: They are unique between each pair of nodes. These keys are managed by the Application level. They are used to encrypt all the information between each two devices, and for this reason more memory resources are needed in each device.
Network key: It is a unique 128 bit key shared among all the devices in the network. It is generated by the Trust Center and regenerated at different intervals. Each node has to get the Network Key in order to join the network. Once the trust center decides to change the Network Key, the new one is spread through the network using the old Network Key.
Digi XBee® Zigbee Modules has 2 Operating Modes, of which API mode offers the most features. Let's look at API Frame Structure.
API Mode allows us to transmit highly structured data quickly, predictably, and reliably The API Frame has the following structure shown in the image below. Lets decode the structure:
Start Delimiter
Every API frame begins with a start byte. 0x7E is a unique number that indicates we are at the beginning of the data frame. If we read bytes that are arriving from the XBee’s serial port in midstream, we won’t know what they represent until we know their order. The start byte is like the front cover of a book.
Length Bytes
The next two numbers we receive after the start byte indicate the overall length of the data frame. This lets us know how long to keep reading before we stop. It's like knowing the page count of a book.
Frame Data Bytes
The frame data is specific to each type of message we receive from the XBee radio. It consists of 2 parts:
1. Frame Type: It determines the type of API frame and indicates how the information is organized in the Data field.
2. Data: It contains the data itself. The information included here and its order depends on the type of frame defined in the Frame type field.
We can consider frame data to be like the inside pages of a book.
To learn about supported frames, check this out: https://lnkd.in/dZiQa4dY
Checksum
The very last byte of the frame is always a checksum. It is a simple sum of all the bytes that made up the frame, used at the receiving end to check data integrity. It is calculated by taking the hash sum of all the API frame bytes that came before it, excluding the first three bytes - start delimiter and length. The calculation is regular arithmetic, designed to be extremely efficient for computers to process.
Want to learn Zigbee Concepts & Practical Implementation? My TOP 4 Book Recommendations:
To Learn Basics & Theory:
1. Zigbee Wireless Networks and Transceivers by Shahin Farahani
2. Zigbee Wireless Networking Book by Drew Gislason
For Practical Learning:
3. Building Wireless Sensor Networks: With Zigbee, XBee®, Arduino, and Processing Book by Robert Faludi
4: The Hands-on XBee® Lab Manual Experiments that Teach You XBee ® Wireless Communications By Jonathan A. Titus
#11-FINAL
You bought a couple of XBee® Modules to learn or implement Zigbee. The first step will be to flash the appropriate firmware for your application. Which should you choose?
In this example, we are using an XBee Pro S2C, which is one of the most commonly available XBee Modules. We are using the excellent Configuration & Monitoring tool called XCTU from Digi International.
So which firmware to choose & upload? The choice depends on the application and the size and type of Zigbee network to form.
1. 802.15.4 TH PRO
This is the oldest firmware and usually is the default firmware on a fresh XBee Module. Use this firmware for:
a. Simple Project
b. End to End Communication
c. Standalone XBee Implementation (no microcontroller)
2. ZIGBEE TH PRO
Use this firmware for:
a. Sleep Feature Support
b. Intelligent Routing
c. Medium Sized Network
3. DigiMesh 2.4 TH PRO
Use this firmware for:
a. Large Networks
b. Self Healing & Self Configuring Capabilities
c. Advanced Network Diagnostics
コメント