Modul TrafficInfo

Hi,

für die Ausgabe der Verkehrsmeldungen stehen verschiedene Quellen zur Verfügung, Michael (DK5HH), favorisiert die Bremer Verkehrsmeldezentrale, ich habe das inzwischen auch auf anderem Wege realisiert.
Um nun beide (und möglicherweise mehr) Varianten unter einen Hut zu bekommen würde ich die folgende Herangehensweise vorschlagen:

Die Meldungen werden in jeweils zwei Dateien von der jeweiligen Stau-Applikation in das Verzeichnis /var/spool/svxlink/trafficinfo abgelegt, einmal als reine TXT-Datei und einmal das generierte WAV-File. Das Format der Dateien soll bitte das folgende Format besitzen:

username.Hashwert.info - für die Textdatei
username.Hashwert.wav - für das Wav-File

Beispiel für eine Meldung:
DB0WSF.a3d6b5a85a032ec74a64695f15b8d8ac.info
DB0WSF.a3d6b5a85a032ec74a64695f15b8d8ac.wav

wobei username dem Call innerhalb der konfigurierten Logic entspricht und der Hash-Wert aus dem Inhalt der info-Datei erstellt wurde (z.B. Perl-Funktion: md5_hex($inhalt)), dieses Verfahren garantiert, dass mehrfach eingehende eMail's mit identischem Text nur einmal als wav generiert und ausgegeben werden. Das passiert leider sehr häufig. Mit der User-Kennung am Anfang kann man die Meldungen logic-/repeaterspezifisch ausgeben lassen.

Diese Dateien werden von SvxLink aus diesem Verzeichnis zunächst nach /usr/share/svxlink/sounds/de_DE/TrafficInfo kopiert, per HF ausgegeben und danach in das Verzeichnis /usr/share/svxlink/sounds/de_DE/TrafficInfo/archive verschoben wo sie für $DELETE_AFTER Minuten lagern. In späteren Versionen soll die Möglichkeit bestehen, diese Meldungen bei Bedarf nochmals aufrufen zu können. Weiterhin soll es später möglich sein, Meldungen nach bestimmten Kriterien auszugeben, z.B. per Modul-Subkommando 11#: Gib mir die 5 letzten Meldungen, die das Wort "Falschfahrer" enthalten. Aus diesem Grund muss das beschreibende info-File mit kopiert werden, damit der Inhalt von SvxLink vor der Ausgabe analysiert werden kann.

Es bestand noch die Forderung, vor der Ausgabe der eigentlichen Meldungen eine Information "Achtung, es erfolgt die Ansage einer Verkehrsmeldung!" auszugeben und $TIME Sekunden bzw. bis sich die Rauschsperre geschlossen hat zu warten um erst dann mit der Ausgabe zu beginnen. Das wird sich nicht alleine per tcl lösen lassen, weil man dafür einen Async-Timer implementieren muß und so was im tcl nicht vorhanden ist, d.h. es läuft letztendlich auf ein C++-Modul hinaus.

Wer weitere Ideen hat, bitte im Forum (an-)melden, vielen Dank.

73's de Adi, DL1HRC

Lieber Adi,

vielen Dank für die Zusammenfassung der Diskussion zwischen uns und die die Beschreibung der von Dir gut vorgedachten und offensichtlich schon lange erprobten Verfahren -- wir sind da ja noch nicht ganz so weit.

Zum Thema asynchrones Abspielen möchte ich gerne das folgende zur Verfügung stellen:
Wenn ich es recht sehe, gibt es die Möglichkeit, mittels Variablen die unterschiedlichen Teile eines Programms auch über TCL kommunizieren zu lassen. Außerdem gibt es clock now.

Ich sehe die Möglichkeit an dem sekündlich aufgerufenen TCL-Prozess einen Haken der folgenden Gestalt einzubauen:

if clock (now) - Sekunde_der_aufgetretenen_Meldung > time_max_fr_meldung then
gibt meldung mit Audio aus

Ästhetisch ist das vielleicht nicht gerade, um damit den sekündlichen Prozess auch nicht zu überfrachten -- und vielleicht durchbricht es ja auch andere asynchrone Konzepte; aus meiner Sicht wäre das aber ein konformes Konzept mit Variablen zu kommunizieren, und damit eine Quick'n'dirty-lösung in tcl zu erzielen.

Auch gibt es doch die Variable Squelch_open und "Nachricht von Echolink". Und ich habe schon beobachtet: wenn ich während einer längeren verlesenen Nachricht eine Eingabe mach, die eine sprachliche Quittung erforderlich macht, dann kommt diese sprachliche Quittung auf jeden Fall im Anschluss -- also hier klappt die Speicherung und dann das Abrufen auf jeden Fall auch über viele Sekunden hinweg.

