我的情况如下:
我有96个XBee S2B和S2C模块的网络。我的应用程序在ARM模块上运行，并具有XBee S2C模块。所有模块(共97个)都在同一个网络中，并且可以相互通信。
软件启动并知道所有模块的64位地址。它将执行网络发现(Local AT -> ND)并等待响应。随着每个响应，每个模块的16位地址被更新。如果一个模块没有响应网络发现，它将每30秒重新发送一次(在大多数测试中，60秒后，所有节点都被发现。
然后，存储了所有64位和16位地址，应用程序将使用单播向每个节点发送消息。它不会在发送消息之间等待。我尝试了36、42、78和现在的96个节点。对于36个节点，每个节点在3秒内接收到消息(如预期的那样)，对于42个和78个节点，到达每个节点分别需要4秒和7秒。而96则至少需要90秒。
没有我可以检测到的外部干扰，并且所有节点都在可及范围内(如果没有，网络发现将失败)。
我还尝试使用64位消息传递并忽略16位地址，使用这种方法需要更长的时间。
我正在使用由attie (https://github.com/attie/libxbee3)制作的xbee3库。
我的问题是:我如何加快96个节点的通信时间(记住目标是能够处理更大的网络)以及为什么78和96个节点之间存在如此大的差异(为什么网络突然变得如此慢?)
如果需要更多关于我的情况的信息，我很乐意提供。当我管理代码时，如果您需要更多信息，我可以执行测试。
首先，使用802.15.4嗅探器并开始查看流量，看看发生了什么。如果没有这些，你就只能猜测可能会发生什么。我已经很多年没有使用802.15.4了，但是除了Ember Desktop(只能从Silicon Labs获得昂贵的开发套件)，我对Ubiqua Protocol Analyzer很满意。您可能还想了解一下Wireshark的802.15.4嗅探能力。
第二，尝试实现在发送下一条消息之前等待发送状态消息的代码。更好的方法是，编写代码来跟踪多个未完成的消息，并使用各种设置对其进行测试——在传输状态上等待1条消息和等待5条未完成消息时，网络的行为如何?
我的猜测是，您在使用XBee模块管理这么多节点的路由表时遇到了挑战。Digi提供了一份用于处理大型XBee网络的文档，其中解释了如何在大型网络上使用源路由。您的中心节点可能需要维护路由表，并在出站消息中指定路由，以提高网络吞吐量。
问题是，在涉及96个节点的情况下，网络上有很多冲突和大开销。
我的建议是随着网络的发展，用多个路由器来集群你的节点。
问题可能是您正在使用基于标准zigbee的路由，即AODV，它基本上是在每次传输中计算的。一旦节点数量达到很大，计算时间就会呈指数级增长。你应该考虑改成Source Routing，这基本上是一种不同的帧类型，它也利用了节点上存储的路由。在一个大型的稳定网络上，这对于消息的传输应该要快得多。
https://www.digi.com/wiki/developer/index.php/Large_ZigBee_Networks_and_Source_Routing