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

Question

关于电气工程Stackexchange的后续问题

我想在很短的时间内反复写入蓝牙低功耗特性的值(作为一个可能的用例,想象一下鼠标).

• 128位UUID的特性是20字节长.因此,它可以在单个低能量交易中编写.
• 写入以50Hz的速率发生,等于每20ms写入一次.
• 因此,写入20*50*8 = 8 kbit/s.
• 我使用Command/Write without response模式来编写特性.因此,属性层上不会发生确认.
• 没有连接其他蓝牙或蓝牙低功耗设备.没有通过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开销.因此,应该可以找到我的问题的解决方案.

更新

该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？

关于电气工程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旨在实现低功耗传输.对于更高的吞吐量,BT classic是更好的传输方法.

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