Перейти к содержанию
    

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

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

240px-Equilateral_Triangle_Lattice_3-color.svg.png

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Это созвездие на 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К, требования к подавлению ФШ, я так понимаю, заметно подрастут.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

 

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

с 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дб. Шило на мыло.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Без модели нелинейного усилителя и оценки 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. Слева нелинейное созвездие. Справа линейное

post-3453-1464165757_thumb.png

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...