Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Алгоритм Витерби.
Форум разработчиков электроники ELECTRONIX.ru > Цифровая обработка сигналов - ЦОС (DSP) > Алгоритмы ЦОС (DSP)
Tpeck
Добрый день.
Подскажите пожалуйста, как быть.
Поток, закодирован базовым кодом (K=7; 131,171), R=1/2. (есть неопределенность по фазе, при выкалывании добавляется неопределенность начальной фазы вкалывателя)
Xilinx предлагает синхронизироваться по оценке входной вероятности ошибки, либо по частоте нормировки метрик см. прикрепленный файл.
Морелос тоже.
Однако в этом случае порог в должен быть функцией от EbN0, а этого не хочется.
Может есть какие-нибудь еще варианты синхронизации ветвей?
andyp
Цитата(Tpeck @ May 18 2016, 15:06) *
Xilinx предлагает синхронизироваться по оценке входной вероятности ошибки, либо по частоте нормировки метрик см. прикрепленный файл.



В прицепленной статье Xilinx предлагает синхронизироваться по отношению BER/Norm и показывает, что для скорости кодирования 1/2 и 3/4 может быть выбран порог, независимый от отношения Eb/N0 (см. желтые треугольники на рисунках). Для скорости 1/2 это примерно 3, для скорости 3/4 - 2 (начинает работать для BER < 0.1)
Serg76
Достаточно в качестве порога задаться только нижней границей Pb, которая будет определяться исходя из корректирующих свойств самого кода, нет смысла в функциональной зависимости от Eb/No
Tpeck
Цитата(andyp @ May 18 2016, 15:31) *
В прицепленной статье Xilinx предлагает синхронизироваться по отношению BER/Norm


Спасибо. Проглядел.
А других способов синхронизации не бывает?


Цитата(Serg76 @ May 18 2016, 15:31) *
Достаточно в качестве порога задаться только нижней границей Pb, которая будет определяться исходя из корректирующих свойств самого кода, нет смысла в функциональной зависимости от Eb/No

Смысл был, чтобы битовый поток не рвался лишний раз из-за пересинхронизации декодера, в случае если сигнал просядет. Хотя тут уже может демодулятор сорвать и тогда точно смысла не будет.
А если его жестко задать, тогда при EbN0 меньше чего-либо он никогда не засинхриться,
Спасибо.
Serg76
Цитата(Tpeck @ May 18 2016, 16:21) *
Спасибо. Проглядел.
А других способов синхронизации не бывает?



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

А смысл от такого потока, который будет "забит" сплошными ошибками, даже при условии, что демодулятор "устоит"?
andyp
Цитата(Tpeck @ May 18 2016, 16:14) *
Спасибо. Проглядел.
А других способов синхронизации не бывает?


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

Если есть возможность, можно поиспользовать Rotationally Invariant TCM
Tpeck
Цитата(Serg76 @ May 18 2016, 16:29) *
А смысл от такого потока.


Особого смысла и нету. Просто было такое желание sm.gif

Цитата(andyp @ May 18 2016, 16:42) *
Если есть возможность, можно поиспользовать Rotationally Invariant TCM


Тут такое не покатит sm.gif
Но все равно, спасибо.
des00
Цитата(Tpeck @ May 18 2016, 21:21) *
А других способов синхронизации не бывает?

преамбулу поставить ? wink.gif

Цитата(Serg76 @ May 18 2016, 21:29) *
А смысл от такого потока, который будет "забит" сплошными ошибками, даже при условии, что демодулятор "устоит"?

Не всегда нужно передать только информацию, иногда символьная/тактовая/фреймовая синхронизация тоже является информацией. Но это больше относиться к демодулятору, чем к декодеру. Хотя, кто его знает sm.gif
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.