Il Packet Radio festeggia nel 2022 ben 40 anni di vita.  Nel 1982 l’American Radio Research and Development Corporation (AMRAD) realizzò uno studio che proponeva l’uso di una versione adattata a fini radioamatoriali dello standard CCITT X25, un protocollo di rete a pacchetto. Si trattava di qualcosa di rivoluzionario rispetto alle altre tecnologie di comunicazione digitale radioamatoriale dell’epoca. AX25 consente infatti connessioni simultanee fra più stazioni  (nodi) attive sulla stessa frequenza, e quindi la possibilità di condivere un singolo canale radio fra più utenti.  Come in X25, il meccanismo di ‘store and forward’ consente trasferimenti senza errori anche fra due nodi che non sono collegabili direttamente. Un mondo completamente diverso da quello tipico delle comunicazioni digitali amatoriali, che sono in genere di tipo punto-punto, ed estremamente interessante dal punto di vista puramente didattico, visto che all’epoca le reti dati erano concretamente agli albori anche nel mondo del 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 effettuava tutte le elaborazioni necessarie a gestire lo scambio di dati.
Si trattava comunque di tecnologia sviluppata interamente 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 indispnesabile disporre di un computer o di un terminale – il packet per le sue caratteristiche inizialmente guadagnò rapidamente un notevole gruppo di appassionati, soprattuto grazie alla sua capacità di distribuire e rendere disponibile sul territorio notizie e documentazione radioamatorali. Il suo periodo d’oro è durato oltre 10 anni. Poi, parallelamente allo sviluppo di internet che  ha ovviamente progressivamente offuscato questa sua pecularità, è caduto pressocè in disuso, al punto che oggi è sostanzialmente usato solo di supporto ad APRS.
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 di questi lustri, può essere effettuato a costi irrisori.

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

E’ basato su un vecchio Raspberry Pi (1) B. Per ‘fare packet’ con il raspberry, che non ha un canale audio in ingresso, è 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 bonificata da systemd: le risorse del Rpi-1 sono abbastanza limitate, ed è quindi maggiormente utile seguire a pieno la filosofia KISS. Io ho usato nello specifico la versione 2 (denominata ascii), che usa il kernel 4.14.  Per l’uso packet radio è in genere preferibile usare kernel non troppo recenti, visto che gli ultimi hanno problemi noti e non risolti con lo stack ax-25.  In paricolare, sui raspberry c’è anche da tenere presente un altro bug noto, che potrebbe compromettere il buon funizonamento.
Le funzioni del TNC sono implementate via software. Su Linux ci sono due prodotti utilizzabili: soundmodem e direworlf. Quest’ultimo è più recente, ed ha migliori funzionalità, ma richiede troppe risorse per l’Rpi-1. Io ho quindi usato il più vecchio soundmodem (che è un progetto del tutto autonomo rispetto all’omonimo di UZ7HO per Windows), che funziona comunque egregiamente, con un impegno di risorse drasticamente più ridotte.
I package da installare via apt-get sono quindi soundmodem, libax25, libax25-dev, ax25-tools, ax25-apps, libax25-dev. E’ 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, quini richiede un apparato dedicato. La tipologia più adatta allo scopo è quella dell’HT, o walkie talkie. E’ probabile che nello shack ve ne sia uno in disuso, e comunque al giorno d’oggi se ne trovano in giro di estremamente economici. Io ho utilizzato un vetusto IC-02E Icom, ma ho testato anche altri apparati, come il Baofeng UV-5R. Dato che i portatili non hanno un metodo standard di commutazione in trasmissione, per questi è necessario costruire una 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 dell’Rpi e dell’HT, che sono entrambe destinate ad una cuffia/altoparlante, agli 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). Ho visto che più di qualcuno usa il VOX dell’HT, quando disponibile, a questo scopo. Non è una soluzione ottimale, visto che è una funzione ‘pensata’ per la voce, e che induce un ritardo indesiderato nei modi digitali, anche nei casi in cui il Vox Delay è regolabile. Ritardo che, nel caso del packet, aumenta la latenza del canale. La soluzione migliore, nel caso dell’Rpi, è quella di usare una delle linee GPIO disponibili, come la GPIO4 che non è assegnata ad altre interfacce.
Sia soundmodem che direwolf consentono di usare come PTT la GPIO in modo diretto, così come hamlib per i trasceiver dotati di interfaccia CAT, o le classiche interfacce basate sulle linee di controllo seriali.
Il disaccoppiamento della GPIO (che funziona a 3.3V, peraltro abbastanza critici) è affidato ad un optoisolatore. Questa è la versione assemblata su una millefori, collegata ad un Rpi Zero

Ax25

Il passo successivo è quello di configurare ed attivare lo stack ax25, a questo scopo è sufficiente modificare alcuni file. Il primo serve a definire le porte ax25 attive nel sistema. Nel nostro caso la porta è solo una, quella su cui configureremo soundmodem, che deve essere identificata con un nome: io ho usato ax0. Il file da modificare è /etc/ax25/axports

# /etc/ax25/axports
#
# The format of this file is:
#
# name callsign speed paclen window description
#
ax0 I8ZSE-3 1200 255 2 144.875 (1200 bps)

