Nota editoriale: le informazioni tecniche sono aggiornate al 2 agosto 2026. CARI è un progetto sperimentale in evoluzione e non uno standard industriale consolidato.
Introduzione
Un ripetitore radioamatoriale tradizionale concentra quasi tutte le proprie funzioni nello stesso luogo: ricevitore, trasmettitore, logica di controllo, modem, filtri audio, gestione del PTT e collegamento verso la rete.
Questa architettura è semplice da comprendere, ma presenta alcuni limiti. Ogni modifica importante richiede spesso di intervenire fisicamente sull’apparato, sostituire schede o installare firmware progettati per uno specifico hardware.
Con l’affermazione delle tecnologie SDR, molte funzioni che un tempo richiedevano circuiti dedicati possono essere eseguite dal software. Rimane però una domanda: come collegare in maniera standardizzata il computer che elabora il segnale con la parte radio che lo riceve e lo trasmette?
CARI, acronimo di Common Amateur Radio Interface, cerca di rispondere proprio a questa esigenza.
L’idea consiste nel separare la parte di elaborazione digitale dalla parte radio, facendo comunicare le due unità attraverso un’interfaccia aperta. In questo modo modem, protocolli e applicazioni possono essere eseguiti su un computer, mentre la conversione tra segnale digitale e radiofrequenza viene affidata a un’unità remota.
Che cos’è CARI
CARI è un protocollo sviluppato nell’ambito del progetto M17 per controllare apparati radio attraverso una connessione dati.
La versione descritta dalla documentazione ufficiale è CARI 1.3, datata 30 gennaio 2026. Il progetto dichiara di ispirarsi concettualmente a CPRI, Common Public Radio Interface, impiegata nel settore professionale per collegare unità di elaborazione e unità radio remote. CARI non replica interamente CPRI, ma ne riprende l’idea di separare i diversi flussi dedicati al segnale, al controllo e alla supervisione.
CARI non è quindi un nuovo protocollo vocale paragonabile a DMR, M17 o D-STAR. Non stabilisce come debba essere codificata la voce dell’utente e non definisce direttamente un sistema di chiamate, talkgroup o reflector.
È invece un’interfaccia tra:
- un’unità che elabora il segnale;
- una o più unità che operano fisicamente in radiofrequenza.
La comunicazione fra questi elementi avviene mediante ZeroMQ, utilizzato per il trasferimento dei dati, dei comandi e della telemetria.
BBU e RRU: cervello e parte radio
L’architettura CARI distingue due ruoli fondamentali.
Baseband Unit
La Baseband Unit, abbreviata BBU, è l’unità principale o master.
Può essere costituita da:
- un computer Linux;
- un server;
- un Raspberry Pi sufficientemente potente;
- un sistema embedded;
- un’applicazione GNU Radio;
- un controller dedicato.
La BBU elabora il segnale in banda base e decide cosa deve fare l’apparato radio. Può occuparsi della modulazione, demodulazione, decodifica del protocollo, gestione degli utenti, instradamento audio e collegamento con altri nodi.
Remote Radio Unit
La Remote Radio Unit, abbreviata RRU, è l’unità controllata o slave.
Essa contiene la parte necessaria per tradurre i dati digitali in radiofrequenza e viceversa. A seconda del progetto, può comprendere:
- sintetizzatori di frequenza;
- front-end ricevente;
- amplificatore di potenza;
- filtri;
- convertitori analogico-digitali;
- convertitori digitale-analogici;
- attenuatori;
- amplificatori a basso rumore;
- circuiti di misura;
- commutazione trasmissione-ricezione.
La specifica prevede che ogni dispositivo assuma un solo ruolo: master oppure slave. Una rete CARI può comprendere più master e più unità radio, purché il mezzo di trasporto permetta di raggiungere correttamente i diversi dispositivi.
Che cosa significa “banda base”
Un segnale radio modulato occupa una determinata porzione dello spettro intorno alla frequenza portante. Prima di essere trasferito su VHF, UHF o microonde, lo stesso contenuto può essere rappresentato a frequenza molto più bassa.
Nel mondo SDR questa rappresentazione viene spesso espressa attraverso due componenti:
- I, componente in fase;
- Q, componente in quadratura.
La coppia I/Q conserva le informazioni relative ad ampiezza e fase del segnale. Elaborando questi campioni, un software può realizzare filtri, demodulatori e modulatori senza ricorrere a una catena separata per ogni modo operativo.
CARI permette alla BBU e alla RRU di scambiarsi flussi in banda base. Il tipo di modulazione può quindi essere determinato in larga parte dal software eseguito sulla BBU, mentre la RRU si occupa della conversione verso la frequenza operativa.
I quattro piani di comunicazione
La specifica CARI divide il traffico in quattro percorsi, chiamati planes:
- banda base in uplink;
- banda base in downlink;
- controllo;
- supervisione.
Questa separazione è uno degli aspetti più importanti del progetto.
Baseband uplink
L’uplink trasporta il segnale ricevuto dalla parte radio verso la BBU.
Il percorso può essere schematizzato così:
antenna → ricevitore RF → conversione I/Q → rete dati → elaborazione software
La BBU può quindi:
- filtrare il segnale;
- demodularlo;
- riconoscere un protocollo;
- estrarre la voce;
- misurare il livello ricevuto;
- inoltrare il traffico verso un reflector;
- registrare o analizzare il contenuto.
Baseband downlink
Il downlink compie l’operazione opposta.
Il segnale viene prodotto dalla BBU e inviato alla RRU:
software → campioni di banda base → rete dati → modulatore RF → amplificatore → antenna
I flussi di banda base CARI utilizzano il modello publisher-subscriber di ZeroMQ e possono essere attivati soltanto quando necessari. La specifica consente inoltre a un dispositivo dotato di più oscillatori o più catene radio di utilizzare differenti coppie di flussi uplink e downlink.
Control Plane
Il piano di controllo viene utilizzato per impartire comandi alla parte radio.
Attraverso questo canale la BBU può, per esempio:
- impostare la frequenza di ricezione;
- impostare la frequenza di trasmissione;
- regolare il guadagno del ricevitore;
- definire la potenza di uscita;
- selezionare la larghezza del canale;
- scegliere il sample rate;
- applicare una correzione di frequenza;
- avviare o arrestare la ricezione;
- richiedere le capacità del dispositivo.
Il sistema usa un modello richiesta-risposta: il master invia un comando e l’unità controllata restituisce una conferma o un codice di errore. Ogni slave deve esporre un proprio endpoint di controllo; la selezione del dispositivo avviene quindi scegliendo l’endpoint corretto, non mediante un indirizzo contenuto nel comando.
Supervision Plane
Il piano di supervisione è dedicato alla telemetria.
Nella versione 1.3 sono previste grandezze come:
- temperatura della sezione RF o del telaio;
- tensione di alimentazione;
- corrente assorbita;
- return loss;
- potenza RF incidente;
- potenza RF riflessa.
La RRU pubblica periodicamente questi valori e il sistema di supervisione può riceverli senza dover interrogare continuamente l’apparato.
Questa funzione sarebbe particolarmente utile in una postazione remota. Il gestore potrebbe rilevare rapidamente:
- un aumento anomalo della temperatura;
- un problema all’alimentatore;
- un assorbimento eccessivo;
- un peggioramento del ROS;
- una riduzione della potenza diretta;
- un aumento della potenza riflessa;
- un possibile guasto all’antenna o al cavo coassiale.
Dispositivi e sottodispositivi
Una singola RRU può contenere più ricevitori e trasmettitori. CARI definisce queste unità interne come subdevices.
Il protocollo permette fino a 256 sottodispositivi per ciascun apparato. Ogni elemento può dichiarare le proprie capacità e i propri intervalli di funzionamento.
Una RRU potrebbe quindi contenere:
- un ricevitore VHF;
- un trasmettitore VHF;
- un ricevitore UHF;
- un trasmettitore UHF;
- due catene per il funzionamento full duplex;
- più canali indipendenti.
La BBU può interrogare l’apparato per sapere quali funzioni siano disponibili. La specifica prevede, fra le altre, capacità relative a ricezione, trasmissione, full duplex, AGC, AFC, riferimenti di frequenza e modulazione o demodulazione di ampiezza, frequenza, fase e banda laterale unica.
Come viene configurata una RRU
Quando la BBU entra in comunicazione con una nuova unità radio, può iniziare richiedendo una stringa identificativa e la versione CARI supportata.
Successivamente può ottenere:
- numero dei sottodispositivi;
- capacità di ciascun sottodispositivo;
- intervallo delle frequenze;
- intervallo della potenza;
- guadagni disponibili;
- larghezze di canale;
- sample rate supportati;
- presenza del canale di supervisione.
A quel punto il software può configurare l’unità in modo coerente con i limiti dichiarati.
Se viene richiesto un valore non consentito, la RRU può restituire un errore. Fra i codici previsti figurano comando non supportato, frame malformato, impossibilità di aprire una porta ZeroMQ, errore di connessione e valore fuori intervallo.
Dal ripetitore monolitico al ripetitore distribuito
L’architettura tradizionale può essere definita monolitica perché quasi tutto risiede nello stesso apparato o nello stesso armadio.
Con CARI sarebbe invece possibile costruire un sistema distribuito:
ANTENNA
│
FILTRI E DUPLEXER
│
REMOTE RADIO UNIT
│
RETE ETHERNET O FIBRA
│
BASEBAND UNIT
│
MODEM, CONTROLLER, REFLECTOR E SERVIZILa RRU potrebbe essere installata vicino all’antenna, mentre la BBU potrebbe trovarsi in un ambiente più accessibile o perfino in una sede diversa.
Riducendo la lunghezza del cavo coassiale fra antenna e parte radio si potrebbero limitare le perdite RF. Il collegamento fra RRU e BBU sarebbe affidato alla rete dati, eventualmente attraverso fibra ottica.
La fattibilità concreta dipenderebbe comunque dalla quantità di dati generata dal flusso in banda base, dalla latenza, dal sample rate e dall’affidabilità del collegamento.
Non soltanto M17
Sebbene CARI sia nato nell’ecosistema M17, l’interfaccia non è legata obbligatoriamente a un unico protocollo vocale.
Una stessa RRU potrebbe teoricamente essere controllata da differenti applicazioni software per generare o ricevere:
- M17;
- FM analogica;
- modi dati;
- beacon;
- telemetria;
- modulazioni sperimentali;
- altri protocolli compatibili con le caratteristiche della catena RF.
Il limite non sarebbe imposto principalmente dal cablaggio interno dell’apparato, ma dalle capacità della RRU, dalla larghezza di banda disponibile e dal software della BBU.
Ciò non significa che qualsiasi modo sia automaticamente supportato. Per ogni protocollo occorrono modulatore, demodulatore, sincronizzazione, gestione delle trame e interfaccia utente.
Un possibile ripetitore multimodo
Un ripetitore basato su CARI potrebbe ricevere i campioni dalla RRU e analizzarli sulla BBU.
Il software potrebbe cercare di riconoscere il tipo di segnale in ingresso:
- portante analogica FM;
- segnale M17;
- trasmissione dati;
- altro modo digitale autorizzato.
Una volta identificato il modo, la BBU potrebbe attivare la catena di elaborazione appropriata.
La stessa infrastruttura RF potrebbe quindi diventare una piattaforma programmabile. L’aggiunta di una nuova modalità potrebbe richiedere soprattutto un aggiornamento software, purché la sezione radio disponga delle caratteristiche necessarie.
È una prospettiva tecnicamente interessante, ma richiede filtri adeguati, controllo rigoroso dei livelli, protezione del trasmettitore e verifiche strumentali sulle emissioni.
Telemetria e manutenzione predittiva
La disponibilità di dati di supervisione apre possibilità che vanno oltre il semplice allarme.
Registrando nel tempo temperatura, tensione, corrente e potenza riflessa, sarebbe possibile individuare variazioni progressive.
Per esempio:
- una corrente che aumenta lentamente può indicare il deterioramento di un componente;
- la potenza riflessa crescente può suggerire infiltrazioni o ossidazione;
- una temperatura anomala può anticipare un guasto alla ventilazione;
- oscillazioni della tensione possono segnalare problemi all’alimentatore;
- una riduzione della potenza diretta può evidenziare il degrado dello stadio finale.
CARI non esegue direttamente l’analisi predittiva, ma rende disponibili i dati necessari affinché applicazioni esterne possano archiviarli, rappresentarli e generare allarmi.
CARI e GNU Radio
GNU Radio rappresenta un possibile ambiente di elaborazione per la BBU.
Un’applicazione potrebbe essere costruita attraverso blocchi dedicati a:
- ricezione dei campioni CARI;
- correzione della frequenza;
- filtraggio;
- demodulazione;
- decodifica del protocollo;
- gestione dell’audio;
- instradamento verso la rete;
- produzione del segnale di trasmissione.
L’interfaccia CARI permetterebbe di sostituire una RRU con un modello differente senza dover riscrivere l’intera applicazione, a condizione che entrambi rispettino la stessa specifica e dichiarino correttamente le proprie capacità.
Questo è uno degli obiettivi più importanti di un’interfaccia standardizzata: ridurre la dipendenza tra software e hardware.
Sicurezza della rete
La documentazione CARI 1.3 descrive comandi, endpoint, telemetria e flussi ZeroMQ, ma non definisce un sistema completo di autenticazione o cifratura end-to-end. Ne consegue, come valutazione progettuale, che la sicurezza deve essere realizzata a livello di rete e di sistema operativo.
Una RRU non dovrebbe essere esposta direttamente su Internet.
Una configurazione prudente dovrebbe prevedere:
- rete separata o VLAN dedicata;
- firewall con accessi limitati;
- VPN fra BBU e postazione;
- autenticazione delle macchine;
- registrazione dei comandi;
- protezione delle porte di controllo;
- blocco automatico in caso di perdita della connessione;
- limiti hardware indipendenti dal software.
Un errore o un accesso non autorizzato non deve poter impostare frequenze o potenze incompatibili con l’hardware e con l’autorizzazione radioamatoriale.
Il problema della latenza
Trasferire campioni in banda base attraverso una rete richiede un collegamento stabile.
Una semplice variazione del ritardo può interrompere la continuità del flusso. Se i campioni arrivano troppo tardi, il sistema può produrre:
- vuoti audio;
- perdita di sincronizzazione;
- interruzioni della modulazione;
- ritardi nel PTT;
- discontinuità nella trasmissione.
Il collegamento BBU-RRU dovrebbe quindi essere trattato come un’infrastruttura real-time, soprattutto quando la modulazione viene generata interamente dal software.
Una rete locale Ethernet o in fibra è generalmente più prevedibile di un collegamento Internet pubblico. L’uso geografico di una RRU remota rimane possibile, ma richiede buffer, controllo temporale e strategie per la perdita della connessione.
Comportamento in caso di guasto
Un apparato sperimentale deve prevedere uno stato sicuro.
Se la BBU si blocca, la connessione cade o il flusso downlink si interrompe, la RRU dovrebbe:
- disattivare immediatamente il trasmettitore;
- impedire una portante continua;
- ripristinare valori sicuri;
- registrare l’evento;
- richiedere una nuova inizializzazione;
- comunicare l’anomalia al sistema di supervisione.
Le protezioni più importanti non dovrebbero dipendere unicamente dal software remoto. Limiti di potenza, timeout del PTT e protezioni termiche devono essere implementati anche localmente.
Possibile sperimentazione per D2ALP
Una rete come D2ALP potrebbe sperimentare CARI senza intervenire inizialmente sui ripetitori in servizio.
Un banco di prova potrebbe comprendere:
- una BBU Linux;
- una RRU a bassa potenza;
- un carico fittizio;
- attenuatori e strumenti di misura;
- una rete Ethernet isolata;
- un’applicazione GNU Radio;
- raccolta della telemetria;
- prove con M17 e FM.
La prima fase dovrebbe essere svolta esclusivamente su banco e senza irradiare segnali.
Successivamente si potrebbe realizzare un nodo simplex sperimentale. Soltanto dopo aver verificato stabilità, purezza spettrale, timeout e comportamento in caso di guasto avrebbe senso valutare un impiego su una postazione remota.
I vantaggi potenziali
CARI potrebbe offrire:
- separazione fra hardware RF e software;
- riutilizzo della stessa unità radio;
- possibilità di cambiare modulazione via software;
- telemetria standardizzata;
- maggiore facilità di sperimentazione;
- architetture distribuite;
- integrazione con SDR e GNU Radio;
- minore dipendenza da un singolo costruttore;
- possibilità di sviluppare unità interoperabili.
I limiti attuali
CARI resta un progetto giovane.
Le difficoltà principali riguardano:
- disponibilità limitata di hardware compatibile;
- necessità di competenze SDR e di rete;
- mancanza di un ecosistema commerciale;
- gestione della latenza;
- dimensionamento della banda;
- sincronizzazione;
- sicurezza;
- verifica delle emissioni;
- affidabilità del software;
- protezioni hardware;
- interoperabilità ancora da dimostrare su larga scala.
Gli aggiornamenti pubblicati nel gennaio 2026 hanno chiarito la selezione dei dispositivi, il formato dei comandi e il trasferimento della telemetria, distinguendo formalmente il piano di controllo da quello di supervisione. Le modifiche erano chiarimenti della specifica e non hanno comportato un incremento del numero di versione.
Conclusione
CARI non è ancora una soluzione pronta per sostituire i ripetitori commerciali.
È però una proposta molto interessante perché affronta un problema centrale della radio definita dal software: creare un’interfaccia comune fra elaborazione digitale e sezione RF.
Il suo valore non consiste soltanto nel controllare una radio attraverso la rete. La vera innovazione è la possibilità di rendere indipendenti hardware e software.
Una RRU potrebbe continuare a svolgere il proprio lavoro mentre modem, protocolli e applicazioni evolvono sulla BBU. Un nuovo modo operativo potrebbe essere aggiunto senza ricostruire completamente l’impianto.
CARI rappresenta quindi un possibile passo verso ripetitori più aperti, modulari e programmabili: non più apparati chiusi dedicati a un solo protocollo, ma piattaforme sulle quali i radioamatori possano tornare a sperimentare.