Filter für PWM

Hallo Dirk,

ja, ich habe die Schaltung eben mal mit PSpice simuliert, sieht nach Butterworth oder so aus, der Frequenzganz sieht ganz gut aus auch mit LM324. Was mir auffällt ist, daß die 2. und 3. Stufe eigentlich vertauscht werden müssen, weil der 2. OP bei 4 KHz um 2 verstärkt und bei 5Vss übersteuert wird, also darf die Amplitude des Sinus nur max.

Hm, habe ich simuliert, sieht da ganz anders aus, das müßte fast wie DC

Das kann eigentlich nicht sein, da fehlt noch Information. Hast Du einen Sinusgenerator an den Eingang angeschlossen, Impedanz 50 Ohm? Das Spektrum mit PSpice zu berechnen ist etwas mühsam, aber das kann ich mir erstmal sparen, der Fehler in der 1. Stufe ist zu deutlich, den würde ich zuerst beseitigen.

Das Filter hat bei 20 KHz eine Sperrdämpfung von 77 dB, das sollte dicke reichen.

Mit welcher PWM-Frequenz schaltest Du denn nun, mit 20 KHz?

Zuerst ist die 1. Stufe des TP völlig daneben, die muß erstmal laufen.

Ich habe Deine obigen Messungen immer noch nicht richtig verstanden. laufen die alle über PWM oder hast Du auch einen reinen Sinus draufgegeben? Wenn Du mit 20 KHz PWM arbeitest, kannst Du IMHO bis ca. 2 KHz Sinus im Flash gehen, das sollte ok sein. Höher darfst Du nicht gehen, egal ob mit Filter oder ohne, das hat nämlich keinen Einfluß, dann kömmen sonst nur noch Störungen raus.

mfg. Winfried

also ich guck mir das nochmal an, wird aber einige Tage dauern, bis ich da wieder drin bin. Eine Ausgabe für GnuPlot und Matlab hab ich schonmal programmiert. Mir fällt auch ein, daß eine Auswertung der Zeitfunktionen von SPICE sinnvoll wäre, da mir das Spektrum in PSpice nicht so gut gefällt. Es sollten sehr lange FFTs möglich sein und das Ganze über simples File-IO laufen, da muß ich dann einiges austesten.

mfg. Winfried

Halloe Winfried

erstmal ein Dankeschön für Deine tatkräftige Unterstützung.

Winfried Salomonschrieb: "

Das muss ich hier noch mal prüfen. Ich habe die Bauteilwerte mit dem Programm "Filter Pro"

Die Stufen sind dort allerdings anders angeordnet, wie Du bereits erwähnt hast. Ich bin davon ausgegangen, das jede Stufe eine Verstärkung von eins hat.

So hab ich das auch in der Simulation gesehen. Nur ein wenig Restwelligkeit. Den letzten Satz verstehe ich aber nicht.

Ich habe lediglich einen Sinusgenerator mit Vpp=5V und Vdc=2,5V angeschlossen.

Angestrebt ist PWM ca. 20kHz, dann könnte ich 10bit ausgeben (20Mhz/1024). Ich könnte aber auch auf 40kHz oder 80kHz gehen.

Die Messung oben waren jetzt nur mit dem beschriebenen Sinussignal.

-------------

Inzwischen habe ich etwas weiter "gespielt". Die Verzerrungen verschwinden völlig, wenn ich die Kondensatoren, welche vom Ausgang zurückkoppeln, entferne. Das betrifft die beide Stufen. Ab dann ist auch Ruhe im Lautsprecher bei 20kHz. Die Dämpfung ist natürlich bescheiden. Bei 5V Eingangsspannung sehe ich dann immer noch ca. 700mV am Ausgang.

Kann es irgendwie damit zu tun haben, dass ich keramische Cs verwende? Für Folie habe ich keinen Platz, da alles in SMD ist. Leider habe ich auch keine zum probieren hier.

mfG Dirk

Hallo Dirk,

das Filter ist ja soweit ok, die Verstärkung 1 ist nur bei DC überall gleich, bei 4 KHz wird die 2. Stufe übersteuert um Faktor 2.

Die 1. Stufe funktioniert nicht, die dahinter filtern das Resultat der

1. und am Ausgang kommt sicher Unsinn heraus.

Ja, die 1. Stufe funktioniert nicht.

