FMX BLE Problem mit automatischem Reconnect nach Verbindungsunterbrechung

[Rollo62]

Ich beschäftige mich mehr mit Android/iOS, aber wenn da was hakt kann ich "Resetten" mit etwas Delay.
Das hatte bis jetzt keinen negativen Einfluss auf das System.
Ich mache das generell so das ich DiscoverDevices starte, mit z.B. 3500ms Timeout, und lasse parallel einen
TimeoutTimer mitlaufen, der dann z.B. um 5000ms checked ob OnEndDiscoverDevices aufgerufen wurde.
Falls nicht, ist irgendwas falsch, und ich mache einen Reset.

[Rapunzel]

Ich danke Dir vielmals!

Free und Create funktionieren aktuell ohne Exception. Auf diese Idee wäre ich wohl nicht gekommen. CancelDiscovery habe ich vor dem Free noch aufrufen, wenn ich schon wieder einen Scan gestartet hatte. Nur DiscoverDevices möchte noch nicht automatisch wieder starten. Das werde ich noch Deinem Tipp folgend in meinen Timeout Timer auslagern. Das ist jetzt Fleißarbeit.

[Rapunzel]

Ich hätte nicht schreiben sollen, dass soweit alles reibungslos funktioniert. Inzwischen konnte ich eigene Phänomene bei der BLE Kommunikation identifizierten, deren Ursache ich nicht kenne und auch keine Lösung weiß.

Unter WIN64 ist die Kommunikation signifikant langsamer als wenn ich die App als WIN32 laufen lasse. Der Unterschied ist zuhause auf meinem Windows 10 Home besonders ausgeprägt. Ein Command, dessen Laufzeit normalerweise ca. 100ms beträgt, braucht unter WIN64 im Schnitt 300ms. Doch damit nicht genug friert die App beim Senden der Nachricht für mehrere 100ms komplett ein. Animationen werden nicht mehr gezeichnet, Labels nicht aktualisiert. Nachrichten, die auf einer Read Characteristik reinkommen, währenddessen nicht verarbeitet. Unter WIN32 läuft dagegen alles glatt. Unter Android ist die Kommunikation noch etwas schneller als bei WIN32. Ich vermute ein Problem auf Treiberebene.

Unter Android 64 werden manchmal Datenpakete meiner Firmware nicht zugestellt. Das ist mir beim Firmware Update mit über 1000 Datensätzen aufgefallen. Teilweise beobachtete ich 20 verlorene Pakete pro Update. Dann wiederum läuft das Update komplett fehlerfrei durch. Unter Android 32 funktioniert es viel viel besser. Zum Glück konnte ich den Fehler mit einem Timer und ReSend leicht in den Griff bekommen. ​Unter Windows gibt es dagegen kein Problem mit verloren Datenpaketen.

Firmware und Hardware waren bei meinen Tests immer gleich.

Schon komisch, habt hier ähnliche Erfahrungen bei BLE gesammelt?

[Rollo62]

Kann es sein dass Du die Daten im OnReadCharacteristics direkt verarbeitest ?
Diese kommen womöglich aus ständig wechselnden Kontexten und Threads, und müssen mit Vorsicht behandelt werden.
Ich lade die im OnReadCharacteristics nur in einen thread-sicheren RingBuffer, möglichst ohne viel Overhead,
und lese diesen dann regelmäßig in einem kontrolliertem Thread zur Verarbeitung der Daten wieder aus.

[Rapunzel]

Vielen Danke für Deinen Denkanstoß.

Ich betrachte in CharacteristicRead nur den Pakettyp und prüfe die Checksumme. Dann werden die Pakete je nach Typ in zwei verschiedene Bffer kopiert. Zum Benachrichtigen der App nutze ich den MessageManager. Bisher habe ich dazu z.B. folgenden Code verwendet:

Delphi-Quellcode:

    TThread.Queue(nil,procedure
        begin
          FMsgManager.SendMessage(Self,TBLEConnectionStatus.Create);
        end);

Das hatte beim Firmware Update zur Folge, wenn CharacteristicRead im Kontext des MainThread aufgerufen wurde und es richtig verstanden habe, dass das nächste Datenpaket direkt ohne Umweg aus CharacteristicRead gesendet wurde.

Das habe ich jetzt entkoppelt:

Delphi-Quellcode:

    TThread.ForceQueue(nil,procedure
        begin
          FMsgManager.SendMessage(Self,TBLEConnectionStatus.Create);
        end);

Und siehe da, es sind jetzt schon viele 1000 Datenpakete durch die Luft geflogen und ohne Fehler beantwortet worden.

[Rollo62]

Ja ForceQueue verleiht Flüüüügel (nicht immer, aber immer öfter)