Помехоустойчивое кодирование, Недостатки турбокодов Опции

[Goose]

Всем доброго времени суток,
Проектирую радиоканал, выявилась такая проблема:
В качестве помехоустойчивого кода собирался использовать сверточный турбо код (готовое ip-ядро), но так как вероятность ошибки в нем заметно зависит от размера блока, то получается что для разных пакетов (разной длины) помехозащищенность будет существенно различаться. К примеру, пакет пришел, а подтверждение не придет, так как оно менее защищено в связи с самим алгоритмом (но это крайний случай, его можно и отдельно разрешить, кодируя подтверждения каким нибудь другим более крутым кодом). привожу график из документации, на который я опираюсь.
Можно конечно делать пакет из N блоков (N-любое), но так сразу падает помехоустойчивость.

Хотелось бы одинаковой помехоустойчивости для пакетов разной длины. Какие бы вы посоветовали варианты? Может быть другие помехоустойчивые коды?

[Goose]

Передумал делать постоянную длину пакета ,слишком уж большие затраты при частых маленьких пакетах.
Посоветовали посмотреть в стандарт 802.15.4, так там используется такая схема кодирования с переменной длиной пакета:
сначала Рид-соломон (K+8,K), потом сверточный код (кодовая скорость 1/2). Так у них получается итоговая кодовая скорость 0.44.
Хотелось бы понять, действительно ли здесь не существенно на помехоустойчивость влияет размер пакета (вопрос в том, не так ли как в турбокодах вероятность ошибки от длины пакета гуляет в тысячи и десятки тысяч раз)?

Эскизы прикрепленных изображений

 

[Dr.Alex]

Передумал делать постоянную длину пакета

Мда.. Столько нелепостей высказано, что не знаешь с чего начать.. :-о

1) Длина пакета определяется допустимой задержкой. Если задержка может быть бОльшей (условно), то вы просто ждёте, пока накопится информация на целый пакет, и никаких """больших затрат при частых маленьких пакетах""" не будет.

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

3) Вы как-то странно трактуете график. Разницу между кодами характеризуют вовсе не """вероятностью ошибки в 10000 раз""", а децибеллами, при которых достигается НЕОБХОДИМАЯ вероятность. В данном случае разница между кодами составляет не более 2 дб, если не брать уж совсем позорно короткие экземпляры. А это не так уж много, учитывая разницу в длине в 20 раз!!

4) Не понял, почему вы решили, что для convolutional+RS длина не имеет значения? :-))))) Это могло бы означать только одно:: код крайне плох или просто не подходит для гауссова канала.
В действительности convolutional+RS применялся в старом DVB и теперь заменён на LDPC, на чём было выиграно ~3 дБ.
Так что ваш turbo-conv точно лучше чем conv+RS, и поэтому задаваться вопросом, как на него влияет длина, вообще бессмысленно.

[Goose]

насчет вакуума понял, у меня GMSK. но графики вроде бы достаточно информативны и без модуляции.

Мда.. Столько нелепостей высказано, что не знаешь с чего начать.. :-о

1) Длина пакета определяется допустимой задержкой. Если задержка может быть бОльшей (условно), то вы просто ждёте, пока накопится информация на целый пакет, и никаких """больших затрат при частых маленьких пакетах""" не будет.

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

3) Вы как-то странно трактуете график. Разницу между кодами характеризуют вовсе не """вероятностью ошибки в 10000 раз""", а децибеллами, при которых достигается НЕОБХОДИМАЯ вероятность. В данном случае разница между кодами составляет не более 2 дб, если не брать уж совсем позорно короткие экземпляры. А это не так уж много, учитывая разницу в длине в 20 раз!!

4) Не понял, почему вы решили, что для convolutional+RS длина не имеет значения? :-))))) Это могло бы означать только одно:: код крайне плох или просто не подходит для гауссова канала.
В действительности convolutional+RS применялся в старом DVB и теперь заменён на LDPC, на чём было выиграно ~3 дБ.
Так что ваш turbo-conv точно лучше чем conv+RS, и поэтому задаваться вопросом, как на него влияет длина, вообще бессмысленно.

1) В нашем случае длина пакета влияет на занятость эфира, система с множеством пользователей и CSMA/CA. и скорости существенно отличаются (в 64 раза максимальная и минимальная), то есть крайне нежелательно например на минимальной скорости передавать 2 байтное сообщение в пакете из 256 байт, так как станции которые хотят передать 1ms сообщение наполненное информацией на большой скорости будет ждать избыточного траффика 300ms, который вообще ничего не несет, задержка важна, но не только она.
2) и приоритет тоже предполагается разный, голос и данные, голос -приоритетный.
3)давайте посчитаем. как вы говорите в 20 раз различающиеся длины пакетов: пусть 5144 и 256 бит. Учитываем, что пакет с одной ошибкой отбрасывается (необходимы только полностью корректные пакеты). К примеру по уровню Eb/N0 = 1.
а) 5144, Вероятность ошибки(график)=10^(-4)=0.0001. Вероятность успешной передачи одного бита = 0.9999. Вероятность успешно (без единой ошибки) передать все сообщение (а это 5144бит) = (0.9999)^5144 = 59.8%
б) 256, Вероятность ошибки(график)=10^(-2)=0.01. Вероятность успешной передачи одного бита = 0.99. Вероятность успешно (без единой ошибки) передать все сообщение (а это 256 бит) = (0.99)^256 = 7.6%
Это существенное различие. Или нельзя ориентироваться на такое Eb/N0. При Eb/N0=2, уже получается 93% и 99,99% - уже конечно не существенно. Но по расстоянию получается разница почти в 1,5 раза. Значит буду при получении битого пакета переходить на более низкую скорость.
4) я не решил, в этом и заключается вопрос. хотелось бы посмотреть на его характеристики. к сожалению не обладаю этими графиками. Спасибо, за помощь)




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