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

Про тернарные свёрточные коды гугл знает. Одна и та же схема для любого размера QAM. Будут потери из-за укладывания битов в триты. Сомнительно, что получитыся обыграть мощные бинарные турбо коды за счёт уменьшения пик-фактора(шестиугольник лучше круг аппроксимирует чем квадрат) и чуть более плотной двумерной решётки.

можно сделать 2 окружности с 4 и 12 точками, что собственно в первом посте и нарисовано только радиусы надо немного поменять (внутренний увеличить немного) чтобы растояния между всеми точками более менее одинаковые стали.
ну или 3 окружности с 4+4+8.

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

для треугольной сетки амплитуда получается немного больше, хотя точек влезло 18, а не 16.


подавить конечно лучше, но для больших, до 2К, требования к подавлению ФШ, я так понимаю, заметно подрастут.
всех не передавишь , и что-нибудь некруглое вылезет. соответственно на больших радиусах шаг сетки по углу придётся увеличить.

к TCM не хотелось бы скатываться. Но идея интересная.



максимальный ФШ считается, от него и танцевать. ИМХО корректировать его надо не по сетке метрик, после округления, а на полной разрядности по выходным символам демодулятора.

с 16 точками разобрались, осталось еще 7 созвездий

Интересно выглядит 18 36 72 144 288 576 1152 2304 QAM гексагональная, 3^2*2^n точек в созвездии, 2 трита переносят чуть больше 3-х бит, центральная точка не используется.

Что бы поставить точку в созвездиях MIL-STD, взял CML либу, выбрал режим WiMAX LDPC 2304 5/6 и сравнил круглые и квадратные КАМы. Проигрыш по чутью от 0.2 - 1,2 дб. При этом пик фактор, на RRC a = 0.35 дает тот же 1дб, а при a = 0.1 всего 0.5дб. Шило на мыло.

Без модели нелинейного усилителя и оценки TD (Total Degradation)= потери Eb/N0+потерии OBO, наверное не корректный вывод. Посмотрите тут http://jwcn.eurasipjournals.springeropen.c...7-1499-2012-317 Выигрыш APSK-16 относительно QAM-16 ~ (2дБ-0.6дБ)=1.4 при OBO 3 дБ (рис. 7 в статье) . Вы учитываете что оптимальное отношение радиусов колец для APSK разное для разных кодовых скоростей? В статье цифры для некодированой передачи. Применение хорошего кода снизит разницу до 0.6-0.7 дБ .

Документ этот еще в начале темы посмотрел. Отметил для себя моменты в статье: некодированный сигнал, большое скругление (0.42).
Изначально нашел вариант когда не кодированный 16APSK идет один в один с 16QAM. Но когда взял слабый LDPC код появился небольшой проигрыш. Причем, по моим измерениям, 16APSK с точками на осях, выигрывает у 16APSK с точками на линиях pi/4 (как в статье). Что в принципе очевидно. ИМХО 16APSK единственный круглый QAM, который позволяет немного отыграть/остаться при своих.

Меня интересуют высокие скорости. А это камы >64 и скругления 5-10%. На таких скруглениях выигрыш по пикфактору круглых старших камов мал и меньше проигрыша по чутью.

PS. Подозреваю что на круглых КАМ проще сделать long tail DPD, т.к. можно упростить структуру сигнала для этого. Но и в квадратных эта проблема решается

Попробовал иерархическое кодирование...А в этом, что-то есть.
Если взять QAM256 LDPC 5/6 и QAM16+0,25*QAM16 LDPC 5/6 то получается выигрыш по чутью ~0.7дб. Потом чуток читернул, сделал QAM16+0,28*QAM16 LDPC 5/6 и 1,5 дб на "ровном" месте. Правда за это надо заплатить двойным декодером(правда меньшей производительности), выравнивающим буфером, масштабирующим усилителем и более сложными LLR

PS. Слева нелинейное созвездие. Справа линейное

Для больших созвездий нет смысла все биты кодировать мягким кодом, в разбиении Унгербоека хорошо видно, что с какого-то разбиения точки в подобразе уже слишком далеко находятся, чтобы там ошибки возникали из-за АБГШ, лучше на эти точки ресурс мягкого кода не тратить, а для кодируемых подобразов использовать более низкоскоростной код.

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

И фишка еще в том, что я сам "порчу" первый слой созвездия, в пределах корректирующей способности декодера, при этом увеличиваю мощность второго слоя.

Унгербоек просто для примера, то же можно и в прагматическом подходе реализовать, скажем использовать кодирование только как для 64 QAM, а остальные точки в одномерных подобразах больших созвездий не кодировать, в идеале надо код с неравной защитой битов в соответствии с их положением в созвездии.

думал над этим, пока уперся в отсутствии разработанных, в своей библиотеке, кодов на скорости кодирования больше 8/9. Поэтому посмотрел в сторону увеличения коэффициента системы, при той же скорости