Mensagem de navegação LEO

O tipo de cenário leo-navmsg constrói a mensagem difundida de efemérides e relógio de um satélite de posicionamento, navegação e temporização (PNT) em órbita terrestre baixa (LEO) e responde às perguntas que um projetista de mensagens coloca: durante quanto tempo pode uma mensagem cobrir, o que compra cada parâmetro adicional, o que vê um utilizador quando a mensagem muda a meio de uma passagem e quantos bits são necessários para a transportar com precisão centimétrica.

É independente do sistema. Qualquer órbita, qualquer portadora e qualquer dos quatro modelos de efemérides funcionam sem nenhuma predefinição; as predefinições com nome são dados opcionais (ver Presets).

Imprima um exemplo incluído com kshana example <name> (um nome por chamada) e execute-o com kshana scenarios/<name>.toml: leo-navmsg-fit-interval-trade, leo-navmsg-model-comparison, leo-navmsg-midpass-update e leo-navmsg-encode-decode. O tipo é também a fase de mensagem do tipo leo-pnt-chain (LEO-PNT.md) e o membro da campanha leo-focus-data-services, que compõe quatro configurações de mensagem e indica o comprimento da trama de cada uma (146, 154, 159 e 171 bytes).

Código: src/leo_navmsg/ — elements.rs (registos e algoritmo do utilizador), truth.rs (órbita e relógio de referência), fit.rs (ajustador), sisre.rs (erro de distância do sinal no espaço), services.rs (ionosfera e Tempo Universal Coordenado (UTC)), codec.rs (formato binário), text.rs (exportações em estilo Receiver Independent Exchange Format (RINEX) e em valores separados por vírgulas (CSV)), presets/ (um ficheiro por predefinição), mod.rs (o tipo).

O que uma mensagem transporta#

Modelos de efemérides#

O algoritmo do utilizador (elements::sat_state) é a sequência do ICD do Galileo (equação de Kepler, correções de segundo harmónico, nodo fixo à Terra) seguida, para kepler-rac, pelos três polinómios ao longo do próprio referencial da órbita kepleriana: radial ao longo da posição calculada, transversal ao longo da normal à órbita a partir da inclinação e do nodo corrigidos, e ao longo da trajetória a completar a tríade. O relógio acrescenta o termo relativista do ICD F·e·√A·sin E; para ecef-poly é a forma geral −2 r·v / c² a partir do polinómio e da sua derivada.

Os termos de Liu et al. seguem o algoritmo do utilizador do artigo (Secção 2,2, Eq. 1-7): A = A0 + ȧ·tk, n = √(μ/A0³) + Δn + ṅ·tk (as versões anteriores à 0,30 usavam a convenção de navegação civil do Global Positioning System (GPS) ½·ṅ·tk, pelo que um ṅ por elas escrito é o dobro do do artigo) e Crs1·sin Φ + Crc1·cos Φ + Crs3·sin 3Φ + Crc3·cos 3Φ somado ao raio, sendo Φ o argumento de latitude não corrigido. A convenção de escala de ṅ é transcrita da Eq. 1 do artigo; a comparação com o artigo em órbitas reais não depende dela (um fator ½ em ṅ deixa inalterados todos os valores ajustados), pelo que o significado de um valor nDot transmitido não está aí validado.

Duas leituras são do próprio Kshana e são indicadas como tal:

• O referencial RAC e a normalização τ = tk / tau_s. Nenhum documento público define um referencial de correção LEO para uma mensagem difundida.
• O relógio de uma mensagem de relógio zero é zero no total: considera-se que o ciclo de controlo mantém o relógio aparente, termo relativista incluído, no tempo do sistema.

O ajustador#

truth.rs integra a órbita com um Runge–Kutta de quarta ordem de passo fixo num referencial que passa a eixos fixos à Terra por uma rotação, θ(t) = θ0 + Ω̇e·t, a mesma rotação única que um algoritmo de utilizador de difusão aplica. A gravidade é de dois corpos (gravity_degree = 0), os harmónicos zonais J2 a J6 (2 a 6) ou o campo do Earth Gravitational Model 2008 (EGM2008) até ao grau e ordem 7 a 70, cujos termos tesserais transportam a assinatura de curto período que torna difícil um ajuste LEO. A resistência atmosférica é opcional (densidade exponencial estática). O relógio é de funcionamento livre (desvio, deriva, taxa de deriva e ruído branco de frequência com um desvio de Allan indicado a um segundo, mais o termo relativista periódico) ou controlado (um resíduo de Gauss–Markov de primeira ordem).

