Diskussion über designierte Messfrequenz

Bee Observer BOB Entwicklung
1

Guten Morgen,

ich habe gestern Abend an einen weiteren Imker Kollegen ein zweites System weitergegeben.
Sein erstes System hat er seit dem WS in Köln in Betrieb.

Auf der Basis seines Hinweises mache ich mir aktuell Gedanken um die Datenflut. ca. 1GB je Monat je Stock.
Wir sollten an dieser Stelle unbedingt einmal über die Messfrequenz sprechen … in meinen Augen sind 10sec. der Overkill.
Schon mit einer recht guten 60sec Regel würden wir das Datenvolumen auf 1/6 reduzieren …
Und dann in der Nacht vielleicht sogar alle 120 sec. …

1 Like
2

Hi @IngoP,
wir haben für das Datenvolumen eine ganz andere Abschätzung der Größenordnung. 1GB wäre in der Tat zu viel. Kannst du kurz beschreiben, wie du auf diesen Wert kommst? Wir rechnen im Moment mit ca 25MB pro Monat bei 10Sek.

Die Messfrequenz ist nur in der jetzigen Projektphase, der sogenannten Datenerhebungsphase, so hoch. Wir wollen im nächsten Entwicklungsschritt unbedingt die Messfrequenz und am liebsten auch die Anzahl der Sensoren verringern. Es gibt verschiedene Hypothesen, was hier sinnvoll sein könnte: 5 Minuten lang alle 10Sek messen und dann 25 Minunten komplett schlafen, nachts nur alle halbe Stunde messen, 24/7 alle 120Sek, die alle bis auf 2 Temperatursensoren loswerden…aber weil wir hier mit wissenschaftlichen Methoden rangehen wollen, haben wir uns entschieden, erstmal eine Datenflut zu erzeugen und diese auszuwerten, bevor wir anfangen zu optimieren.

Es könnte zum Beispiel sein, dass der von uns zu entwickelnde Algorithmus die Datenfrequenz in Zukunft dynamisch anpasst. Wenn die Auswertung der Daten mit geringer Frequenz beispielsweise auf eine Anomalie hinweist, es aber nicht eindeutig ist, was da grade los ist. Dann könnte man für ein paar Minuten genauer hinschauen, sozusagen. Diese Strategie lässt sich aber nur dann sinnvoll verfolgen, wenn man zur Entwicklung des Algorithmus entsprechende Daten hat.

3

Es kommt sehr darauf an, was wir übertragen. Dieser open-hive Datensatz mit nur CSV-Daten

Date/Time,Weight,Outside Temp,Outside Humid,Inside Temp,Inside Humid,H1 Temp,H2 Temp,H3 Temp,H4 Temp,H5 Temp,Voltage
2016/06/01 00:13:08,   1.909, 20.7, 76.7, 20.7, 77.8, 20.6, 20.8, 20.5, 20.6, 20.6, 4.22

hat ohne die Varriablenbezeichnung eine Größe von ca. 0.09 KB, bei 6 Messungen pro Minute haben wir 8640 Messungen pro Tag, reine Daten wären das ca. 23 MB.

Der Datensatz, den die hiveeyes-Software momentan überträgt ist mit 0.9 KB deutlich fetter:

hiveeyes/statista/hds/hive-1/data.json {"system.temperature": 22.17392, "temperature.28030f2509000057.onewire:0": 16.625, "scale.0.kg": 20.907, "system.wifi.rssi": -57, "system.wifi.country": "CN", "temperature.2890912409000025.onewire:0": 24.75, "system.time": 221239, "scale.0.offset": -2588598.0, "pressure.0x76.i2c:0": 1008.944, "temperature.2822f1240900005d.onewire:0": 20.6875, "system.wifi.channel": 11, "temperature.2879502409000075.onewire:0": 16.75, "system.memfree": 2107104, "scale.0.raw": -3126838.0, "system.voltage": 5.13, "temperature.28a1012409000048.onewire:0": 16.875, "temperature.0x76.i2c:0": 16.14393, "weight.0": 20.907, "scale.0.scale": -25745.0, "system.wifi.max_tx_power": 78, "system.wifi.bandwidth": 2, "system.uptime": 221239.3, "system.runtime": 10, "temperature.28eefa24090000cf.onewire:0": 17.4375, "humidity.0x76.i2c:0": 93.39642}

Das ist die 10-fache Menge von oben, hier aber mit den Varriablenbezeichungen und diversen System-Infos, die man ggf. auch weglassen kann. Wären ca. 225 MB im Monat.

Dazu kommt dann noch der Kommunikationsoverhead.

2 Likes
4

Die Datenmenge hatte ich vom Imkerkollegen genannt bekommen, der die Daten via GigaCube zur BoB App überträgt

5

Das hohe Datenvolumen am Gigacube kann man sicher auch durch das Abrechnungsintervall des Providers erklären.

Die Frage ist auch ob der Gigacube genauso rechnet wie der Provider.

