LTSpice FFT Problem

[Lars (Gast)]

Hallo,

ich habe eine Frage zur korrekten Verwendung der FFT-Funktion in 
LTSpice. Ich simuliere transient mit einer Simulationszeit von 20 ms und 
einem Maximum time step von 4 ns.

Aus diesem Grund habe ich insgesamt 20 ms / 4 ns= 5000000 echte 
Abtastungen innerhalb der 20 ms Simulationszeit.

Ich verwende bei der FFT immer die Window-Funktion Blackman. Nun ist es 
ja so, dass die "Number of data point samples in time" nie die Zahl der 
echten Abtastungen übersteigen sollte. Aus diesem Grund habe ich die FFT 
einmal mit "Number of data Point samples" gleich 2097152 und einmal mit 
4194304 gemacht, so dass ich in beiden Fällen unterhalb meiner echter 
Abtastungen bin.

Komischerweise erhalte ich in beiden Fällen ein komplett verschiedenes 
Ergebnis (siehe Screenshots im Anhang). Wer kann mir erklären warum das 
so ist?

Zusätzlich habe ich noch einen Test mit Berechnung der FFT im 
spezifizierten Zeitbereich 10 ms bis 20 ms und "Number of data Point 
samples" gleich 2097152 gemacht (Auch hier halte ich das Kriterium ein, 
weil ich innerhalb 10 ms Simulationszeit 2500000 echte Abtastungen 
habe). Hier ist das Ergebnis wieder vergleichbar mit dem von 0 bis 20 ms 
und 2097152.

Viele Grüße

[Lars (Gast)]

Ach ja, vor jemand fragt. Die Datenkompression habe ich mit .options 
plotwinsize=0 ausgeschaltet.

Viele Grüße

[Lars (Gast)]

Auch wenn sich bisher hier keiner zu dem Thema geäußert hat, habe ich 
mir heute noch ein wenig Gedanken dazu gemacht.

Kann es sein, dass es bei der FFT Probleme gibt, wenn die Zahl sampled 
data points in time wesentlich kleiner als die Zahl echter Samples ist 
(z.B. wie in meinem Beispiel echte Samples=5000000 und sampled data 
points in time=2097152)?
Also ich könnte mir vorstellen, dass dadurch Frequenzen im Zeitsignal 
falsch interpretiert werden, weil nicht mehr alle Abtastpunkte 
betrachtet werden. Ist es vielleicht so, dass die Zahl sampled data 
points in time immer größer als die Zahl echter Samples sein sollte?


Im Internet gibt es ein recht gutes Tutorial zu diesem Thema:

http://www.gunthard-kraus.de/LTSwitcherCAD/CD_LTSwitcherCAD/pdf-file/LTspice4_d_2015.pdf

Auf den Seiten 32 bis 39 wird einiges zum Thema FFT in LTSpice erklärt. 
Unter anderem steht dort auf Seite 32 im Kapitel 6.1 c): " Deshalb macht 
es keinen Sinn, viel mehr Samples für die Verarbeitung in einer FFT 
vorzugeben als tatsächlich simuliert wurden".

Mich würde jetzt interessieren wie man die Aussage "viel mehr Samples" 
interpretieren soll. Gibt es hierfür einen genauen Faktor um wie viel 
die Zahl sampled data points in time maximal größer sein darf als die 
Zahl echter Samples?

Auf Seite 34 beginnt in diesem Tutorial ein praktisches Beispiel in dem 
mit 200000 echten Samples simuliert wird. Der Autor erhöht die Zahl 
sampled data points in time dann schrittweise von 131072 auf  262144 und 
dann schließlich noch auf 524288. Das bedeutet, dass am Ende die Zahl 
sampled data points in time um mehr als das Zweieinhalbfache größer ist 
als die Zahl echter Samples. Der Autor spricht anschließend davon: "Wenn 
wir uns noch weiter steigern wollen, dann geht das vernünftig nur noch 
über mehr berechnete Samples. Das bedeutet längere Simulationszeit und / 
oder kleinere Time Steps."

