XBee connectivity in large networks

Question

Here is my situation:

I have a network of 96 XBee S2B and S2C modules. My application runs on an ARM module and has an XBee S2C module. All modules (97 in total) are on the same network and can communicate with each other.

The software starts up and knows the 64-bit addresses of all modules. It will perform network discovery (Local AT → ND) and will wait for responses. Each response updates the 16-bit address of each module. If the module did not respond to network discovery, it will be sent again every 30 seconds (in most tests, after 60 seconds, all nodes are detected.

Then, while saving all 64-bit and 16-bit addresses, the application will send a message to each node using unicast. He will not wait between sending messages. I tried this with 36, 42, 78 and now 96 nodes. With 36 nodes, messages are received within 3 seconds by each node (as expected), with 42 and 78 for each node, respectively, requiring 4 and 7 seconds. With 96, however, it takes 90 seconds (at least).

There is no external interference that I can detect, and all nodes are within reach (if not, network discovery would fail).

I also tried using 64-bit messaging and ignored the 16-bit address, this takes even longer when using this method.

I am using xbee3library made by attie ( https://github.com/attie/libxbee3 ).

My question is: how to speed up the communication time of 96 nodes (keep in mind that the goal is to be able to process even larger networks) and why there is such a big difference between 78 and 96 nodes (why is the network suddenly so slow?)

If you need more information about my situation, I will be happy to provide it. When I manage the code, I can run tests if you need more information.

Answer 1

First of all, get an 802.15.4 sniffer and start watching traffic to see what happens. Without this, you are stuck in guessing what might happen. I have not worked with 802.15.4 years, but outside of Ember Desktop (only from Silicon Labs in expensive development kits) I was pleased with the Ubiqua Protocol Analyzer . You can also explore where Wireshark 802.15.4 sniffing capabilities are .

Secondly, try executing the code to wait for the transmission status message before sending the next message. It’s even better to write code to track several outstanding messages and check it with different settings - how does the network work with 1 message waiting for transmission status, or 5 outstanding messages?

I assume that you are having problems with the XBee modules that manage the routing table for many nodes. Digi provides a document for working with large XBee networks that explains how to use Source Routing on a large network. The central node may need to maintain a routing table and specify routes in outgoing messages in order to increase network bandwidth.

Answer 2

Your network has a lot of collisions and big overhead in a scenario involving 96 nodes.
My suggestion is to group your nodes with multiple routers as network growth.

Answer 3

Probably the problem is using routing based on stadard zigbee, which is AODV, which is mainly calculated on each transmission. Once the number of nodes reaches a large number, the calculation takes exponentially longer. You should consider switching to Source Routing, which is basically a different type of frame that also uses stored routes in nodes. On a large, stable network, this should be much faster for messaging.

https://www.digi.com/wiki/developer/index.php/Large_ZigBee_Networks_and_Source_Routing