Le origini del Progetto Olliter

Il progetto "Il mio SDR" nasce nel 2010, quando Mauro I2SUH, ispirato dai primi ricetrasmettitori SDR disponibili in commercio, iniziò a progettare e costruire una radio SDR interamente autocostruita. Il sistema originale si basava su un'architettura FPGA ed era controllato tramite PowerSDR, che all'epoca rappresentava una piattaforma solida e flessibile per la sperimentazione.

Quel primo prototipo fu solo l'inizio. Negli anni successivi il progetto divenne uno strumento per approfondire l'elaborazione digitale dei segnali sia in RF sia in bassa frequenza, fino a un modello hardware più raffinato completato nel 2019. Nello stesso periodo Mauro iniziò a collaborare con il team Olliter, portando il progetto in un contesto tecnico e collaborativo più ampio. Fu l'inizio ufficiale dell'OL-SDR come lo conosciamo oggi.

Una ripartenza necessaria e un salto in avanti

Mentre i primi prototipi pronti per la produzione si avvicinavano alla realizzazione, arrivò la pandemia. La grave carenza di componenti, in particolare di FPGA, rese impossibile proseguire con il progetto originale.

A differenza dei sistemi basati su microcontrollore, le piattaforme FPGA non si possono migrare semplicemente cambiando le opzioni del compilatore o l'assegnazione dei pin. Un cambio di questo tipo richiede la riprogettazione completa della logica, dell'architettura e del flusso del segnale, oltre alla riscrittura integrale del firmware. Di fronte a questo vincolo, alla vigilia del primo rilascio hardware, il team scelse di non limitarsi ad adattare il progetto esistente, ma di cogliere l'occasione per ripensare l'intera piattaforma.

Furono valutate famiglie di FPGA più moderne e capaci, fu progettata una nuova scheda filtri RX/TX e l'intera architettura del sistema fu rivista, con l'obiettivo di migliorare ulteriormente le prestazioni, già elevate, del concetto originale. Questo lavoro culminò nella prima metà del 2022 con la produzione della versione da 20 W, che si distinse subito per le sue prestazioni eccezionali.

Origini del software ed evoluzione dell'architettura

Dal punto di vista software, le prime versioni del progetto Olliter SDR risalgono al 2016 e derivavano da PowerSDR. All'epoca PowerSDR e i suoi derivati fornivano non solo l'interfaccia grafica, ma anche l'intero framework di elaborazione DSP, la logica di controllo del dispositivo e la comunicazione.

Fu una scelta voluta e pragmatica. PowerSDR sembrava un buon punto di partenza: non era abbastanza solido e maturo per una piattaforma commerciale destinata a durare nel tempo, ma offriva una base affidabile per validare i primi prototipi hardware.

In quelle prime versioni, lo stack software dipendeva interamente da PowerSDR per l'elaborazione del segnale, l'interazione con l'utente e il controllo dell'hardware. Questo permise al progetto di concentrarsi sul progetto RF, sull'architettura FPGA e sulle prestazioni complessive del sistema, appoggiandosi a un ecosistema software esistente e collaudato invece di reinventarlo prematuramente.

Con l'evoluzione dell'hardware, in particolare con l'introduzione delle nuove piattaforme FPGA e la riprogettazione dei sottosistemi RX e TX, il modello originale centrato su PowerSDR iniziò a mostrare i suoi limiti. Larghezze di banda maggiori, velocità di trasferimento più elevate e la necessità di integrazioni più flessibili richiedevano un'architettura software capace di andare oltre i vincoli del progetto originale. Iniziò così una transizione architetturale graduale ma deliberata.

Disaccoppiamento progressivo e dipendenze attuali

Nel tempo OL-Master si è progressivamente svincolato da una stretta dipendenza da PowerSDR. Aree fondamentali come la gestione dei dispositivi, i livelli di comunicazione e parti significative della catena DSP sono state riscritte o ristrutturate, per supportare un throughput più elevato, più ricevitori simultanei e una maggiore interoperabilità con strumenti e servizi esterni.

