Radar-Verkehrsmessung

Aus der Mikrocontroller.net Artikelsammlung, mit Beiträgen verschiedener Autoren (siehe Versionsgeschichte)
Wechseln zu: Navigation, Suche

von ProjektAE

Aufgebautes Messgerät inkl. Solarmodul

In dieser Dokumentation beschreiben wir, sechs Studenten, unser Vorgehen bei dem Projekt "Radar-Verkehrsmessung". Das Projekt ist im Rahmen eines Projektkurses zu vernetzten und energieautarken Sensoren entstanden. Wir haben uns dabei für die Entwicklung eines Systems zur Erstellung einer Verkehrsstatistik entschieden. Das Messsystem soll aus einem Server und einem oder mehreren Geräten bestehen, welche am Straßenrand installiert werden. Jedes der Geräte enthält einen Doppler-CW-Radar, mit dem Kraftfahrzeuge erfasst, gezählt und deren Geschwindigkeit gemessen werden können. Die Daten werden nach der Erfassung zu statistischen Werten zusammengefasst und in regelmäßigen Zeitabständen via LoraWAN an den Server gesendet. Dort werden die Daten gespeichert, aufbereitet und auf einer Website bereitgestellt.

Einleitung

Blockdiagramm Messgeraet Radar-Verkehrsmessung.png

Zuerst eine kurze Auflistung der wichtigsten Merkmale, die das Radar-Messgerät erfüllen soll:

  • Betriebsbedingungen:
    • IP-Schutzklasse: mindestens IPX4 (Schutz gegen allseitiges Spritzwasser)
    • Temperaturbereich: 0 °C ... 30 °C Umgebungstemperatur
    • Einsatzregion: Deutschland → innerhalb der in Deutschland verfügbaren Frequenzbänder und gültigen Regulierungen (Radarmodul ist zertifiziert nach ETSI EN 300 440)
    • Betriebsdauer: mindenstens 168 h im Akkubetrieb, Optional: Verlängerung durch ein Solarmodul.
  • Funktionen:
    • Akku-Pack ist wechselbar
    • Geschwindigkeiten zwischen 20 und 100 km/h messbar
    • Messung auf einspuriger Fahrbahn in eine Fahrtrichtung
    • Übertragung der Messdaten über LoRa
    • Statistische Auswertung der Messdaten auf externem Server

Stückliste

Im Folgenden sind alle Komponenten, welche für den Aufbau des Messgeräts benötigt werden, aufgelistet. Bis auf die Komponenten für das Akku-Pack und das Solarmodul, können alle Komponenten bei DigiKey bestellt werden.

