Сделал F-LDPC кодек в матлабе (сорцы причешу и чуть позже выложу), вижу недобор чутья, возникло 2 вопроса :
1. Как могут терминироватся решетки в обоих кодерах? Ведь по идее лучше что бы решетка была циклической, но указаний на циркуляцию в доке я не нашел.
2. При вычислении экстринсиков в турбокодах, работающих с алгоритмом MAX LOG MAP вводят коэффициент пропорциональности меньше единицы (компенсация дельты в функции MAX* и "стабилизация" алгоритма). А как поступают в турбокодах, основанных на алгоритме min_sum (F-LDPC)?

Решетку зациркулировал, по логике здравого смысла. Чутье улучшилось. Но вопрос все же актуален.

В приложении F-LDPC кодек, в котором SPC декодер интегрирован в inner siso декодер, не дошел до мысли, как красиво его сделать отдельным.

Зы. Код специально написан примитивно и медленно, заточен к переносу на ПЛИС.

UPD. Немного мыслей по алгоритму сверточного декодирования из статьи. На уровне логики я понял почему они сделали все на min-sum функциях. Т.к. кодеры по сути работают как Parity Check. Но, вот смотрю как растут метрики и вижу странности. Например, рассмотрим уравнение MO[a(j)] = g(F(j), B(j+1) + MI[x(j)]. g - функция min-sum. Т.е. у нас может быть высокая надежность следующего состояния B(j+1), высокая корреляция с ним метрики выходного бита MI[x(j)], но низкая надежность текущего состояния F(j). И в итоге выходное сообщение будет с низкой надежностью. Тоже самое касается и уравнения B(j) =g(B(j+1)+MI[x(j)],MI[a(j)]). низкий MI[a(j)] перевешивает все.

До кучи нигде в коде не видно корреляции входных и выходных данных решетки (метрики перехода), тогда как в сверточниках это основной момент. ИМХО, мне кажется, что по этому, они не пишут про то, как декодируют FlexCode, там сверточники на 4 состояния, подобным образом не отскочишь. Надо попробовать сделать F-LDPC классически и сравнить.

Мельком посмотрел, исправляющая способность лучше, чем в моей реализации, буду внимательно изучать, но чуть позже.
По инициализации решетки и, может быть, разъяснению алгоритма прикрепляю статью - в ней рассматривается тот же алгоритм, но с другого ракурса (это уже было, но в виде презентации - тут подробней).

Сообщение отредактировал maratz - Jul 5 2016, 07:14

Гыыы. Расписал ручками решетку, а ведь они правы черт возьми. Итак решетка кода 1/(1+D)

Рассмотрим MAX LOG MAP с прямыми метриками. Метрики переходов gamma(state, input_bit) будут

оптимизируем

составляем уравнение расчета надежностей состояний при обратном проходе, с учетом решетки trel.preStates

Переходим от вероятностей каждого состояния (беззнаковой) к разностной вероятности (помним что одинаковое смещение не влияет на MAX LOG MAP)

оптимизируем B[k+1] = beta[k+1][1] - beta[k+1][0], gamma(0,0) = 0

снова переходим к разностной вероятности

Делаем подстановку остальных gamma и вуаля.


Ну а работать в прямых или инверсных метриках это уже пожеланию

Возник вот такой вопрос. В MAX LOG MAP алгоритме, с без знаковыми метриками, метрики состояний всегда растут в одну сторону. Нормировка метрик состояния в этом случае делается просто. А как быть в случае знаковой(разностной) метрики? Ведь тут вычитать или использовать модульную арифметику не получится. Ограничивать или использовать деление неправильно.

Как вариант вижу ограничение экстринсиков, что автоматически приведет в ограничению метрик состояния. Может есть другие варианты?

Расписал все уравнения. В статьях, выходные сообщения это именно extrinsic LLR. Никакой другой математики, по вычитанию метрик систематических бит не нужно.


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

Ну и до кучи, еще вытянуть немного чутья помогут следующие простые модификации
1. Небольшая утечка extrinsic LLR, коэффициента 0.75 достаточно.
2. Ограничение extrinsic LLR.
3. Аппроксимация min-sum* в виде g(x,y) = min(|x|, |y|)*sign(x)*sign(y) -0.25*sign(x)*sign(y).

В железе, все это реализуется с минимальным ресурсом.

Надо придумать как сделать N портовый collision free interleave и за недельку можно скидать декодер

Доброго всем.

Озадачился вопросом, есть ли возможность, априори оценить разность ЭВК для одного и того же кода, в зависимости от длинны блока? Понятно, что чем больше длинна блока тем лучше, сказывается эффект интегрирования шума. Но вот пример:
1. FLDPC. блоки 4/8/16к. длинна отличается в 2 раза. Разница по 1е-6 между 4к и 8к ~0.2дб для всех скоростей, между 8к и 16к ~0.1дб.
2. Duo Binary RSC. блоки 30/60/120/240/480 байт. Разница по 1е-6 между 30/60/120/240 ~0.5дб, а между 240 и 480 ~0.2дб.

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

Спасибо.

Судя по рисунку, 16к и 32к будут отличаться на 0.05 дБ. http://datumsystems.com/waterfall

По реализации. На входе стоит 1+D в мягкой форме, потом inner siso, потом outer siso, extrinsic LLR которого суммируется с начальными систематическими LLR(sLLR) и кодируется входным 1+D. Я убрал 1+D и sLLR подаю сразу на проверочный вход outer siso, а на информационный нули. Результат одинаковый, но времени уходит меньше.

Однако по исправляющей недобор. Хотел бы больше узнать об ограничении метрик состояний и extLLR. И что такое утечка extLLR?

Сообщение отредактировал maratz - Jul 16 2016, 11:53

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


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

в декодерах имеет смыл ограничить входные метрики и экстринсик метрики между итерациями на достаточно достоверном уровне, в противном случае возможно ухудшение сходимости декодера. Называется это scalling soft information - по сути утечка в терминах эквалайзирования/затухание фильтра. В приложенной статье, подбором коэффициента получают выигрыш до 0.6дб.

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



Сообщение отредактировал andyp - Jul 21 2016, 10:34

Есть ли у кого-нибудь материалы или сведения о влиянии длины окна при обратном проходе в SOVA на исправляющую способность?