Radar Sensor Hub

Mehr erfahren

Ziel des Gesamtprojektes

Das Gesamtprojekt hat das Ziel, eine topographische Vermessung mittels Radar und Drohnen zu ermöglichen. Ein Schwerpunkt ist die Nutzung von Synthetic Aperture Radar (SAR) Bildern, die eine präzise Analyse und Abbildung ermöglichen. Zusätzlich werden Sensor- und Radardaten synchronisiert, um eine nahtlose Integration zu gewährleisten. Durch Monitoring und Fehlerbehandlung von Sensoren wird die Zuverlässigkeit gesteigert, während Steuerungsmöglichkeiten für Radarfrontends eine flexible Anpassung an unterschiedliche Szenarien ermöglichen.

SAR Overview
Abb. 1: SAR Bild Beispiel

SAR-Bilder

In Abbildung 1 sieht man ein Beispiel eines SAR-Bildes. SAR-Bilder sind eine spezielle Form von Radaraufnahmen, die eine hohe räumliche Auflösung bieten. Sie werden durch die Bewegung des Radarsensors und die Verarbeitung der empfangenen Signale erzeugt. SAR-Bilder sind besonders nützlich für topographische Vermessungen, da sie eine detaillierte Darstellung der Oberfläche ermöglichen. Durch die Kombination von SAR-Bildern mit anderen Sensordaten können präzise 3D-Modelle erstellt werden, die für eine Vielzahl von Anwendungen nützlich sind.

Messungen mit Radarfrontend am JKU Parkplatz

Die Master-Projektgruppe hat bereits Messungen mit dem Radarfrontend am JKU Parkplatz erfolgreich durchgeführt. Aus diesen Messungen und unseren Sensordaten, kann dann ein SAR-Bild erstellt werden.

SAR Parking Lot
Abb. 2: SAR Bild Beispiel JKU

Systemüberblick

System Architektur
Abb. 3: System Architektur

aktuell unterstützte Sensoren:

  • GPS: u-blox ZED-F9P
  • IMU: VectorNav VN300
  • ADC: Cirrus Logic CS5381 (I2S)

FPGA

Altera

vs.

Efinix

Die Machbarkeitsstudie untersuchte den Einsatz von Efinix FPGAs, sowie des Synthesetools "Efinity". Als Alternative wurde ein Altera FPGA verwendet, genauer gesagt das DE1-SoC Development Board mit dem Synthesetool "Quartus". Dadurch können wir bereits mit Tests beginnen, bevor das FPGA-Board fertig ist.

Quartus überzeugte durch Stabilität und größerem Featureumfang, während die Efinity Toolchain noch Verbesserungspotenzial aufweist, insbesondere bei der Timing-Analyse. Dennoch konnten wir im letzten Jahr einen deutlichen Fortschritt bei Efinity beobachten, sowohl in der Stabilität als auch in der Benutzerfreundlichkeit. Quartus bleibt aktuell die ausgereiftere Lösung, doch Efinity zeigt großes Potenzial für zukünftige Projekte.

SensorHub FPGA - Funktionsweise:

FPGA Overview
Abb. 4: FPGA Design

Der Sensor Hub empfängt kontinuierlich Sensordaten in schnellstmöglichen Intervallen. Jeder eingehende Datensatz wird mit einem Zeitstempel versehen, der eine korrekte Zuordnung zu den entsprechenden Radar-Samples gewährleistet. Diese Vorgehensweise ermöglicht eine exakte Synchronisierung von Radar- und Sensordaten, was für die spätere Verarbeitung entscheidend ist. Nach der Zeitstempelung werden die Sensordaten im FPGA-Block-RAM zwischengespeichert, wo sie dann in gleichen Intervallen über eine schnelle SPI-Schnittstelle (25 MBit/s) an den RF-SoC weitergeleitet werden.

Protokoll

Protokoll
Abb. 5: Protokoll

Ein Frame ist immer gleich lange und besteht aus einer fortlaufenden Nummer, allen Sensor-Daten seit dem letzten Paket und abschließend einer 16-bit CRC Checksumme.

Die Sensordaten wiederum bestehen aus einer Sensor-Id, einem Timestamp zu dem das Sample aufgezeichnet wurde und die Daten selbst. Da die Länge des Frames immer gleich ist, kann es vorkommen, dass es samples gibt die nicht gültig sind (z.B. weil der Sensor defekt ist). In diesem Fall wird eine ungültige Sensor-Id versendet.

Länge der Daten:

Anzahl der Samples/Frame:

Gesamtlänge des Frames: 5208-bit

Bei 400 Frames/Sec ergibt das eine Datenrate von ca. 2Mbit/sec

Verifikation

Verification Schritte

Testprogramm

C# Testprogramm
Abb. 6: Testprogramm

