RTL-SDR v4 no Linux

Buscar uma RTL-SDR v4 irá gerar uma chuva de dongles similares por um terço do preço ou menos. A foto é idêntica, descrição, e jura que é v4. Mas não. Só um real aviso para não buscar algo similar.

O que faz um receptor RTL-SDR funcionar

Todo dongle dessa família tem dois chips que importam. Vale entender a função de cada um antes de comparar versões, porque é justamente neles que mora a diferença entre o caro e o barato. E pra situar onde esses chips moram, o desenho da cadeia inteira, do avião ao mapa no browser:

Linha tracejada é enlace sem fio, linha cheia é cabo. A faixa de cima é o mundo analógico do rádio, a de baixo é software rodando no Linux, e a USB é a fronteira entre os dois. Os blocos em azul mais forte são as duas coisas que ficam na sua mesa, e este artigo é inteiro sobre o primeiro deles.

O primeiro é o RTL2832U. Ele é o conversor analógico-digital e demodulador, o coração! É o componente que pega o sinal de rádio já tratado e o transforma no fluxo de bits que o computador vai processar. Esse chip é praticamente igual em todo mundo, do clone mais barato ao modelo oficial. Não é nele que está a briga.

O segundo é o tuner, o sintonizador. É ele que pega a faixa gigante do espectro e seleciona a porção que você quer ouvir, fazendo a primeira filtragem e amplificação antes de entregar pro RTL2832U. E é aqui que a história começa a divergir.

v3, v4 e o tuner

A geração anterior, a v3, usava um tuner chamado R820T2. Bom chip, popular, presente na maioria dos clones até hoje. A v4 trocou pra um R828D, e essa troca vem acompanhada de um front-end redesenhado, com filtragem melhor logo na entrada do sinal.

Por que isso importa na prática, e não só na ficha técnica? Porque o R828D com filtragem decente lida muito melhor com o problema mais chato de receptor barato em ambiente urbano: sobrecarga. Eu moro na região metropolitana de São Paulo. O espectro aqui não é um campo tranquilo, é uma feira livre lotada. Estações FM comerciais transmitindo com potência absurda, torres de celular por todo lado, tudo isso despejando energia na antena ao mesmo tempo. Um receptor sem filtragem adequada simplesmente engasga: o sinal forte de uma rádio popular vaza pra dentro da faixa que você quer ouvir e aparece como fantasma, imagem, ruído onde não deveria ter nada. Você acha que está recebendo um avião e na verdade está recebendo o programa do meio-dia de uma FM três quilômetros adiante.

O front-end melhorado da v4 não elimina o problema, mas reduz ele a um patamar tolerável. Pra ADS-B puro, em 1090 MHz, até um clone aguenta. Pra qualquer coisa abaixo disso, num lugar com poluição de RF como aqui, a diferença aparece rápido.

Os outros componentes

Tem mais coisa separando a v4 oficial de um clone genérico, e nenhuma aparece numa miniatura de anúncio:

O TCXO de 1 PPM. TCXO é um oscilador compensado em temperatura, e o 1 PPM indica a precisão. O oscilador é a referência de frequência do receptor, o relógio que diz “isto aqui é 1090 MHz”. Clones usam um cristal comum e barato, que deriva conforme esquenta. Na prática, você sintoniza uma frequência, o dongle aquece depois de uns minutos ligado, e a frequência escorrega. Pra escuta casual, irritante. Pra decodificação automatizada rodando o dia inteiro, que é o meu plano, inaceitável.

O bias tee ativável por software. É um circuito que injeta tensão pela própria linha da antena, pra alimentar um amplificador de baixo ruído ou uma antena ativa montada lá fora, sem precisar puxar energia separada até o telhado. Some na maioria dos clones.

O upconverter de HF integrado. Permite que a v4 sintonize lá embaixo, até 500 kHz, alcançando as ondas curtas. A v3 fazia isso por um método mais limitado, e os clones em geral nem tentam. Não é o foco do meu projeto aeronáutico, mas abre a porta pra brincar com HF depois sem comprar outro hardware.

E a caixa de alumínio, que não é estética: ela dissipa calor, o que ajuda a estabilidade do tal oscilador, e blinda o circuito de interferência externa. Clone costuma vir em plástico, ou em alumínio que é só enfeite.

