Правильный LLR Опции

[GeGeL]

Запутался с вычислением LLR.
Демодулирую двухбитный символ: бит 0 кодирует сдвиг (форму), бит 1 - полярность символа. Коррелирую с двумя паттернами (по форме), получаю r0 и r1 (-1 ... +1). Как корректно вычислить LLR отдельно для битов 0 и 1 перед подачей на мягкий BCH?
Судя по коду eCall-модема, для бита 0 r0, r1 просто суммируются, а для бита 1 от r0, r1 вычисляется якобиан логарифм. Подскажите, пожалуйста, на сколько это корректно в описанном случае?

[serjj]

Вычисление LLR зависит от схемы модуляции + применяется или нет кодирование по Грею и т.д. Очень доступным мне показалось вот такое описание подхода к вычислению LLR на примере QAM16. Канал предполагается Гауссовым (т.е. все это будет хорошо работать при идеальном выравнивании). Основная идея, что каждая точка сигнального созвездия в приёмнике это Гауссовский процесс с средним соответствующим точке в передатчике (неискаженное значение), и дисперсией равной дисперсии шума. Далее для каждого бита рассчитывается условные вероятности P(y/0), P(y/1) как сумма вероятностей соответствующих им случайных процессов. LLR находится как log(P(y,1)/P(y,0)). При этом в рассчётах делаются всевозможные упрощения, которые связаны с используемым сигнальным созвездием: вместо y берем Re(y) или Im(y), в рассчете суммы случайных процессов обнуляем незначительные компоненты в зависимости от того в какой регион попадает Re(y) или Im(y). И в итоге получаем вместо "страшных" формул с экспонентами, логарифмами и дисперсией шума привычные простые формулы с суммами и проверками условий.

Сообщение отредактировал serjj - Apr 12 2015, 08:38

[andyp]

Запутался с вычислением LLR.
Демодулирую двухбитный символ: бит 0 кодирует сдвиг (форму), бит 1 - полярность символа. Коррелирую с двумя паттернами (по форме), получаю r0 и r1 (-1 ... +1). Как корректно вычислить LLR отдельно для битов 0 и 1 перед подачей на мягкий BCH?
Судя по коду eCall-модема, для бита 0 r0, r1 просто суммируются, а для бита 1 от r0, r1 вычисляется якобиан логарифм. Подскажите, пожалуйста, на сколько это корректно в описанном случае?

