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

[dsp_designer]

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

[petrov]

привязанной к символьному clock-у

Не стоит цепляться за плохую идею.

[dsp_designer]

А что делать... В приемнике частоты должны быть синхронизированы с тактом принимаемого синала

[petrov]

А что делать... В приемнике частоты должны быть синхронизированы с тактом принимаемого синала

Данные вы приняли правильно, им на джиттер наплевать, дальше работайте с местными опорными генераторами.

[dsp_designer]

Местные генераторы надо подстраивать под символьную частоту, приемник рассчитан на непрерывный поток данных. Асинхронный вариант не подходит, fifo-буферы переполнятся/ опустеют в любом случае.

[petrov]

Местные генераторы надо подстраивать под символьную частоту, приемник рассчитан на непрерывный поток данных. Асинхронный вариант не подходит, fifo-буферы переполнятся/ опустеют в любом случае.

Не надо. Переполнение/опустошение решается на уровне протокола передачи данных.

[dsp_designer]

Если предусмотрена возможность пауз, то да. Но не в этом случае

[petrov]

Если предусмотрена возможность пауз, то да. Но не в этом случае

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

[dsp_designer]

Спутниковая связь. Синхронизация должна восстанавливаться приемником

[petrov]

Спутниковая связь. Синхронизация должна восстанавливаться приемником

Синхронизация восстанавливается для нормальной демодуляции, данные вы получаете, никакой необходимости тащить удалённый клок не видно.

[dsp_designer]

Нужна дальнейшая обработка данных (преобразование символов в битовый поток,декадрирование, декодирование; на каждом шаге при этом частота после преобразования будет отличаться в n/k раз от входной, к примеру, после декодирования с кодовой скоростью 3/4 получим частоту данных точно равную 3/4 от входной), в итоге данные и clock передаются на внешний синхронный интерфейс. В модеме CDM600, для примера, выходной clock, сопроводающий данные, синхронен с clock-ом передатчика. Я проверял Я слабо себе представляю как можно было бы обойтись здесь без полностью синхронной сетки частот. Собственно я ее и так формирую сейчас в цифре, но у меня все с джиттером получается в итоге.

[Fat Robot]

Сигналы синхронного межблочного интерфейса:

clock
data[]
data_enable

Fclock может в этом случае быть больше скорости передачи данных data[].

Я слабо себе представляю как можно было бы обойтись здесь без полностью синхронной сетки частот.

[dsp_designer]

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

[petrov]

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

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

[Fat Robot]

Поставьте сразу один clock с высокой fclk для всех блоков.

Сигналы
data[] и data_enable формирует блок-источник

clock - тактовая частота всей системы от внешнего генератора. Она в общем случае никак не связана со скоростью передачи данных data[], просто выше ее.

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

[thermit]

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

Например, если транслируется поток е1. Здесь надо формировать синхронный удаленному входу выход.

[petrov]

Например, если транслируется поток е1. Здесь надо формировать синхронный удаленному входу выход.

А зачем это привязывать к символьной частоте модема?

[thermit]

А зачем это привязывать к символьной частоте модема?

Скорость данных нужно как-то оценивать для формирования соответствующего клока.

[dsp_designer]

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

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

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

[petrov]

Скорость данных нужно как-то оценивать для формирования соответствующего клока.

Нужно в оконечной точке, но заставлять работать 1000 модемов по пути на этой частоте не нужно.

[thermit]

Нужно в оконечной точке, но заставлять работать 1000 модемов по пути на этой частоте не нужно.

Дык об этом и речь, на сколько я понял. тсу не нравится выходной клок.

[petrov]

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

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

[dsp_designer]

В оконечной точке тоже просто так clock синхронный не получить из-воздуха. Данные же на выход поступают с некоторой средней частотой. Если они идут в выходной буфер с паузами (если реализовать асинхронно), то как-то надо будет выудить информацию о средней частоте и подстроить локальный генератор. То что я сейчас делаю - подстраиваю vco под свой внутренний цифровой clock с джиттером, но результирующий clock тоже получаю с джиттером, хотя и с меньшим. Уменьшать шумовую полосу ФАПЧ до бесконечности тоже невозможно - стабильность тактовой частоты конечна+ еще нужен запас на эффект Доплера в спутниковом канале.

