System für kontinuierliche Audio-Aufzeichnung (BOB Projekt, Phase 1)

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.

Hi @clemens , gute Idee, da mache ich gerne mit, ich hatte letztes Jahr Audiodaten produziert mit USB Soundkarte von Ugreen am Raspi, ALC4040 Chipsatz, hat gut geklappt. Bzgl Analyse, meine erste Idee war ein neuronales Netzwerk auf die FFT Daten loszulassen, so eine Art Spracherkennung für Bienen, bin mir aber nicht sicher, wie gross der Aufwand ist, Grüsse, Markus

Hallo @mhies, sehr cool! Magst du mal kurz beschreiben wie und wo du die Audiodaten aufgezeichnet hast. Nur auf der SD des RasPi, oder hast du über Ethernet / WLAN übertragen? Wie groß waren deine “Soundblöcke”? Hast du am Stück aufgenommen oder irgendwie chunks von 1 Stunde / wasauchimmer gemacht? War das am Volk, d.h. Freiland mit “Draußen-Bedingungen” oder auf der Werkbank?

Hi @clemens , live Daten mit Mikro in Beute Anfang Juli, war ein Ableger vom Mai, @Andreas hat danals Audioanalyse gemacht, 120 sec Sample, dokumentiert im Blog: BeePhone Version 1.0: die Hardware ist fertig, erste Ergebnisse | Hies Blog
Audioanalyse ist in, sogar der Economist schreibt drüber: https://www.economist.com/news/science-and-technology/21739645-matching-honeybee-noises-their-ailments-new-app-listens-problems

Grüsse, Markus

Wenn wir die digitale I2S-Schnittstelle (für das Mikrofon), mit der Arduino Sound library nutzen wollen und WLAN voraussetzen, müssten wir auf Boards mit WLAN und Cortex M0 zurückgreifen. Ich weiß nicht, ob die lib auch mit anderen board tut oder gar mit dem ESP läuft.

Diese boards sollten jedenfalls die lib unterstützen, z.B.:

• Adafruit Feather M0 WiFi with uFL - ATSAMD21+ATWINC1500
• Arduino MKR1000 WIFI

Ohne WLAN gibt es den Cortex M0 auf diversen boards, im ProMini-form-factor als SparkFun SAMD21 Mini Breakout, mit SD-Interface zur lokalen Aufzeichnung als Arduino MKR ZERO oder Adafruit Feather M0 Adalogger oder mit SD, Solar-Unterstützung und Bee-Socket als SODAQ Autonomo

Danke für den Link, die erwähnte App “Bee Health Guru” habe ich unter Audio Analysing Apps for Mobile Devices aufgenommen.

• für die Lerndaten sollten wir den Idealfall anstreben: 24/7 Messung. Es wird sicher Ausfallzeiten geben, aber die können wir durch die Anzahl der Standorte kompensieren.
• Strom aus der Steckdose und LAN/WLAN - hier wäre meine Minimalanforderung: der betreuende Imkernde geht jede Woche einmal zum Standort, tauscht händisch einen USB-Stick/SD-Karte und überträgt anschließend die Daten vom zu Hause aus. Aber das würde ich nur in machen wollen, wenn wir nicht genug Standorte ran kriegen (<12).
• wir müssen eine verlustfreie Kompression machen, z.B. mit flac FLAC - Free Lossless Audio Codec
• am besten wären 44,1kHz, minimal 32kHz.
• An die Chunks haben wir keine Anforderungen.

Wir würden am Liebsten einen BeagleBone Green nehmen, weil der bei der Audiodatenverarbeitung deutlich besser ist als der Raspi (er kann 4 Kanäle), preislich und in seinen anderen Features aber vergleichbar.

Hallo in die Runde,

Das sehe ich auch so.

Für die 24/7 live/non-live recording/streaming/Bienenstockstethoskop Geschichte würde ich ebenfalls gerne Hardware verwenden, auf der Linux läuft. Weil SD Karten im Freien gammlig sind, sollten wir vielleicht im “non-connected” Fall stinknormale USB-Sticks verwenden, weil hier wenigstens die physikalische Steckverbindung von Haus aus robuster ist? Ein Seitenblick wäre hier auch auf Hardware mit eMMC Schnittstelle möglich, wie es z.B. die Geräte der ODROID Serie bieten.

