XBee communication 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 (in total 97 of them) are in the same network and are able to communicate with each other.

The software starts and knows the 64 bit addresses of all modules. It will do a network discovery (Local AT -> ND) and will wait for the responses. With each response the 16 bit address of each module is updated. If a module has not responded to the network discovery, it will be sent again every 30 seconds (in most tests, after 60 seconds, all nodes are discovered.

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

There is no outside interference that I can detect and all nodes are within reach (if not, the network discovery would have failed).

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

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

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

If there is any more information needed about my situation, I will be happy to provide it. As I manage the code I can perform tests if you need more information.

Westing

I don't think this question fits SO. – Bulbous

Answer 1

First off, get an 802.15.4 sniffer and start looking at the traffic to see what's going on. Without that, you're stuck guessing at what might be happening. I haven't worked with 802.15.4 in years, but outside of Ember Desktop (only available from Silicon Labs in expensive development kits) I was pleased with the Ubiqua Protocol Analyzer. You might also want to explore where Wireshark's 802.15.4 sniffing capabilities stand.

Second, try implementing code to wait for a Transmit Status message before sending your next message. Better yet, write code to keep track of multiple outstanding messages and test it out with various settings -- how does the network behave with 1 message waiting on a Transmit Status, versus 5 outstanding messages?

My guess is that you're running into challenges with the XBee modules managing a routing table for that many nodes. Digi provides a document for working with large XBee networks, which explains how to use Source Routing on a large network. Your central node may need to maintain a routing table and specify routes in outbound messages to improve network throughput.

Transgress

Great reaction, I'm looking into Ubiqua, it is expensive, but really elaborate. The 96 nodes are now in use, so I will try to get more information about my situation soon and I will update the question for other people with similar situations. – Westing

Answer 2

The thing is there is a lot of collision and large overhead on your network in the scenario where 96 nodes are involved.
My suggestion is to cluster your nodes with multiple routers as your network growth.

Dishabille

Answer 3

The issue is likely to be you are using the stadard zigbee based routing which is AODV which is basically calculated with every transmission. Once the number of nodes reaches a large number the calculation takes exponentially longer. You should consider changing to Source Routing which is basically a different frame type that also makes use of stored routes at nodes. On a large stable network this should be much faster for transmission of messages.

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

Bingaman