[petrov]

В оконечной точке тоже просто так clock синхронный не получить из-воздуха. Данные же на выход поступают с некоторой средней частотой. Если они идут в выходной буфер с паузами (если реализовать асинхронно), то как-то надо будет выудить информацию о средней частоте и подстроить локальный генератор.

Её восстанавливают по самому потоку данных, если джиттер прихода данных небольшой, то ФАПЧ по указателю FIFO, иначе ФАПЧ по счётчикам потока, ну и надёжный протокол, чтобы отрабатывать пропуски.

[des00]

А зачем это привязывать к символьной частоте модема?

позвольте вмешаться: есть модемы задача которых передача данных. есть модемы которые помимо передачи данных решают задачу передачи синхронизации. Например это модемы которые работают в режимах Sync-E (с различными видами синхронизации), модемы SDH, nЕ1, они же в том числе работают и в многопролетных вариантах, в спецприменениях. На качество восстановления синхронизации накладываются требования на остаточный джиттер, его маски, вандер и т.д.

ТС: В вашей системе так и должно быть. Метод лечения зависит от требуемого качества восстановления тактовой частоты и последующего оборудования. Если вам нужен очень качественный клок, то единственный вариант это использование узкополосного деджитера на выходе (с холдовером, если он вам нужен). Насчет узкополосности ФАПЧ вы зря переживаете. Рассчитайте смещение символьной частоты при движении спутника со скоростью ну хотя бы 20км/с на малых углах возвышения, там получаются копейки.

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

Не совсем понятно где именно вам мешает сигнал enable с NCO, который является сигналом валидности данных. Если все решается внутри одной ПЛИС то проблем нет в принципе, если вам нужно передать между устройствами, то это определяется возможностями интерфейса устройств и их возможностями по обработке входных данных и клока.

[dsp_designer]

Да, все внутри ПЛИС. enable с NCO я сейчас использую для формирования сетки других enable-ов (у меня все синхронно сделано сейчас, как я уже выше упоминал). Коэффициенты преобразования частот разные, например, 3/4, 7/8, 2/3, но есть и что-то вроде 1235/1456 (условно), для них уже есть некоторые сложности. Отсутствие джиттера уменьшает проблему. Некоторое уменьшение джиттера я уже делаю в ПЛИС сразу после тактового синхронизатора (с помощью передискретизации и полосового фильтра).
Исхожу из стабильности такта на прием в 2*10^(-5). в принципе, при такой разнице по такту ФАПЧ подавляет периодические скачки неплохо, но если отстройка по такту совсем маленькая, то периодические скачки clock-а ФАПЧ отслеживает->clock на выходе также колебания совершает).

[des00]

Коэффициенты преобразования частот разные, например, 3/4, 7/8, 2/3, но есть и что-то вроде 1235/1456 (условно), для них уже есть некоторые сложности.

Судя по всему вы делаете это для корок декодеров и т.д. А авторы которые делали эти декодеры, не озаботились реализацией сигнала валидности данных? Может быть проще эти корки переписать и сделать по-человечески? Ведь по факту вы занимаетесь прореживанием данных, что легко делается с помощью банального счетчика по сигналу enable. Чистить тактовую нужно уже на выходе сигнала из ПЛИС на другое устройство.

Исхожу из стабильности такта на прием в 2*10^(-5).

Стабильность генератора, формирующего спектр на спутнике у вас 20ппм? Поставили из коробки что было? Или все таки у вас транскодер и 20 ппм это стабильность его генератора? Тогда причем здесь влияние этого генератора на тактовую, если транскодер не демодулирует сигнал?

в принципе, при такой разнице по такту ФАПЧ подавляет периодические скачки неплохо, но если отстройка по такту совсем маленькая, то периодические скачки clock-а ФАПЧ отслеживает->clock на выходе также колебания совершает).

Все эти системы, по факту переводят джиттер в вандер. Поэтому ничего удивительного.

[dsp_designer]

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

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

[des00]

