monitor 1.9.0 - aber richtig :)

[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.

[nepomuck]

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.

Was eine "normale" Fourier-Transformation ist, weiss ich im Groben und Ganzen noch.
Wie funktioniert die ganze Dekodiererei überhaupt vom Prinzip her?

Du greifst permantent Datenblöcke von der Soundkarte ab und prüftst, per FFT, ob einer die vielen gesuchten Töne drinsteck?

Also 11 verschiedene Töne für ZVEI, (?) andere für FMS.

Wie merkt man dann, dass es sich um einen Doppelton handelt?

viele Grüße,
Andreas

[Buebchen]

Im Grunde genommen genau so, wie Du es beschreibst:

Datenblock vom Soundtreiber füllen lassen. Dann Analyse starten. Dann nächsten Block abwarten und wieder Analyse ...

ZVEI läuft eher über Matrix-Operationen (Diskrete Cosinus Transformation) ab. Aber im Grunde bleibt es eine FT.

Die Verarbeitung ist so gegliedert:

1. Rohdaten vom Sound-Device (float, 16 Bit signed)
2. Auf Frequenzanteile prüfen. Anhand dessen wird bei FMS und POCAG ein Bit erkannt.
3. Das erkannte Bit wird dann wiederum zu einem Wort/Byte/Was-auch-immer zusammengesetzt
4. Ist nun das Telegramm vollständig kann man es noch dekodieren und ist fertig.

Soweit die Theorie. In der Praxis ist das recht aufwändig. Gerade die Synchronisation auf den Bittakt des Senders finde ich, ist eine Herausforderung. Warum FMS z.B. mit 12x "Eins" als Vorlauf arbeitet habe ich nie kapiert. Eine Null-Eins-Folge wäre zur Synchronisation m.E. eheblich einfacher gewesen, da man gerade den Wechsel eines Bits relativ gut detektieren kann. Pocsag hat 576 Bits im Vorlauf. Mit ständigem Wechsel. Sowas ist natürlich perfekt zu sync'en.

Ach so, Doppelton. Eigentlich ganz leicht: Zwei FFTs für die beiden Grundfrequenzen und wenn beide Anschlagen (Fourierkoeffizienten sehr gross) hat man nen Doppelton. Habe an der Analyse selbst lange nicht mehr gearbeiten. Stichwort für wenigen Frquenzen wäre Goertzel-Transformation. Ist eine effiziente FFT Variante wenn man nur wenige Frequenzen sucht.

[nepomuck]

ZVEI läuft eher über Matrix-Operationen ...
Auf Frequenzanteile prüfen. Anhand dessen wird bei FMS und POCAG ...

Läuft da ein Dekodierer der alles kann?
Oder gibt es eine Art "Vordekodierung", die den Datenblock erst einmal typisiert und sagt, dass muss FMS, Pocsac oder ZVEI sein und den Block dann an eine Subroutine zur endgültigen Dekodierung übergibt?

Wäre es sinnvoll, in einer modularen Version das ganze zu parallelisieren?
Sprich: für jede Funktion (FMS;ZVEI;DTFM;POCSAC) eine eigene, optimierte Dekodierroutine zu schreiben? In der Praxis würden dann mehrere Dekoder parallel ein und denselben Datenblock bearbeiten. Das dürfte etwas mehr RAM kosten aber dafür die Dekodierung verbessern.

Andreas