Regelmäßige Ansagen

Hallo in die Runde,

habe mich gerade frisch im Forum angemeldet, nachdem ich schon eine Weile interessiert mitlese. Seit kurzem läuft bei mir eine svxlink-Installation (13.03 - ja ich weiß es ist nicht neueste) auf einem Raspi als Simplex-Logik auf unserer Ortsfrequenz.

Ich würde gerne in regelmäßigen Abständen, z.B. alle halbe Stunde, eine oder mehrere wav-Dateien abspielen lassen, möglichst, wenn kein QSO läuft, also wenn SQL geschlossen ist. Mein großes Problem ist, daß ich trotz viel Sucherei nicht herausfinden konnte, wo ich mich mit einer selbstgeschriebenen Prozedur einklinken kann, damit diese regelmäßig aufgerufen wird. Ich kann sicherlich eine .tcl-Datei in ein local Verzeichnis stellen. Die Datei kann dann auch die von mir geschriebene Prozedur enthalten mit einem beliebigen Namen, aber natürlich muß die Prozedur ja noch von irgendwoher aufgerufen werden.

Könnt Ihr mir einen Tipp geben, wie ich eine eigene Funktion einklinken kann?

Vielleicht noch ein Beispiel zur Illustration:
Wenn es irgenwie gelingt, regelmäßig Unwetterwarnungen in eine wav-Datei zu konvertieren und in einem Verzeichnis bereitzustellen, soll diese regelmäßig aufgerufenen Funktion die wav's einfach abspielen. Oder ein Hinweis auf den nächsten OV-Abend könnte regelmäßig durchgesagt werden, etc.

Vielen Dank vorab für Eure Hilfe.

Gruß,
Christian
DL2CST

Hallo Christian,

willkommen hier im SvxLink-Forum.
Auf Anhieb würden mir da die Prozeduren

Logic::send_long_identLogic::send_short_identLogic::manual_identification

einfallen (siehe /usr/share/svxlink/events.d/Logic.tcl). Diese Prozeduren überschreibst Du einfach mit Hilfe des Locale-Konzepts durch Funktionen in einer eigenen tcl-Datei.

Ein kleines Beispiel (Datei local-ansage.tcl):

namespace eval Logic {  proc send_shirt_ident {{hour -1} {minute -1}} {  global mycall;  variable CFG_TYPE;  spellWord $mycall;  playSilence 500;  playMsg "Core" "unwetterwarnung";  playSilence 500;  }}

Das soll nur ein kleines Beispiel sein, es achtet nicht darauf ob gerade gesprochen wird und gibt in den konfigurierten Abständen immer die Unwetterwarnung aus. Man kann das jetzt noch erweitern, z.B. durch das sourcen einer weiteren tcl-Datei, in der Du ein Flag setzt ob oder ob nicht die Warnung ausgegeben wird:

namespace eval Logic {  proc send_shirt_ident {{hour -1} {minute -1}} {    global mycall;    variable CFG_TYPE;    set warnung 0;    source "meine.tcl";    spellWord $mycall;    playSilence 500;    if {$warnung != 1} {       playMsg "Core" "unwetterwarnung";       playSilence 500;    }  }}

meine.tcl enthält dann nur eine Zeile z.B.:

set warnung 1; # schaltet Warnung ein

oder

set warnung 0; # schaltet Warnung aus

So kannst Du das zur Laufzeit konfigurieren ohne SvxLink jedes Mal neu starten zu müssen.
Was die Rauschsperrenerkennung anbetrifft, so werde ich mich in den nächsten Tagen darum kümmern,weil das von anderen OMs auch schon gewünscht wurde. Soweit erst mal ok?

vy 73's de Adi, DL1HRC

Hi Adi,

vielen Dank für die schnelle Antwort. Ich werde es ausprobieren und melde mich dann zurück.

Gruß,
Ch.

Hi Adi,

ich habe es ausprobiert, und es funktioniert ganz prima. Vielen Dank!

Jetzt kann ich an dieser Stelle weiterexperimentieren.

Es schien mir übrigens so, daß wir auch die Aufgabe, nicht in ein laufendes QSO zu sprechen, damit gelöst haben, da nach meiner Beobachtung svxlink dies von sich aus nicht tut. Mir scheint es so zu sein, daß die Ansage einfach übersprungen wird, wenn zu der Zeit gerade ein QSO läuft, also die SQL offen ist. Das muß ich aber nochmal genau untersuchen. Habe ich gestern nur im Vorbeigehen registriert.

Ich denke, daß der Mechanismus aus Deinem Tipp eine gute Realisierungsvariante für Anwendungen aus der Kategorie "regelmäßig wiederkehrend und nicht durch ein Modul aktiviert" sein kann. Da fallen dann z.B. Verkehrsinfos, Unwetterwarnungen, Einladungen zu OV-Abenden, usw. darunter.

Ich habe dazu die Idee im Kopf, daß man die Datenbeschaffung außerhalb von svxlink z.B. mit cron und einem Script programmiert. Diese Mimik legt dann die abspielbereiten wav's in ein bestimmtes Verzeichnis, von wo sie dann mit svxlink regelmäßig abgespielt werden. Man kann da sicher mit ein wenig Programmierung die Häufigkeit der unterschiedlichen Ansagen steuern. Nicht alles will man vielleicht immer im kürzest möglichen Zeitraster hören.

Hier gleich noch eine Frage an Dich:

Weißt Du oder jemand im Forum, ob Variablen in einer Prozedur bis zum nächsten Aufruf der Prozedur erhalten bleiben? In C++ würde man dafür globale Variablen nehmen. Bei tcl kenne ich micht gut genug aus, müßte es ausprobieren.
Wenn das so wäre, könnte man sich durch Hochzählen einer Variable einen einfachen Mechanismus implementieren, daß eine Ansage z.B. nur jedes zweite oder dritte mal abgespielt wird.

