Como atribuir nomes a devices HidRaw (parte 3)

Este artigo conclui o tema sobre a atribuição de nomes a devices, referidos na parte 1 e parte 2, quando os fabricantes não atribuiem um número de série e 2 ou mais dispositivos parecem-nos iguais e impossíveis de identificar…
Os dispositivos HidRaw permitem aceder a interfaces USB e bluetooth sem alteração de dados ou protocolo. Significa em inglês original - Raw Access to USB and Bluetooth Human Interface Devices.

Por vezes os nossos projectos necessitam de chamar estes devices para comunicarem… dou como exemplo a utilização do controlo de PTT pelas placas de som CM108 e CM119, descrito no artigo packet/APRS iGate, BBS, node e DX cluster com Raspberry Pi (parte 2), onde o direwolf usa o pino 13 do GPIO para pôr o rádio em transmissão, através do comando "PTT CM108 3 /dev/hidraw3".

Como consegue imaginar, ao reiniciar o sistema operativo, estes devices mudam a ordem à medida que o kernel as lê e lhes atribui um número… este é o problema que aqui resolvo, a atribuição de um nome ou symlink a um device hidraw para que, independentemente da ordem atribuída pelo kernel, saibamos sempre como comunicar com ele!
Note, este procedimento só é válido (à semelhança dos procedimentos descritos nos artigos anteriores) se e só se o nosso device USB se encontrar sempre ligado à mesma porta USB, seja directamente à board ou através de um HUB USB!

Identificar o device

Antes de ligar o seu dispositivo USB, execute o comando,

e obtém, por exemplo

crw------- 1 root root 243, 3 Mar 14 22:44 /dev/hidraw0
crw------- 1 root root 243, 4 Mar 15 09:25 /dev/hidraw1
crw-rw---- 1 root audio 243, 5 Mar 14 22:44 /dev/hidraw2

Agora ligue o seu dispositivo e execute o comando novamente… apareceu um novo device. Este é o nosso device, aquele que vamos configurar,

crw------- 1 root root 243, 3 Mar 14 22:44 /dev/hidraw0
crw------- 1 root root 243, 4 Mar 15 09:25 /dev/hidraw1
crw-rw---- 1 root audio 243, 5 Mar 14 22:44 /dev/hidraw2
crw-rw---- 1 root audio 243, 5 Mar 14 22:44 /dev/hidraw3

Agora que sabemos que ao nosso device lhe foi atribuido o número 3, como /dev/hidraw3, fazemos

de modo a obtermos toda a informação deste device,

De onde retiramos algumas das variáveis que nos permitem agora identificar o nosso dispositivo, uma vez mais, sempre que este se encontre ligado à mesma porta USB.

Criar o nome ou symlink

Escrevemos ACTION=="add", pois só queremos adicionar este dispositivo quando ele é ligado.
Apenas queremos identificar dispositivos hidraw, então escrevemos SUBSYSTEM=="hidraw", ver linha 9.
Se tiver vários dispositivos iguais repare na linha 32 que identifica pelo kernel a porta USB a que este dispositivo está ligado como, KERNELS=="1-1.2.1.1"
Comum aos nossos vários dispositivos, se existirem 2 ou mais, é o id do fabricante e o id do producto, respectivamente verificados nas linhas 38, ATTRS{idVendor}=="0d8c" e 57, ATTRS{idProduct}=="0012"
Agora é só atribuir-lhe um nome alternativo, com a instrução SYMLINK+="", que no meu caso se trata de uma placa de som CM108 que pretendo, como disse, controlar o PTT através do GPIO…

Construímos a linha a colocar no nosso ficheiro udev rules descrito nos artigos anteriores em /etc/udev/rules.d/99-hamlib.rules, na continuação das instruções que já escrevi…

Na janela terminal escreva, como sudo ou root,

Avance até à última linha, substitua as variáveis ao seu dispositivo e escreva, neste meu exemplo, e para cada uma das suas placas de som onde pretende controlar o PTT,

