Reloj de píxeles de bloqueo de fase a HSYNC/VSYNC

Estoy tratando de capturar datos de píxeles que van a una pequeña pantalla CRT en blanco y negro. Las señales con las que tengo que trabajar son la señal de datos de píxeles de nivel TTL, HSYNC y VSYNC. Conozco la frecuencia del reloj de píxeles (~16 MHz), pero para mi aplicación, no tengo acceso a la señal del reloj de píxeles.

Quiero muestrear la señal de píxel en el momento apropiado (durante la mitad del período de bit, no durante la transición), así que pensé que necesitaba generar un nuevo reloj de 16 MHz con alguna relación de fase con un borde de la señal HSYNC y utilícelo para muestrear la señal de píxel.

Sé cómo usar un PLL para multiplicar una señal de reloj y mantener una cierta relación de fase entre la entrada y la salida, pero ¿cómo mantengo una relación similar entre un nuevo reloj de 16 MHz y una señal que solo ocasionalmente tiene un borde (HSYNC)? ?

¿O hay una mejor manera de resolver este problema?

Probablemente desee un bucle bloqueado por algoritmo o software, con un ancho de banda de bucle bajo, puede ajustar el VCO en el software. O ejecute un reloj fijo más rápido, inicialice un contador en la sincronización y luego muestree los intervalos de conteo calculados a partir de entonces (posiblemente con conteos fraccionarios acumulados). Es posible que los monitores digitales con entradas VGA tengan esquemas sofisticados que miren los cambios de datos reales para la recuperación del reloj más que las sincronizaciones. Su fuente probablemente tenga un ancho de banda bajo, por lo que si su sistema de muestreo y su destino pueden manejarlo, también podría sobremuestrear y limpiar los resultados en el software.
También puede ver si puede usar una solución de captura de video PCI o USB existente; si es lo suficientemente versátil como para manejar el tiempo, la reasignación de nivel analógico sería fácil de resolver.
dos preguntas: a) ¿el "nivel TTL" implica "binario" como en "blanco o negro", o implica "escala de grises, en algún lugar entre 0 V y 5 V"? b) ¿es seguro que existe una relación fija entre el período HSYNC/VSYNC y el reloj de píxeles? Pensando en todo el negocio de frecuencia de cuadro NTSC == 24.97verymanydigits Hz, supongo que el reloj de píxeles podría recuperarse de forma independiente.
Si Hsync es muy estable, entonces un VCXO puede convertirse en un múltiplo estable de Hsync para crear un reloj de píxeles. Pero para alinear los píxeles de la pantalla LCD, es posible que sea necesario ajustar la fase. Mi televisor usa la señal de video real para sincronizar, crear el reloj de píxeles y luego calcula el tamaño H y V y el desplazamiento o el origen para minimizar el error de fase en todos los píxeles y se bloquea en un segundo. El 99 % de las veces al encenderse con una pantalla digital en blanco, se bloquea correctamente sin solapamiento de píxeles. Mi pregunta es qué tan precisa desea la frecuencia/fase del reloj de píxeles y qué tan pequeña es la fluctuación y desea detectar el bloqueo para activar el reloj de búsqueda/congelación.
¿También desea un reloj de píxeles PLL que pueda sincronizarse a cualquier velocidad de píxeles? si es así, ¿qué rango de resoluciones y velocidades de fotogramas?
Por cierto, esto es totalmente sobre el tema aquí, pero si desea hacer esta pregunta sobre cómo recuperar el reloj de píxeles , sería una excelente pregunta para Signals.stackexchange.com
Por cierto, tal vez la hoja de datos de un IC digitalizador de video sería útil como implementación de referencia: ti.com/lit/ds/symlink/tvp7002.pdf
¿De alguna manera siento que esta señal es analógica? Entonces, la fase del reloj de píxeles, o el reloj de muestreo ADC, realmente no importa tanto, y en realidad la frecuencia tampoco importa mucho. Puede sobremuestrearlo si lo desea.
@user3528438 si el origen de la información fuera analógico, no habría "píxeles" para capturar. Es probable que se origine con un circuito digital que genera una salida monocromática binaria o analógica en escala de grises, por lo que será necesario muestrear en los momentos correctos o sobremuestrear y limpiar en el software si se quieren evitar artefactos. Esto es probablemente más importante si se quiere recuperar texto o gráficos de líneas; si el original es una imagen de una cámara, puede que importe menos.

Respuestas (3)

Una forma de abordar esto sería usar su PLL (referido a HSYNC) para generar un reloj maestro a 3 o 4 veces el reloj de píxeles, y luego usar un contador Johnson para generar nuevos relojes de píxeles con 3 o 4 valores de fase diferentes. Luego puede seleccionar la fase que tiene el tiempo deseado, ya sea manualmente con un puente o electrónicamente con un multiplexor.

