Demo — RWR Scope

Demo — RWR Scope#

A radar warning receiver hears one merged stream of pulses from every emitter in view. Its first job is not hearing but sorting — deinterleaving that chaos into per-emitter buckets and classifying each against a threat library. This demo runs that pipeline on a dense scene built from the Block 1 cast.

The pipeline#

Each pulse becomes a descriptor word carrying a measured carrier frequency and time of arrival — this receiver runs with ±50 MHz of frequency error and 2% of TOA jitter, the same error model as the companion script. The processor clusters those descriptors on measured frequency, estimates each cluster’s PRI as the median gap between its times of arrival, and matches the resulting pair against the three-entry threat library. A cluster is named only if it lands within 10% of a library entry in both frequency and PRI; anything else reads UNKNOWN, and clusters too thin to support a PRI estimate at all are sent to a visible rejected lane rather than quietly dropped.

A real processor would also cluster on AoA and pulse width, and would read a mode change from a PRF jump over time. This demo runs the frequency-and-PRI slice of that pipeline on a static scene: no AoA, no pulse width, and each emitter holds one fixed PRI, so you read search and track as states rather than watch the transition.

Interactive demo#

Open in full screen

Walkthrough#

  1. Look at the interleaved stream. Three emitters — EW (0.5 GHz, PRI 5 ms), ACQ (3 GHz, PRI 2 ms), TTR (10 GHz, PRI 0.1 ms) — merge into one 16 ms timeline. Try to read a PRI off it by eye before touching anything.

  2. Hit Deinterleave. The stream clusters on measured frequency into per-emitter lanes, and each lane becomes a regular train — including the EW radar, whose four pulses across the window make it the sparsest thing in the scene.

  3. Read the threat table. Frequency and PRI are measured, so they land near the library values rather than on them: the EW lane reads about 0.51 GHz and 5.02 ms, not 0.5 and 5.0. Each row is named only if both numbers fall inside the 10% match window. The TTR’s 0.1 ms PRI marks it a tracker, not a searcher.

  4. Add clutter. Spurious pulses crowd the merged view until reading it by eye is hopeless. Deinterleave with the slider up and they no longer disappear: pulses that will not cluster into anything land in a visible rejected lane, with the count stated under the table. Doing that rejection reliably is exactly the RWR’s real problem, and here you can watch it happen.

  5. Push the clutter to the top. The first ID to fail is the EW radar — the sparsest emitter in the scene, so a single spurious pulse landing in its frequency bucket is enough to corrupt the median gap and drop it to UNKNOWN. The tracker, with a hundred and sixty pulses in the same window, never notices. Ask why that one goes first.

  6. Classify the mystery emitter. Turn it on and call it from its parametrics. It sits at 9.2 GHz with a 0.105 ms PRI — 8% off the library TTR in frequency and 5% off in PRI — so it resolves as a TTR in track, and the verdict shows you both margins.

Key observations#

  • Frequency narrows the band; PRI names the system. Neither alone is enough, which is why the match window is checked on both axes: a 9.2 GHz cluster with a fire-control PRI resolves as a TTR, while a spurious cluster with a random PRI resolves as nothing at all.

  • Deinterleaving precedes classification. You cannot identify what you have not first separated.

  • Every number in the table is a measurement. The receiver’s frequency error and TOA jitter ride all the way through the pipeline — which is why the estimated PRIs never land exactly on the library, and why a match needs a window rather than an equality.

  • Sorting fails before classifying does. Clutter takes down the sparsest emitter first: a PRI estimated from four pulses cannot survive an interloper the way one estimated from a hundred and sixty can.

Source#

MATLAB bundle · L12_RWRPulseSort.m↓

The companion script runs the same pipeline in MATLAB on a clean three-emitter scene — the same ±50 MHz and 2% error model, the same deinterleave-by-measured-frequency, the same median-of-TOA-differences PRI estimate, and the same 10% match rule against the same three-entry library.

Contents