Stückliste
Name Beschreibung Distributor Bestell-Nr. Menge Stückpreis Preis Gesamt
µC-Board NUCLEO-64 STM32F302R8 DigiKey 497-14594-ND 1 11,91 € 11,91 €
LoRa-Modul RFM95W-868S2 DigiKey RFM95W-868S2-ND 2 15,81 € 15,81 €
OPV für Vorverstärker ADA4841 DigiKey ADA4841-2YRZ-ND 3 6,89 € 20,67 €
MOSFET FDV304P DigiKey FDV304PCT-ND 3 0,26 € 0,78 €
NPN Transistor BCW60C DigiKey 1727-1574-1-ND 3 0,26 € 0,78 €
C 2µ2 CC0805KRX5R7BB225 DigiKey 311-3428-1-ND 10 0,16 1,60
C 1n5 CC0805KRX7R9BB152 DigiKey 311-1128-1-ND 10 0,10 € 1,00 €
R 1k2 CRGCQ0805F1K2 DigiKey A129750CT-ND 10 0,05 € 0,50 €
R 10k RC0805FR-0710KL DigiKey 311-10.0KCRCT-ND 25 0,04 € 1,00 €
R 15k CRGCQ0805F15K DigiKey A129763CT-ND 10 0,05 € 0,05 €
Poti 10k 3361P-1-103GLF DigiKey 3361P-103GLFCT-ND 4 1,51 € 6,04 €
Protoshieled Bare PCB DEV-13819 DigiKey 1568-1865-ND 2 5,42€ 10,82 €
Pin Header Arduino PRT-11417 DigiKey 1568-1413-ND 2 1.65€ 3,30 €
DC/DC Wandler DFR0568 DigiKey 1738-1439-ND 2 3.47€ 6,94 €
OPV für Stromversorgung MCP6241-E/P DigiKey MCP6241-E/P-ND 3 0,32€ 0,96 €
Stecker-Akku CP-2215-ND DigiKey CP-2215-ND 3 4,32€ 12,96€
Lochrasterplatine 8029 DigiKey V2025-ND 1 7,58€ 7,58 €
Draht Schwarz 1,5m C2003A.12.01 DigiKey C2003B-5-ND 1 1,07€ 1,07 €
Draht Rot 1,5m C2003A.12.03 DigiKey C2003R-5-ND 1 1,07€ 1,07 €
Draht Gelb 1,5m C2003A.12.05 DigiKey C2003Y-5-ND 1 1,05€ 1,05 €
Stiftleiste 6pol PH1-06-UA DigiKey 2057-PH1-06-UA-ND 3 0.13€ 0,39 €
Buchse 6pol 09185067813 DigiKey 1195-1670-ND 2 1.54€ 3,08 €
Gehäuse PTS-25323 DigiKey 377-2418-ND 1 17,84 € 17,84€
Schalter M2011S2A1W01 DigiKey 360-3240-ND 1 4,30 € 4,30 €
Abstandsbolzen mit Schraube 24337 DigiKey 36-24337-ND 10 0,49 € 4,90 €
Abstandsbolzen R30-1000402 DigiKey 952-3008-ND 10 0,30 € 3,00 €
Kabel wasserdicht 743 DigiKey 1528-2000-ND 2 2,70 € 5,40 €
Klebeband elek. isol. 33+SUPER-3/4X20FT DigiKey 3M156004-ND 1 4,18€ 4,18 €
Stiftleiste 3 pol PH1-03-UA DigiKey 2057-PH1-03-UA-ND 5 0,11€ 0,55 €
Stiftbuchse 3 pol PPPC031LFBN-RC DigiKey S7036-ND 5 0,40€ 2,00 €
Wärmeschrumpfschläuche Schwarz F221V1/16 BK060 DigiKey F221V1/16BK060-ND 1 0,89€ 0,89 €
Wärmeschrumpfschläuche Rot F2211/16 RD060 DigiKey F2211/16RD060-ND 1 0,89€ 0,89 €
Wärmeschrumpfschläuche Gelb F2211/16 YL060 DigiKey F2211/16YL060-ND 1 0,89€ 0,89 €
Solarmodul 2.5W 5V / 500mAh Amazon Link 1 13,99€ 13,99 €
Akkus mit U-Lötfahne LG INR18650MJ1 ... + Lötfahne U Akkuteile.de 1006971 7 6,20€ 43,40 €
BMS 1S PCB - Keeppower PCM KP-1600-S1 Akkuteile.de 200507 1 2,90€ 2,90 €
Fuyuang (Enerpower) 1S 3,6V - 3,7V (4,2V) Li-Ion-Ladegerät 2A Akkuteile.de 400619 1 11,90€ 11,90 €

Software

In diesem Kapitel werden alle von uns erstellten Software-Komponenten beschrieben. Das vorverstärkte sinusartige Signal des Radarsensors wird über einen I/O-Pin mit dem ADC mit einer 10 kHz Sampling-Frequenz ausgewertet und in einen Buffer geschrieben. So bald eine bestimmte Anzahl an Werten im Speicher steht, wird dieser dem Hauptprogramm übergeben und mittels einer FFT ausgewertet. Aus den ermittelten Frequenzen werden die zugehörigen Geschwindigkeiten berechnet und zu statistischen Mittelwerten zusammengefasst. Diese Werte werden in festgelegten Zeitabständen via LoRa-Wan an einen Server übermittelt, der diese dann auf einer Website darstellt. Als Entwicklungsumgebung haben wir uns für die STM Cube IDE entschieden, um allen Betriebssystemen und Wissensständen in der Gruppe gerecht zu werden.

ADC

Ziel der ADC-Implementierung ist es, den ADC so zu konfigurieren, dass er das vorverstärkte Signal des Radarsensors mit einer bestimmten Frequenz sampelt und eine festgelegte Anzahl an Rohdaten in einem Buffer gesammelt werden, bis sie an die Signalverarbeitung übergeben werden.

