Я встречал другое объяснение - от итерации к итерации информация о бите уменьшается, поэтому вводят нечто типа OOC, чтобы учесть это уменьшение.

хмм, надо еще будет эту тему прошерстить.

В приложении матлабовский примитивный, без какой либо оптимизации, декодер dvb-rsc, часть функций сделана близко к железу, позволяет покрутить/посмотреть что и как считается, что куда идет, как себя ведут метрики и прочее Содержит комментарии как что и куда. Перехожу к работе над HDL идеалкой.

спасибо...

там я только немного "накосяпорил" когда считал оценочный FER (FEC Error Rate), затер некодированный BER. Только сейчас увидел, будете пробовать поправьте

Поздравляю с завершением этапа

Похоже где то я ошибся Сделал идеалку на RTL, осознал откуда растут ноги у количества эффективных бит у метрик пар/ветвей/состояний/extinsic. Но? начал гонять и заметил расхождение в характеристиках декодера, по сравнению с используемым мной "референсным" документом. Документ в приложении, характеристики на странице 3 (466 страница документа). Набрел на него когда искал точки привязки BER для декодера(в других найденных документах приводился FER в качестве характеристик).

Первая мысль что используемый для моделирования в RTL генератор шума не верен. Отложил в сторону RTL. Взял матлабовский вариант без квантования, ограничений, честный Log Map и т.д. Тоже не бьются кривые с документом. Особенно если учесть тот факт, что в документе якобы рассмотрен Max Log Map без каких либо улучшений. Проверяю на QPSK, пакет длинной 64 пары, кодирование 1/3, 10 итераций. Пример расхождения характеристик : EbN0 = 2.5дб, в статье BER 5е-5, RTL код BER 4е-4, матлаб 2е-4.

Может кто нибудь поделиться ссылками на эталонные результаты или характеристиками своих декодеров? Интересует кривая для пакета 64 пары, кодирование 1/3, 8 итераций. Диапазон EbNo 0.5:0.5:4.

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

Посмотрел повнимательнее твой матлаб - есть один момент:

У тебя решетка циклическая, следовательно состояния решетки в начале и конце должны быть одинаковыми. Начинать нужно с альф. Доходишь до конца, используешь последние полученные альфы для инициализации (N+1)ых бет и идешь назад по решетке. Затем сохраняешь полученные 0ые беты для использования как 0ые альфы на следующей итерации.

Ошибся в добавлении шума к сигналу в тесте на SV. Забыл про одну из типовых System Verilog gotcha, в результате при добавлении к сигналу шум становился не AWGN, со всеми вытекающими. Поправил это место и характеристики легли близко с "референсным" декодером в статье. Почему матлаб работает не так еще не понял, может быть сказывается количество бит. RTL гоняю на 8М бит(15 минут на тест), матлаб на 200К (это он ночь стоит, очень уж медленно он работает).


Понял, проверю. Цикличность отдельно альф от бет я сделал основываясь на разделе в стандарте (в приложении). С бет начинал потому что планирую в железе делать sliding window с двумя движками для бет и одним для альф. Уж больно не хочется два раза массив данных перебирать.

Когда искал в чем косяк созрел такой вопрос. Насколько правомочно формирование метрик отсчета L1,L2 для дебитов по правилу:
L00 = 0, L01 = L2, L10 = L1, L11 = L1+L2. По идее это результат вычитания из метрик L01/L10/L11 метрики L00. Но тогда должно быть так :
исходные метрики L00 = -L1-L2, L01 = -L1 + L2, L10 = L1 - L2, L11 = L1+L2 и после вычитания получается L00 = 0, L01 = 2*L2, L10 = 2*L1, L11 = 2*(L1+L2).

