Навигационное сообщение LEO

Вид сценария leo-navmsg строит передаваемое сообщение с эфемеридами и часами навигационного спутника (позиционирование, навигация и время, PNT) на низкой околоземной орбите (LEO) и отвечает на вопросы разработчика сообщения: на какой срок хватает одного сообщения, что даёт каждый дополнительный параметр, что видит пользователь, когда сообщение меняется посреди пролёта, и сколько бит нужно, чтобы передать его с точностью до сантиметра.

Он не привязан к конкретной системе. Любая орбита, любая несущая и любая из четырёх моделей эфемерид работают вообще без предустановки; именованные предустановки — необязательные данные (см. Presets).

Выведите встроенный пример командой kshana example <name> (одно имя за вызов) и запустите его командой kshana scenarios/<name>.toml: leo-navmsg-fit-interval-trade, leo-navmsg-model-comparison, leo-navmsg-midpass-update и leo-navmsg-encode-decode. Этот вид также является стадией сообщения вида leo-pnt-chain (LEO-PNT.md) и участником кампании leo-focus-data-services, которая объединяет четыре конфигурации сообщения и сообщает длину кадра каждой (146, 154, 159 и 171 байт).

Код: src/leo_navmsg/ — elements.rs (записи и алгоритм пользователя), truth.rs (истинная орбита и часы), fit.rs (подгонка), sisre.rs (ошибка дальности сигнала в космосе), services.rs (ионосфера и всемирное координированное время (UTC)), codec.rs (двоичный формат), text.rs (экспорт в стиле RINEX (Receiver Independent Exchange Format) и в формате значений, разделённых запятыми (CSV)), presets/ (по одному файлу на предустановку), mod.rs (сам вид).

Что содержит сообщение#

Модели эфемерид#

Алгоритм пользователя (elements::sat_state) — это последовательность из ICD Galileo (уравнение Кеплера, поправки второй гармоники, земной узел), после которой для kepler-rac применяются три полинома вдоль собственной системы координат кеплеровой орбиты: радиальный — вдоль вычисленного положения, поперёк трассы — вдоль нормали к орбите по исправленным наклонению и узлу, вдоль трассы — дополняющий тройку. Часы добавляют релятивистский член из ICD F·e·√A·sin E; для ecef-poly это общая форма −2 r·v / c², вычисляемая по полиному и его производной.

Члены Liu и др. следуют алгоритму пользователя из статьи (раздел 2,2, формулы 1-7): A = A0 + ȧ·tk, n = √(μ/A0³) + Δn + ṅ·tk (выпуски до 0,30 использовали соглашение гражданской навигации Global Positioning System (GPS) ½·ṅ·tk, поэтому записанное ими ṅ вдвое больше, чем в статье), и Crs1·sin Φ + Crc1·cos Φ + Crs3·sin 3Φ + Crc3·cos 3Φ, добавляемое к радиусу, где Φ — неисправленный аргумент широты. Соглашение о масштабе ṅ перенесено из формулы 1 статьи; сравнение со статьёй на реальных орбитах от него не зависит (множитель ½ при ṅ не меняет ни одной подогнанной величины), поэтому смысл передаваемого значения nDot там не проверен.

Два прочтения принадлежат самой Kshana и названы как таковые:

• Система координат RAC и нормировка τ = tk / tau_s. Ни один открытый документ не определяет систему координат поправок LEO для широковещательного сообщения.
• Часы сообщения с нулевыми часами равны нулю в целом: предполагается, что контур привязки удерживает видимые часы, включая релятивистский член, на системном времени.

Подгонка#

truth.rs интегрирует орбиту методом Рунге — Кутты четвёртого порядка с фиксированным шагом в системе координат, переходящей в земные оси одним поворотом, θ(t) = θ0 + Ω̇e·t, — тем же единственным поворотом, который применяет широковещательный алгоритм пользователя. Гравитация задаётся как двухтельная (gravity_degree = 0), зональные гармоники J2–J6 (от 2 до 6) или поле модели Earth Gravitational Model 2008 (EGM2008) до степени и порядка от 7 до 70, тессеральные члены которой несут короткопериодическую сигнатуру, из-за которой подгонка на LEO затруднена. Сопротивление необязательно (статическая экспоненциальная плотность). Часы либо свободные (смещение, дрейф, скорость дрейфа и белый частотный шум с заданной девиацией Аллана за одну секунду, плюс периодический релятивистский член), либо привязанные (остаток Гаусса — Маркова первого порядка).

