OpenX6X00 v0.3.7 introduce i band plan regionali e migliora Winlink sulle radio Xiegu

L’ultima versione del firmware sviluppato dalla community aggiunge alle Xiegu X6100 e X6200 band plan adattati alle diverse regioni, un flusso di lavoro Winlink più chiaro e il modem sperimentale Mercury. Mostra inoltre quanto possa cambiare una moderna radio definita via software grazie ai programmi eseguiti direttamente al suo interno.

Per molto tempo un ricetrasmettitore HF è stato caratterizzato soprattutto dal pannello frontale e dal firmware fornito dal produttore. OpenX6X00 cambia questa prospettiva per le Xiegu X6100 e X6200. La versione 0.3.7 aggiunge i band plan delle diverse regioni IARU, le limitazioni legate alle classi di licenza statunitensi, una gestione rinnovata di Winlink e il modem sperimentale Mercury. Queste novità si affiancano alle applicazioni per i modi digitali, alla registrazione dei QSO, al controllo tramite browser e ad altri programmi eseguiti direttamente sulla radio.

La differenza ha conseguenze pratiche. Un computer portatile può aggiungere modi digitali e funzioni di rete a quasi qualsiasi ricetrasmettitore, ma comporta anche uno schermo in più, altri cavi e un altro dispositivo da alimentare e configurare. OpenX6X00 integra molte di queste funzioni nell’ambiente informatico già presente nella radio. Non si tratta quindi soltanto di una nuova interfaccia: il software consente di collegare l’attività radio, la registrazione e alcune funzioni di rete in un unico sistema.

La versione 0.3.7 segna un passo avanti in questa direzione. Non introduce un nuovo stadio RF e non modifica il firmware baseband che gestisce le funzioni fondamentali del ricetrasmettitore. Amplia invece il modo in cui la componente Linux della radio interpreta le regole operative, presenta le comunicazioni digitali e protegge i controlli accessibili via web. Le modifiche mostrano anche le sfide che un progetto di firmware aperto deve affrontare: integrare le nuove funzioni su due radio correlate, considerare le differenze tra i piani operativi nazionali e mantenere un comportamento sicuro quando i servizi sono raggiungibili dalla rete locale o da remoto.

Da interfaccia alternativa a piattaforma software

OpenX6X00 funziona sulla parte Linux delle X6100 e X6200 e viene eseguito da una scheda microSD. Le radio mantengono un firmware baseband separato per funzioni come DSP, RF, gestione della potenza e keyer. OpenX6X00 comunica con questa componente, ma non la sostituisce. La separazione consente al progetto di far evolvere l’interfaccia e le applicazioni facendo affidamento sul firmware esistente per le funzioni fondamentali del ricetrasmettitore.

È una distinzione importante, perché l’espressione «firmware aperto» potrebbe far pensare che ogni componente della radio sia stato sostituito o possa essere modificato liberamente. In questo caso il progetto controlla un livello software significativo, ma il baseband rimane una componente distinta fornita da Xiegu. Sistema operativo, applicazioni, interfaccia di controllo e strumenti web possono cambiare indipendentemente dal firmware che gestisce l’hardware radio. Per l’utente, questo significa che una funzione disponibile in OpenX6X00 può comunque dipendere da ciò che il baseband sottostante mette a disposizione.

Anche la storia del progetto aiuta a comprenderne la portata. OpenX6X00 è nato come fork dell’ultima versione aperta del firmware per X6100, dopo che il progetto originale era diventato chiuso. I manutentori dichiarano di aver rimosso i servizi che comunicavano con l’esterno e di aver proseguito lo sviluppo in modo aperto. Nel tempo, il sistema ha integrato un pannello di controllo via browser, una visualizzazione del DX cluster, funzioni di logging, programmi per le attività outdoor e diversi modi digitali. La nuova versione amplia questo ambiente software invece di trattare ogni funzione come un accessorio separato.

Il computer integrato cambia la struttura di una stazione portatile. Quando un’applicazione per i modi digitali viene eseguita sulla radio, può non essere necessario collegare un computer per decodificare o trasmettere nei modi supportati. Se sulla stessa piattaforma sono disponibili anche un logbook e strumenti per le attivazioni, alcune operazioni si possono svolgere senza passare da un dispositivo all’altro. Il controllo tramite browser offre un’altra possibilità: uno smartphone, un tablet o un computer nella rete locale può gestire la radio attraverso un’interfaccia web. Nel complesso, queste funzioni riducono la dipendenza da un computer esterno per molte attività digitali e connesse.