Hay formas de bloquear un PLL directamente a una referencia intermitente (es decir, la señal de video en sí), pero dado que ya conoce la tasa de puntos nominal, esto no debería ser necesario. Sin embargo, podría usar el detector de fase de dicho sistema para ayudarlo a seleccionar automáticamente la mejor fase del contador Johnson para el muestreo.

¿A qué haría referencia el PLL? Si quiere decir que tendría un reloj local que funciona a un múltiplo del reloj de píxeles esperado , entonces esperaría que funcionara, pero la diferencia entre eso y la frecuencia del reloj de origen real causaría saltos ocasionales entre sus diversas opciones de fase. . Si esto sucede rara vez, bien, si varias veces por pantalla, ¿quizás los incrementos de fase deban ser más finos? Con un múltiplo más alto, parece estar bien, y espero que el reloj de píxeles original sea bastante lento, por lo que es posible 10x o más dentro de un FPGA.
@ChrisStratton bueno, una frecuencia de muestreo de 160 MHz impone un requisito no trivial para el diseño de la placa y ADC, así como la velocidad de FPGA en el sistema; entonces creo que la pregunta realmente es, en una señal con transiciones de estado poco confiables, cómo hacer referencia a un PLL
@MarcusMüller: el reloj de 160 MHz (o potencialmente más rápido) sería interno para el FPGA, ya que solo se necesita para poner en fase digitalmente el reloj de muestra real. El reloj enrutado en la placa al ADC no necesita ser más rápido que el reloj de píxeles real, a menos que se desee un sobremuestreo para el posprocesamiento. Estas velocidades de reloj son relativamente compatibles con la lógica simple en un FPGA, sin embargo, tratar de aprovechar los bloques PLL/DLL/lo que sea de un FPGA podría ser mejor.
ah, entonces te entendí mal, @ChrisStratton. Sí, eso suena factible, y como la multiplicación de velocidad de línea en realidad parece ser la forma en que lo hacen los circuitos integrados comerciales , sí, ese podría ser el camino a seguir. Por otro lado: Meh. Esperaba una estimación de la tasa de píxeles solo a partir de la señal de píxeles.

Esto suena como un proyecto único (la mayoría simplemente desecha la tecnología CRT en blanco y negro).
Incluso con una tecnología tan antigua, era común derivar todos los tiempos de un reloj maestro. Si es así, es probable que HSYNC esté sincronizado con los bordes de los píxeles, lo que facilita considerablemente el diseño de PLL.
¿Un 'alcance activado en HSYNC mientras mira un video TTL le diría si HSYNC está sincronizado con el reloj de píxeles? Si es así, también tendrá una idea de la fluctuación con la que tendrá que lidiar su PLL. Y el HSYNC síncrono facilita considerablemente el diseño de su PLL. Incluso en este escenario fácil, debe lidiar con no tener entrada de PLL durante el retroceso vertical.

En el caso de HSYNC, VSYNC no síncronos, la reconstrucción de su reloj de píxeles será muy difícil. Es posible que solo tenga que sobremuestrear píxeles y reconstruir el video de salida desde un búfer de cuadro, introduciendo un retraso de un cuadro.

Vale la pena considerar que incluso con una fuente síncrona, probablemente haya un retraso de fase desconocido desde la sincronización hasta el momento ideal para muestrear un píxel, tanto como un detalle de diseño como debido a los tiempos de subida después de varios cables y redes de transmisión/recepción.

Esto es (en principio) bastante fácil. No intenta bloquear su reloj de 16 MHz. En su lugar, construye un divisor que tiene una salida de la misma frecuencia que su sincronización. Por ejemplo, si su período horizontal es 63,5 usec, esto es 1016 ciclos de 16 MHz. Entonces, alimentaría los 16 MHz en una cadena dividida por 1016, luego sincronizaría la salida de la cadena con Hsync.

Esto es, "en principio", bastante sencillo, pero el diablo está en los detalles. Debe saber EXACTAMENTE cómo se relaciona el reloj con la sincronización, o los nuevos 16 MHz no se bloquearán en las posiciones de píxeles. Deberá usar un VCXO para un oscilador, o el gran factor de división producirá una fluctuación de fase en el VCO que puede hacer que el sistema quede inutilizable. Finalmente, deberá determinar experimentalmente el cambio de fase entre los píxeles y los 16 MHz, lo que puede o no causarle problemas.

Tenga en cuenta que no puede hacer esto con un oscilador de 16 MHz de frecuencia fija. La frecuencia del oscilador DEBE ser controlable y preferiblemente debe ser sintonizable en un rango muy pequeño, como 100 ppm. De ahí la necesidad de un VCXO.

Reloj de píxeles de bloqueo de fase a HSYNC/VSYNC
RespuestasAquíPolítica de privacidad1y, 0v