Ich habe grade nochmal die PWM unter verschiedenen Bedingungen simuliert. Es ist relativ schwierig, die digitale Erzeugung der PWM mit uC zu simulieren, weil das Verfahren mir nicht bekannt ist. Bei einer bestimmten symmetrischen Erzeugung könnte bei 20 KHz PWM noch 4 KHz Signal möglich zu sein. Das mußt Du einfach mal ausprobieren. Durch die Abtastung bekomme ich ein großes Grundrauschen, das S/N habe ich aber nicht bestimmt, am besten probieren.

Wenn ich es analog simuliere mit Dreieck oder Sägezahn und Komparator, so habe ich zwar kein Rauschen, aber bei 20 KHz PWM und 4 KHz Signal sehr große Störkomponenten unterhalb 4 KHz.

Dann würde ich erstmal die 1. Filterstufe ohne PWM zum Laufen bringen.

Keramische Cs in Filtern zu verwenden, würde ich nicht machen. Die sind so stark spannungsabhängig, daß Dir vermutlich das Filter instabil wird. Dein Oszillogramm könnte auch darauf hindeuten. Mit NP0 hast Du zwar die Temperaturabhängigkeit weg, aber schau mal in das Datenblatt, wie die Spannungsabhängigkeit der Cs ist. Ich habe im Moment hier keine Daten verfügbar, aber für Filter würde ich nur Cs mit spezifizierten Daten aus Datenblatt einsetzen. Hier vermute ich das Problem, die MKT-Blöckchen wären da sicher nicht schlecht, weiß nicht ob's die in SMD gibt.

mfg. Winfried

Winfried Salomonschrieb: "

Ich hab noch ein wenig weiter gespielt und die Stufen so hintereinandergehangen, wie TI das vorschlägt (die letzte Stufe als erstes).

Das Ergebnis ist deutlich besser. Bei 20kHz sinus habe ich nur noch

Etwas später....

Ich habe jetzt versuch den LM324 über ein Netzteil mit 29V zu versorgen. Das Verhalten ist deutlich besser. Die Berge bei 10kHz und

Leider habe ich nur 8V zur Verfügung, so dass ich die Eingangsspannung deutlich reduzieren muss. Der Leistungsverstärker kommt sicherlich mit einer Eingangsspannung von 100mV zurecht.

Noch etwas später...

Habe die Eingangsspannung nun auf 200mV reduziert. Die 8V Betreibsspannung sind nun kein Problem mehr. Mit dem Oszi sind kaum noch Störungen zu messen (auch nicht am Rückkopplungs-Kondensator). Bei 1Vss hatte ich noch Verformungen des Signals nach dem Rückkopplungs-Kondensator. Allerdings komme ich nun in den Bereich, wo sich das Netzbrummen bemerkbar macht.

Nun bin ich noch am überlagen, ob ich vor den Filter einfach so einen Spannungsteiler setzen kann, oder ob das meinen Filter beeinflußt. Aber dazu komme ich erst an Fronleichnam.

mfG Dirk

Winfried Salomon schrieb:

FFTW kann Fouriertransformationen für eine beliebige Anzahl von Abtastwerten berechnen, du bist nicht auf 2**n beschränkt. Macht dir also keine Gedanken um Fensterung und Korrektur der Amplitude, einfach Werte reinschmeissen und gut ist.

Jan

BTDT, und es ist eben nicht gut. Wenn Dein Signal "nicht auf dem gleichen Pegel endet, auf dem es anfängt", das Zero Padding, das die FFTW bei Bedarf macht mitgerechnet, hast Du eben ein Gezappel auf dem Spektrum, das ein durch den Sprung bei der periodischen Fortsetzung hervorgerufenes Artefakt ist.

Gruß Henning

FFTW macht KEIN Zero Padding. Es gibt auch FFT Algorithmen für beliebige Anzahl von Abtastwerten. Es ist am günstigsten, wenn du 2^N Werte hast, aber selbst wenn die Anzahl der Werte eine Primezahl ist lässt sich das ganze noch recht effektiv berechnen. Schau dir das hier mal an:

Und die FFTW Dokumentation sagt dazu:

"FFTW is best at handling sizes of the form

Jan

Ok, da hast Du recht. Trotzdem bleibt das Problem der Unstetigkeit bei der periodischen Fortsetzung.

Gruß Henning

Hallo Dirk,

