ubuntuusers.de

Das ist jetzt erstmal nur eine theoretische Frage, da ich dazu noch in der Planungsphase bin, und noch nicht absehen kann, wie lange ich für die Realisierung benötige.

Also, ich experimentiere schon seit einiger Zeit mit mit der Analyse von Audiosignalen, wie sie im Amateurfunk auftreten. Hauptsächlich also Morsesignale. Momentan mache ich das noch nicht in Echtzeit, sondern analysiere .WAV Dateien, um Problemfälle reproduzieren zu können. Dabei werden dann auch Dateien von Aufzeichnungsgeräten verwendet, die mit höheren Abtastraten arbeiten.

Eigentlich interessiert mich nur der Frequenzbereich von 300 bis 2700 Hz (mehr geben die Geräte nicht her) und dafür reicht eine Abtastrate von 8kHz dicke aus. Wenn jetzt aber Dateien mit 44.1 oder 96 kHz Abtastrate verarbeitet werden müssen (durch die Aufzeichnungsgeräte vorgegeben), steigt die CPU Last stark an und der Lüfter dreht hoch.

Ich frage mich daher, ob es Sinn macht, die Abtastrate vor der Verarbeitung auf 8 kHz herunter zu rechnen. Ich habe aber keine Ahnung wie viel CPU Power das kostet oder ob sich das letztendlich gleich bleibt. Ich frage das, weil so ein Downsampling nach meinen bisherigen Ermittlungen auch nicht gerade eine triviale Aufgabe ist.

Ich bin kein Experte für Audiobearbeitung, deswegen kann ich gerade nicht beurteilen, wie rechen- bzw. zeitintensiv das Downsampling einer WAV-Datei ist. Wenn ich bedenke, dass man bspw. MPD für Streams in Echtzeit das Downsampling machen lassen kann, sollte es aber nicht zu heftig sein.

Verwendet man jetzt so eine Audiodatei bei der Analyse vielleicht sogar mehrfach, dann ist es sicherlich sinnvoll, nicht die Originaldatei sondern eine Kopie mit niedrigerer Abtastrate zu verarbeiten um den Vorgang zu beschleunigen und die CPU zuentlasten. Das jetzt ganz prinzipiell, wie man bspw. in einem Bildarchiv statt der hochaufgelösten Originale (RAW/TIFF) eher JPEGS für das Durchsuchen, Betrachten oder Veröffentlichen verwenden kann.

Meines Wissens nach ist beim Downsampling zu berücksichtigen, dass man einen Low-Pass-Filter verwendet, damit Frequenzen tatsächlich abgeschnitten und nicht mit sogenanntem Anti-Aliasing reduziert werden. Eine 16kHz-Frequenz für eine 8kHz-Abtastrate würde sonst nicht entfernt, sondern als heruntergerechnete 8kHz-Frequenz weiterhin in der konvertierten Datei verbleiben. Mit Sox kann man einen solchen Low-Pass-Filter (sinc) für das Downsampling übergeben und die Ergebnisse sind - soweit mir das zumindest aus zweiter Hand berichtet wurde - sehr gut.

Ich hoffe, es findet sich hier im Forum noch ein Anwender, der dir dazu mehr als eine solch vage Antwort geben kann ☺

Dakuan schrieb:

.... Ich frage mich daher, ob es Sinn macht, die Abtastrate vor der Verarbeitung auf 8 kHz herunter zu rechnen. Ich habe aber keine Ahnung wie viel CPU Power das kostet oder ob sich das letztendlich gleich bleibt. Ich frage das, weil so ein Downsampling nach meinen bisherigen Ermittlungen auch nicht gerade eine triviale Aufgabe ist.

Solange Du das Downsampeln um einen einfachen, glatten Faktor machst, ist das nichts weiter als eine einfache Mittelwertbildung. Also z.B. von 96 kS/s auf 8 kS/s ist schlichtweg der Faktor 12. Du sammelst also einfach 12 "schnelle" Samples, addierst sie und teilst die Summe durch 12 (bzw. 16, das ist zwar dann 2 dB leiser, aber man braucht einfach nur 4 Bit nach rechts zu schieben). Also kein nennenswerter Rechenaufwand, und auch kaum Fehler.

