[Grizzly 0]

Начал писать свой демодулятор для LTE-подобной системы и столкнулся с проблемой, касающейся оценки частотного смещения на целое число поднесущих. Получается змея, кусающая себя за хвост. Оценка IFO производится в частотной области по корреляции пилот-сигнала с опорным. Положение максимума будет соответствовать величине IFO. Только вот для растета такой корреляции нужно иметь точную синхронизацию по времени, иначе оценка IFO у меня получалась неверной на несколько бинов. Изначально я синхронизировался по времени по корреляции пилота с опорным, находил границу фрейма, затем считал корреляции ЦП во фрейме, усреднял их, находил дробную CFO, компенсировал, а после в частотной области делал оценку IFO. Однако при расстройке на несколько поднесущих у меня максимум корреляции пилота смещался где-то на 10 отсчетов во временной области. Символьная синхронизация может быть сделана и по корреляции циклических префиксов, которая не чувствительна к отстройке на целое число поднесущих, но там ведь априори точность не очень. В моем моделировании пока что получается необходимость синхронизации отсчет в отсчет по времени, чтобы в частотной области получить корректный результат. На рисунке 2 в PDF из вложения видна зависимость модуля корреляции от рассогласования по времени.

A Low-Complexity Integer Frequency Offset Estimation Scheme Using Combined Training Symbols for OFDM Systems.pdf

В публикациях всё просто. В зависимости от объекта исследования всё остальное считается идельаным. А как на практике поступают? Изначально по префиксам синхронизроваться?

[FatRobot 0]

Начальная оценка фазы символов и смещения частоты делается по PSS. Дальше петли по пилотам, работающие совместно. Оценки фазы символов и смещения частоты, сделанные по CP, можно накапливать для контроля работы основных петель.

[Grizzly 0]

9 минут назад, FatRobot сказал:

можно накапливать

Проблема заключается в том, что это какая-то собственная система, подобная LTE. У меня приходит всего один слот в несколько секунд. Потерять его нельзя. Его надо обнаружить при достаточно большой относительной неопределенности по времени, засинхронизироваться и демодулировать.

Думаю, надо сделать буфер несколько больше размеров слота и всё-таки идти по потоку корреляцией с пилотом Задова-Чу. Энергетический метод с двойным окном, я так думаю, будет часто цепляться за Wi-Fi. В итоге из-за частотной расстройким максимум корреляции окажется сдвинут от истинного положения отсчётов на десять, но слот будет обнаружен. Дальше пробегусь в буфере корреляциями с ЦП, компенсирую  дробную часть CFO. Дальше уже в частотной области будут снова находить корреляции Задова-Чу. Ошибка во времени даст набег фазы на поднесущих. Попробую сделать дифференциальную корреляцию, то есть и для принятого сигнала, и для пилота коррелировать выражения типа Sd(k) = S(k)S*(k-1). Во вложении формула (19). Так можно избавиться от фазового набега. А по (20) уже точно подстроюсь по времени, чтобы верно определить границы для FFT при демодуляции.

kyungsoowoo2007.pdf

Интересно, банк согласованных фильтров Задова-Чу, каждый из которых будет со своим значение IFO, не окажется эффективнее? Хотя без компенсации дробной части CFO, наверное, результаты будут очень плохие.

[Grizzly 0]

О, свеженькое нашлось, даже из Open Access. Как раз про формулу (7) с дифференциальной корреляцией пишут, что применяется в том числе при ошибках, связанных с оценкой STO.

08653297.pdf

Тут, насколько я понимаю, все равно лучше по ЦП подстроиться по времени перед вычислением корреляций в частотной области. При отрицательных IFO пик корреляции пилота во временной области сместится в сторону соседнего символа, с межсимволкой уже фиг что сделаешь в частотной области.

[FatRobot 0]

Рекомендую вам сделать двумерный (по delta_f и delta_t) поиск по пилотам. В частотной области.

Для пакетной передачи что-то делать по CP - плохая затея: СP короткий весьма, за 1 слот вы много не накопите.

[Grizzly 0]

1 минуту назад, FatRobot сказал:

Рекомендую вам сделать двумерный (по delta_f и delta_t) поиск по пилотам. В частотной области.

Спасибо. Буду пробовать.

2 минуты назад, FatRobot сказал:

Для пакетной передачи что-то делать по CP - плохая затея

Поэтому я предпочел использовать пилот вместо них, но вскоре влетел в IFO :)

[Grizzly 0]

@FatRobot только получится довольно много частотных позиций. Ведь нужно будет не 15 кГц делать шаг, а на мелкую сетку разбить, поскольку дробная часть не будет скомпенсирована.

Допустим, грубо я засинхронизируюсь во временной области. Относительно этого положения возьму +/-15 отчётов. Итого 31. По частоте +/-60 кГц в моих реалиях. Наверное, 500 Гц шаг брать, не больше. 241 позиция. Итого почти 7500. Хотя в сравнении с числом корреляций для грубого поиска фрейма это фигня ;) Их там миллионы будут при таком редком появлении фрейма. Так что в принципе можно и меньше делать шаг по частоте. Все познается в сравнении.

[FatRobot 0]

Вы возьмите окно БПФ/ОБПФ побольше. Например 4 х {длительность символа}, и временная позиция у вас автоматом получится, 

И отдельного грубого поиска не надо с "миллионами корреляций"

[Grizzly 0]

15 минут назад, FatRobot сказал:

И отдельного грубого поиска не надо с "миллионами корреляций"

В том-то всё и дело, что система поганая сама по себе :( Раз в 4 секунды приходит слот из 7 символов OFDM. Четвертый, как в uplink LTE, пилот. Только тут все равно OFDM, а не SC-FDMA. Первый раз я ведь должен найти этот слот по времени, дальше уже можно только подстраиваться каждые 4 секунды, зная его ожидаемое место.

Можно, конечно, энергетический детектор использовать для первого обнаружения, но как писал выше, боюсь, что WiFi может очень портить поиск. Зато в этом случае скользящим окном довольно просто считается, не надо коррелировать символы с 1024 отсчётами. На три порядка выигрыш.

 

[FatRobot 0]

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

Разберетесь в итоге, я надеюсь.

 

[Grizzly 0]

11 часов назад, FatRobot сказал:

Разберетесь в итоге, я надеюсь.

Уже нашел один косяк :) Я считал корреляции в частотной области неверно. Брал в качестве длины не размерность Nfft, а длину Задова-Чу, которая занимает только поднесущие, выделенные для передачи информации (это чуть больше половины по центру). Из-за IFO бины циклически сдвигаются, и я терял информацию в итоге.

Так стыдно теперь

[Grizzly 0]

В 13.06.2019 в 00:32, FatRobot сказал:

Разберетесь в итоге, я надеюсь.

Спасибо огромное за помощь! Сделал модель в Matlab и переписал на C++ для реального применения.

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

Единственное, что смущает, где-то на 1-2 отсчёта может быть ошибка при синхронизации с началом фрейма. Я после компенсации IFO делаю точную подстройку, считая еще раз корреляции, но вот отсчёт в отсчёт попасть не всегда получается. До точной синхронизации ошибка модет быть 10-15 отсчетов при частотной отсройке на 10 поднесущих.

Разумно ли в городских каналах с многолучевостью при определении границ окна FFT заведомо смещаться, скажем, на 2-3 отсчёта влево, чтобы уменьшить вероятность появления МСИ? В какой-то работе видел, что вообще советуют становится в середину ЦП.

[Grizzly 0]

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

[FatRobot 0]

Предположу, что вы действуете как-то так:

- взяли вектор отсчетов

- Для него получили PDP и оценку шума.

- Получили Mean Delay.

- Если abs(mean_delay) > n отсчетов, то вы промахнулись с окном, и вам нужно скорректировать начало вектора отсчетов и повторить последовательность шагов, а не просто доворачивать отсчеты после бпф. в противном случае отношение сигнал-шум у вас упадет

[Grizzly 0]

1 час назад, FatRobot сказал:

повторить последоватльность шагов

Черт, ведь надо было делать итерационно, а не однократную повторную более точную оценку. У меня оценка сигнал/шум выполняется после выравнивания канала по пилот-сигналу в частотной области. Так что в нее входят ошибки синхронизации. Я как раз по этой величине оценивал, что при ручной коррекции на несколько отсчетов SNR увеличивается. Такой критерий понятен. А через n вы обозначали какой-то порог или всю длину ЦП?