ADC CNV Jitterfrei - Schaltung

[Gustl B. (-gb-)]

Hallo zusammen,

es gibt ja viele ADCs die mit der steigenden Flanke von CNV abtasten. 
Dazu sollte diese Flanke natürlich jtterfrei sein. Es gibt von LTC auch 
eine schöne Schaltung dazu, aber die verstehe ich noch nicht ganz.

Wenn bei der Schaltung (Angang) CLKIN kein ganzzahliges Vielfaches von 
CNV_EN ist, wie ist da sichergestellt, dass CNV nicht mal einen Takt von 
CLKIN früher oder später erscheint?
Ich glaube bisher, dass das funktioniert, sehe das auch in der 
Simulation, aber mir fehlt die Erklärung für den Fall, dass sich CLKIN 
und CNV_EN gegeneinander verschieben können.

Oder muss CLKIN ein ganzzahliges Vielfaches von CNV_EN sein? Also sollte 
ich CLKIN (wie in dem Schaltplan auch) ins FPGA füttern und mir daraus 
dann CNV_EN erzeugen?

Vielen Dank!

(Sorry, dass das hier steht, aber es ist weder uC noch Analogtechnik und 
hat bei mir was mit einem FPGA zu tun.)

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Gustl B. schrieb:
> Wenn bei der Schaltung (Angang) CLKIN kein ganzzahliges Vielfaches von
> CNV_EN ist, wie ist da sichergestellt, dass CNV nicht mal einen Takt von
> CLKIN früher oder später erscheint?
Erst mal finde ich es "lustig", dass in der Beschreibung ein CLKIN 
auftaucht, der in der zugehörigen Schaltplan an der fraglichen Stelle 
noch CLK heißt. Und zudem ist es "urig", dass der CLK zweimal auftaucht: 
einmal als Text am J4 und mit dem selben Nachem invertiert am Ausgang 
des U11.
Aber sei's drum...  ;-)

Mit dieser Schaltung wird nur garantiert, dass die steigende Flanke vom 
Signal CNV+ definiert jitterfrei zum CLK ist. Das Zurücksetzen beim 
NL17SZ74 ist asynchron und kann über das Deaktivieren vom CNV_EN 
jederzeit erfolgen.

Oder andersrum: kommend vom CNV_EN = '0' wird dieses Signal irgendwann 
und mit Jitter behaftet auf '1' gesetzt. Der Ausgang des FF U11 und 
damit das Signal am CNV+ Pin des ADC wird dann jitterfrei mit der 
nächsten steigenden Taktflanke des CLK gesetzt. Das wars, worauf es bei 
der Schaltung ankommt und mehr kann sie auch nicht. Ob es dabei 
"vielfache Frequenzen" oder gar Versätze um ganze CLK-Zyklen gibt, 
interessiert die Schaltung nicht.

Einzig die Setup-Zeit des Flipflops sollte man beachten, denn sonst 
handelt man sich da metastabile Geschichten ein und es wäre für 
definierte Pegel sinnvoll, 2 solcher Flipflops hintereinander zu 
schalten.

> hat bei mir was mit einem FPGA zu tun
In einem FPGA musst du "nur" dafür sorgen, dass das Ausgangs-FF vom 
CNV-Signal getaktet ist, dann bist du automatisch genauso "jitterfrei" 
wie diese Schaltung hier.

[Gustl B. (-gb-)]

Das trifft noch nicht ganz meine Frage:

Lothar M. schrieb:
> kommend vom CNV_EN = '0' wird dieses Signal irgendwann
> und mit Jitter behaftet auf '1' gesetzt. Der Ausgang des FF U11 und
> damit das Signal am CNV+ Pin des ADC wird dann jitterfrei mit der
> nächsten steigenden Taktflanke des CLK gesetzt.

Das verstehe ich. Aber wie ist das mit den Anzahl der Taktzyklen von CLK 
während einer Periode von CNV_EN?

Sagen wir ich habe eine CLK und eine andere davon unabhängige CLK_B 
(anderer Takt) am FPGA mit der ein CNV_EN mit 5 MHz erzeugt wird. Dann 
kommt alle 200 ns ein neues CNV_EN. Aber die Anzahl der Taktflanken von 
CLK innerhalb dieser Zeit muss nach meinem verständnis nicht konstant 
sein.

Bedeutet, am Ende ist die Periodendauer des CNV einmal N Takte von CLK, 
aber auch mal N+1 oder N-1.

Wenn ich aber immer die gleiche Anzahl N haben will, muss ich dann 
CNV_EN synchron, also aus dem gleichen Takt CLK erzeugen?

Mir geht es hier gerade nicht um den kleinen Jitter, sondern um die 
Erklärung warum ich am Ende keinen Jitter um einen ganzen Takt von CLK 
habe weil CLK und CNV_EN irgendwie driften und kein Integer Teiler 
haben.

Ich weiß aber nicht ob ich das verständlich geschrieben habe ...

[Achim S. (Gast)]

Gustl B. schrieb:
> Mir geht es hier gerade nicht um den kleinen Jitter, sondern um die
> Erklärung warum ich am Ende keinen Jitter um einen ganzen Takt von CLK
> habe weil CLK und CNV_EN irgendwie driften und kein Integer Teiler
> haben.

Wenn CNV_EN mal eine Periode von CLK früher kommt und mal eine später 
(was bei asynchronen Takten kaum vermeidbar ist), dann hast du diesen 
groben Jitter.

Der normale Weg, das zu vermeiden, ist tatsächlich CLK auch ins FPGA zu 
schicken und mit synchronen Takten zu arbeiten (also ganzzahlige 
Vielfache des Takts, die nicht asynchron auseinander laufen). Hattest du 
ja auch zu Beginn schon selbst beschrieben.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Gustl B. schrieb:
> Bedeutet, am Ende ist die Periodendauer des CNV einmal N Takte von CLK,
> aber auch mal N+1 oder N-1.
Richtig. Aber völlig jitterfrei zum CLK.

> aber auch mal N+1 oder N-1.
Eigentlich nur eines davon. Kommt aber drauf an, wie die 
Frequenzverhältnisse tatsächlich sind und wie stark CLK_B jittert.

> Wenn ich aber immer die gleiche Anzahl N haben will, muss ich dann
> CNV_EN synchron, also aus dem gleichen Takt CLK erzeugen?
Ja.

[Gustl B. (-gb-)]

