THDN und SNR mit MATLAB und FPGA berechnen

[Semprini (Gast)]

Ich habe einige Datenströme, die Sinuswellen beschreiben, jedoch 
aufgrund analoger und digitaler Verzerrungen etwas ungenau sind. Die 
Genauigkeit ist aber Gütekriterium und muss beobachtet werden.

Für diese möchte ich gerne den THDN und den SNR berechnen lassen. 
Zunächst geht es darum, mit z.B. MATLAB (?) die Daten zu verarbeiten und 
reale Werte zu bekommen, die ich dann zum Vergleich nutzen kann.

Dann soll weiter das ganze im FPGA implementiert werden, das in realtime 
die Werte für live-Datenströme anzeigt.

Meines Erachtens ist der THD doch aus einer FFT zu ermitteln, in dem man 
die einzelnen Ergebnsisse quadriert und dann addiert und wurzelt.(?) 
Siehe die Formel für due U-Quadrate:
http://de.wikipedia.org/wiki/Total_Harmonic_Distortion


Dann später fürs FPGA:

Da die FFT-Werte ja auch gewurzelt werden müssen, wenn sie aus dem CORE 
kommen (Re2+Im2) fällt da doch schon mal das ersten Wurzeln und 
Weiderquadrieren weg. Man kann also die Summe der Re2+Im2 bilden und 
dann Wurzeln.(?).

Gibt es eine Möglichkeit den Datenstrom zu manipulieren oder 
vorzubereiten, daß erst gar keine Im-Anteile aus dem Core kommen und man 
sich das auch sparen kann?

[Semprini (Gast)]

Hat da keiner etwas dazu zu sagen?

Mir geht es z.B. darum, wie genau die FFt laufen muss, damit ich noch 
verlässliche Werte bekomme. Bei der ganzen Quadriererei und Summiererei 
häufen sich ja die Fehler an.

[Duke Scarring (Gast)]

Semprini schrieb:
> Mir geht es z.B. darum, wie genau die FFt laufen muss, damit ich noch
> verlässliche Werte bekomme. Bei der ganzen Quadriererei und Summiererei
> häufen sich ja die Fehler an.

Um herauszubekommen wie genau die FFT arbeiten muss, macht man doch die 
Matlab-Simulation?! Dort kannst Du einfach mit verschiedenen 
Quantisierungen testen. Außerdem hast Du gleich Referenzdaten für Deinen 
HDL-Code.

Alternativ kannst Du auch eine Fehlerrechnung machen.

Duke

[Semprini (Gast)]

Bliebe die Frage:

Ob es eine Möglichkeit gibt, den Datenstrom in die FFT so zu steuern, 
dass keine imaginären Anteile aus dem Core kommen.

Reicht es, nur real einzuspeisen?

[Detlef _. (detlef_a)]

>>Meines Erachtens ist der THD doch aus einer FFT zu ermitteln, in dem man
>>die einzelnen Ergebnsisse quadriert und dann addiert und wurzelt.

Im Prinzip ist das richtig. Das funzt aber nur, wenn die FFT nicht 
'leckt': Es muß eine ganzzzahlige Wellen in Dein FFT-Fenster passen. Das 
gelingt bei realen Daten nur dann, wenn das gesampelte Signal und der 
Sampler synchron sind, was sie in der Regel nicht sind. THD/SNR 
Berechnung bleibt dann nicht so schlicht, Suchworte sind 'spectrum 
frequency estimation', das is nen weites Feld.

Cheers
Detlef

[Semprini (Gast)]

Ok, ich komme einigermassen hinterher. Im Audiobereich bentuzt man, um 
sich einiger Artefakte zu entledigen, eine Windowfunktion, um die FFT zu 
maskieren.

Wäre das eine Option? Ich beabsichtige ferner, die FFTs zu schachteln, 
als z.B. 8 Stück parallel laufen zu lassen, um die Rate zu erhöhen. Die 
erste arbeitet dann von 0 - 8/8 x FFT-Länge, die zweite von 1/8 - 9/8 
usw und die erste dann wieder auf 9/8 - 16/8, also dem nächsten 
vollständigen Datensatz.

Wenn man diese mittelt, müssten alle Frequenzen gut erfasst sein, oder?

Oder ist es besser, man nutzt unterschiedliche FFT-Längen parallel?

[Detlef _. (detlef_a)]

Semprini schrieb:
> Ok, ich komme einigermassen hinterher. Im Audiobereich bentuzt man, um
> sich einiger Artefakte zu entledigen, eine Windowfunktion, um die FFT zu
> maskieren.

Genau, FFT fenstern (Kaiser 16 oder so) und die FFTs überlappen lassen. 
Aus der Phasendifferenz läßt sich die genaue Frequenz der 
Hauptkomponente bestimmen. Phase und Amplitude:

http://www.dsprelated.com/showmessage/128439/2.php
http://www.claysturner.com/phaseshiftamplitude.pdf

funzt wunderbar.

gute Nacht
Detlef

[Paule (Gast)]

Ich lese mit und versuche zu vertsehen. Jede der überlappenden FFTs 
berechnet dann wohl etwas leicht anderes, was?