Question

Follow-Up question on Electrical Engineering Stackexchange

我想在短时间内反复写出蓝牙低能耗特征的值（作为可能的用例，想象一下鼠标）。

128位UUID的特性是 20字节长。因此，它可以在单个低能量交易中编写。
写入速率为50 Hz，等于写入每20ms 。
因此，写入20 * 50 * 8 = 8 kbit / s 。
我使用命令 / 无响应写入模式来编写特征。因此，属性层上不会发生确认。
未连接其他蓝牙或蓝牙低功耗设备。没有通过WLAN执行任何操作。测试期间不会读取或写入任何其他特征。

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

在接收端，使用一个可编程开发板，它包含一个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是我得到的最大值。通知机制用于此方案。同样，属性层上不会发生确认。
当我尝试同时向两个方向发送时，事情开始爆发，我必须重置开发板和iPhone 4S。

问题：

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

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

市场上是否有支持高频率特性的开发板？
问题的根源可能是什么？

除了假设之外，还请尝试参考部分蓝牙规格/演示幻灯片/文章。

市场上存在蓝牙低能耗鼠标。小鼠的典型轮询速率为125 Hz，并且必须至少发送两个16字节值以及每个滴答的额外HID开销。因此，应该可以找到我的问题的解决方案。

更新

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

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

可以通过刻录TSI并等待一个月来获得Apple的回复。

基本上，他们告诉该行为是在iOS 5.1中。它   不知何故有道理，因为他们不想要你的应用程序   性能取决于另一个应用程序是否使用蓝牙或WiFi。


根据工程师的评论 - 在iOS 5.1下，在连接间隔期间应该有6对通知，这意味着     6 * packetSize * 1000 / interval。这应该转换为~55kbps最大值（最小值     interval是20ms，packetsize是23个字节）。我们做出了决定     限制每个间隔的对数，并具有最小间隔     事实上，iPhone和iPad之间都有共用天线     BT经典，BT LE和WiFi。

iOS LE旨在成为低功耗传输。对于更高的吞吐量，BT classic是一种更好的传输方法。

回到我身边 - 基于上面的工程师评论，如果希望达到200 kbs的吞吐量，经典蓝牙就是答案。     但是，如果希望使用iPhone上的应用程序，我     可以理解，这不是简单的改变 - 经典BT需要MFI     许可。

Answer 2

主要问题似乎是你正在使用的芯片上存在缓冲问题。从核心规范，第3卷，F部分，3.3.2：

对于没有响应PDU的通知，没有流量控制，可以随时发送通知。

不需要响应的命令没有任何流控制。注意：服务器可以充满命令，更高层规范可以定义如何防止这种情况发生。

由于缓冲区溢出或其他原因而收到但无法处理的命令和通知应被丢弃。因此，必须认为这些PDU不可靠。

Answer 3

当数据包丢失时，您看到的是由于iPhone端（最有可能是我想）或主机端的缓冲区溢出。从iOS 11.2开始，apple提供了一种机制，可让您在写入下一个数据包之前检查缓冲区是否已就绪。 canSendWriteWithoutResponse：

如果在写入数据包之前一直等到canSendWriteWithoutResponse为true，则可以保证已将传递放置在接收缓冲区中，但不能保证已对其进行处理（未确认）。可以帮助协商的另一件事是协商大于20的MTU。Apple支持185B的MTU，最大支持251（扩展的数据长度，也称为EDL）。通过以MTU-3大小分块数据包，每个连接间隔的数据包==（MTU-3）x 1。 @ 185B MTU，连接间隔为24 ms，我的吞吐量约为48kbps，没有丢失的数据包。从设备向iPhone发送数据时，该端的SDK将需要与“ canSendWriteWithoutResponse”等效，在我的案例中，使用SiLabs硬件/ SDK确实具有例如

```

 do {
     result = gecko_cmd_gatt_server_send_characteristic_notification(
              0xFF,
              evt->data.evt_gatt_server_attribute_value.attribute,
              chunk.length,
     [chunk bytes])->result;
 } while(result == bg_err_out_of_memory); 
  //retry until buffer is empty and ready for more 
 //then update the offset
 offset += thisChunkSize;

```

这是来自Apple的视频和.pdf，解释了不同的BLE技术和预期的速度。 MTU +连接间隔是您用来确定最大吞吐量的条件。 48kps应该很容易实现，96kbps甚至可能更高。

Core Bluetooth的新功能

video: https://devstreaming-cdn.apple.com/videos/wwdc/2017/712jqzhsxoww3zn/712/712_hd_whats_new_in_core_bluetooth.mp4?dl=1
pdf: https://devstreaming-cdn.apple.com/videos/wwdc/2017/712jqzhsxoww3zn/712/712_whats_new_in_core_bluetooth.pdf

蓝牙低功耗 - 重复更新特征值

3 个答案: