Radar basierter WiFi-Niederschlagssensor für Regen, Hagel und Schnee

Begonnen von chunter1, 10 Juni 2017, 13:07:48

Vorheriges Thema - Nächstes Thema

AxelSchweiss

Zitat von: Per am 19 Juli 2017, 13:03:27
Nicht tauschen, Multifeed!
Das ist ja wohl eher "Many-Feed"  :)

Aber im Ernst .... stört der Radarsender das Sattelitensignal oder zerstört den LNB ?
Wenn nicht könnte man ihn tatsächlich parallel betreiben.
Nur durch die schräge Aufhängung wird die Berechnung der aufgespannten Fläche etwas aufwendiger.


chunter1

#121
Zitat von: AxelSchweiss am 19 Juli 2017, 13:14:41
Das ist ja wohl eher "Many-Feed"  :)

Aber im Ernst .... stört der Radarsender das Sattelitensignal oder zerstört den LNB ?
Wenn nicht könnte man ihn tatsächlich parallel betreiben.
Nur durch die schräge Aufhängung wird die Berechnung der aufgespannten Fläche etwas aufwendiger.

Der 24 GHz Oszillator sollte den 12 GHz Bereich theoretisch nicht stören - eher andersrum - aber selbst das eher nicht da der Local-Oscillator des LNB bei 9.75/10,6 GHz liegt (Erste Oberwelle liegt bei= 19,5/21,2 GHz).
Es könnte allerdings sein, dass die LNAs durch zu geringe Filterung übersteuert werden - was den Sat-Empfang stört.

Einfach ausprobieren.
Zerstören kann man da nix.
Freu mich auf einen Erfahrungsbericht  ;)

Per

Zitat von: AxelSchweiss am 19 Juli 2017, 13:14:41Das ist ja wohl eher "Many-Feed"  :)
Ich habe schon mit Absicht ein Extrem gewählt. Ein einfacher Zwei-Feed-Halter tuts natürlich auch. Und die exakte Himmelsrichtung ist ja eher uninteressant ggü. einem LNB.

Zitat von: AxelSchweiss am 19 Juli 2017, 13:14:41Nur durch die schräge Aufhängung wird die Berechnung der aufgespannten Fläche etwas aufwendiger.
Wird die nicht eh kalibriert? Dabei wird doch die genaue Größe genau wie elektrische oder mechanische Toleranzen ausgemerzt.

AxelSchweiss

Die vom Regen "durchfallene" Fläche kannst du ja schlecht kalibrieren  ... die werden wir schon messen müssen.
Was der Sensor ev. noch bringt ist die Entfernung zur Schüssel  ... die ist aber gewölbt  :)
Eventuell bringt er noch die Breite des reflektierten Signals.
Müsste man mal chunter1 fragen.
Zusammen mit dem Winkel könnte man dann ein Dreieck ausrechnen. Die Wölbung fehlt dann aber.

Das Ganze sieht mir aber nach ziemlich Aufwand nur für einen Kalibriermodus aus.

chunter1

#124
Eigentlich betrachtet der Radarsensor ein "Messvolumen".
Aber aus der Sicht des Regens ist es natürlich eine Fläche. ;)

Datenblatt vom Sensor mit Antennendigramm gibts hier:
http://www.innosent.de/fileadmin/media/dokumente/DATASHEETS_2016/Datenblatt_IPM-165_V8.5.pdf

Das radiation-pattern dürfte in etwa so wie jenes unten aussehen.
Daran sieht man auch, dass die Ausrichtung des Sensors einen Unterschied macht.

Die Ausrichtung mit der ich arbeite ist ebenfalls unten zu sehen (Foto vom PCB).
Bin mir aber noch nicht sicher, ob es nicht doch besser wäre ihn um 90° zu drehen (mehr Breite statt Höhe).
Dann sind die Tropfen zwar nicht so lange im Sichtfeld, dafür ist die betrachtete Fläche größer und die Dopplerfrequenzen sollten schmalbandiger/"schärfer" werden.

HCS

Ich denke, es wäre sinnvoll, eine Varinte hinzubekommen, die ohne Schüsseln und Wände funktioniert.
Ansonsten ist die Möglichkeit der Anbringung schon deutlich eingeschränkt.

Auch wenn mal eine Biene, eine Katze oder eine 747 durchfliegt sollte, ist das nicht schlimm, das sollte man wegrechnen können.
Ich gehe mal davon aus, dass es nicht eine Sekunde lang regnet und dann wieder aufhört. Und wenn doch, dann ist es auch egal gewesen ...

Hat schon mal jemand probiert, wie der Sensor durch ein dünnes Kuststoffgehäuse durch erfasst?
Ich habe außen vor der Haustür eine Leuchte mit Radarsensor und die kann ich von innen schalten. Die "sieht" mich durch eine dreifach verglaste Haustür durch, wenn ich mich bewege.

chunter1

#126
Heute ist mein 0,48€ RCWL-0516 Radar Sensor aus China eingetroffen.
An Pin 12 kann man die Dopplerfrequenz abgreifen. :)
Mal schaun was der Wassertropfentest in der Dusche ergibt.

Auf den ersten Blick scheint es so, dass der Dopplerfrequenzbereich nach oben hin sehr eingeschränkt ist.
Die Frequenz liegt bei meinem Examplar bei exakt 3.156 GHz (mit Seitenbändern im 20 MHz Raster).

Edit:
Und hier noch eine Seite mit mehr Details:
http://www.rogerclark.net/investigating-a-rcwl-9196-rcwl-0516-radar-motion-detector-modules/

Auf alle Fälle "as is" als Regensensor für dieses Projekt nicht zu gebrauchen.

HCS

Ich habe das WebFrontend generell drin und am Laufen, screenshot angehängt. Aber es gibt noch Exceptions, wenn das WebFrontend und der freeRTOS Timer Interrupt zusammentreffen.

Eventuell wäre es sinnvoll, sofern von der Messstrategie machbar, von Timer auf lineare Verarbeitung umzustellen.

Also so (ganz grob):
Loop {
  if intervall > x
    n Millisekunden ADC sampeln
    snapshot usw. rechnen
    Ergebnis abliefern
   
    intervall zurücksetzen
  else
    intervall++
  endif
 
  frontend abhandeln
  ota abhandeln
  usw.
  usw.



Und was hier wie konfiguriert wird, ist mir noch nicht ganz klar:
"First and last bin-number for each bin-group (uint16 firstBin[32], uint16 lastBin[32])"


HCS

Habe gerade mal den commit ins repo getestet. Funktioniert aus meiner Entwicklungsumgebung heraus.

Die Readme-Änderungen kannst Du ignorieren  :)

chunter1

#129
Zitat von: HCS am 20 Juli 2017, 18:08:51
Ich habe das WebFrontend generell drin und am Laufen, screenshot angehängt.

Cool!!
Da ist ja schon alles drin was das Herz begehrt  :)

Zitat
Aber es gibt noch Exceptions, wenn das WebFrontend und der freeRTOS Timer Interrupt zusammentreffen.
Eventuell wäre es sinnvoll, sofern von der Messstrategie machbar, von Timer auf lineare Verarbeitung umzustellen.

Ohne den vorgeschlagenen Code getestet zu haben, fürchte ich, dass wir auf die timer-ISR nicht verzichten können.
(Das einzige ESP32 Board das ich derzeit besitze, steckt im Testaufbau auf der Wiese.)
Um eine möglichst saubere Frequenzauflösung und einen konstanten Frequenzbereich zu erreichen, müssen die ADC-Samples zeitlich so konstant wie möglich genommen werden.
Der ADC-Timer triggert alle 97,66us.
Ich denke mit der loop-Variante bekommen wir da einiges an jitter drauf - Was meinst du?

Zitat
Und was hier wie konfiguriert wird, ist mir noch nicht ganz klar:
"First and last bin-number for each bin-group (uint16 firstBin[32], uint16 lastBin[32])"

Ok, also die FFT liefert 256 Frequenz-bins:

Bin 0 = 0 Hz -> nicht relevant
Bin 1 = 20 Hz -> entspricht 0.18 m/s
Bin 2 = 40 Hz -> entspricht 0.36 m/s
...
Bin 255 = 5100 Hz -> entspricht 44.7 m/s


Die alle einzeln zu übertragen/auszuwerten wäre zu aufwändig und macht auch keinen Sinn.
Daher habe ich einfach mal 32 FFT-binGruppen definiert, die mehrere einzelne bins zusammenfassen.
Die derzeitige Standard Zuordnung sieht so aus:


binGroup0 enthält FFT-bin 1 bis 7 (firstBin=1, lastBin=7)
binGroup1 enthält FFT-bin 8 bis 15 (firstBin=8, lastBin=15)
binGroup2 enthält FFT-bin 16 bis 23 (firstBin=16, lastBin=23)
...
binGroup31 enthält FFT-bin 248 bis 255 (firstBin=248, lastBin=255)


Damit haben die Nutzer die einfache Möglichkeit ihre eigenen "Geschwindigkeitsklassen" zu definieren (auch überlappend zum Vergleichen).
Wenn mal feststeht, welche Gruppenparameter sinnvoll sind, kann man das Development-Feature wieder rausnehmen.
Für die Unterscheidung von Schnee, Regen, und Hagel brauchts sicher keine 32 Gruppen.

Wenn wir allerdings Mengen bestimmen wollen, wäre eine feinere Abstufung eher von Vorteil.

HCS

Zitat von: chunter1 am 20 Juli 2017, 21:34:53
Cool!!
Da ist ja schon alles drin was das Herz begehrt  :)
Ja incl. exceptions :(
Ich committe es in Kürze mal. Habe es so gestrickt, dass man immer noch in precipitationSensorESP32.ino oben die defaults setzen kann und somit auch ohne frontend wie bisher agieren kann. Das Frontend überschreibt die defaults dann, wenn man die Settings speichert (sofern man es schafft ohne crash).
Ich muss mal analysieren, was da eigentlich genau passiert, aber ich habe das ungute Gefühl, dass WebServer -> TCP/IP-Stack die irre Menge an interrupts nicht gut verkraftet.
Es kommt aber nur dann manchmal zum crash, wenn man das WebFrontend öffnet.

Würde den code gerne mal an Dich los werden, auch um zu sehen, ob es bei Dir noch bildet und die eigentliche Messwererfassung immer noch wie vorher liefert.


Zitat von: chunter1 am 20 Juli 2017, 21:34:53
Ohne den vorgeschlagenen Code getestet zu haben, fürchte ich, dass wir auf die timer-ISR nicht verzichten können.
(Das einzige ESP32 Board das ich derzeit besitze, steckt im Testaufbau auf der Wiese.)
Um eine möglichst saubere Frequenzauflösung und einen konstanten Frequenzbereich zu erreichen, müssen die ADC-Samples zeitlich so konstant wie möglich genommen werden.
Der ADC-Timer triggert alle 97,66us.
Ich denke mit der loop-Variante bekommen wir da einiges an jitter drauf - Was meinst du?
War eigentlich eher pseudo code.
Muss mal ausloten, wie exakt micros() delayMicroseconds() usw. ist.
Die idee ist, eine bestimmte Zeit lang in Schleife mit jeweils 97,66us (könnten das auch 100us sein?) Abstand ADC zu lesen, dann zu verarbeiten usw.
Aber mal schauen, ob wir das auch mit dem Timer-Interrupt stabil bekommen.

Oder man muss es in abwechselnden Phasen machen: Messen (mit Timer) -> Messwertaufbereitung -> Daten versenden -> Frontend verarbeiten -> Messen (mit Timer) -> usw.

Das mit den bin groups habe ich jetzt wohl verstanden.
Wir brauchen 32 Konfigurationen mit jeweils von und bis.

Hast Du eigentlich ein Vorgehensweise, um dem Sensor reproduzierbare Bewegung zu geben, um vorher/nachher-Betrachtungen zu machen?

HCS

Habe gerade die Version mit dem web frontend committed.

Funktioniert nun ohne exceptions. Das Problem war, dass der analogRead gecrashed ist, wenn der Timer interrupt kam, während das frontend den NVS flash offen hatte.
Das verträgt FreeRTOS nicht. Ich habe es jetzt erst mal so gelöst, dass ich den Timer stoppe, wenn das Frontend die Settings speichert.
Das sollte erst mal kein Problem sein, weil nach dem Speichern der Settings eh ein Reset ausgelöst wird, ein paar Analogwerte mehr oder weniger kurz vor dem reboot spielen dann auch keine Rolle. Ich schaue aber mal, ob ich noch eine bessere Variante finde, weil es beim Lesen der Settiings nicht so schön ist.

Schau mal, ob Du die Version bilden kannst und ob Sie bei Dir auch läuft.

Wenn das so weit passt, baue ich die "32 bins configuration" ein.

chunter1

#132
Zitat
Hast Du eigentlich ein Vorgehensweise, um dem Sensor reproduzierbare Bewegung zu geben, um vorher/nachher-Betrachtungen zu machen?
Den Sensor selber verwende ich dafür eigentlich gar nicht.
Timings prüfe ich mittels Oszi und "DEBUG-GPIOs" in der ADC-timer ISR und der main loop (DEBUG_GPIO_ISR und DEBUG_GPIO_MAIN).
Zur Prüfung der Signalverarbeitung verwende ich einen Funktionsgenerator.
Ansonsten ist die erwähnte tropfende Dusche ganz praktisch. :)

