Le Origini del Progetto Olliter

Il progetto "Il mio SDR" affonda le sue radici nel 2010, quando Mauro I2SUH, ispirato dai primi ricetrasmettitori SDR disponibili commercialmente, iniziò a progettare e costruire una radio SDR completamente fatta in casa. Il sistema originale era basato su un'architettura FPGA e controllato tramite PowerSDR, che all'epoca rappresentava una piattaforma solida e flessibile per la sperimentazione.

Quel prototipo iniziale segnò solo l'inizio. Nel corso degli anni successivi, il progetto divenne un veicolo per un'esplorazione più approfondita sia dell'elaborazione digitale dei segnali RF che AF, portando 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. Questo fu l'inizio ufficiale dell'OL-SDR come lo conosciamo oggi.

Un Riavvio Necessario e un Salto in Avanti

Mentre i primi prototipi pronti per la produzione si stavano avvicinando alla realizzazione, intervenne la pandemia globale. La grave carenza di componenti, in particolare la disponibilità di FPGA, rese impossibile procedere con il progetto originale.

A differenza dei sistemi tradizionali basati su microcontrollori, le piattaforme FPGA non possono essere migrate semplicemente regolando le opzioni del compilatore o le mappature dei pin. Un tale cambiamento richiede una completa riprogettazione della logica, dell'architettura, del flusso del segnale e una riscrittura completa del firmware. Di fronte al vincolo della prima release hardware, il team scelse di non adattare semplicemente il progetto esistente, ma di cogliere l'opportunità per ripensare completamente la piattaforma.

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

Origini del Software ed Evoluzione Architettonica

Dal punto di vista software, le prime versioni del progetto Olliter SDR ebbero origine nel 2016 e furono derivate da PowerSDR. All'epoca, PowerSDR e i suoi derivati fornivano non solo l'interfaccia utente grafica, ma anche il framework completo di elaborazione DSP, la logica di controllo del dispositivo e la comunicazione.

Questa scelta fu intenzionale e pragmatica. PowerSDR sembrava un buon punto di partenza anche se non era solido o maturo come necessario per un progetto commerciale a prova di futuro, ma offriva una base affidabile per validare i primi prototipi hardware.

In quelle prime iterazioni, lo stack software era completamente dipendente da PowerSDR per l'elaborazione del segnale, l'interazione con l'utente e il controllo hardware. Ciò permise al progetto di concentrare i suoi sforzi sulla progettazione RF, sull'architettura FPGA e sulle prestazioni complessive del sistema, sfruttando un ecosistema software esistente e affidabile piuttosto che reinventarlo prematuramente.

Man mano che l'hardware evolveva, specialmente con l'introduzione di nuove piattaforme FPGA e sottosistemi RX e TX riprogettati, il modello originale incentrato su PowerSDR iniziò a mostrare i suoi limiti. L'aumento della larghezza di banda, velocità di dati più elevate e la necessità di capacità di integrazione più flessibili richiedevano un'architettura software in grado di scalare oltre i vincoli del progetto originale. Questo segnò l'inizio di una transizione architettonica graduale ma deliberata.

Disaccoppiamento Progressivo e Dipendenze Attuali

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

Nonostante questa evoluzione architettonica, OL-Master continua a fare affidamento su una serie di componenti esterni chiaramente identificati. Queste dipendenze sono esplicitamente documentate per evitare ambiguità o interpretazioni errate e attualmente includono, tra gli altri:

• WDSP, utilizzato per funzioni specifiche di elaborazione DSP
• ChannelMaster, la libreria di comunicazione responsabile della gestione dei flussi di dati ad alto throughput dall'FPGA
• PortAudio, utilizzato per interfacciarsi con il sottosistema audio di Windows e gestire flussi audio a bassa latenza
• Componenti GUI e concetti architettonici provenienti dall'ecosistema PowerSDR
• Librerie aggiuntive di terze parti, ciascuna distribuita sotto la rispettiva licenza, utilizzate per integrarsi con servizi e strumenti esterni come MQTT, N1MM, EiBi e altri

Modello di Sviluppo Guidato dalla Community

Fin dalle sue prime fasi, il progetto Olliter è stato supportato da una community di contributori, tester e utenti tecnicamente qualificati. Questa community ha sempre svolto un ruolo attivo nella sperimentazione, nel feedback e nello sviluppo di funzionalità.

Tuttavia, il progetto non è stato immediatamente aperto a contributi esterni illimitati. L'obiettivo iniziale era stabilire una base tecnica solida, stabile e ben compresa, sia nell'hardware che nel software, prima di scalare la collaborazione.

L'attuale modello di community riflette questa intenzione originale: fornire un ambiente strutturato in cui gli sviluppi possono essere rivisti, validati e, quando appropriato, certificati per l'inclusione nel flusso ufficiale del progetto.

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

Struttura del Progetto & Modello Community

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

