Rationale — why this is worth building

Three questions a sceptical reader is entitled to ask before spending a weekend and ~$3K on a hardware project: (1) what's wrong with what already exists? (2) why is this newly possible? (3) who's already doing the same thing at industrial scale, and how does this build relate?

1. What's wrong with what exists

Drone detection is mostly sold as $50K–$200K active radar boxes — DroneShield RfPatrol, Dedrone DroneTracker, Aaronia AARTOS, Echodyne MESA-DAA. They work, they're FCC/CE certified, they have polished UIs and 24/7 support. But:

• They emit RF. Active radars announce themselves at 2–10 GHz with a clear waveform, which means an adversary with a $50 SDR can detect them from kilometres away. For covert deployments — forward observation posts, undisclosed VIP locations, anti-smuggling at borders — this is the wrong tool.
• They're closed. No source, no algorithm transparency. When the system misses a hostile drone, there is nothing to debug — just a vendor support ticket. For research, education, or any deployment where you need to understand why a detection happened, they're black boxes.
• They scale linearly with money. Two sites = $100K–$400K. Five sites for full coverage of a small facility = $250K–$1M. The economic model only works for organisations that already have a $10M security budget.
• They detect what their training data covers. Most commercial systems lean heavily on RF-fingerprint detection of known drone models (DJI, Autel, etc.). New, hobby-built, or first-person-view racing drones — the ones increasingly used in modern conflicts — are not in the database, and the system goes blind.

For the specific use case of small consumer drones in cluttered low airspace, on a hobbyist or research budget, with full algorithmic transparency — there is essentially nothing in the market. That's the gap this build fills.

2. Why this is newly possible

Two parts dropped in price and complexity in the last 24 months. Either alone wouldn't be enough; the combination is what makes a $3K passive radar realistic.

None of these were viable for a hobbyist budget two years ago. All three are off-the-shelf today.

3. Prior art — what scaled-up versions of this look like

Passive bistatic radar isn't a new idea. It has a 70-year history (the British Chain Home auxiliary system in WWII used a similar principle) and a vibrant academic and industrial community today.

• Lockheed Martin Silent Sentry (1998–present) — FM- and TV-illuminated passive radar against aircraft-class targets at 100+ km. Multi-metre antenna arrays, rack-scale processing, integrated with Patriot and other air-defence networks.
• Hensoldt TwInvis (Germany) — commercial passive radar product using DVB-T illuminators, deployed in NATO air-policing roles. Tracks airliners, helicopters, and military aircraft simultaneously over national-scale areas.
• Fraunhofer FHR PARADE / FKIE — German research consortium publishing extensively on FM/DAB/DVB-T passive radar, including specific work on small-UAV detection and micro-Doppler classification.
• Warsaw University of Technology (Malanowski et al.) — academic work on FM and DAB passive radar against UAVs at sub-kilometre range, using hardware not unlike what we're using here.
• Strathclyde / Cranfield (UK) — academic work on Wi-Fi, LTE, and most recently Starlink as illuminators of opportunity.

The build in this guide uses the same underlying technique as those systems — cross-ambiguity processing of a reference channel against a surveillance channel, with GPS-coherent multi-receiver geometry. The performance envelope is much smaller: where Silent Sentry detects airliners at 100 km using a 30-metre antenna array, our two log-periodics detect drones at 1 km. That's a deliberate choice. The small-drone problem doesn't need 100 km range, and the hardware that does reach 100 km is two-to-three orders of magnitude more expensive.

4. The cost-vs-commercial story

The headline number is one thing; the operational difference matters more. This build is the only entry in that table that is simultaneously covert (no emissions), open-source, and under $5K. For research, education, NGO security work, hobbyist defence-tech, and forward-deployed scenarios where active emissions are unacceptable, that combination has no commercial alternative.

5. What this build is not

To pre-empt over-claiming, here's what v1 will not do:

• It will not detect aircraft at 100 km. The antenna aperture is small and the bandwidth is narrow. The performance envelope is small drones at sub-kilometre range, period.
• It will not work in zero-FM-coverage areas. The illuminator is ambient FM broadcast. In the middle of the Pacific or behind a hill with no clear line-of-sight to a station, you'll need a different illuminator (DAB / DVB-T / cell tower — see Extensions tab).
• It will not stop drones. Detection is one half of the problem; interception is the other half, and it's a much larger project covered separately in the Chaser (v2) tab.
• It will not be FCC-certified. Passive receivers don't need certification, but if you commercialise this you'll have your own regulatory path to walk.

What it will do: reliably detect, localise, and classify small consumer drones at 300–1500 m in cluttered low airspace, on battery, covertly, with every line of code and every part-number documented. That's the value proposition.

Architecture

Four concepts to understand before touching any hardware: passive bistatic radar (how detection works without an emitter), GPS-disciplined timing (how two nodes 50 m apart can act as one coherent radar), foundation-model classification (how we skip training entirely and just ask a hosted VLM), and supervisory control (how a human stays in the loop without piloting anything).

1. Passive bistatic radar — detection without emission

Conventional radar emits a pulse and listens for the echo. Passive radar doesn't emit anything. It listens for energy that's already in the air — usually FM broadcast or DVB-T television — and looks for the reflections off targets. The illuminator is somebody else's transmitter; you only own the receivers.

For each target the system measures two things:

• Bistatic range — the extra distance the signal travels by bouncing off the target, vs the direct path from transmitter to receiver. Computed from the time delay between the two paths.
• Bistatic Doppler — the velocity component of the target along the bistatic geometry. Computed from the frequency shift in the reflected signal.

One receiver gives you a bistatic ellipse the target lies on (constant total-path distance). Two receivers give you the intersection of two ellipses → a localized target. With two sites and an FM transmitter ~5 km away, you get drone-class detection out to ~1 km in clear conditions. The diagram below is drawn with just one FM transmitter — that's the v1 build. The following diagram shows the recommended deployed picture, where each sentry listens to that FM tower and multiple cell sectors concurrently.

The math behind this is the cross-ambiguity function: a 2D correlation of the reference and surveillance channels over a grid of (delay, Doppler shift) hypotheses. Where the function peaks, there's a target. The peak's coordinates give you bistatic range and Doppler. This is what runs on the GPU at 10 Hz.

1b. Deployed view — one FM tower plus many cell sectors

The diagram above shows v1 with FM as the only illuminator — that's what you build on the first weekend. In any real urban or suburban deployment, however, you're surrounded by many radio sources, and the recommended deployed configuration adds a second KrakenSDR per sentry to listen to nearby LTE cell sectors concurrently with FM. The top-down view below shows what that looks like operationally — one strong, distant FM tower plus 5–20 weaker, closer cell sectors all illuminating the same airspace at once, with the sentries listening to all of them in parallel.

The two illuminator classes give you concentric detection rings: FM reaches further because it's 125× more powerful and uses 10× longer wavelengths; cell reaches less far but is 100× higher resolution and provides many independent geometric baselines. Inside the inner ring both bands see the target — that's where cross-band confirmation kills false alarms. See the Extensions tab → "Dual-illuminator" for the BOM delta (~$720/sentry) and the operational handoff sequence.

Top-down view of a deployed sentry pair. The FM tower (1, far, 10 kW) creates the outer "candidate" detection ring; the surrounding cell sectors (5–20, near, ~80 W each) create the inner "confirmation" ring. As a drone enters from outside, FM catches it first ("Target 1"); when it crosses into the cell ring it's confirmed and refined by the cell pipeline ("Target 2"). Build v1 with FM only, then add the second KrakenSDR per sentry to unlock the cell pipeline — see Extensions tab.

2. GPS-disciplined timing — making two boxes act as one radar

For two sites 50 m apart to combine their views into a single picture, they need to share a time reference. If site B's clock is off by 1 µs from site A's, the apparent target position is wrong by 300 m (1 µs × c). For useful localization you want sub-100 ns timing error.

The cheap, robust solution: each Jetson has a GPS receiver with a Pulse-Per-Second (PPS) output. Both Jetsons discipline their system clocks to GPS time using chrony. Each site independently times its IQ samples against its own GPS-synced clock. They are now coherent in time to within ~100 ns typical, ~30 ns best-case with strong GPS lock — well under the 1 µs threshold needed for sub-100 m localisation.

