Pixeltakt mit Phasenkopplung zu HSYNC/VSYNC

Ich versuche, Pixeldaten zu erfassen, die an ein kleines Schwarzweiß-CRT-Display gesendet werden. Die Signale, mit denen ich arbeiten muss, sind das Pixeldatensignal auf TTL-Pegel, HSYNC und VSYNC. Ich kenne die Pixeltaktfrequenz (~16 MHz), aber für meine Anwendung habe ich keinen Zugriff auf das Pixeltaktsignal.

Ich möchte das Pixelsignal zum richtigen Zeitpunkt abtasten (in der Mitte der Bitperiode, nicht während des Übergangs), also dachte ich, ich muss einen neuen 16-MHz-Takt mit einer gewissen Phasenbeziehung zu einer Flanke des HSYNC-Signals und erzeugen Verwenden Sie das, um das Pixelsignal abzutasten.

Ich weiß, wie man mit einer PLL ein Taktsignal multipliziert und eine bestimmte Phasenbeziehung zwischen Eingang und Ausgang aufrechterhält, aber wie halte ich eine ähnliche Beziehung zwischen einem neuen 16-MHz-Takt und einem Signal aufrecht, das nur gelegentlich eine Flanke hat (HSYNC)? ?

Oder gibt es eine bessere Möglichkeit, dieses Problem zu lösen?

Sie möchten wahrscheinlich einen Algorithmus- oder Software-Regelkreis - mit einer geringen Schleifenbandbreite könnten Sie den VCO in Software abstimmen. Oder einen schnelleren festen Takt laufen lassen, einen Zähler bei der Synchronisation initialisieren und dann berechnete Zählintervalle danach abtasten (möglicherweise mit akkumulierten Teilzählungen). Möglicherweise stellen Sie fest, dass digitale Monitore mit VGA-Eingängen ausgefallene Schemata haben, die sich mehr mit den tatsächlichen Datenänderungen für die Taktwiederherstellung als mit den Synchronisierungen befassen. Ihre Quelle hat wahrscheinlich eine geringe Bandbreite. Wenn Ihr Sampling-System und sein Ziel damit umgehen können, können Sie die Ergebnisse auch per Software überabtasten und bereinigen.
Sie könnten auch überlegen, ob Sie einfach eine vorhandene PCI- oder USB-Videoaufnahmelösung verwenden könnten - wenn sie vielseitig genug ist, um das Timing zu handhaben, wäre die Neuzuordnung auf analoger Ebene einfach zu bewerkstelligen.
zwei Fragen: a) bedeutet "TTL-Pegel" "binär" wie in "Schwarz ODER Weiß" oder bedeutet es "Graustufen, irgendwo zwischen 0 V und 5 V"? b) ist es sicher, dass es eine feste Beziehung zwischen der HSYNC/VSYNC-Periode und dem Pixeltakt gibt? Wenn ich an die gesamte NTSC-Bildrate == 24,97 sehr viele Ziffern Hz denke, würde ich annehmen, dass die Pixeluhr unabhängig wiederhergestellt werden könnte.
Wenn Hsync sehr stabil ist, kann ein VCXO zu einem stabilen Vielfachen von Hsync gemacht werden, um einen Pixeltakt zu erzeugen. Aber um LCD-Pixel auszurichten, muss die Phase möglicherweise angepasst werden. Mein Fernseher verwendet das tatsächliche Videosignal zum Synchronisieren, Erstellen der Pixeluhr und berechnet dann die H-Größe und die V-Größe und den Versatz oder Ursprung, um den Phasenfehler auf allen Pixeln zu minimieren, und rastet in Sekunden ein. In 99 % der Fälle wird es beim Einschalten mit einem leeren digitalen Bildschirm korrekt ohne Pixel-Aliasing gesperrt. Meine Frage ist, wie genau Sie die Frequenz / Phase der Pixeluhr und wie wenig Jitter wollen und ob Sie die Sperrerkennung aktivieren möchten, um die Such- / Einfrieruhr zu aktivieren.
Möchten Sie auch einen PLL-Pixeltakt, der mit jeder Pixelrate synchronisiert werden kann? Wenn ja, welche Auflösungen und Bildraten?
Übrigens, das ist hier völlig on-topic, aber wenn Sie diese Frage stellen möchten, wie Sie den Pixeltakt wiederherstellen können , wäre dies eine hervorragende Frage für signals.stackexchange.com
Übrigens wäre vielleicht das Datenblatt eines Video-Digitizer-ICs als Referenzimplementierung hilfreich: ti.com/lit/ds/symlink/tvp7002.pdf
Irgendwie habe ich das Gefühl, dieses Signal ist analog? Dann spielt die Phase des Pixeltakts oder der ADC-Abtasttakt wirklich keine so große Rolle, und eigentlich spielt die Frequenz auch keine große Rolle. Sie können es auch oversampeln, wenn Sie möchten.
@ user3528438 Wenn der Ursprung der Informationen analog wäre, müssten keine "Pixel" erfasst werden. Es stammt wahrscheinlich von einer digitalen Schaltung, die entweder eine binäre monochrome oder eine analoge Graustufenausgabe erzeugt, sodass entweder eine Abtastung zu den richtigen Zeiten oder eine Überabtastung und Bereinigung in der Software erforderlich sind, wenn Artefakte vermieden werden sollen. Dies ist wahrscheinlich wichtiger, wenn man Text oder Liniengrafiken wiederherstellen möchte; Wenn das Original ein Bild von einer Kamera ist, spielt es möglicherweise keine Rolle.