Казалось бы постоянный множитель LLR алгоритму не принципиален, но ведь этот множитель задает распределение надежностей. Например пусть L1/L2 = 4, тогда честные метрики будут : L00 = -8, L01 = 0, L10 = 0, L11 = 8. "Расстояния" между метриками L01/L10/L11 и метрикой L00 будет 0/8/8/16. Тогда как по упрощенному правилу метрики будут L00 = 0, L01 = 4, L10 = 4, L11 = 8 и расстояния 0/4/4/8. Как более правильно? Или этом пренебрегают в виду того, что exp(-4) = 0.0183 и exp(-8) = 3.3546e-04?

Код запускаете напрямую или компилируете в mex или exe?
У меня для декодера компиляция дала прирост почти на порядок.

Судя по всему напрямую, рылся в хелпе как скомпилировать в mex (в симулинке такое делать умею), а тут так и не разобрался.

Посмотрите примеры по codegen.

По своему опыту скажу следующее: если в матлабовском коде используются в основном встроенные функции, которые хорошо векторизованы, то от генерации сишного кода будет даже проигрыш прмерно в 1.5-2 раза, если же присутствует множество вложенных циклов, условия, то будет выигрыш (у меня получалось от 1.5 до 20 раз для различных программ, Win7, 64 bit).

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

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


Понял спасибо.

Как раз успел прогнать разные варианты (альфа - бета, бета - альфа) на маленьких кодах, проигрыш виден не вооруженным взглядом. На больших еще не проверял.

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

У меня даже декодер, оптимизированный под матричные операции для ускорения простого кода ускорился значительно.
Плюсом желательно использовать parfor, чтобы полностью загрузить процессор.
Далее можно скомпилировать exe с помощью mcc для запуска сразу на нескольких машинах с установленным mcr.

Какая максимальная скорость (в битах данных или символах в сек.) получилась в итоге после всех оптимизаций и при каких режимах (тип кода, количество итераций, частота и тип процессора, использование SIMD, мультитрейдинга и др.)?


Какая максимальная скорость достигнута в Вашей реализации?

Турбо-декодер делал давно, для него не генерировал код. Описал полученные результаты на различных алгоритмах только в качестве примера по генерации mex-файлов. Из последнего: сейчас мне понадобилась собственная реализация алгоритма Витерби. В первом случае мне нужно только значение наилучшей метрики (оптимальные пути не ищутся, только вычисляются метрики), выигрыш получился минимум в 10 раз, на некоторых длинах блоков и при определенном числе состояний решетки в 15-20 раз. Для случая, когда декодер выдает оптимальный путь, выигрыш составил 1.5 раза (подозреваю, что как-то можно оптимизировать процесс копирования выживших путей). Процессор Intel Core 2 Duo, 3 GHz. Компилятор использовался VS 2010, наверное, от будь от Intel, результаты получились бы лучшими. Matlab 2014a 64 bit. Мне real-time не нужен, генерировал только для сокращения времени моделирвания.
Не подскажете, где можно прочитать по настройкам оптимизации?

~300кб/с (свёрточный турбо на 4х битном регистре, rate 1/2, 10 итераций max-log-map, qpsk + awgn, Xeon E5-2620v2 2.10GHz, mcr 2014a 64bit)

Ок, спасибо. Если немного отойти от темы, то выигрыш 1.5 раза - это сколько в битах и для какой относительной скорости кодирования и длины кодового ограничения? Кстати, алгоритм Витерби, точнее его вариант с генерацией мягкого выхода - SOVA, можно смело применять и для RCS кода, правда неизвестно еще будет ли выигрыш по скорости в сравнении с MAX-LOG-MAP, но по эффективности, конечно, хуже. По поводу Intel: прирост должен быть как на уровне компилятора, так и при использовании их примитивов - IPP, а по поводу настроек оптимизации имеется ввиду компилятор?


Спасибо, 4-х битный - это на 16 состояний как в RCS2?

Это специфическая задача, аналогичная TCM. Пока что модуляция PAM-8, сверточные коды скорости 1/2. Различные полиномы (кодовые ограничения от 3 и до 7).

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

Да, на 16 из стандарта ECSS-E-ST-50-01C, длиной 1784.

