Wir arbeiten gerade an einer Anwendung unter Linux (ua RasPi mit der neuesten Debian Jessie), die sich mit einem von uns entwickelten BLE-Gerät verbindet. Dieses Tool wurde aus Cherry-Picking-Dateien aus dem Bluez-Stapel (5.46) entwickelt und fügt eine Anwendungsschicht hinzu. Das alles funktioniert ganz gut, außer dass die Verbindung unglaublich langsam ist. Aus der Ausgabe unseres Tools geht hervor, dass eine Wagenladung von Nachrichten ausgetauscht werden muss, um GATT-Dienste und -Eigenschaften zu kommunizieren, wobei jede dieser Kosten ein Verbindungsintervall der Zeit kostet. Da es sich um ein Gerät mit niedriger Leistung handelt, möchten wir, dass das Verbindungsintervall relativ hoch ist und somit die hohe Verzögerung.Ändern des Verbindungsintervalls in einer Bluez-basierten GATT-orientierten Anwendung
Bei der Verbindung mit dem Android BLE-Scanner sehe ich (auf der Geräteseite), dass der BLE-Scanner das Verbindungsintervall auf einen niedrigen Wert einstellt, alle angeforderten Daten abruft und das Verbindungsintervall auf den ursprünglichen Wert zurücksetzt. Beachten Sie übrigens, dass weder der BLE-Scanner noch unsere von Bluez abgeleitete Anwendung die bevorzugten Verbindungsparameter berücksichtigt.
Jetzt möchte ich, dass unsere Anwendung dasselbe tut: Stellen Sie das Verbindungsintervall auf 8 ms, erhalten Sie alle Informationen über Merkmale und Dienste, und stellen Sie das Verbindungsintervall zurück. Im Bluez-Stack finde ich dafür sogar eine nette Funktion in der HCI-Ebene: hci_le_conn_update.
Jetzt aber die Herausforderung: Der Rest der Anwendung baut auf der GATT-Funktionalität auf und obwohl die BLE-Spezifikation eine Hierarchie zwischen diesen beiden definiert (mit einigen Layern dazwischen), scheinen sie im Code absolut unabhängig von jedem zu sein andere.
Die HCI-spezifische Funktion hci_le_conn_update enthält zwei Parameter: 'dd' (Dateideskriptor für Gerät) und 'handle' (ein Wert, der die Verbindung identifiziert). Das hcitool sagt mir, dass das erste Handle 64 ist, wenn ich eine Verbindung erstelle, also versuchte ich mit diesem Wert. Für 'dd' habe ich hci_dev_open verwendet, um einen Dateideskriptor für das Gerät zu erhalten. Das hat funktioniert. Irgendwie.
Wie bereits erwähnt, berücksichtigen die Min/Max-Werte nicht vollständig. Also, wenn ich es auf 6/10 setze, bekomme ich 11 und wenn ich es auf 6/50 setze, bekomme ich 60. Dies ist ein wenig zu unbestimmbar für meinen Geschmack, und ich würde eine Funktion bevorzugen, die direkt das Verbindungsintervall ändert einen Bereich zu geben, der sowieso meistens ignoriert wird. Auch die Tatsache, dass ich eine fest codierte magische Zahl 64 verwenden muss, gibt mir ein juckendes Gefühl. Ich kann das Verbindungsintervall auf der Seite des eingebetteten Geräts tatsächlich steuern, aber ich möchte das Steuerelement auf der Seite der Client-Anwendung.
Ziel ist es, das Verbindungsintervall in einer Bluez-GATT-basierten Anwendung zu aktualisieren. In gewissen Grenzen stört mich das nicht, wie ich dahin komme. Irgendwelche Vorschläge?
Es ist schon eine Weile her und es stellte sich heraus, dass wir das völlig falsch angegangen sind. Wir geben jetzt das Verbindungsintervall an, das zwischen 8-500ms liegt, und lassen den Client es herausfinden. Wir hatten Angst, das wäre sehr ineffizient, weil wir dachten, die MCU müsste mindestens einmal pro Verbindungsintervall wach sein. Es stellt sich heraus, dass dies nicht zutrifft (der BLE-Stack bietet Rückrufe für die Signalisierung an, wenn wir schlafen gehen können) und wenn der Client ein Verbindungsintervall von z.B. 49, dann sind wir immer noch gut (genug). –