Probleme Pal-Videosignal

T

Thomas Pototschnig

Guest
Hallo,

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.

Die Frequenz des Bursts dürfte um weniger als <0.5% von den
4,43361875MHz abweichen. Also sicher noch gut genug.

Der Burst wechselt jede Zeile von +135° nach -135° (=225°), U bleibt bei
0° und V wechselt zwischen +90° und -90°.

Ich hab den Output von meinem VHDL-Simulator mal in ein BMP gepeichert
und durch einen Software-Dekoder geschickt, und das Ergebnis war absolut
okay und vor allem farbig.

Trotzdem weigert sich der Fernseher Farbe zu dekodieren. Es tauchen ja
nicht mal Falschfarben auf, sondern es ist ein richtiges Graustufen Bild.

Hat jemand eine Idee, was man da noch falsch machen kann?

Im Internet habe ich das hier mal gefunden:
http://www.serasidis.gr/circuits/colour_bar_gen/colour_bar_gen.htm

Das ist ein PAL-Color-Bar-Generator auf AVR-Basis. Da werden nahezu alle
Vorgaben ignoriert und trotzdem dekodiert der Fernseher Farbe. Also so
kritisch kann das anscheinend nicht sein.

Mittlerweile bin ich fast ratlos.

--
Mfg
Thomas Pototschnig
www.oxed.de
 
Die Frequenz des Bursts dürfte um weniger als <0.5% von den 4,43361875MHz
abweichen. Also sicher noch gut genug.
Click to expand...
da wär ich mir nicht so sicher.

Gruss
Michael
 
Hallo Thomas,

Thomas Pototschnig schrieb:
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.

Die Frequenz des Bursts dürfte um weniger als <0.5% von den
4,43361875MHz abweichen. Also sicher noch gut genug.
Click to expand...
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

--
From-address is Spam trap
Use: wolfgang (dot) mahringer (at) sbg (dot) at
 
On Wed, 19 Oct 2005 08:50:27 +0200, Thomas Pototschnig
<thomas.pototschnig@gmx.de> wrote:
Die Frequenz des Bursts dürfte um weniger als <0.5% von den
4,43361875MHz abweichen. Also sicher noch gut genug.
Click to expand...
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.

Trotzdem weigert sich der Fernseher Farbe zu dekodieren. Es tauchen ja
nicht mal Falschfarben auf, sondern es ist ein richtiges Graustufen Bild.
Click to expand...
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.

Gruß Oliver

--
Oliver Bartels + Erding, Germany + obartels@bartels.de
http://www.bartels.de + Phone: +49-8122-9729-0 Fax: -10
 
Hallo!

Thomas Pototschnig schrieb:

Die Frequenz des Bursts dürfte um weniger als <0.5% von den
4,43361875MHz abweichen. Also sicher noch gut genug.
Click to expand...
Nein, +/-0,5% sind +/-22 kHz daneben, das ist zu viel.

Die Farbträgerfrequenz fc leitet sich aus der Zeilenfrequenz fh wie
folgt ab:

fc = fh * (1135/4 + 1/625)

1135/4 + 1/625 ergibt den Faktor 283,7516.

Farbträger und Zeilenfrequenz sind fest miteinander verschränkt, nur
dann fallen die Spektren der beiden Signalanteile Y und C nicht so
ineinander. Läuft der Farboszillator asynchron und nicht verschränkt
zur Zeilenfrequenz (wie es bei vielen billigen Generatoren der Fall
ist, z. B. MC1377), dann gibt es u. U. Störungen und Kreuzmodulationen
zwischen Y und C. Daher erzeugt man normalerweise die
Farbträgerfrequenz möglichst stabil und genau und leitet daraus die
Zeilenfrequenz und alle übrigen Timings ab. Dann kann man sicher sein,
daß die Verhältnisse der Signale untereinander auch stimmen.

Die übrigen 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 über 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.



CU Peter
 
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 !
Click to expand...
Oha - hätte nicht gedacht, dass es so genau sein muss.

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.
Click to expand...
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.