ACTION=="add", SUBSYSTEM=="hidraw", KERNELS=="1-1.2.1.1", ATTRS{idVendor}=="0d8c", ATTRS{idProduct}=="0012", SYMLINK+="hidHFpacket"

Cada vez que escreve no ficheiro rules aplique as configurações, com sudo ou root, o comando,

Agora, no direwolf o comando passará a ser,

PTT CM108 3 /dev/hidHFpacket

O nosso dispositivo é agora reconhecido pelo nome "hidHFpacket". Verifique, escrevendo no terminal,

crw------- 1 root root 243, 3 Mar 14 22:44 /dev/hidraw0
crw------- 1 root root 243, 4 Mar 15 09:25 /dev/hidraw1
crw-rw---- 1 root audio 243, 5 Mar 14 22:44 /dev/hidraw2
crw-rw---- 1 root audio 243, 5 Mar 14 22:44 /dev/hidraw3
lrwxrwxrwx 1 root root       7 Mar 14 22:44 /dev/hidHFpacket -> hidraw3

Quer ver agora todos os symlinks criados nestes artigos? Substitua as palavras de acordo com o nome que atribuiu e escreva,

Referências:
https://docs.kernel.org/hid/hidraw.html
https://github.com/nasa/IDF/wiki/Differentiating-Identical-Devices
http://reactivated.net/writing_udev_rules.html
https://github.com/nasa/IDF/wiki/Device-Permissions

Como atribuir nomes a placas de som em linux (parte 2)

No post anterior tratámos da atribuição de nomes a devices série ttyUSB para identificar a ligação a rádios ou portas série.
Neste post vamos atribuir nomes a devices de audio, muito útil quando queremos configurar devices de som e nos aparecem listas de 30 e mais periféricos de som a configurar no software, por exemplo, para modos digitais como JS8Call, FT8, SSTV, ou direwolf em AX.25 e tudo nos parece uma confusão…

Confusão maior porque de cada vez que reiniciamos o computador ou o raspberry pi estes devices de som arrancam por ordem aleatória!

O método descrito tem uma condição - os devices de som USB têm de estar ligados sempre na mesma porta USB, seja directamente ou através de um HUB USB, isto se utilizarmos devices com o mesmo idVendor, idProduct e número de série.

Pode parecer estranho o porquê deste artigo! Mas neste projecto eu tenho a saída de audio do raspberry para os auscultadores, a saída do monitor, os 2 rádios Icom, um FT-817, e 5 placas de som alsa para AX.25 através do modem por software direwolf ligadas cada uma a seu rádio! De cada vez que reinicio o raspberry é uma trapalhada acertar todos os devices pela ordem com que foram configurados inicialmente! Já faz sentido?

Em linux existem diferentes camadas para a utilização de som: alsa e pulse audio. Há software que utiliza alsa outros que utilizam pulse audio…
Este é um artigo prático, consulte as referências bibliográfica para compreender a teoria por detrás dos devices de som em linux.

Atribuir nomes aos devices Alsa e Pulse Audio

Aqui o objectivo é, conhecer a identificação de cada um dos devices de som dos nossos Icom ou outro equipamento, adicioná-los ao ficheiro anterior /etc/udev/rules.d/99-hamlib.rules com um nome ou symlink que o designará mais facilmente…

Ligue à vez, a ficha USB do IC-7300, siga o procedimento abaixo descrito, desligue esta ficha e ligue agora a USB do IC-9700…

Para saber o id do device de som abra uma janela terminal e escreva,

ou, sem querer causar mais ruído, pode também conhecer o id de cada periférico fazendo, "udevadm monitor --subsystem=sound", desligando e voltando a ligar cada uma das fichas USB…

Bom, o primeiro comando devolverá uma série de linhas, das quais apenas nos interessa identificar algo semelhante a,

(para o IC-7300)
name: <alsa_input.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo>
sysfs.path = "/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2.3/1-1.2.3.4/1-1.2.3.4:1.0/sound/card2"

