@VV大神求救,ZigBee设备控制不良,再搞不定,要走人了。

@VV大神求救,ZigBee设备控制不良,再搞不定,要走人了。

此问题尚无答案
All Replies
  • 秀才385分

      ZRL(0x1A89)处恰好处于ZC(0x000)发射RSSI边沿,大概为-90db左右,大量的实验抓包发现,ZC处直接控制ZRL,发现大量重发数据和控制不良。通过增加ZRR(0xA301)让ZC和ZRL之间的通信通过ZRR路由转发,但是实际测试并未如愿。

      抓包数据显示,ZC和ZRL通信还是直接传输。

      但是该链路不稳定,总是进行路由发现,从下面的路由发现流程来看。

    ①   、ZC(0x0000) 进行路由请求,请求ID为0x1E;目的地址为0x1A89;

    ②   、ZRR(0x0301)转发路由请求

    ③   、ZRL(0x1A89) 通过(ZRR)0x0301进行路由回复建立正向路由;

    ④   、ZRR继续转发路由回复到ZC(0x0000)路由发现流程结束;

    ⑤   、ZC发送数据还是直接传输数据到ZRR(0x1A89);

      通过更改ZRL和ZC邻居表条目数量为1,让其必须走ZRR路由转发,实际控制良好。

     这里提出问题:

    ①   、怎么让ZC控制ZRL必须走ZRR路由转发而不是直接传输?(因为直接传输控制不良)

    ②   、第三幅图所示的路由发现流程为什么出现正向路由建立成功仍然不走路由?

     

     

  • 状元56621分

    你好,有没有测试后,ZC和ZRR,ZRR和ZRL之间的通信都没问题的对吧。

    你用的协议栈版本是多少,

    请把抓包的文件另存为,用附件上传。

    如果要上传ZigBee Sniffer Log,请把文件另外为psd或者cubx文件,用附件方式上传,不要使用截图没有任何作用。

    谢谢!

  • 秀才385分
    5、发现大量的窗帘(0x1A89)到网关(0x0000)路由回复但是仍然不转发.psd

    呀,果然VV大神出没了

    ZC和ZRR通信是肯定有问题的,因为ZRR是特意增加在ZC和ZRL之间的解决ZC和ZRL控制不好,通常地,ZRR我们会增加PA保证通信良好。

  • 秀才385分

    我们还用2.5.1a协议栈

  • 状元56621分

    为什么说没有发送

    如果要上传ZigBee Sniffer Log,请把文件另外为psd或者cubx文件,用附件方式上传,不要使用截图没有任何作用。

    谢谢!

  • 秀才385分

    呀,感觉论坛交流好慢哦。问题搞明白了,我也被炒鱿鱼的。

    关于你上面的描述,几个疑惑。

    1、你用什么工具打开PSD的?wireshark?感觉比PacketSniffer 更加灵活。

    2、按照你的分析我进行了过滤(SAD=0x0000;FCF=(Type=DATA, Sec=0);NDA=0x1A89;DAD=0x0301;),确实存在给0x1A89的包存在由0x0301转发的,但是也有直接传输的(SAD=0x0000;FCF=(Type=DATA, Sec=0);NDA=0x1A89;DAD=0x1A89;) 同时也有部分数据我上面的疑问,就是路由回复了,但是仍然直接传输(抓包对应帧号为:p.nbr Rx 342-345) 这也符合我的提问:怎么让其只有路由转发?不走直接传输?

    3、我理解是不是回复的路径损耗值大于直接传输的损耗导致其未走路由?

    4、什么时候出现邻居表中存在设备还要继续进行路由发现?

  • 秀才385分

    VV大神,已经打包行李了。帖子也快沉了~Help Me~

  • 状元56621分

    1, Ubiqua

    2, 直接传输是因为邻居表对这个设备的链路状态不是断的

    3,不会,先判断邻居表,再判断路由表,再进行路由发现。一旦进行路由发现了,这次发送就不会再用邻居表了。下次发送还是有可能又使用邻居表了,比方说Link status把邻居表更新了,原先邻居表链路是断的,现在通了。

    4,链路断的情况下。

    如果要上传ZigBee Sniffer Log,请把文件另外为psd或者cubx文件,用附件方式上传,不要使用截图没有任何作用。

    谢谢!

  • 秀才385分

    1.ubiqua 有破解的?不过你们也不需要买破解版的

    2.按照你的意思?我没有办法实现在邻居表链路看似正常的前提下走路由?问题关键就在这里,我现在发现通过邻居表直接传输很不稳定。从抓包也看得出,重发概率很高,失败概率也很高。

  • 状元56621分

    2,链路不好,重发是正常的。

    一旦多次重发以后,链路断了,之后发数据就会启动路由请求的。

    如果要上传ZigBee Sniffer Log,请把文件另外为psd或者cubx文件,用附件方式上传,不要使用截图没有任何作用。

    谢谢!

  • 秀才250分

    相信用TI协议栈的都出现过这个问题,但是TI至今没解决这个问题,起码我1.2.2a协议栈这个问题依然存在,VV大神的解释没错,但是没有给出解决的方法,协议栈这部分又没有开源,这种机制显然不满足实际应用,两个设备处于临界状态,这时的通讯质量但是非常差的,这时link status一会OK一会不OK,导致邻居表也是一会OK,一会不OK,如果固定先邻居表,再路由表这种顺序,这时假如邻居表状态又OK,采用邻居表发送很大概率失败,实际应用发现经常丢包,望解决!

  • 状元56621分

    不是说在邻居表里面,就一定会发送数据出去,在邻居表里面,并且链路是ok的情况下,才会发生发送出去。

    链路值用0-7表示,0表示断,1-7表示通,1最好,7最差。

    我们协议栈里面只有链路值小于goodlink的发送数据,CONST uint8 gGOOD_LINK_COST = GOOD_LINK_COST; 才会发送数据。

    如果一直处于临界状态是不发送的

    如果要上传ZigBee Sniffer Log,请把文件另外为psd或者cubx文件,用附件方式上传,不要使用截图没有任何作用。

    谢谢!

  • 秀才250分

    感谢VV解答,我看了协议栈GOOD_LINK_COST默认是3,只有链路值小于goodlink的发送数据,也就是这个链路值小于3(1或者2)才会走邻居表发送?那么这个链路值是怎么计算的,实际测试不经路由直接发送确实丢包概率很大,链路值应该挺差的

  • 秀才250分

    http://www.deyisupport.com/question_answer/wireless_connectivity/zigbee/f/104/t/115663.aspx

    http://www.deyisupport.com/question_answer/wireless_connectivity/zigbee/f/104/t/115630.aspx

    这时我之前发的帖子,麻烦VV大神有空也帮我看看,里面有抓包

  • 状元56621分

    链路值是通过RSSI转换过来了,通过一个分段函数转化成0-7的。你可以看下邻居表中节点的链路值,或者节点发送出来的Link Status里面维护的对方的链路值。

    如果要上传ZigBee Sniffer Log,请把文件另外为psd或者cubx文件,用附件方式上传,不要使用截图没有任何作用。

    谢谢!