Il Packet Radio festeggia nel 2022 circa 40 anni di vita, considerando le prime sperimentazioni sviluppate tra la fine degli anni ’70 e l’inizio degli anni ’80. In quegli anni diversi gruppi di radioamatori contribuirono allo sviluppo di questa tecnologia; tra questi, l’American Radio Research and Development Corporation (AMRAD) propose l’uso di una versione adattata a fini radioamatoriali dello standard CCITT X.25, un protocollo di rete a pacchetto. Si trattava di qualcosa di rivoluzionario rispetto alle altre tecnologie di comunicazione digitale radioamatoriale dell’epoca. AX.25 consente infatti, grazie al meccanismo di accesso condiviso al mezzo (CSMA), a più stazioni (nodi) di operare sulla stessa frequenza, permettendo la condivisione di un singolo canale radio fra più utenti. Inoltre, attraverso nodi e digipeater che implementano meccanismi di store and forward, è possibile effettuare trasferimenti affidabili anche fra due stazioni non direttamente collegabili. Un mondo completamente diverso da quello tipico delle comunicazioni digitali amatoriali, generalmente di tipo punto-punto, ed estremamente interessante anche dal punto di vista didattico, considerando che all’epoca le reti dati erano ancora agli albori anche in ambito business. Il rovescio della medaglia era che per la sua implementazione era necessario che ogni nodo fosse dotato di un TNC (terminal node controller), un piccolo microcomputer dedicato che gestiva tutte le elaborazioni necessarie allo scambio di dati.

Si trattava comunque di tecnologia sviluppata in gran parte da radioamatori, in quegli anni trainati dal gruppo Tucson Amateur Packet Radio (TAPR): il loro kit TNC-1 apparve sui numeri di luglio ed agosto 1983 di Ham Radio Magazine e fu il primo di una lunga serie di prodotti amatoriali e commerciali.
Nonostante attivarlo in quegli anni richiedesse investimenti non trascurabili – oltre al TNC era indispensabile disporre di un computer o di un terminale – il packet, per le sue caratteristiche, guadagnò rapidamente un notevole gruppo di appassionati, soprattutto grazie alla sua capacità di distribuire e rendere disponibili sul territorio notizie e documentazione radioamatoriale. Il suo periodo d’oro è durato oltre 10 anni. Poi, parallelamente allo sviluppo di internet, che ha progressivamente offuscato questa sua peculiarità, è caduto pressoché in disuso. Oggi è utilizzato soprattutto come supporto ad APRS, ma sopravvive anche in reti locali e attività sperimentali.
Ciò non toglie che il packet radio rimane un ottimo strumento didattico e di sperimentazione in ambito reti e comunicazioni digitali – specie oggi che, grazie ai progressi tecnologici degli ultimi anni, può essere realizzato a costi irrisori.

Un esempio è il nodo packet che ho assemblato in questi giorni, e che opera dal mio shack su 144.875 MHz.

È basato su un vecchio Raspberry Pi (1) B. Per “fare packet” con il Raspberry, che non dispone di un ingresso audio analogico utilizzabile, è sufficiente aggiungere una “chiavetta” audio USB. Il ricetrasmettitore è un vetusto Icom IC-02E.

Il sistema operativo

Linux ha un supporto nativo per AX.25 ed è quindi il sistema operativo più adatto per questa applicazione. Come distribuzione ho usato Devuan, una versione di Debian priva di systemd: le risorse del RPi-1 sono abbastanza limitate, ed è quindi utile seguire la filosofia KISS. Ho usato nello specifico la versione 2 (denominata ascii), che utilizza il kernel 4.14. Per l’uso packet radio può essere preferibile evitare kernel troppo recenti, poiché in alcune configurazioni lo stack AX.25 presenta problemi noti e non completamente risolti. In particolare, sui Raspberry è da considerare anche un bug noto che potrebbe compromettere il buon funzionamento.
Le funzioni del TNC sono implementate via software. Su Linux ci sono due soluzioni principali: soundmodem e direwolf. Quest’ultimo è più recente ed offre funzionalità superiori, ma su hardware molto limitato come il RPi-1 richiede più risorse. Ho quindi utilizzato il più leggero soundmodem (progetto distinto dall’omonimo di UZ7HO per Windows), che funziona comunque egregiamente con un impegno di risorse ridotto.
I package da installare via apt-get sono quindi soundmodem, libax25, libax25-dev, ax25-tools, ax25-apps. È conveniente disabilitare l’audio on-board editando il file /boot/config.txt ed inserendo la voce dtparam=audio=off.

Il ricetrasmettitore

Il progetto prevede un funzionamento continuo 24/7, quindi richiede un apparato dedicato. La tipologia più adatta allo scopo è quella dell’HT, o walkie talkie. È probabile che nello shack ve ne sia uno in disuso, e comunque al giorno d’oggi se ne trovano di estremamente economici. Io ho utilizzato un vetusto Icom IC-02E, ma ho testato anche altri apparati, come il Baofeng UV-5R. Dato che i portatili non hanno un metodo standard di commutazione in trasmissione, è necessario costruire un’interfaccia specifica.