L’integrazione ha comunque dei limiti. I comandi fisici, il display, i percorsi audio e le capacità del baseband continuano a determinare ciò che il software può fare. Un’applicazione Linux può introdurre un nuovo flusso operativo, ma non può eliminare i vincoli dell’hardware né garantire che ogni funzione si comporti allo stesso modo sui due modelli. La distinzione tra livello applicativo e baseband è particolarmente utile quando si confrontano le funzioni del firmware, si cerca la causa di un problema o si decide se installare un aggiornamento. Una piattaforma software più ricca amplia gli usi della radio, ma il progetto hardware continua a stabilirne i confini.

Band plan adattati alla regione dell’operatore

La novità più evidente della versione 0.3.7 è probabilmente il sistema ampliato per i band plan. Nelle versioni precedenti, la fascia dedicata al piano di banda sul display conosceva solo il piano della Regione 1 IARU. La nuova versione aggiunge le Regioni 2 e 3 e i piani statunitensi per le classi di licenza Extra, Advanced, General e Technician. La visualizzazione diventa così più utile per gli operatori le cui allocazioni differiscono da quelle previste dal piano inizialmente supportato.

Un band plan non è soltanto un’etichetta sullo schermo. Aiuta l’operatore a capire dove determinati tipi di emissione siano appropriati o consentiti e orienta le scelte durante la sintonia. Il nuovo sistema può mostrare il piano selezionato nella fascia dedicata, anche nel pannello del browser. Inoltre influisce su funzioni correlate dell’interfaccia, come la selezione del modo in base al band plan e l’indicazione dei segmenti CW. Nei piani statunitensi, le porzioni non disponibili per la classe di licenza selezionata vengono visualizzate in grigio, con l’indicazione “out” dove applicabile.

La selezione automatica utilizza le informazioni di posizione disponibili per scegliere una regione IARU. Cerca prima un fix GPS, poi il locator Maidenhead configurato e infine il paese associato al nominativo. Se nessuno di questi dati è disponibile, la radio mantiene la regione selezionata in precedenza. Questa sequenza è adatta a una radio portatile, che può essere utilizzata in luoghi diversi, e offre comunque una soluzione di riserva agli operatori senza GPS o senza locator configurato.

La selezione automatica non sceglie intenzionalmente un piano statunitense legato alla classe di licenza. Sapere che la radio si trova negli Stati Uniti non basta a determinare i privilegi dell’operatore. Il solo piano regionale non può fare questa distinzione, perciò gli operatori statunitensi devono selezionare manualmente il paese e la propria classe. È una scelta sensata: l’automazione può semplificare la configurazione quando le informazioni necessarie sono disponibili, ma non dovrebbe indovinare un dato regolamentare che il sistema non è in grado di conoscere.

In alcuni casi il piano regionale modifica anche l’elenco delle bande della radio. Nelle Regioni 2 e 3, le voci 160 m, 80 m, SSB sui 40 m e 6 m possono assumere i limiti previsti dalla regione al primo avvio dopo l’aggiornamento, purché l’operatore non abbia già modificato quelle voci. Nella Regione 1, i limiti esistenti non vengono spostati da questa modifica. La differenza è rilevante perché gli intervalli fissi adatti a una regione potrebbero non corrispondere alle allocazioni o alle prassi operative di un’altra.

Per chi opera in portatile, questa funzione può ridurre piccole ma significative discrepanze nell’interfaccia. Una radio portata oltre confine, configurata per un’altra regione o utilizzata secondo un diverso piano nazionale dovrebbe mostrare informazioni coerenti con quel contesto. Il band plan visualizzato non sostituisce la conoscenza delle normative applicabili e una singola impostazione non può rappresentare tutte le varianti nazionali. Può però rendere più visibile il contesto operativo selezionato e aiutare ad allineare la visualizzazione della sintonia alle sue regole.

