The Olliter Project

The Origins of the Olliter Project

The "Il mio SDR" (Italian translation of "my SDR") project traces its roots back to 2010, when Mauro I2SUH, inspired by the first commercially available SDR transceivers, began designing and building a fully home-made SDR radio. The original system was based on an FPGA architecture and controlled via PowerSDR, which at the time represented a solid and flexible platform for experimentation.

That initial prototype marked only the beginning. Over the following years, the project became a vehicle for deeper exploration into both RF and AF digital signal processing, leading to a more refined hardware model completed in 2019. Around the same period, Mauro began collaborating with the Olliter team, bringing the project into a broader technical and collaborative context. This was the official beginning of the OL-SDR as we know it today.

A Necessary Restart, and a Leap Forward

As the first production-ready prototypes were approaching realization, the global pandemic intervened. Severe component shortages, particularly in FPGA availability, made it impossible to proceed with the original design.

Unlike traditional microcontroller-based systems, FPGA platforms cannot be migrated by simply adjusting compiler options or pin mappings. Such a change requires a complete redesign of the logic, architecture, signal flow and a complete rewrite of the firmware. Faced with the first hardware release constraint, the team chose not to merely adapt the existing design, but to take the opportunity to rethink the platform entirely.

New, more modern and capable FPGA families were evaluated, a new RX/TX filter board was designed, and the overall system architecture was revisited with the goal of further improving the already strong performance of the original concept. This effort culminated in the first half of 2022 with the production of the 20 W version, which immediately stood out for its exceptional performance.

Software Origins and Architectural Evolution

From a software standpoint, the earliest versions of the Olliter SDR project originated in 2016 and were derived from PowerSDR. At that time, PowerSDR and its derivates provided not only the graphical user interface, but also the complete DSP processing framework, device control logic, and communication.

This choice was intentional and pragmatic. PowerSDR seemed a good starting point even though it was not as solid or mature as necessary for a future-proof platform commercial project but offered a reliable foundation for validating early hardware prototypes.

In those first iterations, the software stack was fully dependent on PowerSDR for signal processing, user interaction, and hardware control. This allowed the project to concentrate its efforts on RF design, FPGA architecture, and overall system performance, leveraging an existing and trusted software ecosystem rather than reinventing it prematurely.

As the hardware evolved, especially with the introduction of new FPGA platforms and redesigned RX and TX subsystems, the original PowerSDR-centric model began to show its limitations. Increased bandwidth, higher data rates, and the need for more flexible integration capabilities required a software architecture that could scale beyond the constraints of the original design. This marked the beginning of a gradual but deliberate architectural transition.

Progressive Decoupling and Current Dependencies

Over time, OL-Master progressively evolved away from a strict PowerSDR dependency. Core areas such as device management, communication layers, and significant portions of the DSP pipeline were rewritten or restructured to support higher throughput, multiple simultaneous receivers, and extended interoperability with external tools and services.

Despite this architectural evolution, OL-Master continues to rely on a number of clearly identified external components. These dependencies are explicitly documented to avoid ambiguity or misinterpretation and currently include, among others:

• WDSP, used for specific DSP processing functions
• ChannelMaster, the communication library responsible for handling high-throughput data streams from the FPGA
• PortAudio, used to interface with the Windows audio subsystem and manage low-latency audio streams
• GUI components and architectural concepts originating from the PowerSDR ecosystem
• Additional third-party libraries, each distributed under its respective license, used to integrate with external services and tools such as MQTT, N1MM, EiBi, and others

Community-Driven Development Model

From its early stages, the Olliter project has been supported by a community of contributors, testers, and technically skilled users. This community has always played an active role in experimentation, feedback, and feature development.

However, the project was not immediately opened to unrestricted external contributions. The initial focus was on establishing a solid, stable, and well-understood technical base, both in hardware and software, before scaling collaboration.

The current community model reflects this original intent: to provide a structured environment where developments can be reviewed, validated, and, when appropriate, certified for inclusion in the official project stream.

External developers are free to create extensions, plugins, or alternative implementations independently of the official community. Such developments are welcome and encouraged, but they do not automatically receive official certification or compatibility guarantees unless they follow the defined contribution and review processes.

Project Structure & Community Model

This section describes how the OL-Master project is structured, how the community can participate, and how extensibility is achieved while preserving technical quality, legal clarity, and long-term sustainability.

The goal of this model is to encourage experimentation and collaboration without compromising software integrity, licensing compliance, or the reliability of Olliter hardware and official releases.

1. Project Structure Overview

The OL-Master ecosystem is organized around a clear separation between the Core Project and External Components (Plugins and Integrations).