Antworten (3)

Eine Möglichkeit, dies anzugehen, wäre, Ihre PLL (bezogen auf HSYNC) zu verwenden, um einen Haupttakt mit dem 3-fachen oder 4-fachen des Pixeltakts zu generieren, und dann einen Johnson-Zähler zu verwenden, um neue Pixeltakte mit 3 oder 4 verschiedenen Phasenwerten zu generieren. Sie können dann die Phase mit dem gewünschten Timing auswählen, entweder manuell mit einem Jumper oder elektronisch mit einem Multiplexer.

Es gibt Möglichkeiten, eine PLL direkt an eine intermittierende Referenz (dh das Videosignal selbst) zu koppeln, aber da Sie die nominelle Punktrate bereits kennen, sollte dies nicht notwendig sein. Sie könnten jedoch den Phasendetektor eines solchen Systems verwenden, um Ihnen zu helfen, automatisch die beste Phase des Johnson-Zählers für die Abtastung auszuwählen.

Worauf würden Sie die PLL beziehen? Wenn Sie meinen, Sie hätten eine lokale Uhr, die mit einem Vielfachen der erwarteten Pixeluhr läuft, würde ich erwarten, dass sie funktionieren würde, aber der Unterschied zwischen dieser und der tatsächlichen Quelltaktfrequenz würde gelegentliche Sprünge zwischen Ihren verschiedenen Phasenwahlen verursachen . Wenn dies selten vorkommt, gut, wenn mehrmals pro Bildschirm, müssen vielleicht die Phasenschritte feiner sein?. Mit einem höheren Vielfachen scheint es in Ordnung zu sein - und ich gehe davon aus, dass der ursprüngliche Pixeltakt ziemlich langsam ist, sodass in einem FPGA 10x oder mehr möglich sein kann.
@ChrisStratton Nun, eine Abtastrate von 160 MHz stellt eine nicht triviale Anforderung an das Platinenlayout und den ADC sowie die FPGA-Geschwindigkeit des Systems. Ich denke also, die Frage ist wirklich, wie man in einem Signal mit wenig zuverlässigen Zustandsübergängen auf eine PLL verweist
@MarcusMüller - Der 160-MHz-Takt (oder möglicherweise schneller) wäre im FPGA intern , da er nur benötigt wird, um den tatsächlichen Abtasttakt digital zu phasen. Der auf der Platine zum ADC geleitete Takt muss nicht schneller sein als der eigentliche Pixeltakt, es sei denn, Oversampling für die Nachbearbeitung ist erwünscht. Diese Taktraten sind für einfache Logik in einem FPGA relativ akzeptabel, jedoch könnte es besser sein, die PLL/DLL/was auch immer-Blöcke eines FPGA zu nutzen.
Ah, also habe ich dich falsch verstanden, @ChrisStratton. Ja, das klingt machbar – und da die Line-Rate-Multiplikation tatsächlich so zu sein scheint, wie es kommerzielle ICs tun, ja, das könnte der Weg sein. Andererseits: Meh. Ich hatte auf eine Schätzung der Pixelrate allein aus dem Pixelsignal gehofft.

