Здравствуйте.
Случилось так, что нужно сделать генератор DVB-C 256QAM на чипе AD9789.
Знаний в этой области не хватает. Решил здесь задать пару вопросов. Больше по теории, чем по чипу.
Для тех кто не знаком с AD9789 скажу, что в составе у него QAM mapper, SRRC фильтры, rate converter, 16x интерполятор,
BFP.
Данные на него подаю с ПЛИС.
Первые шаги были удачными - подавая на вход константу, я видел на выходе синусоиду желаемой мною частоты (525 МГц)
и строб запроса данных на baudrate, которая мне нужна (5.хх МГц).
У чипа есть возможность вместо данных подсунуть данные внутреннего генератора псевдо-случайных последовательностей. Когда
его включил, то спектр стал красивым прямоугольником шириной 6 МГц. Т.е. всё как надо.

Далее решил генерить NULL пакеты. У нас имеется покупной генератор Dektec на этом же чипе. Если ему подсунуть ts файл, состоящий только из NULL пакетов, то он их генерит, и анализатор (тоже покупной) видит их и скидывает в файл.
Стал я генерить эти NULL пакеты в ПЛИС. Анализатор не может залочиться к моему девайсу. Стал смотреть спектр - красивого
прямоугольника нет и в помине. Данные NULL пакета (которые игнорируются при приеме) у меня все 0хFF. Т.е. из 188 байтов
пакета подавляющее большинство - 0xFF. Я предполагаю, что в такой ситуации спектр и не может быть красивым прямоугольником.
Если эти 0xFF я подменяю счетчиком, то спектр улучшается, но до красивого все равно далеко.
Я полез посмотреть спектр Dektec при генерации таких же NULL пакетов. Уних красота. Значит не шлют они так много
одинаковых байтов. Гляжу на шину данных - и точно, болтаются, будто там случайне числа. Я решил посмотреть, что сохраняет
анализатор, подключеный к Dektec. Оказалось, что сохраняются именно такие пакеты, какие я шлю (с 0xFF в качестве данных).
AD9789 конфигурируется по SPI. Я подпаялся к Dektec, чтобы узнать, как они его конфигуряют. Оказалось, что они не используют
встроенный mapper. Они шлют complex данные с выхода своего маппера. Т.е. выглядит, что последовательность одинаковых
байтов их маппер переделывает в последовательность разных complex данных. Мне калазось, что mapper просто из реального байта делает I и Q компоненты в не зависимости от предыдущего байта. По моей теории линии комплексных данных не должны вести себя так, как я увидел у Dectek.
Может ли кто-нибудь истолковать эти факты? Может ли быть, что маппер у них такой хитрый?
Или кто-нибудь имеет опыт работы с этим чипом?
Спасибо.

По-немногу разбираюсь в проблеме. Маппер вообще вообще не виноват. Перед передачей данные MPEG потока поддаются обработке: рандомизация и т.д.

А вопрос то в чём?Вы рандомизацию сосем не делали?Зря...

Если вы стандарт реализовали уже (ну а как иначе, если что то уже смотреть пытаетесь...) то там есть рандомайзер (http://www.etsi.org/deliver/etsi_en/300400_300499/300429/01.02.01_60/en_300429v010201p.pdf), так что постоянная инфа на входе должна давать равномерный спектр.

Спасибо за ответы.

=> _Anatoliy
Я не то, чтобы рандомизацию не делал, я вообще никак данные не обрабатывал Как говорится, сначала делаю, а потом думаю.

=> svalery
Спасибо за ссылку.

Уважаемые коллеги, стал разбираться с "подготовкой" данных перед пересылкой и забуксовал. Нужна ваша помощь.
Система у меня для северной Америки, она немного отличается от европейской. Первым этапом идет "framing", в котором
заголовки пакетов 0x47 MPEG-2 заменяются на контрольную сумму. Описание тут: http://eu.sabotage.org/www/ITU/J/J0083e.pdf
начиная с пункта B.4
Попытался я реализовать подсчет контрольной суммы по Figure B.2/J.83. Затем попытался декодировать по Figure B.3/J.83.
Результат отазался неверным. Есть несколько моментов, в которые хотелось бы внести ясность:
1. Как я понимаю, блок с названием Z-1497 это 1497 триггеров. Просто задерка на 1497 тактов.
2. Не понятно, тригера энкодера (в частности линия задержки) обнуляются только в самом начале или перед каждым пакетом (188 байт).
3. Первый бит результата (как для decoder, так и для encoder) забирается с выхода после первого такта или сразу, как
был подан входной бит? На схеме декодера видно, что со входа ны выход сигнал проходит в том же такте.
4. Декодер работает в скользящем режиме. Ни о каком обнулении речи не идет. Задержка в 1497 тактов приводит к тому, что
syndrome рассчитывается с использованием данных как текущего пакета, так и предыдущего. Может это говорит о том,
что в энкодере обнуление только перед первым пакетом?
5. Декодер может проверять пакет еще и по варианту с матрицей Р, Figure B.5
Тут видно что расчет ведется только по одному пакету. Это не укладывается в мою теорию, что Z-1497 - это задержка на 1497 тактов (вопрос 4).

Возможно, некоторые вопросы кажутся примитивными. Но прошу понять - не моя это область. Я больше по ПЛИС специализируюсь.
Пытался нарыть в инете хоть что-нибудь. О исходниках и не мечтаю. Хотябы тулзу, которая рассчитает чексумму,
чтобы знать что я должен получить. А то не знаю, то ли энкодер я изваял неверно, то ли декодер. То ли оба.



Сообщение отредактировал otv116 - Nov 2 2011, 19:42