Designing a SIGINT platform from scratch means making hundreds of engineering decisions that compound into architectural commitments lasting years. The RF collection hardware you select constrains your processing pipeline. Your processing pipeline determines what intelligence products you can generate. Your storage architecture determines how fast analysts can retrieve historical data. Every layer affects every other layer, and retrofitting a bad decision at the collection interface is as expensive as rebuilding the platform.
This article walks through the full SIGINT platform architecture — collection layer, processing pipeline, classification engine, storage tier, analyst workflow, scalability patterns, and security handling — with enough implementation detail to inform real design choices. The goal is a reference architecture that covers the decisions that matter, not an inventory of features.
Platform components overview
A production SIGINT platform comprises five distinct layers, each with separate throughput and latency requirements:
Collection layer. SDR hardware, antenna arrays, and front-end digitizers convert electromagnetic signals to IQ sample streams. This layer produces data at rates from hundreds of megabytes to multiple gigabytes per second per collection node. Everything downstream is constrained by what this layer can deliver.
Signal processing pipeline. IQ samples flow through channelization, detection, demodulation, and protocol decode stages. The pipeline must sustain the full collection throughput in real time. Latency from sample capture to detection output is typically 10–500 ms depending on processing depth.
Classification engine. Detected signals are classified by modulation type, protocol, and emitter identity. Classification runs on intermediate pipeline output, not raw IQ, which makes it feasible to apply heavier compute — neural networks, database lookups, cross-correlation — without blocking the real-time pipeline.
Storage tier. Raw IQ archives, structured detection records, geolocation databases, and intelligence reports each have different retention, query, and access-control requirements and should not share a single storage system.
Analyst workflow layer. Tasking queue, workstation UI, watchlist management, and reporting templates translate raw intelligence products into usable outputs for consumers. This layer is where SIGINT system quality is most visible to end users, yet it is the layer most frequently underinvested by engineering teams focused on DSP.
RF collection layer: SDR hardware selection and frequency planning
The collection hardware defines the frequency coverage, instantaneous bandwidth, dynamic range, and phase-coherence characteristics of everything the platform can observe. These parameters are not upgradable in software.
Hardware selection. Ettus Research USRP hardware (N310, N320, X410) is the most common choice for development and mobile deployments — it has mature UHD drivers, extensive community support, and covers from DC to 6 GHz with up to 400 MHz instantaneous bandwidth on the X410. Analog Devices AD9361-based boards (ADALM-PLUTO, ADRV9361) offer extremely compact form factors at the cost of reduced dynamic range and bandwidth. For fixed-site strategic collection requiring maximum dynamic range and bandwidth, purpose-built digitizers from Pentek, Mercury Systems, or Curtiss-Wright run on OpenVPX or PCIe backplanes and exceed the performance of commercial SDR front-ends significantly.
Frequency coverage planning. No single receiver covers the full RF spectrum of interest. Defense SIGINT tasks span HF (3–30 MHz, long-range COMINT and OTH radar), VHF/UHF (30–3000 MHz, tactical communications and L-band radar), and SHF (3–30 GHz, microwave links and C/X/Ku-band radar). Coverage planning allocates specific hardware to frequency bands based on collection priority, sites, and available hardware. A common approach uses three receiver tiers: wideband VHF/UHF receivers covering the tactical communications band continuously, spot-coverage HF receivers monitoring priority channels, and narrowband microwave receivers cued by the wideband tier to investigate specific emitters.
Antenna arrays. Direction-finding requires a coherent multi-element antenna array with known element spacing. A circular array of 8–16 elements enables full-azimuth coverage with AOA accuracy of 1–3 degrees RMS in clear-sky conditions. Element spacing must be calibrated to sub-wavelength accuracy; calibration data is loaded by the processing software at startup and applied as phase corrections to each channel. Array mechanical stability matters — thermal expansion shifts element positions, requiring periodic recalibration or continuous self-calibration using known reference signals.
Key decision: Phase coherence across receiver channels is mandatory for direction-finding and TDOA. Achieve this with a shared reference oscillator (10 MHz GPS-disciplined OCXO) distributed to all front-ends, not with independent per-receiver clocks. Phase-coherent architectures cannot be retrofitted onto hardware that was not designed for it.
Signal processing pipeline: IQ capture to protocol decode
The processing pipeline transforms a continuous stream of IQ samples into structured detection records. The stages are well-defined; the engineering challenge is sustaining real-time throughput across all of them simultaneously.
Channelization. A polyphase filter bank (PFB) divides the wideband IQ stream into narrowband channels. A 100 MHz-wide input sampled at 125 Msps produces — after channelization — approximately 1000 channels of 100 kHz each. Each channel is monitored independently by subsequent stages. The PFB is computationally intensive at this scale; GPU implementation using cuFFT reduces processing time by 10–20x compared to CPU. GNU Radio provides a production-grade polyphase channelizer block; liquid-dsp provides lower-level primitives for custom implementations.
Energy detection. Each channel is monitored by a CFAR (constant false alarm rate) energy detector that compares instantaneous power to a locally computed noise floor estimate. When a channel crosses the detection threshold, the detector records the start time, frequency, and bandwidth of the signal and initiates sample extraction. CFAR adaptation rate is a key tuning parameter — too fast and the detector adapts to a persistent signal and stops detecting it; too slow and it reacts slowly to changing noise floors. A common architecture uses two parallel CFAR detectors with different adaptation rates and takes the logical union of their outputs.
Demodulation. Once a signal is extracted, the demodulator is selected based on Automatic Modulation Classification (AMC) output. AMC runs a lightweight feature extractor first — cyclostationary features, instantaneous amplitude/frequency/phase statistics — and routes to a candidate demodulator. For narrowband FM (the most common tactical communications waveform), a simple discriminator suffices. For digital waveforms, timing recovery and carrier synchronization are required before symbol decisions. GNU Radio's demodulator blocks cover most common waveforms; protocol-specific decoders (P25, DMR, TETRA, ADS-B, Mode S) are available as open-source out-of-tree modules.
Protocol decode. Above the demodulator, protocol decoders extract structured information from the bit stream. For well-documented protocols (ADS-B, Mode S, DMR, APRS), mature open-source decoders exist. For undocumented or proprietary protocols, protocol fingerprinting identifies the protocol family from bit-level statistics and known sync patterns, even without a full decode. Undecoded signals are still valuable — traffic analysis on intercept patterns (who communicates with whom, at what times, on what frequencies) yields significant intelligence without content access.
Signal classification engine: CNN modulation recognition and emitter identification
Classification runs on the output of the detection and demodulation stages, adding semantic meaning to raw signal parameters. There are three distinct classification problems in a SIGINT platform.
Modulation classification. CNN-based AMC takes a fixed-length IQ segment (typically 128–1024 samples) and outputs a probability distribution over modulation classes. The architecture used most widely in defense SIGINT research is a 1D ResNet or a lightweight convolutional architecture trained on the RadioML dataset (which provides labeled IQ samples across SNR conditions). Inference latency is 0.5–2 ms per segment on a GPU, enabling real-time classification of all detected signals. Key practical constraint: the network's SNR floor determines the minimum detectable signal level — a network trained only on high-SNR data will fail on weak signals that are still tactically relevant.
Protocol fingerprinting. Beyond modulation type, the platform identifies specific waveforms by their bit-level structure. A database of known protocol signatures — sync words, header formats, characteristic byte sequences — is matched against decoded bitstreams. Fingerprinting identifies that a signal is not just "4FSK" but specifically "P25 Phase 1 CQPSK with a specific talk group ID," enabling rapid correlation against known communication networks.
Emitter identification. RF fingerprinting extracts hardware-specific imperfections from the signal: phase noise signature, IQ imbalance ratio, carrier frequency offset, and its drift rate over time. These features are stable across intercepts of the same physical transmitter and differ between transmitters of the same model. A trained classifier or nearest-neighbor lookup against a database of known emitter fingerprints enables re-identification of a specific radio device across intercepts separated by time and location. This is particularly valuable for tracking mobile emitters that change frequencies, call signs, or communication groups between intercepts.
Storage architecture: IQ archive, metadata index, and bearings database
SIGINT storage spans three tiers with fundamentally different requirements that cannot be collapsed into a single system without performance and security penalties.
Raw IQ archive. Raw IQ data must be stored in a format that supports efficient time-range retrieval and is readable by standard signal processing tools. SigMF (Signal Metadata Format) is the emerging standard — it pairs binary IQ files with JSON metadata and supports annotations for flagged segments. For bulk analytics (processing stored IQ to extract features not computed in real time), Apache Arrow in-memory format and Apache Parquet columnar storage enable vectorized batch processing with tools like DuckDB or Apache Spark. Retention is typically short — 6 to 72 hours of rolling buffer — due to the extreme data volume; selective archiving based on classification flags retains signals of interest indefinitely.
Metadata index. Detection records, demodulation outputs, classification results, and analyst annotations form the structured intelligence index. PostgreSQL with PostGIS provides the combination of relational query capability and geospatial indexing required for SIGINT analytics: "find all detections of this emitter type within 50 km of this grid square over the past 48 hours" is a standard analyst query. Detection records are typically sub-kilobyte in size; a busy collection site generates millions per day, which is well within PostgreSQL's capacity. PostGIS spatial indexes make geographic queries fast enough for interactive analyst use.
Bearings database. AOA bearing measurements and TDOA time-difference records are stored separately from detection metadata because they are processed by a dedicated geolocation engine. A bearings record links a bearing or time-difference measurement to the site that generated it, the detection record it references, and the timestamp with precision to microseconds. The geolocation engine queries this database across multiple sites to find measurement sets that can be triangulated, applies least-squares or Kalman filter estimation, and writes computed location fixes with confidence ellipses back to the metadata index. The bearings database needs sub-millisecond write latency to keep up with high-rate collection; TimescaleDB (PostgreSQL extension for time-series) or ClickHouse suit this requirement.
Analyst workflow: tasking, watchlists, and reporting
The analyst workflow layer is where SIGINT intelligence products are created. Engineering it well — or poorly — determines whether the platform is used or worked around.
Tasking queue. Collection tasking specifies what the system should look for: frequency bands to monitor continuously, specific frequencies or emitter types to prioritize, geographic collection areas, and scheduled versus persistent collection windows. Tasking is managed through a collection management interface that maps requirements to available collection nodes, deconflicts competing demands on shared receivers, and tracks coverage — time on frequency per band per node — against tasking requirements. Machine-readable tasking formats (based on NATO STANAG 4559 or internal XML schemas) allow tasking to be generated programmatically from downstream intelligence requirements and pushed to collection nodes without manual reconfiguration.
Workstation design. A SIGINT analyst workstation must display three views simultaneously: spectral (waterfall and persistence display showing frequency-time energy), geographic (map showing collection sites, detected emitter locations, and track histories), and temporal (timeline of emitter activity, intercept queue with priority scoring). These views must share state — selecting an emitter on the map centers the spectrum view on its frequency and highlights its intercepts in the timeline. Building these as composable views over a shared state store (Redux, Zustand, or a custom WebSocket-fed state) rather than three independent applications is essential for usability. Electron-based desktop applications provide native OS integration (file access, OS-level security, clipboard handling) while enabling the same React-based frontend codebase to run in a browser when operating from a central server.
Watchlist management. Watchlists define priority emitters, networks, or frequencies whose detection triggers immediate alerts. A typical watchlist entry specifies: emitter fingerprint or frequency range, geographic area of interest, time window, confidence threshold for automatic alerting, and the analyst or team to notify. Watchlist matching runs as a stream processor against the detection output, not as a batch query, to minimize alert latency. Analysts need a self-service interface to create, modify, and deactivate watchlist entries without engineering involvement — over-reliance on engineering for tasking changes is one of the most common operational complaints about SIGINT platforms.
Reporting templates. SIGINT intelligence products follow standardized report formats: ELINT reports record emitter parameters and mode analysis against the emitter parameter database; COMINT reports record intercept content, traffic analysis, and communication network mappings; geolocation reports record fixes with error ellipses and associated emitter track history. Templates pre-populate fields from the structured detection database, leaving analysts to add analytic judgments rather than transcribing parameters. Reports are exported in both human-readable (PDF, Word) and machine-readable (XML, JSON) formats for downstream intelligence fusion systems.
Scalability patterns: Kafka streaming, horizontal collection nodes, GPU clusters
A single-site SIGINT platform may be feasible as a monolithic application. A multi-site, high-bandwidth collection network requires deliberate scalability architecture.
Kafka for IQ streaming. Apache Kafka serves as the distribution backbone for IQ sample blocks and detection events across a distributed processing cluster. Collection nodes publish IQ blocks to Kafka topics partitioned by frequency band; processing consumers subscribe to the partitions relevant to their assigned frequency ranges and output detection records to downstream topics. This decoupling enables independent horizontal scaling of collection and processing, provides a short-term replay buffer for recovery from processing node failures, and gives the geolocation engine a unified stream of time-stamped detection events from all sites. Kafka handles sustained throughput of tens of gigabytes per second across a cluster with appropriate partitioning and replication.
Horizontal collection nodes. Collection nodes are stateless with respect to processing — they publish IQ and receive tasking updates. This makes horizontal scaling straightforward: adding a new collection node with a new SDR front-end requires only registering the node in the tasking system and starting the collection software with the appropriate configuration. Node health monitoring, automatic failover to a spare front-end on hardware failure, and remote reconfiguration via the tasking interface are standard infrastructure requirements. Container orchestration (Kubernetes) manages the collection software lifecycle; stateless node design makes rolling updates non-disruptive.
GPU processing clusters. FFT-based spectrum analysis, polyphase channelization, and neural network inference for AMC are all GPU-acceleratable. A GPU node running cuFFT-based channelization can process 40–100 Gsps throughput — more than any single collection front-end can deliver. GPU cluster sizing is driven by aggregate collection bandwidth across all sites, not per-site bandwidth. The practical constraint on GPU cluster use in tactical deployments is power and cooling: a high-performance GPU server consumes 2–5 kW, which limits its use to fixed sites or vehicles with generator power. Embedded GPU options (Nvidia Jetson AGX) enable edge-processing in size- and power-constrained mobile platforms at reduced throughput.
Security and classification handling
Security in a SIGINT platform is not a feature added at the end — it is an architectural constraint that determines how data flows between every component.
Data classification labels. Every data object is tagged with a classification level and handling caveats at the point of creation. The collection software stamps each IQ block with the classification level of the collection program and the handling restrictions of the source. Classification labels are immutable — they can be raised but never lowered except through an approved sanitization process. The storage layer enforces classification-aware retention: higher-classification data uses shorter default retention windows and stricter access logging.
Need-to-know access control. RBAC enforces which analysts can access which collection programs, geographic areas, and signal types. A typical permission model has three axes: clearance level (UNCLASSIFIED through TS//SCI), program compartment (specific collection programs), and role (analyst, collection manager, system administrator). API requests carry a session token that encodes the user's permissions; the data layer filters query results to objects accessible at the session's permission level. Overly permissive access control — "everyone with a TS clearance can see everything" — is an insider threat risk that SIGINT operators and program security officers will reject.
Audit trails. Every data access, analytic action, and configuration change is written to an immutable audit log. Audit records include: actor identity, action type, object identifier, classification label, timestamp, and source IP. Audit logs are written to a separate append-only store, not the primary database, and are protected against modification even by system administrators. Audit log retention must meet program-specific requirements, typically a minimum of five years. Log integrity is verified by hash-chaining or a hardware security module-backed signing process.
Air-gap considerations. Strategic SIGINT systems operating at the highest classification levels use physically air-gapped network segments. Collection nodes at a remote site communicate to a forward processing node over a dedicated encrypted RF or fiber link; no path to an unclassified network exists. Analyst workstations connect only to the classified network segment. Moving sanitized intelligence products down to lower-classification consumers requires a validated cross-domain solution (CDS) — hardware-enforced one-way data diodes or bidirectional CDS appliances from approved vendors (Forcepoint, Owl Cyber Defense, Everfox). Rolling a custom cross-domain transport is not an acceptable architectural choice; the accreditation pathway for a custom CDS is prohibitively expensive and slow.