Correcção de Frequência de SDR

Os SDR baratos (tipo RTL-SDR) são um compromisso interessante para escuta, mais nas bandas de VHF e UHF, mas alguns deles têm alguns problemas de desvio de frequência, que em alguns caso se nota bastante após o aparelho aquecer. Para corrigir esse desvio existe uma configuração onde podemos especificar uma correcção em PPM – Partes por Milhão. A forma fácil de determinar o valor de correcção é monitorizar uma frequência conhecida e fazer a correcção até a frequência do VFO coincidir com a frequência “real”, mas existe uma forma mais complicada.

Ao configurar uma estação de recepção de sondas meteorológicas deparei com um método de calibração que usa as estações base dos telemóveis 4G como fonte de frequência estável. O código corre em Linux ou Raspberry Pi, mas é algo intensivo de CPU e num Rasperry Pi Model B muito antigo demorou mais de 1 hora para cobrir 1MHz de espectro.

Este artigo é uma descrição em português da informação disponível aqui e deixo todo o crédito a Mark Jessop VK5QI. Alguns pormenores relativos à compilação em Debian (e possivelmente Ubuntu) não são referidas no documento original.

Todos os comandos que deixo de seguida devem ser executados num terminal.

Para começar é necessário instalar as dependências:

$ sudo apt-get install cmake libncurses5-dev liblapack-dev libblas-dev libboost-thread-dev libboost-system-dev libitpp-dev librtlsdr-dev libfftw3-dev

De seguida é necessário obter a source, e isso pode ser feito de duas formas distintas. Se estiver a usar um Raspberry Pi pode obter o código já pronto a ser compilado da seguinte forma:

$ wget http://rfhead.net/sats/LTE-Cell-Scanner_rpi.tar.gz
$ tar -xzf LTE-Cell-Scanner_rpi.tar.gz

Se estiver a usar um desktop (Debian 10 no meu caso) deve obter o código do repositório

$ git clone https://github.com/Evrytania/LTE-Cell-Scanner.git

e de seguida fazer alguns ajustes.

Primeiro, editar o ficheiro LTE-Cell-Scanner/CMakeLists.txt e subsituir a linha
SET (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -ggdb -Wall")
por
SET (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++03 -ggdb -Wall")
que tem como efeito configurar o compilador de forma correcta.

De seguida, nos ficheiros

• LTE-Cell-Scanner/cmake/Modules/FindITPP.cmake
• LTE-Cell-Scanner/cmake/Modules/FindFFTW.cmake
• LTE-Cell-Scanner/cmake/Modules/FindRTLSDR.cmake

Adicionar o caminho
/usr/lib/x86_64-linux-gnu
ou
/usr/lib/i386-linux-gnu
à secção FIND_LIBRARY de modo a que o compilador consiga encontrar as livrarias necessários ao utilitário de pesquisa de células 4G.

Com isto feito podemos continuar para a compilação do código:

$ cd LTE-Cell-Scanner
$ mkdir build
$ cd build
$ cmake ../

Se não existiram erros vai voltar ao prompt, e então pode compilar o programa:

make CellSearch

Esta parte vai demorar um bocadinho, pode ser boa altura de ir buscar um café ou parecido, mas quando voltar ao prompt está pronto a começar, e o primeiro passo é entrar na directoria src onde foi colocado o binário:

$ cd src

As instruções originais falam em usar as frequências entre 770 e 780MHz, no entanto essas frequências em Portugal parecem não ser usadas, e após algumas pesquisas na internet e com o meu SDR reparei que existia “algo” entre os 790 e os 810MHz. O intervalo é bastante grande, e até deve existir uma base de dados da ANACOM com essa informação, mas o computador podia ficar ligado sozinho a trabalhar, e assim ficou. O comando correspondente (depois de ligar o SDR ao computador, claro) é:

$ ./CellSearch --freq-start 790e6 --freq-end 810e6

O output no meu caso começou com

LTE CellSearch v1.0.0 (release) beginning
Search frequency range: 790-810 MHz
PPM: 120
correction: 1
Found Rafael Micro R820T tuner
[R82XX] PLL not locked!
Examining center frequency 790 MHz ...
Allocating 15 zero-copy buffers
Examining center frequency 790.1 MHz ...
Allocating 15 zero-copy buffers
...

e ao fim de vários longos minutos (não fiquei a ver) obtive como resultado

Detected the following cells:
A: #antenna ports C: CP type ; P: PHICH duration ; PR: PHICH resource type
CID A fc foff RXPWR C nRB P PR CrystalCorrectionFactor
351 2 796M -5.7k -7.14 N 50 N one 0.99999284431066226553
352 2 796M -5.7k -9.34 N 50 N one 0.99999284323811299391
474 2 806M -5.58k -7 N 50 N one 0.99999307218738597847
476 2 806M -5.58k -7.51 N 50 N one 0.99999307904034195893
475 2 806M -5.58k -8.74 N 50 N one 0.99999307670099224499
470 2 806.3M -2.47k -17.3 E 50 N two 0.9999969349450061884

De todas estas opções devemos escolher a que tem o valor mais baixo de foff e que têm a coluna PR com one. No meu caso escolhi a terceira linha, nos 806MHz, e quem o valor CrystalCorrectionFactor com 0.99999307218738597847.

Para calcular o valor em PPM podemos fazer a conta

1000000*(1-0.99999307218738597847) = 6.9278126140215335

ou arredondando, 7 ppm (este SDR não é dos piores).

E com isto fiquei com um o valor reportado pelo software de descodificação de sondas mais perto do real. Neste caso em particular a correcção é pequena, mas ainda assim faz diferença no valor reportado como frequência da sonda que no caso dos lançamentos de Lisboa costuma ser 403.02MHz.

Para fechar, chamo a atenção para o meu scan ter apanhado células apenas entre os 796 e os 806MHz, por isso se for necessário poupar tempo, e talvez o faça no próximo SDR que testar, pode-se substituir o comando de scan por

$ ./CellSearch --freq-start 796e6 --freq-end 806e6