ЗЫ. по поводу ФАПЧ, вы можете сделать частотно-фазовый детектор. Это даст вам широчайший диапазон захвата и узкую петлю удержания тактовой частоты.

[dsp_designer]

Да, насчет фазочастотного детектора мысль хорошая. Надо будет попробовать

[des00]

Можно и по выходу почистить)) Подумаю, что можно оптимизировать. Ну если вандер, то пусть вандером называется, я бы и его почистил еще)

вот это уже фантастика. http://en.wikipedia.org/wiki/Jitter прочитаете внимательно поймете почему

Насчет стабильности такта, ну это обычное значение (в максимуме), в принципе, на него и ориентируются. По крайней мере, знающий люди говорят на такую стабильность принимаемого такта рассчитывать из-за Доплера.

тогда это не стабильность, это расстройка. в общем понятно. частотно фазовый детектор ваш выбор.

[petrov]

позвольте вмешаться: есть модемы задача которых передача данных. есть модемы которые помимо передачи данных решают задачу передачи синхронизации. Например это модемы которые работают в режимах Sync-E (с различными видами синхронизации), модемы SDH, nЕ1, они же в том числе работают и в многопролетных вариантах, в спецприменениях. На качество восстановления синхронизации накладываются требования на остаточный джиттер, его маски, вандер и т.д.

Только тот ли это случай, в конце концов STM передают через ethernet, вот уж где джиттер, а тут всего лишь непрерывная передача и несинхронные опорные генераторы.

[Катран]

Если частота сильно не меняется, попробуйте DCXO. Узкополосность цифровой ФАПЧ ограничена лишь фантазией.
http://www.sitime.com/products/programmabl...rs-dcxo/sit3922
http://www.altera.com/literature/an/an_695.pdf

(low-bandwidth digital pll)

P.S. и немного по джиттеру http://www.sitime.com/support2/documents/A...measurement.pdf

Сообщение отредактировал Катран - Dec 2 2014, 23:11

[des00]

Только тот ли это случай, в конце концов STM передают через ethernet, вот уж где джиттер, а тут всего лишь непрерывная передача и несинхронные опорные генераторы.

Вполне может быть и тот. Например они работают через траснкодер и синхронизируют оборудование в разных частях земли по тональному сигналу Е1. Не всегда использование той же GPS синхронизации или любой другой, работающей по другому каналу, возможно. Есть куча оборудования которые требуют подобной синхронизации. Те же ОпСоСы очень полюбили Sync-E, когда намучались с базовыми станциями с GPS синхронизацией.

Если вопрос ТС касался только обработки сигнала в ПЛИС, то вы правы, сигнал валидности и правильные корки решат проблему. Но если ТС задал вопрос об обработке, подразумевая передачу данных и синхронизации стороннему оборудованию, то проблема имеет место быть.

ЗЫ. Передача TDM (Е1/SDH) трафика по асинхронным каналам действительно используется, но в этом случае гарантируется только передача данных, с синхронизацией пытаются решить проблему спец. сообщениями для подстройки часов, но.... тактовая там не та.

[dsp_designer]

Спасибо всем за советы, подумаю, что и как можно улучшить.

[TRILLER]

Для примера в KC705(и др.) применяют Si5324 jitter attenuator. Как раз для очистки восстановленного клока. Интегральная скорость на выходе у него такая же, как и у входного клока - я проверял, а вот качество на выходе лучше. А для компенсации дифференциальной разницы в скорости относительно входного можно по входу поставить FIFO большого объёма, например на DDR. Забиваете его до половины, а потом врубаете обработку в реалтайме на восстановленном клоке - и горя не знаете.. Как вариант)

[des00]

можно по входу поставить FIFO большого объёма, например на DDR. Забиваете его до половины, а потом врубаете обработку в реалтайме на восстановленном клоке - и горя не знаете.. Как вариант)

Угу, а потом измерите пинг тайм и всплакнете. Радости только что фильм с торента будет быстро тянуться

[TRILLER]

Угу, а потом измерите пинг тайм и всплакнете. Радости только что фильм с торента будет быстро тянуться

Это да. Но только если пинг тайм имеет значение.

[Hose]

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