以下是我的情况:
我有一个由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)制作的xbee3library。
我的问题是:如何加快96个节点的通信时间(请记住,目标是能够处理更大的网络)以及为什么78和96个节点之间存在如此大的差异(为什么网络突然这么慢?)
如果我的情况需要更多信息,我将很乐意提供。当我管理代码时,如果您需要更多信息,我可以执行测试。
答案 0 :(得分:3)
首先,获取802.15.4嗅探器并开始查看流量,看看发生了什么。没有它,你就会猜测可能发生的事情。我多年没有使用802.15.4,但在Ember Desktop之外(仅在Silicon Labs的昂贵开发套件中提供)我很满意Ubiqua Protocol Analyzer。您可能还想探索Wireshark's 802.15.4 sniffing功能所在的位置。
其次,尝试在发送下一条消息之前实现代码以等待传输状态消息。更好的是,编写代码来跟踪多个未完成的消息并使用各种设置对其进行测试 - 网络如何处理1个消息等待传输状态,而不是5个未完成的消息?
我的猜测是,您遇到了挑战,XBee模块管理着许多节点的路由表。 Digi为working with large XBee networks提供了一个文档,解释了如何在大型网络上使用源路由。您的中心节点可能需要维护路由表并在出站消息中指定路由以提高网络吞吐量。
答案 1 :(得分:0)
在涉及96个节点的情况下,您的网络上存在大量冲突和大量开销。 我的建议是将您的节点与多个路由器集群化,作为您的网络增长。
答案 2 :(得分:0)
问题很可能是你正在使用基于标准zigbee的路由,这是AODV,它基本上是根据每次传输计算的。一旦节点数量达到大量,计算就会以指数方式变长。您应该考虑更改为源路由,这基本上是一种不同的帧类型,也使用节点上存储的路由。在大型稳定网络上,这应该更快地传输消息。
https://www.digi.com/wiki/developer/index.php/Large_ZigBee_Networks_and_Source_Routing