LT- Spice - Gnu Octave Vergleich Bodediagramm

2π

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

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.

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 ?

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:

1

octave:14> g

2

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

3

4

                              1.816e-35 s^5 + 1.488e-22 s^3                        

5

 y1:  -----------------------------------------------------------------------------

6

      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.

Scott F. schrieb:

1

# ------->

2

pkg load control

3

s = tf('s');

4

xc = 1/(s*1.22e-9);

5

xl = s*100e-6;

6

r = 15e3;

7

g_n  = ((xl*xc)/(xl+xc));

8

g_de = r + ((xl*xc) /(xl+xc));

9

g = g_n / g_de;

10

bode(g);

11

# <------

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.

1

# Zwei Vereinfachungen:

2

# 1) xl*xc ist eine Konstante:

3

xlxc=0.0001/1.22e-9;

4

g2 = (xlxc/(xl+xc))/(r+(xlxc/(xl+xc)));

5

bode(g2);  # schon besser, aber immer noch Mist.

6

7

# 2) Ansatz 

8

#  U := xlxc / (xl+xc),

9

#  g := U / (r+U).

10

# Bruch erweitern mit 1/U liefert

11

#  g = 1 / (r/U + 1).

12

#

13

# In Octave:

14

15

g3=1/(r*(xl+xc)/xlxc+1);

16

bode(g3);  # alles sauber :)

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

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

Probe:

1

minreal(g)

2

minreal(g2)

3

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! :)

vor GPT hat man Gleichungen aufgestellt und umgeformt.

1

clear

2

pkg load control

3

4

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

5

6

# das Original

7

s = tf('s');

8

xc = 1/(s*C);

9

xl = s*L;

10

g_n  = ((xl*xc)/(xl+xc));

11

g_de = R + ((xl*xc) /(xl+xc));

12

g = g_n / g_de;

13

14

# der simple, veraltete Ansatz

15

w0 = 1.0/sqrt(L*C)

16

17

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

18

19

bode(g,gSIMPLE)

mit dem Ergebnis:

1

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

2

3

               6.667e-09 s          

4

 y1:  ------------------------------

5

      1.22e-13 s^2 + 6.667e-09 s + 1

6

Continuous-time model.

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?)

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.