Доброго дня! Разбираюсь с данным девайсом. В качестве базы взял книгу Скляра,Цифровая связь. По алгоритму все понятно, но есть два вопроса: 1й-в примере для вычисления метрики ветвей используются (Xk и Yk) значения напряжений с демодулятора, на входе декодера я использую LLR форму с soft демодулятора, для BPSK переход понятен, а что делать с 4,16 и тд QAM? 2й- в примере Скляр для простоты квадрат дисперсии заменяет 1, на сколько в реальности такое упрощение ухудшит восстановление?

http://electronix.ru/forum/index.php?act=a...st&id=67150

Как получить из I и Q LLR-пока вроде ясно, неясно как из этого LLR получить числа для расчета метрик в ((Xk и Yk) 8.142 стр 527) Скляра.

Вам принципиально использовать map? Может достаточно будет взять аппроксимацию max-log-map, тогда все операции элементарно сведутся к сравнению и взятию знака этих самых LLR, на практике как правило чистый MAP никто не использует. Еще вариант - использовать SOVA, он проще для понимания, но и помехоустойчивость будет ниже.

Собственно я Log-MAP и использую (MAP из примера перевел в Log-MAP), но вычисление метрики ветви только перешло из произведения в сумму, но наличие xki*uki+yki*vki осталось, по отношению к BPSK мне понятен физический смысл этих переменных, а для M-QAM -нет!

Так разложив исходные I/Q квадратуры M-QAM сигнала, Вы по-сути и получаете BPSK последовательность, алгоритм декодирования остается прежним. другими словами, блок расщепления квадратур никакого отношения к декодеру не имеет, если не рассматривать вопросы вхождения в синхронизм, т.е. M-QAM сигнал к моменту расщепления/декодирования должен быть выровнен на начало фрейма и устранена фазовая неоднозначность.

Давайте я попробую поставить по другому вопрос: Допустим есть демодулятор с софт выходом (выход на бит есть логарифмичесое отношение правдоподобий в диапазоне от -N до +N), и есть вход турбо декодера, куда додается этот выход, но в самом демодуляторе для расчета метрики ветви необходимо (согласно примеру) величина не в LLR а в напряжении (от -U до +U), в этой же книжке легко найти перевод для BPSK (фактически он равен толи 0.5 толи 2 (книги нет под руками если взять квадрат сигмы за1). Теперь рассмотрим тот же демодулятор для 16QAM-на выходе имеем LLR метрику для каждых 4х бит в символе, заганяем их в декодер, как в декодере зная что на входе метрика от 16QAM получить эти биты в виде напряжений для расчета метрики ветви?

на выходе имеем 4-ре LLR метрики для каждого из 4-х бит созвездия. Не все биты QAM16 равновероятны. ну и т.д.

Сорри, не верно написал, Вы совершенно правы , 4ре метрики для 4х бит созвездия, но это не меняет сути вопроса. Как из LLR получить то что в BPSK в примере называется напряжением с демодулятора?

забудьте про всякого рода напряжения, их нет ни в демодуляторе, ни в декодере. с выхода демодулятора получаются квантованные I/Q составляющие, далее они поступают на расщепитель в случае M-QAM или сразу на декодер при использовании BPSK/QPSK модуляции, это и будут вашими искомыми LLR, с ними декодер и работает напрямую.

Т.е. если я правильно понял , для ЛЮБЫХ типов сигналов (BPSK,8PSK,M-QAM) выход LLR метрик и есть те переменные для расчета метрик ветви с коэффициентом 2/сигма2 согласно 8.141б и в (стр 526 Скляр)?

Да, это и будут ваши канальные LLR

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

необходимо строить для требуемого диапазона SNR, т.е. для нескольких значений сигма.

Большое спасибо за ответы!

Начал набрасывать блок схему для плисы, и в блоке расчета метрики ветви появился вопрос: в формуле подсчета метрики ветви есть множитель -априорная вероятность 0 или 1 , а у меня с выхода другого декодера есть отношение вероятности (логарифмы пока опускаю), как из того что есть получить то что надо для вычиления дельты?

Скажите, пожалуйста, Вы этим занимаетесь с целью получения навыков/знаний или чтобы сделать продукт? Если продукт, то не мучайтесь, возьмите готовый, у Xilinx точно есть (да, я знаю, что это за деньги, но если очень хочется.... ну Вы меня поняли).

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