Das massebezogene Ausgangssignal des Vorverstärkers wird über einen GPIO-Pin auf das u-Controller-Board geführt. Mit der Funktion void adc_init(void) wird der ADC initialisiert und alle Vorraussetzungen für die erfolgreiche Wandlung gesetzt. Dazu gehören das setzen des Prescalers und der Sampling-Rate, um aus dem u-Controller-Takt von 72 MHz eine Samplingfrequenz von 10 kHz zu erreichen. Außerdem wird der ADC-Channel ausgewählt und der gewünschte IO-Pin in den alternate function mode versetzt. Eine Kalibierung des ADCs für single-ended Signale wird angestoßen. Die ADC-Auflösung wird auf die maximal möglichen 12 Bit festgelegt und das Data Alignment der zwei Ergebnisbytes wird auf Wunsch der Signalverarbeitung auf left gesetzt. Abschließend wird der ADC in einen betriebsbereiten Modus versetzt.

Mit der Funktion void adc_convert(uint16_t * conv_result_array) werden die in FFT_INPUT_SIZE definierten 512 ADC-Wandlungen angestoßen. Sobald nach jeder Wandlung das End Of Conversion flag (ADC_ISR_EOC) gesetzt ist, wird das Ergebnis aus dem ADC1->DR (Data Register) ausgelesen und an der jeweiligen Stelle des übergebenen Arrays conv_result_array abgespeichert. Danach ist der ADC wieder in demselben betriebsbereiten Zustand wie nach der Initialisierung und erneute Wandlungen können gestartet werden.

Signalverarbeitung

Ziel der Signalverarbeitung ist es aus den aufgenommenen Rohdaten des ADCs einzelne Autos zu erkennen und deren Geschwindigkeit zu ermitteln.

Die Information der Geschwindigkeit eines Autos steckt in der Frequenz des Signals. Um diese Information auswerten zu können wird eine FFT verwendet. Die Funktion void fft_l512(q15_t *real_data, q15_t *imag_data) berechnet eine komplexe Fourier-Transformation. Als Datentyp wird eine 16Bit Festkommazahl in dem Format q15_t verwendet. Da das Eingangssignal in diesem Fall nur reell ist, besteht der Imaginärteil aus einem Array gefüllt mit 0. Das Ergebnis der FFT überschreibt die Daten des Eingabe-Arrays. Danach wird aus dem komplexen Frequenzspektrum wird mit der Funktion abs_squared das reelle Amplitudenquadrat gebildet. Hieraus kann mithilfe der Funktion arg_max die Frequenz mit maximale Pegel bestimmt werden. Diese Frequnz wird dann in einen Geschwindigkeitswert umgerechnet.

Der letzte Teil der Signalverarbeitung besteht darin, aus den vielen Geschwindigkeitsinformationen der einzelnen Messungen die einzelnen Autos und ihre Geschwindigkeiten herauszufinden. Hierfür wurde zum einen ein Pegel-Schwellwert (THRESHOLD) definiert, ab welchem eine Geschwindigkeit als valide erklärt wird. Zusätzlich zwei zeitliche Schwellwerte definiert. Ein Schwellwert (TIME_CAR_LENGTH) legt fest, wie viele Geschwindigkeits-Messwerte für ein Auto mindestens benötigt werden. Der andere Schwellwert (TIME_CAR_PAUSE) sagt aus wie viele Zeiteinheiten nichts detektiert werden darf, damit ein Messwert zu einem neuen Auto gehört. Hierrüber wird also die Pause zwischen den Autos definiert.

Datenverwaltung und -komprimierung

Da nicht jede Messung einzeln übertragen wird, wird nachdem eine Geschwindigkeit ermittelt wurde, diese intern bis zur nächsten Übertragung an den Server in einem Datenpaket abgelegt. Dieses Datenpaket, realisiert ein 40Byte großes Structure, beinhaltet die minimale, maximale sowie Durchschnittsgeschwindigkeit, den Zählstand der hinzugefügten Geschwindigkeiten sowie den Batteriestand. Zur Erstellung einer Statistik ist in dem Datenpaket auch ein Array abgelegt, welches die gemessene Geschwindigkeit einem Geschwindigkeitsbereich zuordnet.

