Software

MSK144, FT8… using an IC-9700 and WSJT-X

Publicado em , por Emmanuel

It’s Perseids time! Let’s try some Meteor Scatter contacts, but first, let’s configure the latest version of WSJT-X (2.4.0) on a Linux computer along with an ICOM IC-9700 transceiver…

The IC-9700 is connected to the computer via its USB (Universal Serial Bus, not Upper Side Band, OK?) port, using a regular USB-A/B cable (printer-like). I recommend some cable that has ferrites on each end of it, for eventual EMI reduction.

Assuming that the transceiver has its factory default settings or has been recently resetted
(MENU > SET > Others > Reset > Partial Reset), the following instructions prepare the transceiver for remote control through the computer:

  • [MENU]
    • [SET]
      • [Connectors]
          • [MOD Input]
            • USB MOD Level: 35%
            • DATA MOD: USB
          • [CI-V]
            • CI-V Baud Rate: 19200
            • CI-V USB Port: Link to [REMOTE]
            • CI-V DATA Baud Rate: 19200

On the computer, once the WSJT-X software has been succesfully installed, follow the screenshots below tha illustrate the configurations used in the Radio and Audio tabs of the Settings… configuration tool, available under the menu File.

The Serial Port and the Sound Card settings on your system may be different than the ones shown here… The  system used here runs under Debian 10 Buster.

Once the system is ready to operate and in my case, having pointed the antenna to North-Earth at an elevation of about 45 degrees, after about 24 hours of operation, the results are nice to see on the map of the website pskreporter.info, as shown below (operating in MSK144 from Locator IN51).

As a final note, once the system is completely configured as above, it works also for any digital mode available on WSJT-X…

73 de CT7AFR.

Resolvendo um problema de áudio no GNU Radio

Publicado em , por Emmanuel

Estava a preparar um trabalho com GNU Radio e um dongle RTL-SDR (antes, tinha tentado com um ADALM-Pluto), implementando um popularíssimo esquema (abaixo) para desmodular estações de rádio comercial (FM), e o áudio à saída do meu sistema estava aos soluços…

RTL-SDR_FM-RX

Ainda pensei tratar-se de um erro de cálculo na parametrização das diversas operações de Interpolação e Decimação pela meio da cadeia, mas não era isto. Pensei também tratar-se de uma limitação na frequência de amostragem da minha placa de som; porém alterando o valor desta e procedendo aos devidos ajustes no resto da cadeia, o problema mantinha-se.

Foi então que notei que na janela de Terminal do GNU Radio, dependendo de alguns parâmetros (decimação/interpolação), apareciam sequências de caracteres OOOOO ou aUaUaUaUaU… Uma pesquisa pela Internet induziu-me no sentido de procurar o erro na relação entre o GNU Radio e a placa de som. Os aU referem-se a “audio Underrun“. Portanto, o problema tinha um cheiro a buffer com falta de dados…

Parti então para uma busca minuciosa pelos ficheiros do GNU Radio até descobrir um em particular e com o qual consegui resolver o problema: gr-audio-alsa.conf. No meu sistema (Debian 10 – buster), este ficheiro encontra-se em /etc/gnuradio/conf.d/.

[audio_alsa]
default_input_device = default
default_output_device = default
# period time in seconds
period_time = 0.050
# total buffering = period_time * nperiods
nperiods = 8
verbose = false

Neste ficheiro, após duas iterações de tentativa-erro, resolvi o problema, aumentando o valor das variáveis period_time e nperiods (originalmente estavam iguais a 0.010 e 4, respectivamente).

Resolvido este assunto, deixo aqui o meu apotnmento para a eventualidade de dar jeito a alguém que esteja a passar pelo mesmo azar.

Shutdown button for the Raspberry Pi

Publicado em , por Emmanuel

shutdown_1
One thing that sometimes bothers me when using an headless embedded Linux system, is the workload I get when I need to power off the system for some hardware maintenance (e.g. adding some sensor, replacing some peripheral, moving the system to another location). Indeed, one cannot just cut the power supply; there is the risk that some files become corrupted. So, the proper way to shutdown a Linux system is to send a command like:

$ shutdown -h now

But to do this, one needs to be “online” with the system, via SSH for example, using another system (computer) that, at that moment, may precisely be OFF… Doh!

So, at the expense of a simple push-button (normally open), a couple of wires and some programming, I implemented a smart(?) way of shutting down my Raspberry Pi, safely, without the need of an extra computer, SSH and other complications.

Connecting the push-button

