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

Порядка 10 Мбит/с у меня получалось на персоналке для TPC 3/4 при 5-ти итерациях, применял Чейза.

То что вы спрашивали помню, а вот то что отсылал нет

Не совсем понимаю в чем проблема, там же 4 декодера работают параллельно. Обрабатывается сразу по 4 строки и 4 столбца, при этом как я понимаю работают не побитно, а пословно. Пока совершенно не ориентируюсь в 2D TPC кодах, но если скорость кодирования высокая, то думаю что это может очень быстро работать.

судя по доке на 150МГц они дают 45 мегабит на декодер, итого 3 такта на бит. 4 декодера с запасом.

спасибо...
не отсылали, я Вам тогда не ответил, решил сам покопать...

Глупый вопрос. Почему в RSС кодах не учитывается extrinsic информация о проверочных битах. Понятно что между декодерами передавать LLR проверочных битов не имеет смысла, но в пределах одного декодера между итерациями почему не воспользоваться выходными LLR метриками проверочных бит. В качестве примера вот код из CML

видно что в качестве inz1/inz2 всегда используются канальные LLR, хотя outz1/outz2 - метрики с учетом влияния решетки.
или код с http://the-art-of-ecc.com/8_Iterative/index.html

также parity1/parity2 используются всегда как есть

Апостериорные вероятности проверочных бит не добавляют полезной информации. Вся инфа, выцепленная из структуры кода, уже учтена в экстринсиках систематических бит. Они определяют вероятности состояний решетки и, соответственно переходов по ней, из которых рассчитываются апостериорные вероятности того или иного проверочного бита.

Понял, как самому в голову не пришло Тогда вопросы - следствие:
1. Тогда зачем в некоторых примерах рассчитывают LLR проверочных бит и принимают решение о проверочных битах? Только ради того что бы посчитать BER методом обратного кодирования?
2. В таком случае можно же сократить количество вычислений при итерациях, вычислив gammaE[0][input][k][s]=exp(0.5*Lc*parity1[k]*xk); один раз при первом проходе?

Не знаю.



Давай рассмотрим BCJR без логарифмов. В этом случае gamma - вероятность перехода из состояния s_in в состояние s_out решетки. Пусть переходу соответствует информационный бит in (их может быть не один) и проверочный бит , coded (их тоже может быть не один)

gamma(s_in, s_out) = P_appriory(in) * P_extrinsic(in) * P_appriory(coded).

P_appriory(in) * P_appriory(coded) можно посчитать заранее, это не меняется между итерациями. P_extrinsic(in) - меняется.

Подумал на счет пункта 1 - LLR проверочных бит могут потребоваться для итеративной демодуляции-выравнивания.

или для демодуляции и декодировании в многоуровневых сигнально-кодовых конструкциях.

Это и имел в виду, похоже что в сети полно декодеров, назову их "каноническими", которые показывают работу алгоритма и не заботятся о производительности. Все остальное "пилите шура, пилите" (с)


Вполне возможно, видел много статей про турбоэквалайзирование, но для моих скоростей оно пока не применимо.


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

я имею в виду схемы наподобии trellis-coded modulation на основе разбиения Ангербёка(Ungerboek), где для демодуляции бит следующего уровня нужны все данные с предыдущего.

Ну да, для BCM (BICM) мягкий выход проверочных бит нужен.

точно, спасибо, забыл как это называется.

Перевожу модель в фиксед поинт. Есть глупый вопрос: в документе ETSI TR 101 790 V1.4.1 указаны рекомендации

Насколько я понимаю речь идет о квантовании LLR метрик битов. Изучение других материалов показало, что 1 бит под дробную часть не эффективно, минимально рекомендуемое 2 бита. Делаю вывод, что в случае 4-х бит речь идет о формате представления чисел s2.2. Т.е. знаковое число, 2 бита под целую часть и 2 бита под дробную. В таком случае диапазон LLR метрик битов -4.00 ... +3.75 (вероятность нуля 0.98... вероятность единицы 0.97). Эти значения как раз совпадают со значением LLR битов нормированного QPSK созвездия -+1 -+1i, при попадании точно в точку. Тут все понятно. Нормируем созвездие на эквалайзере/ару, считаем евклидовы метрики, делаем ограничение на уровень -4...3.75.

Чуть ниже в этом же документе написано

И тут у меня взрывается мозг. Судя по доке, рекомендуемые уровни для кодирования [1/3 1/2 2/3 3/4 4/5 6/7] = [2.6 4.0 5.3 6.0 6.4 6.8]. Первый вопрос почему не нормируют созвездие, ведь ару это умножение на константу, сигнал умножается вместе с шумом? Второй вопрос, судя по всему предполагается квантование сигнала в формате s3.0, но в таком случае диапазон чисел -8...+7, т.е. при кодировании 6/7, они ставят созвездие почти в насыщение квантователя. В чем тайный смысл сего действа ?

Давай сначала - что такое канальные LLR (случай BPSK,AWGN)

LLR = log(p(x=1|r)/p(x = 0|r)) = log(exp(-(r-a)^2/sigma^2)/exp(-(r+a)^2/sigma^2)) =
=4*a/sigma^2*r;

r - сигнал на входе демаппера;
sigma^2 - дисперсия шума
a - точка, соответствующая чистому сигналу на входе приемника (фактически, это мат. ожидание абс. величины сигнала на выходе приемника).

АРУ на входе демаппера увеличит в К_agc раз sigma^2 и a, поэтому формула для LLR не изменится. Т.е. это математически это все равно - скалить сигнал на входе или созвездие в демаппере.



На счет 3.0 vs 2.1 - если рассмотреть алгоритм MAXLOG-MAP, то он не чувствителен к постоянному множителю в канальных LLR, т.е. суть вопроса от меня ускользает - можно отскалить вход как это будет удобно. Именно поэтому при реализации смело плюют на a/sigma^2 в знаменателе канальных LLR, если диспресия шума постоянна на кодовом блоке.

Давай теперь перейдем к квантованию. Сначала проще ограничение на входе рассмотреть. Мой опыт говорит, что ограничение на входе декодера полезно даже без квантования. Фактически оно приводит к тому, что в декодер попадает меньше шума, экстремальные всплески которого просто срезаются ограничителем. Я обычно выбираю уровень ограничения, равный a+(1.5...2)*sigma. a/sigma - худший рабочий SNR декодера. Авторы рекомендаций используют мало уровней квантования, так что им нужно сбалансировать шум квантования и шум от ограничения динамического диапазона входа ограничителем. Для больших скоростей они посчитали, что дисперсия шума на входе будет меньше (рабочая точка декодера смещается вправо по шкале SNR) и потому решили сузить динамический диапазон относительно +/- a и уменьшить шум квантования малых LLR. Видимо, провели моделирование какое-то, чтобы подтвердить результаты.