我一直在使用CoreBlueTooth框架在BTLE iOS设备之间进行通信，我看到了一个奇怪的行为。这就是我在做的事情：
问题：如果我通过调用API [iPeripheral respondToRequest:iRequest withResult:iStatus]在几秒钟内回复写请求，那么一切正常，我在Central上取得了成功。但如果我需要一些时间，即使我的Peripheral没有响应写请求，我也会收到错误响应。
这是几秒内某种连接丢失还是已知的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上运行。
答案 0 :(得分：0)
您可能超过了允许写入的最长时间。尝试测试几个不同的确认时间，看看它是否可靠地超过某个阈值。
答案 1 :(得分：0)
当我在代码中出现死锁并且无法及时响应时，我也发现了这个问题;-)我观察它的方式，如果请求未在内部回答，iOS会响应自动错误请求并带有任意错误代码10秒我还没有找到改变这种方法的方法，但从协议的角度来看它是有道理的。
在蓝牙低功耗中，中央只能一次发送一个特征值写请求。发送此请求后，除非响应第一个请求，否则它不能发送不同的写请求。因此，始终尽快回复请求至关重要。
在评论中，您提到您正在等待用户输入以影响要发送到中央的结果代码。如果用户在UI中确认应该启动操作，我猜“成功”，如果用户拒绝，则为错误代码。这不是基于LE的协议的设计方式。这就像阻止UI线程直到操作完成，只是从另一端。您正在阻止BT通信，直到阻塞操作（等待用户输入）完成。
另一种设计是向另一部手机发送写入请求，立即使用“成功”错误代码进行响应，以指示已收到请求并显示弹出窗口。然后，根据用户从外围设备到中心的选择发送特征值指示。
如果您针对iOS 6，有一个小警告：在许多情况下，指示不能很好地工作（重入错误等，最好不要碰它们）。在那里，您应该从您的中心发送一个读取请求，并在此读取请求中返回用户的选择（如果它已经可用）。同样，在给出答案时不要阻止，如果答案尚未准备就回送“用户仍在选择”值。
单一规则：尽快回复请求。这就是蓝牙LE的设计方式。
答案 2 :(得分：-1)
如果您使用的是iPhone 4设备，则此设备不会支持BLE。 iPhone 4及更高版本支持BLS。