soldat_shveyk

Так такой сигнал пропускается через фильтр ) Если иметь ввиду PPS 1Hz и отклонения частоты на один-два порядка меньшие, фильтр там будет очень узкополосный. Джиттер фронтов можно рассматривать как предельное ограничение аддитивного шума, который отлично отфильтровывается )

Вот здесь спросите - http://www.radioscanner.ru/forum/topic36750-227.html Если есть запись сигнала, то опознают быстро )

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

Вот мне тоже так казалось. Но что-то не получается нормальный результат. Делать делать дополнительный прекодер на передатчике - это уже явный перебор ) Отбеливающий-согласованный. Я так понимаю, что это: согласованный с каналом фильтр, сэмплер делающий из SPS отсчетов 1 символ, и загадочный отбеливающий фильтр. В общем, запутался окончательно ) Возможно, начать с DFE - хорошая идея. В чем плюсы: исправленный сигнал можно декодить неискаженным алфавитом без потери кодового расстояния. И как посчитать SNR результата мне тоже понятно.

Да. Получив h канала я сворачиваю ее со всеми последовательностями алфавита. В результате последовательности удлиняются.

Если я правильно понимаю, АЧХ отбеливающего фильтра должна быть обратна АЧХ канала? Вот с этим фильтром сейчас непонятнее всего. Пропустив через канал известную тестовую последовательность я получаю кросс-корреляцию которая представляет собой свертку автокорреляции последовательности и импульсной характеристики канала. Ryx = conv(Rxx,h) Отсюда я могу получить h канала. Вот как из нее сделать фильтр с обратной АЧХ, и при этом устойчивый? Читаю книгу Прокиса - не доходит ( Отбеливающий фильтр ведь не представляет собой полностью обратную импульсную характеристику канала, а только какую-то ее часть (мин.фазовую) которая отвечает за компенсацию АЧХ? После отбеливающего фильтра вроде бы все понятно - как использовать трелис для известного канала и BPSK я вроде разобрался. Это справедливый упрек, но у всех свои недостатки. Мне надо сразу что-то делать руками, я не очень люблю долго разбираться в теории. Вы имеете ввиду MMS-модуляцию? У меня действительно низкая плотность бит/Гц.

А brute-force MMSE ведь может заменить Витерби? Я так понимаю, что Витреби эквалайзер выгоден когда длина памяти канала M намного меньше вариантов передаваемых последовательностей N? В GSM (самом частом примере использования Витерби) перебирать все варианты последовательностей нереально, а память канала довольно короткая. Допустим, есть ресурс на перебор всех N последовательностей. Тогда можно не тратить время на Learning to love the Trellis?

Так получается, что принятый сигнал надо пропустить через фильтр обратный rrc-фильтру. Rx signal = tx_symbs * hrrc * h_channel (* - свертка) Импульсная характеристика rrc-фильтра передатчика нам известна. Попробовал поделить принятый сигнал на fft(h_rrc), чтобы сделать deconvolution - ничего не вышло ) Спектр rrc-харатктеристики имеет нули и после ifft(1/fft(hrrc)) получается черти что. Или все-таки надо во временной форме умножать сигнал на обратную импульсную характеристику rrc?

Спасибо, огромное! Уже скачал, изучу )

Получится, никуда не денется. Пакет набор - набор символов блочного кода. Но можно ведь и по символам работать? Symbol-by-symbol. Тогда получается как декодирование сверточного кода. Отбеливающий фильтр (witening filter) длиной равной памяти канала? Похоже да, что-то у меня все неправильно сделано. petrov, спасибо огромное! Хоть и говорите загадками :) Но Ваши советы как всегда ценны.

Petrov, спасибо. Значит нет смысла городить огород с DFE, а стоит добивать эквалайзер Витерби. Канал - это сверточный кодер передаваемого сигнала с h. Я могу оценить h по известной последовательности. Дальше вроде бы все логично: свернули с h c матрицей всех вариантов пакетов сигнала и посчитали метрики с принятым пакетом. Вот что здесь не так? Надо ли делать какое-то преобразование принятого пакета у учетом памяти канала перед тем как считать метрики с алфавитом декодера?

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

Доброго дня! Есть декодер максимального правдоподобия для небольшого блочного кода. Перемножаю принятый пакет на весь алфавит декодера, смотрю какая последовательность ближе - принимаю решение. MLE в общем. В канале есть многолучевость, поэтому по известной последовательности оцениваю h канала. И использую эту h для свертки со всем алфавитом декодера, чтобы определить какая из последовательностей ближе к принятой, которая тоже искажена этой h. Вроде бы все работает. Но смущает одна вещь: когда я сворачиваю комплексную h канала (а там сильная многолучевость) с алфавитом декодера, хэммингово расстояние между последовательностями алфавита декодера уже не то. Если оригинальные последовательности довольно сильно отличаются друг от друга, то последовательности "смазанные" h канала становятся более похожими друг на друга. И периодически из-за этого декодер принимает неверное решение, даже при приличном SNR. Возникла дилемма: с одной стороны сворачивание h канала с последовательностями декодера дает малую задержку приема, так как приемного фильтра нет вовсе, но при этом декодер не так хорошо отличает последовательности и может ошибаться. С другой стороны чтобы сохранить заложенное хэммингово расстояние между последовательностями декодера и хорошо их различать, надо исправлять исправлять многолучевость полноценным эквалайзером с DFE и инициацией по известной последовательности. Что выгоднее с точки зрения максимально достоверного приема? Задержкой можно немного поступиться. Или может я эквалайзер Витерби как-то неправильно реализую?

