Gestensteuerung per Radar: STM32 und 60GHz Sensoren

Gestensteuerung per Radar wird im Embedded-Bereich zunehmend interessant, weil sie ohne Kamera auskommt, auch bei Dunkelheit funktioniert und in vielen Umgebungen robuster ist als optische Sensorik. Mit einem STM32 als Host-Controller und einem 60GHz-Radarsensor lassen sich Handbewegungen, Näherung, Mikrobewegungen oder einfache „Air-Buttons“ zuverlässig erkennen – etwa für berührungslose Bedienfelder in Industrieanlagen, Haushaltsgeräten, Medizintechnik oder im Fahrzeug. Der Reiz der 60GHz-Technologie liegt in der kurzen Wellenlänge: Sie ermöglicht sehr feine Messungen bei kompakten Antennen und reagiert sensibel auf kleine Bewegungen. Gleichzeitig bleibt die Auswertung beherrschbar, wenn man die Signalkette sauber plant: vom Sensor-Frontend über DMA-gestützte Datenerfassung bis hin zu DSP-Algorithmen (FFT, Filter, Feature-Extraktion) und einer schlanken Klassifikation auf dem Mikrocontroller. Dieser Artikel zeigt praxisnah, wie Sie Gestenradar mit STM32 aufbauen, welche Sensorfamilien sich eignen, welche Parameter wirklich zählen und wie Sie typische Stolpersteine bei Layout, Datenrate und Signalverarbeitung vermeiden.

Warum 60GHz-Radar für Gestensteuerung?

Bei der Gestenerkennung zählt weniger „Reichweite um jeden Preis“, sondern Reaktionsschnelligkeit, Wiederholbarkeit und Robustheit. 60GHz-Radar bietet dafür mehrere Vorteile:

• Lichtunabhängig: Funktioniert bei Dunkelheit, Blendung, Rauch oder wechselnden Lichtverhältnissen.
• Privatsphäre: Keine Bilddaten, daher oft leichter mit Datenschutzanforderungen vereinbar.
• Empfindlich für Bewegung: Besonders gut für Handbewegungen, Annäherung, Wischgesten und Mikrobewegungen (z. B. Fingerbewegungen).
• Kompakte Hardware: 60GHz-Sensoren sind häufig als Antenna-in-Package/AiP verfügbar, wodurch RF-Layout deutlich einfacher wird.
• Industrie- und Automotive-tauglich: Viele Bausteine stammen aus Umfeld von Automotive und industrieller Sensorik.

Wichtig ist die Auswahl des Radarsignals (FMCW, Doppler, Pulsradar) und der passende Algorithmus. Für reine Präsenz- oder Bewegungsdetektion reicht häufig Doppler. Für robustere Gesten und Abstandsinformation ist FMCW oder ein pulskohärentes Radar (PCR) im Vorteil.

Radar-Grundlagen: Doppler, FMCW und Puls-Kohärenz

Damit Sie Sensor-Daten und Datenraten realistisch planen können, lohnt ein kurzer Blick auf die wichtigsten Betriebsarten.

Doppler-Radar (Bewegung ja/nein und Geschwindigkeit)

Doppler-Radar misst Frequenzverschiebungen, die durch Bewegung entstehen. Es ist sehr effizient, weil die Auswertung vergleichsweise simpel ist. Für „Hand nähert sich“ oder „Wischbewegung“ ist Doppler oft ausreichend, liefert aber nur begrenzt Distanzinformation.

FMCW-Radar (Abstand + Bewegung)

FMCW (Frequency Modulated Continuous Wave) nutzt Frequenzrampen („Chirps“). Aus der Mischfrequenz lässt sich die Entfernung bestimmen; über mehrere Chirps hinweg auch Bewegung (Doppler). Eine zentrale Kennzahl ist die Abstandsauflösung, die im Idealfall von der Bandbreite B abhängt:

$\mathrm{\Delta R}=\frac{c}{2B}$

Dabei ist c die Lichtgeschwindigkeit. Größere Bandbreite bedeutet feinere Distanzauflösung – relevant, wenn Sie Gesten nicht nur als „Bewegung“, sondern als räumliche Interaktion (z. B. definierte Zonen) interpretieren wollen.

Puls-kohärentes Radar (PCR)

