About a dozen years ago when it was discovered a cheap RTL-SDR designed to receive DVB-T digital television could be repurposed into a general-purpose software-defined radio receiver a number of open-source projects were spawned to capitalize on this capability. Over time other SDRs have been brought to market for purpose with additional capabilities.
This inspired my first project SIGpi, a “go-kit” for Signal Intelligence (SIGINT) enthusiasts with capabilities in the HF, VHF, UHF, and SHF spectrum. It included a framework for simple installation and management of popular SIGINT applications and devices building/installing SIGINT tools starting with the Raspberry Pi 3B. Over time this expanded to include x86 platforms.
My work in AI found me expanding my use cases into SIGINT analysis with sovereign requirements where no Internet-based resources may be available or desired. This inspired a project called Sovereign SIGINT that I presented at HOPE 2026. Sovereign SIGINT is a web-accessible software-defined radio platform with a local (“sovereign”) AI layer for SIGINT. Signals captured by your own hardware become a structured, queryable record that a local LLM reasons over in natural language. What’s active on the RF bands, what WiFi devices are present, and what a given signal is likely to be with no cloud dependency for the core pipeline. Everything runs on-prem. The design principle is local by default, cloud by exception: cloud LLMs, if used at all, are a deliberate opt-in for sanitized, non-sensitive queries.
Sovereign SIGINT required revisiting the SDR build chain from SDRs dedicated per application to SDR shared across applications. For example:
- SDRangel opens the SDR itself, via SoapySDR (or its own device backends), and holds it exclusively for as long as it’s running. One SDRangel instance owns the radio; nothing else can touch it while it’s running.
- ka9q-radio (radiod) owns the SDR once, continuously, and republishes its IQ/audio/control data as an RTP/IP multicast stream. Any number of consumers (other apps, other hosts, recorders, decoders, an AI pipeline) can subscribe to that stream simultaneously without touching the USB device themselves.
A single physical SDR can only be in one state at a time: either radiod owns it and fans it out over multicast, or a direct-access app (SDRangel, GQRX, and others) owns it exclusively.
SDR hardware -> ka9q-radio -> RTP/IP multicast -> any number of network consumers
SDR hardware -> SDRangel (direct, via SoapySDR) -> one exclusive owner
While Sovereign SIGINT was released as a single-host solution it demonstrated that it needs to evolve to a tiered architecture model where SDRs would be one tier and the application/services consuming signals from the SDR tier be another tier. The tiers themselves may have multiple SDR and application/service platforms.
SIGedge is the first release of the SDR tier. It allows you to choose which SDRs participate as a shared service and which ones are dedicated to single-use applications like SDRangel. The shared services include signal demodulation published as multicast channels. For example, one channel may be APRS, another for FT-8 on a particular band, etc. This is most useful for AI integration. SIGedge will be followed up with the application tier starting with AI and will be known as SIGliere.
Consider the following workflow:
- SIGedge has an SDR dedicated to SDRangel or similar single-use application to do signal discovery. You find interesting signals you want to track over time and configure SIGedge shared service to track over time. Those signals are served raw or decoded as multicast channels for consumption by upstream applications/services.
- SIGliere subscribes to the multicast channels, store, archives, and is queried by AI whether as running agents or on-demand queries. Perhaps you want to do situational awareness of all the signals in your area over time; which signals occur most often, their source, any pattern, etc.
Enjoy,
Joe