typedef struct {
    float avg_speed, max_speed, min_speed;
    uint16_t counter;
    uint16_t histoarr[SIZE];
    uint8_t akku;
} statistic;

Das hinzufügen der Geschwindigkeit erfolgt über den Aufruf der Funktion

void statistic_add(statistic *data, float speed)


Um die Datenrate möglichst gering zu halten, wird das Datenpaket zur Übertragung "komprimiert", wobei nach der Übertragung eine Genauigkeit von 0,5 km/h gegeben ist. Die zu übertragenden Daten werden nach Aufruf von in einem 24Byte großen Array abgelegt.

Komprimierung über

void statistic_compress(statistic *data, uint8_t bat_val, uint8_t compress_Arr[SIZEARR])


Nach erfolgreicher Datenübertragung werden die internen Werte der letzten Messung zurückgesetzt. Reset über

void statistic_reset(statistic *data)


LoRa

Aufbau der LoRa-Ethernet-Bridge

Damit der STM32 in unserem Aufbau mit der Außenwelt kommunizieren kann, haben wir uns hier für LoRa entschieden.

Die Vorteile sind vielschichtig:

  • Lange Strecke (~20 km)
  • Sehr Energiesparend
  • Großes Weltweites Netzwerk an Gateways, die mit dem Internet Verbunden sind.

Als LoRaWAN Anbieter haben wir uns für TheThingsNetwork entschieden, da es dort mehr als 11851 Gateways in über 150 Länder gibt, und das Webinterface einfach zu handhaben ist.

Die Bekannteste Bibliothek für die Authentifizierung für LoRaWAN ist hier die LMIC Bibliothek von IBM für Arduino. Von dieser gibt es auch eine Version für den STM32, welche hier zu finden ist. Mithilfe des Videos lässt sich das LoRa-Modul mit dem STM32 verbinden und testen.

In unserem Test konnten leider keine Pakete gesendet werden, lediglich die Authentifizierung hat geklappt. Dies könnte mehrere Ursachen haben:

  • Bibliothek funktioniert nicht richtig
  • schlechter Empfang

Aufgrund von Zeitmangel und schlechter Gateway-Infrastruktur im ländlichen Bereich haben wir uns im Nachgang dazu entschieden, eine einfache LoRa Strecke ohne Gateways aufzubauen. Dazu sendet der STM32 seine Daten über den LoRa an einen Arduino, den wir in der nähe des Gerätes platzieren müssen. Der Arduino dient dann als LoRa zu Ethernet umsetzer. Diesen kann man dann entweder direkt an unseren Server anschließen, oder aber auch an das Internet anschließen. Als Bibliothek wird die LoRa Bibliothek von Sandeep Mistry genutzt.

Das LoRa-Modul ist dabei auf einem Protoshield aufgebracht, welches später auf den Arduino-Headern montiert wird.

Server

Server Gerätekarte

Der Server dient zur Speicherung und Darstellung der Messwerte der verschiedenen Geräte. Der Server wurde in Python mit dem Framework Flask geschrieben. Zusätzliche Python-Pakete werden für die weiteren Funktionen eingesetzt.

Die Anbindung des Servers and TheThingsNetwork erfolget über die API. Für Python steht hierfür ein SDK bereit. Damit können die einzelnen Geräte des TTN-Servers aufgelistet und die Metadaten (Standort, Beschreibung, ID) ausgelesen werden. Das Empfangen der Daten erfolgt über Einrichten einer HTTP Integration in der TTN-Weboberfläche. Nach korrekter Einrichtung Sendet der TTN-Server bei jedem erfolgerichem Uplink das Datenpaket an den Verkehrsmessung-Server. Über die Weboberfläche der Things-Console kann dabei zu Testzwecken ein Uplink simuliert werden.

Die Informationen zu den Geräten und den Datenpaketen werden in einer Datenbank gespeichert. Hierfür wurde postgres verwendet, da für Python mit dem Paket flask_sqlalchemy hierfür eine bequemene Schnittstelle zur Verfügung steht.

Die Darstellung der Messwerte erfolgt auf einer Website. Hier wurde ein fertiges Template verwendet und entsprechend angepasst. Die Darstellung der einzelnen Grafiken erfolgt mit der Bibliothek bokeh, welche eine Python-Schnittstelle für interaktive JavaScript-Plots bereitstellt.

Auf der Website gibt es verschiedene Unterseiten:

  • Übersicht über Geräte: Hier ist eine Liste der Geräte dargestellt. Von dort kommt man auf die
    • Messwerte eines Gerätes: Darstellung des Status eines Gerätes, Darstellung der Messwerte
  • Karte mit Standorten der Geräte

Der Server muss durchgehend laufen, damit alle Messwerte erfasst werden. Für einen einfacheren Ensatz, steht der Server als Docker-Container zur Verfügung.

Hauptprogramm

Das Hauptprogramm fügt die einzelnen Komponenten zusammen. Zu Beginn des Programms werden die nötigen Komponenten initialisiert.

Danach wird der Reihe nach folgendes ausgeführt:

  1. Aufnahme von Messwerten mit ADC
  2. Signalauswertung und Ermitteln der Geschwindigkeit per FFT
  3. Wenn Geschwindigkeit gültig: Update der Statistik mit neuem Geschwindigkeitswert
  4. Alle 10000 Durchläufe: Komprimieren und Senden der Statistik
  5. Warte 10 ms

An der obigen Aufzählung ist zu erkennen, dass Jeder Schleifendurchlauf unterschiedlich lange dauern kann. Ebenfalls gibt es für die Schleife keine feste Zeitbasis, sodass die Schleifenfrequenz über das Warten variiert wird. Zusätzlich ist das Sendeintervall nicht exakt konstant und muss experimentell eingestellt werden. Dies könnte in Zukunft durch eine zeitgetriggerte Schleife behoben werden.

Hardware

In diesem Kapitel wirdzum einen auf die Auswahl einiger Komponenten, sowie auf den Entwurf, den Aufbau und die Funktion der einzelnen Hardware-Komponenten eingegangen. Dazu zählen unter anderem die Stromversorgung, der Vorverstärker zum Verstärken und Filtern des Radarsignals und das Gehäuse.

Mikrocontroller

Als µController wird der STM32F302(R8T6)-NUCLEO-64 verwendet.

Ausgewählt wurde dieser, da er eine hohe Taktrate (bis zu 72 MHz) und eine 32-Bit-CPU hat. Dies ist für eine schnelle FFT-Analyse für das Radarmodul von Vorteilen. Auch ist er für ca. 11 € kostengünstig und ist auf einem Evaluationsbord aufgelötet. Dies erleichtert den Anschluss der Hardware und die Programmierung des Mikrocontrollers enorm.

Mit seinen 64 KByte Flash Speicher, 16 KByte SRAM Speicher, 3 U(S)ART und 2 SPI Schnittstellen hat dieser auch genügend Resourcen, um all unsere Aufgaben in kürzester Zeit zu erledigen.

Da unser Messgerät mit einem Akku betrieben wird, ist auch der Stromverbrauch ein sehr wichtiges Thema. Der STM32F302 ist dabei auch sehr geeignet, da er standardmäßig bei 3.3 V betrieben wird und sehr energiesparend ist (maximaler Stromverbrauch nicht mehr als 70 mA @ 3.3 V).

Stromversorgung

Akkus versorgen den µController und den Radarsensor über einen DC/DC Wandler mit Energie. Das Solarmodul soll die Akkulaufzeit erhöhen, so dass das Radargerät als ganzes autark ist.

Schaltbild der Stromversorgung

Schaltbild der Stromversorgung

Das Schaltbild ist in die drei Teilkomponenten unterteilt:

  • Rot: Platine mit BMS (Battery Management System),
    Schmitt Trigger und DC/DC Wandler
  • Blau: Akkupaket
  • Grün: Solarmodul

Die Teilkomponenten sind jeweils durch Stecker verbunden:

  • Akku zu Platine (Blau zu Rot)
    (Akku +) zu (B+) des BMS; (Akku -) zu (B-) des BMS
  • Solarmodul zu Platine (Grün zu Rot)
    (Solar +) zu (B+) des BMS; (Solar -) zu (P-) des BMS

