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.

[参考译文] CC2652P:ZigBee 传输速度高时数据包丢失

Guru**** 2458180 points
Other Parts Discussed in Thread: CC2652P

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1289765/cc2652p-packet-loss-when-zigbee-transmission-speed-is-high

器件型号:CC2652P

团队好,

注意:这是关于 ZigBee 的问题。 由于论坛选择框仅包含"Bluetooth forum"选项、因此会分类到蓝牙论坛中。

simplelink_cc13xx_cc26xx_sdk_6_40_00_13

应用场景:一个协调器和一个子器件、被用作一个透明的传输模块。

测试速率:每30ms 发送一个数据包、zcl 有效载荷可承载64字节的数据。

测试过程中发现数据包丢失。

发送端打印的日志表明所有数据均已成功发送、并且没有数据包丢失。

使用数据包捕获工具捕获数据包并验证数据包是否确实已成功发送。

因此、可确定在接收端发生了丢包。 在函数 void afIncomingData(...)中,添加日志打印输出并通过日志确认数据包已丢失。

我的测试期间的串行端口波特率为230400bps。

我还尝试屏蔽接收端的串行端口输出、以优化 CPU 操作的及时性、

但仍然有数据包丢失(尽管数据不是从串行端口输出、

但内部 MCU 将会检测到数据、数据会定期更改、异常时将打印日志)。

1.根据我的测试,数据丢失在基础协议栈的接收器,函数 void afIncomingData(...) 没有收到相关信息、并且下一层不是开源的、因此我无法在这里进行分析。 您能否帮助分析源代码并查看是否可以对其进行优化?

2、您是否知道相关客户在使用透明透射功能时能达到多少?

此致,

银河

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    团队好,

    另外一点:子器件 RxonWhenIdle 已设置为 true、并且器件睡眠不会导致数据包丢失。 而且、子器件发送给协调器还是协调器发送给子器件、在每个数据包30ms 和每个数据包64字节的条件下、数据包都将丢失。 如果设置为每个数据包50ms 和每个数据包64字节、则是正常情况。

    此致,

    银河

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好!

    您可以共享监听器日志吗?

    测试的目的是什么? 是否需要符合射频法规?

    如果需要、我建议使用 SmartRF Studio 7来执行此类测试。 使用数据包 TX 和数据包 RX。

    终端应用是什么? 是否真正需要如此高的数据吞吐量?
    我问这个问题、因为 Zigbee 专用于低功耗、低数据速率(即吞吐量)网络。

    谢谢。
    托比

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好, Toby J ü,

    1.已添加日志。

    2.测试的目的是,如果项目有要求,透明传输速率必须达到2kbytes/s。 我查看了数据包。 应用层为64字节+其他数据、总共为112字节。 每秒30ms 发送一个数据包来计算。 大约30kbps、与 Zigbee 的250kbps 速率相比已经有了很大的折扣。 理论上、它是完全可以实现的。

    3、项目要求满足基于当前协议栈的传输速率。 我们发现它与协议栈相关。 请研究并找出原因。 我认为不需要使用 SmartRF Studio 7进行测试。

    e2e.ti.com/.../7635._C555A2636856E565D75F_.zip

    此致,

    银河

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    Unknown 说:
    因此、可以确定接收端发生了数据包丢失。 在函数 void afIncomingData(...)中,添加日志打印输出并通过日志确认数据包已丢失。

    感谢您澄清数据包不会无线丢失。  更可能的是、由于瓶颈、您在接收器处丢失数据包。

    约30kbps,与 Zigbee 的250kbps 速率相比,这已经是一个很大的折扣。 理论上,它是完全可以实现的。[/报价]

    这不考虑 处理数据包的设备的限制。  在间隔为30ms 的48 MHz 上、CC2652P 在每个传入数据包之间有1440个周期 、用于 MAC 处理-> NWK 处理-> APS 处理->应用处理->打印->等待下一个数据包并重复。   

    如果设置为每个数据包50ms 和每个数据包64字节,这是正常的。

    现在、CC2652P 有2400个周期可用于上述过程、这显然已足够。  改善行为的选项包括:

    • 增加数据包间隔(数据包之间有更多的处理周期)、同时增加数据包大小(对于更多的每个数据包数据字节、但请记住当前数据包为112字节、 MAX_MAC_FRAME_SIZE 为127、因此每个数据包最多限制为80个数据字节)
    • 减少或完全删除 打印日志,因为它们 对主核心造成了过重的负担

    此致、
    瑞安

    [/quote]
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好,Ryan M ü,

    我的客户提出了以下三个问题:

    1.您提到"CC2652P 有2400个周期可完成上述过程、这显然足够了"。 既然已经足够、为什么会发生数据包丢失? 是否要检查问题而不是让我增加发送间隔?

    2.以上改进方法包括删除日志、甚至从串口取消透明数据的输出、以免给 MCU 带来过大的负担。 正如我之前所说,我已经全部尝试过,没有任何改进。

    3.改进方法是将单个数据包的数据量增加80字节。 这是一种很好的方法。 我也对其进行了验证、但结果是、如果我在单个数据包中传输64个字节、并以50ms 的间隔发送、则不会有数据包丢失。 ,如果我更改为每个数据包传输80字节,并以相同的50ms 间隔发送数据包,则数据包将丢失。 所以目前看来,透明传输率并没有明显提高。 建议您检查协议栈的接收端丢失数据包的原因。

    此致,

    银河

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    1."明显"表示根据原始消息50ms = 2400个周期已足够。

    2.如果这是以前说过的,没有得到充分的解释。  有关如何确定丢包的更多详细信息是必要的。

    3.可能这也是在 接收和处理添加的字节所花费的额外时间出现的瓶颈。  您需要提供更具体的步骤来重现问题、包括关于重新创建此行为所需的默认 SimpleLink Zigbee 工程的详细更改列表。   

    此致、
    瑞安

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、 Ryan、

    我已关闭 APS ACK、非睡眠终端设备、rxOnWhenIdle 是正确的。

    那么、在透明传输速率很高的情况下、您能帮助我减少数据包丢失吗?

    此致,

    银河

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    当更多设备同时加入网络时、更可能丢失网络访问通知消息。 在最坏的情况下、32个设备同时加入网络、并且15个设备的网络访问通知丢失。

    此致,

    银河

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Galaxy、  

    可以增加缓冲区大小,例如 NWK_globals.c 中的 NWK_MAX_DATABUFS_*和 *_cnf.opts 中的 MAC_CFG_*,但这只会延迟最终的数据包接收失败。  最终、数据包吞吐量能力过高、尤其是加入多个器件时、并且必须降低、以便 CPU 有时间进一步处理传入数据。  您还应该错开设备联接、可能的方法是将已通电设备的联接时间延迟为随机0到10秒、这样 ZC TC 就不必同时处理多个请求。  我无法就此问题提供任何进一步的建议或帮助。

    此致、
    瑞安