Джиттер при восстановлении тактовой синхронизации для PSK-сигналов Опции

[dsp_designer]

Добрый день!
Пытаюсь понять, как можно избавится от джиттера при востановлении символьной синхронизации в цифровом приемнике PSK и QAM-сигналов. В приемнике (на ПЛИС) реализуется восстановление фазы несущей и символьная синхронизация+ последующая обработка-декодирование и т.д. Реализовал тактовую синхронизацию как описано у Гарднера ("Interpolation in digital modems"), соответственно присутствует джиттер восстановленного clock-а (символьного). Когда номинальная символьная частота приемника отличается от символьной частоты принимаемого сигнала (а на практике это всегда так) символьный clock с выхода NCO периодически совершает "скачок", в результате чего получаем clock с джиттером, что не очень удобно с точки зрения построения остальной частотной сетки, привязанной к символьному clock-у, да и выходной clock в итоге получается "грязным". Как вариант - подстроить аналоговый ГУН под частоту символьного clock-a и получить более чистый clock, но это не всегда дает результат (при малых отстройках такта принимаемого сигнала от номинальной тактовой частоты приемника требуется чрезвычайно узкополосная ФАПЧ; при относительно больших отстройках clock получается более-менее). Еще есть другой подход - гибридная тактовая синхронизация (подстраиваем синхросигнал, подаваемый на АЦП, - опять-таки задействуем ГУН). В этом случае clock получаем без скачка, но возникает другая проблема: опорный синхросигнал (который подается на АЦП и используется в ПЛИС для цифровой обработки) становится зашумленным, особенно при малых отношениях сигнал/шум в канале связи. Этот синхросигнал используется помимо всего прочего и как опора для DDS, формирующего выборки cos и sin для восстановления фазы несущей, соответственно вносим в систему фазовый шум. Дополнительный фазовый шум ухудшает работу схемы восстановления несущей, особенно это заметно при малых скоростях передачи данных.
Заранее спасибо всем, кто выскажет какие-либо разумные идеи.

[dsp_designer]

Как вариант, можно, в самом деле, так сделать, хотя придется на каждом этапе преобразования частоты выставлять clock чуть выше, чем на выходе предыдущего блока. Не уверен, правда, что это будет оптимальный вариант. И, повторюсь, знаю, что есть решения для подобных приемников без всяких буферов и пауз.

[petrov]

Как вариант, можно, в самом деле, так сделать, хотя придется на каждом этапе преобразования частоты выставлять clock чуть выше, чем на выходе предыдущего блока. Не уверен, правда, что это будет оптимальный вариант. И, повторюсь, знаю, что есть решения для подобных приемников без всяких буферов и пауз.

Как-то всё валится в одну кучу. Как уже выше было сказано, FPGA тактируется заведомо большим клоком, синхронизация обработки данных осуществляется через enable сигналы, ниакой безджиттерности и лишних клоковых доменов для обработки не требуется. Необходимо чётко сформулировать почему требуется именно синхронная сеть, просто использовать это как средство от других проблем плохая идея.

[dsp_designer]

Как-то всё валится в одну кучу. Как уже выше было сказано, FPGA тактируется заведомо большим клоком, синхронизация обработки данных осуществляется через enable сигналы, ниакой безджиттерности и лишних клоковых доменов для обработки не требуется. Необходимо чётко сформулировать почему требуется именно синхронная сеть, просто использовать это как средство от других проблем плохая идея.

Мы принимаем сигнал со спутника, он имеет тот такт, который имеет, передача идет непрерывно. Чтобы не терять данные, нам нужно обрабатывать либо с той же скоростью, либо выше - это и так понятно. Если точно с той же скоростью, то это синхронная сетка из нескольких частот. В асинхронном случае - нужно как-то связать блоки между собой, причем каждый последующий должен работать быстрее, чем предыдущий, иначе опять-таки данные будут теряться. Что касается разных клоковых доменов, в настоящий момент как раз я использую одноклоковую синхронизацию + enable-ы, что разумеется, очень удобно. Когда я писал выше про разные клоки для разных блоков - это подразумевало в том числе и возможность использования одного clock-а c разными enable-ми.
Вообще мы ориентируемся на стандарты, по которым делают спутниковые модемы - начиная с IESS-308 и далее;честно говоря, вариант асинхронной работы я даже не рассматривал раньше (не знаю точно, есть ли против него противопоказания в стандартах, возможно, это неудобно будет для оконечного оборудования)+по существующим модемам сужу (а там на выходе clock и данные, причем нет никаких пауз).
Разумеется, безджиттерности для обработки не требуется, сейчас это все работает с джиттером, но выходной clock имеет джиттер и есть некоторые сложности с формированием enable-ов для существующей сетки частот, вот почему я и думаю, можно ли улучшить существующую схему. Простите, не хотел грузить никого, но вот такая у меня задачка. Я подумал, что возможно, кто-то из тех, кто занимается software defined radio, сталкивался с такими вопросами и сможеть подкинуть идею)

Сообщение отредактировал dsp_designer - Dec 2 2014, 14:26

[petrov]

по существующим модемам сужу (а там на выходе clock и данные, причем нет никаких пауз).

Но это не значит что символьная частота модема привязана к частоте синхронного потока и внутри протокола модема он передаётся без "пауз".