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

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

Vorheriges Thema - Nächstes Thema

chunter1

Zitat von: networker am 23 September 2017, 00:01:24
Nein, nach oben
Ok, aber wie löst du das Schnee-Problem und die direkt vor dem Sensor von der Kugel abprallenden Tropfen?

sbiermann

Zitat von: PeMue am 22 September 2017, 22:02:27
Bei ein paar (<= 5) kann man darüber reden. Für mehr fehlt mir schlichtweg die Zeit.

Wenn ich das richtig gesehen habe gab es bisher außer meinen Wunsch nur noch einen nach der Platine. Vielleicht gibt es ja noch mehr Leute die Kapazitäten und die notwendige Ausrüstung haben um SMD zu löten. Oder direkt in China komplett produzieren lassen? Da weiß ich allerdings nicht wie klein eine Serie sein kann damit es sich noch lohnt vom Preis her.

PeMue

Zitat von: sbiermann am 23 September 2017, 08:19:50
Vielleicht gibt es ja noch mehr Leute die Kapazitäten und die notwendige Ausrüstung haben um SMD zu löten.
Vermutlich gibt es die. Aber auch hier könnte die notwendige Zeit den limitierenden Faktor darstellen  ;D

Zitat von: sbiermann am 23 September 2017, 08:19:50
Oder direkt in China komplett produzieren lassen?
Macht keinen Sinn bei einer Prototypenplatine. Wenn dann mal klar ist, dass sie funktioniert könnte man das mal andenken. Aber ich glaube, das ist dann so teuer, dass keiner mehr will. Es braucht ja auch die notwendige Dokumentation  ;)

Gruß PeMue
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

PeMue

Hallo zusammen,

ich habe hier die prel3 der Platine angehängt, bitte schaut mal drüber, ob man die jetzt so lassen kann.
Auf Wunsch eines einzelnen Herrn wurde noch ein Spannungsregler integriert, jetzt ist die Platine halt 28x41 mm (vorher 28x36 mm) groß, aber die Löterei wird deshalb nicht einfacher  8) 8) 8)

Danke + Gruß

PeMue
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

chunter1

Ouch!
Mach blos den Regler wieder runter - will nicht Schuld an einem verstopften Rohr sein. ;)

Ich würde sagen, das Layout ist perfekt.

HCS

Zitat von: PeMue am 23 September 2017, 22:04:51
bitte schaut mal drüber, ob man die jetzt so lassen kann.
Geschaut. Sieht gut aus.

Zitat von: chunter1 am 23 September 2017, 22:23:50
Mach blos den Regler wieder runter - will nicht Schuld an einem verstopften Rohr sein. ;)
Sie muss ja aufgrund der Anschlüsse eh rechtwinklig hinter das Radar, oder sehe ich das falsch?
Dann wäre die Länge eher nicht relevant.

chunter1

Zitat von: HCS am 23 September 2017, 23:24:57
Sie muss ja aufgrund der Anschlüsse eh rechtwinklig hinter das Radar, oder sehe ich das falsch?
Dann wäre die Länge eher nicht relevant.
Yup.
War ja nicht ernst gemeint. ;)

chunter1

#532
Software Version 0.12.0 steht jetzt auf Github zur Verfügung.

Die wichtigsten Änderungen sind:
-) FFT size von 512 auf 1024 verdoppelt
-) x2 Oversampling eingeführt
-) Die Nummer der dominanten Gruppe sowie deren Wert als eigenes Reading

Der Threshold hat momentan keine Funktion.

Zu den Readings:
GroupMagAVGkorrDom ... "MagAVGkorr" Werte der 32 Gruppen - jedoch werden alle, bis auf die dominante Gruppe, ausmaskiert (auf 0 gesetzt).
DominantGroup ... Nummer der dominanten Gruppe
Debug0 ... Enthält die bin-magnitudes der ersten 32 bins (also DC, 20Hz, 40Hz,... 620Hz). Ist nur temporär zum Testen gedacht.

Debug0 soll die Abschätzung der 50Hz Brumm-Störungen ermöglichen.
Wenn euer Debug0 Reading z.B. sowas anzeigt "1 7 14 15 4 1 0 1 1 0..." dann habt ihr ein relativ starkes 50Hz Störsignal.

Anbei noch ein Beispiel eines GroupMagAVGkorrDom Diagramms.

Damit sich die Readings und die SVG Diagramme zukünftig nicht mehr so oft ändern, werd ich mir wohl mal Gedanken über eine universelle Namensgebung machen müssen. :)

PeMue

Hallo zusammen,

