[Rumgucker]

Falls mich Spice jemals wieder zum Schaltungs-Simulieren kommen lassen sollte, werde ich mir Deinen Level-Shifter mal genauer ansehen.

P.S.: Du hast bei Deinen Dateien die Endung vergessen (in Deinem Fall also .PDF)! Das könnte das Problem erklären.

[alfsch]

@Rumgucker: wenn du willst , erkläre ich dir, was so ein fenster tut ( tun sollte); was ist dein wissensstand bzgl fft ?
(damit ich nicht bei adam anfange...)
+ das seltsame spektrum: wenn du im pulse 0 als rise/fall nimmst, hast du ein unendliches spektrum, dass das störungen gibt, ist klar. (systemtheorie...hatte ich nie gern.)

[Ampericher]

https://stromrichter.org/d-amp/content/i..._NTE54.pdf

Danke für den Tip, jetzt funkt es.

[Rumgucker]

Zitat:Original geschrieben von alfsch

@Rumgucker: wenn du willst , erkläre ich dir, was so ein fenster tut ( tun sollte); was ist dein wissensstand bzgl fft ?
(damit ich nicht bei adam anfange...)
+ das seltsame spektrum: wenn du im pulse 0 als rise/fall nimmst, hast du ein unendliches spektrum, dass das störungen gibt, ist klar. (systemtheorie...hatte ich nie gern.)

Wow... ein FFT-Spezialist! So einen brauche wir hier dringend. Daß pulse-rise und fall != 0 ist klar. So stehts auch hier in einem der "Artikel" (guckste links). Den Bug kenn ich schon seit 14 Jahren.

Aber von "FFT" hab ich nur in soweit Ahnung, daß ich sie programmieren kann. Ob ich sie wirklich komplett verstanden hab, bezweifel ich!

Insofern bitte ich Dich, mal alles von Adam an hinzuschreiben, am besten gleich als "Artikel"! Dann hilft es allen.

Thx!!!

[Rumgucker]

Ich halte folgendes Schaltbild:



...für einen idealen PWM-Verstärker. Alle Parameter lassen sich frei verstellen, auch die Phasenverschiebung (wird kompensiert durch delay der Quellen), die MOS-Bahnwiderstände, LC-Filter, Betriebsspannung.

Spice tut sich mit der Schaltung nicht schwer. Auch SODFAs wären nach diesem Prinzip leicht zu idealisieren.

Man könnte nun das Ausgangssignal dieses idealen Verstärker mit einem realen Verstärker vergleichen um zu zuverlässigeren Aussagen zu kommen.

---

Warum bin ich immer noch nicht von der FFT überzeugt?

Selbst -180dB an idealer Sinusquelle reichen mir nicht aus!!!! -180dB entsprechen gerade mal einer 32Bit-Integer-Rechnung. Wir haben aber ein FPU in unseren Pentiums, was vielfach genauer rechnen kann.

Man muß sich ja auch vorstellen, daß diese 180dB bei der Hintereinanderschaltung vielleicht ohne weiteres nur noch -174dB erbringen usw.... Vieles deutet ja darauf hin, daß nicht die FFT schlecht ist, sondern nur die der FFT eingespeisten Signale.

Insofern steh ich weiterhin auf ner relativen Brückenmessung! Mein o.a. Verstärker hat per Definition keine Fehler. Alles was davon abweicht, muß fehlerbehaftet sein.

Hmmmmm....

... oder so ähnlich...

[Rumgucker]

...uns allen einen Artikel angefertigt!

Danke, alfsch.

Den zieh ich mir nun mal genüßlich rein...

[Rumgucker]

Ich nahm bisher an, daß die FFT mit dem ersten Sprung-Wert zu kämpfen hat.

Du sagst, daß die FFT mit jedem Sprung zu kämpfen hat. Und Sprünge entstehen durch die feste 1024...-Rechenweite.

Was können wir tun, um der FFT besser geglättete Daten anzubieten?

Also nicht am Output mit irgendwelchen Filtern rummogeln, sondern gleich den Eingang in optimaler Form aufbereiten?

Können wir irgendwie mit eigener Software in die Daten eingreifen?

[Rumgucker]

