in der letzten Zeit habe ich mir einen VHDL-PAL-Encoder gebaut, der das PAL-Signal digital erzeugt und ein D/A-Wandler analogisiert es dann.
Ein angeschlossener Fernseher synct wunderbar und es sind auch keine Störungen im Bild erkennbar. Das Einzige das absolut nicht will, ist das Dekodieren der Farbe.
Ich hab mich beim Timing nahezu exakt an die Spezifikation gehalten.
- Sync startet bei 0µs und dauert 4,7µs
- dann kommt 0,8µs ein Teil der hinteren Schwarzschulter
- dann Burst mit 2,3µs
- dann der Rest der hinteren Schwarzschulter mit 2,7µs
- 52µs Bild
- 1,5µs vordere Schwarzschulter (Die vordere Schwarzschulter ist bei mir hinten, weil's einfacher war - dürft aber nix ausmachen ...)
Die Pegel sehen so aus, dass bei 0% = Sync, bei 25% = Schwarzschulter, und der Burst ist auch 25% groß - ist also zwischen 12,5% und 37,5% vom Signal.
Ich hab sowas mal gemacht und hatte dasselbe Problem: Keine Farbe zu sehen. Ich musste den PAL-Quarz mit einem Trimmer "ziehen" und schwupps, schon war die Farbe auch da :-) Es war dann nicht einfach, das Ganze temperaturstabil hinzubekommen.
HTH Wolfgang
--=20 From-address is Spam trap Use: wolfgang (dot) mahringer (at) sbg (dot) at
Sicher nicht gut genug, 5000ppm ist jenseits von Gut und Böse. Die Glotzen haben typischerweise auch Quarze drin, und zwar abgeglichene solche.
Die Spezifikation für den Farbträger lautet +/-5Hz !
Außerdem solltest Du prüfen, ob die 8er Bruch Sequenz sauber eingehalten wird (den A/B Burst Wechsel hast Du ja schon implementiert), gerade die modernen Geräte mit digitalem Farbdecoder und Kammfilter wissen davon und wollen das auch genau so sehen.
Der PAL Schalter dürfte nicht aufmachen, dass spricht für eine falsche Burst-Frequenz. Die muss wirklich _genau_ stimmen, es hat schon einen Grund (Verkämmung), warum so viele Stellen hinter dem Komma angegeben sind.
Das PAL ist zwar relativ alt, deshalb sind da keine digitalen Bits und Bytes drin, aber _präzise_ Technik hat man auch damals schon bauen können, manchesmal sogar präziser als heute.
Nein, +/-0,5% sind +/-22 kHz daneben, das ist zu viel.
Die Farbtr=E4gerfrequenz fc leitet sich aus der Zeilenfrequenz fh wie folgt ab:
fc =3D fh * (1135/4 + 1/625)
1135/4 + 1/625 ergibt den Faktor 283,7516.
Farbtr=E4ger und Zeilenfrequenz sind fest miteinander verschr=E4nkt, nur dann fallen die Spektren der beiden Signalanteile Y und C nicht so ineinander. L=E4uft der Farboszillator asynchron und nicht verschr=E4nkt zur Zeilenfrequenz (wie es bei vielen billigen Generatoren der Fall ist, z. B. MC1377), dann gibt es u. U. St=F6rungen und Kreuzmodulationen zwischen Y und C. Daher erzeugt man normalerweise die Farbtr=E4gerfrequenz m=F6glichst stabil und genau und leitet daraus die Zeilenfrequenz und alle =FCbrigen Timings ab. Dann kann man sicher sein, da=DF die Verh=E4ltnisse der Signale untereinander auch stimmen.
Die =FCbrigen von Dir angegebenen Timings scheinen weitgehend zu stimmen, zumindest soweit ich das aus dem Kopf heraus beurteilen kann. Beim Schalten des PAL-Bursts ist es empfehlenswert, den Burst im Nulldurchgang zu schalten, oder wenn man das nicht sauber hinkriegt, dann macht man einen fade-in und fade-out =FCber 2 - 3 Perioden. Damit scheinen manche PLLs im Farbdekoder sauberer einzurasten. Es gibt auch Generatoren, die den PAL-Burst mit einer Sinus-Halbwelle amplitudenmodulieren, das scheint auch ganz gut zu funktionieren.
Oha - hätte nicht gedacht, dass es so genau sein muss.
Uhm - ich hab etliche Stunden mit dem Googeln verbracht, bis ich alle Informationen zusammenhatte - aber was ist eine 8er Bruch Sequenz? Davon hab ich bis jetzt noch nichts gelesen.
Okay - ich hab jetzt meinen digitalen Sinus DDS von 32 auf 48Bit umgebaut (9Bit Adresse für die Sinus-Tabelle, 39Bit Fraktionaler Teil). Mal kucken, ob da die Frequenz dann genau genug wird. (Allerdings kann ich es gerade nicht testen, weil der Aufbau bei einem Kumpel steht)
Wenn das auch nicht klappt, hab ich vermutlich noch einen Denkfehler in meinem DDS drin.
Ich erklär vielleicht mal kurz wie ich das umgesetzt habe und vielleicht kommst du oder jemand anderes auf meinen Denkfehler:
Also - ich hab eine 128 Einträge große Tabelle, in der genau eine viertelte Periode gespeichert wird. Dafür benötige ich einen Index von 7 Bit. Bit Nr. 8 meiner 9Bit Adresse (von meinem fraktionalen counter) sagt, dass die Adresse umgerechnet werden soll, weil die Sinuskurve im
2ten viertel wieder fallend ist - also 127 - 7BitAdr. Ist bit 9 gesetzt, wird außerdem das ganze 2-er-komplementiert.
Ich konnte dabei nicht den Sinus von 0 bis Pi/2 in 128 teile aufteilen, weil ich sonst beim Übergang vom z.B. ersten Viertel auf das Zweite einen doppelten Wert gehabt hätte - da hätt's dann Probleme mit den 2er Potenzen gegeben und Sonderfälle wären notwendig gewesen. Dazu hab ich dann den Sinus um PI/(4*tablesize) verschoben und als Wikelschrittweite PI/(2*tablesize) verwendet (tablesize = 128). Da haben dann auch zwei Punkte, die in verschiedenen Vierteln liegen, den selben Abstand von PI/(2*tablesize) zueinander. Insgesamt besteht der Sinus dann aus 513 Werten, weil der 513. Wert (=1. Wert) den Sinus wieder schließt.
Die Akkumulierkonstante hab ich dann so berechnet:
45MHz/4,43361875MHz = 10,1497225 und mit der Sinus-Größe von 513 Punkten kommt eine Schrittweite von 513/10,1497225 = 50,54325375. Das Ergebnis hab ich jetzt in eine 48Bit-Zahl gepackt, wobei die Kommastelle zwischen Bit 39 und 38 ist.
Öööh ... ja ... so hab ich das gemacht. Hoffentlich war's irgendwie verständlich.
Falls irgendjemandem ein Fehler jetzt aufgefallen ist, würde ich mich freuen, wenn er mir den nennen könnte.
Das ist falsch. Du musst in der 128 Einträge langen Tabelle nicht die Werte von 0 bis Pi/2 speichern, sondern um einen halben Eintrag verschoben. Der erste Eintrag ist also nicht null, sondern sin(0.5 * (Pi/2) / 128), und der nächste Eintrag ist dann sin(1.5 * (Pi/2) / 128), und so weiter. Dann passen die Kurven an den Nahtstellen lückenlos aneinander.
Genauso hab ich es gemacht. sin (0.5 * (PI/2) /128) == sin (PI/(4*tablesize) :-)
Auf das Problem bin ich erstmal auch gestoßen.
Hmm ... da kriegt man einen Knoten ins Hirn ... ich hatte erst immer
512, nach langem überlegen bin ich zu dem Entschluss gekommen, dass ich
513 brauche. Die 512 Punkte decken nur den Bereich von 0.5 * (PI/2) /128 bis 2*PI-(0.5 * (PI/2) /128) ab - und da fehlt doch dann noch genau 1 Punkt zum Vollständigen Sinus.
Okay - aber die Probleme mit der Farbe gibt's mit 512 trotzdem, weil ich das bis gestern immer so hatte. Und einen fraktionalen Teil mit 39Bit für meinen Zähler zu verwenden, erscheint mir schon etwas sehr hoch.
Bei DDS hab ich aber auch noch keine Erfahrung, wieviel Bits man verwenden sollte um eine ausreichenede Genauigkeit zu erreichen.
Update: DDS auf 64bit erweitert, mit 512 Punkten die Akkumulationskonstante berechnet (laut Michael Koch).
Aber immer noch keine Farbe.
Keine Ahnung was das ist ... aber die Frequenz müsste doch schon langsam genau genug sein?! Frequenz gemessen, aber genauer als 4,433MHz wird's nicht angezeigt.
Oszillator über Trimmer einstellbar machen und langsam den ganzen +-100ppm Bereich durchfahren. Oder per Software die Frequenz in 5Hz Schritten verändern. Oder mal einen anderen Fernseher testen.
Was den Farbtraeger angeht, muss er sehr exakt sein. Wenn der auch nur ein paar hundert ppm abweicht, flutscht die Farbsynchronisation weg und ein gescheiter Fernseher schaltet auf schwarz-weiss.
Falls Du einen A/D-Wandler (z.B. TDA8703, Reichelt, 7=80) zur Verf=FCgung=
hast, w=FCrde ich mal ein "gutes" FBAS-Signal nehmen und =FCber A/D- und D/A-Wandler schicken. Also einfach (=FCber den FPGA) durchleiten. Damit kann man Fehler im Analogteil ausschlie=DFen.
Wenn Du dann noch etwas RAM zur Verf=FCgung hast, dann kannst Du Deinen eigenen Output aufzeichnen und mit dem guten Signal vergleichen. Alternativ k=F6nnte man auch aufgezeichnete Signale als Burst ausgeben. Das passt dann zwar nicht zu Deiner sonstigen Phase, aber der Fernseher sollte das erkennen und irgendwas Buntes ausgeben.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.