Bedeutet das jetzt im Umkehrschluss dass die Zahl sampled data points in 
time um nicht mehr als das Zweieinhalbfache größer sein darf als die 
Zahl echter Samples?

Viele Grüße und ein gutes neues Jahr

[Klaus R. (klara)]

Hallo Lars,
ich habe neben G. Kraus noch eine andere interessante Quelle zur 
Optimierung einer FFT gefunden:
http://preamp.org/elektronik/klirrfaktor-simulieren-mit-ltspice

Hier ein Thread-Beitrag von mir.
Beitrag "Re: SNR mit Hobbyausstattung messen"

mfg klaus

[Helmut S. (helmuts)]

Das deutlich unterschiedliche Ergebnis mit 10ms bis 20ms deutet darauf 
hin, dass dein Signal Einschwingvorgänge in den ersten 10ms hat.

Probier auch mal auch ohne die Einstellung "Quadratische Interpolation". 
Dazu im FFT Kontrollfenster das Häkchen wegmachen.
"Quadratic interpolate uncompressed data"

Diese Interpolation kann bei extrem idealsierten synthetischen 
Rechteck-Signalen Artefakte ergeben.

[Cem (Gast)]

Lars schrieb:
> Wer kann mir erklären warum das so ist?
Alles unter -40dB ist bei so einer Simulation eher als Rechenartefakt zu 
betrachten. Entscheidend sind die Peaks.

Was erwartest Du von Deiner Simulation?

[Lars (Gast)]

Helmut S. schrieb:
> Das deutlich unterschiedliche Ergebnis mit 10ms bis 20ms deutet darauf
> hin, dass dein Signal Einschwingvorgänge in den ersten 10ms hat.

Gegen dieses Argument spricht, dass ich die gleichen unterschiedlichen 
Ergebnisse auch dann habe, wenn ich immer von 0 ms bis 10 ms mit maximum 
timestep 10 ns simuliere (siehe Screenshots im Anhang). Auch hier habe 
ich lediglich den Wert sampled data points in time von 524288 auf 
1048576 und 2097152 schrittweise erhöht (quadratische Interpolation war 
hier eingeschaltet). Die Zahl echter Abtastungen im Zeitsignal war hier 
10 ms /10 ns=1000000. Das bedeutet den Wert sampled data points in time 
habe ich mal geringer und mal höher als den Wert echter Abtastungen 
gewählt.

Helmut S. schrieb:
> Probier auch mal auch ohne die Einstellung "Quadratische Interpolation".
> Dazu im FFT Kontrollfenster das Häkchen wegmachen.
> "Quadratic interpolate uncompressed data"

Auch das habe ich gerade ausprobiert (siehe Screenshots im Anhang). Es 
scheint in meinem Fall aber keine Änderung im Ergebnis der FFT zu 
bringen, wenn ich die quadratische Interpolation ausschalte.

Cem schrieb:
> Was erwartest Du von Deiner Simulation?

Meine Simulation ist eine EMV-Simulation zur Simulation der Störspannung 
im Frequenzbereich 150 kHz bis 30 MHz. Nur dieser Frequenzbereich ist 
also von Interesse. Die Simulation beinhaltet einen Frequenzumrichter 
(ganz normale B6-Brücke mit MOSFETs) zur Ansteuerung eines Motors. Der 
Eingangsstrom ist Dank einer aktiven PFC nahezu sinusförmig. Außerdem 
habe ich noch ein Eingangsfilter (Gleichtaktdrosseln, Y-Kondensatoren, 
X-Kondensatoren) und die ganze Schaltung ist in der Simulation wie in 
der Realität auch an eine Netznachbildung angeschlossen. In dieser 
Simulation will ich untersuchen wie sich ein Ferrit über dem Motorkabel 
(U/V/W/PE) auf die FFT des Simulationsergebnisses auswirkt. Aus diesem 
Grund simuliere ich das Ausgangssignal der Netznachbildung V(ESR) und 
mache damit eine FFT. Im ersten Simulationsrun (grüner Verlauf) 
simuliere ich ohne Ferrit (Induktivität auf 1 fH) und im zweiten 
Simulationsrun (blauer Verlauf) simuliere ich den Ferrit mit 3.3 µH 
(jeweils eine Induktivität mit 3.3 µH in U/V/W/PE und mit k=0.99 
miteinader magnetisch gekoppelt).