Nonostante questa evoluzione architetturale, OL-Master continua a basarsi su alcuni componenti esterni chiaramente identificati. Queste dipendenze sono documentate esplicitamente per evitare ambiguità o fraintendimenti e attualmente comprendono, tra le altre:

• WDSP, usata per specifiche funzioni di elaborazione DSP
• ChannelMaster, la libreria di comunicazione che gestisce i flussi di dati ad alto throughput provenienti dall'FPGA
• PortAudio, usata per interfacciarsi con il sottosistema audio di Windows e gestire flussi audio a bassa latenza
• Componenti grafici e concetti architetturali provenienti dall'ecosistema PowerSDR
• Altre librerie di terze parti, ciascuna distribuita con la propria licenza, usate per l'integrazione con servizi e strumenti esterni come MQTT, N1MM, EiBi e altri

Un modello di sviluppo guidato dalla community

Fin dalle prime fasi, il progetto Olliter è stato sostenuto da una community di collaboratori, tester e utenti tecnicamente preparati. Questa community ha sempre avuto un ruolo attivo nella sperimentazione, nel feedback e nello sviluppo di nuove funzioni.

Il progetto, tuttavia, non è stato aperto da subito a contributi esterni senza restrizioni. L'obiettivo iniziale era costruire una base tecnica solida, stabile e ben compresa, sia hardware sia software, prima di ampliare la collaborazione.

Il modello di community attuale riflette questa intenzione originaria: offrire un ambiente strutturato in cui gli sviluppi possano essere revisionati, validati e, quando opportuno, certificati per l'inclusione nel ramo ufficiale del progetto.

Gli sviluppatori esterni sono liberi di creare estensioni, plugin o implementazioni alternative indipendentemente dalla community ufficiale. Questi sviluppi sono benvenuti e incoraggiati, ma non ricevono automaticamente certificazione ufficiale o garanzie di compatibilità, a meno che non seguano i processi di contribuzione e revisione definiti.

Struttura del progetto e modello di community

Questa sezione descrive come è strutturato il progetto OL-Master, come la community può partecipare e come si ottiene l'estensibilità preservando qualità tecnica, chiarezza legale e sostenibilità a lungo termine.

L'obiettivo di questo modello è favorire la sperimentazione e la collaborazione senza compromettere l'integrità del software, il rispetto delle licenze o l'affidabilità degli apparati Olliter e delle release ufficiali.

1. Panoramica della struttura del progetto

L'ecosistema OL-Master è organizzato attorno a una netta separazione tra il Progetto Core e i Componenti esterni (plugin e integrazioni).

Questa separazione è intenzionale ed è fondamentale per la stabilità della piattaforma.

OL-Master Core

Il Core comprende tutti i componenti software essenziali per il funzionamento corretto e sicuro degli apparati radio Olliter, tra cui, a titolo non esaustivo:

• Controllo dell'hardware e gestione dei dispositivi
• Elaborazione DSP principale in RX e TX
• Logica di temporizzazione, sincronizzazione e sicurezza
• Protocolli di comunicazione ufficiali tra software e hardware Olliter
• API pubbliche e relative implementazioni di riferimento
• Configurazione, persistenza e servizi di sistema

Caratteristiche del Core:

• Mantenuto e rilasciato dal core team Olliter
• Versionato e testato sull'hardware supportato
• Distribuito con licenza GNU General Public License versione 3 (GPLv3), in continuità con PowerSDR
• Soggetto a revisione, validazione e approvazione prima dell'inclusione nelle release ufficiali

Il Core rappresenta la base stabile e supportata dell'ecosistema OL-Master.

Plugin e componenti esterni

I plugin e i componenti esterni comprendono tutte le estensioni opzionali o non essenziali, come:

• Decodificatori, codificatori o elaboratori di segnale aggiuntivi
• Estensioni dell'interfaccia utente o front-end alternativi
• Integrazioni con software o servizi di terze parti
• Sistemi di automazione, controller e interfacce hardware personalizzate
• Funzioni sperimentali non destinate al Core

Caratteristiche dei plugin:

• Sviluppati e distribuiti indipendentemente dal Core
• Interagiscono con OL-Master esclusivamente tramite API pubbliche documentate
• Possono adottare modelli di licenza diversi, purché restino compatibili con la licenza del Core
• Possono essere mantenuti da singoli sviluppatori, gruppi o terze parti

