[andyp 10]

9 hours ago, des00 said:

... вы будете смеяться, но....это работает. 

Вуду это какое-то. Не люблю непонятное. Имхо, после первой итерации если нет норм оценок достоверности бит, Чейзу не очень хорошо должно стать -  ему же наиболее плохие биты нужны в списке, а там будет залетать абы что. Мне этим и в оригинальной статье Pyndiah  декодер не особо нравился.  Всегда думал, что SPC как второй код именно в этом помогает. Экстринсики после полуитерации SPC залетают в Чейза и как-то норм более-менее. Хотя да, для квадратных кодов с Хеммингом по колонкам и столбцам я тоже цифры Pyndiah получал.

PS С заголовками графиков не то что-то. Там же не single parity check code, а Хемминг расширенный?

[des00 25]

8 hours ago, andyp said:

Вуду это какое-то. Не люблю непонятное.

Ну вот я крутил крутил логи (что бы получить файлы логов надо включить decSet.log_on = 1), смотрел как ведут себя метрики, какие именно веса кодовых слов насчитываются, как применяются коэффициенты alpha/beta и пришел к следующему выводу, сформированному по правилу "нутром чую что литр":

1. Если посмотреть как применяется коэфцииент beta у Pyndiah, то по сути, при идеальной метрике бита на входе +-1, выходная метрика бита без пары равна ее увеличению на шаг (1+beta), где beta меньше либо равен 1.

2. Поиск контрслова у Pyndiah, приводит к тому, что выходная метрика бита с парой может быть значительно больше остальных метрик, потому что формируемый им список состоит из двух частей: одинаковые кандидаты(спасибо жесткому декодеру) и группа значительно отличающихся кандидатов метрика которых значительно больше(из того что видел доходило до 4 и более раза).

3. Таким образом получается что у Pyndiah на выходе есть значительная неравномерность выходных метрик/экстринсиков: биты с парой могут из -0.25 дать +4, а биты без пары, на первых итерациях, всего лишь незначительно увеличиваются на 20-30%. Поэтому, КМК и вводятся малые коэффициенты alpha на первых итерациях что бы как то "усреднить" эту не равномерность. Типа плохим битам сделаем получше, хорошим накинем чуток. 

4. В предлагаемом Wang алгоритме, формируемый список сразу фильтруется на предмет одинаковых кандидатов (за счет проверки что исправленная жестким кодом ошибка стоит в месте отличном от стирания), в итоге получается в списке находится "точно попавшее" слово со стираниями (нулевой синдром и нулевая четность) и слова с исправленными битами вне позиций стертых бит (которых всего 4). 

5. В итоге в отсортированном списоке метрик таких кандидатов разница между первыми двумя составляет диапазон 0.1 - 1, что при применении указанного правила, для бит без пары дает прибавку аналогичную по весу что у оригинала, а для бита с парой дает результат меньше или равный чем в оригинальном алгоритме. Но, за счет того что берется ближайшая пара, разброс метрик получается не такой большой как Pyndiah. Это позволяет не париться с alpha, сделав его аналогично LDPC кодам, фиксированным для всех итераций.

Вот так я себе обьяснил наблюдаемый эффект.

8 hours ago, andyp said:

PS С заголовками графиков не то что-то. Там же не single parity check code, а Хемминг расширенный?

Спасибо, как всегда извечный копипаст, до этого я отдельно крутил квадратный турбокод на SPC (движусь к реализации wimax BTC полного кодека на 100Мб/с).

Из интересного, BTC (32,31)^2, при скорости кодирования 0.94 на 5 итерациях показал результат аналогичный жесткому классическому витерби [171 133] со скоростью кодирования 1/2, а именно EbN0(1е-6) ~= 7дБ (bertool)

Да, Витерби жесткий, не мягкий, но тем не менее я считаю что это приличный результат для кода, компонентные коды которого могут только определить наличие битовой ошибки) 

[andyp 10]

9 hours ago, des00 said:

...

Вот так я себе обьяснил наблюдаемый эффект.

...

Из интересного, BTC (32,31)^2, при скорости кодирования 0.94 на 5 итерациях показал результат аналогичный жесткому классическому витерби [171 133] со скоростью кодирования 1/2, а именно EbN0(1е-6) ~= 7дБ (bertool)

Да, Витерби жесткий, не мягкий, но тем не менее я считаю что это приличный результат для кода, компонентные коды которого могут только определить наличие битовой ошибки) 

