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.

[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

[Buebchen]

Es wäre auch vorstellbar, einen "Decoder" zu schreiben, der die Daten als mp3 Stream aufbereitet und dem Client direkt "live" senden. Wäre für die Aufnahmefunktion natürlich prima, da viele Soundkarten auch den Stereo-Ausgang als Aufnahmequelle selektieren können.

Man könnte die @rec Funktion ansonsten auch über die gleiche TCP Sitzung starten/stoppen. Ist ja Bidirektional. Sollte man ggf. nur als Benutzerrecht definieren können. Ausserdem wäre dann noch zu klären, wie die Aufnahme zum Frontend kommt. Die besten Aufnahme nützt nichts, wenn man sie nicht hören kann :-)

Ich würde das Konzept auch direkt auf mehrere Soundkarten erweitern. Warum nicht direkt zwei oder mehr Soundkarten ermöglichen ? Sofern die Modularisierung da ist, ist das keine soo grosse Tat mehr.

[jhr-online]

Mir fällt gerade was auf:
Der Thread, in dem wir hier schreiben, ist u.A. betitelt mit "1.9.0". Anfangs dachte ich, das wäre die Beta-Reihe für 2.0, aber da hatten wir uns gegen entschieden, wenn ich das richtig verstanden habe. 1.9.0 ist der jetzige Stand und soll, sofern da noch jemand was dran macht, Bugfixes enthalten. So haben wir eine (mehr oder weniger) lauffähige Fassung vom monitor mit MySQL-Anbindung. Das, was wir hier so beschreiben und als Ideen ansammeln, ist aber alles für 2.0, richtig? Ich möchte das einfach nur aus technischen Gründen auseinander halten. Das macht die Arbeit mit subversion und BTS einfacher...

Außerdem halte ich es für sinnvoll, die Ideen mal konzeptionell zusammen zu fassen. Am Besten wär's, wenn das jemand machen könnte, der auch programmieren kann und versteht, was hier beschrieben ist (buebchen?). Wenn das geschehen ist, sollten wir tatsächlich einmal versuchen, einen gemeinsamen Chat hinzukriegen, sodass man mal abstecken kann, wer was leisten kann und will. Danach (oder meinetwegen auch davor) sollten wir das gesammelte ToDo ins BugTrackingSystem eintragen*.

Auch schön wäre ein grober Zeitplan, aber das sollten wir in den Chat verlegen, weil wir dann wissen, welche Kapazitäten wir haben.

Alles okay so?
jhr

* Aufgaben können da voneinander abhängig gemacht werden. Man kann also große Ziele und kleine als Bugs beschreiben und dann die großen von den kleinen abhängig machen. Außerdem können Aufgaben zugewiesen werden. Dadurch kann man leicht nachvollziehen, wer was macht und an wen man sich wenden muss, wenn sich was überschneidet o.Ä.

[Buebchen]

Hmm. Im Grunde wären wir dann bei Version 2.0 - Das stimmt wohl :-)

Bei der jetzigen Version 1.9 würde ich wenn nur noch Bugfixes machen. Wartung und Lesbarkeit des Source-Codes ist eine Katastrophe (oder eben nah dran).

Zur Zeit stehen wir ungefähr hier (wie schon nepomuk beschrieben hat):

Trennung von Auswertung und Anzeige / Speicherung in zwei eigenständige Programme. Als Verbindenden Element werden IP/TCP Verbindungen genutzt. Auf gleiche Weise arbeiten inzwischen fast alle Programme (Crusader, FMS32, ELS-PRO,...).

Alles weitere sind Details (grosse und kleine) zur Programmierung. Da wäre z.B. die Frage, ob schon jemand mit den Tools der Boost Lib gearbeitet hat (www.boost.org) oder jthreads (http://research.edm.uhasselt.be/~jor...?n=CS.Jthread). Um das ganze direkt auch auf mehrere Plattformen laufen lassen zu können wären das nach meiner Meinung recht geeignete Mittel (Ich würde gerne direkt eine Windows und Linux Version in C++ entwickeln wollen).

Bei Jthreads gibt auch noch eine RTP Library. Sieht recht vielversprechend aus ( wenn sie denn auch läuft ;-)) für die Live-Übertragung von Sounddaten an die Clients.

Werde mal ein paar Diskussionbeiträge im BTS erstellen. Ist meistens einfacher zu planen, wenn es schon einen groben Plot gibt über den man streiten kann :-)

[nepomuck]

Das, was wir hier so beschreiben und als Ideen ansammeln, ist aber alles für 2.0, richtig?

Ja. In den 1.x-Spaghetti-Code würde ich nur noch das Minimum an Arbeit investieren. Wenn sich schon ein paar Leute gefunden haben, die aktiv an dem Projekt weiter arbeiten möchten, dann sollten wir gleich die Modularisierung und damit Version 2 in Angriff nehmen.

Auch schön wäre ein grober Zeitplan,

Der dürfte in erster Linie von Buebchen abhängen, da er die eigentlichen Änderungen im Code durchführen muss. Ich bin hier leider nur eine kleine Hilfe, da ich keinen eigenen Code zusteuern kann

aber das sollten wir in den Chat verlegen

Muss das unbedingt im Chat sein? Ich bin da kein Freund davon weil's lange dauert und eigentlich nicht viel dabei rumkommt. Wie wär's mit einer VoIP-Telefonkonferenz, via Skype oder so?

weil wir dann wissen, welche Kapazitäten wir haben.

