[des00 25]

На практике это оказывается не всегда удобным и народ часто перескакивает на Es/N0, когда именно Es/N0 неизменен и интересует именно выигрыш от применения той или иной схемы в данной конкретной системе связи.

Вот как раз к такому же логическому выводу и прихожу :)

Например два графика BER от Es/N0 для BPSK и QPSK, вроде кажется, что BPSK лучше, на самом деле одинаково, да ещё и на полосе экономим в два раза в случае QPSK. SNR - самозапутывание, Eb/N0 - сразу всё ясно. ИМХО

На практике обычно речь идет об энергетике в фиксированной полосе. ИМХО пример BPSK vs QPSK мне всегда казался исключением чем правилом, если уйти на более сложные созвездия, то при фиксированном EsNo будет не все так однозначно: например QPSK с кодированием 7/8 или 8PSK с 2/3 или QAM16 с 1/2 (при прочих равных). При использовании EsNo будет однозначно понятно что будет в каждом случае, при использовании EbNo нужно будет заниматься перерасчетами

[Mogwaika 0]

Есть подозрение, что кодовую конструкцию в отрыве от сигнальной конструкции сравнивать с чем-то не стоит.

 

Лучше подскажите, пакетирование ошибок это хорошо или плохо? Т.е. на выходе кодека сатистика ошибок отличается от статистики ошибок в канале с абгш с тем же ber, и есть ошибки, которые кучкуются внутри одного кадра.

[andyp 10]

Лучше подскажите, пакетирование ошибок это хорошо или плохо? Т.е. на выходе кодека сатистика ошибок отличается от статистики ошибок в канале с абгш с тем же ber, и есть ошибки, которые кучкуются внутри одного кадра.

 

Не хорошо и не плохо. Это бывает не багом, а фичей :) Часто бывает при декодировании сверточных кодов, где ошибка в пути по решетке приводит к сразу нескольким рядом стоящим поломанным битам на выходе. Для иллюстрации - северточный код (133,171) У него 11 словам с весом d_free соответствует общий вес в 36 информационных бит. Т.е. в среднем ошибка в пути по решетке приводит к появлению 36/11 ошибочных информационных бит, стоящих близко друг от друга.

 

Именно из-за барстов ошибок на выходе сверточного кода вслед за ним ставят декодер Рида-Соломона, исправляющий ошибки в символах по 8 бит. Ему такие барсты не очень страшны. Если на выходе стоит кодер, чувствительный к барстам ошибок (например, исправляющей способности не хватает, чтобы исправлять барсты, но хватает, чтобы исправлять в среднем), то хорошо бы между кодерами поставить нтерливер.

[des00 25]

Может кто сталкивался, что бы заново велосипед не изобретать (время на тестирование не тратить). В стандарте 802.16-2012 оговорено два вида перемежителя в одном и том же RSC : 8.3 WirelessMAN-OFDM PHY и 8.4 WirelessMAN-OFDMA PHY. Не понятно следующее в OFDM параметры перемежителя заданы формулой 8.3.3.2.3.2 CTC interleave в которой по сути P[1] = 0, P[2] = P[3] = N/2, т.е. соседние пары дебитов не перемежаются (только инверсия пары) длинна пакета может быть в диапазоне 8 <= N/4 <= 1024. В OFDMA перемежитель задан таблицей и задает всего 12 режимов работы, близких к DVB.

 

В стандарте для OFDM и OFDMA указаны что оба работают на закрытых интервалах в диапазонах до 11 гиг. Как бы одинаковые режимы работы и используемые модуляции, тогда в связи с чем может быть связана такая свобода и простота перемежителя в OFDM ?

[andyp 10]

В стандарте для OFDM и OFDMA указаны что оба работают на закрытых интервалах в диапазонах до 11 гиг. Как бы одинаковые режимы работы и используемые модуляции, тогда в связи с чем может быть связана такая свобода и простота перемежителя в OFDM ?

 

На сколько помню, в OFDM барсты с пользовательскими данными, которые собственно и кодируются, выровнены на OFDM символы. В OFDMA единица выделения частотно-временного ресурса для барста - слот. Т.е. по факту в OFDM возможно гораздо меньше размеров кодовых блоков.

[des00 25]

В процессе вариации параметров декодера, обнаружил странности, вызвавшие вопросы :

 

1. Среди многообразия скоростей кодирования 1/3, 2/5, 1/2, 3/5, [2:9]/[3:10] работают все, кроме 7/8 (выкалываются 6 пар Y битов из семи). И это не ошибка в реализации декодера. Например беру блок 512 байт, EbNo = 5.0. Скорости 6/7, 8/9 дают нулевой выходной бер, а 7/8 всего в 2 раза меньше чем на входе. Сразу как-то вспомнилась связь цифры 7 с таблицой цикличности решетки и требования на размеры блоков. Может быть кто-то еще сталкивался с этим эффектом "пораженной скорости" и может подтвердить мои подозрения?

 