Damit überprüft werden kann, ob die richtigen Daten im richtigen Protokoll gesendet werden wurde ein kleines C# Testprogramm erstellt. Dieses Programm empfängt die Daten über einen FTDI-USB-Adapter (SPI) oder einem TTL-Converter (UART). Die empfangenen Daten werden dann gemäß dem Protokoll ausgewärtet und in einer Liste angezeigt. Für die GPS-Daten wurde auch eine Karte hinzugefügt, die die aktuelle Position anzeigt.

Testaufbau

Die ersten Tests wurden mit dem DE1-SoC Board und einem GPS-Sensor durchgeführt. Die Empfangenen Daten werden über den FTDI-Adapter and den PC gesendet und dort mit dem Testprogramm ausgewertet.
Testaufbau
Abb. 7: Testaufbau

Spannungsversorgung / Stromregelung

Die Spannungsversorgungmodul dient dazu, das Radar-Frontend mit präzisen Strömen zu versorgen. Hierfür wird ein STM32 in Kombination mit dem AD7293 Current Controller von Analog Devices eingesetzt, der exakte Stromregelung ermöglicht. Zur Steuerung des AD7293 wurde eine SPI-Bibliothek für den STM32 entwickelt, die die erforderlichen Register des AD7293 in der richtigen Reihenfolge konfiguriert und Messdaten ausliest und verarbeitet. Zusätzlich steuert der STM32 einen I²C-Temperatursensor und einen IO-Expander, der eine präzise Referenzspannung für den Current Controller bereitstellt.

Spannungsversorgung
Spannungsversorgung
Abb. 8: Stromregelung

RISC-V Softcore

RISC-V bietet als offene und modulare Architektur maximale Flexibilität und Anpassungsfähigkeit, da es ohne Lizenzkosten genutzt werden kann und Entwicklern die Möglichkeit gibt, benutzerdefinierte Erweiterungen hinzuzufügen. Diese Eigenschaften machen RISC-V ideal für Embedded-Anwendungen, bei denen Effizienz und Anpassungsfähigkeit entscheidend sind. Das Sapphire SoC ergänzt diese Vorteile durch seine speziell für FPGAs optimierte Architektur, die eine energieeffiziente und platzsparende Implementierung ermöglicht. Die Flexibilität des Sapphire SoC erlaubt es uns benutzerdefinierte Peripheriegeräte nahtlos zu integrieren und benötigte Die Unterstützung der Efinity-Toolchain vereinfacht dabei die Entwicklung und unterstützt die Implementierung sowie die Verifikation des Systems.

RISC-V Logo
Sapphire SoC Logo
Softcore Resourcenverbrauch
Abb. 9: Resourcenverbrauch Lite-Version

Lite-Version des SoC ohne Extensions

  • Basic Implementierung des RISC-ISA
  • Interfaces: UART, SPI, I2C, GPIO, JTAG, APB
  • Kein Cache Controller
  • Keine Mul. and Div. unit
  • Kein Barrel Shifter
  • Dafür sehr Ressoucensparend!

Softcore Resourcenverbrauch Voll-Version
Abb. 10: Resourcenverbrauch Lite-Version

Voll-Version des SoC

  • Volle RISC-ISA Implementierung
  • Interfaces: UART, SPI, I2C, GPIO, JTAG, APB
  • Floating Point Unit
  • Cache Controller
  • Barrel Shifter
  • Mul. and Div Unit

  • Eclipsebasierte IDE
  • Allumfängliche Entwicklungsumgebung für C und C++
  • Board Support Packages helfen bei der Entwicklung
  • Debugger in der IDE eingebaut
Integration Softcore, RTL-Design, IDE
Abb. 11: Softcore Design Flow

Hardware

Die Hardware umfasst HF-Komponenten wie Sender und Empfänger sowie eine Platine für die Spannungsversorgung und natürlich den Sensor-Hub.

TX Messungen
Abb. 12: Versuchsaufbau

Versuchsaufbau Sender

Hier ist eine erste Testmessung mit dem Sender (manuell eingestellte Spannungsversorgung) zu sehen. Erwartet wurde ein einfacher Peak im Spektrum (LO Leakage). Leider gab es jedoch noch ein Problem und es sind mehrere Peaks im Spektrum sichtbar. Dies ist auf eine Instabilität vom Chip zurückzufürhen, die über eine Powerstage einkoppelt. Dies wurde mit einer besseren Filterung beseitigt.

Blockschaltbild Sender

Dies ist der Verwendete HF-Chip. Es handelt sich hierbei um einen Up-Converter der Firma Macom der im 71-86 GHz Bereich arbeitet. Die eingespeiste LO wird mit dem Faktor 8 vervielfacht. Auf dieses Signal werden die Signale der I/Q IF Eingänge moduliert.

Blockschaltbild Sender
Abb. 13: Blockschaltbild Sender

Team

Richard Hüttner
Hardware Design
Ralf Hintersteininger

FPGA Design

Testprogramm

David Gscheider
FPGA Design
Boris Dobrijevic
Softcore CPU Einbindung
Paul Engelhardt
Spannungsversorgung / Stromregelung