fit.rs ajusta o conjunto kepleriano com Levenberg–Marquardt em elementos não singulares (e·cos ω, e·sin ω, λ0 = M0 + ω): uma órbita LEO é quase circular, pelo que ω e M0 sozinhos são quase indistinguíveis. Parte do estado osculador em toe com a taxa do nodo por J2. Prioris fracos centrados em zero limitam as taxas e os harmónicos que um arco curto não consegue resolver; com um peso de observação de 1 cm, atuam apenas nessas direções nulas. O ajuste liu22 adota, em vez disso, o arranque e o estimador da Secção 2,3 do artigo: começa com todos os termos de correção a zero, não tem prioris (mínimos quadrados simples) e mantém o limite de 100 iterações do artigo. Pára pela regra própria do Kshana de convergência de parâmetros, quando cada passo de parâmetro é inferior a 1e-3 do seu desvio-padrão formal; o artigo pára, em vez disso, quando o RMS varia menos de 0,1 mm. Os polinómios RAC são depois ajustados aos resíduos ao longo da trajetória, transversais e radiais por mínimos quadrados lineares, e o polinómio de relógio ao relógio de referência menos o termo relativista que o utilizador voltará a somar.

Uma conclusão que as predefinições codificam: após um ajuste kepleriano por mínimos quadrados, o resíduo é, por construção, aquilo que os 16 parâmetros não conseguem abranger, pelo que oscila ao longo da janela (vários cruzamentos por zero em cada componente) em vez de derivar. Um polinómio de correção só o remove quando o seu grau excede o que o conjunto kepleriano já abrange: ao longo da trajetória 7, transversal 5 e radial 6 reduzem um resíduo de 15 minutos de centímetros para cerca de um milímetro, enquanto graus transversais mais baixos quase nada removem (o resíduo transversal é ímpar em torno do centro da janela). Um sistema que obtenha a sua parte kepleriana de outra forma deixa um resíduo de forma diferente, e os graus de que precisa decorrem disso. Os graus de correção próprios da predefinição Celeste (mais baixos do que estes; existem apenas no ficheiro da predefinição, src/celeste_iod.rs) são aqui executados sobre a base de mínimos quadrados do Kshana, razão pela qual os seus termos transversais contribuem pouco neste motor: uma afirmação sobre o ajustador do Kshana, não sobre qualquer sistema real. toe e toc são segundos inteiros, tal como o formato binário os transporta.

Cada mensagem é usada durante um período centrado na sua janela de ajuste (a primeira tabela de compromisso usa a janela inteira). O que os valores do erro de distância do sinal no espaço (SISRE) medem é o erro de representação da mensagem face à referência a que foi ajustada, como raiz do valor quadrático médio (RMS) e máximo ao longo do intervalo. O erro de determinação e de previsão de órbita, que um segmento real em terra ou a bordo acrescenta por cima, não é modelado.

Erro de distância do sinal no espaço#

sisre.rs usa o SISRE de média global de Montenbruck, Steigenberger e 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²) )

Os pesos são as médias sobre utilizadores distribuídos uniformemente na calote visível da Terra de cos² η e ½ sin² η, sendo η o ângulo de nadir da linha de visada no satélite, calculado para o raio e a máscara de elevação da própria órbita. Com uma máscara de 0° o cálculo reproduz a tabela do artigo para a órbita terrestre média (GPS 0,98 e 1/49, GLONASS 1/45, Galileo 1/61, BeiDou 1/54) e para a órbita geoestacionária (0,99 e 1/126): essa é a verificação VALIDATED. Em LEO a mesma média dá

pelo que um utilizador LEO, que vê o satélite longe do nadir, sente muito mais os erros ao longo da trajetória e transversais do que um utilizador de órbita média.

Análises#

analysis = [...] escolhe qualquer das quatro (predefinição: todas).

Compromisso do intervalo de ajuste#

[trade] define o intervalo, os intervalos de ajuste, os períodos de atualização e os modelos. scenarios/leo-navmsg-fit-interval-trade.toml (550 km, 97,6°, EGM2008 até ao grau 20 e resistência atmosférica, 30 minutos de mensagens) dá, com o período de utilização igual ao intervalo de ajuste:

E com um ajuste de 300 s, variando a frequência com que uma nova mensagem assume:

O conjunto kepleriano de 16 parâmetros degrada-se de 0,04 cm a 60 s para 9,35 cm a 900 s: um conjunto kepleriano com harmónicos de duas vezes por revolução não consegue seguir os termos de gravidade de frequência mais alta nem a resistência atmosférica de um arco LEO durante mais do que alguns minutos, e o seu resíduo de mínimos quadrados oscila ao longo da janela. Os polinómios ao longo da trajetória/transversais/radiais (graus 7, 5, 6) absorvem o que resta: 1,01 cm a 900 s, 0,21 cm a 600 s. Nos intervalos mais curtos, os valores keplerianos são submilimétricos e já não estão estritamente ordenados (o ajuste é então limitado pelo condicionamento, não pelo modelo).

Comparação de modelos#

scenarios/leo-navmsg-model-comparison.toml executa os quatro modelos a 1, 5 e 10 minutos na mesma órbita, com o número de parâmetros e os bits de efemérides e relógio na codificação do Kshana:

A linha de relógio zero é pontuada face a um relógio controlado com um resíduo de 0,24 m (o valor do ATOMIC); as outras, face ao relógio de funcionamento livre que ajustam.

Liu et al. 2025, SISRE em função da altitude (MODELLED). O mesmo cenário ajusta o modelo de 22 parâmetros do Kshana em arcos de 20 minutos às cinco altitudes do artigo, na inclinação de cada satélite:

Isto não é uma validação. O artigo ajustou órbitas científicas precisas reais dos satélites indicados (com o seu histórico completo de gravidade, resistência atmosférica e forças não gravitacionais); o Kshana ajusta a sua própria órbita integrada, calcula os seis parâmetros acrescentados como descrito acima e usa os seus próprios pesos SISRE. A comparação mostra a tendência e a ordem de grandeza. A comparação nas mesmas órbitas reais que o artigo ajustou é tests/leo_navmsg_fit_real_orbit_oracle.rs (desde a 0,30 o ajuste de 22 parâmetros concorda aí dentro do fator 1,5 fixado antecipadamente, nos dias do artigo e em oito dias reservados).

Atualização a meio da passagem#

[midpass] coloca um utilizador (predefinição 45° N, 10° E), encontra a passagem mais alta acima da máscara dentro de search_s e agenda mensagens a cada update_period_s. Em cada comutação dentro da passagem indica o salto de posição, o salto de relógio, o salto de pseudodistância do utilizador (mensagem nova menos a antiga), o maior salto que qualquer utilizador visível poderia ver (forma fechada sobre o cone de nadir), o erro de distância antes e depois, e PASS ou FAIL face a threshold_m. scenarios/leo-navmsg-midpass-update.toml (ajustes de 300 s atualizados a cada 150 s):

A passagem mais alta num dia atinge 43,7° e dura 455 s. As suas comutações:

Maior salto de distância do utilizador 0,35 mm face a um limiar de 5 cm: PASS.

Codificação e descodificação#

scenarios/leo-navmsg-encode-decode.toml codifica a primeira de três mensagens, descodifica-a, verifica o CRC e rejeita uma cópia corrompida, imprime o orçamento de quantização e escreve e volta a ler o bloco em estilo RINEX e a tabela CSV:

• trama: 171 bytes (1310 bits de carga útil, dos quais 1045 são de efemérides e relógio), verificação de redundância cíclica de 24 bits (CRC-24Q) 0x19105F;
• maior efeito de meio passo de qualquer campo isolado: af0, 0,545 mm;
• mensagem completa após a quantização: posição a menos de 1,126 mm e relógio a menos de 0,185 mm da mensagem exata; SISRE 0,113 cm exato, 0,129 cm descodificado;
• uma trama com um bit invertido é rejeitada: verdadeiro;
• ida e volta em estilo RINEX a menos de 5.0e-06 m, ida e volta em CSV a menos de 0.0e+00 m.

Independência da plataforma#