Dadurch ist ein einfaches Wechseln des Akku-Packs möglich und es kann außerhalb des Gehäuses geladen werden.
Das Solarmodul kann durch einen Steckverbinder außerhalb des Gehäuses getrennt werden, wodurch auch der Zugang zum Gehäuse ermöglicht wird.
Die Ausgänge VO-, VO+ und die Niederspannungswarnung führen zum µController.
Wird der Schalter auf die Position OFF gestellt, sind alle Funktionen, außer der Ladenfunktion durch das Solarmodul, ausgeschalten.

Beschreibung der Komponenten

Akku
Wir nehmen einen Stromverbrauch der uController Schaltung mit Radarsensor von 100 mA an und das Messgerät soll durch die Akkus (ohne Solarmodul) sieben Tage mit Energie versorgt werden.

Bei 7x18650 (3,6V mit 3,5Ah) wären das:

[math]\displaystyle{ T = 0,8 * \frac{(3,2 \ Ah*7)}{(0,1 \ A*24)} = 7,47 \ d }[/math]

Der DC/DC Wandler hat bei diesem Strom eine Wirkungsgrad von 80%; Die Akkus werden nie zu 100% entladen. Von dem her wird hier von 3,2Ah ausgegangen. [Entlade Diagramm Li Ionen Akku]

BMS
Das Batterie Management System schützt die Akkus vor Tiefentladung, Überspannung und Überstrom. Das BMS sorgt für eine Ladespannung etwas über der Akkuspannung.

Ladestation für Akku-Pack
Die Ladestation besteht aus dem Li-Ion-Ladegerät 2A

DC/DC Wandler
Der DC/DC Wandler stellt 3,3V ausgangsseitig zur Verfügung; geschätzter Stromverbrauch von 100mA und Wirkungsgrad von 80%:

[math]\displaystyle{ P(Ausgang)=330 \ mW; P(Eingang) = \frac{P(Ausgang)}{0,8}=412,5 \ mW }[/math]

Bedeutet, je weniger Ladung und damit Spannung die Akkus haben, desto mehr Strom fließt von den Akkus zum DC/DC Wandler.

Solarmodul
Die Fläche des Solarmoduls ist so ausgelegt, dass die Energie unter guten Umständen (Winkel, Sonneneinstrahlung => Jahreszeit, Tageszeit) den Energieverbrauch der uController Schaltung mit Radarsensor deckt und zusätzlich die Akkus laden soll. Als Beispielrechnung dient eine 25m2 PV-Anlage in Niederbayern, deren Energieertrag täglich seit Mai 2018 erfasst wurden. Es werden Daten aus dem Jahr 2019 genutzt und ein durchschnittlicher Tag als Beispiel durchgerechnet.

Fläche des Solarmodul für das Radargerät: 2*15cm x 13cm
März: Tagesdurchschnitt: 16,9 kWh bei 25m2 => theoretisch 26,35 Wh bei 390cm2
Juni: Tagesdurchschnitt: 29,86 kWh bei 25m2 => theoretisch 46,6 Wh bei 390 cm2
September: Tagesdurchschnitt: 18,23 kWh bei 25m2 => theoretisch 28,4 Wh bei 390 cm2

Vergleich mit dem täglichen Verbrauch des Radargerätes: [math]\displaystyle{ \frac{3,3 \ V*100 \ mA*24 \ h}{0,8} = 10 \ Wh }[/math]

Unter der Annahme, dass das Radargeräte unter Umständen einen nicht so hohen Energieertrag wie eine fest installierte PV-Anlage hat (Schatten im Verlauf des Tages, ungünstiger Winkel, niedrigerer Wirkungsgrad) liefert dieses Solarmoduls (wenn man den theoretischen Wert deshalb mit einem angenommen Faktor von 0,5 multipliziert) trotzdem im Schnitt mehr Energie als verbraucht wird. Damit ist das Radargerät autark und kann auch ohne Probleme schlechter Tage überbrücken. siehe [Diagramm => zum Teil schwankende Werte]

Es können auch Solarmodule mit einer Leerlaufspannung größer als 5V hergenommen werden. Dann muss jedoch ein DC/DC Wandler eingebaut werden, um den optimalen Stromertag der Solarmodule zu erzielen. => Akkus werden mit Strom geladen (Ladung in Ah).

