Packet Encoder в Gnuradio

В этой статье, мы попытаемся разобраться в логике работы блока Packet Encoder
Данный блок  обычно применяется в различных схемах передачи данных.
Итак, приступим.
Для начала создадим следующий простой граф:

packetencoder1Настроим все входы и выходы блоков использовать тип Byte, и создадим простой текстовый файл ascii_data.txt co следующим простым содержимым:
abcdefghijk1234567890
Этот файл мы будем использовать в качестве источника данных в File Source. В блоке File Sink задайте имя выходному файлу packed_data.bin

Итак, мы все настроили, запускаем граф на исполнение. Ждем немного, и останавливаем выполнение.

Теперь давайте изучим содержимое получившегося запакованного файла. Открываем терминал, и перемещаемся в каталог с нашим исходным файлом, и запакованым для дальнейшей передачи. Воспользуемся Unix командой hexdump  с ключом «-C» для того чтобы отобразить содержимое в удобном для анализа виде.

packetencoder2Мда, с первого взгляда все очень загадочно. Нигде не проглядывается последовательностей исходного файла. Но на то кодировщик и пакетный, что бы кодировать пакетами с регулярной структрой.
Взглянем еще раз повнимательнее. Похоже на то, что последовательность  байтов a4 f2 ac dd a4 e2 f2 8c  20 fc 00 09 00 09 повторяется несколько раз. Но что это?
Настало время нырнуть в глубину GnuRadio, и поглядеть что делает наш блок.
Скачаем исходный код Gnuradio, и откроем файл gnuradio/gr-digital/python/digital/packet_utils.py. Все самое интересное происходит в функции make_packet

Функиця принимает в качестве параметров блок из байт для передачи, число семплов на один символ, кол-во бит на символ, преамбулу, код доступа, булево значение для указания генерации отметок для USRP,  сдвиг для отбеливателя, включать ли отбеливатель, и генерировать ли CRC.

Далее в трех условиях проверяется состоит ли код доступа и преамбула из одних только единиц и нулей, и не превышает ли сдвиг отдбеливателя 15.

Ага, если включен подсчет CRC (а у нас он включен), то берем 5 наших байт вычисляем для них CRC и добавляем к данным. Попробуем это записать
61 62 63 64 65 + 6F 5B 4D F4

Определяем длину нашего блока данных (данные + CRC32), и сравниваем его длинну с длиной переменной random_mask_tuple  в которой хранится большая битовая маска. Если вы прокрутите вниз, к самому концу файла, то вы увидите ее содержание, и пояснение, что эти значения в маске являются выводом 15 битного LSFR.

Вот мы и добрались до сути.
В случае если включено отбеливание (а оно у нас включено) то происходит следующее:
Берем и ставим в начало преамбулу. Если она не задана, то используется предопределенное значение A4 F2.
A4 F2
Далее к преамбуле добавляем код доступа, котороый тоже если не задан, будет использован предопределенным значением AC DD A4 E2 F2 8C 20 FC
A4 F2 AC DD A4 E2 F2 8C 20 FC
Добавляем заголовок в кототором указана длина нашего пактета данных (вместе с CRC32), и смещение для отбеливания. 00 09 00 09
A4 F2 AC DD A4 E2 F2 8C 20 FC 00 09 00 09
Потом мы выполняем отбеливание. Отбеливанием тут является побайтовая операция XOR над блоком данных с CRC и равной ему по длине байтовой последовательности из random_mask_tuple (в переменной значения представлены в десятичном виде, я перевел их для удобства в шестнадцатеричную форму)
61 62 63 64 65 6F 5B 4D F4 ^  FF 3F 00 10 00 0C 00 05 C0
————————————————————————————
9E 5D 63 74 65 af 5b 48 34

И вот мы объединяем все вместе:
A4 F2 AC DD A4 E2 F2 8C 20 FC 00 09 00 09 9E 5D 63 74 65 af 5b 48 34

Ну вот. Мы получили точно такой же пакет как в сегенерированном файле.

Теперь для вас не будет загадкой работа данного блока.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">