monitor 1.9.0 - aber richtig :)

[nepomuck]

an dem wir uns alle im IRC treffen (für ne halbe Stunde oder so) und mal überlegen, wie wir es am Besten angehen. Vorschlag: (Oster-) Montag, 20 Uhr.

Da bin ich in der "Offline-Pampa"
Wäre schön, wenn einer das Chat-Protokoll redigiert und den Report hier postet.

Ich werde einfach mal meine Ideen zu einer Wunschliste zusammenschreiben und hier oder in das Code-System einstellen. Ich habe da ein paar Ideen zu Front- und Backends sowie Kommunikationsmodulen, damit der Monitor netzwerkfähig wird. Frond- und Backend könnten dann auf getrennten PCs arbeiten, wie bei FMS Pro.

Andreas

[nepomuck]

Ich werde einfach mal meine Ideen zu einer Wunschliste zusammenschreiben und hier oder in das Code-System einstellen.

Wie angekündigt poste ich hier mal ein paar konkrete Ideen für eine kommende Monitor-Version. Da meine eigenen Programmierkentnisse in C nicht wesentlich über ein "Hello World" hinausragen und ich mit Objektorientierung gar nichts am Hut habe, kann ich leider nicht aktiv am Code mithelfen, sorry.

Der Grundgedanke ist die strikte Trennung in Font- und Backend, eventuell mit einem Zwischenlayer für Netzwerkfunktionen. Der Vorteil liegt auf der Hand: Die einzelnen Module lassen sich einfacher kompilieren und jeder nutzt nur das, was er benötigt. Zudem können die Entwicklerteams von Front und Backend getrennt voneinander arbeiten, ohne den Code des anderen bearbeiten zu müssen.

1. Backend
Das Backend besteht aus einem Loader, dem Monitor-Daemon plus die Dekodierungsmodule. Die Konfiguration definiert "Channels". Jeder Channel besteht aus einem Input-Kanal wie "/dev/dsp0 links", einem Output-Kanal wie "/dev/fms0" und einer Liste der zu ladenden Module, zum Beispiel:

[channel 0]
input =/dev/dsp0 left
modules = zvei,dtfm,fms
output = /dev/fms0
[channel 1]
input = /dev/dsp1 right
modules = pocsac512
output = /dev/fms2

Der Loader prüft die Konfigurationsdatei und startet dementsprechend ein- oder mehrere "monditord"-Instanzen (eine pro Channel). Vorteil: Stürzt eine Instanz ab (siehe ZVEI-Bug), dekodiert die andere weiter.
Wichtig wäre dabei, dass das /dev/fms-Devices so deffiniert ist, dass mehrere Frondend-Tasks parallel darauf nur-lesend zugreifen können.
Auf dem Output-Device landen die dekodierten Werte im Klartext, so wie sie vom Dekodierer kommen, plus der Angabe, was dekodiert wurde, Beipsiel:
ZVEI:12345
DTFM:F
FMS:1234567:2 (<- Statusmeldung)
FMS:1234567:Text:"der übertragene Text"

Anstelle eines "/dev/fms"-Devices könnte der monitord die Ausgabe auch auf einen TCP-Port schreiben. Das würde die Netzwerkfähigkeit direkt integrieren. Lokale Frontends würden dabei dann z.B. auf 127.0.0.1:10122 hören.
Hier müssen die Entwickler entscheiden, was sich einfacher umsetzen lässt, Device oder TCP-Port.

2. Zwischenlayer
Sollte der monitord auf ein "/dev/fms"-Device schreiben, bedarf es eines Zwischelayers für Netzwerkfunktionen. Dieser würde dann auf dem Server alle Ausgaben von /dev/fms auf einem Netzwerkport bereitstellen. Im Gegenzug würden die Clients auf einem anderen PC per TCP diesen Port abhören und ein lokales /dev/fms-Device beschreiben.
Für Frontend-Anwendungen wäre es damit völlig egal, ob sie direkt auf dem monitord-Rechner oder irgendwo im LAN arbeiten -- sie müssen ja nur ein /dev/fms-Gerät abhören und darauf reagieren.
So könnte auch jemand ein Mac- oder Windows-Frontend schreiben.

3. Frondend
Hier kann jeder im Prinzip machen was er will. Es genügt, den Text-Output des FMS-Devices abzuhören und irgendwie darauf zu reagieren. Allerdings müssen Frontends multithreaded arbeiten, wenn sie mehrere Channels simultan auswerten wollen. Das "Monitor-Classic-Frontnend" würde die .monrc benutzen, um die eingehenden Informationen darzustellen, nötigenfalls umzuschreiben und darauf zu reagieren. Ein MySQL-Frontend, das parallel zu anderen arbeitet, schreibt die Auswertung in eine Datenbank. Dabei müssen sich Classic- und MySQL-Frontend nicht eine Zeile Code teilen und können friedlich nebeneinander werkeln.