Спасибо,  интересно было. Может, погоняю Ваш матлаб, посмотрю. Со временем беда какая-то постоянно :(. И всё-таки, имхо, процедура эта ещё здорово не оптимальная.  Была идея подекодировать Хемминга по решетке BCJR алгоритмом, чтобы хотя бы понять, сколько на всех этих выкрутах теряется, да что-то тоже руки не дошли, бросил. А так этот код - действительно хороший варик, когда большая скорость кодирования нужна.

 

[des00 25]

23 hours ago, andyp said:

Была идея подекодировать Хемминга по решетке BCJR алгоритмом, чтобы хотя бы понять, сколько на всех этих выкрутах теряется, да что-то тоже руки не дошли, бросил.

Decoding algorithms for shortened-extended TPC in WiMAX systems.pdf

тут в статье автор рассматривает декодирование по Pyndiah и по MAP BCJR алгоритму, но как я понял статью толку не особо много. Выигрыш незначителен, а проигрыш по производительности значителен. 

23 hours ago, andyp said:

А так этот код - действительно хороший варик, когда большая скорость кодирования нужна.

Да столкнулся с задачей где упираться в предельное чутье не нужно, желательно отсутствие noise-floor но требуется нормальная пропускная способность при минимальном ресурсе, поэтому LDPC избыточен, CTC недостаточен, и тут вспомнил что надо закрыть гештальд по BTC кодам) Единственное что не нравиться это сборка входного/выходного блока данных с гранулярностью бит, тем более при использовании сложных укорочений. Но мне нужно ~100-150Мб/с, что можно сделать на битовом уровне) Но вот собирать такие потоки произвольно на каком нить гигабите, не представляю как, внутри одного ядра)

[andyp 10]

1 hour ago, des00 said:

 

тут в статье автор рассматривает декодирование по Pyndiah и по MAP BCJR алгоритму, но как я понял статью толку не особо много. Выигрыш незначителен, а проигрыш по производительности значителен. 

 

Как-то не очень рассматривает.  Если в лоб, как он пишет, то работать не будет.  Там решетку делают под эти коды и декорируют уже по ней. Здесь например (wang1999). Но и это не для реализации, а только посмотреть, сколько теряем - решетка для 32-битного кода получается приемлемого размера, чтобы моделирование погонять.

На счёт того, что простор для оптимизации есть, я уверен. Например, SEW алгоритм (остальные две ссылки) позволяет часть назад вернуть. И у него сложность контролируемая 

Lalam2006.pdf Feng-013597728.pdf wang1999.pdf

[des00 25]

20 hours ago, andyp said:

Как-то не очень рассматривает.  Если в лоб, как он пишет, то работать не будет. 

Да, глянул, на бегу увидел MAP, подумал что там рядом и BCJR, но оказалось нет) тем не менее, по графикам у автора 0.25дб выигрыш наблюдается.

20 hours ago, andyp said:

Там решетку делают под эти коды и декорируют уже по ней. Здесь например (wang1999). Но и это не для реализации, а только посмотреть, сколько теряем - решетка для 32-битного кода получается приемлемого размера, чтобы моделирование погонять.

Смотрю с практической точки зрения, BCJR для компонентных кодов, не нравится своей двухпроходностью по решетке. А с учетом того что компонентных кодов много, то если требуются большие пропусные способности стоит ли овчинка выделки) Но истины ради интересно погонять, да)

20 hours ago, andyp said:

На счёт того, что простор для оптимизации есть, я уверен. Например, SEW алгоритм (остальные две ссылки) позволяет часть назад вернуть. И у него сложность контролируемая 

Спасибо за статьи, SEW интересное применение, напомнило мне мягкое декодирование расширенного кода Голлея, когда разбиваем его на две половинки (data, parity), в каждой по чейзу на N стираний, потом кодируем, получаем 2*2^N кандидатов и считаем веса для выбора максимально вероятного кода. Но, ЕМНП, в моей реализации энергетический выигрыш, относительного обычного Чейза на N+1 стирание был незначителен, а ресурс требовался раза в 2 больше. 

Думал применить SEW (но я тогда не знал как это правильно называется) к eHamming, но пока руки не дошли, посчитал что для d = 4 он не имеет особого, практического смысла)

 

[andyp 10]

3 hours ago, des00 said:

Смотрю с практической точки зрения, BCJR для компонентных кодов, не нравится своей двухпроходностью по решетке. А с учетом того что компонентных кодов много, то если требуются большие пропусные способности стоит ли овчинка выделки) Но истины ради интересно погонять, да)

С практической точки зрения там реально пользы никакой. Для Хамминга  (32,21) там под 15000 ребер оптимальная решетка. Только посмотреть, как будет декодить, и использовать как границу.

3 hours ago, des00 said:

Спасибо за статьи, SEW 

Ну там примерно 0.5 dB выигрыш. А декодирований жёстких здорово больше надо. Просто как пример, как можно расширить список слов для контргипотез и того, что это что-то даёт.

 

[petrov 7]

des00

напомнило мне мягкое декодирование расширенного кода Голлея, когда разбиваем его на две половинки (data, parity), в каждой по чейзу на N стираний, потом кодируем, получаем 2*2^N кандидатов и считаем веса для выбора максимально вероятного кода

Это из какой-то статьи? Не поделитесь?

[des00 25]

17 hours ago, petrov said:

Это из какой-то статьи? Не поделитесь?

EFFICIENT IMPLEMENTATION OF DECODER USING MODIFIED SOFT DECODING ALGORITHM IN GOLAY (24,12) CODE.pdf

Пробежал глазами, да статья та, но вот блок схемы алгоритма там нет, только описание. Как помню, реализовывал на основе написанных идей. Для ПЛИС кодирование голея (24,12) делается таблично(1 блок памяти), поэтому вместо описанного алгоритма я делал две таблицы: прямую (получить 12 бит четности из 12 бит данных) и инверсную (получить 12 бит данных из 12 бит четности) ну и дальше уже искал максимальное правдоподобие. 

[petrov 7]

des00

Спасибо!