|
|
  |
Вопросы по итеративному декодированию, Реализация CTC/BTC/LDPC кодов |
|
|
|
Feb 24 2015, 16:29
|
Вечный ламер
     
Группа: Модераторы
Сообщений: 7 248
Регистрация: 18-03-05
Из: Томск
Пользователь №: 3 453

|
Цитата(andyp @ Feb 25 2015, 00:02)  На практике это оказывается не всегда удобным и народ часто перескакивает на Es/N0, когда именно Es/N0 неизменен и интересует именно выигрыш от применения той или иной схемы в данной конкретной системе связи. Вот как раз к такому же логическому выводу и прихожу Цитата(petrov @ Feb 25 2015, 00:02)  Например два графика 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 нужно будет заниматься перерасчетами
--------------------
|
|
|
|
|
Feb 24 2015, 17:28
|
Местный
  
Группа: Участник
Сообщений: 453
Регистрация: 23-07-08
Пользователь №: 39 163

|
Цитата(Mogwaika @ Feb 24 2015, 20:14)  Лучше подскажите, пакетирование ошибок это хорошо или плохо? Т.е. на выходе кодека сатистика ошибок отличается от статистики ошибок в канале с абгш с тем же ber, и есть ошибки, которые кучкуются внутри одного кадра. Не хорошо и не плохо. Это бывает не багом, а фичей  Часто бывает при декодировании сверточных кодов, где ошибка в пути по решетке приводит к сразу нескольким рядом стоящим поломанным битам на выходе. Для иллюстрации - северточный код (133,171) У него 11 словам с весом d_free соответствует общий вес в 36 информационных бит. Т.е. в среднем ошибка в пути по решетке приводит к появлению 36/11 ошибочных информационных бит, стоящих близко друг от друга. Именно из-за барстов ошибок на выходе сверточного кода вслед за ним ставят декодер Рида-Соломона, исправляющий ошибки в символах по 8 бит. Ему такие барсты не очень страшны. Если на выходе стоит кодер, чувствительный к барстам ошибок (например, исправляющей способности не хватает, чтобы исправлять барсты, но хватает, чтобы исправлять в среднем), то хорошо бы между кодерами поставить нтерливер.
|
|
|
|
|
Feb 25 2015, 10:02
|
Местный
  
Группа: Участник
Сообщений: 453
Регистрация: 23-07-08
Пользователь №: 39 163

|
Цитата(des00 @ Feb 25 2015, 10:47)  В стандарте для OFDM и OFDMA указаны что оба работают на закрытых интервалах в диапазонах до 11 гиг. Как бы одинаковые режимы работы и используемые модуляции, тогда в связи с чем может быть связана такая свобода и простота перемежителя в OFDM ? На сколько помню, в OFDM барсты с пользовательскими данными, которые собственно и кодируются, выровнены на OFDM символы. В OFDMA единица выделения частотно-временного ресурса для барста - слот. Т.е. по факту в OFDM возможно гораздо меньше размеров кодовых блоков.
|
|
|
|
|
Mar 7 2015, 15:33
|
Вечный ламер
     
Группа: Модераторы
Сообщений: 7 248
Регистрация: 18-03-05
Из: Томск
Пользователь №: 3 453

|
В процессе вариации параметров декодера, обнаружил странности, вызвавшие вопросы :
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)?
--------------------
|
|
|
|
|
Mar 8 2015, 07:27
|
Вечный ламер
     
Группа: Модераторы
Сообщений: 7 248
Регистрация: 18-03-05
Из: Томск
Пользователь №: 3 453

|
Цитата(andyp @ Mar 8 2015, 02:26)  На счет 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. Какая разница, последовательно переданы два бита или параллельно. И в одном и в другом случае шум в квадратурах или последовательных отсчетах на битовой скорости независим. Вот и мне так кажется, поэтому вопрос и возник, что результаты не совпадают с теорией
--------------------
|
|
|
|
|
Mar 8 2015, 09:37
|
Местный
  
Группа: Участник
Сообщений: 453
Регистрация: 23-07-08
Пользователь №: 39 163

|
Почитал немного про выкалывание. Действительно, лучше не использовать скорости, числитель которых равен периоду феедбэк LFSR. В спектре появляется много слов с маленьким весом. При 7/8 длина паттерна как раз равна периоду LFSR. Объяснение на пальцах можно почитать здесь: http://www.argreenhouse.com/society/TaCom/papers99/18_6.pdfЦитата(des00 @ Mar 8 2015, 10:27)  Вот и мне так кажется, поэтому вопрос и возник, что результаты не совпадают с теорией  Попробуй погонять floating-point модель без ограничения при квантовании на входе. Должно работать одинаково для QPSK и BPSK. Больше ничего на ум не приходит.
|
|
|
|
|
Mar 8 2015, 14:29
|
Вечный ламер
     
Группа: Модераторы
Сообщений: 7 248
Регистрация: 18-03-05
Из: Томск
Пользователь №: 3 453

|
Цитата(andyp @ Mar 8 2015, 17:37)  Объяснение на пальцах можно почитать здесь: Спасибо за нужную литературу, вкурил и в итоге Цитата Действительно, лучше не использовать скорости, числитель которых равен периоду феедбэк LFSR. можно использовать, но нужно уйти от простого равномерного выкалывания. Т.е. для 7/8 на группу из 49 символов нужно вместо патерна 0, 7, 14, 21, 28, 35, 42 использовать следующий паттерн 0, 8, 16, 24, 32, 40, 48. И все заработало И судя по всему повезло что решетка с периодом простого числа (7), в противном случае, судя по статье, пришлось бы встретиться с этим эффектом раньше Цитата Попробуй погонять floating-point модель без ограничения при квантовании на входе. Должно работать одинаково для QPSK и BPSK. Больше ничего на ум не приходит. Порою в эту сторону.
--------------------
|
|
|
|
|
Mar 11 2015, 17:54
|
Местный
  
Группа: Участник
Сообщений: 453
Регистрация: 23-07-08
Пользователь №: 39 163

|
Цитата(des00 @ Mar 11 2015, 20:24)  наткнулся в сети на вот такой документ на странице 11 приведены интересные размеры блоков кодирования, которых нет в IEEE Std 802.16-2009/2012. Причем в таблице на этой странице приведены режимы кодирования OFDM которыми даже не пахнет в стандарте. И какой то режим SC2. Прошел поиском по стандартам, тишина. Гугл на вопрос Wimax SC2 mode тоже молчит. Неужели это банальный Single Carrier ? Документ начинается на букву С, что значит contribution для рассмотрения комитетом. Видимо, это предложение комитет по стандартизации не убедило. В стандарте вроде нет TCC для SC модуляции.
|
|
|
|
|
Mar 12 2015, 11:46
|
Местный
  
Группа: Участник
Сообщений: 453
Регистрация: 23-07-08
Пользователь №: 39 163

|
Цитата(des00 @ Mar 12 2015, 13:34)  Мучаю кодек в режиме 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. В первых версиях было полно багов.
Сообщение отредактировал andyp - Mar 12 2015, 12:42
Эскизы прикрепленных изображений
|
|
|
|
|
Mar 12 2015, 15:25
|
Вечный ламер
     
Группа: Модераторы
Сообщений: 7 248
Регистрация: 18-03-05
Из: Томск
Пользователь №: 3 453

|
Цитата(andyp @ Mar 12 2015, 18:46)  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 нет, там сквозная нумерация через весь документ.
Эскизы прикрепленных изображений
--------------------
|
|
|
|
|
  |
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|