Гексагональный и круглый QAM, Вопросы использования(+) Опции

[des00]

Доброго дня!

Заинтересовался вопросом "скругления" квадратных созвездий, аналогично MIL-STD-188-110B или DVB-S2X. Вопросы реализации пока отложим, интересна теория.

1. В матлабе сделал измеритель не кодированного BER для QAM16 (в качестве эталонного) и QAM16 из 188-110B (по сути 16APSK с поворотом внешних точек на 15 градусов). И вижу что круглое созвездие проигрывает квадратному порядка 1дб на 1е-6. Связываю это с тем, что при нормировке мощности созвездия, мощность внутренних точек меньше чем в квадратном QAM. Небольшая коррекция амплитуды внутренних точек нивелирует проигрыш. Возможно дело в используемом кодере, но судя по статье 16apsk проигрывает 16qam.

Вопрос собственно вот в чем. Пикфактор 16апск на ~2дб лучше чем 16кам. Какой тогда смысл увеличить мощность излучения на 2дб, но ухудшить чутье на 1 дб? Вытягивание последних соков ?

2. Эксперимент с ручной коррекцией точек созвездия, подтолкнул к следующему вопросу: при создании созвездия, каким критерием руководствоваться: 1)одинаковым евклидовым расстоянием точки до соседей; 2)минимальным количеством используемых амплитуд; 3)простотой мапера, демапера, блока расчета метрик?

3. Оптимальным по расстоянию является гексагональный QAM. Не натыкался ли кто в сети, на работы по исследованию пикфактора этого созвездия и кривых BER? Интересуют QAM до 2К.

Спасибо.

Эскизы прикрепленных изображений

 

[des00]

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

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

Эскизы прикрепленных изображений

 

[petrov]

Попробовал иерархическое кодирование...А в этом, что-то есть.

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