Il progetto dichiara di aver testato la visualizzazione e le voci dell’elenco delle bande su una versione PC e su una X6100 da banco, con i piani di Regione 2, Regione 3, US General e US Technician. È un’indicazione utile sul comportamento dell’interfaccia, ma non equivale a una certificazione normativa formale né a una verifica esaustiva di ogni possibile combinazione di località e licenza. Secondo le note di rilascio, la selezione automatica basata su un fix GPS non è stata provata su una radio. È bene tenere presenti queste precisazioni: il riconoscimento regionale è una funzione pratica, ma resta responsabilità dell’operatore scegliere e rispettare i privilegi corretti.

Winlink si avvicina a un flusso operativo gestito dalla radio

Winlink è uno degli aspetti più importanti dell’aggiornamento, perché collega il servizio di radioamatore alla posta elettronica e alla messaggistica store-and-forward trasmesse attraverso reti radio. In HF può essere utile quando l’accesso convenzionale a Internet non è disponibile o quando l’operatore vuole scambiare messaggi tramite un gateway radio. Il flusso Winlink di OpenX6X00 utilizza ARDOP, un protocollo digitale progettato per le comunicazioni dati via radio. La nuova versione punta a rendere il processo di connessione più leggibile e gli eventuali problemi più facili da diagnosticare.

L’interfaccia aggiornata introduce una scheda “Before you connect”, che mostra in che modo Winlink utilizzerà la radio. Una scheda dedicata alla connessione spiega perché un tentativo è fallito e quali passi successivi potrebbero essere utili. Il software non si limita quindi a presentare un pulsante di connessione: prova a rendere più comprensibili le condizioni necessarie e le ragioni dell’insuccesso. Durante la diagnosi di una connessione HF, queste informazioni possono essere più utili di un generico messaggio di errore, soprattutto perché configurazione della radio, impostazioni del modem e disponibilità del gateway contribuiscono tutte al risultato.

È stato rivisto anche il comportamento della larghezza di banda ARDOP. La pagina della radio ora utilizza la banda ARDOP più ampia per ogni connessione. Nella configurazione descritta, il valore predefinito è 500 Hz quando l’elenco dei gateway richiede un’impostazione 2000MAX. Le note di rilascio indicano inoltre che viene conservata una password inserita nelle impostazioni dell’applicazione stessa. Possono sembrare dettagli minori, ma contribuiscono a rendere affidabile uno strumento integrato durante una sessione operativa reale.

Altre modifiche riguardano i controlli e i log mentre un’applicazione digitale è aperta. In quella condizione la tastiera non è disponibile, e i log possono essere scaricati insieme con le password oscurate. Le misure rispondono a due esigenze diverse: evitare interazioni inappropriate mentre un’applicazione controlla la radio e limitare l’esposizione non necessaria di informazioni sensibili nei log esportati. Una radio capace di comunicare in rete deve considerare la propria configurazione e i dati memorizzati come parte integrante dell’ambiente operativo.

La versione 0.3.7 aggiunge Mercury come seconda opzione modem sperimentale per Winlink. Mercury è associato al progetto HERMES e la compatibilità prevede un requisito preciso: la stazione remota deve utilizzare Mercury 1.9.20 o una versione successiva. La descrizione del rilascio indica che in Pat si seleziona Mercury tramite l’opzione VARA HF. Gli operatori dovrebbero conoscere questo particolare prima di provare a connettersi. Poiché Mercury è sperimentale in questa versione, la sua presenza va considerata una funzionalità aggiuntiva in fase di sviluppo, non una garanzia di compatibilità con tutti i gateway o client Winlink.

Questa precisazione è importante nelle reti radio. Un modem è utile solo se l’altra estremità è in grado di scambiare dati usando un protocollo e una configurazione compatibili. Un’implementazione locale può essere tecnicamente completa ma avere una portata pratica limitata se il resto della rete non ha adottato il protocollo. Nell’immediato, Mercury può quindi essere utile soprattutto per esperimenti, test e primi utilizzatori in grado di coordinarsi con stazioni compatibili. La sua utilità più ampia dipenderà dall’adozione al di fuori della radio stessa.

Il lavoro su Winlink evidenzia anche una sfida progettuale più generale. Un’applicazione eseguita sulla radio deve gestire decisioni che un programma desktop potrebbe distribuire su più finestre: quale modem è attivo, quale larghezza di banda viene richiesta, se la radio è pronta a trasmettere e cosa è successo dopo una connessione fallita. Riunire questi elementi può semplificare la stazione, ma rende essenziale la chiarezza dell’interfaccia. Se nasconde uno stato importante, una configurazione compatta può diventare più difficile da diagnosticare rispetto a una soluzione basata su laptop.