Aber dort wird es denke ich bald Abhilfe geben (Stichwort Stromsparen).
Wenn mehrere Messungen gebündelt auf einmal übertragen werden wird sich auch das abgerechnete Datenvolumen drastisch verkleinern.

1 Like
6

Die Geschichte mit der Taktung bei der Abrechnung von Daten im Mobilfunknetz wird hier ganz gut erklärt

Was für einen Datentarif hat denn der Imkerollege bei Vodafone? Wenn wir dazu die vertragliche Taktung herausfinden kommen wir der Differenz vielleicht auf die Spur.

7

keine Ahnung.
Leider ist er hier nicht selber online. Die Parameter habe ich nicht alle abgefragt.

Ich versuche mal, wenn meine Beuten online sind, das Ganze über meinen CiscoAP messen zu lassen.

1 Like
8

2 posts were merged into an existing topic: Untersuchung und Verbesserung des Timings bei der Ansteuerung der DS18B20 Sensoren unter MicroPython

9

Neben der Datenmenge ist bei diesem Thema auch die mögliche minimale (!) Messfrequenz relevant. Bisher ist laut @caro und @tox eine Messfreqzenz von 10 Sekunden im Projekt vorgesehen.

Minimal mögliche Messfrequenz

Das hier sind Beispieldatensätze mit deaktiviertem deep sleep und einer Wartezeit von 10 Sekunden zwischen Ende Messung / Übertragung und erneuter Messung.

Timestamp,                  Gewi.,Spannung
2019-09-17T09:53:14.510316Z,0.011,4.152
2019-09-17T09:53:32.780887Z,0.012,4.152
2019-09-17T09:53:51.104433Z,0.012,4.152
2019-09-17T09:54:09.381210Z,0.013,4.152
2019-09-17T09:54:27.673770Z,0.012,4.152
2019-09-17T09:54:46.048883Z,0.012,4.152

Das ganze dauert ca. 19 Sekunden, d.h. wenn wir kontinuierlich messen wollen und das Warte-delay auf 0 Sekunden setzen könnten wir alle 9 Sekunden messen. Allerdings gibt es in diesem Modus Probleme und bei mir steigt das System nach ca. 4 Stunden aus.

Geringere Frequenz im deep sleep mode

Dagegen läuft das System im deep sleep-Modus stabil. Hier erfolgt systembedingt ein kompletter reboot nach einer deep sleep-Phase, was viel Zeit zum erneuten Hochfahren braucht und wir haben damit andere Intervalle:

2019-09-18T15:12:03.595625Z,0.003,4.074
2019-09-18T15:13:04.631589Z,0.003,4.074
2019-09-18T15:14:05.279757Z,0.002,4.068
2019-09-18T15:15:04.036381Z,0.001,4.068
2019-09-18T15:16:01.365069Z,0.003,4.074
2019-09-18T15:16:58.619722Z,0.002,4.068

Hier braucht das System ca. 60 Sekunden für einen Zyklus. Auch hier war eine Wartezeit von 10 Sekunden eingestellt, d.h. wir könnten hier maximal mit einer Frequenz von 50 Sekunden messen, die gewünschten 10 Sekunden erreichen wir damit nicht.

10

Bei der hiverize/FiPy-Software dauert das Auslesen der Sensoren gut 5 sec. Dann wartet man, bis Sekunde 10 erreicht ist. In dieser Wartezeit könnte man Stromsparmassnahmen testen.

11

Vielleicht wollen wir diese Probleme drüben bei Stabilität und längere Testzeiträume des Terkin-Datenloggers angehen?

1 Like
12

Könnte mir als jemandem, der nicht bei BOB involviert ist, einer von den BOB-Leuten mal erklären, was für einen Grund es eigentlich für dieses aberwitzig kleine Meßintervall von nur fünf bzw. zehn Sekunden gibt?

Das kommt einer Dauermessung gleich (die digitalen Sensoren lassen sich sich halt nur quasi-kontinuierlich auslesen), damit ist kein sleep für den FiPy drin und die Stromversorgungsprobleme für autarke Aufstellung, die ich hier lese, kommen daher.

In Anbetracht der Art der gemessenen Größen (eine bis mehrere Temperaturen + Gewicht, ggf. Luftdruck) und deren Änderungsgeschwindigkeit ist mir diese extreme Meßfrequenz komplett unplausibel.

Also warum nicht z.B. minütliche Messungen, und Übertragung/Aufzeichnung von 10-Minuten-Mittel / -max. und min.-Werten, sonden mit den fünf Sekunden quasi Dauermessung, was soll das besser machen als eine auch nur gering kleinere Meßfrequenz?

1 Like
13

Bei mir liegt das nur daran, dass ich an der Software entwickle und so schneller Fehler finden kann.
Später im Messbetrieb kann das Messintervall beliebig verändert werden.
Du hast Recht, in der Beute ändern sich die Werte nicht so schnell.

2 Likes
14

Hier drüben hatten wir auch was zum Thema:

15