L’interfaccia

Questa si presta ad essere utilizzata, con piccole variazioni, con più modelli: quelli che commutano collegando il polo caldo del microfono verso massa attraverso una resistenza (Icom, Yaesu), e quelli che invece chiudono la massa del microfono verso quella dell’altoparlante (Baofeng).

Le due linee hanno lo scopo di regolare i livelli delle uscite del Raspberry e dell’HT, entrambe destinate a cuffie/altoparlanti, verso gli ingressi microfonici della controparte, disaccoppiandoli in continua. Non ho riscontrato la necessità di interporre trasformatori di isolamento.
Una terza linea è quella destinata alla commutazione in trasmissione (PTT). Alcuni utilizzano il VOX dell’HT, ma non è una soluzione ottimale: è una funzione pensata per la voce e introduce un ritardo indesiderato nei modi digitali, aumentando la latenza del canale. La soluzione migliore, nel caso del Raspberry, è utilizzare una linea GPIO, come la GPIO4.
Sia soundmodem che direwolf consentono di usare direttamente una GPIO come PTT, così come hamlib per i ricetrasmettitori dotati di interfaccia CAT, o le classiche interfacce basate sulle linee di controllo seriali.
Il disaccoppiamento della GPIO (che opera a 3.3V) è affidato ad un optoisolatore.

Ax25

Il passo successivo è la configurazione dello stack AX.25. Il primo file da modificare è /etc/ax25/axports:

# /etc/ax25/axports
#
# name callsign speed paclen window description
#
ax0 I8ZSE-3 1200 255 2 144.875 (1200 bps)

I campi sono: name, callsign, speed, paclen, window e description.

Definita la porta, si passa alla configurazione di soundmodem in /etc/ax25/soundmodem.conf. […]

Nella riga pkt, mode può assumere due valori: MKISS e KISS. MKISS consente la gestione di più canali e può essere utilizzato come base per configurazioni più avanzate, mentre KISS crea una semplice interfaccia sullo stack AX.25.

Hamlib

[…]

Soundmodem deve essere sempre in esecuzione in background; può essere avviato automaticamente all’avvio del sistema, ad esempio tramite crontab con una riga @reboot.

Riavviando il sistema lo stack AX.25 dovrebbe essere configurato ed attivo.

Avendo a disposizione un hardware più potente (come un RPi-3/4 o un PC) è possibile utilizzare come soft-modem Direwolf al posto di soundmodem. Implementa le funzioni di base di un TNC KISS, ma offre anche numerose funzionalità aggiuntive. Può operare come APRS GPS tracker, digipeater e gateway senza necessità di software esterno, ed è utilizzabile anche via TCP/IP, oltre che attraverso lo stack AX.25. L’elenco completo delle funzionalità è disponibile sulla pagina GitHub del progetto.

Direwolf è disponibile fra i package installabili con apt-get; trattandosi però di un progetto attivo, per utilizzare la versione più recente può essere preferibile scaricare i sorgenti e compilarli autonomamente.

Il file di configurazione di Direwolf è un semplice file di testo. Per l’uso come TNC, questo esempio è equivalente a quello visto per soundmodem:

PTT GPIO 4
ACHANNELS 1
CHANNEL 0
MYCALL I8ZSE-1
MODEM 1200

Direwolf supporta diverse modalità di gestione del PTT, tutte ben documentate. Ad esempio, per un Yaesu FT-897 collegato via CAT a 38400 bps:

PTT RIG 1023 /dev/ttyUSB0 38400

Direwolf può visualizzare una serie di informazioni diagnostiche direttamente sulla stdout, molto utili per la messa a punto del sistema. Per questo motivo è comodo avviarlo in un terminale separato, così da poterle consultare in qualsiasi momento. A tale scopo è sufficiente utilizzare GNU screen, installabile con apt-get install screen. Screen è un terminal multiplexer che consente di creare sessioni persistenti, scollegate dal terminale di origine, a cui è possibile riconnettersi in qualsiasi momento.

Per avviare Direwolf utilizzo il seguente script:

echo "starting Direwolf..."
/usr/bin/screen -d -m -S direwolf /usr/bin/direwolf -p -c direwolf.conf -t 0
sleep 2
PTS=`ls -l /tmp/kisstnc | awk '{ print $11 }'`
/usr/sbin/kissattach $PTS ax0
# set kiss parameters
/usr/sbin/kissparms -c 1 -p ax0 -r 125 -t 250 -s 20 -f n -l 20
echo "... started"

