gelöst OPV, Funktionsgenerator und Konsorte

[Batucada]

Im spice error log habe ich gerade noch gesehen, dass noch viele Fehlermeldungen eingetragen sind, etwa des Typs:
Questionable use of curly braces in "b0 b0 0v v={if(int(v(in)/2**0)!=int(v(in)/2**1)*2,v(vn),v(vl))}"
Error: undefined symbol in: "if(int([v](in)/2**0)!=int(v(in)/2**1)*2,v(vn),v(vl))"

VG

Hallo Udo,

ja, so langsam wird's besser, fragwürdiger Gebrauch hört sich kriminalistisch an... ich hab' die geschweiften Klammern entfernt, geht auch ohne.

Die Offset-Spannungsquelle hab' ich jetzt mal "real" eingeplant.

und hier das Plotergebnis:

so gefällt mir das. Jetzt fühle ich mich schon ein ganzes Stück sicherer, um damit in die Hardwareplanung zu gehen.

Vielen Dank für die Erläuterungen
Ein schönes Wochenende wünsche ich allen.

VG

 

[Batucada]

Ich denke, ich befinde mich in der Einlaufkurve zu Zielgeraden. Die bisherige Simulation hat sich nur geringfügig verändert: die duale Spannungsversorgung habe ich von bisher ±8 V auf ±12 V geändert. Ich hab' dann auch damit begonnen, den Schaltplan in DipTrace zu entwerfen.

Diese Änderung hat sich ergeben, als ich mir Gedanken zu der Realisierung des Netzteils gemacht habe.

Die beiden Tracos (A101 und A102) sind komfortable DC/DC-Wandler, mit voll regulierten Ausgängen. Auf der Eingangsseite gibt es ein bisschen was zum Schutz gegen Verplong und Überlastung.

Die Erzeugung der negativen Referenz, um den Pico gegen den GND-Bezug der dualen Spannungsversorgung um 1,65 V ins Negative zu verschieben. Mit der Verschiebung wird die symmetrische Ansteuerung der Komparatoren möglich, die letztendlich die Bewertung des DAC-R-2R-Netzwerk möglich machen.

Ob ich den Q111 wirklich benötige? Ich werde das noch prüfen. Eine Einspeisung des Pico über die Mini-USB ist jedenfalls nicht vorgesehen und wird auch noch technisch unterbunden.

Da der Pico in seiner "eigenen" Welt leben soll, habe ich dem Pico einen USB-Isolator spendiert. X121 ist die Mini-USB-Buchse, über die der Pico seinen Kontakt zur Außenwelt aufrecht erhalten kann. Die linke Seite vom U121 ist von der rechten Seite des Chips galvanisch völlig getrennt, diese Seite des Chips bekommt ihre Betriebsspannung übers Kabel, wenn dieses an den PC angeschlossen wird. Die rechte Seite des Chips ist mit der für den Pico vorgesehenen Spannungsversorgung verbunden - deswegen wird wahscheinlich auch der Q111 überflüssig werden. An die Lötpad-Leiste X124 wird ein kleines Kabel angeschlossen, dessen anderes Ende einen Stecker trägt, der für die Mini-USB-Buchse auf dem Pico vorgesehen ist. Durch diese Trennung gibt es keine unkontrollierten Masseschleifen, die den Einsatz des Funktionsgenerators behindern könnten.

Zum Schluss darf der DAC nicht fehlen.

Es fehlt aber doch noch eines. Der Ausgang des DACs soll durch eine Sample&Hold-Schaltung abgeschlossen werden. Da die Auswahl an passenden ICs eher bescheiden ist, habe ich vorläufig beschlossen eine passende Schaltung aus einem OPV des Typs LT1226 und einem Analogschalter des Typs ADG1201 selbst zu erstellen. Meine diesbezüglichen Erfahrungen liegen schon 40 Jahre zurück. Falls jemand so etwas schon mal in der Neuzeit gemacht hat, darf er sich bei mir melden, Tipps nehme ich gerne entgegen.

VG

 

[Batucada]

Eigentlich sollte dies den noch fehlenden Teil in dem Schaltungsentwurf ergänzen. Doch irgendwas erscheint mir an der Simulation falsch zu sein. Doch was?