2. Проверяю другие модуляции, обнаружил странный эффект. Смотрю bertool, BPSK и QPSK, некодированые и витерби 1/2 с мягким решением. Кривые EbNo, в обоях случаях, ложатся один в один. Делаю BPSK с точками 1+1i,-1-1i, мягкую метрику считаю как сумму квадратур/2. Кодирование 1/3 или 1/2 и вижу результат: BPSK где-то на 0.1дб хуже. Причем это наблюдается даже на длинных прогонах (~10^6) бит, т.е. не похоже на влияние разного ансамбля шумовых отсчетов. Но ведь так не бывает. Или это фича декодера заточенного под обработку символов состоящих из двух бит одного символа радиоканала(QPSK,QAM16,QAM64), а не символа составленного двух разных символов радиоканала(BPSK, 8PSK, QAM32)?

[andyp 10]

На счет 1 - расскажи подробнее про паттерн выкалывания - стоит проверить, остаются ли вообще проверочные биты каждого из кодеров после выкалывания. Сам понимаешь, если остаются только проверочные биты одного из кодеров, турбо-балалайка работать не будет.

 

На счет 2 - учел, что твоя BPSK на 3 dB мощнее по энергетике, чем bpsk в одной квадратуре? Декодеру без разницы - что BPSK, что QPSK. Какая разница, последовательно переданы два бита или параллельно. И в одном и в другом случае шум в квадратурах или последовательных отсчетах на битовой скорости независим.

Изменено 7 марта, 2015 пользователем andyp

[des00 25]

На счет 1 - расскажи подробнее про паттерн выкалывания - стоит проверить, остаются ли вообще проверочные биты каждого из кодеров после выкалывания. Сам понимаешь, если остаются только проверочные биты одного из кодеров, турбо-балалайка работать не будет.

Там все четко. Беру пары Y1Y0 и W1W0 (исходный код 1/3), для кодов >= 1/2 убираем W биты. Затем

1/2 - используем все Y пары,

2/3 - каждую вторую пару

3/4 - каждую третью

....

6/7 - каждую шестую

7/8 - каждую седьмую

8/9 - каждую восьмую.

Т.е. все условия для турбирования выполнены :) Пробовал двигать начальную точку выкусывания бита при скорости 7/8, ничего не изменяется. Ощущение что 1 бит четности на период решетки дает "резонанс". При этом 8/9 работает :)

 

На счет 2 - учел, что твоя BPSK на 3 dB мощнее по энергетике, чем bpsk в одной квадратуре?

Я же строю нормированные к EbNo кривые. Сравниваю QPSK с символами 1+1i/-1+1i/1-1i/-1-1i и BPSK с символами 1+1i/-1-1i. Мощность созвездий одинакова и равна 2. EsNo для генератора шума пересчитываю по формуле EsNo = EbNo +10*log10(k*coderate). Для EbNo = 1db и coderate 1/3 для QPSK EsNo = -0.76db, BPSK EsNo = -3.77db.

Декодеру без разницы - что BPSK, что QPSK. Какая разница, последовательно переданы два бита или параллельно. И в одном и в другом случае шум в квадратурах или последовательных отсчетах на битовой скорости независим.

Вот и мне так кажется, поэтому вопрос и возник, что результаты не совпадают с теорией :)

[andyp 10]

Почитал немного про выкалывание. Действительно, лучше не использовать скорости, числитель которых равен периоду феедбэк LFSR. В спектре появляется много слов с маленьким весом.

При 7/8 длина паттерна как раз равна периоду LFSR.

Объяснение на пальцах можно почитать здесь:

http://www.argreenhouse.com/society/TaCom/papers99/18_6.pdf

 

Вот и мне так кажется, поэтому вопрос и возник, что результаты не совпадают с теорией :)

 

Попробуй погонять floating-point модель без ограничения при квантовании на входе. Должно работать одинаково для QPSK и BPSK. Больше ничего на ум не приходит.

[des00 25]

Объяснение на пальцах можно почитать здесь:

Спасибо за нужную литературу, вкурил и в итоге

Действительно, лучше не использовать скорости, числитель которых равен периоду феедбэк LFSR.

можно использовать, но нужно уйти от простого равномерного выкалывания. Т.е. для 7/8 на группу из 49 символов нужно вместо патерна 0, 7, 14, 21, 28, 35, 42 использовать следующий паттерн 0, 8, 16, 24, 32, 40, 48. И все заработало :)

 

И судя по всему повезло что решетка с периодом простого числа (7), в противном случае, судя по статье, пришлось бы встретиться с этим эффектом раньше :)

 

Попробуй погонять floating-point модель без ограничения при квантовании на входе. Должно работать одинаково для QPSK и BPSK. Больше ничего на ум не приходит.

Порою в эту сторону.

[des00 25]

наткнулся в сети на вот такой документ на странице 11 приведены интересные размеры блоков кодирования, которых нет в IEEE Std 802.16-2009/2012. Причем в таблице на этой странице приведены режимы кодирования OFDM которыми даже не пахнет в стандарте. И какой то режим SC2. Прошел поиском по стандартам, тишина. Гугл на вопрос Wimax SC2 mode тоже молчит. Неужели это банальный Single Carrier ?

