есть Fast Chase с частичным перебором, он субоптимальный (проигрыш в районе 0.5 дБ)

я в свое время не осилил

понятно, пойдем другим путем

У меня мысль появилась. Ведь в 2D матрице легко вычислить координаты ошибки. И если уж после нескольких итераций ошибки уже не исправляются, то подставить парочку раз рандомное число. Так хоть все перебирать не придется.

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

Сообщение отредактировал a9d - Jan 27 2013, 14:36

все уже украдено для нас

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

Это естественно.

Но если ошибки перестали исправляться. Т.е. пакет сильно поврежден.

PS: Ничего хорошего из добавления списка не вышло. Это все равно, что тыкать пальцем в небо.

Сообщение отредактировал a9d - Jan 27 2013, 16:50

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

Результат. Проверял в VS2012

 BTC.zip ( 658.45 килобайт ) Кол-во скачиваний: 73




Провел испытания с рандомной генерацией пакета и ошибок. Отловил такие случаи когда количество ошибок не уменьшается, но после парочки итераций пакет восстанавливается. Надо сказать случаи не такие уж и редкие. На 300-400 пакетов 1 случай.

Сообщение отредактировал a9d - Jan 27 2013, 22:25

это как раз то, о чем я говорил

Сейчас, в моей реализации, решения принимаются жестко.

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

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

Одним словом каскад.

Все эти гибридные схемы хорошо работают при относительно высоком С/Ш, при низком
скорость резко упадет, а если еще и характеристики канала непостоянны?
поэтому я бы остановился только на мягкой схеме и постарался бы ее оптимизировать.

Я исхожу из такого понимания.

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

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

В итоге устройство будет быстро восстанавливать данные на близких и медленно на дальних.

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

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



это в каком канале (системе) рассматривается? для АБГШ все символы априори равновероятны, а мягкое декодирование (поправлюсь: мягкие решения) как раз и дает ответ на то, какой из символов наиболее достоверен.

Сообщение отредактировал Serg76 - Jan 28 2013, 10:53

Чето сомневаться начал в необходимости жестких решений. Смысла в таком каскаде особо нет((.



Я говорил чисто теоретически, в реальности наверное такого и не будет.

нет, ну почему же? просто мы не знаем Вашей ситуации, непонятно из каких соображений Вы остановили свой выбор именно на такой схеме FEC - RS TPC, может для Ваших целей стоит остановиться на более простой схеме, может быть достаточно будет даже жесткого декодирования? это исследовательская работа или реальный проект какой-то?