Lançar uma aplicação após o boot, no Linux Debian 11 (bullseye)

Imaginemos um script escrito em Python, chamado o_meu_script.py e guardado na pasta /home/utilizador/scripts.
Imaginemos agora que pretendemos que este script seja lançado automaticamente, após o arranque do computador (Linux Debian 11). Para tal, pode-se recorrer ao gestor de serviços ‘systemd‘ da seguinte forma (no Terminal):

Ir para a pasta onde se encontra o ficheiro ‘o_meu_programa.py’:
utilizador@hostname:~$ cd scripts

Tornar o ficheiro executável:
utilizador@hostname:~/scripts$ chmod +x o_meu_programa.py

Criar um ficheiro de serviço para o gestor ‘systemd’, com o mesmo nome que o do script, usado um editor de texto (e.g., ‘nano’ ou ‘vim’):
utilizador@hostname:~/scripts$ sudo nano /etc/systemd/system/o_meu_programa.service

Inserir o código abaixo, alterando os parâmetros necessários, de acordo com a sua realidade.

[unit]
Description=Descrição do meu script

[Service]
ExecStart=/usr/bin/python3 /home/utilizador/scripts/o_meu_programa.py
WorkingDirectory=/home/utilizador/scripts
Restart=always
User=utilizador

[Install]
WantedBy=multi-user.target

Após guardar o ficheiro de serviço, carregar o novo ficheiro de serviço, no gestor de serviços ‘systemd’:
utilizador@hostname:~/scripts$ sudo systemctl daemon-reload

Permitir que o ficheiro de serviço seja executado após o boot do computador:
utilizador@hostname:~/scripts$ sudo systemctl enable o_meu_programa.service

Lançar o serviço:
utilizador@hostname:~/scripts$ sudo systemctl start o_meu_programa.service

Verificar que o serviço foi lançado e encontra-se a correr normalmente:
utilizador@hostname:~/scripts$ sudo systemctl status o_meu_programa.service

Et voilà le travail! 🙂

Visita à exposição MOTION no Guggenheim de Bilbao

Esta foi a segunda passagem pelo Guggenheim de Bilbao; a primeira tinha sido em 2005… Desta vez, na viagem de regresso de um mini Tour de France, visitamos o museu que exibe até meados de Setembro de 2022 uma exposição acerca de automobilismo com peças raras, clássicas, históricas, futuristas ou apenas de conceito.

As imagens que falem por si. Todas foram captadas com um telemóvel e não sofreram pós-produção além de um resize automático.

Estas imagens ilustram apenas parte da exposição temporária (principalmente, os diversos veículos expostos). Fica de fora desta “reportagem”, a exposição permanente deste Museu que bem merece uma visita, quer por dentro, quer por fora…

Museu Guggenheim de Bilbao (entrada)
Museu Guggenheim de Bilbao (lobby)
Atelier de prototipagem com argila
Benz patent motor car (1886)
Elektrischer Phaeton [Porsche] (1900) e Ford T Tourer (1914)
Rolls Royce 40/50 Alpine Eagle (1914)
 
Bugatti Type 35 (1924)
Tatra T87 (1948) e Chrysler Airflow (1934)
Willys MB (1945)
Ford Mustang Project 50 (1965) e Cadillac Eldorado Biarritz (1959)
Ford Person Brothers Coupe (1934) e Cadillac Eldorado Biarritz (1959)
Firebird III (1958) e Firebird II (1956)
 
Firebird II (1956)
Firebird II (1956) e Firebird I (1954)
Lancia Stratos Zero (1970)
Lancia Stratos Zero (1970)
Mercedes-AMG F1 W11 EQ Performance (2020)
Alfa Romeo Bat 7 (1954)
Firebird I (1954)
Dimaxion Car 4 (2010)
Citroën DS (1971)
Ferrari 250 GTO (1962)
Mercedes-Benz 300 SL Coupe (1955)
Jaguar E-Type (1963)
Aston Martin DB5 James Bond (1964)
Renault 4 (1968) e VW Type 2 Microbus Deluxe “Samba” (1962)
VW Type 2 Microbus Deluxe “Samba” (1962) e Renault 4 (1968)
Volkswagen Type 1 “Beetle” (1951) e Citroën 2CV Sahara (1961)
Delahaye Type 165 (1939)
Bugatti Type 57SC Atlantic (1936)
Pegaso Z-102 Cópula (1952) e Bentley R-Type Continental (1953)
Pavilhão FUTURE, exposição de conceitos de mobilidade por diversas universidades e institutos politécnicos do mundo.
Ethos (Mondragon Unibertsitatea – Goi Eskola Politeknikoa)
Autofficina Futuro – Politecnico di Milano
 