Modi digitali e stazione portatile

Le altre funzioni di OpenX6X00 aiutano a comprendere il contesto delle novità di Winlink. Il progetto supporta applicazioni eseguite sulla radio per modi quali FT8, FT4, FT2, JS8, WSPR, PSK31, PSK63, Olivia, RTTY, SSTV, WeFax e Navtex con DSC in sola ricezione. Il livello di supporto preciso varia in base all’applicazione e al modo, ma l’idea generale resta la stessa: l’ambiente Linux della radio ospita software che normalmente verrebbe eseguito su un computer collegato. La versione 0.3.7 si basa su questa piattaforma invece di introdurre da zero l’operatività digitale.

Questo può cambiare la configurazione fisica di una stazione portatile. Un operatore sul campo potrebbe già portare un ricetrasmettitore, una batteria, un’antenna e un telefono o tablet per mappe e log. Aggiungere un laptop per ogni modo digitale aumenta peso e consumo energetico, oltre a richiedere altri cavi e configurazioni software. Spostando alcune di queste attività nella radio, la stazione può diventare più autonoma. Ciò non rende superflui tutti i computer: un display più grande, gli strumenti di logging abituali o software specializzati possono restare preferibili. La radio, però, è in grado di svolgere direttamente una parte maggiore del lavoro essenziale.

I diversi modi impongono esigenze operative differenti. FT8 e i modi correlati per segnali deboli richiedono una temporizzazione precisa, una decodifica affidabile e trasmissioni sincronizzate. WSPR viene spesso utilizzato per osservare la propagazione attraverso beacon a bassa potenza. JS8 supporta messaggi digitati e operazioni basate sui relay. Winlink risponde a un’esigenza diversa e trasmette messaggi attraverso gateway. Riunire questi strumenti nella radio può rendere più semplice passare dalla sperimentazione ai QSO e alla messaggistica pratica senza ricostruire ogni volta la stazione attorno a un computer separato.

Display e comandi fanno parte della stessa esperienza. Un waterfall può rappresentare i segnali in modo da facilitare la sintonia e l’interpretazione dell’attività. Una vista del cluster può collegare gli spot alla sintonia della radio. Il controllo tramite browser consente di utilizzare un dispositivo familiare come interfaccia remota. Il valore deriva dalla relazione tra queste funzioni: uno spot può guidare una scelta di frequenza, un’applicazione digitale può gestire una trasmissione e un log può registrare il QSO nello stesso ambiente software.

L’integrazione concentra anche la complessità. Un’applicazione digitale deve accedere in modo affidabile all’audio, alla frequenza e al controllo di trasmissione. Un’interfaccia browser deve comunicare con la radio senza consentire a una pagina non attendibile di abusare dei comandi. Il log deve conservare dati corretti sui QSO e i servizi di rete devono distinguere gli utenti previsti dagli altri client. Ogni funzione può sembrare semplice se considerata isolatamente, ma la loro interazione richiede progettazione e test accurati.

La storia degli aggiornamenti del progetto mostra questa sfida. Le versioni precedenti hanno aggiunto il supporto alla X6200, il controllo remoto tramite browser, Winlink in HF e altre funzioni. Nel corso dello sviluppo sono emersi anche difetti nella registrazione, nel controllo TCI, nel PTT via browser e in altri componenti. I manutentori dichiarano che una revisione della versione 0.3.6 ha individuato 14 difetti, tra cui problemi nel PTT del browser, nel configuratore, in TCI e nell’interfaccia web. La nuova versione li corregge e mostra come il lavoro su un firmware aperto consista sia nell’aggiungere capacità sia nel sistemare le interazioni tra quelle già presenti.

La sicurezza entra a far parte dell’operatività radio

Una radio dotata di configuratore web, controllo remoto via browser e servizi di rete ha un profilo di sicurezza diverso rispetto a un apparato gestito soltanto da comandi fisici. La versione 0.3.7 introduce una protezione contro il DNS rebinding, un tipo di attacco in cui un sito malevolo può far sì che un browser interpreti un nome controllato dal sito come se puntasse a un dispositivo della rete locale. Se il browser può raggiungere le pagine di configurazione o controllo della radio, una progettazione vulnerabile potrebbe esporre impostazioni o consentire azioni tramite la sessione browser dell’utente.

