Hallo! so viel ich gelesen habe soll ich einen ADC ja nicht mit einem Clock aus einem FPGA füttern (wegen jitter). Wenn ich jetzt aber z.B. oversampling mit dem ADC machen möchte? Gibt es da überhaupt eine möglichkeit außer den Clock aus dem FPGA zu nehmen und die Phase zu verschieben?? Gruß, Manuel
@ Manuel (Gast) >so viel ich gelesen habe soll ich einen ADC ja nicht mit einem Clock aus >einem FPGA füttern (wegen jitter). Jain. Das gilt in erster Line nur für sehr schnelle ADCs (100MHz++) und sehr auf Super-duper-HiFi bedachte Audio-ADCs. Der Rest kann durchaus mit einem FPGA Takt gut leben. >Wenn ich jetzt aber z.B. oversampling mit dem ADC machen möchte? Gibt es >da überhaupt eine möglichkeit außer den Clock aus dem FPGA zu nehmen und >die Phase zu verschieben?? Wozu brauchst du eine verschobene Phase bei Oversampling? MFG Falk
Das mit der verschobenen Phase hab ich mir so überlegt: Ich habe ein (sich wiederholendes) Signal. Wenn ich jetzt bei 0, 90, 180, 270 Grad messe, dann sollte sich doch die Bandbreite vervierfachen.
@ Manuel (Gast) >Das mit der verschobenen Phase hab ich mir so überlegt: Ich habe ein >(sich wiederholendes) Signal. Wenn ich jetzt bei 0, 90, 180, 270 Grad >messe, dann sollte sich doch die Bandbreite vervierfachen. Sooo einfach ist es nicht. Und du schriebst was von OVERsampling. Das erhöht keine Bandbreite. MfG Falk
Habe mich wohl etwas umständlich ausgedrück... Was ich machen will ist erstmal folgendes: 2 x ADC 80MS/S ADS831 jeweils mit 80MHZ clock mit 180° Differenz zu samplen. Das sollte dann auch die doppelte Bandbreite der ADCs geben wenn die clocks stimmen. Als nächstes hab ich schon gesehen (was ich auch vorhin schon geschrieben habe) das sich wiederholende Signale zu unterschiedlichen Zeiten gemessen werden und somit das Signal dann berechnet werden kann. Hierüber habe ich mir ehrlich gesagt noch keine weiteren Gedanken gemacht, ist aber z.B. auch bei relativ günstigen Scopes implementiert. Steht die Aussage noch das ich die ADCs vom FPGA clocken kann? Oder wie würde man das machen? Gruß Manuel
@ Manuel (Gast) >2 x ADC 80MS/S ADS831 jeweils mit 80MHZ clock mit 180° Differenz zu >samplen. Das sollte dann auch die doppelte Bandbreite der ADCs geben >wenn die clocks stimmen. Nur wenn die Sample&Hold Stufen dee ADCs schnell genug sind. >Als nächstes hab ich schon gesehen (was ich auch vorhin schon >geschrieben habe) das sich wiederholende Signale zu unterschiedlichen >Zeiten gemessen werden und somit das Signal dann berechnet werden kann. Das ist Repititive Sampling, auch Undersampling oder Time Equivalent Sampling genannt, KEIN Oversampling. >Steht die Aussage noch das ich die ADCs vom FPGA clocken kann? Würde ich sagen. MFG Falk
Wenn man das so machen will muss der ADC eine hoehere analoge Bandbreite besitzen. Der LCT2299 zB hat 80MSample und 575MHz analoge Bandbreite. Dh wenn man den Trigger genau genug bringt erreicht man ein 575MHz Signal mit undersampling zu digitalisieren.
"Wide Analog Input Bandwidth: 700 MHz Typ" sollte also ausreichend sein. Ich bin jetzt noch am recherchieren was es mit der von Falk angegebenen Sample&Hold Problematik auf sich hat. Soweit ich das verstanden habe ist das die Zeit die der ADC die analoge Eingangsspannung während des Konvertiurngsvorganges hält. In wie weit sich das auf mehrere parallel "horchende" ADCs auswirkt ist mir noch nicht klar.
Was Falk vermutlich meit, ist die "Sample-and-Hold Acquisition Delay Time tAP". Ist die Differenz dieser Zeit zwischen den beiden ADCs zu gross, wirst du keine verschiebung 180° erreichen können.
>Ich bin jetzt noch am recherchieren was es mit der von Falk angegebenen >Sample&Hold Problematik auf sich hat. Das wesentliche Element der Sample&Hold Stufe ist doch ein (winziger) Kondensator, der kurzzeitig über einen Schalter an das Signal gelegt wird, und dann diesen Wert für die Digitalisierung zwischenspeichert. Wenn dieses "Laden" des Kondensators relativ lange dauert, bekommt man dadurch eine Mittelung des Signals und kann schnelle Signalveränderungen nicht mehr auflösen.
habe das Datenblatt jetzt mehrfach durchgelesen - leider nichts über die Sample-and-Hold time gefunden. Kann vielleicht mal jemand schauen? Im Datenblatt steht allerdings schon etwas über Daisy-Chain... Und wenn ich schonmal dabei bin dumme Fragen zu stellen :-) Was sind die Auswahlkriterien für den OP? Den im Datenblatt angegebenen hab ich leider nicht bei Reichelt und den üblichen Verdächtigen gefunden. Gruß, Manuel
Die ganzen Timings werden doch Im Timing Diagram angegeben. Die Zeit vom Analogwert abgreifen bis zum digitalen Wert sollte die New Data Delay Time sein.
Nicht vergessen, wenn du mehrere ADC´s verbindest, sollten sie die gleiche Vref haben. Weiters schadet es nicht, den Clock durch z.B. AS Bausteine zu buffern, damit wird jitter eliminiert.
@ Chris None (lamda) >Nicht vergessen, wenn du mehrere ADC´s verbindest, sollten sie die >gleiche Vref haben. Das ist das kleinste aller Probleme. > Weiters schadet es nicht, den Clock durch z.B. AS Bausteine >zu buffern, damit wird jitter eliminiert. ??? MfG Falk
>Weiters schadet es nicht, den Clock durch z.B. AS Bausteine >zu buffern, damit wird jitter eliminiert. Leider ist es wohl eher umgekehrt. Gute CLOCK-Generatoren haben Jitter < 1ps -- wenn man einen ADC mit 12 Bit bei 100 MHz hat sollte der Jitter auch nicht wesentlich schlechter sein. Wenn man den Takt durch einen FPGA oder andere Logik-Bausteine schleust, wird der Jitter in der Regel deutlich größer. Warum eigentlich?
>> Weiters schadet es nicht, den Clock durch z.B. AS Bausteine >>zu buffern, damit wird jitter eliminiert. > > ??? Habe so eine Schaltung mit einem FPGA gemacht, 40Mhz VCXO, unmoduliert bzw mit Sinus für Undersampling moduliert, sowie frequenzverdoppelt ohne DLL. Das FPGA schaffte die 2nS, die der ADC gerne hat, nicht sauber bzw waren vielleicht auch ground bounce usw, bzw gleichzeitiges Schalten von Ausgängen für nicht saubere rise/fall levels verantwortlich. Ein Buffer mit 1.5nS rise/fall time hat da sehr viel gebracht. Bezüglich der T/H Schaltung, welche im Datenblatt abgebildet ist, dürfte ein nicht 50%es duty-cycle was bringen. Wie weit das getrieben werden kann, muß experimentell festgestellt werden, 120 Mhz sind warscheinlich machbar. > > MfG > Falk
Stefan Salewski wrote: >>Weiters schadet es nicht, den Clock durch z.B. AS Bausteine >>zu buffern, damit wird jitter eliminiert. > > Leider ist es wohl eher umgekehrt. > Gute CLOCK-Generatoren haben Jitter < 1ps -- wenn man einen ADC mit 12 > Bit bei 100 MHz hat sollte der Jitter auch nicht wesentlich schlechter > sein. > Wenn man den Takt durch einen FPGA oder andere Logik-Bausteine schleust, > wird der Jitter in der Regel deutlich größer. Warum eigentlich? Sorry, ich meinte die <2nS rise/fall time, die der ADC haben möchte, welche bei überschreiten jitter im internen clock des ADC generiert und zu zu Jitter im S/H sampling führt, was dann letztendlich die Genauigkeit senkt.
>Das FPGA schaffte die 2nS, die der ADC gerne hat
Was soll das aussagen?
2 Nanosekunden Jitter? Das wäre für mich ein völlig unbrauchbarer Takt?
Wer als Einheit für Sekunde mehrfach ein großen S verwendet, ist eh
nicht sonderlich glaubwürdig.
>Sorry, ich meinte die <2nS rise/fall time, die der ADC haben möchte, >welche >bei überschreiten jitter im internen clock des ADC generiert und zu zu >Jitter im S/H sampling führt, was dann letztendlich die Genauigkeit >senkt. Ok, rise/fall time ist ein ganz anderes Thema. Es ging um Clock-Jitter.
Eine Langsame rise/fall time erzeugt Jitter durch das Rauschen der Komperatorschwelle des Takteinganges. Mfg Michael
>Eine Langsame rise/fall time erzeugt Jitter durch das Rauschen der >Komperatorschwelle des Takteinganges. >Mfg Michael Ah ja -- ein weiterer Punkt den man bedenken muss.
>Was wäre denn ein guter Clock Generator?
Ich hatte mir vorläufig den hier ausgesucht -- kostet bei Digi-Key aber
ca. 20 Euro, Datenblatt findet man auch über Digi-Key:
Oszillator 100 MHz, low jitter:
OSC 100.0000MHZ 3.3V LVPECL SMD (Digikey CW590-ND)
Nur so als Anhaltspunkt...
Ach ja, wenn die Frequenz einstellbar sein soll gibt es Bausteine wie AD9540 Damit habe ich mich aber noch nicht näher beschäftigt.
>Das ist ja nicht gerade günstig für low.jitter schon...die meisten kosten 30eu +++ >Wann ist eigentlich eine PLL zu bevorzugen? für variablen takt, dann kannst du gleich ne pll bzw dll im fpga nehmen.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.