我在 Samsung 和 Google Pixel 设备上遇到 BLE 问题。我有一个外设，同时具有蓝牙低功耗和蓝牙经典通道。首先，我将音频通道连接到手机，并将 BLE 通道连接到手机上的应用程序。然后，外设开始通过 BLE 通知向手机传输数据，手机同时播放多个曲目。 外设发送一个178字节的数据包，间隔为72ms。每个数据包的标头中都有一个从 0 到 255 的序列号，并且重复。 当 RSSI 稳定时 (< -60), everything is fine, but when the distance between the peripheral and the phone increases, the RSSI becomes weak, and data is lost. The payload received on the phone was interrupted (I checked the sequence number). After that, I brought the phone and the peripheral closer, RSSI became strong again, but the data loss continued. But if I stop playing music, the data loss disappears immediately. When I press playback, the data loss continued.
检查手机上的HCI snoop日志，我发现当数据丢失时，178字节的有效负载数据被分成多个32字节的数据包并重新组装。此问题仅发生在 Samsung 和 Google Pixel 设备上。我在Vivo、Oppo、甚至iPhone上测试过，都没有遇到这个现象。
有什么方法可以去除Android上的这种数据包分割机制吗？如果我无法摆脱它，有什么方法可以重新配置该机制，使其不再像原来那样拆分数据包？
有人遇到过这个问题吗？请推荐我，谢谢。
由于 BLE 链路层是可靠的协议，因此除非发生断开连接，否则不会在空中丢失数据包。如果您在 hci 日志中没有看到预期的数据包，则意味着发送者根本就没有发送它。请检查您的固件代码，尤其是您的流量控制，当您想要发送更多数据或更频繁地发送超出链路所能承受的数据时，您如何处理这种情况。蓝牙吞吐量是共享资源，因此如果您同时传输音频，与外围设备之间的吞吐量会减少，这并不奇怪。
您所指的数据包拆分机制是指将一个 L2CAP 数据包拆分为多个链路层数据包。 LE 数据长度扩展用于协商每个方向的最大数据包大小。通常，Android 似乎会将此与所选的 ATT MTU 大小保持一致。但播放音频时它可能会降低（不确定，但我知道 Android 团队已经做了很多调整来优化良好的音频质量）。您通常会在 hci 日志中看到此协商。
如果无线电调度程序需要在一次或多次往返后中断连接事件，即使任何设备设置了“更多数据”标志，例如为了处理您的音频流，这可以解释为什么您会看到吞吐量下降。该代码在蓝牙控制器（蓝牙芯片）内部运行，而不是在主机（Android）内部运行。
您可以采取的典型解决方案是降低连接间隔。这将增加您的外围设备发送数据的机会。您可以将其与“外设延迟”结合起来，以允许外设跳过没有任何新数据要发送的连接事件。