Como saber se o que te ofereceram é clone

Regra prática, porque links de “v4” falsificada existem aos montes. Desconfie se o anúncio não menciona o tuner R828D, ou pior, se menciona R820T2, que é o tuner da geração antiga. Desconfie se não fala em TCXO. Desconfie se o preço é bom demais. E principalmente, compre da loja oficial, a Open Source SDR Lab, ou de revendedores reconhecidos. A RTL-SDR Blog não fabrica versão “econômica” da v4. Se está barato e diz v4, ou é clone, ou é v3 remarcada.

Um detalhe que na verdade é a melhor prova de autenticidade: a v4 de verdade exige um driver específico, o fork da própria RTL-SDR Blog, e não funciona corretamente com o driver padrão que a maioria das distros instala. Esse atrito de instalação, que enfrento e documento logo abaixo, é praticamente um selo de originalidade. Clone que finge ser v4 costuma rodar liso no driver comum, justamente porque por dentro ele é um R820T2 de sempre.

O que veio na minha caixa

Pra registro, comprei o kit que inclui, além do dongle, um conjunto de antena dipolo. Base com cabo curto, pares de elementos telescópicos de comprimentos diferentes, cabo de extensão, tripé flexível e suporte de ventosa. É um kit pensado pra iniciante, e isso não é demérito: os elementos curtos servem pra ADS-B, os longos pra frequências mais baixas, e montado em formato de V ele recebe satélite meteorológico em 137 MHz. Não é antena definitiva pra nenhum desses usos, mas é o suficiente pra sair do zero, e trocar antena depois é parte da diversão.

A instalação, ou: o atrito prometido

O plano original era deixar a instalação pro próximo artigo. O plano durou até a caixa chegar. Instalei nas duas máquinas na mesma madrugada, e o que aconteceu rende mais do que uma nota de rodapé, porque virou um estudo de caso involuntário de empacotamento de software em Linux. De um lado, o meu mini PC de homelab, um Intel GK3 Pro modesto rodando EndeavourOS, que hospeda meia dúzia de serviços e não impressiona ninguém em benchmark. Do outro, o desktop, um Ryzen 9 3900X de 24 threads com 64 GB de RAM rodando Fedora. Adivinhe em qual deles a instalação levou cinco minutos?

Antes dos comandos, o contexto do problema. A v4 usa o tuner R828D, e o driver rtl-sdr que toda distro empacota não conhece direito esse hardware. O dongle até é detectado, mas se apresenta como um R820T genérico, a sensibilidade fica péssima e as frequências saem deslocadas, porque o driver antigo ignora o upconverter interno de HF. A solução é o fork mantido pela própria RTL-SDR Blog. E tem um segundo inimigo: o kernel Linux carrega automaticamente o módulo dvb_usb_rtl28xxu, que reivindica o dongle para uso como receptor de TV digital e não larga mais. Todo tutorial manda fazer blacklist. Quase nenhum conta o resto da história, que eu descobri do jeito clássico.

EndeavourOS: o mini PC fraco que resolveu tudo em três comandos

No AUR o trabalho já está feito. O pacote rtl-sdr-blog-git declara conflito com o rtl-sdr genérico, então o gerenciador remove um e instala o outro sem me perguntar nada, e ainda traz as regras udev que liberam o acesso ao dispositivo sem root.

yay -S rtl-sdr-blog-git

echo 'blacklist dvb_usb_rtl28xxu' | sudo tee /etc/modprobe.d/blacklist-rtlsdr.conf
sudo modprobe -r dvb_usb_rtl28xxu

rtl_test -t

Saída:

Found 1 device(s):
  0:  RTLSDRBlog, Blog V4, SN: 00000001
Found Rafael Micro R828D tuner
RTL-SDR Blog V4 Detected

Fim. O hardware mais fraco da casa, com o processador que a Intel vende pra caber em mini PC de menos de mil reais, teve a experiência de instalação de um produto Apple. Não porque o Arch é mágico, mas porque alguém na comunidade já tinha resolvido o conflito de pacotes e codificado a solução no PKGBUILD. É isso que o AUR é na prática: memória coletiva de atrito.

Fedora: o desktop parrudo que virou uma saga

