Sky: Passive Aerial Early-Warning Node

Before any radar work, I put up the truth receiver: an RTL-SDR Blog V4 with a 1090 MHz antenna, decoding Mode S / ADS-B with readsb (the maintained fork of dump1090) and serving a live map with tar1090. The decoder writes aircraft state, ICAO24, position, altitude, heading, speed, to /run/readsb/aircraft.json every second, and tar1090 archives rolling history under /run/tar1090/. This log is the scoring key for everything that follows: for any timestamp I can say exactly which cooperative aircraft were actually overhead and where.

Both services install from wiedehopf's one-liners on the mini PC's Ubuntu install, and they survive reboots via systemd:

Installing the ADS-B decoder and live map

sudo bash -c "$(wget -O - https://raw.githubusercontent.com/wiedehopf/adsb-scripts/master/readsb-install.sh)"
sudo bash -c "$(wget -O - https://raw.githubusercontent.com/wiedehopf/tar1090/master/install.sh)"
systemctl status readsb tar1090
# sanity check: how many aircraft are being decoded right now?
curl -s http://127.0.0.1/tar1090/data/aircraft.json | jq '.aircraft | length'

How I verified: the tar1090 map at http://mini-pc:8080/ (this build's deployment choice) showed live tracks matching what I could hear on approach frequencies, and aircraft.json updated every second. What can go wrong: a badly sited 1090 antenna gives you five aircraft and a false sense of failure later, I moved it to a window with sky view before trusting the log.

Passive radar is only as good as its illuminators of opportunity, so before mounting anything directional I mapped my local broadcast landscape with rtl_power: which FM stations (88-108 MHz) and UHF TV transmitters (~470-600 MHz, ATSC) are receivable here, at what power, and on which exact frequencies. FM offers long range and strong signals; 8-VSB/ATSC TV has more bandwidth and therefore better range resolution. I cross-checked the strongest peaks against public transmitter databases to get each station's location, the bistatic geometry later depends on knowing precisely where the transmitter is.

Band surveys with rtl_power

# FM broadcast band: 200 kHz bins, 5 minutes of integration
rtl_power -f 88M:108M:200k -i 10 -c 50% -e 5m -g 40 fm_survey.csv

# UHF TV band: 1 MHz bins
rtl_power -f 470M:608M:1M -i 10 -c 50% -e 5m -g 40 uhf_survey.csv

# render a quick heatmap to eyeball the strongest transmitters
python3 heatmap.py fm_survey.csv fm_survey.png

What can go wrong: the strongest station is not always the best illuminator, one 100 kW FM station a few kilometres away saturated the front end and created intermod products across the band (see Troubleshooting). I picked illuminators that are strong but not co-located with my receiver.

A passive radar lives on faint echoes, so every dB lost to a mistuned antenna hurts twice (once on the reference, once on the echo). I swept the FM Yagi and the UHF log-periodic with the NanoVNA from the bench using NanoVNASaver, checking SWR across each target band and trimming the Yagi's driven element until the dip sat inside the FM band rather than at its edge. Target: SWR under 2:1 across the whole illuminator band, ideally under 1.5:1 at the chosen station's frequency.

NanoVNASaver setup on Ubuntu

sudo apt install python3-pyqt5 libxcb-xinerama0
pip3 install nanovna-saver
NanoVNASaver   # connect the VNA over USB, calibrate open/short/load first

How I verified: after tuning, the reference-channel spectrum in the KrakenSDR UI showed the target station several dB stronger than before, and the survey peaks matched step 02's expectations. What can go wrong: tuning indoors lies, the SWR dip moved when the antenna went up near metal, so I re-swept it in its final position before sealing the coax.

The KrakenSDR is five RTL-SDR-class receivers in one box sharing one clock, covering 24-1766 MHz, the shared clock is what keeps all channels phase-aligned, which is the whole point for passive radar and direction finding. I run the open-source krakensdr_doa stack (HeIMDALL DAQ firmware plus the DSP/web layer) on the mini PC; a Raspberry Pi 4/5 works too, but the x86 box has the headroom for the processing chain in later steps.

Installing and starting the KrakenSDR stack

git clone https://github.com/krakenrf/krakensdr_doa.git
cd krakensdr_doa
# the DAQ launch script must be copied out of the firmware util directory
# into the repo root before the start script can find it (per repo README):
cp heimdall_daq_fw/util/heimdall_daq_fw_run.sh .
# install dependencies per the repo README for your platform, then:
./kraken_doa_start.sh   # starts the HeIMDALL DAQ core + DSP + web UI
./kraken_doa_stop.sh    # clean shutdown between config changes

The web UI comes up on port 8081 on this build; from there I set the centre frequency to the chosen FM station, set gain, and confirmed all five channels streaming.

What can go wrong: undervoltage on the USB-C power line causes random channel drops that look exactly like software bugs. I power the KrakenSDR from a proper 5 V supply, not a hub port, and check dmesg for USB resets after any weird behaviour.