Глянул краем глаза в код eCall (http://www.etsi.org/deliver/etsi_ts/126200_126299/126268/12.00.00_60/ts_126268v120000p0.zip):

То, что там называется JacLog, является вычислением логарифма от суммы экспонент, известным как MAX*:

ln(exp(x) + exp(y)) = max(x,y) + ln(1+exp(-abs(x-y)))

Для второго слагаемого используется table lookup.

Для каждого из 3х бит, которые требуется демодулировать (функция SymbolDemod), считается логарифм от отношения двух сумм вероятностей. Первая сумма - сумма апостериорных вероятностей тех символов, где этот бит равен 1, вторая - сумма ап. вероятностей тех символов, где этот бит равен 0. Это из-за того, что вероятность передачи единицы равна сумме вероятностей передачи всех символов, у которых данный бит 1. Аналогично с 0.

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

ln(P1+P2 + P3) = ln(exp(ln(P1+P2)) +P3), что позволяет применять формулу для суммы экспонент рекурсивно.

Ну и да, аппостериорная вероятность символа в канале с AWGN равна K*exp(r/B) - здесь r - корреляция символа и принятой последовательности. K, B - некие константы, одинаковые для всех символов при фикс. уровне шума в канале. В коде 1/B связана с FEC_VAR, ln(K) связан с FEC_MEAN.

[GeGeL]

Спасибо за пояснения, то-то я все думал, откуда они взяли FEC_VAR и FEC_MEAN.
Вообще, код насыщен всякими эмпирическими штучками, без опыта в теме сложно понять их смысл. Да, и странно r считается: суммируются произведения выборок сигнала и паттерна, но знаменатель формулы Пирсона опущен: результат не делится на сумму квадратов выборок сигнала.
По идее, будет зависимость r от амплитуды. Учитывая, что кодек в канале асинхронный, наблюдаются медленные "биения" из-за разности частот сэимплирования, и быстрые из-за скачков ACELP кодовой книги в GSM EFR и процедуры GridSelection в в GSM HR (видно на осциллограмме).
Как оно у них работает без нормализации по амлитуде, не пойму.

[thermit]

Спасибо за пояснения, то-то я все думал, откуда они взяли FEC_VAR и FEC_MEAN.
Вообще, код насыщен всякими эмпирическими штучками, без опыта в теме сложно понять их смысл. Да, и странно r считается: суммируются произведения выборок сигнала и паттерна, но знаменатель формулы Пирсона опущен: результат не делится на сумму квадратов выборок сигнала.
По идее, будет зависимость r от амплитуды. Учитывая, что кодек в канале асинхронный, наблюдаются медленные "биения" из-за разности частот сэимплирования, и быстрые из-за скачков ACELP кодовой книги в GSM EFR и процедуры GridSelection в в GSM HR (видно на осциллограмме).
Как оно у них работает без нормализации по амлитуде, не пойму.

Там и не надо ничего делить. ln(exp(x)+exp(y)) ~ max(x,y). ну и грубо, в качестве софтбита выбирается разность максимального значения корреляций символов где бит 1 и максимального значения корреляций символов где бит 0. Или наоборот. Не помню... В нормировке нет необходимости.

[andyp]

Спасибо за пояснения, то-то я все думал, откуда они взяли FEC_VAR и FEC_MEAN.
Вообще, код насыщен всякими эмпирическими штучками, без опыта в теме сложно понять их смысл. Да, и странно r считается: суммируются произведения выборок сигнала и паттерна, но знаменатель формулы Пирсона опущен: результат не делится на сумму квадратов выборок сигнала.

Под r имел в виду ненормированную корреляцию, т.е. sum(r_i*s_i). Все остальное попадает в К и В (ну и соответственно в FEC_VAR, FEC_MEAN)

По идее, будет зависимость r от амплитуды. Учитывая, что кодек в канале асинхронный, наблюдаются медленные "биения" из-за разности частот сэимплирования, и быстрые из-за скачков ACELP кодовой книги в GSM EFR и процедуры GridSelection в в GSM HR (видно на осциллограмме).
Как оно у них работает без нормализации по амлитуде, не пойму.

Не знаток вокодеров, но, по коду видно, что на это забивают. Просто в эти моменты на вход декодера будут поступать не совсем "хорошие" LLR. Есть надежда, что декодер справится. Для него это равносильно добавочному шуму.

[GeGeL]

В нормировке нет необходимости.

Я имел в виду нормировку символов по амплитуде перед коррелятором. В предлагаемом варианте выход коррелятора (и, соответственно, LLR в виде разности выходов коррелятора) зависит не только от формы символа, но и от его энергии, что не кошерно.

Не знаток вокодеров, но, по коду видно, что на это забивают.

Тут даже не в свойствах вокодера проблема. Если выход модулятора пропустить через обычный полосовой фильтр, а затем сделать выборки с сэмплрейтом, немного отличающимся от модулятора, то получим "биения" по амплитуде с периодом в разницу сэмплрейтов. Даже ухом слышно, как сигнал "дышит" при прослушивании на РС. И если LLR на входе FEC будет пропорционально зависеть от амплитуды PCM (а, судя по коду, это так), то получится не хорошо. Я думал, что у них где-то по коду есть предпроцессинг PCM, отследил от main() до SymbolDemod() - таки нет. Наверное, предполагается АРУ в самом GSM модуле.

[andyp]

Тут даже не в свойствах вокодера проблема. Если выход модулятора пропустить через обычный полосовой фильтр, а затем сделать выборки с сэмплрейтом, немного отличающимся от модулятора, то получим "биения" по амплитуде с периодом в разницу сэмплрейтов. Даже ухом слышно, как сигнал "дышит" при прослушивании на РС. И если LLR на входе FEC будет пропорционально зависеть от амплитуды PCM (а, судя по коду, это так), то получится не хорошо. Я думал, что у них где-то по коду есть предпроцессинг PCM, отследил от main() до SymbolDemod() - таки нет. Наверное, предполагается АРУ в самом GSM модуле.

Видимо, предполагается, что данные получаются в цифре и поступают на вход вокодера в цифровом виде - gsm модуль с цифоровым аудио входом.

Сообщение отредактировал andyp - Apr 14 2015, 22:48