DACRAM Zusatzplatine

[HSiebrecht]

Hallo Volker,

Kaum entfernt man das verbrutzelte Colofonium von der FPGA Basisplatine, schon klappts auch mit QVGA.
Hab also keine Bildfehler mehr.

das eigene oder das rund um den FPGA Chip.

Hauptsache es funktioniert.

[psclab38]

So, jetzt ist auch meine Lieferung angekommen, und heute abend hat dann der Lötkolben geglüht.
Ich muß Volker zustimmen (siehe erstes Posting in diesem Thread), daß der Test einzelnen Komponenten nicht so ganz einfach ist. So nach und nach konnte ich dann aber alles testen.

Wir müßten echt mal auflisten, was man wie prüfen kann. Ich hab lange den TxDAC nicht zum spielen bekommen, aber er funktioniert.

Sieht soweit ganz gut aus, aber ein Problem hab ich. Der Frequenzähler spinnt, d.h. der Komparator macht eigentlich das, was er soll, aber bei den Flanken des Signals, das er Richtung FPGA auf FN100 schickt, klingeln die Flanken unwahrscheinlich. Sieht auf dem Oszi zunächst ganz gut aus, aber wenn man in die Flanken reinzoomt, dann ist da für eine Zeitlang ein schöner Frequenzhagel. Endeffekt ist natürlich, daß die Messung viel zu hoch ist, so über ein Mhz bei 1kHz. Sieht fast so aus, als ob die Rückkopplung nicht ganz greift, aber die Bestückung ist i.O..

Hat jemand da eine Idee? Außer Platine waschen, was ich aber sowieso noch vorgehabt habe. Die Finepitches haben ein wenig zu viel Flußmittel hinterlassen.


Viele Grüße
Paul

P.S: Hat schon jemand rausgeknobelt, wie man bei Asteroids das Z (Blanking) Signal invertieren kann? Sieht so aus, als ob mein gutes altes Hameg das genau anders rum braucht.

[Merlin]

Hallo,

erst einmal vielen Dank für die zahlreichen Tips.
Ich habe nochmal alle Adressleitungen (auf der DACRAM und der Basisplatine) überbrüft, aber keinen Fehler feststellen können.
Ich hatte vergessen mitzuteilen, dass ich die neuste Firmware 2.33 benutze.
Genau das scheint die Ursache zu sein, denn die beiden Spiele (Invaders u. Pacman) funktionieren einwandfrei.
Das "ct-qvga,zip" auf dem Server enthält das QVGA.bit bzw, main.bit vom 07.02.2009, mit welchem ich die Probleme habe.
Das "pacman_neu.zip" enthält ein anderes main.bit vom 14.02.2009, mit dem die Spiele laufen.

Alles deutet darauf hin, dass das qvga.bit bzw. main.bit auf dem SubVersion-Repository nicht mit der neuen Firmware läuft.

Kann das jemand bestätigen ?

Viele Grüße

Merlin

[psclab38]

Auf der Suche nach der Ursache mit dem Komparator bin im Datenblatt auf die Anmerkung gestoßen, daß das Layout und die Entkopplung der Betriebsspannung ziemlich kritisch sein soll, und man solle nur "gute" Kondensatoren dafür einsetzen.
Bislang hat jedenfalls das Parallelschalten eines 10nF X7R-kerko nicht gebracht. mal sehen.

-Aber mit der Referenzspannungserzeugung auf der Platte hab ich so meine Verständnis-Probleme:

--edit--
Mann, ich glaub ich bin blind, wo hab ich da heut morgen nur hingeschaut. Der Stromlauf stimmt. Ich hab mal allen Unsinn, den ich verzapft hab, wieder rausgelöscht.

Die Symmetrische Referenz ist ziemlich tricky: Sie erzeugt ihren eigenen Fußpunkt für den REF02 über den OP27 bei -2.5V , damit sind die Referenzspannungen +2.5V und -2.5V

Aber diese Frage bleibt:
- Der Eingangspannungsbereich vom AD9752 laut Datenblatt 0.1V-1.26V (Input Compliance Range). Wie paßt das mit den 2.5V

--edit--

Viele Grüße
Paul

[magicroomy]

Hi psclab38,
hab auch Schwierigkeiten mit den DAC spannungen. Hab erst gedacht ich spinne. Scheinbar bin ich nicht alleine.

Am DUAL DAC kommt nur ca. 1,2-1,5 V Maximalamplitude raus. Ich hab bei mir die Referenzspannungen aber noch nicht gemessen. Dieses Wochenende hoffe ich.
am TX kommen maximal ca 3V raus.

Ich hab mal meinen versprochenen Sägezahn generator beigelegt.

