Ich beschäftige mich gerade mit der DS3231 RTC (hier). Mit einer RTC hat man immer Datum & Uhrzeit zur Verfügung und damit ein paar mehr Optionen bei der Messfrequenz.
Vorweg: hier geht es um ‘langsame’ Messungen - also alles was ~ >10 Minuten Intervall hat.
Momentan ist es so, das die nächste Messung bei: ‘aktuelle Messdauer’ + Messintervall stattfindet.
Mit einer RTC ginge dann z.B. ‘zu jeder vollen Stunde’ oder ‘alle 10 Minuten auf die Minute’ etc… Auch Dinge wie Nachts oder im Winter seltener zu messen, wären möglich (um Strom & Daten zu sparen).
Mir würde z.B. alle halbe Stunde tagsüber, Nachts jede Stunde reichen (im Winter verdoppelt).
Was sind eure Ideen / Anforderungen dazu?
Tag-/Nacht-Rhythmus ist sicher etwas, das sich damit implementieren lässt, ebenso wie Winter vs. Rest. Generell sollte man so was immer vom vorhandenen Energiebudget abhängig machen.
Konzeptionell könnte es erst mal ein paar fest definierte Intervalle geben:
“Schwarmzeit” -> 10 Minuten
Frühling -> 20 Minuten
Normal -> 30 Minuten
Winter -> 1 Stunde
Nacht -> 1 Stunde
Für Nacht ist die RTC besonders gut, weil die Nacht für die Bienen im Sommer tatsächlich deutlich kürzer ist als im Herbst! Ggf. etwas tricky zu implementieren.
battery low 3,9 V -> 3 Stunden
battery low 3,8 V -> 1 Tag
battery low 3,6 V -> 7 Tage
battery low 3,4 V -> nur noch deep sleep und Spannung alle 7 Tage messen
Oder man macht das relativ (ist einfacher einzustellen, aber ggf. intransparent für die Imker):
fest eingestellt wird nur die schnellste Messung: 10 Minuten
Hier hat sich @Stefan auch schon mal Gedanken dazu gemacht
Er hat eine Variable SLEEP_SHORT mit der er zwischen langen und kurzen Intervallen umschalten kann, z.B. Sommer / Winter und dann gibt es nochmal zwei Werte, die spannungsabhängig verwendet werden:
# Apply this interval if device goes into shutoff
'shutoff': 10,
# night & winter mode: during the night or winter interval is doubled (-> in a winter night it is quadrupled)
# beginning & end months are included: night from 20 to 5 -> 20.00h to 5.59h, winter from 10 to 2 -> October 1st to February 29th
# a start value of 0 means there is no night/winter, night_start > night_end, winter_start > winter_end
'night_start': 20,
'night_end' : 5,
'winter_start' : 10,
'winter_end' : 2,
Da gibt es nur ein Intervall, das in der Nacht verdoppelt und im Winter nochmal verdoppelt wird (x4).
Das ist recht einfach zu verstehen. So was ähnliches kann man natürlich auch für die Batteriespannung machen.
Brauchen wir weitere Jahreszeiten? Und unterschiedliche Nächte pro Jahreszeit?
Intervalle die 60 glatt teilen halte ich auch für sinnvoll. 2 & 3 würde ich rauslassen - da dauert das Booten ja schon fast so lang. Dann blieben: 4, 6, 10, 12, 15, 20, 30 & vielfache von 60.
Braucht jemand das, das die Messung immer um die selbe Zeit stattfindet? Also auf die glatte Stunde z.B.?
Ich hatte das in meinem allerersten Open Hive code implementiert, dann aber mit etwas anderem gestartet und der Sketch hat es nie in produktiven code geschafft.
Heute finde ich es gar nicht so schlecht weil der node jetzt zufällig startet und immer bei z.B. xx:39:53, überträgt,.Damit sehe ich gut, wenn der node resetet, dann “passt” die Zeit nicht mehr.
Auch wenn wir in Richtung Weltherrschaft denken und sagen wir mal 50 nodes (xX :) Daten gleichzeitig zum Server senden ist die Last ungleichmäßiger verteilt als wenn jeder zufällig startet.
… könnte mensch natürlich auch ab und an den Wetterbericht laden und gucken ob und wieviel Sonnenschein die nächsten Tage so erwartet wird (zzgl. einstellbarem “Beschattungsfaktor”). scnr :)
Ja, jeder, der eine ordentliche Vergleichbarkeit mit den Daten der Wetterdienste haben will. In Schland sind das: “1-kalender-minütlich” der Niederschlag, 10-kalender-minütig das aller meiste, 1-kalender-stündig so fast alles andere – bei Vorhersagen, manuelle Meldungen oder andernorts kanns auch mal 3- und 6-kalender-stündig werden (was in den “vielfachen von 60min” nicht drin wär). [Edit: We’re talking UTC! bussi you’ve asked for! duck :)]
Die RTC macht keine Zeitumstellung mit - die Bienen aber auch nicht. Also eigentlich gut für uns.
Welche Zeitzone der Imker wählt, ist ihm selbst überlassen.
“Kalenderminute” hab ich in Anlehnung an den Begriff “Kalendertag” gewählt. Dit erste findet immer zu den Minuten :00, :10, :20, :30, :40 und :50 (einer “Kalenderstunde”) statt, oder in crond ausgedrückt zu */10 * * * .
Dit zweite findet “alle zehn Minuten statt”; der genaue Zeitpunkt ergibt sich lediglich aus dem Zeitpunkt wann das Gerät zuletzt gestartet wurde. (Und wenn man letztere Strategie wählt kriegt mensch über Zeit bestimmt leicht ne Drift rein, aber dafür gibts ja NTP …)
Und ja, meteorologisch kann in fünf Minuten schon viel passieren! (Historisch prägte der Wunsch nach möglichst zeitgleicher Messung den Begriff der Synoptik (spektrum.de))
Gut. Aber es gäb ja noch Software und Menschen, die auf die Idee kommen könnten ;)
Jo, vielleicht nochn kurzes Fachsimpeln/nen kurzer Exkurs zum “wie” … Du spielst vmtl. auf die RTC-eigenen feautes für Intervalle an, ne?
Unter dem Gesichtspunkt “der perfekten Synoptik” hatt ich mich in “Arduino-C” mal im Rahmen der Autonomen Zelle hingesetzt und versucht meinen gesammelten Hirnschmalz zusammen zu kompilieren:
In der Meteorologie bzw. beim DWD /enden/ die Messungen mit dem Messzeitpunkt. Also sie finden kurz vor der “Messminute” statt.
Das ist praktisch, weil wir nicht wissen können wie lange das Versenden brauchen wird. Die Dauer eines Verbindungsaufbau schwank ja durchaus.
Nach dem Versenden der Daten, direkt vorm Deepsleep – wenn wir wissen wie spät es nach der Übertragung nun wirklich ist – können wir exakt berechnen in wievielen Sekunden wir für die kommende Messung wieder aufwachen wollen. Dazu gibts noch ne Konstante, in der die Dauer der Messungen festgehalten ist. Um diese reduziert können wir passend vor der nächsten Messminute wieder aufwachen und die Messungen wieder /zur/ nächsten Messminute fertig zu haben.
Es gibt dann noch den corner-case, dass wir uns innerhalb des “Messzeitfenster” das Delta-T überlegen wollen, aber das läßt sich ja auch gegenchecken.
Im Code zur Autonomen Zelle ist das soweit so drin, nur vielleicht etwas unübersichtlich. Falls jemand in die Verlegenheit kommt studieren zu wollen was ich da letzten Sommer getan hab; ich helfe gerne.
Nee, bissken anders.
Die RTC hat das genaue Datum & die Uhrzeit. Der DS3231 hat zwei Alarmregister, in die man eine Uhrzeit reinschreiben kann. Sobald die aktuelle Uhrzeit = Alarmzeit wird ein Pin auf low gezogen. Damit kann man z.B. ein P-Kanal MOSFET einschalten und die MCU starten. Löscht man den Alarm, geht der Pin auf high und der MOSFET und die MCU wieder aus - bis der nächste Alarm kommt.
Die Register funktionieren ähnlich - Alarm 1 geht auf die genaue Sekunde, Alarm 2 immer bei 0 Sekunden.
(mit ‘day’ ist in der Tabelle der Wochentag gemeint)
D.h. es wird genau genommen nicht für ein Intervall geschlafen sondern ‘bis’. Wann die Messung bzw. das Versenden stattfindet, hängt von anderen Dingen ab.
Jo, und den Alarm 1 kann man denn ja bei jedem Aufruf der Mainloop um die berechnete Differenz bis zum nächsten Messzeitpunkt setzen und denn den Alarm der RTC “armen” so dass der MOSFET denn das Board abschaltet.
Ick weiss jetzt nicht wie Du auf 20 Sekunden kommst; aber nen Offset von 20 Sekunden wär mir auch bei minütlicher Messung ziemlich egal. Am Ende natürlich lieber nen Wert von :11 als :11, als einer wo :10 dran steht, der aber in Wirklichkeit doch von :11 ist.
Ab ich fänds persönlich halt schon geil, dass, wenn des “angesagte” Intervall 10 Minuten beträgt, die Messungen dann eben nicht um :05, :15, :25, usw. stattfinden, sondern eben um :00, :10, :20.
ah, dass die Messung erst nach dem Termin erfolgt und insg. 20 Sekunden dauert … ja, die Spanne juckt mich persönlich jetz nicht :) Perfektionisten würden jetz natürlich darum bitten die Umwelt/Außen-Parameter zuerst zu messen ;)
