ios - Bluetooth Low Energy - 重复更新特征值

Question

Follow-Up question on Electrical Engineering Stackexchange

我想在短时间内重复写入Bluetooth Low Energy 特性的值(作为一个可能的用例，想象一下鼠标)。

• 具有 128 位 UUID 的特征是 20 字节 长。因此，它可以写在单个低能耗交易中。
• 写入的频率为 50 赫兹，相当于每 20 毫秒写入一次。
• 因此写成20 * 50 * 8 = 8 kbit/s。
• 我正在使用Command/Write without response 模式来写入特性。因此，属性层上不会发生任何确认。
• 未连接其他蓝牙或低功耗蓝牙设备。不通过 WLAN 执行任何操作。测试期间不会读取或写入其他特征。

我通过从 iPhone 4S 发送包含序列号的数据包来测试程序。每发送一个数据包，序列号加一。

在接收端，一个可编程的开发板，其中包含一个 CSR1000 BLE芯片，用于接收数据包并将接收到的序列号打印到串行连接。

我的问题如下:

• 一段时间后，数据包开始被丢弃。前 ~100 个数据包在 50 Hz 下工作正常。从那时起，数据包开始被丢弃。

             0x00 - 0x46   received
              0x47, 0x48   missing
  0x49, 0x4a, 0x4b, 0x4c   received
                    0x4d   missing
  0x4e, 0x4f, 0x50, 0x51   received
                    0x52   missing
  0x53, 0x54, 0x55, 0x56   received
                    0x57   missing
  ...
  

  大多数情况下，一包四个数据包可以很好地传输(很少，只有 2 个数据包)。然后，丢失 1-7 个数据包。

  当我减小特征值大小时，问题仍然存在。

  当我以 100Hz 而不是 50Hz 写入时，画面是一样的 - 只是在大约 35 个数据包后开始出现丢失，并且在成功传输四个数据包之间丢失了 5-7 个数据包。

  对于丢失的数据包，无论写入频率如何，最终的传输速率约为 5 kbit/s。这明显低于 ~305 kbit/s，这在技术上应该是通过低功耗蓝牙实现的。

• 问题也发生在相反的方向，当我从开发板向iPhone 4S发送数据包时。同样，5 kbit/s 是我得到的最大值。 Notification 机制用于此场景。同样，属性层上不会发生任何确认。

• 当我尝试同时向两个方向发送时，情况开始恶化，以至于我不得不重置开发板和 iPhone 4S。

问题:

• 这可能是开发板上使用的低功耗蓝牙芯片的问题吗？

  如果是，为什么问题也发生在相反的方向，即 iPhone 作为接收器？

  市面上有支持高频访问特性的开发板吗？

• 问题的根源可能是什么？

  除了假设之外，还请尝试引用蓝牙规范/演示幻灯片/文章的部分内容。

市场上存在蓝牙低功耗鼠标。鼠标的典型轮询频率为 125 Hz，并且必须至少发送两个 16 字节的值加上每个滴答的额外 HID 开销。因此，应该有针对我的问题的解决方案。

更新

LE 连接完成事件在蓝牙规范版本 4.0 第 2 卷第 E 部分第 7.7.65.1 节中进行了描述。对于不同的连接参数，我收到以下值:

Parameter               Value      Description
--------------------------------------------------
Conn_Interval           0x0054     Time =  105 ms
Conn_Latency            0x0000     Time =    0 ms
Supervision_Timeout     0x00fc     Time = 2520 ms
Master_Clock_Accuracy     0x05              50 ppm

Answer 1

发布连接参数更新 解决了该问题并将吞吐量从 5 kbit/s 提高到 ~33 kbit/s。然而，这仍然低于预期的 ~305 kbit/s。

Conn_Interval = 0x000f = 18.75 ms
Conn_Latency  = 0x0000
Supervision_Timeout = 0x00fc

是否有任何方法可以达到完整的 ~305 kbit/s？

Follow-Up question on Electrical Engineering Stackexchange

Could get a reply from Apple by burning a TSI and waiting for a month.

Basically, they tell that the behavior is intended in iOS 5.1. It somehow makes sense, because they don't want that your app's performance depends on whether another app uses Bluetooth or WiFi.

Per the engineers comments - Under iOS 5.1 there should be 6 pairs of notifications during a connection interval, meaning 6*packetSize*1000/interval . This should translate to ~55kbps max (min interval is 20ms, packetsize is 23 bytes). We made the decision to limit the number of pairs per interval and have a minimum interval due to the fact that the iPhone and iPad both have shared antenna between BT classic, BT LE and WiFi.

iOS LE is designed to be a low power transport. For higher throughput BT classic is a better transport method.

Back to me - Based on the engineers comments above, if the desire is to achieve a 200 kbs throughput, Classic bluetooth is the answer. However, if the desire is to work with an application on the iPhone, I can understand that this is no simple change - Classic BT requires MFI licensing.