Ich fände auf jeden Fall toll, auch die Möglichkeiten zu erforschen, die uns Microcontroller in diesem Bereich bieten. Für den allerersten (auch feldeinsatzfähigen) Prototypen würde ich aber definitv erstmal eine Linux-basierte Lösung anstreben - ohne Löten also ;].

arecord wird ja vermutlich definitiv unser Arbeitspferd werden. Hier und hier finden sich schöne Beispiele, wie damit in Kombination mit sox sowie flac verfahren werden sollte, um z.B. in einem Schritt aufzunehmen, zu resamplen und zu enkodieren:

arecord -d4 -f dat -t wav -r 48000 -c 2 | sox - -b16 -r16k -c1 -t wav - | flac - -o message.flac

Habt Ihr das bei Euren ersten Prototypen auch schon so in der Art gemacht?

Siehe auch die ersten Schritte für einen Wrapper um arecord herum für eine reboot-sichere Aufzeichnung von Audiosamples.

Viele Grüße,
Andreas.

Hallo @caro, danke für deine Anmerkungen. Lossless brauchen wir, ja? Hatte ich schon befürchtet, da wir ja bisher nicht genau wissen wonach wir suchen (sagt da die Bienen-Literatur etwas dazu?) Aber insgeheim habe ich doch auf eine höhere Kompression gehofft. Was würde passieren wenn wir verlustbehaftet komprimieren? Welche Frequenzbereiche sind z.B. bei MP3 besonders betroffen?

Kannst du nochmal sagen, was die negativen Erfahrungen beim RasPi waren? Die allgemeine Stabilität, die SD als Speicher? @mhies du hast ja auch einen RasPi im Dauerbetrieb laufen wie schaut es da mit der Stabilität aus? Mein 3er auf dem Schreibtisch hat ab und an auch Aussetzer. Vorteil wie Nachteil des RasPi ist die SD-Karte, damit kann man schnell ein OS klonen, komplette “vorinstallierte” Betriebssysteme (aus)tauschen, das macht aber auch die Hardware fragiler. Müssen wir uns diesen Punkt als Anforderung nochmal genauer ansehen? Warum habt ihr den BeagleBone green genommen und nicht den normalen? Nutzt ihr die grove-Schnittstelle? Je nachdem was die Imker damit machen müssen - WLAN SSID / PW einrichten - könnte ein Monitoranschluss nicht verkehrt sein.

Lasst uns bitte hier nochmal die Anforderungen genauer durchgehen um ein taugliches Board dann auszuwählen.

@einsiedlerkrebs du schreibst unter Research: audio stream with Linkit 7688, dass der LinkIt Smart 7688 “seems to be a bit slow” für was genau? Streaming, Recording? Ist der aus dem Rennen? Die I2S-Schnittstelle fände ich hier für uns attraktiv. @weef kannst du abschätzen welche Board-Liga wir benötigen, wenn wir gleichzeitig aufzeichnen, (verlustfrei) encodieren und verschicken wollen?

Brauchen wir die 4 Audiokanäle, wenn ja für was? Macht es überhaupt Sinn 4 Völker gleichzeitig mit Audio zu monitoren? Bekommen wir die Daten von 4 lossless-Audio-Aufzeichnungen als 24/7 halbwegs robust über die Leitung? Oder brauchen wir sogar mehrere Audio-Messpunkte von ein und demselben Volk um z.B. die optimale Mikrofonposition zu bestimmen?

Den use case mit dem Imker als Datenmuli sollten wir erst mal aussen vor lassen, da fällt in einer Woche ja schon sehr viel an Daten an, besonders wenn wir lossless brauchen. Das muss zwischengespeichert werden und dann auch wieder beim Imker über die Leitung. Besprechen wir, wenn wir zu wenige “optimale” Standorte haben.