Questo modello permette innovazione e personalizzazione senza destabilizzare il progetto Core.

2. Politica di supporto ufficiale

Componenti supportati ufficialmente

Olliter fornisce supporto ufficiale per:

• L'OL-Master Core distribuito tramite i repository ufficiali
• Le API pubbliche, come documentate per ciascuna versione supportata
• Plugin ed estensioni:
  • sviluppati da Olliter, oppure
  • dichiarati esplicitamente Olliter-compatible o Olliter-certified
• Apparati Olliter usati con firmware e software ufficiali

"Supporto ufficiale" significa che il componente è testato, documentato, mantenuto e considerato compatibile con le release hardware e software correnti.

Componenti non supportati

Olliter non fornisce supporto ufficiale per:

• Fork o versioni modificate del Core non approvate dal core team
• Modifiche dirette al Core distribuite al di fuori dei canali ufficiali
• Plugin basati su interfacce private, non documentate o ottenute tramite reverse engineering
• Software o integrazioni che violano licenze di terze parti
• Configurazioni hardware diverse da quelle documentate o supportate

3. Estendere OL-Master in modo sicuro e corretto

Per preservare chiarezza legale e integrità tecnica, le estensioni dovrebbero seguire questi principi:

• Le estensioni devono usare solo API pubbliche documentate
• Il Core non deve essere modificato direttamente da componenti esterni
• Attribuzioni, note di copyright e intestazioni di licenza non devono essere rimosse o alterate
• Il codice del Core coperto da GPL non deve essere incorporato in componenti proprietari in violazione della licenza

I plugin possono essere distribuiti con la licenza scelta dallo sviluppatore, purché non impongano restrizioni sul Core né presentino come proprietario codice coperto da GPL.

Questi principi definiscono ciò che Olliter può supportare e certificare. Non limitano i diritti di usare, studiare, modificare e ridistribuire OL-Master che la GPL concede a ogni utente.

4. Contributi al progetto Core

I contributi all'OL-Master Core sono benvenuti, ma seguono regole precise:

• Tutti i contributi devono essere inviati tramite il processo di contribuzione ufficiale (ad esempio pull request)
• L'origine del codice proposto deve essere dichiarata chiaramente
• I contributori devono accettare i termini di licenza del progetto Core
• Il core team Olliter mantiene piena discrezionalità nell'accettare, modificare o rifiutare i contributi

L'inclusione nel Core si basa su qualità tecnica, manutenibilità, coerenza architetturale e impatto a lungo termine sul progetto.

5. Filosofia della community

Il progetto OL-Master è aperto, ma non è privo di struttura.

• L'apertura favorisce collaborazione, apprendimento e innovazione
• La struttura garantisce stabilità, sicurezza e sostenibilità nel lungo periodo
• Il valore del progetto sta nel suo ecosistema, non nel controllo esclusivo del codice

Questo modello permette alla community di crescere attorno a una base tecnica condivisa, lasciando a Olliter la responsabilità dell'integrità della piattaforma Core e del suo hardware.

Linee guida per i contributi

Queste linee guida definiscono come singoli e organizzazioni possono contribuire al progetto OL-Master. Il loro scopo è garantire qualità tecnica, chiarezza legale e sostenibilità a lungo termine del software e del suo ecosistema.

Contribuendo al progetto, accetti di seguire queste regole.

1. Ambiti di contribuzione

I contributi possono riguardare uno dei seguenti ambiti:

• OL-Master Core
• Plugin e componenti esterni
• Documentazione e strumenti

Ogni ambito segue regole e aspettative diverse.

2. Contributi all'OL-Master Core

Il Core rappresenta la base stabile e supportata della piattaforma OL-Master.

Requisiti

Tutti i contributi al Core devono:

• Essere inviati tramite il processo di contribuzione ufficiale (ad esempio pull request)
• Dichiarare chiaramente l'origine del codice proposto
• Essere compatibili con la licenza GNU GPL versione 3 del progetto Core
• Non includere codice con licenze incompatibili o poco chiare
• Preservare le note di copyright e le attribuzioni esistenti