This replaces a much more expensive setup involving GPSDOs, 10 MHz reference distribution, and PPS cabling. We get good-enough time alignment by burning a few hundred lines of Python on cross-correlating the direct path between sites at startup (which calibrates out residual nanosecond-scale offsets), then maintaining via GPS-PPS continuously.

3. Foundation-model classification — skip training, just ask a VLM

Once the radar peaks at a (range, Doppler) cell, you still need to label it: drone, bird, helicopter, car, noise. The traditional move is to train a custom classifier — collect a labeled dataset, fine-tune a CNN on micro-Doppler signatures, deploy as a TensorRT engine. That's months of work and ongoing maintenance.

The shortcut: render each detection as an image and ask a hosted vision-language model to label it. Range-Doppler maps, micro-Doppler spectrograms, and (in v2) actual camera frames are all just images. Claude, GPT-4o, Gemini, and DeepSeek-VL all classify them with zero training data and roughly human-expert accuracy.

The classifier doesn't run on the sensor node at all. Each Jetson detects and computes a small image (a 128×128 range-Doppler patch, or a 1-second micro-Doppler spectrogram), packages it with a detection JSON, and ships both to the operator tablet over the mesh. The tablet — or the operator's laptop, or a cloud function — calls the VLM API and returns a label. Total round-trip ≈ 500 ms, which is well under the human decision time anyway.

Why this works in practice:

• The sensor's job is detection, not classification. CFAR + cross-ambiguity reliably tells you something is there. Naming it is a separate, slower step that benefits from a much bigger brain than fits on the Jetson.
• VLMs are good at "what is this image of?". Even when they've never seen a Doppler spectrogram before, a prompt like "this is a micro-Doppler spectrogram of a flying object — is it most likely a drone, bird, helicopter, or other? answer with one word and a confidence 0–1" gets useful answers.
• The model doesn't need to be on the drone. The chaser sends a JPEG over Wi-Fi 6E to the base station; the base station calls Claude / DeepSeek-VL; the answer comes back in <1 s. The chaser saves weight, power, and complexity by carrying just a camera and an encoder.
• Cost is negligible. A two-hour mission with one detection every 10 s is 720 API calls. At Claude Haiku rates that's ~$0.50.
• You can swap models at any time. Today's best VLM gets replaced by next quarter's. No retraining, just change the API endpoint.

4. Supervisory control — humans in the loop without flying anything

Once you have detections, what does a human do with them? There are three operating modes for any drone-detection-and-response system, and only one of them is sane.

The architecture treats the operator as the slow, smart, legal-authority component — not as a pilot. The chaser flies itself; the operator says yes or no. Latency budget is hundreds of milliseconds (operator decision time), which Wi-Fi handles trivially. We never need a sub-50 ms FPV link.

System block diagram — v1 (sensor only) → v2 (with chasers)

Why this design holds up

• Both nodes are identical. Same hardware, same software image, same OS. Configuration is one file (/etc/nomio/node.conf) that sets the unique node ID. Spares are interchangeable.
• Edge processing. Each node runs the full DSP pipeline locally on its GPU. Only KB/s of detections cross the mesh — never raw IQ (which would be 16 MB/s and saturate Wi-Fi).
• No infrastructure. No servers, no cloud, no fixed network. Two batteries, two tripods, one tablet, drop-in deploy.
• Failure modes are graceful. If one node dies, the other still produces single-site bistatic detections (just no localization). If GPS dies, you can fall back to direct-path cross-correlation. If the tablet dies, the OLED + LEDs on each box still tell you what's happening.
• Upgrade path is linear. v1 ships with a hosted-VLM classifier from day one (no training step) → add 3rd/4th sites for TDOA 3D localization (no architecture change) → add chasers (v2).

Sensor Node

Each site is one self-contained box. Inside: a Jetson Orin Nano running the radar pipeline on its CUDA GPU, a KrakenSDR doing the coherent multi-channel RF capture, a GPS HAT for time discipline, an OLED + LEDs for status, and a power bank running the whole thing. The box sits on a tripod with two log-periodic antennas mounted alongside.

Per-site block diagram

Power budget

The Jetson is configurable: 7 W, 15 W, or 25 W power modes. We run at 15 W ("MAXN_SUPER" mode at conservative throttle) — full 67 TOPS available, but moderated for battery life.

An 87 Wh power bank (Anker 737) gives ~3 hours of continuous operation. Add a 40 W folding solar panel ($60) for indefinite daytime use. For static deployment near power, just plug into a wall adapter.

3D-printed enclosure

A two-piece PETG case houses the Jetson + KrakenSDR + power bank in three internal trays. ~12 hour print on a Bambu A1, $8 in filament. External: 220 × 130 × 90 mm.

• Top tray: Jetson Orin Nano dev kit + GPS HAT stacked on the 40-pin header.
• Middle tray: KrakenSDR. Heat conducted to case wall via thermal pad.
• Bottom tray: Anker 737 power bank, slides in/out from rear.
• Front face: 0.96" OLED, 3 status LEDs, 1 push button.
• Rear face: 2× SMA bulkhead (RF in), 1× SMA bulkhead (GPS), 1× USB-C in (charging), 1× IP67 vent membrane.
• Bottom face: 1/4"-20 brass insert for tripod mount.
• Side faces: hex vent grilles aligned with Jetson cooler intake/exhaust.

STL files are produced by an OpenSCAD parametric model (in the project repo, enclosure/nomio_node.scad) where you set compute_module = "jetson_orin_nano", battery, weatherproofing, and mount.

What runs on each Jetson — software stack

Same software image for both nodes. Identity comes from a single config file.

