如果外圍設備響應遲一點，中心會出現寫請求的錯誤響應

Question

我一直在使用CoreBlueTooth框架在BTLE iOS設備之間進行通信，並且我看到一個奇怪的行爲。這是我在做什麼：

1. iOS設備1（外設）：公開一個可寫的特性。
2. iOS設備2（中央）：掃描可寫特性並將數據寫入其中。
3. iOS設備1（外設）：接收寫入請求。等待一段時間以確認收到數據。
4. iOS設備2（中央）：獲取下面的代理回調並收到提到的錯誤。

問題：在這裏，如果我通過調用API [iPeripheral respondToRequest:iRequest withResult:iStatus]在幾秒鐘內回覆寫請求，那麼它一切正常，我的中央成功。但是，如果我花一些時間，即使我的外設沒有響應寫請求，我也會收到錯誤響應。

這是某種在幾秒鐘內連接丟失或已知的CB框架的行爲，任何想法的？

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

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

我的中央和外圍設備都在iOS 7.0上運行。

Answer 1

當我在我的代碼死鎖和無法及時;-)我發現它的方式迴應我也觀察到了這個問題，iOS設備與任意錯誤代碼的自動錯誤請求進行響應，如果請求沒有回答在10秒內。我還沒有找到一種方法來改變這種情況，但從協議的角度來看它是有意義的。

在低功耗藍牙，中央只能發送一次一個單一的特徵值寫入請求。發送此請求之後，除非第一個響應，否則它不能發送不同的寫入請求。因此，始終儘可能快地迴應請求至關重要。

在評論中，你提到你正在等待用戶輸入的影響要發送到中央的結果代碼。如果用戶在UI中確認應該開始操作，那麼我猜測「成功」，如果用戶拒絕，則認爲是錯誤代碼。這不是應該設計基於LE的協議的方式。這就像阻塞UI線程，直到操作完成，從另一端。在阻止操作（等待用戶輸入）完成之前，您正在有效阻止BT通信。

不同的設計會發送一個寫請求對方手機，具有「成功」的錯誤代碼，則立即迴應表示該請求被接收並顯示在彈出。然後，將用戶選擇的特徵值指示從外設發送到中央。

還有一個小警告，如果你定位到iOS 6：指標沒有在很多情況下很好地工作（重入的錯誤等，最好不要碰它們）。在那裏，你應該從你的中心發送一個讀請求，並且在這個讀請求中返回用戶的選擇，如果它已經可用的話。同樣，在給出答案時不要阻止，如果答案還沒有準備好，則發回「用戶仍然選擇」價值。

單規則：儘可能快地回答請求。正是這樣，藍牙LE被設計用於工作。

Answer 2

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

Answer 3

您可能超過了寫入確認所允許的最長時間。嘗試測試幾種不同的確認時間，看看它是否可靠地失效超過一定的閾值。