Komplizierter wird es, wenn Du unbedingt um einen krummen Faktor downsampeln willst, also z.B. von 44.1 kS/s auf 8 kS/s ... dann musst Du ziemlich rechnen, um die Fehler einigermaßen auszugleichen. Aber ok, niemand verlangt, dass Du genau 8 kS/s nimmst, 11.025 kS/s gehen ja auch, und schon hast Du wieder einen einfachen, ganzzahligen Fall. 😉

Hier lohnt es sich also, das Downsampeln maßgenau zu machen, dann sparst Du der CPU viel Arbeit.

LG,

track

Aber ok, niemand verlangt, dass Du genau 8 kS/s nimmst, 11.025 kS/s gehen ja auch,...

Verlangen tut das niemand, aber der Wert ist in mehrfacher Hinsicht ideal. Ich will ja nicht nur erkennen, ob eine bestimmte Frequenz vorhanden ist, sondern auch die Dauer der jeweiligen Impulse messen. Bei 8 kHz und 40 Samples habe ich einen Auswertezeitraum von 5 ms. Damit lässt dich prima rechnen.

Ich habe mir natürlich auch schon mal libsamblerate angesehen, aber das scheint mir auch nicht ganz trivial zu sein.

Meines Wissens nach ist beim Downsampling zu berücksichtigen, dass man einen Low-Pass-Filter verwendet, damit Frequenzen tatsächlich abgeschnitten und nicht mit sogenanntem Anti-Aliasing reduziert werden.

Das ist richtig, und daher habe ich gestern schonmal angefangen damit zu experimentieren, allerdings bisher mit zweifelhaftem Erfolg.

@track

Solange Du das Downsampeln um einen einfachen, glatten Faktor machst, ist das nichts weiter als eine einfache Mittelwertbildung.

Das hatte ich so auch gelesen. Irgendwo stand aber auch, dass das auch bei krummen Faktoren gehen soll, indem man dann einfach den am nächsten liegenden Wert nimmt (nearest neighbor). Allerdings bin ich bei meinem ersten Denkansatz dazu davon ausgegangen, (nur) den jeweiligen Abtastwert direkt zu verwenden.

Du schreibst da etwas von "einfache Mittelwertbildung". Könnte das dann schon der Tiefpass sein, den ich dafür auch brauche? Dafür gibt es nämlich stark optimierte Standardlösungen (simple moving average=SMA), die das alles extrem vereinfachen könnten.

Weil die Beschreibung von track so einfach klingt, habe ich das mal ausprobiert. Also grundsätzlich geht das, auch mit krummen Faktoren. Dazu habe ich dann in einer Fehlervariablen immer die Differenz zum richtigen Wert aufsummiert und immer wenn der Wert >= 1.0 ist, wird ein zusätzlicher Abtastwert für den Mittelwert herangezogen.

Ich habe dann aber auch gleich mal den Elchtest gemacht. Dazu habe ich einer meiner Dateien noch einen Pfeifton von 6615 Hz hinzugefügt. Die Frequenz wurde so gewählt, das sie oberhalb 4000Hz liegt und kein vielfaches der Nutzfrequenz von 800 Hz ist (44100/8000=5.5125 → 1200*5.5125=6615).

Das Bild2 im Anhang (Wasserfalldiagramm) zeigt wohl deutlich, das man auf einen Tiefpass nicht verzichten kann. Das Bild zeigt das Nutzsignal bei 800Hz und ein Störsignal bei 1200Hz plus Hintergrundrauschen. Bild 1 zeigt das Ursprungssignal mit 44.1 kHz. Die Zeitachse bei den Bildern läuft von unten nach oben.

Um wieviel die Auswertung damit schneller geht, habe ich noch nicht getestet.

Bei jeder Abtastung musst Du natürlich das Nyquist- Kriterium beachten. (Ich war davon ausgegangen, dass Du das kanntest !)

Das heißt natürlich, das nur Frequenzen bis zur 1/2 Abtastfrequenz auswertbar sind, alles was höher ist, liefert im Zweifel Interferenzen mit der Abtastfrequenz oder Vielfachen davon. (→ daher auch Dein Störsignal von 8000-6615=1385 Hz ! _{(und nicht 1200 Hz)})

Allerdings sollte das meiste schon herausfliegen, wenn Du ganz stumpf immer 4 Abtastwerte (direkt, nicht gleitend) ausmittelst, denke ich mal.
<sub>(Und sollte das nicht reichen, dann kannst du durch einführen von ein paar Wertungsfaktoren beim Aufaddieren gleich an dieser Stelle einen digitalen Tiefpass mit einbauen !
- auch das ist nur minimaler Aufwand, man muss es nur verstanden haben.)</sub>

