Wann immer neue Funktionen entwickelt werden, besteht die Möglichkeit, dass ein Teil der Energie „verschwendet“ oder suboptimal genutzt wird. Im Allgemeinen beginnt der Prozess der Energieoptimierung einer Anwendung mit dem Power Profiling, um zu identifizieren, welche Funktionen des Codes tatsächlich den meisten Strom verbrauchen.
Wir nehmen die RuuviTag Firmware-Version 2.1.0-alpha als Beispiel und arbeiten uns zur energieoptimierten Version 2.1.0-beta vor. Seit der RuuviTag FW v1 haben wir NFC, GATT-Profil, RTC und Beschleunigungssensor-Interrupts hinzugefügt. Zusätzlich wurde „unter der Haube“ viel Arbeit geleistet, um neue Funktionen für die Roadmap vorzubereiten. Mal sehen, wie der Stromverbrauch aussieht!
Auf den ersten Blick sehen wir, dass einiges „nicht stimmt“. Der durchschnittliche Verbrauch liegt bei fast 80 μA, was einer Steigerung von 166 % seit FW v1 entspricht. Dies würde sich auf vielleicht ein Jahr Batterielebensdauer belaufen, was unangenehm niedrig ist.
Als Erstes fällt uns das Übertragungsintervall auf. Die FW v2 startet im Raw-Modus und sollte mit 1 Hz senden, die Übertragungen erfolgen jedoch offensichtlich mit 2 Hz. Dies ist ein Überbleibsel aus dem URL-Modus, das beheben wir.
Wir haben 20 μA eingespart, indem wir einen Fehler beim Übertragungsintervall behoben haben, nicht schlecht. Es passiert jedoch etwas Seltsames im 1-Hz-Intervall. Aus irgendeinem Grund gibt es einen relativ langanhaltenden Anstieg des Stromverbrauchs. Sind es die Sensorablesungen? Oder dauert die Aktualisierung der übertragenen Daten vielleicht lange?
Eine Mikro-Optimierung, die ich vorgenommen habe, war der Betrieb des BME280 im „Normalmodus“, bei dem der Sensor die Messungen autonom etwa einmal pro Sekunde startet. Dadurch sparen wir wertvolle Mikrosekunden, die sonst für das manuelle Starten der Messungen verwendet würden. Etwas taucht auf:
Wir haben den Übeltäter für den langanhaltenden Stromverbrauch gefunden: Der BME280 macht etwas Dummes. Es stellte sich heraus, dass der Code nach den früheren Experimenten mit dem BME280 immer noch das 16-fache Oversampling aktiviert hatte. Nach dem Entfernen des Oversamplings und dem Belassen der unendlichen Impulsantwortfilterung erhalten wir stark verbesserte Verbrauchswerte:
Wir können die BME280-Messungen immer noch sehen, aber sie sind viel schneller, was bedeutet, dass der Stromverbrauch um 30 μA reduziert wird. Jetzt sind wir bei 28 μA, was der Leistung der RuuviTag FW v1 entspricht.
Nachdem wir unsere Anwendung erneut auf den Stromverbrauch profiliert haben, erhalten wir ein Tortendiagramm des Stromverbrauchs:
Den Stromverbrauch unter 10 μA zu bekommen, wäre „der heilige Gral“, da die Lebensdauer des Tags dann die Lagerfähigkeit der 1000-mAh-Batterie selbst erreichen könnte. Wir müssten jedoch einige Kompromisse eingehen, wie z. B. BME280 und LIS2DH12 seltener abzutasten und seltener zu werben. Auch der Grundverbrauch müsste optimiert werden.
Vorerst können wir den Basismodus der RuuviTag FW als einen guten Kompromiss zwischen Funktionen, Geschwindigkeit und Batterielebensdauer betrachten.