(para o IC-9700)
name: <alsa_input.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo.2>
sysfs.path = "/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2.2/1-1.2.2.4/1-1.2.2.4:1.0/sound/card3"

Agora, no output gerado para o IC-7300, pegamos apenas na expressão,
"/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2.3/1-1.2.3.4/1-1.2.3.4:1.0/sound/card"

e construímos o código a escrever no ficheiro 99-hamlib.rules
Note que, este é o resultado do meu exemplo… deverá substituir esta expressão de acordo com o resultado que obteve! Estes valores identificam a porta USB a que o device se encontra ligado e o próprio device.

Na janela terminal escreva como sudo ou root,

e, a seguir às regras da primeira parte do artigo, relativas aos devices ttyUSB adapte e copie o seguinte código,

# ALSA devices
# IC-7300 Sound Card
SUBSYSTEM!="sound", GOTO="ic7300_alsa_naming_end"
ACTION!="add", GOTO="ic7300_alsa_naming_end"
DEVPATH=="/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2.3/1-1.2.3.4/1-1.2.3.4:1.0/sound/card?", ATTR{id}="IC-7300"
LABEL="ic7300_alsa_naming_end"

# IC-9700 Sound Card
SUBSYSTEM!="sound", GOTO="ic9700_alsa_naming_end"
ACTION!="add", GOTO="ic9700_alsa_naming_end"
DEVPATH=="/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2.2/1-1.2.2.4/1-1.2.2.4:1.0/sound/card?", ATTR{id}="IC-9700"
LABEL="ic9700_alsa_naming_end"

# PulseAudio devices
# IC-7300  pulseaudio device
SUBSYSTEM!="sound", GOTO="ic7300_pa_naming_end"
ACTION!="change", GOTO="ic7300_pa_naming_end"
KERNEL!="card*", GOTO="ic7300_pa_naming_end"
DEVPATH=="/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2.3/1-1.2.3.4/1-1.2.3.4:1.0/sound/card?", ENV{SOUND_DESCRIPTION}="IC-7300"
LABEL="ic7300_pa_naming_end"

# IC-9700 pulseaudio device
SUBSYSTEM!="sound", GOTO="ic9700_pa_naming_end"
ACTION!="change", GOTO="ic9700_pa_naming_end"
KERNEL!="card*", GOTO="ic9700_pa_naming_end"
DEVPATH=="/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2.2/1-1.2.2.4/1-1.2.2.4:1.0/sound/card?", ENV{SOUND_DESCRIPTION}="IC-9700"
LABEL="ic9700_pa_naming_end"

Não se esqueça de ligar as fichas dos rádios sempre nos mesmos portos de ligação USB! Caso contrário este procedimento não servirá para nada!

Placas de som Alsa ligadas ao direwolf

Se for também o seu caso, proceda como anteriormente descrito, e ao meu ficheiro 99-hamlib.rules acrescentei ainda,

# CM108 ALSA devices for direwolf
# DEVPATH can be obtained by looking at `udevadm monitor --subsystem=sound` while pluging in the sound card.
# Do one card at a time, the "?" char on card should stay as it matches any card number that may pop on that USB port.
SUBSYSTEM!="sound", GOTO="alsa_naming_end"
ACTION!="add", GOTO="alsa_naming_end"
DEVPATH=="/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2.4/1-1.2.4.1/1-1.2.4.1:1.0/sound/card?", ATTR{id}="UHFpacket"
DEVPATH=="/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2.4/1-1.2.4.2/1-1.2.4.2:1.0/sound/card?", ATTR{id}="VHFpacket"
DEVPATH=="/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2.4/1-1.2.4.3/1-1.2.4.3:1.0/sound/card?", ATTR{id}="VHFpacketSat"
DEVPATH=="/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2.1/1-1.2.1.1/1-1.2.1.1:1.0/sound/card?", ATTR{id}="HFpacket"
LABEL="alsa_naming_end"