Uma trama é composta por inteiros transmitidos, pelo que tem de ser os mesmos inteiros onde quer e como quer que o cenário seja executado: o binário nativo em qualquer sistema operativo, uma compilação de depuração ou de produção, e a compilação WebAssembly (WASM) num navegador. Três coisas se interpunham. O seno, o cosseno, o arco-tangente e a exponencial da biblioteca matemática de um anfitrião não têm de ser corretamente arredondados e diferem entre anfitriões na última casa. Uma compilação otimizada em macOS obtém um seno e um cosseno de um argumento a partir da rotina combinada do sistema, que nem sempre devolve o valor do seno isolado, pelo que uma compilação de depuração e uma de produção também diferiam. E o amostrador normal habitual chama a exponencial e o logaritmo do anfitrião nos seus ramos raros. O ajuste transforma uma diferença tão pequena em campos quantizados diferentes. O tipo inteiro (órbita e relógio de referência, ajuste, algoritmo do utilizador, erro de distância do sinal no espaço (SISRE), codec) calcula, por isso, todas essas funções com a biblioteca libm em Rust puro através de src/portable_math.rs, potências inteiras como produtos explícitos e desvios normais pelo método polar sobre a saída bruta do gerador. leo_navmsg::tests::the_encoded_frame_is_the_same_bytes_on_every_platform fixa a trama de 171 bytes do cenário de codificação e descodificação abaixo e um valor de verificação por modelo de efemérides; uma compilação de depuração, uma de produção e a compilação WASM dão documentos de resultados idênticos byte a byte para os cinco cenários leo-navmsg incluídos.

Formato binário#

Esta é a codificação documentada própria do Kshana. Transporta os componentes que as descrições publicadas das mensagens de navegação LEO referem, modelada no conjunto de campos do ICD do Galileo. Não é a disposição de bits do Celeste nem de qualquer outro sistema: nenhuma é pública.

Trama: preâmbulo 0xA7 (8 bits), versão 1 (4), modelo (4: 1 kepler16, 2 kepler-rac, 3 liu22, 4 ecef-poly), comprimento da carga útil em bytes (12), carga útil preenchida com zeros até um byte, CRC-24Q (uma verificação de redundância cíclica de 24 bits, 24 bits) sobre todos os bytes anteriores. O CRC-24Q é a verificação da norma da Radio Technical Commission for Maritime Services RTCM 10403 e do ICD do Galileo (polinómio 0x1864CFB, valor inicial 0); o código reproduz o valor de verificação de catálogo 0xCDE703 para 123456789 e os bytes de verificação da trama de exemplo do tipo de mensagem 1005 da RTCM 10403 (VALIDATED).

Os passos do ICD do Galileo foram escolhidos para a órbita terrestre média e são demasiado grosseiros para uma mensagem LEO de nível centimétrico: Crs em passos de 2⁻⁵ m (3,1 cm), Cuc 2⁻²⁹ rad (1,3 cm ao raio LEO), os ângulos 2⁻³¹ semicírculos (1,0 cm) e af0 2⁻³⁴ s (1,7 cm). O Kshana mantém as unidades do ICD e a convenção do semicírculo, refina os passos de modo que o erro de meio passo de cada campo fique abaixo de 1 mm de posição ou distância numa janela de 15 minutos, e alarga os campos para manter os intervalos de que um ajuste LEO necessita:

Um valor fora do intervalo do seu campo é recusado, não é enrolado. Os intervalos foram verificados codificando ajustes a 300 a 2000 km, com inclinações de 0° a 140° e intervalos de ajuste até 20 minutos: deltaN e OmegaDot são largos porque, numa órbita quase equatorial, o nodo é mal definido e o ajuste reparte entre eles a deriva por J2 do argumento de latitude, e aDot e nDot porque o ajuste de 22 parâmetros ao longo de 20 minutos absorve parte da oscilação de curto período do semieixo maior. Desde a 0,30, o ajuste de 22 parâmetros é o de mínimos quadrados simples do artigo, sem prioris, e um ajuste equatorial a 800 km necessita então de nDot de cerca de 6.3e-10 semicírculo/s^2, pelo que a sua escala passou de 2^-60 para 2^-58. As correções de grau 7 ao longo da trajetória de kepler-rac cabem no intervalo de coeficientes de 22 bits até 15 minutos; um ajuste mais longo pode excedê-lo e é então recusado. quantisation_budget indica, para cada campo de efemérides e de relógio, a maior variação de posição e de distância que uma variação de meio passo provoca ao longo do período de utilização, e a variação da mensagem completa após a quantização.

Exportações de texto#

