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)

[grinsekatze003]

Hallo @Schrolli91,

wie gehen denn die Arbeiten an Boswatch 3 voran? Gibt es eine einen Release-Termin? Bin gerne behilflich das Record Plugin für Boswatch 3 zu schreiben..

[MrCoopa]

Gibt es hier Neuigkeiten? Leider funktioniert die oben beschriebene Methode bei mir nicht.

[Frone87]

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. +1

Angepasste Dateien:

* boswatch.py (siehe oben)

* script.sh (siehe oben)

* plugins/record (aus PR übernommen)

* config.ini (um Record Plugin zu starten)

Hallo grinsekatze003,

erstmal vielen Dank für die Anleitung.
Die Aufnahme funktioniert tadellos.

Gibt es eine Möglichkeit statt pro Schleife eine Aufnahme sondern bei erneutert Alarmierung einen retrigger (Verlängerung der Aufnahme) zu starten?

Würde mich über eine Antwort freuen.

Grüße

[MrCoopa]

Nach langem hin und her läuft es auch bei mir.
Das eine Alarmierung nur eine Audiodatei hat, wäre super. Man müsste das Plugin warten lassen und erst dann die Aufnahme nach der letzten ZVEI starten. Aufnahmezeit + meinetwegen 2-3 Sekunden Sekunden pro folgender ZVEI.
Vlt kann sich da jemand noch mal Gedanken drüber machen, leider reichen meine Kenntnisse da nicht.

[Schrolli91]

Da BOSWatch 3 aktuell nahe an einem ersten "Testbaren" Stand ist, wird dieses Thema auch für mich wieder interessanter ;-)

Muss mir mal Gedanken machen, wie man das Software-Architektonisch unterbringen kann

EDIT: Auf jeden Fall muss es der Client machen, da der Server ja nicht an den Audio Stream ran kommt 🤔

[Nortfid]

Läuft die Record-Funktion unter:
SW Version: 2.4.2
Branch: master
Build Date: 11.03.2019

Bin gerade am anpassen der boswatch.py, aber die sieht mittlerweile schon wieder komplett anders aus.

[Nortfid]

Nach langem hin und her läuft es auch bei mir.
Das eine Alarmierung nur eine Audiodatei hat, wäre super. Man müsste das Plugin warten lassen und erst dann die Aufnahme nach der letzten ZVEI starten. Aufnahmezeit + meinetwegen 2-3 Sekunden Sekunden pro folgender ZVEI.
Vlt kann sich da jemand noch mal Gedanken drüber machen, leider reichen meine Kenntnisse da nicht.

Magst du mir deine Dateien zur Verfügung stellen?

[nobbie2009]

habe schon im bwcc.... geschrieben... vielleicht gehts hier besser...

• Habe mir die Dateien hier so zusammengezogen, sprich die boswatch.py gemäß dem Link oben abgeändert (auch zweimal gegengelesen),
• den record-PluginOrdner eingefügt,
• die Config entsprechend geändert,
• den Speicherordner in den Ordner

/home/pi/BOSWatch/recordings

geändert.

• die Zeilen unter PULSE hinzugefügt

• die Script.sh erstellt und die entsprechende Frequenz eingegeben (dort wo "FREQUENZ" steht)

Der Start erfolgt ja mittels sudo python boswatch.py -f "FREQUENZ" -a ZVEI -v
Er erkennt die Alarme, löst laut den DEGBUG Meldungen auch die Aufnahme auf, auch in den LOGs von boswatch steht nix auffälliges.
Schau ich dann aber im Ordner /home/pi/BOSWatch/recordings nach ist keine einzige Datei vorhanden.

was mache ich falsch?

[Nortfid]

Hast du Schreibrechte für den Ordner?

[nobbie2009]

755 - ja

habe da mal noch eine logdatei gefunden: record.log

ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM pulse arecord: main:788: audio open error: No such file or directory

[nobbie2009]

testweise jetzt auch auf 777 gesetzt.

also pulseaudio ist installiert, er erkennt aber diesen nicht als "pulse" über die alsa.conf.

Mit
amixer controls

habe ich das einzige welches auf ein PCM verweist und das nennt sich iec958,
als ich dies in die Command des RecordPlugins übernommen habe also aus:

command+"arecord -D pulse -f cd -d "+str(rec_duration)+" -c 1 "+str(rec_filepath)+str(filename)+""

command+"arecord -D iec958 -f cd -d "+str(rec_duration)+" -c 1 "+str(rec_filepath)+str(filename)+""

gemacht, ist zumindest die Meldung
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM pulse
verschwunden.

Aber
arecord: main:788: audio open error: No such file or directory

bleibt

1. weiß ich nicht ob iec958 der richtige Stream ist
2. sehe ich gerade nicht durch warum arecord nach wie vor keine file or directory findet
3. finde ich auch keinen Hinweis in Google zu diesen Fehler der auf diese Audioquelle passt.

[nobbie2009]

OK, mittlerweile läuft es, habe es auf dem mattermost beschrieben, allerdings haut das mit dem Autostart als Service nicht hin, muss es jedesmal manuell starten, da er sonst leere Dateien aufnimmt.
Sobald ich Pulse als Service starte funktioniert es nicht mehr.

[stoepf]

Wie bekommt man den einen Mattermost-Account?
Hab schon mit 2 verschiedenen Emailadresse eine Anmeldung veruscht, hab aber nie eine Mail bekommen.

[Schrolli91]

@stoepf das ist eigenartig, bisher hat das wohl einwandfrei funktioniert. Dein Konto scheint im BWCC auch aktiviert worden zu sein, daher sollte ein Login möglich sein.

[StahlTim]

Hallo zusammen,

die Thematik klingt super spannend und möchte ich auch auf meinem Server umsetzen!
Da die alten Nachrichten (vor Apr. 2020) im Mattermost nicht mehr einsehbar sind, hier die Frage(n):

• Was ist der letzte Stand in dieser Hinsicht?
• Bastelt sich jeder das Setup wie von @grinsekatze003 beschrieben zusammen? (Wie habt ihr das gemacht @nobbie2009 , @MrCoopa ?)
• Geht das beschriebene Verfahren noch mit der aktuellen Version von boswatch (V2)?
• Gibt es ggf. ein Repo / Fork / ... auf dem das ganze schon umgesetzt wurde?

[maddig21]

Hallo zusammen,

ich schließe mich @StahlTim an. Bevor ich anfange daran zu basteln, gibt es einen Release in dem das implementiert ist?

Vielen Dank für euren Einsatz.

[Frone87]

Hallo Zusammen,

ich habe eine simple und einfache Lösung die mittlerweile seit über einem Jahr tadellos funktioniert.
Ich versuche über die Feiertage ein REpo/Fork zu erstellen.

[maddig21]

Hallo @Frone87,

das wäre top, danke dir schonmal.

[Schrolli91]

@Frone87 gerne die Funktion anschließend per Pull Request bereitstellen, wenn du magst

[maddig21]

Hallo @Frone87 ,

konntest du schon mal schauen? Warte sehnsüchtig darauf, damit ich von Scanner auf SDR umstellen kann.

Danke dir :)

[Frone87]

Hallo @Frone87 ,

konntest du schon mal schauen? Warte sehnsüchtig darauf, damit ich von Scanner auf SDR umstellen kann.

Danke dir :)

schreib mich mal persönlich über boswatch(dot).de an.

[Leitner1]

Hallo zusammen,
ich interessiere mich auch sehr dafür!
Gibt es hier mittlerweile irgendetwas fertiges das unter BW 2.5.2 stabil läuft?
Danke! :-)