Doch was ist es? Was erscheint mir daran nicht stimmig zu sein? Ich bin mal gespannt, ob das wer anders auch so sieht.

VG

 

[Udo]

Ich habe zwar mit dem ADG1201 noch nicht gearbeitet, aber mein Gefühl sagt mir, dass die Pulslängen bei Vin nicht ok sind.
Habe diese mal wie folgt geändert: pulse(0 5 0 1u 1u Tp/2 Tp/2 ). Dabei ist Tp=1/Frequenz der Sinusspannung V3.
Was die geeignete Auswahl einer Sample & Hold Schaltung betrifft, werde ich noch ein bischen suchen.
Auch noch interessant: Werde mal die R2-R ladder-Widerstände mit Toleranzen versehen und dann eine Monte-Carlo Analyse laufen lassen.

VG

 

[Batucada]

Moin Udo

schau dir mal den Spannungsgraphen von C1 an und dabei den Verlauf in der Haltephase an. So in den Haltephasen die Ladung sich im positiven (!!) Bereich befindet - also oberhalb der Nulllinie, erscheint der Abbau der Ladung als fallender Graph den realen physikalischen Gegebenheiten zu folgen. Nicht aber wenn die Ladung sich im negativen (!!) Bereich befindet. Dann haben wir eine Ladung mit umgekehrte Polung, deren betragsmäßige Größe ähnlich sein müsste, wenn sich die Frequenz und die Impulsfolge synchron verhalten würden, wenn man die entsprechende Einstellung vornehmen würde.

Verblüffend ist aber der fallende Graph in den "negativen" Haltephasen!!! Nach meiner Ansicht müsste der Graph dann steigend (und nicht weiterhin fallend) sein, weil die Ladung Q, gemessen in Coulomb (C), dargestellt durch das Spannungspotential (V) stetig abnimmt, was einem abnehmenden Spannungspotential relativ zur Nulllinie entsprechen müsste. Hier liegt nach meiner Meinung ein Fehler im Modell vor!!!

Auch müsste der Verlauf der Entladung einer exponentiellen Darstellung folgen. Es ist kaum anzunehmen, dass die Entladung in den Haltephasen mit einer konstanten Stromentnahme erfolgt, sondern eher zufällig bei den sich einstellenden Umgebungsbedingungen ergibt. Das ist ja schließlich das Schöne an LTspice, man kann mit der Lupe unendlich tief in den Plot einsteigen und die Verhältnisse nachmessen. In den Haltephasen verhält sich der Graph absolut proportional zur Zeitachse und lässt keinerlei exponentiellen Anteil erkennen.

Nach meiner Meinung taugt das Modell für den Schalter nix oder ist es das Modell für den OPV? Oder gar beides?

Wie muss man ein Modell für diesen Fall betrachten? Bei einem echten Schalter mit sich trennenden und wieder schließenden Kontakten kann man getrost davon ausgehen, dass ein solcher Schalter sich nicht an der Entladung beteiligt! Aber ich denke, diese Sichtweise ist im Falle eines analogen Schalters falsch. Und die nächste Frage: Wieviel von der Ladung des Kondensators saugt der OPV ab? Wenn also zwei unabhängige Komponenten an dem Spiel beteiligt sind, kommt es mir merkwürdig vor, wenn die Entladung eine zeitliche Proportionalität aufweist, wo wir doch alle schon in der Schule gelernt haben, dass der exponentielle Verlauf grundsätzlich ist...

VG

 

[Udo]

So sehen die Kurven bei mir aus. Habe sie ergänzt und kommentiert. Die Entladung von C1 bei offenem Schalter sehe ich problematisch. Wodurch wird er entladen? Deshalb das zweite file mit R2IIC1.

VG

 

[Batucada]

Die Entladung von C1 bei offenem Schalter sehe ich problematisch. Wodurch wird er entladen? Deshalb das zweite file mit R2IIC1.

VG

Hallo Udo,

