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

    Einmal editiert, zuletzt von dl1sdz ()

    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

    Addi,


    Du hattest recht: Diesen Teil des Artikels hatte ich ueberlesen, da ich ihn in Bezug auf dem Cubietruck nicht verstanden habe. Jetzt kenne ich zumindest die Optionen und kann in den Kreisen gezielt nachfragen, an welcher Stelle des Makefiles und mit welcher Option ich es einfügen muss. Verstehen tue ich es immer noch nicht. ( Ist halt High Level Wissen :whistling: )


    Danke für den Hinweis.


    73 de Hajo
    PS: Fast alle haben es verstanden und bedauern es ... troppo tardi, die Zeit geht weiter.

    Moin,

    Zitat von dl1sdz

    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?

    Willst Du fldigi auf dem armhf System mit FPU nutzen?


    Für die Audiosteuerung, ich glaube http://jackaudio.org/ macht so was. Habe ich aber noch nie probiert.


    73, Tom

    Hallo Tom,


    Ich/wir bauen gerade ein digitales Interface für den Solf. Cat geht sowieso, Pan-Adapter über pmsdr funktioniert auch. Ich benutze als zentrale Software Fldigi weil dort Cat, Log und 3000 Hz Wasserfall eingebaut ist. Und das läuft alles auf dem Cubietruck. Wenn ich alles gleichzeitig laufen lasse, incl. Apache, iceweasel, opencloud als Backup für einen zweiten Server mit owncloud und Cloudlog habe ich bei 48 KHz Auflösung mit dem internen adda eine Auslastung von ca. 70-80 %. Ohne Pan Adapter, den ich auf den BBB auslagern kann, habe ich eine Auslastung von ca. 50 %.
    Mit der erweiterten CW Dekodierung ohne FPU Unterstützung war die Auslastung bei 90%. Jetzt hatte ich gelesen, dass ab GCC 4.8 die FPU in gewissem Rahmen genutzt werden kann.


    Ja, ich will dies zumindest probieren. Eine Teilloesung habe ich schon gefunden:


    /path/to/your/cross/gcc -mtune=cortex-a7 -mfpu=neon-vfpv4 $*


    Aber noch nicht ausprobiert.


    Uebrigens Mauri hat in Github eine erste Konvertierung in Python zur Verfügung gestellt.


    73 de Hajo

    Tom,


    Ja jackall macht so etwas auch, aber Linux und Audio kann nervig werden, da meine Audio Verarbeitung auf LMDE läuft, Applikationsbedingt mit allen verfügbaren Soundlayern. Aber das ist hier OT.


    73 de Hajo

    Zitat von dl1sdz

    Ja, ich will dies zumindest probieren. Eine Teilloesung habe ich schon gefunden:


    /path/to/your/cross/gcc -mtune=cortex-a7 -mfpu=neon-vfpv4 $*

    Ich probiere z.Zt. fldigi auch einem Toshiba AC100 Netbook mit einen (Nvidia Tegra Dualcore A9) unter lubuntu 13.04 zu kompilieren.
    Die entsprechenden Optimierungsflags habe ich ins Makefile nach dem ./configure Lauf eingebaut:


    CFLAGS = -g -O2 -I. -mfloat-abi=hard -mfpu=vfpv3-d16 -mtune=cortex-a9
    CXXFLAGS = -g -O2 -mfloat-abi=hard -mfpu=vfpv3-d16 -mtune=cortex-a9


    Der Tegra2 hat nur eine VFP-FPU.


    Bei ARM NEON-FPU Optimierungen sollte man noch beachten, evtl. -funsafe-math-optimizations zu aktivieren.


    Siehe:


    If the selected floating-point hardware includes the NEON extension
    (e.g. -mfpu=‘neon’), note that floating-point
    operations are not generated by GCC's auto-vectorization pass unless
    -funsafe-math-optimizations is also specified. This is
    because NEON hardware does not fully implement the IEEE 754 standard for
    floating-point arithmetic (in particular denormal values are treated as
    zero), so the use of NEON instructions may lead to a loss of precision.


    (Quelle: https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html )

    Hallo DO4KR,


    danke fuers Teilen. Nun weiss ich, dass ich nicht alleine bin.


    Ich werde es mir ansehen. Diese NEON-Geschichte hatte ich gelesen, aber weil ich wiederum zu faul war nachzusehen, was dies nun wieder bedeutet und deshalb gleich wieder vergessen.


    Bin halt nur ein kleiner Anwender und mein Interesse an Hardware ist begrenzt. Man kann nicht alles wissen und machen ;(


    73 de Hajo

    Hallo,
    Mauri (AG1LE) hat einen Wettbewerb ausgeschrieben, indem es darum geht eine Software zu entwickeln, die lernt, aus einer Audiodatei, Morsezeichen zu erkennen und zu interpretieren. Hier ist die Ausschreibung zu finden.


    Der Quasi Wettbewerb findet auf Kaggle statt. Auf dieser Seite sind auch die Evaluationsdateien und das schon erwähnte Python Programm zu finden (, das sehr gut läuft).


    Kaggle bietet eine Plattform für solche Wettbewerbe. Mauri' s Vorschlag wurde akzeptiert und es haben sich wohl schon einige Leute angemeldet.


    Wer mitmachen will, nur zu ...


    73 de Hajo

    Hallo DO4KR,


    Mit diesen Optionen hat es geklappt:
    CFLAGS = -g -O2 -I. -mtune=cortex-a7 -mfpu=neon-vfpv4
    -mfloat-abi=hard -funsafe-math-optimizations
    CXXFLAGS = -g -O2 -mtune=cortex-a7 -mfpu=neon-vfpv4
    -mfloat-abi=hard -funsafe-math-optimizations


    Mit externer Soundkarte: Der Cubietruck läuft bei der Bayesian Dekodierung immer noch hochtourig, aber es gibt keine Aussetzer auch wenn der Signal Browser eingeschaltet ist.
    Bei der Interpretation mit neuronalen Netzen liegt die CPU Auslastung bei 45 %.


    Mit dem internen Codec ist es etwas besser.


    73 de Hajo