Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Фазовая синхронизация для QAM высокой полотности
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Математика и Физика
Artem_Petrik
Пытаюсь организовать фазовую синхронизацию(синхронизацию несущей) для QAM256. Много прочитал, пришел к выводу что здесь нет ничего сложного - вычислил разность углов на входе и выходе слайсера, отфильтровал, подал на вход синтезатора комплексной синусоиды, и вуаля. Разбирал выложенные здесь модели QAM16 приемников. Однако моделирование показало, что то, что прекрасно работает с QPSK и QAM16 ведет себя не очень хорошо для QAM256. В частности синхронизация происходит только при малых значениях частотной ошибки. Если QAM16 нормально себя чувствует при frequency offset в 1/50 символьной частоты, то для QAM256 допусимый offset составляет десятитысячные символьной скорости.
Собственно чем это объясняется - понятно. При больших M значительно выше вероятность того, что поворот фазы приведет к тому что точка на выходе слайсера не тудет иметь ничего общего с правильным символом, и, как следствие, вычисленная угловая ошибка будет неправильной. Вопрос в том, в каком направлении копать. Варианты с тренировочными сигналами (типа сначала QPSK, а после установления синхронизации переход на QAM256) весьма не желательны. Кроме того, точно знаю, что есть микросхемы, в частности для цифрового телевидения, которые нормально синхронизируются без преамбул.
Мне тут приходят мысли насчет того, чтобы при вычислении фазовой ошибки учитывать только 4 или 16 точек, наиболее близко расположенных к нолю, но нутром чую, что это все фигня и по науке надо делать совсем не так.
Я уже пересмотрел довольно много книг, но там максимум QAM16, высокоплотные QAM нашел только в случае телефонного модема, но там символьная скорость и частота несущей жестко завязаны, и проблема решается символьной синхронизацией
Поэтому решил обратится за помощью: пните в нужном направлении, посоветуйте что почитать.
alex_os
Цитата(Artem_Petrik @ Mar 20 2008, 16:54) *
Мне тут приходят мысли насчет того, чтобы при вычислении фазовой ошибки учитывать только 4 или 16 точек, наиболее близко расположенных к нолю, но нутром чую, что это все фигня и по науке надо делать совсем не так.

А созвездие у Вас квадратное? Если да, то можно попробовать оценку фазовой ошибки для каждого принятого символа умножать на весовой множитель пропорциональный ( может быть и нелинейная зависимость) модулю принятого символа. Идея в том, чтобы символы расположенные ближе к углам созвездия имели наибольшее влияние на работу системы. Идея эта из какой-то древней статьи (давно утраченной ), но вроде работала. Только Ару хорошее нужно. Еще вот статейка про слепой корректор,там еще система восстановления несущей прикручена :
Нажмите для просмотра прикрепленного файла
Еще если созвездие квадратное можно попробовать банальное возведение в 4ю степень, и вылезет несущая.
Цитата(Artem_Petrik @ Mar 20 2008, 16:54) *
Я уже пересмотрел довольно много книг, но там максимум QAM16, высокоплотные QAM нашел только в случае телефонного модема, но там символьная скорость и частота несущей жестко завязаны, и проблема решается символьной синхронизацией

Почему это несущая и символьная скорости в телефонном модеме жестко завязанны? в телефоном канале тоже может быть частотный сдвиг, кажется 7 Гц согласно стандарту. Еще телефонных модемах есть приамбула и это главное smile.gif.
Artem_Petrik
Цитата
А созвездие у Вас квадратное? Если да, то можно попробовать оценку фазовой ошибки для каждого принятого символа умножать на весовой множитель пропорциональный ( может быть и нелинейная зависимость) модулю принятого символа. Идея в том, чтобы символы расположенные ближе к углам созвездия имели наибольшее влияние на работу системы. Идея эта из какой-то древней статьи (давно утраченной ), но вроде работала. Только Ару хорошее нужно. Еще вот статейка про слепой корректор,там еще система восстановления несущей прикручена :
Нажмите для просмотра прикрепленного файла
Еще если созвездие квадратное можно попробовать банальное возведение в 4ю степень, и вылезет несущая.