Desligue e volte a ligar estas placas de som e escreva no terminal, substituindo nomes ou wildcards... exemplo,

Artigo relacionado - Solução de problemas com a placa de som CM108

Outros comando utilizados para melhor compreender este projecto

Continua...

Referências:
https://x8x.net/2019/04/04/icom-ic-9700-and-ic-7300-coexisting-in-linux/
https://gist.github.com/Aishou/f39c2f970c6db20e1845925c5cc0890e
https://www.florian-wolters.de/posts/static-sound-device-names-ic9700-ic7300/
https://blog.habets.se/2021/12/Linux-Sound-devices-are-a-mess.html

pi-star +GUI, packet e aplicações desktop

Este bem poderia ser o primeiro post do site já que, daqui fui construindo todos os outros projectos...

Há uns meses atrás comecei este projecto. Sempre fui adepto de "all in one", nas impressoras, nos rádios, nos gadgets, até nos canivetes suíços! Compreendo quem prefira um rádio para HF, outro para VHF e UHF, mas eu gosto deles com tudo!
Este projecto é para os que gostam de "tudo na mesma caixa"!

Há uns meses, nem sabia o que era um Raspberry Pi até que me rendi... comprei um zero com wireless, experimentei o 3B + e depois comprei um 4. Foi com o mesmo entusiasmo com que recebi o meu ZX81 ou o Spectrum em 1982, mas com tecnologia mais recente e capaz de um projecto deste tipo!
- Era o computador que faltava na minha estação de rádio! Sem ventoinhas, logo sem barulho, a 5V ou facilmente alimentado a partir de 12V e, o Raspberry 4 com uma capacidade de processamento suficiente para correr um sem número de aplicações em simultâneo! Estas características maravilharam-me...

Tudo começou quando adquiri o meu rádio D-Star, instalei num Pi zero W o software pi-star, num computador antigo a correr linux, apenas linha de comandos, o linbpq para packet e APRS e depois precisava de outro brincar com modos digitais...
Eram muitos computadores, todos ligados, a consumir energia 24 horas por dia! Não, tinha de haver outra solução.
A solução passava por um computador, todos os sistemas e software a correr ali...
Pretendia ainda uma solução alimentada a 12V, de modo a poder alimenta-lo a baterias e criar sistemas de alimentação redundante.

A solução era mesmo um Raspberry Pi!

Fiz teste num 3B + de um amigo. Percebi que tinha de instalar primeiro o pi-star, a última versão "buster" do debian, disponível para download no site deste excelente projeto.
O pi-star tem uma excelente característica, depois do arranque o sistema entra em modo read-only, e apesar de o podermos pôr em read-write, tudo está feito para que volte a read-only no instante seguinte! Era um quebra cabeças e o primeiro problema a resolver! Todos os posts anteriores foram o caminho a percorrer para chegar até aqui e resumem a minha experiência em Pi.

Se quiser ter os modos digitais, o propósito de ter instalado o core do pi-star, terá de adquirir uma pequena placa de RF, chamada MMDVM hotspot. Encontra-se facilmente no eBay e a minha custou cerca de 15€ mais despesas de envio.

As instruções seguintes mostra como o fazer.

No final deste projecto, com algumas horas e muita paciência, fica com um Raspberry Pi (recomendo o 4, com 2 ou mais Gb de RAM) com,

pi-star, para modos digitais (D-Star, DMR, YSF...)
packet e APRS no linbpq + (Hamlib, Direwolf, Xastir, Linpac)
recepção de WSPR com uma simples RTL-SDR v3
FLRig e FLDigi
WSJT-X
JTDX
GridTracker (Display connections on a map)
JS8CALL
CQRLOG + TQSL (Advanced Ham Radio Logbook)
GPredict (Sat-Tracking)
QSSTV (Slow Scan Televison)
GQRX (SDR)
FreeDV (Digital Voice)
VOACAP (Propagation Prediction)
Chirp (Programming transceivers)
Qtel (Echolink Client)
WSPR with RTL-SDR v3
VNC server para acesso externo (tablet, telefone ou computador)

