реклама на сайте
подробности

 
 
16 страниц V  « < 14 15 16  
Reply to this topicStart new topic
> Вопросы по итеративному декодированию, Реализация CTC/BTC/LDPC кодов
des00
сообщение Jul 4 2016, 17:01
Сообщение #226


Вечный ламер
******

Группа: Модераторы
Сообщений: 7 222
Регистрация: 18-03-05
Из: Томск
Пользователь №: 3 453



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


--------------------
Go to the top of the page
 
+Quote Post
des00
сообщение Jul 5 2016, 03:53
Сообщение #227


Вечный ламер
******

Группа: Модераторы
Сообщений: 7 222
Регистрация: 18-03-05
Из: Томск
Пользователь №: 3 453



Цитата(des00 @ Jul 5 2016, 00:01) *
1. Как могут терминироватся решетки в обоих кодерах? Ведь по идее лучше что бы решетка была циклической, но указаний на циркуляцию в доке я не нашел.

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

В приложении 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 классически и сравнить.
Прикрепленные файлы
Прикрепленный файл  F_LDPC_mlab_05072016.7z ( 5.27 килобайт ) Кол-во скачиваний: 32
 


--------------------
Go to the top of the page
 
+Quote Post
maratz
сообщение Jul 5 2016, 07:13
Сообщение #228


Участник
*

Группа: Участник
Сообщений: 42
Регистрация: 4-02-16
Пользователь №: 90 332



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

Сообщение отредактировал maratz - Jul 5 2016, 07:14
Прикрепленные файлы
Прикрепленный файл  high_speed_decoding_for_scc.pdf ( 166.95 килобайт ) Кол-во скачиваний: 42
 
Go to the top of the page
 
+Quote Post
des00
сообщение Jul 5 2016, 12:25
Сообщение #229


Вечный ламер
******

Группа: Модераторы
Сообщений: 7 222
Регистрация: 18-03-05
Из: Томск
Пользователь №: 3 453



Цитата(des00 @ Jul 5 2016, 10:53) *
Надо попробовать сделать F-LDPC классически и сравнить.

Гыыы. Расписал ручками решетку, а ведь они правы черт возьми. Итак решетка кода 1/(1+D)
Код
    trel.nextStates = [[0 1][1 0]];
    trel.outputs    = [[0 1][1 0]];
    trel.preStates  = [[0 1][1 0]];

Рассмотрим MAX LOG MAP с прямыми метриками. Метрики переходов gamma(state, input_bit) будут
Код
            gamma(0, 0) = 0*ma(i) + trel.outputs[0][0]*mx(i);
            gamma(0, 1) = 1*ma(i) + trel.outputs[0][1]*mx(i);
            gamma(1, 0) = 0*ma(i) + trel.outputs[1][0]*mx(i);
            gamma(1, 1) = 1*ma(i) + trel.outputs[1][1]*mx(i);

оптимизируем
Код
            gamma(0, 0) = 0;//00
            gamma(0, 1) = ma(i) + mx(i);//11
            gamma(1, 0) = mx(i);//01
            gamma(1, 1) = ma(i);//10

составляем уравнение расчета надежностей состояний при обратном проходе, с учетом решетки trel.preStates
Код
        beta[k][0] = max(gamma(0, 0) + beta[k+1][0], gamma(0, 1) + beta[k+1][1]);
        beta[k][1] = max(gamma(1, 1) + beta[k+1][0], gamma(1, 0) + beta[k+1][1]);

Переходим от вероятностей каждого состояния (беззнаковой) к разностной вероятности (помним что одинаковое смещение не влияет на MAX LOG MAP)
Код
        beta[k][0] = max(gamma(0, 0), gamma(0, 1) + beta[k+1][1] - beta[k+1][0]);
        beta[k][1] = max(gamma(1, 1), gamma(1, 0) + beta[k+1][1] - beta[k+1][0]);

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

снова переходим к разностной вероятности
Код
        B[k] = max(gamma(1, 1), gamma(1, 0) + B[k+1]) - max(0, gamma(0, 1) + B[k+1]);

Делаем подстановку остальных gamma и вуаля.
Код
        B[k] = max(ma[i], mx[i] + B[k+1]) - max(0, ma[i] + mx[i] + B[k+1]);


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


--------------------
Go to the top of the page
 
+Quote Post
des00
сообщение Jul 5 2016, 17:07
Сообщение #230


Вечный ламер
******

Группа: Модераторы
Сообщений: 7 222
Регистрация: 18-03-05
Из: Томск
Пользователь №: 3 453



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

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




--------------------
Go to the top of the page
 
+Quote Post
des00
сообщение Jul 6 2016, 04:15
Сообщение #231


Вечный ламер
******

