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

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

Vorheriges Thema - Nächstes Thema

HCS

Zitat von: chunter1 am 31 August 2017, 12:33:00
Was man auch schön sieht ist, dass die Sonne ab ca. 9:50 voll auf das Rohr brennt.
Genau dafür, um vergleichbare Ergebnisse zu haben, wäre eine einheitlich gemessene Innentemperatur nicht schlecht.

Da ist meine Positionierung gar nicht so schlecht. Es regnet und schneit nicht drauf und die Sonne brennt nicht direkt drauf.
Könnte nur sein, dass ich zu weit vom Geschehen entfernt bin. Muss drauf warten, dass es leicht nieselt und ich daheim bin und es auch noch merke.

networker

Sollten wir auch den Sensor auf relatv konstanter Teperatur halten wollen, sollten wir einen kompakteren Aufbau überlegen?

chunter1

#422
Zitat von: HCS am 31 August 2017, 12:41:38
Genau dafür, um vergleichbare Ergebnisse zu haben, wäre eine einheitlich gemessene Innentemperatur nicht schlecht.
Ja, hast Recht.

Zitat
Da ist meine Positionierung gar nicht so schlecht. Es regnet und schneit nicht drauf und die Sonne brennt nicht direkt drauf.
Optisch/WAF ist sie perfekt.  ;)
Einer der Gründe, warum ich davon weggegangen bin ist, dass bei ungünstigem Regen-Winkel der Messwert viel schneller gegen "0 km/h" tendieren, als bei einem senkrecht nach oben schauenden.

Zitat von: networker am 31 August 2017, 12:42:07
Sollten wir auch den Sensor auf relatv konstanter Teperatur halten wollen, sollten wir einen kompakteren Aufbau überlegen?
Da bin ich voll bei dir, aber wollen wir wirklich heizen? :)
Wir müssten dann ständig so stark heizen, dass der Sensor bei maximaler Sonneneinstrahlung und Umgebungstemperatur verlässlich über der unbeheizten Temperatur liegt (max. 60°C ist für den IPM-170 spezifiziert).

HCS


networker

mit einem Peltier-Element auf der Unterseite des Sensors musst du die Temperatur gar nicht so hoch heizen, da du im Bedarfsfall auch Kühlen könntest und dabei auch mit 30 - 40 ° durchkommen könntest.

Per

Zitat von: chunter1 am 31 August 2017, 12:56:05dass der Sensor bei maximaler Sonneneinstrahlung und Umgebungstemperatur verlässlich über der unbeheizten Temperatur liegt
Wie hoch ist denn die Abweichung zwischen z.B. 30°C und 60°C? Vllt. reicht es ja, sich oberhalb eines Grenzwertes aufzuhalten und den Rest über die Temperaturmessung zu kompensieren.

chunter1

#426
Ich stell mal testweise meine Gruppen so um, dass sie jenen von Lufft entsprechen.
Also:


1-5       "Schnee"
6-9
10-12
13-14
15-17
18-19
20-22
23-24
25-27
28-29
30-32
33-34
35-37
38-39
40-42
43-44
45-47
48-49
50-52
53-54
55-57
58-59
60-62
63-79
80-255   "Apokalypse"


Allerdings gefällt mir nicht, dass immer abwechselnd 2 bzw. 3 Bins zusammengefasst werden.
Mal schaun ob das nicht unschöne Effekte hat.

EDIT:
Ändert eure Groups aber nur, wenn ihr auf die korrekte Funktion der "magAVGkorrThresh" Werte verzichten könnt.
Die Thresholds sind nämlich auf die aktuellen Group-Settings abgestimmt und müssten erst angepasst werden.
Das Kalibrierungsfeature zum Anpassen der Threshold-Werte kommt dann sobald wir das mit dem Schreiben der 32 thresholds ins NVS hinbekommen haben.

HCS

Zitat von: chunter1 am 31 August 2017, 14:50:48
Das Kalibrierungsfeature zum Anpassen der Threshold-Werte kommt dann sobald wir das mit dem Schreiben der 32 thresholds ins NVS hinbekommen haben.
Kann nicht mehr lange dauern ...

Zitat von: chunter1 am 31 August 2017, 12:56:05
Optisch/WAF ist sie perfekt.  ;)
Die Positionierung vom Rohr war gemeint.
Aber leider messtechnisch weniger gut. Ist momentan eigentlich nur testweise an dieser Stelle, weil es da eine Steckdose hat und ich bequem hinlaufen kann.
Nachteil: Die Pflanzen in ca. 1m Entfernung. OK, Frau und Katze, die manchmal dran vorbeilaufen, sind auch nicht ideal  :)