Ich gehe eher davon aus, dass wir Standorte mit WLAN haben aber kein Stromkabel, ggf. sollten wir für diesen Fall eher ein backup haben (Solarzelle, Akku) als für die Version ohne Datenanbindung.

Zum Thema Lossless Audio Compression Codecs habe ich einen neuen thread erstellt.

Weil das der China-clone von Seeed ist, der ist billiger! ;)

Ausführliche Antwort folgt.

@clemens Die SD Karte ist schwer zugänglich in meinem Raspi Setup, sehr klein und kein Medium was im Feld getauscht werden sollte, dazu müsste man den RPi runterfahren, ich glaube das meint @caro mit schwierigem Handling. Falls kein Wlan zur Verfügung steht könnte man einen USB Stick in wasserdichter Hülle nehmen, der einfach zugänglich ist und gezogen/gesteckt werden kann. Am RPi könnte man auch mehrere Soundkarte via USB anschliesen oder auch den HDMI Kanal benutzen, der hat auch einen Audio Kanal, ich hab aber bisher nur eine IR Beutenkamera angeschlossen, ohne Mic.

Auf keinen Fall würde ich LinkIt Smart 7688 aus dem Rennen schmeißen, bevor wir nicht das getestet haben. Sobald ich ein i2S-mic hab, könnte ich das mal durchspielen. Wobei wir für eine abschließende Betrachtung natürlich den gesammten usecase im Auge behalten sollten, also auch das verschicken der records.

In meinen Augen hat der LinkIt Smart 7688 auch noch andere Vorzüge dem Rasperry Pi und teilweise auch gegenüber dem BeagleBone Green.

Der LinkIt hat auch einen SD-Kartenslot, allerdings wird davon nicht das Betriebssystem gefahren. Das ist ein großer Vorteil in z.B. feuchter Arbeitsumgebung und um z.B. die SD-Karte mal zu tauschen, für den Imker als Datenmuli

Ein weiteren Vorteil ebenfalls die feuchte Arbeitsumgebung betreffend sehe ich darin, dass das die GPIOs auf männlichen Pins ausgeführt werden. Mit z.B. einen Breakoutboard für die Peripherie könnten wir so ganz ohne Steckverbindungen auskommen. (Auch die 3.3V Power kann über die GPIO’s gespeist werden.)

• Der LinkIt Smart 7688 kann direkt Wifi und hat außerdem einen connector für eine externe Antenne.
• Von der CPU ist der Linkit am schmalbrüstigsten, was womöglich einen autonomen Betrieb (gestützt durch Solarzelle) ermöglicht. → Keine Kabel zum Stand nötig.

Insgesamt sind RPI und BBG mit ziemlichen starken CPUs ausgestattet, ferner haben sie noch GPU’s mit an Board. Ich glaube für Audioaufzeichnung ist eine solche Ausstattung ein unerwünschtes Konsumententum.

Ich würde auch sagen so viel Power (CPU / Strom) wie nötig und so wenig wie möglich. Aufzeichnen, encodieren und Verschicken muss halt parallel passieren, wenn wir einen 24/7-Betrieb wollen, daher meine Frage nach dem Aufzeichnungsvolumen. I2S-Mic bringe ich dir morgen mit, dann können wir mal testen, was möglich ist.

A post was merged into an existing topic: Hardware für node im Feld (BOB Projekt, Phase 2)

Mit welchem Aufzeichnungsvolumen rechnen wir pro Tag? Wenn ich das gerade richtig recherchiert habe (weitere Beispiele) berechnet sich die Größe einer unkomprimierten Audio-Datei nach

Auflösung x Anzahl der Kanäle x Samplefrequenz x Dauer in Sekunden
z.B.

• 16 bit x 1 Kanal x 44100 Hz x 60 Sek. = 42336000 Bit,
  das sind ca. 5 MB / Minute!
  – das wären 7,3 GB / Tag und wenn wir ca. 50 % mit flac komprimieren könnten 3,7 GB / Tag
  – oder 111 GB im Monat!!