I capi sono: name, il nome da assegnare alla porta, che deve essere diverso da quelli delle interfacce di rete del sistema; callsign, il nominativo associato alla porta completo di SSID; speed,  la velocità della porta in bps; paclen, la lunghezza massima di un pacchetto in byte; window, il numero di pacchetti che possono essere trasmessi prima di attendere la conferma; description, che è un campo descrittivo libero.

Definita la porta, è il momento di configurare soundmodem, editando /etc/ax25/soundmodem.conf, che è un file xml. Questo è il contenuto del mio:

<?xml version="1.0"?>
<modem>
<configuration name="SNDMDM">
<chaccess txdelay="250" slottime="100" ppersist="40" fulldup="0" txtail="100" />
<audio type="alsa" device="plughw:1,0" halfdup="1" capturechannelmode="Mono" />
<ptt file="/sys/class/gpio/gpio4" hamlib_model="" hamlib_params="" gpio="" />
<channel name="ax0">
<mod mode="afsk" bps="1200" f0="1200" f1="2200" diffenc="1" inlv="8" fec="1" tunelen="32" synclen="32" />
<demod mode="afsk" bps="1200" f0="1200" f1="2200" diffdec="1" inlv="8" fec="3" mintune="16" minsync="16" />
<pkt mode="MKISS" ifname="ax0" hwaddr="I8ZSE-3" ip="192.168.254.1" netmask="255.255.255.0" broadcast="192.168.254.255" file="/dev/soundmodem0" unlink="1" />
</channel>
</configuration>
</modem>

Qualche considerazione sui parametri: in chaccess sono i valori per l’accesso fisico al canale radio. Txdelay è il tempo che passa fra l’attivazione del PTT e l’inizio della trasmissione del pacchetto dati, il valore (in ms) deve essere leggermente maggiore del tempo di commutazione in trasmissione del ricetrasmettitore. Slottime e ppersist sono due parametri del meccanismo di riduzione delle collisioni (CSMA/CR) che possono essere lasciati come sono. Txtail è la ‘coda’ che viene aggiunta al termine del pacchetto. Una descrizione più approfondita è disponibile nella descrizion del protocollo KISS qui.
La riga audio invece contiene i parametri della chiavetta audio. Il parametro da configurare è device, che corrisponde al dispositivo usb utilizzato. Ricordo che i dispositivi usb possono essere elencati con lsusb, mentre i dispositivi audio utilizzabili possono essere elencati con il comando aplay -l, es:

root@packet:/etc/ax25# lsusb
Bus 001 Device 006: ID 0d8c:013c C-Media Electronics, Inc. CM108 Audio Controller
Bus 001 Device 005: ID 148f:3070 Ralink Technology, Corp. RT2870/RT3070 Wireless Adapter
Bus 001 Device 004: ID 0a05:7211 Unknown Manufacturer hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp. SMC9512/9514 USB Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@packet:/etc/ax25# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 1: Device [USB PnP Sound Device], device 0: USB Audio [USB Audio]
Subdevices: 0/1
Subdevice #0: subdevice #0

Nella riga ptt viene indicato il dispositivo usato per mandare in trasmissione il ricetrasmettitore. Il file nell’esempio –  /sys/class/gpio/gpio4 – non è un file reale, ma un riferimento a syfs, il meccanismo usato da linux per gestire le linee gpio sui raspberry. Non è necessario effettuare configurazioni a livello operativo, è lo stresso soundmodem che si occupa di esportare la linea GPIO e di configurarla come linea in uscita. Da notare che se dovesse essere necessario riavviare soundmodem è necessario disattivare prevantivamente la linea inviando il comando echo 4 >/sys/class/gpio/unexport.
L’ultima riga che richiede attenzione è pkt. Mode può asssumere due valori: MKISS e KISS. MKISS crea una interfaccia ax25 con associata una interfaccia di rete TCP/IP, per questo motivo ad ax0 è assegnato un indirizzo di rete, che può essere usato per usare i protocolli internet via radio. KISS, invece, crea una interfaccia solo sullo stack ax25.

Hamlib

Usando un ricetrasmettitore con supporto CAT è possibile controllare la trasmissione attraverso la libreria hamlib. Se non è già presente, va scaricata con il comando apt-get install libhamlib-utils libhamlib2. La riga da modificare è pkt, che deve assumere questa forma:

<ptt file="/dev/ttyUSB0" hamlib_model="1023" hamlib_params="serial_speed=38400"/>

file, in questo caso, è la porta seriale usata per collegare il ricetrasmettitore, hamlib_model il tipo di RTX, mentre in hamlib_params è possibile specificare i dettagli della connessione CAT. In questo esempio 1023 corrisponde allo Yaesu FT-897, che nel mio caso è configurato per usare 38400 bps come velocità di connessione, anzichè i 9600 di default. La lista dei ricetrasmettitori supportati può essere visualizzata con il comando rigctl –list.

Soundmodem deve essere sempre in esecuzione in background, quindi la maniera migliore di gestirlo è quella di avviarlo assieme al sistema, scrivendo un piccolo script tipo

# start ax25
soundmodem &
sleep 3

ed avviandolo con una riga @reboot in crontab.

Riavviando il sistema lo stack ax25 dovrebbe essere configurato ed attivo

Parte  2

Link utili