Hinsichtlich der Quellen versuchen wir gerade herauszufinden, ob für die Stadt Bremen dieser großflächige emai-Dienst (freiefahrt.info) eine hinreichende Qualität aufweist -- wir benchmarken gerade beide Quellen gegeneinander und werden dann vielleicht nach einer guten Woche sagen können, ob es nur eine Quelle oder sogar beide Quellen sein müssen -- vielleicht ein "Luxusproblem" aber aus meiner Sicht für die Akzeptanz bei den Nutzern später, sehr entscheidend.

Das hashen finde ich sehr gut, bin aber noch nicht klar, ob dass für uns mit möglicherweise beiden Quellen anwendbar ist -- für Deinen Vorschlag finde ich das zunächst einmal sehr geeignet. ( Die Bremer VMZ bietet zusätzlich bei jeder Meldung eine eindeutige Verwaltungsnummer (ID) an. da ist also der hash-Wert schon vorhanden.)

soweit fürs erste -- weiter Kommentare möglich.
vy 73
Michael

Hi Michael,

vielen Dank für die schnelle Rückmeldung.

Quote

Ich sehe die Möglichkeit an dem sekündlich aufgerufenen TCL-Prozess einen Haken der folgenden Gestalt einzubauen:

if clock (now) - Sekunde_der_aufgetretenen_Meldung > time_max_fr_meldung then
gibt meldung mit Audio aus...

Die von Dir vorgeschlagende Lösung funktioniert sicher in der Theorie nur habe ich erhebliche Bauchschmerzen mit der Vorstellung, dass ein tcl-Event jede Sekunde neu gestartet wird. Diese Präsentationsebene war eigentlich nicht dafür gedacht um Intelligenz aus dem SvxLink-Async-Framework auszukoppeln und nach "außen" zu verlagern. Im C++-Async-Framework gibt es Timer-Implementierungen, die eigentlich keine Wünsche offenlassen um das von Dir gewünschte Verhalten zu erzeugen.
Bedenke bitte auch, dass SvxLink auf "kleinen" Systemen mit wenig Rechenleistung, RAM und langsamen IO-Zyklen laufen muß. So eine Verkehrsinfo-wav-Datei kann bei längeren Ansagen schon mal 600-800kB groß sein und ich kann beim besten Willen nicht sagen, wie SvxLink reagiert, wenn einerseits jede Sekunde ein tcl-event ausgelöst wird, das aktuelle tcl-Event gerade mit dem Einlesen zweier Meldungen beschäftigt ist und dann vom Folge-Event eingeholt wird. Wenn diese Lösung auch für andere Module kopiert werden würde (Wetter, ... ), dann haben wir irgendwann in SvxLink nur noch sekündliche tcl-Interrupts und keine Resourcen mehr für wichtige Programmteile.
Des weiteren möchte ich gerne eine _sichere_ Lösung haben, die überall _gut_ funktioniert und vielleicht doch irgendwann Einzug in den Trunk finden wird und ich kann Dir jetzt schon definitiv sagen, dass der Chef diese Lösung niemals akzeptiert

Quote

Auch gibt es doch die Variable Squelch_open und "Nachricht von Echolink". Und ich habe schon beobachtet: wenn ich während einer längeren verlesenen Nachricht eine Eingabe mach, die eine sprachliche Quittung erforderlich macht, dann kommt diese sprachliche Quittung auf jeden Fall im Anschluss -- also hier klappt die Speicherung und dann das Abrufen auf jeden Fall auch über viele Sekunden hinweg.

Dieses Verhalten wird aber ausschließlich durch eine Pufferung der DTMF-Kommandos im Programm und nicht durch das tcl-System gewährleistet. Werden DTMF-Kommandos während einer Übertragung empfangen, so werden diese im Programm einen internen Puffer gepackt und nach dem Schließen der Rauschsperre von SvxLink bearbeitet bzw. ausgeführt (-> proc dtmfCmdReceived{} ). Was meinst Du mit "Nachricht von EchoLink"? Wird eine EchoLink-Verbindung während eines QSO's entgegengenommen so wird im Hintergrund das Modul EchoLink aktiviert und natürlich auch die ein oder andere tcl-Prozedur in der ModuleEchoLink.tcl ausgeführt. Das alles wird aber duch die Applikation gesteuert.

Quote

Hinsichtlich der Quellen versuchen wir gerade herauszufinden, ob für die Stadt Bremen dieser großflächige emai-Dienst (freiefahrt.info) eine hinreichende Qualität aufweist -- wir benchmarken gerade beide Quellen gegeneinander und werden dann vielleicht nach einer guten Woche sagen können, ob es nur eine Quelle oder sogar beide Quellen sein müssen -- vielleicht ein "Luxusproblem" aber aus meiner Sicht für die Akzeptanz bei den Nutzern später, sehr entscheidend.