Probleme:
Das Konzept berücksichtigt die REC-Funktion nicht. Die lässt sich auch nicht direkt mit dem monitord-Prozess abbilden, da dieser schließlich nur Dekodiert aber nicht auswertet. Hierfür müsste es als ein Extra Modul geben, welches zwangsläufig auf dem selben PC wie monitord arbeitet. Soweit ich weiss gibt's da aber ein Problem, dass unter Linux nur ein Task auf /dev/dsp Zugreifen kann und nicht mehrere. In diesem Fall belegt der monitord das Device exklusiv und ein getrennter recd käme nicht an die Soundkarte.

Was haltet ihr von dem Konzept?
Zumindest das Backend dürfte sich mit dem bestehenden Code sehr einfach bauen lassen. Beim Frontend müsste man den Code auseinandernehmen und die MySQL-Funktionen von "Classic"-Client trennen und als eigene Module bauen.

Andreas

[Buebchen]

Liest sich soweit ganz gut. Aber warum der Umweg über die Devices ? Ich würde dann direkt den TCP Port nehmen. Wenn es ohne TCP gehen soll wäre noch ein Unix-Filesocket vorstellbar. Ich denke, daß Du das mit dem /dev/fmsXyz meinst.

Die Idee mit den zwei Unterprozessen kann ich nur unterstützen. Habe ich in meiner Eigenentwicklung auch so umgesetzt. Wobei man es nicht 100% trennen kann.

Da man nur ein "komplettes" ein Sound-Device belegen kann muss man Links und Rechts in einem gemeinsamen Haupt-Thread erstmal von Hand trennen und kann erst dann diese Daten an die anderen Subprozesse weitergeben. Ich würde dann über den Haupt-Task auch den TCP Socket Pool verwalten und alle ausgewerteten Daten an die Clients weitergeben.

Habe bisher unter Linux nur mit Perl TCP Listener erstellt. Aber da sollten sich die C-Version von Windows und Linux hoffentlich nicht zu sehr unterscheiden.

[nepomuck]

Ich würde dann direkt den TCP Port nehmen. Wenn es ohne TCP gehen soll wäre noch ein Unix-Filesocket vorstellbar. Ich denke, daß Du das mit dem /dev/fmsXyz meinst.

Exakt. Wenn TCP einfacher ist, dann umso besser. So wird Monitor direkt netzwerkfähig und der Zwischenlayer fällt aus. Dann muss allerdings ein Modul dazu, welches die TCP-Connections zu den Clients irgendwie verwaltet und man muss sich ein wie auch immer geartetes LAN-Protokoll einfallen lassen.

Da man nur ein "komplettes" ein Sound-Device belegen kann muss man Links und Rechts in einem gemeinsamen Haupt-Thread erstmal von Hand trennen und kann erst dann diese Daten an die anderen Subprozesse weitergeben.

Das liesse sich auch so abbilden, dass ein "Channel" und damit eine monitord-Instanz zwangsläufig für zwei Sound-Kanäle steht. Dann wäre nur zu überlegen, ob der Output dann auf einem TCP-Port erfolgt, also:
ZVEI:L:12345, FMS:R:1234567:1
oder ob der Output der Sound-Kanäle auf getrennten TCP-Ports endet. Beispiele:

• [channel 0]
  input = /dev/dsp0
  modules left = ZVEI,DTFM,FMS
  modules right = POCSAC512
  output = 10112
  localonly = yes (an und abschalten des LAN-Zugriffes)

oder

• output left = 10112
  output rigth = 19222
  localonly =yes

Was anderes:
Müssen ZVEI und DTFM eigentlich als seperate Module existieren? DTFM kommt doch ohnehin immer nur in Verbindung mit ZVEI zum Einsatz. Da läge es doch nahe, diese Module zu verbinden.

Andreas

[jhr-online]

Die Thematik übersteigt meine derzeitigen Fähigkeiten ganz ordentlich, aber - nur mal leise angetastet - wäre es nicht möglich den monitord ALSA-fähig zu machen? Das dürfte doch das Sound-Problem lösen, oder nicht?

jhr

[Buebchen]

