Como rastrear satélites com JavaScript: USSF-153 e Starshield

Quando uma missão classificada decola e a única pista que sobra é o local onde o booster pousou, a gente entra em modo de engenharia reversa. Foi exatamente o que o NextSpaceflight fez com a USSF-153, e é o que eu faria com qualquer sistema mal documentado: comparar telemetria, cruzar padrões e inferir o comportamento. A SpaceX lançou mais uma missão secreta para a Força Espacial dos EUA nesta quinta-feira, e apesar da ausência total de detalhes, tem bastante coisa interessante para quem pensa como programador.

O que realmente aconteceu na USSF-153

Segundo o Olhardigital.com.br, o Falcon 9 decolou da Base da Força Espacial de Vandenberg, na Califórnia, às 8h42 no horário local. O destino declarado? Nenhum — a carga é classificada. O que sabemos com certeza é o seguinte:

• O primeiro estágio (B1801) completou seu 27º voo e pousou no drone ship “Of Course I Still Love You” cerca de 8 minutos e meio após o lançamento.
• A transmissão ao vivo foi cortada logo após o pouso do booster. Nada de “confirmação de separação da carga” ou telemetria pós-deploy.
• A zona de retorno do booster sugere uma trajetória para órbita baixa (LEO), e foi justamente isso que levantou a suspeita sobre o Starshield.

O recorde interno da SpaceX é de 37 voos com o mesmo primeiro estágio, alcançado em uma missão Starlink recente. Estamos falando de um propulsor B1801 que já voou quase três vezes mais do que qualquer foguete descartável da história. Isso, por si só, já é uma vitória de engenharia de software e processos.

Starshield: o que sabemos (e o que estamos inferindo)

O Starshield é a versão “governamental” da constelação Starlink. Mesma fábrica, mesma linha de produção, mas com payload óptico, encrypted comlinks e contratos diretos com o DoD (Departamento de Defesa dos EUA). A NASA, a NRO e a Força Espacial já operam contratos bilionários com a SpaceX sob essa marca.

O detalhe técnico que chamou a atenção dos analistas foi a zona de descarte do booster. Comparando com missões anteriores que carregavam Starshield, a trajetória bate. Não é prova, mas é forte correlação. Em engenharia de dados, a gente chama isso de inferência por exclusão: não tem como confirmar diretamente, então você restringe o espaço de hipóteses até sobrar uma.

Por que isso importa para quem programa?

Porque a SpaceX opera o que provavelmente é a maior máquina de ingestão de telemetria do planeta. Cada voo gera gigabytes de dados por segundo de sensores — pressão, temperatura, vibração, torque, attitude. Tudo isso precisa ser:

• Coletado em tempo real com latência de milissegundos.
• Processado por sistemas tolerantes a falha (ninguém pode reiniciar um foguete no meio do voo).
• Arquivado para análise pós-voo, onde modelos de machine learning detectam padrões de fadiga estrutural.

Quando você entende a escala disso, fica óbvio por que a SpaceX investe pesado em Rust, C++ e pipelines de dados distribuídos. Não é hobby — é literalmente controle de missão.

Na Prática: rastreando satélites com JavaScript

Se você quiser fazer o seu próprio “NextSpaceflight caseiro” e cruzar dados de órbitas, dá para começar em menos de 10 minutos. O pacote satellite.js no npm calcula posição e velocidade de qualquer satélite a partir dos dados TLE (Two-Line Element) públicos. Vou te mostrar um exemplo funcional que retorna a posição do ISS agora:

// npm install satellite.js
const satellite = require('satellite.js');

const tleLine1 = '1 25544U 98067A   24315.50000000  .00012345  00000+0  22000-3 0  9999';
const tleLine2 = '2 25544  51.6400 123.4567 0006700  90.0000 270.0000 15.50000000300000';

const satrec = satellite.twoline2satrec(tleLine1, tleLine2);
const now = new Date();

const positionAndVelocity = satellite.propagate(satrec, now);
const positionEci = positionAndVelocity.position; // km
const velocityEci = positionAndVelocity.velocity; // km/s

if (positionEci) {
  const gmst = satellite.gstime(now);
  const positionGd = satellite.eciToGeodetic(positionEci, gmst);

  const longitude = satellite.degreesLong(positionGd.longitude);
  const latitude  = satellite.degreesLat(positionGd.latitude);
  const altitude  = positionGd.height; // km acima do elipsoide

  console.log(`Lat: ${latitude.toFixed(2)}°, Lon: ${longitude.toFixed(2)}°, Alt: ${altitude.toFixed(1)} km`);
  console.log(`Velocidade: ${Math.hypot(velocityEci.x, velocityEci.y, velocityEci.z).toFixed(2)} km/s`);
}

O fluxo é simples: você consome TLEs de APIs públicas (como a Celestrak ou a N2YO), converte para satrec, propaga no tempo e transforma do referencial ECI (Earth-Centered Inertial) para geodésico (lat/lon/alt). Com isso, dá para montar um mapa em tempo real, calcular passagens visíveis ou, como o NextSpaceflight faz, comparar trajetórias de lançamentos para inferir destinos.

Buscando TLEs em massa para análise

Se você quiser ir além e cruzar dezenas de satélites de uma vez (igual a gente faria para tentar inferir quais cargas voaram na USSF-153), a abordagem é esta:

async function fetchTLEGroup(group = 'starlink') {
  const url = `https://celestrak.org/NORAD/elements/gp.php?GROUP=${group}&FORMAT=tle`;
  const res = await fetch(url);
  const text = await res.text();

  // TLE vem em blocos de 3 linhas: nome + linha1 + linha2
  const lines = text.split('\n').filter(Boolean);
  const tles = [];

  for (let i = 0; i < lines.length; i += 3) {
    tles.push({
      name: lines[i]?.trim(),
      l1: lines[i + 1],
      l2: lines[i + 2]
    });
  }
  return tles;
}

// Uso:
const starlinkTLEs = await fetchTLEGroup('starlink');
console.log(`${starlinkTLEs.length} satélites Starlink carregados.`);

// Para cada TLE, calcular altitude média e classificar por shell orbital:
starlinkTLEs.forEach(t => {
  const rec = satellite.twoline2satrec(t.l1, t.l2);
  const meanMotion = rec.no_kozai * 1440 / (2 * Math.PI); // revs por dia
  const altitudeKm = ((Math.cbrt(398600.4418) / meanMotion)**2 * (1 / 1440)**(-2/3)) - 6378.137;
  t.shell = altitudeKm;
});

console.table(starlinkTLEs.slice(0, 5), ['name', 'shell']);

Esse tipo de script é exatamente o que rola nos bastidores de ferramentas como NextSpaceflight, Orbiting Now e os painéis da Space-Track.org. A diferença é que eles têm acesso a dados TLE classificados para satélites governamentais — o que nós, devs civis, nunca vamos ver.

Erros comuns que devs cometem ao trabalhar com dados orbitais

Na minha experiência, vejo muita gente tropeçar nas mesmas armadilhas. Vou listar as principais para você não cair nelas:

• Confundir ECI com ECEF. Coordenadas em referencial inercial não batem com lat/lon diretamente. Sempre passe pelo GMST (Greenwich Mean Sidereal Time) antes de converter.
• Ignorar SGP4 e usar propagação kepleriana simples. TLEs são gerados pelo modelo SGP4, que inclui perturbações (J2, arrasto atmosférico, pressão de radiação). Tentar propagar com Kepler puro dá erro de centenas de quilômetros em poucas horas.
• Esquecer o offset entre UTC e GPS time. Satélites usam GPS time (sem leap seconds). Misturar as duas escalas causa drift sutil que aparece só horas depois.
• Tratar TLE como dado fresco. TLEs envelhecem rápido. Para missões recentes, prefira dados do Space-Track ou fontes oficiais atualizadas nas últimas 24h.
• Não considerar o formato OMM (XML). A NASA e a ESA migraram para o formato XML padrão CCSDS. Se seu parser só entende TLE, ele quebra silenciosamente em missões modernas.

O que dá para inferir sobre o software da SpaceX

A SpaceX nunca publicou oficialmente sua stack, mas alguns vazamentos, ofertas de emprego e apresentações no GitHub permitem montar um quadro razoavelmente preciso:

Repare no padrão: tudo on-prem, nada cloud-first. Faz sentido. Eles não podem ter latência de internet durante um lançamento, e não querem dados de design de foguetes saindo do perímetro de segurança.

FAQ — perguntas que um dev faria sobre essa missão

1. Por que a SpaceX corta a transmissão ao vivo em missões classificadas?

Porque a telemetria da carga pode revelar órbita, perfil de empuxo e timing de separação. Cortar a transmissão elimina o vetor de leak em tempo real, mas o booster ainda precisa pousar de forma pública (para fins regulatórios da FAA).

2. Dá para descobrir a órbita real de um satélite Starshield?

Não diretamente, porque a SpaceX não publica os TLEs governamentais. Mas dá para inferir pelo brilho durante passagens noturnas (como fez o astrônomo amador Scott Tilley com satélites secretos da China), ou pela análise da zona de descarte do booster, como o NextSpaceflight fez aqui.

3. Qual a diferença entre Starlink e Starshield na prática?

Hardware semelhante, missão diferente. Starlink é banda larga comercial. Starshield inclui payloads de observação, enlaces laser crosslink criptografados e contratos governamentais. Basicamente, é Starlink com esteroides para segurança nacional.

4. É possível rastrear satélites sem usar a Space-Track oficial?

Sim. Existem alternativas como N2YO, Celestrak, e o projeto comunitário SatNOGS (rede global de rádios amadores). APIs como a do Launch Library 2 dão dados de missão pré-lançamento.

5. O booster B1801 realmente é seguro depois de 27 voos?

Sim, mas cada reuso adiciona inspeção rigorosa. A SpaceX usa NDT (ensaios não destrutivos), análise de fadiga por ML e revisão estrutural antes de cada voo. É literalmente programação defensiva aplicada a engenharia mecânica.

Por que essa notícia me interessa como dev

Porque ela mostra o que acontece quando software encontra domínio crítico. Não dá para dar “F5 e rezar” em um sistema que carrega satélites de US$ 500 milhões para órbita baixa. Cada decisão de arquitetura — do banco de séries temporais ao sistema de comunicação entre booster e drone ship — precisa ser defensiva, testável e auditável.

E o mais legal: tudo isso está se tornando programável. APIs abertas, TLEs públicos, bibliotecas como satellite.js, astropy, poliastro. Você não precisa de PhD em astrodinâmica para começar a brincar. Com um Raspberry Pi e uma antena Yagi você consegue rastrear a ISS hoje.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto. Se você quiser explorar mais sobre APIs de rastreamento espacial, posso publicar um tutorial completo com Next.js + satélite em tempo real. Só pedir.