Навігаційне повідомлення LEO

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

Він не залежить від системи. Будь-яка орбіта, будь-яка несівна та будь-яка з чотирьох моделей ефемерид працюють без жодного пресета; іменовані пресети є необов'язковими даними (див. Пресети).

Виведіть вбудований приклад командою 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 (експорти в стилі Receiver Independent Exchange Format (RINEX) і значень, розділених комами (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 см вони діють лише в цих нульових напрямках. Підгонка liu22 натомість бере початок і оцінювач зі статті, розділ 2,3: починає з нульових поправкових членів, не має апріорних обмежень (звичайні найменші квадрати) і зберігає обмеження статті в 100 ітерацій. Вона зупиняється за власним правилом збіжності параметрів Kshana, коли кожен крок параметра менший за 1e-3 його формального стандартного відхилення; стаття ж зупиняється, коли RMS змінюється менш ніж на 0,1 мм. Потім поліноми 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, GLONASS 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 км, 97,6°, EGM2008 до ступеня 20 і опір, 30 хвилин повідомлень) дає, коли період використання дорівнює інтервалу підгонки:

А з підгонкою 300 с, змінюючи, як часто нове повідомлення перебирає на себе роботу:

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

Порівняння моделей#

scenarios/leo-navmsg-model-comparison.toml запускає чотири моделі на 1, 5 і 10 хвилинах на тій самій орбіті, з кількістю параметрів і бітами ефемерид та годинника в кодуванні Kshana:

Рядок із нульовим годинником оцінюється відносно годинника, підлаштованого із залишком 0,24 м (показник 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 с, оновлювані кожні 150 с):

Найвищий проліт за добу сягає 43,7° і триває 455 с. Його перемикання:

Найбільший стрибок дальності користувача 0,35 мм проти порога 5 см: PASS.

Кодування та декодування#

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

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

Незалежність від платформи#

Кадр — це передані цілі числа, тож це мають бути ті самі цілі числа, де б і як би не виконувався сценарій: рідний двійковий файл на будь-якій операційній системі, налагоджувальна або випускна збірка та збірка 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, за зразком набору полів Galileo ICD. Це не бітова розкладка 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 і Galileo ICD (поліном 0x1864CFB, початкове значення 0); код відтворює каталожне контрольне значення 0xCDE703 для 123456789 і контрольні байти прикладу кадру типу повідомлення 1005 RTCM 10403 (VALIDATED).

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

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

Текстові експорти#

RINEX 4,02 не визначає навігаційних записів LEO (його літери систем — G, R, E, J, C, I і S; RINEX 4,02 Міжнародної служби GNSS (IGS)). Блок, який записує 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 по одному в рядку. Типові стовпці використовують назви з Galileo ICD (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 застосовує три випадки з Galileo ICD §5.1.7 (до події високосної секунди, протягом шести годин від неї та після неї); вставлена секунда читається як 86400.

Пресети#

Пресети — це дані, по одному файлу під src/leo_navmsg/presets/, із джерелами. Рушій і кожен вбудований сценарій, окрім сценарію Celeste, працюють без них.

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

Celeste IOD. Пресет демонстрації на орбіті (IOD) Celeste Європейського космічного агентства (ESA) — єдиний, що використовує матеріали, представлені на семінарі LEO-PNT програми ESA Navigation Innovation and Support Programme (NAVISP), 2026: структуру повідомлення (кеплерів набір Galileo плюс поліноми поправок вздовж/поперек/радіально, поліном годинника, SVID, справність, IOD, параметри іоносфери та UTC), крок записів і назви стовпців CSV. Орбіта (510 км, майже полярна сонячно-синхронна) і несівна походять із публічних джерел, указаних у файлі. Бітова розкладка 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 та ін. відрізняється орбітами, тлумаченням параметрів і вагами.