Exakt. Wenn TCP einfacher ist, dann umso besser. So wird Monitor direkt netzwerkfähig und der Zwischenlayer fällt aus. Dann muss allerdings ein Modul dazu, welches die TCP-Connections zu den Clients irgendwie verwaltet und man muss sich ein wie auch immer geartetes LAN-Protokoll einfallen lassen.

Wenn alle Stricke reissen, nehmen wir halt XML :-)

Das liesse sich auch so abbilden, dass ein "Channel" und damit eine monitord-Instanz zwangsläufig für zwei Sound-Kanäle steht. Dann wäre nur zu überlegen, ob der Output dann auf einem TCP-Port erfolgt, also:
ZVEI:L:12345, FMS:R:1234567:1
oder ob der Output der Sound-Kanäle auf getrennten TCP-Ports endet. Beispiele:

• [channel 0]
  input = /dev/dsp0
  modules left = ZVEI,DTFM,FMS
  modules right = POCSAC512
  output = 10112
  localonly = yes (an und abschalten des LAN-Zugriffes)

oder

• output left = 10112
  output rigth = 19222
  localonly =yes

Was anderes:
Müssen ZVEI und DTFM eigentlich als seperate Module existieren? DTFM kommt doch ohnehin immer nur in Verbindung mit ZVEI zum Einsatz. Da läge es doch nahe, diese Module zu verbinden.

Andreas

Würde die Ausgabe immer gesammelt über einen TCP Port machen. Man kann ja durchaus den Kanal, von dem die Info stammt mit angeben. Der Client kann dann entscheiden, ob ihn das Ergebnis interessiert.

Der Grund, daß DTMF überhaupt genutzt wird ist die m.E. Sirenentonerkennung (Doppelton). Hätte ich auch eine andere Lösung für parat (Einfach ne FFT genommen).

Ich muss mal meinen Windows C++ Source uns CVS uppen. Mal gucken, ob ich da noch irgendwelche Passwörter hard-coded drin habe. Das wäre dann nicht so geschickt :-)

Mit Alsa müßte man sich mal befassen. Wenn man einigermassen modular arbeitet sollte es nicht dramatisch sein, auf andere "Tonquellen" zugreifen zu können. Das kann ja sogar der monitor schon (Datei).

[nepomuck]

Wenn alle Stricke reissen, nehmen wir halt XML :-)

In erster Linie geht es darum, wie Client und Server sich überhaupt verständigen ("Helo" -> "Ehlo" und so was), ob es eine wie auch immer geartete Useranmeldung gibt und wie der Client regelmäßig prüft, ob er überhaupt noch zum Server verbunden ist ("ping" -> "pong").

Der Grund, daß DTMF überhaupt genutzt wird ist die m.E. Sirenentonerkennung

Klar, und die gibt's meines wissens sowieso nur bei ZVEI-Alarmierungen

Hätte ich auch eine andere Lösung für parat (Einfach ne FFT genommen).

hä? Was ist eine FFT?

Wenn man einigermassen modular arbeitet sollte es nicht dramatisch sein

Thema modular: Ich habe mir heute mal Teile des Codes angesehen, im speziellen demod_zvei.c auf der Suche nach der möglichen Ursache für das angesprochene ZVEI-Problem.
Ich will ja niemand auf die Füße treten, aber der Code ist ein wildes durcheinander: Hier etwas .monrc auslesen, dort etwas Output formatieren und mittendrin irgendwelche Cosinus-Kurven analysen.

Wenn das Projekt modular werden soll, dann muss jemand diesen Code entwirren -- bevorzugt derjenige, der in geschrieben hat. Es würde *imho* sehr viel helfen, im bestehenden Source die Backend-Funktionen zu kennzeichnen, damit man sie in mitten der Frontend-Funktionen überhapt erkennen und dann auch abtrennen kann.

Andreas

[Buebchen]

FFT = Fast-Fourier-Transformation (Damit kann man jetzt bei google mal so richtig viel Spaß haben :-) - Im Grunde genommen prüfe ich ob die gesuchten Töne im gesamten Frequenzspektrum vorhanden sind. Dazu muss das "Rauschen" wie bei einem Equilizer Blöcke für die einzelnen Frequenzen zerlegt werden. Das kann eine FFT.

Was das entwirren des Codes angeht. Ich brauch noch bestimmt bis Mittwoch, bevor ich dazu komme ins svn mal was hochzuladen. Ich habe mir die Mühe, den Code zu entwirren schon gemacht. Bin jetzt gerade aber ein bisschen wegen Familie eingespannt.

Ansonsten stimme ich zu 100% zu: Der Code ist ein Paradebeispiel für Spaghetti-Code.