Первые результаты по RTL кодированию

Сел за синтезируемую RTL реализацию и сразу возник глупый вопрос:
функция генерации адресов перемежителя судя по всему не обратима (табличные реализации не рассматриваются), это делает не возможным предварительную подготовку результата декодирования полу-итерации на этапе записи ее результата в буфер. Следовательно нужно делать перемежение при чтении. Делать это отдельной операцией, перекладывая из буфера в буфер тривиально. Интересна реализация на лету.
В этом случае, насколько понимаю, есть проблема в генерации обратного порядка адресов чтения, которые необходимы для обратного прохода. И даже если бы такой проблемы не было, то была бы проблема расчета начальных адресов буфера для реализации sliding window когда бета считается первой (рассматриваем вариант отсутствия операции деления в целевой архитектуре). Логично в случае sliding window сначала вычислять альфу, складывая данные в LIFO, а потом считать бету одновременно с результатом. Теперь собственно вопрос: во всех материалах что я видел по sliding window, рассматривают вариант расчета беты, потом альфы. И нигде наоборот. Все делают перемежение отдельной операцией или все таки есть метод обращения функции генерации адреса ?

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

Хмм, может я не так задал вопрос. Рассмотрим пример : код длинной 64 пары, делаем перемежение на лету.
Первая полуитерация делается над данными как есть. альфа проходит по адресам 1:1:64, бета по адресам 64:-1:1. Просто реализуется на счетчике. Пишем результат тоже по адресам 1:1:64
Вторая полуитерация делается над данными после перемежения. альфа проходит по адресам 1, 10, 47, 56, 29, 38, 11, 20, 57 ...... 55, 0, 37, 46, 19, 28. Это тоже просто реализуется на счетчике + компаратор, вычитатель и сумматор. А вот бета должна пройти по адресам 28, 19, 46, 37, 0, 55, 18, 9..... 56, 47, 10, 1. Вот эти адреса уже требуют обращения функции генерации адреса. Вот тут бы заранее заполнить память в правильном порядке, что бы вторая полуитерация работала как первая. Это можно сделать либо отдельной процедурой перемежения(переписать данные из памяти результата первой полуитерации в память исходных данных второй), либо обращением адреса при записи результата первой полуитерации

Если делать забег в режиме sliding window сначала по альфе, то можно просто сохранить адреса вместе с данными в LIFO, потом при забеге по бета, расчет не потребуется, т.к. адрес уже посчитан и результат второй полуитерации можно записать в уже деперемеженном формате в результат.

Прошу прощения я кажется запутался, я правильно понимаю ваш вопрос, вы хотите получить адреса данных после перемежения для бет в обратном порядке?

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

да, именно так.


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

самое занятное что они правы, внимательно позырил на формулу и все встало на круги своя. Замена сложения на вычитание P0 в аккумуляторе и изменение адреса инициализации с 0 на P0*(N-1) % N дает искомый результат. Жаль только то, что под каждую длину нужен свой уникальный адрес инициализации

Это не самая большая проблема. Проблема - обеспечить, чтобы параллельно работающие SISO модули не сталкивались при доступе к памяти экстринсиков. Вот статья про это на примере wimax. Может, будет интересно.

статья немного путаная но занятная, но по кросс линкам ведет к статье A HIGH-SPEED MAP ARCHITECTURE WITH OPTIMIZED MEMORY SIZE AND POWER CONSUMPTION вот там яснее написано

Попутно возник вопрос, почему все бьются за повышение параллелизма одной полуитерации. Положим есть 10 параллельно работающих движков, это требует наличия 10 ти портовых регистровых файлов. Ведь можно же уйти в глубину : те же 10 движков поставить последовательно в конвейер и развязать их двухпортовыми блочками памяти(при этом память под Lext можно заменить на память Lext + Ls). Да, задержка обработки вырастет, но пиковая производительность останется на том же уровне. Правда количество итераций произвольно менять будет сложнее.

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