• 16 bit x 1 Kanal x 32000 Hz x 60 Sek. = 30720000 Bit
  – oder 3,7 GB und mit 50 % Kompression 1,8 GB / Tag
  – und immer noch 54 GB im Monat!

Eine ganze Menge, die hier über WLAN bzw. dann weiter mit DSL verschickt werden muss, und das im upstream! Müssen wir hier spezeille Anforderungen an die Internet / DSL-Anschlüsse der Teilnehmenden formulieren? Mit der Handy-Flatrate wirds nicht funktionieren. Ein paar upload-Zeiten für exemplarisch 1 GB bei unterschiedlichen Bandbreiten gibt es unter: https://www.onlinekosten.de/internet/download-upload-geschwindigkeit.html, z.B.

1 GB mit 1.024 Kbit/s: 2 Stunden und 10 Minuten

Mein “normaler” innerstädtischer DSL-Anschluss zeigt gerade ↑ 733 kbit/s an, real sind das eher 500 kbit/s, d.h. die 3,7 GB brauchen so 7 bis 8 Stunden.

Ich wollte das auch genau wissen, nicht nur abschätzen und habe das mit dem von @caro präferierten BeagleBone (hier: Black) exemplarisch probiert. Dieser lief unter Debian 9 mit einem normalen 4.9er kernel (kein RT):

$ uname -a
Linux beaglebone 4.9.82-ti-r102 #1 SMP PREEMPT Thu Feb 22 01:16:12 UTC 2018 armv7l GNU/Linux

Zum Verarbeiten hat der BBB dieses genau eine Minute langes Bienengeräusch bekommen. Es wurde stereo in 48 ksps mit 24 bit gesampled und mit Audacity auf -3 dB normalisiert und dann zu mono, 44.1 ksps und 16 bit gerechnet:

$ file 180411-135534-mono.wav 
180411-135534-mono.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, mono 44100 Hz

Zum Enkodieren zu FLAC wurden flac 1.3.2 sowie alternativ flake 0.11 (flake home, flake vom github oder aus den distro-repos) verwendet. Als einzige explizite Konfigurationsparameter haben beide Programme jeweils -0 bzw. -5 bekommen.

Die vier Einzelergebnisse im Folgenden, output teilweise gekürzt:

flac mit -0 :

$ time flac -0 180411-135534-mono.wav .
[...]
180411-135534-mono.wav: wrote 3676145 bytes, ratio=0.694
[...]
real    0m0.869s
user    0m0.600s
sys     0m0.184s

flac mit -5 :

time flac -5 180411-135534-mono.wav .
0.678
[...]
180411-135534-mono.wav: wrote 3594038 bytes, ratio=0.678
[...]
real    0m1.853s
user    0m1.696s
sys     0m0.108s

flake mit -0 :

$ time flake -0 180411-135534-mono.wav

Flake: FLAC audio encoder
version 0.11
(c) 2006-2007 Justin Ruggles

block time: 27ms
variable block size: none
prediction type: fixed
prediction order: 2,2
partition order: 4,4
order method: estimate
header padding: 4096

input file:  "180411-135534-mono.wav"
output file: "180411-135534-mono.flac"
Signed 16-bit 44100 Hz mono
samples: 2646000 (1m0.000s)
block size: 1152
progress: 100% | ratio: 0.716 | bitrate: 505.5 kbps | bytes: 3791139 

real    0m0.522s
user    0m0.404s
sys     0m0.088s

flake mit -5 :

time flake -5 180411-135534-mono.wav

Flake: FLAC audio encoder
version 0.11
(c) 2006-2007 Justin Ruggles

block time: 105ms
variable block size: none
prediction type: levinson-durbin
prediction order: 1,8
partition order: 0,6
order method: estimate
header padding: 4096

[...]
block size: 4608
progress: 100% | ratio: 0.678 | bitrate: 478.7 kbps | bytes: 3590564 

real    0m1.763s
user    0m1.496s
sys     0m0.116s

Zusammengefaßt:

• ein BeagleBone kann aus einer Minute raw PCM, 44.1 kSamples pro Sekunde in 16 Bit Auflösung in (grob gerundet) einer halben bis zu zwei Sekunden daraus flac erzeugen (ein Kanal; bei -0 resp. -5; Debian 9 usw.).

• flake ist in beiden Fällen auch hier etwas schneller als das ‘Original’ flac.

• der Zeitaufwand wächst, egal, bei welcher flac-Implementation, bei längerem “Nachdenken” des flac-Enkodierers und steht irgendwann in keinem sinnvollen Verhältnis mehr zur erzielbaren Bandbreiten-Einsparung (ok, das war jetzt auch nichts Neues ;) ). Deshalb hier nur -0 und -5 und keine höheren Werte.

• die Audio-Quelle “viele Bienen” hat wenig Anteile, welche sich in der time domain komprimieren lassen; viele Bienen brummen halt immer, für den Algo sieht sowas sehr nach Rauschen aus - daher lassen sich keine 2:1-Verhältnisse erreichen wie bei Musik- oder Sprachquellen.

Das ist ein gutes Ergebnis, es bedeutet nämlich, daß für lossless compression á la FLAC genügend Reserve auch auf diesem single core Cortex-A8 zur Verfügung steht. Eher begrenzt die upstream-Bandbreite.

Flac ist zwar bitstreamed, aber es läßt sich nicht ohne Weiteres über auch breitbandiges WAN streamen. Es bringt zwar ein einfaches container-Format mit, aber das ist TCP meist egal ;). Deshalb muß ein streaming über ogg- oder mka-Container angedacht werden. ogg z.B. läßt multi-stream container zu, darin ließen sich dann auch irgendwelche komplett asynchron erfaßen analogen oder I2S-Mikrofone unterbringen. icecast oder darkice wären dafür geeignet zu streamen - vorteilhafterweise als einfache Lösungen wie z.B. das hier:

"Software efficiency halves every 18 months, compensating for Moore’s Law.” - David May’s law

Hervorragend, nach so einem kompakten Schnipsel, der exakt dies tut, hatte ich schon immer mal gesucht. Danke!

… und natürlich erst recht für die ausführlichen Leistungstests! Da Du hier nun schon einen kleinen Teststand aufgebaut hast, würden mich natürlich auch brennend die Ergebnisse auf einem LinkIt Smart 7688 mit 580 MHz MIPS CPU interessieren, den @einsiedlerkrebs und ich ebenfalls weiterhin als Kandidaten dafür im Rennen sehen.

Vielleicht kannst Du das mal vergleichsweise sogar auf Deinem Carambola (auch bei Heise) mit nur 320 MHz MIPS CPU näher unter die Lupe nehmen, falls Du keine ähnliche MIPS Maschine zur Hand hast?

Du meinst Carambola2, das ist aber auch ein MIPS, immerhin aber etwas modernerer (24kc) und mit 400MHz. - Aber der sowie auch der LinkIt als OpenWRT/LEDE-Maschinen haben etwas wenig RAM und ROM, wenn es mit weniger Audio-Kanälen dort überhaupt geht, müßte man an Applikationssoftware noch mehr abspecken resp. neu schreiben…

So oder so wird man wohl wieder bei dem helper gstreamer (ver)enden, auch pulsaudio als layer wird nötig.

Ok, ich nahm an wir kämen mit arecord bzw. sox und flac bzw. flake auch zurande. Die Python Implementierung von BERadio läuft bereits auf dem LinkIt von @einsiedlerkrebs, daher dachte ich, dass wir aus diesen Bestandteilen auch etwas sinnvolles für die kleineren MIPSen hinkriegen bzgl. robuster Audiodatenaufnahme und -telemetrie (wahlweise chunked oder streamed, je nachdem was auf welcher Hardware möglich ist).

Du meinst wir brauchen das Tandem zwingend? Und ist das jeweils erhältlich für die kleineren Maschinen bzw. dort einsetzbar? Gstreamer ist recht hungrig, stimmts? Passt der in den wenigen RAM? Fragen über Fragen… ;]