Vielen Dank ihr Beiden! Tja das macht es dann schon aufwändiger ... CLK 
über die Isolation zum FPGA und CNV_EN zurück. Und dann ist das noch 
eine CMOS Clock, Digitalisolatoren dafür gibt es nicht in so irre 
schnell (ich bräuchte so 200 MHz). Mal gucken, vielleicht verwerfe ich 
das auch, immer diese Entscheidungen.

[Christoph Z. (christophz)]

Gustl B. schrieb:
> FPGA und CNV_EN zurück. Und dann ist das noch
> eine CMOS Clock, Digitalisolatoren dafür gibt es nicht in so irre
> schnell (ich bräuchte so 200 MHz).

Auf der ADC Seite einen LVDS line driver spendieren und dann zusammen 
mit deinen Daten über den LVDS Digitalisolator. CNV_EN ist ja langsamer, 
da hast du mehr möglichkeiten, sonst auch per LVDS aus dem FPGA raus und 
auf der ADC Seite in single-endet wandeln.

[Gustl B. (-gb-)]

Exakt das könnte ich machen. Derzeit ist der ADC nicht isoliert und 
bekommt CNV direkt aus dem FPGA. Bin aber zufrieden. Ich kann zwei Dinge 
schlecht abschätzen:

1. Das FPGA bekommt einen recht sauberen 125 MHz Takt aus einem Si570. 
Wenn ich den im FPGA durch eine Zweiterpotenz Teile, also nur einen 
Zähler, keine PLL oder so, wie viel Jitter kommt dann da dazu?

2. Diese LVDS Isolatoren fügen nur geringen Jitter hinzu, habe ich aber 
noch nicht aufgebaut und getestet.

Aktuell würde ich den Takt direkt aus dem FPGA nehmen, das ist 
einfacher, braucht weniger Strom auf der isolierten Seite und ich 
bekomme keine zusätzliche Taktdomäne ins FPGA.

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

Gustl B. schrieb:
> 1. Das FPGA bekommt einen recht sauberen 125 MHz Takt aus einem Si570.
> Wenn ich den im FPGA durch eine Zweiterpotenz Teile, also nur einen
> Zähler, keine PLL oder so, wie viel Jitter kommt dann da dazu?

System Jitter ist das richtige Stichwort, laesst sich so unmoeglich 
vorhersagen, den muss man messen:

https://www.xilinx.com/support/answers/37430.html

[Gustl B. (-gb-)]

Danke! Macht zwar meine Entscheidung nicht leichter, aber ist eben so.

[Frickel F. (frickelfritze)]

Moin :)

Gustl B. schrieb:
>
> Aktuell würde ich den Takt direkt aus dem FPGA nehmen, das ist
> einfacher, braucht weniger Strom auf der isolierten Seite und ich
> bekomme keine zusätzliche Taktdomäne ins FPGA.

Was ich so von deinen Projekten mitbekommen habe, wird es sich wohl 
nicht um einen 0815 8Bit ADC handeln oder? So richtig wohl wäre mir dann 
nicht den Takt aus dem FPGA zu nehmen, da würde ich schon zu 
Clock-Buffer tendieren und von diesem aus den Takt Punkt zu Punkt 
verteilen. Auch würde ich den Oszillator und Buffer jeweils von einem 
Rauscharmen LDO versorgen. Ist jetzt nur aus dem Blauen heraus, ich weiß 
ja nicht was Du wirklich vorhast...

Bissel vorgeplänkel... Ich wollte HF-Mäßig einige Signale direkt aus dem 
FPGA verwursten, Spektrum sah einfach Schei.. aus. Auf der Suche nach 
der Ursache bin ich dann am ende beim FPGA gelandet, alle nachfolgenden 
Stufen und die externe PLL die zum FPGA hin geht waren Ok, kommt also 
direkt vom FPGA, hatte dann auch erst mal nicht weiter gemacht.

Als ich das jetzt hier gelesen habe ist mir die Idee gekommen das mal 
unter die Lupe zu nehmen.

Testaufbau:
Takt: 100Mhz CVHD-950 mit LT3042 LDO.
FPGA: Spartan3-500E Frickel Board.
Dämpfung zum Specki ca. 25db.

Blau: 100Mhz Clk-In am FPGA Pin.
Orange: Out 100Mhz mit ODDR2.
Gelb: Out 100Mhz mit ODDR2 und Clk einmal durch DCM.

Core selber war jetzt nur einmal das notwendigste und XOR über ca. 4000 
Register, am Spektrum hat sich aber nicht wirklich viel getan. Das 
könnte sich natürlich noch ändern wen da mehrere Takte/IOs wackeln und 
wie sich das auf anderen FPGAs verhält, Hm... weiß nicht.

Das war jetzt auch nur mal auf die schnelle ein Test um so ungefähr raus 
zu bekommen was aus den 100MHz so werden, da müsste man jetzt auch mal 
umrechnen Phasenrauschen vs. Jitter. Da werde ich die Tage noch mal 
Frickeln und eventuell gibt es hier ja noch jemanden der noch etwas mehr 
licht ins dunkle bringt.

[Gustl B. (-gb-)]

Frickel F. schrieb:
> Was ich so von deinen Projekten mitbekommen habe, wird es sich wohl
> nicht um einen 0815 8Bit ADC handeln oder?

Richtig.
Aktuell habe ich Hardware die wunderbar funktioniert:
Das ist jeweils mit LTC2325 16 Bit, 5 MSps und galvanisch getrennt.
Dann habe ich aktuell eine Hardware mit AD7960 18 Bits 5 MSps ohne 
galvanische Trennung die deutlich schlechtere Ergebnisse zeigt. Ist bei 
der Hardware OK, denn primär wollte ich andere Dinge testen und die 
funktionieren wie gewünscht.