Что касается статьи, она не про тоже самое, что и статья, которую ты привел. У Martinа размер окон меняется динамически в зависимости от размера блока и авторы ставят задачу прокормить до 4 движков, делающих одну полуитерацию, экстринсиками из однопортовой памяти. Т.е. они вообще не ставят перед собой задачу получить макс. пропускную способность с выхода декодера. Они говорят о достаточной.

Больше информации о том, как устроен декодер у Martinа, можно почерпнуть из прицепленной статьи. Предыдущая была только про интерливер.

Что касается граничных альф и бет для окна, они используют значения, полученные на предыдущей итерации.

Вот как раз по этому вопросу мне не до конца понятно.
Реализовал модель декодера который работает по окну == размеру пакета. За один проход считает альфа и бета: читает метрики и экстинсики для двух пар, до середины пакета набирает состояния в память, после середины начинает вычислять выходные экстринсики для двух пар одновременно и пишет в память экстринсиков. Адреса записи не пересекаются, чтение с записью разведено латентностью обработки. Все должно более менее красиво лечь в ПЛИС, правда в качестве блочков памяти нужно будет из двухпортовок сделать память 2 порта на запись и 2 на чтение (как прикрутить однопортовку еще не задумывался). Сама решетка инициализируется на концах и вычисления идут по эталонной модели с первой итерации.

В многооконных декодерах, судя по одной из статей

делают так : если я понял правильно, окна не перекрываются и решетки окон инициализируются в 0. Но ведь свойство решеток в том, что они сходятся спустя несколько длин кодовых ограничений? Т.е. если размер окна у нас 32, то первые 16 состояний уйдут "в молоко". Получается первая итерация "на выброс". Но ведь это может дать неправильные экстринсики и усложнить сходимость декодера. На это забивают и тупо увеличивают количество итераций ? Типа "на что не пойдешь ради производительности" ?

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

Злодеи

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

Базовый синтезируемый декодер в ПЛИСовой теме. К сожалению все уперлось в расчет рекурсии за 1 такт : 4 сложения и 3 MAX* На моем среднем чипе для 8ми итераций, битовая кодированная скорость ~=2*100/(8*2) = 12.5 мегабит.

Код не смотрел, но вброшу - Конвейер не спасет отца русской демократии?

Нет. Сейчас скорость декодирования в полуитерации 1 пара/такт и частота ~100 МГц, если расконвейризировать (поставить регистры на критическом пути), то получиться частота ~200МГц, но и скорость декодирования 0.5пары/такт. В итоге размен шило, на мыло, при более сложном управлении. Как вариант, можно сделать на частоте ~200МГц, с мультиплексированием вычислительных модулей, при скорости декодирования 0.5 пары за такт, даст экономию ресурса процентов 40.

Есть такой вопрос по теории кодирования. На форуме уже была тема с обсуждением этого вопроса, но ЕМНИП закончилась ничем. Предисловие вопроса:
рассмотрим кривую декодирования с такими точками:

это QPSK размер пакета 212 пар, скорость 1/3. ber - бер после декодирования, fer - бер до декодирования. Если "не вооруженным взглядом" сравнить измеренный fer с эталонным графиком не кодированного QPSK с характерной точкой 1e-6 при EbNo = 10.5дб, то кажется что что-то не так. Но если вооружиться и пересчитать через EsNo = EbNo + 10log10(bps) + 10log10(coderate) то все встанет на свои места.

Теперь собственно сам вопрос : использование EbNo для сравнения систем кодирования/декодирования более менее понятно, нужна общая точка для сравнения характеристик декодеров, но для реальных систем связи более актуален EsNo. Почему он в теории кодирования, в применении к реальным системам связи, совсем не встречается? Более актуален ИМХО потому что этот параметр нагляден. Например: система с не кодированным QPSK может работать с 1е-6 при SNR ~= IEVM == 13.5дб, добавляем кодирование и можем работать при том же бер ну положим с SNR = 6дб(но на меньшей скорости). Наглядно и понятно что к чему, без сложных перерасчетов.

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