Имеется ввиду fft(abs(fft(x)))? Таким образом можно половинку автокорреляции посчитать, чтоб заполнить матрицу Rxx. Но petrov же правильно заметил, что невозможно оценить ИХ канала, если спектр зондирующего сигнала не соответствует fft(ИХ канала).

Убрал сглаживание RRC-фильтром для QPSK, чтоб спектр не был нулевым во всем отрезке Найквиста, теперь импульсную характеристику канала восстанавливает точно: petrov, спасибо!

Ага. То есть если используется QPSK сигнал, сглаженный RRC фильтром и ограниченный по полосе, то можно оценить АЧХ канала только в полосе этого сигнала? А я задал такую импульсную импульсную характеристику искажения, что ее полоса гораздо шире зондирующего сигнала. Поэтому оценка дает сильно сглаженный результат :)

Так частотная область используется только для расчета кросс-корреляции и автокорреляции, и получается все норм:

Доброго дня! Попробовал вычислить импульсную характеристику канала через известное соотношение Винера-Хопфа H = Rxx-^1 * Ryx Беру произвольный QPSK сигнал, сворачиваю и известной характеристикой канала. Нахожу их взаимную корреляцию и автокорреляцию исходного сигнала. Умножаю обратную матрицу автокорреляции на вектор кросс-корреляции - должна получиться импульсная характеристика канала. Она вроде получается, но совсем не похожа на ту, которую я использовал для искажения канала :( В чем может быть дело? Обратная матрица автокорреляции находится, с этим все норм. wiener_filter_estimation.m

Вот конкретный пример: http://mwel.ru/products/relation/sistema-svyazi-universalnaya-trx8d1/ Может проще и дешевле купить, то, что уже производится?

Спасибо! Отличный пример. И хороший повод поставить свежий Matlab :) Поигрался с этой моделью DFE RLS, вроде работает даже при низких SNR около 3 дБ. Попробую разобраться с этой технологией.

Да, немного про другое. Возможно ли как-то подстраивать коэффициенты эквалайзера делая несколько попыток декодирования и ориентируясь на SNR после декодера? У меня короткий блочный код, который я декодирую через максимальное правдоподобие. Сейчас у меня перед декодером стоит фильтр с обратной импульсной характеристикой канала. Не самый лучший способ. Есть куда улучшать :)

Доброго дня! Подниму старую тему по многолучевке. Так и не довел до конца в прошлом году, теперь уже точно надо добить :) В общем, идея следующая: по известной последовательности получаю импульсную характеристику канала, но чтобы не размножать шумы не делаю умножение сигнала на инверсную имп. характеристику. У меня сейчас довольно короткий блочный код, который я просто перебираю в MLE декодере. Соответственно, оценив h канала, я могу пропускать через нее все возможные варианты кода и сравнивать с принятым из канала пакетом. У кого меньше метрика - значит тот и передавался. Импульсная характеристика канала, которую я получил по известной последовательности, начинает устаревать, пока передаются данные а не training. Надо бы ее корректировать по результатам декодирования пакетов. Если у меня есть избыток вычислительной мощности, то я могу декодировать пакет не один раз, подстраивая коэффициенты ИХ канала, чтобы SNR улучшалось. То есть фактически делать эквалайзер. Получается не то что бы классическое решение. Вот не понятно: как подстраивать коэффициенты ИХ канала при каждой итерации декодирования? Допустим, мне не лень хоть 10 раз декодировать. Может я и велосипед изобретаю, но пробежался по выше перечисленным книгам по эквалайзированию, там ничего похожего не нашел.

LFCR удобен тем, что можно не хранить последовательность, а генерить по известному закону. Если есть возможность хранить последовательность, то можно найти подходящую по АКФ последовательность случайных бит перебором или поиском. Просто генерим случайные последовательности через randi() в матлабе, вычисляем АКФ и выбираем лучшую.

По вышеприведенной инструкции сделал mentor_example.do, в котором перечислил файлы тестового проекта: vlog -vlog01compat -work work ../test_cnt.v vlog -vlog01compat -work work ../test_cnt_tb.v vlog -vlog01compat -work work ../multer/synth/multer.v Запустил do mentor_example.do - и все заработало, ModelSim просимулировал проект. Я правда так и не понял - какая это был симуляция: RTL или gate-level :) Разберусь завтра. Но это капец, товарищи! Как-то компилил. Сделал пустой проект с 8-битным счетчиком без IP ядер, проект компилился.

Добавил в тестовый проект IP-ядро умножителя. В настройках Квартуса Tools->Options->IP Settings включил "Always regenerate design files for IP cores" и "Generate IP simulation model when genetating IP" (были отключены). В Assignments->Settings->EDA Tool Settings включил "Run EDA Netlist Writer during compilation (require Design entry/synthesis, Simulation, etc.)" (была отключена). После этого сработала генерация скрипта Tools-> Generate Simulation setup script for IP и в папке проекта появился файл mentor/msim_setup.tcl Получается, чтобы что-то просимулировать, надо IP-ядро добавлять?