Группа: Модераторы
Сообщений: 7 222
Регистрация: 18-03-05
Из: Томск
Пользователь №: 3 453



Цитата(des00 @ Jul 5 2016, 19:25) *
Гыыы....

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

Цитата(des00 @ Jul 6 2016, 00:07) *
Может есть другие варианты?

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

Ну и до кучи, еще вытянуть немного чутья помогут следующие простые модификации
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 и за недельку можно скидать декодер sm.gif


--------------------
Go to the top of the page
 
+Quote Post
des00
сообщение Jul 7 2016, 05:13
Сообщение #232


Вечный ламер
******

Группа: Модераторы
Сообщений: 7 222
Регистрация: 18-03-05
Из: Томск
Пользователь №: 3 453



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

Озадачился вопросом, есть ли возможность, априори оценить разность ЭВК для одного и того же кода, в зависимости от длинны блока? Понятно, что чем больше длинна блока тем лучше, сказывается эффект интегрирования шума. Но вот пример:
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дб.

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

Спасибо.
Эскизы прикрепленных изображений
Прикрепленное изображение
Прикрепленное изображение
 


--------------------
Go to the top of the page
 
+Quote Post
maratz
сообщение Jul 15 2016, 14:46
Сообщение #233


Участник
*

Группа: Участник
Сообщений: 42
Регистрация: 4-02-16
Пользователь №: 90 332



Цитата(des00 @ Jul 7 2016, 09:13) *
Поведение разности похоже на какую-то экспоненциальную формулу. Как нибудь это можно рассчитать априори, без моделирования? Интересно же знать, начиная с какого размера пакета, увеличивать его не имеет практического смысла и лучше поискать другой код.

Судя по рисунку, 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
Эскизы прикрепленных изображений
Прикрепленное изображение
 
Go to the top of the page
 
+Quote Post
des00
сообщение Jul 16 2016, 13:12
Сообщение #234


Вечный ламер
******

Группа: Модераторы
Сообщений: 7 222
Регистрация: 18-03-05
Из: Томск
Пользователь №: 3 453



Цитата(maratz @ Jul 15 2016, 21:46) *
Судя по рисунку, 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?

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


--------------------
Go to the top of the page
 
+Quote Post
andyp
сообщение Jul 21 2016, 10:23
Сообщение #235


Местный
***

Группа: Участник
Сообщений: 411
Регистрация: 23-07-08
Пользователь №: 39 163



Цитата(des00 @ Jul 5 2016, 20:07) *
Возник вот такой вопрос. В MAX LOG MAP алгоритме, с без знаковыми метриками, метрики состояний всегда растут в одну сторону. Нормировка метрик состояния в этом случае делается просто. А как быть в случае знаковой(разностной) метрики? Ведь тут вычитать или использовать модульную арифметику не получится. Ограничивать или использовать деление неправильно.

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


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

Код
        for(state_type j = 0; j <= state_type(Trellis::num_trellis_states - 1); ++j)
        {
            std::pair<typename Trellis::Branch, typename Trellis::Branch> branches = _trellis.get_backward_branches(j);

            //max-log-MAP ядро
            state_type s0 = branches.first.state;
            LLRType gamma_s0 = branches.first.input? g1[s0] + apriories[i] : g0[s0];
            state_type s1 = branches.second.state;
            LLRType gamma_s1 = branches.second.input? g1[s1] + apriories[i] : g0[s1];
            LLRType next_alpha = std::max(a[s0] + gamma_s0, a[s1] + gamma_s1);

            //ограничиваем значение alpha снизу
            next_alpha = std::max(next_alpha,min_log_prob);
            a_next[j] = next_alpha;
            //максимальное значение alpha для состояний решетки в текущий момент времени
            max_a = std::max(max_a,next_alpha);
        }
        //нормализация
        if(max_a > max_log_prob)
        {
            for(state_type j = 0; j <= state_type(Trellis::num_trellis_states - 1); ++j)
                a_next[j] = std::max(LLRType(a_next[j] - max_log_prob), min_log_prob);
        }


Сообщение отредактировал andyp - Jul 21 2016, 10:34
Go to the top of the page
 
+Quote Post
maratz
сообщение Feb 9 2017, 15:02
Сообщение #236


Участник
*

Группа: Участник
Сообщений: 42
Регистрация: 4-02-16
Пользователь №: 90 332



Есть ли у кого-нибудь материалы или сведения о влиянии длины окна при обратном проходе в SOVA на исправляющую способность?
Go to the top of the page
 
+Quote Post

16 страниц V  « < 14 15 16
Reply to this topicStart new topic
2 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 1 daiquiri

 


RSS Текстовая версия Сейчас: 29th June 2017 - 14:27
Рейтинг@Mail.ru


Страница сгенерированна за 0.01462 секунд с 7
ELECTRONIX ©2004-2016