Wenn ich mir das VI für die amplitudenmodulierte DDS (AMDDS) anschaue hat die Vorschaukurve übrigens einen Maximalwert von 2.

Gruß
Magic Roomy

[HSiebrecht]

Hallo Merlin,

Ich hatte vergessen mitzuteilen, dass ich die neuste Firmware 2.33 benutze.
Genau das scheint die Ursache zu sein, denn die beiden Spiele (Invaders u. Pacman) funktionieren einwandfrei.
Das "ct-qvga,zip" auf dem Server enthält das QVGA.bit bzw, main.bit vom 07.02.2009, mit welchem ich die Probleme habe.
Das "pacman_neu.zip" enthält ein anderes main.bit vom 14.02.2009, mit dem die Spiele laufen.

main.bit ist nicht gleich main.bit.

Das main.bit aus "pacman_neu.zip" solltest Du besser in pacman.bit umbenennen, dies ist das eigentliche Pacman
Spiel, dann auch pacman.ini anpassen, 1. Zeile.

In "ct-qvga,zip" ist main.bit = qvga.bit, diese brauchst Du für die DEMOVGA.INI. Leider hat die DEMOVGA.INI einen Fehler, dort sind in den ersten Zeilen alle "cfg" Befehle auskommentiert, somit wird keine qvga.bit oder fbas60.bit geladen. Ändere mal die zweite Zeile folgendermassen ab :

0:REM Zeile 1 Test-INIT-File Clocktest
CFG=QVGA.BIT --------------------> hier sind im Original die Kommentarzeichen enthalten gewesen.
// CFG=FBAS60.BIT
// Uhr stellen
CLK 0=12
CLK 1=15
CLK 2=30

Alles deutet darauf hin, dass das qvga.bit bzw. main.bit auf dem SubVersion-Repository nicht mit der neuen Firmware läuft.

Siehe oben, kann ich nicht bestätigen, bei mir funktioniert das alles mit Firmware 2.33.

[psclab38]

Nachdem ich mich ja mit den Referenzspannungen selbst ausgetrickst hatte, hab ich mich wieder meinem Komparatorproblem gewidmet. Also erst mal die Platine gewaschen, vielleicht hilft's ja, so wie bei Volker. Aber Fehlanzeige.

Ich hab mal ein Bild angehängt, wie denn so eine Low-High-Flanke an FN100 aussieht. Kein Wunder, daß der Zähler da die ganzen Pegelwechsel "sieht" und mitzählt. Die High-Low-Flanke ist kaum besser.

Komparator-LH-Flanke.jpg (27.13 KiB) 18681 mal betrachtet

Den 100k-Feedback-Widerstand wegzunehmen oder mal den Ausgang von der Leitung Richtung FPGA abzutrennen hat nix gebracht. Das Signal sieht immer so grauenhaft aus.
Die sonstigen Signale und Betriebsspannungen um den Komparator haben vernünftige Werte, ich hab fast den Verdacht, daß der Komparator einen Schuß hat.

Gibt's in der Runde noch jemanden mit dem Problem oder funktioniert der Frequenzähler bei Euch wie erwartet?

Viele Grüße
Paul

[ompf]

d.h. der Komparator macht eigentlich das, was er soll, aber bei den Flanken des Signals, das er Richtung FPGA auf FN100 schickt, klingeln die Flanken unwahrscheinlich.
(...)
Hat jemand da eine Idee?

Wenn's eher hochfrequent (MHz) ist: Hundert Ohm in Reihe mit dem Ausgang schalten. Bei schnellen Signalen sind diese Bremswiderstände zur Impedanzanpassung nötig (siehe SPI-Busse der verschiedenen Module).

Mit 33-100R am Ausgang (oder 220R nach Plus UND 330R nach Masse am Eingang) werden die Reflexionen unterdrückt.


Wenn die Schwingungen niederfrequent sind, dann ist die Hysterese des Komparators zu klein. In diesem Fall muß der Widerstand zwischen Ausgang und nichtinvertierendem Eingang etwas verkleinert werden.



Gruß
Patrick

[psclab38]

Hi Patrick,

Wenn's eher hochfrequent (MHz) ist: Hundert Ohm in Reihe mit dem Ausgang schalten. Bei schnellen Signalen sind diese Bremswiderstände zur Impedanzanpassung nötig (siehe SPI-Busse der verschiedenen Module).

Es sind keine Überschwinger, die von langen Leitungen herrühren. Der Ausgang geht ja zunächst nicht mal ganz bis nach High. Wenn ich mit dem Oszi-Tastkopf direkt am Ausgang (Pin hochgebogen) messe, dann kommt das obige Signal zustande.

