Uma síntese da construção do sistema entre agosto e setembro de 2026: integração do RTL-SDR com o OpenWebRX, criação do site público, ampliação por perfis de frequência, entrada do segundo dongle e implementação do rastreamento ADS-B.
O objetivo do Poli WebSDR é disponibilizar em um navegador sinais captados por antenas reais. No começo do desenvolvimento, a interface recebia um espectro sintético produzido por um programa em Python. Essa etapa permitiu desenvolver a apresentação sem depender do hardware, mas o marco decisivo foi substituir a fonte simulada por um receptor SDR real.
A arquitetura evoluiu sem abandonar essa ideia de separação entre aquisição e interface: o hardware entrega amostras I/Q; o software realiza processamento, demodulação e geração do espectrograma; e o navegador apresenta o resultado. Isso tornou possível mudar a fonte de dados sem reescrever toda a experiência web.
O projeto deixou de operar apenas sobre dados sintéticos. Um RTL-SDR Blog V4 passou
a fornecer amostras reais, inicialmente na faixa de FM comercial. O fluxo foi
publicado via rtl_tcp e consumido pelo OpenWebRX. A recepção em FM,
o áudio WFM e a identificação RDS serviram como validação de ponta a ponta.
Depois do primeiro funcionamento, a prioridade passou a ser a experiência do usuário. Em vez de expor somente a interface técnica do OpenWebRX, foi criado um site estático independente, servido em outra porta e capaz de incorporar o receptor por iframe. Assim, a apresentação pública poderia evoluir sem colocar o receptor em risco.
A cobertura foi ampliada para 118–137 MHz por meio de perfis AM sucessivos. Cada perfil trabalha com 2,4 MS/s; a navegação foi organizada em trechos de aproximadamente 2 MHz para deixar margem nas bordas. Também foi desenvolvido um controle em forma de régua de frequência para selecionar automaticamente o perfil adequado à sintonia.
Um segundo RTL-SDR, com sintonizador R820T, foi incorporado ao conjunto. Além de
ampliar a flexibilidade de recepção em VHF/UHF, ele permitiu dedicar um receptor à
aviação. A cadeia ADS-B passou a captar 1090 MHz, decodificar mensagens com
readsb e publicar os dados para uma página própria com mapa e lista de
aeronaves.
O simulador original já imitava o protocolo rtl_tcp: abria um socket TCP,
enviava o cabeçalho esperado pelo cliente e transmitia amostras I/Q de 8 bits. Para o
OpenWebRX, portanto, o simulador ocupava a mesma posição lógica que um dongle real.
Em vez de alterar a camada de apresentação, substituímos a fonte de amostras. Esse desacoplamento reduziu o risco da integração e permitiu reaproveitar a interface já desenvolvida.
Nos primeiros ensaios, a frequência central foi definida em 97 MHz e a taxa de amostragem em 2,4 MS/s. A faixa de FM foi escolhida por oferecer sinais fortes, contínuos e fáceis de comparar com frequências conhecidas. A confirmação prática veio com emissoras reais, áudio WFM inteligível e dados RDS decodificados.
O OpenWebRX roda em contêiner Docker, enquanto o rtl_tcp é iniciado no
computador hospedeiro. Isso tornou importante distinguir o localhost do
contêiner do localhost da máquina. O endereço 127.0.0.1 visto de
dentro do contêiner não aponta para o processo do host.
A solução foi publicar o servidor de amostras no gateway da rede Docker,
172.17.0.1, e configurar o OpenWebRX para se conectar a esse endereço. Essa
correção foi central para recuperar a waterfall e estabilizar a integração.
rtl_tcp -a 172.17.0.1 -p 1234 -s 2400000 -f 97000000 -g 25
docker restart openwebrx
Outra restrição importante é física: um dongle só pode ser aberto por um processo por vez.
Por isso, SDR++, rtl_tcp, readsb e outros programas não podem disputar
simultaneamente o mesmo dispositivo.
A interface do OpenWebRX é poderosa, mas densa para quem quer apenas explorar sinais e ouvir uma transmissão. A solução adotada foi separar o site público do receptor: o site apresenta o projeto, as faixas e os conteúdos; o OpenWebRX continua responsável pela parte técnica, incorporado quando necessário.
A identidade visual foi organizada para alternar áreas claras de leitura com áreas escuras associadas ao instrumento. Frequências, unidades e rótulos técnicos usam tipografia monoespaçada. A barra de navegação foi concebida como uma régua de sintonia, reforçando a linguagem visual do rádio sem depender de uma estética institucional genérica.
O RTL-SDR entrega uma janela instantânea determinada pela taxa de amostragem I/Q. No projeto, a configuração conservadora é de 2,4 MS/s. Em vez de trabalhar no limite dessa janela, os perfis foram organizados em trechos de aproximadamente 2 MHz, deixando margens nas bordas e sobreposição entre perfis.
Isso não significa que o rádio esteja limitado a uma faixa total de 2 MHz. O limite é instantâneo: o receptor pode ser ressintonizado e o site pode trocar de perfil. Assim, uma faixa extensa — como 118–137 MHz — pode ser percorrida por várias janelas menores, mesmo que apenas uma delas seja capturada por vez por um dongle.
A entrada do segundo dongle reduziu a necessidade de escolher entre diferentes aplicações.
Ele foi testado como receptor adicional para VHF e outras faixas, com uma instância de
rtl_tcp separada na porta 1235. Também foi configurado um perfil de teste para
a antena loop na região de 500 kHz a 1,8 MHz.
Na sequência, o segundo receptor passou a cumprir um papel ainda mais específico: receber sinais ADS-B de aeronaves em 1090 MHz, liberando o receptor principal para as outras experiências do WebSDR.
ADS-B é um sistema em que aeronaves transmitem periodicamente mensagens com dados de voo.
Quando recebidas pela estação, essas mensagens podem conter identificação, altitude,
velocidade, rumo e posição. No projeto, a recepção em 1090 MHz é tratada por
readsb.
O decodificador gera o arquivo /home/websdr/site-poli/adsb/aircraft.json. A
página adsb.html consulta esse arquivo em intervalos de aproximadamente um
segundo e atualiza um mapa Leaflet e uma lista lateral com as aeronaves detectadas.
A recepção já produziu mensagens válidas com voos identificados e campos de altitude, velocidade, rumo e, quando disponível, latitude e longitude. O mapa é apenas a camada de apresentação desses dados já decodificados.
O resultado mais importante não é apenas um conjunto de páginas ou comandos, mas uma arquitetura modular: diferentes antenas e receptores podem alimentar aplicações distintas sem que a interface pública precise ser reconstruída a cada nova experiência.