• JetPack 6 (NVIDIA's Ubuntu 22.04 LTS for Jetson) as the base OS, on NVMe.
• gpsd + chrony reading NMEA + PPS from the Uputronics HAT. Disciplines the system clock to ~1 µs of GPS time.
• KrakenSDR DAQ daemon (official) capturing coherent IQ over USB 3.2.
• nomio-radar (the pipeline you'll write — see Playbook): Python + CuPy + cuFFT, ~600 lines, runs on the GPU. Cross-ambiguity at 10 Hz, CFAR detection, spectrogram-patch render. No on-device classifier — the patch ships to the base station which calls a hosted VLM.
• nomio-status: OLED + LED + button daemon (~100 lines Python).
• nomio-mesh: batman-adv mesh interface, mDNS via Avahi, signed message bus.
• nomio-web: FastAPI + WebSocket server for the operator tablet web UI.

All seven services managed by systemd, starting in dependency order on boot. Total install footprint ~3 GB on the NVMe.

Why not a Raspberry Pi 5?

Honest comparison. The Pi 5 is a fine general-purpose Linux box, but its compute envelope is a real bottleneck for radar work.

$170 difference, 40× compute uplift, and the difference between "barely functional demo" and "actually useful detection." If results matter, get the Jetson.

Bill of Materials

Every part you need to order, with linked sources and prices. Two columns: Per site means buy two (one for each node); Shared means one for the whole build. Prices are USD as of late 2025 — sanity-check at order time.

1 · Core compute & RF — buy 2 of each

2 · Antennas — buy 4 total (2 per site)

3 · Power — per site

4 · Status display + I/O — per site

5 · Mechanical — per site

6 · Test target & operator hardware (shared)

Grand total

For comparison: the equivalent commercial system from a defence vendor (DroneShield RfPatrol, Hensoldt Spexer 360r) is $50K–$200K. This is the same physics for ~$3K. The catch is you have to build it yourself, and the performance tail is shorter. For learning, prototyping, or low-stakes field work, that's a great trade.

What you don't need (and might be tempted to buy)

• A separate GPSDO (Bodnar Mini, etc., ~$300/site). Not needed in v1. The GPS HAT's PPS into chrony gets you to ~1 µs, which is good enough. Add a GPSDO only if you later want true coherent multistatic with sub-100 ns timing.
• Active cooling for the KrakenSDR. Already built in.
• A discrete USB-3 hub. The Jetson dev kit has 4× USB 3.2 ports — plenty.
• Pelican case. The 3D-printed case is fine for indoor or fair-weather field use. Drop in a Pelican only if you're going to deploy in rain/dust regularly ($80/case extra if you do).
• Big batteries (Jackery 240, 1000, etc.). Tempting for runtime, but adds 3–5 kg per site. The Anker 737 is the right size for 3-hour deployments.

Fast path — first detection in one day

The seven accelerants, ranked by impact

All seven combined: realistic ~12 hours of focused work from boxes-on-desk to first drone detection. This assumes parts are already on hand; the dominant remaining wait is shipping (~1 week from order to inventory).

Choosing a flash host computer

The Jetson Orin Nano dev kit ships blank. You flash NVIDIA's JetPack OS image onto its NVMe SSD using NVIDIA SDK Manager, which runs on a host computer connected over USB-C while the Jetson is in recovery mode. SDK Manager officially supports Ubuntu Linux only, but there are workable paths from Mac and Windows.

Pre-flashed NVMe vendors

This is the single biggest time-saver in the entire build. You order an NVMe SSD that already has JetPack imaged on it. You install the SSD in the Jetson's M.2 slot, plug in power, and the Jetson boots into Ubuntu on first power-on. No SDK Manager, no recovery mode, no flash host.

• Seeed Studio reComputer J3010 / J3011 — Jetson Orin Nano with pre-flashed eMMC or NVMe options. Sometimes sold as a complete pre-imaged compute module.
• Connect Tech Inc. (CTI) — JetPack-imaged NVMe drives sold as a separate SKU. Add to cart with the dev kit.
• SparkFun Jetson Orin Nano kits — bundle with optional pre-imaged storage.
• NVIDIA Reseller Network — Arrow / Symmetry / Mouser. Ask for "JetPack pre-imaged NVMe option" when ordering. Most distributors will ship it that way for an extra $50.
• DIY-but-faster fallback — find a friend with a Jetson, sudo dd if=/dev/nvme0n1 of=jetpack.img bs=4M on theirs, dd the image onto your fresh NVMe in any USB-NVMe enclosure. Takes 10 min, $0.

Optional convenience SKUs (everything that makes Day 1 smoother)

None of these are in the main BOM because they're not strictly required. But each one removes a real friction point. If your time is worth more than your money, buy them all.

The agentic workflow — running me in parallel

The single biggest leverage point is using your AI assistant concurrently rather than sequentially. The v1 build has roughly four independent software tracks; each can be developed in its own chat tab without conflict, then integrated.

While Tab 1 is writing the DSP pipeline, Tab 2 is scaffolding the React UI, Tab 3 is producing the chrony / batman-adv configs, and Tab 4 is writing the OLED driver. Each tab is its own independent task with no shared state. You're the integration layer — pull all four into the repo, resolve the rare config conflict, run end-to-end. Four hours of parallel chatting replaces a full weekend of sequential coding.

Bench setup — first detection in one room

1. Both Jetsons on AC power, sitting on your desk ~30 cm apart. Skip the battery for now.
2. Both KrakenSDRs plugged in over USB. Antennas just dangling — even the random coat-hanger is fine for direct-path reception of a 50 kW FM tower 5 km away.
3. Wired Ethernet between Jetsons and your Mac via a cheap unmanaged switch. Makes SCP / SSH instant. Wi-Fi works too but adds latency.
4. VS Code on your Mac, Remote-SSH'd into Jetson 1. Edit code on the Jetson directly. Save → systemd restart → see effect.
5. Open four chat tabs with me as described above. Drive each track in parallel.
6. For the first drone fly-by: stand by the open window. Have a friend (or yourself, with a timer) fly a small drone 50–100 m past the window. Both Jetsons should see the bistatic Doppler trace simultaneously.

One-day timeline (with all shortcuts active)

What still takes the second weekend

• Mounting in the 3D-printed case — when the print is done. Mostly mechanical work, no debugging.
• Battery / outdoor deployment — moving from bench to actual field positions on tripods. Real RF environment, real weather, real distances.
• Tuning CFAR for your specific environment — every site has a different clutter profile. Iterative.
• Polishing the operator UX — turning the bench-grade tablet UI into something you'd hand a non-engineer.
• Cloning to the second Jetson — dd the NVMe, change the hostname, set up mesh.

That's all real but undramatic work. The hard part is the first detection, and that fits in a Saturday with a competent partner.

User Interface — the operator's view

An Android tablet (or iPad) is the only thing the operator needs in the field. It runs a web app served from one of the sensor nodes, talks to the mesh over Wi-Fi, and pairs over Bluetooth on first use. No native app, no laptop, no flight sticks.

Pairing — once, in 5 seconds

• Boot a sensor node. Press the front-panel button. The OLED shows a 6-digit fingerprint of the node's network key.
• On the tablet, open the Nomio web app (just http://nomio-a1.local when on the same Wi-Fi). Tap "Pair new node". Bluetooth scan finds the node.
• Compare fingerprints. Tap "Confirm". Bluetooth exchanges the mesh key. Done.
• From now on, the tablet auto-joins the mesh whenever any sensor node is in range. Same model as Apple's AirTag/HomePod pairing.

What the tablet shows — v1 (sensor only)

┌─────────────────────────────────────────────────────────────┐
│  Nomio Operator Console      mesh: ✓  GPS: ✓  power: 82%    │
├──────────────────────┬──────────────────────────────────────┤
│   MAP                │  RANGE × DOPPLER (live, 10 Hz)       │
│   ─────              │  ┌────────────────────────────────┐   │
│   • Site A   GPS ✓   │  │   ▒▒▒░░░     ▓                 │   │
│   • Site B   GPS ✓   │  │   ▒░░         ▓░               │   │
│   ✕ T-7      drone   │  │     ░░         ▓               │   │
│   ✕ T-8      bird    │  │       ░░       ░               │   │
│   ✕ T-9      car     │  │            T-7 ◯               │   │
│                      │  └────────────────────────────────┘   │
│   bistatic ellipses  │  T-7  range 380m · -8.2 m/s · p=0.94  │
│   for each track     │                                       │
├──────────────────────┼──────────────────────────────────────┤
│  DETECTION QUEUE     │  EVENT LOG                           │
│  T-7  drone   p=0.94 │  19:42:11 T-7 first seen, 580m bistat │
│  T-8  bird    p=0.71 │  19:42:14 T-7 classified drone p=0.94 │
│  T-9  car     p=0.99 │  19:42:30 T-9 confirmed across 2 nodes │
└──────────────────────┴──────────────────────────────────────┘

Three regions: map (left, ground-truth situational picture from the sensor mesh), range-Doppler heatmap + selected track (right, the actual radar output for the currently-selected detection), queue + event log (bottom, a chronological list of what's been seen).

What the tablet shows — v2 (with chasers)

When chasers are added in v2, the right-hand region splits to show live H.265 video from whichever chaser is currently engaged, with a command bar below for supervisory control. See the Chaser tab for details.

Channel comparison — why Bluetooth pairs and Wi-Fi streams

Several builders' instinct is to use Bluetooth for the data plane. It's the wrong fit. Here's the comparison.

The AX210 module in the BOM already includes Bluetooth 5.3 as a side effect — it's a combo Wi-Fi+BT chip. So BT is on the unit anyway, doing what it's good at: short-range pairing.

Web UI implementation

• Single-page React app, built with Vite, served as static files from FastAPI on the sensor node.
• Detection stream over WebSocket from /ws/detections. JSON messages, ~10 per second per active track.
• Range-Doppler heatmap rendered to <canvas> via WebGL. The heatmap is downsampled on the node side to ~256×256 px to keep the wire payload small.
• Map uses MapLibre GL with offline tile bundles cached on the tablet.
• BT pairing uses the Web Bluetooth API in Chrome on Android, or a native helper app on iOS (Web Bluetooth isn't supported in iOS Safari; that's a known limitation).

Without a tablet — fall-back operator UX

• OLED on each node shows live status (GPS, SDR, peer count, dets/min, battery). Enough for "is it working" without any other device.
• LEDs on the front panel: green = healthy, blue blinking = waiting for GPS, blue solid = locked, red flash = active detection, yellow = low battery.
• SSH from any laptop on the same Wi-Fi: ssh nomio@nomio-a1.local gets you a console with live tail -f on the detection log.

Extensions — near-term additions to v1

1. Micro-Doppler from rotors at FM band — feasibility

The first question worth answering: can the v1 FM-band passive radar see rotor-blade micro-Doppler, or only the bulk-motion Doppler of the airframe? Micro-Doppler is the modulation the spinning rotors impose on the reflected signal — a "fingerprint" that distinguishes a quad from a bird, a helicopter, or an airplane far more reliably than range/Doppler alone. It's the most powerful classification feature passive radar can produce.

The math says yes — modestly

Micro-Doppler resolution depends on integration time, not on illuminator bandwidth. With 1 s of coherent integration at 100 MHz FM:

• Doppler resolution: 1 / 1 s = 1 Hz
• Velocity resolution: c · 1 Hz / (2 · 100 MHz) = 1.5 m/s
• Quad rotor tip speed: 5,000 RPM × 0.12 m radius × 2π / 60 = ~63 m/s (so tip Doppler shift = ±42 Hz at FM — well within resolvable range)
• Number of resolvable bins on the rotor: ~84 / 1 = ~80 Doppler bins across the blade-tip return — more than enough to see "blade flash" lines

What it costs to add

• Pipeline change only — no new hardware. Increase coherent integration time from the 0.1 s baseline (used for fast detection) to 1–2 s for confirmed targets. Render the result as a 2D micro-Doppler-vs-time spectrogram (the "blade flash" pattern is unmistakable visually).
• Cost: 0$ in hardware, ~1 weekend of pipeline work. Add a "long-CPI confirmation pass" stage after the v1 detector fires.
• Compute headroom: the Jetson has ~50% spare at 10 Hz with 0.1 s CPI. A 2 s CPI confirmation runs once per detection (not every frame), so the GPU cost is trivial.
• Classifier benefit: blade-flash micro-Doppler is the single feature that most reliably separates "drone" from "bird" in VLM zero-shot classification. Send the spectrogram patch to the VLM with a prompt like "Does this micro-Doppler spectrogram show periodic blade-flash modulation lines? Yes/no, and if yes, estimate the rotor RPM." — VLMs handle this surprisingly well.

Prior art (FM-band rotor micro-Doppler on drones)

• Schroeder & Edrich, "FM-radio-based passive radar — UAV detection with focus on micro-Doppler features," FHR / IRS conference, 2017.
• Malanowski et al., "Detection of small UAVs using passive radar with FM and DAB illuminators," Warsaw University of Technology, 2018+.
• Daun & Berger, "Track-before-detect for small UAV in FM-PCL," Fraunhofer FKIE.
• Pell et al., "Drone classification from FM passive-radar micro-Doppler," 2020.

2. Acoustic mic-array — nighttime / RF-quiet complement

RF passive radar struggles in two situations: heavy urban RF clutter, and any environment where the ambient FM signal is weak (rural, indoors, behind a hill). A small acoustic mic array bolted to the side of the v1 sensor box gives you a completely independent detection modality — one that's actually better at night, when consumer drones are most likely to be flown for surveillance or smuggling.

What the literature says

• Consumer quads emit a distinctive 80–200 Hz fundamental (rotor passing frequency) plus harmonics out to ~5 kHz. Easily detectable to ~300–500 m in still, quiet air with even a single omnidirectional mic.
• A 4-element microphone array (~10 cm spacing) gives ±5° bearing-of-arrival on the drone via cross-correlation TDOA. Two acoustic-equipped sentries triangulate position the same way the FM passive radar does — and they don't care whether the FM tower is up.
• Acoustic detection is largely weather-independent at short range, works in zero ambient RF, and provides a strong "yes it's a drone" confirmation signal because the acoustic signature is unmistakably mechanical.

Hardware

Pipeline

• ~50 lines of Python + numpy/scipy. 16 kHz sampling on 4 channels, sliding 1 s STFT, peak-pick the harmonic stack, GCC-PHAT TDOA across mic pairs for bearing.
• VLM confirmation: render the 4-channel spectrogram as one image, ask the same VLM that does RF classification: "Is this the acoustic signature of a small consumer drone?" One-line prompt, same code path as the radar classifier.
• Sensor fusion: when both RF radar and acoustic agree on direction within ~10° → very high confidence drone detection. When only one fires, lower confidence. The operator sees both in the UI.

3. Cell-tower variant — illuminator swap on the same hardware

The v1 build is FM-illuminated. A cell-tower (LTE / 5G NR sub-3 GHz) variant replaces only the antenna and the reference-channel logic — every other piece of the v1 system is unchanged. It's the natural next step once v1 is working, especially in areas with weak FM coverage but dense cell sites.

What changes vs v1

Why this is the elegant successor to v1

• Same architecture. Two ground sentries, GPS-disciplined timing, mesh + tablet. Drop-in.
• Open-standard waveform. 3GPP specs are public — the reference channel synthesizes from spec, no blind reconstruction, no proprietary puzzle. Much easier than Starlink.
• Mature prior art. ESA, NATO, Lockheed, Hensoldt, and several university groups have working LTE / 5G passive radar. It's a known-good technique, decades of literature.
• Hardware cost: marginal. A wideband SDR replaces the KrakenSDR ($720–1,200 vs $400). Antennas drop in price. Per-sentry total roughly the same as v1.
• Range resolution improves 100×. 15 m vs 1.5 km. Drones are no longer "blob in a big bin" but "object with measurable structure."
• Free multistatic. From one ground location you see 5–20 cell sectors as separate illuminators — automatic geometric diversity.

4. Dual-illuminator (FM + cell tower) — the natural endpoint

Once both pipelines exist, there's no reason to choose. Run FM and LTE simultaneously on the same sentry, with each illuminator getting its own dedicated SDR + antenna array. Two cross-ambiguity pipelines on the same Jetson, fused at the track level. The Orin Nano Super has the GPU headroom and the BOM cost is modest.

Why it's worth doing

• FM gives long range, cell gives high resolution. FM detects the drone at 1–3 km but in 1.5 km bins. Cell only sees out to ~0.3–1 km but in 15 m bins. Combined you get FM's range with cell-confirmed structure once the target enters the cell-illuminated zone — best of both.
• Two completely independent modalities. A real drone shows up coherently in both bands. Birds, RFI, multipath ghosts, and most jamming attempts show up in only one. Cross-band agreement is a near-free false-alarm killer.
• Defense in depth against jamming. Adversary has to deny two very different bands (88–108 MHz and 600–3500 MHz) simultaneously. Vastly harder than jamming a single band.
• Geometric diversity stacks. 1 FM tower + 5–20 cell sectors = 6–21 independent bistatic geometries from one sentry. Track ambiguities resolve naturally.

Recommended hardware — two full KrakenSDRs (or Kraken + wideband)

The clean answer is to give each band its own full 5-channel array. Don't compromise the AoA precision on either band by sharing a single Kraken's channels.

BOM delta per sentry vs v1

Two sentries = ~$4,000 total — still well below any commercial system, with simultaneous FM + LTE detection and full angle-of-arrival on both bands.

The numbers all check out on the existing Jetson

• USB. Each Kraken streams ~36 MB/s (3.6 MS/s × 5 ch × 2 B). Two Krakens = 72 MB/s. Jetson Orin Nano USB 3.2 = 5 Gbps ≈ 600 MB/s. Plenty of headroom.
• GPU. Two parallel cuFFT cross-ambiguity pipelines + two CFAR detectors ≈ 50% of Orin Nano Super's 67 TOPS. Plenty.
• Power. Each Kraken ~5 W. Sentry total goes from 25 W → 30 W. Same battery, same solar.
• GPS coherence. Drive both Krakens' external clock + PPS inputs from the same GPS-disciplined OCXO via a tiny RF distribution amp. The two boards are then phase-coherent with each other, enabling cross-band fusion that's not just track-level but signal-level if you ever want to go deeper.
• Antenna mast. FM dipole array (~3 m wide) on the bottom, LTE log-periodic array (~50 cm wide) on top. The frequencies are a decade apart — they don't electromagnetically couple in any meaningful way.

Operational handoff — FM acquires, cell confirms and refines

Because every sentry runs both bands concurrently, the two pipelines aren't an either/or — they're a tag-team that hands the target between them as it closes. The link-budget physics drives the sequence:

So in nominal geometry the operational sequence inside one sentry looks like:

1. Drone enters at ~2 km. FM pipeline acquires it first. Coarse range (1.5 km bin) but a clean detection — the operator UI flashes a "candidate" track.
2. Drone closes to ~800 m. Cell pipeline acquires the same target. Now the same track has a 15 m range bin, refined Doppler, and the start of micro-Doppler structure for classification.
3. Inside ~500 m both pipelines track simultaneously. Cross-band agreement promotes the track from "candidate" to "confirmed." Operator UI goes red. The VLM classifier gets fed both spectrograms.
4. Inside ~300 m cell dominates the position estimate (better resolution); FM provides redundancy and continues to track even if the cell network drops or is jammed.

Reference numbers from published prior art on similar consumer-quadcopter targets: FM-based passive radar reaches 1–3 km (Malanowski, Warsaw University); LTE-based reaches 0.3–1 km. Field tuning will shift these by ±50% depending on local FM/cell tower geometry, but the relative ordering — FM-first, cell-second — is consistent in the literature and falls directly out of the radar equation.

Software architecture

Two independent DSP pipelines run side by side, each producing its own track list. A small fusion module above them does track-level association: a candidate track is promoted to "confirmed" only if it appears in both bands within a small spatial + temporal gate (e.g. ±50 m, ±0.5 s). Single-band tracks remain visible but are flagged "single-modality" in the operator UI — important during the FM-acquired-only phase before the target enters the cell-illuminated zone. ~300 lines of Python on top of two copies of the v1.5 / v1 DSP code.

5. Other ideas captured here so we don't lose them

• DAB / DVB-T as a third illuminator — VHF-III (174–230 MHz) and UHF (470–800 MHz) digital TV. ~7 MHz BW gives ~21 m range resolution. Reference is fully decodable (open standard). Strong illuminator in Europe; less in the US. Slot between FM (v1) and LTE (v1.5).
• Camera + VLM cued from the radar — once a target is at known bearing, slew a $50 PTZ camera to it and capture a JPEG. Send the image + radar spectrogram + acoustic signature to the VLM together. "Three independent modalities all say drone" → very high confidence.
• Passive-RF emitter detection (companion modality) — most consumer drones emit a 2.4/5.8 GHz video downlink + telemetry. A second SDR pointed at those bands gives an independent detection channel that's deterministic when present (the drone is literally telling you it's there). Combine with passive radar to confirm.
• Lightweight on-device classifier as a gate before VLM — a tiny TensorRT model (a few MB) running on the Jetson can pre-filter the obvious noise and only escalate ambiguous detections to the VLM. Cuts API calls by ~10×, latency by ~5×.
• Long-baseline TDOA with a third sentry — adds true 3D localisation (altitude estimation), eliminates the 2-sentry ambiguity, only needs another KrakenSDR + Jetson box. ~$1,500.
• Solar / mains powering the sentries — current spec is 87 Wh power bank ⇒ ~3 hr runtime. A 100 W folding panel + small charge controller turns this into permanent deploy. Already noted in BOM but worth elevating.
• Auto-cue handoff to law enforcement / facility ops — when a confirmed drone enters a defined geofence, push an SMS / Slack / email with photo + bearing. Pure software, integrates with Twilio / Slack webhook in ~50 lines.

Suggested order of attack after v1 ships

1. Acoustic mic array — best ROI by far. ~$20, weekend of code, qualitative leap in nighttime + RF-clutter performance.
2. Long-CPI micro-Doppler confirmation — pure software, dramatic classifier improvement, no new hardware.
3. Lightweight on-device classifier gate — cuts API costs, improves latency, frees compute headroom.
4. Cell-tower (v1.5) illuminator swap — bigger lift (new SDR, new reference-channel code) but unlocks 100× range resolution and works where FM doesn't.
5. Dual-illuminator (v1.5-dual) — once cell pipeline works, add a second KrakenSDR and run FM + cell concurrently. ~$720/sentry. Cross-band fusion eliminates most false alarms and raises the bar for jamming.
6. Camera cue + RF emitter listener — small additions, dramatic classifier confidence improvement.
7. Then Chaser / CAP / Starlink (the architectural rewrites in the Future tabs).

Chaser — v2 forward architecture

Three architectures to choose from

There are three clean ways to put the system together, and the right one depends on whether you're defending a fixed site, a mobile unit, or a forward position. Each is detailed below; this is the cheat sheet:

Below: the original two options where ground radar does the wide-area surveillance, and a third where you skip the ground radar entirely and let an airborne swarm do both detection and engagement.

Two ways to split the AI: dumb drone (A) or smart drone (B)

Both of the next two options assume you have the v1 ground radar doing initial detection. They differ only in where the chaser's "is this still a drone?" intelligence runs:

Option A · Smart base, dumb drone

The chaser is deliberately stupid. It's a small quadcopter (~250–500 g) that does only three things: fly where it's told, stream H.265 video over Wi-Fi or OcuSync, and keep itself from crashing. All AI lives at the base station on a Jetson sitting next to the operator's tablet. Classification, target tracking, intercept geometry, abort decisions — all happen at the base. The chaser is just a flying camera with a flight controller.

This inverts the usual industry assumption (which is that the chaser carries its own AI compute). It works because we have a fat video link (OcuSync or Wi-Fi 6E) and a hosted VLM. The chaser doesn't need a Jetson, doesn't need a YOLO model, doesn't need a trained dataset. It needs a flight controller and a video link.

Chaser hardware (per chaser) — radically simplified

Industry chasers typically include a $500–1,500 companion computer (Jetson, Khadas, RB5) running on-board YOLO. By moving the brain to the base station and using a hosted VLM, the chaser collapses to "FPV drone with a video link" — a $700 part you can build from a kit.

Even better: skip the build, use a DJI

Once the chaser is "just video + waypoints", building a custom airframe is mostly hobby effort. The pragmatic move is to use an off-the-shelf DJI drone with the Mobile SDK as the chaser. You get a flight controller, gimbal, obstacle avoidance, RTH, GPS, 30+ minute battery, type certification, and a tested 5–15 km video link — all free, all reliable, all already built.

Three things to understand before picking this path: how DJI actually communicates, which SDK you need, and where the gotchas are.

How DJI drones communicate

Consumer DJI drones (Mavic, Mini, Air, Avata, FPV) talk to a remote controller (RC) over a proprietary RF link called OcuSync (currently O3 / O4 — the latest generation). It's a 2.4 / 5.8 GHz frequency-hopping link with adaptive bitrate, ~5–15 km range, and ~120 ms glass-to-glass video latency. The RC then connects to a phone or tablet via USB. Your Mobile SDK app on the phone gets the video stream and sends commands back, all via the RC.

So the path looks like:

DJI drone  <-- OcuSync RF -->  DJI RC  <-- USB -->  Android phone (your MSDK app)  <-- Wi-Fi -->  base-station Jetson

The phone is the bridge. It runs your Android app (built against MSDK v5), pulls H.265 video and telemetry from the drone, sends the video over Wi-Fi to the base-station Jetson for VLM tracking, and forwards waypoints/commands back to the drone. No 3G/4G needed for short-range work — the Wi-Fi 6E mesh you already have for sensors covers it.

For longer range or BVLOS work, the alternative is an enterprise drone (Matrice 30/300/350) with an LTE module — the drone uploads video over 4G straight to the cloud or your server, no RC needed. But you don't need that for v2.

Which SDK to use

Recommended drone

Trade-offs vs the DIY airframe

The "headless RC" pattern — fully SDK-driven, no human pilot

OcuSync is closed. There is no OcuSync receiver chip you can wire into the Jetson directly — the only thing on Earth that demodulates an OcuSync stream is a DJI controller. So the RC stays in the system, but a human never touches it. It becomes a $0-extra USB-to-OcuSync dongle that sits inside the base-station case with antennas sticking out.

Mavic 3 Pro
   |  OcuSync RF (15 km, proprietary, free)
   v
DJI RC 2  <-- headless: paired once, then sits next to the Jetson
              with antennas up. Converts OcuSync to H.265 over USB.
   |  USB-C
   v
Android instance  <-- Anbox/Waydroid container on the Jetson, OR a
                      $40 Android TV stick, OR an old phone zip-tied
                      to the rig. Runs your MSDK v5 app (~200 lines Kotlin).
   |  localhost / Wi-Fi
   v
Jetson Orin Nano (base station)
   - NVDEC decode H.265
   - CSRT fast tracker (30 Hz)
   - VLM slow tracker (1 Hz)
   - Mission executor sends WaypointV2 / VirtualStick back up the chain

From the operator's perspective it's pure SDK: the tablet shows the video, supervisory buttons drive WaypointV2 commands, no one ever picks up a controller. The RC is hardware infrastructure, not a UI device.

What changes in the rest of the architecture

Almost nothing. The fast/slow visual-tracker loop on the base-station Jetson is unchanged. Steering corrections become DJI VirtualStick or WaypointV2 commands (issued via the MSDK Android app) instead of MAVLink to a Pixhawk. The hybrid VLM tracker doesn't care what the airframe is.

Per-chaser BOM — DJI / SDK path

For a POC, build one chaser. Add more only after the single-chaser loop works end-to-end against a real test drone.

Where the smarts actually live — the base station

The base station is just an extra Jetson Orin Nano (the same module as the sensor nodes) sitting on the operator's table next to the tablet. It runs:

• Mission executor. Takes high-level operator commands (INVESTIGATE, RTB, ABORT, HOLD) and translates them into waypoints — MAVLink for the DIY airframe, DJI WaypointV2 / VirtualStick for the Mavic. Trivial state machine, ~500 lines.
• Hybrid visual tracker (described in detail below). A fast local tracker keeps a bounding box on the drone every frame; a hosted VLM verifies identity periodically. ~600 lines of Python.
• Intercept-geometry planner. Given target velocity (from radar) and chaser state, computes a safe approach trajectory. Modified pursuit-curve logic. ~1K lines.
• Safety layer. Geofencing, battery-reserve return, lost-link return, radar-vision cross-check abort. The legally-mandatory part for civilian use. ~1K lines.
• Operator UI bridge. Same tablet as v1. Adds video feed + supervisory buttons. ~400 lines on top of the v1 web app.
• Terminal action (if applicable). Net-launcher trigger, beacon-emit-and-track, escort-and-land — depending on what the chaser is for. Always human-authorized via the supervisory pattern. ~200 lines plus the hardware.

Total base-station code: ~3K lines, all on one Jetson, all easy to iterate. When you want to upgrade the tracker, you edit one Python file. You don't re-flash any drones.

Hybrid visual tracker — fast local loop, slow semantic loop

The naïve "send every frame to Claude" pattern doesn't work for live pursuit: a hosted VLM round-trip is 200 ms – 2 s, and a drone moving at 10 m/s covers 10 m in that second. We solve it the way classical robotics does — two loops at different speeds:

The fast loop drives the steering. The slow loop catches the failure modes the fast loop is blind to: target swap, occlusion recovery, "wait that's actually a kite". When the slow loop disagrees with the fast loop, the fast loop gets corrected (or the system pauses and asks the operator).

Tracker options — pick by what's available

The recommended default for v2: CSRT (fast loop) + Claude Haiku (slow loop, every 1 s). Total tracker code: ~150 lines. No training. Cents per mission.

End-to-end latency budget — chaser pursuit

The flight controller's innermost loop (attitude stabilization) runs at 200 Hz on the chaser regardless — that's the part that physically can't tolerate latency, and it's already local. The base station only ever issues outer-loop guidance ("steer 5° left", "climb 2 m"). That outer loop at 18 Hz from the fast tracker is more than enough for visual pursuit; it's the same control bandwidth a human FPV pilot has.

Option B · Smart drone, dumb base

Invert the architecture: put the AI on the chaser. The drone carries its own Jetson, runs the detector and tracker locally, makes its own go / no-go decisions about whether it's looking at a drone, and only sends a thin telemetry stream back: "I see a quadcopter, confidence 0.92, range 80 m, my position is X/Y/Z, I'm pursuing — should I continue?". The base station becomes a thin supervisory console, not a real-time AI engine.

What runs on the drone

The chaser becomes self-sufficient. Same software pattern as the base-station Jetson in Option A, just running on a smaller, drone-mounted Jetson:

• Onboard tracker. CSRT or YOLO-World at 30 Hz from the local camera. Same code as Option A's fast loop, just runs locally and never blocks on a network.
• Onboard classifier. A small VLM like Moondream 2 (~150 ms/frame on Orin Nano) or YOLO-World with the prompt "small flying drone, quadcopter, helicopter, bird, kite" — open-vocabulary, no training, no labelled dataset. The drone makes its own "yes this is the target" / "no, this is a bird" judgements.
• Onboard mission executor. Same state machine as base in Option A, just lives on the chaser. Takes high-level commands from the operator (INVESTIGATE, RTB, ABORT) over a low-bandwidth telemetry link, runs the pursuit locally.
• Periodic snapshot uplink. Every 1–2 s, the chaser sends a single ~50 KB JPEG to the operator tablet plus a few hundred bytes of telemetry. Enough for human-in-the-loop supervision; nothing like the bandwidth of a live H.265 stream.

Onboard compute options

For v2, the Jetson Orin Nano is the obvious default — same module as the sensor nodes, same software stack, same JetPack environment. The drone literally runs a stripped-down clone of the base-station image.

BOM — Option B (DIY airframe with onboard Jetson)

Why no DJI in Option B: consumer DJI drones don't let you mount a companion computer with your own code. Only Matrice 30/300/350 with OSDK do, and those start at ~$13K. So Option B is effectively DIY-only unless you're spending enterprise money.

Trade-offs vs Option A

Option C · Airborne CAP — chaser swarm, no ground radar

A third architecture: skip the ground radar entirely. Station a ring of self-sufficient chasers (Option B compute pattern) on the perimeter of the area you're defending, each looking outward with 360° vision. Every inbound threat must cross the ring to reach the protected unit — so detection becomes a tripwire, not a search. Each chaser is both sensor and interceptor; when one sees a target, the adjacent drones instantly triangulate, and the nearest closes for terminal action. The "base station" is just a tablet plus a charging pad.

This is essentially the architecture Anduril's Roadrunner, Israeli SkyLock, and the Ukrainian FPV-interceptor programs are built on. It's the right pattern for a forward-deployed tactical scenario — troops being targeted in the field, threat area is known approximately, deploy time matters, and you can't set up two tripod-mounted radar sites.

The perimeter ring pattern — preferred mode

The cleanest deployment is a fixed perimeter ring, not a raster search. Here's the geometry:

• Station the drones in a circle at 500 m – 1 km radius around the protected unit. 9 drones equally spaced = each owns a 40° wedge of azimuth.
• Four cameras per drone — one on each face of the airframe — give every chaser a full 360° view. Onboard Jetson Orin Nano supports up to 4 MIPI CSI cameras natively. Adds ~$120 to the per-chaser BOM (3 extra IMX477 sensors).
• Each drone holds station at ~150 m altitude and watches outward. Because the FOV per camera (~90°) is wider than the 40° wedge each drone "owns", adjacent drones see overlapping airspace — so every patch of horizon is visible to at least two drones simultaneously.
• Detection is a tripwire, not a search. Any inbound threat must cross the ring to reach the protected unit. The instant it enters the field of view of any ring drone — typically when it's still ~500 m outside the ring — it's seen, in the next camera frame. Detection latency: ~33 ms, not 10–30 s.
• Triangulation is free. Two adjacent drones see the same target from different angles. Two-bearing intersection gives 3D position to ~5–15 m accuracy at 500 m. Same physics as the v1 ground radar — airborne and instant.
• Battery rotation. When a drone's battery drops below 30%, it flies inward to land at the charging pad while a fresh one takes its station. ~30 s gap per swap; the neighboring drones' overlapping FOV covers the temporary blind spot.

Coverage math — perimeter ring

The raster pattern — alternative when you have fewer drones

If you have only 3–4 chasers (not 9–12), the ring becomes too sparse to be a reliable tripwire. In that case, fly a coordinated raster pattern instead: each drone owns a sector and sweeps it at 15 m/s, ~150 m altitude. Detection latency rises to 10–30 s (depending on raster phase), but you cover the same area with a third of the assets. Use raster for low-budget POC; upgrade to a ring once you have hardware to support it.

Hardware — same as Option B, plus 3 extra cameras per drone

Per-chaser BOM is Option B + four cameras instead of one:

The "base station" collapses to:

• One Jetson Orin Nano running mission coordination, video aggregation, operator UI, and the supervisory tablet bridge
• One ruggedized tablet for the operator
• Multi-bay charging pad / battery hot-swap station (capacity for 12 × LiPo packs)
• One long-range telemetry radio (RFD900x or LTE modem) to talk to the swarm

Total system cost for a 12-chaser perimeter ring: ~$15,500–17,000 (12 × $1,300 chasers + ~$1,500 ground kit). Substantially more than the 4-chaser raster system (~$6,000) — but you get persistent 360° coverage with sub-second detection latency over a 1.5 km bubble.

Comparison: perimeter ring vs raster CAP

Terminal action options

"Crash into it" is one option, but you have a spectrum:

Trade-offs vs ground-radar approach (v1 + Option A/B chaser)

Honest gotchas

• False positives. Birds at 300 m look exactly like drones. The VLM verification loop is what keeps you from wasting interceptors on geese. Mandatory.
• Multi-target prioritization. If the threat is a swarm, you need the chasers to not all converge on the same target. Trivial bidding protocol in code, but a real design point.
• Collision avoidance between friendlies. 3–4 drones in the same airspace. ADS-B-like beacon plus geofenced wedges per drone solves it, but you have to design for it.
• Weather. 30-min flight time becomes 20 min in 30 km/h winds. Plan for it.
• Radio congestion. Telemetry mesh between chasers + uplink to operator on the same band as the target's control link is a recipe for interference. Use a dedicated swarm band (915 MHz / 433 MHz for telemetry) separate from the target's 2.4/5.8 GHz.
• Legal. Airborne armed CAP is a defense-context capability. Civilian operators get net-capture or escort-and-report; kinetic terminal action is military / authorized law-enforcement only.

Real-world precedents

This isn't speculative — variants of this architecture are operational:

• Anduril Roadrunner-M. Reusable VTOL interceptor with onboard AI, launched on cue. Same architectural pattern.
• Anduril Anvil-M. Smaller kinetic interceptor; same idea at lower price point.
• Israeli SkyLock + Smash Dragon. Forward-deployed counter-UAS with onboard detection.
• Ukrainian "Sting" interceptors. Effective wartime use of FPV-class drones for counter-UAS, mostly with human-in-the-loop piloting today; the autonomy pieces are being added.
• Fortem DroneHunter. Net-capture interceptor, used at fixed sites and as a CAP asset.

What's new here isn't the architecture — it's that the per-chaser cost has dropped from $30–100K (Anduril class) to ~$1,200 (Jetson + commodity airframe + open-source autonomy), thanks to the same two trends that made v1 cheap: cheap edge-AI compute and foundation-model classifiers that skip the training step.

Hybrid (Option AB) — fast loop on drone, slow loop at base

The pragmatic mature design borrows from both options:

• On the drone: CSRT + tiny detector (YOLO-World) running locally at 30 Hz drives steering. Drone keeps tracking even if comms drop.
• At the base: the drone uplinks 1–2 frames per second over telemetry. Base runs a hosted VLM ("is this still the right target? did we drift to a kite?") and sends back identity corrections. Operator sees the full picture.
• Comms requirement: ~100–500 kbps (a few JPEGs/sec + telemetry), much less than the multi-Mbps of full Option A but more than the bare-telemetry Option B. Works over LTE, RFD900x with a video board, or short-range Wi-Fi.

This is what you eventually want for production. Start with Option A, evolve to Hybrid AB. Pure Option B only if your operational envelope demands it.

How the operator interacts in v2

• Confirmed track from sensor mesh appears on the tablet. Audible alert: target confirmed.
• Operator taps INVESTIGATE. The mesh dispatches the nearest idle chaser. Live H.265 video appears on the tablet within a few seconds.
• Operator can issue HOLD (chaser circles), RTB (return to base), ABORT (immediate safe land), or SWITCH TARGET.
• For systems with a terminal action, AUTHORIZE TERMINAL requires two paired tablets to confirm within a 5-second window — a hard-coded two-person rule. Configurable for non-kinetic systems.
• Chaser executes, returns, lands itself, recharges. Operator never piloted anything.

Why this is the right pattern

Three reasons to lean hard on supervisory control over either extreme:

• Legal. Civilian C-UAS regulations in essentially every jurisdiction require a human in the loop for any kinetic action. Fully autonomous engage is not legal almost anywhere.
• Robust. The autonomy will get edge cases wrong (news helicopter, mistaken classification, GPS-spoof attack). A human at the supervisory layer is the cheapest, most reliable last-line defence.
• Scalable. One operator can supervise 4–8 chasers in parallel. Manual piloting tops out at one operator per drone. Fully autonomous is nominally infinite-scale but isn't trusted enough yet.

Where v2 fits in the timeline

These estimates assume you're working with an AI coding assistant (Claude, Cascade, DeepSeek, etc.) writing 90%+ of the code. The bottlenecks are physical: hardware lead times, antenna placement, field testing windows, regulatory approvals — not lines of code.

• v1 (this guide): sensor mesh + tablet. Two focused weekends of work after parts arrive — one to assemble and bring up, one to tune in the field. Demonstrates detection, classification, multi-site fusion.
• v1.5: add a 3rd and 4th node, swap incoherent fusion for real TDOA 3D localization. One weekend on top of v1: nodes 3 & 4 are clones of node 1's image, and TDOA from already-aligned timestamps is ~200 lines of Python the LLM writes in an hour. The week-ish of elapsed time is parts shipping, not coding.
• v2 (chaser): single chaser drone with autonomy stack and supervisory UI. Realistically 2–4 focused weeks of work, gated by flight-test windows and the iteration loop on the vision tracker. Most of the "12-month" number you see in industry is regulatory paperwork, hiring, and writing code by hand — none of which apply here.
• v3 (multi-chaser, productized): swarm dispatch, formal regulatory approval, hardening for sustained outdoor operation. This is the only stage that is genuinely months of work, and almost none of it is code — it's airworthiness, certification, and operational pilots.

v1 is the only thing in this build guide. v1.5 is a small addendum. v2 is its own project, but not the year-long death-march it would be without an AI pair-programmer.

CAP — v3 perimeter ring defense

The big idea — sentries and seekers

Two specialised drone roles, not one:

• Sentries form a ring at ~1 km radius around the protected unit, hold station, watch outward, and never leave their post. They're the sensors. Reusable, expensive, persistent.
• Seekers sit on a launch pad at the base. When sentries detect and triangulate a threat, the operator authorises and one seeker launches, flies to the target's GPS coordinates, and executes the terminal action. Cheap, fast, often expendable.

Any inbound threat must cross the ring to reach you — so detection becomes a tripwire, not a search. Two adjacent sentries triangulate the target the instant it appears. The base station combines their bearings, verifies via VLM, and dispatches a seeker. Sentries stay put — ring integrity is preserved during engagement, so a second threat doesn't slip in while the first is being handled.

This is the loitering-munition pattern (Anduril Anvil-M, Switchblade 300, Lancet 1) split into a sensor+interceptor team. The novelty here is cost: per-sentry ~$1,300 and per-seeker ~$300–500 thanks to the same two trends that made v1 cheap — sub-$300 edge-AI compute and foundation-model classifiers that skip the training step.

Top-down geometry

9 drones at 1 km radius, each with a 90° camera FOV looking outward. Every wedge of horizon overlaps with two adjacent drones, giving instant two-bearing triangulation.

Single drone — 4 cameras = 360° vision

Per-drone hardware: Jetson Orin Nano + 4 cameras, one per face of the airframe. +$160 over a single-camera chaser. Onboard YOLO-World runs on all 4 streams in parallel.

Triangulation — two bearings, one position

Same physics as the v1 ground radar — two known positions, two bearings, intersection is the target. Airborne, instant, and with much better geometry because the drones are ~680 m apart.

Battery rotation — indefinite persistence

Base station — quiet most of the time

The base station is not the brain of the swarm. The sentries are. Each sentry runs its own onboard YOLO-World on its 4 cameras, and adjacent sentries swap bearings directly with each other over the mesh to triangulate. The base is silent during nominal operation — no video streams, no detector running, no triangulation. It only wakes up when neighbors have already agreed on a track and the operator needs to authorise a seeker.

Concretely, the base station does three things, all of them rare:

• Receive track packets from the mesh — JSON, ~1 kB, fired only when two adjacent sentries have triangulated a candidate. Maybe a few per hour in quiet airspace.
• VLM verify — one JPEG patch is pulled from the closest sentry on demand, shipped to Claude/Moondream, "is this a drone?" Sub-second.
• Operator authorise → dispatch seeker — tablet shows the track + image, operator taps AUTHORIZE, base fires WAYPOINT + ENGAGE to a seeker on the pad.

If the base is jammed, destroyed, or simply turned off, the ring keeps detecting and triangulating. Seekers can't be dispatched without it, but situational awareness survives — that's the whole point of pushing the smarts to the edge.

The base is a dispatcher and a human gate, not a sensor processor. Detection and triangulation happen at the ring.

Seeker — the cheap kamikaze (or net-capture) interceptor

Seekers don't need to detect, persist, or hold station. They only need to fly fast to a GPS coordinate, optically lock on the last 100 m, and execute. So they can be radically simpler and cheaper than sentries:

Operationally: target's GPS arrives from sentry triangulation, base sends WAYPOINT(x,y,z) + ENGAGE to a seeker, seeker takes off, climbs to target altitude, navigates GPS, and at ~100 m switches to optical lock. Last-100 m homing handles any drift in the GPS estimate. Time-to-engage from detection: ~30–60 s depending on target distance.

How sentries communicate — mesh, not cellular

Cellular is a non-starter for any contested or tactical scenario. LTE jammers are commercial products that cost ~$100, take down a base station, and the drones go silent. Even in non-tactical use, cellular concentrates a single point of failure (the cell tower). Real swarms don't use it. Here's how they actually communicate:

Mesh radio — the right default

Every sentry carries a mesh-radio transceiver and routing software (this is mature, well-known technology). Each talks directly to its 2–3 nearest neighbors, not to the base. Packets hop drone-to-drone until they reach a destination. Self-healing: if a node drops out (jammed, shot down, low battery), neighbors detect the loss and route around it. The base station is just another node — typically with a high-gain antenna — not a single point of failure.

For a 9-drone ring, any sentry reaches any other in at most 3 hops, ~5–15 ms latency per hop. Triangulation gets cleaner: adjacent sentries swap bearing measurements directly with their two neighbors and triangulate locally before forwarding the result to base via the mesh.

Add ~$500 per sentry to the DIY BOM for a Doodle Labs Mesh Rider. Mesh + 4-camera onboard AI fit together perfectly: each sentry only needs to send ~10 kbps of telemetry over the mesh (because the AI ran locally), not 5 Mbps of video. The 10 Mbps mesh becomes a swarm command-and-control bus with comfortable headroom.

Fiber tether — for static deployments

If the protected unit is going to stay put for hours-to-days (forward observation post, fixed installation, base perimeter), fiber-tethered sentries are an option:

• 9 fibers run from the base out to 9 station points at 1 km radius
• Each sentry hovers at its station with the tether providing both data and power
• Infinite flight time — no battery rotation, no charging logistics
• Totally unjammable, zero RF — invisible to RF SIGINT, immune to all electronic warfare
• Catches: tether limits altitude to ~150 m practical, positions fixed once deployed, ~9 km of fiber to lay (deployment is a logistical operation, not "3 minutes"), tangling risk in wind, terrain has to cooperate

Tethered systems exist commercially: Elistair Orion 2 (~$30K/system), Hoverfly LiveSky, Equinox Innovative Systems tether kits. DIY is feasible — a 1 km micro-fiber + power tether spool runs ~$500–1,500 — but you give up most of the rapid-deploy advantage.

Free-space optical (FSO) — laser between drones

Genuinely better than RF on every axis except weather and pointing complexity. A modulated laser between two drones gives Gbps bandwidth, near-zero latency, practically unjammable, and almost undetectable by adversary RF SIGINT — the beam is narrow and aimed up, not radiating to the ground. Used by DARPA SDA satellites and Mynaric/Tesat in the satellite world; making its way to airborne platforms.

The challenge you'd expect: how does each drone know where the other one is, accurately enough to keep a narrow beam locked on? Standard solution is Pointing, Acquisition, and Tracking (PAT):

• GPS gives rough position (±2 m). Both ends know roughly where the other is.
• Wide-beam optical beacon (~30° cone LED) for initial discovery. Other drones see it, refine the bearing.
• Narrow tracking beam locks on once coarse bearing is known. This is the high-rate data link.
• Fast steering mirror (FSM) on the gimbal corrects beam direction at hundreds of Hz to compensate for drone vibration and wind.

For a v3 build today, FSO is a great future-direction but the wrong primary link: the optical terminal would cost more than the drone, and a foggy day would ground your sentries. The right architecture for a v3.5+ production system: mesh radio as the always-available backbone, FSO as a high-bandwidth jam-immune upgrade layer between key nodes when conditions allow, fiber tether on the most critical sectors. This is exactly what mature military systems do — optical primary + RF backup + adaptive routing.

Hybrid: mesh-default with tether option

For now, the practical system is: mesh radio everywhere (handles mobility, weather, rapid deploy), with fiber tether on critical sectors if the protected unit will sit for hours-to-days. Add FSO as an upgrade layer once production volume justifies the cost.

Sentry options — DIY 4-camera vs DJI

Now that comms is settled, the sentry choice is between:

Recommendation: DIY 4-camera + Doodle Labs mesh for any tactical use — only path that's actually jam-resistant and NDAA-clean. DJI Mavic 3 Pro only for civilian POC where you're proving out the architecture and don't yet care about a contested RF environment.

Quick numbers

When CAP wins vs ground-radar approach

Full design details, terminal-action options, gotchas, and real-world precedents are in the Chaser tab → Option C. This tab is the visual summary.

Starlink — v4 satellite-illuminated passive radar

Playbook

The actual build, broken into atomic tasks (we call them beads). Each bead is small enough to fit in a single focused session — usually 15 min to 2 hr with an AI coding assistant — and has clear, verifiable success criteria. With Claude / Cascade / DeepSeek writing the code, a motivated builder can complete v1 in roughly two focused weekends after parts arrive: one to assemble + bring up the stack, one to tune in the field.

Bead schema

Phase totals

The beads

Working with Claude / Cascade on each bead

The intended workflow:

1. Open a fresh chat / terminal window for the bead.
2. Paste the bead text plus any context Claude needs (current branch, files, errors).
3. Let Claude propose a plan, push back on it, then ask it to write code or run commands.
4. Verify against the success criterion. If it doesn't match, debug together.
5. Commit, mark the bead done, move to the next.

For very small beads (B-060, B-070, B-080), this might be a single message. For larger beads (B-105, B-142, B-181), expect 1–3 days of conversation across many sessions. The ID lets you resume context cleanly: "Continuing on B-105."

What to do when stuck

• Verification fails. Don't move on. The dependencies in later beads assume earlier ones are correct. Debug or ask Claude to help debug.
• You can't make a measurement. Some success criteria need real RF — find a higher floor with sky view, find a stronger FM station, try at night when local interference is lower.
• A part is broken. Reorder. The system is reproducible by design — the BOM lists every part with a canonical source.
• You're going faster than expected. Don't skip — but feel free to batch small beads into one session.