Troubleshooting XBee Wireless Networks

Posted by Austin Glaser on Feb 8, 2017, 4:14:00 PM
Find me on:

Digi, through its XBee line of wireless devices, provides many kinds of self-contained RF modules. Of particular note are their modules implementing the 802.15.4 standard, for 'low-rate wireless personal area networks'. It emphasizes low-cost and low-power, making it an ideal basis for mesh networks, comprised of many individual 'nodes' – each node needing only to communicate with a few nearby peers. This is in contrast to standards like Wi-Fi, which are higher power, higher data-rate, and based off a central 'hub' through which all communications must pass. XBee implements the ZigBee mesh-network standard on their 802.15.4 devices.

This post is not a comprehensive troubleshooting guide, and referring to the XBee documentation is invaluable. However, it does cover several topics I have had personal experience with, and will hopefully allow you to diagnose some classes of problems more quickly.

XBee's ZigBee networks operate in the same 2.4 GHz frequency range as standard Wi-Fi communications. The 802.15.4 channels are a great deal narrower than 802.11 channels, but there is significant frequency overlap – you can avoid this by operating your network on ZigBee channel 15, 20, 25 or 26. It's important to note as well that XBee networks do NOT automatically channel hop – they will look for a low-noise channel on network commissioning, but not actively during operation. If you commission your network during a low-noise period, it may select a non-optimal channel. If you know you need to operate in conjunction with a Wi-Fi network, you can use the SC parameter on the coordinator to select only the channels which do not overlap for scanning.

Similarly, XBee networks only determine their topology during network commissioning. Each router or endpoint node has a parent from which they expect to receive data; each coordinator and router node has a set of children which they expect to send data to. If a node drops out of the network, the network does not automatically restructure to account for the missing node and its children will not be able to successfully receive or transmit data. This means that XBee networks are not suited for situations where physical network topology can be dynamic. It also means that if a node drops out of communications, a step in the recovery process should be to either manually or automatically re-commission the network.

Perhaps the most difficult thing on an XBee network is operating at or near the maximum network capacity. It's critical to use the API operation mode, rather than the AT mode. In API mode, the host device generates packets which are sent as a whole to an XBee module. The packets encode destination information, as well as a “frame id,” which associates a particular packet with a transmit status packet from the node.

This allows us to deal with the most common type of failure on an XBee network under high load: dropped packets. A host device can queue the packets it sends out, and only consider them delivered when it receives a “success” transmit status packet with the same frame id. If it receives an “error delivering” transmit status packet, it can try to send the packet again (assuming you're operating under conditions where it's critical that every packet come through, such as transferring a file wirelessly).

The XBee documentation states: “It is possible in rare circumstances for the destination to receive a data packet, but for the source to not receive the network acknowledgment. In this case, the source will retransmit the data, which could cause the destination to receive the same data packet multiple times.” In my experience, these “rare circumstances” occur, again, when the network is operated under heavy load. In a sense, this is another manifestation of the “missed packet” problem. Unfortunately, the frame id of a packet is not exposed to the API on the receive side; if it were, it would be much easier to deal with this problem. In my experience, the best solution to this is to insert an incrementing counter into the data payload of your XBee packets. The receiving device can check this counter to determine either if it has missed a packet, or received a duplicate, and deal with the situation appropriately to the application.


Topics: Embedded, RF, XBee, Mesh Networks