В модели я контролирую количество ошибок на входе и на каждой полуитерации. При входном BER в 4*10^-2, декодер выдает чистые нули после 1.5 итераций. Такой входной BER характерен Eb/No около 2дБ.
В железе ошибки появляются на 8 дБ и сам характер работы декодера напоминает работу одной итерации. Что вторая итерация, что 4-ая... особой разницы не видел +-1дБ по BER. Первая итерация раз в 10 дает результат хуже, чем остальные.
К демодулятору также вопросов не имею, так как LDPC-декодер нормально работает с ним на 2.5дБ.
Убивает то, что по одинаковым входным значениям модель и железо работают одинаково) Либо я в модели не те тесты подаю или есть какая то серьезная ошибка в архитектуре, либо пора обращаться к экстрасенсам...
Архитектура без оптимизации, в канальной памяти хранятся данные из канала, они подаются на SISO, который выдает мягкие решения. Записываем их в RAM внешней информации. После, эти же значения складываем со значениями из канальной памяти и снова подаем на SISO и т.д. Первоначально обрабатываются строки по Х, потом колонки по Y и колонки по оси Z. Далее следует новая итерация, но уже на 2-ой итерации имеем внешнюю информацию от Z. В оптимизационных архитектурах видел, что внешняя информация двух осей складывается для вычисления мягких решений по третьей. Но в данном случае не верится, что это сильно поможет делу.

Сообщение отредактировал Neznaika - Apr 21 2017, 11:32

При Eb/No около 2дБ на входе, - 0 ошибок на выходе - это нормально, так и должно быть, хотя картина неполная, желательно промерять во всем рабочем диапазоне.

Эти 8 дБ - это SNR или Eb/No и в какой точке приемного тракта измерены и при какой модуляции? у меня сложилось такое мнение, что у Вас с методикой измерения не все в порядке.

эта фраза вообще ни о чем не говорит, LDPC и демодуляторы бывают разные.

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

На первом рисунке привел диалоговое окно модели. Длина кадра 3840 бит. Видно как исправляются ошибки от оси к оси. Если брать меньшее отношение сигнал/шум, то после первой уже полуитерации по оси Х ошибок почти нет.
Что касается демодулятора, то на втором рисунке приведена BER работы LDPC-декодера по стандарту DVB-S2 с длиной блока 16200 бит. Видно, что при BPSK модуляции и кодовой скоростью 11/15 на 2.5 дБ результат его работы неплохой. О чем я заключаю, что демодулятор в полном порядке.
А измерения проводил по разному. Первоначально оценивал BER на входе BTC-декодера и видел, что при входном BER 10^-2 (около 4 дБ некодированных данных) после декодера появляются ошибки. Так же проводил контрольные измерения Eb/No c помощью вражеского модема CDM-600 на тех же настройках, не меняя параметров генератора шума. И он подтверждал мои оценки Eb/No. Вот только на 5-8 дБ он давал нули, а мой декодер на 8дБ выдавал BER=10^-7.
Сергей, спасибо, за ваши ответы) Вы меня неплохо подзарядили. Очень надеюсь, что ошибка будет найдена в скором времени... Обычно всегда находилась)

Да не за что, в принципе. Да, видно, что Ваш декодер не дотягивает до фирменного, вопрос только в том, насколько? Давайте так, хоть это и не совсем корректно: Вы можете сказать, при каком соотношении Eb/No на фирменном модеме "практически" будут отсутствовать ошибки? По характеристикам кода это должно наступить где-то в районе Eb/No > 2...2,5 dB с учетом потерь демодулятора в BPSK/QPSK режимах. Если это наступит при более высоких значениях Eb/No, то тогда к ошибкам реализации декодера добавятся еще и ошибки методики измерений.

CDM-600 работает до Eb/No=5дБ с BER=0 на BPSK 5/16. Далее у него идёт срыв синхронизации. Фактически это уже 0 дБ, так как коэффициент сжатия приводит к входному Eb/No=5-10*log(16/5). Если взять мой демодулятор и результат работы LDPC на 11/15, то демодулятор нормально работает до Eb/No=3-10*log(15/11)=1,34дБ без срывов.