Que tal? 🙂

Instruções

Não há fórmulas mágicas, os bons projecto levam tempo!
Precisa tempo e paciência, sobre tudo se não tem muita experiência com sistemas operativos linux em linha de comandos. No entanto tentei tanto neste como nos posts anteriores criar instruções para que fosse apenas copiar e colar...
Neste projecto, e porque não sou o autor de tudo, deixo links para outros sites, para os siga e instale tudo pela ordem que sugiro.

Comecemos por instalar o pi-star

Faça o download e siga as instruções para o seu sistema operativo.
A instalação do pi-star não é opcional já que este projecto se baseia nele, que inclui o último sistema operativo "buster" à data em que escrevo este artigo.

Depois vamos instalar o interface gráfico GUI. Sim, vai ter uma consola gráfica, mas toda a instalação corre praticamente em linha de comandos.

Depois de instalado o pi-star, identifique a sua versão. Terá de habilitar o SSH, configurar o acesso à network ou, ligar um monitor, teclado e rato. Abra uma janela terminal, ou aceda por SSH e faça,

...dá-lhe algumas informações sobre a versão, processador e hardware
Para conhecer qual o sistema operativo, pelo nome que conhecemos digite,

PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

ou, digite o comando "lsb_release -a".
Actualize agora o seu sistema já instalado,

O pi-star, foi desenhado com propósito único, e será necessário instalar diversos componentes: software, plugins de terceiros e livrarias de código; de modo a dotá-lo de todo o software para o nosso projecto.

Instale a componente de configuração do Raspberry Pi, que facilitará muito qualquer configuração de rede, hardware, serviços, etc...

Ambiente gráfico de janelas

Agora vamos instalar o X ou interface gráfico GUI. Passo simples. Depois já terá acesso ao sistema pelo interface gráfico de janelas que lhe será mais familiar...

A partir deste momento, pode aceder já por teclado e rato, ligando um monitor à porta HDMI do Pi.
Habilite o VNC, para lhe permitir aceder remotamente, se não pretender como eu, ligar o monitor. Na linha de comandos ainda, faça,

7 Advanced Options
A5 Resolution
…seleccione o modo à sua escolha, no meu caso escolhi uma das configurações 16:9
Faça "Ok", "Ok" de novo, "Finish", "Yes" vamos fazer um reboot…

Agora já se pode ligar por VNC.
Antes de fazer reboot, pode também habilitar o "auto-login" no sistema de janelas. Volte ao "raspi-config" e siga os menus "Boot option"->"Desktop / CLI"->"Desktop autologin".
Algumas instruções que li sugeriram também instalar o xinit. Considere-o para já como opção,

Para conhecer o endereço IP do seu Pi, faça

Identifique a sua ligação de rede, instale o VNC Desktop no seu computador e já pode aceder confortavelmente ao seu Pi, pelo sistema gráfico de janelas.
Note que, a partir do momento que tem acesso ao interface gráfico pode abrir ali uma janela terminal e executar todos os comandos que se seguem...
Eu continuo ligado por SSH.

Porque o pi-star é muito robusto, quase à prova de desligar a alimentação quando e sempre que quiser sem qualquer cuidado em particular, tem também um firewall onde é preciso permitir o acesso externo. Nada complicado. Crie o ficheiro ipv4.fw que será lido pelo sistema e adicione estas regras ao iptables, firewall linux,

Grave, CTRL + x, "yes" e volte à linha de comandos.

Nota: esta lista de regras tem sido actualizada ao longo do projecto embora nem sempre seja referido nos diversos posts. Sempre que uma aplicação ou serviço necessita de comunicar para fora, ou receber dados, temos de abrir a porta respectiva!

Configurei já as portas 5900 e 5901 para acesso por VNC, a 8010 para acesso por telnet ao linbpq, a 9123 o acesso web à consola do linbpq e a 10093 para transferência de mensagens entre nodes, também para o linbpq.
Para aplicar estas regras,