[andyp 10]

наткнулся в сети на вот такой документ на странице 11 приведены интересные размеры блоков кодирования, которых нет в IEEE Std 802.16-2009/2012. Причем в таблице на этой странице приведены режимы кодирования OFDM которыми даже не пахнет в стандарте. И какой то режим SC2. Прошел поиском по стандартам, тишина. Гугл на вопрос Wimax SC2 mode тоже молчит. Неужели это банальный Single Carrier ?

 

 

Документ начинается на букву С, что значит contribution для рассмотрения комитетом. Видимо, это предложение комитет по стандартизации не убедило. В стандарте вроде нет TCC для SC модуляции.

[des00 25]

Мучаю кодек в режиме wimax-ofdm и прихожу к выводу, что фраза про возможные размеры блока кодирования от 8 до 1024 байт (см. приложение), с ограничением только на кратность 7ми не соответствуют действительности. Необходимо наложить условие что размер блока должен быть кратен 4-м байтам (например делаю проверку 20/24байта работает, 21/22/23/25/26 нет). Судя по всему, используемые ими блоки явно или неявно соответствуют этому условию. Правда мне не совсем понятно что это за магическое число 32 и как оно связано с решеткой.

 

Занятная фишка в DVB/Wimax-OFDMA перемежители определены для j = 0..N-1, а вот wimax-OFDM j = 1..N (см. приложение). И пары инвертируются тоже другие. Все это в пределах одного стандарта. Забавно :)

[andyp 10]

Мучаю кодек в режиме wimax-ofdm и прихожу к выводу, что фраза про возможные размеры блока кодирования от 8 до 1024 байт (см. приложение), с ограничением только на кратность 7ми не соответствуют действительности. Необходимо наложить условие что размер блока должен быть кратен 4-м байтам (например делаю проверку 20/24байта работает, 21/22/23/25/26 нет). Судя по всему, используемые ими блоки явно или неявно соответствуют этому условию. Правда мне не совсем понятно что это за магическое число 32 и как оно связано с решеткой.

 

21 не подходит. Кратно 7. На счет остальных размеров - не знаю. В WiMAX OFDMA эти размеры не используется. Таких слотов не бывает (Писал уже, что минимальный размер кодового блока определяется слотом и всегда кратен слотам, это собственно и дает кратность 6 байтам для размеров блоков, описанных в стандарте. Минимальный слот - 48 поднесущих * 2 (QPSK) / 2 (наименьшая скорость кодера) = 6 байт)

 

В OFDM тоже узкий набор блоков используется (таблица 8-45) минимальный кодовый блок 6*Nsubch пар, но не меньше 8 байт. Nsubch = 1,2,4,8,16, т.е. 12 байт.

 

Занятная фишка в DVB/Wimax-OFDMA перемежители определены для j = 0..N-1, а вот wimax-OFDM j = 1..N (см. приложение). И пары инвертируются тоже другие. Все это в пределах одного стандарта. Забавно :)

 

Пары инвертируются одни и те же (используются инверсные условия для перестановки пар). Вот интерливеры - да, разные.

 

PS Стандарт писался с большой кровью, OFDMА здорово позже, чем OFDM. В первых версиях было полно багов.

Изменено 12 марта, 2015 пользователем andyp

[des00 25]

21 не подходит. Кратно 7. На счет остальных размеров - не знаю. В WiMAX OFDMA эти размеры не используется.....

про 21 да, написал на автомате. По остальным размерам вот характерный пример : в приложении результат сравнения блоков OFDMA 6/12/18 байт и тех же блоков OFDM (выбран лучший перемежитель) на одном и том же кодеке. Видно что если размер OFDM не кратен 4 байтам, то результаты сильно хуже OFDMA. В баги и недоработки я охотно верю, но все это осталось и в редакции 2012 года(!!!), недоработка же видна не вооруженным глазом.

 

Судя по всему, я неправильно понял смысл фразы в стандарте

For all the frame sizes, k is a multiple of 8 and N is a multiple of 4. N shall be limited to: 8 <= N/4 <= 1024

Распространив это на любые размеры произвольных данных кодирования, а она относилась к любым размерами блоков используемых в конкретном стандарте :( Эх, а так бы хотелось мягкий кодек с вариацией пакетов данных с точностью до байта в диапазоне 6-1024 (без усечения кода) :)

Пары инвертируются одни и те же (используются инверсные условия для перестановки пар). Вот интерливеры - да, разные.

Сыплю голову пеплом, по OFDMA пробежался, увидел похожесть на DVB и пропустил момент что условие другое, инвертируется другая пара чем в DVB :( А вот интерливер не просто другой, а совсем другой, в OFDMA он как в DVB и первый адрес перемежения == 1, тогда как в OFDM == P0+1

 

PS. а каким именно документом вы пользуетесь по Wimax ? у меня ieee802.16-2009 и ieee802-16-2012. Там таблицы 8-45 нет, там сквозная нумерация через весь документ.