Ich plane also aktuell wieder eine Hardware mit galvanischer Trennung 
und ... naja, ich könnte wieder den LTC2325 nehmen, brauche aber 
eigentlich nur einen ADC Eingang und keine 4. Der LTC2311 wäre eine 
Option, ja, aber wenn es besser wäre, dann wäre das auch nett. Ich denke 
da gerade an den LTC2387-18 (-:

Ich habe heute mal etwas gesucht und mich erinnert, das Problem ist 
nicht der Jitter vom FPGA. Siehe 
Beitrag "Sinus Referenz 100 kHz"
Da kam der Takt auch aus dem FPGA und hatte nur ganz geringen Jitter, 
aber auf der galvanisch getrennten Platine hinter dem Digitalisolator 
Si866x war dann viel Jitter.
Das ist also noch ein Grund einen LVDS Isolator zu nehmen mit geringem 
Jitter. Oder eben CNV lokal auf der isolierten Platine zu erzeugen.
Ich könnte sogar SCK und CNV lokal erzeugen. Mit einem schnellen Takt, 
einem Zähler und einigen Gattern. Das hatte ich in dem verlinkten Thread 
getan, funktioniert also und ist machbar. Dann gehen nur noch DCO und 
Daten vom ADC zum FPGA und auch noch ein CNV damit der FPGA sieht wann 
eine Wandlung war.

Frickel F. schrieb:
> So richtig wohl wäre mir dann
> nicht den Takt aus dem FPGA zu nehmen, da würde ich schon zu
> Clock-Buffer tendieren und von diesem aus den Takt Punkt zu Punkt
> verteilen. Auch würde ich den Oszillator und Buffer jeweils von einem
> Rauscharmen LDO versorgen.

Hatte ich ebenfalls schon mal gemacht 
Beitrag "Re: Zeigt her eure Kunstwerke (2020)" mit einem AD9508. 
Aber das geht bei galvanischer trennung schlecht. Da müsste der Takt 
dann ja auch über den Isolator und der fügt Jitter hinzu.

Frickel F. schrieb:
> Auf der Suche nach
> der Ursache bin ich dann am ende beim FPGA gelandet, alle nachfolgenden
> Stufen und die externe PLL die zum FPGA hin geht waren Ok, kommt also
> direkt vom FPGA, hatte dann auch erst mal nicht weiter gemacht.

Gut, im FPGA würde ich PLL/MMCM vermeiden und nur mit FFs teilen. Dann 
sollte der Jitter gering bleiben so meine Vermutung. Hängt wohl am 
Digitalisolator ...

[Frickel F. (frickelfritze)]

Moin :)

Tobias B. schrieb:
> System Jitter ist das richtige Stichwort, laesst sich so unmoeglich
> vorhersagen, den muss man messen:
>
> https://www.xilinx.com/support/answers/37430.html

Das war genau der Denkanstoß den ich gebraucht habe, DANKE nochmal!!! 
Dazu noch der Schaltungsausschnitt mit dem FF haben mir einfach keine 
ruhe gelassen.

Frickel F. schrieb:
> Core selber war jetzt nur einmal das notwendigste und XOR über ca. 4000
> Register, am Spektrum hat sich aber nicht wirklich viel getan.
Da war ich wohl zu voreilig, ich hätte das mal mit größerem Span messen 
sollen, dann sieht man das sehr wohl.

Ich habe jetzt noch etwas weiter experimentiert und habe wider mal 
mitbekommen wo meine Messgrenzen sind. So ein Standard Specki ist halt 
nur bedingt brauchbar für diese Art Jitter bzw. Phasenrauschmessungen. 
Das bitte beim beurteilen der Messungen im Hinterkopf behalten, mehr 
geht leider nicht und für ein RS-Specki bzw. Ossi mit xxGSa der das 
könnte... ähm, ja, haben will. :D

Messaufbau ist mit einem externen FF (SN74AUP1G80) der mehr oder weniger 
"frei verdrahtet" drauf gebraten ist (Ext_FF.jpg). XO ist wie gehabt 
CVHD-950 100Mhz. Der externe FF und der FPGA-Out kommen beide aus IO-FFs 
vom FPGA.

Für die Rechnerei Phasenrauschen nach ps habe ich dieses Tool verwendet.
http://leleivre.com/rf_iPN_jitter.html

Die Schaltung mit dem Externen FF ist so zu sagen mal wieder einfach 
aber genial, durch das Takten direkt von der quelle aus sollte der 
Jitter der vom FPGA erzeugt wird keine große geige mehr spielen. Für 
normale Digitale Sachen wohl nicht ganz so wichtig, aber wenn man 
Signale braucht mit geringen Jitter bzw. Phasenrauschen aus dem FPGA 
heraus, dann schon. Ich habe auch Messungen mit und ohne interne 
PLL(DCM) gemacht weil die eigentlich Käse sind, aber solange alles 
Syncron läuft biss zum externen FF, passt das auch mit PLL.

Die Jitter angaben sind einmal mit 10Hz und ohne 10Hz vom Signal 
gerechnet, mit 10Hz dürfte eigentlich mit diesem Specki Sinn frei sein.

Bild "Jpg6_100In" 100Mhz direkt am Eingang vom, FPGA 52,643ps / 0,895 
psRMS.
Bild "Jpg9_mit_DCM_ohne_FF.jpg" 25Mhz-Out über IO-FF vom FPGA, 2158.4 / 
8,384 psRMS.
Bild "Jpg10_mit_DCM_und_FF.jpg" 25Mhz-Out uber ext. FF, 1247,08 / 4,833 
psRMS.

Bild "Jpg12" Sind die runter geteilten 25Mhz mit breitem Span, einmal 
mit und ohne externen FF. Schön zu sehen das mit externen FF der 
Rauschteppich um einige dbm niedriger ist und von Nebenlinien bei 
27,08Mhz nichts mehr zu sehen ist.

Bitte noch mal dran denken, der gesamte Aufbau ist nicht der beste, das 
externe FF hat nur die verseuchten 3,3V vom Board bekommen und wie 
gepinselt sind die Messungen eigentlich nur wilde Richtwerte. Der Specki 
selber ist mit -98dBc/Hz@10Khz bei 1Ghz spezifiziert, für solche 
Messungen... Suboptimal um mal vorsichtig zu sein.

Ich denke mal wenn man das ordentlich aufbaut, ein besseres FF einsetzt, 
Rauscharmen LDO am FF, dann dürfte da noch mal deutlich was raus zu 
holen sein.

@Gustl, ich habe jetzt nicht alles in Deinen verlinkten Seiten gelesen, 
aber was mir immer wieder aufgefallen ist, sind Deine FFTs, die sehen ja 
soweit gut aus, aber eigentlich sagen die alle nichts über Jitter bzw. 
Phasenrauschen aus. Dazu ist der Span von 0-xMhz einfach zu groß. Das 
sollte man wohl besser mit großer FFT und sehr kleinem Span Messen. Dazu 
noch ein Khz Messsignal bei einem xxMSPS ADC, da haut man sich doch 
selber die Taschen voll. ;)