es geht dabei nur um die Übersteuerung der jetzt letzten Stufe. Die jetzt 2. Stufe ist aber immer noch falsch, dieser "Berg" bei 10 KHz kann eigentlich nicht sein. Ist das noch 1 Sinus? An jeder Stelle kann nur 1 Sinus auftreten, und zwar mit gleicher Frequenz wie am Eingang, alles andere darf nicht sein. Das Ganze sieht mir nach nichtlinearen Verzerrungen aus, vielleicht ist der OP defekt. Schwingen sollte er in _der_ Schaltung eigentlich nicht können, aber ich würde das nochmal nachprüfen. Was passiert denn, wenn man nur dc ".5 V am Eingang hat? Ist dann AC am Ausgang der 2. Stufe zu sehen?

Die Verzerrungen in der 2. Stufe können bei dem Signal nicht sein, das würde ich mal untersuchen, da muß 1 grundlegender Fehler sein, z.B. beide OP-Eingänge vertauscht oder sowas.

Ganz abgesehen davon, daß ich bei keramischen Kondensatoren Dielektrikum NP0 nehmen würde, hast Du sicher einen elementaren Schaltungsfehler übersehen. Selbst wenn die Cs grob falsch sein würden, könnte eine Schaltung 2. Ordnung nicht so leicht instabil werden. In der Simulation läßt sich kein Anhaltspunkt dafür finden, das Spice-Modell des LM324 wird aber auch nicht sehr realitätsnah sein, das ich hier habe.

Nimm Dir doch mal die jetzt 2. Stufe einzeln vor und gib mal eine Rechteckimpulsfolge kleiner Frequenz und Amplitude drauf, das sagt viel mehr aus als 1 Sinus. Was siehst Du auf dem Oszilloskop bei sagen wir mal 100 Hz, 0.1 Vss Rechteck um die 2.5 V an den Schaltflanken?

Vergiß auch nicht, daß ein Taskopf für Scope mind. 10 pF Kapazität hat und wenn Du gar mit Koaxleitung draufgehst, dann lege einen Vorwiderstand >= 50 Ohm in Reihe zum Ausgamg des OP. Allerdings glaube ich bei LM324 nicht ganz an solche Probleme, bei TL074 jedoch würde ich von Schwingen bei Anschluß eines Koaxkabels schon ausgehen.

mfg. Winfried

Hallo Henning,

mir ist das alles bekannt, die FFT ist hier auch weniger das Problem, das von Cooley-Tukey funktioniert ja sehr gut. Ich habe hier auch etliche FFT-Programme bzw. Literatur zu verschiedenen Verfahren. Sicher könnte man einiges optimieren, nur liegt der Flaschenhals bei dem Beispiel hier mit sehr langer FFT eindeutig in der grafischen Auswertung der Ergebnisse, die dauert nämlich mit Matlab 10er-Potenzen länger als die FFT mit meinem Programm.

Das nächste Problem wäre dann der Speicher bei einer FFT > 2**23, dann tritt die im Moment ungeklärte Frage auf, ob z.B. malloc() das bei GNU-Compilern noch schafft, bei 2**28 ist glaube ich physikalisch Schluß, das sind dann 4 GB Ram.

Und noch ein Problem, das File I/O sprengt die 2 GB-Grenze für Fat32 ab einer FFT-Länge von ca 2**24, muß mir das noch ansehen. Ich halte es für sinnvoll, solche kleinen Programme filegesteuert in einer Konsole mit Kommandozeilenparametern aufrufbar zu programmieren, das Betriebssystem ist dabei egal und das aufrufende oder weiterverarbeitende Programm auch. Damit kann man es auf jede Plattform portieren, hoffentlich in 20 Jahren noch, auch wenn man dann für "Hello World" 1 GB Ram Minimum brauchen wird.

Was FFTW betrifft, hab mal kurz die Webseite aufgerufen, aber keinen Quellcode gefunden, nur Bibliotheken zum Dazulinken. Selbst wenn das unschlagbar schnell sein sollte, würde ich mich hier verzetteln, das Programm ist ja längst fertig und muß nur etwas an den User angepaßt werden. Aber dieses "nur" hat es auch in sich.

mfg. Winfried

|> Das nächste Problem wäre dann der Speicher bei einer FFT > 2**23, dann |> tritt die im Moment ungeklärte Frage auf, ob z.B. malloc() das bei |> GNU-Compilern noch schafft, bei 2**28 ist glaube ich physikalisch |> Schluß, das sind dann 4 GB Ram.

Schaff dir ein 64Bit-System an ;-) Da ist dann auch eigentlich nur der Speicher teuer. Allerdings könnte man bei der FFT noch mit Swapping zurechtkommen, wenn man sie in grössere Blöcke zerteilt...