Bin wie immer für Tipps dankbar.

73,
Christian

Hallo Christian,

freut mich, dass es gleich auf Anhieb geklappt hat. Das alles kann man natürlich noch extrem ausbauen und zur Perfektion treiben

Quote

Mir scheint es so zu sein, daß die Ansage einfach übersprungen wird, wenn zu der Zeit gerade ein QSO läuft, also die SQL offen ist. Das muß ich aber nochmal genau untersuchen. Habe ich gestern nur im Vorbeigehen registriert.

Hm, ich glaube da noch nicht dran, ich denke eher, dass die Ansagen nur "leisegetastet" werden. Aber das Ereignis "Squelch offen" bzw. "Squelch geschlossen" ist im Namespace bekannt, da ja jedes Mal eine Prozedur aufgerufen wird. Man kann das also überall einbauen. Wie schon gesagt, ich arbeite dran, nächste Woche.

Quote

Ich denke, daß der Mechanismus aus Deinem Tipp eine gute Realisierungsvariante für Anwendungen aus der Kategorie "regelmäßig wiederkehrend und nicht durch ein Modul aktiviert" sein kann. Da fallen dann z.B. Verkehrsinfos, Unwetterwarnungen, Einladungen zu OV-Abenden, usw. darunter.

Ja, sowohl als auch. Unwetterwarnungen und Meldungen über Falschfahrer sollten natürlich in dem Moment ausgegeben werden in den sie dem System bekannt sind. Auf WSF habe ich das so umgesetzt:
* Meldung eingegeangen -> sofortige Ausgabe
* Speicherung der Meldung für 2 Stunden
* jederzeit abrufbar per Modulaktivierung (z.B. 8#2# -> Modul 8 wird gestartet dann gibt 2# die Meldungen der Reihe nach aus)
* regelmäßige Ansage zur vollen/halben Stunde "DL0WSF, es ist 12Uhr, es gibt 3 neue Verkehrsinformationen und 3 neue Unwettermeldungen"

Kann man alles umbiegen wie man möchte

Quote

Weißt Du oder jemand im Forum, ob Variablen in einer Prozedur bis zum nächsten Aufruf der Prozedur erhalten bleiben? In C++ würde man dafür globale Variablen nehmen. Bei tcl kenne ich micht gut genug aus, müßte es ausprobieren.

Ja, bin auch nicht so der TCLer. Ich glaube nicht, dass eine globale Variable etwas nützt, weil bei einer eingehenden Echolinkverbindung z.B. das gesamte TCl-Framework neu geladen wird. Das kannst Du prüfen, indem Du in der events.tcl am Ende bei

source $file;

noch ein

puts "lade $file";

einfügst. Das erschwert die Speicherung von Variablen im tcl-Space natürlich ganz erheblich. Wenn also entsprechende Änderungen erforderlich sein sollten, so sollten wir das im C++-Core vorsehen. Macht meiner Meinung nach auch Sinn, weil es normalerweise schneller ist und man auch strategisch eine bessere Trennung Core-Ebene zu Präsentationsebene hinbekommt. Wenn man zu viel Intelligenz ins TCL auslagert schafft das neue Probleme.
Ach so, fällt mir gerade ein, eventuell würde es gehen einen neuen Namespace z.B. "global_params" aufzumachen, in dem Du Deine globalen Parameter hälst. Dieser wird nicht neu gesourced sondern nur einmalig beim Start von SvxLink...sollte klappen...mal ausprobieren.

Quote

Wenn das so wäre, könnte man sich durch Hochzählen einer Variable einen einfachen Mechanismus implementieren, daß eine Ansage z.B. nur jedes zweite oder dritte mal abgespielt wird.

Siehe oben, muß man mal checken. Alternativ ein Vergleich mit der Uhrzeit in Minuten: Ausgabe nur innerhalb der ersten 20 Minuten oder mit mod-Funktion eine Ausgabe nur jede xx-Minute realisieren usw.

vy 73's de Adi, DL1HRC

Hi Adi,

vielen Dank für Deine Tipps. Werde ich alles mal durchdenken und ausprobieren, sobald ich dazu komme.

Du schreibst:

Quote

Unwetterwarnungen und Meldungen über Falschfahrer sollten natürlich in dem Moment ausgegeben werden in den sie dem System bekannt sind. Auf WSF habe ich das so umgesetzt:
* Meldung eingegeangen -> sofortige Ausgabe

Wie hast Du die sofortige Ausgabe getriggert?
Realisierst Du die die regelmäßigen Ausgaben auch so, wie wir besprochen haben?

Gruß,
Ch.

Hi Christian,

Quote

Wie hast Du die sofortige Ausgabe getriggert?

Habe ein eigenes tcl-Modul gebastelt, analog zum PropagationMonitor. Der schaut jede volle Minute in einem Spool-Verzeichnis nach ob es neue Meldungen gibt. Also "Sofortige Ausgabe" heißt im ungünstigsten Fall mit 59 Sekunden Verzögerung.

Quote

Realisierst Du die die regelmäßigen Ausgaben auch so, wie wir besprochen haben?

Ja, auch über eine eigene tcl-Prozedur, die die Original-Funktionen ersetzt (innerhalb des "Logic"-Namespaces).

vy 73's de adi, DL1HRC

cool

Jetzt habe ich erst mal genug Stoff, um in der nächsten Zeit Einiges auszuprobieren 8-)

Melde mich wieder, wenn ich neue Erkenntnisse habe.

Vielen Dank an Adi. Du hast mir sehr weitergeholfen.

73,
Ch.