Configurar o pi-star em mode read-write permanente

Descobrir onde o pi-star re-escrevia as instruções de read-write para read-only deu algum trabalho, muitos ficheiros abertos e re-escritos, novas instalações, pesquisas na web, frustração e umas boas horas. Vamos começar.

Temos de substituir todas as instruções que montam o sistema como leitura apenas, para leitura e escrita, isto é de "ro /" por "rw /".
Comecemos pelas regras na montagem das partições,

Igualmente importante, edite o ficheiro /etc/rc.local e comente com "#" a última linha onde aparece a expressão,

ou melhor, não a comente e altere-a para,

na directoria /var/www, fazemos o login como root,

Verificamos quantas entradas existem, com o user root,

Trocamos todos os "ro /" por "rw /". Para evitar erros copie a seguinte expressão como root,

E, verificamos que já não existe nenhum "ro /" por substituir. O output deve ser vazio!

"exit" sai do user root.
Em cada actualização do pi-star bem sucedida devemos correr estes 3 últimos comandos "find..."! É natural que, durante o update surjam mensagens como: "os seguintes ficheiros foram modificados..." Ignore e, volte a fazer os procedimentos descritos anteriormente.

Vamos editar ainda os seguintes ficheiros e substituir todas as entradas de "ro /" por "rw /"

Renomear os seguintes ficheiros, por exemplo para _[ficheiro]

Existem mais alguns ficheiros encontrados em /usr/local/sbin, /usr/sbin e /usr/bin mas não detectei nada que provocasse o sistema a voltar a read-only.

Notas:
1. Ao tentar actualizar agora o pi-star deve aparecer-lhe uma mensagem com esta,

Starting Services…
Done
Updates complete, sleeping for a few seconds before making the disk Read-Only
mount: /: mount point is busy.
Finished

O que é normal visto que o sistema é read-write. Não há problema.

2. Recentemente dei que o meu raspberry entrava em modo "halt" todas as noites à hora que executava o cron.daily
O problema manifestava-se quando corria no script "powersave" a instrução "tvservice -o" que desliga o port HDMI. Desabilite esta linha, editando o ficheiro /etc/cron.daily/powersave e comentando a instrução com "#",
#/opt/vc/bin/tvservice -o

Instalação de modos digitais em ambiente gráfico

Quer ter uma estação de rádio digital completa no seu raspberry pi?
Prossiga agora para o artigo - https://dl1gkk.com/setup-raspberry-pi-for-ham-radio/

Instalou tudo? Fantástico!

Instalação de Packet AX.25 e APRS com linbpq

Siga os meus posts anteriores, instale e configure de acordo com as suas preferências, o seu indicativo, o QRA locator, etc...

packet/APRS iGate, BBS, node e DX cluster com Raspberry Pi (parte 2)
packet/APRS iGate, BBS, node e DX cluster com Raspberry Pi (parte 3)
packet/APRS iGate, BBS, node e DX cluster com Raspberry Pi (parte 4)
packet/APRS iGate, BBS, node e DX cluster com Raspberry Pi (parte 5)
Mapas de APRS em BPQ32

Opcional

Acesso linux a partir do linbpq
Direwolf AX.25 + FEC = FX.25 (para quem pretende explorar o HF)
Monitor de WSPR com raspberry pi + dongle RTL-SDR

Veja também

Solução de problemas com a placa de som CM108
Como criar Menus no Gnome para o raspberry pi

...aspecto final


Referências:
https://gist.github.com/kmpm/8e535a12a45a32f6d36cf26c7c6cef51
https://forum.pistar.uk/viewtopic.php?t=1237&start=10
https://forum.pistar.uk/viewtopic.php?t=858

Referências avançadas:
https://hallard.me/raspberry-pi-read-only/
https://gist.github.com/paulfurley/8e2e2ead269d81d6c41604233a696acd
https://medium.com/@andreas.schallwig/how-to-make-your-raspberry-pi-file-system-read-only-raspbian-stretch-80c0f7be7353
https://github.com/km4ack/pi-build
https://forum.pistar.uk/viewtopic.php?f=3&t=2059&start=40