Vor Kurzem habe ich das Ausgangssignal des Radarsensors während eines Regenschauers aufgezeichnet.
Evtl. wäre es nützlich daraus eine "Referenz" Audio Datei zu erstellen.

Zitat
Habe gerade die Version mit dem web frontend committed.
Vielen Dank!
Der Code hat ja ordentlich Zuwachs bekommen.
Freu mich aufs Ausprobieren.  ;)

Zitat
Schau mal, ob Du die Version bilden kannst und ob Sie bei Dir auch läuft.
Builden klappt schon mal.
Zum Prüfen der Timings und Simulation mit dem FG, werd ich morgen das Test-Setup im Garten abbauen und dann Berichten.

Hast du eigentlich schon einen Radarsensor am Laufen?

HCS

Zitat von: chunter1 am 22 Juli 2017, 00:57:33
Zum Prüfen der Timings und Simulation mit dem FG, werd ich morgen das Test-Setup im Garten abbauen und dann Berichten.
Ja, gib dann Bescheid.

Zitat von: chunter1 am 22 Juli 2017, 00:57:33
Hast du eigentlich schon einen Radarsensor am Laufen?
Ja, aber bisher nur hier im Zimmer um den Flugverkehr der Musca domestica zu überwachen.  ;D  ;D

chunter1

#134
Das Web-Frontend gefällt mir sehr gut und läuft bisher stabil.  :)
Bei den Timings gibts noch Probleme bei denen ich aber keinen show-stopper sehe.

Zitat
Ich habe es jetzt erst mal so gelöst, dass ich den Timer stoppe, wenn das Frontend die Settings speichert.
Ich messe eine Unterbrechung von ca. 1,25 ms.
Die 1-2 dadurch verlorenen snapshots sind egal.
Das Unterbrechen der Signalerfassung/-verarbeitung müssen wir allerdings kontrolliert durchführen.
Die Einführung einer Funktion stopCapture(), startCapture() (beide blocking) wäre wohl der einfachste Weg?
Ich werd das mal implementieren.

Zitat
Wenn das so weit passt, baue ich die "32 bins configuration" ein.
Ist perfekt!


Bzgl. Timing-Analyse:
Sobald das Web-Frontend Arbeit bekommt, kommt es in der main-loop zu teils unzulässig langen Delays (sollten <20ms sein).
Das führt dazu, dass Samples im Ringbuffer überschrieben und/oder falsch ausgewertet werden.
Folgende Lösungen fallen mir dazu ein:

A) Wie zuvor beschrieben ein kontrolliertes stoppen und starten der Signalerfassung/-analyse.

B) Ringbuffer auf maximal zu erwartende webfrontend Delay-Zeit vergrößern.
Sollten trotzdem "Überläufe" auftreten, wird dies erkannt und der Verlust von Snapshots in Kauf genommen.
Hauptsache es werden keine korrupten samples ausgewertet.

C) Signalverarbeitungsteile (processSamples(processSampleNr_tmp) und updateStatistics()) in eigene ISR auslagern.
Diese müsste dann aber vom ADC-interrupt jederzeit unterbrechbar sein.
Weiß aber nicht ob nested interrupts so einfach möglich sind bzw. wie?
Zusätzlicher Synchronisierungsaufwand der Daten.

Fällt dir noch eine bessere Lösung ein?
Andernfalls würde ich Variante B probieren.

Anzustreben wäre, dass der ADC-timer ununterbrochen läuft.
Alle weitern Delays in der "loop", sind dann via Buffer-Anpassungen in den Griff zu bekommen.