This separation is intentional and fundamental to the stability of the platform.

OL-Master Core

The Core includes all software components that are essential to the correct and safe operation of Olliter radio equipment, including but not limited to:

• Hardware control and device management
• Core DSP processing for RX and TX
• Timing, synchronization, and safety-related logic
• Official communication protocols between software and Olliter hardware
• Public APIs and their reference implementations
• Configuration, persistence, and system-level services

Characteristics of the Core:

• Maintained and released by the Olliter core team
• Versioned and tested against supported hardware
• Distributed under the GNU General Public License (GPL), in continuity with PowerSDR
• Subject to review, validation, and acceptance before inclusion in official releases

The Core represents the stable and supported foundation of the OL-Master ecosystem.

Plugins and External Components

Plugins and external components include all optional or non-essential extensions, such as:

• Additional decoders, encoders, or signal processors
• User interface extensions or alternative front-ends
• Integration with third-party software or services
• Automation systems, controllers, and custom hardware interfaces
• Experimental features not intended for the Core

Characteristics of Plugins:

• Developed and distributed independently from the Core
• Interact with OL-Master exclusively through documented public APIs
• May follow different licensing models, provided they remain compatible with the Core license
• Can be maintained by individual developers, groups, or third parties

This model allows innovation and customization without destabilizing the Core project.

2. Official Support Policy

Officially Supported Components

Olliter provides official support for:

• The OL-Master Core distributed through official repositories
• Public APIs as documented for each supported version
• Plugins and extensions:
  • Developed by Olliter, or
  • Explicitly declared Olliter-compatible or Olliter-certified
• Olliter hardware used with official firmware and software releases

"Official support" implies that the component is tested, documented, maintained, and considered compatible with current hardware and software releases.

Non-Supported Components

Olliter does not provide official support for:

• Forks or modified versions of the Core not approved by the core team
• Direct modifications to the Core distributed outside official channels
• Plugins relying on private, undocumented, or reverse-engineered interfaces
• Software or integrations that violate third-party licenses
• Hardware configurations outside documented or supported designs

3. Extending OL-Master Safely and Correctly

To preserve legal clarity and technical integrity, extensions should follow these principles:

• Extensions must use only documented public APIs
• The Core must not be modified directly by external components
• Attribution, copyright notices, and license headers must not be removed or altered
• GPL-licensed Core code must not be incorporated into proprietary components in violation of its license

Plugins may be distributed under licenses of the developer's choice, provided they do not impose restrictions on the Core or misrepresent GPL-covered code as proprietary.

4. Contributions to the Core Project

Contributions to the OL-Master Core are welcome but governed by clear rules:

• All contributions must be submitted through the official contribution workflow (e.g. pull requests)
• The origin of the contributed code must be clearly declared
• Contributors must agree to the licensing terms of the Core project
• The Olliter core team retains full discretion to accept, modify, or reject contributions

Acceptance into the Core is based on technical quality, maintainability, architectural coherence, and long-term impact on the project.

5. Community Philosophy

The OL-Master project is open, but it is not unstructured.

• Openness enables collaboration, learning, and innovation
• Structure ensures stability, safety, and long-term viability
• The value of the project lies in its ecosystem, not in exclusive control over code

This model allows the community to grow around a shared technical foundation, while enabling Olliter to maintain responsibility for the integrity of the Core platform and its hardware.

Contribution Guidelines

These guidelines define how individuals and organizations may contribute to the OL-Master project. Their purpose is to ensure technical quality, legal clarity, and long-term sustainability of the software and its ecosystem.

By contributing to the project, you agree to follow these rules.

1. Scope of Contributions

Contributions may target one of the following areas:

• OL-Master Core
• Plugins and External Components
• Documentation and tooling

Each area follows different rules and expectations.

2. Contributions to the OL-Master Core

The Core represents the stable and supported foundation of the OL-Master platform.

Requirements

All Core contributions must:

• Be submitted through the official contribution workflow (e.g. pull requests)
• Clearly state the origin of the contributed code
• Be compatible with the GNU GPL license of the Core project
• Not include code with incompatible or unclear licensing
• Preserve existing copyright notices and attributions

Contributors must confirm that they have the right to submit the code and that it does not infringe third-party rights.

Review and Acceptance

All Core contributions are subject to review by the Olliter core team.

Acceptance is based on:

• Technical correctness and code quality
• Architectural consistency
• Maintainability and long-term impact
• Security, safety, and performance considerations

The core team may request changes, refactoring, or additional documentation before accepting a contribution. The core team retains full discretion to accept, modify, or reject any contribution.