Lies Dich mal etwas in die Abtasttheorie ein, dann findest Du Dich damit besser zurecht.

LG,

track

Das Nyquist- Kriterium ist mir natürlich bekannt. Das ist ja auch der Grund, weshalb ich den Test mit einer Frequenz oberhalb von 4000 Hz gemacht hatte. Ich hatte die leise Hoffnung, das die Mittelwertbildung die notwendige Bandbreitenbegrenzung mit erledigt. Aber das betrifft dann wohl nur die Frequenzanteile nach der Umwandlung.

Leider muss ich zugeben, das die Alias Frequenz tatsächlich bei 1385 Hz liegt. Ich habe das jetzt mal pixelmäßig ausgezählt. Allerdings habe ich mir noch keine gedanken gemacht, woher die anderen 3 Frequenzen kommen. Die liegen nach meiner Auszählung etwa bei 2285Hz (kaum sichtbar), 2450Hz und 2690Hz (16.625Hz pro Pixel). Ich bin da wohl von falschen Annahmen ausgegangen.

Allerdings sollte das meiste schon herausfliegen, wenn Du ganz stumpf immer 4 Abtastwerte (direkt, nicht gleitend) ausmittelst, denke ich mal.

Da bin ich mir jetzt aber nicht mehr sicher, es sei denn wenn das vor der Umwandlung stattfindet. Das kann ich aber momentan nicht testen. Ich muss erst meine Programmstruktur abändern. Bisher habe ich die .WAV Dateien blockweise gelesen, was mir jetzt nicht mehr zweckmäßig erscheint.

Übrigens, das mit dem gleitenden Mittelwert bei der Konvertierung war Blödsinn. Der Mittelwert muss jedesmal neu ermittelt werden. Aber als zusätzliche Maßnahme vor der Konvertierung währe das einen Versuch wert. Zumal der Aufwand dafür deutlich geringer ist als bei "normalen" Filtern.

(Und sollte das nicht reichen, dann kannst du durch einführen von ein paar Wertungsfaktoren beim Aufaddieren gleich an dieser Stelle einen digitalen Tiefpass mit einbauen !

Das ist leider nicht ganz trivial.

- auch das ist nur minimaler Aufwand, man muss es nur verstanden haben.)

Genau damit kämpfe ich noch. Ich hatte ja schon Anfangs angedeutet, das ich mich daran bereits versucht hatte. Aber ich versuche noch herauszufinden, wie die Parameter berechnet werden. Was ich bisher habe, entspricht wohl nur einem einfachen RC-Tiefpass (nur 1 Tap). Als nachgeschaltetes Filter ist dessen Wirkung auch gerade noch erkennbar. Aber wie gesagt, für weitergehende Versuche muss ich meine Programmstruktur verändern, da bei einer Samplerate Konvertierung mit krummen Faktoren die Anzahl der zu lesenden Samples im Voraus schlecht bestimmbar ist.

Jedenfall hoffe ich immer noch, das eine vorherige Konvertierung zu weniger CPU Last führt.

Sorry, das ich das noch einmal aufwärme.

Ich denke ich habe jetzt eine zufriedenstellende Antwort gefunden. Nicht zuletzt dank dieser Webseite ist es mir gelungen ein brauchbares Filter zu erstellen, mit dem man die Alias-Frequenzen gut unterdrücken kann.

Nach dem Studium anderer Dokumente habe ich zwar das eigentliche Filterprogramm etwas modifiziert, aber die Berechnung der FIR Filterparameter war sehr hilfreich. Mit einen FIR Filter mit 11 Taps und einer Grenzfrequenz von 3000Hz sieht mein Ergebnis schon deutlich besser aus (siehe Anhang).

Wenn man davon ausgeht, dass bei einem FIR Filter nur einfache Multiplikationen und Additionen stattfinden, bei einer FFT aber zusätzlich einige Male die sin() Funktion benötigt wird, dürfte sich in der Summe eine Leistungsverbesserung ergeben. Messen konnte ich die bisher aber nicht, da die Grafische Oberfläche den Hauptteil der CPU Last ausmacht.

Auf dem Bild ist bei genauem hinsehen die störende Alias Frequenz zwar gerade noch erkennbar, aber ich denke sie ist jetzt ausreichend gut unterdrückt.

Dakuan schrieb:

.... Mit einen FIR Filter mit 11 Taps und einer Grenzfrequenz von 3000Hz sieht mein Ergebnis schon deutlich besser aus (siehe Anhang).

Das ist völliger Overkill ! - Du willst ja kein HiFi-Zeugs, sondern einen Morsedecoder, da ist der Frequenzgang im Durchlassbereich völlig egal. (selbst die härteste Chebychev-Charakteristik würde da noch reichen) - Du brauchst real höchstens 5 Taps in Deinem Filter !

Auf dem Bild ist bei genauem hinsehen die störende Alias Frequenz zwar gerade noch erkennbar, aber ich denke sie ist jetzt ausreichend gut unterdrückt.

Wie gesagt, Störungen die mehr als 20 dB schwächer sind als das Nutzsignal, kannst Du sowieso vergessen, für den Decoder.

Wenn Du es ganz hart filtern willst, kannst Du ja eine PLL für Deine Nutzfrequenz davor setzen. Dann ist so ziemlich alles an Störungen egal, solange es nicht wesentlich stärker ist als das Nutzsignal. _{(das geht natürlich auch digital !)}

Programmier Dir einen digitalen Quadratur-Demodulator, dann hast Du PLL-Funktion und Demodulator in Einem, und bist fertig !
(→ Hier etwas Erklärung dazu )

LG,

track

Das ist völliger Overkill !

Es ist immer wieder schön, mal die Meinug von jemanden zu hören, der etwas von der Materie versteht (oder zumindest mehr als ich).

Zu den 11 Taps bin ich gekommen, weil ich hier 2 Quellen hatte und ich somit die Ergebnisse vergleichen konnte. In dem zuvor geposteten Link werden in der Beispielimplementation 51 Taps verwendet, die ich dann zum Vergleich auf 11 reduziert hatte. Die von diesem Programm ausgegebenen Koeffizienten stimmten dann recht gut mit einer anderen Quelle überein. Da ich allgemein über FIR Filter immer gelesen hatte, das deren Nachteil die große benötigte Anzahl von Tabs ist, hatte ich mich nicht getraut, noch weiter herunter zu gehen. Aber das kann ich jetzt nachholen (die nötige Vorarbeit ist erledigt).

... da ist der Frequenzgang im Durchlassbereich völlig egal.

Das ist richtig. Tatsächlich würde ich Filtertypen wie Cauer, Chebyscheff Typ 1 oder Butterworth (in dieser Reihenfolge) bevorzugen, aber nach dem was ich bisher gelesen habe, lassen sich diese nur als IIR-Filter implementieren. Und dazu habe ich bisher noch keine brauchbare Berechnungsmethode gefunden. Zumal da dann immer darauf hingewiesen wird, das die Filterkoeffizienten bei IIR Filtern immer auf ihre Stabilität überprüft werden müssen.

Wie gesagt, Störungen die mehr als 20 dB schwächer sind als das Nutzsignal, kannst Du sowieso vergessen, für den Decoder.

Um wieviel das Störsignal jetzt genau unterdrückt ist, kann ich nicht wirklich sagen. Dazu müsste ich dann auch meine Automatische Helligkeitsregelung im Wasserfall-Display abschalten und die Eingangswerte protokollieren.

Tatsache ist aber, das meine bisherigen normalen Störsignale (weißes Rauschen) etwa bei -9 DBFS und die Nutzsignale etwa bei -18 bis -21 DBFS liegen. Das ist der kritische Bereich, wo dann zusammen mit Phasenjitter bis 40% der Decoder an seine Grenzen stößt.

Für die eigentliche Decodierung nutze ich aber kein Bandpass, wie das viele andere Programme machen, sondern den Goertzel-Algorithmus, der leider in der deutschen Literatur sehr nachlässig behandelt wird. Aber er ist relativ einfach anzuwenden, vorausgesetzt die Zielfrequenz ist recht genau bekannt. Allgemein wird der zwar als Sonderform der FFT bezeichnet, aber ich habe auch schon gelesen, das dies ein "komplexer Resonator" sei (was immer das jetzt genau sein soll). Jedenfalls ist der Algorithmus relativ schmalbandig (bei f-sample=8000 und 40 Samples ca. 200 Hz). Daher hatte ich schon überlegt, die Filterung vor der Konvertierung gabz sein zu lassen. Aber ich habe ja auch noch im Hinterkopf irgendwann mal zusätzlich RTTY Signale zu decodieren. Da kämen dann noch weiter Frequenzen ins Spiel. Und wie sich mein weißes Rauschen bis 20kHz bei der Konvertierung der Samplerate auswirkt, konnte ich bisher auch nicht testen.

