[SKov 0]

..это называется "градус" нода..

Интересный термин. Можно какую-то ссылку, где бы он использовался?

[Dr.Alex 0]

Интересный термин. Можно какую-то ссылку, где бы он использовался?

Да хотя бы в стандарте поищите "degree"..

 

The number of edges adjacent to a node is called the degree of that node.

en_302307v010201p.pdf

[SKov 0]

Да хотя бы в стандарте поищите "degree"..

 

The number of edges adjacent to a node is called the degree of that node.

Спасибо, я понял.

Перевод degree как градус в данном контексте - это сильно! ;)

Порядок, степень, валентность, да что угодно, но не градус.

[Neznaika 0]

В процессе реализации кодера возник небольшой вопрос. Собрать то я собрал кодер для N=64800, но отладить его в симуляторе Quartus довольно сложно из-за большого объема данных. Симулирует около 15 минут. Решил переключиться на короткий код N=16200, симуляция занимает около 1.5-2 минут. Так вот стал копаться с таблицами, написал программу для получения инверсной таблицы для короткого кода. Но какого размера брать входные сообщения? Например для 1/2 q=25... напрашиваются сообщения в 16200/2/25=324 бита. В стандарте вроде как приведен пример для длинного кода и длина сообщений 360 бит. В какой то статье видел фразу, что М=360 для всех кодов. То ли имеется в виду для всех кодовых скоростей длинного кода, то ли для кодов включая короткие. Взял 360 бит, рассчитал под них инверсную таблицу, получилась цикличная таблица, но в ней кое-где отсутствует некоторые позиции информационных бит для проверочных бит с шагом 25 (В частности: P_186 {I_169,I_236,I_5767,I_6091,I_6875,I_7199,I_7369,I_7436} и P_211{I_170,I_237,I_5768,I_6092,I_6876,I_7370,I_7437}) . Может все-таки надо брать длину в 324 бита или это связано с тем что код короткий, а может вообще ошибка в программе расчета?

Изменено 28 января, 2014 пользователем Neznaika

[Dr.Alex 0]

Эхе-хе.... Незнайка - Незнайка.. Откуда вы всё это взяли..

 

Длина "сообщения" шортфрейма 1/2 составляет 7200 бит.

 

Не надо так уверенно говорить что вы там "написали программу для инверсной таблицы" и всё такое, это не столь простое дело.

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

[Neznaika 0]

Да-да) До вчерашнего вечера я думал что при 1/2 в коротком коде 8100 информационных бит. Покопался в ИНЕТе и все-таки раздобыл статью в которой была исчерпывающая таблица) Думаю достаточно скорректировать программу для инверсной таблицы под 7200 бит и будет то, что нужно. Она по-любому написана, только вот считает пока не правильно :crying:

 

 

 

Сменил количество информационных символов и уваля! Инверсная таблица получилась такая какая и должна быть) :yeah:

[_sda 0]

Покопался в ИНЕТе и все-таки раздобыл статью в которой была исчерпывающая таблица

А можно эту статью посмотреть?

[Serg76 0]

Мдя..., это по нашему. Вместо того, чтобы изучить стандарт, в котором собрана вся необходимая информация, Незнайка шерстит ИНЕТ и ищет инфу в непонятных статьях. Ну что же, Бог в помощь ))))

[Dr.Alex 0]

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

 

[Neznaika 0]

А можно эту статью посмотреть?

 

Действительно есть) Таблица 5b... она в разделе БЧХ находилась, потому и не попалась на глаза... но благодаря моей уникальной невнимательности были найдены несколько полезных статей, где более полно и раскрыто написано о LDPC кодировании/декодировании по DVB-S2 :maniac:

RATE_ADAPTIVE_TECHNIQUES_FOR_FREE_SPACE_OPTICAL_CHANNELS.pdf

[_sda 0]

Действительно есть) Таблица 5b... она в разделе БЧХ находилась, потому и не попалась на глаза... но благодаря моей уникальной невнимательности были найдены несколько полезных статей, где более полно и раскрыто написано о LDPC кодировании/декодировании по DVB-S2 :maniac:

Спасибо!

А по невнимательности мы ещё посоревноваться сможем,коллега :rolleyes:

[Neznaika 0]

И снова здравствуйте! Были сделаны 2 варианта кодеров с разными структурами и затрачиваемыми ресурсами. Можно и 3 вариант замутить, он будет оптимальнее первых, но не суть. Взялся теперь за реализацию декодера. Довольно много тонкостей и деталей по оптимизации архитектуры с использованием регулярности кода. В одной статье наткнулся на предлагаемую архитектуру, но никак не могу понять откуда берутся адреса сдвигов для Barrel Shifter и адреса для чтения из RAM значений ветвей Check Node. Схему и статью прилагаю. Помогите прозреть!

date05.pdf

Изменено 19 февраля, 2014 пользователем Neznaika

[Maverick_ 15]

И снова здравствуйте! Были сделаны 2 варианта кодеров с разными структурами и затрачиваемыми ресурсами. Можно и 3 вариант замутить, он будет оптимальнее первых, но не суть. Взялся теперь за реализацию декодера. Довольно много тонкостей и деталей по оптимизации архитектуры с использованием регулярности кода. В одной статье наткнулся на предлагаемую архитектуру, но никак не могу понять откуда берутся адреса сдвигов для Barrel Shifter и адреса для чтения из RAM значений ветвей Check Node. Схему и статью прилагаю. Помогите прозреть!

спасибо за статью - интересная...

 

[andyp 9]

Не знаток DVD-S2 кода, но:

 

Shift Value с Figure 3 - это x из формулы (2) статьи. Про x говорится, что он определяется в стандарте и зависит от скорости кода (code rate).

 

"Reading address - это вроде бы q из того же соотношения. Но тут я не до конца уверен." - здесь точно наврал. q - это размер банка на стадии Check Nodes Message Mapping

Изменено 19 февраля, 2014 пользователем andyp

[Neznaika 0]

"The shuffling offsets and addresses can be extracted from the x tables provided by [2]" - Сдвиги перестановщика (на мой взгляд Berrel Shifter) и адреса могут быть получены из Х-таблиц ссылки/статьи [2]... [2] - это стандарт DVB-S2 в котором приведены таблицы перестановок, но как получаются из них адреса и сдвиги, приведенные на рисунке? Для меня загадка...