захват сигнала цветности на stm32f4+lm1881 Опции

[Огурцов]

есть ли идеи, как детектировать цветоразностные сигналы, не прибегая к существенным аппаратным дополнениям микроконтроллера ?

[Tarbal]

Если вы можете брать не менее 4х выборок за период, то я знаю как измерять частоту. Надо построить модель осциллятора в виде конечного автомата и синхронизировать его с входящей частотой.
Поскольку входящий синус имеет только два цифровых значения 0 и 1, то мы можем измерять фазу с точностью до 180 градусов. Добавив косинус удвоим точность.
Косинус из синуса получим при помощь дифферинцирования, а проще говоря просто вычитая предыдущее значение входного сигнала из последующего.
Правило перехода:
Или остаемся или переходим в следующее состояние (в зависимости от условий может и вперед через одно). Остальные входные значения игнорируем -- это добавит инерционности и устойчивости.

[Огурцов]

измерять фазу с точностью до 180 градусов

этого мало, это один что ли бит цветности получится

полоса цветоразностных сигналов - 1.3МГц, зачем им 17МГц?

в общем-то почти согласен
просто исхожу из того, что на один семпл яркости нужно полсемпла цветности

и АЦП в stm32 умеет 17.32МГц?

сходу не скажу, нужно проверить

при 168МГц есть 80тактов на отсчёт чтобы 2МГц обработать, неужели не хватит?

смотря для чего, где-то хватит прочитать из памяти, сложить и записать обратно
если на асме, то будет чуть оптимистичней

Не вижу ничего лучше прямого измерения частоты каждого периода субнесущей

весьма и весьма интересное решение, может сработать

[_pv]

смотря для чего, где-то хватит прочитать из памяти, сложить и записать обратно
если на асме, то будет чуть оптимистичней

80 тактов на пиксель пожалуй хватит чтобы на лету эту захваченную картинку в jpeg зажать,
а уж перемножить с синусом/косинусом из таблицы так тем более.

[Tarbal]

80 тактов на пиксель пожалуй хватит чтобы на лету эту захваченную картинку в jpeg зажать,
а уж перемножить с синусом/косинусом из таблицы так тем более.

Пиксели идут с частотой 27 мегагерц для progressive или 13.5 мегагерц для interlaced. Поскольку второе соответствует телевизионному формату, то 168/13.5 = 12.44. Для цветности будет 25 тактов на пиксель.

[_pv]

Пиксели идут с частотой 27 мегагерц для progressive или 13.5 мегагерц для interlaced. Поскольку второе соответствует телевизионному формату, то 168/13.5 = 12.44. Для цветности будет 25 тактов на пиксель.

нет там никаких пикселей, там есть только полоса сигнала в 6МГц, а в СТМ32 нет такого АЦП чтобы эти 6 МГц полосы с 27МГц оцифровать.

[Tarbal]

нет там никаких пикселей, там есть только полоса сигнала в 6МГц, а в СТМ32 нет такого АЦП чтобы эти 6 МГц полосы с 27МГц оцифровать.

Я вам говорю о параметрах цифрового отображения телевизионного сигнала. Если вы поставите стандартный преобразователь в цифровой сигнал, то именно так будет выглядеть картина и будут пиксели. Мне так удобнее считать и согласитесь это наиболее осязаемая оценка. Тем более, что мы обсуждали именно количество тактов процессора на пиксель.
Справка для оценок: Размер картинки для ПАЛ и СЕКАМ 576 на 720 пикселей. для НТСЦ 480 на 720.

[_pv]

Я вам говорю о параметрах цифрового отображения телевизионного сигнала.

1)полоса цветоразностных сигналов - 1.3МГц.
их можно конечно и на 100МГц оцифровать, и сказать потом что там на самом деле 5000 пикселей, но картинка от этого лучше не станет.
2) я прекрасно понимаю как надо видео сигнал оцифровать, но вот возможности встроенного АЦП несколько ограничены, так что разрешением в любом случае придётся немного пожертвовать.

[Tarbal]

1)полоса цветоразностных сигналов - 1.3МГц.
их можно конечно и на 100МГц оцифровать, и сказать потом что там на самом деле 5000 пикселей, но картинка от этого лучше не станет.
2) я прекрасно понимаю как надо видео сигнал оцифровать, но вот возможности встроенного АЦП несколько ограничены, так что разрешением в любом случае придётся немного пожертвовать.

