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: AxelSchweiss am 04 Juli 2017, 14:58:45
Wie wäre es dann mit dem Nachfolger zum ESP8266 ... dem ESP32. ... der soll ja mehr Bums haben.

Ohh jaaa das hat er!
Bin soeben beim Performance testen der zeitkritischen Teile.
Mit dem ESP32 ist es kein Problem ununterbrochen zu samplen und parallel die Signalverarbeitung zu erledigen (Stichwort STFT).
Und als Sahnehäubchen läuft der Wifi-Part (FHEM Transfer) einfach so unterbrechungsfrei auf dem zweiten Core dahin.
Kein einziger Ping geht verloren oder ist delayed.
Das mach Lust auf mehr :)
Bis es allerdings auf dem ESP32 mit der verbesserten Signalverarbeitung sauber läuft, wird noch einige Zeit vergehen.


EDIT:
Der ADC ist allerdings grausam!
Rauschen und Nichtlinearität zeigen sich deutlich im Spektrum :(
Ist zwar noch kein absoluter show-stopper aber sehr schade.

chunter1

Wie angekündigt, anbei die Abmessungen meines Testaufbaus.
Das rote Quadrat markiert die Position des Radar-Sensors.
Ein höherer Mast und damit freiere Sicht sind von Vorteil (außer man ist an der Katzen-, Marder-, Insekten- und Fußball-Geschwindigkeit interessiert ;) ).

AxelSchweiss

Vorschlag zum Gehäuse:
Als Abtropfkante auf die Unterseite vom Blechdach in einem Halbrund eine Raupe aus Silikon auftragen.
So circa 5 mm von der Blechkante entfernt und bis zum Knick vom Blech.
Dann läuft das Wasser bis zum Silikon und wird ab dort dann nach unten geführt.
Damit schützen sie in Australien sehr wirksam die ganzen Felsenmalereien der Natives.

Sobald ich ein Blatt Papier in Reichweite habe male ich mal ein Bildchen.

Edit: Ich sehe gerade die Abmasse in deiner Zeichnung ....
Wichtig ist das die Silikonraupe nicht direkt an der Blechkante endet sondern dort eine Rinne bildet.

chunter1

Zur Info...
Portierung des bestehenden Codes und Umsetzung der kontinuierlichen Signalverarbeitung auf dem ESP32 schreiten schneller voran als gedacht.
Da der ESP32 langfristig die bessere Wahl ist, geht die Entwicklung in diese Richtung weiter.
Tests und Erweiterungen könnt ihr aber ohne weiteres auf dem bestehenden ESP8266-code machen.
Die Publish Funktionen werden auf dem ESP32 ident bleiben.

Wer also weiterhin mitmachen will, der möge sich einen ESP32 besorgen :)

Mein ESP32 dev.board hatte ich übrigens damals hier bestellt:
https://de.aliexpress.com/item/Official-DOIT-ESP32-Development-Board-WiFi-Bluetooth-Ultra-Low-Power-Consumption-Dual-Core-ESP-32-ESP/32799954012.html



sbiermann

Ich habe mir das Board von Wemos bestellt. Die Wemos D1 Teile sind Klasse, daher probiere ich mit dem ESP32 von Wemos ob die ebenfalls so gut sind. Im offiziellen Wemos Aliexpress Store: https://de.aliexpress.com/item/WEMOS-LOLIN32-V1-0-0-wifi-bluetooth-board-based-ESP-32-4MB-FLASH/32808551116.html

Per


chunter1

Zitat von: Per am 06 Juli 2017, 16:21:43
Warum zwei?
Der eine erzeugt die 5V Spannung für den Wemos D1 mini (wollte den LDO und die möglicherweise auf 5V dimensionierten Kondensatoren nicht überstrapazieren).
Den anderen hab ich direkt beim Sensor platziert, damit ich nicht mit 5V über das Kabel fahren muss und Störungen nicht direkt auf den Sensor einwirken.

chunter1

Hat zufällig wer von euch einen IPM-165 (inkl. preamp) und ein Oszi?
Da mein Oszi immer noch im Service ist, wäre ich dankbar, wenn jemand die Ruhespannung sowie das untere und obere Ausgangsspannungslimit messen könnte.
Bräuchte die Werte um den ESP32 ADC code zu optimieren.


Tobias