Pavilhão FUTURE
Pavilhão FUTURE
University of Cape Town Mobility Concept

 

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

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

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.

Converter um número Real para o formato binário em vírgula flutuante segundo a Norma IEEE-754

Já são tantas as vezes que expliquei o processo de conversão de um número qualquer para o formato binário em vírgula flutuante de acordo com a Norma IEEE-754 que desta vez, apeteceu-me escrever sobre isto. 🙂 Quem não quiser ler o que segue e preferir saltar para a versão condensada, clique aqui.

Entre outras coisas, a Norma IEEE-754 especifica dois níveis de precisão: simples e dupla. O primeiro nível ocupa 32 bits, o segundo, 64 bits. Para quem programa em linguagem C, o primeiro nível de precisão corresponde a uma variável do tipo float, o segundo, a uma variável do tipo double.

Atente à distribuição dos bits, de acordo com o nível de precisão do formato:

Tomemos por exemplo o número 94.0254, para o converter para um número em vírgula flutuante com precisão simples (32-bits) de acordo com a Norma IEEE-754. Este número é composto por duas partes: uma inteira (94) e uma fraccionária (0.0254).

1) Comecemos por converter para binário a parte inteira. Não vou entrar nos detalhes da conversão de um número entre os formatos Decimal e Binário. Há muita literatura sobre este assunto e muitos conversores automáticos online…

Portanto, a parte inteira fica: 1011110

2) Em seguida, converte-se a parte fraccionária. Mais uma vez, abstenho-me de entrar nos detalhes deste tipo de conversão. Creio que tal como a imagem anterior, a imagem abaixo é self-explanatory.

Portanto, o número Real convertido para binário fica:

3) O passo seguinte consiste na normalização do número convertido para o formato 1.xxxxxx… Isto é, operar o número original por forma a que a parte inteira fique “reduzida” a uma unidade. Para tal, usa-se a operação SHIFT LOGICAL RIGHT, ou simplesmente, divide-se por 2 e multiplica-se por 2, tantas vezes quantas as necessárias:

A última linha do processo acima, apresenta o número 94.0254, convertido para um número binário normalizado, multiplicado por 2^6, para satisfazer um dos requisitos da Norma IEEE-754. A parte em fundo cor de rosa, corresponde à parte fraccionária que aparecerá na trama final de 32 bits. São apenas 23 bits (os que cabem na precisão simples). Os restantes bits ficam truncados, originando um erro na representação do número original.

4) O 6 a fundo amarelo do passo anterior será adicionado a um BIAS, definido pela Norma IEEE-754, de acordo com o nível de precisão pretendido:

float (32 bits): BIAS = 127 (expoente de 8 bits)
double (64 bits): BIAS = 1023 (expoente de 11 bits)

O resultado desta soma corresponde ao valor da parte correspondente ao EXPOENTE do número em vírgula flutuante. Este expoente fica então (a fundo verde):

5) Por fim, o bit mais significativo da trama de 32 bits (64, no caso da precisão dupla), corresponde ao bit de Sinal. Este bit é igual a 1 se o valor original for negativo. Neste exemplo, este bit (a fundo azul na representação abaixo) fica igual a Zero.

6) Juntanto as parcelas todas, obtém-se a representação de 94.0254 no formato vírgula flutuante com precisão simples de acordo com a Norma IEEE-754:

————————

Resumidamente:

VirtualBox sobre Debian 10 (buster) não encontra dispositivos USB

Linux sobre Uindouze sobre Linux

Sou adepto do Linux desde os tempos do Red Hat 7.1… Mais tarde, adoptei o Debian e nunca mais quis outra coisa. Despedi-me definitivamente do Uindouze na versão 8.1 (e já era tarde quando a Mocosoft abandonou o suporte ao XP).