fit.rs подгоняет кеплеров набор методом Левенберга — Марквардта по неособым элементам (e·cos ω, e·sin ω, λ0 = M0 + ω): орбита LEO почти круговая, поэтому ω и M0 по отдельности почти неразличимы. Подгонка начинается с оскулирующего состояния в toe со скоростью узла от J2. Слабые априорные значения с нулевым центром ограничивают скорости и гармоники, которые короткая дуга разрешить не может; при весе наблюдений 1 cm они действуют только в этих нулевых направлениях. Подгонка liu22 вместо этого берёт начало и оценщик из раздела 2,3 статьи: она начинается с нулевых членов поправок, без априорных значений (обычный метод наименьших квадратов) и сохраняет предел статьи в 100 итераций. Она останавливается по собственному правилу сходимости параметров Kshana, когда каждый шаг параметра меньше 1e-3 его формального стандартного отклонения; статья же останавливается, когда RMS меняется менее чем на 0,1 mm. Затем полиномы RAC подгоняются к остаткам вдоль трассы, поперёк трассы и радиальным линейным методом наименьших квадратов, а полином часов — к истинным часам за вычетом релятивистского члена, который пользователь добавит обратно.

Вывод, закодированный в значениях по умолчанию: после подгонки кеплерова набора методом наименьших квадратов остаток по построению — это то, что 16 параметров охватить не могут, поэтому он колеблется по всему окну (несколько пересечений нуля в каждой компоненте), а не дрейфует. Полином поправок убирает его только тогда, когда его степень превышает то, что уже охватывает кеплеров набор: вдоль трассы 7, поперёк трассы 5 и радиальная 6 сводят 15-минутный остаток с сантиметров примерно к миллиметру, тогда как меньшие степени поперёк трассы почти ничего не убирают (остаток поперёк трассы нечётен относительно центра окна). Система, которая выводит кеплерову часть иным способом, оставляет остаток другой формы, и нужные ей степени определяются им. Собственные степени поправок предустановки Celeste (они ниже указанных; они есть только в файле предустановки, src/celeste_iod.rs) выполняются здесь на основе наименьших квадратов Kshana, поэтому её члены поперёк трассы в этом движке вносят мало: это утверждение о подгонке Kshana, а не о какой-либо реальной системе. toe и toc — целые секунды, так как их так передаёт двоичный формат.

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

Ошибка дальности сигнала в космосе#

sisre.rs использует глобальное среднее SISRE по Montenbruck, Steigenberger и Hauschild (2018, Advances in Space Research 61(12):3020–3038, doi 10.1016/j.asr.2018.03.041):

SISRE_orb = sqrt( w_R² R² + w_AC² (A² + C²) )
SISRE     = sqrt( (w_R R − c·dT)² + w_AC² (A² + C²) )

Веса — это средние по пользователям, равномерно распределённым по видимой шапке Земли, от cos² η и ½ sin² η, где η — угол надира линии визирования у спутника, вычисленный для собственного радиуса орбиты и маски по углу места. При маске 0° вычисление воспроизводит таблицу статьи для средней околоземной орбиты (GPS 0,98 и 1/49, ГЛОНАСС 1/45, Galileo 1/61, BeiDou 1/54) и геостационарной орбиты (0,99 и 1/126): это проверка уровня VALIDATED. На LEO то же усреднение даёт

поэтому пользователь LEO, который видит спутник далеко от надира, ощущает ошибки вдоль трассы и поперёк трассы гораздо сильнее, чем пользователь на средней орбите.

Анализы#

analysis = [...] выбирает любой из четырёх (по умолчанию все).

Сопоставление интервалов подгонки#

[trade] задаёт интервал, интервалы подгонки, периоды обновления и модели. scenarios/leo-navmsg-fit-interval-trade.toml (550 km, 97,6°, EGM2008 до степени 20 и сопротивление, 30 минут сообщений) при периоде использования, равном интервалу подгонки, даёт:

А при подгонке на 300 s, с разной частотой смены сообщения новым:

