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

Denke WiFi sollte hinzubekommen sein. Vollständig autark wäre cool, wir hätten mit O2 aber immer noch das Stromproblem.

Jo, und das O² Problem.

1 Like

A post was merged into an existing topic: Audio hardware for BeagleBone

2 posts were merged into an existing topic: Developing Saraswati: A robust, multi-channel audio recording, transmission and storage system

Für die ersten Test - 365/7/24 Messungen könnte ich 3 Industrie DLT V8310 mit IP 66 Gehäuse bereitstellen.
Mit denen könnte man erstmal ein paar Langzeitmessungen mit größtmöglichen Frequenzbereich machen, um evtl. Besser abschätzen zu können, auf welche Bereiche man sich konzentrieren will/sollte.

Der Aufwand sollte nicht all zu groß sein, wenn sich im Linux oder Windows Universum eine entsprechende Software zum Aufzeichnen finden lässt.

Im Gehäuse ist ein der IP 66 geschützen Anschlussseite auch relativ viel Platz, um dort noch eine kleine USB Soundkarte und einen USB Kartenleser unterzubringen.
Kabeldurchführungen sind vorhanden.

DLT -V8310
Intel® Atom™ D 525 Dual Core 1,8MHz
10,4" Resistiv Touchscreen SVGA 800x600
2 Gb Ram
WLAN IEEE 802.11 a/b/g/n;
Lan: 10/100/1000 Mbit
2 x Com Port
4 x USB 2.0 davon 1 x Service USB
16 GB CF Fast Card Industrie (SYSTEM)
Gehäuse : IP-Schutzart: IP66
Spannungsversorgung 12-48V DC (Netzteile keine vorhanden )

Cool, ich denke den Code, den wir für dein Beaglebone schreiben, wird sich leicht übertragen lassen.

Siehe auch den Thread zur Gstreamer-basierten Mehrkanal-Aufzeichnungssoftware:

Moin, hat hier eigentlich schon jemand etwas weiter gearbeitet? Würde gerne in ein paar Wochen versuchen eine Reihe von Aufzeichnungen zu machen und auf meinen Home. FTP zur Verfügung stellen.

Plan ist es einen Königinnenableger relativ kurz vor der Linde zu machen und nach Ernte zu behandeln und eine neue Königin zuzusetzen oder wieder zu vereinen.
Ein Vergleichs-Volk steht auch bereit.

Hab auf dem Server 1TB zur Verfügung. Es sind also ein paar mehr Datensätze möglich. Bei den Bienen hab ich leider über Powerline und Wlan nur noch Max 40MBit/s bis zum Server zur Verfügung.
ins www aber 400/200MBit/s
Fragt sich:

  • wie viel Sinn das ganze macht?
  • Wie oft und wie lange aufgezeichnet wird.
  • welche Software?
  • mit welcher Hardware ich messe.

zur Verfügung Stehen würden:

  • FiPy I2C-Micro
  • Arduino I2C-Micro
  • Outdoor- Industrie PC Win10/Linux mit 2 x USB Micro ( Automatische Aufzeichnungssoftware?)
  • Raspberry Pi (Software/Micro?)

Die Winterlinde kommt bei mir kommt immer so ca. 1-2 Wochen später als in der Stadt allerdings ist bis dahin auch nicht mehr wirklich viel Zeit zum testen und Entwickeln.

Jemand Ideen / Vorschläge ?

1 Like

Hi Michael,

die Embedded-Varianten zur Audioaufzeichnung (z.B. bei Erschließung von I2S-Support und FFT für MicroPython auf Pycom/ESP32) sind noch relativ im Entwicklungsstadium.

Aus diesem Code hat sich mittlerweile »Saraswati« gemausert, siehe Developing Saraswati: A robust, multi-channel audio recording, transmission and storage system.

Dieses Stück Software ist zwar auch noch in der Entwicklung, @Diren und @clemens haben aber u.U. bereits etwas Erfahrung im Betrieb gewinnen können, siehe Installation von Saraswati auf einem BeagleBone Green Wireless.

