Im Rahmen des BOB Projekts unterstützt Hiveeyes citizen science-Forschung als Bindeglied zwischen Uni und maker community. Wir möchten auf Grundlage von Audio-Aufnahmen den Zustand des Bienenvolks “messen”.
Entwicklung von Algorithmen
Ein späteres System soll batteriebetrieben arbeiten, Sound z.B. jede Stunde für 10 Sekunden aufnehmen, die aufgenommenen Audio-Daten z.B. über eine “fast Fourier transform” (FFT) “eindampfen” und diese reduzierten Daten entweder auf dem node analysieren oder an einen zentralen Server zur Analyse schicken.
Damit wir Algorithmen entwickeln können brauchen wir zu allererst “Trainingsdaten” oder “Lerndaten” an Hand derer wir am Ende sagen können welche Muster in der Zeit oder Soundzusammensetzungen an einem gegebenen Zeitpunkt für welchen Zustand stehen.
Anforderungen an die Sound -Aufnahmen zur Algo-Entwicklung
Diese Fragen gehen vor allem an @tox und @caro. Welche Anforderungen haben wir an die Audio -Daten?
- Für die Lerndaten sollten im Idealfall kontinuierliche Audiodaten vorliegen, d.h. wir messen 24 Stunden an 7 Tagen die Woche. Falls wir diesen Idealfall aus technischen Gründen nicht halten können, was ist dann für euch die Minimal-Anforderung? Reichen 12 Stunden Sound oder gar 6, 3 Stunden? Vielleicht ist das aber auch eine biologische Frage und wir können Sie erst später beantworten.
- Wir werden für die Lernphase voraussichtlich nur Standorte erschließen können, die mit Strom aus der Steckdose und WLAN oder LAN versorgt sind, ggf. müssen wir sogar hier noch höhere Standards definieren, z.B. eine hohe gesicherte Datentransferrate für das WLAN.
- Wir werden die Audiodaten aus kapazitätsgründen nicht “roh” über das Internet schicken können, sondern komprimieren müssen. Was ist bei der Komprimierung zu beachten? Verbreiteter Verfahren wie MP3 sind auf das menschliche Gehör optimiert, das könnte für unser Projekt Nachteile haben. Welche Frequenzen werden “abgeschnitten”, die für uns relevant sein können? Bis zu welcher Kompressionsrate können wir runter?
- Damit hängt auch die Samplingrate zusammen, was brauchen wir hier minimal, was ist wünschenswert?
- Gleiches für das Frequenz-Spektrum? Minimal und gewünscht?
- Wir brauchen für die Audiodaten timestamps und müssen wohl auch mit Netzanomalien usw. rechnen. Daher ist unsere momentane Idee die Audiodaten nicht zu streamen, sondern schon auf dem node zu zerstückeln und diese Audio-chunks dann zu übertragen. Ob und wie das funktioniert müssen wir sehen, da der node beim Verschicken ja gleichzeitig weiter aufzeichnen soll. ;-) Gibt es auf eurer Seite Wünsche / Anforderungen zum chucking, wie groß / klein sollen die Sound-Schnipsel sein?
Anforderungen an die Hardware zur (kontinuierlichen) Sound-Aufnahme
Wenn wir Antworten auf die Fragen oben haben können wir versuchen die benötigte Hardware zu definieren.
Momentan deckt die Anforderungen wohl ein Linux-System wie der RasPi ab. @caro sagte, dass ihr in Bremen nicht so zufrieden mit der Stabilität der RasPis wart. @tox kannst du konkretisieren was die Probleme genau waren? Allgemein die Stabilität (an der wir nichts ändern können), bestimmte Komponenten Software oder Hardware die Probleme bereitet haben? Habt ihr gestreamt, ist die verwendete Software irgendwo public?
Wenn es der RasPi nicht wird, würden wir den LinkIt Smart 7688 (die Schwester des LinkIt Smart 7688 Duo) antesten, er hat eine I²S-Schnittstelle (Inter-IC Sound) und kann damit qualitative und günstige Digitalmikrofone - wie sie heutzutage in allen Smartphones verbaut werden - direkt ansteuern. @einsiedlerkrebs sagte auch, dass ein USB-Anschluss als Pins herausgeführt wurde, an denen man alternativ via USB-Soundkarte (?) ein (analoges) Micro anschließen könnte.
Mein Favorit wäre - ohne große Recherche bisher - ein ESP32, da wir dann für die erste Phase die selbe Hardware verwenden können wie in der zweiten, dann aber batteriebetrieben. Habe aber gerade keine Ahnung, ob der ESP32 das kann was wir in der ersten Phase brauchen.