PASSIV RADAR RFSoC 4x2 · WiFi 5 GHz · FPGA-Signalverarbeitung
Passive Bistatic Radar · Echtzeit-DSP

Ein Radar, das selbst nicht sendet.

Wir nutzen vorhandene Funksignale als Beleuchter und detektieren Ziele allein aus reflektierten Echos – per Kreuzkorrelation und FFT, in Echtzeit umgesetzt auf einem Xilinx RFSoC 4x2.

Tour starten Direkt zu den Ergebnissen
Ralf Hintersteininger Erin Sonnleitner David Hintringer Richard Hüttner
5 GHz
WiFi-Trägerfrequenz (Kanal 50)
160 MHz
Signalbandbreite
~1,8 m
Erwartete Entfernungsauflösung
12,8 GBit/s
Datenrate in den DDR4-Speicher
01Was ist Passivradar?

Ein Radar, das selbst nicht sendet

Ein klassisches Radar sendet ein eigenes Signal aus und wertet das Echo aus. Ein Passivradar verzichtet auf den eigenen Sender und nutzt stattdessen bereits vorhandene Funksignale aus der Umgebung.

Kein eigener Sender

Das System ist rein passiv. Es strahlt nichts ab, ist damit schwer zu detektieren und benötigt keine Sendelizenz für den genutzten Frequenzbereich.

Nutzt bestehende Signale

Statt selbst zu senden, empfängt das System Signale von z.B. TV-Sendern, Radio oder anderen Funksystemen, die ohnehin in der Umgebung verfügbar sind.

Detektiert bewegte Objekte

Durch den Vergleich von direktem Signal und reflektiertem Signal lassen sich bewegte Objekte im Raum erkennen und lokalisieren.

Kernidee

Zwei Empfangskanäle genügen: einer empfängt das direkte Signal von der Quelle (Referenz), der andere beobachtet die Umgebung (Surveillance). Der Vergleich beider Signale verrät, wo sich etwas bewegt.

02Funktionsprinzip

Referenz, Surveillance und Kreuzkorrelation

Passivradare ermitteln Ziele über die Kreuzkorrelation zweier empfangener Signale. Das Referenzsignal stammt direkt von der Signalquelle, das Überwachungssignal enthält die von Objekten reflektierten Anteile.

Referenzsignal  xᵣ*

Das direkt von der Signalquelle (z.B. einem Sender) empfangene Signal über den direkten Pfad. Es dient als „Vorlage“ für den Vergleich.

Überwachungssignal  xₑ

Das von Objekten reflektierte Signal. Es ist gegenüber der Referenz zeitverschoben (Laufzeit → Entfernung) und frequenzverschoben (Doppler → Geschwindigkeit).

Die Kreuzkorrelationsfunktion vergleicht beide Signale für jede Kombination aus Zeitverschiebung τ und Dopplerfrequenz fₒ:

ψ(τ, fₒ) = ∫ xₑ(t) · xᵣ*(t−τ) · e-j2πfDt dt
Ein Maximum bei (τ, fₒ) markiert ein Ziel in genau dieser Entfernung und mit dieser Radialgeschwindigkeit.
Abb. 01 — Direkter Pfad (Referenz) vs. reflektierter Pfad (Surveillance)
03Theoretische Grundlagen

Was die Auflösung bestimmt

Drei grundlegende Zusammenhänge bestimmen, wie gut das System Ziele trennen kann – in Entfernung und in Geschwindigkeit.

Time-Delay / Bistatic Range — R = c·τ/2

Die Entfernung zum Ziel ergibt sich aus dem Zeitversatz τ zwischen Referenz- und Überwachungssignal über die Lichtgeschwindigkeit c.

Range Resolution — ΔR = c/(2B)

Die Entfernungsauflösung hängt direkt von der Bandbreite B ab: je breiter das Signal, desto feiner können nahe beieinander liegende Ziele getrennt werden.

Velocity Resolution — ΔV = λ/(2T)

Die Geschwindigkeitsauflösung steigt mit der Integrationszeit T. Längeres Beobachten trennt Ziele feiner in der Doppler-Frequenz.

04Warum WiFi?

Die Wahl der Signalquelle

Für unser Passivradar haben wir uns für WiFi bei 5 GHz entschieden – und das aus guten Gründen.

5 GHz
Trägerfrequenz
Ch 50
WiFi-Kanal
160 MHz
Bandbreite
~1,8 m
Range-Auflösung

Allgegenwärtig

WiFi-Router sind überall verfügbar. Sie liefern ein starkes, stabiles Signal, das ideal für Passivradar-Anwendungen geeignet ist.