Direwolf AX.25 + FEC = FX.25

Nesta data o projecto direwolf vai na sua versão 1.6 D e suporta FX.25

Trata-se do protocolo AX.25 perfeitamente compatível com compressão de erros, útil sobretudo em comunicações de packet em HF.

Para dispormos desta característica devemos instalar esta versão de desenvolvimento. Siga os passos seguintes,

Após instalada a nova versão, chamo o direwolf com a seguinte linha,

As opções a seguir dizem respeito a,

-X - número de check bytes
-d - as opções de debug, optei por x
-t 0 - evita que ao chamar o direwolf o ecrã cintile
-c - local onde se encontra o ficheiro de configuração para esta placa de som, bauds, PTT entre outras definições
-l (L minúsculo) - onde será guardo o log

Quadro com opções de debug

Um exemplo do output com a função de debug -d x

FX.25: Matched correlation tag 0x05 with 6 bit errors.  Expecting 223 data & 32 check bytes.
FX.25: Matched correlation tag 0x05 with 0 bit errors.  Expecting 223 data & 32 check bytes.
FX.25: Matched correlation tag 0x05 with 0 bit errors.  Expecting 223 data & 32 check bytes.
FX.25: FEC complete with no errors.
FX.25: FEC complete with no errors.
FX.25: FEC complete, fixed 13 errors in byte positions: 11 19 65 73 74 92 116 117 132 138 143 144 192

FX.25: Matched correlation tag 0x06 with 1 bit errors.  Expecting 128 data & 32 check bytes.
FX.25: Matched correlation tag 0x06 with 1 bit errors.  Expecting 128 data & 32 check bytes.
FX.25: Matched correlation tag 0x06 with 1 bit errors.  Expecting 128 data & 32 check bytes.
FX.25: Matched correlation tag 0x06 with 1 bit errors.  Expecting 128 data & 32 check bytes.
FX.25: FEC complete with no errors.
FX.25: FEC complete with no errors.
FX.25: FEC complete with no errors.
FX.25: FEC complete, fixed  1 errors in byte positions: 97

O modo de FX.25 é automático e utilizado pela aplicação quando detecta erros na recepção.

Este modo é mais lento do que o protocolo AX.25 mas com melhor rendimento em comunicações a grande distância onde existe ruído, como as bandas de HF.

A estação que transmite define o número de check bytes a utilizar.

Melhorias do FX.25 em APRS

Um exemplo no envio de 1000 pacotes de APRS onde se introduz uma taxa de erro, controlada, e no final da transmissão contam-se os pacotes recebidos correctamente,

Melhorias do FX.25 em packet radio

O modo de ligação utiliza os mesmos pacotes de AX.25, mas de uma maneira diferente.
Em vez de transmitir broadcasting, isto é para todos como o APRS, é utilizado na comunicação entre duas estações específicas. O TNC que escuta atribui números de sequência aos pacotes recebidos.
O receptor reconhece o que foi recebido e solicita o preenchimento de pacotes ausentes, isto é, com erro.

Este teste utiliza 100 pacotes, cada um com 128 bytes de informação.
A quantidade total de dados da transferência, dividida pelo tempo decorrido, fornecerá uma taxa de transferência efectiva, medida em bytes por segundo neste exemplo.
À medida que a taxa de erro aumenta, são necessárias mais tentativas e a taxa de transferência diminui. Nalgum momento, o receptor simplesmente desiste antes de chegar ao fim. Damos aqui uma pontuação de 0.

Referências:
https://packet-radio.net/direwolf-1-6-d-mar-1-2020-fx-25/
https://packet-radio.net/direwolf-ax-25-fec-fx-25/
https://github.com/wb2osz/direwolf/blob/dev/doc/AX25_plus_FEC_equals_FX25.pdf