Aus echten EMV-Messungen ist bekannt, dass der Ferrit vor allem oberhalb 
10 MHz eine positive Wirkung hat. Aus diesem Grund erwarte ich in der 
Simulation der FFT eine Reduzierung des Pegels des blauen Signals 
oberhalb von 10 MHz gegenüber dem grünen Signal, so wie es 
beispielsweise im Bild 0ms_10ms_2097152 zu sehen ist. Dieses Ergebnis 
würde ich als korrekt ausgeführte FFT bewerten und beispielsweise das 
Bild 0ms_10ms_1048576 als falsch ausgeführte FFT, weil laut diesem Bild 
der Ferrit eine Verbesserung im gesamten Frequenzbereich 150 kHz bis 30 
MHz bringt, was nicht realistisch ist.

Kurzum: Vorausgesetzt meine Simulation zeigt reales Verhalten 
(parasitäre Bauelemente sind abgeschätzt in der Simulation enthalten), 
wird die FFT in LTSpice nur in bestimmten Fällen korrekt berechnet. Aber 
generell finde ich es seltsam, dass das FFT-Ergebnis derart stark von 
der sampled data points in time abhängt. Deswegen wäre ich sehr erfreut, 
wenn mir jemand hierfür eine Art Kochrezept für verlässliche 
FFT-Ergebnisse in LTSpice geben würde.

Viele Grüße

[Lars (Gast)]

Cem schrieb:
> Alles unter -40dB ist bei so einer Simulation eher als Rechenartefakt zu
> betrachten. Entscheidend sind die Peaks.

Genau das ist bei meiner Simulation hier nicht der Fall. Die Peaks sind 
die Grundfrequenzen der aktiven PFC und des Umrichters und liegen 
außerhalb des betrachteten Frequenzbereichs 150 kHz bis 30 MHz. Auch 
wenn die Pegel hier mit beispielsweise -80 dB recht klein ausschauen ist 
es wichtig zu wissen, dass ich in den Screenshots die Verläufe in dBV 
angezeigt habe. Mich interessieren aber Pegel in dBµV (erreicht man in 
dem man im Plotfenster V(ESR)/1u schreibt). Wenn man diese Umrechnung in 
LTSpice durhführt erhält man Pegel im Bereich 30 dBµV bis 50 dBµV im 
Frequenzbereich 150 kHz bis 30 MHz. Und diese Pegel befinden sich grob 
in der Größenordnung, die für die Grenzen einer Störspannungsmessung 
nach Norm gelten.

Viele Grüße

[Klaus R. (klara)]

Hallo Lars,
wie sauber ist denn Dein Quellsignal? In dem verlinken Artikel fing der 
Autor an, indem er den Noise Floor der Spannungsquelle per FFT-Analyse 
aufzeigte. Die ideale Quelle war gar nicht so ideal. Danach wurde 
schrittweise optimiert.

http://preamp.org/elektronik/klirrfaktor-simulieren-mit-ltspice
mfg klaus

[Helmut S. (helmuts)]

> wird die FFT in LTSpice nur in bestimmten Fällen korrekt berechnet.