I contributori devono confermare di avere il diritto di proporre il codice e che questo non viola diritti di terzi.

Revisione e approvazione

Tutti i contributi al Core sono soggetti a revisione da parte del core team Olliter.

L'approvazione si basa su:

• Correttezza tecnica e qualità del codice
• Coerenza architetturale
• Manutenibilità e impatto a lungo termine
• Considerazioni di sicurezza, affidabilità e prestazioni

Il core team può richiedere modifiche, refactoring o documentazione aggiuntiva prima di accettare un contributo, e mantiene piena discrezionalità nell'accettare, modificare o rifiutare qualsiasi contributo.

L'invio di un contributo non ne implica l'accettazione.

3. Plugin e componenti esterni

I plugin e i componenti esterni sono il modo preferito per estendere le funzionalità di OL-Master.

Linee guida per i plugin

I plugin devono:

• Usare solo API pubbliche documentate
• Evitare dipendenze da interfacce private, non documentate o interne del Core
• Non modificare direttamente il Core
• Non presentarsi come ufficiali o approvati da Olliter senza un'autorizzazione esplicita

I plugin possono essere rilasciati con licenze diverse, purché non impongano restrizioni sul Core né ne violino la licenza.

Compatibilità e certificazione

• I plugin sviluppati in modo indipendente sono considerati plugin della community
• I plugin revisionati e approvati da Olliter possono ricevere la designazione Olliter-compatible o Olliter-certified
• Olliter si riserva il diritto di definire i criteri di compatibilità e i processi di certificazione

La compatibilità con le future versioni del Core non è garantita per i plugin non certificati.

4. Fork e opere derivate

I fork dell'OL-Master Core sono consentiti secondo i termini della GNU GPL.

Tuttavia:

• I fork non sono considerati parte del progetto ufficiale
• Olliter non garantisce la compatibilità con i fork
• I fork non possono usare marchi, branding o nomi Olliter in modo da far intendere un'approvazione o un'affiliazione

Chi sceglie di mantenere un fork si assume la piena responsabilità della sua manutenzione, della conformità e della distribuzione.

5. Codice di condotta e collaborazione

Ai contributori si chiede di:

• Agire in buona fede e con rispetto professionale
• Concentrare le discussioni sul merito tecnico e sugli obiettivi del progetto
• Accogliere in modo costruttivo i commenti delle revisioni
• Evitare di introdurre rischi legali o di licenza nel progetto

I disaccordi sono normali. Attacchi personali, rappresentazioni scorrette o comportamenti ostili non sono accettabili.

6. Note finali

Il progetto OL-Master è aperto alla collaborazione, ma non è privo di struttura.

• L'apertura favorisce l'innovazione
• La struttura garantisce affidabilità e sostenibilità
• Regole chiare tutelano sia i contributori sia gli utenti

Se non sei sicuro che un contributo rientri in queste linee guida, contatta il core team all'indirizzo hello@olliter.com prima di investire un impegno significativo.

Licenza e FAQ

Questa sezione chiarisce il modello di licenza di OL-Master, il suo rapporto con le librerie di terze parti e le regole che disciplinano estensioni, plugin e opere derivate.

L'obiettivo è trasparenza, chiarezza legale e allineamento con le buone pratiche dell'open source.

Panoramica sulla licenza

Con quale licenza è distribuito OL-Master?

OL-Master è distribuito con licenza GNU General Public License versione 3 (GPLv3). Il testo completo della licenza è disponibile su gnu.org/licenses/gpl-3.0.html ed è incluso in ogni installazione di OL-Master.

Questa scelta deriva dalle origini e dall'evoluzione del software a partire da PowerSDR, e garantisce continuità legale, chiarezza e rispetto delle licenze a monte.

Perché la GPL?

La GPL garantisce che:

• Gli utenti possano studiare, modificare e ridistribuire il software
• I miglioramenti al Core restino a disposizione della community
• Nessuno possa appropriarsi del Core e ridistribuirlo come software proprietario

La GPL tutela gli utenti e i contributori, non solo il progetto.

Rapporto con le librerie di terze parti