Das klingt nach einem einmaligen Projekt (meistens nur Trash-Schwarzweiß-CRT-Technologie). Selbst bei solch alter Technologie war es üblich, alle Zeitsteuerungen von einer Hauptuhr
abzuleiten . Wenn dies der Fall ist, ist HSYNC wahrscheinlich synchron mit Pixelkanten, was Ihr PLL-Design erheblich vereinfacht. Ein auf HSYNC ausgelöstes Oszilloskop beim Betrachten von TTL-Video würde Ihnen sagen, ob HSYNC mit der Pixeluhr synchron ist? Wenn dies der Fall ist, erhalten Sie auch eine Vorstellung von Jitter, mit dem Ihre PLL fertig werden muss. Und synchrones HSYNC erleichtert Ihr PLL-Design erheblich. Selbst in diesem einfachen Szenario müssen Sie sich damit abfinden, dass während des vertikalen Rücklaufs kein PLL-Eingang vorhanden ist.

Im Fall von nicht synchronem HSYNC, VSYNC wird Ihre Pixeltaktrekonstruktion sehr schwierig sein. Möglicherweise müssen Sie Pixel überabtasten und das Ausgabevideo aus einem Frame-Puffer neu erstellen, wodurch eine Verzögerung von einem Frame entsteht.

Es ist zu bedenken, dass es selbst bei einer synchronen Quelle wahrscheinlich eine unbekannte Phasenverzögerung von der Synchronisierung bis zum idealen Zeitpunkt zum Abtasten eines Pixels gibt, sowohl als Konstruktionsdetail als auch aufgrund von Anstiegszeiten nach verschiedenen Kabeln und Treiber-/Empfangsnetzwerken.

Das ist (im Prinzip) ziemlich einfach. Sie versuchen nicht, Ihren 16-MHz-Takt einzurasten. Stattdessen bauen Sie einen Teiler, der die gleiche Frequenz wie Ihr Sync ausgegeben hat. Wenn Ihre horizontale Periode beispielsweise 63,5 us beträgt, sind dies 1.016 Zyklen von 16 MHz. Sie würden also die 16 MHz in eine durch 1016 geteilte Kette einspeisen und dann den Ausgang der Kette mit Hsync synchronisieren.

Das ist "im Prinzip" ziemlich einfach, aber der Teufel steckt im Detail. Sie müssen GENAU wissen, wie die Uhr mit der Synchronisation zusammenhängt, oder die neuen 16 MHz werden nicht an die Pixelpositionen gebunden. Sie müssen einen VCXO für einen Oszillator verwenden, oder der große Teilungsfaktor erzeugt Phasenjitter auf dem VCO, was das System unbrauchbar machen kann. Schließlich müssen Sie die Phasenverschiebung zwischen den Pixeln und den 16 MHz experimentell bestimmen, was Ihnen Probleme bereiten kann oder auch nicht.

Beachten Sie, dass dies mit einem 16-MHz-Oszillator mit fester Frequenz nicht möglich ist. Die Oszillatorfrequenz MUSS steuerbar sein und sollte vorzugsweise über einen sehr kleinen Bereich, wie 100 ppm, abstimmbar sein. Daher die Notwendigkeit für einen VCXO.

Pixeltakt mit Phasenkopplung zu HSYNC/VSYNC
AntwortenHierDatenschutz-Bestimmungen1y, 0v