核心藍牙發送數據包

時，我遇到了一個問題，即使用核心藍牙發送數據包

[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和他們的使用手動引用計數。

其他信息：一切都在主線程上運行（因爲它是與模塊廠商示例應用程序）我使用主隊列（類似於模塊製造商示例應用程序） CPU負載在iOS創建中央管理器設備只有3％，而我的應用程序正在運行，似乎沒有任何東西似乎由於CPU負載等原因而延遲。

我把我的頭髮撕了，如果有人可以提出任何可能的原因或解決方案，這個問題我會永遠感激！

感謝，豐富

來源

2013-10-23 Richard Baxter

這是真的，真的很有趣的是，他們的示例應用程序不會出現這種延遲，但你做。我沒有什麼好的理由。這是巫術，但要排除它，你可以嘗試製作一個簡單的手動保留計數應用程序，看看ARC是否影響它？ – cbowns

這是我一直在考慮的事情。我之前從未遇到過ARC的任何問題，但由於我排除了其他可能性，所以我得出的結論是，我將不得不證明它不是ARC導致問題並執行類似於您的建議。 –

我對此有了另一個想法：可能值得使用Instruments分析CoreBluetooth應用程序和示例應用程序，以查看什麼時候創建了什麼對象。如果您的應用程序在創建永不釋放的資源方面存在微妙的錯誤，CoreBluetooth可能會花費更多時間更新不再使用的對象，這可能是導致放緩的原因。 – cbowns

我已經做這方面的一些進展和消息並不好。事實證明，我對問題的原始描述是不正確的。我認爲（總是一件壞事），模塊供應商生產的示例應用程序是正確的，但是它報告的時序數據是錯誤的 - 當它們報告〜3ms發送數據包並檢索響應時，它們只是時序從-didWriteValueForCharacteristic開始，並且不包括調用writeValueForCharacteristic和didWriteValueForCharacteristic之間的時間 - 一旦我包含這次他們的應用程序的行爲與我的一樣慢。

經過所有的進一步調查，似乎iOS CoreBluetooth庫引起請求發送數據包和實際開始發送之間的延遲 - 這些任意延遲可能在80毫秒到2秒之間。有誰知道爲什麼iOS庫發送實際數據包的速度很慢？我們在Android下運行的等效代碼幾乎是即時的。

如果我有我的玩世不恭的帽子，我會說蘋果故意這樣做，以防止應用程序需要使用BTLE開發的快速響應，從而迫使硬件開發人員使用需要蘋果安全芯片的藍牙3，從而有效地即被上製造單位的蘋果授權費用...

來源

2013-10-28 10:02:35

我有同樣的問題。你有沒有找到其他的東西？ – mohkhan

我也遇到了與iOS 9相同的問題。有沒有人發現過什麼？ – Pierre

首先檢查你進去：

-(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]; 
    } 


}

來源

2013-12-10 14:05:15

核心藍牙發送數據包

回答

相關問題