OpenX6X00 v0.3.7 limita alcune operazioni web ai nomi propri della radio, come il suo hostname locale o un nome configurato per essa. La restrizione si applica al salvataggio delle modifiche nel configuratore web e alle pagine e connessioni correlate, mentre i programmi TCI possono continuare a connettersi usando qualunque nome. La distinzione risponde a un’esigenza pratica: le interfacce di controllo via browser e quelle usate per la comunicazione tra programmi non necessitano sempre delle stesse regole sui nomi. Limitare alcuni interventi web sensibili a determinati nomi può ridurre il rischio che un sito inganni il browser e lo induca a interagire con la radio.

Il lavoro sulla sicurezza di questa versione si inserisce in una serie di audit e revisioni del codice. Il progetto dichiara che la revisione di v0.3.6 ha individuato 14 difetti, corretti nella v0.3.7. Audit indipendenti precedenti avevano portato a correzioni anche nel controllo TCI, nella gestione dei dati ADIF, nella modifica dei log e nel comportamento delle sessioni browser. Non sono problemi soltanto estetici. Un errore nel controllo della trasmissione può influire sulla corretta commutazione tra trasmissione e ricezione, mentre un difetto nella gestione dei dati può corrompere i log o rendere instabile il sistema.

L’attenzione dedicata al PTT via browser è particolarmente importante perché il controllo remoto cambia il significato del pulsante di trasmissione. Un interruttore sul pannello è fisicamente associato all’operatore e alla radio. Un comando browser dipende dalla connessione di rete e dallo stato del software. Se la connessione si blocca e poi riprende, l’interfaccia non deve attivare inaspettatamente il trasmettitore sulla base di un comando rimasto in sospeso. Le note di rilascio descrivono la correzione di un caso in cui un PTT browser tenuto premuto poteva riattivare la trasmissione dopo il ripristino di un collegamento interrotto. È un caso limite che un’interfaccia ben progettata deve gestire esplicitamente.

La sicurezza influenza anche il modo in cui viene offerto l’accesso remoto. OpenX6X00 può utilizzare Tailscale per il controllo a distanza e la versione 0.3.7 aggiunge il supporto a Tailscale Funnel, che rende raggiungibili dall’esterno della rete locale alcune pagine browser. Il rilascio distingue le pagine Panel e Screen dagli altri servizi, come il configuratore, i programmi TCI e le applicazioni Winlink. La distinzione è importante perché “accesso remoto” non equivale a un’unica autorizzazione: un pannello di controllo in tempo reale, un’interfaccia di configurazione e un servizio di rete offrono capacità diverse e comportano rischi differenti.

La funzione Funnel presenta limiti specifici. Il browser deve essere associato alla radio prima di poter utilizzare il collegamento remoto. Un browser associato a casa può ricevere un link distinto da usare fuori casa. Il servizio pubblico è limitato alle pagine Panel e Screen e ai relativi socket; per accedere serve un browser associato in precedenza dalla rete domestica. Gli altri servizi non vengono esposti tramite Funnel. La funzione è stata testata contro un sostituto del demone Tailscale e su una versione PC, ma non ancora su un tailnet reale e su una radio reale. I manutentori chiedono quindi di ricevere segnalazioni dagli utenti che la provano in quell’ambiente.

La funzione è più di un semplice interruttore di comodità. Pubblicare un servizio su Internet cambia chi può tentare di raggiungerlo e quale tipo di autenticazione è necessario. OpenX6X00 separa l’accesso del browser remoto dagli altri servizi della radio e richiede un’associazione precedente. Il progetto avverte anche che il nome host pubblico diventa visibile nei registri pubblici dei certificati. Chi non ha bisogno del controllo remoto via browser può lasciare Funnel disattivato; chi lo utilizza dovrebbe sapere quali pagine diventano raggiungibili e quali restano escluse.

Limiti di potenza, manutenzione e significato della versione 0.3.7