Gustl B. schrieb:
> Frickel F. schrieb:
>> So richtig wohl wäre mir dann
>> nicht den Takt aus dem FPGA zu nehmen, da würde ich schon zu
>> Clock-Buffer tendieren und von diesem aus den Takt Punkt zu Punkt
>> verteilen. Auch würde ich den Oszillator und Buffer jeweils von einem
>> Rauscharmen LDO versorgen.
>
> Hatte ich ebenfalls schon mal gemacht
> Beitrag "Re: Zeigt her eure Kunstwerke (2020)" mit einem AD9508.
> Aber das geht bei galvanischer trennung schlecht. Da müsste der Takt
> dann ja auch über den Isolator und der fügt Jitter hinzu.

Im groben schon, aber was ich nicht gesehen habe, ist ein Rauscharmer 
LDO, weder beim Si-Clk noch beim AD9508, oder habe ich das übersehen?

Mit der VCC wo alles andere auch dran baumelt, wirst Du nicht mal im 
Ansatz an die angegeben Daten kommen. Schau mal ins Datenblatt bzw. im 
Schaltplan zum Eval-Kit vom AD9508, die verbauen da nicht ohne Grund so 
einen µV-RMS-Low-Noise-LDO. :)

Zum Jitter wurde in den anderen Beiträgen ja eigentlich schon alles 
gesagt, bei deinen geforderten Bit-breiten und Frequenzen glaube ich 
auch nicht das Du da mit irgendwelchen LVDS-Isolatroen den Takt 
verteilen kannst, zumindest nicht mit 1-2 stelligen ps-Jitter 
Anforderung.

Gustl B. schrieb:
> Gut, im FPGA würde ich PLL/MMCM vermeiden und nur mit FFs teilen. Dann
> sollte der Jitter gering bleiben so meine Vermutung. Hängt wohl am
> Digitalisolator ...
Du wirst da Teilen können wie Du willst, wahrscheinlich ist Deine 
Annahme das im FPGA der Takt so schön sauber ist wie er von außen 
anliegt... Das dem nicht so ist, ist mir aber auch erst nach dem Einwurf 
"System Jitter" wirklich klar geworden. ;) Klar, die internen PLLs sind 
Murks, aber auch ohne diese bleibt der Takt nicht das was man haben 
will.

Mit dem Synchronen FF wie im Ausschnitt von Deinem Plan, sollte das 
Lokal aber hinhauen wen das Signal vom FPGA kommt, das FF was ich 
verwendet habe (SN74AUP1G80) dürfte auch einfacher zu handhaben sein, 
müsste man mal ausprobieren mit den passenden Messmitteln Messen.

Falls noch jemand Vorschläge hat wie man die Messungen verbessern 
könnte...?


Gruß

[Duke Scarring (Gast)]

Frickel F. schrieb:
> Blau: 100Mhz Clk-In am FPGA Pin.
Sind die ~100 kHz schon im Taktsignal drin, oder kommen die erst durch 
das FPGA rein?
Irgendwie sind die Farben nicht so ganz eindeutig...

Duke

[Frickel F. (frickelfritze)]

Ja, am Clk-In, die schleppe ich mir durch die GPS Synchronisierung ein, 
wie schon geschrieben ist der Aufbau etwas sch_lam_pig..., so gut das 
Phasenrauschen vom diesem XO auch ist, ein kleiner Luftzug und die 
Frequenz schwimmt weg, das war bei Sweep Zeiten um die 40 Sekunden mit 
langer mittelung natürlich Käse.

War auch nur ein Test auf die schnelle um überhaupt erst mal zu sehen 
was rein geht/raus kommt und ob ich da überhaupt etwas Messen kann.

Was mir jetzt aber auch erst aufgefallen ist, die beiden huckel sind aus 
dem FPGA raus, deutlich kleiner mit ca. 10dbm im Gegensatz zu ca. 20dbm 
die reingehen. (ein paar db verstecken sich im Bild zwischen Gelb und 
Pink.)

Werde ich noch mal genauer Messen.

Gruß

[Duke Scarring (Gast)]

Frickel F. schrieb:
> Ja, am Clk-In, die schleppe ich mir durch die GPS Synchronisierung ein,
Ah, ok.

Einen Nachteil hat der normale Spektrumanalysator: man kann 
Amplitudenmodulation und Phasenmodulation nicht unterschieden, beide 
erzeugen Nebenlinien. Bei besseren Analysatoren gibt es 
Phase-Noise-Measurement-Optionen, die auch gleich den Jitter über einen 
einstellbaren Bereich ausrechnen.

Im Prinzip könnte man auch einen Netzwerkanalysator zur 
Phasenrauschmessung heranziehen. Da braucht man aber noch die passende 
Auswertung dazu (ich meine der VNWA3 hat da was) und das Referenzsignal 
des NWA sollte dazu ein Größenordnung besser sein als das Signal des 
DUT.

Phasenrauschmessung von FPGA-Ausgängen steht auf meiner TODO-Liste 
relativ weit hinten, da ich in kritischen Fällen auch einfach ein 
externes Flip-Flop spendiere...

Duke

[Gustl B. (-gb-)]

Frickel F. schrieb:
> Die Schaltung mit dem Externen FF ist so zu sagen mal wieder einfach
> aber genial, durch das Takten direkt von der quelle aus sollte der
> Jitter der vom FPGA erzeugt wird keine große geige mehr spielen.

Ja, ist sie, braucht aber einen FPGA Eingang zusätzlich. Darum ging es 
mir ja oben in dem Thread und zwar ob ich den schnellen Takt in das FPGA 
füttern muss um CNV_EN zu erzeugen. Ja, muss ich, braucht also eine 
Verbindung mehr über den Digitalisolator.

Frickel F. schrieb:
> sind Deine FFTs, die sehen ja
> soweit gut aus, aber eigentlich sagen die alle nichts über Jitter bzw.
> Phasenrauschen aus. Dazu ist der Span von 0-xMhz einfach zu groß. Das
> sollte man wohl besser mit großer FFT und sehr kleinem Span Messen. Dazu
> noch ein Khz Messsignal bei einem xxMSPS ADC, da haut man sich doch
> selber die Taschen voll. ;)

Klar, dazu waren die auch nicht gedacht. Erst weiter unten im Thread 
geht es um das Phasenrauschen und den Jitter.

