BluetoothLE Verhalten bei Wiederverbinden

[Rollo62]

Hallo Mensch72,

du hast ja Recht:

Im Moment iOS 8.1 bis 8.3,
RadStudio XE8 Pro (mit und ohne Upd1)
Getestet auf iPhone 4, 5S, 6.

Unter Android bisher nur unter Sansung Galaxy 5, mit akt. Version, aber da läuft es auch.
Scheint ein Problem unter iOS zu haben.

Ich habe als Basis das Emba HeartRateMonitor Beispiel benutzt, welches auch erstmal gut lief.
Aber ich hatte nur unter Android und auf dem MacBook getestet.

Ich bin gerade dabei die RadXE8 Subscription zu besorgen, in der Hoffnung das ein grosses Upd1
auch hier Verbesserungen bringt.
Ich hatte nur die Recharge-Version, bin aber davon ausgegangen das es 1:1 das Gleiche ist.

Wen ich damit nicht weiter komme werde ich nochmal ein abgespecktes Demo machen:
- aber ich benutze die OnEndDiscoveryDevices, OnEnd--Services, etc.
- die einzelnen States habe ich entweder durch Tastendruck, oder durch Timer getrennt, mit mind. 0.5 Sec. dely
- mehrere CancelServices hatte ich noch nicht probiert, ist eine gute Idee, werde ich aber mal machen.

Hast du einen Event falls sich das BT-Gerät abschaltet (AutoShutOff) ?
Das passiert namlich, und ich bekomme das so nicht mit.
Ich habe versucht über regelmäßige ReadRSSI herauszufinden wann das Gerät weg ist, aber das ist auch
nur suboptimal.

Am Besten wäre es ein OnConnectionLost Event, den es aber leider nicht gibt.


Rollo




Rollo

[mensch72]

"Am Besten wäre es ein OnConnectionLost Event"...

Viele Charakteristics können ja abonniert werden... also einfach nach DiscoverServices ein EnableNotifycation aufrufen.
- da kommt dann sofort per Event der aktuelle Wert, und dann zyklisch eine Aktualisierung
- also einfach die Empfangszeit merken und beim nächsten Event die Zeitdifferenz mal "2,2" als TimeOut nehmen und bei jedem Empfang so weiterführen
- so kann einmal eine Aktualisierung verloren gehen ohne das ein gleich der TimeOut kommt
- wenn TimeOut erreicht, hast du dein "OnConnectionLost Event", weil sich das BLE Device dann 2x nicht regelmäßig gemeldet hat
- RSSI Polling ist aus meiner Sicht ungünstig, weil dies je nach BLE Gerät sogar ein Connect/Reconnect auslöst, ohne das alle Delphilisten dann intern aktuell sind
- PushNotify Events mit bekannter Wiederholrate und TimeOut-Faktor 1,1(kein Ausfall erlaubt) oder 2,2(ein Ausfall erlaubt) sind die eleganteste und BLE seitig stromsparendste Lösung

[Rollo62]

Hallo mensch72,

danke für die Hinweise.

Events für EnableNotification würde ich gerne setzten, finde aber keine.

Nur zur Klarstellung:
Ich lese Rssi nicht vom IOS-Device, sonder vom lokalen Host-Stack.
Das sollte eigentlich eine Variable sein die sofort, ohne Transfter over-the-air, auslesbar sein sollte
weil das nur vom eingebauten BT-Chip kommt.

Deshalb havbe ich Polling für Rssi eingebaut über 3sec. Timer:

Code:

if not DeviceCurrent.ReadRemoteRSSI then // Obtain RSSI
begin ...

procedure TS4BleConnectDm.BluetoothLE1ReadRSSI(const Sender: TObject; ARssiValue: Integer; AGattStatus: TBluetoothGattStatus);
begin ...

Es hat für mich auch noch einen anderen Grund:
- Ich habe eine Service Notification beim Gerät registriert, und dieses sendet nur ab und zu wenn der Nutzer eine
Taste drückt, durch das Polling glaube ich das Timing besser Steuerun zu können.
D.h. wenn User eine datenpaket sendet spar ich mir einen Rssi Zyklus (denn beides ist mein KeepAlive Signal).


Wenn du weisst wie man den Rssi-Wert als Event oder Notification ausliest dann hilf mir bitte auf die Sprünge.

Ich habe schon einiges durchgesehen, finde aber nichts.
Jetzt will ich nochmal schauen wie die Beacons das machen, denn das ist ja eigentlich das Gleiche Problem.
Es gibt die neue RssiToDistance Funktion bei den Beacons, aber wie die an den RssiWert kommen muss ich noch checken.

Ich habe hier etwas von David I gefunden, siehe Bild im Anhanghttp://de.slideshare.net/embarcadero...llsprintdavidi

Heisst das das mit LastDiscoveredDevice geprüft werden kann ob ein Gerät noch am Leben ist ?



Rollo