Ich denke schon, dass dieser Info-Dienst besser sein wird, ich sehe es auch nicht als entweder/oder-Frage sondern eher die Kombinationsmöglichkeiten beider Varianten. Aber bitte nicht vergessen, es bringt nix etwas zu bauen, was ausschließlich in Bremen oder Halle funktioniert.

Quote

Das hashen finde ich sehr gut, bin aber noch nicht klar, ob dass für uns mit möglicherweise beiden Quellen anwendbar ist -- für Deinen Vorschlag finde ich das zunächst einmal sehr geeignet. ( Die Bremer VMZ bietet zusätzlich bei jeder Meldung eine eindeutige Verwaltungsnummer (ID) an. da ist also der hash-Wert schon vorhanden.)

Ok, diese ID geht sicher auch. Der Hash über den Inhalt garantiert halt, dass zwei exakt gleiche Meldungen nur einmal vorgelesen werden. Wenn das die ID auch macht, dann nimm die einfach als Hash. Die Struktur ist dann einfach "username.id.info" bzw. "username.id.wav". Da macht meine Extension keinen Unterschied

vy 73's de Adi, DL1HRC

Moin Moin

wollte hier mal meinen Einstand geben.

DK5HH und ich überlegen seit ein paar Tagen, inwieweit sich Verkehrsinformationen für den Bremer Raum realisieren lassen.
Da ich von svxlink keine kenne habe, konzentriere ich mich auf die beschaffung der Verkehrsmeldungen.

Dabei ist mir aufgefallen, daß die email Benachrichtigungen von freiefahrt sehr dürftig sind, zumindest für unseren Region.
Ebenso halte ich die Filter Regeln, um den output zu verfeinern für stark verbesserungswürdig.
Eine Antwort der Betreiber von freiefahrt auf eine Anfrage von mir lässt noch auf sich warten.

Dennoch finde ich, daß deren Datenbank als universelle Datenquelle für Deutschland sehr gut ist,
um möglichst vielen Nutzern des Plugins einen einfachen und schnellen Einstieg zu gewährleisten.

Scheint, als ob die problematiken im Bremer Raum wohl nur regional bedingt sind, wenn es bei dir in Halle zufriedenstellend läuft.
Wie schon erwähnt wurde, haben wir hier eine weitere Datenquelle, die deutlich bessere und aktuellere Informationen liefert.

Meine Frage wäre nun hinsichtlich der Implementierung in dein Plugin:

Du schreibst, die .txt und die .wav müssen in ein spooling verzeichnis verschoben werden, soweit ne super Idee, somit könnten wir unsere Datenquelle ganz einfach einbinden.
Allerdings erschliesst sich mir der sinn der .txt Datei dann nicht mehr, wenn die Sprachausgabe extern realisiert werden muss.
Eventuell könntest du diesen Punkt noch einmal näher erläutern.
Aus diesem Grund habe ich schon mal ein wenig mit Mary rum probiert. Falls Interesse an einer Live-Demo besteht, lasse ich dir den Link gerne zukommen.

grüße chris

Hallo Chris,

vielen Dank für Deinen Beitrag.

Quote

Du schreibst, die .txt und die .wav müssen in ein spooling verzeichnis verschoben werden, soweit ne super Idee, somit könnten wir unsere Datenquelle ganz einfach einbinden.
Allerdings erschliesst sich mir der sinn der .txt Datei dann nicht mehr, wenn die Sprachausgabe extern realisiert werden muss.
Eventuell könntest du diesen Punkt noch einmal näher erläutern.

Die Idee dahinter war, dass diese TXT-Datei noch für eine gewisse Zeit zusammen mit dem WAV-File im /archive-Verzeichnis liegt (1h, 2h, 1d, 5d, je nach Konfiguration) um per Kommando sozusagen wieder aktiviert zu werden. Falls jemand morgens um 8Uhr losfährt, so dachte ich daran, dass er per Kommando die Verkehsrinformationen z.B. der letzten Stunde abrufen kann was sich sicher auch ohne TXT-Dateien realisieren läßt aber als add-on eventuell ein Kommando zur Verfügung zu stellen, welches die gespeicherten Verkehrsinformationen auf Kommando nach Schlagworten wie z.B. 4#->"Falschfahrer", 5#>"Stau AB40" oder ähnliches durchforstet, d.h. SvxLink grabt jedes archivierte TXT-Files nach einer vorher in der Konfiguration hinterlegten Wortkombination und falls diese auftritt wird das dazugehörige WAV-File ausgegeben, ansonsten halt die Info "Für Deine Anfrage gibt es heute leider keine passende Staumeldung und Du bist leider pünktlich auf Arbeit, tut mir leid!"