Submission of a contribution does not imply acceptance.

3. Plugins and External Components

Plugins and external components are the preferred way to extend OL-Master functionality.

Guidelines for Plugins

Plugins must:

• Use only documented public APIs
• Avoid dependencies on private, undocumented, or internal Core interfaces
• Not modify the Core directly
• Not misrepresent themselves as official or endorsed by Olliter unless explicitly approved

Plugins may be released under different licenses, provided they do not impose restrictions on the Core or violate its license.

Compatibility and Certification

• Plugins developed independently are considered community plugins
• Plugins reviewed and approved by Olliter may be designated as Olliter-compatible or Olliter-certified
• Olliter reserves the right to define compatibility criteria and certification processes

Compatibility with future Core versions is not guaranteed for non-certified plugins.

4. Forks and Derivative Works

Forks of the OL-Master Core are permitted under the terms of the GNU GPL.

However:

• Forks are not considered part of the official project
• Olliter does not guarantee compatibility with forks
• Forks may not use Olliter trademarks, branding, or names in a way that implies endorsement or affiliation

Developers choosing to maintain a fork assume full responsibility for its maintenance, compliance, and distribution.

5. Code of Conduct and Collaboration

Contributors are expected to:

• Act in good faith and with professional respect
• Focus discussions on technical merits and project goals
• Accept review feedback constructively
• Avoid introducing legal or licensing risks to the project

Disagreements are normal. Personal attacks, misrepresentation, or hostile behavior are not acceptable.

6. Final Notes

The OL-Master project is open to collaboration, but it is not unstructured.

• Openness enables innovation
• Structure ensures reliability and sustainability
• Clear rules protect both contributors and users

If you are unsure whether a contribution fits within these guidelines, contact the core team before investing significant effort.

Licensing & FAQ

This section clarifies the licensing model of OL-Master, its relationship with third-party libraries, and the rules governing extensions, plugins, and derivative works.

The goal is transparency, legal clarity, and alignment with open-source best practices.

Licensing Overview

What license does OL-Master use?

OL-Master is released under the GNU General Public License (GPL).

This choice follows from its origin and evolution from PowerSDR and ensures legal continuity, clarity, and compliance with upstream licensing.

Why GPL?

The GPL ensures that:

• Users can study, modify, and redistribute the software
• Improvements to the Core remain available to the community
• No party can appropriate the Core and redistribute it as proprietary software

The GPL protects users and contributors, not just the project.

Relationship with Third-Party Libraries

OL-Master makes use of third-party libraries distributed under their own licenses, including but not limited to:

• WDSP — GNU GPL v3
• ChannelMaster — GNU GPL v3
• FFTW — GNU GPL v2
• PortAudio — MIT-like license

These libraries remain under their original licenses. Their inclusion does not alter their licensing terms, nor does the OL-Master license override them.

Users and developers are responsible for complying with the licenses of all included components.

Frequently Asked Questions

Is OL-Master a derivative of PowerSDR?

Yes. OL-Master originated from the PowerSDR codebase and has evolved significantly over time through extensive modification, refactoring, and extension.

Being a derivative work does not diminish the technical value of the project. It defines its licensing obligations, which are respected.

If most of the original code has been rewritten, does the GPL still apply?

Yes.

As long as the software remains a derivative work of GPL-licensed code, the GPL continues to apply, regardless of how much the codebase has evolved or been rewritten.

Rewriting parts of a GPL project does not automatically remove GPL obligations.

Does dynamic linking or moving DLLs avoid GPL requirements?

No.

If the software depends on GPL-licensed libraries for its core functionality, licensing obligations still apply, regardless of how the components are technically linked or packaged.

Technical separation does not override legal dependency.

Can I use OL-Master in a commercial product or service?

No, unless explicitly permitted by the applicable license terms and/or a separate commercial agreement with Olliter.

The GPL allows redistribution and modification, but it does not grant rights to restrict users or relicense the Core as proprietary.

For commercial use, contact Olliter to discuss licensing options.

Can I sell plugins or extensions?

Plugins developed outside the Core, using only public APIs, may follow different licensing models, subject to GPL compatibility and applicable laws.

However:

• Plugins must not include or embed GPL Core code in violation of the license
• Plugins must not misrepresent themselves as official or endorsed without approval
• Compatibility with the Core is not guaranteed unless explicitly stated

Can I fork OL-Master?

Yes.

The GPL explicitly permits forking.

However:

• Forks are independent projects
• Olliter does not provide support or compatibility guarantees for forks
• Olliter trademarks, branding, and names may not be used in a way that implies endorsement or affiliation

Forking is a right. Support is not automatic.