Das man rein softwaremäßig eine PLL realisieren kann, höre ich jetzt zum ersten Mal, obwohl das nicht abwegig ist. Aber wenn man weiss, wie heftig sich Störungen bei KW Empfang auswirken können, halte ich das nicht für zweckmäßig. Zumal ich ja gerade versuche auch Verbindungen mitzuschreiben, bei denen die beteiligten Stationen nicht exakt auf der gleichen Frequenz arbeiten und dabei auch noch unterschiedliche Geschwindigkeiten verwenden. Das ist eine Herausforderung, die von den bisher etablierten Programmen nur mäßig bewältigt wird.

Wir reden hier insgesamt über 2 grundsätzlich verschiedene (digitale) "Baugruppen":

1. Samplerate- Konverter. → Hier ist das Problem mit den Interferenzen aufgetreten, das Du mit einem digitalen Filter beseitigen wolltest.
   Deshalb bietet es sich an, diese beiden Funktionen zu kombinieren, indem man z.B. die vergangenen 4 Samples direkt als "FIR- Taps" benutzt (hier bekommst Du die Verzögerung direkt "gratis" geliefert !) → mit geeigneten Wertungsfaktoren) und erst danach die Summe über die 4 Samples.
   _{(Das ist das, worauf ich oben schon mal hingewiesen hatte !)}

2. Die eigentliche Detektorfunktion. → hier bietet sich ein PLL- Algorithmus an, um Störungen auf "Nebenfrequenzen" zu minimieren.
   Stichwort Korrelationsempfänger. _{(Vor 20 Jahren habe ich mal sowas entwickelt, für DCF77- Signale.)}

Diese beiden Baugruppen kannst Du sehr gut unabhängig voneinander entwickeln. Wichtig ist nur, dass Du zuerst die ingenieurstechnische Konzeption machst, und die dann in einen Algorithmus gießt. Mit "Try-and-Error" geht hier nichts, dazu ist die Materie zu tückisch. (nicht komplex ! - wenn man es richtig macht, sind die Algorithmen sogar ziemlich einfach.)

LG,

track

Deshalb bietet es sich an, diese beiden Funktionen zu kombinieren, indem man z.B. die vergangenen 4 Samples direkt als "FIR- Taps" benutzt (hier bekommst Du die Verzögerung direkt "gratis" geliefert !) → mit geeigneten Wertungsfaktoren) und erst danach die Summe über die 4 Samples.

Das hatte ich auch öfters gelesen, hatte aber nicht begriffen, wie man das realisieren kann. Auch ein Blick in den Quelltext von Fldigi brachte mich erstmal nicht weiter. Ich hatte immer den Eindruck, dass das nur mit ganzzahligen Verhältnissen geht. Aber nach einer Diskussion mit anderen PC Anwendern gestern Abend, sehe ich das etwas anders.

Der Speicher ist das Filter selber. und ob ich da jetzt in unregelmäßig wechselnder Folge jeden 5-ten oder 6-ten Wert weitergebe, sollte die eigentliche Filterfunktion nicht interessieren. Das muss ich aber noch ausprobieren.

Übrigens habe die Taps jetzt auf 7 herabgesetzt, bei 5 war ich mit dem Ergebnis noch unzufrieden.

hier bietet sich ein PLL- Algorithmus an, um Störungen auf "Nebenfrequenzen" zu minimieren.

Da bin ich jetzt nicht ganz sicher, aber ich werde das mal im Auge behalten und bei Gelegenheit wieder aufgreifen. Momentan habe ich da noch keinen Denkansatz dazu. Bisher bin ich auch immer davon ausgegangen, das man für eine PLL ein konstant vorhandenes Signal benötigt, was ja bei Morsetelegrafie nicht gegeben ist.

Wichtig ist nur, dass Du zuerst die ingenieurstechnische Konzeption machst, und die dann in einen Algorithmus gießt.

Hierzu sollte ich vielleicht noch anmerken, das mein bisheriges Programm eigentlich nur sowas wie ein "Analysetool" ist, mit dem ich erstmal ausprobieren will, was mit wie viel Aufwand realisierbar ist. Über ein Gesamtkonzept kann ich erst nachdenken, wenn ich weiss, welche Bausteine mir zur Verfügung stehen.