das ist einer der Punkte. C1 soll schließlich nicht zwangsweise über einen Widerstand entladen werden, sondern seinen Ladungszustand in der Sample-Phase den aktuellen Verhältnissen anpassen, was er zumindest in der Simulation auch tut. Soweit die Theorie. In der praktischen Anwendung dürfte der "geöffnete" analoge Schalter und der Spannungsfolger-OP an der Ladung von C1 zehren, das wird auch in der Simulation deutlich, in der Phase, wenn das Nutzsignal positiv war (vor dem Wechsel in die Hold-Phase), wird es in der Simulation korrekt dargestellt, in der anderen Phase, wenn das Nutzsignal negativ war, wird die zu erwartende Tendenz in der Simulation falsch dargestellt - da beißt die Maus kein Faden ab!

Jetzt hab' ich die Verhältnisse willkürlich gewählt, normalerweise müsste der Ablauf anders erfolgen. Ich versuche es zu beschreiben.

Jeder Koordinatenpunkt auf der darzustellenden Funktion beschreibt in x-Richtung die Zeit und in y-Richtung die entsprechende Größe der Amplitude zu diesem Zeitpunkt. Wenn jetzt der µ-Controller feststellt, dass es bald an der Zeit sein wird, die Amplitude zu ändern, wird er dem SHA signalisieren: "Du musst jetzt mal den aktuellen Wert halten" - der Schalter öffnet, und für den µ-Controller bedeutet das, den Amplituden-Wert neu auszugeben. Im DAC wird's rumpeln und knistern, da nicht nur das Bitmuster sich ändert, es kommen noch parasitäre Kapazitäten auf der Leiterplatte hinzu, die sich durch die Umschaltung ändern - aber am Ausgang des Funktionsgeber merkt man davon nix, weil der SHA auf seinem letzten Wert verharrt. Das ganze Spiel sollte aber nicht mehr als 10% von einem Viertel der zu Verfügung stehenden Perioden-Dauer ausmachen. Bei 20 kHz ist die Perioden-Dauer 50 µsec, 1/4tel davon sind 12,5 µsec, davon 10% ergibt 1,25 µsec. Innerhalb dieser Zeit sollte das Geschehen sich im DAC-Netzwerk beruhigt haben, so dass man den analogen Schalter wieder schließen kann und der C1 die Gelegenheit erhält sich den neuen Verhältnissen anzupassen, also zu "samplen".

Wenn also für die Hold-Phase eine feste Zeitdauer eingeplant wird, dann ist die Zeitdauer der Sample-Phase mit der Frequenz variabel. D.h. der C1 muss nur für eine kurze Zeitdauer den letzten Wert halten. Die Verluste werden bei den "fabrikfertigen" SHAs mit wenigen Millivolt angegeben. Ich hab die DAC-Spannung jetzt auf ±12 Volt hochgetrieben, so dass Verluste im Bereich von wenigen Millivolt sich nicht bemerkbar machen werden - hoffentlich.

Also, die vorliegende Simulation stellt absichtlich nicht die Realität dar. Im unteren Frequenzbereich ist die Sample-Phase extrem lang im Verhältnis zur Hold-Phase, die immer konstant sein wird.

VG

 

[Udo]

Nur zur Info
LF398 sample&Hold IC

 

[Batucada]

Och!! wo hast'n den her?
Analog Devices hat seinen eigenen Typ etwas stiefmütterlich behandelt. Die Datenblätter sehen schon so zerfledert aus
aber das ist auch der Typ, der halbwegs vom Parameterspektrum in meine Anwendung passen würde, wenn nicht die Erfassungszeit wäre, die in der Liste mit 16 µsec angebene wird.

 

[Udo]

Den hab ich bei der LTspice group gefunden LTspice@groups.io
Allerdings stand im .asy-Symbol LF398.lib, die lib-Datei war aber eine LF398.sub. Habe die .sub in .lib umbenannt und hoffe es passt.

VG
(Sherlock Holmes)
Udo

 

[Batucada]

Hallo Udo,

Ich hab' mal ein bisschen gespielt und den AD8597 als OPV für den Spannungsfolger gekürt, nach meiner meinung sieht das sehr gut aus
Das Modell für den AD8597.cir hab ich vom Service der AD-Webseite und las .lib umgetauft, das Symbol ist ne Kopie und entsprechend zurechtgemacht.

Ich glaub, ich hab meine Kombination gefunden

VG

 

[Batucada]

