UVS Detector

Under active development. UVS Detector is pre-release v1.0 — it ships when the system is ready, with no calendar promises. Full technical documentation and builds — by separate agreement (NDA) for verified partners.

What it is

UVS Detector is an SDR-based platform for hands-on radio-spectrum work in the field. The cycle is sweep (scan), detect, classify the modulation, identify the emitter, and where possible decode the payload. Everything is driven from a single operator-grade UI — 40+ panels and 4 layout presets (Default, Scanner, Decode, Deep dive) for different tasks, from a wide spectrum overview to a deep dive on a single signal.

Processing pipeline

• Sweep — configurable SweepPlans (Full / Targeted / Stare / FollowFHSS), stitched wide-band PSD, waterfall, heatmap, named band presets.
• Detect — noise-floor tracker, CA-CFAR, peak grouping, burst segmentation, hit aggregation, dedicated FHSS tracker, JSONL detection log.
• Classify — a feature stack (bandwidth, cumulants, α-SCF, cyclostationary features, chirp, fingerprint) and a fusion classifier that weighted-combines rules, a constellation EVM probe, and an ML model. 24 modulation classes.
• Identify — Bayesian fusion of frequency, modulation class, fingerprint and regional spectrum allocations (ITU r1/r2/r3 + national files) against a database of 360+ emitters (as of 2026-08). A separate layer — the hostile-intel overlay: 105 profiles as of 2026-08, covering Russian tactical radio and EW systems, with entries for Iranian, North Korean and Chinese UAV and missile systems — the Shahed and Mohajer families among them. Profile depth varies by platform with the available open-source record. Enabled in the appropriate operating modes.
• Decode — live today: analog video (PAL B&W, NTSC, SECAM), analog audio (NBFM/WFM/AM/SSB), and nine band-mux data protocols (ADS-B, AIS, APRS, POCSAG, FLEX, DSC, APT, YSF, NXDN). Implemented and tested but not yet on the live receive path: CW, FT8, WSPR, DMR, LoRa, LTE MIB, Wi-Fi PHY, PAL colour and the Walksnail FPV PHY — they wait on a single registry bridge.

Classification and learning

The classifier is multi-stage: fast rules on signal statistics first, then a constellation-lock EVM probe for PSK/QAM, then, in builds with the ML backend enabled, an in-process XGBoost model over a 32-field feature vector. Results are merged by weighted fusion, so adding ML doesn’t break the deterministic rule behaviour.

The operator isn’t just a consumer of the verdict: a “Not X” correction button flags a wrong classification, and those labels are collected into a dataset for model retraining. The classifier backend is switchable in settings — globally or per drone family — so the system can be tuned to a specific theatre.

Direction finding

Four DF algorithms are implemented and unit-tested — MUSIC, correlative interferometer, Watson-Watt and pseudo-doppler — together with TDOA solvers and a passive-bistatic scaffold. None is wired into the live receive path yet; DF is a designed and coded subsystem awaiting bench bring-up on a coherent AD9361 pair. The dual_coherent profile scales to 2–6 AD9361 devices.

Hardened network architecture

Three deployment modes, chosen by the first-boot wizard:

• Isolated — full autonomy: no outbound connections; the whole RF pipeline, recording and playback stay local.
• LAN — sync within the local network only: nothing leaves the network. Station-to-station federation — TDOA and an encrypted key-anchored peer channel — is designed for this mode and not yet built.
• Full — the mode designed for participation in a UVS-operated backend (station registry, shared signature database, integration API, auto-update, telemetry). The backend services are not deployed and parts of the station-side client are still unwired, so Full ships as forward compatibility, not a capability available today.

Station identity and operator access are being re-anchored in the physical hardware key — no usernames, no passwords, no roles, no certificate authority — and a station never revokes or locks itself down. The key, and the offline peer-pairing model that goes with it, are in development; current builds run against development keys. An auto-update path is implemented — an Ed25519-signed canonical-JSON manifest, cohort-staged rollout and rollback after two failed boots — but it is not yet reachable from the interface, and no release server is deployed. An integration API is defined and implemented as a request-dispatch layer — three endpoints (signals, alerts, trigger recording), JWT-compact tokens and a 60 req/min limit — but the HTTP server that would expose it over the wire is not built yet. The shared signature database is federated and anonymised — contributions are aggregated under a k-anonymity floor, with no raw IQ. Telemetry and crash reporting are five independent opt-ins — crash uploads, hardware, network, performance and feature usage — every one off by default; nothing is sent unless the operator turns that specific category on. Storage — PBKDF2 + AES-GCM software sealer with a Linux TPM probe.

A chain-of-custody session signer is implemented and tested — a canonical-JSON session manifest signed with Ed25519 — but it is not yet wired into the recorder; recordings today are unsigned.

Field readiness

Target platform — Ubuntu 26.04 LTS amd64 (the sole production target after the 2026-04 narrowing). It ships as a .deb with a systemd unit and as a portable AppImage. Release artefacts are signed (detached SHA256SUMS, embedded .deb and AppImage signatures); the production signing key is issued at release. It runs on a compact x86_64 station (mini-PC class) with a TPM for at-rest encryption; the SDR attaches over libiio (USB or IP). For the first minutes after launch, synthetic sources are available for a smoke test — the full interface works before any hardware is attached; then the SDR is connected and scanning begins.

How to get access

Builds, a demo and full technical documentation — by separate agreement; possession of the source or binaries by itself does not grant a licence. Reach out via the contact form: we’ll ask for a short brief on the use case, verify the counterparty, and agree NDA terms. Supply of this software outside Ukraine is subject to Ukraine’s export-control regime. Licence terms, including permitted use, are set out in the EULA and agreed case by case.