|> Und noch ein Problem, das File I/O sprengt die 2 GB-Grenze für Fat32 ab |> einer FFT-Länge von ca 2**24, muß mir das noch ansehen. Ich halte es für |> sinnvoll, solche kleinen Programme filegesteuert in einer Konsole mit |> Kommandozeilenparametern aufrufbar zu programmieren, das Betriebssystem |> ist dabei egal und das aufrufende oder weiterverarbeitende Programm |> auch. Damit kann man es auf jede Plattform portieren, hoffentlich in 20 |> Jahren noch, auch wenn man dann für "Hello World" 1 GB Ram Minimum |> brauchen wird.

Auch Windows kann mit NTFS mehr 2GB pro File.

|> Was FFTW betrifft, hab mal kurz die Webseite aufgerufen, aber keinen |> Quellcode gefunden, nur Bibliotheken zum Dazulinken. Selbst wenn das

Bei den Windows-Sachen ist der Code selten dabei, kann da eh' kaum einer was damit anfangen :-)

da warte ich besser, bis es Software dafür gibt ;-). Außerdem kann ich mir nicht dauernd neue Rechner kaufen, meiner hier ist recht modern und schnell. Ich sehe natürlich die Strategien um Leute zu zwingen, sich jedes Jahr 'nen neuen Rechner zu kaufen...., aber man muß da nicht unbedingt mitmachen.

Ja stimmt, muß ich wirklich mal ausprobieren.

Hm, hast Du da mal reingeguckt? Statt 1 Unterprogramm wie bei mir sind das 1005 Files, auch mit Quellcode, der nach C oder ähnlichem aussieht. Bei mir paßt die FFT auf 1 Bildschirmseite, aber bei dem da oben packt mich das blanke Entsetzen. Ist das der heutige Stil? Mich wundert bald garnix mehr, deshalb schrieb ich von Verzetteln, dachte mir schon sowas.

mfg. Winfried

|> > Schaff dir ein 64Bit-System an ;-) Da ist dann auch eigentlich nur der Speicher |> > teuer. Allerdings könnte man bei der FFT noch mit Swapping zurechtkommen, wenn |> > man sie in grössere Blöcke zerteilt... |> > |> |> da warte ich besser, bis es Software dafür gibt ;-). Außerdem kann ich |> mir nicht dauernd neue Rechner kaufen, meiner hier ist recht modern und |> schnell. Ich sehe natürlich die Strategien um Leute zu zwingen, sich |> jedes Jahr 'nen neuen Rechner zu kaufen...., aber man muß da nicht |> unbedingt mitmachen.

|> > Bei den Windows-Sachen ist der Code selten dabei, kann da eh' kaum einer was |> > damit anfangen :-) |> |> Hm, hast Du da mal reingeguckt? Statt 1 Unterprogramm wie bei mir sind

Sogar schon mal compiliert ;-) Früher (fftw-2.1, müsste so ~99 gewesen sein) als FFTW noch nicht Standard bei den Linuxdistris war...

|> das 1005 Files, auch mit Quellcode, der nach C oder ähnlichem aussieht. |> Bei mir paßt die FFT auf 1 Bildschirmseite, aber bei dem da oben packt |> mich das blanke Entsetzen. Ist das der heutige Stil? Mich wundert bald |> garnix mehr, deshalb schrieb ich von Verzetteln, dachte mir schon sowas.

FFTW ist nicht "nur" einfach eine FFT (die passt in 20 Zeilen), sondern eine wirklich maximal schnelle FFT für alle möglichen FFT-Arten, Feldgrössen, etc. Die ganzen Buildingblocks (FFT von 1 bis 128) sind in Einzelfiles, grössere oder "krumme" FFTs werden daraus zusammengebaut. Ist auch gut so, das nutzt bei vielen Punkten den Cache viel besser aus als die naive FFT nach Lehrbuch.

Es ist übrigens auch eine Adaption auf das System drin, sodass wirklich immer die schnellste Art benutzt wird. Da ist viel Gehirnschmalz reingeflossen...

D.h. wenn du willst, dass die FFT schnell läuft, nimm FFTW und freu dich, dass es trotz der zig Files geht :-)

Genau, die "Wisdom". Ist aber auch schon sauschnell, wenn man die nicht-optimierte Version nimmt.

Doku liegt hier:

Gruß Henning