The push-button is connected to two of the 26 or 40 pins header, depending on the version of the raspberry Pi in use. From those two pins, one is GND and the other may be any free GPIO. Remember that some pins have multiple possible roles (I2C, UART, SPI, etc), so choose wisely. In my case, I plugged the button between pins 14 and 16, respectively GND and GPIO23.

raspi_pinout

Programming

To translate any action on the push-button into a Shutdown command, a script was written in the Pi’popular Python programming language.

In a folder of your choice (e.g., /home/pi), using the terminal command line, enter:

$ nano shutdown_button.py

Then, copy the following code into it and save as usual (CTRL-X + Y + ENTER):

shutdown_2

Testing the script

To test this script, just enter the following command and then press the button once.

$ sudo python shutdown_button.py

If everything is correct, the system should shutdown itself. You must then unplug and replug the power cord to start your system again.

Launching this script automatically after every system power-up

In order to launch this script automatically after every system boot, one must add the following line to the /etc/rc.local file (just before the line with exit 0) as shown in the image hereafter (assuming your script file is in the /home/pi folder):

python /home/pi/shutdown_button.py &

shutdown_3

Final notes

  1. If you prefer to have your Pi to reboot instead of shutting down after pressing the button, in the shutdown_button.py script, in the line containing os.system(“shutdown -h now”), replace the letter ‘h‘ (from halt) by a ‘r‘ (for reboot).
  2. The line stated in the above note is in fact a System Call. So, with this script, you can have your Pi doing “anything you want” after pressing the push-button, just by replacing the command between quotation marks, by another command invoking some application that suit your needs.

Have fun!

 

Simple C code to dump I2C device memory

Publicado em , por Emmanuel

I have been using I2C devices for a while and most of the times when I put my hands on a new device, I need to dump the contents of its registers on my screen, for debug purposes. For this task, I wrote a while ago a little script. Today, I feel I can share this code to whom it may be useful. Use it at your own risk.

This code was written in C language, on a Raspberry Pi and requires the WiringPi library to be installed.

Once you saved this code into a file (e.g., main.c), compile it with the following command in a shell:

$ gcc -o regdump main.c -lm -lwiringPi -Wall

If all went well and you have some I2C device plugged into your Raspberry Pi, your are good to go as long as you know the device’s bus address (try the command i2cdetect -y 1, if your are not sure of its address or if your device is connected to the bus).

So, once you are good to go, just type the following command, specifying the device’s I2C address and the first and last registers addresses to be read (all in Hexadecimal format):

$ ./regdump <device I2C address> <start address> <stop address>

For example, typing the command $ ./regdump 0x77 0x75 0xd3 returns the following result, from the reading of a BMP085 pressure sensor existing in my I2C bus.

regdump_screenshot

The code is available for download, here!

Feel free to change it to your needs. And if suits your needs, I will be glad to receive some feedback, opinions or critics about it; either via a comment below or via e-mail to webmaster @rrob@ airlomba dot net.

Have fun!

 

O que pode correr mal num SOTA (XIV)

Publicado em , por Emmanuel

EA1_OU-013

Nem só de caminhadas e operações com rádio, se fazem SOTAs. Uma SOTAda implica uma preparação prévia e algum trabalho de pós-produção, entre outras tarefas mais ou menos óbvias. Este artigo não visa explicar como faço as minhas activações, pelo menos, com o título que tem. Para contar como preparo e executo as minhas activações, escreverei outro artigo, um dia…

Não, este artigo, como o título indica, revela mais uma “armadilha” que pode aparecer na linha de uma activação.

Por já me ter acontecido no passado e por saber que aconteceu com outros sotistas, resolvi deixar por escrito aqui, um pequeno guia de correcção de gafes no LOG da sotada, submetido no sítio sotadata.

O primeiro tipo de erro é comum e simples de cometer. Ocorre quando se está a inserir manualmente no LOG, um a um, os contactos realizados. Trata-se do erro tipográfico. Pode acontecer na Hora, no Indicativo de Chamada ou até na selecção de um dos ítens dos menus drop-down, Band ou Mode. A imagem abaixo, ilustra um desses erros. NOTA: Esta imagem e as seguintes, são apenas ilustrativas e não correspondem a alguma activação real.

Gafe 1

Para corrigir o erro no Callsign, terei de eliminar (Delete) a linha correspondente e voltar a inserir os dados relativos a este contacto. O sistema de gestão de LOGs inserirá a nova linha no local certo, uma vez que os contactos são ordenados cronologicamente, conforme ilustra a imagem abaixo.

Gafe 1 resolvida

A outra situação de erro, ocorre quando o activador se apercebe do erro já depois de ter submetido o LOG ao sistema de gestão (através da acção no botão Finish e posterior confirmação na tick-box “I Agree”). Esta percepção acontece normalmente quando um dos caçadores reclama do erro ou se o activador fizer uma verificação posterior. A imagem abaixo ilustra um situação de erro identificado na consulta do LOG relativo a uma activação.

