[Stepan25 0]

Не надо путать истерию по поводу "свободного ПО" и вопросы защиты моих коммерческих интересов :)

Я ж просто не профи в этих делах, я думал что самое сложное здесь это именно идея такой схемы. А код можно и самому переписать, но наверное ошибался...

[Rst7 5]

я думал что самое сложное здесь это именно идея такой схемы. А код можно и самому переписать

 

Ну тут очень взаимосвязаны код и схема. Но больше всего мне там дорог jpeg-кодер ;)

[Stepan25 0]

Ну тут очень взаимосвязаны код и схема. Но больше всего мне там дорог jpeg-кодер ;)

Просто аппаратное обеспечение это не софтварное... Если кто-то украдет незаконно вашу код, сделает прошивку, выпустит на ней девайс, залочит все биты для считывания, но вы никогда не узнаете что код ураден. Тут выявить это посложнее...

[Dmitro25 0]

Собрал на макетке данный кодер. Не сразу, но всё заработало.

В качестве источника видеосигнала подал сигнал с выхода видеокарты (разъём S-Video).

Однако, есть один не очень приятный эффект: иногда кадр начинается не с начала, а с отступом примерно 20% от верха кадра (полученный кадр сдвинут относительно реального вниз на 20%). Причём, это происходит не всегда.

Подскажите, в чём может быть дело?

[Rst7 5]

Видимо, не совсем правильно работает синхроселектор. Осциллограммы на всех точках синхроселектора в момент кадрового синхроимпульса в студию.

[Dmitro25 0]

Вопрос про сдвиг кадра снимаю. Оказывается, это была особенность вывода изображения с выхода используемой мною видеокарты. В ней был установлен режим, когда на TV-выход идёт изображение не всего экрана, а только части, и эта часть определяется положением указателя мыши в текущий момент времени. Когда я смещал курсор мыши сильно вниз, видеовыход начинал выводить картинку не с начала экрана.

Просто на днях из Китая пришло USB устройство видео/аудиозахвата, и я увидел картинку в динамике...

 

Хочу попробовать использовать вместо синхродетектора на V2 микросхему LM1881, мне кажется, это более "честный" синхродетектор. Кроме того, прочитал документацию на TDA8708. Там пишут, что есть два режима работы микросхемы: Mode1 и Mode2. И микросхема должны сначала работать в Mode1, а затем, когда сигнал станет устойчивым, переключаться в Mode2. В данном проекте, насколько я понял, используется только Mode1.

Просто у меня в получившемся JPEG картинка слишком тёмная, недостаточно белого цвета, вот я и подумал, что, может быть, автоподстройка уровня и усиления работает недостаточно хорошо, может быть, нужно второй режим использовать...

Всё осложняется тем, что у LM1881 инверсный выход (во время синхроимпульса низкий уровень), а также тем, что у используемого процессора категорически не хватает ножек...

Придётся, наверное, использовать дополнительный инвертор на транзисторе и получившийся GATEA подавать прямо на TDA и на контроллер, а GATEB формировать контроллером в зависимости от режима работы (Mode1 или Mode2).

Вот только когда переключаться в из Mode1 в Mode2 и обратно? При срыве синхронизации, что ли?

[yarunt 0]

Ну тут очень взаимосвязаны код и схема. Но больше всего мне там дорог jpeg-кодер ;)

Извиняюсь за нахальство,у вас есть такой-же оптимальный вариант декодера ,для арм?

[Rst7 5]

Извиняюсь за нахальство,у вас есть такой-же оптимальный вариант декодера,для арм?

 

Декодера? Декодера нет, не делал. Кодер есть, выложен, поиск по форуму рулит. Не забываем про GPL-лицензию ;)

[Dmitro25 0]

Попробовал запустить TDA8708 в Mode1 и Mode2. Попробовал включить его в Mode1 - получил целиком белую картинку, правда диаграммы немного отличались от приведённых в даташите из-за того, что выход детектора синхроимпульсов идёт прямо на GATEA АЦП, а также из-за того, что GATEA нельзя принудительно устанавливать в нижний уровень до окончания строчного синхроимпульса (иначе не определить начало кадрового). Но GATEB я гарантированно устанавливал в 1, когда ещё GATEA был в 1.

Пришёл к выводу, что всё-таки в оригинальном проекте у видео-АЦП включается режим Mode2, несмотря на то, что в программе сигнал GATEB устанавливается в 1 сразу же после установки в 0 сигнала GATEA (без паузы).

Попытался искусственно снизить амплитуду сигнала с видеокамеры до 0.6..0.8 Vpp (исходная была 1-1.2 Vpp) - картинка стала тусклее, а именно пропали элементы с кодом яркости от 0xE0 до 0xFF (в несжатом виде), хотя, судя по описанию на TDA сигнал от 0.6 В АРУ должна была отработать.

Также попробовал вместо детектора синхроимпульсов на транзисторе использовать микросхему LM1881. При использовании этой микросхемы необходимо слегка менять программу, поскольку длительность генерируемого LM-кой синхроимпульса превышает 5 мкс, и оригинальная программа детектирует его как кадровый. Но особого преимущества от использования этого специализированного детектора не получил - исходная схема нормально детектирует синхроимпульс в достаточно широком диапазоне амплитуд входного сигнала. Может быть, если бы видеосигнал шёл издалека, у него бы портились фронты, тогда бы имело смысл использовать эту ИМС, а так смысла, похоже, нет.

 

Есть пара вопросов:

1. Просмотрел отсканированный несжатый растр и увидел, что в нём присутствует небольшое число элементов с яркостью меньшей, чем 64 (в частности, 59, 60, 61, 62, 63), т.е. элементы "Чернее чёрного". Не происходит ли при преобразовании в JPEG их превращение в "белые" - ведь там встречаются формулы вроде

__fractional_multiply_unsigned(r-64,170)>>8

?

2. Просмотрел код файла "grab.asm" и проникся большим уважением к автору проекта. Вы очень остроумно применили код Грея для перекачки значений с выхода видео-АЦП во внешнюю память, и макрос для этого просто класс. Вот только возник вопрос: а насколько целесообразно использовать именно код Грея для генерации нового адреса? Ведь можно было вместо инструкций cbi/sbi использовать что-то вроде

ldi ZL, CUR_ADR
out ADR_LO, ZL

(ну, всё это в макросе, конечно). Один раз за весь цикл пришлось бы, конечно, поменять A17 вручную, но один пиксел роли не сыграет... Код процедуры захвата тоже в почти 2 раза возрастёт по объёму, но зато при дальнейшем сжатии в JPEG мы получим линейную адресацию пикселов, и, возможно, более быструю процедуру сжатия?

[Rst7 5]

Попробовал запустить TDA8708 в Mode1 и Mode2....

 

Посмотрите, какая у Вас TDA8708, с буквой А или нет. Ибо там разные номиналы в обвязке нужны.

 

Есть пара вопросов:

1. Просмотрел отсканированный несжатый растр и увидел, что в нём присутствует небольшое число элементов с яркостью меньшей, чем 64 (в частности, 59, 60, 61, 62, 63),

 

Не должно таких элементов там быть, если есть - нифига АЦП не пашет. А это умножение приводит из диапазона 64-255 в диапазон 0-255.

 

Вот только возник вопрос: а насколько целесообразно использовать именно код Грея для генерации нового адреса?

 

Плату я плохо развел, когда сразу переключалось много линий адреса - появлялась помеха на изображении (вертикальные полосы, чем больше адресов переключалось, тем жирнее полоса). Код Грея эту проблему снял, ибо единоразово меняет состояние только один бит адреса.

 

 

 

 

 

исходная схема нормально детектирует синхроимпульс в достаточно широком диапазоне амплитуд входного сигнала.

 

А то :) УПИМЦТ ;)

[Dmitro25 0]

Посмотрите, какая у Вас TDA8708, с буквой А или нет. Ибо там разные номиналы в обвязке нужны.

У меня TDA8708АТ, как и у Вас в схеме.

Не должно таких элементов там быть, если есть - нифига АЦП не пашет

У меня сложилось впечатление, что АЦП всё-таки работает, просто, похоже, камера выдаёт в видеосигнале просечки, которые иногда опускаются чуть ниже уровня чёрного. Я посмотрел на осциллографе, и, похоже, наблюдал такие моменты.

Я немного модифицировал процедуру Main, чтобы по команде "L" выдавалась не одна строка, а весь растр.

По полученным данным я определил, что максимальное значение яркости равно 0xFF, а минимальное - не 0x40 как предполагалось, а 0x3A (меньше не наблюдал).

Пример прикреплён к сообщению.

Использовалась чёрно-белая камера SK-1004.

picture.rar

[Rst7 5]

У меня TDA8708АТ, как и у Вас в схеме.

 

Я сейчас уже не помню, какие номиналы записаны в выложенной схеме (глянуть не могу), но сравните их с номиналами в даташите - конкретно та цепь, которая суть фильтр НЧ между входным каскадом микросхемы и собственно АЦП. Там серьезно влияют номиналы резисторов.

[Dmitro25 0]

Я сравнивал, в даташите почти всё как у Вас в схеме. Отличаются только номиналы фильтрующих емкостей по питанию, цепочка между VCCD и VCCO чуть другая, на OF рекомендуют кондёр вешать и на вход CLK рекомендуют ставить небольшой фильтр. Но номиналы емкостей на ногах AGC и CLAMP такие же. Фильтр между ANOUT и ADCIN такой же.

Мне кажется, что возникающая разница между уровнем чёрного и минимальным значением на выходе АЦП не так уж велика - максимум 6 единиц. Можно будет попробовать вставить дополнительную проверку в программу, чтобы не появлялись артефакты. Хотя, честно говоря, я этих артефактов не наблюдал, (хотя и не приглядывался специально). По расчётам, эти пиксели должны иметь яркость от 0x4C до 0x52.

Ещё вопрос возник про масштабирование яркости: почему умножение идёт на 170, а не на 171?

Ведь (255-64)*170*2>>8=253, а (255-64)*171*2>>8=255

[TU-104 0]

Есть альтернатива за 2 бакса?

интересный проектик...

Я, может опоздал года на 3, но она 10$ стоит :laughing:

За такую цену, может TVP7000PZP ? как думаете пойдет?

даташит тут http://focus.ti.com/general/docs/lit/getli...mp;fileType=pdf

пишут, что встроена PLL, экстрактор сигналов Sync .

[Rst7 5]

Я, может опоздал года на 3, но она 10$ стоит

 

Да, остатки, цена растет. Хоть и не в 5 раз. Но это не суть, суть в том, что АЦП надо поменять. В принципе, достаточно любого параллельного АЦП, лишь бы обеспечивал 8Мсемплов/с. Ну и надо схемку привязки черного сгородить. Уровень сигнала можно корректировать и в кодере (домножением, оно там все равно выполняется).

 

может TVP7000PZP ?

 

Хороший камень, но уж очень избыточен. Да цена кусается для поделки выходного дня.