Channels, Zigbee
Channel detail
802.15.4 and Zigbee break the 2.4Ghz band into 16 channels as shown below.
| Decimal | Hex | Frequency | SC mask | WiFi Conflict | Comments |
|---|---|---|---|---|---|
| 11 | 0x0B | 2.405GHz | 0x0001 | Overlaps Ch 1 | Newer XBee only |
| 12 | 0x0C | 2.410GHz | 0x0002 | Overlaps Ch 1 | |
| 13 | 0x0D | 2.415GHz | 0x0004 | Overlaps Ch 1 | |
| 14 | 0x0E | 2.420GHz | 0x0008 | Overlaps Ch 1 | |
| 15 | 0x0F | 2.425GHz | 0x0010 | Overlaps Ch 6 | |
| 16 | 0x10 | 2.430GHz | 0x0020 | Overlaps Ch 6 | |
| 17 | 0x11 | 2.435GHz | 0x0040 | Overlaps Ch 6 | |
| 18 | 0x12 | 2.440GHz | 0x0080 | Overlaps Ch 6 | |
| 19 | 0x13 | 2.445GHz | 0x0100 | Overlaps Ch 6 | |
| 20 | 0x14 | 2.450GHz | 0x0200 | Overlaps Ch 11 | |
| 21 | 0x15 | 2.455GHz | 0x0400 | Overlaps Ch 11 | |
| 22 | 0x16 | 2.460GHz | 0x0800 | Overlaps Ch 11 | |
| 23 | 0x17 | 2.465GHz | 0x1000 | Overlaps Ch 11 | |
| 24 | 0x18 | 2.470GHz | 0x2000 | Overlaps Ch 11 | Newer XBee only |
| 25 | 0x19 | 2.475GHz | 0x4000 | No Conflict | Newer XBee only |
| 26 | 0x1A | 2.480GHz | 0x8000 | No Conflict | Newer non-PRO XBee only |
Things to note:
- WiFi bands vary by country and region. The three WiFi bands above are common worldwide, but for example, Japan allows enough extra channels to permit a fourth WiFi band starting at channel 14. Therefore the "No Conflict" statements above would not be true in Japan.
- Sometimes Xbee documentation uses hex as "17" instead of "0x17" to mean a channel like 23. Be careful about the context!
- Digi Xbee starts on the first channel in the SC mask and stops on the first channel which grants it association. Depending on the age of the firmware on your Xbee ZB module it might start on channels 0x0B, 0x0C, or 0xD (11, 12, or 13)
- Once a coordinator selects a channel, it does not move regardless of error rate (i.e. not frequency agile), so ZigBee does not automatically hop to a clear channel - it does this to avoid confusing potentially sleeping devices. A user or external software must manually force the coordinator to move via setting changes, plus the routers will not follow unless various non-default settings have been enabled.
- More than one 802.15.4/Zigbee coordinator can settle on a single channel.
- For example you could have 5 distinct WPAN, and all 5 Digi gateways decide they want to use the default channel 13/0x0D despite the fact that no WPAN uses any of the other 15 channels.
- So in a crowded 802.15.4/Zigbee environment, it is helpful to change your SC to force your WPAN to less-used channels.
- Not all Zigbee radios support all 16. It depends on the age and power rating.
- Older Digi XBee supported only 12 to 23, so default scan_channel/SC is 0x1FFE
- Newer Digi XBee non-PRO (S2/S2B/S2C) support all channels, so scan_channel/SC can be 0xFFFF.
- Newer Digi XBee PRO (S2) support channels 11 to 24, so scan_channel/SC can be 0x3FFF.
- Newer Digi XBee PRO (S2B/S2C) support channels 11 to 25, so scan_channel/SC can be 0x7FFF.
- A new-hardware coordinator picking channels 11, 24, 25, or 26 won't be accessible by older hardware, so consider force the SC to 0x1FFE or narrower. You will have no clear 'feedback' that this is occurring
Channel Mask Examples
The following table shows four common channel masks, plus one single channel example, to demonstrate how binary bitmasks are linked to individual channels. If there is a 1 in the channel column, that channel is available for use, and will be scanned, when that mask is configured.
Remember - it is only the mask in the coordinator which affects the selected channel. Assuming you used fixed PAN Id, then you have the most flexible design by putting the reduced/restricted mask in the coordinator alone, and leaving the other devices to check all channels.
The binary ones and zeros are then converted to hexadecimal to create the mask to configure. Using the last example, forcing channel 25: 0100,0000,0000,0000 in binary is 0x4000 in hexadecimal.
| Channel/Mask | Notes | 26 | 25 | 24 | 23 | 22 | 21 | 20 | 19 | 18 | 17 | 16 | 15 | 14 | 13 | 12 | 11 | |||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0xFFFF | All channels, may get low-power channel 26 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |||
| 0x1FFE | Best for mixed old/new Xbee networks, very safe | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | |||
| 0x3FFF | Newer Digi XBee PRO (S2) | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |||
| 0x7FFF | Digi XBee PRO (S2B/S2C) | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |||
| 0x4000 | Example of single channel (Channel 25 only) | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Tips
Control SC within the coordinator
For maximum compatibility, it is advisable to restrict the number of channels the coordinator can use, and keep routers and end nodes as wide open as possible. The coordinator sets the channel the network will use, so it is best to make sure it will set a channel that all the other devices are configured to use. As some older chips are limited to which channels they can use it is important that the coordinator does not select a channel some chips cannot use.
- Coordinators should be set for 0x1ffe
- Routers and End nodes should be configured for as wide a range as possible. Newer low-power XBee should be set for 0xffff. All XBee should be AT LEAST 0x1ffe.
Helping your manufacturing / test people
If your own products contain Digi XBee, then careful channel control of local semi-permanent XBee networks will help a great deal. For example, you put sleeping XBee modules into a battery powered sensor and require manufacturing to test each unit as part of final quality-assurance. Assuming you also have a few test networks in engineering and tech support, your manufacturing people will find the final QA test frustrating, as the units-under-test may not join the manufacturing coordinator.
The simple solution is to leverage the knowledge that a default Digi XBee starts at the lowest enabled channel and works upwards looking for a mesh to join. This offers a handy solution:
- First, make sure all semi-permanent gateway\coordinators have SC set to one or a few of the higher channels. For example, if engineering and tech support use SC=0x1F00, then their mesh will never use the lower 8 ZigBee channels.
- Second, manufacturing should insure that their QA test gateway\coordinators are only in those lower 8 channels. This can be done by manually limiting SC to 0x00FE, or manually confirming that the functioning coordinators have selected a channel between 11 and 18 (hex 0x0B to 0x12).
If you do the above, then any new sensor powered for the final test will find the QA coordinators, not those used by engineering and tech support.
A more active way to help with ad-hoc testing is for engineering and tech support people (who understand the technology) to manually turn their joining on or off as required. For example, an engineer with 1 gateway and 3 XBee 485 adapters properly joined and running, no longer requires 'new joining'. So if they turn all joining of (set NJ=0 in the gateway AND in the 3 XBee 485 adapters) then systems set up by QA or company sales people preparing demos will never join or be affected by the semi-permanent engineering system. Should one of the XBee 485 loss association, or the engineer wish to join new adapters, they can temporarily enable joining.
Avoiding your Office/Home WiFi
In general, the small infrequent ZigBee packets are not affected by WiFi, and one could say that the destructive 'bullets' ZigBee punches in your WiFi bandwidth are treated as common back ground noise and worked around.
However, since you can control which WiFi channels your ZigBee may interfere with, and since you have over a dozen channels to select, it is smart to setup your ZigBee to *not* interfere with your home or office WiFi. You would enforce this avoidance by setting SC in your gateway\coordinators only.
Most consumer WiFi devices default to use 'channel 6' (so WiFi channels 6 to 10), therefore your home or small business WiFi is probably using channel 6. If your PC/notebook/tablet/smart-phone allows you to do a 'WiFi site survey', scanning all WiFi channels for raw traffic, then you can intelligently put your ZigBee either in the clearest bands, or those used by your neighbors!
| Desired Outcome | SC to use |
|---|---|
| To Avoid WiFi Ch 1 | 0x7FF0 |
| To Avoid WiFi Ch 6 | 0x7E0F |
| To Avoid WiFi Ch 11 | 0x41FF |
| To Avoid all WiFi | 0x4000 |
| To Force Use of WiFi Ch 1 | 0x000F |
| To Force Use of WiFi Ch 6 | 0x01F0 |
| To Force Use of WiFi Ch 11 | 0x3E00 |
| To Force Use of non-WiFi | 0x4000 |
Be Aware of Wireless Audio or Phones
Successful use of ZigBee may require careful avoidance of competing NON-WIFI devices including:
- Wireless mic/headsets in a restaurant drive-through
- Wireless phone systems
- Wireless audio (music) headphones
- Wireless phone head sets.
The serious risk with these competing 2.4GHz devices is that many use as much raw bandwidth as possible to maximize audio quality. So for example, a ZigBee mesh in a fast food restaurant might work great when installed at 6AM, but start to see a 60-70% error rate when the drive-through audio system is operational and busy.
Ideally, review the technical documentation for the competing technology. Although it is not WiFi, it likely defines its frequency usage in WiFi terms, and it likely includes a way to assign it Wifi ranges 1, 6, or 11. Since most consumer grade WiFi devices default to use channel 6, it is safe to assume these non-WiFi devices likely default to either WiFi channel 1 or 11 - meaning exactly where you may wish to place your ZigBee.
If you do not have access to the product documentation, review the 'XBee Range Test' procedures on Digi's tech support website, then run a few range tests when the competing 2.4Ghz technology is being heavily used. If you do not detect any significant error rate, then either your selected XBee frequency is unaffected by the competing technology, or the competing technology is gracefully sharing the radio waves. The need to possibly change your XBee channel should be very obvious after very little testing.
PDF
