CW Analyseverfahren in Fldigi und anderswo

  • Hallo,


    Wer sich mit Cw Analyseverfahren (Dekodierung unter realen Bedingungen) beschaeftigt, sollte sich die Artikelserie von Mauri zu Gemuete führen
    AG1LE


    Die Artikelserie entstand über mehrere Jahre und beschäftigt sich mit Verfahren, wie Morsezeichen aus dem Rauschen erkannt und dekodiert werden können. Es kommen dabei u.a. Ansätze des maschinellen Lernens zum Einsatz. Alles mit Sourcecode in u.a. GNU Octave und mit den entsprechenden Modifikationen in Fldigi.


    Das Spannendste was ich in den letzten Jahren gelesen habe, aber ich bin noch nicht durch, da die zitierte Begleitliteratur immens ist.


    Unbedingte Leseempfehlung!


    73 de Hajo

  • Hallo,


    So jetzt bin ich mit den 22 Einträgen durch. Meine Empfehlung: lest die Artikel chronologisch, dann werden einige Vorgehensweisen transparenter. Wer den Bayesian Decoder nur ausprobieren will, findet im zusammenfassenden Teil 6 die notwendigen Links. Man sollte aber zumindest 1-5 gelesen haben, um zu verstehen, wo die Probleme und deren Lösungen liegen.


    Zusammengefasst: Die Vorgehensweise ermöglicht aehnliche Ergebnisse wie der Skimmer, und der ist schon sehr gut. Auch dieser benutzt wohl Neuronale Netzwerke. Im letzten Artikel wird eine kürzlich freigegebene Python Bibliothek Nupic eingeführt, die auch in den letzten Entwicklungen von Joe Taylor verwendet wurden ... Und mit denen ich meine Probleme hatte.


    Da sag nur noch mal einer, dass im Amateurfunk nichts passiert. Mit dem Einbezug der Erkenntnisse der Hirnforschung im Bereich maschinellen Lernens, sind wir auf dem Stand der Forschung. Und das Anwendungsgebiet CW in "natürlicher" Umgebung ist ein geeignetes Testfeld, da es vom Symbolumfang eingeschränkt ist, aber durch die HF Umgebung beliebig komplex gestaltet werden kann.


    73 de Hajo

  • Moin,


    ich habe zwar nur kurz geschaut, sieht aber sehr interessant aus. Tnx fer info!


    Aber, gibt es bereits ein Verfahren, dass mir die Zeit verschafft, mich mit all den Dingen beschäftigen zu können? Mein DeLorean ist leider kaputt, vom Zug überrollt :D


    73, Tom

  • Hallo,


    wer auf die Idee kommen sollte, das Programm von Mauri auf einer alten Linuxgurke zu installieren, kann sich die Arbeit sparen.


    Ich habe das Programm auf einem Cubietruck ( 1Mhz 2 Kernel 2 GB Ram) ohne Probleme kompiliert.
    Ohne die bayesiche Dekodierung lief FlDigi incl. aller Optionen (Cat, snd, ...) ausser pulseaudio mit ca. 50 % Auslastung der Kernel.
    Wenn ich die bayeische Kodierung eingeschaltet habe, lag die Last bei ueber 90 %, wenn ich das Fenster für die Multi-Kodierung eingeschaltet habe, wurden zwar bis zu 30 Kanaele erkannt, aber die Dekodierung konnte man den Hasen geben.


    Ich probiere es jetzt auf einem schnelleren Linux Rechner.
    [Nachtrag: Auf einem Intel 2* 1,6 GHz Prozessor laeuft FlDigi in der modifizierten Version ohne Probleme.]


    73 de
    Hajo

  • hallo hajo,


    waere vielleicht was fuer den odroid u3 .... 4 kerne, 1.7ghz und 2gb ram.
    interessantes kistchen.
    gibt es bei pollin bzw. hardkernel.com


    73 de addi / dc0dw

  • Hallo Addi,


    bin ich ueberfragt, da ich die Architektur nicht kenne. Es waren nicht die zwei Kerne beim Cubietruck, an denen es gescheitert ist. Dieser hat sogar eine armhf Architektur. Also hat eine floating Point (FPU) Unterstützung. Aber die wird von Debian nur teilweise oder wenig unterstützt und ich habe beim Compiler nicht die richtige Option gefunden, um dies zu optimieren und hatte keine Lust weiterzusuchen.


    Das Verfahren verwendet aber einen Eimer voll von floating point operations. Wenn das vom Odroid nicht unterstützt wird, bzw. die Compiler für die Architektur nicht angepasst werden, duerfte es genauso eng werden.


    Demnaechst kommt der Cubietruck mit 8 Kernen raus, aber siehe oben.


    Da ist noch viel im Fluss und leider kommen die Geraete schneller auf den Markt als die Software- und Systementwickler folgen koennen oder wollen.


    73 de Hajo

  • hallo HaJo,


    dankefür die Info.
    hier eine kurze Spezifikation des ODROID U3.


    Prozessor Samsung Exynos4412 Prime Cortex-A9 Quad Core 1,7 GHz mit 1 MB L2 Cache
    Memory 2048 MB (2GB) LP-DDR2 880 Mega Data Rate
    3D Accelerator Mali-400 Quad Core 440 MHz
    Video unterstützt 1080p über HDMI-Kabel (H.264+AAC based MP4 container format)
    Video Out micro HDMI connector
    Audio Standard 3,5 mm Kopfhörerbuchse, HDMI Digital
    LAN 10/100 Mbps Ethernet mit RJ-45 Jack (Auto-MDIX support)
    USB 2.0 Host High Speed Standard A-Typ Connector, 3x Ports
    USB 2.0 Device ADB/Mass storage (Micro USB)
    Display HDMI Monitor
    Speicher (optional) Micro SD-Kartenschacht, eMMC Modul-Sockel
    Betriebsspannung 5V-/2A (Hohlbuchse 2,5/0,8mm + innen)
    System Software Linux: Xubuntu 13.10 oder ältere Versionen
    Android: u-boot 2010.12, Kernel 3.0.x, Android 4.x
    Maße (LxBxH) 83x48x20 mm
    Gewicht 50 g inkl. Kühler


    Gruss
    Addi

  • Hallo ,
    sollte nur als Info dienen ..zum Abrunden meines Beitrages.


    jetzt nicht drauf rumreiten


    73 de Addi / DC0Dw

  • Hallo,


    Ein kurzer Zwischenbericht:


    Ich habe versucht mit zwei Installationen von Fldigi die beiden Algorithmen auf demselben Audiostream zu testen, aber leider waren auf meiner Seite die Bedingungen so schlecht, dass ich zu keinen aussagekraeftigen Ergebnissen gekommen bin.
    Das Multidekoding funktionierte mit bis zu 30 Audiokanaelen bei 3000 Hz Bandbreite prinzipiell. Allerdings hatte ich selten mehr als 3 Signale und war dann mit der Einstellung des Squelchs beschäftigt. Bis ich das geregelt bekam waren meist die Durchgänge beendet. Schwierig war die Einstellung auch bedingt durch die grosse Latenzzeit. Im Kopf wusste ich was kommt, aber am Bildschirm dauerte es.


    Bei der Dekodierung von Einzelsignalen hatte ich weiterhin damit zu kämpfen, dass die Signal oft nur knapp über dem Rauschpegel lagen. So war der Dekoder von Mauri manchmal unterlegen. Aber auch hier lag es zum Teil an mir, da ich in der Kuerze der Zeit nicht die optimalen Filtereinstellungen gefunden habe.


    Zusammenfassend: Die Dekodierung der "alten" Software ist im Vergleich zu Versionen vor ca. 2 Jahren sehr viel besser geworden.
    Die Dekodierung mit dem bayesischen Verfahren erscheint vergleichbar, hat aber noch Optimierungspotential .
    Der Skimmer ist immer noch besser, erleichtert sich aber die Arbeit, da er mit sehr viel mehr Constraints arbeiten kann.


    Ich mache jetzt erst einmal eine Lesepause und warte auf bessere Bedingungen + Contests.


    Zwei Fragen zur Linuximplementation :
    1. Gibt es ausser mit pavucontrol einen anderen Weg fldigi davon zu ueberzeugen, den Audiostream am LineIn- /Mikrofoneingang an den Kopfhoererausgang weiterzureichen ? (Ich habe das hardwareseitig gelöst.)
    2. Kennt jemand die c++/g++ Optionen, um bei Armhf die FPU anzusprechen/optimieren?
    (Gern auch peEmail)


    73 de Hajo