[Rumgucker]

Ich mach mal ne Vorgabe:

[e83cc]

O.k. du bist Gewinner. Bekomme das nicht annähernd so gut hin, egal. Vermutlich ist das ein generelles Problem die digitale Welt ist nun mal in der Genauigkeit begrenzt mit der verwendeten Auflösung. Unter einem gewissen Schwellenwert kommen da keine brauchbaren Ergebnisse raus. Jedenfalls verute ich, das dies der Grund ist. Weißt du es genauer?

[Rumgucker]

Also wir empfehlen hier folgende Einstellungen:

1. Simulate -> Control-Panel -> Compression -> Alle Checkboxen ausschalten

2. Simulate -> Edit Simulation Cmd -> Maximum timestep -> möglichst klein (2ns geht auch - dann gehts schon runter auf -180dB - irgendwo hab ich hier auch schon mal -300dB gesehen, bei kahlo glaub ich)



Mit diesen beiden Einstellungen verbesserst Du die Rohdaten. Sobald die Simul durchgelaufen ist (was natürlich unheimlich viel Speicher und Zeit frisst, weil die FFT ja nicht nur eine Vollwelle braucht wie bei ".four", sondern mindestens so 50 Stück), gehts um die Nachbereitung:


3. Im FFT-Menü die erste und die letzte Millisekunde wegschneiden, falls es Vorteile bringt.

4. Irgendwelche Filter ("Hamm" und Co.) rechnen das Ergebnis im Nachhinein "schön". Die können nichts darstellen, was im Rohmaterial nicht schon drin steckt.

[kahlo]

Zitat:Original geschrieben von Rumgucker
Ich mach mal ne Vorgabe:

Wenn es irgendwo unter -120db rumdümpelt, reicht das doch eigentlich in jedem Fall. Aber gut:

[Rumgucker]

Wahrscheinlich 1ns-Steps und 1000 GHz-PC...

[kahlo]

Die Stepweite war grösser als bei dir .

[alfsch]

ich auch mal versucht....

[voltwide]

Also an den -200dB-peaks bei k3 und k5 musst Du aber noch arbeiten

[Rumgucker]

Alfschs Träger ist zu breitgekloppt. Der hat da bestimmt ein "Hamm" oder sowas eingeschaltet.

[alfsch]

..jo, Hann window.
ein fenster brauchst bei fft in der realität immer, nur wenn fft-länge / daten-länge / frequenz bzw perioden-länge genau (!!) gleich sind, gehts ohne fenster. aber so lang wollt ich damit auch wieder nicht rumblödeln...

[alfsch]

so sieht ne "passend" berechnete fft ohne fenster aus (-> grüüse an kahlo)

1khz 40ms


mit
.tran 0 40000u 0 30.51758n

[kahlo]

Das scheint die Rechengenauigkeit von LTSpice zu sein.

[alfsch]

jo.

200db -> 10 dez. stellen , vmtl double

[Rumgucker]

Seh ich auch so. Spice rechnet mit double float. +/- 1 x 10^10 (+/-200dB) ist pillepalle. Double float kommt über 290 Dekaden weiter!

Hab ich hier nicht mal was mit -300dB gesehen bei gleichzeitigem Plus?

Die FFT kann grundsätzlich sogar genauer sein als jeder einzelne Messwert. Und zwar um die Anzahl der Messpunkte genauer.

Nenene.... von der Rechengenauigkeit her kann man die von uns erreichte Genauigkeit nicht so einfach erklären.

[kahlo]

Die Sinusberechnung scheint diese Genauigkeit zu haben. 200db Dynamik. Wenn die Amplitude verringert wird, sinkt der Störteppich. Hier mal mit 0,1V Amplitude:

Vielleicht ist Pi nicht genau genug implementiert .

[Rumgucker]

Die klassische ".four"-Anweisung kommt auf 1 x 10^-11, also auf -220dB. Somit 20dB bis 40dB besser als unsere Grafiken.

[alfsch]

jaja, und null is auf 500db genau

der entscheidende unterschied ist eben : bei der fft sieht man alles, auch nichtharmonische, bei four NUR genau die paar harmonischen. --> fazit: wer nix sehen will, ausser genau 10 frequenzen, soll four nehmen.
eventuell sieht man die 10 dann auf 11 stellen, statt "nur" auf 10 kommastellen genau.

[Rumgucker]

Warum immer so ironisch?

Ich meinte meinen Test mehr so, dass ich das Gefühl habe, dass wir bei der grafischen Analyse noch besser runterkommen sollten.

[kahlo]

War mein Beispiel nicht deutlich genug? Also deutlicher:

[Rumgucker]

Wir wollen schon bei 0dB beginnen, kahlo.