Zur Berechnung der FFT muss LTspice (wie auch jedes andere SPICE) aus 
den nicht äquidistanten simulierten Werten neue Werte, die in einem 
konstanten Abstand sind, berechnen(interpolieren). Je mehr Punkte man 
bei der FFT wählt, um so mehr Punkte werden interpoliert. Diese 
Interpolation ist keine sinc-Funktion die auf der Basis eines 
bandbegrenzeten Signales beruht. Dadurch ist diese Interpolation ein 
nichtlinearer Prozess der zwangsläufug zu ursprünglich  nicht 
vorhandenen Signalanteilen führt. Auch Matlab würde hier kein anderes 
Ergebnis bringen, wenn man mit den gleichen Methoden die benötigten 
Werte interpoliert.

Wenn man auch bei höchsten Frequenzen eine hohe Genauigkeut haben will, 
dann müsste man den maximalen Zeitschritt in deiner Anwendung vermutlich 
auf 1ns oder weniger reduzieren. Eventuell sind auch noch andere 
Einstellungen wie trtol=0.1 hilfreich.

[Lars (Gast)]

Klaus R. schrieb:
> Hallo Lars,
> wie sauber ist denn Dein Quellsignal?

Mein Quellsignal ist ein reiner Sinus mit Amplitude von 325 V und 
Frequenz 50 Hz. Aber ich messe wie gesagt dass Ausgangssignal der 
Netznachbildung V(ESR) und dessen Entstehung hängt weniger vom 
Quellsignal als von verschiedenen kapazitiven Umladeströmen 
(hervorgerufen durch steile Schaltflanken) des Umrichters ab.

Helmut S. schrieb:
> Wenn man auch bei höchsten Frequenzen eine hohe Genauigkeut haben will,
> dann müsste man den maximalen Zeitschritt in deiner Anwendung vermutlich
> auf 1ns oder weniger reduzieren. Eventuell sind auch noch andere
> Einstellungen wie trtol=0.1 hilfreich.

Basierend auf diesen Vorschlag habe ich jetzt noch einmal mit den 
folgenden Einstellungen simuliert :

.tran 0 10m 0 1n
.options gmin=1e-10 abstol=1e-10 reltol=0.003 trtol=0.1
.options plotwinsize=0

Im Vergleich zur vorherigen Simulation habe ich den maximum timestep auf 
1 ns geändert und sonst noch trtol=0.1 hinzu gefügt. Die quadratische 
Interpolation habe ich jetzt wieder eingeschaltet.

Die Ergebnisse mit verschiedenen Number of data point samples in time 
findet Ihr im Anhang.

Wie Ihr sehen könnt, schauen die Ergebnisse jetzt noch seltsamer aus und 
haben überhaupt nichts mehr mit den vorherigen Ergebnissen zu tun. Das 
kann allerdings jetzt auch daran liegen, dass ich erstmals jetzt mit 
trtol=0.1 simuliert habe. Vorher hatte ich immer trtol=1.

Da die Simulation gerade 2 Stunden lang benötigt hat, will ich sie jetzt 
aber nicht noch einmal mit trtol=1 laufen lassen sondern stattdessen die 
Simulationszeit verkürzen.

Deswegen habe ich jetzt nochmal eine andere Simulation gemacht. Dieses 
Mal habe ich 2.5 ms lang mit einem maximum timestep von ebenfalls 1 ns 
und wieder mit trtol=0.1 simuliert. Dabei habe ich folgende 
Einstellungen verwendet:

.tran 0 2.5m 0 1n
.options gmin=1e-10 abstol=1e-10 reltol=0.003 trtol=0.1
.options plotwinsize=0

Die Ergebnisse findet Ihr wieder im Anhang. Das Ergebnis schaut ähnlich 
seltsam aus wie bei der Simulation vorher (0ms bis 10 ms, maximum 
timestep 10n, trtol=0.1).

Da ich die Vermutung hatte, dass die stark abweichenden Ergebnisse zu 
denen von den Tagen vorher (siehe letzte Posts) mit der Einstellung 
trtol=0.1 zusammenhängen, habe ich die Simulation über 2.5 ms und 
maximum timestep=1 ns noch einmal aber dieses Mal mit trtol=1 
(default-Wert) ausgeführt und dabei mit folgenden Einstellungen 
simuliert:

.tran 0 2.5m 0 1n
.options gmin=1e-10 abstol=1e-10 reltol=0.003
.options plotwinsize=0

Die Ergebnisse findet Ihr wieder im Anhang. Die Vermutung hat sich 
bestätigt. Mit trtol=1 (default-Wert) sind die Ergebnisse wieder so 
ähnlich wie die Tage vorher.

Alles in allem ist es für mich momentan sehr schwierig zu sagen welches 
FFT-Ergebnis nun richtig ist, da die Ergebnisse abhängig von den 
Einstellungen sehr stark variieren.

Allgemein würde mich interessieren ob jemand von Euch schon mal ähnliche 
Erfahrungen gemacht hat, dass bei der FFT in LTSpice die Ergebnisse 
derart von den FFT-Einstellungen abhängen.

Viele Grüße

[Helmut S. (helmuts)]

LTspice berechnet die FFT aus den Werten des .raw Files. Du könntest 
diesen File nehmen und daraus einen Text-File für ein externes 
Programm(Matlab, Octave,Scilab) machen. Damit könntest du dann extern 
die Interpolation, Filterung und FFT machen um die Ergebnisse zu 
vergleichen. Falls du mit LTspiceIV simuliert hast, könntest du das 
Programm ltsputil.exe für die Konvertierung von .raw nach .txt nehmen.
Alternativ einfach File->Export im Programm LTspice machen. Damit erhält 
man auch einen Text-file als Ausgabe.

[Lars (Gast)]

Helmut S. schrieb:
> LTspice berechnet die FFT aus den Werten des .raw Files. Du könntest
> diesen File nehmen und daraus einen Text-File für ein externes
> Programm(Matlab, Octave,Scilab) machen. Damit könntest du dann extern
> die Interpolation, Filterung und FFT machen um die Ergebnisse zu
> vergleichen. Falls du mit LTspiceIV simuliert hast, könntest du das
> Programm ltsputil.exe für die Konvertierung von .raw nach .txt nehmen.
> Alternativ einfach File->Export im Programm LTspice machen. Damit erhält
> man auch einen Text-file als Ausgabe.

Vielen Dank schon mal für diesen guten Hinweis. Ich habe jetzt mal von 
zwei Simulationsdurchläufen (0ms bis 2.5ms, maximum timestep=1ns, 
trtol=1 bzw. trtol=0.1) die simulierten Zeitverläufe in txt-Files 
gepackt und für jeden Run ein eigenes txt-File gemacht und die txt-Files 
so modifiziert, dass sie nur noch die Zahlenwerte enthalten.

Ich habe mir für die Berechnung der FFT Scilab heruntergeladen. Leider 
habe ich mit dem Programm noch nie gearbeitet. Nichtsdestotrotz habe ich 
ein wenig nach den einzelnen Funktionen gegoogelt und probiert die FFT 
zu machen.

So würde mein Code für das Einlesen der txt-Files für trtol=1 aussehen:

path = 'D:\...';

-->measured1 = 'run1_0ms_2_5ms_1ns_trtol_1.txt';

-->measured2 = 'run2_0ms_2_5ms_1ns_trtol_1.txt';

-->// input to B

-->chdir(path);

-->B = fscanfMat(measured1, '%lg');

-->A = fscanfMat(measured2, '%lg');

Weiter zur eigentlichen FFT und grafischen Ausgabe bin ich leider noch 
nicht gekommen, weil bereits dieser Code zu einer Fehlermeldung 
(Stapelgröße überschritten!) führt. Hierzu wäre ich um Unterstützung 
sehr dankbar, auch was die Umsetzung und grafische Ausgabe der FFT 
angeht. Ich arbeite ja wie gesagt zum ersten Mal mit Scilab. Aber 
vielleicht hat dafür ja jemand von euch, der so etwas schon einmal 
gemacht hat, einen Code als Vorlage für mich der vom Einlesen der 
txt-Files bis zur Berechnung der FFT und grafischen Ausgabe alles 
enthält.

