Преимущества использования помехоустойчивого кода в стенде «УНКС»

Продолжаем разбирать задачи, предложенные на треке «Технологии беспроводной связи» ОНТИ.

В прошлый раз мы рассмотрели, как повышает качество принятых данных хорошая программа сопровождения «радаром» «спутника». И остановились на картинке:

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

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

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

Таким образом, наша задача состоит в том, чтобы этот сигнал передать так, чтобы этот недостаток сопровождения можно было исправить.

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

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

Давайте попробуем запустить стенд. Но при этом будем использовать кодер и декодер не по умолчанию, а наши с вами кодер и декодер, которые будут использовать расширенный код Хэмминга [8, 4]. Это означает, что у нас будет 4 информационных символа и 4 контрольных, фактически объём файла увеличится в 2 раза. Но данный код позволяет обнаруживать и исправлять однократную ошибку в байте и определять в некоторых случаях возникновение двукратной ошибки.

Давайте посмотрим справится ли такой простой код Хэмминга в данном случае. Итак, загружаем новый энкодер, загружаем его на «бортовой» компьютер «спутника», компилируем программу, видим: ошибок нет, предупреждений нет, закрываем. Теперь загружаем декодер соответственно на «бортовой» компьютер «радара», проверяем, видим, что заголовок, который требуется, на месте, загружаем, компилируем, всё работает. Загрузим файл с данными. И попробуем запустить «спутник» по той же самой траектории, что и на прошлом занятии. 

Итак, первое, что делает «спутник», — выставляет себя в центр: сначала он доехал до левого концевика, потом доехал до правого концевика, встаёт в центр — начало системы координат. и дальше начинает своё движение. Как уже говорили ранее «спутник» передаёт свою координату на «радар». 

Как выглядит этот файл, давайте посмотрим. Фактически это расписание движения «спутника», по которому он движется. Первый столбик — это время в секундах, второй — это X координата, Y координата здесь не указана, потому что «спутник» движется вдоль одной проекции на ось X. Фактически он передаёт эти свои координаты.

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

Посмотрим, как выглядит закодированный сигнал. Как выглядит поступающий сигнал на вход кодера мы видели — тут вполне понятная для нас информация, мы её хорошо понимаем. А как выглядит файл, который передаётся в канале связи? 

Кстати, обратите внимание, что передаваемый закодированный файл составляет примерно 26 КБ, а входной файл примерно 13 КБ, то есть файл закрыт кодом Хэмминга [8, 4]. Посмотрим, как он устроен.

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

А как выглядит принятый сигнал, который зарегистрировал «радар». Он выглядит очень похоже, на взгляд отличить эти два сигнала очень сложно: кажется, что случайная последовательность символов и в первом, и во втором случае. Но тем не менее уже в принятом сигнале есть ошибки, с которыми мы сталкивались на прошлом занятии: те синие участки между зелёными интервалами, здесь тоже присутствуют.

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

Обратите внимание, что принятый файл, который уже прошёл декодирование, выглядит уже вполне понятно и читаемо. Это говорит о том, что кодер и декодер справились с задачей: ошибки устранены.

Давайте попробуем графически отобразить принятый файл на рисунке, с которым работаем.

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

Также когда мы смотрим на эти данные, видим, что всё в порядке: никаких пропусков больше нет. Это говорит о том, что шумы в канале были точечными, то есть в одном байте был испорчен один бит. Но часто в работе возникают блочные ошибки, то есть когда не один бит исказился, а исказилась сразу какая-то группа битов, то есть возникают двукратные, трёхкратные… многократные ошибки. Такая ситуация на практике достаточно часто наблюдается. Но если блочная ошибка проходит не так часто, то её тоже можно исправить с помощью кода Хэмминга.

Например, в блоке из восьми байт возникает двукратная ошибка, то есть два бита испорчены или три бита подряд испорчены. В этом случае можно поступить следующим образом: можно взять первый байт закодировать кодом Хэмминга, потом второй, потом третий, после чего эти блоки записать не один за другим, как делали в прошлом примере, а следующим образом: берём первый бит из первого блока, второй бит, который будем записывать, — это первый бит из второго блока, а третий бит, который будем записывать в выходной файл, — это первый бит из третьего блока. То есть получается «зебра» из блоков, мы их перемешиваем: первые три бита в выходном файле — это первые биты наших трёх блоков.

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

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

Вообще говоря, этот приём достаточно распространён и используется не только в том случае, если вы работаете с кодом Хэмминга, но и с кодом Рида-Соломона, и в случае если вы работаете с более современными кодами.

Как бывает в жизни