No Fedora não existe pacote do fork, nem nos repos, nem em COPR funcional. É compilar da fonte, o que em si não é problema. O problema é o que vem depois, em camadas.

sudo dnf remove rtl-sdr
sudo dnf install git cmake gcc libusb1-devel

git clone https://github.com/rtlsdrblog/rtl-sdr-blog
cd rtl-sdr-blog && mkdir build && cd build
cmake ../ -DINSTALL_UDEV_RULES=ON
make -j$(nproc)
sudo make install
sudo ldconfig

Compilou, instalou, e o rtl_test respondeu com:

rtl_test: error while loading shared libraries: librtlsdr.so.0:
cannot open shared object file: No such file or directory

Primeira camada: no Fedora x86_64, o cmake instala bibliotecas em /usr/local/lib64, e esse diretório não está no caminho do linker dinâmico por padrão. O binário existe, a lib existe, os dois simplesmente não se conhecem. A correção é uma linha, desde que você saiba qual linha:

echo '/usr/local/lib64' | sudo tee /etc/ld.so.conf.d/local-lib64.conf
sudo ldconfig

Lib resolvida, rtl_test de novo, e agora: No supported devices found. O dongle sumiu do barramento. lsusb vazio. Abri o dmesg -w, repluguei, e encontrei a segunda camada, a mais bonita da noite.

A porta USB que aceita YubiKey mas rejeita rádio

O log era um festival de error -71, o EPROTO do subsistema USB, em loop: o dongle enumerava, falhava ao configurar, desconectava, o kernel tentava de novo, ciclava a energia da porta e por fim desistia com a mensagem mais passivo-agressiva do kernel Linux:

usb usb1-port11: Cannot enable. Maybe the USB cable is bad?

Não era o cabo. Era a porta. Aquela porta tinha passado meses hospedando uma YubiKey sem nenhum incidente, e por isso eu nem suspeitava dela. Só que YubiKey é um dispositivo full-speed, 12 Mbps, consumindo uns 30 mA. Praticamente qualquer porta com mau contato, trilha marginal ou alimentação capenga sustenta isso. O RTL-SDR v4 é outro animal: high-speed, 480 Mbps de barramento, na casa dos 300 mA de consumo. Ele expõe toda fraqueza elétrica que um dispositivo leve mascara. A porta não estava boa, estava boa o suficiente pra criptografia e insuficiente pra rádio.

A lição de troubleshooting que fica: “funciona com outro dispositivo” não valida uma porta USB. Valida a porta para aquela classe de dispositivo. Mudei o dongle pra uma porta traseira ligada diretamente ao controlador USB do próprio processador, em vez do controlador do chipset da placa, e o EPROTO evaporou. Se o seu dongle enumera e desconecta em loop, antes de culpar o hardware ou abrir issue no GitHub do driver, teste outra porta física, de preferência as traseiras coladas na placa-mãe, e esqueça hubs e as portas frontais do gabinete, que chegam ao chipset por um cabo interno de qualidade duvidosa.

O módulo zumbi

Terceira camada. Com o dongle enumerando limpo, o rtl_test reclamou que o kernel driver estava ativo. Mas eu tinha feito a blacklist. Rodei lsmod e lá estava o dvb_usb_rtl28xxu, carregado, vivo, saudável.

Acontece que blacklist no modprobe.d impede o carregamento automático do módulo no boot, mas não impede que ele seja carregado por alias quando um evento de hotplug pede. Replugou o dongle, o udev viu um dispositivo DVB, pediu o módulo pelo alias, e o kernel entregou, blacklist ou não. A diretiva que fecha essa porta é outra:

sudo tee /etc/modprobe.d/blacklist-rtlsdr.conf << 'EOF'
blacklist dvb_usb_rtl28xxu
install dvb_usb_rtl28xxu /bin/false
EOF

A linha install substitui o comando de carga do módulo por /bin/false, ou seja, qualquer tentativa de carregá-lo, por qualquer via, falha silenciosamente. Depois disso, dracut -f pra regenerar o initramfs e blindar também o cenário de boot com o dongle já plugado. Guarde essa segunda linha: ela falta em nove de cada dez tutoriais, e é a diferença entre um sistema que funciona e um sistema que funciona até você replugar o dongle.