Wenn die Schwingungen niederfrequent sind, dann ist die Hysterese des Komparators zu klein. In diesem Fall muß der Widerstand zwischen Ausgang und nichtinvertierendem Eingang etwas verkleinert werden.

Es hat bestimmt was mit der Hysterese zu tun, aber die Schwingung ist in zig MHz. Das geht nicht über das externe Feedback oder?

Viele Grüße
Paul

PS: Nur der Vollständigkeit halber: Der Test vom Frequen.vi mit Generator->Zähler (FP99->FN100) funktioniert wunderbar (natürlich ohne die DACRAM-Platine)

[psclab38]

Jetzt ist mir vorhin doch die folgende Frage gekommen: für welche Art Signale ist die Schaltung des Frequenzzähles eigentlich gedacht? Digitale oder auch analoge?

Ich hatte eigentlich angenommen, daß der Komparator intern schon über eine vernünftige Hysterese verfügt, aber dem ist gar nicht so: 2mV für den ADCMP600. !?! Nur seine Brüder haben sowas eingebaut.

Ich bin die ganze Zeit immer mit einem 1kHz Sinus (halt Einschaltwert) von der DDS hingegangen, und da reicht wohl die Anstiegszeit bei weitem nicht. Dreieck dto, nur Rechteck funktioniert. Naja, einigermaßen. Auch da ist wohl die Anstiegszeit bei der DDS nicht ausreichend. Es wird signifikant stabiler, wenn ich 10k dem R29 parallel schalte. Jetzt müßte man nur noch die Leitungsdämpfung/Abschluss einbauen, so wie von Patrick vorgeschlagen, weil's jetzt Überschwinger gibt, die wieder für zusätzliche Pulse sorgen.

Kann es sein, daß der Eingang nur für Digital gedacht ist
Und wenn ja, stand das irgendwo?

Viele Grüße
Paul

[magicroomy]

Hi nochmal zusammen,
nur damit ich nicht dumm sterbe. Was sind denn die MaximalSpannungen der DACs an den Ausgängen?

Gruß
Volker

[psclab38]

Hallo Volker,

ich hab mir das Datenblatt zu dem AD5447 mal angesehen. Die Beschaltung bei uns ist ziemlich trickreich, und mit unserer Uref=2.5V sollte

Uout im Bereich von -Uref/2 bis +Uref/2 liegen, also -1.25V bis +1.25V

Genauer:

Uout = Uref * ( 1/2 - D/2^12 )

mit D= 0 ... (2^12) -1

Die Toleranz des internen R (nominal 10k) liegt bei 8..12k, der R11/14 bei 20K(1%) = 2*R.
Damit ist der Offset vermutlich in der Praxis nicht so richtig exakt bei Null.

Viele Grüße
Paul

PS: Für den TxDAC ists mir jetzt zu spät (1:41)

[Merlin]

Hallo Helmut,

vielen Dank für den Tip, aber das hatte ich schon auspropiert bzw korrigiert.
-dempvga.ini mit qvga.bit -> fehlerhaftes Bild
-pacman bzw. Invaders mit entsprechendem main.bit -> einwandfreies Bild
-Firmware 2.33
Meine Schlußfolgerung:
An den Adressleitungen oder Datenleitungen kann es dann nicht mehr liegen, oder liege ich da falsch?


Viele Grüße

Merlin

[psclab38]

Hi Merlin,

also speziell, wenn pacman richtig läuft, dann kann's eigentlich doch nicht am SRAM liegen, weil hier der Programmspeicher im RAM liegt. Und wenn da was nicht stimmt, dann würde sich auf dem Bildschirm gar nichts bewegen. Allerdings sind ist der ROMcode nur 16k groß, und das RAM hat ja 32k.

Aber was das mit dem qvga.bit sein könnte, das ist mir spätestens jetzt ein Rätsel. Die Bilder zeigen, daß die Daten eigentlich alle vorhanden sind, nur teilweise an der falschen Stelle dargestellt werden. Ich weiß jetzt aber nicht, wieviel von den 32k sich qvga für den Bildschirmspeicher nimmt.

Tja,....
Viele Grüße
Paul

[ingo]

Hi DACRAM-bastler,

warum benutzt Ihr zum (D/A-Wandler-)Testen denn nicht das DDSDUAL-Projekt? Wenn man es neu übersetzt, funktionieren zusammen mit dem LabView-Programm die drei D/A-Wandler einwandfrei ...

... FAST ... bis auf einen 'jitter' um eine Taktlänge (20ns) bei den Wandlungen und allen drei DACs, seht Ihr das auch?

Gruss, Ingo.