微波EDA网,见证研发工程师的成长!
首页 > 研发问答 > 无线和射频 > TI Zigbee设计交流 > 使用TI的zstack如何查询网络节点的运行状态

使用TI的zstack如何查询网络节点的运行状态

时间:10-02 整理:3721RD 点击:

我们现在使用的CC2530F256开发,如何能通过协调器快速知道同一个网络内的在线节点状态,如何利用协议栈快速获取整个网络的拓扑结构,有短地址就可以,节点全部是路由器,最好能使用协议栈内建的策略或方法,谢谢。

你好,

1,最新的协议栈里面,有对End Device加入关于Child Aging的功能,原理就是End Device会定期的发Data Request出来,当父节点连续多长时间没有收到以后,就认为节点掉线了。Router没有加这样的功能,因为Router一直处于唤醒状态,所以你只要在Application加上类似的机制就可以了。

2,在协议栈的安装目录下有一个Document的文件夹,里面有一个Method for Discovering Network Topology.pdf专门介绍如何获取网络的拓扑结构的

我们原来使用的策略是从协调器依次给网络里的每个路由器节点发送心跳包,路由器节点接收到后回应一个确认包,这样路由器和协调器都可以知道自己的网络状态,协调器的发包间隔是50mS,路由器节点在20s内如果没有收到协调器的心跳包,就会报警认为自己离开了zigbee网络,我们做的网络最大是100个节点,我们再测试的时候发现路由器节点有有不规律的提示掉线的状态输出,请问我们的这种做法合适吗?

另外如果按照您上面提示的那种方法就是路由器主动向其父节点发送心跳,会不会出现多个路由节点向同一个父节点发包而堵塞丢包的现象?谢谢您的支持。

你好!

你们的做法没什么问题,你们的网络有开启Many -to-one和Sourc Routing功能,如果没有开启的话会有问题

1)你协调器给路由节点去发送心跳包,如果到这个路由节点的路径在Coordinator端有保存,那么没什么问题直接发下去,如果在Coordinator没有保存的话,那么Coordinator首先要做的是发送Route Request去发现这个节点,然后收到Route Reply以后再把心跳包发下去,而且你的时间间隔50ms,太短了,很有可能会造成前一个点Router Reply没有回来,就要发送下一个节点的数据了。

2)你们的目的是为知道节点是否在线,没必要再让Coordinator去找到,再回复上来。路由节点上开一个定时器这个的定时器的时间可以是T+Random的周期,这个心跳包的作用只是为了知道是否在线,所以每个节点发数据的周期不一样也无所谓,而且这样可以避免碰撞。

3)如果是Many -to-one和Sourc Routing的网络的话,所有节点的路由信息保存在Coordinator上,而且会定期更新,所以你需要去poll节点的话也不用每次要Route Request来找了,而且每个节点都有自己到Coordinator的路径,这样节点在发心跳包的时候也不用Route Request了。

你们需要搭建100个节点的网络

用的是哪个协议栈版本?

具体应用是什么?

您好:

        请问该如何开启Many-to-one和Source Routing功能啊?对网络容量有影响吗?

        我们现在这样做是为了防止碰撞,而且路由节点和协调器节点之间能够相互知道是否和对方连接正常,我们把间隔改成了100mS,心跳好像没有问题了,路由和协调器增加其他的通讯数据时还出现了丢包的现象,无线数据发送的间隔有时间限制吗?这个怎么控制好呢?

       我们现在用的协议栈版本是ZStack-CC2530-2.3.0-1.4.0,我们想应用到智能物联网上,协调器做网关,路由节点和设备连接,从主站实现对各个设备节点的数据采集和控制。

Many-to-one的目的是为了让节点能够存储到Coordinator的Routing path,这个path会定期更新,

Souce Routing的目的是为了让Coordinator存储到每个节点的Routing path,这个path是整条路径都存储的,所以需要更多的RAM 开销。

协调器需要发送的路由节点,路由信息没有在路由表里的话,需要发送route request出去,这样是有可能和你100ms的数据产生碰撞的。

实际应用中应该不需要这么短的周期发送心跳吧?

建议你们使用最新的协议栈,性能会更加稳定。

我们现在使用的协议栈是zstack-cc2530-2.3.0-1.4.0,在GeneralApp的基础上开发的,添加完我们的应用程序后,资源占用情况见附件中的map文件,协议栈中使用的路由深度等参数都是使用的原默认值,如果我们换成最新的协议栈,改用您说的many-to-one模式能正常运行吗?资源够用吗?我们现在使用的芯片是CC2530F256,我们现在RAM资源基本已经用完了。

我看到论坛里一篇文章《building a Zigbee Network Based on Many-to-one Routing of 400+ Nodes》,里面设置的MAX_RTG_SRC_ENTRIES为430,协议栈里默认值是12,修改这个参数会大量占用RAM,我们现在的资源根本不够用,请问这篇文章使用的是CC2530实现的吗?我在TI的zstack-cc2530-2.3.0-1.4.0的GeneralApp例程里按这种方法试了一下还是提示资源不够,最新的协议栈能解决这个问题吗?谢谢您的支持。

 

 

 

我们现在使用的是CC2530F256,按照我们现在的资源使用情况,能使用最新的协议栈吗?

知道你下载的最新版的协议栈里面有对应CC2530的工程,说明都可以支持CC2530的

您好,请问,您说的这个“End Device会定期的发Data Request出来”是不是就是人们经常说的终端向父设备报心跳呢?

还是每次唤醒了,自己添加向父设备发送心跳的函数呢?还是协议栈中还有自动报心跳的函数呢?谢谢您

最新协议栈版本里面的Child aging就是根据Data request来做的。

自己想添加的话,可以在应用层自己添加

初学者,请问什么地方能找到CC2530F256的firmware?

 CC2530与CC2540封装相同,firmware能共用吗?

我认为二者是不同的,一个是支持zigbee,一个是支持bluetooth,firmware就是自己编译好的程序吧

你好,我使用的协议栈版本是ZStack-CC2530-2.3.1-1.4.0,里面router是定期发送link status,associatedevlist的age是有自动增加的功能的。反而没有你说的终端data request的功能,我想知道这个终端的datarequest是怎么发送的,到其父节点是做什么处理的,谢谢

怎么开启Many-to-one和Souce Routing?

在代码中有这样的定义:

#if !defined ( ZIGBEE_MANY_TO_ONE )
#define ZIGBEE_MANY_TO_ONE
#endif
#if !defined ( ZIGBEE_SOURCE_ROUTING )
#define ZIGBEE_SOURCE_ROUTING
#endif

应该就是全能这两个功能 的

麻烦问一下end device定期发出data reques出来,是端点加入网络后会自动发送,还是需要自己用API来实现,如果是自动发送,那协调器怎么知道有end device掉线了。route应该是自己发数据给协调器,然后在应用层判断route是否断开,对嘛

Copyright © 2017-2020 微波EDA网 版权所有

网站地图

Top