Hohe Bandbreite

Mit 160 MHz Bandbreite bei 5 GHz ermöglicht WiFi eine sehr gute Entfernungsauflösung von etwa 1,8 m – ideal, um bewegte Objekte klar zu trennen.

Zwei Kanäle reichen

Mit nur zwei Empfangskanälen (Referenz + Surveillance) lässt sich das System realisieren – ein großer Vorteil gegenüber aktiven Radarsystemen.

Konsequenz

Die hohe Trägerfrequenz und die große Bandbreite bringen jedoch auch technische Herausforderungen mit sich: der Frequenzbereich liegt oberhalb dessen, was der ADC direkt abtasten kann, und die Datenrate ist enorm.

05Technische Herausforderungen

Datenrate & Frequenzbereich

Bevor überhaupt korreliert werden kann, muss das Signal erst einmal sauber digitalisiert und in den Speicher gebracht werden.

Datenrate: 12,8 GBit/s in den DDR4

Bei 160 MHz Bandbreite und komplexer (I/Q-)Abtastung mit 16 Bit pro Wert ergibt sich pro Kanal eine erhebliche Datenrate. Für Referenz- und Überwachungskanal zusammen muss der DDR4-Speicher mit 12,8 GBit/s gefüllt werden.

  • → Abtastrate fₛ ≈ 200 MHz
  • → pro Kanal 3,2 GBit/s, mit I/Q 6,4 GBit/s
  • → beide Kanäle: 12,8 GBit/s
Abb. 05 — Herleitung der Sample-Transfer-Rate
Frequenzbereich

Der Nutzbereich liegt bei 5170–5330 MHz. Der RF-ADC tastet mit maximal 5 GSPS ab – für eine direkte Abtastung bräuchte man nach Nyquist jedoch mindestens 10,66 GHz. Die Lösung dafür heißt Subsampling.

06Subsampling

Wenn der ADC zu langsam ist – und es trotzdem geht

Subsampling (Bandpass-Abtastung) nutzt den Aliasing-Effekt gezielt aus: Ein hochfrequentes, aber schmalbandiges Signal wird durch Unterabtastung eindeutig ins Basisband gefaltet.

Das Problem

Das Nutzsignal sitzt um 5,25 GHz. Eine direkte Abtastung nach Nyquist–Shannon würde > 10 GSPS verlangen – mehr als der ADC liefert.

Die Lösung

Da die Bandbreite (160 MHz) sehr viel kleiner ist als die Mittenfrequenz, genügt eine Abtastrate, die das schmale Band eindeutig in eine niedrigere Nyquist-Zone abbildet. Das Signal „faltet“ kontrolliert ins Basisband – ohne Informationsverlust.

Bedingung

Bandpass-Abtastung funktioniert, solange das gesamte Nutzband innerhalb einer Nyquist-Zone liegt und sich die Aliase nicht überlappen.

Abb. 06a — Faltung des HF-Bands ins Basisband

Vom RF-Signal zum Basisband

Die folgenden Messplots zeigen die Kette: das ursprüngliche RF-Signal, das unterabgetastete Signal und schließlich das saubere, gefilterte Basisbandsignal in Zeit- und Frequenzbereich.

Original-RF & Subsampling
Basisband (I/Q)
Gefiltertes Basisband
07Batch-Algorithmus

Korrelation in Blöcken statt am Stück

Statt das gesamte Integrationsfenster auf einmal zu verarbeiten, wird es in kurze Blöcke zerlegt. Das hält den Rechenaufwand beherrschbar und liefert zugleich die Doppler-Achse.

Abb. 07a — Blockaufteilung des Integrationsfensters
Abb. 07b — Korrelation pro Block → FFT über Blöcke

1 · Aufteilen

Das 64-ms-Fenster beider Signale wird in 64 Blöcke zu je 1 ms zerlegt.

2 · Korrelieren

Jedes Blockpaar (Referenz/Surveillance) wird einzeln kreuzkorreliert – das ergibt die Entfernungsachse.

3 · FFT über Blöcke

Eine FFT über die Blöcke hinweg liefert die Doppler-Achse. In Summe entstehen rund 2000 FFTs pro Range-Doppler-Map.

08Hardwareplattform

Xilinx RFSoC 4x2

Die Plattform vereint schnelle RF-Wandler, große FPGA-Logik und einen Prozessor auf einem Chip – genau die Kombination, die dieses Projekt verlangt.

RFSoC 4x2 — Entwicklungsboard
Logikzellen930 k
On-Chip-RAM60 MB
DSP-Slices4272
RF-ADC4 × 5 GSPS
RF-DAC2 × 9,85 GSPS
DDR4 (PS)4 GB
DDR4 (PL)4 GB
Ethernet100 GBit
Warum diese Plattform