Trotzdem weigert sich der Fernseher Farbe zu dekodieren. Es tauchen ja
nicht mal Falschfarben auf, sondern es ist ein richtiges Graustufen Bild.


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.
Click to expand...
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.


--
Mfg
Thomas Pototschnig
www.oxed.de
 
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.


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.
Click to expand...

Wenn man gezielt danach googelt, findet man schnell was:
http://groups.inetbot.com/showgrp/de_psci_pelectronics_s3894.html

Aber eigentlich müsste man sich doch garnicht darum kümmern, wenn man
ein exaktes Horizontales Timing hat und einen exakten Farbträger, oder?


--
Mfg
Thomas Pototschnig
www.oxed.de
 
Hallo Thomas,

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.
Click to expand...
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.

45MHz/4,43361875MHz = 10,1497225 und mit der Sinus-Größe von 513 Punkten
kommt eine Schrittweite von 513/10,1497225 = 50,54325375.
Click to expand...
und da musst du natürlich mit 512 rechnen.

Gruss
Michael
 
Michael Koch wrote:
Hallo Thomas,


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.


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.
Click to expand...
War wohl etwas viel zu lesen ;-)

Genauso hab ich es gemacht. sin (0.5 * (PI/2) /128) == sin
(PI/(4*tablesize) :)

Auf das Problem bin ich erstmal auch gestoßen.

45MHz/4,43361875MHz = 10,1497225 und mit der Sinus-Größe von 513 Punkten
kommt eine Schrittweite von 513/10,1497225 = 50,54325375.
und da musst du natürlich mit 512 rechnen.
Click to expand...
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.



--
Mfg
Thomas Pototschnig
www.oxed.de
 
Hallo Thomas,

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.
Click to expand...
Das macht nichts, 512 ist trotzdem richtig.
Miss es einfach mit einem Frequenzzähler nach, dann wirst du 0.2% Fehler
sehen wenn du mit 513 rechnest.

Gruss
Michael
 
Michael Koch wrote:
Hallo Thomas,


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.


Das macht nichts, 512 ist trotzdem richtig.
Miss es einfach mit einem Frequenzzähler nach, dann wirst du 0.2% Fehler
sehen wenn du mit 513 rechnest.
Click to expand...
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.

Hast du Erfahrung damit?

--
Mfg
Thomas Pototschnig
www.oxed.de
 
Okay - aber die Probleme mit der Farbe gibt's mit 512 trotzdem, weil ich
das bis gestern immer so hatte.
Click to expand...
Dann ist wohl der Oszillator nicht genau genug.

Bei DDS hab ich aber auch noch keine Erfahrung, wieviel Bits man verwenden
sollte um eine ausreichenede Genauigkeit zu erreichen.
Click to expand...
alle natürlich, soviel wie die Hardware hergibt.

Gruss
Michael
 
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.

Noch irgendwelche Ideen?

--
Mfg
Thomas Pototschnig
www.oxed.de
 
Noch irgendwelche Ideen?
Click to expand...
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.

Gruss
Michael
 
Hallo Thomas,

Aber eigentlich müsste man sich doch garnicht darum kümmern, wenn man
ein exaktes Horizontales Timing hat und einen exakten Farbträger, oder?
Click to expand...
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.

Gruesse, Joerg

http://www.analogconsultants.com
 
Thomas Pototschnig wrote:
Noch irgendwelche Ideen?
Click to expand...
Falls Du einen A/D-Wandler (z.B. TDA8703, Reichelt, 7€) zur Verfügung
hast, würde ich mal ein "gutes" FBAS-Signal nehmen und über A/D- und
D/A-Wandler schicken. Also einfach (über den FPGA) durchleiten. Damit
kann man Fehler im Analogteil ausschließen.

Wenn Du dann noch etwas RAM zur Verfügung hast, dann kannst Du
Deinen eigenen Output aufzeichnen und mit dem guten Signal
vergleichen. Alternativ könnte 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.

Markus
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top