ich werde auf die Platine eine USB-micro-B Buchse machen (oberhalb des Pfostensteckers).
Dann kann man auch folgende Konfiguration nutzen:
- USB Netzteil an Vorverstärker
- vom Vorverstärker geht OUT, GND und 5 V zur Spannungsversorgung an den ESP32 (ggf. mit einem abgeschnittenen USB Kabel
M.E. hat das den Vorteil, dass der Vorverstärker eine (hoffentlich) vernünftig geblockte Spannungsversorgung bekommt und danach erst der ESP kommt. Diese Konfiguration berücksichtigt vermutlich auch Softwarentwickler, die den Radarsensor am Schreibtisch betreiben  :-\ :-\ :-\

Spricht aus Eurer Sicht was dagegen? Ich habe leider auf einer der anderen Platinen noch einen Fehler/Ungereimtheit gefunden, die ich gerne noch fixen würde. D.h. ich werde heute leider nicht mehr bestellen  ???

Gruß PeMue
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

HCS

Zitat von: PeMue am 24 September 2017, 18:16:58
Diese Konfiguration berücksichtigt vermutlich auch Softwarentwickler, die den Radarsensor am Schreibtisch betreiben
Man kann ja dann die Rauschwerte vergleichen (Doppelspeisung / 5V ), ob das eine Option ist.
Bin schon echt gespannt auf die Rauschwerte der Platine.

Zum Thema Softwareentwickler: wollen wir nun eine Temperatur haben, auch wenn sie nicht für die Kalibrierung erforderlich ist?
Falls ja, würde ich das Thema nochmal angehen, also den DS18B20.
Oder alternativ einen BME280, dann hätte man Niederschlag, Temperatur, Feuchte und Druck zentral von einem Ort.
Optional mit AutoSense natürlich.

networker

#535
Ich bin für eine Temperatur, auch wenn sie nicht für die Kalibrierung erforderlich sein sollte.
::)

Zitat von: chunter1 am 24 September 2017, 14:05:58
-) Die Nummer der dominanten Gruppe sowie deren Wert als eigenes Reading

Kannst du das mit der dominanten Gruppe näher erklären, wie wird die bestimmt und was wird, oder soll sie aussagen?

chunter1

#536
Zitat von: HCS am 24 September 2017, 21:52:29
Zum Thema Softwareentwickler: wollen wir nun eine Temperatur haben, auch wenn sie nicht für die Kalibrierung erforderlich ist?
Falls ja, würde ich das Thema nochmal angehen, also den DS18B20.
Oder alternativ einen BME280, dann hätte man Niederschlag, Temperatur, Feuchte und Druck zentral von einem Ort.
Optional mit AutoSense natürlich.
Hmmm...
Also nachdem mit dem DS18B20 keine kontinuierliche Radar-Messung möglich ist und der BME280 einen deutlichen Mehrwert bringt, würde ich wenn dann zum BME280 tendieren.

Wobei mich ja das Thema Ultraschall Windrichtungsmessung auch stark reizen würde. :)
Da hält mich nur das notwendige Heizen davon ab.

Zitat von: networker am 24 September 2017, 23:24:19
Kannst du das mit der dominanten Gruppe näher erklären, wie wird die bestimmt und was wird, oder soll sie aussagen?
Momentan ist die dominante Gruppe einfach jene mit dem höchsten magAVGkorr Wert.
Genau genommen steigt der Messfehler mit dem Abstand zum Rohr deutlich an, sodass die tatsächliche Maximalgeschwindigkeit immer etwas darüber liegt.
Siehe Diagramm in folgendem Post:
https://forum.fhem.de/index.php/topic,73016.msg680169.html#msg680169

Im kurz zuvor geposteten Diagramm zur dominanten Gruppe sieht man, dass es "mengenmäßig" um 8:26 und 9:02 zwar ähnlich "viel" geregnet hat, die Tropfengeschwindigkeit/Intensität jedoch unterschiedlich war.
Um zu testen, ob mit dem Radar auch eine Regenmengenbestimmung möglich ist, reicht es demnach nicht einfach nur die magAVGkorr Werte zu akkumulieren.
Die reine Akkumulation hatte je nach Regen-Intensitätsschwankungen mal mehr oder weniger gepasst.
Es muss also zuerst aus der Trofpengeschwindigkeit das Tropfenvolumen abgeleitet und mit berücksichtigt werden.

Kurz gesagt kann man aus den Werten des magAVGkorrDom Reading zum einen die "Intensität" und "Menge" recht schnell erfassen, zum anderen soll es als Basis für die Abschätzung einer möglichen Regenmengenbestimmung dienen.

HCS

Zitat von: chunter1 am 25 September 2017, 09:43:27
Hmmm...
Also nachdem mit dem DS18B20 keine kontinuierliche Radar-Messung möglich ist und der BME280 einen deutlichen Mehrwert bringt, würde ich wenn dann zum BME280 tendieren.
Ich auch, wobei ich erst mal ausloten muss, ob die I2C Kommunikation mit einem BME280 auch von der Timer-ISR verhagelt wird.
Mit dem DS18B20 hatte ich vor einiger Zeit ein wenig experimentiert (ohne den Timer zu stoppen). Da scheitern ca. 10% der Messungen, halt immer dann, wenn die ISR zufällig an einer timingkritischen Stelle reingegrätscht hat, was man aber merkt und die Messung verwerfen könnte. Eine Minute später ist es ja auch nicht viel wärmer oder kälter.
Ich schaue mal, wie gut oder schlecht das mit einem BME280 gehen würde, dann können wir überlegen, was wir wollen.
Klar ist: die ISR muss durchlaufen.

chunter1

Zitat von: HCS am 25 September 2017, 10:16:27
Ich auch, wobei ich erst mal ausloten muss, ob die I2C Kommunikation mit einem BME280 auch von der Timer-ISR verhagelt wird.
Kommt noch dazu, dass ich in der aktuellen Version 0.12.0 die sampling-rate um den Faktor 4 erhöht und damit voll ausgereizt hab. ;)

HCS

Zitat von: chunter1 am 25 September 2017, 10:33:00
Kommt noch dazu, dass ich in der aktuellen Version 0.12.0 die sampling-rate um den Faktor 4 erhöht und damit voll ausgereizt hab. ;)
Ja, eben, ...  :(