Android - BlueTooth LE Advertise Broadcast Bytes empfangen

[Rollo62]

Hallo Jürgen,

sorry das wir etwas von deinem Thema abweichen, ich gelobe Besserung.
Dachte du wartest noch auf dein neues Board zum Testen.
Ich hoffe damit kriegst du es dann gelöst.

Dein PCB sieht ja ganz gut aus, so wie die Antennenflächen übereinanderliegen sollte es
gut funktionieren.

Rollo

[OrtmannMedia]

Hallo Rollo, mensch72,
ja das passt schon, mich interessiert das Rand-Thema auch sehr Ja, muss noch auf das neue PCB warten.
Aber ich habe ja noch das DemoBoard. Zumindest das was ich eigentlich wissen wollte könnte ich damit auch
ausprobieren.
Hättet Ihr für mich so ein Mini-Setup für den RN4020, mit dem ich so einen Service starte?
Im Moment ist das Problem, dass ich eigentlich zwei Unbekannte habe, 1. ein nützliches Setup für den RN4020,
2. eben Delphi-Code mit dem ich das dann sehen kann.
Also vielleicht sowas mit
128BitGUID PrivateService advertisen. Egal welche payload nur
damit ich was habe womit ich dann Delphi-seitig weiterkomme,
das dann zu sehen.
Dann denke ich komme ich schon mal weiter.
Wie ich lese, war es wohl unter XE8 Problematisch,
und unter Berlin dann gut. Ist noch spannend jetzt für mich,
ob Seattle auch schon Ok war...

[mensch72]

Hast ne PN bezgl der "Setups"

[OrtmannMedia]

Hallo,
bekomme DiscoverServices nicht vernünftig zum Laufen.

Habe mein Board nun endlich wieder bereit. Mit RN4871 allerdings.
Und habe nun auch selbst geschafft diesen mit
1. Alternate Beacon (einige Bytes payload im Major/Minor part) oder
2. Private Service mit Characteristic read/write u. 128bit UUID aufzusetzen.
(der beacon läuft dann bei mir nicht gleichzeitig).
3. Device Info Service aufsetzen.
Und mache jetzt mit Tokyo rum.
Beacon kann ich mit Delphi Android app auch empfangen u. auswerten.

Den private Service kann ich mit einem zweiten RN4871 problemlos
connecten u. bonden und Daten bidirectional austauschen. Auch mit notification.

Leider - mit der Delphi App (Android 6.0.1) klappt das speziell das Listen der Services nur gelegentlich.
Und zwar habe ich eine BluetoothLE compo.
Starte DiscoverDevices. Alle meine RN4871 werden immer aufgelistet.

Mit einem Device starte ich dann DiscoverServices.
Und das klappt nur ca. jedes 10. mal dass die Services aufgezeigt werden.
Meist wird keiner gefunden. (Wenn doch, dann bekomme ich auch alle Characteristics problemlos aufgelistet).
Komisch auch, wenn ich DiscoverServices gleich nochmal starte, dann kommt
OnDiscoverServicesEnd sehr schnell/sofort. Scheint garnicht nochmal zu suchen.
Nimmt wohl was aus nem cache?

Klappt das Auflisten der Services bei Euch mit dem RN4020 oder 4871?
Was müsste ich ggf. beachten?

Wann muss ich eigentlich connecten?
Sollte ich schon bevor DiscoverServices, vielleicht? Oder erst wenn ich die Chars lesen will?

Viele Grüße, Jürgen

[Rollo62]

Hallo Jürgen,

damit kämpfe ich auch schon seit Wochen.
Es lief anfangs Alles super, aber ich habe mittlerwiele 12 ganz verschiedene Geräte unter einen Hut gebracht und sehe das es ziemliche Unterschiede im Verhalten gibt.

Insbesondere habe ich ein lokales Problem, es funktioniert in der Entwicklung ganz gut, gehe ich aber raus zum Kunden fliegen die Connections raus, oder er findet keine Connection.
Die Services auch manchmal ja, manchmal nein.

Ich habe mir extra ein paar Tests geschrieben, und ich vermute stark das es auch Funk-Störungen bei bestimmten WLan Konfigurationen gibt.
Ich kann mit der gleichen Konfiguration verbinden und den ganzen Tag verbunden bleben, bin ich
aber in anderer Umgebung dann fliegt die Verbindung alle 5 Sekunden raus.

Beides unter And/iOS dasselbe.
Nach etas Recherche gab es auch Hinweise dazu das soetwas mal unter Android 4.4.3 als Kinderkrankheit gab, aber ich denke das wird es nicht mehr sein.

Das Service-UUID Filtern funktioniert bei mir auch nicht gut, deshalb muss ich manuell filtern.
Weil die Steuerung vom Phone kommt liefert die bei Advertisen mal 7 mal 5 mal keins zurück, und das scheint normal zu sein.
Ausserdem ist das Verbinden und Verviceabfragen mal in 300ms, mal in 3 Sek., mal 6 Sek. mal gar nicht möglich.

Ich gehe mittlerweile davon aus das es nicht so wie zu Anfang war:
einmal verbunden, immer verbunden,
sondern das man BLE Verbindungen immer als etwas Temporäres ansehen muss.
Ich baue im Moment die Library um, so das ich notfalls schnell wiederverbinde in der Hoffnung das es schnell genug geht.

