andyp

Стоит посмотреть на пик-фактор того, что будет излучаться.

Неинтересно, так как скремблирующий код никакого отношения к защите информации не имеет. Стоит сначала разобраться для чего он вообще в CDMA.

Ну или в лоб - 10 генераторов комплексной экспоненты, 10 смесителей и 10 децимирующих фильтров, все ветви работают параллельно. Это если совсем изучать ничего не хочется. Ага, тоже не ясно

Нормированная полоса RRC фильтра всегда больше или равна 1. Это означает, что без интерполяции на выходе фильтра возможен алиасинг (зависит от полосы сигнала на входе). Безотносительно специфического типа фильтра, всегда есть вопрос, как отфильтровывать имиджи в спектре аналогового выхода DAC. Все стараются оттащить имиджи подальше от полезного спектра и упростить аналоговую фильтрацию. Для этого увеличивают частоту дискретизации DAC.

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

Упрощает в двух моментах в основном: 1. Временное окно поиска сигналов абонента меньше. 2. Медленный Power Control - позволяет хоть как-то контролировать уровень помехи между абонентами. Ортогонализовать абонентов на базовой не дает многолучевый канал. С фазой и сдвигами несущей никакая замкнутая через базовую петля не справится из-за опять же многолучевого канала (у каждого луча свой допплеровский сдвиг) и возможной большой скорости движения терминалов (просто не успеет).

Если у вас, как и в IS95 есть пилот, то на мобиле сдвиги длинного кода, которые требуются, будут с шагом в период PN кода пилот-сигнала (2^15 чипов, ~27 ms для IS95). Для подкручивания можно использовать процедуру с известным шагом, предложенную мной выше, по модулю периода длинного кода (для 42 бит LFSR и чиповой скорости 1.2288 Mcps период равен 40 с хвостиком дней). Работу можно здорово сократить (до миллиона подкручиваний макс) имея таблицу из пары сотен состояний генератора длинного кода внутри периода. А так ничем помочь не могу. Не зря инженеры Квалкома выбрали передавать биты состояния на терминалы. Для скремблирования приватных каналов они просто используют тот же код, но с приватной маской.

На сколько помню, стандартным решением (например в is95) является является передача состояния генератора длинного кода на базовой станции по синхроканалу к мобилкам. [IEEE Transactions on Communications 1996-may vol. 44 iss. 5] Seok Chang Kim_ Byeong Gi Lee - A theory on sequence spaces and shift register generators (1996) [10.1109_26.494305] - libgen.li.pdf

Если величина n сдвига известна и относительно невелика - сотни тысячи, десятки тысяч..., то, на сколько помню, можно отделаться одним матричным умножением текущего состояния на матрицу размера LxL. Здесь L - длина сдвигового регистра. Матрицу можно посчитать заранее, для небольших n проблемы не составит - фактически, это возведенная в n-ую степень другая матрица Подробности например здесь S. C. Kim and B. G. Lee, A theory on sequence spaces and shift register generators, IEEE Transactions on Communications 1996-may vol. 44 iss. 5

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

В статье, что я привел, есть формула (7с). Подставляете параметры кода и получаете верхнюю границу недетектируемой ошибки при условии, что уже исправляете t ошибок Ну это собственно следует из того, что CRC - линейный код и будет работать в каких-то ограниченных сценариях. Только вот про коммутативность бы не забыть: CRC(a+b) = CRC(a) + CRC(b) = CRC(b + a)

С одновременным исправлением и детектированием дела обстоят так: Если добавили к информационному блоку d проверочных символов, а исправляете t ошибок, то детектироваться будут все ошибочные паттерны длиной d-t. И ещё много паттернов большей длины. Если исправляете d/2 паттернов (полная исправляющая способность кода) то уже начиная с длины d/2+1 будут детектироваться не все паттерны. Ну так и crc32 на блоках, скажем, в 400 байт будет детектировать не все ошибочные паттерны длины 4бита, что для многих является сюрпризом. Что касается сложности, то сложность расчета синдромов и так линейная от размера блока - нужно посчитать значение полинома для d элементов поля, что делается по схеме Горнера. Сложение в конечном поле - xor, умножение - по таблицам логарифмов и степеней.

