monitor 1.9.0 - aber richtig :)

[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

[Buebchen]

Ne, Ne. Schon beim monitor waren das getrennte Dekodierer. Für jede "Spezies" einer.

Parallel habe ich bisher nur die Kanäle laufen lassen. Ob es Sinn macht, das auf die einzelnen Auswerter herunterzubrechen ... muss man mal drüber nachdenken. Ich würde Spontan nur linken und rechten Kanal als einzelnen Prozeß laufen lassen. Wobei man natürlich auch mehr als zwei Prozesse bilden kann (um z.B. mehrere Soundkarten auszuwerten).

[Dove]

ich glaube um die modularsierung zu wahren sollte man die einzelt lassen.
So kann man dann eventuell auch das laden der für mich wichtigen module einstellen und alle anderen module werden außen vor gelassen.

[Buebchen]

Reden wir jetzt von logischen Modulen oder von real existierenden Prozessen ?

Ich würde die Module trennen, keine Frage. Das ist im monitor sowieso schon so, also keine Änderung. Ich würde nur für den linken und rechten Kanal (ggf. auch weitere) immer einen Unterprozeß (Thread) bilden. Hängt sich ein Kanal weg, läuft der andere weiter. Ausserdem würde man so zumindest ein Stückchen von HT / Dualcore profitieren.

[Dove]

Reden wir jetzt von logischen Modulen oder von real existierenden Prozessen ?

Ich würde die Module trennen, keine Frage. Das ist im monitor sowieso schon so, also keine Änderung. Ich würde nur für den linken und rechten Kanal (ggf. auch weitere) immer einen Unterprozeß (Thread) bilden. Hängt sich ein Kanal weg, läuft der andere weiter. Ausserdem würde man so zumindest ein Stückchen von HT / Dualcore profitieren.

genauso seh ich das auch.

[nepomuck]

Mal eine kurze Zusammenfassung:

Der neue Monitor arbeitet mit einem Backend "monirotd", das zwei Soundkanäle eines Devices dekodiert und die Ergebnisse auf einem TCP-Port für Frondend-Anwendungen ausgibt. Das Protokoll wird dabei den Dienst (FMS, ZVEI, POCSAN), den Kanal (L,R) und die jeweiligen Daten angeben. Dieser Port kann simultan von mehreren Fontend-Apllikationen -- auch über das LAN -- abgehört werden. So kann ein MySQL-Frontend getrennt von einem "Classic-Client" arbeiten.

Jetzt hätte ich noch einen Vorschlag für den Daemon:
Das modulare Konzept erlaubt bislang keine @rec-Funktion, da diese vom Frondend gesteuert aber vom Backend ausgefürt werden muss.
Dazu könnte man doch das Backend mit einem TCP-Listener versehen, das auf einem zusätzlichen TCP-Port Kommandos von einem Frontend entgegen nimmt.
Beispiel: monitord gibt seine Infos wie "ZVEI:L:12345" auf localhost:10112 aus, hört aber gleichzeitig auf localhost:10113. Wenn das Frontend nun aufgrund des Regelwerks eine Funkaufzeichung anfertigen möchte, dann sendet sie eine Nachricht via Port 10113 an den monitord mit dem Inhalt:"Bitte Funk für 120 Sekunden aufzeichnen". Die eigentliche Aufzeichung übernimmt dann das Backend, welches ohnehin das /dev/dsp exklusiv belegt. Das Frontend steuert über sein Kommando, wie lange welcher Kanal aufgezeichnet wird und übergibt im Zweifelsfalle auch die sox- oder lame-Parameter an das Backend.

Der zusätzliche Port liesse sich somit auch für weitere Steueranweisungen verwenden, welche das Front- an das Backend übermitteln will.
Einschränkung: Viele Frontends können die Auswertung von Port 10112 verarbeiten aber nur EINE Frontend-Anwendung kann dem Backend zur Laufzeit via 10113 Anweisungen erteilen.

Andreas