An dieser Stelle können wir vielleicht anknüpfen, wenn Dich die Geschichte mit dem Recording per SBCs (RaspberryPi, BeagleBone, etc.) interessiert. Für die robuste Langzeitaufzeichnung ist diese Variante vermutlich ohnehin besser geeignet als mit Embedded Geräten und für den Fall der Fälle auch besser (fern-)wartbar.

Die Voraussetzungen sind natürlich, ordentlich Infrastruktur (Strom und Netz) in der Nähe des Bienenstands zu haben. Aber das scheint ja bei Dir der Fall zu sein?

Viele Grüße,
Andreas.

Gut würde dafür dann gerne einen der Industrie PC (DLT-V8310) nutzen, so hätte ich direkt am Bienenstand Zugriff auf die Daten und müsste auch nicht immer mit dem Laptop raus, wenn wieder was mit den Waagen nicht stimmt.
Außerdem hat der schon IP67 und auch etwas längere USB Stecker + Kabeldurchführung passen wasserdicht mit ins Gehäuse.
Gibt es eine bestimmte Linux Distribution, die ich verwenden sollte? Würde sonst Linux Mint oder Ubuntu nehmen.

Ich denke wir sollten mit beiden dieser Debian Derivate gut hinkommen. Es geht primär darum, dass sich die bei Saraswati » Install prerequisites » Debian-based systems genannten Pakete gut installieren lassen.

Es ist nun ein Linux Mint 20.2 geworden.

Damit hatten wir noch kurz zu tun, es hat aber nur geringfügig Ärger gemacht.

Read all about it: Erschließung von Saraswati für den Betrieb auf einem Industrie PC, mit Upload per SSH+rsync auf Synology NAS

Wir haben unter Installation von Saraswati auf einem Industrie PC, mit Upload auf Synology NAS eine prototypische Installation am laufen und sind darüber nochmal zum Thema Dateiformat und ggf. Weiterverarbeitung / Anhören der aufgezeichneten Sounds gekommen:

Könnten wir mit den bisher produzierten *.mka-Dateien direkt sox füttern um damit z.B. FFT- Spektrogramme wie hier Sound Visualization - #2 by Andreas zu bekommen? Matroska / *.mka ist ein Audio-Container-Format was steckt da bei uns momentan drin? Nur eine Überlegung, um sich späteres Umkopieren zu sparen … siehe auch Lossless Audio Compression Codecs

1 Like

Im *.mka Container steckt momentan der FLAC “Free Lossless Audio Codec”.

Ich habe geschaut, ob man den Sonic Visualiser mit Plugins oder ähnlichem erweitern kann, so daß er direkt *.mka verarbeiten kann, leider ohne Erfolg.

Ich bin mir auch nicht sicher, ob wir den Container überhaupt brauchen. Für mein leienhaftes Verständnis sind solche Container dazu gedacht mehrere Ton und Videospuren In einer Zeitlinie zusammen zu fassen. Es kann aber sein, das der Container ganz andere, aufzeichnungsrelevante Gründe hat.

Die Daten mit mkvextract zu extrahieren ist kein Problem, allerdings ist das bei ca. 3Gb pro Kanal pro Tag leider sehr Speicherintensiv, wenn man die Rohdaten behalten möchte.

Vielleicht weiß @Andreas oder @Diren noch, warum dieses Format gewählt wurde. FLAC oder WAV wär sicher für eine unkomplizierte Weiterverarbeitung besser.

1 Like

Hab es gefunden:

Ok Brauchen wir in meinem fall beim Industie PC mit Swisbit CFast Industrial 16GB Nand Speicher mit Zwischenspeicherung und Übertragung per Rsync also theoretisch nicht.

Hat viel wahres. Wenn ein anderes System mit dem aktuellem Setup läuft, ist eine normale SD sicherlich ziemlich schnell an ihrer Schmerzgrenze, was Schreibzyklen angeht.
Daher evtl doch lieber beim *.mka bleiben.

@weef ich habe auf meinem Rechner auch den FTP Server als Laufwerk gemountet. Daher wär es für mich ein leichtes zu testen, ob man nicht direkt darauf speichern kann. Oder macht das aus oben genannten Problemen keinen Sinn?

