Le porte su linux
Seriali e audio: nulla da temere
Colleghi il TRX al PC e il software non trova la porta. Un nome strano come /dev/ttyUSB0 appare (e scompare) senza preavviso.
Facciamo un po’ di chiarezza su un argomento che è spesso causa di grattacapi, e come smettere di indovinare.
Chi si avvicina al mondo della radio digitale – FT8, PSK31, Winlink, controllo CAT – si scontra quasi subito con un ostacolo inaspettato: che non è la propagazione, non è l’antenna, ma il semplice fatto di non riuscire a far dialogare il computer con la radio. In campo abbiamo le periferiche USB, Linux che sembra assegnare nomi misteriosi che cambiano: /dev/ttyUSB0 oggi, /dev/ttyUSB1 domani.
Senza una mappa, si rischia di perdersi.
La cosa migliore è partire dall’inizio: cosa è una porta di comunicazione su Linux, come viene battezzata, perché esistono porte “fisiche” e “virtuali”, per vedere – alla fine – un accessorio che ho scritto appositamente per consentire ai miei colleghi che non amano usare il terminale per avere un quadro completo della situazione.
Tutto è un file – la filosofia Unix
Su Linux (come su tutti i sistemi Unix-like) ogni dispositivo hardware è rappresentato da un file speciale nella directory /dev.
Questo non è un vezzo storico: significa che per comunicare con una porta seriale si usa esattamente la stessa interfaccia (apertura, lettura, scrittura, chiusura) che si usa per un file di testo normale. Un programma come WSJT-X non ha bisogno di sapere se parla con un chip FTDI o con un Prolific: apre /dev/ttyUSB0 e scrive bytes.
I file in /dev non occupano spazio su disco perché sono interfacce verso il kernel. Scrivere su /dev/ttyUSB0 significa inviare dati alla radio collegata alla prima chiavetta USB-seriale; mentre leggendo dallo stesso file si ricevono i dati inviati dalla radio.
I nomi
Ma come assegna Linux i nomi? Il nome di una porta non è permanente per default: dipende dall’ordine in cui il kernel trova i dispositivi all’avvio del computer, o alla connessione di una periferica USB. Il sotto-sistema responsabile si chiama udev, e lavora così: quando si inserisce un adattatore USB-seriale, il kernel carica il driver appropriato (es. cp210x per i chip Silicon Labs, ftdi_sio per FTDI) e crea il nodo in /dev. In base al tipo di periferica assegna un nome (ttyUSB sono gli adattatori seriali USB) ed un numero finale (0, per la prima, 1 per la seconda, e così via). Lo zero di /dev/ttyUSB0 indica che è il primo disponibile in quel momento. Se si connettono due interfacce, quella che il kernel vede per prima diventa ttyUSB0, l’altra ttyUSB1. Scollegare e ricollegare può cambiare l’ordine.
Porte esterne, porte interne
È poi importante fare anche una distinzione fra porte fisiche esterne (collegate generalmente via USB) e fisiche interne (integrate nella scheda madre o in una scheda PCI).
Le porte esterne sono di gran lunga le più comuni nel setup moderno. Un cavo USB con chip FTDI oppure una scheda di interfaccia audio/seriale dedicata alla radio (Signalink, RigBlaster, DigiRig…) appaiono tutte qui.
Linux riconosce il produttore e il modello tramite due numeri: il VID (Vendor ID) e il PID (Product ID), scritti nel firmware del chip e generalmente visibili con il comando lsusb.
# Esempio: chip Silicon Labs CP2102 Bus 001 Device 004: ID 10C4:EA60 Silicon Laboratories CP210x UART Bridge ^^^^ ^^^^ VID PID
Interne
Le porte /dev/ttySN corrispondono agli UART fisici saldati sulla scheda madre (tipicamente due, ttyS0 e ttyS1, cioè le vecchie COM1 e COM2 di Windows). Su un PC moderno sono spesso inutilizzate o addirittura assenti, ma è facilissimo trovarle sui computer datati che vanno benissimo per l’uso radiantistico. Hanno un indirizzo I/O fisso (0x3F8 per COM1, 0x2F8 per COM2) e un IRQ dedicato (IRQ 4 per ttyS0, IRQ 3 per ttyS1), il che le rende molto stabili e prevedibili, quindi non c’è nessun rischio di cambiamento di nome. Spesso si trova sul pannello posteriore un connettore a 9 pin per la ttyS0, con la ttyS1 presente sulla scheda madre ma non collegata a connettori esterni.
Porte virtuali
Una porta virtuale non ha hardware dietro: è un’astrazione creata dal software. Sotto il profilo funzionale appare identica a qualsiasi altra porta fisica: si apre, si legge e si scrive. I dati, però, prendono un’altra strada. Ce ne sono di vario tipo:
Pseudo-terminali (PTY): sono porte create, in coppie, per gestire il flusso di dati verso l’utente; la coppia è formata da una master (/dev/ptmx) ed una slave (/dev/pts/N). Normalmente non li vedete mai, ma appaiono nella lista delle porte se un programma le scansiona tutte: nel caso, ignoratele.
Coppie virtuali (socat, tty0tty): strumenti come socat o il modulo kernel tty0tty permettono di creare coppie di porte seriali virtualmente collegate tra loro: tutto ciò che si scrive su una esce dall’altra. Sono usate spesso per fare da ponte tra due programmi che vogliono entrambi essere il “proprietario” di una porta, oppure per fare debug senza hardware fisico.
L’audio: stessa logica, un sottosistema diverso
Le schede audio su Linux sono gestite da ALSA (Advanced Linux Sound Architecture) con uno strato opzionale chiamato PulseAudio o PipeWire che gira sopra ALSA.
A differenza delle porte seriali, i dispositivi audio non appaiono in /dev con nomi leggibili: si accede a loro tramite indici numerici o tramite API di più alto livello come sounddevice (Python) o portaudio.
Per un radioamatore i parametri più rilevanti sono il numero di canali di ingresso e uscita (necessari per gestire segnali distinti), la frequenza di campionamento e la latenza.
Il numero di canali è importante quando si vogliono separare flussi diversi (ad esempio RX/TX o più ricevitori), per l’uso con un singolo apparato non è determinante; la latenza influisce sul monitoraggio in tempo reale e sulla stabilità del sistema.
Per quanto riguarda la frequenza di campionamento, sebbene 44.1 kHz sia lo standard storico dell’audio musicale, in ambito radiantistico è generalmente più importante il supporto nativo a 48 kHz, che rappresenta lo standard de facto per la maggior parte delle interfacce USB e dei sistemi DSP. Molti software per modi digitali, come WSJT-X, e numerosi dispositivi SDR operano internamente a 48 kHz o multipli, rendendo questa frequenza preferibile per evitare riconversioni, resampling e possibili degradazioni del segnale.
Un aspetto spesso sottovalutato è la stabilità del clock e la sincronizzazione temporale: una scarsa stabilità del clock della scheda audio può introdurre drift di frequenza nel segnale campionato, con effetti negativi sulla decodifica, rendendo in pratica più importante la qualità del clock rispetto alla sola frequenza di campionamento nominale.
Una latenza bassa è importante per il monitoraggio in tempo reale e per alcune applicazioni SDR, mentre nei modi digitali come WSJT-X è generalmente poco critica. In molti casi una latenza più alta può addirittura migliorare la stabilità del sistema riducendo errori e interruzioni audio.
Il modo standard per verificare le periferiche audio è quello di usare aplay -l o pactl list sinks, ma la lista dei dispositivi è verbosa e difficile da leggere a colpo d’occhio.
Devenum
Per ogni porta è mostrata come una scheda con una barra colorata sul lato sinistro che ne indica immediatamente la tipologia
Il software mostra tutte le informazioni utili:
Per le porte seriali:
- Classificazione automatica in fisica esterna, fisica interna o virtuale
- Nome del driver e descrizione del dispositivo (es. “CP2102 USB to UART Bridge”)
- VID:PID per identificare univocamente il chip
- Numero seriale e posizione nel bus USB (per porte esterne)
- IRQ e indirizzo I/O (per porte interne RS-232, tramite
setserial) - Nome del processo che tiene la porta occupata, con PID (tramite
fuser) - Badge di stato: Available (verde) o In use (arancione)
- Filtro rapido: Tutte / Solo esterne USB / Solo interne / Solo virtuali
Per i dispositivi audio:
- Numero di canali di ingresso e uscita con pillole visive
- Frequenza di campionamento di default
- Latenza bassa e alta (ingresso e uscita), in secondi
- Host API (ALSA, PulseAudio, JACK…)
- Badge Default I/O, Default IN o Default OUT
- Filtro: Tutti / Solo ingresso / Solo uscita
Può essere molto utile per individuare le nuove periferiche: basta tenere il programma aperto mentre collegate l’interfaccia radio, e premete Refresh subito dopo l’inserimento del cavo USB: vedrete comparire la nuova porta con tutti i dettagli.
Se la scheda mostra In uso e non ci sono applicazioni in esecuzione, significa che un altro programma (forse rimasto aperto per errore) sta occupando la porta.
In sintesi
Linux non è ostile alle radio: è solo trasparente. Ogni dispositivo ha un nome, un driver, una storia. Una volta capito il meccanismo con cui sono assegnati i nomi in /dev e la differenza tra porte fisiche e virtuali, configurare WSJT-X, Fldigi o qualsiasi altro software diventa una questione di minuti, senza ammattire in ricerche online.
Ho scritto devenum con l’obiettivo di rendere visibile e leggibile questa infrastruttura, senza sostituire la comprensione, ma per accelerarla.
InfoLe periferiche USB sono identificate anche da una posizione fisica, del tipo
1-1.2, che è stabile ed identifica su quale porta USB (del computer o di un hub) è connessa. Se, come è normale, la radio è collegata sempre sulla stessa porta è possibile creare una regola udev che crea un file con un nome ad hoc per quella specifica interfaccia, ad esempio /dev/radio_cat.Se volete smanettare potete creare un file in
/etc/udev/rules.d/99-radio.rules con una riga del tipo:
SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", SYMLINK+="radio_cat"
che istruisce Linux a creare un file di periferica dal nome /dev/radio_cat che punta alla periferica USB con VID 10c4 e PID ea60, indipendentemente da dove è connessa.
È utile nel caso abbiate più periferiche analoghe – ad esempio un singolo PC che gestisce più radio. In una installazione con PC dedicato e con una singola interfaccia seriale esterna non è necessario, visto che sarà sempre assegnata a /dev/ttyUSB0.
C’è anche da aggiungere che alcune periferiche USB hanno un numero seriale, che permette di identificare in modo univoco quello specifico oggetto. Ad esempio le porte FTDI hanno un ID univoco di fabbrica, le Silicon Labs lo supportano ma non sempre è programmato (spesso viene lasciato il valore di default 0001). Le WCH (CH340/341) e le Prolific non hanno questa possibilità, e quindi non possono essere differenziate. È una caratteristica da tenere a mente al momento della scelta.
InfoLe famiglie di nomi
| Nome | Tipo | Caso d’uso tipico |
|---|---|---|
| /dev/ttyUSBN | Fisica esterna – convertitore USB→seriale (FTDI, CP210x, Prolific) | Cavo CAT, TNC, interfaccia Signalink |
| /dev/ttyACMN | Fisica esterna – CDC/ACM (dispositivo USB nativo) | Arduino, schede SDR con firmware CDC |
| /dev/ttySN | Fisica interna – UART sulla scheda madre o slot ISA/PCI | PC industriali, vecchi TNC RS-232 |
| /dev/rfcommN | Fisica esterna – Bluetooth RFCOMM | Headset PTT Bluetooth, TNC wireless |
| /dev/pts/N | Virtuale – pseudo-terminal (PTY) | Sessioni SSH, screen, minicom |





Commento all'articolo