16-параметрический кеплеров набор ухудшается с 0,04 cm при 60 s до 9,35 cm при 900 s: один кеплеров набор с двукратными за оборот гармониками не может следовать более высокочастотным гравитационным членам и сопротивлению дуги LEO дольше нескольких минут, а его остаток по методу наименьших квадратов колеблется по всему окну. Полиномы вдоль трассы, поперёк трассы и радиальный (степени 7, 5, 6) поглощают оставшееся: 1,01 cm при 900 s, 0,21 cm при 600 s. На самых коротких интервалах кеплеровы величины составляют доли миллиметра и уже не строго упорядочены (подгонка тогда ограничена обусловленностью, а не моделью).

Сравнение моделей#

scenarios/leo-navmsg-model-comparison.toml запускает четыре модели с интервалами 1, 5 и 10 минут на одной и той же орбите, с числом параметров и числом битов эфемерид и часов в кодировании Kshana:

Строка с нулевыми часами оценивается относительно часов, привязанных с остатком 0,24 m (величина ATOMIC), остальные — относительно свободных часов, которые они подгоняют.

Liu и др., 2025: SISRE в зависимости от высоты (MODELLED). Тот же сценарий подгоняет 22-параметрическую модель Kshana на 20-минутных дугах на пяти высотах из статьи, при наклонении каждого спутника:

Это не валидация. В статье подгонялись реальные прецизионные научные орбиты названных спутников (с их полной историей гравитации, сопротивления и негравитационных воздействий); Kshana подгоняет собственную интегрированную орбиту, вычисляет шесть добавленных параметров, как описано выше, и использует собственные веса SISRE. Сравнение показывает тенденцию и порядок величины. Сравнение на тех же реальных орбитах, которые подгонялись в статье, — это tests/leo_navmsg_fit_real_orbit_oracle.rs (начиная с 0,30 22-параметрическая подгонка там согласуется в пределах заранее зарегистрированного множителя 1,5, как на днях из статьи, так и на восьми отложенных днях).

Обновление в середине пролёта#

[midpass] размещает пользователя (по умолчанию 45° с. ш., 10° в. д.), находит самый высокий пролёт над маской в пределах search_s и планирует сообщения каждые update_period_s. При каждом переключении внутри пролёта он сообщает скачок положения, скачок часов, скачок псевдодальности пользователя (новое сообщение минус старое), наибольший скачок, который мог бы увидеть любой видимый пользователь (замкнутая форма по конусу надира), ошибку дальности до и после, а также PASS или FAIL относительно threshold_m. scenarios/leo-navmsg-midpass-update.toml (подгонки на 300 s с обновлением каждые 150 s):

Самый высокий пролёт за сутки достигает 43,7° и длится 455 s. Его переключения:

Наибольший скачок дальности пользователя 0,35 mm при пороге 5 cm: PASS.

Кодирование и декодирование#

scenarios/leo-navmsg-encode-decode.toml кодирует первое из трёх сообщений, декодирует его, проверяет CRC и отвергает повреждённую копию, выводит бюджет квантования, а также записывает и считывает обратно блок в стиле RINEX и таблицу CSV:

• кадр: 171 байт (1310 бит полезной нагрузки, из них 1045 — эфемериды и часы), 24-битный циклический избыточный код (CRC-24Q) 0x19105F;
• наибольшее влияние половины шага для любого одного поля: af0, 0,545 mm;
• всё сообщение после квантования: положение в пределах 1,126 mm и часы в пределах 0,185 mm от точного сообщения; SISRE 0,113 cm для точного, 0,129 cm для декодированного;
• кадр с одним инвертированным битом отвергается: true;
• круговое преобразование в стиле RINEX в пределах 5.0e-06 m, круговое преобразование CSV в пределах 0.0e+00 m.

Независимость от платформы#