На практике это оказывается не всегда удобным и народ часто перескакивает на Es/N0, когда именно Es/N0 неизменен и интересует именно выигрыш от применения той или иной схемы в данной конкретной системе связи.

Например два графика BER от Es/N0 для BPSK и QPSK, вроде кажется, что BPSK лучше, на самом деле одинаково, да ещё и на полосе экономим в два раза в случае QPSK. SNR - самозапутывание, Eb/N0 - сразу всё ясно. ИМХО

Вот как раз к такому же логическому выводу и прихожу

На практике обычно речь идет об энергетике в фиксированной полосе. ИМХО пример BPSK vs QPSK мне всегда казался исключением чем правилом, если уйти на более сложные созвездия, то при фиксированном EsNo будет не все так однозначно: например QPSK с кодированием 7/8 или 8PSK с 2/3 или QAM16 с 1/2 (при прочих равных). При использовании EsNo будет однозначно понятно что будет в каждом случае, при использовании EbNo нужно будет заниматься перерасчетами

Есть подозрение, что кодовую конструкцию в отрыве от сигнальной конструкции сравнивать с чем-то не стоит.

Лучше подскажите, пакетирование ошибок это хорошо или плохо? Т.е. на выходе кодека сатистика ошибок отличается от статистики ошибок в канале с абгш с тем же ber, и есть ошибки, которые кучкуются внутри одного кадра.

Не хорошо и не плохо. Это бывает не багом, а фичей Часто бывает при декодировании сверточных кодов, где ошибка в пути по решетке приводит к сразу нескольким рядом стоящим поломанным битам на выходе. Для иллюстрации - северточный код (133,171) У него 11 словам с весом d_free соответствует общий вес в 36 информационных бит. Т.е. в среднем ошибка в пути по решетке приводит к появлению 36/11 ошибочных информационных бит, стоящих близко друг от друга.

Именно из-за барстов ошибок на выходе сверточного кода вслед за ним ставят декодер Рида-Соломона, исправляющий ошибки в символах по 8 бит. Ему такие барсты не очень страшны. Если на выходе стоит кодер, чувствительный к барстам ошибок (например, исправляющей способности не хватает, чтобы исправлять барсты, но хватает, чтобы исправлять в среднем), то хорошо бы между кодерами поставить нтерливер.

Может кто сталкивался, что бы заново велосипед не изобретать (время на тестирование не тратить). В стандарте 802.16-2012 оговорено два вида перемежителя в одном и том же RSC : 8.3 WirelessMAN-OFDM PHY и 8.4 WirelessMAN-OFDMA PHY. Не понятно следующее в OFDM параметры перемежителя заданы формулой 8.3.3.2.3.2 CTC interleave в которой по сути P[1] = 0, P[2] = P[3] = N/2, т.е. соседние пары дебитов не перемежаются (только инверсия пары) длинна пакета может быть в диапазоне 8 <= N/4 <= 1024. В OFDMA перемежитель задан таблицей и задает всего 12 режимов работы, близких к DVB.

В стандарте для OFDM и OFDMA указаны что оба работают на закрытых интервалах в диапазонах до 11 гиг. Как бы одинаковые режимы работы и используемые модуляции, тогда в связи с чем может быть связана такая свобода и простота перемежителя в OFDM ?

На сколько помню, в OFDM барсты с пользовательскими данными, которые собственно и кодируются, выровнены на OFDM символы. В OFDMA единица выделения частотно-временного ресурса для барста - слот. Т.е. по факту в OFDM возможно гораздо меньше размеров кодовых блоков.

В процессе вариации параметров декодера, обнаружил странности, вызвавшие вопросы :