O RINEX 4,02 não define registos de navegação LEO (as suas letras de sistema são G, R, E, J, C, I e S; RINEX 4,02 do International Global Navigation Satellite System (GNSS) Service (IGS)). O bloco que text.rs escreve toma emprestada a forma do RINEX 4 — um cabeçalho de registo > EPH, uma linha de satélite e época com três termos de relógio, linhas de órbita difundida de quatro campos D19.12 — e é uma extensão documentada do Kshana: letra de sistema L, tipos de registo KP16, KRAC, LU22, APOL, e três comentários de cabeçalho que o indicam. Trabalho anterior sobre órbitas LEO em registos de navegação de estilo 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

A tabela CSV transporta mensagens kepler16 e kepler-rac, uma por linha. As colunas predefinidas usam os nomes do ICD do 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 seleciona, em vez disso, a grafia de uma predefinição. Ambos os formatos podem ser lidos de volta.

Ionosfera e UTC#

• Klobuchar: o modelo L1 do motor (gnss_sim::klobuchar_delay_m, verificado face ao RTKLIB) escalado para a portadora pela lei de primeira ordem (f_L1 / f)².
• NeQuick-G: os coeficientes viajam na mensagem e effective_ionisation_level devolve Az = ai0 + ai1·μ + ai2·μ² para uma latitude de inclinação modificada μ, com as regras do algoritmo (coeficientes todos nulos dão 63,7 unidades de fluxo solar, sfu; o resultado é limitado a [0, 400] sfu). O modelo de densidade eletrónica NeQuick e a sua integração oblíqua, que transformam Az num atraso, não estão implementados.
• Um satélite a algumas centenas de quilómetros voa dentro da ionosfera. Nenhum dos modelos difundidos tem em conta o conteúdo eletrónico acima do satélite e não é aplicada nenhuma correção para ele.
• UTC: system_to_utc aplica os três casos do §5.1.7 do ICD do Galileo (antes, a menos de seis horas e depois de um evento de segundo intercalar); um segundo inserido lê-se 86400.

Predefinições#

As predefinições são dados, um ficheiro cada em src/leo_navmsg/presets/, com as suas fontes. O motor e todos os cenários incluídos, exceto o Celeste, funcionam sem elas.

RNSS é o serviço de satélite de radionavegação; RNTF a Resilient Navigation and Timing Foundation.

Celeste IOD. A predefinição da demonstração em órbita (IOD) Celeste da Agência Espacial Europeia (ESA) é a única que usa material apresentado no workshop LEO-PNT do Navigation Innovation and Support Programme (NAVISP) da ESA, 2026: a estrutura da mensagem (conjunto kepleriano do Galileo mais polinómios de correção ao longo da trajetória/transversais/radiais, polinómio de relógio, SVID, saúde, IOD, parâmetros ionosféricos e de UTC), o espaçamento dos registos e os nomes das colunas CSV. A órbita (510 km, quase polar heliossíncrona) e a portadora provêm de fontes públicas citadas no ficheiro. A disposição de bits do Celeste não é pública e não é reproduzida; fases posteriores do Celeste e o sistema LEO-PNT da União Europeia (UE) podem diferir. Todos os valores derivados do workshop encontram-se no módulo navmsg de src/celeste_iod.rs, usado por scenarios/leo-navmsg-celeste-iod.toml. Como a predefinição é retida: todos os números do motor derivados do workshop encontram-se num único ficheiro, src/celeste_iod.rs, que build.rs só compila quando ele existe, e nos cenários exclusivos do repositório scenarios/*celeste-iod*.toml. Eliminar esse ficheiro e esses cenários retém a predefinição sem qualquer edição de código; todos os outros testes, referências independentes e cenários funcionam sem ela, e a contagem de ficheiros de cenário do README continua a contar os ficheiros retidos.

Verificação#

Limitações#

• O SISRE é apenas erro de representação: sem erro de determinação ou de previsão de órbita.
• A referência é uma integração do Kshana (sem terceiro corpo, pressão de radiação solar nem marés), não a órbita precisa de um satélite real.
• O formato binário e o bloco em estilo RINEX são do próprio Kshana.
• O NeQuick-G é transportado, não integrado num atraso; não há correção para um satélite dentro da ionosfera.
• A comparação com Liu et al. difere nas órbitas, na leitura dos parâmetros e nos pesos.