So .. ich hab diesen ganzen Spice-Kram mal von den "SODFA-Alternativen" hierher verschoben.

[alfsch]

ahem, die 1024 waren nur als beispiel, für 2exp(n), also 2e(10), das prinzip dahinter ist aber immer gleich; dh bei 16k oder 32k ffts wird der mittlere rauschpegel (durch rundung usw) besser, aber störungen an den fenstergrenzen bleiben halt...und erzeugen dann den "teppich" unten.
zur verbesserung: weis net, ob wir an die spice daten kommen, bevor die zur fft gehen, denke eher nicht; i.ü. scheinen da schon ein paar fehlerchen drin, habe selbst schon genug fft-fenster programmiert (und auch ein eigenes entwickelt...), bei sw-cad scheint mir bei den meisten irgendein müll mit in die fft zu kommen, nur hann geht so lala, vielleicht stellen wir auch irgendwas falsch ein..?

[Rumgucker]

Daß das mit 1024 nur ein beispiel war, war mir klar. Deswegen hatte ich ja "..." hinter die 1024 gemacht.

Die Feinheiten bei der Einstellung, die ich rausgefunden hab, stehen unter "Artikel".

An die reinen Simulationsdaten kommt man schon ran. Irgendeine (sehr lange) raw-Datei oder so ähnlich. Leider ist die binär. Finden wir im I-Net eine Formatbeschreibung darüber?

Ich könnte mir folgendes Programm vorstellen:

wir simulieren nur einen einzigen Zyklus, den allerdings recht genau. Unser Zusatzprogramm dupliziert diesen einen Zyklus. Und während es dupliziert glättet es auch die Meßwerte.

Diese neue "raw" (?)-Datei geben wir dann dem FFT zum Fressen.

Zur Realisierung eines Programms ergeben sich zwei Möglichkeiten:

Entweder wir machen ne Exe-Datei. Dabei steh ich allerdings in der Verantwortung, Eure ganzen verschiedenen Windows-Systeme zu unterstützen. Da wir nur mit file-io zu tun haben, wäre das aber machbar.

Eleganter wäre es aber, wenn wir das Programm auf dem Server installieren und Ihr Eure zu bearbeitenden Dateien hoch/runterladen würdet. Dagegen spricht aber, daß die Datenmengen imens werden können.

Also werde ich Euch wohl ein Windows-EXE-Programm basteln müssen.

Gibts Alternativen?

[alfsch]

hmmm, vielleicht sollten wir bei lt mal anfragen, wie man das richtig einstellt, da die fenster nicht den richtigen effekt bringen...entweder wir machen ja was falsch oder die merken dann was...

[Rumgucker]

.. an der Spice-Entwicklung nicht überbewerten! Wie mans "richtig" einstellt, schreiben die in #23, hier in diesem Thread. Die haben also auch keine Ahnung.

LT will nur die "LT"-Bauteile verkaufen. Logischerweise wollen die wenig investieren, deswegen hat wohl auch nur ein einziger Mann die Verheiratung von SwitcherCad und Spice durchgeführt.

Ich bin überzeugt davon, daß wir hier wesentlich mehr Manpower als LT zur Verfügung haben!

Und stellt Euch mal vor: wir simulieren nur noch einen einzigen Zyklus - das geht "ratz fatz". Die ganze Duplizierung auf 10.000 oder mehr Zyklen überlassen wir dann dem "Duplikator". In Windeseile erstellen wir -500dB-FFT's.

Also los jetzt! Wir brauchen zuerst das Datenformat der raw-Dateien.

[alfsch]

also nee, duplizieren muss man gar nix, wenn fenster und input ok sind, bleibt das ergebnis ohnehin gleich. bei 10ns schritt und 2ms fenster = 200k sampels, wäre aber ne 2e18 analyse nötig...etwas übertrieben, denke ich. hier liegt vermutlich auch eins der probleme: bei zb 16k analyse auf 2ms liegt die schrittweite bei 120ns, es muss also vor analyse und fensterung downsampling erfolgen...auch ne heikle sache( fir filter oder evtl spline ???) konnte ich bislang nicht rausfinden. aber habe auch so mit hann-window recht brauchbare ergebnisse; was unter -120dB liegt, is doch egal, in der realität muss das erst mal erreicht werden (die meisten guten cd aufnahmen eiern so bei -85 bis -105dB rauschabstand rum, also wenn ein amp besser als das ist....)