Rein theoretisch könnte man die gesamten TXT-Informationen auch im SvxLink-Speicher halten, wobei mir das als nicht günstig erscheint.....ist nur so eine Idee. Was meinst Du dazu?

vy 73's de Adi, dL1HRC

Quote

Rein theoretisch könnte man die gesamten TXT-Informationen auch im SvxLink-Speicher halten, wobei mir das als nicht günstig erscheint.....ist nur so eine Idee. Was meinst Du dazu?

würde bedeuten: einmal einlesen, spool datei löschen und nach timeout x wieder verwerfen? Auch keine schlechte Idee.
Aber mir fehlt die Erfahrung im umgang mit svxlink um zu beurteilen, inwieweit das gegenüber der derzeitigen Methode sinn macht.
Zur rush hour liegen hier so ~5 aktuelle Meldungen vor. Die größe des Textes ist hierbei wohl vernachlässigbar :>

Quote

würde bedeuten: einmal einlesen, spool datei löschen und nach timeout x wieder verwerfen? Auch keine schlechte Idee.
Aber mir fehlt die Erfahrung im umgang mit svxlink um zu beurteilen, inwieweit das gegenüber der derzeitigen Methode sinn macht.
Zur rush hour liegen hier so ~5 aktuelle Meldungen vor. Die größe des Textes ist hierbei wohl vernachlässigbar :>

ja, die Files wechseln halt theoretisch jede Minute, weil natürlich ständig neue Meldungen reinkommen, dann z.B. für 60 Minuten vorgehalten und danach gelöscht werden. Es ist sozusagen ein ständiges Kommen und Gehen.
Ich persönlich würde das Analysieren der 5 TXT-Dateien favorisieren, die genau in dem Moment erfolgt in dem ein OM dieses Kommando aktiviert. Das ist, so denke ich, zeitmäßig verkraftbar...ich denke nicht, dass ein OM ausrastet, wenn er die Meldung erst nach 3 Sekunden (und um diese Zeiten geht es hier) bekommt.

73's de Adi, DL1HRC

Quote

ist, so denke ich, zeitmäßig verkraftbar...ich denke nicht, dass ein OM ausrastet, wenn er die Meldung erst nach 3 Sekunden (und um diese Zeiten geht es hier) bekommt.

Allerdings relativ unwichtig. Zumal die Meldungen ja eh nicht sekundengenau rein kommen, sondern teilweise mit 5 minuten verzug.

edit:
hab da wohl was falsch verstanden. Ging wohl um die manuelle Abfrage.
Aber sowohl bei der, als auch bei der automatischen ansage neuer Meldungen ist das nicht allzu zeitkritisch.

Hi Michael und Chris,

so, ich habe das jetzt wie folgt am Laufen:

* die Meldungen werden (in Analogie zum PropagationMonitor) sofort ausgegeben
* Wenn man das TrafficInfo-Modul startet, stehen folgende Kommandos zur Verfügung:

0# Hilfe
1# Anzahl der aktuell gespeicherten Verkehrsinformationen
2# Ausgabe der archivierten Verkehrsinformationen in der Reihenfolge der RX-Zeit

Ok, das ist noch nicht der Weisheit letzter Schluß, der Code ist noch etwas, sagen wir mal vorsichtig, "verschönerungswürdig". Ich würde aber den Vorschlag machen, dass Ihr es einfach mal bei Euch installiert und ein bischen damit spielt. Ich würde jetzt ehrlich gesagt auch nicht mehr ganz so viel Arbeit in die tcl-Umgebung stecken, sondern mal beginnen ein C++Modul zu schreiben um die von Dir/Euch gewünschte Funktionalität mit einzubauen. Darin können ja die gewonnenen Erkenntnisse ja einfließen.

73's de Adi, DL1HRC

Lieber Adi,

das klingt ja sehr interessant und ich bin sehr gespannt auf Deine Beschreibung auf der Webseite. Wir werden gerne über unsere ersten Einsatzerfahrungen berichten und unsererseits zu der Anbindung der Verkehrmeldezentrale dann die dafür allgemein interessanten Informationen zur Verfügung stellen.

Schön, dass Du sehr schnell vorangekommen bist und die Ideen sich offensichtlich schon sehr schnell umsetzen ließen.

Einstweilen sind wir in Lauerstellung und warten auf weiterführende Informationen auf svxlink.de für das Modul Trafic-Info --

vy 73
Michael