[参考译文] CC2340R5：在使用双中央器件+外设时功耗可变性

你好 Luca！

我不确定我是否完全理解您的问题,您能否向我提供以下信息:
-您使用的是哪个 SDK 版本?
-两张图片之间的设置有什么不同?
-你所面临的确切问题是什么,我不太明白你是什么意思“错过了 TX/Rx 睡眠过渡“

此致、
Maxence

嗨、 Lea 

SDK：8.20.00.119

如果器件仅作为外设或中央连接、则功耗是恒定的、并置于 0.4mA 之下、这很好。

如果设备 与外设和中央（2 个双连接）同时连接、且连接参数不同、则功耗会以 1 分钟的时间波动。 它从 0.4mA 开始,然后逐渐上升到 0.8mA（在~1 分钟后）,然后下降回 0.4mA ,然后上升和下降以相同的模式。

我假设 是由于 无线电 TX/RX 中存在移位和交错、这取决于不同的连接参数、因此会发生这种情况。 当中央器件和外设同时发生无线电 TX/Rx 时、功耗会较高（可能是因为无线电跳过睡眠阶段）

我想 知道我的假设是否正确、以及 当器件作为中央和外设连接时、是否可以避免无线电行为以保持恒定的功耗。

您好！

我可以问您的连接参数是什么吗？ 如果您的外设具有不同的连接间隔、则在某些时候、来自您的外设的 TX/RX 可能会与来自中央器件的 TX/RX 重叠、并且您在某些时间段会有更高的平均值、在其他时间段会有更低的平均值。

我不知道总是分离中央和外围设备的对讲机事件的任何方法、但无论如何、您的设备的全局消耗不应该改变、唯一的区别是您的消耗峰值可能更高。

此致、
Maxence

早上好、

中心可在 30 至 45ms 范围内  

外设可在 15ms 至 45ms 范围内

一种常见的连接间隔配置是中心 30ms 和外设 20ms

您好、

我已尝试复制您的问题、但我无法复制。 我的能耗与右侧的图表类似、其中事件是分开的、绝不会与另一个图表类似。 您是否在测试中使用 basic_ble 示例？

此致、
Maxence

不可以、测试使用我们的 生产固件执行。

Lea 您好、

我可以使用 DK 进行复制。

这里有一个视频和使用的固件。

在函数 EstablishConnection 中、更改 th central 应连接的可填地址。

e2e.ti.com/.../video1147677155.mp4

e2e.ti.com/.../5008.basic_5F00_ble_5F00_LP_5F00_EM_5F00_CC2340R5_5F00_freertos_5F00_ticlang.zip

你好 Luca！

我想用于 BLE 的时钟可能存在一些漂移。 您能告诉我您使用的时钟、如果您使用的是外部时钟吗？

此致、
Maxence

在我向您发送的上面示例中、固件使用开发套件 LP-EM-CC2340R5 运行

Lea 你好,这方面的任何更新?

你好 Luca！

我认为正在发生的情况是、您的某个连接的时间有点偏离（也可能是两个连接都偏离了不同的方向）。

在您的视频中、我假设您的连接 A 的连接间隔为 30ms、连接 B 的连接间隔为 15ms。 首先、连接 A 和 B 是同步的、连接 A 的无线电事件几乎与连接 B 的无线电事件同时发生。但随着时间的推移、这两个连接会取消同步、连接 A 的无线电事件会在连接 B 的无线电事件之前发生。这可以通过一半的能耗尖峰变大（连接 A 和 B 发生，中间出现延迟）来看出、 而另一半则较小（仅连接 B）。

随着连接断开、连接 A 和 B 之间的延迟越来越大。 当该延迟低于几毫秒时、电路板的电源管理器会决定不进入睡眠状态、这是因为如果无线电事件很快就会发生。 这就是为什么您会看到这种情况下功耗较高的原因。 当此延迟足够大（超过大约 5ms）时、电源管理器决定在连接 A 和 B 的无线电事件之间进入睡眠状态。但是、与同步连接时相比、这仍然会导致更高的功耗、因为这会比以前更长时间地唤醒和关断 CC2340R5。

为了确保我的想法确实发生了变化、您可以将能耗图与逻辑分析仪中的功率放大器 (TX) 和低噪声放大器 (RX) 图进行比较、看看器件何时真正处于 RX 状态或 TX 状态。 此处是用户指南中有关如何启用 PA 和 LNA 引脚的一章。

我认为 BLE 数据包中的漂移量惊人地大、我不确定是什么原因导致的。 这可能是一个错误、漏掉的数据包会使连接间隔时间稍微偏离一点、随着时间的推移、连接间隔会累积、可能是时钟硬件有缺陷或完全其他问题。 一种方法是减少器件的时钟漂移、方法是切换使用的时钟、添加漂移较小的外部时钟或对温度进行补偿。 但即使采用该解决方案、如果连接 CC2340R5 的器件的时钟发生变化、也可能会出现相同的问题。

我将花时间在今天和明天尝试重现您的问题、因为我没有与您相同的加密狗、所以要重现有点困难。

此致、
Maxence

感谢您的反馈。

我可以使用手机或笔记本电脑与充当中央+外围设备的装置建立可连接。 因此、它看起来不依赖于连接到 DK 的客户端。

您好！

我可以重现您的问题。 唯一的区别是,我的延迟增长比你慢,我花了不到 15 分钟才有一个“周期“,使用 15ms 的中央和 30ms 的外围设备。 我仍然不知道造成这种漂移的原因、但我将继续调查。

此致、
Maxence

谢谢你

您好、

我已向我们的研发团队开了一个 TT、询问他们有关情况。 我会随时更新您的最新信息。

此致、
Maxence

 对此有任何更新吗？

您好、  

研发部门尚未更新情况。

此致、
Lea