Синхронизация пикселей с синхронизацией по фазе в HSYNC/VSYNC

Я пытаюсь захватить пиксельные данные, идущие на небольшой черно-белый ЭЛТ-дисплей. Сигналы, с которыми мне приходится работать, — это сигнал пиксельных данных уровня TTL, HSYNC и VSYNC. Я знаю тактовую частоту пикселей (~ 16 МГц), но для моего приложения у меня нет доступа к тактовому сигналу пикселей.

Я хочу сэмплировать сигнал пикселя в соответствующее время (в середине битового периода, а не во время перехода), поэтому я решил, что мне нужно сгенерировать новый тактовый сигнал 16 МГц с некоторым фазовым отношением к фронту сигнала HSYNC и используйте это для выборки сигнала пикселя.

Я знаю, как использовать PLL для умножения тактового сигнала и поддержания определенного соотношения фаз между входом и выходом, но как мне поддерживать подобное соотношение между новыми тактовыми импульсами 16 МГц и сигналом, который лишь изредка имеет фронт (HSYNC) ?

Или есть лучший способ решить эту проблему?

Вы, вероятно, хотите замкнутый цикл алгоритма или программного обеспечения - с низкой полосой пропускания контура, которую вы могли бы настроить VCO в программном обеспечении. Или запустите более быстрые фиксированные часы, инициализируйте счетчик при синхронизации, а затем выберите рассчитанные интервалы счета после этого (возможно, с накопленными дробными значениями). Вы можете обнаружить, что цифровые мониторы с входами VGA имеют причудливые схемы, которые больше обращают внимание на фактические изменения данных для восстановления тактовой частоты, чем на синхронизацию. Ваш источник, вероятно, имеет низкую пропускную способность, поэтому, если ваша система выборки и ее место назначения могут справиться с этим, вы также можете выполнить передискретизацию и очистить результаты в программном обеспечении.
Также вы можете увидеть, можете ли вы просто использовать существующее решение для видеозахвата PCI или USB - если оно достаточно универсально, чтобы обрабатывать синхронизацию, переназначение аналогового уровня будет легко работать.
два вопроса: а) означает ли «уровень TTL» «двоичный», как в «черный ИЛИ белый», или он подразумевает «оттенки серого, где-то между 0 В и 5 В»? б) точно ли существует фиксированная связь между периодом HSYNC/VSYNC и тактовой частотой пикселей? Размышляя обо всей частоте кадров NTSC == 24,97 очень многих цифр в Гц, я бы предположил, что тактовая частота пикселей может быть восстановлена ​​​​независимо.
Если Hsync очень стабилен, то VCXO можно сделать стабильным, кратным Hsync, чтобы получить пиксельные часы. Но для выравнивания пикселей ЖК-дисплея может потребоваться регулировка фазы. Мой телевизор использует фактический видеосигнал для синхронизации, создавая часы пикселей, а затем вычисляет размер по горизонтали и вертикали, а также смещение или начало координат, чтобы минимизировать фазовую ошибку во всех пикселях и фиксируется за секунду. В 99% случаев при включении с пустым цифровым экраном он корректно блокируется без наложения пикселей. Мой вопрос заключается в том, насколько точны вы хотите, чтобы частота/фаза часов Pixel и насколько малы дрожания, и хотите ли вы, чтобы обнаружение блокировки активировало поиск/замораживание часов.
Также вам нужны пиксельные часы PLL, которые могут синхронизироваться с любой частотой пикселей? если да, то какой диапазон разрешений и частоты кадров?
Кстати, здесь это полностью в тему, но если вы хотите задать этот вопрос о том, как восстановить пиксельные часы , это был бы отличный вопрос для signal.stackexchange.com .
Кстати, возможно, даташит микросхемы видеодигитайзера будет полезен в качестве эталонной реализации: ti.com/lit/ds/symlink/tvp7002.pdf
Как-то я чувствую, что этот сигнал аналоговый? Тогда фаза тактовой частоты пикселей или тактовая частота дискретизации АЦП действительно не имеют большого значения, и на самом деле частота также не имеет большого значения. Вы можете передискретизировать его, если хотите.
@user3528438 user3528438, если бы источник информации был аналоговым, не было бы «пикселей» для захвата. Вероятно, это связано с цифровой схемой, генерирующей двоичный монохромный или аналоговый вывод в оттенках серого, поэтому для предотвращения артефактов потребуется либо выборка в правильное время, либо передискретизация и очистка в программном обеспечении. Это, вероятно, более важно, если вы хотите восстановить текст или линейную графику; если оригинал - это изображение с камеры, это может иметь меньшее значение.

Ответы (3)

Один из способов приблизиться к этому — использовать вашу PLL (со ссылкой на HSYNC) для генерации основных часов с тактовой частотой в 3 или 4 раза больше, чем тактовая частота пикселей, а затем использовать счетчик Джонсона для генерации новых тактовых импульсов пикселей с 3 или 4 различными значениями фазы. Затем вы можете выбрать фазу с желаемой синхронизацией либо вручную с помощью перемычки, либо электронным способом с помощью мультиплексора.

