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

[Goose]

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

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

[Kluwert]

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

Вообще-то при постоянной скорости кода R и помухоустойчивость будет постоянной. Причём тут длина?

[Fat Robot]

Вообще-то при постоянной скорости кода R и помухоустойчивость будет постоянной. Причём тут длина?

т.е. от самого кода помехоустойчивость не зависит по-вашему? только от R?

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

[Dr.Alex]

т.е. от самого кода помехоустойчивость не зависит по-вашему? только от R?

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

Это всё можно было проще сказать:: с уменьшением длины кода нужно также снижать его R от исходных 1/3 до тех пор, пока его S/N не сравняется с S/N самого длинного кода.

Только вот если при переходе от 5114 к 1024 придётся снизить R всего от 0.33 до 0.3 (по моим подсчётам), то при дальнейшем укорочении R скорее всего упадёт до немыслимых низот. Считать это при мелких длинах уже бесполезно, можно только смоделировать, а так как нигде не видно графиков для ТСС с очень низким R, то это как бы намекает.... :-о