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

Сообщение отредактировал neo-n - Sep 5 2012, 16:37

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

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

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

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

Сообщение отредактировал neo-n - Sep 5 2012, 17:20

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

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



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

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

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

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

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



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

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

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

Сообщение отредактировал andyp - Sep 5 2012, 17:45

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

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




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


типа того.

Сообщение отредактировал Serg76 - Sep 5 2012, 17:46

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

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

Сообщение отредактировал Gold777 - Sep 5 2012, 18:04

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

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

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

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

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


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

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

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

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