Gafe 2

Esta situação pode ser resolvida de duas maneiras diferentes, dependendo do tamanho do LOG (número de contactos registados). A solução mais radical passa pela eliminação do LOG e criação de um novo; voltando a inserir todos os contactos, um a um.

A outra solução consiste nos seguintes passos (implica ter feito o login no sistema):

  1. Ir à pagina Activator Log e na linha corresponde à activação cujo LOG contém erro(s), clicar no botão “Download” e gravar no computador o ficheiro CSV oferecido pelo site. SOTA_4
  2. Editar este ficheiro com uma aplicação tipo OpenOffice Calc, Microsft Excel ou outro processador de folhas de cálculo (não esquecendo de gravar o ficheiro alterado no mesmo formato CSV).SOTA_5
  3. Na página Activator Log, apagar o LOG clicando na ligação “Delete”. SOTA_6Na página que aparece em seguida, confirmar o apagamento, clicando no botão “Delete”. SOTA_7
  4. Na página de entrada do sotadata, ir ao menu Submit Log e ecolher o ítem Import Activator TSV/CSV. SOTA_8
  5. Clicando no botão “Browse…”, seleccionar o ficheiro CSV que foi editado anteriormente (isto é, em que foram efectuadas as correcções de erro). Em seguida, clicar no botão “Upload File”. SOTA_9
  6. Se o LOG estiver correcto, clicar no botão “Submit Entry”. SOTA_10
  7. Confirmar a inserção do LOG no sistema para validação. SOTA_11
  8. O LOG já está inserido no sistema, os pontos foram contabilizados, o problema está resolvido. SOTA_12

O SOTA só termina quando o LOG está contabilizado no sistema de gestão de activações da sotadata. Até este ponto, com o caro adepto desta saga(*) deve ter reparado, muita coisa pode correr mal num SOTA…

73 de CT7AFR, Emmanuel.

(*) Se ainda não leu, leia os restantes episódios da série “O que pode correr mal num SOTA“.

ADB_Toolbar v1.0

Publicado em , por Emmanuel

Barra de Ferramentas AIRLOMBA para Mozilla Firefox.
Para maior comodidade e rapidez na busca de informações acerca de alguma aeronave, ou para aceder rapidamente aos radares virtuais disponíveis na Internet ou ainda para aceder facilemente aos serviços disponibilizados neste site, foi criada uma Barra de Ferramentas para o navegador Firefox.

Visite a página desta aplicação aqui e comece logo a usufruir da ferramenta!

Auto Snapshot uploader v2.2 disponível!

Publicado em , por Emmanuel

O programa Auto SBS Snapshot Uploader foi actualizado!

Desde há uns tempos para cá, o screenshot “radar” da TMA do Porto aparecia volta e meia, com uma janela de erro relacionado com este programa. Hoje, este erro que ocorria quando havia falha de ligação à Internet, foi (esperamos) corrigido! Aconselha-se a quem utiliza este software o download da versão mais recente (2.2) que já está disponível nesta página.

gps2kml, agora suporta ficheiros IGC

Publicado em , por Emmanuel

O programa gps2kml (“gps to kml”) foi actualizado e passa a aceitar ficheiros de logger de voo no formato IGC.

Este programa permite converter os ficheiros de registo de voo em formato NMEA ou IGC, em ficheiros no formato KMZ. Os ficheiros KMZ, uma vez abertos com o Google-Earth permitem-lhe observar em em 2D ou 3D o percurso realizado durante o voo. Para aceder à página deste programa, clique aqui, ou dirija-se à página “Covnersor GPS2KML” na secção PROJECTOS deste site.

GPS2KML v0.1 – Conversor de NMEA para Google-Earth

Publicado em , por Emmanuel

Apesar de o AIRLOMBA.NET não ser uma softwarehouse, acontece que a equipa deste site, volta e meia, desenvolve algumas aplicações informáticas para atingir certos fins. Foi o que aconteceu ontem! A fim de poder ver no Google-Earth os trajectos efectuados em planador e gravados em texto com recurso a um GPS, desenvolveu-se a aplicação “GPS2KML” (gps-to-kml).
Trata-se de um conversor de dados de gps no formato NMEA para um ficheiro KML que pode ser aberto pelo Google-Earth. Este programa está agora à disposição de quem o quiser, gratuitamente! Para fazer a descarga do ficheiro de instalação, visite a página deste trabalho em PROJECTOS – Conversor GPS2KML. Ou vá directamente clicando aqui.