Android - BlueTooth LE Advertise Broadcast Bytes empfangen

[OrtmannMedia]

Hallo Rollo,
auch danke für diese Info.
Inzwischen habe ich das recht brauchbar hinbekommen.
Nach recht langen Versuchen, dann auch ähnliche Sequenz wie von Dir.
Ja, scheint das DiscoverServices macht nen connect, wenn erforderlich.
Allerdings verhält sich DiscoverServices (bei mir) unterschiedlich stabil,
jenachdem wieviel Chars ich eingerichtet habe. Habe nun nach langen Versuchsreichen
beschlossen, immer Connect konkret zu verwensen, und dann erst nach Erfolg DiscoverServices.

DiscoverDevices selbst klappt sehr rasch.
Connect dagegen eben nur gelegentlich, das hab ich in eine Loop gepackt.
Muss man halt leider warten bis es verbindet.
Leider gibt Connect immer True zurück, auch wenn es nicht geklappt hat.
Ich verwende dann bei jedem Versuch IsConnected (statt die RSSI abzufragen), um zu
sehen ob die Verbinung tatsächlich geklappt hat. Das funktioniert zuverlässig.
Auch in meinem RN4871 Modul kommt dann gleichzeitig das Connect,
sobald es geklappt hat.
Ich habe 1 Private Service mit 2 Private Characteristics eingerichtet,
diese kann ich dann problemlos abfragen. Ich filtere die Suche dabei
"manuell" nach 128bit UUID.
Jedoch gibt es Probleme, wenn ich z.B. 4 oder mehr Characteristics einrichte.
Bei 4 klappt es gelegentlich nicht, und die Sucher dauert deutlich länger, bei 6 garnicht mehr.
Bei 2 jedoch immer, bisher absolut zuverlässig, und auch ohne merkliche Suchzeit.
Also mache ich nur mit 2 Chars, mit je 20 Octets Daten.
Das passt eh gut. Eine nehme ich zum Senden an das RN4871, das andere
habe ich als Notification eingerichtet und darüber sendet das RN an meine App.
Somit habe ich bidirektionale Schnittstelle. Ist ja fast wie eine RS232/UART jetzt bei mir.
Wenn was nicht mehr klappt (connection verloren, IsConnect false),
gehe ich zurück, dann fängt es wieder an zu connecten usw.
und holt das nach, was nicht erledigt wurde.
Das gibt dann zwar eine Pause, aber irgendwann werden die Daten dann übertragen.
Und dann halt noch ein Timeout (zähler) insgesamt, wenn es halt wirklich nicht mehr geht.
Somit, denke ich ists zumindest ne Komplett-Lösung.
Nun muss ich mich noch mit Threads und so beschäftigen, damit das auch
nicht nur "so" bei mir zuhause klappt, sondern wirklich zuverlässig. Da werde ich sicher
noch andere Fragen posten hier... Aber so prinzipiell habe ich es hinbekommen.
Vielen Dank

[Rollo62]

Hallo Jürgen,

bringt das Connect bevor DiscoverServices denn etwas ?
Es hört sich so an als wäre es auch so unzuverlässig wie das zweite.

Ich glaube jedenfalls das die unterschiedlichen Stabilitäten wohl im Wesentlichen von den AdvertiseZyklen abhängen, das würde ja Sinn machem.
Also Teile die mit 20ms feuern sind schnell erkannt, die mit 400ms soso, die mir 2000ms da kann man sich auf eine 2te oder 3te Runde einstellen.

Ich würde deshalb in der heissen Phase versuchen oft zu feuern, und ein intelligentes Device kann die Rate dann runternehmen wenn keine Connection kommt.

Ich habe übrigens ein guter Tool für Android gefunden Bluetooth LE Analyser von Bertrand Martel, das ein bischen die Advertisingzyklen darstellen kann.
Gibts in Playstore und auch in Github.
Vielleicht hilft es dir ja auch beim Debuggen.

Rollo

[OrtmannMedia]

Hallo Rollo,
Connect vor DiscoverServices ist letztlich nicht zuverlässiger als direkt DiscoverServices.
Nur konnte ich so unterscheiden, ob ein Erfolg vom Connect oder vom DiscoverServices abhing.
Mit Connect im Loop, und dann erst DiscoverServices dauert es nicht länger und würde ich daher empfehlen.
DiscoverServices geht dann, wenn man connected hat sehr schnell. (jedenfalls bei 1 Service, 2 Chars).
Ja, ohne das messtechnisch zu wissen, habe ich auch genau das gefühl, dass es eine Timing-Sache
von den Advertice Bursts vom Modul ist.
Da es jetzt zumindest mit loops auch wenigstens prinzipiell geht, habe ich bei meinem Projekt nicht mehr so viel Stress. Da eine schnelle Verbindung bei meinem Projekt schön wäre, aber nicht wichtig.
Aber ich möchte mich auch noch später mit den Timing Settings vom RN4871 beschäftigen, vielleicht kann ich
da was einstellen. Ich glaube da ist was.
Bei hunderten von Versuchen habe ich bei Connect alles zwischen beim 1. und beim 15. mal gehabt.
Meist ist es so bei 3 ... 6. mal erledigt. Jede Runde dauert 3.5 Sekunden...
Noch eine interessante Beobachtung - wenn es mal connected war und ich disconnecte, oder
gehe so weit weg, bis es disconnected und connecte dann wieder innerhalb kurzer Zeit, vielleicht 5 Sekunden,
dann connectet es fast immer sofort. Da ist ein Unterschied.
Auch, wenn ich die App dann schnell beende und wieder starte, dann schnell connecte,
dann connectet es meist sofort.
Also irgendwas ist da noch, was das ausmacht...? Zu dem Effekt habe ich noch keine Idee.
Viele Grüße
Jürgen

