低功耗蓝牙 – 重复更新特征值
电气工程Stackexchange后续问题
我想在很短的时间内重复写入一个蓝牙低功耗特性的值（作为一个可能的用例，想象一下鼠标）。
- 具有128位UUID的特性是20字节长。 因此，它可以写在一个单一的低能量交易。
- 写速度为50Hz，相当于每20ms写一次 。
- 因此写入20 * 50 * 8 = 8 kbit / s 。
- 我正在使用命令 / 写入无响应模式写入特性。 因此，在属性层上不会发生确认。
- 没有连接其他蓝牙或蓝牙低功耗设备。 没有什么是通过WLAN执行的。 在testing过程中没有其他特征被读取或写入。
我通过发送包含iPhone 4S序列号的数据包来testing程序。 序列号在每个发送的数据包之后递增1。
在接收端，使用一个集成了CSR1000 BLE芯片的可编程开发板，用于接收数据包并将接收到的序列号打印到串行连接。
我的问题如下：
-
一段时间后，数据包开始下降。 前100个数据包在50赫兹时工作正常。 从那时起，数据包开始下降。
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 ...大多数情况下，一包四个数据包传输很好（很less，只有2个数据包）。 然后，1-7包丢失。
当我减小特征值大小时，问题仍然存在。
当我以100Hz而不是以50Hz写入时，图像是相同的 – 只有在大约35个分组之后才开始发生丢包，并且在四个分组的成功发送之间丢弃了5-7个分组。
丢失数据包时，不pipe写入的频率如何，最终的传输速率都在5 kbit / s左右。 这显然低于〜305 kbit / s，这在技术上应该可以通过蓝牙低功耗实现。
-
当我从开发板发送数据包到iPhone 4S时，问题也出现在相反的方向。 再次，5 kbit / s是我得到的最大值。 通知机制用于此scheme。 同样，在属性层上不会发生确认。
-
当我尝试同时向两个方向发送信息时，事情开始发生，我必须重置开发板和iPhone 4S。
问题：
-
这可能是开发板上使用的蓝牙低功耗芯片的问题吗？
如果是的话，为什么这个问题也出现在相反的方向，iPhone作为接收方？
市场上有没有支持高频访问特性的开发板？
-
这个问题的根源是什么？
除了假设之外，还请尝试引用部分蓝牙规格/演示幻灯片/文章。
市场上有蓝牙低功耗鼠标。 小鼠具有125赫兹的典型轮询速率，并且必须至less发送两个16字节值加上每个时间片附加的HID开销。 因此，我的问题的解决scheme应该是可用的。
更新
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
发出连接参数更新解决了这个问题，吞吐量从5 kbit / s增加到〜33 kbit / s 。 但是，这仍然低于预期的〜305 kbit / s。
Conn_Interval = 0x000f = 18.75 ms Conn_Latency = 0x0000 Supervision_Timeout = 0x00fc
有没有办法达到〜305 kbit / s？
电气工程Stackexchange后续问题
可以通过刻录TSI并等待一个月来得到Apple的回复。
基本上，他们说这个行为是在iOS 5.1中的。 它不知何故是有道理的，因为他们不希望你的应用程序的性能取决于另一个应用程序是否使用蓝牙或WiFi。
根据工程师的意见 – 在iOS 5.1下，连接间隔期间应该有6对通知，即6 * packetSize * 1000 / interval。 这应该转换成最大〜55kbps（最小间隔是20ms，包大小是23个字节）。 由于iPhone和iPad在BT classic，BT LE和WiFi之间都有共享天线，因此我们决定限制每个区间的配对数量并且具有最小间隔。
iOS LE被devise成一个低功率运输。 对于更高的吞吐量，BT classic是更好的传输方法。
回到我的上面 – 基于上面的工程师的评论，如果希望达到200 kbs的吞吐量，Classic bluetooth就是答案。 但是，如果愿意与iPhone上的应用程序一起工作，我可以理解这不是简单的改变 – 传统BT需要MFI许可。
主要的问题似乎是你正在使用的芯片上的缓冲区问题。 从核心规范第3卷F部分3.3.2：
对于没有响应PDU的通知，不存在stream量控制，并且可以随时发送通知。
不需要响应的命令没有任何stream量控制。 注意：服务器可以被命令填充，更高层规范可以定义如何防止发生这种情况。
由于缓冲区溢出或其他原因收到但无法处理的命令和通知应被丢弃。 因此，这些PDU必须被认为是不可靠的。