Сообщение отредактировал Neznaika - Apr 24 2017, 09:58

Вы ничего не путаете, как промышленный модем в такой мощной конфигурации BPSK + FEC 1/3 работает при Eb/No>5 dB. Он без проблем должен работать при более низкой энергетике, для Eb/No>2 dB он должен выдавать практически нулевой BER. Как измеряете Eb/No?


Так и есть, модем CDM-625, режим BPSK + FEC 5/16 дает BER 1e-6 при Eb/No = 2,5 dB, полдецибела на потери реализации.

В CDM-600 есть свой измеритель Eb/No, по нему и ориентируюсь. То что модем перестаёт работать при менее 5дБ, скорей всего связано с низким уровнем сигнала, идущего от генератора шума, он самопальный и собран на аттенюаторах. Модем фиксирует входной сигнал на уровне менее -75дБм.

Понятно, так Вы ничего не добьетесь. как итог, я бы банально посоветовал отладить и промерять декодер в модели, там это делается все проще.

Так в моделе то все отлажено и работает на мой взгляд неплохо, проблема возникла в железе. Может быть вся причина в низком входном уровне сигнала, но мне банально не хватает диапазона генератора шума, чтобы обеспечить нужное отношение сигнал/шум при достаточно высоком уровне сигнала. Демодулятор работает на пределе чувствительности и может быть в этом и кроется все безобразие. Еще повожусь с измерениями, в любом случае Спасибо за поддержку)

Всем привет! Решил снова обратиться к гуру кодирования) 5/16 удалось временно победить, устранил пару ошибок в железе при работе с памятью и декодер на BPSK стал работать без ошибок до срыва синхронизации демодулятора при 5дБ, аналогично работе CDM-600. Стал копаться со скоростью 21/44 на BPSK. Длина кадра 25088 бит. Из-за того, что CDM-600 использует микросхему AHA, а в ней максимальный блок данных может быть около 4 кбит, то наши "партнеры" из Америки, решили выкрутиться и разбили 25088 бит на 7 блоков. Каждый блок состоит из 3 страниц полезной информации и 1 страницы, сформированной из предыдущих 3 путем операции XOR. Все 4 страницы кодируются 2D-кодером.
Вопрос встал, что делать с данными 4-ой страницы?..
Первоначально декодирую все 4 страницы по оси Х и Y декодером Чейза. Аналогично 3D-декодеру, по оси Z беру слова, состоящие из данных 4-х страниц: 3 бита полезной информации и 1 бит проверочный, полученный через XOR из предыдущих бит. Для параллельности процесса беру сразу несколько 4-к... В одном случае 5, в другом 6 (из-за укороченного кода по оси Y)... Провожу декодирование аналогичное декодированию по алгоритму Чейза... Нахожу позиции полезных бит с минимальными вероятностями, формирую тестовые вектора, а затем просто пересчитываю 4-ые биты. Далее вычисляю метрики и аналогично алгоритму Чейза вычисляю мягкие решения.
В результате, получаю, что декодирование по оси Z ухудшает кодовое усиление декодера. Результат декодирования только по осям X и Y заметно лучше, но BER=10^-6 на Eb/No=5дБ. Наверняка сидит что-то серьезное... но.. Что делать с осью Z?... Очевидно, что мой способ декодирования по Z дает ошибку.. Может кто знает или подскажет как использовать данные 4-ой страницы?

В очередной раз побеспокою кудесников блочного кодирования...
Уткнулся в реализацию BTC при QPSK, 3/4, совместимую с CDM-600. Нашел 30-битную метку в кадре и вычислил длину самого кадра с меткой в 4444 бит. Попытка разложить 3333/4414 на элементарные коэффициенты не приводит к положительному успеху. Может кто то занимался этой реализацией и подскажет как коллегам из Америки удалось получить этот коэффициент?

Всем спасибо) Может кому пригодится...
Параметры кода CDM-600 для TPC, QPSK 3/4:
2D-код с коэффициентами (39/46)*(57/64), 20-битная метка x"f50b8".