Fang doch schon mal eine Liste an:
Buebchen: Head of Development und Meister des Codes :-)
Nepomuck: Designvorschläge, schlau daherreden, Bugfixing, Testing, Dokumentation, Live-CD bauen.
Zudem kann ich, falls erwünscht, Web-Space und Internet/Speicher-Kapazität anbieten. Ich verfüge über eine 10 MBit/s Standleitung mit ein paar festen IP-Adressen und kann ins Internet hängen was ich will. Ich würde dazu passend einen oder mehrere (auch virtualisierte) Server stellen.

Es wäre auch vorstellbar, einen "Decoder" zu schreiben, der die Daten als mp3 Stream aufbereitet und dem Client direkt "live" senden.

Machbar ist viel. Wir sollten uns aber für die Version 2.0 nicht zu viel vornehmen. Ich würde diese Funktion als "Kür" einstufen, die "Pflicht" ist jedoch zunächst die grundlegende modularisierung und die Kommunikation Back-Frontend.

Ausserdem wäre dann noch zu klären, wie die Aufnahme zum Frontend kommt.

In der Version 2.0 soll sich da jemand anderes drum kümmern (NFS/SAMBA). Der monitord kann die Aufzeichnungen auf einem File Share sichern und das Frontend holt sie da ab. Stand heute gibt's im Frontend ja auch noch keinen integrierten Player. Das Streaming würde ich erst ein einer späteren Version berücksichtigen.

Ich würde das Konzept auch direkt auf mehrere Soundkarten erweitern. Warum nicht direkt zwei oder mehr Soundkarten ermöglichen ?

Das sollte das modulare Konzept ja ohnehin beherrschen. Das Frondend kann über den Control-Port problemlos Anweisungen für mehr als eine Soundkarte übermitteln und dabei die jeweilige monitord-Instanz instruieren.

Vorschlag:
Es gibt den bereits angesprochenen Launcher, der die monitord-Konfigurationsdatei auswertet und entsprechend viele monitord-Instanzen startet. Der Launcher besitzt einen TCP-Port über den er Steuerkommandos mit EINER Frondend-Anwendung (wie einem "Monitor Manager") abwickelt. Darüber erhält er @rec-Anweisungen, kann zur Laufzeit konfigurationsänderungen vornehmen oder ferngesteuert einzelne monitord-Instanzen starten und stoppen.
Jede monitord-Instanz steht für ein komplettes Sounddevice und damit für zwei Kanäle. Jede Instanz verfügt über einen eigenen TCP-Port, auf dem sie die Auswertungen an mehrere Frontends übermittelt.

Ich würde gerne direkt eine Windows und Linux Version in C++ entwickeln wollen.

Ich würde mir da nicht zu viel auf einmal vornehmen, sonst kommt am Ende erst mal gar nichts raus. Ich sehe erst einmal keinen Grund, das Backend auf Windows zu portieren. Und beim Frondend ist ohnehin alles möglich, denn es gilt nur, die Daten eines TCP-Listeners auszuwerten.

Ich würde daher folgende Vorgehensweise vorschlagen:

• 1. Code entwirren und modularisieren (Buebchen)
  2. Backend "monitord" und Launcher bauen (Buebchen)
  2a. TCP-Kommunikatiosnprotokoll für Daemon und Launcher festlegen, Struktur der Config-Dateien festlegen (Nepomuck, Buebchen)
  3. Ausführliche Tests des Backends (Nepomuck) und Debugging (Buebchen)
  4. Bestehenden Frontend-Code zu "Frondend-Classic" konvertieren (Buebchen)
  5. Neues MySQL-Frontend erstellen -- dazu müssten Perl-Skripte völlig ausreichen (?)
  6. Testing der Frondends (Nepomuck u.v.a.) Dokumentation von Frond&Backend, der Konfigurationsdateien und den TCP-Protokollen (Nepomuck)
  7. Release 2.0
  7a. Release Bosix 0.2 :-)
  8. Spinnof diverser Frontends (Windows, Mac, Java, was-auch-immer)
  9. Projekt "Monitor Manager" als Control-Applikation für ein oder mehrere monitor Server
  10. Entwicklung des @rec-Streamings für die Backend-Version 2.1

...

Andreas

[jhr-online]

@buebchen: Korrekt. :)
@nepomuck: Nicht zu schnell verteilen! Wir haben noch mehr Entwickler und auch noch eine Menge vor. Um das zusammen zu tragen, ist irgendeine Form von live-Gespräch sinnvoll. Ich schlage da Chat vor, weil es das einfachste ist und leicht zu protokollieren ist. Skype kommt mit mir nicht in die Tüte (proprietär), was nicht heißt, dass du nicht jeden anrufen darfst ;)

jhr

[nepomuck]

Nicht zu schnell verteilen! Wir haben noch mehr Entwickler

Ich wollte nur mal ein paar Basics verteilen, damit mal was vorwärts geht. Selbstverständlich sollen so viele mitarbeiten wie möglich.
Lass uns eine Liste der Projektteilnehmer zusammenstellen und dabei berücksichtigen, was wer tun kann und tun möchte.

und auch noch eine Menge vor.

Hier bitte Vorsicht: Lass uns nicht zu viel auf einmal in 2.0 planen, sonst geht das ganze irgendwann baden. Erst Pflicht, dann Kür -- und ich glaube wir sind uns in so weit einig, dass die saubere Trennung von Frond und Backend absolute Priorität hat -- wenn das steht, bleibe genug Zeit, "eine Menge" anderer Dinge dazuzuprogrammieren.

Um das zusammen zu tragen, ist irgendeine Form von live-Gespräch sinnvoll. Ich schlage da Chat vor, weil es das einfachste ist und leicht zu protokollieren ist.

Sehe ich ja ein.
Schlag einen Termin vor, ich kann morgen oder Fraitag sowohl tagsüber als auch mal abends oder spätabends -- immer voraus gesetzt, es brennt nicht :-)

Andreas