Coisas da vida profissional, para ensinar a usar GCC a uma turma de adeptos do Uindouze, tive de escrever um pequeno Guia Prático de instalação do Cygwin. Para redigir este Guia com conhecimento de causa, precisei de recorrer ao Uindouze. E para evitar conspurcar o meu querido PC com tal “sistema operativo” (cof cof…), instalei a versão 10 desta coisa, numa máquina virtual, criada para o efeito, recorrendo ao Oracle VirtualBox.

Correu tudo bem (até a instalação do Uindouze), mas quando precisei de ler uns ficheiros de uma pendrive USB, esta não aparecia no Uindouze… Não aparecia porque o Debian não deixava o VirtualBox aceder à referida pen. Mesmo depois de ter instalado o VirtualBox Extension Pack e activado o Controlador USB (neste caso, o controlador USB 2.0 OHCI+EHCI). Sem este Extension Pack, o VirtualBox apenas vê os portos USB como sendo USB 1.1 (OHCI).

Para resolver tal problema, foi necessário adicionar o utilizador ao grupo vboxusers. Para tal e como SuperUser (root):

$ usermod -aG vboxusers emmanuel

Obviamente, no comando acima, substitua-se ‘emmanuel’ pelo nome do utilizador que pretende usar o VirtualBox e aceder aos portos USB.

Finalmente, foi necessário reiniciar o computador para que as alterações produzissem efeito. Bem ao jeito do Uindouze, quem diria? 🙂

Falta de som no Morse Runner em Linux?

Morse Runner é uma excelente aplicação freeware para o treino de escuta/descodificação de telegrafia/CW. É da autoria do colega radioamador Alex Shovkoplyas (VE3NEA) e está disponível para download em http://www.dxatlas.com/MorseRunner/.

Esta aplicação foi desenvolvida para “Uindouze”… No entanto, é possível executá-la em Linux, recorrendo ao emulador Wine (WineHQ). Ainda assim, quem quiser, poderá portar o código fonte desta aplicação para Linux, já que o mesmo está disponível no GitHub.

Lançar o Morse Runner em Linux, com recurso ao Wine, pode levantar um problema (foi o que me aconteceu e não fui o único): o Morse Runner não tem ou fica sem som… Acontece que o som do Wine é “pescado” no pulseaudio que costuma ser a opção de “default” do Wine, quando este é instalado.

O objectivo deste artigo é alterar a confuração do Wine, para que em vez de usar o pulseaudio, passe a usar o Alsa. Para tal, comece por abrir uma janela do Terminal e execute o comando winetricks.

$ winetricks

Em seguida, siga os passos, tal como aparecem nas imagens abaixo:

Depois de clicar em OK na janela ilustrada na imagem acima, sair do winetricks, lançar o Morse Runner e começar a treinar! 🙂

Antes de fechar este artigo, fica a referência de que o conteúdo deste artigo foi baseado no Linux Debian 10 (buster) com o wine-4.0 (Debian 4.0-2) e o Morse Runner 1.67.

73 de CT7AFR.

Touchpad tapping, em Debian Buster (10)

HP Folio 9470m

O portátil é um velhinho HP EliteBook Folio 9470m, recondicionado mas 100% operacional e eficiente. Um dia, ao substituir a versão 9 do Debian pela versão 10, o touchpad deixou de reconhecer os cliques através de tapping (ou double-tapping). Uma busca na Internet, rapidamente retornou a informação necessária para reactivar esta útil funcionalidade.

Curiosamente, descobri na ‘net, muitos relatos que afirmam que o driver libinput funciona melhor que o da Synaptics. Não me dei ao trabalho de fazer um benchmark para confirmar; tinha alguma urgência em repor o touchpad a funcionar como deve ser, para quando não me dá jeito usar um rato externo (e.g. durante viagens).

Assez parlé! Ao trabalho!

Primeiro, deve-se assegurar que o driver da Synaptics (xserver-xorg-input-synaptics) já não se encontra no sistema. Para o remover (através do Terminal):

$ apt remove xserver-xorg-input-synaptics

Instalar (se já não está instalado) o driver libinput:

$ apt install xserver-xorg-input-libput

Criar o directório xorg.conf.d em /etc/X11

$ mkdir /etc/X11/xorg.conf.d

Criar o ficheiro 40-libinput.conf no directório recém criado:

$ nano /etc/X11/xorg.conf.d/40-libinput.conf

Neste ficheiro, inserir o seguinte script:

Section “InputClass”
Identifier “libinput touchpad catchall”
MatchIsTouchpad “on”
MatchDevicePath “/dev/input/event*”
Driver “libinput”
Option “Tapping” “on”
EndSection

CTRL+X e Yes para gravar e sair do editor de texto

O último passo: Reiniciar o Display Manager (no meu caso, o lightdm):

$ systemctl restart lightdm

Et voilà!

Acender um LED com a tensão da rede eléctrica

Por diversos motivos, é útil saber se um determinado dispositivo está sob tensão. Por exemplo, um aparelho, apesar de estar desligado (OFF), pode estar conectado à rede eléctrica (230V-50Hz). Para este efeito informativo, muitos aparelhos têm um indicador luminoso (LED ou de outro tipo) que testemunha a presença da tensão da rede eléctrica no seu interior.

O circuito apresentado neste artigo, permite acender um LED com a tensão monofásica da rede eléctrica (230V – 50Hz). Pode então por exemplo, instalar este circuito num qualquer aparelho que funcione a 230V ou ainda instalá-lo num quadro eléctrico para indicar a presença de cada Fase, etc.

AVISO: Este artigo tem fins meramente informativos. Se não tem formação e experiência na montagem e manuseamento de circuitos eléctricos com tensão da rede eléctrica, procure ajuda de um técnico ou electricista qualificados. O autor deste artigo não se responsabiliza por quaisquer danos materiais ou fisiológicos que possam advir da consulta e implementação do conteúdo deste artigo. A sua utilização de qualquer informação ou materiais publicados neste artigo é da sua total responsabilidade. Se não concorda com o conteúdo deste aviso, queira abandonar este sítio.

O Esquema

Princípio de funcionamento

É possível simplificar este esquema, retirando dele o condensador. Funcionalmente, o resultado seria o mesmo; i.e., o LED acenderia sempre que se aplicassem 230V entre os terminais J1 e J2, desde que a resistência R1 tenha sido dimensionada apropriadamente. Porém, esta resistência seria demasiado “grande” pela potência que teria de dissipar como se pode verificar pelas operações seguintes:

UREDE = 230 V
ULED = 1,6 V
ILED = 20 mA (0,02 A) – Valor máximo, para um LED comum.

R1 = (UREDE – ULED) / ILED = (230 – 1,6) / 0,02 = 11420 Ω -> 12000 Ω (12 kΩ)

Com R1 = 12 kΩ, a corrente no LED passa a ser:

ILED = (UREDE – ULED) / R1 = (230 – 1,6) / 12000 = 0,019 A (19 mA)

A potência que a resistência terá de dissipar, pelo papel abaixador de tensão e limitador de corrente para o LED é calculada pela expressão:

PR = R1 x I2 = 12000 x 0,0192 = 4,33 W (Temos um aquecedor!)

Para evitar o uso de uma resistência “de aquecimento”, e baixar a tensão da rede para a necessária para o LED, recorre-se então ao uso de um circuito RC série. Esta técnica é frequentemente usada em fontes de alimentação sem transformador. Mas atenção!!! Esta técnica só funciona correctamente para cargas com corrente constante, pois a queda de tensão no par RC varia com a corrente solicitada pela carga.

Dimensionamento dos componentes

No dimensionamento de um “transformador de tensão” sem Transformador (máquina electromagnética), procura-se minimizar as perdas por Efeito de Joule (calor) na resistência, passando para o condensador a tarefa de baixar a tensão, já que este não sofre (tanto) de Efeito de Joule. Isto é possível porque o condensador, em corrente alternada adquire uma Impedância que tem o mesmo “efeito voltaico” que a resistência.

A resistência tem no entanto, de permanecer no circuito para limitar a corrente neste (circuito série).

Para proteger o LED contra eventuais flutuações da tensão da rede, limita-se a 15 mA, a corrente no mesmo, o que para um LED vulgar, permite um brilho muito bom. Assim,

UREDE = 230 V
fREDE = 50 Hz
ULED = 1,6 V
ILED = 15 mA (0,015 A)

Z = (UREDE – ULED) / ILED = (230 – 1,6) / 0,015 = 15227 Ω

Z = √ (R12 + XC12)

A questão agora consiste em arbitrar valores aos componentes R1 e C1 por forma a obter uma impedância total Z com cerca de 15,2 kΩ.