[Rumgucker]

...raw-Format befaßt. Es gibt tierisch wenig darüber, obgleich es schon immer das Standard-Format von Spice war.

Schaden kann es keinesfalls, wenn wir unser Arbeitswerkzeug möglichst gut und intim kennenlernen.

Ich VERMUTE, daß in der raw-Datei zu jedem Zeitpunkt alle Knoten-Spannungen und alle Terminal-Ströme abgespeichert werden. Ich weiß (aus den vorigen Tests), daß man pro Verdopplung der Datenmenge 5dB mehr SR-Abstand erhält! Insofern habe ich die Hoffnung, daß uns eine simple Duplizierung bei gleichzeitiger Glättung der Daten wesentliche Vorteile bringt.

Ich hab mir heute den ganzen Tag dafür reserviert.

Wollen mal sehen, ob was Verwertbares dabei rauskommt.

[Rumgucker]

In den raw-Dateien wird am Anfang allerlei rumgeplappert. Wichtig ist die "Anzahl der Points" und der timeoffset (auf den sich alle Zeiten beziehen). Weiterhin befindet sich im Kopf eine Tabelle der Variablen in der gleichen Reihenfolge, wie später die Werte abgespeichert sind.

1. time
2. V(n001)
3. I(Quelle)
4. I(Senke)

Das wars! Nach diesem Header werden stur "Anzahl der Points" * "vier Variablen" * "5 Byte (FP)" abgespeichrt

Byte 0-4: FP-Wert des ersten time-Points
Byte 5-9: FP-Wert V(n001) zu diesem Zeitpunkt
Byte 10-14: FP-Wert I(Quelle) zu diesem Zeitpunkt
Byte 15-19: FP-Wert I(Senke) zu diesem Zeitpunkt

und dann kommen die nächsten 20 Byte des nächsten Zeit-Points. Und das so lange, bis alle "Anzahl der Points" abgearbeitet sind.

---

Aller Voraussicht nach werde ich hier in den nächsten Stunden einen simplen Windows-Post-Prozessor für raw-Dateien zum Download bereitstellen können!

Was haltet Ihr von "RAW_WORK.EXE" ?

[Gast]

Zitat:daß man pro Verdopplung der Datenmenge 5dB mehr SR-Abstand erhält! Insofern habe ich die Hoffnung, daß uns eine simple Duplizierung bei gleichzeitiger Glättung der Daten wesentliche Vorteile bringt.

eigenlich verschiebt das ja nur irr-real den rauschboden, während die spitenpegel der oberwellen doch mehr oder weniger unabhängig davon jeweils die gleichen werte haben, oder? (hatte das bisher so)

mfg

[Rumgucker]

Von der Duplizierung der Zyklen erhoffe ich mir eine Herabdrückung des Rauschbodens.

Eine Verbesserung in den Oberwellen erhoffe ich mir durch Verfeinerung der Übergänge von einem Zyklus zum nächsten.

Aber wesentlich wird das Tool die Simulationszeit drastisch drücken, weil es eigentlich schon genügt, wenn man einen einzigen Zyklus aufzeichnet. Diese gesparte Zeit kann man in eine verfeinerte Simulation dieses einen Zyklus stecken.

[Gast]

;deal2 wie gesagt: herabdrückung des rauschbodens mit irrrealem wert, mit anderen worten: solange der oberwellenwert stimmt.......

10 oder gar 1 prozent simuzeit mit korrekten ergemnissen - DAS wärs latürnich

[Rumgucker]

"5 Bytes" für nen FP kam mir gleich so komisch vor. Üblich ist 4, 8 oder 10 Byte. Und tatsächlich: raw-Dateien arbeiten mit 32 Bit.

Jetzt hänge ich natürlich an der zusätzlichen Variablen. Offensichtlich wird immer eine zusätzliche Variable in einem Datenpunkt abgespeichert. Aber was bedeutet diese Variable?

*jammer*

Gast? Bist Du Spotnick? Dein Tonfall kommt mir so vertraut vor..

[Gast]

nein
schade
egal