Spectrum Analyzer using DXPatrol MK4

The 2MHz maximum display from an RTL dongle sometimes is not enough, one way to deal with it and explore the spectrum is using QSpectrumAnalyser.

Using QSpectrumAnalyser with DXPatrol MK4 from 87 MHz to 1,5GHz

Just follow the instructions on AD-Vega/rtl-power-fftw

DXPatrol MK4 SDR

There is a new DXPatrol SDR, the Ultra Wide-band Coverage SDR Receiver DXpatrol Mk4. Some new features:

Direct Sample Mode *

Very High performance Pre-amplifier +33dBm IP3*
Font-end input antennas protection *
Shielded Aluminum box *
*New

Dispositivos série remotos

servidor

Na máquina onde temos o radio ou o winkeyer e até mesmo a TNC, gps etc. Instalar o ser2net sudo apt-get update&&sudo apt-get install ser2net
Editar /etc/ser2net.conf

BANNER:banner:Serial-USB Proxy Server: 38400 baud, 8, none, 1 (Kenwood TS-590S)
4001:raw:0:/dev/ttyUSB0:38400 8DATABITS NONE 1STOPBIT
3001:raw:0:/dev/ttyS0:1200 8DATABITS NONE 2STOPBITS

 
A configuração anterior disponibiliza a porta sério do rádio em 192.168.1.25:4001 e em 192.168.1.25:3001 como se fosse uma bridge serial to ethernet.
 

cliente

Se for aberta uma sessão de telnet para os portos configurados podemos  comandar o rádio ou gerar morse no winkeyer pela consola. Porem, normalmente o desejável é usar o nosso software que poderá não ter ligação a portos TCP para isso basta instalar o socat sudo apt-get update&&sudo apt-get install socat
Correr o seguinte comando: sudo socat -v -d -d -d PTY,link=/dev/ttyS1,rawer,wait-slave,user=pmc,group=dialout TCP4:192.168.1.25:4001
A partir daqui o porto série virtual /dev/ttyS1 está ligado ao porto série no servidor e disponível para ser usado por qualquer programa como se o equipamento estivesse ligado na máquina cliente

No FLRig configurar o rádio e no separador TCPIP configurar o TCP IP address, TCPIP Port, e "Use tcpip".

 O fldigi na versão 4 já tem um modem com o winkeyer, esta configuração complementada com o pulseaudio permite operação remota completa e totalmente integrada. O custo de largura de banda é simpático, pulseaudio + serial2net e socat cerca de 4  MBytes no máximo. A resposta é muito melhor do que soluções com o VNC ou remote desktop afinal temos o software a correr na nossa máquina.

Áudio remoto no linux (revisitado)

Usando arecord e aplay

Existem muitos softwares para capturar e distribuir áudio remoto para SO Microsoft, nomeadamente os dedicados a esta tarefa e outros mais genéricos que podem ser usados para o efeito como o Skype. No GNU/Linux o panorama é um pouco diferente, aparentemente não há soluções "chave na mão". Porem com alguma imaginação isto é muito fácil de obter: basta instalar o 'alsamixer' e 'libogg' 'libvorbis' 'vorbis-tools' e finalmente 'mplayer' no par servidor/cliente. Não se admire que alguns destes já façam parte da sua distribuição.
Assim para obter áudio remoto:
ssh user@192.168.1.25 'arecord -f cd -t wav -vv | oggenc - -r' | mplayer -
Versão com menos lag e BW de cerca de 400k, a novidade está aqui.
ssh -C pmc@192.168.1.25 'arecord -f cd -D hw:2,0 -t wav -M | oggenc - -r -q 10' | mplayer -
Assim tem o áudio da entrada de áudio "default" da sua máquina remota. Para setups mais complexos o programa 'arecord' permite a escolha da entrada, por ex: ...arecord -f cd -D hw:0,0... uma vista de olhos pela man page revela outras facilidades. Esta pode ser usada numa máquina remota com vários rádios ligados a várias placas. Rádios com o o TS-590 com placa de som interna podem ser usados com muita facilidade não precisando de adaptadores ou cabos especiais, apenas o cabo USB.
Para enviar áudio para o rádio remoto é assim:
arecord -f cd -t raw | oggenc - -r | ssh user@192.168.1.25 'mpalyer -'
Um "&" no fim de cada comando liberta a shell para receber outros comandos e temos uma ligação full-duplex para o nosso rádio remoto.
https://ct7aez.blogspot.pt/2016/09/audio-remoto-no-linux.html

Usando portaudio Audio Server

A novidade aqui é podemos usar uma placa de som remota no fldigi. 

Servidor

sudo apt-get install pulseaudio pulseaudio-module-zeroconf alsa-utils avahi

Adicionar o utilizador aos grupos audio pulse e pulse-access

sudo usermod -a -G audio user sudo usermod -a -G pulse user sudo usermod -a -G pulse-access user
Ver os grupos a que pertence o utilizador sudo groups user
Fazer PulseAudio iniciar no arranque
Editar /etc/default/pulseaudio

Change PULSEAUDIO_SYSTEM_START to 1

Editar /etc/pulse/daemon.conf

exit-idle-time = -1 para evitar "timeout"

Editar /etc/pulse/default.pa

load-module module-alsa-sink device=hw:2,0
load-module module-alsa-source device=hw:2,0
load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.1.0/24
load-module module-zeroconf-publish

Comentar o seguinte:

### Automatically load driver modules depending on the hardware available
#.ifexists module-udev-detect.so
#load-module module-udev-detect
#.else
### Use the static hardware detection module (for systems that lack udev support)
#load-module module-detect
#.endif

pulseaudio -vvv para fazer o debug se necessário.

Cliente

Instalar o psprefs sudo apt-get install paprefs
Correr o paprefs e configurar o seguinte:

• Make discoverable PulseAudio network sound devices available locally
• Enable network access to local sound devices
• Allow other machines on the LAN to discover local sound devices
• Don’t require authentication

A monitorização do sinal pode ser feita assim:
pactl load-module module-loopback
No pauvcontrol selecionar o separador A Gravar selecionar "Show All Streams" e selecionar a fonte para o monitor "PCM2903BAudio CODEC on XXXXX".

fldigi

No fldigi na configuração da placa de som selecionar "PortAudio" e colocar o servidor local.
Com este setup a latência é quase 0 (menos de 1 segundo garantidamente). 

fldigi remoto + eficaz

Uma das maneiras de operar uma estação remota é usar o X11 com o ssh. Porem a largura de banda necessária não é a mais conveniente para o caso do fldigi, tornando este impossível de usar.

A maneira "normal" de usar o fldigi numa máquina remota será esta:

ssh -X xxx@remote

mas vamos de precisar de uns 50 Mb/s ou mais o que numa rede Wi-Fi fica impossível de usar. Uma maneira de melhorar é usar a compressão de dados assim:

ssh -XC xxx@remote

Isto reduz para menos de metade a largura de banda necessária, difícil de usar por wireless mas excelente numa ligação por cabo.

 Se tivermos uma máquina lenta ainda podemos melhorar desligando a cifra:

ssh -XC -c none xxx@remote

e ficamos livre do processamento de encriptação necessário, mas com o problema de ficar com o nosso tráfego visível.

Alias úteis

Se usar Linux é bem provável que tenha de usar bash, ou a linha de comandos se preferir. este ambiente é altamente configurável e aqui tem algumas dicas para a estação de rádio. Assim alguns comandos aparentemente compridos podem ser reduzidos a por exemplo '590' na linha de comandos para obter um terminal de controlo do rádio com o rigctl. Os comandos desde que respeitem as regras do seu terminal podem ser o que quiser.
Em baixo um extrato do meu .bashrc

# iniciar o rigctl para o TS-590S em /dev/ttyUSB2
alias 590='rigctl -m 231 -r /dev/ttyUSB2'
# iniciar o terminal para fazer morse pelo teclado (existe um ficheiro .minirc.begali com a configuração alvo)
alias cwm='minicom begali'
# terminal de controlo do kx3
alias kx3='rigctl -m 229 -r /dev/ttyUSB0'
# inicia o deamon de controlo do TS-590S (conector de rede)
alias r590='rigctld -m 231 -r /dev/ttyUSB2'
# liga remota ao controlo do rádio
alias rem='rigctl -m 2 -r 192.168.1.24'
# inicia o daemon para o kx3
alias rkx3='rigctld -m 229 -r /dev/ttyUSB0'

A forma de carregar as modificações ao .bashrc é a seguinte 'souce .bashrc'

Problemas com placas gráficas Intel

Devido à natureza do desenvolvimento do GNU/Linux por vezes não temos o melhor suporte para o nosso hardware. O pc que uso na minha estação é um Core 2 Duo com 4 GB de RAM e uma placa gráfica Intel (tentem fazer tudo o que fazem a correr o Windows numa máquina antiga como esta :D).
Ás vezes ficava com os menus completamente escuros ou mesmo janelas inteiras completamente pretas, um login-logout e assunto resolvido. Porem com o gqrx ou o fldigi a puxar pela gráfica este problema era mais frequente. Se sofre do mesmo mal o remédio é este:

Crie um ficheiro em /etc/X11/xorg.conf.d/20-intel.conf (é muito provável que não exista, é criar) com o seguinte:

Section "Device"
   Identifier  "Intel Graphics"
   Driver      "intel"
   Option      "AccelMethod"  "uxa"
EndSection

Se o problema persistir substitua "uxa" por "sna". Uma forma de verificar o sistema é assim:

cat /var/log/Xorg.0.log | grep -i uxa

[    28.820] (II) intel(0): SNA compiled: xserver-xorg-video-intel 2:2.21.15-2+b2
[    28.896] (**) intel(0): Option "AccelMethod" "sna"
[    29.116] (II) intel(0): SNA initialized with Alviso (gen3) backend

Banda dos 2 metros

Por causa da minha disponibilidade, a escolha de bandas que opero assenta quase sempre no HF. É com alguma pena que tenho "poucas horas de voo" nas ondas ainda mais curtas. Nas horas que estou no rádio os grandes eventos da ionosfera e atmosféricos no VHF já foram.
Depois de um update ao gqrx para a ultima versão fiquei com a possibilidade de ter um waterfall de algumas horas, uma boa oportunidade para monitorizar o que passa pela banda dos 2 metros que calha mesmo bem para DX Patrol Mk3 que consegue receber 2 MHz de espectro.

Infelizmente neste caso, e sem grande surpresa, o ruído é notório e em quantidade para desencorajar qualquer um.
O ambiente é rural, a antena usada é um J-Pole montado baixinho.
Ainda assim se pode ver o APRS e o TX de alguns repetidores no lado direito.