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

1.

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

2.

理论上是支持的

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

很抱歉，没有实测过

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

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

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

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

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

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

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

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

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

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

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

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

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

1、日志已添加。

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

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

嗅探器日志.zip

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

感谢您澄清数据包不会在空中丢失。 更有可能的是，由于瓶颈，您丢失了数据包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

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

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

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

好的，继续为您跟进。

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

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

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

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

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

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

我们尽量为您复现