Tradução automática, não revista por um falante nativo. O inglês é a referência.

CenáriosGerado a partir dos ficheiros de cenário do repositório e da matriz de verificação no momento da compilação.

Referência de cenários

Todos os ficheiros de cenário incluídos (193), agrupados por tipo. A descrição é o comentário de cabeçalho do próprio ficheiro; os parâmetros principais são as suas configurações de nível superior. O estado lê a matriz de verificação para o módulo do tipo de cenário. Abrir no Kshana Studio abre a execução escrita.

Um satélite sobre uma estação: a distância oblíqua, a elevação e o Es/N0 de cada passagem ao longo da passagem, o MODCOD DVB-S2 escolhido em cada passo (limiares da Tabela 13 da ETSI EN 302 307-1 mais uma margem de implementação) e o volume de dados que o ACM transfere face à linha de base de codificação constante que fecha na máscara. MODELLED.

aocs#

Controlo de atitude de veículos espaciais: uma reorientação com apontamento inercial de um corpo rígido com três ou mais rodas de reação equilibradas sob realimentação MRP (L = -K sigma - P omega), binários de roda de norma mínima limitados ao limite de cada motor, RK4 com retenção de ordem zero; opcionalmente fechada sobre um EKF multiplicativo a partir de um giroscópio simulado (passeio aleatório de ângulo e de taxa) e de um seguidor de estrelas. Comunica o tempo de estabilização, o erro de apontamento final e máximo, a velocidade e o binário máximos das rodas, a fração saturada, a deriva do momento angular e, com o estimador, o seu erro de atitude e o NEES. O ciclo de estado verdadeiro é VALIDATED face ao Basilisk 2.9.1; o estimador é MODELLED.

aocs-slew.toml

tipo aocsnão associado a um módulo do registo pelo nome

Manobra de atitude com rodas de reação sob realimentação MRP, fechada sobre o estado real.

kind = "aocs"
duration_s = 600.0
dt_s = 0.1
sample_s = 1.0
k_nm = 3.5
p_nms = 30.0
pointing_threshold_deg = 0.1
axis = [0.5773502, 0.5773502, 0.5773504]

Abrir no Kshana Studio · Ver no GitHub

aocs-slew-mekf.toml

tipo aocsnão associado a um módulo do registo pelo nome

Manobra de atitude com rodas de reação sob realimentação MRP, fechada sobre uma estimativa MEKF.

kind = "aocs"
duration_s = 600.0
dt_s = 0.1
sample_s = 1.0
k_nm = 3.5
p_nms = 30.0
pointing_threshold_deg = 0.1
axis = [0.5773502, 0.5773502, 0.5773504]

Abrir no Kshana Studio · Ver no GitHub

aperture-duty-cycle#

Ciclo de utilização de aberturas: a partilha de tempo entre navegação e comunicações que um plano de contactos implica para um conjunto de aberturas orientáveis. Recebe um plano de contactos (uma lista de janelas [[contacts]] aos_s/los_s, cada uma a pedir navegação ou comunicações — o mesmo vocabulário aos_s/los_s que o preditor passes emite), um número de aberturas e uma POLÍTICA DE ARBITRAGEM (prioridade à navegação por predefinição, ou prioridade às comunicações, ou por ordem de chegada sem preempção), e comunica a utilização para navegação, a utilização para comunicações, a utilização em repouso e a indisponibilidade por sessão — o tempo de contacto que uma sessão pediu e que nenhuma abertura serviu. Uma varredura exata de intervalos sobre os limites das janelas, de modo que janelas contíguas nunca disputam e nenhum segundo de abertura é contado duas vezes; os segundos de abertura de navegação, de comunicações e em repouso são acumulados independentemente e fecham face a apertures*horizon_s. O relatório indica a política resolvida, a sua definição completa e as definições de utilização e de indisponibilidade, porque um valor de utilização citado sem a sua política de arbitragem não é reprodutível. Aritmética de escalonamento MODELLED: não é contabilizado nenhum tempo de reorientação / resintonização / mudança quando uma abertura muda de serviço ou de sessão, nenhum volume de dados, estado de memória intermédia, orçamento de energia ou fecho de ligação entra na decisão, e as janelas de contacto são entradas — a sua geometria é aquilo que as produziu. Não é um produto de escalonamento de segmento terrestre.

aperture-duty-cycle.toml

tipo aperture-duty-cyclenão associado a um módulo do registo pelo nome

Demonstrador do ciclo de trabalho de abertura (segmento terrestre e operações).

kind = "aperture-duty-cycle"
apertures = 2
arbitration = "navigation-priority"
name = "nav-1"
service = "navigation"
aos_s = 0.0
los_s = 600.0
name = "comms-1"

Abrir no Kshana Studio · Ver no GitHub

araim-reference-check#

Vetores de referência de certificação ARAIM publicados: os níveis de proteção horizontal e vertical ARAIM do motor executados face aos PRÓPRIOS exemplos numéricos resolvidos do Subgrupo Técnico ARAIM do WG-C, com a tolerância (TOL_PL = 5e-2 m) que esses próprios documentos indicam. Dois vetores estão submetidos como dados de teste, cada um com o seu URL de obtenção, data de obtenção, SHA-256 do ficheiro de origem e página: o Reference Airborne Algorithm Description Document v3.1 (2019) Apêndice D — autoconsistente, e o vetor de aceitação — e o Milestone 3 Report (2016) Anexo A secção A.IX, a declaração que as bibliografias de investigação citam. Cada entrada publicada (a matriz de geometria de 10 satélites e 2 constelações, as diagonais de variância C_int e C_acc, b_nom, P_sat, P_const e o conjunto de constantes LPV-200) e cada saída publicada (VPL, HPL, EMT, sigma_v_acc, K_fa_3 e os sigma_3, sigma_ss_3 e b_3 dos dois modos de falha de constelação) é comunicada junto do número do próprio motor e da sua diferença absoluta. A equação do nível de proteção NÃO é resolvida de novo aqui: a lista de modos da referência é entregue ao raim::araim_protection_level / araim_integrity_risk já existentes do motor, pelo que a bissecção e a álgebra da cauda gaussiana em teste são as do próprio motor; apenas a geometria, as subsoluções, os limiares de deteção e a divisão do orçamento publicada são construídos para ele. EXTERNALLY CHECKED face ao vetor de 2019: VPL 18,2926 m face a 18,3 m publicado, HPL 13,4063 m face a 13,45 m, EMT 7,2997 m face a 7,2998 m, sigma_v_acc 1,3694 m face a 1,3694 m, e todos os seis intermédios publicados com uma diferença inferior a meia unidade na sua última casa decimal impressa. O vetor de 2016 contém dois defeitos internos que o relatório indica em vez de ocultar — um erro de sinal na linha 3 de G, e um K_fa_3 avaliado em 57 modos de falha enquanto o documento indica N_fault_max = 1 (12 modos) — pelo que os seus intermédios de geometria são reproduzidos exatamente, enquanto os seus níveis de proteção são comunicados como discrepâncias medidas e excluídos do valor de aceitação; a tolerância nunca é alargada para os absorver. Cada campo numérico emitido tem uma unidade e uma classe de proveniência, e um valor transcrito é etiquetado published para que nunca possa ser confundido com um calculado. ÂMBITO: apenas N_fault_max = 1 (modos de falha de um único satélite e de uma única constelação) está implementado, e um caso cujas probabilidades a priori exijam subconjuntos de falhas simultâneas de vários eventos é REFUSED em vez de truncado em silêncio; a deteção de falhas, a exclusão, a verificação de consistência do qui-quadrado e o passo de reatribuição da dupla contagem do algoritmo de referência estão fora do âmbito. Isto reproduz o exemplo resolvido de um algoritmo de referência publicado — não é uma certificação, um artefacto de aeronavegabilidade nem uma aprovação.

araim-reference-check.toml

tipo araim-reference-checknão associado a um módulo do registo pelo nome

Os níveis de proteção ARAIM do motor face aos exemplos resolvidos PRÓPRIOS do subgrupo WG-C.

kind = "araim-reference-check"

Abrir no Kshana Studio · Ver no GitHub

ascent-losses#

Ascensão planar com viragem gravitacional de um veículo de vários andares sobre uma Terra esférica sem rotação, através da US Standard Atmosphere 1976 (subida vertical, impulso de inclinação, tração ao longo da velocidade), integrando as perdas por gravidade, resistência, orientação e contrapressão e verificando o dv ideal menos as perdas face à velocidade no fim da queima; max-Q, aceleração máxima e estado no fim da queima. MODELLED.

ascent-losses.toml

tipo ascent-lossesnão associado a um módulo do registo pelo nome

Perdas de ascensão por viragem gravitacional de um lançador ILLUSTRATIVE de dois andares a querosene/oxigénio (sem veículo real): subida vertical até 1 km, um impulso de picada de 3 deg durante 10 s, e depois propulsão ao longo da velocidade. A execução integra as perdas por gravidade, arrasto, direção e contrapressão e verifica que o dv ideal menos as perdas é igual à velocidade de fim de combustão. MODELLED: Terra plana e sem rotação, C_D constante, sem fase de inércia, sem guiamento além do impulso.

kind = "ascent-losses"
payload_kg = 10000.0
drag_coefficient = 0.3
kick_altitude_m = 1000.0
kick_angle_deg = 3.0
kick_duration_s = 10.0
step_s = 0.1
dry_mass_kg = 25000.0

Abrir no Kshana Studio · Ver no GitHub

attitude-budget#

Orçamento de erro de atitude e de apontamento a 3-DOF: o binário perturbador de gradiente de gravidade no pior caso ((3/2)(μ/R³)ΔI) e um orçamento de erro de apontamento por raiz da soma dos quadrados sobre contribuintes nomeados de 1σ (ruído de sensores, vibração das rodas de reação, térmico, alinhamento) com o termo dominante, para uma altitude orbital e uma dispersão de inércia do corpo. Orçamento escalar de AOCS MODELLED — um complemento pré-hardware do Basilisk/42, não uma simulação de ciclo de controlo/6-DoF/modos flexíveis.

attitude-budget.toml

tipo attitude-budgeto tipo de cenário tem linhas validadas no registo · 1 de 1 linhas validadas

Demonstrador de orçamento de erro de atitude e apontamento a 3 graus de liberdade (AOCS/GNC pré-hardware).

kind = "attitude-budget"
altitude_km = 600.0
name = "star_tracker_noise"
sigma_arcsec = 5.0
name = "reaction_wheel_jitter"
sigma_arcsec = 8.0
name = "thermal_distortion"
sigma_arcsec = 4.0

Abrir no Kshana Studio · Ver no GitHub

body-pnt#

Posicionamento em torno de qualquer corpo do sistema solar: um orbitador ou um módulo de aterragem na superfície em torno de um corpo central escolhido pelo nome (Marte, a Lua, Europa, Ganimedes, Titã e o restante do catálogo do sistema solar), a navegar com pseudodistâncias unidirecionais de uma pequena constelação de navegação Walker em torno do corpo (órbitas de dois corpos com a deriva secular de J2 do próprio corpo, um relógio de utilizador desconhecido) e, opcionalmente, uma medida de distância bidirecional de espaço profundo, sem relógio, a partir da Terra, cuja direção e distância vêm das efemérides analíticas do sistema solar em cada época. As linhas de visada são bloqueadas pela esfera média do corpo, e um utilizador na superfície também precisa da máscara de elevação. Por época: relés em vista, se a Terra está acima do limbo, o GDOP e o PDOP apenas da constelação (diluição de precisão geométrica e de posição), a incerteza formal de posição de um sigma com e sem a linha da Terra, e o erro de uma solução de posição por mínimos quadrados de Gauss-Newton com semente, em cada caso; ao longo da execução: disponibilidade, visibilidade da Terra, PDOP mediano, erro RMS e sigma formal mediano, além do tempo de luz Terra-corpo, da ida e volta, do atraso de Shapiro e da separação do Sol na época. MODELLED: as órbitas dos relés, os níveis de ruído e o modelo de medida instantâneo são escolhas de modelação, não validadas contra dados de navegação de uma missão; as constantes do corpo são os valores publicados citados em body.rs, e a geometria da Terra herda os rótulos das efemérides do sistema solar.

europa-surface-pnt.toml

tipo body-pntnão associado a um módulo do registo pelo nome

Posicionamento de um módulo de aterragem em Europa: o caso de uma lua de Júpiter.

kind = "body-pnt"
body = "Europa"
epoch = "2027-02-19T00:00:00"
duration_s = 306822.0
step_s = 1800.0
seed = 11
kind = "surface"
lat_deg = 20.0

Abrir no Kshana Studio · Ver no GitHub

mars-orbit-pnt.toml

tipo body-pntnão associado a um módulo do registo pelo nome

Posicionamento de um orbitador baixo de Marte com uma constelação de navegação de Marte e uma ligação ao espaço profundo.

kind = "body-pnt"
body = "Mars"
epoch = "2027-02-19T00:00:00"
duration_s = 88775.0
step_s = 300.0
seed = 7
kind = "orbiter"
altitude_km = 300.0

Abrir no Kshana Studio · Ver no GitHub

campaign#

Campanha: tipos de cenário existentes compostos numa só execução, com cada número lido de uma execução real do tipo de cenário nomeado. Quatro secções, em qualquer combinação. PHASES: uma missão encadeada numa cronologia partilhada -- cada fase executa um ou mais cenários (por exemplo jamming, depois spoofing, depois um relógio em holdover com um sistema de navegação inercial a deslizar ao lado, depois um alarme de integridade, depois a recuperação), as suas saídas são lidas em canais nomeados (erro de tempo do relógio contra a sua guarda, relação portadora/densidade de ruído contra o limiar mínimo de seguimento, nível de proteção contra o limite de alerta, erro de posição, satélites em seguimento, indicadores de alarme) por uma predefinição por tipo de cenário ou por caminhos de resultado explícitos, e reamostradas numa grelha comum por retentor de ordem zero, com fronteiras de fase e eventos; o estado é repassado por carry (um canal continua a partir do valor final da fase anterior), handoff (um número da fase anterior gravado no cenário desta fase) e end_at (uma fase termina num instante que uma execução calculou, como o instante de deteção de um monitor de spoofing). SWEEP: uma grelha sobre uma a três chaves de cenário com pontos de qualquer tipo de cenário (um segmento de número inteiro indexa um array de tabelas, como em system.2.sisre_m), com métricas lidas por caminho de resultado e, com execuções acima de uma, um conjunto de Monte Carlo com semente em cada nó. MONTE_CARLO: a realização k executa em base_seed + k; cada métrica indica média, desvio padrão, percentis 5.º/50.º/95.º pelo método do posto mais próximo e um intervalo de confiança de 95% por bootstrap com semente fixa sobre a média. COMPOSE: vários cenários sob valores partilhados (a potência e a posição de um jammer gravadas num recetor marítimo e num rodoviário), com um resumo combinado de melhor/pior caso. O resultado traz um hash de campanha, um resumo sobre o resultado de cada membro e uma entrada de unidades para cada número emitido; as exportações de interoperabilidade gravam cada cenário membro que tem geometria como seu próprio conjunto de ficheiros. As identidades de composição são testadas: uma campanha de uma fase reproduz a execução isolada bit a bit, um conjunto de semente fixa é estável byte a byte e, num relógio com ruído de frequência branco, a média do conjunto cai dentro do intervalo indicado, com a dispersão a coincidir com sqrt(q_wf * tau). MODELLED: o carry aditivo e o retentor de ordem zero são escolhas de modelação, e cada fase traz o rótulo do tipo de cenário que a executou.

campaign-jam-spoof-holdover-integrity.toml

tipo campaignnão associado a um módulo do registo pelo nome

Uma missão encadeada: nominal, jamming, spoofing, perda de GNSS com holdover do relógio e navegação inercial à estima, um alarme de integridade e recuperação, numa única cronologia partilhada.

kind = "campaign"
title = "Jamming, spoofing, holdover and integrity: a chained mission"
seed = 20260928
step_s = 10.0
name = "nominal"
duration_s = 600.0
seed = 42
threshold_ns = 50.0

Abrir no Kshana Studio · Ver no GitHub

campaign-monte-carlo-clock-holdover.toml

tipo campaignnão associado a um módulo do registo pelo nome

Um conjunto Monte Carlo com semente através de uma campanha, num caso com forma fechada.

