2013-03-18 27 views
9

Tôi đang phát triển một hệ thống có thiết bị BLE (TI CC2540) là Trung tâm và ứng dụng iOS trên iPhone4S làm Ngoại vi. Mọi thứ hoạt động tốt ngoại trừ 1 chức năng tôi cần: các thiết bị quảng cáo danh sách trắng (lọc) từ phía trung tâm.Dữ liệu ngoại vi/quảng cáo iOS BLE ở chế độ nền

Theo như tôi biết, thiết bị iOS sử dụng địa chỉ MAC ngẫu nhiên có thể giải quyết, vì vậy chúng tôi không thể áp dụng danh sách trắng dựa trên địa chỉ MAC.

Vì vậy, phương pháp hiện tại của tôi là: đặt ID vào trường "Tên địa phương" trên dữ liệu quảng cáo của ứng dụng iOS (thiết bị iOS hoạt động ngoại vi), Thiết bị trung tâm sẽ quét và lọc dựa trên dữ liệu quảng cáo đã truy xuất. Điều này hoạt động trừ khi ứng dụng ở chế độ nền.

Khi ứng dụng của tôi được đặt ở chế độ nền, dữ liệu quảng cáo bị cắt bớt và "tên cục bộ" của tôi không xuất hiện trong không trung. Từ tệp tiêu đề của corebluetooth, tôi thấy chỉ có dữ liệu "vùng tràn" có thể ở trong dữ liệu quảng cáo khi ứng dụng ở chế độ nền nhưng chỉ thiết bị iOS mới có thể đọc được khu vực này.

Vì vậy, bất kỳ ai cũng có thể làm sáng tỏ cách thêm dữ liệu tùy chỉnh vào gói quảng cáo ngay cả ở chế độ nền hoặc bất kỳ giải pháp nào khác để có chức năng lọc này.

Mọi nhận xét sẽ giúp tôi rất nhiều.

+0

Bạn đã bao giờ tìm thấy giải pháp/giải pháp cho vấn đề này chưa? Cùng một vấn đề ở đây. –

Trả lời

0

Tôi biết đây là một bài đăng cũ hơn, nhưng đối với bất kỳ ai tò mò, không có cách nào đáng tin cậy để thực hiện điều này vì CBAdvertisementDataLocalNameKey không được truyền trong khi ứng dụng ở chế độ nền.

Ngoài ra, hệ điều hành bỏ qua phím CBCentralManagerScanOptionAllowDuplicatesKey, vì vậy bạn sẽ nhận được chính xác một cuộc gọi đã thực hiệnDiscoverPeripheral cho mỗi thiết bị mới được phát hiện.

Nếu bạn tò mò tại sao, hãy nhớ rằng ở cấp phần cứng chỉ có một đài phát thanh bluetooth được chia sẻ bởi tất cả các ứng dụng sử dụng BLE và gói quảng cáo được chia sẻ giữa tất cả các ứng dụng quảng cáo.

Khu vực tràn chứa tất cả UUID của dịch vụ mà thiết bị của bạn quảng cáo. Tôi sẽ tưởng tượng rằng lĩnh vực này là nhỏ và hệ thống có khả năng phải gửi một số gói đi xe đạp thông qua UUID để quảng cáo cho tất cả, nếu bạn có nhiều.

Ngoài ra, đây là một lý do nữa khiến gói quảng cáo là địa điểm không tối ưu để đưa thông tin ứng dụng bắt buộc. Giả sử bạn có ứng dụng dựa trên dữ liệu quảng cáo cho dịch vụ UUID A. Sau đó, ứng dụng đó sẽ được tạo nền và người dùng mở một ứng dụng khác sử dụng dữ liệu quảng cáo cho dịch vụ UUID B.

Vì thiết bị hiện là dịch vụ quảng cáo cho UUID A và UUID B, bất kỳ thiết bị nhận nào sẽ nhận được cuộc gọi lại trên bất kỳ trung tâm nào tìm kiếm A hoặc B. Tuy nhiên, CBAdvertisementDataLocalNameKey sẽ chỉ chứa dữ liệu cho B, vì nó ở phía trước trên thiết bị truyền, có nghĩa là thiết bị của bạn chỉ mong đợi dữ liệu cho A có thể xử lý dữ liệu sai.

Nếu bạn muốn rõ ràng hơn về dữ liệu quảng cáo thực sự truyền, có một ứng dụng iOS tuyệt vời trên App Store có tên LightBlue sẽ hiển thị cho bạn dữ liệu này và cho phép bạn kết nối với thiết bị và xem tất cả đó là dịch vụ, đặc điểm và mô tả.

0

Tôi đang gặp khó khăn với cùng một vấn đề. Đối với dự án của tôi, tôi cần phải đọc ít nhất CBAdvertisementDataLocalNameKey của iPhone trong nền từ một Raspberry Pi. Tôi vẫn không thể nhận được bất kỳ thông tin nào từ vùng tràn.

Tuy nhiên, tôi đã tìm thấy một điều thú vị có thể giải quyết được vấn đề của chúng tôi. Có một số ứng dụng Android để quét BLE có thể đọc LocalName trong khi thiết bị iOS lân cận ở chế độ nền. Ví dụ là this một. This là ảnh chụp màn hình của ứng dụng được trích dẫn hiển thị CBAdvertisementDataLocalNameKey chính xác trong khi iPhone lân cận ở chế độ nền.

Trong thử nghiệm quét android, mâm xôi không thể đọc bất cứ điều gì ngoại trừ khối Dữ liệu nhà sản xuất. Một giải pháp có thể là sử dụng gói sniffer bluetooth để hiểu đó là yêu cầu quét chính xác để nhận được thông báo phản hồi quét có chứa vùng tràn. Rất tiếc, phần cứng này yêu cầu phần cứng cụ thể như phần cứng Ubertooth One.

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