Ich hätte die txt-Files gerne im Anhang mit angehängt. Aber leider die 
Files echt riesig, so dass das nicht möglich ist.

Viele Grüße

[Helmut S. (helmuts)]

Hallo Lars,

Falls du LTspiceIV hast, kannst du das Programm ltsputil.exe nehmen um 
die Daten aus dem .raw-file zu extrahieren. Damit erhält man eine 
Textdatei die man in jedes Matheprogramm einlesen kann. Das erwähnte 
Programm ltsputil.exe ist im Anhang. Es muss in einem cmd-window 
ausgeführt werden. Ich kopiere immer die exe in das Verzeichnis des 
raw-files, damit ich keine Pfadnamen eintippen muss.

In Matlab gibt es dann eine Funktion zum Interpolieren auf konstante 
Abstände.
yi = interp1(x,Y,xi)
Ähnliches gibt es sicher auch in anderen Mathe-Programmen.

Gruß
Helmut

[Lars (Gast)]

Helmut S. schrieb:
> Falls du LTspiceIV hast, kannst du das Programm ltsputil.exe nehmen um
> die Daten aus dem .raw-file zu extrahieren.

Ich benutze die neuste Version also LTspiceXVII aber trotzdem vielen 
Dank für den Hinweis.

Helmut S. schrieb:
> Damit erhält man eine
> Textdatei die man in jedes Matheprogramm einlesen kann.

Eine Textdatei aus den LT-Spice Ergebnissen zu erzeugen habe ich, wie 
bereits erwähnt, schon geschafft.

Helmut S. schrieb:
> In Matlab gibt es dann eine Funktion zum Interpolieren auf konstante
> Abstände.

Ich besitze leider kein Matlab und hab deswegen gehofft das Ganze mit 
Scilab zu machen.

Da ich absoluter Scilab-Neuling bin und momentan nicht die Zeit dazu 
habe mich tief in das Programm einzuarbeiten sehe ich leider gerade eher 
weniger Möglichkeiten eine FFT mit aussagekräftigen Ergebnissen mit 
Scilab durchzuführen. Aus diesem Grund hab ich ja gehofft, dass mir 
jemand hier vielleicht eine Code-Vorlage für dieses Vorhaben 
bereitstellt.

Viele Grüße

[Helmut S. (helmuts)]

Hallo Lars,

hie rmal der Scilab code.

Der Daten file muss so wie unten aussehen. Dazu musste ich dei Tabs \t 
mit , ersetzen. Das kann z. B. Notepad++.

0.000000000000000e+000,0.000000e+000
9.999999824516700e-015,1.000000e-005
1.999999964903340e-014,2.000000e-005
3.999999929806680e-014,4.000000e-005
7.999999859613360e-014,8.000000e-005



Scilab commands
// sind auskommentierte Zeilen.
Diese Plotzeile enthält min/max der Achsen. Das musst du noch anpassen 
in rect[].

plot2d("nl",frequency,spectrum,style=2,rect=[0,1e-7,5e9,1]); // linx, 
logy, xmin,ymin,xmax,ymax

// Textfile-Format
// xi,yi

// Example: Simulation t=0..100e-6 -> TMAX=100e-6
N = 1048576 // samples for the FFT
TMAX = 100e-6;
FMIN = 1/TMAX;

stacksize('max');

a=csvRead("test1.txt");

time=a(:,1);

signal=a(:,2);

x=linspace(0, TMAX*(N-1)/N, N);

y=interp1(time,signal,x);

win1=window('kr',N,8); // Kaiser window

yw= y.*win1;

spectrum2=abs(fft(yw))/N; // Apply window
// spectrum2=abs(fft(y))/N; // No window

spectrum=2/sqrt(2)*spectrum2(1:(N/2)); // RMS value

spectrum(1)=spectrum2(1); // DC value

