核心蓝牙在发送数据包时会变慢

时间:2013-10-23 13:54:40

标签: ios objective-c core-bluetooth

我遇到的问题是使用

将值写入特征之间的时间
[peripheral writeValue:dataPacket forCharacteristic:writeChar type:CBCharacteristicWithResponse]

实际上物理发送蓝牙数据包的iOS设备正在逐渐耗费更长时间。

这可以在调试器的以下输出中说明:

2013-10-23 14:12:17.510 Test App iOS[1561:60b] Packet sent
2013-10-23 14:12:17.595 Test App iOS[1561:60b] Packet sent confirmation, error = (null)
2013-10-23 14:12:17.598 Test App iOS[1561:60b] Packet response received

2013-10-23 14:12:17.611 Test App iOS[1561:60b] Packet sent
2013-10-23 14:12:17.656 Test App iOS[1561:60b] Packet sent confirmation, error = (null)
2013-10-23 14:12:17.657 Test App iOS[1561:60b] Packet response received

2013-10-23 14:12:22.601 Test App iOS[1561:60b] Packet sent
2013-10-23 14:12:23.123 Test App iOS[1561:60b] Packet sent confirmation, error = (null)
2013-10-23 14:12:23.125 Test App iOS[1561:60b] Packet response received

2013-10-23 14:12:27.601 Test App iOS[1561:60b] Packet sent
2013-10-23 14:12:28.111 Test App iOS[1561:60b] Packet sent confirmation, error = (null)
2013-10-23 14:12:28.113 Test App iOS[1561:60b] Packet response received

2013-10-23 14:12:32.611 Test App iOS[1561:60b] Packet sent
2013-10-23 14:12:34.595 Test App iOS[1561:60b] Packet sent confirmation, error = (null)
2013-10-23 14:12:34.597 Test App iOS[1561:60b] Packet response received


2013-10-23 14:12:37.611 Test App iOS[1561:60b] Packet sent
2013-10-23 14:12:39.582 Test App iOS[1561:60b] Packet sent confirmation, error = (null)
2013-10-23 14:12:39.585 Test App iOS[1561:60b] Packet response received

2013-10-23 14:12:42.611 Test App iOS[1561:60b] Packet sent
2013-10-23 14:12:44.570 Test App iOS[1561:60b] Packet sent confirmation, error = (null)
2013-10-23 14:12:44.573 Test App iOS[1561:60b] Packet response received

2013-10-23 14:12:47.611 Test App iOS[1561:60b] Packet sent
2013-10-23 14:12:49.558 Test App iOS[1561:60b] Packet sent confirmation, error = (null)
2013-10-23 14:12:49.560 Test App iOS[1561:60b] Packet response received

// Several packets omitted...

2013-10-23 14:13:07.610 Test App iOS[1561:60b] Packet sent
2013-10-23 14:13:09.508 Test App iOS[1561:60b] Packet sent confirmation, error = (null)
2013-10-23 14:13:09.511 Test App iOS[1561:60b] Packet response received

2013-10-23 14:13:12.610 Test App iOS[1561:60b] Packet sent
2013-10-23 14:13:14.496 Test App iOS[1561:60b] Packet sent confirmation, error = (null)
2013-10-23 14:13:14.498 Test App iOS[1561:60b] Packet response received

//等等......

数据包发送消息在writeValue命令之后的行上输出,以将数据包写入特征。

数据包发送确认在didWriteValueForCharacteristic委托方法的第一行输出。

收到的数据包响应消息在didUpdateValueForCharacteristic中输出,当BTLE设备发送响应数据包(通过辅助通知特性)确认收到我发送的数据包时,会调用该数据。

从最初可以看出,我调用writeValue forCharacteristic方法和确认数据包的回调之间的时间是在didWriteValueForCharacteristic中发送的,最初是85ms(已经很慢但可以忍受)。我大约每5秒发送一次这些数据包,在发送少量数据包之后,这会增加到约2秒,之后在2秒时似乎是静态的。在确认正在发送的数据包之后,从BTLE设备发回的响应数据包总是约2ms。

我不明白为什么在调用writeValue和确认回调didWriteValueForCharacteristic之间我在CoreBluetooth库中出现这种延迟。

在所有其他方面,代码工作正常(BTLE设备完全按照指示执行操作,并且没有任何数据包丢失)。

我有一个由BT4.0模块制造商提供的示例应用程序(包括源代码),它不会遇到这种不断增长的延迟 - 不幸的是,示例应用程序旨在应对模块的大量实现,而不仅仅是我们的具体实现是非常复杂的,包含许多与我们的实现无关的代码 - 我在样本中的每个函数中放置了断点,并手动逐步确定它们发出的命令,我相信我在复制他们完美(但显然不是)。

我看不出他们在做什么,我没有做,反之亦然。我可以在两个项目之间找到的唯一区别是我的使用ARC,他们使用手动引用计数。

其他信息: 一切都在主线程上运行(与模块制造商示例应用程序一样) 我使用主队列创建中央管理器(类似于模块制造商示例应用程序) iOS设备上的CPU负载仅为3%而我的应用程序正在运行,并且由于CPU负载等原因似乎没有任何延迟。

我用这个撕掉了我的头发,如果有人能为这个问题提出任何可能的原因或解决方案,我将永远感激不尽!

谢谢, 富

2 个答案:

答案 0 :(得分:7)

我在这方面取得了一些进展,但新闻并不好。事实证明,我对问题的原始描述是不正确的。我假设(总是一件坏事)模块供应商生产的样本应用程序是正确的,但它报告的时间数据是错误的 - 当他们报告〜3ms发送数据包并检索响应他们只是时间来自-didWriteValueForCharacteristic并且不包括调用writeValueForCharacteristic和didWriteValueForCharacteristic之间的时间 - 一旦我包括这次他们的app的行为和我的一样慢。

经过所有进一步调查后,似乎iOS CoreBluetooth库导致请求发送数据包并实际开始发送之间的延迟 - 这些任意延迟可以在80ms到2s之间的任何时间。有谁知道为什么iOS库在发送实际数据包时这么慢?我们在Android下运行的等效代码或多或少是即时的。

如果我戴上愤世嫉俗的帽子,我会说苹果故意这样做是为了防止需要快速响应的应用程序使用BTLE开发,从而迫使硬件开发人员使用需要苹果安全芯片的蓝牙3,从而有效地发生制造单位的苹果许可成本......

答案 1 :(得分:2)

首先检查一下你的内容:

-(void) peripheral:(CBPeripheral *)peripheral didWriteValueForCharacteristic:(CBCharacteristic *)characteristic
 error:(NSError *)error {

}

如果错误代码为0,则表示您正在向外围设备发送值而不确认它。 检查你的periheral是否实现了这个方法:

//assuming 
@property (strong, nonatomic) CBPeripheralManager       *peripheralManager;

- (void)peripheralManager:(CBPeripheralManager *)peripheral didReceiveWriteRequests:(NSArray *)requests
{
    NSLog(@"WRITE REQUEST!!! %lu",(unsigned long)requests.count);
    //check if there are data

   for (CBATTRequest * req in requests) {
   //send reposnse to Central that you recivied write value and eg / accept / reject the write request
    [self.peripheralManager respondToRequest:req
                                          withResult:CBATTErrorSuccess];
   }


}