[参考译文] CC2340R5：寻求帮助：CC2340R52 (SDK 9.11.00.18)-使用 iPhone (iOS) 时、185‑字节传输截断为 23 字节、传输距离~3m

您好！

23 字节是默认的 MTU 值、这表明您的问题是未处理 MTU Exchange。 您的问题是否发生在其他中心,如 Android 设备? 在屏幕截图的第一次 MTU 交换之后、是否会发生第二次 MTU 交换或断开连接、从而会覆盖此交换？

CC2340R5 使用的 F3 SDK 的 API 包含一个名为 L2CAP_GetMTU的函数、该函数允许您在调用函数时获取连接的当前 MTU。 您能尝试调用这个函数并查看它返回的值吗？

此致、
Lea

尊敬的 Lea：   

API L2CAP_GetMTU I 无法调用。 错误代码为“错误：使用未声明的标识符“IDX_L2CAP_GetMTU"。“。 Android 可以使用超过 23 字节。 没有第二次 MTU 交换或断开连接。 谢谢

您好！

看起来外设和中央器件同时发送 LL_LENGTH_REQ、并且两者同时回复。 虽然这应该不是问题、因为结果值应该完全相同、您是否还可以从外设发送 LL_LENGTH_RSP 的屏幕截图？

中央器件肯定支持 RX 和 TX 251 字节、但外设回复时可能仅支持 RX 最多 27 个字节、这就解释了为什么中央器件只发送 23 长的数据包。

此致、
Lea

 嗨 Lea 、这是 来自外设的 LL_LENGTH_RSP。 是 251。 我已再次使用 LightBlue iOS App 进行了检查 它可以接收 185 个字节。  谢谢

您好！

“它可以接收 185 个字节“是什么意思？ 中央设备能够向 CC2340R5 外设发送 185 个字节、还是只能从 CC2340R5 外设接收 185 个字节？ 这是有还是没有碎片?

此致、
Lea

中央设备（iOS LightBlue 应用）能够向 CC2340R5 外设发送 185 个字节而不进行 分段。  但我们的 IOS 应用程序有 碎片化。

您好！

在这种情况下、问题肯定来自您的 iOS 应用程序执行的操作与 LightBlue 应用程序不同 您可以尝试获取 2 个嗅探器日志,一个以 LightBlue 为中心,另一个以 iOS 应用程序为中心吗? 因此、您可以比较两者并查看两个监听器日志之间的不同之处。

此致、
Lea

尊敬的 Lea：

在进行额外测试后、我们发现是什么时候进行的 外设启动 MTU 交换 (247) 、iOS 应用程序可以使用传输图像数据 247 字节数据包 。

然而,当 iOS App (Central) 启动 MTU 交换 、数据包仍与传送 23 字节有效载荷 、即使 MTU 交换成功完成。 使用 BLE 监听器日志观察到了该行为。

基于此行为、这是否表明限制来自 IO 应用 ？

此外、是常用还是推荐使用 外围设备启动 MTU 交换 为了确保智能手机应用程序使用协商的 MTU？

谢谢。

。

您好！

启动 MTU 交换的设备不应对事务的结果产生任何影响、除非 Apple 设备执行了一些奇怪的操作。

请分享嗅探器的日志、以便我可以通过 Wireshark 自行查看？

此致、
Lea

尊敬的 Lea：

我附加了两个日志以供您参考： PAYLOAD_SIZE_23.pcapng 和 PAYLOAD_SIZE_247.pcapng 。
请参阅随附的图像、了解日志中的数据包位置。

您能否帮助检查日志并告知导致此行为的原因？

谢谢

.e2e.ti.com/.../7534.log.zip

尊敬的 Lea：

如果有机会、您可以帮助检查随附的日志吗？
我们目前正在调查 23 字节有效载荷行为的根本原因、您的见解将非常有帮助。

如果需要其他信息、请告知我。

提前感谢。

此致、
生活的示例