E o typo que protegia contra DVDs

Justiça seja feita ao Fedora: quando voltei ao EndeavourOS pra validar tudo com o mesmo rigor, descobri que a minha blacklist de lá continha blacklist dvd_usb_rtl28xxu. Com D de DVD. O arquivo estava lá havia semanas, protegendo o sistema com firmeza contra um módulo que não existe, enquanto o módulo real tinha simplesmente dado a sorte de não reivindicar o dongle nas sessões em que testei. Funcionava por acaso. O tipo de bug que nenhum monitoramento pega, porque não há erro nenhum, só uma configuração fazendo nada com muita convicção.

O placar

O hardware não teve voto em nada disso. O desktop tem doze núcleos ociosos esperando trabalho e apanhou de um mini PC porque a variável que importa é ecossistema de empacotamento, não silício. Pra software de nicho como SDR, o AUR é imbatível, e não é fanboyismo de Arch, é constatação: a chance de alguém já ter empacotado o fork obscuro que você precisa, com os conflitos declarados e as regras udev no lugar, é ordens de magnitude maior lá do que em qualquer COPR.

E por falar em COPR: a saga do Fedora não acabou no driver. O SDR++ não está no Flathub, apesar do que a internet sugere. O COPR do SatDump respondia 404 pra versão atual do Fedora. Resultado: os dois também foram compilados da fonte, num ciclo de cmake, erro de dependência, dnf install alguma-coisa-devel, repeat, que qualquer um que já compilou software de rádio em RPM conhece de cor. No EndeavourOS, os três estão no AUR.

O stack completo, e pra que serve cada peça

Com o driver no lugar, o que roda em cima dele:

rtl-sdr-blog é a fundação, o fork do driver com a librtlsdr que entende o R828D, mais os utilitários de linha de comando. O rtl_test valida detecção e mede perda de amostras, o rtl_tcp expõe o dongle pela rede pra outro computador consumir o sinal, e o rtl_biast liga o bias tee por software quando houver um LNA lá fora pra alimentar.

readsb é o decodificador de ADS-B, sucessor espiritual do dump1090. Ele consome as amostras brutas em 1090 MHz, encontra os preâmbulos das mensagens dos transponders, decodifica, valida CRC e serve o resultado em várias interfaces de rede. É o coração do pipeline que alimenta o Prometheus e, mais adiante, o mapa e o bot. Roda 24/7 no mini PC, que é exatamente o tipo de carga pra qual aquele hardware existe.

SDR++ é o receptor de propósito geral com interface gráfica, o equivalente moderno de girar o dial de um rádio, só que vendo o espectro inteiro na tela em cascata. É a ferramenta de exploração: procurar sinais, escutar repetidoras, investigar aquele pico estranho em uma frequência que você não conhece. Suporte nativo à v4 e ao protocolo do rtl_tcp, o que significa que posso rodar a interface no desktop consumindo o dongle plugado no servidor.

SatDump é o decodificador de satélites, e é o que transforma um passe do NOAA-19 em imagem meteorológica. Ele conhece os pipelines de dezenas de satélites, do APT analógico dos NOAA aos digitais mais modernos, cuida da demodulação e da composição das imagens. É a peça do plano que justifica os elementos longos da antena dipolo montados em V.

Quatro programas, uma biblioteca embaixo de todos. Se a librtlsdr errada estiver no caminho do linker, os quatro enxergam o dongle como um R820T antigo e degradam em silêncio, sem erro, sem aviso, só recepção pior. No Fedora isso exige atenção permanente, porque instalar qualquer coisa via dnf que dependa de rtl-sdr reintroduz a lib genérica em /usr/lib64, na frente da do fork na ordem de resolução. A vacina é uma linha no /etc/dnf/dnf.conf:

excludepkgs=rtl-sdr

Lá em cima eu disse que o atrito de instalação é praticamente uma prova de originalidade da v4, porque clone roda liso no driver comum. Depois desta madrugada, sustento com mais convicção ainda: o meu dongle exigiu o driver certo, expôs uma porta USB fraca que dois anos de YubiKey nunca revelaram, sobreviveu a um módulo de kernel zumbi e a um typo meu, e no fim entregou 0 samples lost e a detecção correta do R828D nas duas máquinas.