Есть ли смысл для уменьшения джиттера при передаче цифрового сигнала применять передатчики и приемники от систем передачи данных (HFBR-2416, HFBR-1414). Если да, то одномод или многомод? Если кто делал, поделитесь, пожалуйста, опытом.
Есть ли смысл для уменьшения джиттера при передаче цифрового сигнала применять передатчики и приемники от систем передачи данных (HFBR-2416, HFBR-1414). Если да, то одномод или многомод? Если кто делал, поделитесь, пожалуйста, опытом.
tomtit вы модуль spdif использовали CWda14 или свой?
браво!
думаю, есть смысл сделать модулечек. я бы купил такой для экспериментов, как и многие другие здесь
tomtit,
С интересом следил за продвиженем вашего проекта.
Поздравляю с воплощением на макете!
Хотелось бы задать несколько вопросов.
Насколько я понял, ARM используется только для загрузки Спартана?
В основном интересует реализация приемника spdif:
вы писали, что отказались от идей xapp224,
какой частотой клочится ваш теперешний приемник, или так же 4 фронта на UI?
Поток каких частот декодируется - 44/96/192кГц?
Насколько пОлно декодируется поток Channel Status - pro/cons, деемфазис, длина слова аудиоданных?
Сколько ресурсов занимает?
Насколько я понял, ARM используется только для загрузки Спартана?
-Да
В основном интересует реализация приемника spdif:
вы писали, что отказались от идей xapp224,
какой частотой клочится ваш теперешний приемник, или так же 4 фронта на UI?
-6 на UI
Поток каких частот декодируется - 44/96/192кГц?
-44.1
Насколько пОлно декодируется поток Channel Status - pro/cons, деемфазис, длина слова аудиоданных?
- Декодируется все но ничего не используется, незачем, и так играет.
Сколько ресурсов занимает?[/quote]
Декодер - 2-4%
Распаковка - 6%
АПЧ+интерфейс к управляющему ДАК - 10%
DF+FIFO+20bit DAC интерфейс - 67%.
Итого: 87% от XC3S200VQ100-4, что реально, под завязку.
Необходимо использовать ФПГА потолще и подлиннее, тогда и ресурсов уйдет меньше, такой вот парадокс.
Не использовал никаких IP, все делал сам, а инче бы и в миллионник не уложился.
Последний раз редактировалось tomtit; 13.01.2010 в 01:10.
Последний раз редактировалось SashaNetrusov; 13.01.2010 в 17:43. Причина: Добавлено сообщение
Tomtit,я так и подумал что IP не использовали
Если когда возможно поделитесь проектом - если он не коммерческий .
Какую серию хилинх посоветовали бы еще - хотелось бы
влепить туда фильтр на 16х в перспективе.
П.С. Cейчас очень много adsl модемов пошло и роутеров вай фай- есть и на
процессорах до 800 мгц. Там в основном arm сortex и куча переферии.
Как думаете перспективно или нет?
Понятно.
В принципе да. Если делать "в лоб", то нужно не менее 4 на ui. Ну, 3 хотя бы, в крайнем случае.
Получается, для 192кГц нужен клок близкий к сотне мегагерц.
Но ген на сотню мегагерц или даже pll внутри микросхемы, мне кажется некрасивым.
Поэтому, я прикинул, мультичастотный приёмник c mclk=128*fs должен уместиться в 128 ячеечный max7000.
Чем, как раз, и занимаюсь в данный момент.
У меня и не было большого выбора, как делать декодер, так как тактовая VCXO равна 33.8688/36.864 Мгц вот и получилось 6/UI. А 33.8 оптимальна для мультибитных ДАК-ов для формирования сигналов и реклока. Все АД имеют тактовую не выше 17МГц. Вообше-то приемник - очень простая вещь и занимает минимум ресурсов, поэтому собираюсь, со временем, придумать оптимальные решения для других частот и переключать блоки приемников, а не городить универсального монстра. Например, приемник для 44.1/48 с (х 6) клоком -это всего лишь 35 строк на верилоге, что транслируется в дюжину триггеров.
А если не ставить задачу решить все в цифре - то для декодирования ВМС кода достаточно 3 Д-триггеров и линии задержки - я использовал это решение будучи студентом, когда ПЛИС еще не существовали. Правда тот декодер не мог отлавливать маркеров с нарушением правил кодирования, но это и не было нужно, да и проект не имел никакого отношения ни к звуку ни к стандартам. А решение с 100МГц является обычным и используется, например, в WM8804, и я не вижу в этом ничего сильно плохого.
Желаю успехов!
2 Кокон: На счет раздачи исходников я еще не решил вопрос. Во-первых я наверняка нарушил пару-тройку чьих-то патентов, что может обернуться в Заокеании очень большими проблемами для меня самого. Во-вторых проект еще не проверен, как следует. Да и исходники без подробного разъяснения и математики никому понятны не будут - гарантирую полное разочарование. Sorry.
P.S. Необходимость 16Х оверсэмплинга вызывает у меня большие сомнения - ведь каждое удвоение тактовой удваивает также и мощность генерируемого ЦАПом глитча. Да и фильтр последней ступени будет очень короткий - около 5 ненулевых коеффициентов - практически это линейный интерполятор. Если бы проект был коммерческий - я был бы горой за 128-разрядный цап и за 1024-кратную интерполяцию и орал бы об этом на каждом углу, а так надо еще крепко подумать ...
Последний раз редактировалось tomtit; 16.01.2010 в 07:22.
...Чтобы избежать паразитной фазовой модуляции ГУН, между ДАК и ГУН д.б. RC цепочка с очень большой постоянной времени. Где нить десятки, а может и сотни секунд. Поэтому быстрое регулирование не подходит. Нужен большой буфер на DDR памяти. Например комповую линеечку. По включению частоту ГУН выставлять заведомо ниже примерно на 100ppm. Пока буфер наполняется несколько минут до середины мерять тупо среднюю входную частоту и устанавливать её на ГУН с точностью 1ppm. Буфер практически заморозится где то на середине, так что до следующеё коррекции уже понадобятся десятки минут...
Резонно. Только сотни, мне кажется, это уже нездоровый фанатизм. Единицы-десятки хватит.Адаптивную фильтрацию применять, да и всё. Захват производить быстрым методом, а на синхронизм вышел - тут уже можно и на сотни секунд перейти.Поэтому быстрое регулирование не подходит. Нужен большой буфер на DDR памяти. Например комповую линеечку. По включению частоту ГУН выставлять заведомо ниже примерно на 100ppm. Пока буфер наполняется несколько минут до середины мерять тупо среднюю входную частоту и устанавливать её на ГУН с точностью 1ppm. Буфер практически заморозится где то на середине, так что до следующеё коррекции уже понадобятся десятки минут...
Добавлено через 1 час 28 минут
для 100с в самом худшем случае, пока ФАПЧ не выберет разницу:
100ppm*100с=0.1с разбег. Реально намного меньше. А для 10с вобще всего 0.01с получится.
Последний раз редактировалось Syava; 18.01.2010 в 10:53. Причина: Добавлено сообщение
Действуйте, Саша, воплощайте сами все, что вы мне насоветовали, а я тут поржу потихоньку в уголке ...
Offтопик:
tomtit, примите мои поздравления с завершением проекта(ну практически)!
Социальные закладки