[Rollo62]

Hallo Jürgen,

Zitat:

wenn es mal connected war und ich disconnecte, oder
gehe so weit weg, bis es disconnected und connecte dann wieder innerhalb kurzer Zeit, v

Ja das sehe ich bei mir auch.
Ich denke dass das Phone die Settings speichert, umn schneller zu re-connecten.
Habe gesucht aber nicht allzuviel dazu gefunden, ich denke das ist Teil des Standards weil sich Android iOS da ähnlich verhalten.
Das würde auch Sinn machen, denn Funk kann öfters mal wegfallen, und wenn das Phone das dann automatisch
wieder einfangen kann wäre das von Vorteil.
Leider ist das bei mir auch nicht sehr vorhersehbar, insbesondere bei verschiedenen Module-Typen.
Beim RN4871 solltst du bestimmt die Advertisingrate einstellen können, leider habe ich viel mit Noname aus
Asien zu tun, wo man wenig bis keinen Einfluss drauf hat.
Da muss man nehmen was kommt.

Die Verbindung geht bei mir mittlerweile beim ersten, und nur bei manchen Geräten beim 2ten Versuch.
Ich glaube ich habe im Moment 4500ms - 5500ms Discovertime eingestellt.
Mit RSSI-Filter wollte ich auch schon arbeiten, habe aber festgestellt das die ScanFilter nicht zuverlässig arbeiten. Das geht bei manchen Geräten, aber es sind eben welche dabei die sich nicht nach Service filtern lassen.
Also kann ich die Filter nicht mehr benutzen.
Das ScanFilter nach ServiceUUID hatte sehr viel Stabilität reingebracht, deshalb hoffe ich immer noch das ich
da eine Lösung finde, so das alle anderen "Störsender" gar nicht mehr berücksichtigt werden.
So ähnlich wollte ich auch RSSI-Filter machen, habe aber gesehen das es so als Vorfilter gar nicht vorgesehen ist.
Also muss ich das filtern selber machen, im OnDiscoverDevice Event, was aber nicht so gut ist als wenn ich dem
StartDiscoverDevices schon einen Filter mitgebe.

Das Thema Disconnect/Reconnect war bei mir auch lange auf der Agenda: Verbinden OK, aber gezieltes Disconnect machte Probleme. Ich hatte da schon überall mal nachgesehen und nachgefragt, aber eine klar definierte Vorgehensweise gibt es da anscheinend nicht.
Auch Jim McKeeth hat da bei seinen Testgeräten nur Wert auf Verbindung gelegt, aber es wird nie berücksichtigt das man auch mal disconnecten möchte und sich woanders verbinden.
Naja, ich habe da jetzt halbwegs etwas zuverlässiges hingefrickelt, eine Mischung aus RSSI-Überwachung, OnDisconnect, KeepAlive-Signal und Reset aller möglichen BLE-Adapter und Manager.

Was ich schon gesehen habe ist das in machen Umgebungen eine ansonsten sehr stabile Verbindung ständig abbricht,
auch das ist vermutlich Teil der BLE-Standards, das soetwas immer passieren kann.
Ich bin bis dato aber davon ausgegangen das "connected" vom Phone auch möglichst gehalten wird, ala TCP,
und notfalls automatisch wiederverbunden wird, s.o., solange es in Reichweite ist.
Das wird aber anscheinend auch nicht garantiert, jede kurze Unterbrechung muss ich selbst wiederverbinden.

Ich hoffe immer das von Version zu Version mal seitens Emba dran gearbeitet wird, aber ich sehe das eingentlich kaum an den BLE Kernels gearbeitet wird.
Vielleicht ist es ja auch gut so, denn im Moment fixe ich gerade die Änderungen seit 10.2 in anderen Bereichen.
Besonders blöd ist wenn eine laufende App nach einem Update plötzlich nicht mehr sauber läuft, das kommt seit XE8 leider immer wieder vor, aber die Tendenz ist zumindest das Fmx regelmäßig stabiler wird.

Rollo