100 мегагерц будет слижком и оно никому не нужно, но если провести исследования, то можно найти оптимальную частоту. Исследования были проведены, частота была найдена и стандартизирована. Именно ее я и привел.

Я вам рассказываю о стандартных значениях телевизионного сигнала в цифровой форме, а не о желаниях и предположениях. Поверьте мне на слово если вам лень посмотреть в интернете эти вещи (PAL SECAM NTSC) в цифровом формате стандартизированы и имеются соответствующие документы. Я привел значения из этих документов, а не мои мечты.

Например здесь приведен параметр:
Pixel Clock frequency
(digital sources with 704
or 720 active Pixel/Line)
https://en.wikipedia.org/wiki/PAL


Как вы думаете откуда взяты эти значения и что такое Pixel Clock frequency для PAL signal details если никаких пикселей в телевизионном сигнале нет. Я два года занимался цифровым видео в серьезной фирме и если будут вопросы -- обращайтесь.

Вот по-русски рассказывают, что пиксели таки есть:
https://ru.wikipedia.org/wiki/%D0%A1%D1%82%...BD%D0%B8%D0%B5)

мнения разделились
я сам не проверял, только 5 секунд чтения ds
12 мгц достаточно, 18 хорошо для видео, но уже избыточно для памяти и нагрузки на шину
кроме того, пиксели будут не квадратные

В телевизионном изображении пиксели итак не квадратные.
Формат кадра 3х4 дает 480х640, а никак не 480х720 NTSC. PAL Secam вместо 480 будет 576 при том же формате кадра.
Вот в стандарте VESA (компьютерные форматы) 460х640 один из стандартных форматов, но там все форматы имеют квадратные пиксели.

Вот тут я эксперементировал с АЦП F303:
stm32f303 АЦП 16 мГц
СТМ разогнан до 80 мГц

А это оцифровка видеосигнала внешним АЦП (СТМовский хуже-валит фронты):

Строчный синхроимпульс и вспышка.

В вспышке самое важное - ее фаза. Полагаю, что при таком разрешении фазу нелегко определить (если возможно). А вот цвета, которые непредсказуемы (неизвестно где какой и какой длины), детектировать будет еще трудней. Это приведет к дрожанию границ цвета да и самих цветов.

[_pv]

Я вам рассказываю о стандартных значениях телевизионного сигнала в цифровой форме, а не о желаниях и предположениях. Поверьте мне на слово если вам лень посмотреть в интернете эти вещи (PAL SECAM NTSC) в цифровом формате стандартизированы и имеются соответствующие документы. Я привел значения из этих документов, а не мои мечты.

да в цифровом формате пожалуйста, никто с этим не спорит.

раз вам так нравятся цифирки из википедии, нарисуйте пожалуйста как будет выглядеть картинка (720х576) из чередующихся пикселей (черные/белые, а особоенно хорошо если красные/синие) с частотой 13.5МГц, после прохождения через PAL, если там аналоговая полоса пропускания для цветоразностных сигналов - всего 1.3МГц? или цветонесущуюю 4.43МГц получается можно с частотой 6.25МГц промодулировать? да так, чтобы общая полоса в 5МГц взела?

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

Как вы думаете откуда взяты эти значения и что такое Pixel Clock frequency для PAL signal details если никаких пикселей в телевизионном сигнале нет. Я два года занимался цифровым видео в серьезной фирме и если будут вопросы -- обращайтесь.

да тема вроде как про аналоговое видео, а не про цифровое.

В вспышке самое важное - ее фаза. Полагаю, что при таком разрешении фазу нелегко определить (если возможно). А вот цвета, которые непредсказуемы (неизвестно где какой и какой длины), детектировать будет еще трудней. Это приведет к дрожанию границ цвета да и самих цветов.

если шумов там будет немного (SNR~50 учитывая амплитуду color burst) то по этим десяти периодам фазу при 15МГц оцифровки можно с где-то с 0.5гр определить, что к концу строки приведёт к расползанию на 150градусов и цвета поплывут, но если с усреднением по многим строкам думаю получится.