Die Leitung zu meinem ca. 300m entfernten Bienen läuft bei mir etwas Chaotisch erst über Lan (80m im Haus) dann DLan(80m zum Schuppen) anschließend über Lan(50m zu einem weiteren Schuppen) und zu guter letzt über Wlan (60m übers freie Feld). Also alles dabei. Am Ende kommt per Wlan nur noch ca. 50 Mb/s an dem PC an.

ogg scheint etwas universeller zu sein als mka, zumindest lassen sich ogg-files mit SonicVisualiser und Audacity öffnen, was mit mka nicht geht. sox kann auch ogg.

https://de.wikipedia.org/wiki/Ogg

Die Streamingfähigkeit ist dabei das entscheidende Designmerkmal: Alles, was in einem Ogg-Container verpackt ist, kann ohne zusätzliche Anpassungen gestreamt werden. Dies unterscheidet Ogg von Formaten, die entweder nur in bestimmten Ausprägungen streamingfähig sind (wie z. B. Matroska) oder überhaupt nicht live-streaming-fähig sind (wie z. B. MP4).

Vgl. Matroska FAQ.

Wäre es dann sinnvoll ogg zu nehmen oder was spricht sonst für Matroska?

Hatte leide bisher nicht viel Zeit. Habe mich aber schon etwas mit gstreamer und den oggmuxer beschäftigt.
Ich denke auch das ich es hinbekommen habe Flac in einen ogg Container zu packen.
meine Änderungen an recorder.py

pipeline_expression = (
            f"{source} ! audioconvert ! queue !flacenc ! flactag ! flacparse ! "
            f"muxer.audio_%u splitmuxsink name=muxer muxer=oggmux "
            f"max-size-time={chunk_duration_ns:.0f} max-files={self.settings.chunk_max_files}"
        )

und in model.py

] = "{year}/{month:02d}/{day:02d}/{channel}/{timestamp}_{channel}_{fragment:04d}.ogg"

leider scheinen die erzeugten Dateien nicht korrekt erzeugt zu werden. Ich kann die Dateien zwar mit dem VLC Player(win10) offnen und abspielen, jedoch klappt das nicht mit dem SonicVisualiser (Win) Mit dem SonicVisualiser (Linux) geht es zwar aber die Dateien werden nicht Richtig Decodiert.

Habe dann mal versucht die Dateien direkt während der Erzeugung mit sink wieder zu demuxen und in FLAC zu speichern, da FLAC bei splitmuxsink nicht unterstützt wird.
Leider akzeptiert SonicVisualiser die so erzeugten Dateien nicht.
Ich erhalte bei Überprüfung mit Audiotester v1.7 von vuplayer.com bei allen Dateien ein (LOST_SYNC @ 0m 00s)

Einzig der Spek – Free Acoustic Spectrum Analyzer / Spectrogram Viewer offnet diese Dateien, das macht er aber auch schon mit den .mka Dateien.

Edit: Beispielfiles hierzu finden sich auf dem FTP Server unter /saraswati_test oder unter
http://gofile.me/6R2B4/cOggK1qQX

1 Like

Vielen Dank für diesen Beitrag, ich habe ihn gerade per Optionally use Ogg container format for audio recordings · hiveeyes/saraswati@13de01a · GitHub eingearbeitet. Das Feature steht nun auch per Saraswati 0.6.0 zur Verfügung.

2 Likes

Die Antwort darauf haben wir nun schon oben bei System für kontinuierliche Audio-Aufzeichnung (BOB Projekt, Phase 1) - #73 by MKO reflektiert.

Vielen Dank für Deinen Beitrag bei https://github.com/hiveeyes/saraswati/pull/15!

Audacity kann mka bei mir öffnen, - aber deshalb, weil ffmpeg hier ohnehin installiert ist. Damit kann Audacity viele ‘neue’ Formate im- und exportieren. FFmpeg rangiert in der gleichen Klasse wie gstreamer, es wird aber neben seiner Kommandozeilen-Eignung viel als Im- und Export-Library durch andere AV-Software genutzt - davon profitiert auch Audacity. @clemens, @mko, nehmt ffmpeg zusätzlich!

2 Likes