Ab hier Beitrag "Re: Sinus Referenz 100 kHz" geht es um 
den Jitter mit der Schaltung und ab hier 
Beitrag "Re: Sinus Referenz 100 kHz" kommen Oszi 
Screenshots.

Frickel F. schrieb:
> Falls noch jemand Vorschläge hat wie man die Messungen verbessern
> könnte...?

Mir wurde damals empfohlen mit dem Oszi auf eine Flanke zu triggern und 
mir dann eine weit entfernte Flanke anzugucken die z. B. 10 us oder 1 ms 
später kommt. Dann sehe ich wie stark der Jitter im Durchschnitt über 
diese Zeit ist. Klar, wenn das gaußförmig verteilt ist, dann mittelt 
sich das weg. Da sollte man dann lieber auf eine Flanke triggern und 
sich die nächste Flanke angucken.

Frickel F. schrieb:
> Im groben schon, aber was ich nicht gesehen habe, ist ein Rauscharmer
> LDO, weder beim Si-Clk noch beim AD9508, oder habe ich das übersehen?

Richtig, bei der Platine habe ich darauf keinen Wert gelegt.

Aber ich habe noch Fragen:

1. Der ADC braucht 5 V, geht aber Laut Datenblatt von 4,75 V bis 5.25 V. 
Mein isolierter DCDC liefert 5 V. Die werden gefiltert, aber ist es 
sinnvoll da noch einen LDO vor den ADC zu setzen, z. B. einen TPS736 mit 
"Ultra-Low Dropout Voltage:75 mV typ" laut dessen Datenblatt den ich 
dann auf 4,85 V oder so einstellen würde?

2. Ich benötige ein sauberes CNV mit 15 MHz. Dann habe ich 66.6... ns 
Zeit je Wandlung und davon 50,6... ns zum Auslesen der Daten mit SCK. 
SCK muss während dieser Zeit im Two-Lane-Mode 5 Pulse haben und 
dazwischen 4 Täler. Damit muss ein Puls also 50,6... ns/9 = 5,6295 ns 
lang sein. Maximal. Kürzer ist erlaubt bis minimal 2,5 ns.
Die Frage ist jetzt:
Sollte ich
a) im isolierten Bereich nur einen schnellen Takt erzeugen und ein 
CNV_EN vom FPGA jitterbefreien und den schnellen Takt über den Isolator 
in das FPGA füttern. Das braucht 2 Isolierte Verbindungen.
oder
b) im isolierten Bereich mit einem schnellen Zähler und ein paar 
Logikgattern gleich selber CNV_EN und SCK erzeugen. Dann müssten nur 
noch DCO (also das SCK Echo und die Daten) zum FPGA gehen.

3. Es gibt auch FFs mit LVDS Eingängen und Ausgängen. Siehe 
https://www.onsemi.com/pub/Collateral/NB7V52M-D.PDF
Macht es Sinn ein solches zu verwenden in Kombination mit einer LVDS 
Taktquelle? Dann wäre alles LVDS und ich bräuchte keine Wandler 
dazwischen. Ausser eben wenn ich mit einem schnellen Zähler gleich 
CNV_EN und SCK erzeuge. Damals hatte ich den Zähler verwendet, der geht 
bis 140 MHz.
https://www.onsemi.com/pub/Collateral/MC74AC4040-D.PDF

Jetzt würde ich wieder diesen Zähler und als Takt ... naja, ich könnte 
100 MHz nehmen. Dann mit einem Zähler bis 7 Zählen, gibt 14,29 MHz für 
CNV. Wäre OK für mich. Und die einzelnen Pulse von 100 MHz sind < 5,6295 
ns lang, passt also auch. Oder etwas teurer aber noch genauer ein
ABLNO-104.000MHz .

Aber gut, dann wird mir wieder Overengeneering vorgeworfen^^ meine 
einfachste Lösung, also SCK und CNV beides aus dem FPGA über die eher 
schlechten (was Jitter betrifft) Si866x zum ADC funktioniert und ist gut 
genug für das was ich damit messe. Das könnte ich also 1:1 nachbauen. 
Ich will aber eben auch was lernen und besser machen - ob es das braucht 
oder nicht, nennt sich Hobby.

[Duke Scarring (Gast)]

Den ADC-Eingang zu isolieren ist wohl keine Option?
(Sorry, wenn das schon vorgeschlagen wurde...)

Duke

[Gustl B. (-gb-)]

Wie meinst du? Mit einem Transformator? Das hatte ich schon versucht 
aber 1. ist die Auswahl an Transformatoren sehr groß und ich kenne mich 
nicht aus und 2. waren die Ergebnisse mit Trafo nicht gut. Am besten ist 
meine alte Lösung mit galvanisch getrenntem ADC. Das möchte ich jetzt 
nochmal bauen nur eben mit auf eine andere Platine drauf und mit anderem 
ADC.

[Duke Scarring (Gast)]

Gustl B. schrieb:
> Mit einem Transformator?
Zum Beispiel. Oder mit einem Kondensator.

> Das hatte ich schon versucht
> aber 1. ist die Auswahl an Transformatoren sehr groß und ich kenne mich
> nicht aus und 2. waren die Ergebnisse mit Trafo nicht gut.
1. bedingt vmtl. 2.

Was für Anforderungen an den zu erfassenden Frequenzbereich hast Du 
wirklich?
Ich habe hier einen Trafo (bzw. zwei in Serie) die gehen von 10 MHz bis 
ca. 1.5 GHz. Mit dem 2. Trafo kann man einen DC-Offset einstellen.

Duke

[Gustl B. (-gb-)]

Das ist ein 5 MSample/s ADC, also wenige kHz bis 1 MHz würde mir 
reichen. Aber weil es mal wieder um Impulse aus radioaktivem Zerfall 
geht sollte die Impulshöhe weiterhin erhalten bleiben oder wie soll ich 
sagen, wenn am Eingang ein doppelt so hoher Impuls reinkommt, dann soll 
der am ADC immer noch die doppelte Höhe haben.

Duke Scarring schrieb:
> Oder mit einem Kondensator.

Und wie trenne ich da die Massen? Auch mit Kondensator? Das könnte ich 
natürlich mal probieren.

Wobei das Problem eigentlich so ist, dass die Masse vom Detektor mit dem 
Signal des Detektors beides etwas schwingt im Vergleich zur Masse meiner 
Hardware. Meine Hardware hat über USB eine Verbindung zum Rechner. Wenn 
ich also den ADC galvanisch vom Rest meiner Hardware trenne, dann kann 
die Masse des ADC schön mitschwingen.

