FMX BLE Problem mit automatischem Reconnect nach Verbindungsunterbrechung

[Rollo62]

Ja solche "Hänger" kenne ich zur Genüge, auch dass bei Disconnect mal Exceptions geworfen werden können,
vermutlich weil bei Disconnect nicht immer alle Characteristics sauber unsubscribed werden können.

Dass sich BLE automatische wiederverbindet ist teilweise wohl in den Phones implementiert, und ist eigentlich ein Feature, wenn man die Verbindung nicht explizit beendest bleibt sie wohl bestehen.

Um die "Hänger" abzufangen habe ich die relevanten TBluetoothLE Komponenten hart mit .Free entsorgt, und neu created.
Das funktioniert aber auch nicht immer so sauber.
Ich mache aber immer noch Grundsatz-Versuche wie man das sicherer hinbekommen kann, so dass es einfach läuft wie erwartet.

[Rapunzel]

Danke für Dein Feedback.

Ich bin an sich sehr zufrieden mit der BLE Implementierung sowohl unter Windows als auch Android. Mein automatischer Verbindungsaufbau läuft reibenungslos über eine State machine von Scan bis zu Austausch mehrere grundlegender Commands vollautomatisch und fehlerfrei. Laufe ich in einem Timeout, was extremst selten vorkommt, wird die state machine zurückgesetzt und bleibt niemals hängen. Nur diese kurzzeitigen Unterbrechungen will ich noch in den Griff bekommen.

Funktionieren Free und Create denn ohne Exception im WinRT Unterbau, wenn diese halbgare Verbindung besteht? Kann ich das direkt hintereinander aufrufen oder sollte ich besser ein Delay einhalten?

[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.