L'obiettivo di questo modello è incoraggiare la sperimentazione e la collaborazione senza compromettere l'integrità del software, la conformità alle licenze o l'affidabilità dell'hardware Olliter e delle release ufficiali.

1. Panoramica della Struttura del Progetto

L'ecosistema OL-Master è organizzato attorno a una chiara separazione tra il Progetto Core e i Componenti Esterni (Plugin e Integrazioni).

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

Core OL-Master

Il Core include tutti i componenti software che sono essenziali per il corretto e sicuro funzionamento dell'apparecchiatura radio Olliter, inclusi ma non limitati a:

• Controllo hardware e gestione dei dispositivi
• Elaborazione DSP core per RX e TX
• Logica di temporizzazione, sincronizzazione e sicurezza
• Protocolli di comunicazione ufficiali tra software e hardware Olliter
• API pubbliche e le loro implementazioni di riferimento
• Configurazione, persistenza e servizi a livello di sistema

Caratteristiche del Core:

• Mantenuto e rilasciato dal team core Olliter
• Versionato e testato con l'hardware supportato
• Distribuito sotto la GNU General Public License (GPL), in continuità con PowerSDR
• Soggetto a revisione, validazione e accettazione 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 includono tutte le estensioni opzionali o non essenziali, come:

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

Caratteristiche dei Plugin:

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

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

2. Politica di Supporto Ufficiale

Componenti Ufficialmente Supportati

Olliter fornisce supporto ufficiale per:

• Il Core OL-Master distribuito attraverso repository ufficiali
• API pubbliche come documentate per ogni versione supportata
• Plugin ed estensioni:
  • Sviluppati da Olliter, o
  • Esplicitamente dichiarati compatibili con Olliter o certificati Olliter
• Hardware Olliter utilizzato con firmware e release software ufficiali

"Supporto ufficiale" implica che il componente sia 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 team core
• Modifiche dirette al Core distribuite al di fuori dei canali ufficiali
• Plugin che si basano su interfacce private, non documentate o ottenute tramite reverse engineering
• Software o integrazioni che violano licenze di terze parti
• Configurazioni hardware al di fuori dei progetti documentati o supportati

3. Estendere OL-Master in Modo Sicuro e Corretto

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

• Le estensioni devono utilizzare solo API pubbliche documentate
• Il Core non deve essere modificato direttamente da componenti esterni
• Le attribuzioni, gli avvisi di copyright e le intestazioni di licenza non devono essere rimossi o alterati
• Il codice Core con licenza GPL non deve essere incorporato in componenti proprietari in violazione della sua licenza

I plugin possono essere distribuiti sotto licenze a scelta dello sviluppatore, purché non impongano restrizioni sul Core o rappresentino erroneamente il codice coperto da GPL come proprietario.

4. Contributi al Progetto Core

I contributi al Core OL-Master sono benvenuti ma governati da regole chiare:

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

L'accettazione nel Core si basa sulla qualità tecnica, manutenibilità, coerenza architettonica e impatto a lungo termine sul progetto.

5. Filosofia della Community

Il progetto OL-Master è aperto, ma non è destrutturato.

• L'apertura abilita collaborazione, apprendimento e innovazione
• La struttura garantisce stabilità, sicurezza e vitalità a lungo termine
• Il valore del progetto risiede nel suo ecosistema, non nel controllo esclusivo del codice

Questo modello consente alla community di crescere attorno a una base tecnica condivisa, permettendo allo stesso tempo a Olliter di mantenere la responsabilità per l'integrità della piattaforma Core e del suo hardware.

Linee Guida per i Contributi

Queste linee guida definiscono come individui 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. Ambito dei Contributi

I contributi possono riguardare una delle seguenti aree:

• Core OL-Master
• Plugin e Componenti Esterni
• Documentazione e strumenti

Ogni area segue regole e aspettative diverse.

2. Contributi al Core OL-Master

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

Requisiti

Tutti i contributi al Core devono:

• Essere inviati attraverso il flusso di lavoro ufficiale di contribuzione (ad es. pull request)
• Dichiarare chiaramente l'origine del codice contribuito
• Essere compatibili con la licenza GNU GPL del progetto Core
• Non includere codice con licenze incompatibili o non chiare
• Preservare gli avvisi di copyright e le attribuzioni esistenti

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

Revisione e Accettazione

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

L'accettazione si basa su:

• Correttezza tecnica e qualità del codice
• Coerenza architettonica
• Manutenibilità e impatto a lungo termine
• Considerazioni su sicurezza, safety e prestazioni

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

L'invio di un contributo non implica 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:

• Utilizzare solo API pubbliche documentate
• Evitare dipendenze da interfacce private, non documentate o interne del Core
• Non modificare direttamente il Core
• Non rappresentarsi erroneamente come ufficiali o approvati da Olliter a meno che non siano esplicitamente approvati