[Frickel F. (frickelfritze)]

Moin zusammen :)

Duke Scarring schrieb:
> Einen Nachteil hat der normale Spektrumanalysator: man kann
> Amplitudenmodulation und Phasenmodulation nicht unterschieden, beide
> erzeugen Nebenlinien. Bei besseren Analysatoren gibt es
> Phase-Noise-Measurement-Optionen, die auch gleich den Jitter über einen
> einstellbaren Bereich ausrechnen.
>
> Im Prinzip könnte man auch einen Netzwerkanalysator zur
> Phasenrauschmessung heranziehen. Da braucht man aber noch die passende
> Auswertung dazu (ich meine der VNWA3 hat da was) und das Referenzsignal
> des NWA sollte dazu ein Größenordnung besser sein als das Signal des
> DUT.
>

Ja, richtig. Ich habe mich da auch schon in die eine oder andere dunkle 
Sackgasse verlaufen. Das Problem ist halt mit Amateurmitteln nur schwer 
zu umschiffen, Phasenrauschen messen mit der Vergleichs-Mischermethode 
bekommt man aber sehr gut hin, ist aber auch schon ein Riesen Tam Tam.

Betonung liegt aber beim "Vergleichen". Ja klar, ich habe einige 
Referenzen gegen die ich antreten kann, aber eben nur gegen diese. Von 
daher ist das nur sehr bedingt brauchbar, also letztendlich war der 
ganze hocus pocus nur ein Erkenntnisgewinn.

Für so einen Agilent E5052a oder Co. fehlen mir leider irgendwie die 
nötigen Taler und selbst wenn, dann dürfte mir der Waf einen deutlichen 
Strich durch die Rechnung machen. :D

> Phasenrauschmessung von FPGA-Ausgängen steht auf meiner TODO-Liste
> relativ weit hinten, da ich in kritischen Fällen auch einfach ein
> externes Flip-Flop spendiere...
>
> Duke

Mich würde das wirklich extrem interessieren das da mal jemand mit den 
nötigen Messmittel drauf schaut. Was ist Dein bevorzugtes FF und 
spendierst Du diesem dann einen Extra LDO? Ich hatte jetzt noch mal, 
rein aus Interesse, das FF saubere 3,3V verpasst und es ging noch mal 
1-2db runter.

@Gustl, so langsam bin ich auch schon am grübeln was ich mit so einem 
ADC + FPGA anstellen kann. :)

Ich fange mal von hinten an...

Gustl B. schrieb:
> Ich will aber eben auch was lernen und besser machen - ob es das braucht
> oder nicht, nennt sich Hobby.

Genau so sehe ich das auch! Obwohl das meine bessere Hälfte irgendwie 
"etwas" anders sieht, Tis... :D

Gustl B. schrieb:
> Frickel F. schrieb:
>> Falls noch jemand Vorschläge hat wie man die Messungen verbessern
>> könnte...?
>
> Mir wurde damals empfohlen mit dem Oszi auf eine Flanke zu triggern und
> mir dann eine weit entfernte Flanke anzugucken die z. B. 10 us oder 1 ms
> später kommt. Dann sehe ich wie stark der Jitter im Durchschnitt über
> diese Zeit ist. Klar, wenn das gaußförmig verteilt ist, dann mittelt
> sich das weg. Da sollte man dann lieber auf eine Flanke triggern und
> sich die nächste Flanke angucken.

Ja, richtig, macht bei mir aber mit 100Mhz/1Gs China-Scope keinen Sinn, 
zumindest nicht um in die Regionen vorzudringen die von Interesse wären. 
Da bin ich mit dem Specki der ganzen Sache schon deutlich näher.

Gustl B. schrieb:
> 1. Der ADC braucht 5 V, geht aber Laut Datenblatt von 4,75 V bis 5.25 V.
> Mein isolierter DCDC liefert 5 V. Die werden gefiltert, aber ist es
> sinnvoll da noch einen LDO vor den ADC zu setzen, z. B. einen TPS736 mit
> "Ultra-Low Dropout Voltage:75 mV typ" laut dessen Datenblatt den ich
> dann auf 4,85 V oder so einstellen würde?
>
Würde ich auf jeden Fall machen! Alles was Analog rund um ADC hängt 
würde bei mir eine eigene saubere Versorgung bekommen, das Rauschen von 
Schaltreglern bekommt man mit ein paar Filter nicht wirklich so sauber 
hin und was man auch auf dem ersten Blick vernachlässigt, ist das 
Rauschen in den unteren Frequenzen die noch mal deutlich schwerer zu 
Filtern sind aber mitunter mehr Probleme verursachen.

Schau Dir mal bei Deinem verlinkten Demo-Board die Versorgung an, so in 
der Richtung würde ich das auch angehen.
https://www.analog.com/media/en/technical-documentation/eval-board-schematic/DC2395ASCH.PDF

Ich habe mir auch schon sehr lange abgewöhnt in "einfachen" Versorgungen 
aus Datenblätter zu Denken, so von wegen 100n dran klatschen und gut 
iss. Das mag gut sein wen man dieses "eine" Bauteil beurteilen will und 
mit einem guten Lab-Nt versorgt, aber das ist weit weit weg von der 
Realität. Sieht man ja auch immer wieder in den Demo-Boards der 
Hersteller das die Aufwand betreiben und selbst das kann man nur als 
Anhaltspunkt nehmen.

Wie oben schon gepinselt, saubere Spannungen sind bei ADCs oder 
HF-Geraffel das a und o.

Zu den anderen fragen, Lass mich vorher bitte mal meine Gedanken los 
werden wie ich das insgesamt angehen würde.

- Trennen würde ich entweder alles, also die gesamte(n) Baugruppe(n), 
oder auf der Analogen Seite.

- Die Messeingänge würde ich Symmetrisch auslegen.

- Alles was Takte & Co. sind, schön "frei" verlegen, auch bei LVDS.

- Stromversorgung wie schon geschrieben.

- Auf jeden Fall Schirmung im Analogen Bereich.

- Referenzspannung wäre auch noch so eine Sache, es geht zwar nicht um 
genaue DC Messungen, aber schaden würde es auf keinen Fall da ein Auge 
drauf zu haben, die internen Referenzen sind meist nicht so dolle.

