Здравствуйте, пытаюсь построить универсальный декодер fldpc кодов. Имеются разные значения длины кодовых слов и относительных скоростей. Написал декодер для длины кода 256 и скорости 1/2 (min-sum). Возникла проблема приведения сигнала 2/3 к скорости 1/2 - то есть вставке выколотых символов. Это нужно для того, чтобы декодировать одной матрицей независимо от скорости. Есть ли вообще возможность проведения такой процедуры?

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

http://www.trellisware.com/solutions/f-ldpc/

А есть материалы выше уровня обзорных статей? Можете поделиться? Сделал бы кодек и выложил бы для всех

это обзорные статьи
присоединяюсь к вопросу des00.
Можете поделиться материалами по которым можно сделать декодер FLDPC ?

Я имел ввиду перфорировании матриц. В указанной Вами статье об этом ничего нет. Думал может Вы где в патентах встречали ?

В приаттаченной статье говорится вскользь про перфорирование. К сожалению, у меня нет сейчас времени, чтобы с ней подробно ознакомиться. Возможно, в списке литературы будет что-то полезное.
 halford2008.pdf ( 242.56 килобайт ) Кол-во скачиваний: 397


А вот их патент: https://patentimages.storage.googleapis.com...s/US7975189.pdf

Имеются в виду турбоподобные коды - то есть RA(repeat accumulate) коды. В статье "New class of turbo-like codes with universally good performance and high-speed decoding" говорится, что можно их декодировать и как LDPC-коды, и как систематические турбокоды, и что кодер работает как турбокодер.
Также эти коды упомянуты в 802.16-2012.

Реализация MSA на ПЛИС фактически сводится к описанию матрицы, поэтому под каждую вариацию блок/скорость писать не вариант. Вопрос стоит в следующем: существует ли вообще возможность вставить выколотые биты для декодирования всех скоростей канонической матрицей 1/2?

PS. Я б прикрепил статью, но она весит 6.5 метров, если что - пишите письма.

Там есть CC, CTC, LDPC и BTC коды на основе кодов хэмминга? Вы последние имеете в виду ?

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

Вы новичок, поэтому у вас личка еще не работает. Если не сложно зашлите на shdv собака micran точка ру. Спасибо

В стандарте страница 1286 (LDPC опционально). Очень похожи матрицы - наличие сдвоенной единичной диагонали.

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

Хмм, ваймаксовский LDPC кодер, насколько знаю меняет скорость подменой матрицы, а не выкалыванием проверочных бит.


Если я правильно понял статью, то в декодере должен меняться на лету интерливер и блок вычисления SPC, никаких вставок делать не надо.

Можно ли где-нибудь найти законы перемежения для TW F-LDPC?

Там случайно проверочная матрица не для 4/5 самая большая, включает H(2/3), а та содержит H(1/2) как в ccsds LDPC кодеках?
Но там не все комбинации скоростей (1/2 - 4/5) и размеров подматриц (128 - 8192) проверочной матрицы используются.

Не, там матрицы там другие.

Есть ли у кого-нибудь типичные законы перемежения? Я нашел один, потестил, но он не подходит. Есть основания полагать, что разработчики fldpc не стали выдумывать велосипед, а взяли уже готовый перемежитель,а они для турбокодов все однотипные вроде.


Вот этот не подошёл:
for i = 1:N
if mod(i, 4) == 0
p(i) = 0;
elseif mod(i, 4) == 1
p(i) = N/2 + p1;
elseif mod(i, 4) == 2
p(i) = p2;
elseif mod(i, 4) == 3
p(i) = N/2 + p3;
end
end

for i = 1:N
int_coef(i) = (mod((p0*i + p(i) + 1), N)+1);
end

Сообщение отредактировал maratz - Feb 10 2016, 12:52

То что вы нашли для RSC турбокода. А вам нужно что-то вроде описанного в статье (стр.3).

ЗЫ. Покурил немного тему, занятная вещь. Непонятно только почему корка у хилых такая тормозная. 50 мегабит всего на артиксе. По идее если он декодируется как классический LDPC там 500 мегабит не должно быть проблемой.