Five receivers sharing a clock are frequency-coherent, but each channel still has its own phase and amplitude offset from mixer and path differences. The KrakenSDR's built-in noise source injects a common wideband signal into all five channels, and the software measures and nulls those offsets. The critical operational rule: frequency and gain changes trigger Kraken recalibration, and any retune or sample-rate change invalidates the phase calibration, so recalibrate on every retune or sample-rate change and it must be re-run. I log the calibration timestamp alongside every capture so I can prove later that a capture was taken in a calibrated state.

DAQ configuration (key fields) and calibration flow

# _daq_core/daq_chain_config.ini - key fields for an FM illuminator
[daq]
center_freq = 98.1        # MHz - the chosen FM station
# legacy _daq_core/daq_chain_config.ini uses MHz; native v2 control examples use Hz
sample_rate = 2400000     # Hz
uniform_gain = 40.2         # dB, all channels
# Then in the web UI (http://mini-pc:8081):
#   1. enable the noise source  2. run calibration  3. disable noise source
#   4. confirm per-channel phase offsets read near zero

How I verified: with the noise source on, the calibrated channels report near-zero residual phase spread; a deliberately skipped calibration shows up immediately as garbage correlation. This failure mode, silently uncalibrated captures, is exactly why the timestamp logging exists.

Port note (documented workaround): tar1090 keeps port 8080 on this build, so the KrakenSDR web UI runs on port 8081. Both tools commonly come up on 8080 in their stock installs, so confirm the actual deployed ports on your own build if you follow these steps.

Two antenna roles carry the radar geometry. The reference Yagi points at the broadcast transmitter and captures the clean direct signal on channel 1. The surveillance antennas point at the area of interest on channels 2-5 and capture that same signal delayed and Doppler-shifted by aircraft reflections. Spacing between surveillance elements matters for direction-of-arrival work: the rule of thumb is half-wavelength spacing to avoid grating lobes, which is band-dependent, at FM frequencies the elements sit far apart, at UHF TV they pack tightly.

Element spacing per band

python3 - <<'EOF'
c = 299792458
for f in (98.1e6, 550e6):
    lam = c / f
    print(f"{f/1e6:6.1f} MHz: lambda = {lam:.2f} m, half-lambda = {lam/2:.2f} m")
EOF
#  98.1 MHz: lambda = 3.06 m, half-lambda = 1.53 m
# 550.0 MHz: lambda = 0.55 m, half-lambda = 0.27 m

I also placed the reference antenna so its pattern nulls toward the surveillance array, direct-path breakthrough leaking into the surveillance channels is the number-one enemy of a small passive radar.

What can go wrong: at FM wavelengths the "array" is over a metre per element, so my first indoor layout had the elements coupled to each other and to the room. Moving the surveillance antennas away from walls and large metal objects visibly cleaned up the clutter floor.

Processing development needs repeatable data, so before tuning anything live I built a recorder that pulls synchronized IQ frames from the HeIMDALL DAQ's network IQ interface (the same output the KrakenSDR mobile app consumes) and writes per-channel interleaved float32 files plus a small JSON sidecar with centre frequency, sample rate, gain, and calibration timestamp. The DAQ speaks framed MCHQ packets on that interface (magic, big-endian header with per-channel frequency and gain, then interleaved uint8 IQ), so the real recorder parses frames and converts to float32; the socket snippet below is schematic. A 10-30 second capture at 2.4 MHz sample rate is a few hundred MB across five channels, big enough to develop against, small enough to keep a library of.

record_iq.py (simplified capture loop; pseudocode, cannot parse MCHQ headers directly)

import json, socket, time
import numpy as np

# NOTE: pseudocode. The DAQ sends framed MCHQ packets (magic, big-endian
# header with per-channel frequency and gain, then interleaved uint8 IQ);
# the real recorder parses each frame header first and converts the CU8
# payload to float32. This sketch reads raw complex64 for illustration.
N_CH, N_SAMPLES = 5, 1 << 22          # ~1.7 s per CPI block at 2.4 MHz
sock = socket.create_connection(("127.0.0.1", 5000))   # DAQ IQ interface

def read_exact(n):
    buf = b""
    while len(buf) < n:
        buf += sock.recv(n - len(buf))
    return buf

stamp = int(time.time())
raw = read_exact(N_CH * N_SAMPLES * 2 * 4)             # complex float32
iq = np.frombuffer(raw, dtype=np.complex64).reshape(N_CH, N_SAMPLES)
iq.tofile(f"captures/iq_{stamp}.cf32")
json.dump({"fc_hz": 98.1e6, "fs_hz": 2.4e6, "gain_db": 40.2,
           "cal_ts": last_calibration_ts},
          open(f"captures/iq_{stamp}.json", "w"))

How I verified: every capture gets opened in a waterfall before being filed, a capture with USB dropouts shows visible streaks and gets deleted, because training a clutter filter on corrupted data wastes days.

