Vor einiger Zeit haben wir einen Blogbeitrag über die Überwachung des Motorbetriebs mit RuuviTags veröffentlicht. Die damals entwickelte Firmware hatte das Ziel, Rohdaten vom überwachten Objekt für weitere Analysen zu sammeln. Während die Firmware für die Datenerfassung gut funktioniert, verbraucht sie viel Strom und erfordert manuelle Arbeit bei der Datenverarbeitung.
In diesem Beitrag entwickeln wir das Konzept ein Stück weiter, verarbeiten die Daten direkt auf dem RuuviTag und senden den Spitze-Spitze-Wert, den Effektivwert (RMS) sowie die Standardabweichung der Daten.
Sammeln der Daten
Die Datenerfassung ist eine einfache Fortsetzung des vorherigen Teils: Wir sammeln Daten mit 400 Hz und warten, bis der First-In-First-Out-Interrupt (FIFO) vom Beschleunigungssensor LIS2DH12 kommt. Dann lesen wir die FIFO-Daten aus und berechnen den Spitze-Spitze-Wert (P2P), den Effektivwert (RMS) und die Standardabweichung (STDEV) der Daten.
Die berechneten Werte werden dann als UINT16_T in ein herstellerspezifisches Datenformat kodiert, das als Bluetooth Low-Energy (BLE) Advertisement gesendet wird. Jedes BLE-Gerät in der Nähe kann diese Sendungen empfangen und parsen. Wir beginnen das Paket mit einem Header-Byte 0xAC, einem Versions-Byte 0x00 und übertragen dann die X-Y-Z-Werte von P2P, RMS und STDEV. Schließlich fügen wir einen Sequenzzähler hinzu, mit dem fehlende Pakete erkannt werden können, sowie die Batteriespannung, um uns zu warnen, wenn es Zeit für einen Batteriewechsel ist.
Empfangen der Daten
Die Daten werden mit dem TypeScript / NodeJS Collector geparst, der für den Batterie-Ausdauertest erstellt wurde, und der Code läuft auf einem Raspberry Pi. Du findest die Quellen auf GitHub. Bitte beachte, dass die Noble-Bibliothek seit Januar 2019 Probleme mit NodeJS 10+ hat. Du kannst den Code mit NodeJS 8 unter NVM ausführen. Die geparsten Daten werden dann an InfluxDB gesendet und mit Grafana visualisiert.
Stromverbrauch
Wieder einmal müssen wir den Stromverbrauch des Tags berücksichtigen. Es reicht nicht aus, dass der Tag wie erwartet funktioniert; er muss auch lange durchhalten.
Der Stromverbrauch ist momentan viel zu hoch; bei 300 µA können wir mit einer Batterielaufzeit von etwa 4 Monaten rechnen. Das ist offensichtlich nicht genug, also schauen wir mal, was wir dagegen tun können.
Optimierung der Firmware
Im Moment sendet der Sensor die Daten so schnell, wie es die BLE-Spezifikationen erlauben, unabhängig davon, ob es etwas Interessantes gibt. Der erste Optimierungsschritt besteht darin, das Aktivitätsniveau zu überwachen und in einen Standby-Modus zu wechseln, wenn nichts Relevantes passiert. Unser Standby-Modus hat ein Sendeintervall von 9.900 ms und eine Abtastrate des Beschleunigungssensors von 10 Hz.
Wenn während des Standbys ein Beschleunigungsereignis eintritt, das den vordefinierten Schwellenwert überschreitet, wird ein Interrupt ausgelöst und der Sensor schaltet zurück in den 400-Hz-Modus. Wir haben den Schwellenwert für den Interrupt auf 50 mg festgelegt, was aufgrund der Sensorgrenzen auf 64 mg aufgerundet wird.
Zusätzlich kombinieren wir 4 Sätze von FIFO-Ergebnissen in einer Berechnung, wodurch wir die Sende-Rate auf 400/128 Hz oder etwa 320 ms reduzieren können.
Jetzt sollte unsere Firmware für den langfristigen Einsatz bereit sein, aber wir werden das natürlich noch überprüfen.
Der Standby-Stromverbrauch deutet darauf hin, dass wir eine Standby-Zeit von zehn Jahren erreichen könnten – das ist definitiv genug. Allerdings würden die 200 µA Stromverbrauch im aktiven Zustand die Batterie in etwa sechs Monaten leeren. Das ist völlig okay für ein Haushaltsgerät, das nur gelegentlich eingeschaltet ist, wie zum Beispiel eine Waschmaschine. Ein Kühlschrank, bei dem der Kompressor ständig anspringt, erfordert möglicherweise mehr Feinabstimmung, zum Beispiel indem nur ein Probensatz für alle 10 Sekunden Aktivität genommen wird. Andererseits könnte ein anderes Gerät, wie eine CNC-Maschine (Computerized Numerical Control), von einer kontinuierlichen Überwachung profitieren. Die Anwendung kann für den jeweiligen Anwendungsfall weiter optimiert werden.
Ausprobieren
Wie zuvor nutzen wir eine Waschmaschine als zu überwachendes Haushaltsgerät. Ein doppelseitiges 3M VHB-Klebeband wird verwendet, um den Tag an der Seite der Waschmaschine zu befestigen.
Der Beschleunigungssensor ist intern so ausgerichtet, dass die X-Achse die axiale Beschleunigung und die Y-Achse die tangentiale Beschleunigung erfasst. Z ist „natürlicherweise“ die radiale Beschleunigung, da die Z-Achse zum Zentrum der Trommel hin ausgerichtet ist. Dann starten wir einen Waschgang und warten auf die Ergebnisse.
Zufälligerweise gab es bei unserem Durchlauf eine Anomalie. Ein Bügelbrett fiel gegen die Waschmaschine, während ich gerade ein Foto vom Aufbau machte.
Die durch das Bügelbrett verursachte Beschleunigungsspitze ist leicht zu erkennen.
Fazit
Wir haben nun eine einfache Firmware zur Vibrationsüberwachung fertig für erste Praxistests. Wenn du sie ausprobieren möchtest, findest du die Quellen und die kompilierte Binärdatei auf GitHub. Wie bisher stellen wir kein fertiges DFU-Paket zur Verfügung, da die Firmware Nordic SDK15 und SoftDevice 6 verwendet, während RuuviTags SoftDevice 3 nutzen. RuuviTags können zwar „over-the-air“ aktualisiert werden, aber eine Rückkehr zur ursprünglichen Programmierung ist ohne kabelgebundene Verbindung nicht möglich.