frequency=linspace(0, FMIN*(N/2-1), N/2);

plot2d("nl",frequency,spectrum,style=2,rect=[0,1e-7,5e9,1]); // linx, 
logy, xmin,ymin,xmax,ymax

//set(gca(),"grid",[1 1]); // grid on

//set(gca(),"grid",[-1 -1]); // grid off

//plot2d(     frequency,spectrum,style=2) // lin x, lin y
//plot2d("nl",frequency,spectrum,style=2) // lin x, log y
//plot2d("ll",frequency,spectrum,style=2) // log x, log y
//plot2d("ln",frequency,spectrum,style=2) // log x, lin y

[Lars (Gast)]

Vielen Dank, Helmut für den bereitgestellten Scilab-Code.

Helmut S. schrieb:
> Der Daten file muss so wie unten aussehen. Dazu musste ich dei Tabs \t
> mit , ersetzen. Das kann z. B. Notepad++.

Das habe ich jetzt mal bei allen txt-Files gemacht.


Deinen Code habe ich zuerst mit dem ersten Run (grüner Verlauf in 
LTSpice) getestet. Die Zahl N habe ich für jeden Test angepasst. 
Getestet habe ich mit N=524288, 1048576, 2097152 und 4194304. Außerdem 
habe ich noch die Grenzen im Diagramm auf rect=[0,1e-7,100e6,1] 
angepasst:

N = 524288 // samples for the FFT
TMAX = 2.5e-3;
FMIN = 1/TMAX;

stacksize('max');

a=csvRead("run1_0ms_2_5ms_1ns_trtol_1.txt");

time=a(:,1);

signal=a(:,2);

x=linspace(0, TMAX*(N-1)/N, N);

y=interp1(time,signal,x);

win1=window('kr',N,8); // Kaiser window

yw= y.*win1;

spectrum2=abs(fft(yw))/N; // Apply window
// spectrum2=abs(fft(y))/N; // No window

spectrum=2/sqrt(2)*spectrum2(1:(N/2)); // RMS value

spectrum(1)=spectrum2(1); // DC value

frequency=linspace(0, FMIN*(N/2-1), N/2);

plot2d("nl",frequency,spectrum,style=2,rect=[0,1e-7,100e6,1]); // linx, 
logy, xmin,ymin,xmax,ymax

Anschließend habe ich analog dazu das Gleiche mit dem txt-File vom 
zweiten Run (blauer Verlauf in LTSpice) gemacht.

Ich hab von den Plots der verschiedenen Tests Bilder im Anhang 
beigefügt.

So auf den ersten Blick würde ich sagen, dass die Ergebnisse denen von 
LTSpice sehr ähnlich sehen. Wobei natürlich die Frage, welches 
FFT-Ergebnis nun das Richtige ist, weiterhin nicht geklärt ist.

Kann man den Code eigentlich mit wenig Aufwand so erweitern, dass zwei 
Verläufe im selben Plot erscheinen (so wie in LTSpice)? Dann könnte man 
die Ergebnisse noch besser mit denen von LTSpice vergleichen.

Kann man die Berechnung auch mit größeren N als die Anzahl Zeilen im 
txt-File machen, so dass zusätzliche Werte interpoliert werden? Also im 
Prinzip meine ich das so wie es in LTSpice möglich ist. Also gehen tut 
es prinzipiell (hab gerade mal mit N=4194304 getestet). Die Frage ist 
nur ob Scilab dann auch wirklich interpoliert.

Viele Grüße

[Helmut S. (helmuts)]

> Kann man die Berechnung auch mit größeren N als die Anzahl Zeilen im
txt-File machen, so dass zusätzliche Werte interpoliert werden?

Ja.

>Kann man den Code eigentlich mit wenig Aufwand so erweitern, dass zwei
Verläufe im selben Plot erscheinen

Das geht bestimmt. Ich schau mal ob ich ein Beispiel im Internet finde.