kind = "campaign"
title = "Monte Carlo: free-running clock error against its closed form"
seed = 20260928
runs = 200
seed_key = "seed"
metrics = [
seed = 42
threshold_ns = 20.0

Abrir no Kshana Studio · Ver no GitHub

campaign-shared-jammer-sea-road.toml

tipo campaignnão associado a um módulo do registo pelo nome

Composição entre domínios: um emissor de jamming, duas plataformas. Um navio no Golfo da Finlândia (59,80 N, 24,90 E, o recetor do exemplo maritime-strait-jamming) e um automóvel numa estrada costeira de Helsínquia (60,17 N, 24,94 E) ficam sob o mesmo emissor de jamming de banda larga, colocado a 59,80 N, 25,44 E, a 30 m de altura (cerca de 30 km do navio e 50 km do automóvel).

kind = "campaign"
title = "One jammer, a ship and a car"
seed = 20260928
name = "jammer_power"
unit = "dBW"
value = 8.0
name = "jammer_position"
unit = "m"

Abrir no Kshana Studio · Ver no GitHub

campaign-spectrum-holdover-integrity.toml

tipo campaignnão associado a um módulo do registo pelo nome

Uma missão encadeada conduzida pelo espetro em banda L: um emissor de jamming de varrimento de frequência (chirp) ocupa o GPS L1 C/A e o Galileo E1, o relógio mantém-se em holdover, e um tom de onda contínua (CW) deixado na portadora L1 mantém o C/A em baixo enquanto o E1 recupera, pelo que o recetor recorre ao Galileo e o seu monitor de integridade funciona sobre um céu só com Galileo.

kind = "campaign"
title = "L-band jamming from the spectrum, clock holdover and a Galileo-only fallback"
seed = 20260928
step_s = 1.0
name = "onset"
duration_s = 60.0
end_at = "timeline.bands[0].first_loss_t_s"
end_at_run = 1

Abrir no Kshana Studio · Ver no GitHub

campaign-sweep-jammer-power.toml

tipo campaignnão associado a um módulo do registo pelo nome

Um varrimento de parâmetros através de uma campanha: o recetor do exemplo jamming (52 N, 4 E, camada Walker do tipo GPS de 24 satélites) sob um emissor de jamming de banda larga a 1 km, com a potência de emissão do emissor variada de -50 dBW (10 nW) a +10 dBW (10 W) em passos de 5 dB. Cada nó é uma execução jamming normal; a campanha regista, por nó, a fração de épocas com pelo menos quatro satélites ainda em seguimento, a razão média jamming-sinal (J/S) e o menor número de satélites em seguimento.

kind = "campaign"
title = "Jammer power sweep: availability and J/S against transmit power"
seed = 20260928
metrics = [
name = "jammer_power"
key = "jammer.power_dbw"
unit = "dBW"
start = -50.0

Abrir no Kshana Studio · Ver no GitHub

leo-focus-data-services.toml

tipo campaignnão associado a um módulo do registo pelo nome

Área de foco LEO-PNT: serviços de dados PNT adicionais na mensagem de navegação.

kind = "campaign"
title = "Navigation-message service data against frame length"
seed = 20260929
name = "fit_interval"
unit = "s"
value = 300.0
label = "ephemeris-clock"
bind = { fit_interval = "message.fit_interval_s" }

Abrir no Kshana Studio · Ver no GitHub

leo-focus-fused-pnt-sisre.toml

tipo campaignnão associado a um módulo do registo pelo nome

Área de foco LEO-PNT: PNT fundido MEO + LEO.

kind = "campaign"
title = "Fused MEO + LEO positioning against the LEO SISRE"
seed = 20260929
metrics = [
name = "leo_sisre"
key = "system.2.sisre_m"
unit = "m"
start = 0.05

Abrir no Kshana Studio · Ver no GitHub

leo-focus-indoor-uhf.toml

tipo campaignnão associado a um módulo do registo pelo nome

Área de foco LEO-PNT: navegação em interiores com UHF.

kind = "campaign"
title = "Indoor LEO-PNT by band and building class"
seed = 20260929
label = "traditional-building"
metrics = [
kind = "leo-pass"
epoch = "2026-09-28T12:00:00"
duration_s = 900.0

Abrir no Kshana Studio · Ver no GitHub

leo-focus-iot-eirp.toml

tipo campaignnão associado a um módulo do registo pelo nome

Área de foco LEO-PNT: posicionamento de baixo consumo para a Internet das Coisas (IoT) e para móveis.

kind = "campaign"
title = "IoT energy per fix against LEO UHF transmit power"
seed = 20260929
metrics = [
name = "uhf_eirp"
key = "satellite.0.band.0.eirp_dbw"
unit = "dBW"
start = -35.0

Abrir no Kshana Studio · Ver no GitHub

leo-focus-ntn-bandwidth.toml

tipo campaignnão associado a um módulo do registo pelo nome

Área de foco LEO-PNT: compatibilidade com redes não terrestres (NTN) 5G/6G.

kind = "campaign"
title = "NTN positioning against reference-signal bandwidth"
seed = 20260929
metrics = [
name = "bandwidth"
key = "signal.0.bandwidth_hz"
unit = "Hz"
start = 180000.0

Abrir no Kshana Studio · Ver no GitHub

leo-focus-ppp-altitude.toml

tipo campaignnão associado a um módulo do registo pelo nome

Área de foco LEO-PNT: posicionamento de elevada exatidão (posicionamento por ponto preciso, PPP).

kind = "campaign"
title = "PPP convergence against the altitude of a 192-satellite LEO layer"
seed = 20260929
metrics = [
name = "leo_altitude"
key = "case.0.system.0.shell.0.altitude_km"
unit = "km"
start = 500.0

Abrir no Kshana Studio · Ver no GitHub

leo-resilience-gnss-jammed-leo-carries.toml

tipo campaignnão associado a um módulo do registo pelo nome

Missão de resiliência LEO-PNT: GNSS sujeito a jamming, o LEO-PNT suporta o utilizador, integridade mantida.

kind = "campaign"
title = "GNSS jammed, LEO-PNT carries the user, integrity maintained"
seed = 20260929
step_s = 30.0
name = "nominal"
duration_s = 600.0
series = [
kind = "spectrum"

Abrir no Kshana Studio · Ver no GitHub

leo-resilience-multiband-diversity.toml

tipo campaignnão associado a um módulo do registo pelo nome

Resiliência LEO-PNT por diversidade de bandas: um jammer, um recetor de quatro bandas.

kind = "campaign"
title = "LEO-PNT band diversity against an L-band barrage jammer"
seed = 20260929
metrics = [
name = "jammer_power"
key = "jammers.0.received_power_dbw"
unit = "dBW"
start = -140.0

Abrir no Kshana Studio · Ver no GitHub

leo-resilience-spoof-monitors.toml

tipo campaignnão associado a um módulo do registo pelo nome

Resiliência LEO-PNT face a spoofing: que monitor vê que spoofer.

kind = "campaign"
title = "Spoofing monitors against four spoofers"
seed = 20260929
name = "jump"
unit = "m"
value = 30.0
label = "l-band-only"
bind = { jump = "spoofer.offset_m" }

Abrir no Kshana Studio · Ver no GitHub

leo-vertical-5g-network-timing.toml

tipo campaignnão associado a um módulo do registo pelo nome

Vertical LEO-PNT: redes sem fios, temporização de estações de base 5G/6G.

kind = "campaign"
title = "5G base-station timing: holdover and LEO time"
seed = 20260929
step_s = 300.0
name = "gnss-lost"
duration_s = 86400.0
events = [
kind = "telecom-timing"

Abrir no Kshana Studio · Ver no GitHub

leo-vertical-asset-tracking-iot.toml

tipo campaignnão associado a um módulo do registo pelo nome

Vertical LEO-PNT: seguimento de ativos e Internet das Coisas (IoT), energia por solução de posição.

kind = "campaign"
title = "Container tracking with LEO UHF: energy per fix along a journey"
seed = 20260929
step_s = 10.0
name = "port-hamburg"
duration_s = 480.0
series = [
kind = "leo-pass"

Abrir no Kshana Studio · Ver no GitHub

leo-vertical-autonomous-vehicle.toml

tipo campaignnão associado a um módulo do registo pelo nome

Vertical LEO-PNT: veículos autónomos, um canyon urbano com uma camada LEO.

kind = "campaign"
title = "Autonomous vehicle in an urban canyon with a LEO layer"
seed = 20260929
step_s = 10.0
name = "open-road"
duration_s = 600.0
series = [
alarms = [{ channel = "position_error_m", compare = "above", threshold = 1.5 }]

Abrir no Kshana Studio · Ver no GitHub

leo-vertical-autonomous-vehicle-skyline.toml

tipo campaignnão associado a um módulo do registo pelo nome

Vertical LEO-PNT: o canyon urbano de veículos autónomos, como um corte plano e como uma rua.

kind = "campaign"
title = "Autonomous vehicle in an urban canyon: a flat cut-off and a city-street skyline"
seed = 20260929
step_s = 10.0
name = "urban-canyon"
duration_s = 900.0
series = [
alarms = [{ channel = "position_error_m", compare = "above", threshold = 1.5 }]

Abrir no Kshana Studio · Ver no GitHub

leo-vertical-critical-infrastructure-timing.toml

tipo campaignnão associado a um módulo do registo pelo nome

Vertical LEO-PNT: temporização de infraestruturas críticas, holdover com tempo LEO.

kind = "campaign"
title = "Critical infrastructure timing: holdover with LEO time"
seed = 20260929
step_s = 300.0
name = "gnss-locked"
duration_s = 600.0
alarms = []
seed = 42

Abrir no Kshana Studio · Ver no GitHub

leo-vertical-polar-arctic.toml

tipo campaignnão associado a um módulo do registo pelo nome

Vertical LEO-PNT: utilizadores polares e árticos.

kind = "campaign"
title = "Polar and Arctic users with a polar LEO layer"
seed = 20260929
step_s = 60.0
name = "tromso"
duration_s = 3600.0
series = [
alarms = [{ channel = "position_error_m", compare = "above", threshold = 3.0 }]

Abrir no Kshana Studio · Ver no GitHub

leo-vertical-rail-maritime.toml

tipo campaignnão associado a um módulo do registo pelo nome

Vertical LEO-PNT: ferroviário e marítimo, os cenários marítimos e ferroviários incluídos mais LEO.

kind = "campaign"
title = "Railway and maritime with a LEO layer"
seed = 20260929
step_s = 10.0
name = "strait-jammed"
duration_s = 1800.0
kind = "jamming"
seed = 1

Abrir no Kshana Studio · Ver no GitHub

cislunar-arc-recovery#

Teste MODELLED de estimador independente do limiar de observabilidade do comprimento de arco cislunar. Esse limiar é uma leitura de CARACTERÍSTICA sobre a matriz de observabilidade montada a partir das linhas ANALÍTICAS do jacobiano de distância e da matriz de transição de estado variacional ANALÍTICA, e a sua verificação cruzada por filtro de informação em raiz quadrada incorpora essas mesmas linhas — uma verificação de consistência entre duas máquinas numéricas, não uma corroboração. Este tipo de cenário fornece o árbitro que faltava: um estimador de mínimos quadrados em lote que de facto RECUPERA o estado inicial do chefe a partir de medidas simuladas, com as derivadas parciais da medida tomadas como DIFERENÇAS FINITAS CENTRAIS do modelo direto composto. Este não chama nenhuma linha de jacobiano analítico, nenhuma STM variacional, nenhuma decomposição em valores singulares ou autovalores, nenhuma tolerância de característica e nenhum filtro de informação em raiz quadrada — uma guarda de texto-fonte em tests/cislunar_arc_recovery_reference.rs torna isso verificável — enquanto a dinâmica (o mesmo fluxo RK4 do CR3BP), as condições iniciais (a mesma constelação corrigida diferencialmente), o observável escalar e a grelha de épocas são partilhados deliberadamente e nomeados no bloco independence emitido, porque duas análises de um mesmo problema físico precisam concordar quanto à física para serem comparáveis. Dois critérios, cada um varrido ao longo de cinco décadas do seu próprio limite: RECUPERAÇÃO SEM RUÍDO (o erro de estado final de cada tentativa com semente no máximo recovery_factor vezes o seu deslocamento a priori — o análogo da característica, sem nenhuma tolerância de valor singular) e ESTIMABILIDADE POR MONTE CARLO (o erro RMS de posição medido sobre um conjunto de ruído com semente abaixo de um limite declarado — o análogo da estimabilidade, medido e não previsto). Suporta o caso planar de quatro estados e o espacial de seis estados, as famílias DRO / halo L2 / NRHO L2, os observáveis de distância e de taxa de distância, e uma parametrização polar centrada na Lua em que a transformação é aplicada ao ESTADO e o modelo direto é rediferenciado ali. MEASURED na grelha planar de DRO publicada: o estimador recupera o caso de quatro estados a partir de 0,782609 h contra os 2,086957 h do critério de característica em rel_tol 1e-6 (razão 0,375) — o limiar de característica NÃO é corroborado como fronteira de recuperabilidade — enquanto a fronteira de estimabilidade medida cai na mesma célula da grelha que a formal, 5,739130 h, e a curva de erro medida reproduz o 1 sigma formal ao longo de 21 comprimentos de arco com uma razão de média geométrica de 0,98. MODELLED: o projeto da constelação, a grelha de épocas, o único enlace em seguimento, a magnitude do deslocamento, o sigma da medida e os dois limites declarados. Não é um produto de desempenho de navegação certificado.

cislunar-arc-recovery.toml

tipo cislunar-arc-recoverynão associado a um módulo do registo pelo nome

Teste de estimador independente do limiar de observabilidade do comprimento de arco cislunar (R6, artigo B).

kind = "cislunar-arc-recovery"

Abrir no Kshana Studio · Ver no GitHub

cislunar-observability#

Observabilidade MODELLED de constelação cislunar planar (P6): segue uma constelação planar de DRO corrigida diferencialmente, com quatro espaçonaves e alcance intersatélites, e indica quanto do estado de quatro componentes [x,y,ẋ,ẏ] de uma espaçonave o arco torna observável. Emite (1) a tabela de característica contra comprimento de arco para um único enlace só de distância — de característica 1 instantânea, crescendo em direção ao estado completo de quatro componentes à medida que o arco se estende (P6 Tabela 1); (2) o espetro de autovalores do gramiano de observabilidade + o número de condição ao longo do arco; (3) a comparação de característica instantânea só de distância contra distância + taxa de distância (a alavanca de projeto do Doppler) mais o relato de GDOP singular só com distância / definido com distância + taxa; e (4) uma validação cruzada independente por SRIF cuja covariância a posteriori se torna finita / bem condicionada exatamente no arco em que a característica observável chega a quatro. Núcleo VALIDATED: a característica observável é um limiar de valor singular que revela a característica, verificado de forma cruzada contra o característica de autovalores do gramiano; o espetro de autovalores obedece aos invariantes espetrais (traço=Σλ, det=Πλ, Frobenius²=Σλ²); a STM variacional é a STM do CR3BP validada por diferenças finitas; as linhas do jacobiano de distância/taxa de distância são derivadas parciais analíticas validadas por diferenças finitas (verificadas de forma cruzada contra o observável de taxa de distância em 3-D do crate); as quatro condições iniciais são DROs planares corrigidas diferencialmente que fecham com um resíduo de periodicidade estreito e são retrógradas; a transição de característica é validada de forma cruzada contra o filtro de informação em raiz quadrada do crate (covariância a posteriori finita exatamente em característica completa, cond(P)=cond(OᵀO)); um instantâneo com deficiência de característica é sinalizado como GDOP indefinido (fim condition=inf), nunca como um valor finito espúrio — a mesma guarda de geometria singular que pvt::solve_spp aplica. MODELLED: o projeto da constelação (amplitudes e fases do perilúnio dos DROs) e a progressão específica de característica que ele produz. Não é um produto de desempenho de navegação certificado.

cislunar-observability.toml

tipo cislunar-observabilitynão associado a um módulo do registo pelo nome

Observabilidade de uma constelação cislunar planar ao longo de um arco de seguimento (P6).

kind = "cislunar-observability"

Abrir no Kshana Studio · Ver no GitHub

clock#

Holdover do relógio face à especificação; conjunto Monte Carlo opcional (execuções > 1).

clock-ensemble.toml

tipo clocknão associado a um módulo do registo pelo nome

Conjunto Monte Carlo do cenário de holdover do relógio.

seed = 42
threshold_ns = 20.0
runs = 200
step_s = 10.0
duration_s = 7200.0
windows = [
id = "optical-sr-lattice"
provenance = "Strontium optical lattice clock, space-oriented goal sigma_y(1s)=1e-15 (Origlia/Schiller/Bongs et al., arXiv:1503.08457); q_wf=sigma_y(1s)^2; ground-demonstrator maturity, not flown; flicker floor modeled at sigma_y=1e-16"

Abrir no Kshana Studio · Ver no GitHub

clock-fitted-log.toml

tipo clocknão associado a um módulo do registo pelo nome

Um cenário de relógio cujo relógio clássico assume o ruído de um registo medido ([clock_fit]).

seed = 42
threshold_ns = 20.0
step_s = 10.0
duration_s = 7200.0
windows = [
id = "optical-sr-lattice"
provenance = "Strontium optical lattice clock, space-oriented goal sigma_y(1s)=1e-15 (Origlia/Schiller/Bongs et al., arXiv:1503.08457); q_wf=sigma_y(1s)^2; ground-demonstrator maturity, not flown; flicker/aging not modeled"
q_wf = 1.0e-30

Ainda não está no GitHub

clock-holdover.toml

tipo clocknão associado a um módulo do registo pelo nome

Cenário de referência do Kshana: execução de 2 h, 10 min de sincronização GNSS e depois ~1,8 h negadas. Ruído branco de FM do relógio calibrado segundo o sigma_y(1 s) publicado: q_wf = sigma_y(1s)^2. Validado face ao desvio de Allan simulado em tests/calibration.rs (~2%).

seed = 42
threshold_ns = 20.0
step_s = 10.0
duration_s = 7200.0
windows = [
id = "optical-sr-lattice"
provenance = "Strontium optical lattice clock, space-oriented goal sigma_y(1s)=1e-15 (Origlia/Schiller/Bongs et al., arXiv:1503.08457); q_wf=sigma_y(1s)^2; ground-demonstrator maturity, not flown; flicker/aging not modeled"
q_wf = 1.0e-30

Abrir no Kshana Studio · Ver no GitHub

clock-holdover-labsr.toml

tipo clocknão associado a um módulo do registo pelo nome

Variante: relógio ótico de estrôncio de qualidade de laboratório vs CSAC. Os relógios de Sr de laboratório atingem sigma_y(1 s) = 4.8e-17 (Oelker et al. 2019, Nature Photonics).

seed = 42
threshold_ns = 20.0
step_s = 10.0
duration_s = 7200.0
windows = [
id = "optical-lab-sr"
provenance = "Laboratory Sr optical lattice clock, sigma_y(1s)=4.8e-17 (Oelker et al. 2019, Nature Photonics); q_wf=sigma_y(1s)^2; laboratory maturity, not flown; flicker/aging not modeled"
q_wf = 2.304e-33

Abrir no Kshana Studio · Ver no GitHub

clock-measured-log.toml

tipo clocknão associado a um módulo do registo pelo nome

Um cenário de relógio com um registo medido ao lado do holdover simulado ([clock_log]).

seed = 42
threshold_ns = 20.0
step_s = 10.0
duration_s = 7200.0
windows = [
id = "optical-sr-lattice"
provenance = "Strontium optical lattice clock, space-oriented goal sigma_y(1s)=1e-15 (Origlia/Schiller/Bongs et al., arXiv:1503.08457); q_wf=sigma_y(1s)^2; ground-demonstrator maturity, not flown; flicker/aging not modeled"
q_wf = 1.0e-30

Ainda não está no GitHub

combined-altpnt#

Navegador combinado de gravidade + campo magnético + terreno sem GPS: três canais de campo escalares fundidos a cada ponto de passagem para uma correção de deriva mais precisa (CRLB menor) do que qualquer campo isolado.

combined-altpnt.toml

tipo combined-altpntnão associado a um módulo do registo pelo nome

Navegador combinado de gravidade + magnetismo + terreno sem GPS — PNT alternativo fundido.

kind = "combined-altpnt"
start_lat_deg = 12.05
start_lon_deg = 20.05
step_lat_deg = 0.004
step_lon_deg = 0.003
waypoints = 60
drift_lat_deg = 0.5
drift_lon_deg = -0.4

Abrir no Kshana Studio · Ver no GitHub

conflict-resilience#

Resiliência a conflitos MODELLED de PNT em camadas (P7): um utilizador em ambiente contestado dispõe de várias camadas de PNT (GNSS de serviço aberto, GNSS de banda larga, uma constelação autenticada, um relé de aumentação), cada uma com uma disponibilidade-base, uma exatidão de 1σ e uma vulnerabilidade de negação por vetor à ameaça partilhada de jamming/spoofing. Um Monte Carlo COM SEMENTE, varrido em intensidade, nega cada camada com probabilidade clamp(vulnerabilidade·intensidade·peso_do_vetor,0 1), funde as sobreviventes pela regra de forma fechada de variância inversa σ_fused=(Σ 1/σ_i²)^(−1/2), e indica a probabilidade de perda total (todas as camadas negadas), o erro fundido mediano e estatísticas de utilizável/negada por camada em função da intensidade. A razão de resiliência principal (probabilidade de perda total de camada única contra em camadas) chega a cerca de 7x sob a hipótese de INDEPENDÊNCIA; um varrimento de negação correlacionada por cópula gaussiana de um fator mostra então esse ~7x a colapsar para 1 à medida que a correlação da negação aumenta (a correlação derrota a estratificação em camadas). Um bloco de sensibilidade a priors varia o valor principal sobre os priors de vulnerabilidade COM FONTE por meio do tornado mcda + uma realocação de esforço de ameaça de Dirichlet + ICs por percentis. Núcleo VALIDATED: a perda total por Monte Carlo converge para o produto independente de forma fechada Π_i p_deny_i (dentro do erro-padrão do MC com semente fixa e N grande); a fusão por variância inversa é uma identidade de forma fechada; em ρ=0 a cópula reduz-se ao modelo independente e qualquer ρ preserva a taxa de negação marginal de cada camada. MODELLED: as magnitudes de vulnerabilidade/disponibilidade/exatidão por camada são entradas com fonte, porém modeladas (JammerTest 2024, TEXBAT, EASA SIB, RTCA DO-229, LunaNet/IOAG — ver conflict_threat_params), e a magnitude específica de ~7x e a forma da curva razão-versus-correlação decorrem dessa parametrização. Uma decomposição da sobrevivência por vetor, na secção § 4,2, resolve então a ameaça de RF partilhada nos quatro vetores nomeados (jamming/spoofing/cinético/cibernético) e indica a curva de degradação gradual de PNT utilizável de cada vetor S_v(x)=1-Prod_i(1-a_i(1-clamp(susceptibilidade_i,v·x,0 1))) — VALIDATED: o Monte Carlo por camada com semente converge para essa forma fechada; o jamming é o vetor mais severo para a linha de base de RF correlacionada e a camada inercial, imune a RF, é a sobrevivente decisiva. Não é um produto de disponibilidade de navegação certificado.

conflict-resilience.toml

tipo conflict-resiliencenão associado a um módulo do registo pelo nome

Resiliência a conflitos de PNT em camadas (artigo P7).

kind = "conflict-resilience"
trials = 4000
seed = 20260709
primary_layer = 0
min = 0.0
max = 1.0
steps = 11
values = [0.0, 0.2, 0.4, 0.6, 0.8, 0.95]

Abrir no Kshana Studio · Ver no GitHub

constellation-design#

Projeto de constelações à escala: padrões Walker DELTA e Walker STAR na convenção i: T/P/F (nós distribuídos por 360 ou 180 deg, espaçamento no plano 360*P/T, desfasamento de fase entre planos 360*F/T), listas explícitas de elementos e projetos com várias camadas, várias constelações numa só execução, em torno da Terra, da Lua, de Marte ou de qualquer outro planeta, de Plutão ou de uma lua importante, usando as constantes do módulo body (as mesmas que os tipos de cenário solar-system e body-pnt usam). PREDEFINIÇÕES a partir de elementos nominais publicados: gps-baseline e gps-expandable (as 24 posições e os seis pares expansíveis à frente/atrás do GPS Standard Positioning Service Performance Standard, 5.ª edição 2020, Tabelas 3.2-1 a 3.2-3), galileo (Walker 24/3/1 a 29 599,801 km e 56 deg, Galileo Open Service Service Definition Document edição 1,1 Tabelas 1 e 23), beidou e beidou-meo (Walker 24/3/1 a 21 528 km e 55 deg mais três satélites geoestacionários a 80, 110,5 e 140 deg E e três satélites geossíncronos inclinados a 55 deg, BeiDou Open Service Performance Standard 3,0 secção 4,1; a fase MEO e o cruzamento geossíncrono inclinado a 118 deg E são modelados porque a norma não os indica) e glonass (24/3/1 a 19 100 km e 64,8 deg a partir da fórmula de posições do GLONASS Interface Control Document edição 5,1 secção 5,2). COBERTURA E DILUIÇÃO DA PRECISÃO: sobre uma grelha de latitude/longitude e uma janela amostrada com uma máscara de elevação, o número de satélites à vista, GDOP, PDOP, HDOP e VDOP por célula, a disponibilidade (uma posição calculada com PDOP igual ou inferior a um limiar, 6 por predefinição) por célula, globalmente (ponderada por área) e no pior local, com um relógio de recetor por constelação, salvo clock = "common". Escala para milhares de satélites: a visibilidade é um produto escalar com o semiângulo de cobertura de cada satélite, e os satélites são agrupados por latitude subsatélite em cada época, de modo que uma linha da grelha só testa os que podem estar à vista; o relatório conta os testes de pares poupados. O JSON traz os mapas da grelha e as trajetórias à superfície por satélite subamostradas. VALIDATED: o gerador Walker face à Tabela 23 do Galileo OS SDD e à fórmula de posições do ICD do GLONASS, a predefinição GPS face à coluna publicada de cruzamento do equador da Tabela 3.2-1 do SPS PS, e a distribuição global de HDOP da linha de base GPS face ao Apêndice B do SPS PS (mediana 0,94, 95% 1,25, média 0,96, tolerância 0,03). MODELLED: órbitas de dois corpos com J2 secular opcional, um corpo esférico, apenas visibilidade geométrica (sem potência de sinal, estado de saúde nem terreno), e a fase relativa entre sistemas diferentes, que não é um instantâneo de nenhuma data real.

constellation-multi-gnss-coverage.toml

tipo constellation-designnão associado a um módulo do registo pelo nome

Cobertura multiconstelação: os quatro sistemas globais de navegação por satélite (GNSS) em conjunto, como um mapa de satélites à vista, diluição da precisão (DOP) e disponibilidade em toda a Terra durante um dia.

kind = "constellation-design"
body = "earth"
duration_s = 86164.0
step_s = 900.0
mask_deg = 10.0
pdop_threshold = 6.0
grid_step_deg = 10.0
clock = "per-constellation"

Abrir no Kshana Studio · Ver no GitHub

leo-pnt-mega-shell.toml

tipo constellation-designnão associado a um módulo do registo pelo nome

Uma megaconstelação de posicionamento, navegação e tempo (PNT) em órbita terrestre baixa: 5 000 satélites em quatro camadas Walker, pontuada como um mapa de cobertura e de diluição da precisão (DOP).

kind = "constellation-design"
body = "earth"
duration_s = 7200.0
step_s = 600.0
mask_deg = 20.0
pdop_threshold = 3.0
grid_step_deg = 10.0
clock = "common"

Abrir no Kshana Studio · Ver no GitHub

lunar-relay-constellation.toml

tipo constellation-designnão associado a um módulo do registo pelo nome

Uma constelação lunar de retransmissão e navegação: satélites em órbitas lunares elípticas congeladas (ELFO) mais uma camada circular em órbita lunar baixa, pontuada como um mapa de cobertura e de diluição da precisão (DOP) sobre toda a Lua durante um dia.

kind = "constellation-design"
body = "moon"
duration_s = 86400.0
step_s = 1800.0
mask_deg = 10.0
pdop_threshold = 6.0
grid_step_deg = 10.0
clock = "common"

Abrir no Kshana Studio · Ver no GitHub

contact-schedule#

Planeamento de contactos com o solo para vários satélites sobre várias estações: janelas de acesso aparentes (SGP4, referencial fixo à Terra IAU 2006/2000A, refração ITU-R P.834, tempo de luz), o volume de dados DVB-S2 ACM de cada passagem (limiares da Tabela 13 da ETSI EN 302 307-1) e um calendário sem conflitos (um satélite por antena com um tempo de retorno, uma estação por satélite, entrega ponderada por prioridade limitada a cada backlog) por um método guloso de valor marginal, uma linha de base de ordem de chegada e um branch and bound exato em conjuntos pequenos, com a lacuna de otimalidade do método guloso. MODELLED.

contact-schedule.toml

tipo contact-schedulenão associado a um módulo do registo pelo nome

Planeamento de contactos com a terra: três satélites ilustrativos sobre três estações ilustrativas durante 12 horas. A execução dá a cada passagem satélite-estação a sua janela de acesso e o volume de dados que a codificação e modulação adaptativas (ACM) DVB-S2 pode transferir nela (limiares da ETSI EN 302 307-1 Tabela 13 mais uma margem de implementação). Constrói depois um plano de contactos sem conflitos em que cada antena serve um satélite de cada vez, com um tempo de rotação entre contactos, e cada satélite emite para uma estação de cada vez. A entrega é ponderada por prioridade e limitada ao atraso acumulado de cada satélite. São comunicados três planos lado a lado: um algoritmo guloso de valor marginal, uma linha de base por ordem de chegada e, quando o conjunto de candidatos é pequeno, o ótimo exato, com a lacuna de otimalidade do guloso.

kind = "contact-schedule"
epoch = [2024.0, 1.0, 1.0, 0.0, 0.0, 0.0]
duration_hours = 12.0
step_s = 30.0
refraction = true
light_time = true
frequency_ghz = 8.2
eirp_dbw = 7.0

Abrir no Kshana Studio · Ver no GitHub

earth-gnss-lunar#

Receção de GNSS da Terra à distância lunar, a camada de sinal fraco que o artigo sobre resiliência a conflitos nomeia e para a qual o motor não tinha modelo. Um satélite GNSS aponta a sua antena para a Terra; um recetor perto da Lua fica a cerca de quinze vezes o raio orbital de distância, de modo que três coisas pesam ao mesmo tempo. A Terra OCULTA O EIXO DE VISADA: a partir de 26 560 km ela subtende um semiângulo de 13,9 graus, de modo que qualquer raio dirigido à Lua deve deixar o transmissor com pelo menos esse afastamento do nadir, o que remove o pico do feixe antes de qualquer potência ser calculada. O que resta são A ORLA DO LÓBULO PRINCIPAL E OS LÓBULOS LATERAIS, o regime em que a carga útil LuGRE realmente operou em 2025. E a perda no espaço livre é de cerca de 208 dB em L1, aproximadamente 25 dB a mais do que um utilizador terrestre paga. O relatório emite uma linha por satélite (ângulo fora do eixo, ocultação pela Terra, distância, perda de percurso, ganho de transmissão nesse ângulo, potência recebida, densidade de portadora sobre ruído) e agrega apenas os enlaces que superam o limiar de seguimento. TAMBÉM INDICA O CONDICIONAMENTO, porque é isso que define esta camada: cada satélite visível está dentro de um cone de poucos graus de largura visto da Lua, de modo que as linhas de visada são quase paralelas, a diluição de precisão é enorme, e uma solução de GNSS da Terra à distância lunar é uma observação de grau de TEMPORIZAÇÃO muito mais do que de grau de posição. MODELLED, e o diagrama de transmissão é o motivo: o ganho em função do ângulo é uma abertura circular uniforme (Airy), enquanto uma antena GPS L1 real é um arranjo helicoidal de doze elementos com um lóbulo principal moldado e lóbulos laterais que não são de Airy. Existem diagramas medidos e eles não estão incluídos aqui, de modo que ordenações e ordens de grandeza são significativas, mas o dB de um único satélite não é. DELIBERADAMENTE AUSENTES, cada uma tornando o balanço otimista: nenhuma perda ionosférica ou troposférica nos raios rasantes ao limbo, nenhuma perda por polarização, apontamento ou implementação, e uma Terra esférica sem extensão refrativa. A posição da Lua é uma ENTRADA (distância mais direção inercial) em vez de uma consulta a efemérides, porque a grandeza sob teste é o enlace e a geometria do feixe. Elevar esta linha a validada exige um diagrama de transmissão medido e pontos normais do LuGRE; nenhum dos dois está no repositório e nenhum é inventado aqui.

earth-gnss-lunar.toml

tipo earth-gnss-lunaras linhas do tipo de cenário no registo são modeladas · 0 de 1 linhas validadas

Receção de GNSS terrestre à distância lunar.

kind = "earth-gnss-lunar"
altitude_km = 20180.0
inclination_deg = 55.0
planes = 6
sats_per_plane = 4
phasing_f = 2.0
epoch_s = 0.0
receiver_range_m = 384400000.0

Abrir no Kshana Studio · Ver no GitHub

entry-heating#

Entrada atmosférica de massa pontual em 3-DoF sobre uma Terra esférica em rotação ou Marte (balística ou com sustentação a inclinação lateral constante), RK4, através da US76, de uma atmosfera exponencial ou da atmosfera de Marte, com aquecimento convectivo no ponto de estagnação de Sutton-Graves (NASA TR R-376): desaceleração de pico, fluxo de calor e pressão dinâmica, carga térmica, alcance longitudinal, uma verificação de energia no referencial em rotação e a forma fechada de Allen-Eggers ao lado. A desaceleração de pico é conferida contra o valor nominal publicado da Stardust; o aquecimento é MODELLED.

entry-heating-stardust.toml

tipo entry-heatingnão associado a um módulo do registo pelo nome

Entrada da cápsula de retorno de amostras Stardust: o caso publicado face ao qual o tipo de cenário entry-heating é verificado (xval/entry-stardust/PREREGISTRATION.md; tests/entry_stardust_published.rs).

kind = "entry-heating"
body = "earth"
atmosphere = "us76"
entry_interface_altitude_m = 125003.0
velocity_frame = "inertial"
entry_speed_m_s = 12900.0
flight_path_angle_deg = 8.2
latitude_deg = 41.0

Abrir no Kshana Studio · Ver no GitHub

eo-coverage#

Pegada da carga útil de observação da Terra e geometria de cobertura (triângulo espacial do SMAD): raio angular da Terra, largura da faixa imageada, distância de amostragem no solo no nadir, acesso máximo fora do nadir, período circular, período nodal com J2 e espaçamento equatorial do traço no solo com um indicador de cobertura contígua, para uma altitude orbital, uma inclinação (heliossíncrona por predefinição) e um FOV/IFOV do sensor. Geometria de Terra esférica MODELLED (sem radiometria/MTF/atmosfera/jitter/reflexo solar); espaçamento de nós R_e·(ω − Ω̇)·T_nodal com taxas seculares de J2 de primeira ordem.

eo-coverage.toml

tipo eo-coveragenão associado a um módulo do registo pelo nome

Demonstrador de pegada e cobertura da carga útil de observação da Terra (triângulo espacial SMAD).

kind = "eo-coverage"
altitude_km = 700.0
half_fov_deg = 7.5
ifov_microrad = 14.0
max_off_nadir_deg = 45.0

Abrir no Kshana Studio · Ver no GitHub

eo-radiometry#

Radiometria de imageador no nadir e qualidade de imagem: radiância na abertura de uma cena lambertiana, a equação da câmara, sinal e ruído de disparo/escuro/leitura/quantização e SNR; a MTF do sistema em Nyquist (difração x detector x arrasto x jitter), a resposta relativa de borda a partir dela, Q = lambda F/p e o NIIRS da GIQE versão 4 sem compensação de MTF. MODELLED.

eo-radiometry.toml

tipo eo-radiometrynão associado a um módulo do registo pelo nome

Radiometria e qualidade de imagem de um gerador de imagens no nadir para uma pequena câmara de observação da Terra ILLUSTRATIVE (sem projeto de nenhum operador): abertura de 0,40 m, distância focal de 3,6 m (F/9), píxeis de 5,5 um, a partir de 500 km. A execução dá o orçamento de relação sinal-ruído de uma cena de reflectância de 15 %, a MTF do sistema em Nyquist, a resposta relativa de arestas e a NIIRS da versão 4 do GIQE. MODELLED: a NIIRS é uma regressão empírica avaliada sobre entradas modeladas, não uma imagem classificada.

kind = "eo-radiometry"
altitude_m = 500000.0
focal_length_m = 3.6
aperture_m = 0.40
pixel_pitch_um = 5.5
wavelength_um = 0.65
bandwidth_um = 0.2
fill_factor = 1.0

Abrir no Kshana Studio · Ver no GitHub

ephemeris#

Efemérides e traço no solo: propaga um satélite (TLE→SGP4 ou órbita analítica) e emite o seu estado TEME/GCRS (posição + velocidade), a posição ITRF/ECEF, latitude/longitude/altitude subsatélite WGS-84 e, a cada passo, azimute/elevação/distância da estação + taxa de variação da distância (Doppler). O satélite vem de um tle ou de uma orbit analítica com a sua epoch (um tle prevalece quando ambos são dados); com um tle, um epoch substitui a própria época do TLE como t = 0.

ephemeris.toml

tipo ephemerisnão associado a um módulo do registo pelo nome

Efemérides e traço no solo — "onde está o satélite neste momento".

kind = "ephemeris"
tle = """
step_s = 30.0
duration_s = 16740.0
xp_arcsec = 0.0
yp_arcsec = 0.0
lat_deg = 49.8707
lon_deg = 8.6217

Abrir no Kshana Studio · Ver no GitHub

fusion#

PNT por fusão de sensores com filtro de Kalman conjunto sobre as mesmas entradas híbridas.

fusion-pnt.toml

tipo fusionnão associado a um módulo do registo pelo nome

PNT de fusão conjunta de sensores: um único filtro de Kalman é o navegador, a fundir os estados do relógio e inerciais e auxiliado pela transferência de tempo ótica ISL, em vez de compor preditores independentes. GNSS negado 1,8 h.

kind = "fusion"
seed = 42
timing_spec_ns = 20.0
position_spec_m = 100.0
step_s = 10.0
duration_s = 7200.0
windows = [
enabled = true

Abrir no Kshana Studio · Ver no GitHub

fusion-pnt-coupled.toml

tipo fusionnão associado a um módulo do registo pelo nome

PNT de fusão conjunta de sensores acoplada: os mesmos conjuntos e a mesma interrupção do GNSS que fusion-pnt.toml, mas o navegador é UM filtro de Kalman empilhado sobre posição, velocidade, fase do relógio, frequência do relógio e o viés do acelerómetro (a tabela [coupled]). Enquanto o GNSS é nominal, recebe pseudodistâncias, cada uma rho = g * position + c * clock phase + noise ao longo de um fator de linha de vista g, de modo que uma única medição restringe em conjunto a posição e o relógio e o filtro mantém a sua covariância cruzada; as ressincronizações por transferência de tempo ótica durante a interrupção são pseudodistâncias só de relógio. Os acelerómetros aqui têm um viés constante, que o estado de viés aprende antes da interrupção (fusion-pnt.toml anula os viés porque os seus filtros não têm estado de viés). Neutro quanto a fabricantes; parâmetros do relógio e do ruído como em fusion-pnt.toml, os viés são ilustrativos. MODELLED.

kind = "fusion"
seed = 42
timing_spec_ns = 20.0
position_spec_m = 100.0
step_s = 10.0
duration_s = 7200.0
windows = [
enabled = true

Abrir no Kshana Studio · Ver no GitHub

gnss-ins#

EKF de estado de erro GNSS/INS com acoplamento fraco e forte.

automotive-urban-canyon.toml

tipo gnss-insnão associado a um módulo do registo pelo nome

Veículo rodoviário num desfiladeiro urbano: navegação à estima GNSS/INS ao longo de uma passagem inferior e de um emissor de jamming junto à estrada, face a um orçamento ao nível da faixa de rodagem.

kind = "gnss-ins"
seed = 7
threshold_m = 1.5
fix_interval_s = 1.0
sigma_pos_m = 1.0
sigma_vel_mps = 0.05
lat_deg = 48.137
lon_deg = 11.575

Abrir no Kshana Studio · Ver no GitHub

gnss-ins.toml

tipo gnss-insnão associado a um módulo do registo pelo nome

GNSS/INS de acoplamento fraco: o navegador strapdown de três eixos disciplinado por um EKF de estado de erro de 15 estados, que depois segue em inércia durante uma interrupção do GNSS de 60 s. Ao contrário do pacote inertial (um navegador à estima escalar de 1 grau de liberdade com uma reposição à referência em cada posição calculada), este executa o verdadeiro filtro em malha fechada: aprende com posições calculadas ruidosas enquanto o GNSS está disponível e segue em inércia sobre o estado corrigido durante a interrupção. O erro comunicado é o verdadeiro resíduo horizontal face à referência; cada sensor traz também o seu RMS de INS livre em malha aberta, de modo que o valor do filtro fique explícito.

kind = "gnss-ins"
seed = 7
threshold_m = 50.0
fix_interval_s = 1.0
sigma_pos_m = 1.0
sigma_vel_mps = 0.05
lat_deg = 45.0
lon_deg = -57.3

Abrir no Kshana Studio · Ver no GitHub

gnss-ins-aviation.toml

tipo gnss-insnão associado a um módulo do registo pelo nome

GNSS/INS de aviação com acoplamento forte: uma aeronave ligeira descola, sobe a 6 deg, nivela e faz uma curva coordenada com inclinação de 25 deg (perfil de trajetória aircraft); o GNSS é negado durante dois minutos que cobrem a curva, a parte mais difícil de um trecho em inércia porque os erros de rumo e de atitude são então projetados na horizontal. Acoplamento forte ([tight]) sobre uma constelação Walker SGP4 do tipo GPS.

kind = "gnss-ins"
seed = 13
threshold_m = 100.0
fix_interval_s = 1.0
sigma_pos_m = 3.0
sigma_vel_mps = 0.1
lat_deg = 52.0
lon_deg = 5.0

Abrir no Kshana Studio · Ver no GitHub

gnss-ins-maritime.toml

tipo gnss-insnão associado a um módulo do registo pelo nome

GNSS/INS marítimo: uma embarcação a 8 m/s (cerca de 15,5 nós) a descrever círculos completos a 1 deg/s, e depois uma interrupção do GNSS de cinco minutos, no mesmo filtro GNSS/INS de 15 estados em malha fechada que gnss-ins.toml. O movimento vem da biblioteca de trajetórias ([trajectory], perfil figure8): viragem lenta e constante, o regime de um navio e não de um automóvel.

kind = "gnss-ins"
seed = 11
threshold_m = 50.0
fix_interval_s = 1.0
sigma_pos_m = 2.0
sigma_vel_mps = 0.1
lat_deg = 54.0
lon_deg = 10.0

Abrir no Kshana Studio · Ver no GitHub

gnss-ins-rail.toml

tipo gnss-insnão associado a um módulo do registo pelo nome

GNSS/INS ferroviário com acoplamento forte: um comboio circula entre paragens a 30 m/s com curvas suaves de 20 deg (perfil de trajetória stop_go), passa por uma trincheira profunda onde apenas dois satélites permanecem à vista, e depois por um túnel de dois minutos. O recetor tem acoplamento forte ([tight]): continua a fundir as pseudodistâncias dos dois satélites que ainda segue na trincheira, onde um recetor de acoplamento fraco não tem qualquer posição calculada. Os satélites provêm de uma constelação Walker SGP4 do tipo GPS.

kind = "gnss-ins"
seed = 12
threshold_m = 30.0
fix_interval_s = 1.0
sigma_pos_m = 2.0
sigma_vel_mps = 0.1
lat_deg = 48.0
lon_deg = 11.0

Abrir no Kshana Studio · Ver no GitHub

small-uas-jammed-nav.toml

tipo gnss-insnão associado a um módulo do registo pelo nome

Pequena aeronave não tripulada sob jamming de GNSS: quanto deriva uma unidade inercial MEMS da classe de um controlador de voo depois de o recetor perder o bloqueio, face a uma unidade de grau tático, no mesmo filtro GNSS/INS em malha fechada que gnss-ins.toml.

kind = "gnss-ins"
seed = 7
threshold_m = 50.0
fix_interval_s = 1.0
sigma_pos_m = 1.0
sigma_vel_mps = 0.05
lat_deg = 59.437
lon_deg = 24.745

Abrir no Kshana Studio · Ver no GitHub

gnss-sim#

Simulação de pseudodistância no domínio da medição (ionosfera de Klobuchar, troposfera de Saastamoinen/Niell) + RAIM.

gnss-sim-container-terminal-skyline.toml

tipo gnss-simnão associado a um módulo do registo pelo nome

Pseudodistâncias e RAIM para um carregador de pórtico num cais de contentores, com gruas de cais do lado do mar e pilhas de contentores do lado de terra: o cenário gnss-sim sob a predefinição de linha de horizonte container-terminal.

kind = "gnss-sim"
seed = 7
mask_deg = 5.0
noise_sigma_m = 1.5
multipath_m = 0.5
sat_clock_rms_m = 30.0
uere_m = 3.0
p_fa = 1.0e-5

Abrir no Kshana Studio · Ver no GitHub

gnss-sim-raim.toml

tipo gnss-simnão associado a um módulo do registo pelo nome

Simulação GNSS no domínio das medições: pseudodistâncias com atrasos ionosféricos e troposféricos, fornecidas ao RAIM instantâneo para níveis de proteção.

kind = "gnss-sim"
seed = 7
mask_deg = 5.0
noise_sigma_m = 1.5
multipath_m = 0.5
sat_clock_rms_m = 30.0
uere_m = 3.0
p_fa = 1.0e-5

Abrir no Kshana Studio · Ver no GitHub

gnss-ssv#

Disponibilidade e intensidade de enlace de GNSS MODELLED no Space Service Volume e além: para um utilizador numa esfera (a camada global do folheto do ICG) ou numa trajetória kepleriana (de LEO a transferência lunar), conta, por constelação (GPS, GLONASS, Galileo, BDS, QZSS, NavIC) e para todas em conjunto, os sinais utilizáveis acima de um limiar de C/N0 - disponibilidade de pelo menos um e de quatro sinais, duração máxima de interrupção, C/N0 recebido, diluição de precisão, enlaces de lóbulo principal contra lóbulo lateral - com um diagrama de transmissão do folheto, paramétrico ou fornecido pelo utilizador, efeitos opcionais de ionosfera, plasmasfera e atmosfera em raios rasantes ao limbo e um projeto opcional de recetor de sinal fraco; também um filtro de Kalman estendido de GNSS a bordo para naves em HEO e em transferência lunar (dinâmica orbital, pressão de radiação solar, terceiros corpos, relógio) e a navegação relativa de uma formação de várias naves por pseudodistâncias de diferença simples. Conferido contra as tabelas do folheto SSV do ICG sob um pré-registo (xval/gnss-ssv)

gnss-ssv-formation-heo.toml

tipo gnss-ssvnão associado a um módulo do registo pelo nome

Navegação relativa de uma formação de três veículos na órbita altamente elíptica do caderno.

kind = "gnss-ssv"
name = "HEO formation relative navigation (reduced length)"
include = ["gps", "glonass", "galileo", "bds"]
bands = ["l1", "l5"]
preset = "heo"
duration_min = 400.0
step_s = 60.0
antennas = ["booklet-high-gain-nadir", "booklet-patch-zenith"]

Abrir no Kshana Studio · Ver no GitHub

gnss-ssv-heo.toml

tipo gnss-ssvnão associado a um módulo do registo pelo nome

Uma órbita altamente elíptica através das órbitas GNSS: o que um utilizador vê do perigeu ao apogeu.

kind = "gnss-ssv"
name = "HEO, high-gain nadir and patch zenith antennas, parametric sidelobes, limb medium"
include = ["gps", "glonass", "galileo", "bds"]
bands = ["l1", "l5"]
pattern = "parametric"
preset = "heo"
duration_periods = 1.0
step_min = 10.0

Abrir no Kshana Studio · Ver no GitHub

gnss-ssv-lunar-weak.toml

tipo gnss-ssvnão associado a um módulo do registo pelo nome

GNSS numa transferência lunar, com um recetor de sinais fracos que ganha a sua sensibilidade.

kind = "gnss-ssv"
name = "Lunar transfer, weak-signal receiver, parametric sidelobes"
include = ["gps", "galileo", "glonass", "bds"]
bands = ["l1", "l5"]
pattern = "parametric"
apply = "acquisition"
t_coh_s = 0.1
n_noncoherent = 100.0

Abrir no Kshana Studio · Ver no GitHub

gnss-ssv-nav-lunar.toml

tipo gnss-ssvnão associado a um módulo do registo pelo nome

Navegação GNSS a bordo a caminho da Lua: um filtro de Kalman estendido só com pseudodistâncias.

kind = "gnss-ssv"
name = "Lunar transfer, onboard GNSS EKF (reduced length)"
include = ["gps", "glonass", "galileo", "bds"]
bands = ["l1", "l5"]
preset = "lunar-transfer"
duration_min = 1440.0
step_s = 300.0
antennas = ["booklet-high-gain-nadir", "booklet-patch-zenith"]

Abrir no Kshana Studio · Ver no GitHub

gnss-ssv-shell.toml

tipo gnss-ssvnão associado a um módulo do registo pelo nome

Disponibilidade do sinal GNSS na camada SSV superior: a métrica global do caderno, num tamanho que executa num segundo.

kind = "gnss-ssv"
name = "Upper SSV shell, 20 dB-Hz (reduced size)"
include = ["gps", "glonass", "galileo", "bds"]
bands = ["l1", "l5"]
altitude_km = 36000.0
antenna = "hemisphere"
grid_levels = 2
duration_min = 4320.0

Abrir no Kshana Studio · Ver no GitHub

gravity-map#

Navegação por correspondência com mapa de gravidade sem GPS: um gravímetro de átomos frios recupera uma deriva constante do INS a partir da sequência de anomalias de gravidade pela qual voa.

gps-denied-gravity-nav.toml

tipo gravity-mapnão associado a um módulo do registo pelo nome

Benchmark de correspondência de mapa gravimétrico de 60 minutos sem GPS (PNT alternativo quântico).

kind = "gravity-map"
nmax = 3
start_lat_deg = 10.0
start_lon_deg = 20.0
step_lat_deg = 0.06
step_lon_deg = 0.045
waypoints = 90
drift_lat_deg = 0.5

Abrir no Kshana Studio · Ver no GitHub

gps-denied-gravity-nav-egm2008.toml

tipo gravity-mapnão associado a um módulo do registo pelo nome

Benchmark de correspondência de mapa gravimétrico de 60 minutos sem GPS sobre o campo gravítico REAL (WP-10, RM-17).

kind = "gravity-map"
nmax = 3
start_lat_deg = 10.0
start_lon_deg = 20.0
step_lat_deg = 0.06
step_lon_deg = 0.045
waypoints = 90
drift_lat_deg = 0.5

Abrir no Kshana Studio · Ver no GitHub

gravity-map-error-mc.toml

tipo gravity-mapnão associado a um módulo do registo pelo nome

Monte Carlo do erro de mapa sobre o benchmark de mapa gravimétrico de 60 minutos sem GPS (WP-10, RM-15).

kind = "gravity-map"
nmax = 3
start_lat_deg = 10.0
start_lon_deg = 20.0
step_lat_deg = 0.06
step_lon_deg = 0.045
waypoints = 90
drift_lat_deg = 0.5

Abrir no Kshana Studio · Ver no GitHub

gravity-map-nav.toml

tipo gravity-mapnão associado a um módulo do registo pelo nome

Cenário de navegação quântica por correspondência de mapa gravimétrico (PNT alternativo sem GPS).

kind = "gravity-map"
nmax = 3
start_lat_deg = 12.0
start_lon_deg = 24.0
step_lat_deg = 0.18
step_lon_deg = 0.13
waypoints = 12
drift_lat_deg = 0.55

Abrir no Kshana Studio · Ver no GitHub

holdover-test#

Teste de holdover MODELLED de um sistema de temporização, pontuado a partir de um registo de erro de tempo que o OPERADOR fornece (um log do ptp4l, phc2sys ou ts2phc do linuxptp, um log de tracking ou statistics do chrony, um log de relógio TICC, TimeLab ou RINEX, ou pares time_s,time_error_ns). O teste tem quatro etapas e o Kshana não executa nenhuma delas: uma LINHA DE BASE bloqueada, GNSS REMOVIDO pelo operador (o cabo da antena ou a saída do simulador; o Kshana não transmite nem aciona nada) num instante declarado, HOLDOVER no oscilador próprio do sistema e RECUPERAÇÃO depois de o operador restabelecer o GNSS num segundo instante declarado. O registo é dividido nesses dois instantes. Linha de base: estatísticas de erro de tempo e as máscaras da ITU-T escritas para um relógio bloqueado. Holdover: estatísticas, o desvio fracionário de frequência que o sistema manteve (uma reta de mínimos quadrados), as máscaras escritas para holdover ou para um relógio autónomo, o envelope de holdover do ePRTC-A a partir da duração bloqueada declarada e o tempo para exceder cada orçamento de erro de tempo. Recuperação: se e quando |TE| entrou numa banda declarada e permaneceu nela, o pico e o maior degrau. Cada limite é transcrito de uma tabela pública da ITU-T (as máscaras de temporização de telecomunicações); as palavras são 'medido em relação à máscara', e os dois instantes são uma declaração do operador, não verificada. Um registo curto demais para uma máscara é INCOMPLETE, nunca extrapolado. Ver docs/TIMING-HIL.md.

holdover-test-example.toml

tipo holdover-testnão associado a um módulo do registo pelo nome

Teste de holdover, exemplo de ingestão: um registo de erro de tempo pontuado pelo tipo de cenário holdover-test ("retirar a antena, pontuar o holdover"). O registo é dividido nos dois instantes que o OPERADOR indica, aqui o GNSS retirado aos 600 s e restabelecido aos 2 400 s, e cada passo é medido face às máscaras ITU-T escritas para ele.

kind = "holdover-test"
masks = ["prtc-a", "eprtc-a-holdover"]
gnss_removed_s = 600.0
gnss_restored_s = 2400.0
locked_duration_days = 5.0
recovery_band_ns = 100.0
recovery_dwell_s = 60.0
samples = [

Abrir no Kshana Studio · Ver no GitHub

holdover-test-ptp4l.toml

tipo holdover-testnão associado a um módulo do registo pelo nome

Teste de holdover de um registo linuxptp: os mesmos quatro passos que holdover-test-example.toml, com o registo lido de um registo de servo ptp4l através de [series.clock_log] (format "ptp4l", desvios em ns, as marcas temporais do próprio daemon, aqui com 5 s de intervalo).

kind = "holdover-test"
masks = ["prtc-a", "eprtc-a-holdover"]
gnss_removed_s = 600.0
gnss_restored_s = 2400.0
locked_duration_days = 5.0
recovery_band_ns = 100.0
recovery_dwell_s = 60.0
format = "ptp4l"

Abrir no Kshana Studio · Ver no GitHub

hybrid#

Capstone de PNT híbrido: relógio + IMU + auxílio por transferência de tempo.

hybrid-pnt.toml

tipo hybridnão associado a um módulo do registo pelo nome

Pedra angular de PNT híbrido: conjunto totalmente quântico (relógio ótico + IMU de átomos frios + auxílio por transferência de tempo ótica ISL) vs conjunto totalmente clássico (CSAC + IMU de qualidade de navegação + RF). GNSS negado 1,8 h.

kind = "hybrid"
seed = 42
timing_spec_ns = 20.0
position_spec_m = 100.0
step_s = 10.0
duration_s = 7200.0
windows = [
enabled = true

Abrir no Kshana Studio · Ver no GitHub

hybrid-optical-rf#

Figura de mérito conjunta de PNT ótico + RF heterogéneo MODELLED (P5): compõe o balanço de enlace ótico bidirecional de 1550 nm (CRLB de medição de distância bidirecional limitada por fótons σ_τ/√N e pegada de difração λ/D·distância), um nível de proteção RAIM de separação de soluções entre modalidades (posição E temporização) que funde as soluções de RF frouxa e ótica estreita com covariâncias díspares, a disponibilidade de céu claro ótica de N estações (união independente 1−Π(1−a_i) e uma variante espacialmente correlacionada), uma transferência de estado/covariância ótico↔RF com uma média COMPROVADAMENTE contínua bit a bit (sem salto) e uma barreira de consistência NEES χ², e uma pontuação conjunta de P(disponível E de grau de precisão E com integridade assegurada) com tratamento de correlação. Forma fechada VALIDATED: o CRLB de medição de distância, a pegada de difração, o quantil de nível de proteção χ², a combinatória da união, a continuidade da média da transferência + a barreira NEES e o produto independente conjunto. MODELLED: as alocações de perda ótica, as magnitudes de σ de RF/ótico, as entradas de climatologia de nuvens, as correlações e o orçamento de P_HMI. Não é um produto de disponibilidade/integridade certificado.

hybrid-optical-rf.toml

tipo hybrid-optical-rfnão associado a um módulo do registo pelo nome

Disponibilidade / precisão / integridade conjuntas de PNT heterogéneo ótico + RF (P5).

kind = "hybrid-optical-rf"
wavelength_nm      = 1550.0
tx_power_w         = 1.0e-3
tx_aperture_m      = 0.85
rx_aperture_m      = 0.85
range_km           = 384000.0
pulse_rms_ps       = 50.0
integration_s      = 1.0

Abrir no Kshana Studio · Ver no GitHub

hybrid-ukf#

UKF GNSS/INS híbrido quântico+clássico com acoplamento forte e 17 estados (MODELLED): 15 estados de erro do INS + correção de viés do acelerómetro derivada de CAI + um relógio de 2 estados (fase+frequência) do motor de relógio de parâmetros q, conduzido pelo modelo de erro de CAI em intervalo. A figura de mérito é a autoconsistência do filtro (NEES + brancura da inovação contra limites de χ²) — uma declaração de autoconsistência, NÃO uma garantia de exatidão no mundo real. Apenas simulação; sem TRL>3, sem herança de voo, sem validação externa.

hybrid-ukf.toml

tipo hybrid-ukfnão associado a um módulo do registo pelo nome

Filtro de Kalman unscented (UKF) GNSS/INS híbrido quântico + clássico de acoplamento forte com 17 estados (MODELLED).

kind = "hybrid-ukf"
seed = 1771
speed_m_s = 100.0
sigma_pr_m = 1.0
sigma_rr_mps = 0.05
consistency_seeds = 24
q_factor = 1.0
r_factor = 1.0

Abrir no Kshana Studio · Ver no GitHub

impairment-eval#

Bancada de avaliação de deteção de degradações de RF por aprendizagem automática (13494): gerar um corpus SINTÉTICO rotulado e fundamentado em parâmetros (nominal/jamming/spoof de tempo/spoof de posição/multipercurso), pontuar um detector (energy|agc|sqm|parity|fused) com a estrutura de teste agnóstica ao detector, e indicar AUC/ROC/confusão + Pd por classe num Pfa-alvo, além da lacuna de otimismo dentro versus fora da distribuição. Apenas características operacionais MODELLED — nunca dados de campo/IQ, sem veredito bom/mau.

impairment-eval.toml

tipo impairment-evalas linhas do tipo de cenário no registo são modeladas · 0 de 1 linhas validadas

Banco de ensaio de avaliação da deteção de perturbações de RF por aprendizagem automática (demonstrador ESA AO/1-13494).

kind = "impairment-eval"
seed = 42
n_per_class = 200
meas_noise = 0.6
detector = "fused"
target_pfa = 0.05
shift_severity_scale = 0.5
optimism_tol = 0.05

Abrir no Kshana Studio · Ver no GitHub

inertial#

Navegação inercial por estima em 1-DOF durante uma interrupção do GNSS.

imu-deadreckoning.toml

tipo inertialnão associado a um módulo do registo pelo nome

Navegação à estima durante uma interrupção do GNSS: acelerómetro quântico de átomos frios vs de qualidade de navegação. Viés = resíduo após calibração GNSS = estabilidade de viés publicada; q_va = (PSD de raiz do ruído)^2.

kind = "inertial"
seed = 42
threshold_m = 100.0
step_s = 10.0
duration_s = 7200.0
windows = [
id = "cold-atom-quat"
provenance = "Exail hybrid quantum accelerometer triad: bias stability 6e-8 g = 5.88e-7 m/s^2 after 24 h (Templier et al., Science Advances 2022, arXiv:2209.13209); noise 22 ug/sqrtHz = 2.16e-4 (m/s^2)/sqrtHz; laboratory maturity, not deployed"

Abrir no Kshana Studio · Ver no GitHub

quantum-cai-coast.toml

tipo inertialnão associado a um módulo do registo pelo nome

Predefinição quântica: um acelerómetro de interferómetro de átomos frios (CAI), construído a partir da sua física de interferómetro, face a um acelerómetro de quartzo de qualidade de navegação durante uma interrupção do GNSS. Um trecho unidimensional de navegação à estima: 10 minutos de GNSS e depois 110 minutos negados.

kind = "inertial"
seed = 20261013
threshold_m = 100.0
step_s = 10.0
duration_s = 7200.0
windows = [
id = "cold-atom-interferometer"
provenance = "Cold-atom (Rb-87 D2) interferometric accelerometer: q_va derived from the [accel_quantum.cai] parameters, a bracket in the GAIN/MAIUS literature range (Freier et al. arXiv:1512.05660; Becker et al. Nature 2018); residual bias 5.88e-7 m/s^2 = the 6e-8 g bias stability of a laboratory hybrid quantum accelerometer (Templier et al., Science Advances 2022, arXiv:2209.13209). Laboratory maturity, not deployed."

Abrir no Kshana Studio · Ver no GitHub

ins-trn-coast#

Modelo de erro de INS/TRN em inércia: erro de posição em função da duração da inércia, construído a partir de coeficientes da IMU em vez de varrido como uma taxa de deriva presumida. Cinco contribuições de crescimento — viés do acelerómetro, inclinação por viés do giroscópio através da gravidade, passeio aleatório de velocidade, passeio aleatório de ângulo e fator de escala em função da distância percorrida — cada uma propagada por um modelo de erro inercial de nove estados em nível local com realimentação de Schuler a uma latitude e altura declaradas (as leis de ordem dominante para inércia curta t², t³, t^1,5, t^2,5 e t¹/t² são indicadas ao lado) e combinadas sob uma regra DECLARADA (raiz da soma dos quadrados por predefinição, ou soma linear, ou soma determinística com rss estocástico; as três são calculadas em cada execução, de modo que a escolha fica visível em vez de enterrada). As durações de inércia que atingem limiares de posição fornecidos pelo chamador (10 m e 50 m por predefinição) são localizadas pela bisseção já existente no motor, cada uma com uma decomposição por contribuição que nomeia a fonte dominante, e o cruzamento de cada contribuição isolada é, além disso, invertido algebricamente para que os dois coincidam. Um modo de navegação relativa ao terreno limita a inércia com correções de posição periódicas e indica o maior intervalo entre correções que mantém cada limiar; uma correção apenas de posição deixa o erro de velocidade e a inclinação vivos através da correção, de modo que nem sempre limita a inércia, seja qual for a taxa de correções, e o relatório diz isso em vez de devolver um zero. MODELLED: os coeficientes de classe da IMU são valores representativos de intervalo, não de uma ficha técnica, e o resíduo da correção de terreno é uma entrada. Um limiar não alcançado é indicado como nulo com um status, nunca como zero. Não é um produto de desempenho de navegação inercial certificado.

ins-trn-coast.toml

tipo ins-trn-coastnão associado a um módulo do registo pelo nome

Modelo de erro de INS/TRN em inércia — erro de posição em função da duração do trecho em inércia, e as durações em que atravessa 10 m e 50 m.

kind = "ins-trn-coast"
imu_grade = "navigation"
speed_m_s = 250.0
combination = "rss"
crossing_thresholds_m = [10.0, 50.0]
drift_band_lo_m_per_s = 0.001
drift_band_hi_m_per_s = 0.050
trn_fix_mode = "position-only"

Abrir no Kshana Studio · Ver no GitHub

maritime-port-approach-coast.toml

tipo ins-trn-coastnão associado a um módulo do registo pelo nome

Aproximação marítima a um porto com GNSS sujeito a jamming: durante quanto tempo um sistema de navegação inercial (INS) mantém um navio dentro do orçamento de exatidão de aproximação ao porto depois de perdido o sistema global de navegação por satélite (GNSS).

kind = "ins-trn-coast"
imu_grade = "navigation"
speed_m_s = 6.17
combination = "rss"
crossing_thresholds_m = [10.0, 100.0]
drift_band_lo_m_per_s = 0.001
drift_band_hi_m_per_s = 0.050
trn_fix_mode = "none"

Abrir no Kshana Studio · Ver no GitHub

rail-tunnel-coast.toml

tipo ins-trn-coastnão associado a um módulo do registo pelo nome

Trecho em inércia num túnel ferroviário: durante quanto tempo o sistema de navegação inercial (INS) de um comboio o mantém dentro de um orçamento de discriminação de via sem sistema global de navegação por satélite (GNSS) num túnel.

kind = "ins-trn-coast"
imu_grade = "tactical"
speed_m_s = 44.4
combination = "rss"
crossing_thresholds_m = [2.0, 20.0]
drift_band_lo_m_per_s = 0.001
drift_band_hi_m_per_s = 0.050
trn_fix_mode = "none"

Abrir no Kshana Studio · Ver no GitHub

integrity#

RAIM instantâneo / de separação de soluções / ARAIM com HPL/VPL e um diagrama de Stanford.

araim-gps-galileo.toml

tipo integritynão associado a um módulo do registo pelo nome

Disponibilidade ARAIM de dupla constelação: GPS + Galileo avaliados com o motor ARAIM avançado, incluindo a hipótese de falha em toda a constelação (araim_dual).

kind = "integrity"
mask_deg = 5.0
sigma_uere_m = 0.75
p_fa = 1.0e-5
p_md = 1.0e-3
al_h_m = 40.0
al_v_m = 50.0
araim_dual = true

Abrir no Kshana Studio · Ver no GitHub

integrity-harbour-approach.toml

tipo integritynão associado a um módulo do registo pelo nome

Disponibilidade ARAIM para uma embarcação a entrar num porto: o tipo de cenário integrity com um utilizador em local terrestre (user_site) sob a predefinição de linha de horizonte harbour-approach.

kind = "integrity"
seed = 7
mask_deg = 5.0
sigma_uere_m = 1.0
p_fa = 1.0e-5
p_md = 1.0e-3
al_h_m = 40.0
al_v_m = 50.0

Abrir no Kshana Studio · Ver no GitHub

integrity-raim.toml

tipo integritynão associado a um módulo do registo pelo nome

Disponibilidade de integridade GNSS (RAIM) sobre uma constelação do tipo GPS.

kind = "integrity"
seed = 7
mask_deg = 5.0
sigma_uere_m = 1.0
p_fa = 1.0e-5
p_md = 1.0e-3
al_h_m = 40.0
al_v_m = 50.0

Abrir no Kshana Studio · Ver no GitHub

jamming#

Jamming por balanço de enlace: J/S → C/N₀ efetivo → perda de sincronismo.

jamming-demo.toml

tipo jammingas linhas do tipo de cenário no registo são modeladas · 0 de 1 linhas validadas

Jamming de RF: um jammer de banda larga em terra a impedir o GNSS a um recetor próximo.

kind = "jamming"
seed = 1
mask_deg = 5.0
tracking_threshold_dbhz = 25.0
step_s = 30.0
duration_s = 1800.0
lat_deg = 52.0
lon_deg = 4.0

Abrir no Kshana Studio · Ver no GitHub

jamming-harbour-approach-skyline.toml

tipo jammingas linhas do tipo de cenário no registo são modeladas · 0 de 1 linhas validadas

Um navio a entrar num porto sob um emissor de jamming em terra, com os edifícios do cais à frente a ocultar os satélites baixos nessa direção: o cenário jamming sob a predefinição de linha de horizonte harbour-approach.

kind = "jamming"
seed = 1
mask_deg = 5.0
tracking_threshold_dbhz = 25.0
step_s = 60.0
duration_s = 21600.0
lat_deg = 59.80
lon_deg = 24.90

Abrir no Kshana Studio · Ver no GitHub

maritime-strait-jamming.toml

tipo jammingas linhas do tipo de cenário no registo são modeladas · 0 de 1 linhas validadas

Jamming de GNSS marítimo: um emissor de jamming de banda larga, em terra ou a bordo de uma embarcação, a negar o sistema global de navegação por satélite (GNSS) a um navio que atravessa águas abertas.

kind = "jamming"
seed = 1
mask_deg = 5.0
tracking_threshold_dbhz = 25.0
step_s = 30.0
duration_s = 1800.0
lat_deg = 59.80
lon_deg = 24.90

Abrir no Kshana Studio · Ver no GitHub

launch-window#

Geometria de lançamento e ascensão de dois corpos: azimute(s) de lançamento (sin Az = cos i / cos lat), inclinação mínima alcançável, velocidade circular, o bónus para leste da rotação da Terra, Δv de mudança de plano em dogleg quando a inclinação-alvo está abaixo da latitude do local, e o número de oportunidades diárias de lançamento. Geometria de Terra esférica MODELLED (sem correção do triângulo de velocidades da Terra em rotação, sem modelo de ascensão/perda por arrasto).

launch-window.toml

tipo launch-windownão associado a um módulo do registo pelo nome

Demonstrador de janela de lançamento e geometria de subida (análise de missões, nível de estudo comparativo).

kind = "launch-window"
site_lat_deg = 28.5
target_inclination_deg = 51.6
altitude_km = 400.0

Abrir no Kshana Studio · Ver no GitHub

leo-navmsg#

Mensagem de navegação LEO: as efemérides e o relógio transmitidos de um satélite de posicionamento, navegação e temporização em órbita terrestre baixa (LEO), para qualquer órbita, portadora e modelo, com predefinições nomeadas opcionais (Xona Pulsar, Iridium, Starlink, CentiSpace, um sistema representativo em banda C, o modelo ATOMIC de relógio zero, Celeste IOD). CONTEÚDO: dados auxiliares (SVID, número de emissão dos dados, banda, saúde do sinal), sincronização (semana, tempo da semana, um polinómio de relógio de segunda ordem af0-af2 em torno de toc), efemérides num de quatro modelos -- o conjunto kepleriano de 16 parâmetros do Galileo OS SIS ICD; esse conjunto mais polinómios de correção ao longo da trajetória, transversais e radiais; o modelo de 22 parâmetros de Liu et al. 2025; um polinómio ECEF sem termos de relógio (ATOMIC de relógio zero) -- e outros serviços (um conjunto de transmissão de Klobuchar, ai0-ai2 do NeQuick-G com o nível efetivo de ionização, e parâmetros de tempo do sistema para UTC com a lógica de segundos intercalares do ICD). AJUSTADOR: uma órbita-verdade integrada com gravidade zonal J2-J6 ou EGM2008 até ao grau escolhido e arrasto, e um relógio livre ou conduzido com semente; ajuste de Levenberg-Marquardt do conjunto kepleriano em elementos não singulares, depois polinómios de correção por mínimos quadrados lineares; relógio ajustado líquido do termo relativístico que o utilizador acrescenta. ANÁLISES: fit-interval-trade (erro de distância do sinal no espaço, SISRE, com pesos médios globais para a altitude da órbita, em função do intervalo de ajuste e do período de atualização, apenas órbita e com relógio), model-comparison (quatro modelos, número de parâmetros, bits codificados e o ajuste do Kshana nas altitudes de Liu et al. ao lado dos valores publicados), midpass-update (a passagem mais alta sobre um utilizador, o salto de posição, de relógio e de distância do utilizador a cada troca de mensagem, o salto na pior geometria, PASS/FAIL contra um limiar de continuidade), encode-decode (o quadro binário documentado do próprio Kshana com CRC-24Q, um orçamento de quantização de meio passo por campo, uma verificação de quadro corrompido, uma exportação e importação de registo no estilo RINEX 4 rotulada como extensão do Kshana, e uma tabela CSV). VALIDATED: os pesos do SISRE contra a tabela MEO/GEO publicada (Montenbruck et al. 2018); o algoritmo de utilizador do Galileo contra o RTKLIB em efemérides de transmissão reais do Galileo; o CRC-24Q contra o seu valor de verificação de catálogo e o quadro de exemplo RTCM 1005. MODELLED: cada valor de ajuste e de SISRE é erro de representação contra uma verdade integrada pelo Kshana (sem erro de determinação ou predição de órbita); a comparação com Liu et al. usa órbitas diferentes; os formatos de codificação e de texto são do próprio Kshana.

leo-navmsg-celeste-iod.toml

tipo leo-navmsgnão associado a um módulo do registo pelo nome

Predefinição de demonstração em órbita (IOD) Celeste da ESA: o único cenário que usa material apresentado no workshop LEO-PNT do ESA Navigation Innovation and Support Programme (NAVISP), 2026. Retenha-o de uma edição ao apagar este ficheiro e src/leo_navmsg/presets/celeste_iod.rs (ver o cabeçalho desse ficheiro).

kind = "leo-navmsg"
name = "Celeste IOD message (workshop preset)"
seed = 15
preset = "celeste-iod"
analysis = ["encode-decode", "fit-interval-trade"]
csv_schema = "celeste-iod"
span_s = 1800
fit_intervals_s = [60, 120, 300, 600, 900]

Abrir no Kshana Studio · Ver no GitHub

leo-navmsg-encode-decode.toml

tipo leo-navmsgnão associado a um módulo do registo pelo nome

Mensagem de navegação LEO: a codificação binária do Kshana, o seu orçamento de quantização e as exportações em estilo RINEX e CSV.

kind = "leo-navmsg"
name = "LEO message encode and decode"
seed = 14
analysis = ["encode-decode"]
altitude_km = 550.0
inclination_deg = 97.6
gravity_degree = 20
model = "kepler-rac"

Abrir no Kshana Studio · Ver no GitHub

leo-navmsg-fit-interval-trade.toml

tipo leo-navmsgnão associado a um módulo do registo pelo nome

Mensagem de navegação LEO: erro de distância do sinal no espaço (SISRE) versus intervalo de ajuste.

kind = "leo-navmsg"
name = "LEO message fit-interval trade"
seed = 11
analysis = ["fit-interval-trade"]
altitude_km = 550.0
inclination_deg = 97.6
gravity_degree = 20
cd_area_over_mass = 0.005

Abrir no Kshana Studio · Ver no GitHub

leo-navmsg-midpass-update.toml

tipo leo-navmsgnão associado a um módulo do registo pelo nome

Mensagem de navegação LEO: uma atualização da mensagem a meio de uma passagem, e se o utilizador vê um salto.

kind = "leo-navmsg"
name = "LEO message mid-pass update"
seed = 13
analysis = ["midpass-update"]
altitude_km = 550.0
inclination_deg = 97.6
gravity_degree = 20
model = "kepler-rac"

Abrir no Kshana Studio · Ver no GitHub

leo-navmsg-model-comparison.toml

tipo leo-navmsgnão associado a um módulo do registo pelo nome

Mensagem de navegação LEO: quatro modelos de efemérides numa só órbita, e a tabela SISRE-versus-altitude de Liu et al. 2025.

kind = "leo-navmsg"
name = "LEO message model comparison"
seed = 12
analysis = ["model-comparison"]
altitude_km = 550.0
inclination_deg = 97.6
gravity_degree = 20
model = "kepler-rac"

Abrir no Kshana Studio · Ver no GitHub

leo-pass#

Passagem LEO e balanço de enlace, banda a banda, para LEO-PNT (posicionamento, navegação e temporização a partir de órbita terrestre baixa), agnóstico de sistema: um utilizador (em terra, no mar, no ar ou em ambiente fechado, estático ou em movimento) e um ou mais satélites LEO a partir de uma PASS PROJETADA (uma órbita circular posicionada de modo que o utilizador veja uma passagem de uma elevação máxima escolhida num instante escolhido, heliossíncrona se pedido), ELEMENTOS explícitos, um TLE (conjunto de elementos de duas linhas) pelo SGP4 do motor, ou uma constelação WALKER construída pelo código constellation-design (as passagens mais altas indicadas). As bandas vêm de uma predefinição nomeada (UHF/L/S/C genérica multibanda, banda C genérica, Xona Pulsar X1/X5, Iridium STL, Starlink como um sinal de oportunidade apenas de Doppler, CentiSpace, e uma predefinição opcional Celeste IOD marcada WORKSHOP) ou são escritas no cenário; cada predefinição declara se os seus números são PUBLIC (com URL), REPRESENTATIVE ou WORKSHOP. Por satélite, banda e época: elevação, azimute, distância, taxa de variação da distância e aceleração da distância; perda no espaço livre; EIRP e o ganho do diagrama do satélite (isofluxo, feixe gaussiano ou plano); ganho da antena do utilizador em função da elevação (patch, hemisférica ou isotrópica); atenuação gasosa (ITU-R P.676-10 Anexo 2), atenuação por chuva (coeficientes da ITU-R P.838-3 e o procedimento da P.618-14, a partir de uma taxa de chuva e uma altura de chuva), cintilação troposférica (ITU-R P.618-14 secção 2.4.1), perda de penetração em edifícios para um utilizador em ambiente fechado (ITU-R P.2109-2), descasamento de polarização, temperatura de ruído do sistema e C/N0 (densidade de portadora sobre ruído); Doppler e taxa de Doppler em forma fechada a partir da taxa de variação e da aceleração da distância, cada uma conferida contra diferenças centrais; o atraso ionosférico de primeira ordem 40,3 STEC/f^2 a partir de um TEC oblíquo de Klobuchar ou de TEC vertical, escalado para a parte da ionosfera abaixo do satélite. Pares de bandas recebem os coeficientes livres de ionosfera, a amplificação de ruído e o ruído de código no pico da passagem. Satélites GNSS em MEO (predefinições do Galileo ou do GPS) são avaliados com o mesmo modelo de antena e de ruído a partir das potências recebidas dos seus documentos de interface, de modo que a passagem LEO em forma de sino e as portadoras GNSS planas partilham um mesmo gráfico. Uma secção opcional [iot] fornece tempo até à primeira solução, energia por solução e vida útil da bateria em função do ciclo de trabalho para um orçamento de potência de recetor declarado (MODELLED). Cada par de bandas fornece também o TEC oblíquo que a sua combinação livre de geometria recupera no pico e o sigma de ruído de código dessa estimativa (sondagem da ionosfera). Uma secção opcional [spoofer] falsifica os sinais de uma posição alegada que salta ou é empurrada para longe da verdadeira depois de um início e executa dois monitores com probabilidades de falso alarme e de deteção perdida declaradas: consistência de Doppler e de geometria da passagem (taxas de variação da distância medidas contra as previstas a partir das órbitas e de uma posição e velocidade a priori independentes, um teste de qui-quadrado de mínimos quadrados generalizados sobre uma janela, nos canais GNSS, LEO e em todos) e consistência entre bandas (o passo de época a época da combinação livre de geometria, corrigida pelo modelo, de cada par de bandas LEO), com estatísticas por época e o momento em que cada monitor deteta (MODELLED). Componentes VALIDATED: perda no espaço livre, os coeficientes da P.838-3 contra a sua Tabela 5, os procedimentos de chuva e cintilação da P.618-14 e a perda de penetração em edifícios da P.2109 contra os exemplos de validação do Grupo de Estudos 3 da ITU-R, a razão de atraso de grupo L1/L2 do IS-GPS-200 e o Doppler máximo de utilizador estático numa órbita circular contra a Tabela 1 do arXiv 2509,19551. MODELLED: EIRPs, diagramas, a fração de Chapman do TEC abaixo do satélite e a passagem inteira.

leo-focus-science-iono-sounding.toml

tipo leo-passnão associado a um módulo do registo pelo nome

Área de foco LEO-PNT: ciência LEO-PNT, sondagem da ionosfera a partir do atraso de dupla banda.

kind = "leo-pass"
name = "LEO ionosphere sounding from multi-band delays"
epoch = "2026-09-28T11:00:00"
duration_s = 900.0
step_s = 5.0
environment = "ground"
lat_deg = 69.66
lon_deg = 18.94

Abrir no Kshana Studio · Ver no GitHub

leo-indoor-uhf.toml

tipo leo-passnão associado a um módulo do registo pelo nome

LEO-PNT em interiores: porque é que uma portadora UHF chega ao interior de um edifício quando as bandas L, S e C têm dificuldades.

kind = "leo-pass"
name = "Indoor UHF LEO-PNT"
epoch = "2026-09-28T12:00:00"
duration_s = 900.0
step_s = 5.0
environment = "indoor"
lat_deg = 41.9
lon_deg = 12.49

Abrir no Kshana Studio · Ver no GitHub

leo-iot-energy.toml

tipo leo-passnão associado a um módulo do registo pelo nome

LEO-PNT de baixo consumo para um localizador IoT (Internet das Coisas): energia por solução de posição face ao ciclo de trabalho.

kind = "leo-pass"
name = "IoT energy per fix"
epoch = "2026-09-28T06:00:00"
duration_s = 900.0
step_s = 5.0
environment = "ground"
lat_deg = 53.55
lon_deg = 9.99

Abrir no Kshana Studio · Ver no GitHub

leo-pass-celeste-iod-multiband.toml

tipo leo-passnão associado a um módulo do registo pelo nome

ESA Celeste IOD, configuração de sinal n.º 1, todas as bandas numa passagem. Predefinição WORKSHOP.

kind = "leo-pass"
name = "Celeste IOD multi-band pass"
epoch = "2026-09-28T08:00:00"
duration_s = 600.0
step_s = 2.0
iono_free_pairs = [["E5", "C"], ["UHF", "C"], ["E5", "SR"]]
environment = "ground"
lat_deg = 52.218

Abrir no Kshana Studio · Ver no GitHub

leo-pass-iridium.toml

tipo leo-passnão associado a um módulo do registo pelo nome

Rajadas Iridium STL (tempo e localização por satélite) vistas a partir de uma aeronave.

kind = "leo-pass"
name = "Iridium STL from an aircraft"
epoch = "2026-09-28T14:00:00"
duration_s = 900.0
step_s = 5.0
environment = "air"
lat_deg = 50.0
lon_deg = -30.0

Abrir no Kshana Studio · Ver no GitHub

leo-pass-vs-gnss-cn0.toml

tipo leo-passnão associado a um módulo do registo pelo nome

Uma passagem LEO-PNT face aos satélites Galileo à vista: C/N0 numa passagem.

kind = "leo-pass"
name = "LEO pass versus MEO GNSS C/N0"
epoch = "2026-09-28T08:00:00"
duration_s = 900.0
step_s = 2.0
environment = "ground"
lat_deg = 48.137
lon_deg = 11.575

Abrir no Kshana Studio · Ver no GitHub

leo-pass-xona-pulsar.toml

tipo leo-passnão associado a um módulo do registo pelo nome

Xona Pulsar X1 e X5 numa passagem, com as passagens mais altas da constelação Pulsar.

kind = "leo-pass"
name = "Xona Pulsar pass"
epoch = "2026-09-28T10:00:00"
duration_s = 1200.0
step_s = 5.0
environment = "maritime"
lat_deg = 45.5
lon_deg = -5.0

Abrir no Kshana Studio · Ver no GitHub

leo-resilience-spoof-doppler.toml

tipo leo-passnão associado a um módulo do registo pelo nome

Resiliência LEO-PNT face a spoofing: consistência do Doppler e da geometria da passagem.

kind = "leo-pass"
name = "Spoofing detection by LEO Doppler consistency"
epoch = "2026-09-28T08:00:00"
duration_s = 1800.0
step_s = 5.0
environment = "ground"
lat_deg = 50.11
lon_deg = 8.68

Abrir no Kshana Studio · Ver no GitHub

leo-pnt-chain#

Um sistema LEO-PNT (posicionamento, navegação e temporização a partir da órbita terrestre baixa) de ponta a ponta, para qualquer constelação e sinal: o projeto leo-signal indicado por signal_design (uma predefinição pública ou um projeto [signal] em linha) define o centro, a largura de banda, a taxa de chips e a repartição da EIRP de uma banda [pass], o orçamento de ligação leo-pass fornece o C/N0 seguido e o jitter de código limitado em banda ao longo da passagem, uma reta de C/N0 em sin(elevação) e o SISRE de difusão da mensagem [navmsg] (ajustado à altitude do satélite da passagem) alimentam todos os sistemas LEO da solução de posição conjunta leo-pvt de [fusion] e, opcionalmente, os casos leo-ppp de [ppp]; cada transferência é listada com o seu valor e unidade. MODELLED.

celeste-iod-end-to-end.toml

tipo leo-pnt-chainnão associado a um módulo do registo pelo nome

Celeste IOD de ponta a ponta (predefinição opcional): o sinal E5 da configuração n.º 1 -> uma passagem Celeste IOD -> a mensagem de navegação ao estilo Celeste -> posição calculada fundida GPS + Galileo + Celeste IOD.

kind = "leo-pnt-chain"
name = "Celeste IOD end to end"
seed = 4
signal_design = "celeste-iod-e5-1-pfa"
od_sisre_m = 0.25
name = "celeste-iod-e5-1-pfa"
system = "Celeste IOD"
source = "WORKSHOP"

Abrir no Kshana Studio · Ver no GitHub

leo-pnt-end-to-end.toml

tipo leo-pnt-chainnão associado a um módulo do registo pelo nome

LEO-PNT de ponta a ponta numa constelação genérica: projeto do sinal -> orçamento de ligação da passagem -> mensagem de navegação -> posição calculada fundida MEO + LEO e convergência do posicionamento de ponto preciso.

kind = "leo-pnt-chain"
name = "LEO-PNT end to end, generic 1080 km constellation"
seed = 5
signal_design = "generic-l"
od_sisre_m = 0.25
presets = ["generic-bands"]
epoch = "2026-09-28T08:00:00"
duration_s = 1200.0

Abrir no Kshana Studio · Ver no GitHub

xona-pulsar-end-to-end.toml

tipo leo-pnt-chainnão associado a um módulo do registo pelo nome

Xona Pulsar de ponta a ponta: o sinal X5 público -> uma passagem Pulsar -> uma mensagem de navegação LEO -> posição calculada fundida GPS + Galileo + Pulsar e convergência do posicionamento de ponto preciso.

kind = "leo-pnt-chain"
name = "Xona Pulsar end to end"
seed = 9
signal_design = "xona-x5"
od_sisre_m = 0.25
presets = ["xona-pulsar"]
epoch = "2026-09-28T10:00:00"
duration_s = 1200.0

Abrir no Kshana Studio · Ver no GitHub

leo-ppp#

Convergência do posicionamento pontual preciso (PPP) só com GNSS e com aumento por LEO: um filtro de Kalman estendido de parâmetros flutuantes sobre código e fase da portadora sem ionosfera, com as coordenadas estáticas da estação, um relógio do recetor branco, um desvio entre sistemas por cada sistema adicional, um atraso zenital húmido em passeio aleatório projetado por 1/sin(elevação) e uma ambiguidade flutuante por arco de satélite; o erro preciso de órbita e relógio é branco e comum ao código e à fase de um satélite, pelo que cada satélite é uma atualização correlacionada de duas linhas, numa forma estabilizada de Joseph. As medições são simuladas a partir do mesmo modelo com ruído de semente fixa, em vários locais e sementes, e cada caso (primeiro só GNSS, depois cada [[case]] de sistemas LEO, qualquer constelação ou predefinição) indica o tempo de convergência mediano (a primeira época a partir da qual os erros horizontal e vertical se mantêm abaixo dos limiares, 10 cm por predefinição), a fração convergida, as curvas de erro medianas e a consistência do filtro (o NEES da posição médio da execução face à banda do qui-quadrado bilateral de 95%). Opcionalmente, a par dos valores de latitudes médias publicados por Li et al. (2019, J. Geod. 93:749, doi 10.1007/s00190-018-1195-2): 9,6 min para multi-GNSS, encurtados para 7,0, 3,2, 2,1 e 1,3 min com 60, 96, 192 e 288 satélites LEO. MODELLED: uma comparação de consistência da tendência, não uma reprodução das constelações, do ruído ou das estações desse estudo; sem resolução de ambiguidades, saltos de ciclo, phase wind-up, marés nem erros de produtos correlacionados no tempo.

leo-ppp-convergence.toml

tipo leo-pppnão associado a um módulo do registo pelo nome

Convergência do posicionamento por ponto preciso (PPP) com aumento por LEO.

kind = "leo-ppp"
seed = 20
duration_s = 1800.0
step_s = 10.0
runs = 4
lat_deg = 30.5
lon_deg = 114.4
lat_deg = 48.1

Abrir no Kshana Studio · Ver no GitHub

leo-pvt#

Posicionamento, navegação e temporização (PNT) fundidos de órbita terrestre média (MEO) e órbita terrestre baixa (LEO) sobre QUALQUER constelação: cada [[system]] é uma predefinição GNSS do tipo de cenário constellation-design, uma predefinição LEO (xona-pulsar, iridium-stl, starlink-sop, centispace, generic-c-band, o modelo de efemérides atomic-zero-clock, ou outro ficheiro de predefinição, cada um no seu próprio ficheiro com as fontes assinaladas como PUBLIC, WORKSHOP ou DERIVED), camadas Walker ou conjuntos de elementos explícitos, com uma portadora, uma taxa de chips, uma envolvente da densidade de ruído da portadora (C/N0) desde a máscara de elevação até ao zénite, um erro de distância do sinal no espaço (SISRE), um sigma de Doppler e um modelo de relógio (o seu próprio relógio do recetor, pelo que o desvio entre sistemas é estimado, ou um desvio de difusão conhecido). Quatro modos. DOPPLER: posicionamento em lote por Gauss-Newton a partir da taxa de variação da distância, com derivadas parciais analíticas, estados de deriva do relógio e de velocidade opcionais e uma restrição de altura opcional, com um ou vários satélites, o erro em função da duração da janela, a envolvente do Doppler, da taxa de Doppler e do jerk de cada sistema LEO, e a exatidão ao longo da trajetória e transversal numa única passagem em função do desvio transversal (o erro transversal cresce sem limite à medida que a passagem se torna zenital; uma única passagem tem também uma solução espelhada através do traço no solo). Aqui executa-se um sinal de oportunidade só com Doppler (starlink-sop). JOINT: soluções de pseudodistância por mínimos quadrados ponderados em cada época, só com GNSS, só com LEO e com ambos, sigmas por medição a partir de um modelo de ruído térmico do laço de bloqueio de atraso em C/N0 mais o SISRE (ou um sigma fixo, de modo que um modelo de sinal os possa alimentar), os desvios entre sistemas estimados e PDOP/HDOP/VDOP em função do número de satélites LEO acrescentados. POLAR: satélites à vista e DOP em função da latitude para GNSS, LEO e ambos. TIMING: transferência de tempo para o Tempo Universal Coordenado (UTC) a partir de satélites LEO numa posição conhecida, com um filtro de relógio de dois estados cujo ruído de processo provém das classes de osciladores do motor, em função do C/N0 e do oscilador, e a expressão do IS-GPS-200 do tempo do sistema para o UTC; com [timing] trace = true cada linha indica também o seu erro de tempo e o sigma previsto em cada época. VALIDATED: o maior Doppler de uma passagem do zénite ao horizonte face aos valores publicados do Iridium (até 36 kHz) e do Xona Pulsar X1 (32 a 34 kHz). MODELLED: tudo o resto; o DOP é verificado face a um caso derivado à mão, as soluções de posição face à sua covariância e o modelo de Doppler face à identidade da aceleração da distância.

celeste-iod-fused-pvt.toml

tipo leo-pvtnão associado a um módulo do registo pelo nome

Posicionamento GNSS reforçado pelos dois satélites de demonstração em órbita Celeste da ESA.

kind = "leo-pvt"
mode = "joint"
seed = 4
duration_s = 5700.0
step_s = 30.0
lat_deg = 52.22
lon_deg = 4.42
height_m = 5.0

Abrir no Kshana Studio · Ver no GitHub

leo-doppler-positioning.toml

tipo leo-pvtnão associado a um módulo do registo pelo nome

Posicionamento apenas a partir do Doppler LEO, sobre uma constelação de navegação LEO genérica.

kind = "leo-pvt"
mode = "doppler"
seed = 7
duration_s = 600.0
step_s = 10.0
lat_deg = 48.14
lon_deg = 11.58
height_m = 520.0

Abrir no Kshana Studio · Ver no GitHub

leo-pvt-fjord-skyline.toml

tipo leo-pvtnão associado a um módulo do registo pelo nome

Posicionamento fundido MEO e LEO para uma embarcação no fundo de um fiorde, onde as paredes do vale ocultam tudo o que está baixo do outro lado do canal: o modo conjunto leo-pvt sob a predefinição de linha de horizonte fjord.

kind = "leo-pvt"
mode = "joint"
seed = 3
duration_s = 1800.0
step_s = 30.0
lat_deg = 61.1
lon_deg = 6.6
height_m = 20.0

Abrir no Kshana Studio · Ver no GitHub

leo-timing-utc.toml

tipo leo-pvtnão associado a um módulo do registo pelo nome

Transferência de tempo para UTC a partir de satélites LEO, face ao C/N0 e ao oscilador do recetor.

kind = "leo-pvt"
mode = "timing"
seed = 9
duration_s = 21600.0
step_s = 10.0
lat_deg = 39.99
lon_deg = -105.26
height_m = 1655.0

Abrir no Kshana Studio · Ver no GitHub

meo-leo-fused-pvt.toml

tipo leo-pvtnão associado a um módulo do registo pelo nome

Posicionamento fundido por pseudodistâncias MEO e LEO: GPS e Galileo com uma camada de navegação LEO.

kind = "leo-pvt"
mode = "joint"
seed = 3
duration_s = 1800.0
step_s = 30.0
lat_deg = 40.42
lon_deg = -3.70
height_m = 650.0

Abrir no Kshana Studio · Ver no GitHub

polar-arctic-leo-coverage.toml

tipo leo-pvtnão associado a um módulo do registo pelo nome

Satélites à vista e diluição da precisão do equador ao polo: só GNSS MEO, só uma constelação LEO quase polar, e ambos.

kind = "leo-pvt"
mode = "polar"
duration_s = 7200.0
step_s = 600.0
lat_step_deg = 10.0
lon_step_deg = 45.0
pdop_threshold = 6.0
name = "GPS"

Abrir no Kshana Studio · Ver no GitHub

leo-signal#

Projetos de sinais LEO-PNT: sinais parametrizados de posicionamento, navegação e temporização (PNT) de órbita terrestre baixa (LEO) para qualquer sistema, banda e estrutura. Um SINAL é uma banda (frequência central, largura de banda de transmissão, atribuição da ITU RNSS/RDSS/MSS/EESS/non-RNSS/other) e componentes (aquisição, dados, piloto; qualquer subconjunto), cada um com uma modulação (BPSK(n) com n fracionário, BOC(m,n), MBOC(6 1,p) ou uma banda plana do tipo OFDM), uma quota de potência, desvios opcionais de subportadoras FDMA, um comprimento de código e uma taxa de dados. Os sinais provêm de ficheiros de predefinições públicas compilados no programa (xona-pulsar, iridium-stl, starlink-soo, centispace, generic-c-band, generic-bands; cada um com o seu URL de origem e cada valor não publicado etiquetado REPRESENTATIVE) ou são escritos em linha. POR SINAL: a densidade espetral de potência limitada em banda e a fração da potência de cada componente que a banda de transmissão deixa passar (forma fechada BPSK a par do valor numérico), a largura de banda RMS (Gabor), o jitter térmico de seguimento de código do laço de bloqueio de atraso em função do C/N0 e do espaçamento early-late a partir da fórmula early-late coerente (ou não coerente) limitada em banda de Betz & Kolodziejski 2009, com a sua forma de manual de banda ilimitada e o seu limite de Gabor para espaçamento nulo, a exatidão de medição de distâncias em metros, o espaço de pesquisa de aquisição (células de Doppler a partir do Doppler máximo da órbita mais termos do oscilador e do utilizador, vezes células de código), a probabilidade de deteção de lei quadrática e o tempo médio de aquisição em série e com código em paralelo, o coeficiente de separação espetral do sinal para o GPS L1 C/A, o Galileo E1, o GPS L5, o Galileo E5a, E5b e E5 AltBOC e de cada um para o sinal com a degradação do C/N0, e o J/S CW, de banda larga e adaptado que a componente seguida tolera, a partir da maquinaria SSC do próprio tipo de cenário spectrum. Um COMPROMISSO DE BANDA: atraso ionosférico de primeira ordem (40,3 TEC/f^2), perda no espaço livre, exatidão de medição de distâncias com igual C/N0 e com igual EIRP, e tolerância a jammers. VERIFICAÇÕES DE FORMA opcionais confrontam o espetro de um projeto com uma medição descrita (consistência MODELLED). VALIDATED: as formas fechadas da potência BPSK em banda (90,3 % no lóbulo principal) e da largura de banda de Gabor, o jitter limitado em banda a reduzir-se à forma early-late coerente dos manuais e ao seu limite de Gabor, o coeficiente de separação espetral BPSK com desvio face à sua forma fechada de Parseval, a área unitária do espetro AltBOC e o Doppler LEO máximo face aos valores publicados do Xona Pulsar (32-34 kHz) e do Iridium (36 kHz). MODELLED: cada projeto, repartição de potência, C/N0 e nível de jammer; os espetros EFQPSK, CSK e OFDM são aproximados.

celeste-iod-classical-pilot-signals.toml

tipo leo-signalnão associado a um módulo do registo pelo nome

Projetos de sinal Celeste IOD: as bandas de frequência e a configuração de sinal n.º 1 "Classical Pilot" da missão de posicionamento, navegação e tempo (PNT) em órbita terrestre baixa (LEO) Celeste In-Orbit Demonstration (IOD) da ESA, como projetos de sinal parametrizados.

kind = "leo-signal"
noise_figure_db = 2.0
antenna_temp_k = 290.0
loop_bandwidth_hz = 1.0
integration_time_s = 0.02
correlator_spacings_chips = [1.0, 0.5, 0.2, 0.1]
reference_spacing_chips = 0.5
tracking_threshold_dbhz = 25.0

Abrir no Kshana Studio · Ver no GitHub

leo-band-trade.toml

tipo leo-signalnão associado a um módulo do registo pelo nome

Compromisso de bandas LEO-PNT, de UHF a banda C larga: o que um sinal de posicionamento, navegação e tempo (PNT) em órbita terrestre baixa (LEO) ganha e perde em cada banda, independentemente de qualquer sistema em particular.

kind = "leo-signal"
presets = ["generic-bands"]
noise_figure_db = 2.0
antenna_temp_k = 290.0
loop_bandwidth_hz = 1.0
integration_time_s = 0.02
correlator_spacings_chips = [1.0, 0.5, 0.2, 0.1]
reference_spacing_chips = 0.5

Abrir no Kshana Studio · Ver no GitHub

xona-pulsar-signals.toml

tipo leo-signalnão associado a um módulo do registo pelo nome

Sinais Xona Pulsar: os sinais X1 (banda L1) e X5 (banda L5) de uma constelação comercial de posicionamento, navegação e tempo (PNT) em órbita terrestre baixa (LEO), a partir da sua tabela de sinais publicada (Leclère, Marathe e Reid, ION GNSS+ 2025, https://arxiv.org/abs/2509.19551), como a predefinição xona-pulsar compilada no programa.

kind = "leo-signal"
presets = ["xona-pulsar"]
noise_figure_db = 2.0
antenna_temp_k = 290.0
loop_bandwidth_hz = 1.0
integration_time_s = 0.02
correlator_spacings_chips = [1.0, 0.5, 0.2, 0.1]
reference_spacing_chips = 0.5

Abrir no Kshana Studio · Ver no GitHub

Orçamento de ligação unidirecional segundo a equação de ligação CCSDS 401 / DSN 810-005: perda de percurso no espaço livre, C/N₀, Eb/N₀, margem e fecho para uma EIRP de transmissão, G/T de receção, distância, taxa de dados e banda (s|x|ka) face a um Eb/N₀ exigido. Um cálculo de engenharia determinístico a partir das entradas fornecidas (não a ficha técnica de um terminal calibrado).

lunar-ascent#

Ascensão propulsionada MODELLED de um local de superfície polar sul até à órbita de encontro, e a covariância de posição e velocidade que ela leva de volta à órbita (classe Artemis). O modelo de erro inercial de cinco estados por eixo de lunar-descent (posição, velocidade, enviesamento do acelerómetro, inclinação de atitude, enviesamento do giroscópio, conduzido pela força específica) é executado nos três eixos do local a partir do estado de superfície com que a fase começa; uma solução de posição AFS a partir dos relés visíveis de uma constelação ILLUSTRATIVE de classe LCNS (isolada, ou diferencial usando o resíduo do enlace de correção de lunar-differential-pnt, com o relógio auxiliado quando apenas três relés estão visíveis) é obtida num intervalo declarado, com o tempo lunar a entrar pelo relógio do veículo e um erro de marcação temporal ao longo da trajetória. Indica as fontes inerciais em forma fechada, a contribuição do auxílio, a ablação, os 1-sigmas de navegação ao longo da ascensão, a dispersão no corte do motor ao lado do conhecimento de navegação, e a covariância MCI 6x6 completa na inserção com a correlação posição-velocidade mantida. MODELLED: classe de IMU, força específica, conjunto de relés e dispersão no corte ilustrativos; erros mantidos nos eixos do local de lançamento; o estado nominal de saída é um substituto. Sem aval de agência; software de caráter consultivo, não um equipamento de navegação certificado.

lunar-ascent.toml

tipo lunar-ascentnão associado a um módulo do registo pelo nome

Ascensão lunar: a ascensão propulsionada a partir de um local de superfície polar sul (classe Artemis) até à órbita de encontro a 100 km, e a covariância de posição e velocidade que ela leva de volta à órbita.

kind = "lunar-ascent"
site_lat_deg = -89.5
site_lon_deg = 0.0
ascent_s = 450.0
insertion_altitude_km = 100.0
accel_bias_ug = 100.0
align_arcmin = 3.0
gyro_bias_deg_per_hr = 0.01

Ainda não está no GitHub

lunar-attack-surface#

Superfície de ataque à segurança dos sinais de navegação à superfície lunar (P1): compõe as análises abertas de segurança de sinais numa única execução acessível por binário. Indica (1) a potência recebida do AFS e o seu EXCEDENTE de potência face a uma referência GPS terrestre, bem como a banda de sensibilidade de 12-18 dB, como uma verdadeira varredura multieixo sobre as entradas da ligação (nível de referência x EIRP x distância oblíqua), com a reconciliação dos fatores lineares de 25x arredondado / 28x não arredondado. REVISTO (regra R4): isto indicava um DÉFICE de potência de 15,6 dB e um fator de 32x/36x até a referência GPS ser corrigida de -125 / -128.5 (que são os valores em dBm) para -155 / -158.5 dBW, os valores da ICD-GPS-200 que o módulo de jamming sempre usou. O sinal inverte-se: o sinal AFS lunar modelado é 14,4 dB MAIS FORTE do que o GPS L1 C/A terrestre, não mais fraco. A própria potência recebida não se alterou um único bit, e o fator linear é o antigo dividido por exatamente 1000, que é exatamente o desvio de 30 dB entre dBm e dBW; (2) a potência de transmissão exigida ao atacante para falsificar (J/S = 3 dB) e para negar (J/S = 30 dB) a cada distância de afastamento, o inverso da ligação J/S; (3) a pegada orbital de captura sob um diagrama de antena real de abertura uniforme (Airy [2 J1(x)/x]^2), uma calota sub-hemisférica limitada pela altitude cujo limbo NÃO é capturado; (4) um resultado calculado de atracão por captura de spoofing no laço de seguimento (um spoofer de código adaptado, com uma dada vantagem de potência e desvio de código, arrasta efetivamente o DLL/PLL?) em vez do limiar afirmado de 3 dB; (5) o alcance do horizonte geométrico de um corpo sem atmosfera para um transmissor de superfície elevado; e (6) o orçamento de autenticação OSNMA/TESLA (20 bit/s de sobrecarga = ~40 % de uma mensagem de navegação AFS de 50 bit/s, latência de divulgação de chaves, falsificação de 2^-40). Um corpo vazio reproduz a linha de base P1; todas as entradas têm valor predefinido e podem ser substituídas. Os subresultados VALIDATED trazem a referência independente do respetivo módulo de origem (radiometria em dB de forma fechada; ida e volta do J/S inverso; diagrama de Airy face a Bessel de A&S e à geometria da calota esférica; atracão DLL/PLL face a Kaplan & Hegarty; identidade do horizonte tangente esférico face a eo_payload; dimensionamento de campos do ICD de SIS do OSNMA). MODELLED: as magnitudes representativas de geometria/potência e os valores específicos das células do mapa de captura. Não é um produto de segurança certificado.

lunar-attack-surface.toml

tipo lunar-attack-surfacenão associado a um módulo do registo pelo nome

Superfície de ataque à segurança do sinal de navegação à superfície lunar (artigo P1).

kind = "lunar-attack-surface"
afs_eirp_dbw = 26.0
user_gain_dbi = 3.0
slant_range_m = 3.0e6
carrier_hz = 2.4e9
gps_reference_dbw = -155.0
gps_reference_min_dbw = -158.5
transmitter_altitude_m = 100_000.0

Abrir no Kshana Studio · Ver no GitHub

lunar-beacon#

Aumento de um serviço de navegação orbital lunar por balizas de superfície, como uma tabela executável de antes/depois. Um utilizador no polo sul vê um conjunto orbital esparso numa faixa estreita do céu, pelo que a geometria de medição de distâncias é mal condicionada; algumas BALIZAS DE SUPERFÍCIE TOPOGRAFADAS fornecem as linhas de linha de vista de baixa elevação e grande azimute que falta a um conjunto todo ele zenital, e a diluição horizontal da precisão desce abruptamente. O cenário indica três configurações numa época — só os satélites, os satélites mais as balizas visíveis, e uma constelação maior como via alternativa para a mesma geometria — cada uma com as suas contagens de fontes visíveis, o seu DOP completo e a exatidão realizada de 1 sigma em METROS, obtida multiplicando por um erro de distância equivalente do utilizador por baliza, montado como a soma quadrática dos termos de sincronização de relógio, multipercurso e levantamento. A visibilidade das balizas é o horizonte geométrico de duas alturas da Lua sem atmosfera (sem atmosfera, pelo que o limite é exato), e a montagem do DOP é o mesmo núcleo verificado face ao gnss_lib_py em tests/dop_reference.rs. PORQUE EXISTE ESTE TIPO DE CENÁRIO: o módulo subjacente existe no motor e foi verificado face a um percurso de DOP independente desde L08/L09, mas não era acessível a partir de uma execução — sem tipo de cenário, sem ramo de despacho, sem ficheiro incluído. O README anunciava a capacidade e a matriz de verificação não tinha NENHUMA linha para ela, pelo que era simultaneamente afirmada em prosa e não afirmada no registo, ao mesmo tempo que era inacessível no motor. As predefinições são a geometria que já tem uma referência de ouro registada (um utilizador a -80 graus com uma antena de 2 m, três balizas a -80/0, -79/+60 e -79/-60 a 2 km, um instantâneo ilustrativo de seis satélites LCNS em t=0, uma máscara de 5 graus), pelo que uma execução simples reproduz uma tabela que uma referência independente já cobre, em vez de inventar números novos. MODELLED: o projeto da constelação, a colocação das balizas e todas as magnitudes do orçamento de erro são entradas ilustrativas, não um levantamento no terreno nem uma ligação medida; apenas a aritmética do DOP, a forma fechada do horizonte e a relação sigma = DOP x sigma_URE estão ancoradas externamente. Não é um compromisso de desempenho do serviço.

lunar-beacon.toml

tipo lunar-beaconas linhas do tipo de cenário no registo são modeladas · 0 de 1 linhas validadas

Aumento por balizas de superfície de um serviço de navegação orbital lunar.

kind = "lunar-beacon"
n_satellites = 6
comparison_n_satellites = 24
epoch_s = 0.0
elevation_mask_deg = 5.0
clock_sync_m = 1.0
multipath_m = 0.5
survey_m = 0.3

Abrir no Kshana Studio · Ver no GitHub

lunar-descent#

Orçamento de dispersão de aterragem MODELLED para uma descida propulsionada a um local polar sul (classe Artemis). Por eixo horizontal, um modelo de erro inercial de cinco estados (posição, velocidade, enviesamento do acelerómetro, inclinação de atitude, enviesamento do giroscópio) é conduzido pela força específica da descida; um filtro sequencial recebe soluções de posição dos auxílios ativados: uma solução AFS a partir dos relés visíveis de uma constelação ILLUSTRATIVE de classe LCNS (isolada, ou diferencial usando o resíduo do enlace de correção de lunar-differential-pnt, com o relógio auxiliado quando apenas três relés estão visíveis) e uma solução relativa ao terreno (o correlacionador TERCOM/SITAN da biblioteca sobre um relevo sintético, ou o limite de Cramer-Rao da correlação de uma janela de elevação do DEM polar sul real do LOLA). O tempo lunar entra pelo relógio do veículo nas soluções (o desvio LTC-TT de lunar-time-offset, ou a incerteza do seu intervalo publicado) e como um erro de marcação de tempo ao longo da trajetória. Indica a elipse de aterragem de 3 sigma, R95, as fontes inerciais em forma fechada, a contribuição de cada auxílio, a ablação de cada combinação de auxílios, uma calibração de Monte Carlo da elipse e a covariância transferida. MODELLED: classe de IMU, conjunto de relés, perfil de descida e termo de orientação ilustrativos; terrain-nav usa um relevo sintético em escala métrica terrestre; a disponibilidade de AFS é de uma época com uma máscara plana. Sem aval de agência; software de caráter consultivo, não um equipamento de navegação certificado.

lunar-descent.toml

tipo lunar-descentnão associado a um módulo do registo pelo nome

Dispersão de aterragem lunar: o orçamento de uma descida propulsionada a um local polar sul (classe Artemis), a partir da deriva inercial do conjunto de descida e do que a navegação relativa ao terreno, os sinais da LunaNet e o tempo lunar retiram dele.

kind = "lunar-descent"
site_lat_deg = -89.5
site_lon_deg = 0.0
more_site_lats_deg = [-89.9, -88.5, -85.0]
descent_s = 600.0
horizontal_speed_m_s = 150.0
accel_bias_ug = 100.0
align_arcmin = 3.0

Ainda não está no GitHub

lunar-descent-lola.toml

tipo lunar-descentnão associado a um módulo do registo pelo nome

Dispersão de aterragem lunar com o DEM polar sul real do LOLA: o orçamento de uma descida propulsionada a um local polar sul (classe Artemis), a partir da deriva inercial do conjunto de descida e do que a navegação relativa ao terreno, os sinais da LunaNet e o tempo lunar retiram dele.

kind = "lunar-descent"
site_lat_deg = -89.5
site_lon_deg = 0.0
more_site_lats_deg = [-89.9, -88.5, -85.0]
descent_s = 600.0
horizontal_speed_m_s = 150.0
accel_bias_ug = 100.0
align_arcmin = 3.0

Ainda não está no GitHub

lunar-differential-pnt#

PNT DIFERENCIAL lunar modelado (um análogo lunar do DGNSS/SBAS): uma estação de referência da classe NovaMoon, numa localização selenográfica CONHECIDA, calcula correções diferenciais por satélite a partir de uma constelação ILLUSTRATIVE de classe Moonlight/LCNS, de fontes públicas (NovaMoon referida apenas como uma CLASSE de sistema, sem afiliação à ESA), e um utilizador afastado por baseline_km aplica-as, de modo que os erros de órbita e de relógio de MODO COMUM se cancelam. O termo do relógio cancela-se EXATAMENTE (uma identidade algébrica); do termo da órbita resta apenas a projeção da diferença de linha de vista, que → 0 quando a linha de base → 0 (o piso da decorrelação espacial) e cresce ≈ linearmente com a linha de base. Indica o erro de posição 3-D do utilizador COM versus SEM correções, o fator de redução, a curva do erro em função da linha de base e um nível de proteção do utilizador que REAPROVEITA a maquinaria SBAS da DO-229E (crate::sbas) com o resíduo diferencial σ. MODELLED — identidade de cancelamento exata + modelo de decorrelação de primeira ordem; não validado com dados reais; sem TRL, herança de voo nem aval de agências. Determinístico se tiver semente fixa.

lunar-differential-pnt.toml

tipo lunar-differential-pntnão associado a um módulo do registo pelo nome

PNT lunar DIFERENCIAL — um análogo lunar de DGNSS / SBAS.

kind = "lunar-differential-pnt"
n_sats = 8
sma_km = 9737.4
eccentricity = 0.6
inc_deg = 57.7
argp_deg = 90.0
ref_lat_deg = -89.0
ref_lon_deg = 0.0

Abrir no Kshana Studio · Ver no GitHub

lunar-frame-campaign#

Datum de referencial de sete parâmetros de Helmert (semelhança) conduzido por uma CAMPANHA DE OBSERVAÇÃO SIMULADA, e não por uma transformação injetada. Uma rede de estações terrestres observa um catálogo de balizas da superfície lunar segundo um calendário explícito; as derivadas parciais do atraso VLBI lunar são acumuladas ao longo desse calendário numa matriz de informação de Fisher das coordenadas das balizas, exatamente como o lunar-vlbi-fim; e essa informação é propagada através do projeto de Helmert A = [I3 | [p]_x | p] nos pontos do catálogo para a covariância do datum H = A^T M_b A, diagnosticada por crate::fim::crlb. NENHUMA transformação é injetada e nada é recuperado a partir de uma resposta plantada, pelo que a exatidão do datum indicada decorre do programa de observação: reduzir o sigma do atraso a metade reduz-no exatamente a metade, e alongar o arco melhora-a porque a libração que o relatório MEDE (sub_earth_direction_sweep_deg) é o que separa a coordenada da baliza ao longo da linha de vista das do plano do céu. Posto, defeito de datum, número de condição, o espetro completo, as direções inobserváveis NA BASE DE SETE PARÂMETROS, a direção mais fraca mesmo com posto completo e a parcela de cada parâmetro nela são emitidos em cada execução; um parâmetro que a campanha não restringe é publicado como NULL com um estado, nunca lido a partir de uma inversa quase singular. A correlação de erro das balizas é medida, não assumida: com as estações fixas nenhuma observação toca em duas balizas, pelo que a matriz de informação é exatamente diagonal por blocos (offblock_fraction 0), e com as estações estimadas o bloco marginalizado por Schur está acoplado, sendo a correlação induzida impressa e toda a propagação repetida com ela descartada, de modo que o preço de um pressuposto de independência é um número. A mesma propagação com um sigma isotrópico por coordenada, e o erro de recuperação que o cenário lunar-frame-realisation indica, são ambos executados aqui e impressos a par do valor da campanha, com as suas razões. MODELLED: o catálogo de balizas tem fonte, mas a CAMPANHA é simulada — a rede de estações e o sigma do atraso são entradas ilustrativas, as observações de atraso individuais são tratadas como independentes, e as efemérides do centro da Lua, os relógios das estações, a troposfera e os parâmetros de orientação da Terra são mantidos FIXOS, pelo que a covariância do datum é um limite de Cramer-Rao para um conjunto reduzido de parâmetros. Não é um produto geodésico.

lunar-frame-campaign.toml

tipo lunar-frame-campaignnão associado a um módulo do registo pelo nome

Datum de referencial lunar de Helmert de sete parâmetros conduzido por uma CAMPANHA DE OBSERVAÇÃO SIMULADA (G9).

kind = "lunar-frame-campaign"

Abrir no Kshana Studio · Ver no GitHub

lunar-frame-realisation#

Realização modelada do referencial lunar: um ajuste de datum de Helmert (semelhança) de 7 parâmetros — 3 de translação, 3 de rotação de ângulo pequeno, 1 de escala — que liga um conjunto estimado de coordenadas de pontos MCMF de origem selenográfica a um datum por mínimos quadrados ponderados (crate::batch_ls::gauss_newton), mais uma ligação de orientação simples que exprime a pequena rotação realizada em torno dos eixos do ICRF relativamente à orientação do corpo segundo o WGCCRE da IAU de 2015. O cenário injeta uma pequena transformação conhecida (translação de ~dezenas de m, rotação de ~µrad, escala de ~1e-7) numa rede sintética de pontos bem distribuída, acrescenta ruído gaussiano de semente fixa, recupera o datum e indica a transformação recuperada, o erro de recuperação por parâmetro face à verdade injetada e o resíduo RMS pós-ajuste. Autoconsistência MODELLED — recupera uma transformação de semelhança injetada (sem ruído até ~à precisão da máquina), NÃO uma realização face a dados reais de seguimento/VLBI; determinístico (semente fixa); sem TRL, herança de voo nem aval de agências.

lunar-frame-realisation.toml

tipo lunar-frame-realisationnão associado a um módulo do registo pelo nome

Realização do referencial lunar — ajuste de um datum de Helmert (de semelhança) de 7 parâmetros.

kind = "lunar-frame-realisation"
n_points = 8
tx_m = 25.0
ty_m = -40.0
tz_m = 15.0
rot_x_urad = 3.0
rot_y_urad = -2.0
rot_z_urad = 5.0

Abrir no Kshana Studio · Ver no GitHub

lunar-infrastructure#

Estudos MODELLED da órbita e da superfície da Lua como infraestrutura de navegação e geodésica, cinco estudos num único tipo de cenário selecionado por study: od-consistency (determinação de órbita a bordo com Earth-GNSS numa NRHO ou ELFO face à determinação de órbita radiométrica independente a partir do solo, avaliadas pelas suas próprias covariâncias sobre um Monte Carlo de semente fixa), carrier-phase (fase da portadora de dupla diferença conjunta superfície-orbitador e resolução de ambiguidades inteiras com LAMBDA), frame-coestimation (uma estação de superfície e orbitadores acrescentados à medição de distâncias de estações terrestres para o datum de referencial lunar de sete parâmetros), space-tie (GNSS, VLBI e telemetria laser numa única nave, precisão da ligação de referenciais face ao erro de ligação local) e geodesy-sensitivity (informação de Fisher dos números de Love lunares h2, k2, l2 e da libração física a partir de telemetria laser, seguimento de orbitadores, um gravímetro de superfície e um relógio de superfície). Um modelo restrito de três corpos com simplificações indicadas; a numérica é verificada face a programas independentes e nada é comparado com uma medição de uma grandeza lunar.

lunar-infrastructure-carrier-phase.toml

tipo lunar-infrastructurenão associado a um módulo do registo pelo nome

Cenário de infraestrutura lunar do Kshana: fase da portadora, o exemplo RÁPIDO (dois arcos curtos, 10 extrações, segundos; a configuração pontuada, três arcos e 400 extrações, é xval/lunar-infra/scenarios/carrier-phase-scored.toml). MODELLED; o projeto, as entradas e os limiares estão fixados em xval/lunar-infra/PREREGISTRATION.md (submetido antes de qualquer execução). As entradas ILLUSTRATIVE estão etiquetadas aí com as suas fontes públicas.

kind = "lunar-infrastructure"
study = "carrier-phase"
seed = 20261019
family = "nrho"
sample_s = 600.0
arcs_days = [0.25, 0.5]
lat_deg = 0.0
lon_deg = 0.0

Abrir no Kshana Studio · Ver no GitHub

lunar-infrastructure-frame-coestimation.toml

tipo lunar-infrastructurenão associado a um módulo do registo pelo nome

Cenário de infraestrutura lunar do Kshana: frame-coestimation. MODELLED; o projeto, as entradas e os limiares estão fixados em xval/lunar-infra/PREREGISTRATION.md (submetido antes de qualquer execução). As entradas ILLUSTRATIVE estão etiquetadas aí com as suas fontes públicas.

kind = "lunar-infrastructure"
study = "frame-coestimation"
seed = 20261019
family = "nrho"
arc_days = 6.56
sample_s = 900.0
sigma_m = 0.05
epochs = 200

Abrir no Kshana Studio · Ver no GitHub

lunar-infrastructure-geodesy-sensitivity.toml

tipo lunar-infrastructurenão associado a um módulo do registo pelo nome

Cenário de infraestrutura lunar do Kshana: geodesy-sensitivity. MODELLED; o projeto, as entradas e os limiares estão fixados em xval/lunar-infra/PREREGISTRATION.md (submetido antes de qualquer execução). As entradas ILLUSTRATIVE estão etiquetadas aí com as suas fontes públicas.

kind = "lunar-infrastructure"
study = "geodesy-sensitivity"
seed = 20261019
sigma_m = 0.05
epochs = 400
sigma_mm_s = 0.05
arc_days = 27.3
sample_s = 3600.0

Abrir no Kshana Studio · Ver no GitHub

lunar-infrastructure-od-consistency.toml

tipo lunar-infrastructurenão associado a um módulo do registo pelo nome

Cenário de infraestrutura lunar do Kshana: od-consistency. MODELLED; o projeto, as entradas e os limiares estão fixados em xval/lunar-infra/PREREGISTRATION.md (submetido antes de qualquer execução). As entradas ILLUSTRATIVE estão etiquetadas aí com as suas fontes públicas.

kind = "lunar-infrastructure"
study = "od-consistency"
seed = 20261019
family = "nrho"
arc_days = 3.0
sample_s = 600.0
altitude_km = 20180.0
inclination_deg = 55.0

Abrir no Kshana Studio · Ver no GitHub

lunar-infrastructure-od-consistency-model-error.toml

tipo lunar-infrastructurenão associado a um módulo do registo pelo nome

Cenário de infraestrutura lunar do Kshana: od-consistency com uma aceleração não modelada. MODELLED; o projeto, as entradas e os limiares estão fixados em xval/lunar-infra/PREREGISTRATION.md (submetido antes de qualquer execução). As entradas ILLUSTRATIVE estão etiquetadas aí com as suas fontes públicas.

kind = "lunar-infrastructure"
study = "od-consistency"
seed = 20261019
family = "nrho"
arc_days = 3.0
sample_s = 600.0
altitude_km = 20180.0
inclination_deg = 55.0

Abrir no Kshana Studio · Ver no GitHub

lunar-infrastructure-space-tie.toml

tipo lunar-infrastructurenão associado a um módulo do registo pelo nome

Cenário de infraestrutura lunar do Kshana: space-tie. MODELLED; o projeto, as entradas e os limiares estão fixados em xval/lunar-infra/PREREGISTRATION.md (submetido antes de qualquer execução). As entradas ILLUSTRATIVE estão etiquetadas aí com as suas fontes públicas.

kind = "lunar-infrastructure"
study = "space-tie"
seed = 20261019
family = "nrho"
arc_days = 6.56
sample_s = 900.0
gnss_sigma_m = 10.0
vlbi_sigma_m = 1.0

Abrir no Kshana Studio · Ver no GitHub

lunar-integrity#

Passagem de nível de proteção ARAIM no polo sul lunar face a um conjunto de retransmissores LunaNet representativo. sigma_ure_m expõe a exatidão de medição de distâncias do sinal no espaço (os níveis de proteção escalam linearmente com ela, pelo que variá-la responde à pergunta sobre que exatidão de medição de distâncias um limite de alerta exige). Por predefinição, o caso histórico do polo sul da classe LNIS.

lunanet-araim.toml

tipo lunar-integritynão associado a um módulo do registo pelo nome

Integridade no polo sul lunar: um recetor pousado na região Artemis face a um conjunto representativo de retransmissores LunaNet, níveis de proteção ARAIM ao longo de uma passagem de 24 h.

kind = "lunar-integrity"
step_s = 3600.0
duration_s = 86400.0
alert_limit_m = 50.0
p_hmi = 1.0e-4

Abrir no Kshana Studio · Ver no GitHub

lunar-interop-export#

Exportação de interoperabilidade lunar modelada: emite o referencial lunar, a escala de tempo lunar e as efemérides lunares em formas de intercâmbio alinhadas com LunaNet/IOAG e baseadas em CCSDS, com aderência à norma de ida e volta e dos campos. REAPROVEITA o emissor e analisador CCSDS OEM 2,0 da crate (crate::oem), reetiquetado para o contexto lunar — o REF_FRAME do OEM transporta o referencial do corpo lunar segundo o WGCCRE da IAU de 2015 (MOON_ME / MOON_PA), o TIME_SYSTEM a escala de tempo lunar (LTC / TCL / UTC), CENTER_NAME = MOON — sobre umas efemérides de amostra ilustrativas da classe LCNS (posições de crate::lunar_service, velocidade por diferença finita). Emite também um descritor de tempo lunar alinhado com LunaNet/IOAG (id da escala, taxa secular em µs/dia de crate::lunar_time, banda publicada, superfície de referência) que faz ida e volta via serde_json, e envolve os artefactos no envelope KIF existente (crate::interchange) com a etiqueta de honestidade MODELLED. Indica os artefactos emitidos, o número de linhas do OEM, a aderência dos campos à norma (resultado positivo) e a lista de campos presentes/em falta, a ida e volta do OEM correta, a ida e volta dos metadados de tempo correta e o tamanho em bytes do KIF. MODELLED — a referência independente é a ida e volta determinística e a aderência dos nomes de campos à norma face ao CCSDS OEM publicado e à semântica de campos do LunaNet/IOAG; NÃO é um ensaio certificado de aderência à norma de interoperabilidade; efemérides ilustrativas de fontes públicas, sem afiliação à ESA; sem TRL, herança de voo nem aval de agências.

lunar-interop-export.toml

tipo lunar-interop-exportnão associado a um módulo do registo pelo nome

Exportação de interoperabilidade lunar — intercâmbio alinhado com LunaNet / IOAG e baseado em CCSDS.

kind = "lunar-interop-export"
frame = "MOON_ME"
time_system = "LTC"
n_states = 9
step_min = 30.0
epoch = "2030-01-01T00:00:00"
object = "LCNS-ILLUSTRATIVE-1"

Abrir no Kshana Studio · Ver no GitHub

lunar-jamming#

Jamming de RF nativo lunar: razão jammer-sinal por satélite, C/N₀ efetivo e perda de bloqueio para um utilizador à superfície selenográfica sob um jammer na superfície lunar (ou elevado), sobre a constelação ilustrativa de fontes públicas de órbita lunar da classe Moonlight/LCNS. Compõe a física aberta de jamming existente (jamming::j_over_s_db, effective_cn0_dbhz, rx_antenna_gain_db, lock_status, q_factor) com a geometria do céu lunar existente (lunar_service::LunarConstellation + topocentric, lunar::selenographic_to_mcmf); não se rededuz nenhuma geometria nem radiometria. Ao contrário do tipo de cenário jamming terrestre, a componente do sinal NÃO é uma potência recebida fixa: a potência recebida isotrópica de cada satélite é o seu próprio orçamento de ligação EIRP − FSPL(distância oblíqua), pelo que o J/S varia de satélite para satélite com a distância e a elevação lunares. Indica UMA LINHA POR LIGAÇÃO (época, satélite) VISÍVEL — azimute, elevação, distância oblíqua, as duas potências recebidas de que o J/S é a diferença, o J/S, o C/N₀ nominal e efetivo e o estado de bloqueio — mais figuras de mérito agregadas a par dessa tabela (nunca em seu lugar), e a mesma tabela como artefacto CSV. Cada campo numérico emitido traz uma unidade e uma classe de proveniência. Os subresultados VALIDATED trazem a referência independente do respetivo módulo de origem (a equação antiinterferência e a ligação J/S de Kaplan & Hegarty §9,4, referenciadas externamente em tests/gnss_denied_jamming_resilience_reference.rs; a geometria lunar de lunar_service). A própria composição é verificada de forma cruzada face a um percurso independente de dois orçamentos de ligação (linkbudget::received_signal_power_dbw, uma expressão de perda no espaço livre diferente) até 1e-9 dB. MODELLED: a constelação ilustrativa, a EIRP / potência do jammer / ganhos de antena / temperatura de ruído representativos, e a ausência de sombreamento do terreno, multipercurso, dinâmica do AGC e anulação adaptativa. Não é um produto certificado de negação de serviço. Com um jammer configurado, o relatório traz também um CONTORNO DE NEGAÇÃO COM UMA BANDA DE INCERTEZA, em vez de um contorno lido a partir de um único escalar: a distribuição completa medida do C/N₀ do sinal pretendido sobre a tabela por satélite (n, mín., p05, p25, mediana, p75, p95, máx., média, desvio-padrão amostral e a própria assimetria da amostra), e o contorno avaliado em cada uma dessas estatísticas de ordem segundo AMBOS os critérios de negação que o motor reconhece — o incumbente de razão de potências (J/S = 30 dB, como em attack-surface e tracking-loop) e o de perda de bloqueio (C/N₀ efetivo a descer até tracking_threshold_dbhz, o critério que a própria coluna de estado deste relatório utiliza) — nos dois eixos do plano de negação (EIRP do jammer exigida à distância de afastamento do cenário, distância de afastamento de negação à EIRP do cenário). Os limites da banda SÃO contour(p05) e contour(p95), o mesmo mapa de forma fechada aplicado aos quantis da própria amostra: não um sigma ajustado à amostra e não mediana ± k·desvio-padrão, com o desvio-padrão emitido por continuidade e não utilizado por nada. Um quantil já igual ou inferior ao limiar de seguimento não tem J/S de negação finito e as suas colunas de perda de bloqueio são nulas, com um motivo contabilizado, nunca um raio truncado.

lunar-jamming.toml

tipo lunar-jammingnão associado a um módulo do registo pelo nome

Jamming de RF nativo lunar: J/S por satélite para um utilizador à superfície lunar.

kind = "lunar-jamming"
n_sats = 4
sma_km = 9737.4
eccentricity = 0.6
inc_deg = 57.7
argp_deg = 90.0
site_lat_deg = -89.67
site_lon_deg = 129.78

Abrir no Kshana Studio · Ver no GitHub

lunar-joint-od-clock#

Estimador em lote multitécnica modelado de OD lunar + relógio, numa rede SIMULADA: um ajuste instantâneo de Gauss-Newton que funde atrasos VLBI geodésicos de linha de base terrestre, distâncias locais lunares estação↔satélite e distâncias entre satélites para recuperar, em conjunto, a posição 3-D de uma estação à superfície lunar, as posições de uma pequena constelação e o desvio de relógio de cada ativo a partir de uma verdade injetada. O resultado principal, apresentado com honestidade — o VLBI torna observável a posição 3-D completa da estação, onde a medição de distâncias apenas local lunar deixa uma direção fracamente observada — é indicado como o contraste do erro da estação com versus sem VLBI. Recuperação simulada em malha fechada MODELLED (a verdade partilha o modelo de observação), determinística (semente fixa), NÃO validada com dados reais; sem propagação de modelo de forças dentro do resolvedor; sem TRL, herança de voo nem aval de agências.

lunar-joint-od-clock.toml

tipo lunar-joint-od-clocknão associado a um módulo do registo pelo nome

Determinação conjunta lunar de OD + relógio com várias técnicas (uma rede SIMULADA).

kind = "lunar-joint-od-clock"
n_sat = 3
n_earth = 6
seed = 42
sigma_vlbi_s = 1.0e-11
sigma_range_m = 0.1
sigma_isl_m = 0.1
station_lat_deg = -88.0

Abrir no Kshana Studio · Ver no GitHub

lunar-llr-datum#

Datum de referencial lunar de Helmert de sete parâmetros conduzido por uma campanha de observação REAL e ARQUIVADA, e não por uma simulada. Onde o lunar-frame-campaign removeu a transformação injetada mas continuou a indicar a sua rede de estações, o seu calendário e o seu sigma por observação como entradas ILLUSTRATIVE, este tipo de cenário retira os três da medição: as épocas são os instantes de transmissão a partir do solo de pontos normais arquivados dos Consolidated Laser Ranging Data da ILRS, as observações são as distâncias laser efetivamente disparadas contra as cinco matrizes de retrorrefletores na Lua, e cada peso de observação é a PRÓPRIA precisão arquivada desse ponto normal, bin_rms/sqrt(n_raw), lida do ficheiro. As coordenadas das estações provêm da solução SLR ITRF2020 do IERS (propagadas para a época pelas suas velocidades publicadas) e as coordenadas dos refletores da Tabela 7 do JPL DE430, no referencial de Terra média/rotação média que o modelo WGCCRE da IAU de 2015 realiza. As derivadas parciais das distâncias acumulam-se na matriz de informação de Fisher conjunta das coordenadas dos refletores e propagam-se através do mesmo projeto de Helmert para a covariância do datum, diagnosticada por crate::fim::crlb. Posto, defeito, condição, espetro, direções inobserváveis na base de sete parâmetros, a direção mais fraca com posto completo e a parcela de cada parâmetro nela são emitidos em cada execução, e um parâmetro não restringido é publicado como NULL com um estado. A correlação entre matrizes é MEASURED como exatamente zero, em vez de assumida, porque uma distância laser toca numa só matriz. Um registo que os catálogos não conseguem situar — uma estação sem posição ITRF publicada — é IGNORADO E CONTADO, nunca recebendo uma coordenada substituta. QUAIS AS LIGAÇÕES MEASURED E QUAIS AS MODELLED É O RELATÓRIO, NÃO UMA NOTA DE RODAPÉ: as efemérides do centro da Lua e a orientação do corpo segundo a IAU continuam modeladas e a sua dimensão combinada é emitida como o resíduo da distância unidirecional observado menos calculado sobre todos os pontos utilizados; a troposfera, as marés do corpo sólido, a excentricidade da estação, o movimento polar, o UT1-UTC, o atraso relativista e os relógios das estações estão ausentes e incluídos nesse resíduo. Como um erro de efemérides só chega a uma covariância através da direção de cada linha de vista, cada execução volta também a resolver todo o datum com todas as derivadas parciais inclinadas de sensitivity_tilt_deg (com o sinal alternado) e emite a razão, pelo que a insensibilidade da covariância às efemérides modeladas é um número e não um argumento. Os valores da própria campanha simulada são EXECUTADOS e impressos a par dos medidos, não transcritos. MODELLED: os valores de sete parâmetros são um limite de Cramer-Rao para um conjunto reduzido de parâmetros num calendário real — não um datum resolvido, não uma análise LLR e não um produto geodésico. A fatia de dados reais registada é distribuída com o repositório, mas não com a crate publicada; aponte data_dir para uma cópia da mesma.

lunar-llr-datum.toml

tipo lunar-llr-datumnão associado a um módulo do registo pelo nome

Datum de referencial lunar de Helmert de sete parâmetros a partir de uma campanha de observação REAL e ARQUIVADA (V3).

kind = "lunar-llr-datum"

Abrir no Kshana Studio · Ver no GitHub

lunar-station-geodesy-baseline.toml

tipo lunar-llr-datumnão associado a um módulo do registo pelo nome

Geodesia da estação de referência lunar, LINHA DE BASE: apenas as cinco matrizes de retrorrefletores atuais.

kind = "lunar-llr-datum"
epoch_year = 2024
epoch_month = 1
epoch_day = 1
arc_hours = 672.0
step_min = 60.0
delay_sigma_s = 1.0e-11
elevation_mask_deg = 10.0

Abrir no Kshana Studio · Ver no GitHub

lunar-station-geodesy-with-station.toml

tipo lunar-llr-datumnão associado a um módulo do registo pelo nome

Geodesia de uma estação de referência lunar, COM ESTAÇÃO: as cinco matrizes de retrorrefletores mais um retrorrefletor e um farol VLBI num local de estação de referência lunar no polo sul.

kind = "lunar-llr-datum"
extra_earth_elevation_mask_deg = 0.0
name = "lunar-reference-station-reflector"
lat_deg = -89.0
lon_deg = 0.0
alt_m = 0.0
name = "lunar-reference-station-beacon"
lat_deg = -89.0

Abrir no Kshana Studio · Ver no GitHub

lunar-orbit-rendezvous#

Navegação relativa MODELLED para uma acoplagem no estilo Orion-módulo de aterragem numa órbita lunar baixa ou numa órbita polar elíptica (classe Artemis). Um veículo perseguidor e um alvo voam na mesma órbita sob o modelo de forças lunares da biblioteca; uma estimativa conjunta de Gauss-Newton em lote de 21 parâmetros ao longo do arco (dois estados de veículo e enviesamentos persistentes do sinal no espaço) funde uma solução absoluta de posição por veículo a partir de um conjunto de relés ILLUSTRATIVE de classe LCNS (relés atrás da Lua descartados, quatro necessários, o erro de modo comum do sinal no espaço a cancelar-se entre os veículos) e uma distância por enlace cruzado, com a precisão de medição de distância vinda do limite de seguimento de código do piloto AFS da LunaNet. Indica o erro relativo formal e de Monte Carlo de posição e velocidade nos eixos LVLH do alvo, a disponibilidade das soluções, o erro de estimação normalizado quadrático médio face ao valor esperado, e qualquer tentativa cuja iteração não convergiu, a deriva por ignorar os harmónicos da gravidade e a covariância 6x6 completa transferida. Uma verificação de Hill/Clohessy-Wiltshire em forma fechada aplica-se ao caso circular. MODELLED: conjunto de relés, orçamento de erro e priores ilustrativos; a referência e o estimador partilham um único modelo de forças, de modo que o NEES verifica a autoconsistência e não o erro do modelo. Sem aval de agência; software de caráter consultivo, não um equipamento de navegação certificado.

lunar-orbit-rendezvous.toml

tipo lunar-orbit-rendezvousnão associado a um módulo do registo pelo nome

Encontro lunar: navegação relativa para uma acoplagem no estilo Orion-módulo de aterragem numa órbita lunar baixa polar circular de 100 km (classe Artemis), com um campo gravitacional lunar e sinais no estilo LunaNet.

kind = "lunar-orbit-rendezvous"
orbit = "llo"
separation_m = 2000.0
arc_s = 7200.0
step_s = 20.0
n_relays = 8
sis_ure_m = 30.0
common_mode_fraction = 0.9

Ainda não está no GitHub

lunar-orbit-rendezvous-elfo.toml

tipo lunar-orbit-rendezvousnão associado a um módulo do registo pelo nome

Encontro lunar numa órbita polar elíptica: navegação relativa para uma acoplagem no estilo Orion-módulo de aterragem numa órbita polar de 100 km por 3000 km com periapsia sobre o polo sul (classe Artemis), com um campo gravitacional lunar e sinais no estilo LunaNet.

kind = "lunar-orbit-rendezvous"
orbit = "elfo"
separation_m = 2000.0
arc_s = 7200.0
step_s = 20.0
n_relays = 8
sis_ure_m = 30.0
common_mode_fraction = 0.9

Ainda não está no GitHub

lunar-station-coverage#

Cobertura modelada de uma estação de referência lunar: uma varredura de Monte Carlo do modelo de PNT diferencial lunar sobre uma grelha de utilizadores do polo sul e um dia de épocas. Uma estação de referência diferencial num local conhecido do polo sul corrige uma constelação indicada (kepleriana ilustrativa ou efemérides tabeladas) com um erro de sinal no espaço, um erro de levantamento, uma latência de correção e uma quantização da ligação indicados; por ponto e ao longo da região, indica o erro de posição percentil corrigido e não corrigido (3-D, horizontal, vertical), a disponibilidade, a cobertura face a um limiar indicado, os níveis de proteção da DO-229E, o raio de cobertura por azimute e o orçamento da ligação de correção na estação e no pior ponto. Não é uma afirmação sobre o desempenho de nenhum sistema real; sem afiliação nem aval de nenhuma agência. MODELLED.

lunar-station-coverage.toml

tipo lunar-station-coveragenão associado a um módulo do registo pelo nome

Cobertura de uma estação de referência lunar: que exatidão de posicionamento e que nível de proteção um utilizador obtém de uma estação de referência diferencial lunar num local conhecido do polo sul, sobre a região polar sul e durante um dia.

kind = "lunar-station-coverage"
n_sats = 8
sma_km = 9737.4
eccentricity = 0.6
inc_deg = 57.7
argp_deg = 90.0
mask_deg = 5.0
station_lat_deg = -89.0

Abrir no Kshana Studio · Ver no GitHub

lunar-station-coverage-public-sources.toml

tipo lunar-station-coveragenão associado a um módulo do registo pelo nome

Cobertura de uma estação de referência lunar com os pressupostos PUBLICAMENTE DECLARADOS: o mesmo tipo de cenário que lunar-station-coverage.toml, com cada entrada que uma fonte pública declara definida a partir dela e citada pelo identificador da fonte; cada entrada que nenhuma fonte declara é mantida a partir da predefinição da árvore e etiquetada ILLUSTRATIVE. Fontes (obtidas em 2026-10-12; títulos, identificadores e licenças em docs/LUNAR-REFERENCE-STATION.md): S1 arXiv:2602.08432v3 S2 IOAG Cislunar PNT Workshop 2025, "Lunar local Differential PNT and Selenodetic Reference Station" (diapositivos) S3 UNOOSA ICG WG-B, Lunar PNT, June 2024 (LunarPNT_Jun24_01_04.pdf) S4 IOAG Cislunar 2026, "Moonlight Programme Development Status"

kind = "lunar-station-coverage"
n_sats = 4
sma_km = 9737.4
eccentricity = 0.6
inc_deg = 57.7
argp_deg = 90.0
mask_deg = 5.0
station_lat_deg = -89.4765

Abrir no Kshana Studio · Ver no GitHub

lunar-station-coverage-terrain.toml

tipo lunar-station-coveragenão associado a um módulo do registo pelo nome

Cobertura de uma estação de referência lunar com terreno: o cenário lunar-station-coverage fornecido, com um horizonte por local traçado por raios sobre um modelo digital de elevação lunar real na estação e em cada ponto de utilizador, em vez da máscara de elevação plana apenas.

kind = "lunar-station-coverage"
n_sats = 8
sma_km = 9737.4
eccentricity = 0.6
inc_deg = 57.7
argp_deg = 90.0
mask_deg = 5.0
station_lat_deg = -89.0

Abrir no Kshana Studio · Ver no GitHub

lunar-surface#

Disponibilidade MODELLED de posicionamento e temporização na superfície por local e estação para locais polares sul de classe Artemis. Para cada local e estação (uma época e uma janela após ela) indica o posicionamento por relés (quatro ou mais relés de uma constelação ILLUSTRATIVE de classe LCNS à vista e PDOP abaixo de um limite, a partir das mesmas funções de moonlight-service-volume e, com uma secção de terreno, o horizonte por traçado de raios do terreno de lunar-station-coverage), se a Terra e o Sol estão acima do horizonte do local (Sol, Lua e orientação lunar analíticos, libração incluída, que é o que varia com a estação) e a disponibilidade de temporização (um relé ou a Terra à vista) com o maior intervalo sem nenhum dos dois, o holdover que um relógio de superfície precisa atravessar. Um resultado de local único é igual, bit a bit, ao de moonlight-service-volume. MODELLED: conjunto de relés kepleriano ilustrativo numa Lua de rotação média; o valor dos relés não muda com a estação; o terreno é o recorte de 1200 m do LOLA. Sem aval de agência; software de caráter consultivo, não um equipamento de navegação certificado.

lunar-surface.toml

tipo lunar-surfacenão associado a um módulo do registo pelo nome

Disponibilidade de PNT e temporização na superfície lunar por local e estação (locais polares sul de classe Artemis).

kind = "lunar-surface"
season_dates = ["2028-01-01", "2028-04-01", "2028-07-01", "2028-09-30"]
window_days = 27.3217
step_min = 30.0
n_sats = 8
sma_km = 9737.4
eccentricity = 0.6
inc_deg = 57.7

Ainda não está no GitHub

lunar-surface-terrain.toml

tipo lunar-surfacenão associado a um módulo do registo pelo nome

Disponibilidade de PNT e temporização na superfície lunar por local e estação com o horizonte de terreno polar sul real do LOLA (locais polares sul de classe Artemis).

kind = "lunar-surface"
season_dates = ["2028-01-01", "2028-04-01", "2028-07-01", "2028-09-30"]
window_days = 27.3217
step_min = 30.0
n_sats = 8
sma_km = 9737.4
eccentricity = 0.6
inc_deg = 57.7

Ainda não está no GitHub

lunar-time-budget#

Orçamento de erro de tempo MODELLED, de ponta a ponta, do Tempo Lunar Coordenado (LTC): os sete termos de erro do LTC reunidos como curvas de erro de tempo x_i(τ) ao longo de uma grelha completa de tempos de média, somados em soma quadrática em x_Σ(τ), e o CRUZAMENTO τ entre relógio e referencial em que o termo crescente do relógio ultrapassa o termo constante de realização do referencial em tempo real (abaixo dele o orçamento é limitado pelo referencial, acima dele limitado pelo relógio) — a resposta honesta ao artefacto de um único τ. As inclinações em τ são de forma fechada e verificáveis analiticamente (relógio τ^{+1/2}/τ^{+1}, patamares τ^0, medição τ^{-1/2}) e as linhas do relógio reproduzem as especificações publicadas de relógio a um dia (crate::clock_specs); as MAGNITUDES dos patamares da ligação RF/ótica, da realização do referencial, do resíduo relativista e das efemérides são atribuições de orçamento modeladas (predefinições documentadas, substituíveis por quem chama), não medições. O contributo é o cruzamento τ reprodutível, não um valor certificado por termo; não certificado para manutenção da hora operacional.

lunar-station-time-lab.toml

tipo lunar-time-budgetas linhas do tipo de cenário no registo são modeladas · 0 de 1 linhas validadas

Laboratório de tempo de uma estação de referência lunar: um relógio de rubídio miniatura (miniRAFS) disciplinado pelo Tempo Lunar Coordenado (LTC) e depois deixado em funcionamento livre.

kind = "lunar-time-budget"
clock = "passive-h-maser"
clock = "mini-rafs"
steer_residual_ns = 0.5
ltc_realisation_ns = 0.05
station_height_sigma_m = 0.0
thresholds_ns = [1.0, 10.0, 100.0]
horizons_s = [3600.0, 86400.0, 604800.0, 2592000.0]

Abrir no Kshana Studio · Ver no GitHub

lunar-time-budget.toml

tipo lunar-time-budgetas linhas do tipo de cenário no registo são modeladas · 0 de 1 linhas validadas

Orçamento de erro de tempo de ponta a ponta do Tempo Lunar Coordenado (LTC) sobre uma grelha de tau.

kind = "lunar-time-budget"
clock = "passive-h-maser"

Abrir no Kshana Studio · Ver no GitHub

lunar-time-offset#

Taxa relativista modelada do relógio Terra–Lua (Tempo Coordenado Lunar, LTC/TCL): a taxa secular LTC−TT a partir da diferença de autopotencial e do termo cinético da Lua, indicada com a banda publicada de 56–59 µs/dia, mais o desvio acumulado ao longo de um horizonte.

lunar-time-offset.toml

tipo lunar-time-offsetnão associado a um módulo do registo pelo nome

Tempo-coordenada lunar (LTC/TCL): a taxa relativista do relógio Terra-Lua.

kind = "lunar-time-offset"
epoch_year = 2000
epoch_month = 1
epoch_day = 1
horizon_days = 1.0

Abrir no Kshana Studio · Ver no GitHub

lunar-vlbi#

Observável modelado do atraso VLBI geodésico lunar: uma linha de base terrestre (duas estações em terra, GCRS) observa um sinal unidirecional de uma baliza da superfície lunar da classe NovaMoon. Emite o atraso de campo próximo por diferença de duas distâncias, a sua taxa e a correção de campo próximo por curvatura da frente de onda ao longo de uma passagem — verificada de forma cruzada face ao observável Δ-DOR de onda plana da mesma base de código no limite de campo distante, com derivadas parciais verificadas por diferenças finitas. O percurso analítico predefinido é MODELLED e traz as ressalvas de consistência de referencial, de movimento polar xp=yp=0 e de onda plana versus campo próximo. Definir planetary_kernel_path, earth_orientation_kernel_path e moon_orientation_kernel_path executa em vez disso o percurso por núcleos (DE440, MOON_PA_DE440, ITRF93; tempos de luz baricêntricos convergidos; acrescenta as derivadas parciais da baliza e da estação da época), cujo atraso newtoniano e cujas derivadas parciais concordam com os tempos de luz convergidos do NAIF SPICE até 0,06 ps e 7.4e-9. Não validado face a dados VLBI reais.

lunar-vlbi.toml

tipo lunar-vlbias linhas do tipo de cenário no registo são modeladas · 0 de 1 linhas validadas

VLBI geodésico lunar: uma linha de base terrestre a observar uma baliza à superfície lunar.

kind = "lunar-vlbi"
beacon_lat_deg = 0.0
beacon_lon_deg = 0.0
beacon_alt_m = 0.0
epoch_year = 2024
epoch_month = 1
epoch_day = 1
horizon_hours = 6.0

Abrir no Kshana Studio · Ver no GitHub

lunar-vlbi-fim#

Covariância das coordenadas de estação VLBI lunar: as derivadas parciais de atraso da observável lunar-vlbi acumuladas ao longo de um PLANO DE OBSERVAÇÃO explícito (linhas de base x épocas) numa matriz de informação de Fisher, invertida, e comunicada como a covariância das coordenadas da estação e o sigma da estação por coordenada — uma saída calculada do motor, em vez de uma precisão escalar de atraso passada por um fator de equipartição isotrópico presumido g = 3. O estado traz coordenadas da estação FIXAS À TERRA (ITRS), pelo que o jacobiano é a derivada parcial inercial rodada pela matriz GCRS->ITRS de cada época: a rotação da Terra é o que torna essas coordenadas observáveis, e o relatório MEDE a varredura da linha de vista fixa à Terra e a declinação do farol em vez de os presumir. Uma observação é um par (linha de base, época) com AMBAS as estações acima da máscara de elevação, ponderada por 1/delay_sigma_s^2. Comunica a característica, o defeito de datum, o número de condição, o espetro de informação completo, a matriz de covariância, os sigmas por estação, por eixo e 3-D, e o espaço nulo de rede livre em todas as execuções; sob uma deficiência de característica, o sigma principal é publicado como NULL com um estado, nunca lido de uma inversa quase singular. O valor de equipartição c*delay_sigma_s*sqrt(g/N) para o MESMO plano é emitido junto do valor calculado com a razão, juntamente com o limite de traço isotrópico sqrt(p/trace(M)) que a AM-HM torna um mínimo rígido — pelo que a razão é a anisotropia que o pressuposto descartou. O fecho de atraso tau_ik = tau_ij + tau_jk torna apenas n-1 das n(n-1)/2 linhas de base geometricamente independentes; o relatório indica ambas as contagens. MODELLED: as efemérides do centro da Lua, os relógios das estações, a troposfera e os parâmetros de orientação da Terra são mantidos FIXOS e as observações são tratadas como independentes, pelo que a covariância é um limite de Cramer-Rao para um conjunto reduzido de parâmetros, não um resultado previsto de sessão; o sigma de atraso, as coordenadas das estações e o plano são entradas. A derivada parcial que o jacobiano de atraso geométrico deixa de fora (o termo de Shapiro diferenciado) é medida por diferenças finitas e emitida. Não é um produto geodésico.

lunar-vlbi-fim.toml

tipo lunar-vlbi-fimnão associado a um módulo do registo pelo nome

Covariância das coordenadas das estações do VLBI lunar a partir de um calendário de observação explícito (G8, artigo D3).

kind = "lunar-vlbi-fim"

Abrir no Kshana Studio · Ver no GitHub

mars-pnt#

PNT de espaço profundo em Marte: uma constelação simulada de retransmissores MARCONI (retransmissores areoestacionários + inclinados que difundem em sentido único + retransmitem em sentido duplo para uma estação de espaço profundo) navega um utilizador de referência (transfer | lmo | surface) através do estimador de fusão radiométrica conjunta de sentido único/duplo. Indica a geometria/visibilidade por época, o RMS alcançado face à verdade e a covariância formal (posição 1σ / 3σ) — uma figura de mérito simulada e honesta, NÃO um nível de proteção certificado.

mars-pnt-lmo.toml

tipo mars-pntnão associado a um módulo do registo pelo nome

PNT em Marte — um utilizador em órbita baixa de Marte navegado face à constelação de retransmissores MARCONI simulada (retransmissores areoestacionários a emitir em sentido único + a retransmitir em dois sentidos para uma estação de espaço profundo) através do estimador de fusão radiométrica conjunta de sentido único/dois sentidos.

kind = "mars-pnt"
user = "lmo"
clock_class = "uso"
step_s = 60.0
duration_s = 7200.0
nmax = 4
range_sigma_m = 1.0
doppler_sigma_mps = 1.0e-4

Abrir no Kshana Studio · Ver no GitHub

mars-pnt-surface.toml

tipo mars-pntnão associado a um módulo do registo pelo nome

PNT em Marte — um utilizador fixo à superfície (um módulo de aterragem / veículo explorador na superfície rotativa de Marte) navegado face à constelação de retransmissores MARCONI simulada através do estimador de fusão radiométrica conjunta de sentido único/dois sentidos.

kind = "mars-pnt"
user = "surface"
clock_class = "uso"
step_s = 30.0
duration_s = 7200.0
nmax = 4
range_sigma_m = 1.0
doppler_sigma_mps = 1.0e-4

Abrir no Kshana Studio · Ver no GitHub

mars-pnt-transfer.toml

tipo mars-pntnão associado a um módulo do registo pelo nome

PNT em Marte — um utilizador de transferência / captura em Marte (um arco areocêntrico alto e excêntrico — o longo arco que um veículo percorre na aproximação / numa órbita de captura) navegado face à constelação de retransmissores MARCONI simulada através do estimador de fusão radiométrica conjunta de sentido único/dois sentidos.

kind = "mars-pnt"
user = "transfer"
clock_class = "dsac"
step_s = 120.0
duration_s = 28800.0
nmax = 4
range_sigma_m = 1.0
doppler_sigma_mps = 1.0e-4

Abrir no Kshana Studio · Ver no GitHub

mission-thread#

Orçamento de erro de navegação e temporização MODELLED de uma cadeia declarada de fases de missão, do lançamento à reentrada: lançamento e ascensão, encontro e acoplagem em órbita baixa da Terra (repetível), injeção trans-lunar e cruzeiro cislunar, encontro em órbita lunar, descida, permanência na superfície, ascensão, regresso e reentrada, cada fase um de oito tipos registados com os seus próprios sensores e filtro. A covariância 6x6, o relógio e o referencial são transferidos de fase em fase sob uma regra declarada (carry, inflate ou reacquire); as conversões de referencial e de escala de tempo (GCRF, MCI, MCMF, UTC, TT, TDB, LTC) são linhas próprias do orçamento, com o estado da Lua a partir de um recorte opcional do kernel DE440 e a série analítica como alternativa declarada. Uma sobreposição opcional da rede terrestre define o ciclo de seguimento de cada fase. Indica o orçamento por fase (1-sigmas de entrada, de pico e de saída, cada contribuição com a sua unidade), a margem face a um requisito declarado, o elo mais fraco, os eventos e uma figura de cronologia. MODELLED: todo número é uma entrada declarada; a cadeia segue uma única pilha e nenhum veículo é modelado. Apenas fontes públicas; sem afiliação nem aval de qualquer agência; software de caráter consultivo, não um equipamento de navegação certificado.

mission-thread-artemis-class.toml

tipo mission-threadnão associado a um módulo do registo pelo nome

Uma cadeia da missão de classe Artemis: o orçamento de erro de navegação e temporização de uma cadeia de fases, do lançamento à reentrada, construído a partir de material público de conceito de operações.

kind = "mission-thread"
title = "Artemis-class mission thread (ILLUSTRATIVE)"
seed = 20261024
epoch_utc = "2028-01-01T00:00:00Z"
moon_kernel_path = "tests/fixtures/mission_thread/de440s_moon_2028-01-01_2028-04-01.bsp"
min_elevation_deg = 10.0
handover_gap_s = 120.0
step_s = 300.0

Ainda não está no GitHub

mission-thread-short.toml

tipo mission-threadnão associado a um módulo do registo pelo nome

Uma cadeia da missão curta que corre a partir de um único binário: lançamento e ascensão, um encontro em órbita terrestre baixa, um dia de cruzeiro translunar e o regresso e a entrada, com a posição da Lua a partir da série analítica (sem ficheiro de kernel). É o companheiro incluído de mission-thread-artemis-class, que lê um kernel lunar extraído de um checkout.

kind = "mission-thread"
title = "Short mission thread, launch to entry (ILLUSTRATIVE)"
seed = 20261028
epoch_utc = "2028-01-01T00:00:00Z"
frame = "gcrf"
x = [5285007.866, 1880185.649, 3025316.817, -137.105, 385.389, 0.0]
sigma_pos_m = 10.0
sigma_vel_mps = 0.01

Abrir no Kshana Studio · Ainda não está no GitHub

moonlight-service-volume#

Análise modelada do volume de serviço de navegação lunar a partir de uma constelação de órbita lunar da classe Moonlight/LCNS, ILLUSTRATIVE e de fontes públicas (sem afiliação à ESA): varre uma grelha selenográfica de latitude/longitude ao longo de um horizonte temporal e indica DOP / cobertura / disponibilidade (≥4 sats E PDOP < limiar) mais uma envolvente generalizada de níveis de proteção ARAIM lunares (HPL/VPL) sobre o volume. A geometria do DOP REAPROVEITA o núcleo VALIDATED face ao gnss_lib_py (crate::orbit::dop); o nível de proteção REAPROVEITA a maquinaria ARAIM lunar LNIS do LunaNet (crate::lunar, σ_URE≈30 m) e reduz-se ao nível de proteção existente do polo sul como caso particular. Composição MODELLED: um conjunto de retransmissores kepleriano circular/elíptico (não as efemérides LCNS/NRHO reais corrigidas diferencialmente), uma Lua de rotação média (sem libração nem polo em precessão). Determinístico (geometria pura). Sem aval de TRL, de herança de voo nem de agências.

moonlight-service-volume.toml

tipo moonlight-service-volumenão associado a um módulo do registo pelo nome

Análise de VOLUME DE SERVIÇO da navegação lunar — constelação da classe Moonlight / LCNS.

kind = "moonlight-service-volume"
n_sats = 8
sma_km = 9737.4
eccentricity = 0.6
inc_deg = 57.7
argp_deg = 90.0
lat_min_deg = -90.0
lat_max_deg = -60.0

Abrir no Kshana Studio · Ver no GitHub

ntn-positioning#

Posicionamento a partir de uma ligação descendente de uma rede não terrestre (NTN) 5G na banda S do serviço móvel por satélite (MSS) (banda 3GPP n256, ligação descendente de 2170 a 2200 MHz; portadora predefinida de 2172,5 MHz): o limite de Cramér-Rao (CRB) para o tempo de chegada, c / (2 pi beta sqrt(2 (C/N0) T)), com beta a largura de banda quadrática média (de Gabor) do espetro OFDM plano (B/sqrt(12)), e para o Doppler de um tom complexo, sqrt(3 / (2 pi^2 (C/N0) T^3)), para cada sinal (por predefinição, um canal New Radio de 5 MHz com 4,5 MHz ocupados e um canal de banda estreita de 200 kHz com 180 kHz ocupados); depois, sobre qualquer constelação LEO, soluções de posição por tempo de chegada na ligação descendente com um relógio do recetor desconhecido (de semente fixa, com o limite mais um erro de sincronização da rede como sigma), o seu PDOP e o sigma 3D formal, e uma solução de posição por Doppler com um único satélite sobre a passagem mais longa com a altura mantida. MODELLED: o passo da largura de banda para o limite é a forma fechada dos manuais, verificada face à integração numérica dos espetros BPSK plano e limitado em banda (consistência interna, sem nenhum valor trabalhado publicado fixado), e a exatidão do posicionamento é um limite num canal sem multipercurso com um erro de sincronização indicado, não um resultado alcançado.

ntn-5g-positioning.toml

tipo ntn-positioningnão associado a um módulo do registo pelo nome

Posicionamento a partir de uma ligação descendente de uma rede não terrestre (NTN) 5G na banda S de satélites móveis.

kind = "ntn-positioning"
seed = 5
carrier_hz = 2172.5e6
integration_s = 0.1
doppler_integration_s = 1.0
sync_error_m = 1.0
duration_s = 600.0
step_s = 10.0

Abrir no Kshana Studio · Ver no GitHub

oem-interop#

Ponte de interoperabilidade CCSDS OEM: importa uma Orbit Ephemeris Message produzida por uma ferramenta externa de dinâmica de voo (GMAT/Orekit/STK emitem todas OEM) e indica os seus segmentos/objetos/referenciais/intervalo de épocas, mais uma verificação de consistência da velocidade; sem entrada, faz a ida e volta de uma órbita de referência gerada e indica a fidelidade importação↔exportação. Verificação de ingestão estrutural/física MODELLED, NÃO uma validação da exatidão orbital da origem.

oem-interop.toml

tipo oem-interopnão associado a um módulo do registo pelo nome

Demonstrador de ponte de interoperabilidade CCSDS OEM (interoperabilidade GMAT / Orekit / STK).

kind = "oem-interop"

Abrir no Kshana Studio · Ver no GitHub

optical-atmosphere#

PNT ótico MODELLED através da atmosfera: para uma ligação ótica e um conjunto de locais em terra com climas de nuvens indicados, indica a perda em céu limpo dependente do comprimento de onda e da elevação (lei de visibilidade de Kim mais Rayleigh), o estado de turbulência de Hufnagel-Valley (variância de Rytov, índice de cintilação, parâmetros gama-gama, média de abertura), a disponibilidade determinada pelo tempo meteorológico face à margem da ligação (profundidade ótica das nuvens a partir de um clima de água líquida log-normal, extinção de ótica geométrica, desvanecimento por turbulência independente), a margem de ligação necessária para disponibilidades-alvo, a distribuição da duração das interrupções, o crescimento do erro de temporização e de medição de distâncias por interrupção através do modelo de holdover do relógio, a disponibilidade de diversidade de locais correlacionada pela distância e os ganhos hipotéticos de técnicas de melhoramento (comprimento de onda, abertura de receção, redução da cintilação por ótica adaptativa, margem adicional). VALIDATED como implementação das fórmulas indicadas face a uma referência independente mpmath: variância de Rytov, índice de cintilação, probabilidade de desvanecimento gama-gama, fator de média de abertura, profundidade ótica das nuvens e do céu limpo. MODELLED: toda a entrada meteorológica, de técnica e de relógio e os pressupostos de independência e de cópula; não foi comparado nenhum registo de disponibilidade medida. Análise de caráter consultivo, não um produto certificado de disponibilidade nem de navegação.

optical-atmosphere-network.toml

tipo optical-atmospherenão associado a um módulo do registo pelo nome

PNT ótico através da atmosfera: três locais terrestres ILLUSTRATIVE (um local setentrional mais nublado, um local central intermédio e um local meridional mais limpo) a observar um terminal ótico LEO a 30 graus de elevação a 1550 nm. Os climas de nuvens são entradas declaradas, não medições nem valores de nenhum conjunto de dados, pelo que toda a disponibilidade abaixo é MODELLED. A execução comunica por local a perda em céu limpo, o estado de turbulência de Hufnagel-Valley, a disponibilidade face à margem da ligação, a margem necessária para 40 / 50 / 60 / 70 por cento (uma ligação ótica não atravessa nuvens espessas, pelo que um local tem um teto de disponibilidade que nenhuma margem eleva, comunicado por local), a distribuição da duração das interrupções e o crescimento do erro de tempo por interrupção para três classes de relógio, e depois a disponibilidade com diversidade de locais dos melhores 1, 2 e 3 locais com meteorologia independente e com meteorologia correlacionada com a distância (comprimento de descorrelação de 500 km).

kind = "optical-atmosphere"
wavelength_nm = 1550.0
elevation_deg = 30.0
availability_targets_pct = [40.0, 50.0, 60.0, 70.0]
tx_power_w = 0.5
tx_aperture_m = 0.1
rx_aperture_m = 0.4
range_km = 1000.0

Abrir no Kshana Studio · Ver no GitHub

optical-atmosphere-techniques.toml

tipo optical-atmospherenão associado a um módulo do registo pelo nome

Hipóteses de técnicas de melhoria para um local terrestre ILLUSTRATIVE: uma mudança de comprimento de onda, uma abertura de receção maior, uma redução da cintilação por ótica adaptativa e margem adicional, cada uma prevista como ganho de disponibilidade face à linha de base do mesmo local. Os ganhos são entradas declaradas (o Kshana não modela um ciclo de ótica adaptativa), um novo comprimento de onda ou abertura reavalia o orçamento de céu limpo, a perda em céu limpo e a média de abertura, e tudo é MODELLED. O terminal tem deliberadamente a margem limitada (cerca de 3 dB antes da atmosfera) para que as técnicas contem; a execução indica também o teto de nuvens que nenhuma técnica eleva. Os alvos abaixo de 100 por cento da tabela de margens são comunicados como a margem adicional necessária (negativo significa excedente).

kind = "optical-atmosphere"
wavelength_nm = 1550.0
elevation_deg = 25.0
availability_targets_pct = [50.0, 60.0, 70.0]
tx_power_w = 0.5
tx_aperture_m = 0.1
rx_aperture_m = 0.3
range_km = 1000.0

Abrir no Kshana Studio · Ver no GitHub

orbit#

Disponibilidade GNSS + DOP a partir de uma constelação orbital (Walker / TLE / RINEX).

orbit-gnss-challenged.toml

tipo orbitnão associado a um módulo do registo pelo nome

Disponibilidade GNSS derivada da geometria orbital (não de janelas escritas à mão).

kind = "orbit"
seed = 7
threshold_ns = 5.0
mask_deg = 10.0
sigma_uere_m = 1.0
step_s = 60.0
duration_s = 86400.0
altitude_km = 8000.0

Abrir no Kshana Studio · Ver no GitHub

orbit-molniya.toml

tipo orbitnão associado a um módulo do registo pelo nome

Disponibilidade GNSS para um utilizador de órbita muito excêntrica (Molniya), a partir da geometria orbital.

kind = "orbit"
seed = 11
threshold_ns = 5.0
mask_deg = 5.0
sigma_uere_m = 1.0
step_s = 120.0
duration_s = 43200.0
altitude_km = 20229.0

Abrir no Kshana Studio · Ver no GitHub

orbit-multignss.toml

tipo orbitnão associado a um módulo do registo pelo nome

Disponibilidade multi-GNSS a partir da geometria orbital: GPS + Galileo combinados.

kind = "orbit"
seed = 7
threshold_ns = 5.0
mask_deg = 10.0
sigma_uere_m = 1.0
step_s = 60.0
duration_s = 86400.0
altitude_km = 8000.0

Abrir no Kshana Studio · Ver no GitHub

orbit-real-tle.toml

tipo orbitnão associado a um módulo do registo pelo nome

Disponibilidade GNSS a partir da geometria de satélites REAL, através de conjuntos de elementos de duas linhas.

kind = "orbit"
seed = 13
threshold_ns = 10.0
mask_deg = 5.0
sigma_uere_m = 1.0
step_s = 120.0
duration_s = 43200.0
altitude_km = 500.0

Abrir no Kshana Studio · Ver no GitHub

orbit-rinex.toml

tipo orbitnão associado a um módulo do registo pelo nome

Disponibilidade GNSS a partir de efemérides de difusão RINEX 3 reais.

kind = "orbit"
seed = 13
threshold_ns = 10.0
mask_deg = 5.0
sigma_uere_m = 1.0
step_s = 120.0
duration_s = 43200.0
altitude_km = 500.0

Abrir no Kshana Studio · Ver no GitHub

orbit-sgp4-gps.toml

tipo orbitnão associado a um módulo do registo pelo nome

Disponibilidade GNSS a partir da constelação GPS REAL propagada com SGP4/SDP4.

kind = "orbit"
seed = 17
threshold_ns = 10.0
mask_deg = 5.0
sigma_uere_m = 1.0
step_s = 120.0
duration_s = 43200.0
altitude_km = 500.0

Abrir no Kshana Studio · Ver no GitHub

orbit-urban-canyon-skyline.toml

tipo orbitnão associado a um módulo do registo pelo nome

Disponibilidade de GNSS e diluição da precisão no fundo de uma rua de cidade: o tipo de cenário orbit com um utilizador em local terrestre (user_site) sob a predefinição de linha de horizonte city-street.

kind = "orbit"
seed = 7
threshold_ns = 5.0
mask_deg = 5.0
sigma_uere_m = 1.0
step_s = 300.0
duration_s = 86400.0
lat_deg = 52.0

Abrir no Kshana Studio · Ver no GitHub

passes#

Previsão de passagens sobre estações em terra: as passagens de visibilidade no domínio do tempo (AOS/TCA/LOS, elevação aparente máxima, duração) de uma órbita circular, como elementos médios SGP4 no início da janela, sobre uma estação acima de uma máscara de elevação ao longo de uma janela, com o tempo total de acesso. Propagação SGP4/SDP4 no referencial fixo à Terra IAU 2006/2000A (UT1 - UTC e movimento polar opcionais), refração troposférica da ITU-R P.834-9 e o tempo de luz da ligação descendente (ambos ativos por predefinição), cruzamentos resolvidos até 1e-7 s e a culminação por pesquisa de secção áurea. A geometria da passagem é VALIDATED face ao Orekit 13.1.8 em estações ao nível do mar; a órbita e a estação do cenário são entradas ilustrativas.

passes.toml

tipo passeso tipo de cenário tem linhas validadas no registo · 1 de 1 linhas validadas

Demonstrador de previsão de passagens sobre estações terrestres (segmento terrestre e operações).

kind = "passes"
altitude_km = 550.0
inclination_deg = 97.6
raan_deg = 0.0
arg_lat_deg = 0.0
station_lat_deg = 52.2
station_lon_deg = 4.4
station_alt_m = 0.0

Abrir no Kshana Studio · Ver no GitHub

pvt#

Posicionamento de ponto único com observações reais: resolve a posição de um recetor a partir de um ficheiro de observação RINEX 3 e de um ficheiro de navegação por difusão (pseudodistâncias de código, efemérides por difusão, ionosfera Klobuchar, troposfera Saastamoinen/Niell), opcionalmente validado face a uma coordenada de levantamento.

pvt-abmf.toml

tipo pvtnão associado a um módulo do registo pelo nome

Posicionamento de ponto único (SPP) com observações reais de uma estação IGS de coordenadas conhecidas.

kind = "pvt"
mask_deg = 5.0
dual_frequency = true
truth_ecef = [2919786.4480, -5383745.1780, 1774604.7340]
obs_rinex = """
nav_rinex = """

Abrir no Kshana Studio · Ver no GitHub

quantum-anomaly-detect#

Deteção MODELLED de falhas/anomalias para sistemas PNT quânticos: um catálogo etiquetado de falhas (relógio: salto de frequência/deriva/perda de bloqueio; sensor: degrau de enviesamento/perda de sinal), uma AUC da ROC da estatística de deteção (com um IC bootstrap a partir do eval_stats validado externamente) e uma falha mínima detetável a uma taxa fixa de falsos alarmes, com o monitor assistido por relógio quântico (menor ruído) a detetar falhas mais pequenas — como TradeEvidence honesta + representatividade. Modelo gaussiano da estatística de deteção (AUC = Phi(mu/(sigma*sqrt2))); modela a classe, parâmetros ilustrativos de fontes públicas, sem TRL/voo/certificação.

quantum-anomaly-detect.toml

tipo quantum-anomaly-detectnão associado a um módulo do registo pelo nome

Deteção de falhas/anomalias para sistemas PNT quânticos — catálogo de falhas etiquetado + AUC ROC + falha mínima detetável, relógio quântico auxiliado vs monitor clássico. MODELLED; parâmetros ilustrativos de fontes públicas; modela a classe, sem alegação de TRL/voo.

kind = "quantum-anomaly-detect"
fault_mu = 1.0
quantum_sigma = 0.3
classical_sigma = 1.0
pfa = 1.0e-3
pd = 0.9
samples = 2000
seed = 42

Abrir no Kshana Studio · Ver no GitHub

quantum-gnss-free-nav#

Navegação quântica MODELLED sem GNSS: durante uma interrupção do GNSS, um orçamento inercial quântico (interferómetro de átomos frios) vs um INS clássico de classe de navegação — crescimento do erro de posição durante o deslize, holdover até um limiar de posição, e o compromisso quântico-vs-clássico como TradeEvidence honesta com representatividade. Nota honesta de observabilidade: sem solução de posição externa, o enviesamento do acelerómetro é inobservável, pelo que o erro cresce; o sensor quântico atrasa essa diferença, mas não a elimina. Parâmetros ilustrativos de dispositivos de fontes públicas; modela a classe, sem TRL/voo/certificação.

quantum-gnss-free-nav.toml

tipo quantum-gnss-free-navnão associado a um módulo do registo pelo nome

Navegação quântica sem GNSS — navegação à estima quântica (interferómetro de átomos frios) vs INS clássico de qualidade de navegação durante uma interrupção do GNSS. MODELLED; parâmetros de dispositivo ilustrativos, de fontes públicas; modela a classe, sem alegação de TRL/voo.

kind = "quantum-gnss-free-nav"
outage_s = 300.0
threshold_m = 100.0

Abrir no Kshana Studio · Ver no GitHub

quantum-time-transfer#

Cadeia de temporização quântica fidedigna MODELLED: um orçamento de transferência de tempo de ponta a ponta quântico (relógio de rede ótica + ligação por emaranhamento/fotão único) vs clássico (CSAC + RF bidirecional), um nível de proteção de temporização reutilizado + uma FoM de segurança contra ataques de atraso/repetição (1-P_md), uma probabilidade de deteção de anomalias do relógio + latência CUSUM, e o compromisso quântico-vs-clássico como TradeEvidence honesta com um registo de representatividade + lacunas até ao voo. Parâmetros ilustrativos de dispositivos/ligações de fontes públicas; modela a classe, sem alegação de TRL/voo/certificação.

quantum-time-transfer.toml

tipo quantum-time-transfernão associado a um módulo do registo pelo nome

Temporização quântica de confiança — cadeia de transferência de tempo de ponta a ponta, disseminação segura, deteção de anomalias e um compromisso quântico-vs-clássico. MODELLED; parâmetros de dispositivo/ligação ilustrativos, de fontes públicas; modela a classe, sem alegação de TRL/voo.

kind = "quantum-time-transfer"
integration_s = 1.0
dissemination_interval_s = 100.0
link_loss_db = 30.0
classical_link_sigma_s = 1.0e-9
monitor_pfa = 1.0e-3
attack_delay_s = 5.0e-9
clock_fault_sigma = 4.0

Abrir no Kshana Studio · Ver no GitHub

quantum-trade#

Compromisso PNT quântico-vs-clássico (13503): benefício de holdover de temporização + holdover inercial de um relógio candidato (uma curva de ADEV medida — o eixo da defensabilidade — ou uma classe de relógio quântico) vs uma classe de linha de base clássica, com a ressalva do pressuposto de patamar a tau longo transportada no artefacto, mais uma envolvente de resiliência-vs-tempo sem GNSS. MODELLED; quantifica (nunca valida) um dispositivo de parceiro. O relógio candidato é uma curva medida (candidate_adev_taus + candidate_adev_values, de igual comprimento, com pelo menos 2 pontos; prevalece quando ambas as formas são indicadas) ou um candidate_clock_class.

quantum-trade.toml

tipo quantum-tradeas linhas do tipo de cenário no registo são modeladas · 0 de 1 linhas validadas

Compromisso PNT quântico vs clássico com ingestão de ADEV medido (demonstrador ESA AO/1-13503).

kind = "quantum-trade"
timing_threshold_s = 20.0e-9
position_threshold_m = 100.0
baseline_clock_class = "csac"
candidate_adev_taus   = [1.0, 10.0, 100.0, 1000.0, 10000.0, 100000.0]
candidate_adev_values = [5.0e-16, 1.6e-16, 6.0e-17, 4.0e-17, 6.0e-17, 2.0e-16]
resilience_times_s = [1.0, 60.0, 600.0, 1800.0, 3600.0, 7200.0, 14400.0, 28800.0]

Abrir no Kshana Studio · Ver no GitHub

realtime-frame-eop#

Orçamento de previsão do referencial lunar / orientação da Terra em tempo real: P4 Tabela 1 (a verificação de consistência do erro de referencial — pós-processado ~0,27 m ↔ ~0,010 ms e em tempo real ~15 m ↔ ~0,5 ms, cada posição de referencial expressa como o erro UT1 equivalente através do braço de alavanca L19 Δr = D_EM·ω⊕·ΔUT1) e Tabela 2 (erro de previsão UT1 medido vs horizonte — a curva L18 lida diretamente da série real IERS finals2000A: o patamar final Boletim A − Boletim B e o erro do preditor de persistência a vários dias, cada um projetado numa posição do referencial lunar por L19), mais o orçamento de erro de referencial em tempo real L21 por raiz da soma dos quadrados (EOP + efemérides + patamar de realização). Forma fechada VALIDATED (o braço de alavanca L19, ω⊕ verificada por comparação com o ângulo de rotação da Terra CIO) e dados reais VALIDATED (a curva L18 a partir das linhas reais finals2000A); são MODELLED as magnitudes de covariância OD do relé lunar e o patamar de realização do referencial (atribuições representativas) e o preditor de persistência (não é o algoritmo operacional do Boletim A do IERS). Não é um produto de referencial em tempo real certificado.

realtime-frame-eop.toml

tipo realtime-frame-eopnão associado a um módulo do registo pelo nome

Orçamento de previsão em tempo real do referencial lunar / orientação da Terra (EOP).

kind = "realtime-frame-eop"
epoch = "2022-01-01"
horizons_days = [1, 2, 3]

Abrir no Kshana Studio · Ver no GitHub

reentry#

Corredor de reentrada balística de Allen-Eggers: desaceleração máxima (independente do coeficiente balístico, V_e^2 sin|γ|/(2eH)), a velocidade e a altitude no pico de g e a velocidade de aquecimento máximo, para uma velocidade de entrada/ângulo da trajetória de voo/coeficiente balístico numa atmosfera exponencial, mais uma integração planar de massa pontual da mesma entrada balística com gravidade, curvatura da Terra e a Atmosfera Padrão dos EUA de 1976 (desaceleração máxima, velocidade, altitude e tempo no pico). Entrada balística (sem sustentação) MODELLED; o resultado de aquecimento é a VELOCIDADE de aquecimento máximo, não um fluxo de calor (sem modelo aerotérmico/TPS).

reentry.toml

tipo reentryas linhas do tipo de cenário no registo são modeladas · 0 de 1 linhas validadas

Demonstrador de corredor de reentrada balística (Allen-Eggers, análise de missões).

kind = "reentry"
entry_velocity_m_s = 7800.0
flight_path_angle_deg = 6.0

Abrir no Kshana Studio · Ver no GitHub

slot-timing#

Temporização de intervalos: segundos até um relógio em funcionamento livre sair da guarda de um intervalo de encaminhamento ou de atribuição de tarefas indexado no tempo (o maior erro de tempo absoluto que o intervalo tolera), a contribuição de cada termo nesse momento com o dominante identificado (incerteza da solução de posição, ruído de fase branco, ruído de frequência branco, flicker, de passeio aleatório e de corrida aleatória, desvio de frequência residual, temperatura, envelhecimento), o tempo restante desde a última solução de posição e o maior intervalo entre soluções de posição que mantém o relógio dentro, líquido da latência da solução de posição. O oscilador é uma predefinição de CLASSE (csac, uso, dsac, tcxo, ocxo ou rafs: um desvio de Allan citado a um segundo e um patamar de ruído vermelho assumido), uma PREDEFINIÇÃO DE FICHA TÉCNICA de temporização de telecomunicações ou uma FICHA TÉCNICA em linha (máximos do desvio de Allan ajustados como envolvente, mais envelhecimento e um coeficiente de temperatura), ou um REGISTO DE FASE MEASURED em linha (o seu desvio de Allan sobreposto ajustado por mínimos quadrados ponderados na base de fase branca e de modulação de frequência IEEE Std 1139, de modo que o patamar de ruído vermelho é medido e não assumido). Uma violação além do maior tempo de média que a ficha técnica ou o registo suporta é assinalada como extrapolada. Uma secção opcional de spoofing acrescenta o nível de proteção de temporização para um recetor em órbita: velocidade e período orbitais, durante quanto tempo um único spoofer terrestre consegue alcançar o satélite por passagem, o patamar do monitor assistido por relógio e a latência de deteção CUSUM, o limite condicional, o arrastamento que um spoofer a uma taxa de rampa máxima indicada acumula antes de o satélite sair do seu alcance ou de uma verificação independente ser executada, e se cada verificação de contacto terrestre ou de ligação cruzada é independente desse spoofer. VALIDATED: a inversão de holdover a partir de um registo ajustado, reservada num relógio de césio real medido face a um maser de hidrogénio (tests/slot_timing_cs5071a_holdout.rs, condicionado pelos dados); num oscilador de cristal medido, a previsão reservada é conservadora mas não está dentro do limiar, pelo que o caso do cristal é MODELLED. MODELLED: as fontes de classe e de ficha técnica, os termos determinísticos e a avaliação de spoofing.

slot-timing-ocxo-leo.toml

tipo slot-timingnão associado a um módulo do registo pelo nome

Temporização de intervalo: durante quanto tempo um oscilador de cristal controlado por forno (OCXO) num pequeno satélite de órbita terrestre baixa permanece dentro da guarda de um intervalo de encaminhamento indexado no tempo após a sua última posição calculada do sistema global de navegação por satélite (GNSS), e com que frequência precisa de uma.

kind = "slot-timing"
preset = "ocxo"
guard_ns = 100.0
k_sigma = 3.0
fix_sigma_ns = 10.0
elapsed_since_sync_s = 600.0
fix_latency_s = 5.0
temperature_excursion_k = 2.0

Abrir no Kshana Studio · Ver no GitHub

solar-system#

O sistema solar completo numa época, para PNT (posicionamento, navegação e temporização) em torno de qualquer corpo. Para o Sol, os oito planetas, Plutão, a Lua, Fobos, Deimos, Io, Europa, Ganimedes, Calisto e Titã, indica a posição e a velocidade heliocêntricas no ICRF (Referencial Celeste Internacional, equatorial J2000), a distância heliocêntrica e a longitude e latitude eclípticas J2000, o parâmetro gravitacional, o raio equatorial e médio, J2 quando publicado e o seu raio de referência, o período de rotação sideral, o polo IAU e o meridiano de origem na época, uma trajetória orbital amostrada ao longo de uma revolução (heliocêntrica para os planetas, centrada no corpo principal para as luas), e o tempo de luz, a distância unidirecional e bidirecional, o atraso de Shapiro solar e a separação do Sol a partir de um corpo observador (predefinição: Terra); as ligações adicionais de origem/destino recebem o mesmo tratamento. Posições: os elementos keplerianos JPL de Standish e Williams (Tabela 1 para 1800 AD a 2050 AD, Tabelas 2a/2b para 3000 BC a 3000 AD) com o erro nominal de cada planeta, a série lunar de Montenbruck & Gill para a separação Terra-Lua, elementos médios JPL com a taxa de rotação síncrona IAU para as luas marcianas e galileanas, e o modelo de rotação IAU para Titã. Tempo de luz: resolução radiométrica de ponto fixo, com o emissor na sua posição retardada; newtoniano, com o atraso de Shapiro indicado em separado. VALIDATED face ao JPL Horizons (DE441) dentro do dobro do erro nominal: de Mercúrio a Saturno e a Terra a partir da Tabela 1 (pior caso 1,87 vezes o nominal) e os oito planetas a partir das Tabelas 2a/2b (pior caso 1,71 vezes), e o tempo de luz da Terra a Marte e a Júpiter. MODELLED, cada linha etiquetada: Úrano e Neptuno a partir da Tabela 1 (2,0 e 5,2 vezes o erro nominal face ao DE441), Plutão (a linha de 1992; sem erro indicado), a Lua e as sete luas (medidas face ao Horizons, sem limite publicado).

solar-system-tour.toml

tipo solar-systemnão associado a um módulo do registo pelo nome

Todo o sistema solar numa só época.

kind = "solar-system"
epoch = "2026-09-28T00:00:00"
observer = "Earth"
track_points = 180
from = "Mars"
to = "Jupiter"
from = "Saturn"
to = "Earth"

Abrir no Kshana Studio · Ver no GitHub

space-packet#

Enquadramento CCSDS 133.0-B Space Packet Protocol: codifica um fluxo sintético de pacotes TM/TC (cabeçalho primário de 6 octetos + campo de dados) e indica a descodificação do cabeçalho de cada pacote, o total de octetos e uma viagem de ida e volta codificação↔descodificação exata. Enquadramento determinístico com disposição exata de bits — a camada de interoperabilidade de formato de pacotes das agências; NÃO é uma certificação de aderência à norma (sem lógica de cabeçalho secundário/CRC/segmentação além dos indicadores).

space-packet.toml

tipo space-packeto tipo de cenário tem linhas validadas no registo · 1 de 1 linhas validadas

Demonstrador de enquadramento de pacotes espaciais CCSDS 133.0-B (interoperabilidade TM/TC).

kind = "space-packet"
apid = 100
telecommand = false
packet_count = 4
data_len = 32

Abrir no Kshana Studio · Ver no GitHub

space-weather#

Modelo do ambiente de meteorologia espacial: índices de atividade solar (F10.7/F10.7a) e geomagnética (Kp, com a tabela definicional Kp↔ap), a temperatura exosférica de Jacchia-1971 que estes determinam (validada face aos mínimo/média/máximo solares publicados), e a densidade neutra termosférica de Jacchia-1971 à temperatura exosférica média diurna face ao perfil estático sem atividade a um conjunto de altitudes — a dependência da densidade relativamente ao ciclo solar que a atmosfera estática omite. MODELLED: a densidade concorda com as densidades derivadas de acelerómetros (TOLEOS CHAMP e GRACE) dentro de um fator 2 no máximo solar, mas é cerca de 1.7x demasiado densa no mínimo solar de 2008.

space-weather.toml

tipo space-weatheras linhas do tipo de cenário no registo são modeladas · 0 de 1 linhas validadas

Demonstrador de modelo de ambiente de meteorologia espacial.

kind = "space-weather"
kp = 4.0
altitudes_km = [300.0, 400.0, 500.0, 600.0, 800.0]

Abrir no Kshana Studio · Ver no GitHub

spectrum#

Modelo de espetro da banda L e cascata: toda a banda L do GNSS como uma única densidade espetral de potência (PSD), com a frequência na horizontal e o tempo na vertical, sobre uma cronologia de jammers com guião. SINAIS: GPS L1 C/A e L2C (BPSK(1)), serviço aberto Galileo E1 (MBOC(6,1,1/11), ou BOC(1 1)), GPS L5 e Galileo E5a (BPSK(10)), cada um na sua portadora com a potência recebida mínima da especificação de interface (IS-GPS-200, IS-GPS-705, Galileo OS SIS ICD), salvo indicação em contrário; GLONASS, BeiDou e Galileo E6 não são modelados. JAMMERS: tom de onda contínua, ruído plano de banda estreita, chirp linear em dente de serra e ruído de banda larga adaptado à modulação da própria banda, cada um com um centro, uma largura de banda, uma potência recebida (direta, ou EIRP e distância através da perda de percurso em espaço livre do tipo jamming) e instantes de ligação/desligamento. Cada jammer é avaliado em cada banda pelo seu coeficiente de separação espetral kappa sobre a largura de banda do recetor, e (C/N0)_eff = [1/(C/N0) + sum (J/S) kappa]^-1; para um jammer, isto é igual à equação anti-jam do tipo jamming com Q = 1/(R_c kappa), e o relatório inclui essa verificação cruzada (e, a seu lado, o valor de Q representativo do tipo jamming). O patamar de ruído é k T_sys com T_sys = T_ant + 290 K (F - 1). A cascata faz a média de cada célula sobre o seu intervalo e a sua linha (chirps exatamente, varrimentos completos mais o parcial; jammers que comutam a meio da linha pelo seu ciclo de trabalho), de modo que a cronologia de C/N0 e a imagem vêm dos mesmos números; result.json inclui a grelha com média em blocos em potência, o C/N0 e o J/S por banda e por linha, e, por jammer e por banda, o SSC, Q, J/S, J/S em banda e C/N0 estável. [iq] opcional: o modelo desenhado como IQ complexo num instante, escrito e relido de uma gravação SigMF (cf32_le ou ci16_le), e comparado com uma estimativa de Welch. [recording] opcional (compilações nativas): a PSD de Welch de uma gravação SigMF real ao lado do modelo. VALIDATED: as PSD dos sinais face às larguras de lóbulo principal de manual (BPSK(n) 2n x 1,023 MHz de nulo a nulo; lóbulos BOC(1 1) centrados em +/-1.023 MHz) e os coeficientes de separação espetral face às suas formas fechadas de Parseval e ao Q = 1 (CW) e 1,5 (adaptado) de Kaplan & Hegarty. MODELLED: as potências dos jammers, a cronologia, as larguras de banda do front-end, o tratamento de espetro contínuo (sem linhas de código) e a ausência de AGC, de blanking e de diagrama de antena.

l-band-waterfall-jamming.toml

tipo spectrumnão associado a um módulo do registo pelo nome

Cascata em banda L sob jamming: toda a banda L do sistema global de navegação por satélite (GNSS) como uma única densidade espetral de potência (PSD), frequência na horizontal, tempo para baixo, enquanto uma sequência programada de emissores de jamming é ligada.

kind = "spectrum"
seed = 7
duration_s = 60.0
step_s = 1.0
noise_figure_db = 2.0
antenna_temp_k = 290.0
tracking_threshold_dbhz = 25.0
f_min_mhz = 1160.0

Abrir no Kshana Studio · Ver no GitHub

leo-resilience-js-margin.toml

tipo spectrumnão associado a um módulo do registo pelo nome

Resiliência LEO-PNT a partir da potência recebida: a margem jammer-sinal (J/S).

kind = "spectrum"
seed = 12
duration_s = 100.0
step_s = 1.0
noise_figure_db = 2.0
antenna_temp_k = 290.0
tracking_threshold_dbhz = 25.0
f_min_mhz = 1150.0

Abrir no Kshana Studio · Ver no GitHub

multi-band-jamming-waterfall.toml

tipo spectrumnão associado a um módulo do registo pelo nome

Cascata de jamming multibanda: sinais de posicionamento, navegação e tempo (PNT) em órbita terrestre baixa (LEO) em quatro bandas (UHF, L, S e C) ao lado de GPS e Galileo, cada banda com o seu emissor de jamming, desenhada como uma cascata por banda numa única cronologia.

kind = "spectrum"
seed = 11
duration_s = 60.0
step_s = 1.0
noise_figure_db = 2.0
antenna_temp_k = 290.0
tracking_threshold_dbhz = 25.0
f_min_mhz = 1160.0

Abrir no Kshana Studio · Ver no GitHub

spoof#

Detetor estocástico de spoofing de tempo (Neyman–Pearson / χ²₁) com P_fa/P_md de Monte Carlo.

spoof-attack.toml

tipo spoofnão associado a um módulo do registo pelo nome

Ataque ativo de spoofing de tempo: o monitor de integridade de cada relógio consegue detetar o spoofing antes de causar dano?

kind = "spoof"
threshold_ns = 20.0
step_s = 10.0
duration_s = 660.0
start_s = 60.0
rate_ns_per_s = 0.1
id = "optical-sr-lattice"
provenance = "Strontium optical lattice clock, space-oriented goal sigma_y(1s)=1e-15 (arXiv:1503.08457); not flown."

Abrir no Kshana Studio · Ver no GitHub

spoof-meaconing.toml

tipo spoofnão associado a um módulo do registo pelo nome

Deteção de spoofing de tempo com uma forma de ataque explícita e um detetor estocástico.

kind = "spoof"
threshold_ns = 0.5
step_s = 1.0
duration_s = 1200.0
start_s = 100.0
target_pfa = 0.001
mc_runs = 20000
kind = "meaconing"

Abrir no Kshana Studio · Ver no GitHub

spoof-detect#

Detetor combinado de spoofing por RF/medições (consistência RAIM multi-SV + AGC + SQM, fundidos) vs um ataque parametrizado (vantagem de potência, alinhamento de fase da portadora, empurrão de tempo/posição; ao estilo TEXBAT).

maritime-spoof-position-push.toml

tipo spoof-detectnão associado a um módulo do registo pelo nome

Spoofing de GNSS marítimo: deteção de um emissor que arrasta a posição comunicada de um navio.

kind = "spoof-detect"
power_advantage_db = 2.0
carrier_aligned = false
push = "position"
push_magnitude_m = 500.0
num_biased = 4
el_imbalance = 0.12
sat_power_dbm = -130.0

Abrir no Kshana Studio · Ver no GitHub

spoof-detect.toml

tipo spoof-detectnão associado a um módulo do registo pelo nome

Detetor combinado de spoofing por RF e medições: consistência RAIM multi-SV + AGC + SQM, fundidos.

kind = "spoof-detect"
power_advantage_db = 1.5
carrier_aligned = false
push = "position"
push_magnitude_m = 75.0
num_biased = 3
el_imbalance = 0.12
sat_power_dbm = -130.0

Abrir no Kshana Studio · Ver no GitHub

sweep#

Varrimento 1-D de estudo de compromissos sobre um parâmetro de um pacote de relógio.

sweep-clock-stability.toml

tipo sweepnão associado a um módulo do registo pelo nome

Estudo comparativo: como escala o holdover com a estabilidade do relógio?

kind = "sweep"
parameter = "classical_q_wf"
metric = "holdover_s"
start = 1.0e-24
stop = 1.0e-18
steps = 25
scale = "log"
seed = 42

Abrir no Kshana Studio · Ver no GitHub

sweep-nd#

Varrimento N-D genérico sobre qualquer pacote através de chaves TOML com pontos / caminhos de métricas JSON.

sweep-nd-inertial.toml

tipo sweep-ndnão associado a um módulo do registo pelo nome

Varrimento genérico de parâmetros N-D sobre QUALQUER tipo de cenário. Ao contrário do tipo de cenário sweep, só para relógios, sweep-nd faz variar chaves TOML com pontos do cenário [base] sobre o produto cartesiano dos eixos, volta a executar cada nó da grelha e lê as métricas escolhidas do resultado por caminho JSON com pontos. Funciona para todos os pacotes (inertial, gnss-ins, integrity, spoof, …) porque opera na fronteira TOML/resultado, não num tipo Rust por pacote. As execuções nativas avaliam a grelha em paralelo (sem dependência adicional); o wasm recorre ao modo sequencial. A grelha de saída é determinística e por linhas (o último eixo varia mais depressa).

kind = "sweep-nd"
metrics = ["classical.fom.holdover_s", "classical.fom.pos_rms_m"]
key = "threshold_m"
start = 100.0
stop = 500.0
steps = 5
key = "accel_classical.bias"
start = 1.0e-3

Abrir no Kshana Studio · Ver no GitHub

telecom-timing#

Temporização de telecomunicações: erro de tempo, erro máximo de intervalo de tempo (MTIE) e desvio de tempo (TDEV) de um holdover de GNSS, verificados face a máscaras ITU-T com PASS ou FAIL e uma margem por máscara. A entrada é um HOLDOVER SINTÉTICO (uma predefinição de oscilador -- ocxo, rubídio, césio ou csac, cada uma com os valores de estabilidade, envelhecimento e temperatura de uma ficha técnica pública da Microchip identificada -- mais o instante de perda de GNSS, a duração do registo e o intervalo de amostragem; o relógio em funcionamento livre tem ruído de frequência branco, flicker e, quando o ajuste à ficha técnica o exige, de passeio aleatório, envelhecimento linear e um termo de temperatura sinusoidal) ou uma SÉRIE INGERIDA de pares [time_s, time_error_ns] indicados em linha (e, apenas em compilações nativas, um ficheiro CSV). Máscaras: ITU-T G.8272 (07/2025) PRTC-A e PRTC-B (máx|TE| 100 / 40 ns, MTIE Tabelas 1-2, TDEV Tabelas 3-4); G.8272.1 (2024) Amd. 1 (07/2025) ePRTC bloqueado (30 ns, Tabelas 1-2) e holdover ePRTC-A (a envolvente de erro de tempo da Tabela 3 a subir de 30 ns para 100 ns ao longo do período de holdover H definido pela duração de bloqueio, MTIE Tabela 4, TDEV Tabela 5); G.8273.2 (2023) Amd. 2 (11/2025) classes A-C de T-BC/T-TSC (máx|TE|, erro de tempo constante, MTIE e TDEV filtrados por passa-baixo) e classe D (máx|TE_L| 5 ns, o único valor da classe D que não fica para estudo posterior); G.8271.1 (2022) Amd. 3 (05/2025) ponto de referência C (máx|TE_L| 1100 / 600 / 100 ns com MTIE Tabelas 7-1 a 7-3). Cada entrada que uma Recomendação marca para estudo posterior está ausente em vez de preenchida, e cada relatório lista o que não está implementado. Indica também o tempo até exceder cada orçamento de erro de tempo máximo (predefinições: 100 ns máx|TE_HO| do ePRTC, 400 ns de atribuição de holdover de rede, 1100 ns ponto C, 1,5 us classe 4), as curvas MTIE/TDEV como uma tabela CSV com cada limite de máscara, e uma entrada de unidades e proveniência por campo numérico. VALIDATED: os estimadores MTIE e TDEV face ao pacote allantools sobre uma série de holdover registada. MODELLED: as tabelas de máscaras são transcrições, e um holdover sintético é um modelo construído a partir de máximos de fichas técnicas, não uma medição de qualquer unidade. Não é um ensaio de aderência à norma.

telecom-prtc-holdover-24h.toml

tipo telecom-timingnão associado a um módulo do registo pelo nome

Referência de temporização de telecomunicações: um relógio de rubídio que perde a sua referência do sistema global de navegação por satélite (GNSS) e mantém-se em holdover durante 24 horas, verificado face às máscaras do Setor de Normalização das Telecomunicações da União Internacional das Telecomunicações (ITU-T).

kind = "telecom-timing"
seed = 20260925
masks = ["eprtc-a-holdover", "prtc-a"]
oscillator = "rubidium"
gnss_loss_s = 3600.0
duration_s = 90000.0
sample_interval_s = 1.0
locked_te_sigma_ns = 1.0

Abrir no Kshana Studio · Ver no GitHub

telecom-synce-eec.toml

tipo telecom-timingnão associado a um módulo do registo pelo nome

Temporização de telecomunicações, sincronização de frequência: um oscilador de cristal controlado por forno (OCXO) em funcionamento livre confrontado com as máscaras de geração de wander do relógio de equipamento de Ethernet síncrona (EEC) do Setor de Normalização das Telecomunicações da União Internacional das Telecomunicações (ITU-T).

kind = "telecom-timing"
seed = 20260925
masks = ["g8262-eec-option-1", "g8262-eec-option-2", "g8262-1-eeec"]
budgets = []
oscillator = "ocxo"
gnss_loss_s = 0.0
duration_s = 12000.0
sample_interval_s = 1.0

Abrir no Kshana Studio · Ver no GitHub

telecom-tie-ingest.toml

tipo telecom-timingnão associado a um módulo do registo pelo nome

Temporização de telecomunicações, exemplo de ingestão: uma série de erro de intervalo de tempo (TIE) dada em linha e verificada face às máscaras do Setor de Normalização das Telecomunicações da União Internacional das Telecomunicações (ITU-T).

kind = "telecom-timing"
masks = ["prtc-a", "prtc-b", "eprtc", "eprtc-a-holdover", "t-bc-class-c", "g8271-1-point-c"]
holdover_start_s = 300.0
locked_duration_days = 5.0
samples = [

Abrir no Kshana Studio · Ver no GitHub

terrain-nav#

Navegação por referência ao terreno sem GPS (TERCOM/SITAN): um altímetro radar/barométrico compara o perfil de elevação do solo com um DEM ao estilo SRTM para recuperar a deriva do INS.

terrain-nav.toml

tipo terrain-navnão associado a um módulo do registo pelo nome

Navegação referenciada ao terreno (TERCOM/SITAN) — PNT alternativo sem GPS.

kind = "terrain-nav"
dem_seed = 1
start_lat_deg = 12.05
start_lon_deg = 20.05
step_lat_deg = 0.004
step_lon_deg = 0.003
waypoints = 60
drift_lat_deg = 0.5

Abrir no Kshana Studio · Ver no GitHub

terrain-slam#

Navegação sequencial (recursiva) por referência ao terreno sem GPS: um filtro de partículas executa o modelo de medição de correspondência de terreno época a época (SITAN como filtro em execução), de modo que uma deriva do INS variável no tempo é seguida ao longo da trajetória, ao passo que o terrain-nav em lote só recupera um único desvio constante.

terrain-slam.toml

tipo terrain-slamnão associado a um módulo do registo pelo nome

Navegação sequencial (recursiva) referenciada ao terreno — PNT alternativo sem GPS.

kind = "terrain-slam"
dem_seed = 1
start_lat_deg = 12.08
start_lon_deg = 20.08
step_lat_deg = 0.004
step_lon_deg = 0.003
waypoints = 60
drift_rate_lat_deg = 0.0006

Abrir no Kshana Studio · Ver no GitHub

time-transfer-budget#

Transferência bidirecional de tempo e frequência por satélite entre duas estações através de um relé geoestacionário: a equação bidirecional resolvida para T_A - T_B com todos os termos não recíprocos (atrasos do equipamento das estações, ionosfera em banda Ku, transponder, Sagnac), um orçamento de incerteza em quadratura cujo termo do tipo A é o TDEV da ligação simulada ao tempo de média, uma ligação simulada com ruído de fase branco e flicker e uma não reciprocidade diurna, e a estabilidade (taxa, RMS residual, TDEV, ADEV) de qualquer série da Secção 1 da Circular T do BIPM, CSV MJD,ns ou registos de relógio de estação RINEX do IGS fornecida. MODELLED.

time-transfer-budget.toml

tipo time-transfer-budgetnão associado a um módulo do registo pelo nome

Transferência bidirecional de tempo e frequência por satélite (TWSTFT) entre duas estações ILLUSTRATIVE, uma na Europa central e outra no leste da América do Norte, através de um retransmissor geoestacionário a 10 deg W. A execução resolve a equação bidirecional para T_A - T_B a partir dos termos declarados de equipamento, transponder, ionosférico (banda Ku, 14/11 GHz) e de Sagnac. Forma um orçamento de incerteza cujo termo estatístico é o TDEV, a um dia, de uma ligação simulada com ruído de fase branco e de cintilação e uma não reciprocidade diurna. Os atrasos e as incertezas são ilustrativos, não a calibração de nenhum laboratório. MODELLED. Pode ser acrescentada uma série real UTC-UTC(k) ou de relógio de estação em [[series]] (format circular-t, mjd-csv ou rinex-clock) para comunicar a sua estabilidade.

kind = "time-transfer-budget"
satellite_lon_deg = -10.0
transponder_ab_ns = 812.0
transponder_ba_ns = 809.5
uplink_ghz = 14.0
downlink_ghz = 11.0
true_offset_ns = 12.5
white_noise_ns = 0.3

Abrir no Kshana Studio · Ver no GitHub

timetransfer#

Transferência bidirecional de tempo/frequência ótica vs RF.

timetransfer.toml

tipo timetransfernão associado a um módulo do registo pelo nome

Transferência de tempo ótica entre satélites vs RF clássica (TWSTFT).

kind = "timetransfer"
seed = 42
samples = 600
step_s = 1.0
range_spec_mm = 10.0
id = "optical-isl"
provenance = "Optical inter-satellite link, picosecond-level synchronization target; free-space optical two-way time-frequency transfer lab floor ~1 fs (Giorgetta 2013, Nature Photonics; Deschenes 2016, PRX). Using a 1 ps target as the on-orbit-credible figure."
sigma_j_s = 1.0e-12

Abrir no Kshana Studio · Ver no GitHub

tracking-loop#

Perda de bloqueio do ciclo de seguimento: C/N0 -> bloqueio/desbloqueio COM HISTERESE, o tempo que demora a perder o bloqueio, e a captura por spoofing em função da TAXA de desvio de código e de portadora. Os critérios de negação e de captura já existentes no motor são razões de potência recebida (um emissor de jamming nega a J/S = 30 dB, um spoofer captura a 3 dB); a perda de bloqueio real não é uma razão de potência, é o ponto em que a instabilidade (jitter) de um ciclo mais a tensão dinâmica o deixam fora do seu orçamento de limiar de seguimento. Comunica (1) a instabilidade térmica de 1 sigma da portadora (Costas) e do código (adiantado/atrasado não coerente) em função de C/N0, com a perda de quadratura incluída, face às regras indicadas 3*sigma_PLL + theta_e <= 45 deg (a regra dos 15 graus em forma de três sigmas) e 3*sigma_DLL + atraso de rampa <= d/2 chips; (2) os limiares de C/N0 de perda e de recuperação do bloqueio com o ciclo limitante nomeado, o limiar de recuperação do bloqueio DERIVED da largura de banda maior com que um recetor volta a capturar em vez de afirmado, pelo que a largura da histerese tem de situar-se entre 5*log10(razão) e 10*log10(razão) dB; (3) o tempo declarado para perder o bloqueio de um detetor de bloqueio de dois limiares com tempos de confirmação, conduzido sobre uma rampa de C/N0, comunicado separadamente do tempo físico de fuga de fase (o tempo médio de Viterbi entre saltos de ciclo, em log10 s porque abrange centenas de décadas); (4) os limites de captura por spoofing — a maior deriva de código e a maior taxa de Doppler de portadora que os ciclos de uma vítima conseguem seguir, com um mapa sobre ambos os eixos, porque um spoofer que deriva mais depressa do que estes não captura o ciclo, ultrapassa-o; e (5) o RAIO DE NEGAÇÃO que a dinâmica do ciclo implica, comunicado AO LADO DO raio de razão de potência existente, nunca em seu lugar, com a sua diferença com sinal como campo próprio com nome (denial_radius_delta_km) e uma definição ao lado. Cada campo numérico emitido traz uma unidade e uma classe de proveniência. Formas fechadas VALIDATED: as expressões de instabilidade da portadora e do código, a redução do filtro de ciclo sqrt(2*B_n*T) e o atraso de rampa de primeira ordem são verificados em cruzamento com o correlacionador sdr do próprio motor, avançado passo a passo sobre IF sintética com semente — um caminho diferente para os mesmos números — em 0,6 %, 3,7 % e 0,17 % respetivamente, e a Bessel modificada I0 por trás do tempo de salto de ciclo face a valores tabelados padrão em 1e-7. O limite inferior de validade é afirmado, não apenas declarado: abaixo de ~32 dB-Hz a 1 ms o discriminador atan real satura contra o seu intervalo +-pi/2 e mede menos instabilidade do que qualquer teoria linear. MODELLED: as larguras de banda dos ciclos, o tempo de integração, o espaçamento do correlacionador, a razão de largura de banda de captura, os tempos de confirmação, a potência do emissor de jamming e os ganhos das antenas são valores representativos da banda, não de uma ficha técnica. NÃO modelados: a instabilidade do oscilador (desvio de Allan) e de vibração, a limitação da largura de banda do front-end, o multipercurso, a dinâmica do AGC, a perda por transição de bits de dados, o auxílio externo e qualquer correção de meio ciclo à fórmula de salto de ciclo de Costas. Sob a dinâmica do ciclo, a captura por spoofing não tem qualquer raio — a restrição limitante é a taxa de desvio, não a potência — pelo que esse campo é nulo com uma razão em vez de um número fabricado. Não é um produto de desempenho de recetores certificado.

tracking-loop.toml

tipo tracking-loopnão associado a um módulo do registo pelo nome

Perda de bloqueio do ciclo de seguimento: C/N0 -> bloqueio/desbloqueio com histerese, o tempo que demora a perder o bloqueio, e os limites de captura por spoofing definidos pela TAXA de desvio de código e de portadora.

kind = "tracking-loop"
pll_bandwidth_hz = 10.0
dll_bandwidth_hz = 1.0
predetection_integration_s = 0.001
correlator_spacing_chips = 0.5
carrier_allowance_deg = 45.0
pullin_bandwidth_ratio = 2.0
drop_confirm_epochs = 50

Abrir no Kshana Studio · Ver no GitHub

Conjuntos de estudo#

Um conjunto é um ficheiro de cenário que lista outros cenários; kshana --study executa-o num único study.json e study.html carimbados. Este é o executor de conjuntos gratuito, não o estudo personalizado pago.

quantum-pnt-demonstrator.suite.toml

Demonstrador PNT com Tecnologia Quântica — as três áreas de aplicação como um único estudo.

kshana --study scenarios/quantum-pnt-demonstrator.suite.toml

Ver no GitHub