Ausserdem schenit es mit Threading Problemen zusammenzuhängen, denn die Fehler fangen an sobalb man an die Services geht, das Advertising ist noch OK.
Die Umstellung auf Rx10.2 hat ja das Threading komplett auf den Kopf gestellt, und ich Teste im Moment noch und versuche das Beste rauszuholen.
Auf iOS 10 habe ich mich noch nicht getraut upzudaten, denn im Moment geht es zumindest wieder einigermassen.

Ich habe auch so ein bischen das Gefühl das es mal geht und mal nicht.
Komme ich Abends gar nicht mehr klar und nichts wird sauber verbunden, dann kann es am nächsten Morgen schon wieder perfekt weiterlaufen.
Ganz so als würde sich das Phone irgendwelche Stati merken.

Edit:
Auch die Verbindung mit den Notify Characteristics läuft nicht immer sauber, und es muss wiederverbunden werden.

Ein DiscoverTimeout habe ich von 3500ms bis zu 15000ms probiert, das scheint aber relativ egal zu sein.

Es ist schon sehr nervig, und wenn ich andere Lösungen teste dann sehe ich das es auch zuverlässiger geht.
Sollte da evtl. doch etwas mit dem Delphi BT Stack nicht in Ordnung sein ?

Ich mache es in der Reihenfolge:
- DiscoverDevices
- DiscoverServices (ich denke vor dem DiscoverServices wird es automatisch connected)
- DiscoverChars
- ReadRemoteRSSI als final Test das jetzt Alles stabil ist.

Rollo

[OrtmannMedia]

Hallo Rollo,
danke für die Info.
Dann ist die instabile Verbindung nicht nur bei mir.
Das hilft mir schon mal.
Hatte gedacht, ich mache alles falsch, weil Mensch vor einigen Seiten ja geschrieben
hat, dass das mit den Services bei ihm out-of-the-box funktioniert. Das dürfte dann wohl
so nicht ganz exakt der Fall sein.

Und wie ich Dich verstehe, ists bei anderen BT Modulen auch nicht besser.
Dann bleibe ich wohl bei dem RN4871.
Welches hast Du eigentlich?

Dann werde ich mal auch so Loops verschachteln, die nach Bedarf mehrmals scannen und re-connecten usw.
Dürfte wohl eine etwas hackelige Kommunikation werden dann.
Aber ich muss eigentlich eh nur hauptsächlich so Config Daten übertragen/lesen, also recht wenig.
Guid werde ich auch manuell filtern.
Werde auch noch experimentieren mit Standort.
Also, ich fürchte ansich ists wieder ein Delphi Problem.

Jedenfalls, ist es nicht normal, dass DiscoverServices bei jedem zweiten Versuch
sofort zurückkommt ohne gescannt zu haben.
Ist das bei Dir auch der Fall, und loopst einfach so lange drüber, bis es klappt?

Viele Grüße

[Rollo62]

Hallo Jürgen,

ja ich mache DiscoverServices solange bis ich etwas gefunden habe, in einer Zeitgesteuerten Schleife alle 5 Sec..
Hier gehr auch nur jedes 2te Mal, meistens aber auch beim ersten Mal.
Hängt halt irgendwie davon ab was das Phone dir gerade zurückschickt.
Woran das genau liegt kann ich nicht sagen, aber iPHone und Android tun sich hier nichts.

Vielleicht liegt es ja auch einfach am BLE Standard, wo die Geräte mit mehr oder weniger großen Zyklen
sich synchronisieren müssen.
Ist klar das 20ms Advertising besser/schneller läuft als 400ms.

Alles das ist akzeptabel, was aber enorm nervt ist das Verlieren verbundener Geräte, das habe ich teilweise auch.
Ich habe so gewisse Orte wo das Verbinden extrem schlecht funktioniert.
Bei mir im Büro (auch 2-3 Wifi Netzwerke, >= 7 aktive WiFi Geräte, bis zu 12 BLE Geräte verschiedener Kategorie und Hersteller), da klappt Alles perfekt.

Sobald ich zum Kunden damit fahre funktioniert die Verbindung nicht zuverlässig.
Das ist sehr blöd, weil wenn ich den Grund wüsste was passiert könnte ich das debuggen,
aber so ist es ein Try and Error.

Ich benutze hier TI Module und Cypress Pioneer Kit zum Basteln, aber die Geräte die ich
einbaue kommen aus China und enthalten mehr oder weniger unbekannte Module.
Oft aber nicht immer von den üblichen Herstellern TI, Nordic, aber mir ist jetzt auch ein exotischer Dialog Semiconductor untergekommen.
Ich vermute mal die Lösungen aus China basieren meistens auf den Referenzdesigns der Hersteller, die kopieren halt erstmal, deshalb funktioniert es auch meistens erwartungsgemäß.
Ich benutze aber bisher keine GATT Services, weil zu Speziell.
Sondern nur notifications mit WriteNoResponse als quasi RS232 Ersatz-Schnittstelle, das funktioniert ganz gut.

Die Probleme mit FMX liegen bei mir
- in der nicht so stabilen Auswertung
- in der anscheinend blockierenden Service/Char Auslesung (konnte in der Vergangenheit 1-2 Sek. MainUI hängen lassen)
(das ist durch 10.2 womöglich besser wg. geändertem Thread System, das checke ich gerade)
- in der nicht stabilen Verbindung (so habe ich das noch bei keinem Testsystem gefunden, und auch andere Analyser scheinen sicherer zu arbeiten)
- entweder das sind das Alles FMX Probleme, oder auch Android/iOS Entwickler müssten dieselben Schwierigkeiten haben


Rollo

[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