LT- Spice - Gnu Octave Vergleich Bodediagramm

[Scott F. (scott_f)]

Hallo zusammen,
ich habe aktuell ein Problem bei der Simulation eines einfachen 
R-(L||C)-Bandpassfilters in GNU Octave und LT Spice.

Die Schaltung besteht aus einem Serienwiderstand R=15 kΩ, gefolgt von 
einem Parallelschwingkreis aus L=100μH und C=1,22 nF. Die 
Ausgangsspannung wird über dem LC-Glied abgegriffen.

Die LT Spice Simulation und das Octave Skript zeigen mir 
unterschiedliche Ergebnisse- könnt ihr mir bitte bei der Fehleranalyse 
des Skriptes helfen.

Hier sind die Zeilen des Skripts:

pkg load control
s = tf('s');
xc = 1/(s*1.22e-9);
xl = s*100e-6;
r = 15e3;
g_n  = ((xl*xc)/(xl+xc));
g_de = r + ((xl*xc) /(xl+xc));
g = g_n / g_de;
bode(g);


Vielen Dank für eure Unterstützung und viele Grüße,
Scott

[Giovanni (sqrt_minus_eins)]

2π

In Welt der Frequenzgänge gibt es f, und es gibt ω. Der Unterschied ist 
ein Faktor von 2π.

[M.A. S. (mse2)]

Giovanni schrieb:
> 2π
>
> In Welt der Frequenzgänge gibt es f, und es gibt ω. Der Unterschied ist
> ein Faktor von 2π.
Genau. Das Octave-Diagramm ist ja sogar entsprechend beschriftet: da 
steht rad/s als Einheit und bei LTSpice Hz.

[Scott F. (scott_f)]

Vielen Dank für eure schnellen Antworten.

Tatsache, ihr habt vollkommen recht, das ist mir nicht aufgefallen !

Könnt ihr euch erklären vorher die Spitze bei ca. -17 dB kommt ?

[H. H. (hhinz)]

Scott F. schrieb:
> Könnt ihr euch erklären vorher die Spitze bei ca. -17 dB kommt ?

Polstelle, ist halt ein Artefakt.

[Giovanni (sqrt_minus_eins)]

Scott F. schrieb:
> Könnt ihr euch erklären vorher die Spitze bei ca. -17 dB kommt ?


Ja. Eine Übertragungsfunktion für R-L//C in der Form:

octave:14> g
Transfer function 'g' from input 'u1' to output ...

                              1.816e-35 s^5 + 1.488e-22 s^3                        
 y1:  -----------------------------------------------------------------------------
      3.323e-40 s^6 + 1.816e-35 s^5 + 5.448e-27 s^4 + 1.488e-22 s^3 + 2.233e-14 s^2

ist schon ein Hammer. Es sind zwar Ferien, aber hier gibt es noch 
Verbesserungspotential. Dann verschwindet auch das Gezappel.

[Stefan R. (stefan_r_bs)]

Scott F. schrieb:

# ------->
pkg load control
s = tf('s');
xc = 1/(s*1.22e-9);
xl = s*100e-6;
r = 15e3;
g_n  = ((xl*xc)/(xl+xc));
g_de = r + ((xl*xc) /(xl+xc));
g = g_n / g_de;
bode(g);
# <------

Oh, wusste nicht, dass Octave das kann. Schön, dazuzulernen... zum 
Ausgleich die gewünschte Hilfe :)

Problem: Es stoppelt einfach alles zu einem numerischen Alptraum 
zusammen, wenn man nicht vereinfacht.

# Zwei Vereinfachungen:
# 1) xl*xc ist eine Konstante:
xlxc=0.0001/1.22e-9;
g2 = (xlxc/(xl+xc))/(r+(xlxc/(xl+xc)));
bode(g2);  # schon besser, aber immer noch Mist.

# 2) Ansatz 
#  U := xlxc / (xl+xc),
#  g := U / (r+U).
# Bruch erweitern mit 1/U liefert
#  g = 1 / (r/U + 1).
#
# In Octave:

g3=1/(r*(xl+xc)/xlxc+1);
bode(g3);  # alles sauber :)

In Variante 3 kommen nur noch Polynome max. 2. Grades vor.

Nachtrag: Aha, ok - es kann auch selbst vereinfachen...

Probe:

minreal(g)
minreal(g2)
minreal(g3)

liefert alles das gleiche. Numerisch wird es sich mit dem "zu Fuß" 
gerechneten wohl nicht viel nehmen.

minreal(g-g3) liefert 0, yeah! :)

[Giovanni (sqrt_minus_eins)]

vor GPT hat man Gleichungen aufgestellt und umgeformt.

clear
pkg load control

C = 1.22e-9;  L = 100e-6; R = 15e3;

# das Original
s = tf('s');
xc = 1/(s*C);
xl = s*L;
g_n  = ((xl*xc)/(xl+xc));
g_de = R + ((xl*xc) /(xl+xc));
g = g_n / g_de;

# der simple, veraltete Ansatz
w0 = 1.0/sqrt(L*C)

gSIMPLE = tf([L/R,0], [L*C,L/R,1.0])

bode(g,gSIMPLE)

mit dem Ergebnis:

Transfer function 'gSIMPLE' from input 'u1' to output ...

               6.667e-09 s          
 y1:  ------------------------------
      1.22e-13 s^2 + 6.667e-09 s + 1
Continuous-time model.

[Lutz V. (lvw)]

Habe ich hier irgendwas wichtiges überlesen, oder woran liegt es, dass 
ich so einigen Ausführungen nicht folgen kann (ich sehe z.B. auch eine 
Gleichung 6.-ten Grades).
Es geht doch eigentlich nur um den einfachsten aller RLC-Bandpässe mit 
der Übertragungsfunktion wie unten angegeben, oder?
Und in diesem Zusammenhang wird sogar ChatGPT bemüht? Das kann ja wohl 
nicht sein...oder erkenne ich die komplizierte Aufgabenstellung gar 
nicht?

H(s)=(sL/R) / [1 + s(L/R) + s²LC]

(Und da wird nach der Ursache einer "Spitze" gefragt?)

[Rainer W. (rawi)]

Scott F. schrieb:
> Könnt ihr euch erklären vorher die Spitze bei ca. -17 dB kommt ?

Da ist die Software mit ihrer Zahlendarstellung am Ende, d.h. die 
Zahlendynamik nahe der Polstelle wird zu hoch. Immerhin rechnest du mit 
Float-Zahlen und die sind bei Differenzen relativ schnell am Ende.