- Die Schaltung und das Layout insgesamt, würde ich flexibel auslegen, 
so das man mehrere Versionen gegeneinander vergleichen kann ohne noch 
mal ganz von vorne anzufangen.


Gustl B. schrieb:
> 2. Ich benötige ein sauberes CNV mit 15 MHz. Dann habe ich 66.6... ns
> Zeit je Wandlung und davon 50,6... ns zum Auslesen der Daten mit SCK.
> SCK muss während dieser Zeit im Two-Lane-Mode 5 Pulse haben und
> dazwischen 4 Täler. Damit muss ein Puls also 50,6... ns/9 = 5,6295 ns
> lang sein. Maximal. Kürzer ist erlaubt bis minimal 2,5 ns.
> Die Frage ist jetzt:
> Sollte ich
> a) im isolierten Bereich nur einen schnellen Takt erzeugen und ein
> CNV_EN vom FPGA jitterbefreien und den schnellen Takt über den Isolator
> in das FPGA füttern. Das braucht 2 Isolierte Verbindungen.
> oder
> b) im isolierten Bereich mit einem schnellen Zähler und ein paar
> Logikgattern gleich selber CNV_EN und SCK erzeugen. Dann müssten nur
> noch DCO (also das SCK Echo und die Daten) zum FPGA gehen.

A Wäre mein erster Gedanke, ist man deutlich flexibler, oder?

> 3. Es gibt auch FFs mit LVDS Eingängen und Ausgängen. Siehe
> https://www.onsemi.com/pub/Collateral/NB7V52M-D.PDF
> Macht es Sinn ein solches zu verwenden in Kombination mit einer LVDS
> Taktquelle? Dann wäre alles LVDS und ich bräuchte keine Wandler
> dazwischen. Ausser eben wenn ich mit einem schnellen Zähler gleich
> CNV_EN und SCK erzeuge. Damals hatte ich den Zähler verwendet, der geht
> bis 140 MHz.
> https://www.onsemi.com/pub/Collateral/MC74AC4040-D.PDF

Das LVDS-FF ist ja nen Biest, alter Schwede, krass!!!

Ja, klar, das LVDS-FF wenn eh schon LVDS an allen ecken vorhanden ist. 
Ich würde auch einfach mal behaupten das die max. 0,8psRMS Jitter mit 
einem 0815 FF wie ich das verwendet habe da nicht mal ansatzweise ran 
kommt.


Zu dem Trafo Thema... Ich selber habe in deinem Bereich und ADCs noch 
nichts gefrickelt, aber HF-mäßig ist das Gang und gebe, da kommt man um 
Trafos praktisch nicht drum rum. Musst halt nur auf Terminierung achten 
und die 6dbm die verloren gehen, die kann man ja im Analogen teil wieder 
um 6dbm verstärken. Die 5Mhz sind ja eigentlich Gleichstrom. :)

Zu dem Masse Problem, entweder Trafo, oder Differenzial, oder noch 
besser beides. Ich weiß jetzt nicht was deine Signalquellen hergeben, 
aber wen es eh ein Laboraufbau ist... da ist man doch flexibel? :D

Gruß

[Duke Scarring (Gast)]

Frickel F. schrieb:
> letztendlich war der
> ganze hocus pocus nur ein Erkenntnisgewinn.
Nunja, ich veranstalte einige Dinge nur um neue Erkenntnisse zu 
gewinnen...

Frickel F. schrieb:
> Was ist Dein bevorzugtes FF und
Z.B. NC7SV74 oder MC100EP52 für differentielle Sachen.

> spendierst Du diesem dann einen Extra LDO?
> Ich hatte jetzt noch mal,
> rein aus Interesse, das FF saubere 3,3V verpasst und es ging noch mal
> 1-2db runter.
Filter und rauscharme Spannungsregler sind immer eine gute Idee, wenn es 
auf wenig Rauschen ankommt.

Nur das Rauschen zu messen ist dann wieder nicht so trivial.


Gustl B. schrieb:
> Das ist ein 5 MSample/s ADC, also wenige kHz bis 1 MHz würde mir
> reichen. Aber weil es mal wieder um Impulse aus radioaktivem Zerfall
> geht sollte die Impulshöhe weiterhin erhalten bleiben oder wie soll ich
> sagen, wenn am Eingang ein doppelt so hoher Impuls reinkommt, dann soll
> der am ADC immer noch die doppelte Höhe haben.
Die schnellen Anstiege bleiben bei einer kapazitiven Kopplung mehr oder 
weniger erhalten. Normalerweise ist da ja auch schon ein Kondensator im 
Geschäft, um die Hochspannung vom Strahlendetektor fernzuhalten.
Nach oben hin begrenzt üblicherweise der Detektor die Frequenzen...

Duke

[Gustl B. (-gb-)]

Frickel F. schrieb:
> Würde ich auf jeden Fall machen! Alles was Analog rund um ADC hängt
> würde bei mir eine eigene saubere Versorgung bekommen, das Rauschen von
> Schaltreglern bekommt man mit ein paar Filter nicht wirklich so sauber
> hin und was man auch auf dem ersten Blick vernachlässigt, ist das
> Rauschen in den unteren Frequenzen die noch mal deutlich schwerer zu
> Filtern sind aber mitunter mehr Probleme verursachen.
>
> Schau Dir mal bei Deinem verlinkten Demo-Board die Versorgung an, so in
> der Richtung würde ich das auch angehen.

Nun, so Demoboards sind ja toll, aber leider steht da nicht dabei welche 
Masßnahme was gebracht hat. Ich habe hier schon mehrfach einen LTC2325 
mit den 5V aus dem DCDC versorgt. Klar, mehrfach gefiltert, viel Ferrit, 
und das war gut. Zumindest konnte ich grob die Werte aus dem Datenblatt 
erreichen.

Frickel F. schrieb:
> Ich habe mir auch schon sehr lange abgewöhnt in "einfachen" Versorgungen
> aus Datenblätter zu Denken, so von wegen 100n dran klatschen und gut
> iss. Das mag gut sein wen man dieses "eine" Bauteil beurteilen will und
> mit einem guten Lab-Nt versorgt, aber das ist weit weit weg von der
> Realität. Sieht man ja auch immer wieder in den Demo-Boards der
> Hersteller das die Aufwand betreiben und selbst das kann man nur als
> Anhaltspunkt nehmen.
>
> Wie oben schon gepinselt, saubere Spannungen sind bei ADCs oder
> HF-Geraffel das a und o.

