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 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.

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 ~30 ns — better than required.

This replaces a much more expensive setup involving GPSDOs, 10 MHz reference distribution, and PPS cabling. We get the same time alignment by burning a few hundred lines of Python on cross-correlating the direct path between sites at startup, 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.

Operator Interface

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.

Chaser — v2 forward architecture

What a chaser is — dumb airframe, smart base station

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, 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 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.

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 MAVLink waypoints, which it sends to the chaser over Wi-Fi. 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.

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.

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.