Android - BlueTooth LE Advertise Broadcast Bytes empfangen

[OrtmannMedia]

Hallo,
ich habe eine Hardware, die sendet per BlueTooth LE (4.1) broadcasts im Advertise modus.
Also da können ja 25 Bytes als PayLoad gesendet werden.
Diese möchte ich nun mit meiner Android-App empfangen.
Mit BlueToothLE1.DiscoverDevices(15000); bekomme ich das Gerät auch schön gelistet,
und habe dann im event TForm1.BluetoothLE1EndDiscoverDevices auch das Device gelistet:
ADeviceList[i].DeviceName...

Jetzt möchte ich die Payload, also die Broadcast bytes haben.
Leider gibt die Help garnix her... aber z.B. habe ich gefunden
ADeviceList[i].AdvertisedData. ...
Das hört sich zumindest schon mal so an.

Wer kann mir helfen, wie kann ich die Bytes zu empfangen, bitte?
Viele Grüße, Jürgen

[Rollo62]

Hast du die Demos BleScanner und ExploreDevicesLE ausprobiert ?
Da kann man schon eine Menge Geräte mit analysieren.

Rollo

[OrtmannMedia]

Hi, oh, stimmt gibt's ja Samples. Probiere ich erst mal. Danke, Jürgen

[mensch72]

