Уважаемые друзья!
https://habr.com/ru/articles/538870/
Можете прояснить вопрос.
Итак имеем:
некий набор байтов - соответственно сделали кодировку. Получили другой набор байтов, чтобы потом можно было бы исправить потерянные байты. Теория подсказывает какое количество байт на приёме может быть сбойным для конкретного избыточного кодирования.
Вопрос следующий:
как понимается, что конкретный байт принят с ошибкой на приёме. Если на физическом уровне данный байт не принят в силу каких-то обстоятельств, то я так понимаю он будет отмаркирован (как- не понятно), если он всё-таки принят но есть ошибка, как система далее понимает, что есть ошибка (СRC - код?).
Но ошибка может быть и в CRC коде на приёме.
Далее аналогично, ошибка может быть как массиве данных, так и в массиве где хранится избыточный код.
Вот собственно вопрос.
Заранее спасибо за ответ.
С уважением Алексей.

alexast23
там не вопрос, будет ли принят или нет. Не принятый бит будет приравнен одному из состояний - 0 или 1. То есть, это не пробел, а ошибка и поэтому можно применить "тупой" алгоритм.

Спасибо за ответ.
Итак в случае сбойного принятия устанавливается (видимо исходя из наибольшей достоверности - вероятию) 1 или 0. Но остаётся всё-таки вопрос:
что там для какого-то блока применяется СRC код при помощи которого можно тоже что-то подправить. Что если ошибка в CRC коде как и защитном кодировании? Всё отбрасываем и далее требуется ретрансляция - о чём должна быть проинформирована передающая сторона?

Может быть не совсем чётко поставил вопрос, тогда так:
ошибка может пролезть куда угодно. Но в случае кодировки Ридом-Соломоном предполагается наличие ошибки (которая и исправляется) только в "полезной нагрузки" - или это не так и значит я неправильно понимаю суть кодирования?
Заранее спасибо за наставление на путь истинный.
С уважением Алексей.

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

spbtvmaster
CRC позволяет лишь обнаружить ошибку.
Зависит от длины защищаемого блока + длины самого CRC. Если для каждого бита при этом существует свой уникальный остаток от деления на порождающий полином, то можно и корректировать.

spbtvmaster и abrados, спасибо за ответ. Т.е. в случае обнаружение ошибки по CRC только повторная ретрансляция. Понятно. Возвращаемся к Риду-Соломону. Первое: принимается решение, что есть ошибка. Если ошибки нет в в защитном интервале - начинаем исправлять. Опять же если побито значительно больше чем этот код может исправить - запрос на ретрансляцию. Вопрос - ошибка в самом защитном интервале. Как понимается, что она там есть и что будет далее.

alexast23
Уважаемые друзья!
Вам уже советовали читать книги, а не помойки, ориентированные на поколение ЕГЭ, иначе в голове так и останется помойка.
По кодированию классика - Блейхут P. Теория и практика кодов, контролирующих ошибки: Пер. с англ. — М.: Мир, 1986. — 576 с, ил.

В качестве вводного курса это крутовато.

Предлагаю попроще.

Аршинов, Садовский. Коды и математика.

Вопрос - ошибка в самом защитном интервале. Как понимается, что она там есть

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

Давным-давно, нам вначале рассказали про продольный и попречный контроль, а потом про коды с исправлением ошибок. Акцентировали на кодах Грея. Тогда их применяли в машинах. Может эта инфа поможет спрашивающему.
Это было у нас( у меня) на 3-м курсе. 45 лет назад..

Дорогие коллеги!
Всем преогромнейшее спасибо за рекомендации и ответы.
В реальности ответ в конце концов прозвучал:
"CRC блока охватывает и сами данные , и избыточные данные. Поэтому если повредились избыточные данные , (или даже если исказились данные самого поля CRC) , то CRC во всех этих случаях не сойдётся и принятый блок будет считаться недостоверным, ну, а дальше сторонами будут предприняты действия, которые в этой ситуации предусмотрены."
Но параллельно я получил ответ из другого источника.
Давайте подытожу.
Итак:
у приёмной стороны после демодуляции нет полной ясности куда вкралась ошибка и характер сбой. Приёмная сторона (ПС - здесь и далее) понимает на основе CRC кода или как-то иначе, что есть ошибка. Опять же ошибка может быть и в самом CRC коде, но повторюсь ясности для ПС в этом вопросе нет.
Следующий шаг ПС идёт попытка исправить при помощи блочного декодирования (с нашем случае это коды Рида Соломона). Вариантов два:
1. Положительный - исправлено. Пошло выше в работу.
2. Не исправлено в силу многих причин (большое количество сбоев и т.п.). Фиксируется и уже более высокими уровнями отрабатывается. При этом если это что-то типа потокового видео - не страшно. Просто игнор. На картинке в случае большого количества сбоев картинка будет в конце концов рассыпаться. Решение - добиваться улучшений в работе канала. Это уже тема другого разговора. В случае передачи ПО, где это недопустимо - повторные ретрансмиссии, запросы. Но это уже решения других уровней.
Ну вот вкратце так.
За книги большое спасибо.
Ещё. В принципе коды Рдиа Соломона сводятся к простой вещи. Это уравнение с неизвестным (с случае сбоя). А вот уже далее по характеру сбой и количеству ошибок возникает понимание - решается это уравнение или нет. Вот и всё.
Всем спасибо.
С уважением Алексей.
Тему можно закрывать.

я бы тоже хотел задать вопрос, может, кто знает ответ.

Если передаваемые данные подвергаются шифрованию, то вначале шифрование, потом избыточное кодирование или наоборот?

Я знаю по GSM - шифрование после кодирования. Но как всегда (принцип классической русской медицинской школы) всё индивидуально. Как я понимаю всё делается по разному в разных системах. Шифрование может применять и до и после.

alexast23
если это что-то типа потокового видео - не страшно. Просто игнор.

Для потоковых данных аудио/видео критичным является общая скорость потока. Задержки должны быть или минимальны, а если трансляция в реальном времени они просто недопустимы. Например, при чтении данных с CD диска, то при появлении ошибки про CRC там просто выставляется флаг ошибки (их два), который или игнорируется или подменяется соседним отсчётом (маскировка) или если совсем плохо - появляются щелчки.
На исправление и пере передачу блока данных чтение сбойной дорожки заново просто нет времени. Также и для видео потока используют маскировку или подмену данных, иногда снижение разрешения, а если уже совсем плохо, то, да, картинка рассыпается. Но, от это тоже научились маскировать, включают таблицу или mute.
Методы исправления тоже существуют, но в реальности их используют для случаев когда это крайне необходимо, например, передача данных со спутника - дальний космос. Если канал транспорта данных избыточно мощный и время не критично, там просто данные перемешивают и передают с большой избыточностью, позволяющей обнаружить ошибку и полностью её исправить за счёт избыточности, двойной, тройной передачи. Примерно, так.
Вообще, тема интересная.

Тему можно было бы и назвать способы устранения ошибок при воздействии помех в канале. А вообще, конечно же, спасибо всем. Можно посмотреть как уже это всё реализовано в системах. Отталкиваться от того, что уже работает с приемлемым уровнем. Есть документация. Можно её изучить.