Итак, разбирая каким образом можно обеспечить передачу сигнала без потерь со «спутника» на «радар», мы поняли две важные вещи: первое — это необходимо использовать помехоустойчивый код, который помогал бы избавиться от однократной ошибки (в том примере который разбирали, хотя бывают и блочные ошибки); второе — это как можно точнее антенной («радаром») сопровождать источник передачи сигналов («спутник» в нашем случае). Если эти два условия выполняются, то есть хорошо сопровождаете — обеспечиваете хорошее соотношение сигнал-шум — и используете помехоустойчивый код, то получается практически безпотерьная передача данных: зелёная линия на графике — успешно принятые данные.

Задачу мы практически решили, но в жизни бывают различные сложные ситуации. Например, могут встречаться не просто блочные ошибки, а может происходить блочная потеря данных: могло возникнуть какое-то препятствие на пути распространения сигнала, либо произошла проблема с передатчиком на «спутнике», либо на «радаре», либо «радар» просто потерял из видимости «спутник». И такую ситуацию с возможной потерей данных мы сейчас рассмотрим на стенде.

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

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

У нас всё готово: есть программа управления «радаром», программа кодирования установлена на «бортовом» компьютере «спутника», программа декодирования расположена на «бортовом» компьютере «радара», и сейчас вся система в действии. Видите, что «спутник» откалибровался и пошёл по траектории, вдоль которой передаёт данные. Обратите внимание, когда «спутник» прячется за помехой, «радар» не всегда успешное его различает, поэтому в алгоритме сопровождения «спутника», который действует на «радаре», необходимо учитывать такие ситуации. То есть алгоритм должен предусматривать возможность, когда «спутник» теряется из поля зрения камеры «радара»: он не должен зависать, по-хорошему он должен переходить в поисковый режим. То есть, когда «спутник» потерян, то «радар» должен начинать его искать, но никогда не должен выключаться — никакие внештатные ситуации не должны происходить в этом случае. Поэтому это необходимо предусмотреть при разработке.

Вы видели, что когда «спутник» проходил за препятствием, то «радар» останавливался, что не очень хорошо. Теперь посмотрим что у нас с данными.

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

Чёрная линия — расчётная траектория движения «спутника», зелёные точки — это позиции «спутника», в которых были успешно переданы данные. Когда «спутник» передаёт данные, он передаёт и своё положение, на которое также действуют шумы и помехи. И мы чётко видим наличие пустых участков. Это означает, что примерно в 15 сантиметрах от центра «радар» ещё получал данные, а дальше примерно до тридцать третьего сантиметра данных не было, дальше на краю данные опять поступали, и когда «спутник» стал возвращаться, то вновь пропадает сигнал, и так далее на всех участках мы видим такие лакуны, в которых информация не была получена. Конечно, это неправильно, когда вы теряете 20–25% данных (если внимательно посмотреть на график).

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

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

Те данные, которые необходимо передать, можно, во-первых, разбить на определённые блоки. Для этого нужно разработать формат таких блоков. Как правило, такой блок состоит из заголовка, тела, которое передаётся, какой-то контрольной суммы, и окончания блока, которое легко найти в том потоке информации, который получает ваш объект. Важно также, чтобы блоки, которые передаются, были пронумерованы, когда «радар» получает такие блоки, он знает какой формат использовал «спутник», это всё должно быть согласованно. Тогда программа декодер определяет заголовок, в котором есть специальная последовательность символов (которую вы сами можете придумать), если она правильная, то далее идёт номер блока, тело, контрольная сумма, окончание блока. Если начальная последовательность, конечная последовательность, контрольные суммы совпали, то с большой долей вероятности тот блок, который был передан, правильный.

В блок можно поместить любую служебную информацию, которая поможет для решения задачи, это может быть в том числе и положение «спутника» на образующей. И когда на радаре вы будете анализировать последовательность принятых блоков, то по номерам блоков можно будет понять: все ли блоки приняты или есть пропущенные по их последовательности нумерации. И в зависимости от того, что получено можно принять решения. Для того примера, который был продемонстрирован, когда помеха статична, можно придумать решение, исходя из периодичности движения спутника, когда данные не передавались. Но, как правило, помехи ведут себя не стационарно, они  меняются со временем, и лакуны могут как-то менять свою позицию, поэтому в таких случаях предусматривают повторную передачу блоков. То есть блоки можно передавать в разных позициях в разных местах, и далее на стороне «радара» анализировать блоки и выстраивать из них ту информацию, которую хотели передать.

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

Для размышления

Поищите, какие ещё помехоустойчивые коды существуют?

Материалы

• Статья о других методах кодирования информации, которые используются в реальных задачах наиболее часто