• 状态 TI Thinks Resolved
  • 已锁定 已锁定
  • 个回复 19 个回复
  • 答案 1 答案
  • 名订阅用户 10 名订阅用户
  • 次查看 1174 次查看
  • 用户 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.

CC2652P: CC2652P: zigbee传输速度较快时丢包

sinjin guo
Prodigy 70 points
Part Number: CC2652P

说明：这是一个关于zigbee的问题，因论坛选择框只有“bluetooth forum”可选项，所以被划分至蓝牙论坛了。

芯片： CC2652P

协议栈版本号：simplelink_cc13xx_cc26xx_sdk_6_40_00_13

应用场景：一个协调器，一个子设备，当作透传模块使用。测试速率：每间隔30ms发送一包数据，zcl payload携带64字节数据。测试过程中，发现丢包的情况。发送端的打印LOG显示，所有数据发送成功，未出现丢包的情况，使用抓包工具抓包验证，确实是发送成功了。所以判定是接收端出现了丢包的情况。在函数void afIncomingData(...)中，增加log打印输出，通过LOG确认是丢包了。

问题：协议栈可支持最高的传输速率是多少，是否支持每间隔30ms发送64 bytes数据？

  • 0
    TI__Genius 14400 points

    1.

    Zigbee在2.4GHz频段下 可支持最高的传输速率是250kbps

    2.

    理论上是支持的

  • 0 回复 Galaxy Yue
    Prodigy 70 points

    有没有实测过，250kbps只是mac层空中传输速度，实际还会受Mcu运行速率、协议栈的实效性、装载数据等影响。根据我测试的情况，目前是远达不到这个速度的。

  • 0 回复 sinjin guo
    TI__Genius 14400 points

    很抱歉，没有实测过

    最高传输速率会受多种因素影响。

    Zigbee每个网络模块射频前端的数据传输速率是250K, 而控制端数据处理速率，则取决于所使用的CPU的处理速度。ZigBee 的最大传输速率是 250kbps ，但是一般达不到这么大，如使用波特率在 115200 ，一般就是 11.25bps

    在ZigBee标准中指定了两个物理频段和直接序列扩频（DSSS）实体层频段：868/915MHz和2.4GHz。 2.4GHz的实体层支援空气中250kb/s的速率，而868/915MHz的实体层支援空气中20kb/s和40kb/s的传输速率。

  • 0 回复 Galaxy Yue
    Prodigy 70 points

    1、根据我测试的情况看，数据是在接收方的底层协议栈丢了，函数函数void afIncomingData(...)未收到相关信息，再下一层未开源，我这边无法分析了。你们能不能帮忙分析下源码，看可否优化一下。

    2、是否了解到相关客户使用透传功能，速率可达多少。

  • 0 回复 sinjin guo
    Prodigy 70 points

    我测试时的串口波特率是230400bps，也曾经试过将接收端的串口输出屏蔽掉，以优化CPU运行的时效性，但是仍有丢包的情况（虽然未将数据从串口输出，但是MCU内部会检测数据，数据是有规律变化的，异常时会打印LOG）。

  • 0 回复 sinjin guo
    TI__Genius 14400 points

    关于您的问题和出现的情况，已经在跟进中，有进展会立即通知您的。

  • 0 回复 Galaxy Yue
    Prodigy 70 points

    补充一点：子设备RxonWhenIdle已设置为了true，不存在因设备休眠导致丢包的问题。并且，无论是子设备发往协调器，还是协调器发往子设备，在30ms每包，每包64字节的条件下，都会丢包。如果设置为50ms每包，每包64字节，则正常。

  • 0 回复 sinjin guo
    TI__Genius 14400 points

    好的，收到您补充的信息。请稍作等候。

  • 0 回复 sinjin guo
    TI__Genius 14400 points

    可以分享一下嗅探器日志吗？

    测试的目的是什么？ 是为了遵守射频法规吗？

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

    最终应用是什么？ 真的需要这么高的数据吞吐量吗？
    我问这个问题是因为 Zigbee 适用于低功耗、低数据速率（即吞吐量）网络。

  • 0 回复 Galaxy Yue
    Prodigy 70 points

    1、日志已添加。

    2、测试的目的是项目有需求，透传的速率要达到2k bytes/s，我看了一下数据包，应用层64 bytes+其它数据，共112字节，按30ms发一包来算，每秒大概30kbps，这相对于zigbee 250kbps的速率来讲，已经是大打折扣了，理论上是完全能实现的。

    3、项目需求是在当前协议栈基础上满足传输速率，已查明与协议栈有关，请研究查明原因，我觉得没必要使用SmartRF Studio 7测试了。

    嗅探器日志.zip

  • 0 回复 sinjin guo
    TI__Genius 14400 points

    好的，已经跟进，有进展会通知您的。

  • 0 回复 Galaxy Yue
    TI__Genius 14400 points

    感谢您澄清数据包不会在空中丢失。 更有可能的是，由于瓶颈，您丢失了数据包at the receiver due to bottleneck.

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

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

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

    以下是打印日志方面的指南

    https://dev.ti.com/tirex/explore/node?node=A__ANhb8wLgMuaIL980opkRTQ__com.ti.SIMPLELINK_ACADEMY_CC13XX_CC26XX_SDK__AfkT0vQ__6.40.00.00&r=AfkT0vQ__6.40.00.00

  • 0 回复 Galaxy Yue
    Prodigy 70 points

    1、你提到“CC2652P 有 2400 个周期用于上述过程，这显然足够”，既然足够，为何会丢包，是否要查一下问题，而不是让我这边增加发送间隔呢？

    2、你提到的改善方法，删除日志，甚至取消透传数据从串口输出，以避免MCU负担过重，如我这前所讲，我都试过，没有改善。

    3、你提到的改善方法，单包数据量增加80字节，这是个好办法，我也验证过，但结果是假如我单包传输64字节，间隔50ms发送的情况下，不丢包，如果我改为每包传输80字节，同样间隔50ms发送，则会丢包。所以目前看来，并没有明显增加透传速率。建议你们还是查一下协议栈接收端为什么会丢包。

  • 0 回复 sinjin guo
    TI__Genius 14400 points

    好的，继续为您跟进。

  • 0 回复 sinjin guo
    TI__Genius 14400 points

    1.“明显”意味着根据原始消息，50 ms = 2400 个周期就足够了。

    2. 如果先前已陈述过这一点，则尚未得到充分解释。 关于如何确定数据包丢失的更多细节是必要的。

    3. 也许这也因接收和处理添加的字节所需的额外时间而受到瓶颈。 您需要提供更具体的步骤来重现该问题，包括重新创建此行为所需的默认 SimpleLink Zigbee 项目的详细更改列表。

  • 0 回复 sinjin guo
    Guru 109510 points

    試試看關閉APS ack，另外如果是sleeping end device,照我的經驗這樣的速度幾乎已經是極限了,會出現丢包的狀況是正常的

  • 0 回复 YiKai Chen
    Prodigy 70 points

    已经关闭了APS ACK的，非sleeping end device，rxOnWhenIdle为true。目前没有也没有啥办法，只能这样了。

  • 0 回复 sinjin guo
    TI__Genius 14400 points

    您可以提供您更具体的步骤吗？

    我们尽量为您复现

  • 0 回复 sinjin guo
    TI__Genius 14400 points

    我又和英文论坛的工程师沟通了一下，您可以参考以下建议：

    您可以增加缓冲区大小，例如 nwk_globals.c 中的 NWK_MAX_DATABUFS_* 和 *_cnf.opts 中的 MAC_CFG_*，但这只会延迟最终的数据包接收失败。 最终，数据包吞吐能力太高，尤其是在多个设备加入的情况下，必须减少数据包吞吐能力，以便让 CPU 有时间进一步处理传入数据。 您还应该错开设备加入，可能是通过将开机设备的加入时间延迟在随机的零到十秒之间，以便 ZC TC 不必同时处理多个请求。 

    您说的建议我们会进一步测试改进。