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



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

теперь понятно) спасибо)

Делают, в различного рода адаптивных системах, где может меняться не только длина пакета (правда не в десятки раз), но модуляция и скорость кодирования. В качестве примера можно посмотреть уже упомянутые здесь стандарты широкополосной связи такие, как DVB-S2 и Comtech VersaFEC.

Спасибо, буду теперь читать

кстати, в том же самом DVB-S2 информация о типе фрейма, модуляции и кодировании передается в заголовке начала пакета

Вы кажется что-то недопоняли. В DVB код "на ходу" не меняется. Он меняется по команде с земли, если допустим условия приёма в одном из лучей резко ухудшились, ему могут скорость кода снизить. VersaFEC не знаю, но наверняка то же самое.

А Афтор хочет буквально для каждого пакета длину FEC менять. Набралось данных на длинный пакет - шлём длинный, набралось 2 байта - шлём 2 байта, а на сэкономленное время освобождаем канал.. :-)))

все верно, но тем не менее как вариант можно глянуть, вреда не будет.


ну можно и другой пример привести: если мне не изменяет память, то у Hughes в VSАТ системе используются фреймы разной длины, причем отличаются они заметно и применяется там как раз сверточный турбокод. но пакеты там, конечно, не 2 байта.

Дак дьявол в деталях. Может быть там иерархический канал, про что я сразу сказал. Но автор похоже хочет в одном канале всё гнать.
К тому же, он на короткие коды нацелился, а в том же TCC длиной 256 это ж всего ~10 байт полезная нагрузка, куда уж меньше.. :-))))

нет там никакой иерархической модуляции как, к примеру, в DVB. это Inroute каналы в TDMA режиме и полезная нагрузка в слоте там от 7 байт (считайте 112 бит кодированный слот для R=1/2) и выше, меньше не получится, потому как кроме плохой помехоустойчивости в довесок еще преамбула, постамбула, защитный интервал и т.д. короче избыточности в малых пакетах достаточно. но пример как раз неплохой, может TC пригодится.

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

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

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

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

BER одинакова, FER (PER) будет разной

P.S. имеется ввиду для одного и того же кода

С каких щей? Ведь на графиках в самом первом посте всё прекрасно видно. И для всех хороших кодов так..

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

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

"Поучайте лучше ваших паучат."