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

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) я прекрасно понимаю как надо видео сигнал оцифровать, но вот возможности встроенного АЦП несколько ограничены, так что разрешением в любом случае придётся немного пожертвовать.