这是我的情况:
我有一个由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制作的xbee3library(https://github.com/attie/libxbee3).
我的问题是:如何加快96个节点的通信时间(请记住,目标是能够处理更大的网络)以及为什么78和96个节点之间存在如此大的差异(为什么网络突然这么慢？)
如果有关于我的情况需要更多信息,我将很乐意提供.当我管理代码时,如果您需要更多信息,我可以执行测试.
首先，使用 802.15.4 嗅探器并开始查看流量以了解发生了什么情况。如果没有这个，你就只能猜测可能会发生什么。我已经很多年没有使用 802.15.4 了，但在 Ember Desktop 之外（只能从 Silicon Labs 的昂贵开发套件中获得），我对Ubiqua 协议分析仪很满意。您可能还想了解Wireshark 的 802.15.4 嗅探功能的情况。
其次，尝试实现代码以在发送下一条消息之前等待传输状态消息。更好的是，编写代码来跟踪多个未完成的消息并使用各种设置对其进行测试 - 当 1 条消息等待传输状态时，与 5 条未完成的消息相比，网络的行为如何？
我的猜测是，您在 XBee 模块管理这么多节点的路由表方面遇到了挑战。Digi 提供了一个用于大型 XBee 网络的文档，其中解释了如何在大型网络上使用源路由。您的中央节点可能需要维护路由表并在出站消息中指定路由，以提高网络吞吐量。