РАДИОЛЮБИТЕЛЯМ
Спутник — телескоп «УмКА" — будет выведен на орбиту 27 июня 2023 года ракетой-носителем «Союз-2.1б» с разгонным блоком Фрегат с космодрома Восточный. Спутник представляет собой кубсат формата 3U+, основными элементами полезной нагрузки являются светосильный телескоп «Лептонар-20 955К» и астрономическая цифровая камера PlayerOne Saturn-C SQR для решения учебных астрономических задач.
Основными образовательными целями является — съёмка астрономических объектов, созвездий, звёздных скоплений, а также возможность освоить управление малого космического аппарата на низкой околоземной орбите.
Дополнительные задачи миссии заключаются в съёмке объектов на орбите Земли, например, космического мусора, для его идентификации и оценки состояния; наблюдение за негативным влиянием радиации на работу полезной нагрузки спутника-телескопа и других систем спутника для последующего анализа.
В процессе нашей миссии операторы наземных приёмных комплексов средних школ, университетов, а также радиолюбители по всему миру смогут самостоятельно получить снимки, сделанные нашим космическим телескопом прямо с орбиты, посредством использования приёмного оборудования, работающего в диапазоне S,
и предоставленного программного обеспечения.
За успешный прием и декодирование телеметрии в течение двух дней предусмотрена отправка QSL карточек.
Подробное описание программы и форму заявки можете посмотреть по ссылке: https://r4uab.ru/diplomnye-programmy-i-qsl/mka-umka-1/.
Получившие снимки астрономических объектов, сделанных нашим КА «УМКА» во время эксперимента, декодировав их самостоятельно и прислав полученный снимок по e-mail radioamateurumka@school29.ru, будут поощрены за данное достижение специальным сертификатом.
Прием телеметрии
Спутник-телескоп «УмКА» имеет позывной RS40S и использует модуляцию GMSK, протокол USP, битрейт 2400 (в последующем битрейт планируется изменить на 4800 и 9600). Частота нисходящей линии связи— 437.625 МГц .
Для удобства приема телеметрии рекомендуется воспользоваться программным обеспечением сети космического мониторинга и связи «ЭФИР» (ссылка будет доступна позже).
Прием данных с ПН
Снимки астрономических объектов будут передаваться на частоте 2402 МГц в формате GPSK.
Расписание работы передатчика S диапазона будет оперативно публиковаться на следующих ресурсах:
Сайт Дмитрия Пашкова— https://r4uab.ru/
Форум «Радиолюбительские спутники»— https://forum.r4uab.ru/viewforum.php?f=11
Телеграмм канал ON AIR— https://t.me/onthe_air
Форум «Libre space»— https://community.libre.space/
Основными образовательными целями является — съёмка астрономических объектов, созвездий, звёздных скоплений, а также возможность освоить управление малого космического аппарата на низкой околоземной орбите.
Дополнительные задачи миссии заключаются в съёмке объектов на орбите Земли, например, космического мусора, для его идентификации и оценки состояния; наблюдение за негативным влиянием радиации на работу полезной нагрузки спутника-телескопа и других систем спутника для последующего анализа.
В процессе нашей миссии операторы наземных приёмных комплексов средних школ, университетов, а также радиолюбители по всему миру смогут самостоятельно получить снимки, сделанные нашим космическим телескопом прямо с орбиты, посредством использования приёмного оборудования, работающего в диапазоне S,
и предоставленного программного обеспечения.
За успешный прием и декодирование телеметрии в течение двух дней предусмотрена отправка QSL карточек.
Подробное описание программы и форму заявки можете посмотреть по ссылке: https://r4uab.ru/diplomnye-programmy-i-qsl/mka-umka-1/.
Получившие снимки астрономических объектов, сделанных нашим КА «УМКА» во время эксперимента, декодировав их самостоятельно и прислав полученный снимок по e-mail radioamateurumka@school29.ru, будут поощрены за данное достижение специальным сертификатом.
Прием телеметрии
Спутник-телескоп «УмКА» имеет позывной RS40S и использует модуляцию GMSK, протокол USP, битрейт 2400 (в последующем битрейт планируется изменить на 4800 и 9600). Частота нисходящей линии связи— 437.625 МГц .
Для удобства приема телеметрии рекомендуется воспользоваться программным обеспечением сети космического мониторинга и связи «ЭФИР» (ссылка будет доступна позже).
Прием данных с ПН
Снимки астрономических объектов будут передаваться на частоте 2402 МГц в формате GPSK.
Расписание работы передатчика S диапазона будет оперативно публиковаться на следующих ресурсах:
Сайт Дмитрия Пашкова— https://r4uab.ru/
Форум «Радиолюбительские спутники»— https://forum.r4uab.ru/viewforum.php?f=11
Телеграмм канал ON AIR— https://t.me/onthe_air
Форум «Libre space»— https://community.libre.space/
Версия документа 1.04
Протокол предназначен для использования на линиях космос—Земля и Земля—космос в системах передачи телеметрии и телекоманд (TM/TC). Протокол описывает физический и канальный уровни передачи.
Протокол в первую очередь предназначен для использования на сравнительно низкоскоростных (1200-115200 бит/с) полудуплексных каналах, учитывая потребности малых космических аппаратов на низкой околоземной орбите. Предусмотрена его реализация на устройствах, основанных на микроконтроллерах
и интегральных приёмопередатчиках общего применения.
Общие соглашения
За исключением специально оговоренных случаев, действуют следующие соглашения:
• Все поля передаются в формате MSB first, то есть старший бит передаётся первым.
• Для многобайтных полей порядок байт всегда указан в соответствующем разделе документа.
• Все битовые последовательности, упомянутые в документе, передаются слева направо.
Параметры радиосигнала
Протокол не ограничивает использование какими-либо определёнными частотами. Однако, имеются рекомендуемые конфигурации, позволяющие линии передачи соответствовать требованиям регламента любительской радиосвязи с целью использования на радиолиниях любительского диапазона частот.
В данный момент определено и рекомендовано использование GMSK – гауссовской частотной манипуляции
с минимальным сдвигом. Однако нет принципиальных ограничений, мешающих использовать другие типы манипуляции.
В случае использования частотной манипуляции нулю соответствует меньшее значение частоты, единице – большее значение.
Закрашенная часть кадра кодируется свёрточным кодом, скрэмблируется, кодируется кодом Рида-Соломона.
* Указана длина поля типа до наложения упомянутых кодов.
Преамбула
Рекомендуется использование 32-битной преамбулы из чередующихся нулей и единиц 55555555h.
Синхропоследовательность
Протокол использует 64-битную синхропоследовательность 5072F64B2D90B1F5h.
На приёмной стороне рекомендуется считать корректной последовательность, которая отличается от указанной
на 13 бит или менее. Вероятность ложной синхронизации на каждый бит при этом составляет 9,4*10-7, что при скорости 9600 бит/с даёт в среднем одну ложную синхронизацию в 109 секунд.
При применении аппаратных трансиверов, как правило, обеспечивается автоматическое детектирование максимум 32-битной последовательности. Рекомендуется в этом случае устанавливать порог в 7 допустимых ошибок, вторую часть последовательности проверять программно с тем же порогом. Вероятность ложной
синхронизации на каждый бит при этом составляет 1,1*10-6, что при скорости 9600 бит/с даёт в среднем одну ложную синхронизацию в 94 секунды.
Кривая Eb/N0 для каждого варианта приведена в разделе «Энергетические возможности протокола».
PLS-код
Непосредственно за синхропоследовательностью передаётся PLS-код (physical layer signaling). Код имеет длину 7 бит, закодирован кодом 64-7, в закодированном виде длина поля составляет 64 символа. Хэмингово расстояние кода составляет 32 бита.
Код является линейным блочным кодом со следующей порождающей матрицей:
* Указана длина поля типа до наложения упомянутых кодов.
Преамбула
Рекомендуется использование 32-битной преамбулы из чередующихся нулей и единиц 55555555h.
Синхропоследовательность
Протокол использует 64-битную синхропоследовательность 5072F64B2D90B1F5h.
На приёмной стороне рекомендуется считать корректной последовательность, которая отличается от указанной
на 13 бит или менее. Вероятность ложной синхронизации на каждый бит при этом составляет 9,4*10-7, что при скорости 9600 бит/с даёт в среднем одну ложную синхронизацию в 109 секунд.
При применении аппаратных трансиверов, как правило, обеспечивается автоматическое детектирование максимум 32-битной последовательности. Рекомендуется в этом случае устанавливать порог в 7 допустимых ошибок, вторую часть последовательности проверять программно с тем же порогом. Вероятность ложной
синхронизации на каждый бит при этом составляет 1,1*10-6, что при скорости 9600 бит/с даёт в среднем одну ложную синхронизацию в 94 секунды.
Кривая Eb/N0 для каждого варианта приведена в разделе «Энергетические возможности протокола».
PLS-код
Непосредственно за синхропоследовательностью передаётся PLS-код (physical layer signaling). Код имеет длину 7 бит, закодирован кодом 64-7, в закодированном виде длина поля составляет 64 символа. Хэмингово расстояние кода составляет 32 бита.
Код является линейным блочным кодом со следующей порождающей матрицей:
Старший бит исходного значения умножается на первую строку матрицы, младший – на последнюю, получившиеся значения суммируются по модулю 2, или, иначе говоря, выполняется операция исключающее или между всеми строками таблицы, напротив которых в кодируемом значении стоит единица.
Получившееся в итоге значение скремблируется сложением по модулю 2 (исключающим ИЛИ, XOR) с битовой последовательностью 0111000110011101100000111100100101010011010000100010110111111010
Применённый код полностью эквивалентен используемому в стандартах DVB- S2 (раздел 5.5.2) и CCSDS 131.2-B-1 (раздел 5.3.3), несмотря на другой способ определения.
PLS-код несёт информацию о типе и параметрах кодирования, размере передаваемого блока данных кода (FEC codeblock).
На данный момент реализован только один тип кодирования данных c двумя возможными размерами кодируемого блока данных:
Получившееся в итоге значение скремблируется сложением по модулю 2 (исключающим ИЛИ, XOR) с битовой последовательностью 0111000110011101100000111100100101010011010000100010110111111010
Применённый код полностью эквивалентен используемому в стандартах DVB- S2 (раздел 5.5.2) и CCSDS 131.2-B-1 (раздел 5.3.3), несмотря на другой способ определения.
PLS-код несёт информацию о типе и параметрах кодирования, размере передаваемого блока данных кода (FEC codeblock).
На данный момент реализован только один тип кодирования данных c двумя возможными размерами кодируемого блока данных:
* При использовании блока данных более короткого, чем длина блока данных кода Рида-Соломона, призводится виртуальное заполнение (см. ниже).
Все другие значения на данный момент являются зарезервированными.
Кадр данных
Далее передаётся кадр (фрейм) данных с заголовком,
на передающей стороне последовательно подвергнутый
следующим преобразованиям, соответствующим отдельным разделам CCSDS 131.0-B-3:
– Кодирование кодом Рида-Соломона.
– Скремблирование.
– Кодирование свёрточным кодом.
Свёрточный код
Используется свёрточный код, идентичный рекомендованному в книге CCSDS 131/0- B-3, пункт 3.3.1. Следует, однако, обращать внимание, что sync-последовательность, как и PLS-код, не кодируются свёрточным кодом, как рекомендует указанный документ.
Параметры кода:
тип: свёрточный код
с декодированием методом наибольшего правдоподобия;
относительная скорость кода (code rate) r=½;
память кода (constraint length) K=7 bits;
вектора соединений (connection vectors): G1 = 1111001, G2=1011011;
инверсии: инвертируется выход G2.
Схема кодера приведена на рисунке ниже (CCSDS 131.0-B-3 Figure 3-1):
Все другие значения на данный момент являются зарезервированными.
Кадр данных
Далее передаётся кадр (фрейм) данных с заголовком,
на передающей стороне последовательно подвергнутый
следующим преобразованиям, соответствующим отдельным разделам CCSDS 131.0-B-3:
– Кодирование кодом Рида-Соломона.
– Скремблирование.
– Кодирование свёрточным кодом.
Свёрточный код
Используется свёрточный код, идентичный рекомендованному в книге CCSDS 131/0- B-3, пункт 3.3.1. Следует, однако, обращать внимание, что sync-последовательность, как и PLS-код, не кодируются свёрточным кодом, как рекомендует указанный документ.
Параметры кода:
тип: свёрточный код
с декодированием методом наибольшего правдоподобия;
относительная скорость кода (code rate) r=½;
память кода (constraint length) K=7 bits;
вектора соединений (connection vectors): G1 = 1111001, G2=1011011;
инверсии: инвертируется выход G2.
Схема кодера приведена на рисунке ниже (CCSDS 131.0-B-3 Figure 3-1):
Квадраты с символом D обозначают задержку на 1 бит, сумматоры суммируют по модулю 2. Первый символ передаётся при положении переключателя 1.
Скрэмблер
Используется скрэмблер в соответствии со стандартом CCSDS 131/0-B-3 раздел 10.4.1.
Скрэмблирование осуществляется выполнением операции исключающее или (сложение по модулю 2)
с последовательностью, порождённой полиномом:
h (x) = x8 + x7 + x5 + x3 + 1
Это M-последовательность длины 255.
Первые 40 бит последовательности приведены ниже:
1111 1111 0100 1000 0000 1110 1100 0000 1001 1010 . . . .
Код Рида-Соломона
Используется код Рида-Соломона (255,223) в варианте, описанном в стандарте CCSDS 131/0-B-3, раздел 4.
Укорочение кода Рида-Соломона
В случае, если длина блока данных (фрейма с заголовком), определяемого по PLS- коду, меньше, чем длина блока данных кода, производится укорочение кода путём дополнения блока данных нулями спереди до размера блока данных кода Рида- Соломона, кодирования и удаления дополненных нулей перед скремблированием и свёрточным кодированием. На приёмной стороне перед декодированием нули вновь добавляются.
Эта процедура называется виртуальным заполнением и основана на том, что код Рида-Соломона является систематическим кодом и не изменяет блок данных при кодировании, а лишь дополняет его контрольными символами.
Укорочение кода соответствует пункту 4.3.7 CCSDS 131/0-B-3.
Скрэмблер
Используется скрэмблер в соответствии со стандартом CCSDS 131/0-B-3 раздел 10.4.1.
Скрэмблирование осуществляется выполнением операции исключающее или (сложение по модулю 2)
с последовательностью, порождённой полиномом:
h (x) = x8 + x7 + x5 + x3 + 1
Это M-последовательность длины 255.
Первые 40 бит последовательности приведены ниже:
1111 1111 0100 1000 0000 1110 1100 0000 1001 1010 . . . .
Код Рида-Соломона
Используется код Рида-Соломона (255,223) в варианте, описанном в стандарте CCSDS 131/0-B-3, раздел 4.
Укорочение кода Рида-Соломона
В случае, если длина блока данных (фрейма с заголовком), определяемого по PLS- коду, меньше, чем длина блока данных кода, производится укорочение кода путём дополнения блока данных нулями спереди до размера блока данных кода Рида- Соломона, кодирования и удаления дополненных нулей перед скремблированием и свёрточным кодированием. На приёмной стороне перед декодированием нули вновь добавляются.
Эта процедура называется виртуальным заполнением и основана на том, что код Рида-Соломона является систематическим кодом и не изменяет блок данных при кодировании, а лишь дополняет его контрольными символами.
Укорочение кода соответствует пункту 4.3.7 CCSDS 131/0-B-3.
Серым закрашена часть кодируемого блока, отбрасываемого при передаче перед скремблированием
и восстанавливаемого при приёме после дескремблирования.
В случае, если кадр данных с заголовком короче блока данных, блок также дополняется справа нулями, но они передаются обычным образом и сокращением кода это не является.
Структура кадра данных
Кадр данных в общем случае предваряется двухбайтным заголовком, состоящим из поля типа, в качестве которого используется IEEE 802.3 EtherType.
Поле длины в общем случае не предусмотрено. При добавлении энкапсуляции в USP(с выделением EtherType) протоколов, опирающихся на внешнее кадрирование, то есть не включающих в себя поле длины, может возникнуть необходимость добавления заголовка с таким поле. Рекомендуется использовать для такого поля два следующих за полем типа байта в формате little-endian. Длина должна включать в себя все данные, энкапсулированные протоколом, но не включать никаких USP- заголовков, то есть в ней считаются данные, начиная со следующего за полем длины байта.
Поле длины кодирует длину полезных данных в байтах, включая все последующие заголовки, но не включая сам заголовок фрейма.
Суммарно блок данных имеет следующий вид:
и восстанавливаемого при приёме после дескремблирования.
В случае, если кадр данных с заголовком короче блока данных, блок также дополняется справа нулями, но они передаются обычным образом и сокращением кода это не является.
Структура кадра данных
Кадр данных в общем случае предваряется двухбайтным заголовком, состоящим из поля типа, в качестве которого используется IEEE 802.3 EtherType.
Поле длины в общем случае не предусмотрено. При добавлении энкапсуляции в USP(с выделением EtherType) протоколов, опирающихся на внешнее кадрирование, то есть не включающих в себя поле длины, может возникнуть необходимость добавления заголовка с таким поле. Рекомендуется использовать для такого поля два следующих за полем типа байта в формате little-endian. Длина должна включать в себя все данные, энкапсулированные протоколом, но не включать никаких USP- заголовков, то есть в ней считаются данные, начиная со следующего за полем длины байта.
Поле длины кодирует длину полезных данных в байтах, включая все последующие заголовки, но не включая сам заголовок фрейма.
Суммарно блок данных имеет следующий вид:
Контроль целостности данных
USP не использует отдельной контрольной суммы для контроля целостности данных. Он полагается
на контроль кода Рида-Соломона, который при указанных параметрах кода обеспечивает достаточную степень проверки.
Передача AX.25 пакетов с использованием USP
Энкапсуляция протокола AX.25 выполняется аналогично, но не полностью идентично созданному для таких же целей протоколу AX.25 BPQ.
В поле EtherType в этом случае используется значение 08FFh (big-endian, FF08h в little-endian, выделен неофициально, но де-факто используется в существующих реализациях).
Перед началом заголовка AX.25 помещается значение длины, которое несёт длину пакета AX.25, включая AX.25 заголовок. Следует обратить внимание, что такое значение длины не совпадает с реализациями AX.25 BPQ для EtherNet, добавляющими дополнительные 4 байта, во избежание путаницы и проблем, порождаемых несоответствием длины.
При этом не используется HDLC-кадрирование, то есть не передаются флаги и контрольная сумма, а также
не используется bit stuffing. Задачу определения длины пакета играет длина из заголовка кадра, а контроль целостности осуществляется средствами USP.
Суммарно блок данных имеет следующий вид:
USP не использует отдельной контрольной суммы для контроля целостности данных. Он полагается
на контроль кода Рида-Соломона, который при указанных параметрах кода обеспечивает достаточную степень проверки.
Передача AX.25 пакетов с использованием USP
Энкапсуляция протокола AX.25 выполняется аналогично, но не полностью идентично созданному для таких же целей протоколу AX.25 BPQ.
В поле EtherType в этом случае используется значение 08FFh (big-endian, FF08h в little-endian, выделен неофициально, но де-факто используется в существующих реализациях).
Перед началом заголовка AX.25 помещается значение длины, которое несёт длину пакета AX.25, включая AX.25 заголовок. Следует обратить внимание, что такое значение длины не совпадает с реализациями AX.25 BPQ для EtherNet, добавляющими дополнительные 4 байта, во избежание путаницы и проблем, порождаемых несоответствием длины.
При этом не используется HDLC-кадрирование, то есть не передаются флаги и контрольная сумма, а также
не используется bit stuffing. Задачу определения длины пакета играет длина из заголовка кадра, а контроль целостности осуществляется средствами USP.
Суммарно блок данных имеет следующий вид:
*FF08h в little-endian.
**в типичном для космической телеметрии случае применения unnumbered кадров длина заголовка
составляет 16 байт. Указанное максимальное число байт данных дано именно для этого случая. При другой длине заголовка максимальный размер данных должен быть скорректирован.
Для верификации HEX-дампа пакета можно воспользоваться свободной программой Wireshark в режиме
dummy header или добавив произвольные 12 байт MAC-адресов в начале дампа.
**в типичном для космической телеметрии случае применения unnumbered кадров длина заголовка
составляет 16 байт. Указанное максимальное число байт данных дано именно для этого случая. При другой длине заголовка максимальный размер данных должен быть скорректирован.
Для верификации HEX-дампа пакета можно воспользоваться свободной программой Wireshark в режиме
dummy header или добавив произвольные 12 байт MAC-адресов в начале дампа.
Энергетические возможности протокола в виде графика Eb/N0 приведены на графике ниже. График показан в двух вариантах – при применении «мягкого» алгоритма Витерби и детектирования синхропоследовательности
с допущением 13 ошибок, и жесткого декодирования с допущением по 7 ошибок в каждой половине синхропоследовательности.
Также показан вклад отдельных составляющих – вероятности ошибки синхронизации, вероятности неправильного приёма PLS-кода
и вероятности ошибки при декодировании пакета.
Из графика видно, что при мягком декодировании при Eb/N0≈2,8 обеспечивается вероятность успешного приёма фрейма 99,9%
(т. е. PER≤0,001) для модели аддитивного Гауссова шума (AGWN).
При жестком декодировании
та же вероятность успешного приёма обеспечивается при Eb/N0≈4,1,
т. е. параметры ухудшаются примерно на 1,5 dB.
с допущением 13 ошибок, и жесткого декодирования с допущением по 7 ошибок в каждой половине синхропоследовательности.
Также показан вклад отдельных составляющих – вероятности ошибки синхронизации, вероятности неправильного приёма PLS-кода
и вероятности ошибки при декодировании пакета.
Из графика видно, что при мягком декодировании при Eb/N0≈2,8 обеспечивается вероятность успешного приёма фрейма 99,9%
(т. е. PER≤0,001) для модели аддитивного Гауссова шума (AGWN).
При жестком декодировании
та же вероятность успешного приёма обеспечивается при Eb/N0≈4,1,
т. е. параметры ухудшаются примерно на 1,5 dB.
Приложение 1. Энергетические возможности протокола
Приложение 2. Синхропоследовательность
Приложение 3. Обоснование принятых технических решений
Последовательность балансирована по числу нулей и единиц, имеет максимально 5 последовательных нуля и 5 последовательных единиц.
Последовательность оптимизирована таким образом, чтобы приемлемую автокорелляцию имела как она сама, так и её первая половина – сама по себе и с добавлением перамбулы.
График автокорелляционной функции для разных вариантов использования в пространстве растояний Хэмминга приведён на рисунке.
Последовательность оптимизирована таким образом, чтобы приемлемую автокорелляцию имела как она сама, так и её первая половина – сама по себе и с добавлением перамбулы.
График автокорелляционной функции для разных вариантов использования в пространстве растояний Хэмминга приведён на рисунке.
Обзор существующих протоколов
Перед созданием собственного протокола были проанализированы уже существующие. В частности, были рассмотрены:
• CCSDS 131/0-B-3 TM synchronisation and channel coding
• Протокол УКВ-приёмопередатчика GOMspace NanoCom U482/AX100 в режиме ASM и ASM+Golay
• Протокол УКВ-приёмопередатчика GOMspace NanoCom U482/AX100 в режиме
• Протокол аппарата AAUSAT-4
• Семейство протоколов FEC аппарата AO-40 и его модификации
Все упомянутые протоколы используют помехоустойчивое кодирование. Ниже приведено краткое описание и причины, по которым протокол не был использован без изменений.
CCSDS 131/0-B-3 TM synchronisation and channel coding
https://public.ccsds.org/Pubs/131x0b2ec1s.pdf
Этот протокол лежит в основе USP. Основная проблема при использовании в полудуплексных низкоскоростных линиях – отсутствие возможности динамически менять длину фрейма, что приводит при работе многих протоколов к неэффективному использованию канала, большому раунд-трипу и, как следствие, к замедлению передачи.
Протокол УКВ-приёмопередатчика GOMspace NanoCom U482/AX100 в режиме ASM или ASM+Golay
Этот протокол имеет поле длины, что позволяет использовать короткие пакеты, огда это требуется. Однако, он имеет и недостатки. Протокол использует sync-слово небольшой длины, а также некодированное поле длины, что ограничивает энергетику радиоканала на значениях, далёких от возможностей используемого помехоустойчивого кодирования.
Семейство протоколов FEC аппарата AO-40 и его модификации
https://www.amsat.org/articles/g3ruh/125.html
Протокол хорошо оптимизирован с точки зрения работы в условиях замираний и имеет хорошие энергетические возможности. Проблемой является также отсутствие возможности динамически менять длину фрейма.
Изменения
Версия 1.01 Первая опубликованная версия
Версия 1.02 Изменена синхропоследовательность с целью улучшения автокорелляционной функции первой её половины. Это значительно улучшило приём при использовании аппаратных трансиверов.
Версия 1.03 Ещё улучшена синхропоследовательность. Теперь она оптимизирована как по полной автокорелляции, так и по двум частичным – с преамбулой и без.
Версия 1.04 Приложения перенумерованы. Дописано обоснование принятых технических решений.
Перед созданием собственного протокола были проанализированы уже существующие. В частности, были рассмотрены:
• CCSDS 131/0-B-3 TM synchronisation and channel coding
• Протокол УКВ-приёмопередатчика GOMspace NanoCom U482/AX100 в режиме ASM и ASM+Golay
• Протокол УКВ-приёмопередатчика GOMspace NanoCom U482/AX100 в режиме
• Протокол аппарата AAUSAT-4
• Семейство протоколов FEC аппарата AO-40 и его модификации
Все упомянутые протоколы используют помехоустойчивое кодирование. Ниже приведено краткое описание и причины, по которым протокол не был использован без изменений.
CCSDS 131/0-B-3 TM synchronisation and channel coding
https://public.ccsds.org/Pubs/131x0b2ec1s.pdf
Этот протокол лежит в основе USP. Основная проблема при использовании в полудуплексных низкоскоростных линиях – отсутствие возможности динамически менять длину фрейма, что приводит при работе многих протоколов к неэффективному использованию канала, большому раунд-трипу и, как следствие, к замедлению передачи.
Протокол УКВ-приёмопередатчика GOMspace NanoCom U482/AX100 в режиме ASM или ASM+Golay
Этот протокол имеет поле длины, что позволяет использовать короткие пакеты, огда это требуется. Однако, он имеет и недостатки. Протокол использует sync-слово небольшой длины, а также некодированное поле длины, что ограничивает энергетику радиоканала на значениях, далёких от возможностей используемого помехоустойчивого кодирования.
Семейство протоколов FEC аппарата AO-40 и его модификации
https://www.amsat.org/articles/g3ruh/125.html
Протокол хорошо оптимизирован с точки зрения работы в условиях замираний и имеет хорошие энергетические возможности. Проблемой является также отсутствие возможности динамически менять длину фрейма.
Изменения
Версия 1.01 Первая опубликованная версия
Версия 1.02 Изменена синхропоследовательность с целью улучшения автокорелляционной функции первой её половины. Это значительно улучшило приём при использовании аппаратных трансиверов.
Версия 1.03 Ещё улучшена синхропоследовательность. Теперь она оптимизирована как по полной автокорелляции, так и по двум частичным – с преамбулой и без.
Версия 1.04 Приложения перенумерованы. Дописано обоснование принятых технических решений.
Описание протокола передачи данных по нисходящей линии S-диапазона МКА «УмКА-1»
1. Описание структуры сигнала
1.1 Модуляция
Для передачи данных используется двухпозиционная фазовая модуляция (BPSK). Значения фазы несущего колебания принимают только два значения: 0 и 180 градусов для передачи логического «1» и логического «0».
1.2 Символьная скорость
Символьная скорость сигнала составляет 2MS/s (2МВыб/Сек).
1.3 Частота
Частота передаваемого сигнала составляет 2402 МГц.
1.4 Используемые алгоритмы для повышения помехоустойчивости сигнала
Для защиты передаваемых данных от помех и обеспечения частых переключений модулятора между двумя возможными состояниями фазы используются: Скремблирование данных и свёрточное кодирование с относительной скоростью кодирования ½ , k=7. Порождающие полиномы: [1111001] и [1011011].
2. Структура транспортного кадра
Структура транспортного кадра опирается на рекомендации CCSDS (Международный Консультативный Комитет по космическим системам передачи данных), но имеет изменённый транспортный кадр CADU (Channel Access Data Unit).
Структура настоящего транспортного кадра (CADU):
1.1 Модуляция
Для передачи данных используется двухпозиционная фазовая модуляция (BPSK). Значения фазы несущего колебания принимают только два значения: 0 и 180 градусов для передачи логического «1» и логического «0».
1.2 Символьная скорость
Символьная скорость сигнала составляет 2MS/s (2МВыб/Сек).
1.3 Частота
Частота передаваемого сигнала составляет 2402 МГц.
1.4 Используемые алгоритмы для повышения помехоустойчивости сигнала
Для защиты передаваемых данных от помех и обеспечения частых переключений модулятора между двумя возможными состояниями фазы используются: Скремблирование данных и свёрточное кодирование с относительной скоростью кодирования ½ , k=7. Порождающие полиномы: [1111001] и [1011011].
2. Структура транспортного кадра
Структура транспортного кадра опирается на рекомендации CCSDS (Международный Консультативный Комитет по космическим системам передачи данных), но имеет изменённый транспортный кадр CADU (Channel Access Data Unit).
Структура настоящего транспортного кадра (CADU):
Общая длина транспортного кадра составляет 8192 бит.
Где:
1. ASM – Маркер синхронизации транспортного кадра (CADU). Длина: 32 бит. Значение: 0x1ACFFC1D.
2. VCID – Номер информационного канала для поля с данными. Длина: 8 бит. Возможные значения: 0x40 и 0x41.
3. Counter – Бинарный счётчик транспортных кадров (CADU) Длина: 24 бит. Возможные значения: от 0x000000 (Dec: 0) до 0xFFFFFF (DEC: 16777215).
4. Spacer 1 – Разделитель с фиксированным значением. Длина: 8 бит. Значение: 0xFF.
5. Data field – Поле с полезными данными. Длина: 8064 бит.
6. Spacer 2 - Разделитель с фиксированным значением. Длина: 8 бит. Значение: 0xEF.
7. CRC32 – Контрольная сумма CRC32, которая генерируется для поля с данными длиной 8064 бит. Длина: 32 бит.
8. Spacer 3 - Разделитель с фиксированным значением. Длина: 16 бит. Значение: 0xFFFF.
3. Рандомизация (скремблирование) данных
Иногда в данных может передаваться большое количество логических «1» или «0» подряд. Это может вызвать рассинхронизацию демодулятора. Для того, чтобы этого избежать используется рандомизация данных, то есть приведение их к псевдо-случайному виду. В настоящем протоколе используется маска ПСП, которая генерируется по полиному: h(X)=X^8+X^7+X^5+X^3+1
Схема рандомизатора данных:
Где:
1. ASM – Маркер синхронизации транспортного кадра (CADU). Длина: 32 бит. Значение: 0x1ACFFC1D.
2. VCID – Номер информационного канала для поля с данными. Длина: 8 бит. Возможные значения: 0x40 и 0x41.
3. Counter – Бинарный счётчик транспортных кадров (CADU) Длина: 24 бит. Возможные значения: от 0x000000 (Dec: 0) до 0xFFFFFF (DEC: 16777215).
4. Spacer 1 – Разделитель с фиксированным значением. Длина: 8 бит. Значение: 0xFF.
5. Data field – Поле с полезными данными. Длина: 8064 бит.
6. Spacer 2 - Разделитель с фиксированным значением. Длина: 8 бит. Значение: 0xEF.
7. CRC32 – Контрольная сумма CRC32, которая генерируется для поля с данными длиной 8064 бит. Длина: 32 бит.
8. Spacer 3 - Разделитель с фиксированным значением. Длина: 16 бит. Значение: 0xFFFF.
3. Рандомизация (скремблирование) данных
Иногда в данных может передаваться большое количество логических «1» или «0» подряд. Это может вызвать рассинхронизацию демодулятора. Для того, чтобы этого избежать используется рандомизация данных, то есть приведение их к псевдо-случайному виду. В настоящем протоколе используется маска ПСП, которая генерируется по полиному: h(X)=X^8+X^7+X^5+X^3+1
Схема рандомизатора данных:
Маска ПСП имеет длину 255 бит и далее просто повторяется. Начинается с “11111111” и оканчивается “01011000”. Для одного транспортного кадра она повторяется 32 раза. Итого 255*32=8160 бит.
На транспортные CADU данные она накладывается через блок XOR. При этом маркер ASM никак не затрагивается и сохраняется в исходном виде.
Один CADU имеет длину 8192 бит. Первые 32 бит – маркер ASM, остальные 8160 бит побитно сравниваются с маской ПСП. Так обеспечивается рандомизация данных.
4. Алгоритм генерации свёрточного кода
Свёрточный код хорошо подходит для защиты данных от ошибок в каналах с преимущественно гауссовским шумом. В настоящем протоколе используется свёрточный код с относительной скоростью кодирования ½ и длиной сдвигового регистра (k) 7. Порождающие полиномы: [1111001] и [1011011].
Схема генератора свёрточного кода:
На транспортные CADU данные она накладывается через блок XOR. При этом маркер ASM никак не затрагивается и сохраняется в исходном виде.
Один CADU имеет длину 8192 бит. Первые 32 бит – маркер ASM, остальные 8160 бит побитно сравниваются с маской ПСП. Так обеспечивается рандомизация данных.
4. Алгоритм генерации свёрточного кода
Свёрточный код хорошо подходит для защиты данных от ошибок в каналах с преимущественно гауссовским шумом. В настоящем протоколе используется свёрточный код с относительной скоростью кодирования ½ и длиной сдвигового регистра (k) 7. Порождающие полиномы: [1111001] и [1011011].
Схема генератора свёрточного кода:
Кодовое отношение составляет ½, а значит, что на каждый новый бит полезных данных, которые сдвигают регистр, приходится 2 бита на выходе C1, C2. Таким образом данных на выходе кодера становится в два раза больше, чем на входе.
Кодирование данных
Общая структура кадра
Общая структура кадра приведена на рисунке ниже
Унифицированный протокол SPUTNIX (USP)
Описание протокола
Версия документа 1.04
Протокол предназначен для использования на линиях космос—Земля и Земля—космос в системах передачи телеметрии и телекоманд (TM/TC). Протокол описывает физический и канальный уровни передачи.
Протокол в первую очередь предназначен для использования на сравнительно низкоскоростных (1200-115200 бит/с) полудуплексных каналах, учитывая потребности малых космических аппаратов на низкой околоземной орбите. Предусмотрена его реализация на устройствах, основанных на микроконтроллерах и интегральных приёмопередатчиках общего применения.
Общие соглашения
За исключением специально оговоренных случаев, действуют следующие соглашения:
• Все поля передаются в формате MSB first, то есть старший бит передаётся первым.
• Для многобайтных полей порядок байт всегда указан в соответствующем разделе документа.
• Все битовые последовательности, упомянутые в документе, передаются слева направо.
Параметры радиосигнала
Протокол не ограничивает использование какими-либо определёнными частотами. Однако, имеются рекомендуемые конфигурации, позволяющие линии передачи соответствовать требованиям регламента любительской радиосвязи с целью использования на радиолиниях любительского диапазона частот.
В данный момент определено и рекомендовано использование GMSK – гауссовской частотной манипуляции с минимальным сдвигом. Однако нет принципиальных ограничений, мешающих использовать другие типы манипуляции.
В случае использования частотной манипуляции нулю соответствует меньшее значение частоты, единице – большее значение.
Закрашенная часть кадра кодируется свёрточным кодом, скрэмблируется, кодируется кодом Рида-Соломона.
* Указана длина поля типа до наложения упомянутых кодов.
Преамбула
Рекомендуется использование 32-битной преамбулы из чередующихся нулей и единиц 55555555h.
Синхропоследовательность
Протокол использует 64-битную синхропоследовательность 5072F64B2D90B1F5h.
На приёмной стороне рекомендуется считать корректной последовательность, которая отличается от указанной на 13 бит или менее. Вероятность ложной синхронизации на каждый бит при этом составляет 9,4*10-7, что при скорости 9600 бит/с даёт в среднем одну ложную синхронизацию в 109 секунд.
При применении аппаратных трансиверов, как правило, обеспечивается автоматическое детектирование максимум 32-битной последовательности. Рекомендуется в этом случае устанавливать порог в 7 допустимых ошибок, вторую часть последовательности проверять программно с тем же порогом. Вероятность ложной
синхронизации на каждый бит при этом составляет 1,1*10-6, что при скорости 9600 бит/с даёт в среднем одну ложную синхронизацию в 94 секунды.
Кривая Eb/N0 для каждого варианта приведена в разделе «Энергетические возможности протокола».
PLS-код
Непосредственно за синхропоследовательностью передаётся PLS-код (physical layer signaling). Код имеет длину 7 бит, закодирован кодом 64-7, в закодированном виде длина поля составляет 64 символа. Хэмингово расстояние кода составляет 32 бита.
Код является линейным блочным кодом со следующей порождающей матрицей:
* Указана длина поля типа до наложения упомянутых кодов.
Преамбула
Рекомендуется использование 32-битной преамбулы из чередующихся нулей и единиц 55555555h.
Синхропоследовательность
Протокол использует 64-битную синхропоследовательность 5072F64B2D90B1F5h.
На приёмной стороне рекомендуется считать корректной последовательность, которая отличается от указанной на 13 бит или менее. Вероятность ложной синхронизации на каждый бит при этом составляет 9,4*10-7, что при скорости 9600 бит/с даёт в среднем одну ложную синхронизацию в 109 секунд.
При применении аппаратных трансиверов, как правило, обеспечивается автоматическое детектирование максимум 32-битной последовательности. Рекомендуется в этом случае устанавливать порог в 7 допустимых ошибок, вторую часть последовательности проверять программно с тем же порогом. Вероятность ложной
синхронизации на каждый бит при этом составляет 1,1*10-6, что при скорости 9600 бит/с даёт в среднем одну ложную синхронизацию в 94 секунды.
Кривая Eb/N0 для каждого варианта приведена в разделе «Энергетические возможности протокола».
PLS-код
Непосредственно за синхропоследовательностью передаётся PLS-код (physical layer signaling). Код имеет длину 7 бит, закодирован кодом 64-7, в закодированном виде длина поля составляет 64 символа. Хэмингово расстояние кода составляет 32 бита.
Код является линейным блочным кодом со следующей порождающей матрицей:
Старший бит исходного значения умножается на первую строку матрицы, младший – на последнюю, получившиеся значения суммируются по модулю 2, или, иначе говоря, выполняется операция исключающее или между всеми строками таблицы, напротив которых в кодируемом значении стоит единица.
Получившееся в итоге значение скремблируется сложением по модулю 2 (исключающим ИЛИ, XOR) с битовой последовательностью 0111000110011101100000111100100101010011010000100010110111111010
Применённый код полностью эквивалентен используемому в стандартах DVB- S2 (раздел 5.5.2) и CCSDS 131.2-B-1 (раздел 5.3.3), несмотря на другой способ определения.
PLS-код несёт информацию о типе и параметрах кодирования, размере передаваемого блока данных кода (FEC codeblock).
На данный момент реализован только один тип кодирования данных c двумя возможными размерами кодируемого блока данных:
Получившееся в итоге значение скремблируется сложением по модулю 2 (исключающим ИЛИ, XOR) с битовой последовательностью 0111000110011101100000111100100101010011010000100010110111111010
Применённый код полностью эквивалентен используемому в стандартах DVB- S2 (раздел 5.5.2) и CCSDS 131.2-B-1 (раздел 5.3.3), несмотря на другой способ определения.
PLS-код несёт информацию о типе и параметрах кодирования, размере передаваемого блока данных кода (FEC codeblock).
На данный момент реализован только один тип кодирования данных c двумя возможными размерами кодируемого блока данных:
* При использовании блока данных более короткого, чем длина блока данных кода Рида-Соломона, призводится виртуальное заполнение (см. ниже).
Все другие значения на данный момент являются зарезервированными.
Кадр данных
Далее передаётся кадр (фрейм) данных с заголовком, на передающей стороне последовательно подвергнутый следующим преобразованиям, соответствующим отдельным разделам CCSDS 131.0-B-3:
– Кодирование кодом Рида-Соломона.
– Скремблирование.
– Кодирование свёрточным кодом.
Свёрточный код
Используется свёрточный код, идентичный рекомендованному в книге CCSDS 131/0- B-3, пункт 3.3.1. Следует, однако, обращать внимание, что sync-последовательность, как и PLS-код, не кодируются свёрточным кодом, как рекомендует указанный документ.
Параметры кода:
тип: свёрточный код
с декодированием методом наибольшего правдоподобия;
относительная скорость кода (code rate) r=½;
память кода (constraint length) K=7 bits;
вектора соединений (connection vectors): G1 = 1111001, G2=1011011;
инверсии: инвертируется выход G2.
Схема кодера приведена на рисунке ниже (CCSDS 131.0-B-3 Figure 3-1):
Все другие значения на данный момент являются зарезервированными.
Кадр данных
Далее передаётся кадр (фрейм) данных с заголовком, на передающей стороне последовательно подвергнутый следующим преобразованиям, соответствующим отдельным разделам CCSDS 131.0-B-3:
– Кодирование кодом Рида-Соломона.
– Скремблирование.
– Кодирование свёрточным кодом.
Свёрточный код
Используется свёрточный код, идентичный рекомендованному в книге CCSDS 131/0- B-3, пункт 3.3.1. Следует, однако, обращать внимание, что sync-последовательность, как и PLS-код, не кодируются свёрточным кодом, как рекомендует указанный документ.
Параметры кода:
тип: свёрточный код
с декодированием методом наибольшего правдоподобия;
относительная скорость кода (code rate) r=½;
память кода (constraint length) K=7 bits;
вектора соединений (connection vectors): G1 = 1111001, G2=1011011;
инверсии: инвертируется выход G2.
Схема кодера приведена на рисунке ниже (CCSDS 131.0-B-3 Figure 3-1):
Квадраты с символом D обозначают задержку на 1 бит, сумматоры суммируют по модулю 2. Первый символ передаётся при положении переключателя 1.
Скрэмблер
Используется скрэмблер в соответствии со стандартом CCSDS 131/0-B-3 раздел 10.4.1.
Скрэмблирование осуществляется выполнением операции исключающее или (сложение по модулю 2) с последовательностью, порождённой полиномом:
h (x) = x8 + x7 + x5 + x3 + 1
Это M-последовательность длины 255.
Первые 40 бит последовательности приведены ниже:
1111 1111 0100 1000 0000 1110 1100 0000 1001 1010 . . . .
Код Рида-Соломона
Используется код Рида-Соломона (255,223) в варианте, описанном в стандарте CCSDS 131/0-B-3, раздел 4.
Укорочение кода Рида-Соломона
В случае, если длина блока данных (фрейма с заголовком), определяемого по PLS- коду, меньше, чем длина блока данных кода, производится укорочение кода путём дополнения блока данных нулями спереди до размера блока данных кода Рида- Соломона, кодирования и удаления дополненных нулей перед скремблированием
и свёрточным кодированием. На приёмной стороне перед декодированием нули вновь добавляются.
Эта процедура называется виртуальным заполнением и основана на том, что код Рида-Соломона является систематическим кодом и не изменяет блок данных при кодировании, а лишь дополняет его контрольными символами.
Укорочение кода соответствует пункту 4.3.7 CCSDS 131/0-B-3.
Скрэмблер
Используется скрэмблер в соответствии со стандартом CCSDS 131/0-B-3 раздел 10.4.1.
Скрэмблирование осуществляется выполнением операции исключающее или (сложение по модулю 2) с последовательностью, порождённой полиномом:
h (x) = x8 + x7 + x5 + x3 + 1
Это M-последовательность длины 255.
Первые 40 бит последовательности приведены ниже:
1111 1111 0100 1000 0000 1110 1100 0000 1001 1010 . . . .
Код Рида-Соломона
Используется код Рида-Соломона (255,223) в варианте, описанном в стандарте CCSDS 131/0-B-3, раздел 4.
Укорочение кода Рида-Соломона
В случае, если длина блока данных (фрейма с заголовком), определяемого по PLS- коду, меньше, чем длина блока данных кода, производится укорочение кода путём дополнения блока данных нулями спереди до размера блока данных кода Рида- Соломона, кодирования и удаления дополненных нулей перед скремблированием
и свёрточным кодированием. На приёмной стороне перед декодированием нули вновь добавляются.
Эта процедура называется виртуальным заполнением и основана на том, что код Рида-Соломона является систематическим кодом и не изменяет блок данных при кодировании, а лишь дополняет его контрольными символами.
Укорочение кода соответствует пункту 4.3.7 CCSDS 131/0-B-3.
Серым закрашена часть кодируемого блока, отбрасываемого при передаче перед скремблированием и восстанавливаемого при приёме после дескремблирования.
В случае, если кадр данных с заголовком короче блока данных, блок также дополняется справа нулями, но они передаются обычным образом и сокращением кода это
не является.
Структура кадра данных
Кадр данных в общем случае предваряется двухбайтным заголовком, состоящим из поля типа, в качестве которого используется IEEE 802.3 EtherType.
Поле длины в общем случае не предусмотрено. При добавлении энкапсуляции в USP(с выделением EtherType) протоколов, опирающихся на внешнее кадрирование, то есть
не включающих в себя поле длины, может возникнуть необходимость добавления заголовка с таким поле. Рекомендуется использовать для такого поля два следующих
за полем типа байта в формате little-endian. Длина должна включать в себя все данные, энкапсулированные протоколом, но не включать никаких USP- заголовков, то есть в ней считаются данные, начиная со следующего за полем длины байта.
Поле длины кодирует длину полезных данных в байтах, включая все последующие заголовки, но не включая сам заголовок фрейма.
Суммарно блок данных имеет следующий вид:
В случае, если кадр данных с заголовком короче блока данных, блок также дополняется справа нулями, но они передаются обычным образом и сокращением кода это
не является.
Структура кадра данных
Кадр данных в общем случае предваряется двухбайтным заголовком, состоящим из поля типа, в качестве которого используется IEEE 802.3 EtherType.
Поле длины в общем случае не предусмотрено. При добавлении энкапсуляции в USP(с выделением EtherType) протоколов, опирающихся на внешнее кадрирование, то есть
не включающих в себя поле длины, может возникнуть необходимость добавления заголовка с таким поле. Рекомендуется использовать для такого поля два следующих
за полем типа байта в формате little-endian. Длина должна включать в себя все данные, энкапсулированные протоколом, но не включать никаких USP- заголовков, то есть в ней считаются данные, начиная со следующего за полем длины байта.
Поле длины кодирует длину полезных данных в байтах, включая все последующие заголовки, но не включая сам заголовок фрейма.
Суммарно блок данных имеет следующий вид:
Контроль целостности данных
USP не использует отдельной контрольной суммы для контроля целостности данных.
Он полагается на контроль кода Рида-Соломона, который при указанных параметрах кода обеспечивает достаточную степень проверки.
Передача AX.25 пакетов с использованием USP
Энкапсуляция протокола AX.25 выполняется аналогично, но не полностью идентично созданному для таких же целей протоколу AX.25 BPQ.
В поле EtherType в этом случае используется значение 08FFh (big-endian, FF08h в little-endian, выделен неофициально, но де-факто используется в существующих реализациях).
Перед началом заголовка AX.25 помещается значение длины, которое несёт длину пакета AX.25, включая AX.25 заголовок. Следует обратить внимание, что такое значение длины
не совпадает с реализациями AX.25 BPQ для EtherNet, добавляющими дополнительные
4 байта, во избежание путаницы и проблем, порождаемых несоответствием длины.
При этом не используется HDLC-кадрирование, то есть не передаются флаги
и контрольная сумма, а также не используется bit stuffing. Задачу определения длины пакета играет длина из заголовка кадра, а контроль целостности осуществляется средствами USP.
Суммарно блок данных имеет следующий вид:
USP не использует отдельной контрольной суммы для контроля целостности данных.
Он полагается на контроль кода Рида-Соломона, который при указанных параметрах кода обеспечивает достаточную степень проверки.
Передача AX.25 пакетов с использованием USP
Энкапсуляция протокола AX.25 выполняется аналогично, но не полностью идентично созданному для таких же целей протоколу AX.25 BPQ.
В поле EtherType в этом случае используется значение 08FFh (big-endian, FF08h в little-endian, выделен неофициально, но де-факто используется в существующих реализациях).
Перед началом заголовка AX.25 помещается значение длины, которое несёт длину пакета AX.25, включая AX.25 заголовок. Следует обратить внимание, что такое значение длины
не совпадает с реализациями AX.25 BPQ для EtherNet, добавляющими дополнительные
4 байта, во избежание путаницы и проблем, порождаемых несоответствием длины.
При этом не используется HDLC-кадрирование, то есть не передаются флаги
и контрольная сумма, а также не используется bit stuffing. Задачу определения длины пакета играет длина из заголовка кадра, а контроль целостности осуществляется средствами USP.
Суммарно блок данных имеет следующий вид:
*FF08h в little-endian.
**в типичном для космической телеметрии случае применения unnumbered кадров длина заголовка составляет 16 байт. Указанное максимальное число байт данных дано именно для этого случая. При другой длине заголовка максимальный размер данных должен быть скорректирован.
Для верификации HEX-дампа пакета можно воспользоваться свободной программой Wireshark в режиме dummy header или добавив произвольные 12 байт MAC-адресов
в начале дампа.
**в типичном для космической телеметрии случае применения unnumbered кадров длина заголовка составляет 16 байт. Указанное максимальное число байт данных дано именно для этого случая. При другой длине заголовка максимальный размер данных должен быть скорректирован.
Для верификации HEX-дампа пакета можно воспользоваться свободной программой Wireshark в режиме dummy header или добавив произвольные 12 байт MAC-адресов
в начале дампа.
Энергетические возможности протокола в виде графика Eb/N0 приведены на графике ниже. График показан в двух вариантах – при применении «мягкого» алгоритма Витерби и детектирования синхропоследовательности с допущением 13 ошибок, и жесткого декодирования с допущением по 7 ошибок в каждой половине синхропоследовательности.
Также показан вклад отдельных составляющих – вероятности ошибки синхронизации, вероятности неправильного приёма PLS-кода и вероятности ошибки при декодировании пакета.
Из графика видно, что при мягком декодировании при Eb/N0≈2,8 обеспечивается вероятность успешного приёма фрейма 99,9% (т. е. PER≤0,001) для модели аддитивного Гауссова шума (AGWN).
При жестком декодировании та же вероятность успешного приёма обеспечивается при Eb/N0≈4,1, т. е. параметры ухудшаются примерно на 1,5 dB.
Также показан вклад отдельных составляющих – вероятности ошибки синхронизации, вероятности неправильного приёма PLS-кода и вероятности ошибки при декодировании пакета.
Из графика видно, что при мягком декодировании при Eb/N0≈2,8 обеспечивается вероятность успешного приёма фрейма 99,9% (т. е. PER≤0,001) для модели аддитивного Гауссова шума (AGWN).
При жестком декодировании та же вероятность успешного приёма обеспечивается при Eb/N0≈4,1, т. е. параметры ухудшаются примерно на 1,5 dB.
Приложение 1. Энергетические возможности протокола
Приложение 2. Синхропоследовательность
Приложение 3. Обоснование принятых технических решений
Последовательность балансирована по числу нулей и единиц, имеет максимально 5 последовательных нуля и 5 последовательных единиц.
Последовательность оптимизирована таким образом, чтобы приемлемую автокорелляцию имела как она сама, так и её первая половина – сама по себе
и с добавлением перамбулы.
График автокорелляционной функции для разных вариантов использования
в пространстве растояний Хэмминга приведён на рисунке.
Последовательность оптимизирована таким образом, чтобы приемлемую автокорелляцию имела как она сама, так и её первая половина – сама по себе
и с добавлением перамбулы.
График автокорелляционной функции для разных вариантов использования
в пространстве растояний Хэмминга приведён на рисунке.
Обзор существующих протоколов
Перед созданием собственного протокола были проанализированы уже существующие. В частности, были рассмотрены:
• CCSDS 131/0-B-3 TM synchronisation and channel coding
• Протокол УКВ-приёмопередатчика GOMspace NanoCom U482/AX100 в режиме ASM и ASM+Golay
• Протокол УКВ-приёмопередатчика GOMspace NanoCom U482/AX100 в режиме
• Протокол аппарата AAUSAT-4
• Семейство протоколов FEC аппарата AO-40 и его модификации
Все упомянутые протоколы используют помехоустойчивое кодирование. Ниже приведено краткое описание и причины, по которым протокол не был использован без изменений.
CCSDS 131/0-B-3 TM synchronisation and channel coding
https://public.ccsds.org/Pubs/131x0b2ec1s.pdf
Этот протокол лежит в основе USP. Основная проблема при использовании
в полудуплексных низкоскоростных линиях – отсутствие возможности динамически менять длину фрейма, что приводит при работе многих протоколов к неэффективному использованию канала, большому раунд-трипу и, как следствие,
к замедлению передачи.
Протокол УКВ-приёмопередатчика GOMspace NanoCom U482/AX100 в режиме ASM или ASM+Golay
Этот протокол имеет поле длины, что позволяет использовать короткие пакеты, когда это требуется. Однако, он имеет и недостатки. Протокол использует sync-слово небольшой длины, а также некодированное поле длины, что ограничивает энергетику радиоканала на значениях, далёких от возможностей используемого помехоустойчивого кодирования.
Семейство протоколов FEC аппарата AO-40 и его модификации
https://www.amsat.org/articles/g3ruh/125.html
Протокол хорошо оптимизирован с точки зрения работы в условиях замираний
и имеет хорошие энергетические возможности. Проблемой является также отсутствие возможности динамически менять длину фрейма.
Изменения
Версия 1.01 Первая опубликованная версия
Версия 1.02 Изменена синхропоследовательность с целью улучшения автокорелляционной функции первой её половины. Это значительно улучшило приём при использовании аппаратных трансиверов.
Версия 1.03 Ещё улучшена синхропоследовательность. Теперь она оптимизирована как по полной автокорелляции, так и по двум частичным – с преамбулой и без.
Версия 1.04 Приложения перенумерованы. Дописано обоснование принятых технических решений.
Перед созданием собственного протокола были проанализированы уже существующие. В частности, были рассмотрены:
• CCSDS 131/0-B-3 TM synchronisation and channel coding
• Протокол УКВ-приёмопередатчика GOMspace NanoCom U482/AX100 в режиме ASM и ASM+Golay
• Протокол УКВ-приёмопередатчика GOMspace NanoCom U482/AX100 в режиме
• Протокол аппарата AAUSAT-4
• Семейство протоколов FEC аппарата AO-40 и его модификации
Все упомянутые протоколы используют помехоустойчивое кодирование. Ниже приведено краткое описание и причины, по которым протокол не был использован без изменений.
CCSDS 131/0-B-3 TM synchronisation and channel coding
https://public.ccsds.org/Pubs/131x0b2ec1s.pdf
Этот протокол лежит в основе USP. Основная проблема при использовании
в полудуплексных низкоскоростных линиях – отсутствие возможности динамически менять длину фрейма, что приводит при работе многих протоколов к неэффективному использованию канала, большому раунд-трипу и, как следствие,
к замедлению передачи.
Протокол УКВ-приёмопередатчика GOMspace NanoCom U482/AX100 в режиме ASM или ASM+Golay
Этот протокол имеет поле длины, что позволяет использовать короткие пакеты, когда это требуется. Однако, он имеет и недостатки. Протокол использует sync-слово небольшой длины, а также некодированное поле длины, что ограничивает энергетику радиоканала на значениях, далёких от возможностей используемого помехоустойчивого кодирования.
Семейство протоколов FEC аппарата AO-40 и его модификации
https://www.amsat.org/articles/g3ruh/125.html
Протокол хорошо оптимизирован с точки зрения работы в условиях замираний
и имеет хорошие энергетические возможности. Проблемой является также отсутствие возможности динамически менять длину фрейма.
Изменения
Версия 1.01 Первая опубликованная версия
Версия 1.02 Изменена синхропоследовательность с целью улучшения автокорелляционной функции первой её половины. Это значительно улучшило приём при использовании аппаратных трансиверов.
Версия 1.03 Ещё улучшена синхропоследовательность. Теперь она оптимизирована как по полной автокорелляции, так и по двум частичным – с преамбулой и без.
Версия 1.04 Приложения перенумерованы. Дописано обоснование принятых технических решений.
Описание протокола передачи данных по нисходящей линии S-диапазона МКА «УмКА-1»
1. Описание структуры сигнала
1.1 Модуляция
Для передачи данных используется двухпозиционная фазовая модуляция (BPSK). Значения фазы несущего колебания принимают только два значения: 0 и 180 градусов для передачи логического «1» и логического «0».
1.2 Символьная скорость
Символьная скорость сигнала составляет 2MS/s (2МВыб/Сек).
1.3 Частота
Частота передаваемого сигнала составляет 2402 МГц.
1.4 Используемые алгоритмы для повышения помехоустойчивости сигнала
Для защиты передаваемых данных от помех и обеспечения частых переключений модулятора между двумя возможными состояниями фазы используются: Скремблирование данных и свёрточное кодирование с относительной скоростью кодирования ½ , k=7. Порождающие полиномы: [1111001] и [1011011].
2. Структура транспортного кадра
Структура транспортного кадра опирается на рекомендации CCSDS (Международный Консультативный Комитет по космическим системам передачи данных), но имеет изменённый транспортный кадр CADU (Channel Access Data Unit).
Структура настоящего транспортного кадра (CADU):
1.1 Модуляция
Для передачи данных используется двухпозиционная фазовая модуляция (BPSK). Значения фазы несущего колебания принимают только два значения: 0 и 180 градусов для передачи логического «1» и логического «0».
1.2 Символьная скорость
Символьная скорость сигнала составляет 2MS/s (2МВыб/Сек).
1.3 Частота
Частота передаваемого сигнала составляет 2402 МГц.
1.4 Используемые алгоритмы для повышения помехоустойчивости сигнала
Для защиты передаваемых данных от помех и обеспечения частых переключений модулятора между двумя возможными состояниями фазы используются: Скремблирование данных и свёрточное кодирование с относительной скоростью кодирования ½ , k=7. Порождающие полиномы: [1111001] и [1011011].
2. Структура транспортного кадра
Структура транспортного кадра опирается на рекомендации CCSDS (Международный Консультативный Комитет по космическим системам передачи данных), но имеет изменённый транспортный кадр CADU (Channel Access Data Unit).
Структура настоящего транспортного кадра (CADU):
Общая длина транспортного кадра составляет 8192 бит.
Где:
1. ASM – Маркер синхронизации транспортного кадра (CADU). Длина: 32 бит. Значение: 0x1ACFFC1D.
2. VCID – Номер информационного канала для поля с данными. Длина: 8 бит. Возможные значения: 0x40 и 0x41.
3. Counter – Бинарный счётчик транспортных кадров (CADU) Длина: 24 бит. Возможные значения: от 0x000000 (Dec: 0) до 0xFFFFFF (DEC: 16777215).
4. Spacer 1 – Разделитель с фиксированным значением. Длина: 8 бит. Значение: 0xFF.
5. Data field – Поле с полезными данными. Длина: 8064 бит.
6. Spacer 2 - Разделитель с фиксированным значением. Длина: 8 бит. Значение: 0xEF.
7. CRC32 – Контрольная сумма CRC32, которая генерируется для поля с данными длиной 8064 бит. Длина: 32 бит.
8. Spacer 3 - Разделитель с фиксированным значением. Длина: 16 бит. Значение: 0xFFFF.
3. Рандомизация (скремблирование) данных
Иногда в данных может передаваться большое количество логических «1» или «0» подряд. Это может вызвать рассинхронизацию демодулятора. Для того, чтобы этого избежать используется рандомизация данных, то есть приведение их к псевдо-случайному виду. В настоящем протоколе используется маска ПСП, которая генерируется по полиному: h(X)=X^8+X^7+X^5+X^3+1
Схема рандомизатора данных:
Где:
1. ASM – Маркер синхронизации транспортного кадра (CADU). Длина: 32 бит. Значение: 0x1ACFFC1D.
2. VCID – Номер информационного канала для поля с данными. Длина: 8 бит. Возможные значения: 0x40 и 0x41.
3. Counter – Бинарный счётчик транспортных кадров (CADU) Длина: 24 бит. Возможные значения: от 0x000000 (Dec: 0) до 0xFFFFFF (DEC: 16777215).
4. Spacer 1 – Разделитель с фиксированным значением. Длина: 8 бит. Значение: 0xFF.
5. Data field – Поле с полезными данными. Длина: 8064 бит.
6. Spacer 2 - Разделитель с фиксированным значением. Длина: 8 бит. Значение: 0xEF.
7. CRC32 – Контрольная сумма CRC32, которая генерируется для поля с данными длиной 8064 бит. Длина: 32 бит.
8. Spacer 3 - Разделитель с фиксированным значением. Длина: 16 бит. Значение: 0xFFFF.
3. Рандомизация (скремблирование) данных
Иногда в данных может передаваться большое количество логических «1» или «0» подряд. Это может вызвать рассинхронизацию демодулятора. Для того, чтобы этого избежать используется рандомизация данных, то есть приведение их к псевдо-случайному виду. В настоящем протоколе используется маска ПСП, которая генерируется по полиному: h(X)=X^8+X^7+X^5+X^3+1
Схема рандомизатора данных:
Маска ПСП имеет длину 255 бит и далее просто повторяется. Начинается с “11111111”
и оканчивается “01011000”. Для одного транспортного кадра она повторяется 32 раза. Итого 255*32=8160 бит.
На транспортные CADU данные она накладывается через блок XOR. При этом маркер ASM никак не затрагивается и сохраняется в исходном виде.
Один CADU имеет длину 8192 бит. Первые 32 бит – маркер ASM, остальные 8160 бит побитно сравниваются с маской ПСП. Так обеспечивается рандомизация данных.
4. Алгоритм генерации свёрточного кода
Свёрточный код хорошо подходит для защиты данных от ошибок в каналах с преимущественно гауссовским шумом. В настоящем протоколе используется свёрточный код с относительной скоростью кодирования ½ и длиной сдвигового регистра (k) 7. Порождающие полиномы: [1111001] и [1011011].
Схема генератора свёрточного кода:
и оканчивается “01011000”. Для одного транспортного кадра она повторяется 32 раза. Итого 255*32=8160 бит.
На транспортные CADU данные она накладывается через блок XOR. При этом маркер ASM никак не затрагивается и сохраняется в исходном виде.
Один CADU имеет длину 8192 бит. Первые 32 бит – маркер ASM, остальные 8160 бит побитно сравниваются с маской ПСП. Так обеспечивается рандомизация данных.
4. Алгоритм генерации свёрточного кода
Свёрточный код хорошо подходит для защиты данных от ошибок в каналах с преимущественно гауссовским шумом. В настоящем протоколе используется свёрточный код с относительной скоростью кодирования ½ и длиной сдвигового регистра (k) 7. Порождающие полиномы: [1111001] и [1011011].
Схема генератора свёрточного кода:
Кодовое отношение составляет ½, а значит, что на каждый новый бит полезных данных, которые сдвигают регистр, приходится 2 бита на выходе C1, C2. Таким образом данных на выходе кодера становится в два раза больше, чем на входе.
Кодирование данных
Общая структура кадра
Общая структура кадра приведена на рисунке ниже
Унифицированный протокол SPUTNIX (USP)
Описание протокола
Старший бит исходного значения умножается на первую строку матрицы, младший – на последнюю, получившиеся значения суммируются по модулю 2, или, иначе говоря, выполняется операция исключающее или между всеми строками таблицы, напротив которых в кодируемом значении стоит единица.
Получившееся в итоге значение скремблируется сложением по модулю 2 (исключающим ИЛИ, XOR) с битовой последовательностью
Получившееся в итоге значение скремблируется сложением по модулю 2 (исключающим ИЛИ, XOR) с битовой последовательностью
Применённый код полностью эквивалентен используемому в стандартах DVB- S2 (раздел 5.5.2) и CCSDS 131.2-B-1 (раздел 5.3.3), несмотря на другой способ определения.
PLS-код несёт информацию о типе и параметрах кодирования, размере передаваемого блока данных кода (FEC codeblock).
На данный момент реализован только один тип кодирования данных c двумя возможными размерами кодируемого блока данных:
PLS-код несёт информацию о типе и параметрах кодирования, размере передаваемого блока данных кода (FEC codeblock).
На данный момент реализован только один тип кодирования данных c двумя возможными размерами кодируемого блока данных:
0111000110011101100000111100100101010011010000100010110111111010
0111000110011101100000111100100101010011010000100010110111111010