Sehe ich ähnlich und habe mich auch schon mit @tox und @caro darüber unterhalten, ob es ggf. Modelle oder Formeln gibt, mit denen man aus Kennwerten zur Trägheit der Messfühler und Schwankungsbreite / Messungenauigkeit das höchstmögliche sinnvolle, d.h. pratisch bedeutsame Messintervall berechnen kann.

Als Beispiel: Wir haben bei den DS18B20 die wasserdichte Version genommen mit einer Edelstahlhülse und drinnen vermutlich einiges an Wärmeleitpaste. Selbst bei einem abrupten Wechsel von 0 °C zu 5 °C wird das physikalische System eine Zeit brauchen, um die Temperaturänderung an den eigentlichen elektronischen Sensor weiterzureichen. Aus der hohlen Hand heraus sage ich mal 30 Sekunden bis sich überhaupt was tut, und 3 Minuten bis das Maximum erreicht ist, dann haben wir auch noch eine Ungenauigkeit des Sensors, d.h. selbst wenn der Sensor 0,3 °C statt 0 °C misst ist das noch im “Unsicherheitsintervall” und könnte einfach eine Messungenauigkeit statt einer “echten” Temperaturänderung sein. Gerade Temperaturen sind mit der Menge an Brut, Honig, Bienen im Stock träge und werden sich nicht schnell ändern.

Bei der Waage ist es etwas anders, da sind Änderungen schneller möglich, aber selbst ein Schwarm braucht Zeit um den Bienenstock zu verlassen. Und auch hier ist die Frage, wenn ich 10 g Unterschied messe, sind das wirklich 10 g Gewichtsänderung oder die “natürliche” Schwankung des Messwerts im Bereich des Messfehlers?

Die Idee war ja, dass wir in einer ersten Phase bei BOB so viel Daten wie möglich sammeln, dann auswerten und auf Grundlage der gefundenen Muster entscheiden, welche Messintervalle wir später im Feld für eine Prognose wirklich brauchen. Daher kamen die aktuellen 10 Sekunden! Alles erst mal mitnehmen was geht an Daten und Dynamik, und dann nach der ersten Auswertung entscheiden, wie weit wir von den Datenquellen und dem Messintervall streichen können.

Eigelntlich war der Solarbetrieb ja erst in der zweiten BOB-Phase geplant. Wir können sicher deutlich mehr Bienenstände erschließen, wenn wir beim Messintervall deutlich runter gehen und damit die Stromsparoptionen der boards über deep sleep nutzen. Dabei müssten wir aber eher auf 5 oder 10 Minuten gehen, da der FiPy momentan noch ca. 20 Sekunden zum Hochfahren braucht (da sind die Arduinos mit Kompilat auf dem MC deutlich schneller!) mit code freezing (@Andreas ist da schon dran) könnte es im MicroPython-Universum aber auch schneller werden, mal schauen, wie nah wir dann an die Arduinos bei den boot-Zeiten ran kommen.

1 Like
16

Würde auch sagen, anfangs so viel Daten sammeln wie möglich. Wahrscheinlich läßt sich aus der Steilheit von den Temperaturkurven sicher mehr herleiten, als von den Temperaturen selbst. Auch kann es vorkommen, das einer der Sensoren mal bei einer Messung stumm bleibt und wir, damit alles erfasst wird, mit nahezu doppelter Rate messen sollten.

Das die Sensoren relativ träge sind und eine hohe thermische Masse haben. Finde ich gut. So wird eine einzelne durch Sonne oder Flug aufgeheizte Biene nicht registriert, wenn sie es sich auf dem kühlenden Metall des Sensors gemütlich macht.

17

Bei einem Test mit der BOB-Software und LTE M1 via 1nce-Karte sind wir auf ca. 100 MB pro Tag gekommen! Siehe: Anpassungen BOB-Software zur Nutzung von LTE (CAT M1)

18

Das ist ja schon heftig viel im Monat für nur eine einzel Waage. Messezyklus 30sec? Und sicherlich auch alle Messdaten wie Rohdaten und Systemressourcen usw. Würde zum BOB Server parallel auch übermittelt?

Sollten für den Betrieb sicher über einen Mapper wie bei der Übermittlung zum Bob Server nachdenken.

19

Gemessen wird alle 5 Sekunden + Datenübertragungszeit, wie es default momentan bei BOB eingestellt ist:

"measurement_interval": 5,

Es werden bei BOB nur die Messdaten, keine Rohdaten oder Systemressourcen (wie bei Terkin / Hiveeyes) übertragen. Nur zu BOB, nicht zu hiveeyes!

Mich hat der massive Verbrauch gerade auch gewundert, hab das nur aus den Angaben bei 1nce im backend berechnet, daher kann auch hier ein Fehler vorliegen wenn die quotas nicht live sind. Ich teste nochmal:

Start: 15:37: 499,70 MB Restguthaben
Ende: 16:38: 499,01 MB [nun warte ich mal, was sich die nächste Zeit noch so tut, wäre realistischer, nicht mal 1 MB / Stunde]