Да, созвездие квадратное. Идею весовых коэффициентов в зависимости от амплитуды символа видел, но что-то у меня это особого выигрыша не дает. Правда зависимость я пробовал только одну, взятую с потолка. Вообще, насколько я понимаю суть проблемы этот подход кардинально ее не решит, так как он собственно уменьшает влияние аддитивного шума на погрешность измерения угловой ошибки, а у меня и без шумов нифига не работает sad.gif. Но за статью спасибо, с аддитивным шумом тоже придется бороться.
Возведение в четвертую степень есть готовым блоком в симулинке, но результат даже хуже чем в используемой мной модели.

Вдаташите на TDA8046 нашел, что у них там два детектора - фазовый и частотно-фазовый, и они сначала подстраиваются частотно-фазовым, а когда ошибка становится меньше порога - переключаются на просто фазовый. Вероятно и мне придется поступить подобным образом, но я пока не представляю что такое частотно-фазовый детектор smile.gif . Вобщем буду искать.

Цитата
Почему это несущая и символьная скорости в телефонном модеме жестко завязанны? в телефоном канале тоже может быть частотный сдвиг, кажется 7 Гц согласно стандарту. Еще телефонных модемах есть приамбула и это главное

Жестко завязаны потому что задаются одним и тем же кварцем, а промежуточных частот нет и в помине. и если разность тактовых приемника и передатчика равна скажем 50ppm, то и несущая и символьная скорость отличаются на те же 50ppm. Даже вроде фазы у них завязаны.
Впрочем прочитав ваш пост я вспомнил,что частотный сдвиг может произойти при прохождении телефонного сигнала по по линиям с частотным уплотнением каналов(аналоговым), такие до сих пор у нас уплотняют междугородные тракты. Однако в аппликейшенах TI и AD по построению модемов на базе их сигнальных процессоров почему-то о carrier phase syncronization нет ни слова. Хотя может это такая простая задача, что даже не стоит упоминания smile.gif.
alex_os
Цитата(Artem_Petrik @ Mar 21 2008, 21:24) *
Вообще, насколько я понимаю суть проблемы этот подход кардинально ее не решит, так как он собственно уменьшает влияние аддитивного шума на погрешность измерения угловой ошибки, а у меня и без шумов нифига не работает sad.gif.

Тут идея не столько в уменьшении влияния шума, сколько сделать датчик фазовой ошибки, который дает более или менее правдивые показания в большем диапазоне углов. Сейчас посмотрел, я не правильно написал в предидущем посте. Вычисляется модуль входного сигнала и в сигнальном созвездии ищется ближайшая точка из точек примерно с такимже модулем. Чем больше модуль тем больше вклад в выход ФД. Другими словами созвездие разбивается на концентрические субсозвездия и субсозвездие(в котором ищется ближайшая точка) выбирается из abs входного сигнала. Вот матлабовская модель, где два субсозвездия.
Код
N = 3000;
const256 = zeros(1, 256);
k = 1;
for i=1:16
    for j=1:16
        const256(k) = (i-8.5) + 1j*(j-8.5);
        k = 1+k;
    end
end

x = const256(1 + mod( fix(1000*rand(1, N) ), 256));
R = 8.9;
I = find( abs(const256) > R );

const256hi = const256(I);
const256lo = const256;
const256lo(I) = [];

noise = 0.1*(randn(1, N) + 1j*randn(1, N));
y = x+noise;
figure(2)
plot(const256hi, '+');
hold on;
plot(const256lo, 'o');
hold off;

L = 90;
phase_step = pi/2/L;
phase_estimated = zeros(1, L);
phase_estimated2 = zeros(1, L);
phase_et = zeros(1,L);
phase = -pi/4

for i=1:L
  phase = phase + phase_step;
  phase_et(i) = phase;
  z = exp(1j*phase) * y;
  tmp = 0;
  d = 0;
  for k=1:N
      [a, ind] = min( abs(z(k) - const256) );
      phase_estimated(i) = phase_estimated(i) + angle(z(k)*conj(const256(ind)));
      
      if abs( z(k) )>R
            [a, ind] = min( abs(z(k) - const256hi) );          
            d = 4*const256hi(ind);
      else
            [a, ind] = min( abs(z(k) - const256lo) );                    
            d = const256lo(ind);            
      end
      tmp = tmp + z(k)*conj(d)/abs(z(k));  
  end
      phase_estimated2(i) = angle(tmp);  
      phase_estimated(i) = phase_estimated(i)/N;  
