• 状态
  • 已锁定 已锁定
  • 回复 24 回复
  • 订户 26 订户
  • 视图 13274 视图
  • 用户 0 会员在此处
选项
选项
相关

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

关于AF_DATA_CONFIRM_CMD

zhenxing wang1
Prodigy 90 points

Other Parts Discussed in Thread: Z-STACK

case AF_DATA_CONFIRM_CMD:  
          afDataConfirm = (afDataConfirm_t *)MSGpkt;
          sentEP = afDataConfirm->endpoint;
          sentStatus = afDataConfirm->hdr.status;
          sentTransID = afDataConfirm->transID;
          (void)sentEP;
          (void)sentTransID;

          if ( sentStatus != ZSuccess )
          {
          }
          break;

只要调用AF_DataRequest()函数发送数据且返回afStatus_SUCCESS，就会返回事件AF_DATA_CONFIRM_CMD，这么理解对吗？ 在对此事件的处理中，sentStatus != ZSuccess是目的接收端没有接到数据吗？查了一些资料，对这一块始终有点疑惑，还望大家指点一下。谢谢了。

  • 0
    TI__Genius 10563 points

    Hi Zhenxing,

    只要调用了AF_DataRequest()函数发送数据，就会有AF_DATA_CONFIRM_CMD事件返回，无论传输成功与否。

    sentStatus != ZSuccess的解释与你调用AF_DataRequest()函数的options参数有关：

    如果option中使能了AF_ACK_REQUEST，表明需要应用层的ACK，那么此时若sentStatus == ZSuccess则表明数据已经到达了目的地址。

    若option中并没有使能AF_ACK_REQUEST，表明只需要网络层的ACK，那么此时若sentStatus == ZSuccess则表明数据已经到下一跳节点。

    关于这一点可参考Z-Stack Developer's Guide.pdf文档的第8节End-to-end acknowledgements

  • 0 回复 Martin
    Prodigy 90 points

    您好：

            非常感谢您的回复，原本我也是这么理解的。可是最近一些测试中，我发现即使发送端sentStatus = ZSuccess，接收端也不一定接收到了数据，这一点我觉得意外。另外，还有数据丢失、收到重复数据现象。看开发文档第8节End-to-end acknowledgements时，说的是MAC ACk和APS ACk足以保证数据传输的正确性。我想，要利用协议栈的ACK机制，是不是还要加入某一个预编译选项或者使能某些参数？

  • 0 回复 zhenxing wang1
    TI__Genius 10563 points

    Hi Zhenxing,

    我在2楼的回答可能有点错误：

    1. 没有网络层的ACK的说法，2楼中的网络层ack应该是MAC层的ACK！

    2. 实际上当你调用AF_DataRequest()函数的option中并没有使能AF_ACK_REQUEST时，表明只需要MAC层的ACK，那么此时不会再有AF_DATA_CONFIRM_CMD事件。 只有当option中使能了AF_ACK_REQUEST时，才会有AF_DATA_CONFIRM_CMD事件返回。

    您所描述的 即使发送端sentStatus = ZSuccess，接收端也不一定接收到了数据，有没有可能是你的接收端在数据处理过程中有问题？

    协议栈中，的ACK机制，不需要再加入额外的预编译选项或者使能某些参数了。MAC层ACK是默认开启的，应用层的ACK则是在调用AF_DataRequest()函数的option中使能AF_ACK_REQUEST就可以实现了。

     

     

  • 0 回复 Martin
    Prodigy 90 points

    您好：

            您在2中提到，调用AF_DataRequest()函数的option中没有使能AF_ACK_REQUEST，不会再有AF_DATA_CONFIRM_CMD事件。这一点我有疑问，因为我在测试中，并没有使能AF_ACK_REQUEST，但是却有AF_DATA_CONFIRM_CMD事件发生，我在该事件下对sentStatus != ZSuccess的处理是，一直重发，直到成功。这样处理的缺点是，接收端可能会受到重复的数据。

            另一方面，我也试过使能AF_ACK_REQUEST，启用APS ACK，协议栈默认的重传次数是3，延时3s，这种情况下，可能会出现重传3次以后，数据仍然会丢失的情况。

            还有一点，想咨询一下，当传输距离增大，会不会出现接收功率小于某个阀值（这个阀值有没有参考值？）时，即使接收到数据，也无法正确的解析。

            再次对您的回复表示谢意，谢谢！

  • 0 回复 Martin
    Prodigy 120 points

    如果我想要 禁止 MAC的ack，要在哪里设置呢？

  • 0 回复 Martin
    Prodigy 240 points

    发送的时候，随便指定一个合法地址，就会产生AF_DATA_CONFIRM_CMD；

    mac层的应答指的是数据到达接收方的mac层以后，接收方回一个ack数据包到发送方吗？

    还是说发送自己mac层给自己的ack？

  • 0
    TI__Genius 9970 points

    这是 ZigBee 的吧？去 ZigBee 版面询问效果更好。

  • 0 回复 zhenxing wang1
    Intellectual 691 points

    你好，请问后续还有研究这个问题吗，我也发现了发射端即使收到了AF_DATA_CONFIRM_CMD的success，也存在数据包没有发送到接收端，或者发送的数据有误，请问有什么方法解决这个问题吗？能否指导下，谢谢。

  • 0 回复 zexin zeng
    Guru 109510 points
    有沒有先抓包看看問題
  • 0 回复 zexin zeng
    Genius 5580 points
    您好，请问这个问题解决了么。我也遇到了类似的问题，能否讲解下思路？
  • 0 回复 user4711142
    Guru 109510 points
    已經在你 e2echina.ti.com/.../168524 的帖子協助，請勿重複發帖
  • 0 回复 user4711142
    Intellectual 691 points

    还没呢，不过我这边出现这个现象，是因为终端或者路由连上协调器之后，立马发数据导致，如果延时个几秒钟再发送，基本上就不会出现了，具体原因我也搞不清。

  • 0 回复 zexin zeng
    Genius 5580 points
    你的通信距离是多远？
  • 0 回复 YiKai Chen
    Expert 2011 points
    我测试不论终端是否开启aps ack，终端发送zcl数据都断点调试都不会进入zdapp的AF_DATA_CONFIRM_CMD中。只有终端入网的device announce广播时候回进入一次，这是怎么回事呢？
    看zdapp的AF_DATA_CONFIRM_CMD的代码注释很像说ack的处理。但是如果分析代码就不对了。发送数据之后会进入af.c的afDataConfirm中，这个函数最好是调用osal_msg_send向taskid发送消息。deviceannounce属于zdo数据当然发送到zdo，zcl数据当然发送到app层。与测试是一致的，但是与分析不符合
  • 0 回复 user4381970
    Guru 109510 points
    你有抓包看看狀況嗎？
  • 0 回复 YiKai Chen
    Expert 2011 points
    嗯抓包看了，AF_DATA_CONFIRM_CMD与是否进入跟aps ack没有关系。只有调用af发送函数就会进入afDataConfirm，这个函数最好是调用osal_msg_send向taskid发送消息，taskid就是af发送函数发送的zcl层或者zdo层数据。
    announce是墨绿色 是zdo数据，所以osal_msg_send向taskid是zdo的taskid。（zdo初始化注册了端点0）
    普通的onoff汇报等，都是zcl层数据，所以osal_msg_send向taskid是zcl的taskid。（app层初始化一般注册端点1）

    至于aps ack开启是option|=AF_ACK_REQUEST，抓包能看见紫色的aps ack数据。但是发送数据方面如何处理是否收到aps ack数据找不到相关函数。因为aps ack是点对点的ack可以快速判断终端数据目的是否收到（例如协调器不在线，门锁接路由，门锁数据发送是成功的，如果app自己增加协议确认消息是否被接受比较麻烦还没有重发机制），aps ack自带超时时间和重发次数。
    打开这个功能主要为了像门锁这种终端，在网关协调器不在线的情况下（消息不能被上层接收到，需要终端判断网络恢复后重传历史记录），快速判断目的不可达，从而保存记录，待目的恢复后重传重要的历史记录。
  • 0 回复 user4381970
    Guru 109510 points
    就是在AF_DATA_CONFIRM_CMD去確認收到的seq ID跟發送封包的seq ID是否相同來確認是否收到APS ack.
  • 0 回复 YiKai Chen
    Expert 2011 points
    是的 从前面楼层的介绍和代码注释来看。在AF_DATA_CONFIRM_CMD確認是否收到APS ack。
    但是我上面讲的是我实际端点调试，终端调用zcl发送函数后根本就不进zdapp的AF_DATA_CONFIRM_CMD中，不进怎么判断呢？同时我调查了为啥不进zdapp的AF_DATA_CONFIRM_CMD。是因为调用zcl发送函数会返回到zcl的event loop而不是zdo的event loop中。
    并且我验证了1.2.2和3.0.2都是这样的。程序都不进入怎么判断呢？
  • 0 回复 YiKai Chen
    Expert 2011 points
    你有设备，你可以自己断点测试一下
  • 0 回复 user4381970
    Guru 109510 points
    你有沒有用zcl_registerClusterOptionList去註冊要收APS ACK，應該沒有吧，你參考一下我在 e2e.ti.com/.../312024 這個帖子的回答吧
  • 0 回复 YiKai Chen
    Expert 2011 points
    原来如此，楼上讨论了那么多从来没有说zcl_registerClusterOptionList注册的问题。
    我之前确实使用过zcl_registerClusterOptionList，并且看见ota的init中注册了。但是可能当时没有打开aps ask。是不是既要打开，还要注册把。等我测试看看
  • 0 回复 user4381970
    Guru 109510 points
    下次如果找不到資料，建議到英文版E2E
  • 0 回复 zhenxing wang1
    Prodigy 100 points

    你好，我这边也遇到了跟你一样的问题，没有是能APS ACK，但是一样会有AF_DATA_CONFIRM_CMD事件发生，而且更奇怪的是，并不是每一次成功收到MAC ACK都会有这个事件发生，偶尔会出现有MAC ACK，但是对方实际是没有动作的，感觉MAC ACK好像并不能用来说明数据发送成功，后续还有研究吗，能否解答一下，谢谢。

  • 0 回复 zhenxing wang1
    Prodigy 100 points
    你好，我这边也遇到了跟你一样的问题，偶尔会出现有MAC ACK，但是对方实际是没有接收到的，感觉MAC ACK好像并不能用来说明数据发送成功，后续还有研究吗，能否解答一下，谢谢。