Hallo, ich werde bald mal einen 16 Bit 1 MSample/s ADC verbauen/layouten. Den möchte ich natürlich testen. Dafür habe ich zur Verfügung den Signalgenerator im Oszi und der ist naja, nicht so sonderlich. Dann habe ich an einem FPGA 14 Bit 125 MHz DACs, da könnte ich selber mit DDFS einen Sinus ausgeben, aber auch der rauscht dann deutlich mehr als ich möchte. Gibt es irgendwo günstig zu kaufen oder selber aufbaubar eine Hardware/Schaltung die einen sehr sauberen Sinus erzeugt? Als Frequenz wäre irgendwas aus dem Bereich 50 bis 200 kHz ganz brauchbar.
:
Bearbeitet durch User
Vielen Dank, ist abgespeichert. Ich würde aber irgendwie doch lieber was kaufen. Einfach weil ich dann weiß, dass es gut ist. Wenn ich das selber aufbaue und dann den ADC teste, wie soll ich feststellen ob meine Quelle oder das ADC-Layout schlecht ist?
Gustl B. schrieb: > Dann habe ich an einem FPGA 14 Bit 125 MHz DACs, Rauscht er analog oder sind das die Quantisierungen die Du meinst?
Gute Frage, Quantisierungsrauschen ist ja bei DDFS immer dabei, aber auch analog rauscht der vermutlich. Ich hab das vor längerer Zeit einmal getestet und da war das Rauschen recht hoch, weiß aber nix genaues mehr. Aber wäre denn ein 14 Bit DAC überhaupt geeignet einen 16 Bit ADC zu testen?
Ein einfacher Quarzoszillator duerfte beim Rauschen jeden DDS-Chip in den Schatten stellen. 100kHz Quarze gibts auf Ebay (die ganz grossen). Kaufen kann man natuerlich alles - aber eher nicht billig.
Gustl B. schrieb: > irgendwas aus dem Bereich wäre 50 bis 200 kHz ganz brauchbar. Wie wärs denn mit 77,5 kHz?
Wenn es rauschfrei ist. Also mir geht es nicht drum, dass die Frequenz nicht driftet oder so, sondern dass das Rauschen sehr leise ist.
Ja, also einen einfachen rauscharmen Oszillator aus der Empfaengertechnik. Natuerich geht auch ein normaler Schwingkreis. Ein Quarzoszillator hat demgegenueber ein sehr viel geringeres Phasenrauschen, denke ich. Beides ist einfacher und besser als DDS.
Gustl B. schrieb: > Ich würde aber irgendwie doch lieber was > kaufen. Einfach weil ich dann weiß, dass es gut ist. Dann schau mal hier: http://www.helmut-singer.de/stock/x26.html und wähle links Hewlett Packard 3325B Ist sicher mehr als du erträumen kannst. Georg
vorticon schrieb: > Phasenrauschen, denke ich. Beides ist einfacher und besser als DDS. DDS nimmt man nur, bei VERÄNDERLICHEN Frequenzen.
Dass DDFS nicht geeignet ist ist mir auch klar, ich suche auch keine veränderliche Frequenz. Ok, scheint also nicht so einfach zu sein, da werde ich die Tage mal an der Uni nachfragen was die so dahaben ... Der HP http://www.helmut-singer.de/pdf/hp3325b.pdf ist schon nicht schlecht, aber nun, etwas teuer und hat auch nicht das Rauschverhalten das ich suche. Ich hätte gerne sowas http://www.ti.com/tool/tsw2110evm, nur in etwas besser und mit niedrigerer Frequenz.
Für 150 Öhre kannst du es auch mal mit einer EMU0202 probieren. Die hätte dann auch noch weitere Anwendungsmöglichkeiten.
Gustl B. schrieb: > Hallo, ich werde bald mal einen 16 Bit 1 MSample/s ADC > verbauen/layouten. Den möchte ich natürlich testen. Hast du schon dran gedacht dass die Qualität deines ADC auch davon abhängt wie gut der Takt ist mit dem den Wandler speist (ich meine den Referenztakt, nicht das zu messende Objekt)? Sonst hilft das beste Layout nix.... Also die Methode "billiger Digital-Oszillator" funktioniert hier zum Speisen womöglich nicht. Eventuell wird dein Wandler deutlich schechter ausfallen als die Quelle die zu zu vermessen gedenkst. Gustl B. schrieb: > Gibt es irgendwo günstig zu kaufen oder selber aufbaubar eine > Hardware/Schaltung die einen sehr sauberen Sinus erzeugt? Die meisten stabilen Referenzoszillatoren sind meist keine sauberen Sinusquellen. Wenn du das haben willst musst du noch tiefpass-filtern. Ich würde einen QUarzoszillator "guter Qualität" und niedriger Frequenz nehmen und diesen auf die gewünschte Frequenz herunterteilen und filtern. vorticon schrieb: > Ein > Quarzoszillator hat demgegenueber ein sehr viel geringeres > Phasenrauschen, Yes.
Ähm ich suche die Sinusquelle NICHT um damit den ADC zu takten. Das wird ein Wandler mit SPI-Anschluss, da taktet man sowieso nur die Daten raus (grob gesagt). Arduinoquäler schrieb: > Sonst hilft das beste Layout nix.... > Also die Methode "billiger Digital-Oszillator" funktioniert > hier zum Speisen womöglich nicht. Ich will doch gerade mein Layout überprüfen. Und wie sollte ich das anders machen als eine sehr saubere Sinusquelle mit dem ADC-Eingang verbinden und dann das Spektrum messen. Es geht mir hier nicht um das Layout oder wie ich den ADC bespaße, sondern darum wie ich ein fertiges Layout teste. Dazu kann ich natürlich selber eine Quelle aufbauen, aber wenn das Ergebnis nicht wie gewünscht ist weiß ich nicht ob der Fehler an meiner Quelle oder meinem ADC-Layout liegt. Aber gut, es gibt wohl nicht Günstiges Einfaches mit dem man einen ADC mit etwas mehr Bits testen kann. @ Abdul K.: Du meinst so ein USB-Audio-Teil? Davon habe ich selber ein paar ganz brauchbare ... naja kann man mal ausprobieren.
:
Bearbeitet durch User
Gustl B. schrieb: > Ähm ich suche die Sinusquelle NICHT um damit den ADC zu takten. Das wird > ein Wandler mit SPI-Anschluss, da taktet man sowieso nur die Daten raus > (grob gesagt). Ähm .... wenn du mal den Wandler nennen würdest könnten wir ja mal drüber diskutieren ob du einen guten Referenztakt brauchst oder nicht. Was ein Referenztakt ist hast du offensichtlich noch nicht verstanden.
Das ist ein normaler ADC mit SPI Interface, ja der hat auch eine Sampleclock (CNV Eingang am Chip). Aber ich habe schon das Referenzlayout gesehen und da kommt die auch nur aus einem CPLD. Ich werde die Clock in einem FPGA erzeugen. Mir geht es jetzt auch garnicht um irgendwelche Vorschläge wie ich den ADC anschließe oder layoute, sondern nur um die Frage wie ich das dann teste. Also generell, klar hab ich schon einen ADC ausgesucht, aber das ist noch unklar ob ich den tatsächlich verbauen werde. In einem anderen Thread habe ich einen 12 Bit 65 MSample/s AD9235 getestet mit dem hier verlinkten Board von TI. Für einen 16 Bit ADC mit niedrigerer Samplerate kann ich das aber leider nichtmehr verwenden und bin auf der Suche nach Alternativen.
:
Bearbeitet durch User
Vergiss es den Referenztakt eines ADC mit einem FPFA zu erzeugen. Der ADC is nur so gut wie der Referenztakt. Da kannst du als Signalquelle auch gleich einen 555 nehmen und messen was mit einem Wuerfel auch rauskommen wuerde.
Joggel schrieb: > Vergiss es den Referenztakt eines ADC mit einem FPFA zu erzeugen. > > Der ADC is nur so gut wie der Referenztakt. > > Da kannst du als Signalquelle auch gleich einen 555 nehmen und messen > was mit einem Wuerfel auch rauskommen wuerde. Danke Joggel, gut dass das in anderer Färbung von einem zweiten Leser kommt. Jetzt fällt mir nur noch das ein: ... denn sie wissen nicht was sie tun.
Joggel schrieb: > Vergiss es den Referenztakt eines ADC mit einem FPFA zu erzeugen. Also nochmal: Das wird im Referenzlayout auch gemacht. Und ausserdem: Mir geht es darum wie ich den ADC teste, nicht drum wie ich den anschließe oder layoute. Bei dem AD9235 den ich schon verwende kommt der Takt auch aus einem FPGA und ich bin zufrieden. Aber wie gesagt, darum geht es hier nicht.
Naja, dann kann ja nichts schiefgehen. Mach mal. Zeig uns die Werte und wir sehen weiter.
Lol anscheinend hast Du immernoch nicht meine Fragestellung im Thread verstanden. Welche Werte? Mit was soll ich das testen? Wenn ich den an den Signalgenerator vom Oszi hänge ist das Rauschen bei -60 dB und ihr werdet mich auslachen. Meine Frage war ja exakt wie ich das teste, mit welcher Quelle. Aber gut. Hier ist sogar ein 18 Bit ADC bei dem der Takt im Demoboard aus einem CPLD kommt: http://www.linear.com/product/LTC2338-18 und hier das Datenblatt zum Demoboard mit Schaltplan: http://cds.linear.com/docs/en/demo-board-manual/DC1908AF.PDF Wieso sollte das bei mir nicht funktionieren wenn es beim Hersteller passt?
Gustl B. schrieb: > Wieso sollte das bei mir nicht funktionieren wenn es beim Hersteller > passt? Weil der Takt nicht aus dem FPGA kommt sondern von einem Referenzoszillator dessen Takt im FPGA verwendet wird und auch zum ADC weitergeleitet wird. Daher kommt der Takt nicht aus dem FPGA. Auch wenn's so aussieht. Sobald du mit irgendeiner PLL im FPGA eine neue Frequenz erzeugt ist diese hundsmiserabel verjittert und taugt für einen ADC nicht mehr.
Das glaubst Du doch selber nicht. Wo ist denn dieser Referenzoszillator im Schaltplan? So wie ich das sehe kommt ein schneller Takt ins CPLD rein und geht eben NICHT direkt wieder raus. Denn raus kommt ein 1 MHz Takt (maximal) für den CNV Eingang am ADC. Die SCK ist schnell, aber das ist nur die Clock für das SPI Interface, da ist Jitter egal.
Gustl B. schrieb: > So wie ich das sehe kommt ein schneller Takt ins CPLD rein ... und der muss ja irgendwo herkommen ... auch wenn "der Oszillator" nicht auf dem Board ist. Und du meinst also das CPLD erzeugt für sich alleine eine Frequenz von 1 MHz? Dir ist wirklich nicht zu helfen, du musst es offensichtlich auf die harte Tour selbst erfahren.
Arduinoquäler schrieb: > Dir ist wirklich nicht zu helfen, du musst es offensichtlich > auf die harte Tour selbst erfahren. Ja das werde ich sowieso und suche in diesem Thread nach einem Referenzsignal mit dem ich den ADC dann testen kann. Arduinoquäler schrieb: > und der muss ja irgendwo herkommen Klar, kommt er auch, aber wo? Ich kann den nicht finden, helf mir doch den zu finden. Im Schaltplan geht der schnelle Takt auf über BNC auf das Board und da sowohl in CPLD als auch in ein D-FF. Aus diesem kommt dann das Signal für den CNV Eingang am ADC. Also generiert das CPLD ein Signal das zusammen mit der schnellen Clock das CNV Signal aus dem FF erzeugt. Während bei dem LTC im Datenblatt noch was von celan and low Jitter für die CNV Clock steht, finde ich bei einem anderen ADC gar nix dazu http://www.ti.com/lit/ds/symlink/ads8681.pdf Gut kann wichtig sein oder auch nicht, ist mir aber erstmal egal, hier im Thread hatte ich was anderes gefragt.
:
Bearbeitet durch User
Gustl B. schrieb: > Klar, kommt er auch, aber wo? Du als Benutzer speist den Takt ein, du als Benutzer bist dafür verantworlich dass der ADC das bekommt was er braucht bzw was du an Performance von ihm erwartest. Die Hersteller die solche Eval Boards anbieten bauen bewusst keine Oszillatoren drauf da diese wegen kleiner Bauart evtl schlecht sind oder weil sie keine teueren Oszillatoren draufbauen wollen. Gustl B. schrieb: > Also generiert das CPLD ein > Signal das zusammen mit der schnellen Clock das CNV Signal aus dem FF > erzeugt. Ja aber nicht per PLL in einem FPGA sondern durch Herunterteilen, das verschlechtert die Signaleigenschaften nur unwesentlich (ab- hängig von den Rauscheigenschaften des CPLD). Das ist was ganz anderes als wenn ich einen Takt aus einem FPGA generiere.
Arduinoquäler schrieb: > Du als Benutzer speist den Takt ein Und wo? Da auch dem Demoboard ist nur ein Takteingang für den schnellen Takt. Arduinoquäler schrieb: > Ja aber nicht per PLL in einem FPGA sondern durch Herunterteilen, Das kann man auch in einem FPGA herunterteilen ohne PLL, aber ich vermute das hat dann eher mehr Jitter weil das Signal dann nichtmehr über die extra dafür optimierten Taktnetzwerke im FPGA geroutet wird.
>Das kann man auch in einem FPGA herunterteilen ohne PLL, aber ich vermute das hat dann eher mehr Jitter weil das Signal dann nichtmehr über die extra dafür optimierten Taktnetzwerke im FPGA geroutet wird. Du hast einige Details nicht richtig verstanden. Das Clocknetzwerk in einem FPGA stellt den Takt global zur Verfuegung. Dies ist speziell so ausgelegt weill das ganze (oder Teile davon) Netzwerk synchron laeuft. Wenn ich aber nur ein Taktsignal runterteilen will benoetige ich ein paar Flip-flops. Man kann deren Ausgang immer noch auf das Taktnetzwerk legen, wenn man ihn denn intern benoetigt. Herunterteilen ist extrem jitterarm, solange man unterhalb der Grenzfrequenz bleibt.
Ok, klingt vernünftig, die FFs haben eben immer die gleiche Laufzeit. Aber das mit dem Runterteilen kann ich ja auch in meinem FPGA machen, also wo ist damit das Problem? Mir geht es hier weiterhin nicht drum wie ich den ADC anspreche oder layoute sondern wie ich das teste. Da weiß ich bisher nur, dass das schwer ist und vermutlich teuer wenn man das fertig kaufen möchte.
Gustl B. schrieb: > Vielen Dank, ist abgespeichert. Ich würde aber irgendwie doch lieber was > kaufen. Einfach weil ich dann weiß, dass es gut ist. Wenn ich das selber > aufbaue und dann den ADC teste, wie soll ich feststellen ob meine Quelle > oder das ADC-Layout schlecht ist? Hallo, auch wenn Du lieber etwas fertiges kaufen möchtest, hier noch ein Link: http://www.edn.com/design/analog/4400342/Injection-lock-a-Wien-bridge-oscillator http://m.eet.com/media/1173490/injection-lock%20a%20wien-bridge%20oscillator.pdf
Sieht interessant aus, aber ich finde keinen "Kaufen" Button :-) Naja noch bin ich in der Planungsphase und hab noch keinen ADC.
Joggel schrieb: > Herunterteilen ist extrem jitterarm, solange man unterhalb der > Grenzfrequenz bleibt. Das würde ich etwas anders darstellen: Das Runterteilen selber bringt gar keinen Jitter - unterstellt man, dass die Ausgänge getaktet sind. Dann zählt in erste Linie der Takt. Darüber hinaus gibt es ein -YSSO PRoblem, von daher käme es bei DDS auf den Wandler an. Wenn man das richtig anfangt, ist der Jitter der DDS letzlich völlig anabhängig von den PLLs im FPGA, was anzustreben ist. Aber mal was anderes: Warum nicht einfach einen "digital loop back" und die gerade ausgebenen Werte zurücklesen? Wenn Du beides synchronisierst, müsstest Du ohne DDS die bits direkt zurücklesen können. Darf hat kein Reko Filter im DAC aktiv sein.
Moin, ich suche immer noch. Aber ich bin auch bereit etwas zu basteln. Hier wurden schon Quarzoszillatoren empfohlen, aber wie gut sind die? Meine Signalgeneratoren haben die Obertöne bei -60 dB, ich hätte aber gerne eine Quelle bei der die noch viel weiter unten liegen. Das Rauschen vom 16 Bit ADC liegt unter -100 dB. Vielleicht ist aber auch mein Vorgehen komplett falsch. Wie testet man solche ADCs samt Eingangsbeschaltung?
Moin, Gustl B. schrieb: > Meine > Signalgeneratoren haben die Obertöne bei -60 dB, Dann bau' halt noch ein LC-Tiefpass/Bandsperre fuer den ersten Oberton hinter deinen Generator. Sowas kann man doch prima in eine Blechdose mit den entsprechenden Buchsen reinloeten. Gruss WK
Danke, daran hatte ich nicht gedacht. Gibt es so Filter zu kaufen? Gerne gleich als Set mit unterschiedlichen Grenzfrequenzen ... 100 kHz, 1 MHz, 2 MHz, ... mit SMA an beiden Enden.
Gustl B. schrieb: > Ähm ich suche die Sinusquelle NICHT um damit den ADC zu takten. Das wird > ein Wandler mit SPI-Anschluss, da taktet man sowieso nur die Daten raus > (grob gesagt). Wenn du den ADC vernünftig testen willst, brauchst du aber einen sauberen Takt für die Abtastung deines Referenzsignals. Sonst versaut dir der Abtastjitter die effektive Bit-Zahl, d.h. die 16 Bit kannst du vergessen.
Genau, das habe ich mittlerweile gelernt. 16 rauschfreie Bits erreiche ich mit dem ADC um den es geht LTC2325 https://www.analog.com/media/en/technical-documentation/data-sheets/232516fa.pdf sowieso nicht. Ich bin auch zufrieden mit dem Resultat, aber ich würde das gerne mal richtig angehen und nicht nur auf Verdacht Bauteilwerte ändern. Ich habe die Schaltung in Multisim, da kann ich mir Frequenzverhalten und so schön angucken, aber in der Realität sieht es eben anders aus. Bei einem 10 kHz Signal am Eingang liegen die Obertöne noch bei kleiner -80 dB. Aber vor allem so ab 200 kHz wachsen diese sehr deutlich an so dass der Abstand zwischen gewünschtem Signal und Obertönen deutlich kleiner wird. Wenn ich mir das Diagramm Harmonic Distortion vs. Frequency, G = +1 angucke, dann ist da alles bis 1 MHz unter -80 dB. Das ist allerdings nur der ADA4897 https://www.analog.com/media/en/technical-documentation/data-sheets/ada4896-2_4897-1_4897-2.pdf den ich als Impedanzwandler direkt am Eingang habe. Dahinter folgt ein LTC6363 https://www.analog.com/media/en/technical-documentation/data-sheets/LTC6363.pdf und der hat im Harmonic Distortion vs Frequency Diagramm ... nun ja, das Diagramm endet bei 100 kHz und da geht es steil nach oben. Ich vermute jetzt also, dass das an diesem Stein liegt. Aber so ganz verstehe ich das nicht, der ist ja schnell (500MHz Gain-Bandwidth Productn und 35MHz –3dB Bandwidth) und wird als "20-Bit, 18-Bit and 16-Bit SAR ADC Drivers" beworben. Verzerrt aber schon bei 100 kHz deutlich. Welchen OPV sollte ich dann verwenden wenn ich bis zur halben Samplerate, also bis 2,5 MHz, nur geringe Verzerrung haben will? Muss der dann noch sehr viel schneller sein? Für mich ist dieser große Zoo aus OPVs recht undurchsichtig.
Der Verstärker sollte schon schnell sein. Bei den OPs wird die GBW angegeben, d.h. das Produkt auf Frequenz und open loop gain. Für eine geringe Verzerrung will man (bzw. braucht man) eine deutliche loop Verstärkung, um damit die nichtlinearitäten des Verstärkers ohne Rückkopplung zu unterdrücken. Stark vereinfacht werden die Harmonischen um die noch vorhandene Loop Verstäkung gedämpft. Viel Verstärkung auch bei 1 MHz heißt dann halt eine hohe GBW, ggf. bis in den GHz Bereich. Ich würde so etwas wie THS4521 oder THS4541 in Betracht ziehen. In der Regel hat man auch nicht die volle Amplitude nahe der Nyquist-grenze. D.h. ganz so dramatisch ist das mit den Verzerrungen bei hohen Frequenzen nicht. Bei viel Amplitude bei hoher Frequenz wird dann auch der Takt Jitter sehr wichtig. Wenn das Signal dagegen weniger HF Anteil hat reduzieren sich die Anforderungen. Bei einem SAR ADC wird man einen AA filter benötgen und daher oft die obere Oktave oder so die der ADC theoretisch noch könnte nicht wirklich nutzen, sondern nur als Übergangsbereich für das AA-Filter haben.
Lurchi schrieb: > Viel Verstärkung auch bei 1 MHz heißt dann halt > eine hohe GBW, ggf. bis in den GHz Bereich. > > Ich würde so etwas wie THS4521 oder THS4541 in Betracht ziehen. Das war mir bisher nicht bekannt und ich hatte auch nicht auf die THD geachtet. Danke für die Empfehlungen. Pinkompatibel ist ja der ADA8138, den werde ich jetzt erstmal draufsetzen. Lurchi schrieb: > Wenn das Signal dagegen weniger HF Anteil hat reduzieren > sich die Anforderungen. Bei einem SAR ADC wird man einen AA filter > benötgen und daher oft die obere Oktave oder so die der ADC theoretisch > noch könnte nicht wirklich nutzen, sondern nur als Übergangsbereich für > das AA-Filter haben. Jap, das Filter hat hier den 3 dB Punkt bei unter 1 MHz. @ Hans-Georg: Danke, aber die Frequenz ist doch sehr niedrig. Wenn ich mir 2 kHz mit dem Signalgenerator erzeuge habe ich auch > 80 dB Abstand zwischen dem gewünschten Signal und den lautesten Obertönen. Klar da geht noch mehr, aber 80 dB würde mir schon reichen. Ich werde das aber trotzdem mal als Bastelprojekt auf meine ToDo Liste schreiben.
Angehängte Dateien:
-
25kHz.png
37 KB -
200kHz.png
39 KB -
25kHz_oszi.png
230 KB -
200kHz_oszi.png
270 KB
Hier mal Spektren bei 25 kHz und 200 kHz. Ja wenn das wirklich am LTC6363 liegt dann verstehe ich das. Zwischen dem LTC6363 und den ADC ist nur ein einfaches RC Filter, das hat keine gute Flankensteilheit. Edit: Noch zum Vergleich Bildchen vom Oszi. So wirklich weiß ich nicht ob das jetzt meine Hardware oder die Quelle ist ...
:
Bearbeitet durch User
Nimm eine DDS oder was auch immer die 77,5kHz auf besser 0,1Hz genau erzeugt und schicke sie durch einen 77,5kHz-Quarz (aus einem DCF77-Empfänger). Der Quarz wirkt als Schwingkreis der nur genau diese Frequenz durchläßt so daß ein wirklich sauberer Sinus herauskommt. Den Pegel vor dem Quarz auf irgendwas 100mV herunterteilen damit der Quarz nicht mechanisch überlastet wird.
Gustl B. schrieb: > Gibt es so Filter zu kaufen? Gerne > gleich als Set mit unterschiedlichen Grenzfrequenzen ... 100 kHz, 1 MHz, > 2 MHz, ... mit SMA an beiden Enden. Bei Minicircuits geht es erst ab 10 MHz los. Filter für diese Frequenzen kann man sich aus diskreten Bauteilen noch gut selber bauen. Wolfgang schrieb: > Wenn du den ADC vernünftig testen willst, brauchst du aber einen > sauberen Takt für die Abtastung deines Referenzsignals. Sonst versaut > dir der Abtastjitter die effektive Bit-Zahl, d.h. die 16 Bit kannst du > vergessen. Der Einfluß des Abtasttaktes wird doch gleich mitgemessen. Und je nach Anwendung spielt der Jitter u.U. auch keine Rolle, z.B. wenn das Meßsignal DC ist. Neben der FFT kann man auch eine sehr lange Messung über viele Perioden machen und anschließend einen Sinusfit durchlegen. Danach ermittelt man die Abweichung zwischen Messwert und Sinusfit und mappt alle Perioden aufeinander.
Bernd schrieb: > Filter für diese Frequenzen kann man sich aus diskreten Bauteilen noch > gut selber bauen. Klar, aber für ein fertiges Set hätte ich auch etwas ausgegeben. Muss ja nicht perfekt sein. Oder auch für ein paar Platinen mit SMA auf beiden Seiten und dazwischen genug Pads um verschiedene Filter, vielleicht auch aktive, zu bestücken. Bernd schrieb: > wenn > das Meßsignal DC ist. Gut, dann braucht man es nur einmal abtasten und hat den Wert. Da spielen dann auch Obertöne keine Rolle. Beim Abtasttakt ist für mich immer noch etwas unklar auf welche Weise man den erzeugen kann und wie man den nicht erzeugen sollte. Ich habe am FPGA einen Oszillator mit 100 MHz dran. Einen Si510 https://www.silabs.com/documents/public/data-sheets/si510-11.pdf und der liefert doch eigentlich einen ganz schönen Takt. Aber der geht in das FPGA rein und dort ... wird mit diesem Takt eine 40 Bit lange Sequenz über ein ODDR herausgetaktet. Da ist keine PLL oder so im Spiel und eigentlich sollte dann auch das Signal am Ausgang schön jitterfrei sein.
Was sollen die Aussagen zu Verzerrungen. Das ist Audio-Slang. Die werden als Harmonische bezeichnet. Und spielen nur bei Erzeugung(Wiedergabe) eine Rolle, wenn man mit nichtlinearen Elementen arbeitet. Bei Sampling(Aufnahme) gibt es nur den Frequenzgang. Und dort gibt es nur eine Frequenz, welche sich auszeichnet, die Sampling Frequenz. Von dort gibt es noch Subharmonische, welche von Nichtidealitaeten des Samplings herruehren.
Jim Williams hat doch mal so einen ultra-puren Wien-Oszillator gebaut, um einen hochauflösenden DAC zu qualifizieren. Irgendwo hab ich die AppNote bestimmt noch. Muss mal heute Abend suchen.
Mit einem DDS auf einen Quarz als Filter ist eine schlechte Idee. Der hat eine Guete von vielleicht 10^5.. 10^6. Wenn der auf Resonanz kommt, nimmt die Amplitude zu, er wird warm und laeuft weg. Und kommt wieder, eine Schwingung mit der thermischen Zeitkonstanten. Das einzige, was man bei einem DDS wegmachen muss ist die Hackfrequenz. Und die ist idealerweise weit weg. Bedeutet man sollte einen DDS nicht mit nur 4 Punkten pro Periode oder so laufen lassen. Ein Filter mit geringerer Guete sollte genuegen. Vielleicht ein LC-Schwingkreis, mit Guete 30, oder so.
Naja schrieb: > Was sollen die Aussagen zu Verzerrungen. Das ist Audio-Slang. Die werden > als Harmonische bezeichnet. Wo ist der Unterschied? Ist das eine Verzerrung oder nicht? Naja schrieb: > Bei > Sampling(Aufnahme) gibt es nur den Frequenzgang. Und dort gibt es nur > eine Frequenz, welche sich auszeichnet, die Sampling Frequenz. Von dort > gibt es noch Subharmonische, welche von Nichtidealitaeten des Samplings > herruehren. Ist das so? Ber der Aufnahme gibt es aber auch vor dem ADC und selbst in dem ADC Bauteile die das Signal am Eingang verzerren können. Z. B. Operationsverstärker. Aber was meinst du mit Frequenzgang und wo zeichnet sich die Samplingfrequenz aus? Natürlich können auch Harmonische entstehen, wenn das Signal z. B. clippt. Naja schrieb: > Ein Filter mit geringerer Guete sollte genuegen. Vielleicht ein > LC-Schwingkreis, mit Guete 30, oder so. Vermutlich wurde das genau so in den Signalgeneratorden gemacht die ich hier habe. Und trotzdem schaffen die "nur" ca. 60 dB zwischen Grundfrequenz und den Obertönen.
Ja, die Harmonischen zum Signal enstehen auch in der Signalkette vor dem ADC, durch Nichtidealitaeten, Saettigungserscheinungen. Clipping is natuerlich ein grober Fehler, welcher in diesem Kontext nicht passieren sollte. Kompression ist weniger dramatisch, fliessender. Ich waere mit 60dB Spurious Frequenzen sehr zufrieden. Wenn ich nur schon an die Nichtidealitaeten von Keramik Kondensatoren denke ... deren Kapazitaet nimmt mit zunehmender Spannung ab, bei neueren Materialien, Y5R zB -40% bei Nennspannung.. Meist bringen die Transducer, welche mit das physikalische Signal in Spannung umwandeln weniger dynamischen Bereich wie diese 60dB. Ohne jetzt die Anstrengungen schmaelern zu wollen. Interessant wird's wenn wir den Pegel des Signals um zB 30dB absenken. Sind dann die Harmonischen immer noch 60dB tiefer ?
Naja schrieb: > Ich waere mit 60dB Spurious Frequenzen sehr zufrieden. Naja, bei einem 16 Bit ADC bin ich das aber eher nicht. Naja schrieb: > bei neueren Materialien, > Y5R zB -40% bei Nennspannung.. Ich verwende im Signalpfad nur NP0. Naja schrieb: > Interessant wird's > wenn wir den Pegel des Signals um zB 30dB absenken. Sind dann die > Harmonischen immer noch 60dB tiefer ? Werde ich testen.
Wir haben auch 16Bit ADCs, unsere Signale sind zum Grossteil im Rauschen. Nach 10000 Additionen sehen wir's dann langsam. Wir hattens schon dass das Signal im 1 bit Rauschen versteckt war. Weil der Vorverstaerker fehlte. Es ging aber trotzdem, weil wir einen Brumm vom vielfachen des Nutzsignals drauf hatten.
Ein Design für einen Sinusoszillator, aber wieder Selbstbau und Quelle ist vorher zu charakterisieren: https://www.edn.com/design/analog/4368298/Test-18-bit-ADCs-with-an-ultrapure-sine-wave-oscillator Aber das hier könnte was sein? (500$) https://www.analog.com/media/en/dsp-documentation/evaluation-kit-manuals/dc1858af.pdf Die arbeiten interessanterweise mit der oben genannten Schaltung. Scheint als ganz brauchbar zu sein. Die Schaltung wurde auch schon in einem älteren Beitrag verlinkt. https://www.analog.com/media/en/technical-documentation/application-notes/an132f.pdf Oder einen Audio-DAC zum "Selbstbau", wenn auch so 10 kHz reichen? Muss man die Zunge aber auch gerade in den Mund nehmen: http://www.ti.com/lit/ds/symlink/dsd1792a.pdf Oder halt als fertiges Gerät. z.B.: (gibt es sicher auch günstiger) https://www.rme-audio.de/de_adi-2-dac.html Und hier noch was, bezüglich Messung (schneller) ADCs: https://www.analog.com/media/en/technical-documentation/application-notes/AN-835.pdf "Usually, dynamic testing employs a Rohde & Schwarz SMA/ SMHU/SMG/SMGU, an Agilent 8644 signal generator, a Wenzel crystal oscillators or a Valpey Fisher crystal oscillator. These sources have proven to provide exceptional performance (low phase noise, flat frequency response, and reasonable harmonic performance) for frequencies of a few kilohertz to those of a few gigahertz. Harmonic performance of these generators is typically not as good as the intrinsic linearity of a given ADC, mandating the need for additional filtering between the signal generator and the analog input to the ADC." Bezüglich Jitterarmer Taktquelle für den ADC: https://www.analog.com/media/en/training-seminars/tutorials/MT-007.pdf Walt Kester ist generell eine Empfehlung bezüglich ADCs/DACs. Viel Spaß beim Lesen! :-)
Naja schrieb: > Ich waere mit 60dB Spurious Frequenzen sehr zufrieden. Wenn ich nur > schon an die Nichtidealitaeten von Keramik Kondensatoren denke ... deren > Kapazitaet nimmt mit zunehmender Spannung ab, bei neueren Materialien, > Y5R zB -40% bei Nennspannung.. >..... > Ohne jetzt die Anstrengungen schmaelern zu wollen. Interessant wird's > wenn wir den Pegel des Signals um zB 30dB absenken. Sind dann die > Harmonischen immer noch 60dB tiefer ? In dem Frequenzbereich sieht man zu das man NP0 Keramk nimmt und keine Klasse 2. Die kommen dem Idealfall schon recht nahe. Da stellt sich die Frage nach der Linearität schon fast eher bei den Widerständen. Die relative Stärke der Harmonischen hängt in der Regel von der Amplitude ab. Oft wird es mit kleiner Amplitude besser, es gibt aber Grenzen, wenn so etwas wie Übernahmeverzerrungen beteiligt sind. 60 dB Abstand zu den Harmonischen sind noch nicht wirklich gut - das wäre etwas um einen 10 Bit Wandler zu testen.
Lurchi schrieb: > 60 dB Abstand zu den Harmonischen sind noch nicht wirklich gut - das > wäre etwas um einen 10 Bit Wandler zu testen. Nun, dass ist überhaupt nicht gut! Schon eine Schallplatte schafft das! Natürlich will ich nicht wirklich eine Schallplatte mit Testsignal vorschlagen :-) Gruß Rainer
Bernd schrieb: > Der Einfluß des Abtasttaktes wird doch gleich mitgemessen. > Und je nach Anwendung spielt der Jitter u.U. auch keine Rolle, z.B. wenn > das Meßsignal DC ist. War hier nicht von 100kHz als Referenz die Rede? Manche Leute bezeichnen das als DC, aber die arbeiten dann selten mit 16-Bit Wandlern ;-) Wenn du dir schon durch Abtastjitter über die Signalsteigung Amplitudenfehler einfängst, kannst du auf die richtigen Feinheiten bei der Erzeugung eines sauberen 100kHz Referenzsinus auch gleich verzichten.
Danke Elias, ja ich sehe schon ich muss das mit dem Takt tatsächlich anders machen. Und dafür brauche ich eine neue Hardware bzw. muss diese erstellen. Wirklich wichtig ist ja hier der Abtasttakt, also im Beispiel die 5 MHz. Aber wenn ich einen Taktgeber mit auf die ADC Platine packe, dann soll der auch gleich den SPI SCLK mit machen. Da verwende ich 100 MHz, 105 MHz wäre etwas besser aber geht beides. Wie macht man das? Einen guten 100 MHz Oszillator und dann ein Gattergrab mit Zähler das die Takte zählt und dann abhängig davon #CNV und SCLK bedient? Klingt umständlich. Von AD gibt es dann noch so Takt ICs mit PLL und Jittercleaner, braucht man das oder kann ich darauf gut verzichten wenn ich einen ordentlichen Oszillator verwende?
Hast du einen FPGA? Und der ADC braucht die 5 MHz als stabilen Systemtakt? Dann würde ich Jitterarme 5 MHz erzeugen und damit FPGA und ADC versorgen. Und im FPGA dann eine PLL nehmen, um von 5 MHz zu 100 oder 105 MHz zu gehen. Die können ruhig mehr Jitter haben. Ob der SPI oder die Logik im FPGA etwas jittert, macht ja an der Auflösung des ADC nix mehr. Muss der SPI-Takt eigentlich synchron zum ADC-Takt sein? Bei einem µC statt FPGA müsstest du wahrscheinlich eine externe PLL nehmen. Wenn du einen stabilen 100 MHz Oszillator findest, auch gut. Und ja, dann mit Logik runterteilen. (im FPGA, wenn vorhanden?) Aber meines Wissens sind Quarze mit so hohen Frequenzen selten, da die mit Oberwellen arbeiten müssen. MEMS könnte es was geben. Der erste 100 MHz Oszillator, den ich gefunden habe: https://de.farnell.com/abracon/asdmb-100-000mhz-xy-t/mems-oszillator-100mhz-smd-2-5/dp/2849471 60 ps Cycle-to-Cycle Jitter. Das reicht wahrscheinlich noch nicht ganz. Müsstest du konkret nachrechnen.
Elias K. schrieb: > Muss der SPI-Takt eigentlich synchron zum ADC-Takt sein? Was meinst du damit? Alle 200 ns ein Sample. Und innerhalb der 200 ns muss #CNV eine Zeit lang high sein und dann lese ich die Daten raus, also 16 Takte von SCLK während #CNV low ist. Mit 100 MHz geht das gerade so. OK, aber den 5 MHz Takt direkt an #CNV vom ADC anschließen geht nicht, da bekomme ich nicht den Durchsatz wenn der Takt 50% Tastverhältnis hat. Ich gucke mir mal das EVAL Board an, da wurde das ja irgendwie gelöst.
:
Bearbeitet durch User
Elias K. schrieb: > Der erste 100 MHz Oszillator, den ich gefunden habe: > https://de.farnell.com/abracon/asdmb-100-000mhz-xy-t/mems-oszillator-100mhz-smd-2-5/dp/2849471 > 60 ps Cycle-to-Cycle Jitter. Das reicht wahrscheinlich noch nicht ganz. > Müsstest du konkret nachrechnen. Mems Oszillatoren sind eher nicht so gut. Es sollte schon ein echter Quarz oder SAW basierter Oszillator sein. Wie oben schon von anderen geschrieben entweder mit 100 MHz starten und dann teilen (sollte mit 2 Chips (Teiler + sync. zu machen sein) oder alternativ mit 5 oder 10 MHz anfangen und dann den Takt für den µC oder FPGA per PLL hoch setzen lassen. Je nach Modell ist der PLL da schon enthalten. Neben den reinen Chips kommt es auch auf das Layout an, sonst macht einem ggf. eine Masseschleife alles kaputt. Entsprechend ist ein Teiler rein im FPGA auch mit Vorsicht zu genießen - mit externer Synchronisation geht es aber.
Die Referenz ist Audio Precision www.ap.com Für 100 kHz brauchst du aber den analogen Generator.
So, hier das Demoboard vom Hersteller https://www.analog.com/media/en/technical-documentation/eval-board-schematic/DC2395ASCH.PDF gleich auf der ersten Seite ist die Beschaltung für den Takt. Macht auch sinn so, denn gerade die fallende Flanke von #CNV sollte frei von Jitter sein. Bei Schaltung brauche ich aber ein zusätzliches FPGA IO und hier bei dem Demoboard ist das FPGA mit auf der gleichen Platine. Bei mir ist das nicht so und ich habe Digitalisolatoren dazwischen (die ja auch Jitter hinzufügen). Um damit keine Probleme zu haben würde ich gerne folgendes bauen: 100 MHz oder 105 MHz Oszillator mit zum ADC auf die Platine, und dort aus diesem Takt sowohl #CNV als auch SCLK generieren. Ohne dass ich vom FPGA ein CNV_EN brauche. Dazu könnte ich einen Zähler verwenden der bei den 105 MHz bis 21 zählt und dann resettet wird. Und dann in Abhängigkeit des Zählerstandes könnte ich dort lokal ein CNV_EN erzeugen und auch entscheiden ob der Takt als SCLK angelegt wird oder nicht. Macht das Sinn? Das sollte ja eigentlich auch keinen Jitter hinzufügen wenn man das ordentlich macht. Zum FPGA geht dann wie jetzt CLKOUT und die SDO1 ... SDO4. SCLK und #CNV vom FPGA zum ADC brauche ich dann nicht mehr. Nachteil: Ich habe eine feste Samplerate die ich nicht mehr mit dem FPGA verstellen kann. Aber das ist völlig OK für mich. ap.com kannte ich noch nicht, aber für mein Hobby ist das zu teuer.
Zum Testen würde ich eher 50kHz nehmen und mehr Oberwellen betrachten. udok schrieb: > Für 100 kHz brauchst du aber den analogen Generator. Wenn es nur die 100kHz sein sollen, stimme ich dem zu. Einen analogen Schaltkreis mit einer sehr trägen Regelung und Filterung kriegt man kostengünstig noch so hingestellt, dass der jede digitale Realisation toppt, wenn der Aufbau stimmt. Kommt aber bei industriellen Anwendungen auch auf die geforderte Störempfindlichkeit an. In ungünstigen Bereichen ist es besser, einen digitalen Aufbau zu wählen. FPGA aber nur mit statischem Teiler und starrem OSC mit eng toleriertem Filter, also keine PLL im FPGA. Am Besten einen eigenen Takt zum Wandler mit asynchronem Registerausgang der DDS aus dem FPGA, dass dessen Jitter keinen Einfluss hat. Die DDS voll digital aber mit optimiertem Phasenrauschen für den DAC. Muss man eben sehen und messen, was der kann und tut und braucht. Im DIY Audio-Technik-Bereich gibt es einige, die einen 32BIT-R2R verwendet haben. Der ist - eine saubere Kalibrierung und Nachregelung für Temperatur, etc vorausgesetzt - genauer, als die gegenwärtigen Sigma-Delta-DACs. Auch im variablen Audioband. Lohnt aber i.d.R. nicht. 50% mehr Qualität, 5-facher Preis :-)
Nur 100 kHz oder eben eine andere feste Frequenz wäre schon OK. Ich habe von TI den http://www.ti.com/tool/TSW2110EVM aber den gibt es leider nur mit 10 MHz und 70 MHz. 0,1 MHz oder 0,5 MHz und 1 MHz wäre noch fein. Aber vielleicht nehme ich die Schaltung und passe sie für 100 kHz oder 500 kHz an. So, jetzt habe ich eine Logikschaltung die aus einem 105 MHz Takt, einem Zähler IC, einem D-FF und ein paar einzelnen Gattern sowohl #CNV als auch SCLK für den ADC erzeugt. Der Zähler zählt immer bis 21 und wird dann resettet. Wenn der Zählerstand kleiner 4 ist, dann ist nCLR vom D-FF auf '1', es bleibt als gesetzt und wird nach etwas Zeit (Zählerstand 4 und höher) zurückgesetzt. Dann wird gleichzeitig auch in Abhängigkeit des Zählerstandes ein SCLK_EN erzeugt. Und das wird mit dem Takt auf ein AND Gatter gegeben. Dadurch kommen dann nur 16 Takte auf SCLK zum ADC. Ist so eine Konstruktion vom Jitter her OK? Ich würde sagen ja.
Jetzt suche ich gerade nach ICs mit denen ich das bauen könnte, aber ich finde nichts. RS Flip Flop gibt es nur in irre langsam. Logikkomparatoren gibt es auch, aber auch zu langsam. In einem FPGA geht das doch auch mit einem hohen Takt, und hier sind 105 MHz gar nicht so irre schnell, oder suche ich nur falsch?
Gustl B. schrieb: > Jetzt suche ich gerade nach ICs mit denen ich das bauen könnte, aber ich > finde nichts. RS Flip Flop gibt es nur in irre langsam. Man, wenn ein RS-FlipFlop zulangsam ist, dann heilige Marie!! Es gibt immer noch die berühmte HiSpeed-Logik, die alles unter 1nS regelt. Kostete damals etwa ein Einfamilienhaus - ECL-Logik -und jetzt??? Gruß Rainer
Dann zeig mir doch ein schnelles RS FF das ich kaufen kann. Bei Mouser finde ich nichts.
Moin, Gustl B. schrieb: > So, jetzt habe ich eine Logikschaltung die aus einem 105 MHz Takt, einem > Zähler IC, einem D-FF und ein paar einzelnen Gattern sowohl #CNV als > auch SCLK für den ADC erzeugt. Hm - haste da mal einen Schaltplan? Gruss WK
Gustl B. schrieb: > Dann zeig mir doch ein schnelles RS FF das ich kaufen kann. Bei Mouser > finde ich nichts. Echt, gibts ECL-Logik nicht mehr??? Nicht das ich dafür jemals eine anständige Applikation gehabt hatte...aber einer meiner Doktoranden...er ist jämmerlich baden gegangen. Unter 1nS wirds sowohl messtechnisch, als auch darstellungsäßig (Oskar, mit Speicher?) schwer! Auch heute noch!!! Lasse mich gern korrigieren. Gruß Rainer
Ne, noch nicht, habe mir die ICs in VHDL geschrieben. Jetzt habe ich also den Zählen, den gibt es auch in schnell zu kaufen, aber ich muss ja die Ausgänge auswerten. Da kann ich entweder einen Logikkomparator verwenden für kleiner/größer, das ginge, aber den kann ich nicht kaufen. Ich könnte aber auch ein RS FF nehmen, das bei genau einem Zählerstand setzen, und bei einem anderen Zählerstand löschen. Die andere Lösung wäre, dass ich die Clock wie im Referenzdesign auch zum FPGA führe und dort das CNV_EN Signal und SCLK erzeuge. Aber bei mir ist da deutlich Latenz dazwischen weil zwischen FPGA und ADC Digitalisolatoren sitzen. Bisher ist die Latenz egal denn #CNV und SCLK kommen beide vom FPGA, haben beide die gleiche Verzögerung bis zum ADC und zurück kommt vom ADC CLKOUT und SDOx. Das passt also wunderbar. Aber wenn ich den 105 MHz Takt mit Latenz zum FPGA führe, dann dort mit diesem Takt CNV_EN und SCLK erzeuge, wieder mit Latenz zum ADC führe, dann ist dort noch das retiming FF. Und das wäre doof wenn das retiming FF einmal nach 21 und dann nach 20 Takten oder erst nach 22 Takten das CNV_EN neu taktet. Edit: Gut, auch das kann man ja mit VHDL nachbauen und simulieren. Die Digitalisolatoren sind dann ein transport delay mit etwas Jitter. Mal gucken^^ Mouser listet ECL, aber auch dort habe ich nichts brauchbares gefunden. Wenn du mir ein RS FF zeigst wäre das sehr fein.
:
Bearbeitet durch User
So, jetzt habe ich das VHDL so weit, dass ich mit dem Jitter anfange. Ich habe da also das D-FF zum retimen, einen Inverter und die Digitalisolatoren. Tja ... und die Datenblätter geben zwar alle Timingdaten an, aber ich weiß nicht was davon zutrifft. Das FF https://www.onsemi.com/pub/Collateral/NL17SZ74-D.PDF hat auf Seite 4 die Information. Wenn ich da jetzt mal Propagation Delay, CP to Q or notQ nehme, dann gehe ich in die Zeile mit der Versorgungsspannung 3.3 ± 0.3 und lese dort bei 25 °C: typisch 2,8 ns, maximal 6,5 ns. Nun, das ist aber ein großer Unterschied für mich. Ist das jetzt so, dass das bei einem einzelnen Bauteil zwischen den Werten schwankt, oder ist das so, dass wenn ich viele Bauteile nehme, manche 6,5 ns haben, aber sehr viele weniger und im Mittel hat so ein Baustein also 2,8 ns? Sprich ist der Wert für einen Stein fest oder schwankt der? Ähnlich beim Inverter https://www.mouser.de/datasheet/2/308/NC7SZ04-1301544.pdf , auf Seite 5. Dort steht z. B. Propagation Delay, wieder 3,3 V, minimal 0.5 ns, typisch 2.1 ns und maximal 4.5 ns. Auch da wäre es gut zu wissen ob das für ein Bauteil ein fester Wert ist oder ob der schwankt. Beim Isolator https://www.silabs.com/documents/public/data-sheets/Si866x.pdf stehen die Timings auf Seite 13. Relativ feste Werte, egal wie groß kann man ja kompensieren, aber wenn das schwankt wäre es schlecht. Die Temperatur ist relativ konstant. Vielleicht im Sommer um 5 °C wärmer als im Winter. Ich würde die Werte jetzt einfach mal als fest annehmen und das ausprobieren.
Gustl B. schrieb: > Dann zeig mir doch ein schnelles RS FF das ich kaufen kann. Ich würde ein D-FF nehmen (z.B.: MC100LVEL31). Das (verjitterte) Datensignal kommt vom FPGA und der (saubere) Takt geht auf den Takteingang. Hast Du eine Möglichkeit Jitter zu bestimmen?
Klar, zum retimen von nCNV ein D-FF. Ein RS wollte ich verwenden um in Abhängigkeit eines Zählerstandes ein SCK Enable zu erzeugen. Ne, Jitter kann ich mir hier höchstens auf dem Oszi angucken.
Die Propagation delay Bereiche geben die Schwankungen zwischen Verschiedenen Exemplaren und oft auch über den Temperatur- und Spannungsbereich an. Für den Jitter ist der Teil nicht relevant. Schnelle RS Flip flops findet man schon als 74VHC74 oder ähnlich. Das xx74 kann man auch als RS FF nutzen.
Ich habe jetzt nicht im Blick, welchen ADC du verwendest. Gustl B. schrieb: > Klar, zum retimen von nCNV ein D-FF. Ein RS wollte ich verwenden um in > Abhängigkeit eines Zählerstandes ein SCK Enable zu erzeugen. Gustl B. schrieb: > Denn raus kommt ein 1 MHz > Takt (maximal) für den CNV Eingang am ADC. Die SCK ist schnell, aber das > ist nur die Clock für das SPI Interface, da ist Jitter egal. Dem würde ich zu stimmen. > Ne, Jitter kann ich mir hier höchstens auf dem Oszi angucken. Damit kann man nur gegen die Zeitbasis des Oszis messen. Für einen ersten Vergleich kann das gehen. Wenn das Oszi keine explizite Jittermessoption hat, schaut man sich das Taktsignal ein paar µs oder paar ms nach dem Trigger an:
1 | _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ |
2 | ^ | | |
3 | Trigger Zoomfenster |
Die nächst bessere Messmöglichkeit wäre ein Spektrumanalysator (idealerweise mit Phasenrauschmessoption).
Man muss natuerlich nach etwas anderem suchen. Nicht nach RS FlipFlop. https://www.analog.com/en/products/high-speed-logic/logic-devices/flip-flops.html https://www.analog.com/en/products/clock-and-timing/clock-generation-distribution/clock-dividers.html Ich persoenlich verwende gerne auch eingebaute Teiler, zB in einem ADF4001, welcher 100MHz durch bis zu 2^14 = 16384 teilen kann. Falls es schneller sein muss, gibt es auch schnellere Bausteine.
Lurchi schrieb: > Die Propagation delay Bereiche geben die Schwankungen zwischen > Verschiedenen Exemplaren und oft auch über den Temperatur- und > Spannungsbereich an. Für den Jitter ist der Teil nicht relevant. Danke! Lurchi schrieb: > Schnelle RS Flip flops findet man schon als 74VHC74 oder ähnlich. Das > xx74 kann man auch als RS FF nutzen. OK, mal gucken. Dass es schnelle D-FFs gibt habe ich schon gesehen. @ Bernd: Danke! @ Joggel E.: Naja, was bringt mir ein Taktteiler? Klar, ich könnte von 105 MHz durch 21 Teilen und komme auf 5 MHz. Aber was bringt mir das? Ich habe einen 105 MHz Takt, muss daraus ein möglichst jitterfreies #CNV Signal erzeugen das so um die 40 ns lang high ist, und danach muss ich 16 Pulse für SCK erzeugen. Im FPGA würde ich einen Zähler mit den 105 MHz von 0 bis 20 zählen lassen und dann zurücksetzen. #CNV_Enable <= '1' when Zähler < 4 else '0'; SCK_Enable <= '1' when Zähler > 4 else '0'; Und dann wird #CNV durch das retiming FF erzeugt wie im Schaltplan des Demoboards, #CNV_Enable geht auf den Clear vom D-FF und der saubere 105 MHz Takt geht auf den CP Eingang. SCK wird durch ein AND erzeugt, also SCK <= SCK_Enable AND CLK105MHz. Das ginge, aber ich bräuchte zwei Vergleich ICs oder schnelle Gatter. Einen schnellen Zähler gibt es, ich könnte also auf < 4 prüfen indem ich prüfe ob die höheren Bits alle 0 sind. Auf größer 4 zu prüfen wird etwas schwieriger. Daher dachte ich für das SCK_Enable eben an ein RS FF. Das setze ich wenn der Zähler den Wert 5 hat und resette es wenn der Zähler zurückgesetzt wird. Aber es wird wohl darauf rauslaufen, dass ich mal eine Platine baue ohne ADC, aber mit mehreren Footprints für die unterschiedlichen Bausteine und Oszillator. Und dann kann ich mir da gut angucken ob ich das Timing schaffe. #CNV werde ich auf eine SMA Buchse legen um mir dann auch mal den Jitter angucken zu können.
:
Bearbeitet durch User
Angehängte Dateien:
-
SPI.png
180 KB
So, hat jetzt etwas gedauert, aber es reichen wohl 4 AND Gates, 3 D-FFs und ein Binärzähler um aus einem Takt sowohl nCNV als auch SCK zu generieren. Macht das Sinn das zu dem ADC auf die Platine zu setzen? Zum FPGA geht dann wirklich nur noch CLKOUT vom ADC und synchron dazu die SDO Signale. Und vielleicht noch ein Weiteres Signal, z. B. der Reset für den Zähler damit im FPGA dann auch klar ist wann ein Sample fertig ist, also die mit CLKOUT hereingeschobenen Daten in die andere Clockdomäne im FPGA übernommen werden können.
:
Bearbeitet durch User
Jürgen S. schrieb: > Im DIY Audio-Technik-Bereich gibt es einige, die einen 32BIT-R2R > verwendet haben. Der ist - eine saubere Kalibrierung und Nachregelung > für Temperatur, etc vorausgesetzt - genauer, als die gegenwärtigen > Sigma-Delta-DACs. Auch im variablen Audioband. Lohnt aber i.d.R. nicht. > 50% mehr Qualität, 5-facher Preis :-) Den möchte ich sehen, der mehr als 100 dB THD+N schafft, über sagen wir mal +- 5 Grad Temperaturschwankung. Bei > 120 dB, wo es interessant wird, muss der Teiler mit den Mosfet Schaltern auf 5 Milloohm genau sein, und dass bei R=10kOhm, was rauschmässig schon zu viel ist. Abgesehen sind die R2R DACs berühmt für ihre Glitches beim Umschalten...
Es gibt tatsächlich ECL zu kaufen, die sind schon ziemlich schnell. Aber die sind auch zu CMOS nicht kompatibel. Macht es Sinn ECL zu verwenden und dann für die ADC Eingänge das mit einem zusätzlichen IC nach 2.5 V CMOS zu wandeln? Ich vermute nein und werde jetzt mal die Schaltung in CMOS aufzubauen.
Moin, Die Schaltung um U2 und U4A ist schonmal sehr, sehr boese. Nicht so machen. Gruss WK
Warum denn? Und wie sollte ich das denn sonst machen? Zu einem bestimmten Zählerstand soll der Zähler zurückgesetzt werden. Und hier wird geprüft ob der auf 21 steht. Ja, da werden manche Bits ignoriert, stimmt, aber ... das wären höhere Zählerstände. Der wird also zurückgesetzt bevor diese eintreten können. Oder habe ich einen Denkfehler?
Gustl B. schrieb: > Warum denn? Weil du nicht sicher sein kannst, dass der Reset auch alle Flipflops in dem Zaehler "erwischt". Wenn jetzt z.b. im 4024 nur Flipflop, das Q1 treibt, etwas hurtiger im Reset ist als die anderen Flipflops, dann kannst passieren, dass nicht alle Flipflops im 4024 den Reset mitkriegen. Im FPGA wuerdest du das auch niemals so aufbauen, sondern mittels eines Synchronzaehlers. So solltest du das auch mit diskreten Bauteilen machen. Gruss WK
Macht Sinn. Ja, ich habe das schon so aufgebaut wie im Bildchen, aber bei langsamem Takt und das hat funktioniert. In der Simulation geht das auch, aber sicher ist sicher, ich suche mir einen anderen Zähler IC. Das ist gar nicht so einfach. Die die ich finde sind alle langsamer als 105 MHz. In ECL gibt es was, ja, aber der ADC hat CMOS Eingänge.
Moin, Ja, diese Schaltungen funktionieren meistens. Aber halt nicht immer. Und immer dann nicht, wenn man nicht damit rechnet. Daher: Nicht machen ;-) Gruss WK
Tja ... alles nicht so einfach. Vielleicht ist ein kleines CPLD die passende Lösung um aus dem Takt das nCNV_Enable und SCLK zu erzeugen. Der XCR3032XL-5VQ44C ist schön klein und wenn man bei Mouser nach Geschwindigkeit filtert der Schnellste von Xilinx. Billig ist der auch.
:
Bearbeitet durch User
Ich glaube, dass du vielleicht die "höheren" Megaherze etwas unterschätzt! Ich durfte mich während meiner HiWi-Zeit ausgiebig mit ECL-Logik herumschlagen und denke, das macht man nur, wenn es absolut nötig ist! Warum versuchst du dich nicht an den verlinkten LT-Applikationen und baust mal so einen Testgenerator auf? Ja, wird ein Höllengeld kosten, aber du willst ja auch eine "Höllenpräzision"...mit einem passenden Modell für den Optokoppler könnte man auch erst mal simulieren... Bin gespannt, wo du landen wirst! Gruß Rainer
Rainer V. schrieb: > Ich durfte mich während meiner HiWi-Zeit ausgiebig mit > ECL-Logik herumschlagen und denke, das macht man nur, wenn es absolut > nötig ist! OK. Rainer V. schrieb: > Warum versuchst du dich nicht an den verlinkten > LT-Applikationen und baust mal so einen Testgenerator auf? Naja, offensichtlich habe ich erstmal noch andere Probleme, eben en Takt en wohl ordentlich jittert und dann habe ich ja einen OPV vor em ADC er bei >100 kHz eutlich nichtlinear wird. Ich werde also zuerst iese beiden Baustellen beheben. Vielleicht bin ich ann sowieso schon zufrieden. Edit: Ach männo, das Vivado unterstützt keine CPLDs ... also kleinen Spartan7 oder einen Intel Max 10. Pluspunkt für den Max 10 ist, dass es den im EQFP-144 gibt und der keinen externen Konfigurationsspeicher braucht.
:
Bearbeitet durch User
Gustl B. schrieb: > Naja, offensichtlich habe ich erstmal noch andere Probleme, eben en Takt > en wohl ordentlich jittert und dann habe ich ja einen OPV vor em ADC er > bei >100 kHz eutlich nichtlinear wird Wie mans nimmt. Habe deine Eingangsfrage so verstanden, dass du einen Referenzgenerator bauen willst, bzw. suchst! Bei einem klassischen Sinusgenerator hast du keine Probleme mit Jitter oder Flankensteilheit :-) das kommt von der offensichtlich wichtigeren Erzeugung eines Taktes aus großem MHz-Bereich. Und wenn du einen OPV hast, der >100KHz nicht mehr mitmacht, dann hast du einfach den Falschen! Schau dir ruhig mal die analogen Lösungen an...und wie gesagt, Geld mußt du sicher so oder so in die Hand nehmen!! Gruß Rainer
...schau dir doch einfach mal das Beispiel dieses Generators zur Ausmessung eines 18-Bit-AD an. Und wenn ich richtig gelesen habe, dann ist dir ein Audio-Precision zu schlecht??? Dann jetzt aber mal schleunigst weg von dem digitalen Frequenzteilen :-) Gruß Rainer
Rainer V. schrieb: > Wie mans nimmt. Habe deine Eingangsfrage so verstanden, dass du einen > Referenzgenerator bauen willst, bzw. suchst! Das stimmt schon, ich wollte damit einen ADC testen. Mittlerweile ist mir zumindest teilweise klar welche Fehler ich bei der Beschaltung des ADCs gemacht habe und möchte diese auf einer neuen Platine nicht mehr machen. Ich habe da auch keine konkrete Anwendung, ich mache das um das einmal gelernt zu haben. Auf dem Evalbaord zum ADC ist ein Cyclone3 FPGA drauf. Wie ich jetzt weiß nicht ganz ohne Grund. Für eine Anwendung habe ich das ADC Board bisher galvanisch getrennt vom FPGA und USB Teil. Das funktioniert auch gut genug. Aber diese galvanische Isolation macht mir vermutlich die Idee mit dem retimen kaputt. Das kann ich schlecht abschätzen. Ich sehe jetzt mehrere Möglichkeiten (jeweils mit retiming FF): 1. Den Takt vom ADC Board zum FPGA Board, dort nCNV_Enable und SCLK erzeugen, beides vom FPGA Board zum ADC Board, dort nCNV retimen und zum ADC. Das wäre für mich die geringste Änderung am Design, aber ich habe da deutlich Latenz durch die Digitalisolatoren. Latenz wäre aber schnicht schlimm. Jitter wäre schlecht wenn der bewirkt, dass nCNV mal einen ganzen Takt länger und mal einen ganzen Takt kürzer ist. 2. Eine Logikschaltung aus einzelnen Bauteilen mit auf das FPGA Board packen die aud dem Takt sowohl nCNV_Enable und SCLK erzeugt. Ob das geht weiß ich nicht, da bräuchte ich schnelle Bauteile, vor allem einen Zähler. Einen asynchronen Zähler hatte ich gefunden, aber, naja der könnte Ärger machen. Vielleicht sollte ich das einfach mal probieren. 3. Einen CPLD oder FPGA mit auf die ADC Platine packen. Aber wenn ich das mache, dann brauche ich keine zusätzliche FPGA Platine. Wenn ich dann wirklich galvanisch trennen will, dann trenne ich zwischen FPGA und den USB Bausteinen. Rainer V. schrieb: > ...schau dir doch einfach mal das Beispiel dieses Generators zur > Ausmessung eines 18-Bit-AD an. Und wenn ich richtig gelesen habe, dann > ist dir ein Audio-Precision zu schlecht??? Dann jetzt aber mal > schleunigst weg von dem digitalen Frequenzteilen :-) Nein. Das muss nicht irre genau sein. Ich will auch keine vollen 16 Bits, da hat der ADC selbst schon zu viel Rauschen. So 90 dB Signal Rauschabstand würden mir schon reichen. Aber eben bis 1 MHz hoch.
:
Bearbeitet durch User
Danke für die rasche Antwort. Aber jetzt verstehe ich dein Problem überhaupt nicht mehr! Um einen ADW zu testen - zumindest wenn du Wechselspannung messen willst - brauchst du eine rausch- und klirrarme Sinusquelle...danach hattest du auch gefragt...das ganze Drumherum, mit deinen CPLD oder FPGA, verstehe ich nicht. Vielleicht hast du dein Problem ja nur unglücklich beschrieben und ich habe es wiederum unglücklich in den "falschen Hals" gekriegt. Gruß Rainer
Rainer V. schrieb: > brauchst du eine rausch- und klirrarme > Sinusquelle Genau. Die hatte ich eingangs auch gesucht, darum dieser Thread. Aber ich habe festgestellt, dass der ADC mit der jetzigen Beschaltung schon das Signal das aus meinem Frequenzgenerator rauskommt verzerrt. Der Generator hier hat so zwischen 80 dB und 60 dB Signalrauschabstand, und das bekommt der ADC nicht ordentlich hin. Bei niedrigen Frequenzen schon, aber so ab 200 kHz nicht mehr. Ausserdem ist der Frequenzpeak im FFT recht breit. Eine der Ursachen ist ein Verstärker vor dem ADC. Der bleibt nur im unteren Frequenzbereich schön linear. Eine weitere Ursache ist der Abtasttakt vom ADC. Wenn dieser Takt einen Jitter drauf hat, also die Abtastzeitpunkte nicht äquidistant sind, dann sieht das abgetastete Signal ebenfalls verzerrt aus. Ich werde also auf der nächsten Bastelhardware andere OPVs verwenden und auch den Abtasttakt, konkret das Signal #CNV, möglichst jitterfrei anliefern. Und das geht mit einem retiming FlipFlip, mal erzeigt also ein jitterbehaftetes #CNV_Enable, und das wird mit einem FF und einem sehr sauberen Takt dann jitterfrei gemacht. Tja, und da das ein SPI ADC ist brauche ich auch noch SCLK. Ich überlege also ob ich dieses gerne etwas jitterbehaftete #CNV_Enable lokal durch eine Logikschaltung erzeugen soll, und gleichzeitig dann auch noch SCLK. Oder ob ich das im FPGA erzeuge. Aber dazu muss der Takt erstmal durch einen Digitalisolator zum FPGA, und dann das #CNV_enable durch den Digitalisolator zuück zum retiming FF. Da kann ich mich gerade nicht so wirklich entscheiden weil ich nicht weiß wie groß der Jitter ist den FPGA und Digitalisolatoren hinzufügen. Wenn dieser Jitter nämlich zu groß ist, dann könnte es sein, dass das retiming FF mal einen Takt länger und mal einen Takt weniger draus macht. Ich werde das aber wohl einfach ausprobieren. Wenn ich das gemacht habe (das dauert), und dann noch nicht zufrieden bin mit dem ADC, dann baue ich eine schöne Sinusreferenz. Bei niedrigen Frequenzen bin ich ja schon zufrieden. Da ist nur der Frequenzpeak recht breit (siehe weiter oben die FFT Bildchen) was gut durch den Jitter kommen kann.
Gustl B. schrieb: > Da ist nur der Frequenzpeak recht breit (siehe weiter oben > die FFT Bildchen) was gut durch den Jitter kommen kann. Kann, aber muß nicht :-) Viel Spass, Rainer
...und wenn du wirklich "nur" Bastler bist, dann mußt du aber bei deinem Projekt jetzt trotzdem auch sowas wie Jitter messen können! ANsonsten verlierst du dich in den berühmten "Verschlimmbesserungen". Was du bisher geschrieben hast, bestärkt mich in meiner Vermutung, dass du ein AD-System hast, welches eine Grenzfrequenz hat, die dir zu niedrig erscheint. Schon der mehrfach erwähnte OPV scheint ja das ganze System sehr zu limitieren. Wie du da ohne gravierendes Neudesign auf deine Bandbreite größer 1MHz kommen willst, ist mir erst mal nicht klar! Gruß Rainer
Ja, da hast du Recht, aber das kostet eben alles. Bandbreite hat der genug. Aber er verzerrt dann eben. Klar wird das ein neues Layout, neue Platine. Derzeit verwende ich diesen OPV https://www.analog.com/media/en/technical-documentation/data-sheets/LTC6363.pdf auf Seite 15 oben in der Mitte sieht man, dass ab ein paar 10 kHz die harmonische Verzerrung deutlich nach oben geht. Für die nächste Hardware habe ich mir den https://www.analog.com/media/en/technical-documentation/data-sheets/ADA4927-1_4927-2.pdf rausgesucht. Rainer V. schrieb: > ANsonsten > verlierst du dich in den berühmten "Verschlimmbesserungen". Exakt! Aber als Anfänger kann ich schlecht abschätzen wann etwas ausgereizt ist. So Dinge wie den Vorteil von NP0 gegenüber X7R. Das kann man alles irgendwo nachlesen, dann gibt es viele Forenposts und Appnotes, aber wie viel was jetzt wirklich bringt ist für mich oft unklar bis ich das selber mal probiert habe. Es gibt ja auch immer diesen Streit zwischen Layer mit Masse fluten oder nicht. Klar macht das einen Unterschied, aber oft ist der eben egal. Daher verschlimmbessere ich auch mal und sehe dann was etwas gebracht hat und was nicht. Ich habe das hier mal an einer FPGA Platine gesehen. Da hatte ich noch genau 0 Kondensatoren zwischen Versorgung des FPGAs bestückt. Nur die Kondensatoren am Ausgang des Schaltreglers waren natürlich da. Tja und das hat auch funktioniert, sogar mit einem recht großen Design im FPGA. Aber man konnte an der Versorgung eben sehen, dass da Dinge schalten. Nachdem ich weiter bestückt hatte war die Versorgung dauerhaft schön sauber. Das sind eben so Dinge die man mal ausprobieren kann um dann von Empfehlungen auch abweichen zu können wenn man weiß, dass es auch so geht. Xilinx empfiehlt für jeden Versorgungspin einen Kondensator. Das habe ich bisher auch gemacht, bei vielen kaufbaren FPGA Boards ist das aber nicht so gemacht, da sitzen wenige sehr große Cs und noch ein paar kleine am FPGA. Da wusste der Hersteller vermutlich auch ob er von der Empfehlung abweichen darf und hat das gemacht. Ich will also nicht Dinge machen weil man sie schon immer so gemacht hat, sondern weil ich verstanden habe wie etwas funktioniert. Und dann sehe ich oft ein, dass man dann etwas so machen muss wie es schon immer gemacht wurde und mache das dann auch so.
:
Bearbeitet durch User
Du hast recht, dass man auch durch Verschlimmbessern lernen kann. Eigentlich oftmals nur so :-) aber du hast da ein Paket, in dem sich viele Baustellen verbergen! Da wäre doch erst einmal ein Plan zu überlegen, welche "isolierte" Probleme gelöst werden sollten. Im Moment hast du dich auf Jitter des Taktsignals eingeschossen. Gut, diverse Vorschläge für ein sauberes Signal sind gekommen. Hast du da mal was aufgebaut (hoffentlich nicht doch in ECL...) und sehen können, wie die Auswirkungen sind? Wäre immerhin ein Anfang...bevor du jetzt schon das nächste Problem dazu nimmst. Immerhin bleibt es vorerst doch eine Vermutung von dir, dass du ein Jitterproblem hast. Messen kannst du das aber nicht und so könnte das Problem doch ganz woanders liegen... Gruß Rainer
Angehängte Dateien:
-
no_delay.png
57 KB -
no_delay_falling.png
62 KB -
1us_delay.png
58 KB -
1us_delay_falling.png
65 KB -
10us_delay.png
70 KB -
10us_delay_falling.png
83 KB -
period_width.png
58 KB
Rainer V. schrieb: > Hast du da mal was > aufgebaut (hoffentlich nicht doch in ECL...) und sehen können, wie die > Auswirkungen sind? Wäre immerhin ein Anfang...bevor du jetzt schon das > nächste Problem dazu nimmst. Das mache ich gerade.Also ich bin gerade am Layout mit anderen Verstärkern und anderer Taktbeschaltung. Rainer V. schrieb: > Immerhin bleibt es vorerst doch eine > Vermutung von dir, dass du ein Jitterproblem hast. Messen kannst du das > aber nicht und so könnte das Problem doch ganz woanders liegen... So, ich habe mal gemessen. Ja, das ist in der Tat erstmal nur eine Vermutung. Ich nehme die ernst weil ich einsehe/verstanden habe, dass der Jitter einen Einfluss hat. Und weil hier im Forum andere Leute mich darauf hingewiesen haben. Im der Demoschaltung wird das ja auch mit retiming gemacht, also wird das wohl wichtig sein. Wie sehr der Jitter bei mir die Ursache ist und in wie weit das ganz andere Probleme sind weiß ich nicht. Ich dachte ich sei von dem Jitter nur wenig/kaum betroffen, weil der Takt aus einer jitterarmen Quelle kommt (Si510) und auch im FPGA nicht durch eine PLL/MMCM geht. Aber gut, jetzt gibt es Bildchen. Getriggert wurde immer auf die steigende Flanke. Und dann habe ich mir den Puls angeguckt, mal direkt den getriggerten, dann den 1 us später und zuletzt den 10 us später. Und dann gibt es noch die Statistik vom Oszi zu Periode und Pulsweite. Die Periode und Pulsweite wackeln also grob um 1 ns.
Auf den ersten Blick sieht das doch nicht schlecht aus! Was braucht denn der ADC? Steigende Flanke, Pegel oder fallende. Die steigende Flanke sieht für mich brauchbar aus...die fallende zappelt da was. Wie sahen denn die "alten" Signale aus? Gruß Rainer
Das sind die aktuellen Signale noch ohne retiming. Naja 1 ns Jitter ist schon recht viel bei 200 ns Periodendauer. Die fallende Flanke ist wichtig.
Gustl B. schrieb: > Die fallende Flanke ist > wichtig. Dann würde ich genau das auch messen. Also auf eine fallende Flanke triggern und dann die Stabilität von nachfolgenden fallenden Flanken auftragen. Das zeigt dir den Jitter deiner Abtastzeitpunkte. Hast du die 1ns vor oder nach deinem Digitalisolator gemessen? Den gemessenen Jitter dt kannst du mit der Anstiegsgeschwindigkeit deines Signals du/dt in einen Spannungsfehler du umrechnen. 1ns Abweichung des Abtastzeitpunkts machen bei einem 16 Bit ADC (um welchen gehts eigentlich genau) und bei deinem 100kHz full scale Sinus einen Fehler von 20 LSB. Da dürfte das Einsynchronisieren mit dem stabilen Takt schon sinnvoll sein. Das Ganze mit einem CPLD besser machen zu wollen, stelle ich mir dagegen als schwierig vor. Schnellere Teile gehen dann tendentiell zu differentiellen Logiksignalen, auch um den Jitter klein zu halten. Wobei diese Anforderungen sich ein Stück weit mit deinen Digitalisolatoren beißen dürften.
Gustl B. schrieb: > Das sind die aktuellen Signale noch ohne retiming Danke. Na dann warten wir doch mal die "neuen" Signale ab... Gruß Rainer
Gustl B. schrieb: > Die fallende Flanke ist wichtig. Dann schau Dir doch die an. Wenn dein Signal perfekt wäre, dürfte das Oszi nach 10 µs einen Fehler von +/- 100 ps haben, siehe Datenblatt (S. 19): https://beyondmeasure.rigoltech.com/acton/attachment/1579/f-0907/1/-/-/-/-/MSO5000_datasheet.pdf Nach 10 µs sieht man einen Peak-Peak-Jitter von 1 ns. Ich bin aber überfragt, wie man daraus den Cycle-to-Cycle-Jitter errechnet. Einfach durch 50 zu teilen ist vermutlich falsch (10 µs / 200 ns). Wenn man die ermittelten 270 ps nimmt, müßte sich bei einem 2 Vpp Sinus mit 100 kHz ein maximaler Amplitudenfehler von 170 µV ergeben (Standardabweichung). Zum Vergleich: Bei einem (idealen) 16-Bit-Wandler mit 2 Vpp Vollaussteuerung hat ein Bit eine Wertigkeit von 30 µV. Kannst du eine vergleichbare Messung des Taktes am Evaluationboard machen?
Achim S. schrieb: > Dann würde ich genau das auch messen. Also auf eine fallende Flanke > triggern und dann die Stabilität von nachfolgenden fallenden Flanken > auftragen. Das zeigt dir den Jitter deiner Abtastzeitpunkte. Prinzipiell richtig, aber hier egal. Das Signal kommt aus einem ODDR vom FPGA und zwar beide Flanken ohne Retiming. Die Flanken sollten also beide ähnlich jittern. > Hast du die 1ns vor oder nach deinem Digitalisolator gemessen? Das war zwischen Digitalisolator und ADC. Achim S. schrieb: > Den gemessenen Jitter dt kannst du mit der Anstiegsgeschwindigkeit > deines Signals du/dt in einen Spannungsfehler du umrechnen. 1ns > Abweichung des Abtastzeitpunkts machen bei einem 16 Bit ADC (um welchen > gehts eigentlich genau) und bei deinem 100kHz full scale Sinus einen > Fehler von 20 LSB. Da dürfte das Einsynchronisieren mit dem stabilen > Takt schon sinnvoll sein. Das Ganze mit einem CPLD besser machen zu > wollen, stelle ich mir dagegen als schwierig vor. Danke! Mit dem CPLD wollte ich auch nicht #CNV erzeugen, sondern nur ein #CNV_Enable das dann mit einem FF retimed wird. Ich dachte mir eben, dass wenn ich da schon einen Taktgeber zum ADC packe, dann kann ich daraus auch gleich das #CNV_Enable und SCLK erzeugen. Das ginge mit einem Zähler une ein paar Gattern oder eben einem CPLD. Aber weil der Jitter doch recht gering ist, werde ich den sauberen schönen Takt auf der ADC Platine zum retimen verwenden und diesen Takt auch zum FPGA führen, dort mit diesem Takt das #CNV_Enable erzeugen und das dann wieder zum ADC führen. Ja, das macht etwas Latenz, aber die ist mir egal. Bernd schrieb: > Dann schau Dir doch die an. Da das Signal bisher nur Bits sind die aus einem ODDR herausgeschoben werden ist das wohl egal welche Flanke. > Wenn dein Signal perfekt wäre, dürfte das Oszi nach 10 µs einen Fehler > von +/- 100 ps haben, siehe Datenblatt (S. 19): > https://beyondmeasure.rigoltech.com/acton/attachment/1579/f-0907/1/-/-/-/-/MSO5000_datasheet.pdf Danke! > Nach 10 µs sieht man einen Peak-Peak-Jitter von 1 ns. > Ich bin aber überfragt, wie man daraus den Cycle-to-Cycle-Jitter > errechnet. > Einfach durch 50 zu teilen ist vermutlich falsch (10 µs / 200 ns). Naja, diese 1 ns bleibt recht konstant, auch nach 100 us ist das noch nicht mehr weil das vermutlich gleichverteilt ist. Im Schnitt hebt sich der Jitter auf. Der Takt ist jetzt gerade ein Si510 Oszillator, der geht in das FPGA und damit wird das ODDR getaktet. Aber da ist keine PLL dazwischen. > Wenn man die ermittelten 270 ps nimmt, müßte sich bei einem 2 Vpp Sinus > mit 100 kHz ein maximaler Amplitudenfehler von 170 µV ergeben > (Standardabweichung). > Zum Vergleich: Bei einem (idealen) 16-Bit-Wandler mit 2 Vpp > Vollaussteuerung hat ein Bit eine Wertigkeit von 30 µV. Ja, ich habe dieses Problem jetzt auf der Liste, wird bearbeitet, dauert aber noch. Weil wenn ich eine Platine baue, dann will ich da mehrere Dinge testen, also andere Verstärker, Analogfilter, ... > Kannst du eine vergleichbare Messung des Taktes am Evaluationboard > machen? Das habe ich nicht.
Angehängte Dateien:
-
fpga_200ns_5ns.png
68 KB -
fpga_200ns_1ns.png
60 KB -
fpga_1us_5ns.png
69 KB -
fpga_1us_1ns.png
55 KB -
fpga_10us_5ns.png
48 KB -
fpga_10us_1ns.png
59 KB -
fpga_100us_5ns.png
71 KB -
fpga_100us_1ns.png
65 KB -
iso_200ns_5ns.png
64 KB -
iso_200ns_1ns.png
80 KB -
iso_1us_5ns.png
64 KB -
iso_1us_1ns.png
82 KB -
iso_10us_5ns.png
63 KB -
iso_10us_1ns.png
83 KB -
iso_100us_5ns.png
64 KB -
iso_100us_1ns.png
79 KB
So, gemessen. Und ja, die Flanke war wirklich egal, auch bei der flallenden Flanke ist jetzt grob 1 ns Jitter drauf. Aber eben nur wenn das Signal durch den Isolator durch ist. Vor dem Isolator, also am Ausgang des FPGAs sieht es sehr viel jitterfreier aus. Tja, jetzt weiß ich, dass das jittert und werde das so bauen wie schon weiter oben beschrieben. Das war jetzt also nur noch eine Bestätigung.
Gustl B. schrieb: > Aber eben nur wenn > das Signal durch den Isolator durch ist. Vor dem Isolator, also am > Ausgang des FPGAs sieht es sehr viel jitterfreier aus. Welchen Digitalisolator verwendest du denn genau? Einen ADUM von Analog Devices? Es gibt in der ADUM-Reihe zwei unterschiedliche Arbeitsweisen. Die eine Methode besteht darin, eine RF-Spannung über den isolierenden Übertrager zu schicken und auf der Sekundärseite gleichzurichten. Diese RF-Spannung wird an- oder ausgeschaltet, je nach gewünschter Schaltflanke. Ein Beispiel dafür ist der ADUM1100N (siehe Fig. 10 von https://www.analog.com/media/en/technical-documentation/data-sheets/ADuM110N.pdf) Bei dieser Methode wirst du immer einen gewissen Jitter bekommen, zumindest bei der Flanke, bei der die RF abgeschaltet wird (je nachdem bei welcher Phaselage das Abschaltsignal die RF gerade erwischt geht sie schneller oder langsamer aus, der Jitter sollte mindestens in der Größenordnung einer Periode der RF liegen.) Daneben gibt es ADUM-Isolatoren, die pro Schaltflanke nur einen einzelnen 2ns Puls über den Übertrager schicken (aus der Pulspolarität ergibt sich dann die Polarität der Schaltflanke). Ein Beispiel dafür ist der ADUM1100 (wie oben, nur ohne den Buschstaben N am Ende). Das hat im Prinzip den Nachteil, dass eine gewisse Mindestfrequenz der Pulse benötigt wird - sonst springt ein Watchdog ein, der zsätzliche Pulse anfordert. Aber wenn du in deiner Anwendung diese Mindestfrequenz sicherstellst (laut https://www.analog.com/media/en/technical-documentation/data-sheets/ADUM1100.pdf brauchst du mindestens 1,2Mb/s), dann könnte ich mir vorstellen, dass die Flanke eines einzelnen Spannungspuls weniger Jitter in die Übertragung einbringt als die An- bzw. ausschwingende RF. Wenn du weniger Jitter im Digitalisolator willst, lohnt es sich vielleicht auch, das mal zu prüfen. Im Fall des ADUM1100 ist nur bei der N-Variante der Jitter spezifiziert. Die Spec liegt mit typ. 380ps Peak-Peak unter dem, was du in deiner Anwendung siehst.
Achim S. schrieb: > Welchen Digitalisolator verwendest du denn genau? Einen ADUM von Analog > Devices? Die Si866x hier: https://www.silabs.com/documents/public/data-sheets/Si866x.pdf ADUM hatte ich mir auch angeguckt, aber die sind nur bei 5 V schnell und der ADC hat ein 2,5 VDD. Und auch bei 5 V schaffen die ADUMs "nur" 100 MBit/IO, ich bräuchte aber idealerweise 105 MBit/s. 100 MBit/s gehen natürlich auch, verwende ich derzeit sogar, ist aber nicht ideal für die maximale Abtastrate. Aber ich baue das ja jetzt sowieso mit gutem Taktgeber direkt auf der ADC Platine und retiming per FF. Da muss jetzt nur noch das #CNV_Enable über den Isolator vom FPGA zum ADC. Weil aber dieses #CNV_Enable synchron zu dem retiming Takt erzeugt werden sollte, führe ich diesen Takt auch von der ADC Platine über den Isolator zum FPGA. Mit Retiming sollten wenige ns Jitter egal sein. Die andere Option wäre, wie oben geschrieben, das #CNV_Enable und sogar SCLK direkt auf der ADC Platine zu erzeugen. Entweder mit einem Binärzähler und ein paar Gattern oder in einem CPLD. Das werde ich jetzt aber nicht machen. Vielleicht werde ich das aber als Bestückungsoption vorsehen und erstmal unbestückt lassen. Mal gucken. Das scheitert am schnellen Digitalzähler, weil ECL Logik möchte ich nicht verwenden.
Gustl B. schrieb: > Das scheitert am > schnellen Digitalzähler, weil ECL Logik möchte ich nicht verwenden Hast du dir mal die 74xxS angeschaut? Die sind auch verdammt schnell und brauchen das ganze "Drumherum" der ECL-Typen nicht. Und vor allem verpulfern sie deutlich weniger Leistung/Wärme als die ECL, obwohl sie auch schon gehörig Strom brauchen. Von nix kommt nix :-) Gruß Rainer
Der hier ist schnell genug: https://www.onsemi.com/pub/Collateral/MC74AC4040-D.PDF Aber wenn ich das #CNV_Enable sowieso im FPGA erzeuge brauche ich den nicht. Das wäre eben eine zusätzliche Bestückungsoption die ich testen könnte. Aber weil das mit dem FPGA ja auch funktionieren sollte brauche ich das nicht.
udok schrieb: > Den möchte ich sehen, der mehr als 100 dB THD+N schafft, > über sagen wir mal +- 5 Grad Temperaturschwankung. Ich habe schon mit weniger Bits 100dB geschafft und zwar nicht nur bei Messfrequenz 1000Hz wo untenrum alles missachtet wird. > Bei > 120 dB, wo es interessant wird, muss der Teiler mit den Mosfet > Schaltern auf 5 Milliohm genau sein, und dass bei R=10kOhm, Nur, wenn du unkalibriert arbeitest. Es gibt natürlich Spezialisten, die sich hinsetzen und Bauteile selektieren und dann die DIY-Leute kritisieren, dass es nicht möglich sei. Es gibt aber auch Leute, die etwas ingenieurwissenschaftlicher denken und das Ganze kalibieren. Und so machen es auch die meisten auf DIY-Audio: Der FPGA kriegt eine Kalibiertabelle hinterlegt. Gegen den Temperaturdrift hilft regelmäßiges Nachkalibrieren und/vor ein Kennlinienfeld. Es ist natürlich auch einsichtig, dass man nicht - wie man naiv meinen könnte - mit einem mathematisch perfekten R2R arbeiten kann, sondern man muss die Bautteilstreuung mit einbeziehen, d.h. der jeweils geringere Widerstand muss größer sein, als 0.5 der Vorstufe, weil man nicht garantieren kann, dass deren Summe insgesamt genau 0,5 ergeben wird. Auf diese Weise bekommt man mit 32 Bit auch niemals 32 Bit hin, auch wenn das immer wieder behauptet wird. Da liegen die DIY Leute wiederum daneben. > Abgesehen sind die R2R DACs berühmt für ihre Glitches beim Umschalten... Wenn man sie falsch baut, ja. Wenn man aber das Analogsignal mit einem analogen Setup-Hold-Glied versieht, ist das Thema erledigt. Was du nicht genannt hast und von anderen gerne eingeworfen wird: Mr. X schreibt regelmäßig >Euro DIY DACs haben mehr Jitter, wegen der FPGA-PLL und der >ungleichmäßigen Ausgänge und Ausgangsbelastungen, weil die Regelung des >Ausgangs fehlt Jitter ist kein Problem, weil der DAC-Teil, das Analog-Gate und FPGA einen eigenen Takt haben und am Ende nur das Signal nach dem Gate zählt Ausgangsfehler sind kein Problem, weil man die berechnen und vorkompensieren kann, zudem kann man die Ausgänge mit dem DAC-Takt registrieren und asynchron auslesen, wobei man die IOs so einstellt, dass sie nacheinander schalten und so dass SSO-Problem lindern. Damit ist man diesbezüglich sogar besser dran, als mit einem synchronen parallelen Betrieb zu einem CHIP-DAC. Kein Witz.
Also ... das mag ja alles stimmen, aber für mich ist das was die Audioleute da abziehen krass überzogen. Ob mir ein Musikstück gefällt hängt von ganz anderen Kriterien ab wie ob da noch ein minimales Rauschen zu hören ist. Ich habe hier ganz nochmale billo Audiohardware und hatte da nie Probleme. Was tatsächlich ärgerlich sind Störungen die kein Rauschen sind. Mein alter Acer Laptop z. B. hat unter last gefiept. Aber nicht nur das Gerät, sondern das war auch auf angeschlossenen Kopfhörern zu hören. Das war irre nervig. Aber sonst finde ich das genauso sinnfrei wie 4K Filme, der Film wird dadurch nicht besser. Urlaubserinnerungen werden nicht schöner nur weil sie heute mit vielen Megapixeln festgehalten wurden. Ich verstehe natürlich auch die Leute die das trotzdem machen, da geht es eben um die Grenze des Machbaren, quasi als Sport.
Gustl B. schrieb: > Derzeit verwende ich diesen OPV > https://www.analog.com/media/en/technical-documentation/data-sheets/LTC6363.pdf > auf Seite 15 oben in der Mitte sieht man, dass ab ein paar 10 kHz die > harmonische Verzerrung deutlich nach oben geht. Wieviel dBc muss der Verstärker für deine Messungen denn schaffen?
Gute Frage. So mit 90 wäre ich zufrieden wenn das bis hoch zu 1 MHz geht.
Jürgen S. schrieb: > udok schrieb: >> Den möchte ich sehen, der mehr als 100 dB THD+N schafft, >> über sagen wir mal +- 5 Grad Temperaturschwankung. > Ich habe schon mit weniger Bits 100dB geschafft und zwar nicht nur bei > Messfrequenz 1000Hz wo untenrum alles missachtet wird. > >> Bei > 120 dB, wo es interessant wird, muss der Teiler mit den Mosfet >> Schaltern auf 5 Milliohm genau sein, und dass bei R=10kOhm, > Nur, wenn du unkalibriert arbeitest. Es gibt natürlich Spezialisten, die > sich hinsetzen und Bauteile selektieren und dann die DIY-Leute > kritisieren, dass es nicht möglich sei. > > Es gibt aber auch Leute, die etwas ingenieurwissenschaftlicher denken > und das Ganze kalibieren. Und so machen es auch die meisten auf > DIY-Audio: Der FPGA kriegt eine Kalibiertabelle hinterlegt. Gegen den > Temperaturdrift hilft regelmäßiges Nachkalibrieren und/vor ein > Kennlinienfeld. > > Es ist natürlich auch einsichtig, dass man nicht - wie man naiv meinen > könnte - mit einem mathematisch perfekten R2R arbeiten kann, sondern man > muss die Bautteilstreuung mit einbeziehen, d.h. der jeweils geringere > Widerstand muss größer sein, als 0.5 der Vorstufe, weil man nicht > garantieren kann, dass deren Summe insgesamt genau 0,5 ergeben wird. > Auf diese Weise bekommt man mit 32 Bit auch niemals 32 Bit hin, auch > wenn das immer wieder behauptet wird. Da liegen die DIY Leute wiederum > daneben. > >> Abgesehen sind die R2R DACs berühmt für ihre Glitches beim Umschalten... > Wenn man sie falsch baut, ja. Wenn man aber das Analogsignal mit einem > analogen Setup-Hold-Glied versieht, ist das Thema erledigt. > > Was du nicht genannt hast und von anderen gerne eingeworfen wird: > > Mr. X schreibt regelmäßig >>Euro DIY DACs haben mehr Jitter, wegen der FPGA-PLL und der >>ungleichmäßigen Ausgänge und Ausgangsbelastungen, weil die Regelung des >>Ausgangs fehlt > > Jitter ist kein Problem, weil der DAC-Teil, das Analog-Gate und FPGA > einen eigenen Takt haben und am Ende nur das Signal nach dem Gate zählt > Ausgangsfehler sind kein Problem, weil man die berechnen und > vorkompensieren kann, zudem kann man die Ausgänge mit dem DAC-Takt > registrieren und asynchron auslesen, wobei man die IOs so einstellt, > dass sie nacheinander schalten und so dass SSO-Problem lindern. > Damit ist man diesbezüglich sogar besser dran, als mit einem synchronen > parallelen Betrieb zu einem CHIP-DAC. Kein Witz. In der Theorie kann man das, und vieles andere machen. Nur in der Praxis sieht man den Clock trotz Sample-Hold am Ausgang, und die lästigen nichtlinearen PN Kapazitäten spielen eine Rolle, und der Aufwand geht exponentiell hoch. Es wird gute Gründe geben, warum die Burr-Brown Ingenieure um die Jahrtausendwende das R2R Konzept (PCM1792 war einer der letzten), das sie über mehr als 15 Jahre verfeinert, und mit etlichen Patenten verteidigten, hingeschmissen haben. Interessanterweise machen ja auch die Sigma-Delta DACs heute ganz ähnliche Tricks, die haben inzwischen ja auch mehr als 1 Bit, und damit Probeme mit Toleranzen und Nichtlinearitäten.
Wolfgang schrieb: > Gustl B. schrieb: >> Derzeit verwende ich diesen OPV >> https://www.analog.com/media/en/technical-documentation/data-sheets/LTC6363.pdf >> auf Seite 15 oben in der Mitte sieht man, dass ab ein paar 10 kHz die >> harmonische Verzerrung deutlich nach oben geht. > > Wieviel dBc muss der Verstärker für deine Messungen denn schaffen? Was willst du denn überhaupt messen, da ist doch nichts interessantes mehr??
Ich will gar nix messen, das ist ein Lernprojekt. Ich versuche mir Stück für Stück Dinge beizubringen. Wie man die Beschaltung macht dass sie für meine Anwendungen gut genug ist weiß ich bereits. Jetzt möchte ich das noch optimieren. Ich werde da jetzt auch andere Analogfilter verbauen und nicht nur ein RC vor dem ADC Eingang. Wenn das nicht wie gewünscht funktioniert ist es nicht schlimm.
Na ja, und was ist jetzt die Anwendung? Oder ist das streng geheim? Was willst denn da lernen, was nicht schon in der Application Note drinnen steht?
Jetzt mal ganz lustig reingeworfen : Hubraum kann man nur durch mehr Hubraum ersetzen! (oder so ähnlich) Gruß Rainer
Das wird eine Hardware und die kommt dann in eine Schublade und bleibt dort. Es ist ein Unterschied zwischen Appnote lesen und das selber mal gemacht haben. Hast du keine "Projekte" nur um mal etwas mit noch unbekannter Hardware gemacht zu haben?
Hi, ich wollte damit nur sagen, dass es manchmal einfach reicht, die beteiligten Macher mal eine 10er-Potenz höher zu bringen :-) Mal einen OP mit 800MHz versuchen? Du bist aber immer noch am Takt oder?! Sorry, wenn ich jetzt nicht ganz folgen kann. Gruß Rainer
Gustl B. schrieb: > Das wird eine Hardware und die kommt dann in eine Schublade und > bleibt > dort. > > Es ist ein Unterschied zwischen Appnote lesen und das selber mal gemacht > haben. Hast du keine "Projekte" nur um mal etwas mit noch unbekannter > Hardware gemacht zu haben? Deine Zeit möchte ich auch haben :-)
@ Rainer: Ja, Schaltung und Layout für den Takt sind fertig. Jetzt kümmere ich mich noch um andere OPVs. Wenn dann das ganze Layout fertig ist wird bestellt. Ich möchte Platine und Bauteile noch vor den Feiertagen auf dem Tisch haben. Mal gucken ... @ udok: Die letzten beiden Jahre war ich Referendar und das war ziemlich anstrengend. Dieses Schuljahr oder zumindest das erste Halbjahr mache ich eine Auszeit um mich mehr mit Hobbys zu beschäftigen. Vielleicht mache ich das ja irgendwann mal beruflich oder fange im Herbst eine Ausbildung in dem Bereich an.
Gustl B. schrieb: > Ich möchte Platine und Bauteile noch vor den Feiertagen auf > dem Tisch haben. Na dann aber los!! Viel Spass beim Basteln. Gruß Rainer
Habe den Informations-Wust von drei jahren jetzt nicht voll im Überblick und hatte auch keine Lust das im Detail durch- zuarbeiten, aber irgenwie fehlt mir die Berücksichtigung des ADC-Taktes. Der ADC-Takt beeinflusst entscheidend was an Signalgüte am Ausgang herauskommt. In professionellen Geräten wird erheblicher Aufwand getrieben um diesen speziellen Takt so sauber wie möglich zu bekommen. Alles was an Phasenrauschen und Nebenlinien (also Nichtharmonischen) im ADC-Takt enthalten ist kommt ungeschönt (unverschlechtert/unverbessert) am Sample-Ergebnis heraus ohne dass man es jemals wieder herausfiltern könnte. Ich hoffe das hat sich jemand vor Augen gehalten ....
@ Rainer: Danke! @ Pessi Mist: Ja, genau dieser Punkt wurde diskutiert und wird behoben.
So, da bin ich wieder. Platine ist da und ich habe jetzt mal mit der Bestückung angefangen. Und habe ein Problem: Bei einem FF NL17SZ74 https://www.onsemi.com/pub/Collateral/NL17SZ74-D.PDF sehe ich am Ausgang #Q ein Signal, aber der Ausgang Q den ich verwenden will liegt nur auf der Versorgungsspannung. Eingang CP und #CLR habe ich angeguckt und sehen aus wie gewünscht. D liegt auf Versorgungsspannung (gemessen) und #PR liegt auf Masse (gemessen). Versorgung liegt natürlich auch an und Masse ist ebenfalls verbunden. Ich finde das sehr seltsam, dass ich an #Q etwas sehe. Habe den Stein schon durch einen baugleichen ersetzt. Die Ausgänge sind bisher beide unbelastet, also offen und haben auch keinen Kurzschluss nach Masse oder Versorgung. Ist das ein typisches Verhalten bei fehlerhafter Beschaltung?
Angehängte Dateien:
-
RigolDS1.png
110 KB -
RigolDS0.png
120 KB -
counter_sch.png
12 KB
Oh ich habe doch eine Frage: So ein FF funktioniert doch so, wenn Resettet wird hat der nach dem Reset den Zustand vom Preset. Wenn dann der nächste Takt kommt, dann ist das gespeichert was zum Zeitpunkt der Taktflanke am Dateneingang D anliegt. Sehe ich das richtig? Dann habe ich die Schaltung wie im Anhang. Der Zähler zählt und ab und zu geht RESET_COUNTER kurz hoch. Funktioniert. Das ist auf den Oszibildchen das gelbe Signal. Das AND Gatter vor dem FF gibt einen hohen Pegel aus wenn die beiden LSBs des Zählers high sind. Also bei 3, 7, 11, 15, ... das funktioniert auch. Das ist das blaue Signal. #Preset vom FF liegt auf Masse. Das bedeutet, dass nach dem Reset eine 1 gespeichert ist. Der Dateneingang D liegt ebenfalls auf Masse. Für mich müsste das also so sein, der Resetpuls (gelb) kommt, die 1 aus dem Preset wird geladen und bleibt so lange, bis der erste Takt (blau) kommt und dann die 0 von D lädt. Der Ausgang Q müsste also zwischen gelben Puls und erstem blauen Puls danach high sein. Und #Q genau umgekehrt. Ich betrachte hier #Q (lila), ja, den Inverter könnte man weglassen, aber ich hatte #Preset und D genau invertiert belegt, das ist jetzt aber egal. Die Frage ist: Warum ist #Q nur für so kurze Zeit low und nicht bis die nächste blaue Flanke kommt? Danke! Edit: Männo, ich muss natürlich den Reset invertieren ... mal gucken ob sich da was basteln lässt. Und den #Preset darf ich auch nicht dauerhaft Low lassen, aber das war er in der Ursprünglichen Bestückung auch nicht, da war #Preset High und D Low. So werde ich das jetzt auch umbasteln aber eben noch einen Inverter vor das #CLR setzen. Dass die Signale so schlimm aussehen liegt an der Masseanbindung. 3 Tastköpfe kann ich nicht sinnvoll halten, also hatte ich da Fädeldraht dran und somit eine eher große Masseschleife. Mit der Massefeder am Taskopf sieht das deutlich besser aus. Edit:
:
Bearbeitet durch User
Also schön, wieder was zu hören...aber jetzt galloppierst du irgendwie in die Pampa oder?! Nimm mal alles zurück, bis auf einfache, nachprüfbare Sachen:-) Gruß Rainer
Angehängte Dateien:
-
RigolDS2.png
120 KB -
RigolDS10.png
54 KB -
RigolDS11.png
53 KB
Nene, sieht gut aus. Hab das jetzt umgebaut und bekomme ein schönes #CNV_Enable lokal erzeugt ganz ohne FPGA. Dann habe ich noch dieses Enable retimed mit einem FF und dann hat das ja mal richtig hybsche Flanken. Auch dazu ein Bildchen. Eine SPI SCLK erzeuge ich auch lokal, aber da fehlt mir am Anfang ein halber Takt ... da weiß ich noch nicht ob das a) stört oder b) wie ich das löse.
Man oh man...scheint gut zu sein! Insgesamt - also in deiner Applikation auch?? Gratulation! Rainer
Angehängte Dateien:
-
RigolDS13.png
52 KB
Gute Frage, weiß ich noch nicht, ADC ist noch lange nicht bestückt. Jetzt versuche ich gerade die Clock am AND Gate für SCLK etwas zu verzögern. Habe gerade schon einen Inverter versucht, aber die Verzögerung muss doch etwas geringer sein, jetzt setze ich mal ein AND Gate dazwischen. Edit: Genug für heute. Das SPI das vorher das FPGA gemacht hat wird jetzt lokal erzeugt und sieht gut aus. Die Schalung braucht 50 mA bei 5 V inklusive der beiden LDOs und Taktgeber aber noch ohne ADC und Digitalisolatoren und sonstiges. Ja, im Bildchen sieht das Signal wieder nicht so fein aus, aber das sind wieder Masseschleifen beim Messen. Gibt es eigentlich kleine leichte Tastköpfe? Müssen jetzt nicht irre schnell sein, aber gerne so, dass da vorne nur zwei Pads sind an die man dann selber dünnen Draht ranlötet. Oder vielleicht auch zwei kleine Klemmen vorne. Und eben leicht. Die hier vom Oszi sind zwar handlich aber ... wie soll ich das beschreiben. Ich habe nahe an einem IC auf eine freigekratzte Leitung (das musste ich sowieso machen) einen kurzen Draht gelötet, wenige mm lang und dann habe ich dort die Klemme vom Tastkopf angeschlossen. Aber der Taskopf wird ja in der Mitte dicker und hinten ist noch Gewicht dank Kabel. Also hatte das eine Hebelkraft und hat mir die Leiterbahn weiter von der Platine gezogen. Nicht schön.
:
Bearbeitet durch User
Ja ich sollte #CNV etwas länger machen. Also so würde es schon funktionieren aber längeres #CNV gibt kleineren Fehler. Nun, jetzt habe ich einen 104 MHz Oszillator und das teile ich durch 20. Etwas mehr weil der Reset vom Zähler ja auch Zeit braucht, aber eben grob 20. Das gibt eine Samplerate von >5 MSample/s, also mehr als die Spezifikation vom ADC. Ich werden auch noch folgendes testen: Takt durch 21 teilen (4,952 MSample/s) und dann #CNV um einen Takt länger machen. Statt derzeit grob 38 ns wäre #CNV dann 48 ns lang. Wie man im Datenblatt https://www.analog.com/media/en/technical-documentation/data-sheets/232516fa.pdf Seite 9 Mitte links sieht wäre das vorteilhaft. Mal gucken.
Es gab frueher einen Spannungsteilertastkopf bei dem im Prinzip drei Widerstaende in Reihe verbaut waren. Die Messelektroden gingen vom mittleren Widerstand weg. Es war damit moeglich ohne dass es knallte an Fersehern ohne galvanische Trennung und Trenntrafo zu messen. Denke, do eteas muesstest Du Dir basteln.
Dieter schrieb: > an Fersehern ohne galvanische Trennung und Trenntrafo zu messen = Aus Versehen ohne galvanische Trennung durch Trenntrafo gemessen? Da kam es sicher zu "lustigen" Effekten - magst Du sie aufzählen?
Aus welchem Material ist denn die Seele von diesen Oszi-Tastkopf-Kabeln? Ich habe jetzt einen alten Tastkopf zerlegt und ja, den kann man deutlich kleiner bauen, aber die Seele des Kabels lässt sich nicht verlöten. Die war auch gequetscht beim Tastkopf. Oder hier https://www.batronix.com/images/generated/rp5600-1200x735-White-b.jpg links am Rand oben unter dem Schwarzen Dreieck. Das sieht wie ein Aufsteckaufsatz aus. Kann man sowas auch einzeln kaufen? Wie nennt man sowas?
:
Bearbeitet durch User
So, habe jetzt lange mit dem SPI Timing gespielt. Wenn ich da 16 halbwegs schöne Takte haben will bleibe ich bei 38 ns für #CNV. Ich erzeuge mit SCLK mit einem AND Gatter, also #CNV_Enable AND CLK = SCLK. Aber damit der erste und der letzte SCLK Puls gut aussieht muss ich CLK und #CNV_Enable so hinschieben, dass die sich nicht halb überlagern. Wenn in der Mitte von einem CLK High das #CNV_Enable High geht, dann bekäme ich nur einen halben Puls auf SCLK. Ich habe mich entschieden CLK zu verzögern. Und zwar mit AND Gattern weil ich da etwas mehr bestellt habe. Das funktioniert auch wunderbar (nach ein paar Stunden Drahtverfädelung) aber ich habe eine Frage dazu: Ich habe jetzt CLK an beide Eingänge des AND angeschlossen. Am Ausgang bekomme ich ein verzögertes CLK. Macht es einen Unterschied ob ich CLK an beide Eingänge anschließe oder es nur an einen Eingang anschließe und den anderen Eingang fest auf VCC lege? Ich vermute nein, aber vielleicht gibt es da ja Eigenheiten die man beachten sollte. Jedenfalls habe ich jetzt 3 AND Gatter in Reihe für die nötige Verzögerung. Volle 5 MSample/s kommen nicht bei rum, aber 4,9XX. Die Tage wird dann weiterbestückt.
So, ein kleines Update: Platine ist da wurde in verschiedenen Varianten bestückt. Zum SPI: Ich konnte lokal beim ADC mit dem sauberen Takt, einem Zähler IC und ein paar Gattern schön #CNV und auch SCK erzeugen. #CNV hat zwar auf der fallenden Flanke vermutlich weiterhin etwas Jitter, der ist mit meinem Oszi aber nicht mehr messbar. Bzw ich weiß nicht ob ich den Jitter vom Oszi oder den von #CNV sehe. Die Variante nur mit dem retiming FF funktioniert ebenfalls. Da reiche ich den sauberen Takt über den Digitalisolator zum FPGA, der erzeugt intern mit einem Zähler und DDR-IOs ein #CNV_Enable, dieses geht dann wieder über den Digitalisolator zurück zum ADC und wird dort vor dem ADC mit dem lokalren sauberen Takt und einem FF eingetaktet. Auch da ist der Jitter für mich nicht messbar. An der Stelle bin ich also sehr zufrieden. Dann gibt es den OPVs vor den ADC Eingängen und ... nun, "da schwingt etwas". Was das genau ist ist noch unklar. Und es ist auch unklar ob das nicht das Oszi ist. Und zwar sehe ich eigentlich überall unterschiedlich stark ein Signal etwas über 300 MHz. Auf der Versorgung schwach, am Ausgang des OPV stärker, aber auch am unbestückten OPV (eben schwächer). Tja aber eben nur wenn am Oszi 20 mV/Div einstelle. Bei 10 mV/Div und 5 mV/Div ist es teilweise sichtbar aber sehr viel geringer. Sehr seltsam. Ich messe natürlich mit der kurzen Massefeder. Momentan habe ich die FPGA Platine in Verdacht. Da verwende ich zwar keine so hohen Frequenzen, aber da könnte ja auch etwas schwingen. Jedenfalls ist das auch dort gut sichtbar. Mal gucken ob ich das wegbekomme.
Gustl B. schrieb: > Da reiche > ich den sauberen Takt über den Digitalisolator zum FPGA, der erzeugt > intern mit einem Zähler und DDR-IOs ein #CNV_Enable, dieses geht dann > wieder über den Digitalisolator zurück zum ADC und wird dort vor dem ADC > mit dem lokalren sauberen Takt und einem FF eingetaktet. Auch da ist der > Jitter für mich nicht messbar. Das klingt doch gut. > Dann gibt es den OPVs vor den ADC Eingängen und ... nun, "da schwingt > etwas". Welchen Typ OPV hast Du genau verwendet und wie ist dieser beschaltet? Einige OPV mögen es nicht, wenn die Verstärkung zu gering ist. Stichwort: unity-gain stable Eine zusätzliche Kapazität (wie z.B. der Tastkopf vom Oszi) kann da Wunder wirken. Lesestoff zum Thema: https://www.ti.com/lit/an/slyt087/slyt087.pdf
Tja, es liegt sehr wahrscheinlich nicht an den OPVs. Denn auch wenn ich von der FPGA Platine die ADC Platine abstecke kann ich an der FPGA Platine diese Störung messen. Jetzt ist die FPGA Hauptplatine selbst erstellt und hat einen DCDC drauf und wird über USB versorgt. Darauf sitzt ein FPGA Modul von Trenz. Also hatte ich den DCDC in verdacht, aber ich kann das auch an einem älteren FPGA Board messen an dem ich noch statt DCDC einen LDO drauf hatte. Tja ... Ich werde die Tage mal Fotos machen, darin markieren wo genau ich gemessen haben und auch die zu der jeweiligen Messung gehörenden Oszibildchen hochladen. Vielleicht jage ich Gespenster.
:
Bearbeitet durch User
Gustl B. schrieb: > Und zwar sehe ich eigentlich überall unterschiedlich > stark ein Signal etwas über 300 MHz. Gustl B. schrieb: > Also hatte ich den DCDC in verdacht DC/DC-Wandler arbeiten mit Frequenzen in der Größenordnung von 20 kHz bis 1 MHz. Das passt nicht, zu niedrig. Die untere VCO-Frequenz von MMCM und PLL liegt bei 600 bzw. 800 MHz. Das ist zu hoch. Ist irgendwo DDRx-RAM verbaut?
Ja, der DCDC ist drunter, dachte vielleicht Obertöne?! Ne, kein RAM, keine PLL/MMCM, nur ein 100 MHz Takt für das ganze Design. Ich werde noch mit unkonfiguriertem oder einem Design ohne Takt gucken. Und auch mal mit einem anderen Oszi.
Angehängte Dateien:
-
ADC_Short.jpg
220 KB -
ADC_Signal.png
16 KB -
ADC_Spek.png
62 KB -
ADC_Short.png
510 KB
Gut, wenn ich im FPGA keinen Takt verwende sehe ich den auch nicht auf der Versorgung. Ist eben ein recht fettes Design (>90%). Ich hatte mich da eigentlich auf Trenz verlassen, dass das FPGA Modul gut entkoppelt ist. Naja, ist es eigentlich auch. Die Störung ist je recht schwach sichtbar. Jetzt habe ich der isolierten Platine vor dem DCDC und auch dahinter etwas mehr Kapazität spendiert und sehe auf der isolierten Seite jetzt "nurnoch" den Takt, den ich ja jetzt lokal beim ADC habe. Das sind 104 MHz. Und die sind auf der Versorgung sichtbar mit ca. 20 mV Amplitude. Tja ... ist das OK als Versorgung für die OPVs und den ADC? Wenn ich einen OPV bestücle, dass ist das auch an dessen Ausgang sichtbar. Ich erkläre mir das so: Der fängt das am Eingang ein, verstärkt es und dann sieht man das am Ausgang. Oder es ist ein "Gespenst". Wenn ich die Isolierte Masse gegen den OPV Ausgang messe, dann könnte es ja auch sein, dass die isolierte Masse schwingt (mit den Versorgungen) und der Ausgang des OPVs eigentlich sauber ist. Kann das sein? Jedenfalls, wenn ich den Eingang des ADCs kurzschließe an der Stelle die auf dem Bild zu sehen ist (die OPVs sind nicht betstückt), dann sieht das Spektrum gut aus. Also da scheint die Störung keinen oder kaum Einfluss zu haben. Ups, sorry, falsches Bild ohne Markierung. Also nur in einem Layout ist die Markierung was ich kurzgeschlossen habe.
:
Bearbeitet durch User
Gustl B. schrieb: > Und die sind auf der Versorgung sichtbar mit ca. 20 mV Amplitude. Zeig mal bitte einen Screenshot vom Oszi. Und als Vergleich, statt dem Tastkopf ein 50 Ohm-Widerstand am Eingang (Eigenrauschen).
Angehängte Dateien:
-
Keysight_10mV.png
17 KB -
Keysight_20mV.png
12 KB -
Keysight_50R_10mV.bmp
1,2 MB -
Rigol_50R_10mV.png
76 KB -
Rigol_50R_20mV.png
84 KB -
Rigol_10mV_10ns.png
81 KB -
Rigol_20mV_10ns.png
100 KB -
Rigol_50mV_10ns.png
73 KB -
Rigol_10mV_200ns.png
86 KB -
Rigol_20mV_200ns.png
110 KB -
Rigol_50mV_200ns.png
79 KB -
Suppy_mess.png
45 KB
So, jetzt mal ein paar Bildchen. Einen Fehler habe ich mittlerweile selbst gemerkt: Bei Messungen mit dem 50 Ohm Abschluss habe ich nicht auf 1:1 umgestellt. Was mich etwas sehr verwirrt ist, dass die Messungen mit 10 mV/Div beim Rigol deutlich besser aussehen als die mit 20 mV/Div. Ich habe den Trigger jeweils so eingestellt, dass ich die Störung möglichst gut sehen konnte.
Angehängte Dateien:
-
100kHz_Oszi.png
130 KB -
500kHz_Oszi.png
95 KB -
1MHz_Oszi.png
130 KB -
2MHZ_Oszi.png
180 KB -
100kHz_Oszi_100kHz_Span.png
150 KB -
SMA_Short.png
60 KB -
SMA_Short_Hist.png
20 KB -
DC_Gen_Hist.png
22 KB -
DC_Gen_FFT.png
70 KB -
100kHz_FFT.png
71 KB -
100kHz_Signal.png
140 KB -
500kHz_FFT.png
75 KB -
1MHz_FFT.png
72 KB -
1.5MHz_FFT.png
71 KB -
2MHz.png
73 KB -
Frontend.png
30 KB
Es geht weiter. Ich habe jetzt die Schaltung wie im Anhang, aber nur die OPVs und nur Widerstände bestückt. Ausnahme sind die 3x 1 nF zwischen OPV und ADC und die Kondensatoren an den OPV Versorgungen. Ich finde das sieht OK aus, aber ich kann das jetzt mit dem Generator aus dem Oszi auch nicht besser testen. Ich habe auch Screenshots vom Oszi mit FFT im Anhang. Es war entweder meine ADC Hardware oder ein Kanal vom OSzi an den Generator angeschlossen, nicht beides gleichzeitig. Was mir auffällt, ist dass der Peak bei mir recht breit ist. Aber ich habe im FPGA auch nur 8 kPunkte Platz (da wäre schon mehr, aber der ist anderweitig belegt, ich müsste mal ein Design machen nur für die ADC Samples). Wenn ich aber beim Oszi die Anzahl der Samplepunkte auch einschränke, z. B. auf 10k was das nächst Mögliche an 8k ist, dann ist der Peak dort auch sehr breit. SMA_Short ist ein Kurzschluss am SMA der ADC Platine. Und bei DC_Gen ist die ADC Platine mit dem Generator im Oszi verbunden, der ist auch an, aber der ist auf DC und 0 V eingestellt. Naja, seht selbst. Edit: Ja, C2 links ist ein Fehler. Da muss vorher ein R rein zur Strombegrenzung weil das ja der Ausgang ist. Aber der ist zur Zeit nicht bestückt.
:
Bearbeitet durch User
Angehängte Dateien:
-
100kHz_FFT_32k.png
47 KB -
1MHz_FFT_32k.png
53 KB -
SMA_Short_C8_C9.png
50 KB -
SMA_Short_C6_C7_C8_C9.png
39 KB
Mit C8 und C9 jeweils 27p bestückt bekomme ich eine deutliche Störung. Wenn ich den Wert auf 5 p verringere, dann wird die Störung stärker, also habe ich C6 und C7 auch mal bestückt und zwar C6 und C7 mit 68 p und C8 und C9 mit 5 p. Auch da sind deutliche Störungen sichtbar. Und ich habe jetzt 32k Punkte Samplelänge, wie man in der FFT sieht werden die Peaks deutlich schmäler gegenüber der 8k. Hier im Anhang bei den 100 kHz und 1 MHz waren die Kondensatoren nicht bestückt.
Thread beobachten
Seitenaufteilung abschalten
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.