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

SECAM? Там же 3-4 мегагерца модулированы кажется амплитудно, а в PAL и NTSC фазовая модуляция это налагает жесткие требования на стабильность частоты выборки. Сомневаюсь, что сможете обойтись без ЦОС, но лучше не изобретать велосипед, а поставить специальную микросхему. Она и оцифрует.

в secam хоть и частотная, но декодировать её гораздо проще, чем квадратурную pal/ntsc
так что 1/3 решения уже есть

Вам осталось сделать частотный детектор Вернее два. Там ведь две цветоразностные и у каждой своя субнесущая.

Кстати знаете один из вариантов расшифровки аббревиатуры NTSC? Never the same color. Помеха, вызвавшая искажение фазы изменит цвет. Наибольшее удовольствие вызывает пролетающий самолет вызывающий периодические пульсации цвета. Хотя сегодня передают в цифре и все это уже отходит на второй план.

Так там 3 АЦП х 2.5MSPS, с интерливингом вместе до 7.5МГц, и полосой пропускания МГЦ до 20 вроде. Так что цветоразностные сигналы с полосой в пару МГц даже встроенным АЦП захватить вроде как проблемы нет.
Взять с STM 3мя АЦП, два из них запустить в интерливинг на максимум в 5МГц, для яркости, пропущенной через ФНЧ.
А оставшийся АЦП запустить на 1.97МГц и на него сигнал подать через полосовой фильтр 4.43 +- 1МГц, тогда цвет с несущей 4.43 (PAL) ему прямо в середину пятой зоны Найквиста попадёт, даже без переворота спектра.
Собстветнно тут lm1881 не нужен. Уж синхронизацию-то выделить не самая большая проблема, а если чего ставить дополнительно, то тогда лучше сразу декодер целиком на DCMI.

вроде бы по-очереди



вы меня заинтриговали, намёк понял, однако вопрос деталей и реализации
с другой стороны, если мы будем пропускать выборки, то очевидно потеряем разрешение
а оно по цвету и так невелико
так что цифровать, как мне кажется, нужно на 17,32 мегагерц
что позволит декодировать квадратурный сигнал пал путём сложения-вычитания
тогда как для секам видимо должно быть достаточно 8,812 и 8.5 мегагерц
лишь бы pll успевало перестроиться за время обратного хода


не, тактовая совсем невелика, чтобы всё математикой в лоб решать


неспортивно

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


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

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

Нет. Не получится так. Слишком низкое разрешение. Для модема где частоты разнесены будет работать, а для демодуляции ЧМ нет. Не вижу ничего лучше прямого измерения частоты каждого периода субнесущей.
Настраиваете input capture для таймера. Входную частоту таймера делить не надо -- это снизит точность измерения. Сигнал субнесущей через компаратор на вход input capture и в прерываниях считываете периоды. Если помех не будет, то будет работать. Если есть вопросы -- отвечу.

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




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


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


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



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

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

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

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

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

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

в стм есть такой ацп, которым можно около 6.5 * 2 == 13 мгц оцифровать
этого должно быть вполне достаточно для видео


если с секам уже понятно, то что делать с пал/нтсц ?

у f4 - нет, разве что только у f303, но там ядро 72МГц, отсутствует внешняя память, а внутренней совсем немного.

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

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

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

сложить кадр ему некуда, а в jpeg пожать на лету - силёнок не хватит.
а f4 c уменьшенным разрешением, соответствующим возможностям его АЦП, может и справился бы.

странно, в моём есть
скажите, а вот как синхру поймать, успеет ?
ибо lm1881 преотвратительнейшее создание, не имеет pll, ловит тупо компаратором

ну может тогда точное название МК укажете?
а то насколько я знаю во всех F4 АЦП до 2.4МГц, в некоторых есть по 3 штуки которые в interleave умеют работать все вместе.

картинку двумя постами выше видите?

это 7.2мгц * 15 тактов
или 12мгц * 9 тактов

15 тактов * 3 ацп
9 тактов * 2 ацп

В 8 битном режиме 7.2 MSPS (10 тактов)
В 6 битном режиме 9 MSPS (8 тактов)

Два АЦП дают 18 MSPS при 6 битах.
Но это в interleaved mode - либо вычитывать в память через ДМА, либо на асме считать четко такты.
При 18 мГц на все про все 4 такта между измерениями.

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

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)




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



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

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

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

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


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


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

а в секаме не нужна фаза



если взять секам 576 линий умножить на 4 разделить на 3, то получится 768, а не 640

Вы вроде про пал и нтсц тоже говорили

да, а так же, про то, что не понятно, как их победить

Да непонятно и даже не уверен, что возможно. В американских телевизорах видеодецодер сделан без линии задержки как это делается в ПАЛ. С линией задержки вроде как две оси разложения вектора цветности. Поэтому цвет сильно зависит от помехи и может измениться от шума, при наличии отраженногио сигнака.
К чему я это? А вот к тому, что даже там где нет проблем с быстродействием (аналоговая схема) есть масса других проблем. А ведь есть еще множество разных модификаций всех трех стандартов.
Вы из проблем них не выберетесь. Если же взять специализированнуя микросхему, то там все сделано.
Все конечно зависит от поставленной задачи. Мне она неизвестна.

PAL меняет фазу одного цветоразностного сигнала через строку, так что ошибка меняет знак, а линия задержки помогает усреднять 2 строки в идеале подавляя ошибку (фазы).

Обычно для оцифровки используют ровно 4х поднесущую цветности (4.43 или 3.58), но синхронно с фазой, захваченой PLL по вспышке. Но если захватить поднесущую, то можно и выделить аналоговые Y-R и Y-B и цифровать на относительно низкой частоте. Я про PAL/NTSC - с Секамом дела не имел.

Так вот речь как я понял о том чтобы PLL в программе исполнить. Если часть рещить аппаратно, то все упрощается немеряно. Самое простое будет поставить специализированный чип.

Какой специализированный чип?
STM32F4 "в лоб" видеосигнал не оцифрует. Нужно либо подстраивать тактирующий МК кварц, либо ставить мультистандартный декодер. В любом случае всё начинается с привязки к цветовой вспышке, причём аналоговыми средствами. Существует ли ГУН на 4.43361875 и 3.579545 МГц с диапазоном перестройки порядка 250 ppm?

Не знаю, насколько это важно при оцифровке, но в SECАMe фаза сигнала меняется через пару строк для снижения заметности
муара от поднесущей.

Хех... Затея обречена на провал, с громким треском. Даже DSP процессора не оцифровывают сигналы цветности самостоятельно, а используют для этого аппаратные декодеры. Конечно, возможно оцифровать и ресурсами STM, но смотреть такой сигнал вряд-ли кто то захочет. А могут ещё и побить...

Video Decoders

Уточнение:

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

Даже после оцифровки с помощью ADV7xxx, прикрученного на параллельную шину камеры DCMI не совсем понятно, что потом с потоком делать. Его же перекодировать надо для показа на экране, а ресурсов не хватает. Более-менее начал справляться только STM32F746. А до этого только захват отдельных кадров получалось сделать.