[Serg76 0]

Кину свои несколько копеек - BTC предлагались как альтернатива для высоких (R здорово больше чем 1/2) скоростей кодирования. На сколько помню, у них проблемы когда нужна гибкость (несколько поддерживаемых одной схемой скоростей кодирования и более-менее плавное изменение размеров блока). Как по этим параметрам обстоят дела у совеременных LDPC просто не знаю.

для "гибкости" LDPC придумали так называемые F-LDPC (flexible LDPC) коды, например, смотрим стандарт 802.11n

[andyp 10]

для "гибкости" LDPC придумали так называемые F-LDPC (flexible LDPC) коды, например, смотрим стандарт 802.11n

спасибо, посмотрю.

[Serg76 0]

спасибо, посмотрю.

добавлю еще, что переход с классической каскадной схемы RSV на TPC в 90-ые состоялся из-за более "мощных" характеристик помехоустойчивости последних, да к тому же и необходимую скорость кодирования на них получить не представляется никакого труда (2D/3D, hyperaxis, добавление компонентных кодов четности, выкалывание и др.). кроме того вычислительная сложность субоптимальных алгоритмов декодирования TPC невелика, чего не скажешь об LDPC (которые были известны еще до появления TPC), особенно, с длинным фреймом (как, например, DVB-S2), для которых только недавно (последнее десятилетие, наверное) стало возможным реализовать алгоритмы декодирования с помощью современных СБИС.

[andyp 10]

почитал это про F-LDPC. Выглядит впечатляюще. Очень интересно для систем с ARQ.

[des00 25]

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

а можете поделиться материалами или ссылками на материалы по этим алгоритмам ? Спасибо

[Maverick_ 15]

а можете поделиться материалами или ссылками на материалы по этим алгоритмам ? Спасибо

вот то что я "нарыл" (некоторыми материалами поделился andyp)

[Serg76 0]

а можете поделиться материалами или ссылками на материалы по этим алгоритмам ? Спасибо

в принципе тема не нова и неоднократно здесь обсуждалась. в основном в качестве алгоритма декодирования используются различного рода вариации алгоритма Чейза (метод 2), дает довольно неплохие результаты, баловался также лет 6-7 назад различными аппроксимациями MAP, но это довольно тяжелый алгоритм, можно попробовать также мажоритарное декодирование, должно получиться быстро, но я не пробовал ))). а сам декодер по Чейзу я делал по книге Кларка "Кодирование с исправлением ошибок в системах цифровой связи", мне кажется одна из лучших книг по кодированию во все времена. все, что нашел по декодированию TPC кинул Вам в личку, может что полезное найдете.

[Maverick_ 15]

в принципе тема не нова и неоднократно здесь обсуждалась. в основном в качестве алгоритма декодирования используются различного рода вариации алгоритма Чейза (метод 2), дает довольно неплохие результаты, баловался также лет 6-7 назад различными аппроксимациями MAP, но это довольно тяжелый алгоритм, можно попробовать также мажоритарное декодирование, должно получиться быстро, но я не пробовал ))). а сам декодер по Чейзу я делал по книге Кларка "Кодирование с исправлением ошибок в системах цифровой связи", мне кажется одна из лучших книг по кодированию во все времена. все, что нашел по декодированию TPC кинул Вам в личку, может что полезное найдете.

а со мной поделиться можете?

[Serg76 0]

Maverick да, конечно, ссылка в личке. Кое-что выкладывал здесь, тема неоднократно подымалась, посмотрите

[Tpeck 0]

Инженер использует в своей системе связи код с R=1/4. Напоминаю, что предел Eb/No для него равен минус 0.8 дБ.

В какой-то момент выясняется, что скорость передачи данных недостаточна, и он решает просто увеличить R до 1/2 (предел Eb/No = 0.2 дБ).

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

 

4 дБ. При условии, что бодовая скорость останется прежней. А в чем подвох?

 

Вообще, нелепость Eb/No многогранна, и на ночь глядя всё не описать.

Может попробуете, если свою точку зрения за года не поменяли? :)