The core DSP runs on pyAPRiL, the open-source Python passive-radar library on PyPI (pip install pyapril). KrakenRF's own ready-to-use passive radar code was withdrawn for regulatory reasons, so this chain is built on pyAPRiL instead of any Kraken-distributed implementation. The chain per coherent processing interval (CPI): prepare the reference and surveillance channels, suppress the direct-path breakthrough and stationary clutter with an adaptive filter (the ECA family, Extensive Cancellation Algorithm), compute the cross-ambiguity surface (surveillance correlated against reference over a bank of Doppler shifts), and run CA-CFAR detection over the resulting range-Doppler map. Aircraft appear as peaks at a bistatic range (extra path length vs the direct signal) and a Doppler speed. With multiple surveillance channels calibrated, pyAPRiL also estimates direction of arrival, which turns a blip into a bearing.

rd_pipeline.py, one CPI through the chain (simplified wrapper pseudocode, not verbatim pyAPRiL API)

import numpy as np

ref  = load_cf32("iq_1695600000.cf32")[0]     # channel 1: reference
surv = load_cf32("iq_1695600000.cf32")[1]     # channel 2: surveillance

# 1. ECA clutter cancellation: project direct path + static clutter out
surv_clean = eca_filter(ref, surv, n_filter_taps=10)

# 2. cross-ambiguity: bistatic range vs Doppler
rd_map = cross_ambiguity(ref, surv_clean, fs=2.4e6,
                         max_doppler_hz=600, cpi_s=0.5)

# 3. CA-CFAR hit detection over the range-Doppler surface
hits = ca_cfar(np.abs(rd_map), guard=2, train=8, pfa=1e-4)

What can go wrong: the call names below are simplified wrappers showing the processing order, consult the installed pyAPRiL release for the exact API. With insufficient clutter cancellation the zero-Doppler ridge swamps everything and CFAR declares hundreds of false hits, the tuning loop is filter order vs false-alarm rate, judged on recorded captures before ever running live. Memory is the other constraint: full CPI surfaces accumulate fast, which is why the mini PC has 16 GB.

A radar page without numbers is marketing, so the scoring harness is a first-class part of the build. For each logged ADS-B aircraft at each capture timestamp, I compute where it should appear in bistatic range-Doppler space, the extra path length via the known transmitter location, and the Doppler from its velocity projected onto the transmitter-aircraft and aircraft-receiver legs, then check whether the radar produced a CFAR hit there, and whether it produced hits where no aircraft existed. That yields the three numbers that define the radar: detection rate, false-alarm rate, and effective range per illuminator. FM and UHF TV get scored separately, because the honest answer is usually "it depends on the transmitter."

score_run.py, aligning detections with truth (simplified)

import glob, json
import pandas as pd

truth = pd.concat(pd.read_json(f)
                  for f in sorted(glob.glob("adsb_history/*.json")))
hits  = pd.read_json("captures/run_012_hits.json")   # CFAR hits, this run

for _, ac in truth[truth.run_id == RUN_ID].iterrows():
    bistatic_r = extra_path(tx_pos, ac.pos, rx_pos)  # known TX + RX sites
    doppler    = bistatic_doppler(tx_pos, ac, rx_pos)
    hit = hits.query("abs(range_m - @bistatic_r) < TOL_R and "
                     "abs(doppler_hz - @doppler) < TOL_D")
    record(ac.icao24, detected=not hit.empty)

How I verified: the harness is only trustworthy if its clock is, both the ADS-B log and the captures come off the same chrony-disciplined mini PC, and I reject any run where the truth log has gaps in the scoring window.

A sensor node you have to babysit is a demo, not a node. The DAQ, recorder, and processing chain run as a systemd service that starts on boot and restarts on failure; captures and score summaries rotate to the archive disk nightly. The endgame is 2-3 nodes at different sites publishing detections over MQTT, the same signed-detections bus the rest of the hardware program uses, into the multi-domain common operating picture, where intersecting range-Doppler-DoA solutions from multiple nodes become actual positions. Store-and-forward applies here too: nodes buffer through dead links and sync on reconnect, the DDIL pattern the rest of the program is built around.

/etc/systemd/system/sky-node.service

[Unit]
Description=Sky passive radar node (HeIMDALL DAQ + processing)
After=network-online.target

[Service]
User=taki
WorkingDirectory=/home/taki/sky-node
ExecStart=/home/taki/sky-node/run_node.sh
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

Publishing a detection to the fusion bus

import json, paho.mqtt.client as mqtt

client = mqtt.Client("sky-node-01")
client.connect("cop-broker.local", 1883)
client.publish("defence/sky/detections", json.dumps({
    "node": "sky-node-01", "ts": capture_ts,
    "range_m": bistatic_r, "doppler_hz": doppler, "doa_deg": bearing,
}), qos=1)

What can go wrong: a node that silently stops publishing looks identical to empty sky. The service logs a heartbeat metric, and the COP side flags any node that goes quiet, the same health-check discipline as any production fleet.