OL-Master utilizza librerie di terze parti distribuite con le proprie licenze, tra cui, a titolo non esaustivo:

• WDSP: GNU GPL v2 o successive
• ChannelMaster: GNU GPL v2 o successive
• FFTW: GNU GPL v2 o successiva
• PortAudio: licenza di tipo MIT

Queste librerie restano soggette alle loro licenze originali. La loro inclusione non ne modifica i termini, e la licenza di OL-Master non prevale su di esse.

Utenti e sviluppatori sono responsabili del rispetto delle licenze di tutti i componenti inclusi.

Domande frequenti

OL-Master è un'opera derivata da PowerSDR?

Sì. OL-Master è nato dal codice di PowerSDR e si è evoluto in modo significativo nel tempo, attraverso ampie modifiche, refactoring ed estensioni.

Essere un'opera derivata non riduce il valore tecnico del progetto. Ne definisce gli obblighi di licenza, che vengono rispettati.

Se la maggior parte del codice originale è stata riscritta, la GPL si applica ancora?

Sì.

Finché il software resta un'opera derivata da codice coperto da GPL, la GPL continua ad applicarsi, indipendentemente da quanto il codice si sia evoluto o sia stato riscritto.

Riscrivere parti di un progetto GPL non elimina automaticamente gli obblighi della GPL.

Il collegamento dinamico o lo spostamento delle DLL permettono di evitare gli obblighi della GPL?

No.

Se il software dipende da librerie GPL per le sue funzioni principali, gli obblighi di licenza restano validi, indipendentemente da come i componenti sono collegati o impacchettati tecnicamente.

La separazione tecnica non annulla la dipendenza legale.

Posso usare OL-Master in un prodotto o servizio commerciale?

Sì. La GPLv3 consente l'uso commerciale, la vendita e la ridistribuzione di OL-Master, a condizione che chi lo riceve ottenga gli stessi diritti previsti dalla GPL, compreso l'accesso al Sorgente Corrispondente completo, e che siano rispettate le licenze dei componenti di terze parti inclusi.

La GPL non consente a nessuno di limitare i diritti degli utenti o di ridistribuire il Core con una licenza proprietaria.

I marchi, i nomi e il branding Olliter non sono concessi in licenza con la GPL e non possono essere usati senza autorizzazione. Per accordi relativi ad apparati Olliter, supporto o certificazione, contatta direttamente Olliter.

Posso vendere plugin o estensioni?

I plugin sviluppati al di fuori del Core, usando solo API pubbliche, possono adottare modelli di licenza diversi, nel rispetto della compatibilità con la GPL e delle leggi applicabili.

Tuttavia:

• I plugin non devono includere o incorporare codice del Core coperto da GPL in violazione della licenza
• I plugin non devono presentarsi come ufficiali o approvati senza autorizzazione
• La compatibilità con il Core non è garantita, salvo dove dichiarato esplicitamente

Posso fare un fork di OL-Master?

Sì.

La GPL consente esplicitamente i fork.

Tuttavia:

• I fork sono progetti indipendenti
• Olliter non fornisce supporto né garanzie di compatibilità per i fork
• Marchi, branding e nomi Olliter non possono essere usati in modo da far intendere un'approvazione o un'affiliazione

Fare un fork è un diritto. Il supporto non è automatico.

Come ottenere il codice sorgente

Chiunque abbia ricevuto una copia di OL-Master, insieme a un apparato Olliter o da un'altra persona, può ottenere gratuitamente il Sorgente Corrispondente completo della versione in suo possesso scrivendo a hello@olliter.com.

Questa offerta è valida per almeno tre anni dalla data in cui è stato ricevuto il software e, in ogni caso, per tutto il tempo in cui Olliter offre ricambi o assistenza per il relativo modello di apparato. Per aiutarci a rispondere rapidamente, indica la versione di OL-Master che possiedi e come l'hai ottenuta (ad esempio il numero di serie della tua radio).

Il sorgente fornito comprende le nostre modifiche e tutto ciò che serve per compilare, installare ed eseguire il software, insieme alle librerie di terze parti da cui dipende (come WDSP, ChannelMaster, FFTW e PortAudio).