Schmitt Trigger (nicht invertierender)
Die Niederspannungswarnung soll dann aktiv werden (Ausgang auf 0V) , wenn das Akkupaket nur noch eine Tag den uController mit Radarsensor nur noch einen Tag mit Strom versorgen kann. Die Niederspannungswarnung geht wieder aus (Ausgang auf 3,3V), wenn der Akku mehr als 2 Tage das Radargerät mit Strom versorgen kann. Die Grenze und Hysterese ist flexible einstellbar.
=> Hysterese von einem Tag (entspricht ca. 70mV) In den Downloads befindet sich eine dazugehörige LTspice Simulation und eine .odt mit den entsprechenden Rechnungen
Der Schmitt Trigger in dem Schaltbild soll durch diese Schaltung ersetzt werden.

Datei:Schmitt trigger.asc

Nachtrag
Das Radarmodul hat einen Stromverbrauch von 80mA. Das bedeutet, dass die Akkus länger als sieben Tage das Radargeräte mit Strom versogen können.

[math]\displaystyle{ T = 0,8 * \frac{(3,2 \ Ah*7)}{(0,08 \ A*24)} = 9,33 \ d }[/math]

Radarsensor

Für den Radarsensor kamen zwei Kategorien in Frage: CW-Radar (= unmodulierter Dauerstrichradar) und FMCW-Radar (= frequenzmodulierter Dauerstrichradar). Mit letzterem ist außer der Geschwindigkeitsbestimmung mittels Doppler-Effekt zusätzlich noch eine Entfernungsbestimmung möglich. Da diese Sensoren aber um einiges teurer sind und die Entfernungsbestimmung nicht Teil des Projektes ist, wurde sich für einen CW-Radar entschieden. Auf Grund seines vielseitigen Angebots und guter Verfügbarkeit in Elektronik-Online-Shops haben wir uns für den Hersteller Innosent entschieden.
Die angebotenen Radarsensoren wurden nach folgenden Kriterien aussortiert:

  • niedriger Preis
  • Versorgungsspannung möglichst 3,3 V
  • niedrige Stromaufnahme
  • schmales Antennenpattern

So fiel die Auswahl auf:
SMR-333 (Stereo, Vpp = 3,2..3,4 V, 47..57 mA, Pout = 12.7 dBm max, SMT-mountable, Integrated LNA, signal level 120..360 uVrms, noise level = 20 uVrms max, narrow antenna pattern)

Vorverstärker

Stromlaufplan Vorverstärkerschaltung

Der Radarsensor liefert ein Ausgangssignal mit variierender Amplitude (im mV-Bereich) und Frequenz. Je näher ein Objekt dem Sensor kommt desto größer ist die Amplitude und je schneller das Objekt ist, desto höher ist die Frequenz. Um das Ausgangsignal vernünftig verarbeiten zu können, muss zum einen die Amplitude verstärkt werden und da nur Geschwindigkeiten bis max. 100 km/h gemessen werden sollen, muss es zusätzlich gefiltert werden.

Das ausgehende Signal muss also zunächst durch einen Vorverstärker und einen Frequenzfilter. Dazu wurde sich zweier in Serie geschaltenener Verstärkern mit aktivem Filter 1.Ordnung bedient. Als Vorlage wurde der Vorverstärker eines EvalBoards der Firma InnoSent verwendet [1]. Bei dem aktiven Filter handelt es sich um einen Tiefpass mit einer oberen Grenzfrequenz von 5 kHz. Zusätzlich wird vor jedem OPV ein Kondensator zur AC-Kooplung eingefügt, wodurch der Filter ein Hochpass-Verhalten mit Center-Frequenz 2,55 kHz und einer Bandbreite von 4,9 kHz erhält.

Um das Ausgangssignal im weiteren Verlauf mittels ADC einzulesen, wird es als Single-Ended Signal mit einer Offset-Spannung von 1,65 V (halbes Vcc) ausgegeben. Dabei kann das Signal einen maximale Peak-Peak-Spannung (Vpp) von 3,3 V bei einem Eingangssignal von max. 48 mV erreichen ohne das der Verstärker in Säätigung geht.

Da bei der Messung der Geschwindigkeit die Amplitude des Signals keine Rolle spielt, sonder lediglich die Frequenz ausschlagebend ist, ist es annehmbar falls der Verstärker in Übersteuerung gehen würde.

