核心蓝牙在发送数据包时会变慢 [英] Core Bluetooth slow down when sending packets

问题描述

我遇到了一个问题，即使用

I'm experiencing an issue where the time between writing a value to a characteristic using the

[peripheral writeValue:dataPacket forCharacteristic:writeChar type:CBCharacteristicWithResponse]

实际上物理发送蓝牙数据包的iOS设备正在逐步延长

and the iOS device actually physically sending the bluetooth packet is progressively taking longer and longer.

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

This can be illustrated in the following output from the debugger:

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

//等等...

Packet sen在writeValue命令之后的行上输出t消息，以将数据包写入特征。

The Packet sent message is output at the line immediately after the writeValue command to write the packet of data to the characteristic.

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

The packet sent confirmation is output in the first line in the didWriteValueForCharacteristic delegate method.

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

The packet response received message is output in the didUpdateValueForCharacteristic which is called when the BTLE device sends the response packet (via a secondary notification characteristic) to confirm receipt of my sent packet.

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

As can be seen initially the time between my calling the writeValue forCharacteristic method and the callback to confirm the packet has been sent in didWriteValueForCharacteristic is initially 85ms (which is already slow but bearable). I send these packets approx every 5 seconds, and after only a small number of packets sent this increases to ~2 seconds after which is seems to be static continually at 2 seconds. The response packet sent back from the BTLE device is always ~2ms after the confirmation of the packet being sent.

我不明白为什么我会在调用writeValue和确认回调之间的CoreBluetooth库didWriteValueForCharacteristic。

I don't understand why I'm getting this delay in the CoreBluetooth libraries between calling writeValue and the confirmation callback didWriteValueForCharacteristic.

在所有其他方面，代码运行正常（BTLE设备完全按照指示执行并没有丢失任何数据包。）

In all other respects the code is working perfectly (the BTLE device is doing exactly what it is being instructed to do and none of the packets go missing).

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

I have a sample app that is provided by the BT4.0 module manufacturer (including source) which does not experience this growing delay - unfortunately the sample app is designed to cope with a large range of implementations of the module, not just our specific implementation and so is massively complex containing much code that is just not relevant to our implementation - I've placed breakpoints in every function in the sample and manually stepped through to determine exactly which commands they are issuing, and I believe I am copying them perfectly (but obviously not).

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

I can see nothing that they are doing that I am not doing and vice versa. The only difference I can spot between the two projects is that mine uses ARC and theirs uses manual reference counting.

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

Other information: Everything is running on the main thread (as it is with the module manufacturers sample app) I create the Central Manager using the main queue (similarly in module manufacturers sample app) CPU load on the iOS device is only at 3% whilst my app is running and nothing seems to be being delayed due CPU load etc.

我正在用这个撕掉我的头发，如果有人可以提出任何可能的原因或解决方案对于这个问题，我将永远感激不尽！

I'm tearing my hair out with this, and if anyone can suggest any possible causes or solutions for this problem I would be eternally grateful!

谢谢，
Rich

Thanks, Rich

推荐答案

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

I have made some progress on this and the news isn't good. It turns out that my original description of the problem is incorrect. I'd assumed (always a bad thing to do) that the sample app produced by the module supplier would be correct however the timing figures it's reporting are wrong - when they report ~3ms to send the packet and retrieve the response they are only timing from the -didWriteValueForCharacteristic and do not include the time between calling the writeValueForCharacteristic and the didWriteValueForCharacteristic - once I included this time their app behaves as slowly as mine.

进一步的调查看来，iOS CoreBluetooth库导致请求发送数据包之间的延迟并且它实际上开始发送 - 这些任意延迟可以是80ms到2秒之间的任何时间。有谁知道为什么iOS库在发送实际数据包时这么慢？我们在Android下运行的等效代码或多或少是即时的。

After all the further investigation it appears that the iOS CoreBluetooth libraries are causing the delay between requesting the packet be sent and it actually begin sent - these arbitrary delays can be anywhere between 80ms and 2seconds. Does anyone know why the iOS libraries are so slow at sending the actual packet? Our equivalent code running under Android is more or less instant.

如果我对我的愤世嫉俗的话，我会说Apple故意这样做以防止需要快速响应的应用程序使用BTLE进行开发，从而迫使硬件开发人员使用需要苹果安全芯片的蓝牙3，从而有效地为制造的设备带来苹果许可成本...

If I had my cynical hat on I would say Apple are deliberately doing this to prevent applications requiring a fast response from being developed using BTLE and thereby force the hardware developers to use Bluetooth 3 which requires the apple security chip and thereby effectively incurs an apple licensing cost on units manufactured...

这篇关于核心蓝牙在发送数据包时会变慢的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！