Добрый вечер уважаемые форумчане. Возникла необходимость реализовать декодер TPC кодов. Собственно вопрос в том что есть ли алгоритм мягкого декодирования таких кодов или же только по жестким решениям??
Чтобы не плоить темы попуно хотел спросить как приемник определяет наличие в сигнале турбокода?
И можно ли определить правильную фазовую плоскость не перебирая всевозможные варианты для ФМ4 согласен их не так и много можно и перебрать но на ФМ8 можно перебирать до "бесконечности"....(имею ввиду уже демодулированый сигнал)
Заранее большое спасибо откликнувшимся.

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

да уж, вот что значит лень-матушка. на этой же странице тема недавно подымалась http://electronix.ru/forum/index.php?showtopic=29886

Эту тему я читал .... вот как разтаки из-за нее и возник вопрос о мягком декодере....тобишь есть ли мягкий декодер для кода хеминга .... TPC ведь и есть два кода хемина один по строкам другой по столбцам .... в жестком я так понимаю алгоритм таков деодирем по строкам потом по столбцам и так некоторое кол-во раз либо пока не исправм все ошибки .... при жестких выходах это синдромный декодер а вот про мягкий я увы ничего не нашел ....

Да но при фм8 этих поворотов будет 8!... а приемник хватает сигнал очень быстро ведь ....

невнимательно прочитали, там сплошь и рядом ссылки по алгоритмам мягкого декодирования.

то о чем Вы пишите и есть принципы итеративного (турбо) декодирования и совсем неважно в какой метрике вы будете работать, в хемминговой или эвклидовой, но кроме разницы в энергетическом выигрыше.



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

Мягкий декодер для кодов Хемминга есть. Почитайте про декодер Чейза (Chase)

Смысл почему я этим заинтересовался в том что думал что при мягких решениях не прийдется заниматься этим вращением повидимому этого избежать не получится =)

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

Энергетический выйгрыш то всмысле большее кол-во ошибок можно исправить???



Спасибо большое буду изучать...
Еще хотел уточнить MAP декодер применяется только для сверточных кодов??

MAP - maximum aposteriori probability кодированных (ну или информационных) бит ищет например алгоритм BCJR. Для того, чтобы он работал, ему нужна решетка. Для блочных кодов тоже можно построить решетку.

Но Вам лучше использовать модифицированный алгоритм Чейза.

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

в общем проблема решения фазовой неоднозначности никакого отношения к алгоритму декодирования не имеет !!!




а что, нельзя это делать в непрерывном режиме, без старт-стопов.


типа того.

Про фазовую неоднохначность я так и думал просто ...решил что это некий способ ее устранения =) уже понял что нет...
Без старт-стопов это всмысле записали кусок ищем там турбокод пока ищем приращивае фазу и записываем другой кусок??
И возникает вот какой вопрос в моем понимании наличие турбокода в сигнале на первом этапе мы ищем синхро-комбинацию потом дескремблируем(если там конечно есть скремблер )а потом пробуем декодировать.... так вот как в мягких решениях находить синхрокомбинацию и дескремблировать???или же это делается при жестких решениях а потом переходят к мягким?? илиже мое представление о поиске в сигнале наличия турбокода в орне не верно??

Наличие турбокода определяется по синхрокомбинации. Естественно в мягком решении синхра будет отличатся от той которая была в жестком. Как вариант записать сигнал с известными параметрами в жестком и мягком решении по отдельности, и посмотреть какая там синхра.

=) немного опоздали выше написал пдробный вопрос на эту тему

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

Дескремблер, как правило, должен стоять на выходе декодера, поэтому он уже будет работать непосредственно по битовому потоку.

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

а вообще непонятно, Вам необходимо построить автоматический классификатор турбокодов, т.е. по входному потоку определить наличие такого кода и его параметры, или же Вы строите обычный декодер, т.е. конфигурация кода известна заранее?


очень просто. старший бит каждого мягкого отсчета и будет его соотвествующим жестким решением.

про дескремблер тоже написал выше

По поиску синхры и скремблер понятно спасибо.... про то чо проверять ее наличие на нескольких кадрах и ошибки заю... там сложность возникает когда код ь большим ..TPC*K(кол-во блоков например 128*128 до следующей синхры) у них синхра почти у всех одинаковая а само К может быть очень большим...

Именно классификатор прям в точку попали =)
А декодер писать всеравно прийдется так как у некоторых турбокодов синхра одинаковая и определить какой именно это код можно только пробным декодированием иначе никакого решения роблемы не вижу.... там где ошибок будет меньше всего тот код и есть ...

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

так все-таки нужно только автоматическое определение типа турбокода или все-таки Вы строите декодер?


Про размножение ошибок все правильно, НО, как правило, в тракте декодирования сначала идет декодер, а затем уже дескремблер (аддитивный или рекурентный), но и обратная конфигурация с аддитивным дескремблером тоже применяется на практике, но реже.

Именно автоматическое определение турбокода...пока что сделал только по синхре но только синхры недостаточно.... на практике видел код в котором сначало идет скремблер потом декодер потому и спрашиваю как потом прейти к мягким решениям...
В идеале конечно хорошо бы сделать автоматическое определение а потом и декодирование по уже определенным параметрам

Помоему и аддитивный тоже размножает ошибки.... а самосинхронизирующийся скремблер я называл мултипликативным (такое название встречал поому так и называю)

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

Впринципе в голове что-то начинает проесняться спасибо всем огромное ...напследок не подскажите где можно более подробно почитать про мягкие решения??

Оффтоп... Serg76 а вы случаем не из Курска??

ссылки выше давал. нет, не оттуда. а что там в Курске?

Ок буду более подробно штудировать ту тему...
Я там живу =) думал может пивом угостил бы ...

Как в литературе называются алгоритмы получения значений мягких решений по принятым I и Q? Единственное место где видел - даташит AHA для QAM. Это ведь наверняка не единственный способ и есть другие. Спрашиваю, потому что необходимо выбрать оптимальный с тчк зрения быстродействия для модуляции APSK и это приминительно к турбо и LDPC кодам.

http://ieeexplore.ieee.org/xpl/login.jsp?t...umber%3D5423908

Походу сам алгоритм так и называется, другого названия не встречал, можно назвать его расщепителем квадратур. По другому реализовать его тоже не получиться, а вот по-быстрее сделать можно, если рассчитать соответствующий от вида модуляции LUT

Спасибо, очень помогло

Мягкое решение, это которое log-likelihood ratio (LLR)?
Аддитивный дескремблер должен работать как-то типа умножать llr на +1 или -1 вместо xor.

LLR - логарифмическое отношение правдоподобия, вычисляется для каждого бита символа на основании принятой пары I/Q квадратурных составляющих для определенной сигнальной конструкции (constellation). с алгеброй логарифмов в качестве метрики работать проще, чем с линейной.

если стоит перед декодером, то да. если после декодера, то обработка уже битовая, базовая операция - xor.