schaue dir die "AdvertisedData" BINÄR an, verlasse dich nicht auf die Erkennung&Aufteilung durch den BLE Stack&Delphi... suche dir also deine PayLoad-Daten und verifiziere sie selbst(z.B. durch eine eigene CRC), lass dir was zum Thema Simulationssicherheit durch Fremde einfallen! (BLE-Name+XYZ als "SALT" der CRC oder was auch immer, verwende nicht die MAC des BLE Gerätes, weil die bekommt deine App unter IOS leider NICHT heraus, weil Apple die nur für eigene Zwecke intern verarbeitet und den APPs nur einen HashID zur Geräteidentifikation anstatt der BLE-MAC herausgibt.

Verwende bitte mindestens IOS9.x oder Android 5.1 oder neuer... IOS8.x und Android 4.4.x und Android 5.0.x hatten das Problem, das sich erstens die PrimaryServiceID nicht sauber als AdvertiseFilter nutzen ließ und zweitens sich die AdvertiseDaten(PayLoad und Name) nicht aktualisiert haben, wenn die BLE MAC einmal erfasst wurde (CacheProblem im AndroidStack, da half nur gesteuertes BLE Disable,Wait,"DisabledCheck" und Enable... wenn "BLE-Disable nicht binnen 3sec möglich, Hinweis an Nutzer, doch bitte mal sein Gerät hart neu zu starten)

Da der AdvertisePayload im BLE "zeitlich" begrenzt ist, sollte man möglichst kurze Namen(bis 8Standard-ASCII-Zeichen und nur eine PrimaryServiceID im BLE Gerät konfigurueren und den Payload als "UserDefined" wenn man echt die Daten will(das verhindert das OS-Services den PayLoad "abfangen", wie sie es bei erkanntem "BeaconPayload" machen), wenn man lieber einen AutoWakeup+AutoStart seiner App möchte, dann sollte man seinen BLE-Advertise-Payload als "BeaconSimualtion" OS kompatibel senden... dann klappt wenn man es geschickt anstellt das sogar unter IOS(ist aber etwas tricky und nur rechtlicher Graubereich ohne echte Apple-MFI Lizenz )

Prüfe wenn IOS für dich wichtig bitte immer zuerst was unter IOS geht, denn es gilt grob gesagt: alles was unter IOS geht, klappt auch unter aktuellen Androids, umgedreht gilt das leider NICHT! Speziell bei NonStandard BLE Daten verhält sich Android gutmütig und gibt alles an seine APPs weiter. Bei IOS bekommt man nur das, was Apple einem freigibt und durchreicht. Seit Apple IOS Richtung SmartHome intern erweitert, ist aktuelles IOS gerade wieder verschärft wurden, da bereitet man intern eine weitere Lizenzstruktur im Advertise Payload für offizielle MFI kompatible BLE Geräte vor. (Nach "Connect" kann ja jeder machen was er will, aber gerade das "normale" Advertise als verbindungsloses BroadCast für eigene Daten(änderungen) zu nutzen... da arbeiten Apple und andere wie auch wir gerade ausgiebig daran )

[MyRealName]

Da will ich mal kurz ne Frage einwerfen, vielleicht wisst ihr das ja als BT Experten

Wenn ich einen externen Kamera Auslöser habe, der sich ja beim Android Gerät als Keyboard anmeldet, und ich mochte den Knopfdruck in meiner App mitbekommen, dann kann ihc das OnKeyPress Event des Forms nehmen während die App im Vordergrund ist.

Wenn sie im Hintergrund ist, krieg ich das nicht mehr...
Gib es eine Chance, das Event zu bekommen ?

Danke

[OrtmannMedia]

Hallo mensch72, danke,
ja Android 5.1 mache ich als Voraussetzung. IOS wird nicht unterstützt werden.
Sender ist ein Microchip RN4020. Ich setze den in Broadcast mit ein paar bytes Payload
(z.B. Temperaturmess-Daten) und lasse ihn advertisen (mit no direct advertisement,
so dass ihn alle nicht-gebondeten Devices sehen müssten, wenn sie vorbeikommen).
Im 100ms Intervall, invinite.
Die Payload-Daten selbst enthalten auch noch ein paar Bytes extra für eine Id, damit ich ein bisschen weiss, obs auch meine Payload ist und zur Fehlererkennung usw.
Autowake/start der App brauche ich nicht. Die App wird vom Anwender gestartet und soll sich dann
auf klick auf die Suche machen und die Temperatur anzeigen. Sonst eigentlich nix.
Habe dem RN4020 schon einen (kurzen) DeviceName gegeben, und das Ding wird
nach DiscoverDevices auch schon gefunden und gelistet.
Nun eben noch, womit komme ich an die Payload?

[mensch72]

Ich behaupte, ich weiß hier zufällig mal sehr sehr gut Bescheid... "zufällig" setzen wir auch das RN4020 von Microchip von Anfang an ein, sogar in mittlerweile 5stelliger Stückzahl

Welche Softwareversion hast du auf dem RN4020?
(V1.20/V1.23 oder V1.33+ ... alles unter V1.20 ist Schrott, lässt sich aber per DFU/OTA updaten)

Hast du am RN4020 noch ein eigenes Programm(z.B. Microcontroler), oder willst du es per "Script" Standalone im Modul machen?
(Script unter V1.23 funktioniert nie wirklich gut, und wirklich drauf verlassen tun wir uns auch aktuell nicht, wir setzen immer einen eigenen Microcontroler zur Modulsteuerung und Powermanagement bei BattSystemen ein)

Wie konfigurierst du dein Modul?
(... sag mal deine "SS" & "SR" Werte)

Wenn es dir wirklich nur um ein paar Bytes(bis zu 5Bytes+1ByteCRC) eigenen Payload im Advertise geht, würde ich dir sogar als schnelle und 100% Android&IOS kompatiple Alternative empfehlen, nur den BLE Advertise Namen (SN oder S_ Komando) als 8Zeichen Base64 kodierte 6Bytes zu nutzen und eine 16ByteGUID als PrivateService zu definieren, womit du "deine Geräte" erkennen und vorfiltern kannst. Dann einfach bei allen 8Zeichen langen BLE Namen diese Base64 decodieren und die CRC der 5+1Bytes prüfen... so machen wir das nebenbei auch noch, weil das Verfahren 2 Vorteile hat: Die BLE Namen sind "unlesbar" was den Spieltrieb von Leuten mit BLE Scannern deutlich reduziert, das Verfahren bietet "zusätzliche" 40Bit Payload und funktoniert sogar mit allen Wald&Wiesen BLE-Modulen sowie ab Android 4.4 und IOS8.x

[OrtmannMedia]

Oh, wow, das ist allerdings ein sehr schöner Zufall!
Super

Ja, der wird über einen PIC32MX340 angesteuert.
Habe mal ausgelesen, mein Modul, in meinem Projekt,
antwortet mir mit Version "MCHP BTLE v1.23.5 8/7/2015".
Habe die von Microchip Direct Ende letzten Jahres bekommen.

(Ausserdem habe ich aber noch so ein Demo-Board von Microchip,
das man über USB am PC ausprobieren kann,
das hat noch das 1.20 drauf sehe ich grade.)

Ich habe mir das Setup lt. User Guide mal so ausgedacht:

SN,BLUETEST
SR,04000000
R,1
N,12345566
A

Lasse ich das N, .. weg,
dann kommt das Teil beim Scannen als BLUETEST auch gelistet.
Mit N, ist es unsichtbar.

Jedoch:
Inzwischen habe ich das Demo-Board mit
SR,80000000 (set to central)
R,1
F
J,1
aufgesetzt. Und es sausen die Broadcast-Daten daher.
Also scheint das Broadcasten schon zu klappen.

Jetzt müsste ich die bytes noch in Delphi reinbekommen.
Hier bin ich leider noch nicht so weit.

Ansonsten, ja stimmt, könnte man auch im DeviceNamen was so geschickt reintun.
Und PrivateService definieren u. filtern.
Hat ja sogar nennenswerte Vorteile wie Du schreibst.
Muss ich mal nachdenken.

Die Broadcast-Daten bekomme ich die überhaupt mit Delphi?
Wenn nicht, wäre eben die DeviceName Idee eine Lösung.

[mensch72]

der SS Wert wäre noch sehr wichtig!

oder mach mal ein "D" wie "Dump" und gibt mal die gesamte Rückgabe

[mensch72]

deine zwar gut gedachte Kombi aus

Y ...als "Disable(Auto)Adverise" fehlt, sonst kann man keine AdvertiseDaten setzen/ändern
N,12345566 ... klar das sollen deine Broadcast Daten sein
A ... EnableAdvertise

klappt so leider trozdem nicht, da der BroadCast(Beacon)-Mode des RN4020 vor Version 1.33 leider zu nix kompatibel ist!

Entweder du machst überall V1.23 drauf und nutzt den BLE Namen, oder mach das Update auf V1.33 und lies dir von Microchip die ReleaseInfo durch, das steht recht gut beschieben wie du echt binär mit Kennung deine Zusatzdaten für das normale Advertise definieren kannst. ("N" ist was für ala "BeaconMode"... wir verwenden es nicht, weil nicht kompatibel zum BLE-Standard.Scan unter Android&IOS)