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

[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]

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