Guten Tag, ich habe probleme bei dem Berechnen von den Filterkoeffizienten eines FIR-Filters. Gegeben sind folgenden Werte: Durchlassbereich 0 – 1kHz Sperrbereich ab 5kHz nach einiger Recherche habe ich keinen wirklichen Ansatz gefunden, ich hoffe jemand könnte mir helfen! :)
markus99 schrieb: > nach einiger Recherche habe ich keinen wirklichen Ansatz gefunden, ich > hoffe jemand könnte mir helfen! Lade dir die "dspguide.pdf" herunter und lies die. Da sind auch Beispiele in BASIC mit drin. Ansonsten: - Filterkoeffizienten nach sin(x)/x berechnen (läuft von -N/2 bis +N/2) - Fensterfunktion deiner Wahl drauf - Normalisieren - fertig. Die Frequenz wird hier nicht in Hz oder kHz angesagt, sondern als Bruchteil der Sample-Frequenz. W.S.
Nachtrag: Habe das eben so kurz wie möglich gehalten, weil ich schon mal von anderen hier genau deswegen angerempelt worden bin. War damals allerdings auch ein Bandpaß und nicht nur ein Tiefpaß. Mittlerweile geht sogar eine gezielte Phasenveschiebung beim Filtern, so daß man sich für das Demodulieren von SSB die anschließende Hilbert-Transformation sparen kann. W.S.
Vielleicht sollte man ERST die Filterstruktur festlegen, bevor man nach Koeffizienten fragt. Die Angaben Durchlassbereich und Sperrbereich sind auch nicht zielführend. Die jeweilige Dämpfung muss vorgegeben werden. Daraus resultiert dann die minimale Qualtität und Optionen, welchen Filter man üerhaupt nutzen muss, wieviele Kaskaden Stufen TAPs er haben muss. Und auch das ist noch nicht alles. Man kann einen Filter so bauen, dass er im Sperrbereich glatter ist oder im Durchlassbereich.
Audiomann schrieb: > Vielleicht sollte man ERST die Filterstruktur festlegen, bevor man nach > Koeffizienten fragt. Du theoretisierst herum. Das Allererste bei sowas ist eine Betrachtung, wieviel Zeit (sprich Takte) man hat zwischen zwei Samples. Das ist das, was den Rahmen setzt. Danach kommt dann, wie lang (wieviele Taps) der Filterkernel maximal haben kann. Alles andere kommt danach. Und wenn du mal verschiedene Fensterfunktionen vergleichst, dann siehst du sehr deutlich, was die für einen Einfluß auf die Flankensteilheit, die Tiefe des Sperrbereiches usw. haben. Speziell beim Kaiser-Fenster ist das Justieren des Beta ne wichtige Sache. So herum. W.S.
W.S. schrieb: > Das Allererste bei sowas ist eine Betrachtung, > wieviel Zeit (sprich Takte) man hat zwischen zwei Samples. ? Das ist das Pferd von hinten aufgezogen. Du kannst dann nur das bauen, was die Frequenzkonstellation zulässt. Der eigentlich richtige Weg wäre, die Qualität des Signals festzulegen und dann abzuschätzen, welchen Rechenbedarf es erzeugt, um danach den richtigen Prozessor auszusuchen. Nennt sich requirement driven development. Ein theoretischer Begriff mit sehr viel praktischer Bedeutung.
Tobias N. schrieb: > Das ist das Pferd von hinten aufgezogen. Du kannst dann nur das bauen, > was die Frequenzkonstellation zulässt. Ist ja logisch! Man kann nur das realisieren, was technisch auch realisierbar ist. Wenn die Ansprüche ins Astronomische wachsen, muß man entweder sie herunterschrauben oder sich ins rein Theoretische flüchten. tertium non datur. Ich halte das nicht für "das Pferd von hinten aufgezogen" sondern für den realistischen Weg. W.S.
markus99 schrieb: > Gegeben sind folgenden Werte: > > Durchlassbereich 0 – 1kHz > > Sperrbereich ab 5kHz Hast Du Zugriff auf Matlab (Firma, Hochschule)? Da gibt es sehr nützliche Tool zur Filterberechnung: https://de.mathworks.com/help/signal/ug/fir-filter-design.html Von Hand macht das heute niemand mehr. Natürlich fehlen oben noch Angaben, wie Sperrdämpfung, Abtastrate etc.
Mike schrieb: > Von Hand macht das heute niemand mehr. Mit dieser Einstellung degradiert man sich zum reinen Benutzer ohne Ahnung, wie das Ganze überhaupt funktioniert. Aber ich hätte da einen Tip: es gibt seit einiger Zeit Dinger, die man gemeinhin als PC bezeichnet und wenn man sowas richtig programmiert, dann kommt auch ein richtig berechneter Filterkernel dabei heraus. Die Handarbeit konzentriert sich dabei auf das Schreiben des Quellcodes. Und Matlab hat nicht jeder, sowas kostet richtig Geld. W.S.
Mir gefällt der kostenlose Iowa Hills FIR-Designer sehr gut. Auch zum Abschätzen, was bei unterschiedlicher Tap-Anzahl an Frequenzgang rauskommt. Aber ich musste auch schmerzlich erfahren, dass in meinem Fall selbst ein 100MHz 32Bit-Prozessor zu keinem vernünftigen FIR (>20 Taps) reicht. Kaskadierte MAVs gehen bei fast jedem Prozessor, nur der Frequenzgang ist besch...eiden.
Elektrolurch schrieb: > Aber ich musste auch schmerzlich erfahren, dass in meinem Fall selbst > ein 100MHz 32Bit-Prozessor zu keinem vernünftigen FIR (>20 Taps) reicht. Nun dann schätze ich mal, daß das Verhältnis Samplefrequenz/Eckfrequenz weitaus zu groß war oder daß deine Vorstellungen über digitale Filter schlichtweg zu astronomisch waren. Also hier mal eine grobe Hausnummer: Bei einer Samplefrequenz von 44 kHz schafft man es auf einem 100 MHz Arm Cortex M4F, einen SSB fähige Bandpaß von etwa 300 Hz bis etwa 3 kHz mit an die 201 (immer ungeradzahlig!) Taps hinzukriegen. W.S.
Mike schrieb: > Hast Du Zugriff auf Matlab (Firma, Hochschule)? Da gibt es sehr > nützliche Tool zur Filterberechnung: > https://de.mathworks.com/help/signal/ug/fir-filter-design.html die Randbedingungen, die in einen Filter und dessen Struktur einfließen müssen, lassen sich in MATLAB überhaupt nicht einbringen. MATLAB sagt dir nicht, welche Filterstruktur die beste ist, sondern ermittelt lediglich für eine von dir gewählte Form die Koeffizienten. Schon wenn es an die Umsetzung geht und festzulegen ist, wie stark man den Filter überabtastet und wieiviele TAPs und welche Auflösung nötig ist, kommt ein ganzes Feld von Lösungen heraus, die man einzeln abklappern müsste, um das beste zu erhaschen. Ohne die Erfahrung und eine Ahnung, wohin die Reise geht, ist das nicht zielführend.
ich glaub in simulink kann man auch fürs target simulieren. dann weiß man auch schon grob ob der uc schnell genug ist zum echtzeitfiltern
Matlab kann kein Entwurfsdenken ersetzen, sondern ist ein Simulationswerkzeug, um seine Ideen zu prüfen und das möglichst einfach, schnell und ohne sich zu verrechnen. Was Filter und Optimierung angeht, ist MATLAB eher dumm. Koeffizienten kann man für einen Filter nur dann optimieren, wenn man weiß, wie die Eingangsdaten aussehen. Ansonsten muss man weißes Rauschen für den Input annehmen annehmen und kann die Filterfrequenzen nicht gewichten. Damit ist man aber in aller Regel sehr weit weg von der Realität, denn es gibt sehr wenige Anwendungen, deren Daten ein Spektrum aufweisen, welches einem gleichverteilten weißen Rauschen nahe kommt. Schon an der Stelle ist das, was Matlab liefert, also bereits suboptimal! Nimmt man z.B. Audio, dann kommt der Nutzer wenigstens noch auf die Idee, das klassische Rosa Rauschen einzuprägen, um den Filter zu testen. Wie man von da auf gute Koeffizienten kommt, muss man aber auch wieder selber wissen, da MATLAB erst einmal nur stumpf drauflos rechnet und nichts von der Anwendung weiß. Audioanwendungen, wie man sie in der Musik- und Tonbearbeitung braucht, haben eben kein rosa Spektrum und damit sind die Matlab-Koeffizienten für die Tonne. Und dann kommen solche Themen wie Daten mit Offset und BIAS. Will man das maximale aus seiner Auflösung herausholen, dann muss man bei INT die Koeffizienten richtig runden. Habe noch keine MATLAB Funktion gesehen, die das richtig macht, obwohl der Überlauffall nur 2 Betrachtungen erfordert. Man kann dem Filter diese Randbedingungen eben nicht mitgeben und muss nacharbeiten. Dann nehme ich doch lieber gleich das Excel. NeeNee, MATLAB macht da ohne ausdrückliche Manipulation der Daten erst einmal gar nichts perfekt. Das kann man z.B. an den Daten des RKI sehen: Es gibt 100 Ansätze, wie man die täglich eintreffenden COVID19-Inzidenzen so filtert, daß der Wochenrhythmus rausfliegt und man die geschätzte tägliche Inzidenz bekommt, die sich weitgehend unabhängig von Zufällen ausreichend genau abbildet. Ich habe aber noch keinen gesehen, der das Wochengehoppel vernünftig eliminiert hätte, dabei wäre die Lösung eigentlich einfach: Pauschaler Halbbandfilter über 3 Tage, um die 1-tägige Meldeverzögerung rauszukriegen. Pauschaler 7-Tage-Filter mit span = (Wurzel 2) / 2 -> 7*1,41 = 10 Tage. Extrapolation der Tage 7...4 über die letzten drei Tage hinweg. Fertig ist die Laube! Wer es ganz dolle mag, davor noch einen diskreter Filter auf die Tagesinzidenzen, wenn die Meldung 0 ist, bzw. mehr als Faktor 1.4 vom Schätzergebnis ausweicht. Dann darf ein Wert auch mal 2 Tage beim Gesundheitsamt verbummeln, ohne sich zu sehr auszuwirken.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.