Il comando /usr/bin/screen -d -m -S direwolf avvia una sessione disconnessa denominata direwolf, nella quale viene eseguito /usr/bin/direwolf -p -c direwolf.conf -t 0. L’opzione -p crea uno pseudoterminale a cui collegare lo stack AX.25, mentre -t 0 disabilita la colorazione del testo.

Direwolf crea un link simbolico in /tmp/kisstnc per rendere disponibile il nome dello pseudoterminale, assegnato dinamicamente. Questo valore viene letto e assegnato alla variabile PTS, che viene poi utilizzata da kissattach per collegare l’interfaccia AX.25 (ax0). Il comando kissparms consente invece di configurare i parametri di temporizzazione del canale AFSK.

Direwolf può essere eseguito in spazio utente, purché l’utente abbia accesso ai dispositivi audio (gruppo audio). Alcuni comandi richiedono però privilegi elevati; una soluzione semplice è abilitare il bit SUID (chmod u+s) sugli eseguibili necessari (direwolf, kissattach, kissparms, axlisten, axcall, ecc.).

Livelli audio

Sia soundmodem che Direwolf richiedono un’accurata regolazione dei livelli audio, sia in trasmissione che in ricezione. Una prima regolazione “grossolana” può essere effettuata tramite l’interfaccia hardware, mentre quella fine tramite il mixer ALSA (alsamixer):

La regolazione in trasmissione è relativamente semplice: anche senza strumenti di misura è sufficiente monitorare il livello di modulazione con un altro apparato. In ricezione è invece utile sfruttare le informazioni diagnostiche di Direwolf, che indicano se il livello audio è troppo alto o troppo basso. Anche su sistemi meno performanti può essere utile eseguirlo temporaneamente per effettuare questa regolazione. È consigliabile disabilitare eventuali controlli automatici del guadagno per ottenere risultati più accurati.

Una volta completata la configurazione, è importante salvarla con alsactl store, altrimenti verrà persa al riavvio.

Per accedere alla sessione di Direwolf: screen -r direwolf. Per disconnettersi mantenendola attiva: CTRL-A seguito da D.

Modem

Il protocollo AX.25 non specifica il tipo di modem da utilizzare. Lo standard più diffuso in VHF/UHF è l’AFSK a 1200 baud, con toni a 1200 e 2200 Hz (derivato dal Bell 202). Si tratta di una tecnologia ormai datata e poco efficiente. Esistono alternative più evolute, come il 9600 baud G3RUH, inizialmente pensato per uso satellitare ma adottato anche su collegamenti terrestri, oppure soluzioni come SuperVozelj.

Un approccio alternativo è l’uso di modulazioni più efficienti, in grado di sfruttare meglio la banda disponibile (circa 2.2 kHz) con apparati standard. Tuttavia, nell’uso radioamatoriale la velocità non è sempre prioritaria, salvo applicazioni specifiche come le comunicazioni di emergenza.

Direwolf supporta anche FX.25, che introduce meccanismi di forward error correction. Anche soundmodem include modalità sperimentali come Q15X25.

Si tratta di ambiti di sperimentazione ancora molto interessanti: rimanere ancorati al modello TNC-2 è oggi piuttosto limitante.

Test

Una volta regolati i livelli, è il momento di testare il sistema. A questo scopo è molto utile il Test CD di WA8LMF, che contiene registrazioni di traffico radio utilizzabili come sorgente di prova. In ambiente Linux, il comando axlisten consente di monitorare il traffico ricevuto, mentre axcall permette di stabilire una connessione con un’altra stazione e testare anche la catena trasmittente.

A questo punto lo strato packet radio del sistema è operativo, ed è possibile installare le applicazioni.

LinFBB

F6FBB è una nota applicazione per BBS, utilizzata fin dagli anni ’80. LinFBB è la versione per Linux, installabile via apt-get o dai sorgenti. La configurazione richiede diversi file; tra questi, uno dei più significativi è port.sys:

# FBB7.0.10
#
#Ports TNCs
1 1
#
#Com Interface Adress (Hex) Baud
1 9 0 1200
#
#TNC NbCh Com MultCh Pacln Maxfr NbFwd MxBloc M/P-Fwd Mode Freq
0 0 0 0 0 0 0 0 00/01 ---- File-fwd.
1 4 1 ax0 250 7 2 10 30/05 XUWYL 144.875
#
# End of file.
#

LinFBB può essere avviato automaticamente all’avvio del sistema tramite /etc/rc.local. È possibile collegarsi localmente con xfbbC -c -i <callsign> (porta TCP 3386).

DxSpider beacon

Sul mio nodo è attivo anche un beacon che visualizza gli spot provenienti dalla rete DxCluster, in particolare dal nodo dxcluster.i8zse.eu. Il sistema rimane in attesa di comandi inviati tramite pacchetti UI (DXCLUSTER HELP o DXCLUSTER <filtro>), attivando temporaneamente la trasmissione degli spot filtrati.

Il software è disponibile su GitHub.

Link utili