Puls-kohärente Verfahren senden sehr kurze Pulse und werten die Laufzeit über kohärente Verarbeitung aus. Moderne 60GHz-Sensoren können damit sehr präzise Nahfeldmessungen realisieren. Für Gesten, die sich im Bereich weniger Zentimeter abspielen, ist PCR häufig attraktiv, weil es fein auflösen kann und die Signalkette oft auf „Embedded-Realität“ optimiert ist.

Sensor-Auswahl: Welche 60GHz-Familien passen zu STM32?

Für ein STM32-basiertes Gestenradar sind vor allem drei Kategorien verbreitet: kompakte Radar-Frontends (Host rechnet), Radar-Sensoren mit integrierter State-Machine, sowie leistungsstarke mmWave-SoCs (Sensor rechnet selbst). Beispiele:

• Radar-Frontend mit Host-Auswertung: Sehr gut kombinierbar mit STM32, wenn DMA/DSP genutzt werden kann. Ein typischer Vertreter ist die XENSIV-Serie, z. B. Infineon BGT60TR13C Datenblatt.
• 60GHz-PCR-Sensoren für Nahbereich: Kompakt und oft mit guter Toolchain. Beispiel: Acconeer A121 Dokumentation und Software.
• mmWave-SoC mit DSP/MCU im Sensor: Sehr leistungsfähig, aber meist komplexer. Beispiel: TI IWR6843 Produktseite und Dokumentation.

Wenn der STM32 die Hauptauswertung übernehmen soll, sind AiP-Frontends oder PCR-Sensoren oft der pragmatische Einstieg. mmWave-SoCs lohnen sich, wenn Sie mehrere Antennenkanäle, Beamforming oder komplexe Szenenklassifikation benötigen und die Rechenlast nicht komplett auf dem STM32 liegen soll.

Systemarchitektur: So sieht eine robuste STM32-Radar-Pipeline aus

Ein praktikabler Aufbau lässt sich in fünf Blöcke aufteilen:

• Sensor-Frontend: 60GHz-Radar (AiP), Takt, Versorgung, ggf. LDO/PMIC.
• Digital-Interface: Häufig SPI (Konfiguration + Daten), seltener LVDS oder Parallel-Interfaces bei High-End-Sensoren.
• Datenerfassung: STM32 mit DMA (SPI DMA, ggf. DCMI/Parallel bei Spezialfällen), Ringpuffer, Time-Stamping.
• Signalverarbeitung: Windowing, FFT, Filter, Feature-Extraktion; optional CMSIS-DSP und ggf. FPU/Helium (je nach STM32-Familie).
• Klassifikation + Applikation: Zustandsautomat, Schwellenwerte, Hysterese, oder kleines ML-Modell (z. B. TensorFlow Lite Micro) – plus Schnittstellen (BLE/WLAN/GUI).

Für die Entwicklung ist eine saubere Projektstruktur in STM32CubeIDE hilfreich, inklusive Debug-Views, Peripheriekonfiguration und Build-Profile. Als Einstieg bietet sich die offizielle Seite STM32CubeIDE an.

Hardware-Design: Stromversorgung, Takt, Layout und Antennenpraxis

60GHz klingt nach „RF-Magie“, ist aber mit modernen AiP-Sensoren deutlich zugänglicher, als viele erwarten. Trotzdem entscheidet das Board-Design über Stabilität und Wiederholbarkeit.

Versorgung und Entkopplung

Radar-ICs reagieren empfindlich auf Versorgungseinbrüche und Ripple. Planen Sie:

• Saubere LDOs oder DC/DC mit nachgeschaltetem LDO für analogkritische Bereiche.
• Mehrstufige Entkopplung (z. B. 100 nF nahe am Pin + 1 µF/4,7 µF in der Nähe).
• Getrennte Rückstrompfade und eine solide Massefläche.

Uhren und Referenz

Viele Radarsensoren benötigen einen stabilen Referenztakt. Achten Sie auf Layoutregeln für Quarze/Oszillatoren, kurze Leitungen und saubere Masseführung. Wenn ein Sensor einen Takt ausgibt, können Sie den STM32 in bestimmten Architekturen synchronisieren – das reduziert Drift, ist aber nicht zwingend erforderlich.

Mechanik und „freie Sicht“

Gestenradar funktioniert nur so gut, wie der Sensor „sehen“ kann. Vermeiden Sie metallische Abdeckungen direkt vor dem AiP. Kunststoffabdeckungen sind üblich; testen Sie aber Material, Dicke und Abstand, weil Dämpfung und Reflexionen stark variieren können.