Interessant: Wenn Wind aufkommt, "sieht" das Radar die Bewegung der Pflanzen.
Wobei das Rauschen der Blätter im Wind scheinbar sehr hohe Frequenzen erzeugt, da G31 heftig reagiert.
Man braucht also reichlich freie Sicht vor und neben dem Radar.

networker

#428
 ;D auch die richtige Positionierung des Rohres bei der Steckdose ist für einen hohen WAF unerlässlich. ;D

In einem Doc. von LUFFT hab ich glaub ich einen Abstand zu Objekten von 10 Metern gesehen.

chunter1

#429
Zitat von: HCS am 01 September 2017, 08:15:13
Wobei das Rauschen der Blätter im Wind scheinbar sehr hohe Frequenzen erzeugt, da G31 heftig reagiert.
Zur Bewertung von störenden Bewegungen nehmt bitte die "magAVG" Grafik.
Diese zeigt das tatsächliche/unkorrigierte Frequenzspektrum bzw. die tatsächlichen AVG bin-"Amplituden" an.
Die "magAVGkorr" ist die um die Flugzeit durch das FOV korrigierte "magAVG" und somit nicht geeignet.
So wird z.B. beim magAVGkorr der bin1 (20Hz) durch 322.67 geteilt wo hingegen bin255 (5100Hz) nur durch 1.27 geteilt wird.

Bei meinen Tests mit "reinem" Sinus aus einem FG hat sich gezeigt, dass bestimmte bins gerne öfter mal in Erscheinung treten (nicht die Oberwellen bins).
Woran das genau liegt, kann ich nicht sagen.
Dein G31 Rauschen sieht aber ganz danach aus.

Zitat von: networker am 01 September 2017, 08:17:40
;D auch die richtige Positionierung des Rohres bei der Steckdose ist für einen hohen WAF unerlässlich. ;D
In einem Doc. von LUFFT hab ich glaub ich einen Abstand zu Objekten von 10 Metern gesehen.
Der war gut.  :)
Abstand 10m seitlich und 5m über Boden.
Grafik im Manual auf Seite 5:
https://www.lufft.com/download/manual-lufft-r2s-umb-en/

HCS

Zitat von: chunter1 am 01 September 2017, 09:49:43
Zur Bewertung von störenden Bewegungen nehmt bitte die "magAVG" Grafik.
Diese zeigt das tatsächliche/unkorrigierte Frequenzspektrum bzw. die tatsächlichen AVG bin-"Amplituden" an.
Die "magAVGkorr" ist die um die Flugzeit durch das FOV korrigierte "magAVG" und somit nicht geeignet.
So wird z.B. beim magAVGkorr der bin1 (20Hz) durch 322.67 geteilt wo hingegen bin255 (5100Hz) nur durch 1.27 geteilt wird.
Jetzt habe auch ich das endlich verstanden  :)
Anbei mit MagAVG für den Zeitraum.
Da sehen wir nun wohl in G0 meinen 50Hz-Brumm und dann den Wind kommen.

Ist eigentlich auch ein guter Wind-Sensor. Muss mal testen, mit welcher Sorte Pflanze man optimale Ergebnisse bekommt.  8) ;D ;D

chunter1

Funktioniert bei euch eigentlich das OTA aus der Arduino IDE heraus auch in gefühlten 90% der Fälle nicht?

networker

#432
Habe damit nach dem letzten ESPRESSIF update keine Probleme mehr.

HCS

Zitat von: chunter1 am 01 September 2017, 19:42:07
Funktioniert bei euch eigentlich das OTA aus der Arduino IDE heraus auch in gefühlten 90% der Fälle nicht?
Habe gerade beide Varianten jeweils drei mal hintereinander probiert. Hat immer geklappt und es ist jedes mal die neue Version angesprungen.

HCS

Settings::SaveCalibration / Settings::LoadCalibration ist eingecheckt.
Die Stellen, an die Du ran musst, findest Du mit einer Suche nach: "// TODO: chunter1 calibration"

Allerdings setzt die statistics.Calibrate() alle [binGroupNr].threshold auf 0. Ich vermute mal, dass die calibration nicht zu einem beliebigen Zeitpunkt laufen darf, oder vorher ein Finalize oder so was gemacht werden müsste.
Da musst Du jetzt ran.
Die LoadCalibration setzt aktuell die [binGroupNr].threshold auf 1.0, wenn im NVS nichts dafür vorliegt. Das muss evtl. auch noch angepasst werden.