Есть способы привязать PLL непосредственно к прерывистому опорному сигналу (т. е. к самому видеосигналу), но, поскольку вы уже знаете номинальную частоту точек, в этом нет необходимости. Однако вы можете использовать фазовый детектор такой системы, чтобы автоматически выбирать лучшую фазу счетчика Джонсона для отбора проб.

На что бы вы сослались на PLL? Если вы имеете в виду, что у вас будут локальные часы, которые работают с частотой, кратной ожидаемой частоте пикселей, то я ожидаю, что она будет работать, но разница между этим и фактической частотой исходных часов вызовет случайные скачки между вашими различными вариантами фазы. . Если это происходит редко, хорошо, если несколько раз на экран, возможно, шаг фазы должен быть тоньше? С более высоким множителем все в порядке - и я ожидаю, что исходные пиксельные часы довольно медленные, поэтому внутри FPGA может быть возможно 10-кратное или более.
@ChrisStratton хорошо, частота дискретизации 160 МГц предъявляет нетривиальные требования к компоновке платы и АЦП, а также к скорости FPGA в системе; поэтому я думаю, что вопрос на самом деле в том, в сигнале с небольшими надежными переходами состояний, как ссылаться на PLL
@MarcusMüller - тактовая частота 160 МГц (или потенциально более быстрая) будет внутренней для FPGA, поскольку она необходима только для цифровой фазы фактической тактовой частоты выборки. Тактовая частота, направляемая на плате в АЦП, не должна быть быстрее, чем фактическая тактовая частота пикселя, если только не требуется передискретизация для постобработки. Эти тактовые частоты относительно приемлемы для простой логики в FPGA, однако попытка использовать PLL/DLL/какие-либо блоки FPGA может быть лучше.
а, значит, я неправильно тебя понял, @ChrisStratton. Да, это кажется осуществимым, и, поскольку умножение скорости линии на самом деле похоже на то, как это делают коммерческие ИС , да, это может быть выходом. С другой стороны: Мех. Я надеялся получить оценку скорости пикселя только по сигналу пикселя.

Это звучит как одноразовый проект (большинство просто мусорная технология B&W CRT).
Даже с такой старой технологией было принято получать все время от одних главных часов. Если это так, то HSYNC, скорее всего, синхронизируется с границами пикселей, что значительно упрощает разработку PLL.
Осциллограф, запущенный на HSYNC при просмотре видео TTL, скажет вам, синхронизирован ли HSYNC с часами пикселей? Если это так, вы также получите некоторое представление о джиттере, с которым придется иметь дело вашей PLL. А синхронный HSYNC значительно упрощает проектирование PLL. Даже в этом простом сценарии вы должны бороться с отсутствием ввода PLL во время вертикального обратного хода.

В случае несинхронных HSYNC, VSYNC восстановление часов вашего пикселя будет очень сложным. Возможно, вам просто придется передискретизировать пиксели и реконструировать выходное видео из буфера кадров, вводя задержку в один кадр.

Стоит учитывать, что даже с синхронным источником, вероятно, существует неизвестная фазовая задержка от синхронизации до идеального времени для выборки пикселя, как из-за детали дизайна, так и из-за времени нарастания после различных кабелей и сетей передачи/приема.

Это (в принципе) довольно просто. Вы не пытаетесь зафиксировать свои часы на 16 МГц. Вместо этого вы строите делитель, который имеет выходную частоту той же частоты, что и ваша синхронизация. Например, если ваш период горизонтальной развертки равен 63,5 мкс, это будет 1016 циклов по 16 МГц. Таким образом, вы должны передать 16 МГц в цепочку деления на 1016, а затем синхронизировать вывод цепочки с Hsync.

Это "в принципе" довольно просто, но дьявол кроется в деталях. Вы должны ТОЧНО знать, как часы связаны с синхронизацией, иначе новые 16 МГц не будут привязаны к позициям пикселей. Вам нужно будет использовать VCXO для генератора, иначе большой коэффициент деления вызовет дрожание фазы на VCO, что может сделать систему непригодной для использования. Наконец, вам нужно будет экспериментально определить фазовый сдвиг между пикселями и частотой 16 МГц, что может вызвать у вас проблемы, а может и не вызвать.

Обратите внимание, что вы не можете сделать это с генератором с фиксированной частотой 16 МГц. Частота генератора ДОЛЖНА быть управляемой, и желательно, чтобы ее можно было настраивать в очень небольшом диапазоне, например, 100 ppm. Отсюда необходимость в VCXO.

Синхронизация пикселей с синхронизацией по фазе в HSYNC/VSYNC
СпросиСетьПолитика конфиденциальности1y, 0v