Datenerfassung am STM32: DMA, Puffer und Timing sauber planen

Die häufigste Fehlerquelle bei Radarprojekten ist nicht der Algorithmus, sondern der Datenfluss: Samples kommen nicht konstant, Puffer laufen über, oder Latenzen schwanken. Bewährte Ansätze:

• SPI mit DMA: Nutzen Sie Double-Buffering (Ping-Pong), um Rechenzeit und Transferzeit zu entkoppeln.
• Ringpuffer im RAM: Speichern Sie Frames/Chirps in einem Ring, damit kurzfristige Lastspitzen keine Daten verlieren.
• Prioritäten im NVIC: Transfer-Complete-Interrupts (DMA) sollten höher priorisiert sein als UI/Logging.
• Zeitstempel: Legen Sie pro Frame einen Timestamp ab (Timer-Capture), um Jitter sichtbar zu machen.

Als Faustregel gilt: Erst wenn Sie eine stabile, reproduzierbare Datenpipeline haben, lohnt sich die Optimierung der Signalverarbeitung. Andernfalls „tunen“ Sie an Symptomen statt an Ursachen.

Signalverarbeitung für Gesten: Vom Rohsignal zum Feature

Je nach Sensor liefern Sie I/Q-Daten, Magnituden oder bereits vorverarbeitete „Bins“. In der Praxis führen viele Systeme über ein ähnliches Grundrezept zum Ziel:

• Vorverarbeitung: DC-Offset entfernen, ggf. I/Q-Balance, Normalisierung.
• Fensterfunktion: z. B. Hann/Hamming, um Leakage in der FFT zu reduzieren.
• FFT und Spektren: Doppler-FFT (Bewegung), Range-FFT (Abstand) oder Kombination (Range-Doppler).
• Filter: Glättung über mehrere Frames, Medianfilter gegen Ausreißer.
• Feature-Extraktion: Peak-Position, Peak-Breite, Energie in Bändern, zeitliche Gradienten, Zero-Crossings.

Praxisnahe Features für Gesten

Für Einsteiger ist es oft sinnvoll, mit handgebauten Features zu starten, bevor ein ML-Modell trainiert wird. Typische Features:

• Annäherung/Entfernung: Trend der Peak-Range oder Gesamtsignalenergie.
• Wisch links/rechts: Asymmetrische Energieverteilung über Antennenkanäle (falls mehrere RX vorhanden) oder zeitlicher Shift im Peak.
• „Air-Button“: Schneller Energieimpuls in einer definierten Distanzzone, mit Hysterese gegen Prellen.

Klassifikation: Zustandsautomat oder Embedded-ML?

Für viele Produkte reicht ein gut gemachter Zustandsautomat. Er ist leichter zu testen, erklärbar und stabil. ML lohnt sich, wenn Gesten stark variieren (unterschiedliche Hände, Geschwindigkeiten, Montagehöhen) oder wenn Sie mehrere Gesten sicher unterscheiden müssen.

Zustandsautomat (empfohlen für den Einstieg)

• Vorteile: Transparent, deterministisch, wenig Ressourcen, leicht zertifizierbar.
• Schlüsseltechniken: Hysterese, Mindestdauer, Cooldown-Zeit, adaptive Schwellen basierend auf Grundrauschen.

Embedded-ML (wenn die Varianz hoch ist)

• Vorteile: Bessere Generalisierung, weniger Hand-Tuning, kann komplexere Muster erkennen.
• Risiken: Datensatzqualität, Overfitting, Interpretierbarkeit, aufwändigeres Testen.

Ein pragmatischer Mittelweg ist „Feature-basiertes ML“: Sie berechnen robuste Features (z. B. Energievektoren über Zeitfenster) und nutzen ein kleines Modell (z. B. lineare Klassifikation oder kleines MLP). Das ist meist deutlich leichter als ein End-to-End-Modell auf Rohdaten.

Typische Stolpersteine und wie Sie sie vermeiden