Кадр — это передаваемые целые числа, поэтому это должны быть одни и те же целые числа, где и как бы ни выполнялся сценарий: в нативном двоичном файле в любой операционной системе, в отладочной или релизной сборке и в сборке WebAssembly (WASM) в браузере. Этому мешали три обстоятельства. От синуса, косинуса, арктангенса и экспоненты из математической библиотеки хоста не требуется корректного округления, и на разных хостах они различаются в последнем разряде. Оптимизированная сборка на macOS берёт синус и косинус одного аргумента из комбинированной процедуры системы, которая не всегда возвращает значение отдельного синуса, поэтому отладочная и релизная сборки тоже различались. А обычный генератор нормальных величин вызывает экспоненту и логарифм хоста в своих редких ветвях. Подгонка превращает столь малую разницу в разные квантованные поля. Поэтому весь вид (истинная орбита и часы, подгонка, алгоритм пользователя, ошибка дальности сигнала в космосе (SISRE), кодек) вычисляет каждую такую функцию чистым Rust-крейтом libm через src/portable_math.rs, целые степени — явными произведениями, а нормальные отклонения — полярным методом по сырому выводу генератора. leo_navmsg::tests::the_encoded_frame_is_the_same_bytes_on_every_platform фиксирует 171-байтовый кадр сценария кодирования и декодирования, приведённого ниже, и одно контрольное значение на каждую модель эфемерид; отладочная сборка, релизная сборка и сборка WASM дают побайтово одинаковые документы результата для всех пяти встроенных сценариев leo-navmsg.

Двоичный формат#

Это собственное документированное кодирование Kshana. Оно несёт компоненты, которые называют опубликованные описания навигационных сообщений LEO, и построено по образцу набора полей ICD Galileo. Оно не является раскладкой битов Celeste или какой-либо другой системы: ни одна из них не является открытой.

Кадр: преамбула 0xA7 (8 бит), версия 1 (4), модель (4: 1 kepler16, 2 kepler-rac, 3 liu22, 4 ecef-poly), длина полезной нагрузки в байтах (12), полезная нагрузка, дополненная нулями до целого байта, CRC-24Q (24-битный циклический избыточный код, 24 бита) по всем предшествующим байтам. CRC-24Q — это контрольный код стандарта Radio Technical Commission for Maritime Services RTCM 10403 и ICD Galileo (полином 0x1864CFB, начальное значение 0); код воспроизводит каталожное контрольное значение 0xCDE703 для 123456789 и контрольные байты примера кадра RTCM 10403 типа сообщения 1005 (VALIDATED).

Шаги ICD Galileo выбраны для средней околоземной орбиты и слишком грубы для сообщения LEO с сантиметровой точностью: Crs с шагом 2⁻⁵ m (3,1 cm), Cuc 2⁻²⁹ рад (1,3 cm при радиусе LEO), углы 2⁻³¹ полуокружности (1,0 cm) и af0 2⁻³⁴ s (1,7 cm). Kshana сохраняет единицы ICD и соглашение о полуокружности, уточняет шаги так, чтобы ошибка половины шага каждого поля оставалась ниже 1 mm положения или дальности на 15-минутном окне, и расширяет поля, чтобы сохранить диапазоны, нужные подгонке LEO:

Значение вне диапазона своего поля отвергается, а не переносится по модулю. Диапазоны проверялись кодированием подгонок на 300–2000 km, при наклонениях от 0° до 140° и интервалах подгонки до 20 минут: deltaN и OmegaDot широки, потому что на околоэкваториальной орбите узел определён плохо, и подгонка делит между ними J2-дрейф аргумента широты, а aDot и nDot — потому что 22-параметрическая подгонка на 20 минут поглощает часть короткопериодических колебаний большой полуоси. Начиная с 0,30 22-параметрическая подгонка — это обычный метод наименьших квадратов статьи без априорных значений, и экваториальная подгонка на 800 km тогда требует nDot около 6.3e-10 полуокружности/s^2, поэтому её масштаб изменился с 2^-60 на 2^-58. Поправки вдоль трассы степени 7 из kepler-rac укладываются в диапазон 22-битных коэффициентов до 15 минут; более длинная подгонка может его превысить и тогда отвергается. quantisation_budget сообщает для каждого поля эфемерид и часов наибольшее изменение положения и дальности от изменения на половину шага за период использования, а также изменение всего сообщения после квантования.

Текстовый экспорт#

RINEX 4,02 не определяет навигационных записей LEO (его системные буквы: G, R, E, J, C, I и S; Международная служба GNSS (IGS), RINEX 4,02). Блок, который записывает text.rs, заимствует форму RINEX 4 — заголовок записи > EPH, строку спутника и эпохи с тремя членами часов, строки широковещательной орбиты из четырёх полей D19.12 — и является документированным расширением Kshana: системная буква L, типы записей KP16, KRAC, LU22, APOL и три комментария заголовка, которые об этом говорят. Предшествующая работа по орбитам LEO в навигационных записях в стиле RINEX 4: arXiv 2401,17767.

