AD5062 Probleme mit digitaler Schnittstelle

Was mir in deinem Bild auffällt: Das "nsync" ist nie '1' bei einer Taktflanke(SCLK), nur mal so kurz danach ...

Bernhard K. schrieb:

Was mir in deinem Bild auffällt: Das "nsync" ist nie '1' bei einer Taktflanke(SCLK), nur mal so kurz danach ...

Ok, Danke, muss denn SCLK auch mal takten, wenn nSYNC = high ist? Werde da aus dem Datenblatt nicht wirklich schlau... Probieren kann ich es ja mal. ;-)

Ok, habe nun mal den Takt ohne Unterbrechung auch während der nSYNC=high-Phase weiter laufen lassen. Leider macht das auch keinen Unterschied. Nur wenn ich ich den FPGA-Takt halb so langsam machen (sodass alles mit halber Geschwindigkeit läuft), dann macht der DAC was er soll. Woran kann das nur liegen?

Hat jemand noch einen Tipp?

Na wenn die Frequenz eine Rolle spielt kann natürlich das Platinen Design noch eine Rolle spielen. Schick Mal ein Bild zum PCB und zum Aufbau.

Kannst ja auch Mal die Signale aufzeichnen wenn es funktioniert und wir vergleichen dann nochmal zum ersten Post.

Dafuer dass dein SCLK mit 25MHz laeuft sehen die Signale echt beschissen aus. Weshalb muss das Ding so schnell laufen ? Irgendwoher Stress ?

Georg M. schrieb:

Nur wenn ich ich den FPGA-Takt halb so langsam machen

Ist "halb so langsam" das Gleiche wie "doppelt so schnell"? ;-)

Habe nun noch folgendes probiert:

1. Einen neuen DAC eingelötet -> keine Änderung.
2. Die Phase, in der nSYNC = 1 ist, verlängert. Ab 230ns funktioniert es dann. Wieso braucht er denn hier so viel Zeit? Im Datenblatt steht doch nur etwas von t8 = 12ns.....

N. M. schrieb:

Na wenn die Frequenz eine Rolle spielt kann natürlich das Platinen Design noch eine Rolle spielen.

Morgen früh schicke ich gleich mal Bilder vom Aufbau. Aber die Signale sind direkt am DAC gemessen, eben damit das Oszi das selbe sieht wieder DAC. Versorgungsspannung ist auch direkt am DAC abgeblockt und stabil.

Guten Morgen,

nachdem ich mir die Sache nochmals durch den Kopf gehen lies, ist mir aufgefallen, dass im Datenblatt des AD5062 die maximale Samplerate gar nicht angegeben ist. Mein Ziel sind 1MS/s, daher das schnelle Timing. Kann es sein, dass der DAC gar nicht so schnell kann? Wie findet man das raus, wenn es nicht im Datenblatt steht?

Die 25MHz SCLK sind ja innerhalb der laut Datenblatt maximal zulässigen 30MHz . Ob allerdings die angestrebte 1MSPS bei einer "Fast settling time of 4 μs typically" sinnvoll ist, muss der Anwender selbst entscheiden.

Dieter W. schrieb:

Die 25MHz SCLK sind ja innerhalb der laut Datenblatt maximal zulässigen 30MHz . Ob allerdings die angestrebte 1MSPS bei einer "Fast settling time of 4 μs typically" sinnvoll ist, muss der Anwender selbst entscheiden.

Ja, genau, so habe ich es mir auch gedacht. Allerdings updated der DAC seinen Ausgang nur für jeden 2. Code, wenn man ihm mit 1MS/s Codes sendet. Erst ab ca. 0.75MS/s nimmt er dann jeden Code. Das hätte ich so nicht erwartet und wollte fragen, ob das jemand so aus dem Datenblatt entnehmen würde?

Laut Datenblatt "Fast settling time of 4 μs typically" das grenzt die Sache doch schon auf 250kS/s ein.

Datenblatt S.14: Data is written to the AD5062 in a 24-bit word format, via a 3-wire serial interface. Datenblatt S.14: 33 ns min SCLK cycle time 24*33ns = 0,792µs dazu noch eine (kleine?) Pause zwischen zwei 24-Bit-Übertragungen. Das entspricht <1,2 MHz Datenrate.

Datenblatt S.3: Output Voltage Settling Time 4 μs (¼ scale to ¾ scale code transition to ±1LSB.) Das betrifft nur die analoge Änderungsgeschwindigkeit. Schnellere Änderungen sind nur etwas ungenauer.

Christoph db1uq K. schrieb:

Datenblatt S.14: Data is written to the AD5062 in a 24-bit word format, via a 3-wire serial interface. Datenblatt S.14: 33 ns min SCLK cycle time 24*33ns = 0,792µs dazu noch eine (kleine?) Pause zwischen zwei 24-Bit-Übertragungen. Das entspricht <1,2 MHz Datenrate.

Datenblatt S.3: Output Voltage Settling Time 4 μs (¼ scale to ¾ scale code transition to ±1LSB.) Das betrifft nur die analoge Änderungsgeschwindigkeit. Schnellere Änderungen sind nur etwas ungenauer.

Ja, genau so hatte ich es mir auch zusammengereimt. Aber der DAC verhält sich anders. In Deiner Rechnung oben braucht ja die reine Datenübertragung 792ns. Damit bleiben (um auf 1us (also 1MS/s)) zu kommen noch 208ns "Pause" (also nSYNC=1. Damit akzeptiert der DAC dann aber immer nur jeden 2. Code. Erste wenn die Pause gegen 230ns, dann übernimmt er jeden Code.... Das hätte ich eben auch nicht erwartet, aber z.B. Figure 17 auf Seite 10 gibt auch einen entsprechenden Hinweise (warum kommt der Glitch so spät?).