Die schnellen RF-ADCs erlauben die Bandpass-Abtastung direkt, die große PL-Logik und die vielen DSP-Slices tragen Korrelator und FFT, und der integrierte Prozessor (PS) übernimmt mit PYNQ Steuerung, Auswertung und Visualisierung – alles auf einem einzigen Baustein.

09System- & FPGA-Architektur

Programmable Logic, Processing System & PYNQ

Der RFSoC teilt sich in zwei Welten: die frei konfigurierbare Logik (PL) für die schnelle Signalverarbeitung und das Prozessorsystem (PS) für Steuerung und Auswertung.

Programmable Logic (PL)

Hier läuft die eigentliche Signalverarbeitungskette in Hardware: ADC-Anbindung, Korrelator, FFT, Speicher- und Datenflusssteuerung – getaktet und parallel.

Processing System (PS)

Die Application-Processing-Unit trägt PYNQ-Linux. Die Realtime-Processing-Unit bleibt in diesem Projekt ungenutzt.

PYNQ-Linux

  • → Offizielle Unterstützung für das RFSoC 4x2
  • → Jupyter-Runtime, erreichbar über HTTP
  • → Laden von Overlays (dem FPGA-Design)
  • → Overlay = Python-Objekt mit Hardware-Abstraktion
  • → Memory-Map & Hierarchie, von Vivado generiert
Overlay

Ein Overlay macht das in Vivado gebaute FPGA-Design als Python-Objekt zugänglich – Register und Speicher werden direkt aus dem Notebook angesprochen.

Abb. 09 — PYNQ-Stack: Overlay, Memory-Map, Jupyter
10Signal-Processing-Pipeline

Der erste Entwurf des Datenflusses

Die ursprüngliche Pipeline ist bewusst einfach gehalten: ein gerader Weg vom ADC bis zur Range-Doppler-Map.

Abb. 10 — Pipeline v1: ADC → Korrelation → FFT → PS-RAM / PYNQ
  1. ADC-Referenz & ADC-ÜberwachungBeide Kanäle werden digitalisiert und in die PL geführt.
  2. KorrelationKreuzkorrelation der beiden Signale erzeugt die Entfernungsinformation.
  3. FFT über KorrelationsergebnisseDie FFT überführt die Ergebnisse in den Doppler-Bereich.
  4. PS-RAM / PYNQDas Ergebnis landet im Speicher und wird über PYNQ ausgewertet und dargestellt.
11Bottlenecks & Herausforderungen

Wo es im Datenfluss klemmt

Der einfache Entwurf trifft auf reale Engpässe – vor allem beim Timing, beim Speicherzugriff und bei der Pufferung zwischen den Stufen.

ADC-FIFOs dürfen nicht überlaufen

Läuft ein FIFO über, gehen Samples verloren – die Verarbeitung muss mit dem Datenstrom zuverlässig Schritt halten.

Taktfrequenz von Korrelator & FFT

Korrelator und FFT erreichen unter Umständen nicht die nötige Frequenz, um den Datenstrom in Echtzeit zu bewältigen.

Zwischenspeicherung nötig

Die Korrelationsergebnisse müssen für die FFT zwischengespeichert werden – ein direkter Durchlauf reicht nicht.

Kein sequenzieller FFT-Zugriff

Die FFT greift nicht sequenziell auf die Daten zu – ein memory-mapped Interface wird erforderlich.

Übergreifend

Hinzu kommen Komplexität des Gesamtsystems, große Datenmengen, kniffliges Timing, lange Synthese- und Simulationszeiten in Vivado, kryptische Fehlermeldungen, begrenzte Debug-Möglichkeiten und Xilinx-Blöcke, die sich nicht immer wie erwartet verhalten – und der Effekt, dass ein kleines Design funktioniert, das große aber nicht.

12Weiterentwicklung

Signal-Processing-Pipeline v2

Die Antwort auf die Engpässe: ein gemeinsamer DDR-RAM als zentraler Puffer, mehrere Sync-&-DMA-Einheiten für geordnete Speicherzugriffe – und eine zentrale Steuerung.

Abb. 12 — Zentraler DDR-RAM, Sync & DMA und der „Vorarbiter“ als Dirigent

Gemeinsamer DDR-RAM

Statt Daten starr durchzureichen, dient der DDR-RAM als zentraler Puffer zwischen allen Stufen – das entkoppelt ihre Zeitanforderungen.

Sync & DMA

