iOS BLE-Peripheriegeräte / Werbungsdaten im Hintergrundmodus

9

Ich entwickle ein System mit einem BLE-Gerät (TI CC2540) als Central und einer iOS-App auf dem iPhone4S als Peripheral. Alles funktioniert gut außer 1 Funktion, die ich brauche: Whitelist (Filterung) Werbe-Geräte von der zentralen Seite.

Soweit ich weiß, verwenden iOS-Geräte eine zufällig auflösbare MAC-Adresse. Daher können wir die Whitelist nicht anhand der MAC-Adresse anwenden.

Meine aktuelle Methode lautet also: Geben Sie eine ID in das Feld "Lokaler Name" auf den Werbedaten der iOS-App ein (das iOS-Gerät fungiert als Peripheriegerät). Das zentrale Gerät scannt und filtert basierend auf abgerufenen Werbedaten. Dies funktioniert, wenn die App nicht im Hintergrund ist.

Wenn meine App in den Hintergrund gestellt wird, werden die Werbungsdaten abgeschnitten und mein "lokaler Name" erscheint nicht über Funk. Aus der Header-Datei von Corebluetooth sehe ich, dass es nur "Überlaufbereich" Daten in Werbedaten geben kann, wenn die App im Hintergrund ist, aber nur iOS-Geräte können diesen Bereich lesen.

So kann mich jemand hier anzünden, wie man selbst im Hintergrundmodus benutzerdefinierte Daten zu einem Werbepaket hinzufügt, oder irgendeine andere Lösung, um diese Filterfunktion zu haben.

Jeder Kommentar wird mir sehr helfen.

    
mgdaubo 18.03.2013, 11:50
quelle

2 Antworten

0

Ich weiß, dass dies ein älterer Post ist, aber für alle Neugierigen gibt es keinen zuverlässigen Weg, dies zu erreichen, weil der CBAdvertisementDataLocalNameKey nicht gesendet wird, während sich die App im Hintergrund befindet.

Außerdem ignoriert das Betriebssystem den CBCentralManagerScanOptionAllowDuplicatesKey, sodass Sie für jedes entdeckte neue Gerät genau einen didDiscoverPeripheral Callback erhalten.

Wenn Sie neugierig sind, warum, denken Sie daran, dass es auf der Hardwareebene nur ein Bluetooth-Radio gibt, das von allen Apps mit BLE geteilt wird, und das Werbepaket wird von allen Apps, die Werbung haben, geteilt.

Der Überlaufbereich enthält alle Dienst-UUIDs, die von Ihrem Gerät angekündigt werden. Ich könnte mir vorstellen, dass dieses Feld klein ist und das System wahrscheinlich mehrere Pakete durch die UUIDs senden muss, um sie alle anzukündigen, wenn Sie viele haben.

Auch hier ist ein weiterer Grund, warum das Werbepaket ein nicht optimaler Ort ist, um erforderliche App-Informationen zu platzieren. Angenommen, Sie verwenden eine App, die auf Werbungsdaten für die Service-UUID A basiert. Dann wird diese App im Hintergrund angezeigt und der Nutzer öffnet eine andere App, die Werbedaten für die Service-UUID B verwendet.

Da das Gerät jetzt Dienste für UUID A und UUID B ankündigt, erhält jedes empfangende Gerät einen Rückruf auf jeder Zentrale, die nach einem A oder B sucht CBAdvertisementDataLocalNameKey wird nur die Daten für B enthalten, da es auf dem sendenden Gerät im Vordergrund ist, was bedeutet, dass Ihr Gerät nur Daten erwartet, für die A möglicherweise falsche Daten verarbeitet.

Wenn Sie genauer wissen möchten, was die Werbedaten tatsächlich übertragen, gibt es eine hervorragende iOS-App im App Store namens LightBlue, die Ihnen diese Daten anzeigt und es Ihnen ermöglicht, sich mit einem Gerät zu verbinden und alles anzusehen Dienstleistungen, Merkmale und Deskriptoren.

    
Adamb 18.10.2013 16:03
quelle
0

Ich kämpfe mit dem gleichen Problem. Für mein Projekt muss ich zumindest den CBAdvertisementDataLocalNameKey eines iPhone im Hintergrund von einem Raspberry Pi lesen. Ich kann immer noch keine Informationen aus dem Überlaufbereich erhalten.

Ich habe jedoch eine interessante Sache gefunden, die unser Problem lösen könnte. Es gibt einige Android-Anwendungen für BLE-Scan, die in der Lage sind, den LocalName zu lesen, während sich das nahegelegene iOS-Gerät im Hintergrund befindet. Ein Beispiel ist das . Dies ist der Screenshot der zitierten App, der den korrekten CBAdvertisementDataLocalNameKey zeigt, während das nahegelegene iPhone im Hintergrund ist.

Während des Android-Scan-Tests kann die Himbeere außer dem Herstellerdatenblock nichts lesen. Eine mögliche Lösung besteht darin, einen Bluetooth-Paket-Sniffer zu verwenden, um zu verstehen, welche die richtige Scan-Anforderung ist, um die Scan-Antwortnachricht zu erhalten, die den Überlaufbereich enthält. Dies erfordert leider spezielle Hardware wie die Ubertooth One.

    
andreaciri 10.07.2016 17:32
quelle