Se se utilizar uma resistência comum de 0,25 W e se limitar a potência desta a 0,2 W (por aplicação de um factor de cagaço), deduz-se o valor da resistência para uma corrente de 15 mA da seguinte forma:

R1 = P / ILED2 = 0,2 / 0,0152 = 889 Ω

Sabendo que a potência dissipada na resistência aumenta com o valor desta, reduz-se o valor obtido acima para o valor normalizado imediatamente abaixo (Série E12), isto é 820 Ω!

Conhecendo os valores de R1 e de Z, calcula-se o valor da impedância do condensador C1:

XC1 = √ (Z2 – R2) = √ (152272 – 8202) = 15205 Ω

Sabendo que XC1 = 1 / (2 . Π . fREDE . C1), obtém-se o valor da capacidade do condensador C1:

C1 = 1 / (2 . Pi . fREDE . XC1) = 1 / (2. Pi . 50 . 15205) = 209.10-9 = 209 nF

Sabendo que a impedância de um condensador diminui com o aumento da sua capacidade, ajusta-se o o valor obtido para um valor normalizado imediatamente abaixo (180nF). No entanto, é interessante verificar os valores teóricos das grandezas envolvidas no circuito, também para o valor imediatamente acima dos 209 nF (220nF). A tabela abaixo apresenta os resultados das grandezas relevantes no circuito para as diferentes combinações R1-C1.

Comparando as soluções 2 e 4 da tabela acima, verifica-se que para uma corrente aproximadamente igual (mesmo brilho do LED), a potência dissipada na resistência da solução 4 atinge valores próximos do limite nominal do modelo previamente escolhido (1/4W).

Optando-se pela solução 2, o esquema do circuito fica:

Cuidados adicionais

Conforme o esquema tratado aqui, existe ainda neste circuito um díodo (D1) de tipo 1N4007. Este díodo tem por função, proteger o LED durante a arcada negativa da tensão da rede eléctrica. De facto, sem este díodo, durante a arcada negativa, o LED ficaria submetido a uma tensão máxima de 230 . √ 2 = 325 V!!! Os LEDs não suportam este valor de tensão inversa. Uma forma de proteger o LED deste valor de tensão, consiste em ligar em anti-paralelo, um outro díodo (poderia ser um outro LED mas, para quê dois LEDs?). Assim, durante a arcada negativa da tensão da rede, o LED fica submetido a uma tensão inversa igual ao valor da tensão directa do díodo D1: cerca de 0,7 V.

Pelo que se conta no parágrafo anterior, deduz-se que o LED está aceso apenas durante a arcada positiva da tensão da rede. De facto, o LED só está aceso durante metade do período da tensão da rede; isto é, durante 10 ms (f=50 Hz).

Um outro pormenor a ter em atenção é a tensão de serviço do condensador C1. Se se tiver em consideração o momento em que a tensão da rede passa pelo seu valor máximo (cerca de 325 V), o condensador fica submetido a uma tensão de:

UC1 = UMAX – UR1 – ULED = 325 – (R1 . ILED) – 1,6 = 325 – 820 . 15,8.10-3 – 1,6 = 310 V

Como tal, o condensador deverá ter uma tensão de serviço superior a este valor; por exemplo: 400V.

Finalmente, aconselha-se (vivamente) a colocação de uma resistência de alto valor (e.g., 1MΩ), em paralelo com o condensador. Esta resistência descarregará o condensador quando o circuito não estiver a ser alimentado.

Lista de componentes

R1: 820 Ω – 1/4 W
C1: 220 nF – 400 V
D1: 1N4001
D2: LED standard

Não faz parte do âmbito deste artigo apresentar soluções de montagem deste circuito. Recomenda-se o máximo cuidado e respeito pelas regras de segurança na montagem, instalação e utilização deste circuito. Se tiver dúvidas acerca do que está a fazer, procure ajuda especializada! A sua vida, a de outras pessoas, de animais ou de bens, depende da atitude que tiver daqui em diante.

Implementação experimental

A imagem acima ilustra uma implementação tipo “Live” do circuito. Esta implementação foi usada para verificar experimentalmente a funcionalidade do circuito e efectuar diversas medições. Uma integração deste circuito numa qualquer aplicação final, carece de protecção física contra contactos acidentais; isto é, isolamento adequado dos componentes e de todos os condutores.