Mehrere Sync-&-DMA-Einheiten regeln den geordneten Transfer zwischen Verarbeitung und Speicher – auch für nicht-sequenzielle Zugriffe.

Entkoppelte FFT

Die FFT liest ihre Eingangsdaten über das memory-mapped Interface aus dem RAM und schreibt das Ergebnis für PYNQ ins PS-RAM.

13Vorarbiter-Konzept

Ein Dirigent für den Datenfluss

Der „Vorarbiter“ ist die zentrale Steuerinstanz: Er taktet die einzelnen Schritte, verwaltet den Speicher und macht das System überhaupt erst debugbar.

Ablaufsteuerung

Er gibt die Reihenfolge der Verarbeitungsschritte vor und sorgt dafür, dass jede Stufe zur richtigen Zeit auf den richtigen Daten arbeitet.

Memory-Management

Er verwaltet die Speicherbereiche im DDR-RAM und koordiniert die Sync-&-DMA-Transfers.

Überwachung & Error-Reporting

Er beobachtet die Verarbeitung fürs Debugging und meldet, wo und welcher Fehler aufgetreten ist.

Anbindung

Steuerung über AXI-Lite – ansprechbar per PYNQ-Overlay (in Arbeit) oder direkt über die Buttons am Board.

14Blockdiagramme

Vom abstrahierten Schema zum realen Vivado-Design

Zwei Blickwinkel auf dieselbe Architektur: eine aufgeräumte, abstrahierte Darstellung – und das tatsächliche, implementierte Blockdesign aus Vivado.

Abb. 14a — Blockschaltbild (abstrahiert), skalierbar als SVG
Abb. 14b — Implementiertes Vivado-Blockdesign (zum Vergrößern anklicken)
15Erreichte Ziele

Was funktioniert

Über den Projektverlauf wurden die zentralen Bausteine der Kette erfolgreich umgesetzt und verifiziert.

  • ✓ ADC-Daten

    Erfassung der RF-Daten über die ADC-Kanäle.

  • ✓ Taktnetzwerk

    Aufgebaut (ohne Synchronisierung der Kanäle).

  • ✓ Korrelation

    Kreuzkorrelation in der PL umgesetzt.

  • ✓ Datenmanagement

    Geordneter Datenfluss durch die Pipeline.

  • ✓ Speicherung im PL-RAM

    Ablage der Daten im PL-seitigen DDR4.

  • ✓ Speicherung im PS-RAM

    Übergabe der Ergebnisse an das PS für PYNQ.

  • ✓ Debug über AXI-Bus

    Einblick in interne Zustände zur Fehlersuche.

  • ✓ Korrekte Range-Doppler-Map

    Mit generierten Daten verifiziert.

16Ergebnisse

Range-Doppler-Maps

Eine Range-Doppler-Map trägt Entfernung (Range-Bin) gegen Geschwindigkeit (Doppler-Bin) auf; helle Bereiche markieren detektierte Ziele. Drei Stufen zeigen den Weg von der Simulation bis zum realen WLAN-Signal.

Simulierte Daten — Block-RAM

Verifikation der Kette mit kontrollierten Eingangsdaten: die Ziele erscheinen genau dort, wo sie erwartet werden.

Rechteck — Funktionsgenerator

Reales Eingangssignal aus einem Funktionsgenerator – die periodische Struktur prägt das charakteristische Muster.

WLAN — über langes Kabel

Der Schritt zum echten WLAN-Signal: über ein langes Kabel eingespeist, als Vorstufe zum reinen Funkbetrieb.

∑Fazit & Ausblick

Ein passives Radar aus WiFi – machbar gemacht

Das Projekt zeigt, dass sich aus alltäglichen WiFi-Signalen ein funktionsfähiges Passivradar aufbauen lässt – getragen von der Idee des Subsamplings, einer in Blöcke zerlegten Kreuzkorrelation und einer FPGA-Signalverarbeitungskette auf dem RFSoC 4x2.

Die zentrale Kette aus ADC-Erfassung, Korrelation, FFT und Speicherung wurde realisiert und mit simulierten sowie realen Signalen bis hin zu korrekten Range-Doppler-Maps verifiziert. Der überarbeitete Datenfluss mit gemeinsamem DDR-RAM und dem steuernden „Vorarbiter“ löst die Engpässe des ersten Entwurfs.

Ausblick

Naheliegende nächste Schritte sind die Kanal-Synchronisierung, die Vervollständigung der PYNQ-Overlay-Ansteuerung des Vorarbiters sowie der Übergang vom kabelgebundenen WLAN-Signal zum reinen Funkbetrieb über Antennen.

Zurück zum Anfang Ergebnisse noch einmal ansehen