• Mehrwegreflexionen: Metallflächen und enge Gehäuse erzeugen „Geisterpeaks“. Abhilfe: Montageposition optimieren, Zonen definieren, Hintergrundmodell (Clutter Removal).
• Zu hohe Datenrate: FMCW-Setups können schnell RAM und CPU sprengen. Abhilfe: geringere FFT-Größe, weniger Chirps, Downsampling, Auswertung nur in relevanten Zonen.
• Schwellenwertdrift: Temperatur, Alterung oder Montageabweichungen verändern das Rauschniveau. Abhilfe: adaptive Noise-Floor-Schätzung, automatische Kalibrierphase beim Start.
• Latenz und „gefühlte Qualität“: Eine perfekte Erkennung nützt wenig, wenn die Reaktion zu spät kommt. Abhilfe: Pipeline optimieren, early-exit (Erkennung vor vollständigem Frame), Prioritäten sauber setzen.

Regulatorik und Markteinführung: 60GHz in Europa verantwortungsvoll einsetzen

Auch wenn 60GHz-Systeme häufig in lizenzfreien Bereichen eingesetzt werden, gelten in Europa Anforderungen aus der Funkregulierung und der CE-Konformität. Für einen praxisnahen Einstieg in Normenlandschaften und Funkanforderungen bietet sich ein Blick auf ETSI-Ressourcen an, zum Beispiel die Übersicht ETSI Short Range Devices oder harmonisierte Standards im SRD-Umfeld wie ETSI EN 305 550 (40–246 GHz). Für die Produktpraxis gilt: Planen Sie frühzeitig EMV, Antennen-/Gehäuseeffekte und die Dokumentation für die technische Datei ein – dann wird die spätere Konformitätsbewertung deutlich entspannter.

Empfohlener Startpfad: Vom Demo-Setup zur eigenen Gestenfunktion

• Sensor evaluieren: Starten Sie mit einem Modul oder Evaluation-Board, das zur gewünschten Reichweite passt (Nahbereich vs. „Room-Scale“).
• Datenpipeline stabilisieren: SPI+DMA, Ping-Pong-Puffer, Logging von Framezeiten und Dropped Frames.
• Einfaches Ziel definieren: Zuerst Präsenz oder „Wisch“ statt fünf Gesten auf einmal.
• Feature-Set bauen: 3–6 robuste Features, die die Geste eindeutig machen.
• Validieren im echten Gehäuse: Nicht nur am offenen Tisch testen – Material und Mechanik ändern das Radarbild.

Weiterführende Ressourcen und Datenblätter

• Infineon XENSIV BGT60TR13C Datenblatt (60GHz AiP, FMCW)
• Acconeer A121 Dokumentation & Software (60GHz PCR)
• Texas Instruments IWR6843 (60–64GHz mmWave Sensor/SoC)
• STM32CubeIDE für STM32-Projekte (Setup, Debug, Build)
• EU-Überblick zu Short-Range-Devices und harmonisiertem Spektrum

IoT-PCB-Design, Mikrocontroller-Programmierung & Firmware-Entwicklung

PCB Design • Arduino • Embedded Systems • Firmware

Ich biete professionelle Entwicklung von IoT-Hardware, einschließlich PCB-Design, Arduino- und Mikrocontroller-Programmierung sowie Firmware-Entwicklung. Die Lösungen werden zuverlässig, effizient und anwendungsorientiert umgesetzt – von der Konzeptphase bis zum funktionsfähigen Prototyp.

Diese Dienstleistung richtet sich an Unternehmen, Start-ups, Entwickler und Produktteams, die maßgeschneiderte Embedded- und IoT-Lösungen benötigen. Finden Sie mich auf Fiverr.

Leistungsumfang:

• IoT-PCB-Design & Schaltplanerstellung

• Leiterplattenlayout (mehrlagig, produktionstauglich)

• Arduino- & Mikrocontroller-Programmierung (z. B. ESP32, STM32, ATmega)

• Firmware-Entwicklung für Embedded Systems

• Sensor- & Aktor-Integration

• Kommunikation: Wi-Fi, Bluetooth, MQTT, I²C, SPI, UART

• Optimierung für Leistung, Stabilität & Energieeffizienz

Lieferumfang:

• Schaltpläne & PCB-Layouts

• Gerber- & Produktionsdaten

• Quellcode & Firmware

• Dokumentation & Support zur Integration

Arbeitsweise:Strukturiert • Zuverlässig • Hardware-nah • Produktorientiert

CTA:
Planen Sie ein IoT- oder Embedded-System-Projekt?
Kontaktieren Sie mich gerne für eine technische Abstimmung oder ein unverbindliches Angebot. Finden Sie mich auf Fiverr.