CRC - обычный циклический код, предназначенный для детекции ошибок. Код Рида-Соломона сам по себе может детектировать еще очень много ошибочных паттернов, даже если его корректирующая способность используется на полную. В этих случаях декодер просто говорит, что не справился. Оценка способности кода Рида-Соломона одновременно с коррекцией детектировать ошибки (верхняя граница вероятности ошибочного детектирования) дана например здесь: 84F.PDF (nasa.gov) Вот и встает вопрос, зачем еще и CRC, если код Рида-Соломона сам по себе вполне себе с детекцией справляется.

Тоже не пойму, зачем CRC поверх RS. Штатные декодеры RS и так отлично детектируют ошибки. Для сжатого видео надо очень маленькие BLER иметь, так что лучше на какую-то составную схему смотреть - внешний кодек дочищает за внутренним. До появления турбокодов сверточный + RS были наилучшим вариантом. Жесткий вход внутреннего декодера конечно ухудшит ситуацию, но работать все равно будет неплохо. По крайней мере, гораздо лучше, чем просто RS с сопоставимой скоростью кодирования.

Разбить данные на несколько вертикальных полос. В каждой полосе строить гистограмму по значениям вертикальной координаты?

Если есть возможность передавать несколько ЛЧМ импульсов и сдвиг несущей невелик по отношению к 1/T, то сначала можно будет его оценить по разности фаз откликов СФ.

Понять, зачем нужен whitening matched filter можно по приложенной статье. Там все достаточно подробно разобрано. Первая ее часть, именно про фильтр, применима вне зависимости от того, будете ли вы использовать алгоритм Витерби или просто брютфорсить, сравнивая все последовательности. Там показано, что же является достаточной статистикой для оценки последовательности с межсимволкой. Также показано, что делать в случае нулей в ЧХ канала. [IEEE Transactions on Information Theory vol. 18 iss. 3] Forney, G., Jr. - Maximum-likelihood sequence estimation of digital sequences in the presence of intersymbol interference (1972) [10.1109_tit.1972.1054829] - libgen.li.pdf

А что тут комментировать? Попробуйте выписать формулу для веса однотапового эквалайзера, минимизирующего СКО, потом, с использованием этого веса для его выходного сигнала. Уже там будет видно, что оценка получается смещенной. Смещение обратно пропорционально ОСШ.

А она должна быть. На счёт 3 dB я конечно погорячился :) - это выигрыш от длинного фильтра по сравнению с коротким. Некогерентное накопление будет что-то давать в зависимости от входного ОСШ - на низких ОСШ мало, а на высоких ближе к когерентному.

Где длинный фильтр. Любой учебник по статистической радиотехнике, где упоминается согласованный фильтр, подойдёт. Можете и сами посчитать амплитуду сигнала и дисперсию шума на выходе устройства. Для простоты можно посмотреть на накопления в колодце, соответствующем нулевой частоте. Для других все будет аналогично.

Нет, не идентичны. Разница в ОСШ на выходе 3 dB.

С треугольной ИХ. Простейший случай - интерполяция в 2 раза. ИХ будет ( 0.5, 1, 0.5). Можно проверить для двух сдвигов разбавленной нулями последовательности.

Не побоюсь спросить, а каковы же Ваши ожидания от практической реализации генератора синуса? Какие компоненты спектра должны присутствовать на его выходе, а какие же тогда являются нежелательными? И с чем же сравнивать практическую реализацию, как не с теоретическими ожиданиями? Я видно совсем от жизни отстал. Теперь вот узнал, что у хорошего генератора синуса на выходе только одна палка в спектре должна быть.

Не очень понимаю, о чём разговор. Амплитудный спектр синуса - всегда две палки, симметричных относительно 0 . С учётом периодичности спектра дискретного сигнала, компонент окажется на частоте Fs-Fg. Fg - та частота, которую генерируете. Fs - частота дискретизации.

Ну конечно, это ж в общем случае работает. Я ж предупредил о marginal stability, больше не смею мешать.