ich bin hieran auch stark interessiert. Ich muss früh informiert werden wenn die ersten Tropfen fallen um meine Dachfester zu schließen. Mein aktueller Kemo Sensor meldet sich erst wenn es von oben bereits schüttet :(
Sobald der erste Sketch funktioniert und mein ESP32 angekommen ist, teste ich auch mit :)
Maintainer: Text2Speech, TrashCal, MediaList

Meine Projekte: https://github.com/tobiasfaust
* PumpControl v2: allround Bewässerungssteuerung mit ESP und FHEM
* Ein Modbus RS485 zu MQTT Gateway für SolarWechselrichter

HCS

Zitat von: chunter1 am 05 Juli 2017, 21:42:26
Der ADC ist allerdings grausam!
Rauschen und Nichtlinearität zeigen sich deutlich im Spektrum :(
Ist zwar noch kein absoluter show-stopper aber sehr schade.

Ja, das ist übel, da bin ich auch schon beim LGW ins rudern geraten und Espressif hat es immer noch nicht gerichtet:
https://github.com/espressif/arduino-esp32/issues/92#issuecomment-266648072
https://github.com/espressif/esp-idf/issues/164
aber es besteht Hoffnung auf Besserung.

Der ESP32 ist aber auf alle Fälle eine gute Entscheidung.

Wenn Du interessiert bist, könnte ich das WebFrontend vom LaCrosseGateway beisteuern, für die IP-Konfiguration, Settings usw., natürlich angepasst.
Wenn Du es nicht kennst, kann ich noch Screenshots anhängen, dass Du siehst, was ich meine.

Allerdings müsste das git dann erst mal auf die neue ESP32-Variante.

chunter1

#101
Zitat von: HCS am 10 Juli 2017, 19:21:27
Wenn Du interessiert bist, könnte ich das WebFrontend vom LaCrosseGateway beisteuern, für die IP-Konfiguration, Settings usw., natürlich angepasst.
Wenn Du es nicht kennst, kann ich noch Screenshots anhängen, dass Du siehst, was ich meine.

Vielen Dank, die Hilfe nehm ich gerne an. ;)
Hab ein LaCrosseGateway am laufen und kenne somit das WebFrontend.
Was die Kommunikation zwischen ESP32 und FHEM betrifft, würde der Projektfortschritt definitiv von einem Insider profitieren.

chunter1

#102
Eine erste ESP32 basierte "Developer"-Version ist jetzt auf GitHub verfügbar.
https://github.com/chunter1/precipitationSensorESP32

Vorerst ist nur DHCP möglich.
Wie gehabt, in der precipitationSensorESP32.ino folgendes an euer Netzwerk anpassen:
-) SSID
-) Wifi-Password
-) FHEM server IP
-) FHEM server Port

In FHEM einen dummy namens "PRECIPITATION_SENSOR" anlegen.

Folgende Daten werden jede Minute übertragen:
-) ADCclipping ... Anzahl der ADC clipping events
-) ADCoffset ... Offset von der idealen ADC-Bereich Mitte (= 2048) bzw. DC-Bias Spannung (= ca. 0.97V).
-) ADCpeak ... Peak Wert des ADC (0...2048)
-) detections ... Anzahl aller FFT-bin Threshold-Überschreitungen
-) detectionsInGroup ... Anzahl der FFT-bin Threshold-Überschreitungen je Gruppe (32 Gruppen)
-) peakInGroup ... Peak-Wert des höchsten FFT-bins innerhalb der Gruppe (32 Gruppen)
-) snapshots ... Anzahl der FFT-snapshots (50ms Messintervalle) die analysiert wurden.
-) state .... Gleiche wie "detections". Anzahl aller FFT-bin Threshold-Überschreitungen

Der Threshold des FFT-bin peaks für die Zählung ist auf 90 eingestellt und kann im Code natürlich angepasst werden:

#define DETECTION_THRESHOLD 90


Für die Zuordnung der Gruppen zu den Geschwindigkeitsbereichen siehe Post #83.

HCS


chunter1

#104
Die Beschaltung meines Testaufbaus sieht so aus.
Ist ein sehr rudimentärer Bandpass mit Bias Spannungsteiler.
Auf der ESP32 Seite führt das Signal auf GPIO_34 (ADC1_CH6).

EDIT:
Die 20k erhaltet ihr durch Serienschaltung von zwei 10k Widerständen ;)
Wenn ihr für den 1uF Kondensator einen gepolten Typen verwendet, dann muss der Minuspol Richtung ESP32 zeigen.
Standard Bauteiltoleranzen sind ausreichend.