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