FatRobot

нет никаких скачков. всё плавно

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

а вам уже известен метод разбиения? например, если нам нужно передать по радиоканалу сигнал с ацп, то мы будем передавать старшие биты в более надежном канале, а младшие в менее надежном. у вас что -то похожее?

на уровне битов - такого нет. есть modulation-coding scheme (mcs) для пакета данных или группы частотных каналов либо вам нужен кодер источника, который бы 'выравнивал' влияние разных битовых позиций

для объяснений вам нужен школьный курс тригонометрии. раздел тригонометрические тождества.

ограничиваете полосу гетеродином 1.5к поднимаете область отрицательных частот в 0, фильтруете квадратуры поднимаете еще на 1.5к берете действительную часть

Mobile Radio Channels, Second Edition Author(s): Matthias Pätzold

https://www.spirent.com/products/gss9000

Привет, я один из тысяч индусов. В идеале для разработки сложных систем реального времени вам нужно 2 симулятора. Применительно к системам, близким к циклостационарным, например к системам связи, это link level simulator - здесь вы отлаживаете алгоритмы. по сути это не привязанная ко времени модель обработки, реализованная на с++ или матлаб. также lls является генератором тестовых векторов для rtl system level simulator - здесь вы проектируете и отлаживаете архитектуру системы, взаимодействие узлов, временные ограничения, коэф. использования, получаете первичные оценки площади и энергопотребления. в качестве sls порекомендую

Рекламирую сам себя:

На здоровье, конечно. Вы хотите на каждой итерации обращать матрицу в этом решении?

Кажется, вы сами выкладывали статью с оценками влияния различных смещений на SNR для OFDM. n выберете так, чтоб SNR слишком уж не падало Ну и работать с "живыми" записями - не очень хорошая затея. В матлабе же есть LTE Toolbox и модели каналов, рекомендованные 3gpp.

Предположу, что вы действуете как-то так: - взяли вектор отсчетов - Для него получили PDP и оценку шума. - Получили Mean Delay. - Если abs(mean_delay) > n отсчетов, то вы промахнулись с окном, и вам нужно скорректировать начало вектора отсчетов и повторить последовательность шагов, а не просто доворачивать отсчеты после бпф. в противном случае отношение сигнал-шум у вас упадет

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

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

Рекомендую вам сделать двумерный (по delta_f и delta_t) поиск по пилотам. В частотной области. Для пакетной передачи что-то делать по CP - плохая затея: СP короткий весьма, за 1 слот вы много не накопите.

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

так поставьте генератор, если изначально его 'нету'. насчет больших мегагерцев я тоже не вполне понимаю. несущая 200 кгц плюс 200 кгц х 100 для счета

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

Генератор -> Квадратурный модулятор (смеситель) -> ограничитель -> фазовый детектор

тогда для компактного и/или бытового угломера изоляция в 20дб между каналами - это уже большие усилия.

у вас азимут постоянный?

На здоровье. Вам останется решить вопрос с временнОй базой. Иначе вы столкнетесь со сложностями, например, с DTX/DRX.

Тогда так: вам в любом случае нужно оценивать pdp канала, чтобы определить границы окна БПФ. считайте, что sto так или иначе войдет в оценку PDP. А временную базу вы уж как-нибудь перепривяжете. Но обычно для sto используют отсчеты cfo, подавая их на более узкую, чем у cfo, петлю. а затем интерполятор в dfe или что-то в таком духе.

если вы привязываетесь к пику cir, то да, он будет смещаться во времени вы можете компенсировать временной сдвиг и сдвиг фазы при оценке вариации канала, но зачем?