Da der Radarsensor SMR-333 sowhl I- als auch Q-Daten bereitstellt, müssten zwei der Vorverstärker aufgebaut werden. In diesem Projekt wird allerdings nur ein Anteil des Ausgangsignals verwendet, welches der beiden gewählt wird ist optional.

Plot des Frequenzgangs

Der Vorverstärker wurde mittels LT-Spice simuliert.
Datei:Simu OPV Radarsensor ADA4841.asc

Die wichtigsten Eigenschaften des Vorverstärkers:

  • untere Grenzfrequenz (-3 dB): 100 Hz
  • obere Grenzfrequenz (-3 dB): 5 kHz
  • maximale Verstärkung: 40 dB @ 700 Hz
  • Ausgangssignal: Single-Ended mit Offset von 1,65 V (max. Vpp = 3,3 V)

Der Vorverstärker wurde auf einem Protshiled aufbeaut, welches im späteren Aufbau auf den Arduino-Headern des µControllers aufgesteckt wird.

Gehäuse

Schematischer Aufbau des Gehäuses
Geöffnetes Messgerät inkl. Solarmodul

Das Messgerät wird überwiegend im Außenbereich eingesetzt und muss daher in einem passenden Gehäuse untergebracht werden. Wie in der Einleitung bereits erwähnt, soll das Messgerät in aufgebauter Form einem Standard von mind. IPx4 entsprechen. Das in der Stückliste aufgeführte Gehäuse entspricht laut Herstellerangabe einem Standard von IP67.

In den Abbildungen rechts können zum einen der schematische Aufbau der einzelnen Komponenten im Gehäuse, sowie das geöffnete das Gehäuse des aufgebauten Prototyps betrachtet werden.

In das Gehäuse werden die folgenden Komponenten eingebracht:

  • das Akku-Pack
  • die Leiterplatte mit der gesamten Beschaltung für die Stromversorgung
  • das Radarmodul auf einer zusätzlichen Leiterplatte zur einfacheren Montage
  • das Protoshield, auf welchem der Operatiosnverstärker und das LoRa-Modul samt deren Beschaltung montiert sind

Auf der einen Seite befinden sich gestappelt (in aufsteigender Reihenfolge) die Lochrasterplatine der Stromversorgung, der µController und das Protoshield mit Vorverstärker und LoRa-Modul. Die Lochrasterplatine der Stromversorgung ist dabei mit einer Schraube an der Platinenhalterung am Boden des Gehäuses befestigt. Auf der anderen Seite des Gehäuses wird das Akku-Pack reingestellt.

Das Radarmodul ist mit seiner Leiterplatte an der Gehäusewand befestigt. Dazu werden zwei der Abstandsbolzen mit Gewinde im Deckel an der langen Seitenwand angebracht und die Leiterplatte mit den einfachen Abstandsbolzen festgeschraubt.

Das Gehäuse kann durch das Entfernen der vier Schrauben an den Ecken des Gehäuses und durch abheben des Deckels geöffnet werden. Somit hat man Zugang zum Wechseln des Akku-Packs oder zum Konfigurieren des Messgeräts.

Für den Fall, dass ein Solarmodul zur Verlängerung der Laufzeit verwendet wird, muss eine mechanische Modifikation in Form einer Bohrung an der Gehäusewand vorgenommen werden. Um das Gehäuse weiterhin den Mindeststandard von IPx4 zu geben, wird die Bohrung nach der Durchführung des Kabels mit einem geeigneten Material wieder versiegelt. Hierfür kann Beispielsweise einfaches Fugen-Silikon verwendet werden, welches optimaler Weise sowohl an der Innen-, wie auch an der Außenseite des Gehäuses um das durchgeführte Kabel aufgebracht wird. Alternativ kann die Durchführung auch mit einem geeigneten Kleber versiegelt werden.

Die Solarpanele werden auf einer Sperrholzplatte aufgebracht. Auf der Rückseite der Sperrholzplatte, sowie auf dem Deckel des Gehäuses werden je zwei Streifen Klettband aufgebracht. Dadurch kann das Solarmodul einfach auf dem Gehäuse befestigt und wieder abgenommen werden.

Downloads

Hier stehen Dateien zum Download zur Verfügung:

Simulation des Schmitt Triggers

Simulation des Vorverstärkers

Mikrocontroller Code

Server Code

Referenzen