Den ganzen Scilab-Code den ich da geschrieben habe habe ich mit Hilfe 
der  Helpseiten von Scilab, Code-Schnipseln aus dem Internet und 
kombinatorischem Denken erstellt. Ich habe da echt nichts fertiges 
gefunden das genau diese Aufgabe erledigt obwohl man annehmen müsste, 
dass das eine Standardaufgabe ist. Schach fand ich ja, dass man bei 
Scilab erstmal den stacksize erhöhen muss nur um Dateien mit 
100000(200000 Zahlen) Zeilen einzulesen. Da könnte sie bei 64bit 
Systemen standardmäßig großzügiger Platz reservieren da kaum noch einer 
einen Rechner mit weniger als 4GB RAM hat.

[Lars (Gast)]

Das mit den Plots der beiden Runs in einem Fenster habe ich mittlerweile 
selber hinbekommen. Hierfür habe ich den Code von Helmut folgendermaßen 
erweitert:

N = 524288 // samples for the FFT
TMAX = 2.5e-3;
FMIN = 1/TMAX;

stacksize('max');

a=csvRead("run1_0ms_2_5ms_1ns_trtol_1.txt");
b=csvRead("run2_0ms_2_5ms_1ns_trtol_1.txt");

time=a(:,1);
time_b=b(:,1);

signal=a(:,2);
signal_b=b(:,2);

x=linspace(0, TMAX*(N-1)/N, N);

y=interp1(time,signal,x);
y_b=interp1(time_b,signal_b,x);

win1=window('kr',N,8); // Kaiser window

yw= y.*win1;
yw_b= y_b.*win1;

spectrum2=abs(fft(yw))/N; // Apply window
spectrum2_b=abs(fft(yw_b))/N; // Apply window
// spectrum2=abs(fft(y))/N; // No window

spectrum=2/sqrt(2)*spectrum2(1:(N/2)); // RMS value
spectrum_b=2/sqrt(2)*spectrum2_b(1:(N/2)); // RMS value

spectrum(1)=spectrum2(1); // DC value
spectrum_b(1)=spectrum2_b(1); // DC value

frequency=linspace(0, FMIN*(N/2-1), N/2);

plot2d("nl",frequency,spectrum,style=2,rect=[0,1e-7,100e6,1]); // linx,
plot2d("nl",frequency,spectrum_b,style=2,rect=[0,1e-7,100e6,1]); // linx, 
logy, xmin,ymin,xmax,ymax

Ich hab die Plots im Anhang angehängt.

Viele Grüße

[Helmut S. (helmuts)]

Nachtrag

> plot2d("nl",frequency,spectrum,style=2,rect=[0,1e-7,100e6,1]); // linx,
logy, xmin,ymin,xmax,ymax

In LTspice hast du doppelt logarithmische Darstellung gewählt. Das wäre 
dann die Option "ll" statt "nl".

plot2d("ll",frequency,spectrum,style=2,rect=[0,1e-7,100e6,1]); // linx,
logy, xmin,ymin,xmax,ymax

[Lars (Gast)]

Wenn man die Plots meines letzten Posts mit denen von LTSpice vergleicht 
sieht man eine gute Übereinstimmung.

Nichtsdestotrotz stellt sich für mich die Frage mit welcher Zahl number 
of data point samples in time man das beste (realistischste) 
FFT-Ergebnis erhält, da sich die einzelnen Ergebnisse doch recht stark 
voneinander unterscheiden.

Viele Grüße

[Helmut S. (helmuts)]

Wenn man zweimal mit unterschiedlichem style(=Farbe) plottet, dann sind 
beide Kurven übereinander. Leider sind die nicht transparent sondern die 
größere überdeckt die kleinere. Man sieht das, wenn man an Stellen die 
unterschiedlich sind hinein-"zoomed".
Hier hilft wohl nur ein Export von Scilab nach Gnuplot.
http://gnuplot.sourceforge.net/demo/transparent.html

Die Stichorte für Google sind: transparent transparency opacity