end
figure(1);
plot(1:L, phase_estimated(1:L), 1:L, phase_et(1:L), 1:L, phase_estimated2(1:L) )
Artem_Petrik
Спасибо, буду разбраться. Ваш подход похоже должен решить проблему, правда вероятно реализация получится громоздкая. Насколько я понял из ваших слов здесь применяется слайсер, нарезающий не в декартовой системе координат, а в полярной( не на квадраты, а на кольца, и потом на сектора. Действительно, для оценки угла такой подход более оптимален. Предвижу сложности с символами примерно со средним модулем - там уж очень близко кольца друг к другу лежат - но думаю все равно эффективность будет значительно выше.
В вашей модели пока не разобрался, чето по субботам голова не воспринимает математику smile.gif но в понедельник, в рабочей обстановке, думаю все станет понятно.
Если вдруг вспомните какую-нибудь литературу, описывающую такой метод - дайте название, буду очень признателен.

Еще раз спасибо!
Artem_Petrik
Только сегодня добрался до матлаба, посмотрел модель, и понял, что мой предыдущий пост - полный бред(про слайсер в полярной системе). Разобрался, действиельно результат значительно лучше, чем в обычном детекторе. Буду заниматься моделированием в динамике.
Единственное что огорчает, это то, что я пока не представляю, как это реализовать на практике. Если во внешнем кольце оставить только четыре угловых точки, то реализовать не сложно, а вот если больше - проблема. Впрочем думаю это не самя большая проблема в моей жизни, что нибудь придумаю.
petrov
Здесь статьи по теме:

http://www.dspman.narod.ru/archive.html
Artem_Petrik
petrov: Большое спасибо! ссылки на некоторые из этих статей находил в инете, но не нашел, где их можно бесплатно скачать. Будет очень интересно почитать. Правда данная проблема на данный момент несколько отошла на задний план, ввиду возникновения других, более принципиальных сложностей.
_karabas_
Насчет фазовой синхронизации. Попытался разобраться с алгоритмами, в том числе, выложенными по ссылке выше, и обнаружил вот какой трабл. При синхронизации по диагональным точкам вроде бы все работает. Но иногда фазовая плоскость переворачивается на Пи/2. Т. е. иногда при настройке ошибок нет, а иногда символы принимаются с учетом разворота диаграммы амплитуд на 90 град. Ни в одном из алгоритмов о борьбе с такой трудностью ничего не вычитал. Стало быть возникает вопрос: это у меня в программе ошибка? Причем возникает именно при определенном значении первоначальной фазовой ошибки и возникает устойчиво. Меняем первоначальный фазовый сдвиг и все работает. Либо, с другой стороны, в алгоритме необходимо предпринимать какие-то синхронизирующие приемы. Кто что может сказать?
alex_os
Цитата(_karabas_ @ May 20 2008, 17:28) *
Насчет фазовой синхронизации. Попытался разобраться с алгоритмами, в том числе, выложенными по ссылке выше, и обнаружил вот какой трабл. При синхронизации по диагональным точкам вроде бы все работает. Но иногда фазовая плоскость переворачивается на Пи/2. Т. е. иногда при настройке ошибок нет, а иногда символы принимаются с учетом разворота диаграммы амплитуд на 90 град. Ни в одном из алгоритмов о борьбе с такой трудностью ничего не вычитал. Стало быть возникает вопрос: это у меня в программе ошибка? Причем возникает именно при определенном значении первоначальной фазовой ошибки и возникает устойчиво. Меняем первоначальный фазовый сдвиг и все работает. Либо, с другой стороны, в алгоритме необходимо предпринимать какие-то синхронизирующие приемы. Кто что может сказать?

обычно на уровне кодирования битиков принимаются меры что бы приемник работал инвариантно при повороте фазы на 90*n градусов. И вообще как можно распознать поворот созвездия на 90*n если оно симметрично относительно этого поворота? - только если есть каки-либо пилоты, либо по работе ПУ декодера ( работет-не работает)
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.