So, das war's zunächst einmal mit dem Projekt in dieser Ausdehnung. Ich hab' das Schema in Diptrace schon fertig gezeichnet und ich könnte den Router starten. Irgendwas in meinem Hinterkopf hat mich gewarnt, zu sehr auf das Gaspedal zu treten. Heute habe ich das Vehikel erst einmal geparkt und den Zündschlüssel abgezogen.

Eine einfache Abschätzung hat mich auf den harten Boden der Realität zurück geholt. Wollte man die Auflösung von 20 Bit faktisch ausnutzen so müsste man rechnen, dass je Quadrant einer Sinuswelle genau 524.288 nacheinander in das GPIO-Register des Pico zu schieben wären. Bei einer kompletten Sinuswelle ergibt das in Summe die Anzahl von 2.097.152 Werten je Periode. Bei einer gewünschten Signalfrequenz von 20 kHz resultiert daraus die fantastische Anzahl 41.943.040.000 von Werten, die jede Sekunde in das GPIO-Ausgaberegister verbracht werden müssten. Wenn man jetzt mal die tatsächliche Anforderung an ein Programm außer acht lassen würde und träfe die kuriose Annahme, dass die mit jedem Prozessortakt auch geschehen könnte, hätten wir eine Raspberry Pi Pico mit einer Taktfrequenz von knapp 42 GHz vor uns auf dem Tisch liegen. Das normale was der Pico kann, sind 133 MHz.

Bleiben wir noch ein wenig bei der dümmlichen Annahme, der Pico könnte bei jedem Takt einen Amplitudenwert in sein GPIO-Ausgaberegister verschieben, so wären das 315,3612 Werte je Periode bei einer Signalfrequenz von 20 kHz. Effektiv wäre das die Auflösung eines Quadranten mit 79 Werten die locker vom Hocker mit 7 Bit zu bewältigen wären.

Auch die Gegenrechnung wieviel von der möglichen Auflösung bei eine Signalfrequenz von 20 Hz noch verwendet werden könnte, macht die Stimmung nicht tröstlicher. Pauschal lässt sich somit schon feststellen:
-- eine Auflösung von 8 Bit ist bei einer Signalfrequenz von 20 kHz todsicher immer noch reichlich überdimensioniert,
-- eine Auflösung von 20 Bit wäre bei einer Signalfrequenz von 20 Hz gerade so eben machbar, wenn der Pico mit nichts anderem beschäftigt sein würde.
-- kappt man die 20 Bit um 4 Bit auf 16 Bit, ist man bei einer Signalfrequenz von 20 Hz noch üppig bedient, die Schallgrenze wäre aber bei einer Signalfrequenz von 1000 Hz schon wieder erreicht.

Es wird also noch einige Überlegungen kosten, bis die Schaltung in allen Lebenslagen praktikabel ist.

VG

 

[Udo]

Am Anfang einer Entwicklung steht immer die Aufstellung einer genauen Spezifikation! Was ist das Ziel ? Welche elektrischen Umgebungsbedingungen sind gegeben? Beim "Drauf los entwickeln" kann herauskommen, dass man woanders landet.
Ergebnis einer jahrzehntelangen Erfahrung. Bin selbst anfänglich in dieselbe Falle getappt.
Wie schon mal gepostet: Erfahrung ist die Summe aller Reinfälle.
VG

 

[Batucada]

Am Anfang einer Entwicklung steht immer die Aufstellung einer genauen Spezifikation!

... sollte so sein! Doch der Weg zur Hölle ist mit guten Vorsätzen gepflastert

Auf der Suche nach Entschuldigungen, die ich für mich anführen könnte... bin ich zu blauäugig einer Idee gefolgt, die für mich fantastisch erschien. 22 Bit Auflösung... und das mit einem Mikrocontroller, der nur ein paar Mark fünfzig kostet... Da war kein Raum für eine deterministische und strategische Planung.

Aber ein netter Zeitvertreib war's doch. Hatte mich dieser Zeitvertreib wieder zu meinen Wurzeln geführt, von denen ich mich vor etwas mehr als einem Jahrzehnt gelöst hatte. Warum ich nicht meiner Entscheidung treu geblieben bin, ärgert mich aber doch.

Jetzt verschwindet die bisherige Planung zunächst einmal in der Schublade, ein Verlust war's nicht, hat ja kein Geld gekostet und Zeit hab' ich ja eh genug.

VG