Ja, ich würde tatsächlich das Micro in Bodennähe anbringen, da sollte mehr “Informationsgehalt” als anderswo in der Beute herrschen, etwa Flugbetrieb Räuberei.
Beim Gitterboxen hast du vermutlich etwas mehr “noise” aus der Umwelt als am anderen Stellen, und bei manchen Testaufnahmen hatte ich den Eindruck Resonanzen vom Gitter zu hören. Dennoch würde ich es da versuchen.
Hatte es zunächst am Boden probiert, leider hat es einigen Bienen nicht ganz so sehr gefallen. habe sie mit so einem Schaumstoffhaube direkt auf den Gitterboden gelegt, da ich auch ab und an das Einflugloch mit Schaumstoff einenge war ich der Meinung, das die Bienen Dieses Material ignorieren würden. Die Soundfiles Sprachen doch eine andere Sprache. 5 Bis 10 Bienen waren der Meinung das das Teil dort nicht hin gehört und haben es versucht Richtung Ausgang zu schleifen. Durch die Lautstärke dieser Bienen direkt am Mikro ist es nahezu unmöglich irgendwas anderes zu hören.
Wenn die Bienen mal nachließen waren die Nebengeräusche wie Vogelgezwitscher, Hundegebell usw. doch recht störend. Ohne die Schutzhülle ließen die Bienen auch keine Ruhe.
Entweder werden die Mikrofone als störendes Objekt erkannt, oder sie erzeugen irgendwelche Geräusche.
Habe Die Mikrofone jetzt deshalb erstmal im Deckel platziert Ich habe in meinen Beuten oben keine Folie sondern ein Abdeckgaze so das die Geräusche doch recht gut durchkommen sollten.
Werde es später aber auch nochmal mit einem Gedruckten Gehäuse für die Mikrofone versuchen.
Zugangsdaten für den FTP Server gibt es erstmal auf Nachfrage per PN.
Auch im aktuellen (Werbe-)Video von Beep wird das Mikro am Flugloch platziert. Ist ein I2S-mic das natürlich kleiner als ein normales ist, daher passt es in einen Lockenwickler.
Meine sind auch klein, sie haben einen Durchmesser von ca 4mm und sind 12-15mm lang. Ich habe nur leider keine Locken, also auch keine Lockenwickler 
Die kleine Größe kann sicherlich auch ein Grund sein, so das die Bienen meinen könnten sie könnten/müssten sie weg/aufräumen.
Werde mal schauen, ob ich Montag ein paar Lockenwickler besorgen kann.
:-))
https://www.holtermann-shop.de/Koeniginnenzucht/Zusetzkaefige/Imgut---Lockenwickler--Chico-.html
4 posts were merged into an existing topic: System für kontinuierliche Audio-Aufzeichnung (BOB Projekt, Phase 1)
Das system läuft momentan schon seit ein paar Tagen stabil und recht sauber. Bisher gesammelte Daten sind 28GB.
Der 2.Kanal hinkt ab und an mit dem Rsync ein paar Stunden hinterher. Derzeit fehlen noch knapp 1GB Daten auf dem NAS.
Auch gibt es ein kleines Problem mit de USB Mikrofonen. Bei einem Neustart werden sie nicht immer vom Gstreamer erkannt. Sie müssen dann eimal kurz abgezogen und wieder angesteckt werden. Bin jetzt dabei einen weiteren PC fertig zu machen, dann kann ich auch schauen, ob ich es hin bekomme auf .ogg umzustellen. Der erste “naive” Versuch einfach in der recorder.py von muxer=matroskamux auf muxer=oggmux umzustellen ist natürlich gescheitert.
So ein Phänomen habe ich bei einem Windows-Rechner mit einer Maus auch, die über einen USB-Hub angebunden ist. Wenn die Maus über den Hub angeschlossen ist funktioniert sie nach einem Neustart des Rechners nicht und muss ab- und wieder angesteckt werden. Wenn sie direkt an einem USB-Port des Rechners hängt funktioniert es.
Wie sind deine Mics angeschlossen? Direkt am Rechner, könntest du ggf. auch USB-Ports tauschen oder laufen die über einen Hub?
Der Rechner hat unten 3 x USB und oben unter der roten Antennenabdeckung einen weiteren Service-USB in dem mein Funk Maus/Tastatur Adapter steckt. Die 2 Microfone stecken direkt in den unteren 3 USB-Ports. Sie sind aber mit einem Wasserdichtem Deckel überdeckt. So muß man den Deckel immer aufschrauben, wenn man sie abstecken muß.
Mit lsusb werden die Microfone auch immer erkannt. Er erkennt dabei aber auch 2 interne Linux USB Hubs .
Mit meinem Testrechner könnte ich das Problem aber bisher nicht reproduzieren.
Habe da saraswati zwar schon installiert aber den saraswati-dienst bisher noch nicht gestartet.
Ich tippe mal ins Blaue und sage das der Dienst startet bevor der USB fertig initialisiert ist und es daher nicht funktioniert. Es könnte also reichen alsa und Gstreamer vor saraswati neu zu starten. Hatte gestern Abend im Dunkeln keine Muße evtl. erneut zu den Rechner raus zu müssen, und hab es daher nicht nochmal ausprobieren wollen.
Hi Michael,
vielen Dank für Deine Rückmeldungen.
Dazu habe ich bei Start Saraswati service after USB sound devices have been registered · Issue #12 · hiveeyes/saraswati · GitHub ein Ticket angelegt.
Viele Grüße,
Andreas.
Laut linux - In systemd service file, how do I say "after USB is ready"? - Super User müsste man den Mechanismus wohl am besten individuell auf die Zahl der USB-Busse abstimmen.
Wie sieht denn Dein Verzeichnis unter /dev/bus/usb oder /sys/bus/usb aus, wenn alle Audiogeräte ordnungsgemäß aktiv sind?
Aus der Hüfte heraus habe ich nun https://github.com/hiveeyes/saraswati/commit/357b14898 eingereicht. Saraswati würde damit (saraswati.path) erst dann gestartet, nachdem das Verzeichnis /dev/bus/usb nicht (mehr) leer ist. Für Audiogeräte am USB Bus könnte es so funktionieren, mir gefällt es aber trotzdem noch nicht 100%ig, weil es auf Systemen ohne USB Audiogeräte zu kurz greift.
Trotzdem ist es so erstmal bis auf weiteres Bestandteil von Saraswati 0.6.0, die Systemd Unit Konfiguration kann also nach dem Upgrade per "sudo pip3 install saraswati --upgrade" via "sudo saraswati setup --systemd" entsprechend aktualisiert werden.
Danach das System zum Testen am besten komplett neustarten und berichten, ob es damit vielleicht schon gut klappt. Vielen Dank!
Wenn alles läuft schaut es so aus, es schaut aber genauso aus wenn es nicht läuft.
bsoering@Bienenstand:/sys/bus/usb/devices$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 003: ID 04d8:0c02 Microchip Technology, Inc. AR1100 HID-MOUSE
Bus 005 Device 002: ID 1a02:bad8 Advantech DLoG DLT-V83xx
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 003: ID 1b3f:2019 Generalplus Technology Inc. USB Microphone
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 003: ID 0c76:160a JMTek, LLC. USB Audio Device
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
bsoering@Bienenstand:~$ lsusb -t
/: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
|__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 1: Dev 2, If 1, Class=Application Specific Interface, Driver=, 12M
|__ Port 2: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
|__ Port 1: Dev 3, If 0, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 1: Dev 3, If 2, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 1: Dev 3, If 3, Class=Human Interface Device, Driver=usbhid, 12M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
|__ Port 1: Dev 3, If 0, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 1: Dev 3, If 1, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 1: Dev 3, If 2, Class=Human Interface Device, Driver=usbhid, 12M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/8p, 480M
bsoering@Bienenstand:/dev/bus/usb$ ls
001 002 003 004 005
bsoering@Bienenstand:/dev/bus/usb$ cd /sys/bus/usb
bsoering@Bienenstand:/sys/bus/usb$ ls
devices drivers drivers_autoprobe drivers_probe uevent
bsoering@Bienenstand:/sys/bus/usb$ cd devices
bsoering@Bienenstand:/sys/bus/usb/devices$ ls
1-0:1.0 2-1:1.0 3-0:1.0 3-1:1.2 5-0:1.0 5-1:1.1 usb1 usb4
2-0:1.0 2-1:1.1 3-1 3-1:1.3 5-1 5-2 usb2 usb5
2-1 2-1:1.2 3-1:1.0 4-0:1.0 5-1:1.0 5-2:1.0 usb3
bsoering@Bienenstand:/sys/bus/usb/devices$
Habe es aber anscheinend über diese Anleitung hinbekommen. War anscheinend ein Fehler in Linux selbst, nach Installation von ein paar Updates. Auf alle fälle startet saraswati jetzt auch selbsttätig ohne Probleme. Nur in der GUI unter Menu/Einstellungen/Klang/Eingang werden die Soundkarten bis zum ersten Restart von saraswati nicht angezeigt. Womit man aber durchaus leben kann.
Wunderbar, dann könnten die bei Erschließung von Saraswati für den Betrieb auf einem Industrie PC, mit Upload per SSH+rsync auf Synology NAS - #43 by Andreas beschriebenen Verbesserungen der Systemd Unit Konfiguration vielleicht wirklich hilfreich sein:
bsoering@Bienenstand:~$ sudo pip3 install saraswati --upgrade
[sudo] Passwort für bsoering:
Collecting saraswati
Downloading saraswati-0.6.0.tar.gz (31 kB)
Requirement already satisfied, skipping upgrade: appdirs<2,>=1.3 in /usr/local/lib/python3.8/dist-packages (from saraswati) (1.4.4)
Requirement already satisfied, skipping upgrade: click<8,>=7.1.2 in /usr/local/lib/python3.8/dist-packages (from saraswati) (7.1.2)
Requirement already satisfied, skipping upgrade: cloup<0.9,>=0.8.0 in /usr/local/lib/python3.8/dist-packages (from saraswati) (0.8.2)
Requirement already satisfied, skipping upgrade: teetime<0.1,>=0.0.3 in /usr/local/lib/python3.8/dist-packages (from saraswati) (0.0.3)
Building wheels for collected packages: saraswati
Building wheel for saraswati (setup.py) ... done
Created wheel for saraswati: filename=saraswati-0.6.0-py3-none-any.whl size=28415 sha256=48aea257891abe19d4191587265df0c5e02150a2a72dc4a3c07056e5e44252dd
Stored in directory: /root/.cache/pip/wheels/64/ad/c4/f6a1fe7703cfa942ce2ebd8d41c8f8ea878cf0eddfb0d5f923
Successfully built saraswati
Installing collected packages: saraswati
Attempting uninstall: saraswati
Found existing installation: saraswati 0.5.0
Uninstalling saraswati-0.5.0:
Successfully uninstalled saraswati-0.5.0
Successfully installed saraswati-0.6.0
bsoering@Bienenstand:~$ sudo saraswati setup --systemd
WARNING: /etc/default/saraswati already exists, skip copying
cp: Aufruf von stat für '/usr/local/lib/python3.8/dist-packages/saraswati/setup/systemd/saraswati.path' nicht möglich: Datei oder Verzeichnis nicht gefunden
Saraswati unit enabled successfully. The service will start when /dev/bus/usb is not empty.
bsoering@Bienenstand:~$
Anschliesend ich natürlich noch die Config, um die fehlende Optionen ergänzt.
cd /etc/default
sudo nano saraswati
und dort dann die Zeilen hinzugefügt.
# Configure audio recording container
# SARASWATI_CONTAINER_FORMAT=matroska
# SARASWATI_CONTAINER_FORMAT=ogg
Scheint auf dem Bienenstand und auch bei dem Test-Rechner, wo das Problem bis dahin noch nicht behoben wurde jetzt problemlos zu laufen.
Nur der sonic Visualiser in Windows scheint das flac im .ogg Container immer noch nicht zu mögen.
mit .wav oder flac ohne Container bin ich momentan auf dem Testrechner am testen.
flac sollte da aber theoretisch Probleme machen.
gst-launch-1.0 autoaudiosrc ! splitmuxsink location=output_%d.wav muxer=wavenc max-size-time=60000000000
bzw.
gst-launch-1.0 autoaudiosrc ! splitmuxsink location=output_%d.flac muxer=flacenc max-size-time=60000000000
Edit:
Beide Files laufen im Sonic Visualiser da wir ja momentan nicht direkt über W-Lan Streamen
werde ich meinen Testserver mal auf Flac ohne container umstellen.
Da ich die Umstellung “quickanddirty” manuell auf dem Linux gemacht habe, hab ich es nochmal auf meiner Gabel aus der Hüfte nachgepflegt. Bitte den Pullrequest #14 vorher genau prüfen.
Muß noch rausfinden wie ich eine Git-Gabel über pip installieren kann.
Das klappt zum Beispiel so:
pip install git+https://github.com/MKO1640/saraswati.git@dev-MKO1640
Habe saraswati auf dem live server auf Flac umgestellt und es läuft jetzt wieder seit einem Tag stabil.
Auch Stromausfälle nimmt er achtlos entgegen.
Der SonicVisualiser nimmt diese Daten jetzt auch problemlos.
wir sollten bei Gelegenheit noch überprüfen, ob was mit der OGG - Flac Kombination nicht stimmt.
Ich überlege wie ich die vorher aufgezeichneten Daten jetzt am besten ebenfalls auf Flac umzuwandeln bzw. aus den Containern auspacken kann. Das NAS baut auf Unix auf und hat einen 1,2MHz Prozessor. Hatte daher überlegt das mit GStreamer direkt auf dem NAS zu machen. Leider ist es kein Debian-Linux, daher funktioniert apt-get nicht. Ich suche derzeit noch das Pendant für Unix.
Ansonsten heißt es, 110Gb runterzuladen, zu entpacken und wieder hochzuladen.
Hi Michael,
vielen Dank für Deine Arbeiten und Beiträge zu diesem Thema.
Wunderbar!
Bei jenem Aspekt, der Einrichtung der Benutzerkonfiguration für die Datenübertragung per rsync, wollte ich noch einmal nachhaken, damit wir nicht vergessen, alle gewonnenen Erkenntnisse für zukünftige Installationen optimal umzusetzen.
Die Essenz hieraus wäre, der Doku von Saraswati noch einen Abschnitt zu spendieren, wie man eine Synology NAS entsprechend konfiguriert. Darin gehören die wesentlichen Inhalte von
– richtig?
Wie oben geschrieben, würde mich interessieren, ob nun "sudo saraswati setup --systemd" vollständig ausreichend ist und dann alles out-of-the-box funktioniert, ohne noch an irgendwelchen Dateien händisch rumfummeln zu müssen. Vielleicht kannst Du das bei Gelegenheit noch einmal mit einer frischen Installation testen?
Viele Grüße,
Andreas.
Richtig, habe hier auch noch ein Ready NAS Duo, bei dem jedoch eine Festplatte das zeitliche gesegnet hat. wenn ich das zum laufen bekommen habe werde ich das auch nochmal testen und schauen, ob man damit ähnlich arbeiten kann.
Ja funktioniert, habe ich bei meinem test-Rechner bereits gemacht. Den SSH Schlüssel musste ich aber selbst reinkopieren, was auch sicherlich so gedacht ist. Die Rechte waren aber glaube ich richtig gesetzt. Werde das die Tage aber nochmal Testen.
Habe auch schon versucht Saraswati auf einem Raspberry Pi Zero W mit OS lite zu Installieren, was aber leider nicht geklappt hat. Obwohl ich einiges zusätzlich nachinstalliert habe, habe ich nicht rausfinden können, was mir noch fehlt. gst-device-monitor-1.0 | grep gst-launch zeigt mir keine verfügbaren audio Geräte an. ALSA, Pulseaudio und div. plugins dafür habe ich bereits ausprobiert. Alsa und Pulseaudio funktionieren aber sonst problemlos.
Außerdem habe ich es auf meinen Testrechner auch mal mit ubuntu-20.04.2-live-server-amd64 ohne GUI probiert, wo ich auch teile von ALSA und Pulseaudio nachinstallieren musste, es dann schlussendlich lief. Rsync habe ich bisher dort aber noch nicht probiert.
Wunderbar. Danke!
Schade.
Damit ist das Problem wohl “out of scope” von Saraswati selbst? Mich würde aber trotzdem interessieren, was hier genau hakt.
a) Was sagt denn $ gst-launch-1.0 --version bei Dir?
b) Was ist denn OS lite genau? Im Endeffekt auch nur ein Debian? Welches?
c) Findet $ gst-device-monitor-1.0 (ohne grep gst-launch) überhaupt irgendwelche Audiogeräte oder zeigt andere Dinge an? Hast Du es sicherheitshalber auch als root Nutzer versucht?
Wunderbar. Welche Pakete mussten denn noch nachinstalliert werden? Hierbei schiele ich auf eine Verbesserung der Dokumentation bei Install prerequisites » Debian-based systems.