I plugin possono essere rilasciati sotto licenze diverse, purché non impongano restrizioni sul Core o violino la sua licenza.

Compatibilità e Certificazione

• I plugin sviluppati indipendentemente sono considerati plugin della community
• I plugin revisionati e approvati da Olliter possono essere designati come compatibili con Olliter o certificati Olliter
• Olliter si riserva il diritto di definire i criteri di compatibilità e i processi di certificazione

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

4. Fork e Lavori Derivati

I fork del Core OL-Master sono permessi 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 utilizzare marchi, branding o nomi Olliter in modo da implicare approvazione o affiliazione

Gli sviluppatori che scelgono di mantenere un fork si assumono la piena responsabilità della sua manutenzione, conformità e distribuzione.

5. Codice di Condotta e Collaborazione

Ci si aspetta che i contributori:

• Agiscano in buona fede e con rispetto professionale
• Concentrino le discussioni sui meriti tecnici e sugli obiettivi del progetto
• Accettino costruttivamente il feedback della revisione
• Evitino di introdurre rischi legali o di licenza nel progetto

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

6. Note Finali

Il progetto OL-Master è aperto alla collaborazione, ma non è destrutturato.

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

Se non sei sicuro che un contributo rientri in queste linee guida, contatta il team core prima di investire uno sforzo significativo.

Licenza & FAQ

Questa sezione chiarisce il modello di licenza di OL-Master, la sua relazione con le librerie di terze parti e le regole che governano estensioni, plugin e lavori derivati.

L'obiettivo è la trasparenza, la chiarezza legale e l'allineamento con le migliori pratiche open-source.

Panoramica delle Licenze

Quale licenza usa OL-Master?

OL-Master è rilasciato sotto la GNU General Public License (GPL).

Questa scelta deriva dalla sua origine ed evoluzione da PowerSDR e garantisce continuità legale, chiarezza e conformità con le licenze upstream.

Perché GPL?

La GPL garantisce che:

• Gli utenti possano studiare, modificare e ridistribuire il software
• I miglioramenti al Core rimangano disponibili alla community
• Nessuna parte possa appropriarsi del Core e redistribuirlo come software proprietario

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

Relazione con le Librerie di Terze Parti

OL-Master utilizza librerie di terze parti distribuite sotto le proprie licenze, incluse ma non limitate a:

• WDSP — GNU GPL v3
• ChannelMaster — GNU GPL v3
• FFTW — GNU GPL v2
• PortAudio — Licenza simile a MIT

Queste librerie rimangono sotto le loro licenze originali. La loro inclusione non altera i termini di licenza, né la licenza di OL-Master li sostituisce.

Utenti e sviluppatori sono responsabili della conformità con le licenze di tutti i componenti inclusi.

Domande Frequenti

OL-Master è un derivato di PowerSDR?

Sì. OL-Master ha avuto origine dal codebase di PowerSDR e si è evoluto significativamente nel tempo attraverso modifiche estensive, refactoring ed estensioni.

Essere un lavoro derivato non diminuisce il valore tecnico del progetto. Definisce i suoi obblighi di licenza, che sono rispettati.

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

Sì.

Finché il software rimane un lavoro derivato di codice con licenza GPL, la GPL continua ad applicarsi, indipendentemente da quanto il codebase si sia evoluto o sia stato riscritto.

Riscrivere parti di un progetto GPL non rimuove automaticamente gli obblighi GPL.

Il linking dinamico o lo spostamento di DLL evita i requisiti GPL?

No.

Se il software dipende da librerie con licenza GPL per le sue funzionalità core, gli obblighi di licenza si applicano comunque, indipendentemente da come i componenti siano tecnicamente collegati o impacchettati.

La separazione tecnica non sostituisce la dipendenza legale.

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

No, a meno che non sia esplicitamente permesso dai termini di licenza applicabili e/o da un accordo commerciale separato con Olliter.

La GPL consente la ridistribuzione e la modifica, ma non concede diritti di limitare gli utenti o rilicenziare il Core come proprietario.

Per uso commerciale, contattare Olliter per discutere le opzioni di licenza.

Posso vendere plugin o estensioni?

I plugin sviluppati al di fuori del Core, utilizzando solo API pubbliche, possono seguire modelli di licenza diversi, soggetti alla compatibilità GPL e alle leggi applicabili.

Tuttavia:

• I plugin non devono includere o incorporare codice Core GPL in violazione della licenza
• I plugin non devono rappresentarsi erroneamente come ufficiali o approvati senza approvazione
• La compatibilità con il Core non è garantita a meno che non sia esplicitamente dichiarata

Posso fare un fork di OL-Master?

Sì.

La GPL permette esplicitamente il fork.

Tuttavia:

• I fork sono progetti indipendenti
• Olliter non fornisce supporto o garanzie di compatibilità per i fork
• I marchi, il branding e i nomi Olliter non possono essere utilizzati in modo da implicare approvazione o affiliazione

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