1

我一直在使用 CoreBlueTooth 框架在 BTLE iOS 设备之间进行通信，但我看到了一个奇怪的行为。这是我正在做的事情：

  1. iOS 设备 1 (Peripheral)：公开一个可写特性。
  2. iOS 设备 2（中央）：扫描可写特征并将数据写入其中。
  3. iOS 设备 1（外围设备）：接收写入请求。等待一段时间以确认收到数据。
  4. iOS 设备 2（中央）：在下面的委托上获取回调并收到上述错误。

问题：在这里，如果我通过调用 API 在几秒钟内响应写入请求，[iPeripheral respondToRequest:iRequest withResult:iStatus]那么一切正常，并且我在 Central 上获得了成功。但是如果我花一些时间，即使我的外围设备没有响应写入请求，我也会收到错误响应。

这是几秒钟内的某种连接丢失还是已知的 CB 框架行为，知道吗？

- (void)peripheral:(CBPeripheral *)iPeripheral didWriteValueForCharacteristic:(CBCharacteristic *)iCharacteristic error:(NSError *)iError 

Error Domain=CBErrorDomain Code=0 "Unknown error." UserInfo=0x183a6d70 {NSLocalizedDescription=Unknown error.}

我的 Central 和 Peripheral 都在 iOS 7.0 上运行。

4

3 回答 3

0

当我的代码出现死锁并且无法及时响应时，我也观察到了这个问题 ;-) 我观察到的方式是，如果在 10 秒内没有响应请求，iOS 会以带有任意错误代码的自动错误请求进行响应。我还没有找到改变这一点的方法，但从协议的角度来看它是有意义的。

在低功耗蓝牙中，中央一次只能发送一个特征值写入请求。发送此请求后，除非第一个请求得到响应，否则它不能发送不同的写入请求。因此，始终尽可能快地响应请求至关重要。

在评论中，您提到您正在等待用户输入来影响您想要发送到中心的结果代码。如果用户在 UI 中确认应该开始操作，我猜“成功”，如果用户拒绝，我猜是错误代码。这不是基于 LE 的协议的设计方式。这就像阻塞 UI 线程直到操作完成，只是从另一边。在阻塞操作（等待用户输入）完成之前，您实际上是在阻塞 BT 通信。

另一种设计是向另一部手机发送写入请求，立即响应“成功”错误代码以指示已收到请求并显示弹出窗口。然后，将带有用户选择的特征值指示从外围设备发送到中央设备。

如果您以 iOS 6 为目标，有一个小警告：在许多情况下，指示效果不佳（重入错误等，最好不要碰它们）。在那里，您应该从您的中心发送一个读取请求，并在此读取请求中返回用户的选择（如果它已经可用）。同样，在给出答案时不要阻止，如果答案尚未准备好，则发回“用户仍在选择”值。

单一规则：尽快回答请求。就是这样，低功耗蓝牙旨在工作。

于 2013-10-26T11:35:21.933 回答
0

您可能超过了确认写入所允许的最长时间。尝试测试几个不同的确认时间，看看它是否可靠地失败超过某个阈值。

于 2013-10-18T02:28:00.187 回答
-1

如果您使用 iPhone 4 设备，此设备不支持 BLE。iPhone 4 及更高版本支持 BLS。

于 2013-10-17T19:42:07.213 回答