> EPH L04 KRAC
L04 yyyy mm dd hh mm ss  af0 af1 af2
     IOD      Crs      deltaN   M0
     Cuc      e        Cus      sqrtA
     toe      Cic      Omega0   Cis
     i0       Crc      omega    OmegaDot
     IDOT     Band     Week     Health
     txTOW    clock    degA     degC
     degR     tau_s    a0       a1         then the rest of a_k, c_k and r_k, four per line

Таблица CSV содержит сообщения kepler16 и kepler-rac по одному в строке. Столбцы по умолчанию используют названия из ICD Galileo (SVID, IOD, Band, WeekNumber, ToW, Health, toc, af0, af1, af2, toe, M0, sqrtA, e, deltaN, Omega0, OmegaDot, iDot, i0, omega, Crc, Crs, Cic, Cis, Cuc, Cus, a0…, c0…, r0…, racTau); csv_schema выбирает вместо них написание предустановки. Оба формата читаются обратно.

Ионосфера и UTC#

• Klobuchar: модель L1 движка (gnss_sim::klobuchar_delay_m, проверена по RTKLIB), приведённая к несущей по закону первого порядка (f_L1 / f)².
• NeQuick-G: коэффициенты передаются в сообщении, и effective_ionisation_level возвращает Az = ai0 + ai1·μ + ai2·μ² для модифицированной магнитной широты μ по правилам алгоритма (нулевые коэффициенты дают 63,7 единиц солнечного потока, sfu; результат ограничивается интервалом [0, 400] sfu). Модель электронной плотности NeQuick и её интегрирование по наклонной трассе, превращающие Az в задержку, не реализованы.
• Спутник на высоте в несколько сотен километров летает внутри ионосферы. Ни одна из широковещательных моделей не учитывает электронное содержание выше спутника, и поправка на него не применяется.
• UTC: system_to_utc применяет три случая из ICD Galileo, § 5.1.7 (до события високосной секунды, в пределах шести часов от него и после него); вставленная секунда читается как 86400.

Предустановки#

Предустановки — это данные, по одному файлу в src/leo_navmsg/presets/, с их источниками. Движок и все встроенные сценарии, кроме сценария Celeste, работают без них.

RNSS — радионавигационная спутниковая служба; RNTF — Resilient Navigation and Timing Foundation.

Celeste IOD. Предустановка Celeste in-orbit demonstration (IOD) Европейского космического агентства (ESA) — единственная, использующая материалы, представленные на семинаре по LEO-PNT программы ESA Navigation Innovation and Support Programme (NAVISP) в 2026 году: структуру сообщения (кеплеров набор Galileo плюс полиномы поправок вдоль трассы, поперёк трассы и радиальных, полином часов, SVID, исправность, IOD, ионосферные параметры и параметры UTC), интервал записей и имена столбцов CSV. Орбита (510 km, околополярная солнечно-синхронная) и несущая взяты из открытых источников, указанных в файле. Раскладка битов Celeste не является открытой и не воспроизводится; поздние фазы Celeste и система LEO-PNT Европейского союза (ЕС) могут отличаться. Каждое значение, полученное с семинара, находится в модуле navmsg файла src/celeste_iod.rs, используемом scenarios/leo-navmsg-celeste-iod.toml. Как предустановка удерживается: каждое число движка, полученное с семинара, находится в одном файле, src/celeste_iod.rs, который build.rs включает в сборку только при его наличии, и в сценариях только для репозитория scenarios/*celeste-iod*.toml. Удаление этого файла и этих сценариев удерживает предустановку без правки исходного кода; любые другие тесты, оракулы и сценарии работают без неё, а число файлов сценариев в README по-прежнему включает удержанные файлы.

Верификация#

Ограничения#

• SISRE — это только ошибка представления: без ошибки определения или прогнозирования орбиты.
• Истина — это интегрирование Kshana (без третьего тела, давления солнечного излучения и приливов), а не прецизионная орбита реального спутника.
• Двоичный формат и блок в стиле RINEX — собственные для Kshana.
• NeQuick-G передаётся, но не интегрируется в задержку; поправки для спутника внутри ионосферы нет.
• Сравнение с Liu и др. отличается орбитами, прочтением параметров и весами.