2013-10-23 19 views
10

Tôi đang gặp một vấn đề mà thời gian giữa viết một giá trị cho một đặc tính sử dụnglõi Bluetooth chậm khi gửi gói tin

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

và các thiết bị iOS thực chất việc gửi các gói dữ liệu bluetooth được dần dần mất nhiều thời gian và lâu hơn.

này có thể được minh họa trong đầu ra sau từ 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 

// Và vân vân ...

Packet gửi thông điệp là đầu ra tại dòng ngay sau khi lệnh writeValue để ghi gói dữ liệu vào đặc tính.

Xác nhận đã gửi gói được xuất trong dòng đầu tiên trong phương thức ủy quyền didWriteValueForCharacteristic.

Thông báo nhận được gói tin là đầu ra trong didUpdateValueForCharacteristic được gọi khi thiết bị BTLE gửi gói phản hồi (thông qua đặc tính thông báo phụ) để xác nhận đã nhận gói tin đã gửi của tôi.

Như có thể thấy ban đầu, thời gian giữa việc gọi phương thức writeValue forCharacteristic và gọi lại để xác nhận gói đã được gửi trong didWriteValueForCharacteristic ban đầu là 85ms (đã quá chậm nhưng có thể chịu được). Tôi gửi các gói này khoảng 5 giây một lần, và chỉ sau một số lượng nhỏ các gói tin được gửi đến mức tăng lên ~ 2 giây sau đó dường như là tĩnh liên tục trong 2 giây. Gói phản hồi được gửi lại từ thiết bị BTLE luôn là ~ 2ms sau khi xác nhận gói tin được gửi đi.

Tôi không hiểu tại sao tôi nhận được sự chậm trễ này trong thư viện CoreBluetooth giữa việc gọi writeValue và cuộc gọi xác nhận đã làmWriteValueForCharacteristic.

Trong tất cả các khía cạnh khác, mã hoạt động hoàn hảo (thiết bị BTLE đang thực hiện chính xác những gì nó đang được hướng dẫn thực hiện và không có gói nào bị mất).

Tôi có một ứng dụng mẫu được cung cấp bởi nhà sản xuất mô-đun BT4.0 (bao gồm cả nguồn) mà không gặp phải sự chậm trễ ngày càng tăng này - rất tiếc ứng dụng mẫu được thiết kế để đối phó với phạm vi triển khai lớn của mô-đun, chứ không phải chúng tôi đã đặt các điểm ngắt trong mọi chức năng trong mẫu và tự bước qua để xác định chính xác các lệnh mà chúng đang phát hành và tôi tin rằng tôi sao chép chúng hoàn hảo (nhưng rõ ràng là không).

Tôi không thể thấy điều gì họ đang làm mà tôi không làm và ngược lại. Sự khác biệt duy nhất tôi có thể nhận ra giữa hai dự án là tôi sử dụng ARC và của họ sử dụng tính toán tham chiếu thủ công.

thông tin khác: Tất cả mọi thứ đang chạy trên các chủ đề chính (vì nó là với các ứng dụng mẫu nhà sản xuất mô-đun) tôi tạo Quản lý Trung ương sử dụng hàng đợi chính (tương tự như trong các nhà sản xuất mô-đun ứng dụng mẫu) CPU tải trên iOS thiết bị chỉ ở mức 3% trong khi ứng dụng của tôi đang chạy và dường như không bị trễ do tải CPU ...

Tôi đang xé tóc ra và Toi se mai mai biet on!

Cảm ơn, Giàu

+0

Nó thực sự, thực sự thú vị mà ứng dụng mẫu của họ không thể hiện sự chậm trễ này nhưng bạn không có gì. Tôi không có lý do chính đáng nào. Đó là voodoo, nhưng để loại trừ nó ra, bạn có thể thử làm cho một hướng dẫn sử dụng đơn giản giữ lại ứng dụng đếm để xem nếu ARC đang ảnh hưởng đến nó? – cbowns

+0

Đó là điều tôi đã cân nhắc. Tôi chưa bao giờ gặp bất kỳ vấn đề nào với ARC trước đây, nhưng khi tôi loại trừ các khả năng khác, tôi sẽ đi đến kết luận rằng tôi sẽ phải chứng minh rằng đó không phải là ARC gây ra vấn đề và làm điều gì đó như bạn đề xuất. –

+0

Tôi đã có một suy nghĩ về điều này: nó có thể có giá trị profiling cả hai ứng dụng CoreBluetooth của bạn và các ứng dụng mẫu với dụng cụ để xem những gì các đối tượng đang được tạo ra khi. Nếu ứng dụng của bạn có một lỗi nhỏ xung quanh việc tạo tài nguyên mà nó không bao giờ phát hành, CoreBluetooth có thể dành nhiều thời gian cập nhật các đối tượng không được sử dụng nữa và đó có thể là lý do cho sự chậm lại. – cbowns

Trả lời

7

Tôi đã thực hiện một số tiến bộ về vấn đề này và những tin tức không tốt. Nó chỉ ra rằng mô tả ban đầu của tôi về vấn đề là không chính xác. Tôi giả định (luôn luôn là một điều xấu để làm) rằng các ứng dụng mẫu được sản xuất bởi các nhà cung cấp mô-đun sẽ được chính xác tuy nhiên các số liệu thời gian báo cáo là sai - khi họ báo cáo ~ 3ms để gửi gói và lấy phản hồi họ chỉ là thời gian từ -didWriteValueForCharacteristic và không bao gồm thời gian giữa việc gọi hàm writeValueForCharacteristic và didWriteValueForCharacteristic - khi tôi đưa vào thời gian này ứng dụng của họ hoạt động chậm như của tôi. Sau khi tất cả các điều tra tiếp theo, dường như các thư viện CoreBluetooth của iOS đang gây ra sự chậm trễ giữa yêu cầu gửi gói và nó thực sự bắt đầu được gửi - những sự chậm trễ tùy ý này có thể ở bất cứ đâu trong khoảng 80ms đến 2 giây. Có ai biết tại sao các thư viện iOS chậm đến mức gửi gói tin thực sự? Mã tương đương của chúng tôi đang chạy trong Android ít nhiều tức thì.

Nếu tôi có mũ hoài nghi, tôi sẽ nói Apple đang cố tình làm điều này để ngăn các ứng dụng yêu cầu phản hồi nhanh bằng cách sử dụng BTLE và do đó buộc các nhà phát triển phần cứng sử dụng Bluetooth 3 yêu cầu chip bảo mật của Apple. gánh chịu một chi phí cấp phép táo trên đơn vị sản xuất ...

+1

Tôi có cùng một vấn đề. Bạn có tìm thấy gì khác không? – mohkhan

+0

Tôi cũng gặp vấn đề tương tự với iOS 9. Có ai từng phát hiện ra điều gì đó không? – Pierre

1

Trước hết kiểm tra những gì bạn nhận được trong:

-(void) peripheral:(CBPeripheral *)peripheral didWriteValueForCharacteristic:(CBCharacteristic *)characteristic 
error:(NSError *)error { 

} 

nếu mã lỗi là 0 có nghĩa là bạn đang gửi giá trị đến ngoại vi KHÔNG xác nhận nó. Kiểm tra nếu periheral bạn thực hiện phương pháp này:

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


} 
Các vấn đề liên quan