Перейти к содержанию
    

Вопросы по итеративному декодированию

Доброго дня!

 

Развлечения ради, решил сделать LDPC кодек из стандарта GSFC-STD-9100. Проверочная матрица в приложении. Видно что в базовой подматрице 2 единичных коэффициента, вместо одного, как в WiMax. Я же правильно понимаю что количество vnode при декодировании будет в 2 раза больше, если бы это были единичные матрицы WiMax? Т.е. каждый cnode связан с 32 vnode, а каждый vnode связан со входным битом и 4 cnode?

 

Правильно ли понимаю, что по сути, в декодере нужно сделать 2 слоя vnode по 16*511 метрик (четный/нечетный), связанных между собой через cnode и при итерациях обновляются оба слоя?

 

Спасибо.

 

ЗЫ. Думал по "быстролянчику" натяну этот код на Wimax овский декодер. Но .... не тут то было :D

post-3453-1465473893_thumb.png

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Доброго дня!

...

Вопрос снимается. Сделал идеалки. Начну пилить RTL :)

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

LDPC кодек из стандарта GSFC-STD-9100

Тема пройденная. Смотрю на F-LDPC коды от Trellis Ware. Подскажите, где можно взять эталонные фреймы, для проверки работы кодера ?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Смотрю на F-LDPC коды от Trellis Ware. Подскажите, где можно взять эталонные фреймы, для проверки работы кодера ?

Денис Вы случайно не находили Parity check matrix для F-LDPC кода от Trellis Ware? Может Вы где в патентах встречали ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Денис Вы случайно не находили Parity check matrix для F-LDPC кода от Trellis Ware? Может Вы где в патентах встречали ?

Пока не находил. Только намеки как ее вычислить. И в статье указано что декодировать эти коды как LDPC не рекомендуется. Слишком много единиц в проверочной матрице. Проигрывает турбо декодеру по ресурсам. Странно что нигде не указан четко используемый интерливер. Одни намеки. И в стандартах вроде этого кода нет :(

 

ЗЫ. То что LDPC использовать нельзя не айс. Быстрое турбо сделать не просто, надо решетку дробить. Мне интересны скорости > 500 мегабит %(

A_New_Class_of_Turbo_like_Codes_with_Universally_Good_Performance_and_High_Speed_Decoding_.pdf

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Никто не находил/вычислял таблицы полиномов битов четности для всего диапазона скоростей/размеров кодов ARJ4A из оранжевой книги? Поделитесь, что бы с протографами не заморачиваться :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

По FLEX известно, что интерливер строится на основе Dithered Relative Prime алгоритма.

US20050216819.pdf

Изменено пользователем maratz

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

По FLEX известно, что интерливер строится на основе Dithered Relative Prime алгоритма.

US20050216819.pdf

Спасибо, теперь много понятнее. Ндя, интерливер для не ищущих легких путей. Придется таблицы использовать. Не до конца понятно использование различных решеток. Вроде как там структура внутреннего и внешнего кода фиксирована. Откуда разные решетки ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Патент описывает некий турбоподобный код с хорошей гибкостью в плане изменения скорости кодирования. Внешний и внутренний коды, описанные в нём, отличаются от применяемых в FLDPC, поэтому я не уделял им внимания. В FLDPC используются два простейших кодера: внешний - 1+D, внутренний 1/1+D. Алгоритм их декодирования детально описан в статье, прикрепленной des00. Алгоритм декодирования подобных кодов можно посмотреть в матлабе, в хелпе SCCC, там свёрточники немного сложнее, но суть такая же.

PS. По скорости - автор статьи утверждает, что на virtex-II 8000 c тактовой 100 МГц они добились 300 Мбит/с с 10 итерациями.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Раскурил патент по запчастям

Патент описывает некий турбоподобный код с хорошей гибкостью в плане изменения скорости кодирования.

Похоже это описание FLEX кода, более прошаренного чем F-LDPC в плане noise floor. Но за это нужно заплатить ресурсом декодеров.

PS. По скорости - автор статьи утверждает, что на virtex-II 8000 c тактовой 100 МГц они добились 300 Мбит/с с 10 итерациями.

Если делать скользящее окно то да, это возможно. Правда тут все упирается в возможность реализации collision free интерливера.

 

В целом, архитектура этого кодека мне понятна. Параллельный MAP движок, collsion free интерливер и математика из CNODE движка LDPC для декодирования SPC. Спасибо за инфу !

Внешний и внутренний коды, описанные в нём, отличаются от применяемых в FLDPC, поэтому я не уделял им внимания.

А вы делали этот кодек? Использовали свой интерливер или из патента? Можете поделиться эталонными закодированными последовательностями для блоков разной длинны? Эталонного сравнения ради.

 

Изучая ссылки на статьи, наткнулся вот на такую книгу Turbo-like Codes Design for High Speed Decoding Может мимо кого пробегала. Прошу поделиться :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Изучая ссылки на статьи, наткнулся вот на такую книгу Turbo-like Codes Design for High Speed Decoding Может мимо кого пробегала. Прошу поделиться :)

 

http://bookfi.net/md5/4D7D9B149550E1F6803A197B6AEBDCF5

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В статье A_New_Class_of_Turbo_like_Codes_with_Universally_Good_Performance_and_High_Speed

_Decoding, прикрепленной выше, описывается алгоритм мягкого декодирования интегрирующего кодера 1/1+D. В описание утверждается, что если подать на информационный вход нули, а на проверочный - полученные мягкие решения проверок, то на одном из выходов декодера мы получим исходную информационную последовательность, а на втором обновленную проверочную.

Что, собственно, я и делаю в прикрепленных м-файлах, но в некоторых случаях информационная последовательность действительно идентична исходной, а в некоторых появляется ошибка в первом бите.

Может быть у кого-то получится реализовать алгоритм без этой фичи:)

fba.rar

Изменено пользователем maratz

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Покурил немного тему про TPC. Созрел глупый вопрос. Почему код Хэмминга не декодируют в мягкой форме по графу Таннера? Зачем связываться с алгоритмом Чейза, находить ненадежные метрики и т.д, если можно сделать все через сложение вероятностей, ведь уравнения четностей никуда не делись ?

 

прикрепленной выше, описывается алгоритм мягкого декодирования интегрирующего кодера 1/1+D. В описание утверждается, что если подать на информационный вход нули, а на проверочный - полученные мягкие решения проверок, то на одном из выходов декодера мы получим исходную информационную последовательность, а на втором обновленную проверочную.

Вы про страницу 5 и формулы 11a - 11d? Там же вроде классические прямая и обратные рекурсии MAP алгоритма.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вы про страницу 5 и формулы 11a - 11d? Там же вроде классические прямая и обратные рекурсии MAP алгоритма.

Именно так - частный случай MAP алгоритма. Может у кого-то есть код для этого случая?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...