Das ist mir klar.

Frickel F. schrieb:
> Zu den anderen fragen, Lass mich vorher bitte mal meine Gedanken los
> werden wie ich das insgesamt angehen würde.

Ist mir auch klar.

Frickel F. schrieb:
> Zu dem Trafo Thema... Ich selber habe in deinem Bereich und ADCs noch
> nichts gefrickelt, aber HF-mäßig ist das Gang und gebe, da kommt man um
> Trafos praktisch nicht drum rum.

Naja, Trafo nimmt man wenn einen DC nicht interessiert oder es 
galvanisch getrennt sein soll. Ist aber wohl nicht so toll wie eine DC 
Kopplung was die Signalqualität angeht.

Duke Scarring schrieb:
> Nur das Rauschen zu messen ist dann wieder nicht so trivial.

Stimmt.

Duke Scarring schrieb:
> Die schnellen Anstiege bleiben bei einer kapazitiven Kopplung mehr oder
> weniger erhalten. Normalerweise ist da ja auch schon ein Kondensator im
> Geschäft, um die Hochspannung vom Strahlendetektor fernzuhalten.
> Nach oben hin begrenzt üblicherweise der Detektor die Frequenzen...

Müsste ich mal testen. Ja, bei AC Kopplung mit Kondensator geht das 
Signal schön durch, stimmt. Aber was mache ich mit der Masse vom 
Detektor? Der steht ein paar Meter weg von meiner Hardware und die 
Massen schwingen leicht unterschiedlich. Daher möchte ich einfach meinen 
ADC Teil isolieren dann kann der schön mit der Detektormasse 
mitschwingen.

Zu dem FF:

Wenn ich im isolierten Teil einen schnellen Takt nehme mit FF, dann muss 
der schnelle Takt auch zum FPGA (ausser ich erzeuge mir lokal mit Zähler 
auch noch CNV_EN und SCK). Wenn ich da jetzt LVDS nehme, dann brauche 
ich nicht nur ein LVDS FF sondern auch noch einen IC zur Taktverteilung 
mit LVDS. Das frisst alles Strom und nicht ganz wenig.
Wenn ich das aber als CMOS baue, dann brauche ich statt einem LVDS 
Digitalisolator nur einen für CMOS, das ist schon mal deutlich weniger 
Strom, dann so ein CMOS FF braucht auch fast nix, ... wäre also die 
deutlich sparsamere Lösung. Und auf FPGA Seite häte ich dann ebenfalls 
CMOS, das könnte ich wunderbar in einen Takteingang einer 3,3 V Bank 
füttern.

Und dann braucht das auch noch Platz auf der Platine. Ich muss mich da 
mal entscheiden ...

[Frickel F. (frickelfritze)]

Duke Scarring schrieb:
> Z.B. NC7SV74 oder MC100EP52 für differentielle Sachen.
Ah, Ok, Danke. Ist ja auch so ein super flinkes teil.

Duke Scarring schrieb:
> Nur das Rauschen zu messen ist dann wieder nicht so trivial.
Ja, ist definitiv Sportlich.

Beitrag "Low Noise mit LM723"
Hier hatte ich mit dem Wenzel Verstärker angefangen, jetzt bin ich in 
abgewandelter Form bei diesem gelandet.

https://www.analog.com/media/en/technical-documentation/application-notes/an159fa.pdf

Messungen gehen nur in Keksdose + Akkus und dann auch nur an bestimmten 
Stellen in der Werkstadt.

Gruß

[Gustl B. (-gb-)]

Nur zur Sicherheit:

Wenn ich das FF mit 2,5 V versorge und einen Oszillator mit 2,5 V 
verwende wie den ECS-TXO-2520MV-120-AY-TR, dann brauche ich doch weder 
die AC-Koplung vom Takt noch dieses NOT Gatter. Richtig?

Wobei, ich muss den Takt vom Oszillator ja auch zum FPGA führen. Ich 
dachte da an einen ADuM121N. Kann ich also den Takt direkt sowohl an FF 
als auch an den ADuM anschließen? Ich würde sagen Ja.

Edit:
Männo, oben genannter Oszillator wurde bei Mouser falsch einsortiert ... 
und zwar bei 120 MHz, hat aber laut Datenblatt nur 12 MHz. Na dann such 
ich einen Anderen.

[Christoph Z. (christophz)]

Gustl B. schrieb:
> Müsste ich mal testen. Ja, bei AC Kopplung mit Kondensator geht das
> Signal schön durch, stimmt. Aber was mache ich mit der Masse vom
> Detektor? Der steht ein paar Meter weg von meiner Hardware und die
> Massen schwingen leicht unterschiedlich. Daher möchte ich einfach meinen
> ADC Teil isolieren dann kann der schön mit der Detektormasse
> mitschwingen.

Vielleicht müssten wir diese Diskussion doch zuerst ins Analog Forum 
stellen, bevor wir den Digitalteil diskutieren ;-)

Ich beginne das Gefühl zu haben, das da vor dem ADC noch recht viel 
rauszuholen ist, durch passende Schaltungstechnik, Verkabelung, 
Vorverstärker.

Dazu zwei meiner Quellen die ich weiter empfehlen kann:

Get your signals off ground:
https://linearaudio.net/article-detail/2146

Video zu Balanced-differential Signal Transmission (Titel ist zu Phantom 
Power was nebenbei auch schnell erwähnt wird). Hab ziemlich dazu 
gelernt:
https://www.youtube.com/watch?v=e5xenXTwAzo&list=PLvOlSehNtuHv98KUcud260yJBRQngBKiw&index=6

[Gustl B. (-gb-)]

Christoph Z. schrieb:
> Vielleicht müssten wir diese Diskussion doch zuerst ins Analog Forum
> stellen, bevor wir den Digitalteil diskutieren ;-)

Ja, könnte man natürlich machen und ist bestimmt lehrreich, aber ich 
habe hier schon eine wunderbar funktionierende Lösung. Die möchte ich 
jetzt nur zusammen mit dem FPGA auf eine Platine setzen. Und weil ich da 
gerade dabei bin möchte ich natürlich etwas verbessern wenn das einfach 
möglich ist.

Christoph Z. schrieb:
> Dazu zwei meiner Quellen die ich weiter empfehlen kann:

Vielen Dank!