1. Среди многообразия скоростей кодирования 1/3, 2/5, 1/2, 3/5, [2:9]/[3:10] работают все, кроме 7/8 (выкалываются 6 пар Y битов из семи). И это не ошибка в реализации декодера. Например беру блок 512 байт, EbNo = 5.0. Скорости 6/7, 8/9 дают нулевой выходной бер, а 7/8 всего в 2 раза меньше чем на входе. Сразу как-то вспомнилась связь цифры 7 с таблицой цикличности решетки и требования на размеры блоков. Может быть кто-то еще сталкивался с этим эффектом "пораженной скорости" и может подтвердить мои подозрения?

2. Проверяю другие модуляции, обнаружил странный эффект. Смотрю bertool, BPSK и QPSK, некодированые и витерби 1/2 с мягким решением. Кривые EbNo, в обоях случаях, ложатся один в один. Делаю BPSK с точками 1+1i,-1-1i, мягкую метрику считаю как сумму квадратур/2. Кодирование 1/3 или 1/2 и вижу результат: BPSK где-то на 0.1дб хуже. Причем это наблюдается даже на длинных прогонах (~10^6) бит, т.е. не похоже на влияние разного ансамбля шумовых отсчетов. Но ведь так не бывает. Или это фича декодера заточенного под обработку символов состоящих из двух бит одного символа радиоканала(QPSK,QAM16,QAM64), а не символа составленного двух разных символов радиоканала(BPSK, 8PSK, QAM32)?

На счет 1 - расскажи подробнее про паттерн выкалывания - стоит проверить, остаются ли вообще проверочные биты каждого из кодеров после выкалывания. Сам понимаешь, если остаются только проверочные биты одного из кодеров, турбо-балалайка работать не будет.

На счет 2 - учел, что твоя BPSK на 3 dB мощнее по энергетике, чем bpsk в одной квадратуре? Декодеру без разницы - что BPSK, что QPSK. Какая разница, последовательно переданы два бита или параллельно. И в одном и в другом случае шум в квадратурах или последовательных отсчетах на битовой скорости независим.

Там все четко. Беру пары Y1Y0 и W1W0 (исходный код 1/3), для кодов >= 1/2 убираем W биты. Затем
1/2 - используем все Y пары,
2/3 - каждую вторую пару
3/4 - каждую третью
....
6/7 - каждую шестую
7/8 - каждую седьмую
8/9 - каждую восьмую.
Т.е. все условия для турбирования выполнены Пробовал двигать начальную точку выкусывания бита при скорости 7/8, ничего не изменяется. Ощущение что 1 бит четности на период решетки дает "резонанс". При этом 8/9 работает


Я же строю нормированные к EbNo кривые. Сравниваю QPSK с символами 1+1i/-1+1i/1-1i/-1-1i и BPSK с символами 1+1i/-1-1i. Мощность созвездий одинакова и равна 2. EsNo для генератора шума пересчитываю по формуле EsNo = EbNo +10*log10(k*coderate). Для EbNo = 1db и coderate 1/3 для QPSK EsNo = -0.76db, BPSK EsNo = -3.77db.

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

Почитал немного про выкалывание. Действительно, лучше не использовать скорости, числитель которых равен периоду феедбэк LFSR. В спектре появляется много слов с маленьким весом.
При 7/8 длина паттерна как раз равна периоду LFSR.
Объяснение на пальцах можно почитать здесь:
http://www.argreenhouse.com/society/TaCom/papers99/18_6.pdf



Попробуй погонять floating-point модель без ограничения при квантовании на входе. Должно работать одинаково для QPSK и BPSK. Больше ничего на ум не приходит.

Спасибо за нужную литературу, вкурил и в итоге

можно использовать, но нужно уйти от простого равномерного выкалывания. Т.е. для 7/8 на группу из 49 символов нужно вместо патерна 0, 7, 14, 21, 28, 35, 42 использовать следующий паттерн 0, 8, 16, 24, 32, 40, 48. И все заработало

И судя по всему повезло что решетка с периодом простого числа (7), в противном случае, судя по статье, пришлось бы встретиться с этим эффектом раньше


Порою в эту сторону.