Alarmdurchsage dekodieren

[grinsekatze003]

Hallo!

Ich versuche seit geraumer Zeit verzweifelt die Alarmdurchsagen (ZVEI) aufzunehmen und zu dekodieren. Zunächst habe ich folgenden PR probiert (#327), damit aber keinen Erfolg erzielt, da kein Alarm mehr ausgelöst wird. Anschließend habe ich die Änderungen in folgendem Issue vorgenommen (#164). Die Ausgabe des rtl_fm Streams wurde dadurch in eine Datei geschrieben. Diese wollte ich nun abspielen bzw. in eine WAV Datei umwandeln. Ich habe folgendes probiert:

sox -t raw -r 22050 -b 16 -L -es datei.raw datei.wav

Wenn ich die wav Datei abspiele, kann ich eine Durchsage erkennen, die Sprache wirkt jedoch "verwaschen", fast so als wäre es nicht Deutsch, sondern eine andere Sprache. Schwer zu beschreiben.

Woran kann das liegen? Habe ich falsch dekodiert oder ist der Empfang bei der Aufnahme zu schlecht? Wie kann ich hier vorgehen um den Fehler zu finden?

Danke für eure Hilfe!

[MarioSDR93]

Das Problem mit der verwaschenen/schlecht verständlichen Sprache hatte ich auch. Ich hab aber auch noch keine Lösung gefunden.

[flothi]

Was geschieht denn, wenn du den Stream direkt mittels rtl_fm aufnimmst?

[grinsekatze003]

Das Problem mit der verwaschenen Sprache konnte ich klären, jedoch nicht beheben. Die einzige Möglichkeit vernünftig aufzunehmen, ist wohl den Stream mittels tee zu duplizieren. In dem verlinkten Issue (von @MarioGeckler), wird der Stream ohne Verwendung von tee mit cat verwendet. Dadurch "kämpft" sowohl multimon als auch cat um den Stream und jeder erhält abwechselnd einen Bruchteil -> sowohl die Alarmierung mit multimon ist nicht mehr zuverlässig, als auch die Sprachausgabe mit cat ist fehlerhaft. Hätte ich eigentlich gleich dahinter kommen können.

Leider klappt der vorgeschlagene PR bei mir noch nicht, da habe ich aber gerade im PR etwas dazu geschrieben.

[Schrolli91]

Wäre auf jeden Fall super, wenn Ihr berichtet, falls sich was ergibt.
Aktuell arbeite ich nämlich an BOSWatch 3 - einem kompletten reWrite des ganzem.

Die Möglichkeit der Audiomitschnitte würde ich dort gerne integrieren.

[grinsekatze003]

Nach mehreren Tagen/Wochen intensivem Test mal ein Feedback... Mittlerweile läuft das von mir angepasste Record Plugin seit mehreren Tagen problemlos und es werden keine Alarme verschluckt.

1. Die einzige Möglichkeit den Stream vernünftig aufzunehmen, ist diesen mit Hilfe von tee zu duplizieren. Die Möglichkeit im verlinkten Issue funktioniert nicht, da keine Duplizierung des Streams vorgenommen wird und die Sprachausgabe somit fehlerhaft wird.

2. Im vorgeschlagenen PR wird multimon-ng, rtl_fm und nun auch aplay mittels Pythons subprocess gestartet. Ich halte das für keine gute Idee, da Python als Programmiersprache meiner Meinung nach für so etwas nicht geeignet ist. Besser wäre es - auch im Hinblick auf Boswatch 3 - die ganzen Anwendungen per Bash-Script zu starten und Boswatch/Python als Auswertemöglichkeit zu nutzen. Ich könnte mir z.B. vorstellen, dass ein Bash-Script multimon-ng, rtl_fm und aplay startet und das Ergebnis nach Boswatch gepiped wird. Das ist aber nur eine Frage der Architektur (z.B. .... | multimon_ng | boswatch3)

3. Wie bereits erwähnt werden im PR die drei Softwaremodule per Pythons subprocess gestartet. Ich habe es damit NICHT hinbekommen die Alarmierung vernünftig, d.h. ohne fehlende Alarme, aufzunehmen. Mit dem PR ist die Alarmierung nicht mehr zuverlässig und manche Alarme werden von Multimon nicht erkannt. Komischerweise hat ein rtl_fm ... | tee >(aplay ...) | multimon-ng ... auf der Konsole keinen Alarm verschluckt. Daher habe ich versucht den kompletten Prozess (rtl_fm ... | tee >(aplay ...) | multimon-ng ...) in Pythons subprocess zu starten. Auch hier wurden Alarme verschluckt.. Letzendlich bin ich dann auf eine Lösung gekommen..

4. Ich habe eine Bash-Datei angelegt, in welcher das Kommando zusammengebaut liegt (rtl_fm ... | tee >(aplay ...) | multimon-ng ...). Diese Bash-Datei wird anschließend in Boswatch mittels subprocess gestartet (bash /opt/boswatch/script.sh). Nun werden keine Alarme mehr verschluckt. Scheinbar! startet das subprocess Modul von Python die Prozesse anders, wenn sie einzeln gestartet werden, oder gerät in eine Deadlock/Buffer Situation. Ich kann es nicht genau erklären, Fakt ist aber, dass nur per extern gestarteten Bash-Script die Alarmierung und die Aufnahme problemlos läuft.

Falls ich irgendwie helfen kann das in Boswatch3 zu integrieren, helfe ich gerne! @Schrolli91

[Schrolli91]

SUPER - Danke für deine Mühen - Und über das Angebot der Hilfe zur BW3 integration bin ich natürlich auch dankbar.

Im ersten Schritt wäre es toll, wenn du dein Ergebnis hier mal als Pull Request zur Verfügung stellen würdest. Dann könnten mehr User eine saubere Funktion verifizieren und wir können den aktuellen PR der scheinbar nicht richtig zu funktionieren scheint, schließen.

[Schrolli91]

Siehe #220 wäre diese Funktion nicht ganz einfach zu implementieren?
Eine eigene Bash-Datei für jede Eingangs-Verarbeitungs-Kombo?
Statt rtl_fm zu pipen wird dann einfach der Audio-Eingang genutzt.

Sollte doch machbar sein @grinsekatze003

[grinsekatze003]

Das klingt gut! Den PR werde ich in den nächsten Tagen vorbereiten. Das mit der Bash-Datei klingt gut - eventuell könnte man ja im Setup-Prozess die Bash-Datei entsprechend aufbauen, indem verschiedene Sachen abgefragt werden (z.B. Soll rtl_fm verwendet werden? Ist eine Aufnahme gewünscht?) -> die entsprechenden Kommandos werden in die Bash-Datei eingefügt.

[Schrolli91]

Könnte man so machen.
Flexibler wäre man aber, wenn es einfach verschiedene Bash Files gibt, und ich in der config meine gewünscht Angeben kann. So müsste man nicht jedes mal den Installer laufen lassen.

[grinsekatze003]

Hallo @Schrolli91,

hier wie versprochen meine Anpassungen - bewusst ohne PR. 1 zu 1 lassen sie sich so und so nicht übernehmen und außerdem sind die Variablen in der script.sh hart codiert.

Diff boswatch.py: https://www.diffchecker.com/4dyrHV85
Inhalt script.sh:

#!/bin/bash

mkfifo /opt/boswatch/pipe
rtl_fm -d 0 -f FREQUENZ -M fm -p 0 -E DC -F 0 -l 0 -g 100 -s 22050 | tee >(aplay -t raw -r 22050 -f S16_LE /dev/stdin > /dev/null) >/opt/boswatch/pipe & sleep 5; multimon-ng -a ZVEI1 -f alpha -t raw - </opt/boswatch/pipe | tee /opt/boswatch/multimon_output.raw

Erklärung: boswatch.py startet anstelle von rtl_fm, multimon & co. nur noch die Bash-Datei script.sh und liest deren Standard-Ausgabe. In der script.sh wird eine Named Pipe im Boswatch Verzeichnis erstellt, welche die Ausgabe von rtl_fm wiedergibt. Anschließend wird rtl_fm gestartet und dessen Ausgabe in die Named Pipe und nach aplay gegeben. Nach einer Wartezeit von 5 Sekunden (diese war bei mir notwendig, sonst funktioniert multimon manchmal! nicht), wird multimon gestartet und bedient sich aus der Named Pipe. Die Ausgabe von multimon wird sowohl in die Textdatei multimon_output.raw geschrieben, als auch über die normale Standard-Ausgabe zur Weiterverarbeitung in boswatch.py genutzt.

Mit diesem Setup läuft die Alarmierung und Aufnahme seit Tagen stabil. Lediglich das sleep 5 Timeout ist später dazu gekommen, da sich multimon sonst ab und an verschluckte. Eventuell könnte man das Timeout auch verkleinern, mich störten die einmaligen 5 Sekunden beim Start jedoch nicht. Vorteil der Named Pipe ist, dass man auch immer mal wieder debuggen kann, ob rtl_fm noch Ausgaben bringt oder ob da etwas fehlschlägt.

Achtung: Es ist natürlich nicht gut mittels shell=True per Python ein Bash-Script zu starten. Deshalb würde ich mir für Boswatch 3 wünschen: Startet die ganzen Programme (rtl_fm, multimon, aplay etc.) nicht innerhalb von Boswatch, sondern überlasst das Bash. Boswatch sollte nur die Ausgabe von multimon erhalten und weiterverarbeiten (z.B. rtl_fm .. | bla | multimon ... | python boswatch.py). So könnte man dann auch die Ausgaben von externen Scannern etc. verwenden und nach Boswatch schleusen.

Zusammenfassend kann ich auch jetzt nachträglich nicht genau sagen, warum der vorgeschlagene PR (welcher alle Programme direkt mittels Python startet), bei mir nicht zuverlässig funktioniert. Vermutlich startet Python die Prozesse - irgendwie - anders als Bash direkt. Ich möchte mich da aber auch nicht weiter vertiefen und freue mich, dass ich jetzt eine zufriedenstellende Lösung gefunden habe!

[Schrolli91]

@grinsekatze003 Könntest du noch ein paar Worte zur Aufnahme verlieren? Läuft die dauerhaft? Nur im Alarmfall? Das erschließt sich mir gerade spontan nicht ganz.

EDIT:
Mal so als Fallstudie, @grinsekatze003 hälst du das für Moglich:

• Bashfile welches für den Input verantwortlich ist und dann entweder rtl_fm oder eine andere Eingabequelle (zB Soundkarte) startet und diese in die named Pipe schreiben lässt

• multimon.sh welche die Daten aus der named Pipe abgreift, und damit macht was multimon eben so macht :-P und das ganze am Ende an BOSWatch weitergibt

• record.sh welche zB beim Alarm aufgerufen wird, sich der named Pipe bedient und für eine fixe Zeit in ein Audio File aufnimmt

[grinsekatze003]

Hallo @Schrolli91,

sorry für die verspätete Antwort. Die Aufnahme läuft nur im Alarmfall und wird über das Plugin "record" aus dem genannten PR gestartet. Heißt im Klartext: Ich nutze das Plugin aus dem PR erweitert mit meinen Anpassungen. Momentan habe ich eingestellt, dass das Plugin record für jede ZVEI läuft. Es läuft also genau so wie du beschrieben hast. 👍

Angepasste Dateien:

• boswatch.py (siehe oben)
• script.sh (siehe oben)
• plugins/record (aus PR übernommen)
• config.ini (um Record Plugin zu starten)