monitor 1.9.0 - aber richtig :)

[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

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