Jump to content

    

Гексагональный и круглый QAM

Recommended Posts

petrov

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

240px-Equilateral_Triangle_Lattice_3-color.svg.png

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

Share this post


Link to post
Share on other sites

_pv
Это созвездие на 16 точек содержит 4 амплитуды, уже проигрывая классическому КАМ16 (3 амплитуды) по пикфактору. Не говоря о 16APSK (2 амплитуды). Но решение интересное :)

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

ну или 3 окружности с 4+4+8.

 

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

post-3954-1463585124_thumb.png

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

 

Рассматриваю только AWGN канал, там шум - круг. ФШ, лучше заранее подавить чем потом декодером вытаскивать.

...

QAM до 2К

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

всех не передавишь :), и что-нибудь некруглое вылезет. соответственно на больших радиусах шаг сетки по углу придётся увеличить.

Share this post


Link to post
Share on other sites

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

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

 

 

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

всех не передавишь :), и что-нибудь некруглое вылезет. соответственно на больших радиусах шаг сетки по углу придётся увеличить.

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

des00

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

Share this post


Link to post
Share on other sites

ilya79
Что бы поставить точку в созвездиях 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 дБ .

Share this post


Link to post
Share on other sites

des00
Без модели нелинейного усилителя и оценки 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, т.к. можно упростить структуру сигнала для этого. Но и в квадратных эта проблема решается :)

Share this post


Link to post
Share on other sites

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. Слева нелинейное созвездие. Справа линейное

post-3453-1464165757_thumb.png

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

Share this post


Link to post
Share on other sites

des00
в идеале надо код с неравной защитой битов в соответствии с их положением в созвездии.

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.