Всем здрасти!

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

Кто знает в чем может быть проблема?

Сообщение отредактировал Ivan55 - Apr 22 2014, 07:06

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

shiftTime - это оценка смещения пика корреляции префикса в отсчетах
DetectiontBuffer размером двух OFDM символов поиск корреляции осуществляется в первой половине буфера

ну так вот... когда не добавляю shiftTime при записи в буфер корреляция работает и производит оценку смещения времени, а
когда добавляю shiftTime при записи в буфер пик постоянно уплывает... По идее он же должен сдвинуться и в последующем оставаться на месте



Сообщение отредактировал Ivan55 - Apr 22 2014, 10:21

Так, как написано у вас, может быть и заработает. Проверьте знак обратной связи (знак перед shift_time). И сам расчет необходимого сдвига.
Еще мне не нравится то, что при изменении shift_time у вас произойдет повторение, или пропуск отсчетов.

Ну чет с изменением знака не помогло...

ну это же поиск индекса максимума корреляции защитного интервала(без shift_time то работает, а когда его добавляю уровень пиков падает) в соответствии с тем на сколько отсчетов сдвинут максимум пика на столько и сдвигаем входной буфер, или там не все так просто? много где пишут как считать сдвиг а как проводить синхру не пишут, останавливаются на том что типо вот "положение пика это смещение во временной области, а его фаза это смещение по частоте."

а как же без этого? если есть варианты скажите, мне было бы интересно промоделить

Сообщение отредактировал Ivan55 - Apr 25 2014, 17:45

Ivan55
Не совсем понятно как у Вас сделано.
IMHO, входные отсчёты во буфере сдвига (символьном) должны двигаться всегда на одинаковое количество отсчётов.
А вот копировать из буфера нужно в демодулятор с границы интервала интегрирования.
Может возникнуть проблема из-за разности тактовых генераторов передатчика и приёмника, когда пики начнут плавно двигаться (появляться раньше относительно предыдущего или позже), но это отдельная тема.
Выделения границ интервала ортогональности лучше определять по нескольким символам. В простейшем случае обыкновенным усреднением.
Автокорреляционная функция, естественно, комплексная. И по ней можно отследить рассинхронизацию по частоте. Но только в достаточно узком диапазоне. Для увеличения диапазона и более быстрой подстройки систем АПЧ и АПТЧ используйте или пилоты (символы или каналы), или итеративную обработку (если целостность сообщения контролируется CRC).
Всё вышеизложенное - это только самые-самые основы. Дальше будет гораздо интереснее.
Вообще, литературы по OFDM - море.
Удачи.

Есть подозрение, что вы что-то двигаете неправильно и у вас коррелированный отрезок выпадает из усреднения.
Когда я был совсем маленький, писал на эту тему статью в меру своего студенческого понимания. Может быть поможет http://dsol.ru/uploads/pdf/dspa_2.pdf. Знатокам просьба сильно не пинать.
Общее пожелание - считайте КФ потоком без разрывов на умножителе и скользящем усреднителе, а на выходе ищите пики. Если рассинхронизации по клоку нет, то пик будет всегда в окрестности нужной точки. Если клоки разные - пик будет плыть и за ним надо будет следить. Но пока сделайте поиск постоянного пика.

ну да чет я затупил...

Спасибо)