Auch darüber hatte ich nachgedacht, ob der Kanalname oder der Timestamp vorgelagert sein sollte.
Am Anwendungsfall “ich will alle Dateien eines bestimmten Stocks (aka. Kanal) im Schwung haben” entlang gedacht, wäre ersteres ja durchaus sinnvoll, nicht? Sonst wird es schwierig, im Dateisystem-Archiv interaktiv per “browse & sort & select” entsprechend nach bestimmten Beuten (Kanälen) filtern zu können.
Wenn wir den Dateinamen mit dem Timestamp beginnen lassen wollen, wäre es wohl sinnvoll, dem Kanalnamen (zusätzlich?) ein übergeordnetes Verzeichnis zu spendieren?
Die Dokumentation über “Running Saraswati in production” wurde ebenfalls signifikant verbessert und nimmt nun auch besseren Bezug auf die Einrichtung der SSH-Verbindung.
Außerdem wird die Verwendung einer RAM disk für das Spoolverzeichnis vorgeschlagen, um übermässiger Nutzung von Festplatten bzw. Flash-Speichern im Feldbetrieb vorzubeugen, was sich positiv auf das Energiebudget und die Abnutzungsfolgen des Systems auswirkt.
Für diese Variante ist ein wirklich regelmäßiger und zuverlässiger automatischer Datenupload (z.B. alle fünf Minuten) natürlich wichtig.
es wäre nett, Saraswati mit einem Scheduler auszustatten, um nicht nur durchgehend Audio aufnehmen zu können, sondern auch auf Ansage.
Ich denke dabei beispielsweise an folgende Zeitpläne:
Jede Minute für jeweils zehn Sekunden (1/6)
Alle zehn Minuten für jeweils eine Minute (1/10)
Jede Stunde für jeweils fünf Minuten (1/12)
6x am Tag (08:00, 12:00, 16:00, 20:00, 00:00, 04:00) für jeweils zehn Minuten (1/24)
Damit bekäme man doch weiterhin einen guten Überblick, muss aber nicht ganz so viele Ressourcen (CPU-Zyklen, Transfer-Bandbreite, Speicherplatz) dafür aufwenden. Was meint Ihr dazu?
Viele Grüße,
Andreas.
P.S.: Um eine optimale Gestaltung des Meßintervalls der diskreten Meßwerte geht es bei Dynamische Regelung des Meßintervalls und Messfrequenz bei Verwendung einer RTC. Das hat zwar nichts mit dem Audiosystem Saraswati zu tun, trotzdem sind entsprechende Inspirationen à la “im Winter weniger oft als im Sommer” ggf. auch hier sinnvoll.
Genau daran hatte ich auch schon gedacht. Im Winter gibt es gerade in Sachen Saraswati nicht viel an Informationen die man wirklich erfassen könnte. Evtl höchstens Anzeichen von mehr oder weniger Aktivität. Interessant wäre da aber sicherlich mit einem Mikrofonarray um die Position und die Bewegung der Wintertraube erfassen zu können. Dieses muß nicht alle 5 Min und auch sicher nicht alle 10 Min erfolgen.
In der Schwarmzeit hingegen würde ich engmaschig und länger aufzeichnen und bei Schwarmstimmung sogar dauerhaft. So kann man im nachhinein evtl ein paar Tage oder Wochen früher schon Veränderungen feststellen. Um dann beim nächsten mal eine Wahrscheinlichkeit für z.B. einen Schwarm schon Min/Stunden/Tage/Wochen vorher erkennen zu können.
Eine Erkrankung, Hunger oder hoher Varoadruck wird sich denke ich nicht innerhalb von ein paar Minuten oder Stunden so stark auf ein Volk auswirken, das da plötzliche sprunghafte Änderungen bei einer Analyse zu erwarten sind.
… wenn wir dann noch eine FFT dran hängen, könnte man den Datenstrom nochmals verdichten und bräuchte noch weniger Durchsatz um die Daten auf einen Server zu bekommen oder zu visualisieren.
Auch für einen stromsparenden Betrieb mit Schlaufpausen zwischen den Erhebungsintervallen wäre das eine Voraussetzung. Ausblick: Beim HoneyPi-Projekt wird fürs zeitgesteuerte Hoch- und Runterfahren ein WittyPi-Modul verwendet.
Die Idee ist gut, würde da an an ein FFT über 1min und davon dann 30sec. zusätzlich als .flac denken.
Daran hab ich auch schon gedacht. Deshalb beschäftige ich mich aktuell mit Terkin für den Raspberry.
Terkin kennt den DS3231 vom WittyPi schon. Es könnte also relativ einfach umzusetzen sein.
Ich schaue also gerade, ob man nicht Saraswati und Terkin parallel oder hintereinander weg laufen lassen kann.