Il comportamento della potenza di trasmissione della X6200 è un’altra modifica rilevante nell’uso pratico. Con la versione 0.3.7, l’interfaccia limita la potenza selezionabile a 8 W e a 5 W quando la radio è alimentata a batteria. Un limite software può essere utile come misura di protezione, soprattutto in una stazione portatile la cui alimentazione può cambiare, ma non va confuso con un’affermazione generale sulla potenza massima della radio. È un limite imposto dal comportamento di controllo di questo firmware e può influire sulla configurazione scelta in base alla fonte di alimentazione.

Il rilascio corregge anche diversi comportamenti secondari. Il livello Moni della X6100 è ora impostato per default a zero, come sulla X6200, ma il valore impostato dall’operatore viene conservato. Quando un VFO viene sintonizzato oltre il limite di una banda, l’altro mantiene la propria posizione. Sono stati inoltre risolti difetti nel controllo browser, in TCI, nei moduli Wavelog e nel configuratore. Ogni correzione contribuisce a un funzionamento più prevedibile, anche quando non introduce una nuova funzione di primo piano.

Chi utilizza già OpenX6X00 può avviare l’aggiornamento direttamente dalla radio. Le note di rilascio indicano che una X6100 o una X6200 con un’installazione compatibile v0.2.x o v0.3.x può ricevere la versione attraverso la funzione di aggiornamento integrata. Sono disponibili nuove immagini della scheda per le prime installazioni e per le radio che non riescono più ad avviarsi abbastanza a lungo da eseguire l’aggiornamento. Alcune immagini più datate devono essere sostituite per ottenere modifiche precedenti al bootloader o al driver Wi-Fi. Queste esigenze dipendono però dal modello e dalla versione installata: non tutti devono riscrivere la scheda per installare v0.3.7.

La separazione tra pacchetto di aggiornamento e immagine della scheda è un vantaggio pratico dell’architettura. Applicazioni e pagine web possono essere aggiornate senza riscrivere l’intera immagine di sistema se kernel, driver e componenti di avvio non sono cambiati. Il progetto dichiara che, per installare v0.3.7, non serve una nuova immagine sulle radio che utilizzano già una delle immagini precedenti compatibili. Impostazioni e log restano nella partizione dati della scheda, anche se viene comunque consigliato di creare un backup prima di aggiornare. Separare il sistema operativo dalle applicazioni può rendere la manutenzione meno invasiva, ma gli utenti devono sapere in quali casi è necessaria un’immagine completa.

Anche il rollback fa parte del sistema di aggiornamento. La radio mantiene disponibile la versione precedente per tornare automaticamente indietro se la nuova installazione non si avvia correttamente. Questo non elimina l’utilità di salvare configurazione e log, né rende privo di rischi qualsiasi aggiornamento. Offre però un meccanismo di recupero importante in un dispositivo embedded, dove altrimenti un errore potrebbe richiedere una procedura più complessa per riscrivere la scheda.

Il progetto evidenzia anche una tendenza più ampia nel settore radioamatoriale. I ricetrasmettitori SDR integrano sempre più spesso hardware informatico general purpose, connettività di rete e interfacce definite via software. Questo rende possibile aggiungere funzioni anche dopo la vendita della radio, ma porta la qualità della manutenzione software a far parte del suo valore nell’uso quotidiano. Logica dei band plan, interoperabilità dei modem, sicurezza del browser, integrità dei log e controllo della potenza sono tutti aspetti software che influenzano il funzionamento reale. Lo sviluppo aperto consente agli utenti di capire queste modifiche e segnalare problemi, ma chiede anche ai manutentori di mantenere coerente un sistema in continua crescita.

OpenX6X00 v0.3.7 è quindi più di un elenco di novità. I band plan regionali rendono l’interfaccia più adatta agli operatori che si trovano in diverse parti del mondo. Le modifiche a Winlink puntano a rendere le connessioni più comprensibili e Mercury offre alle stazioni compatibili una possibilità sperimentale in più. Le correzioni di sicurezza e le verifiche del codice mostrano come il controllo remoto via browser sia anche una questione di affidabilità operativa. Nel complesso, il rilascio trasforma le Xiegu X6100 e X6200 in piattaforme in cui il firmware contribuisce a definire come un ricetrasmettitore viene utilizzato, collegato in rete e mantenuto nel tempo.

Le immagini utilizzate in questo articolo sono generate tramite IA...

Questo articolo può contenere link di affiliazione...