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

[chunter1]

@chunter1: mir wurde gerade klar, dass man ja nur einen Radarsensor in FHEM haben kann.
Soll ich, bis es die endgültige Kommunikation mit FHEM gibt, mal vorerst den Prefix des Dummy names auf der setup page konfigurierbar machen?
Also den fett markierten Teil:
publish_compact("PRECIPITATION_SENSOR");
publish_bins_count("PRECIPITATION_SENSOR_BINS_COUNT");

Default ist dann "PRECIPITATION_SENSOR"

Wenns schnell geht, ist das sicher nützlich.
Auch wenn ich hoffe, dass zukünftig ein Sensor ausreicht. 

[HCS]

Wenns schnell geht, ist das sicher nützlich.

Ich beeile mich ... 

Auch wenn ich hoffe, dass zukünftig ein Sensor ausreicht. 

Da kann man aber noch andere Geschwindigkeiten als Regen messen.
- Ob die Katze auf der Terrasse rumtiegert
- Wie schnell die Autos durch die Straße fahren
- Ob der Hof langsam oder schnell gefegt wird
- Eventuell bekomme ich damit einen Hoflicht-Sensor hin, der tatsächlich zwischen Baumen im Wind, Katzen und Menschen unterscheiden kann.


Jetzt zum Rohr:
Ich habe den Senor (mit etwas Heißkleber) auf einen Streifen Platine gesetzt. Auf die Platine die 5V Spannungsversorgung und den Bandpass gebaut.
Das würde natürlich kompakter gehen, aber ich wollte etwas Abstand zwischen das Radar und den ESP32 bekommen.
Das Ganze mit Heißkleber in den Deckel von einem 50er Rohr gesetzt (siehe Tube1.png). Den Deckel dann auf ein 50cm Rohrstück gesetzt, das Sensorende ist somit Wasserdicht (siehe Tube2.png). Das Ganze mal provisorisch unter das Dach der Terrasse gehängt (siehe Tube3.png). Der Ort ist natürlich nicht ideal, zu viel Publikumsverkehr und knapp in Reichweite Pflanzen, die sich im Wind bewegen können. Den endgültigen, schwerer zu erreichenden Aufstellungsort, wird er erst eines Tages kennen lernen. Wer den Sensor nicht findet, dem roten Pfeil folgen.

Da kein Regen in Aussicht war, habe ich das Rohr unter der Dusche erst mal simuliert (siehe Radar_Shower_Simulation.png).
Es hat drei mal in kurzen Anständen "geregnet". Die Lücke um 13:08 habe ich verursacht, als ich zwischen Sensor und Dusche geraten bin.

Nicht zu fassen, aber jetzt hoffe ich auf Regen, um echte Daten zu bekommen und zu sehen, ob diese Anordnung generell funktioniert.

[chunter1]

Bin schon gespannt auf deine ersten Messergebnisse.

Bzgl. Aufbau.
Welchen Rohrdurchmesser verwendest du?
Der Abstand zwischen Antenne und Kunststoffdeckel sollte 6 mm betragen (=Lambda/2).

Ich bin mitten im Testen verschiedener Algorithmen zur Auswertung.
Da gibts definitiv Optimierungspotential gegenüber der aktuellen Version.
Knackpunkt ist in jedem Fall den detection-threshold auf das Grundrauschen abzustimmen.
Ich fürchte nur, dass die Temperatur keine unwesentliche Rolle spielen wird - fragt sich nur ob es primär vom Sensor oder dem OPV kommt.

[HCS]

Bin schon gespannt auf deine ersten Messergebnisse.

Gibt leider nicht viel. Gestern Abend hat es mal kurz geregnet. Der Peak am Ende könnte die Katze gewesen sein, die kam kurz danach nass daher.

Ab 23:15 kamen keine Daten mehr, das WF war heute morgen auch nicht mehr erreichbar. Der ESP32 ist wohl stehen geblieben.
Das ist auch noch so ein unschönes Thema im ESP32 core. Wenn er abstürzt, dann schreibt er die exception auf serial raus und bleibt stehen, anders als der ESP8266, bei dem der Watchdog dann einen Reset ausgelöst hat. Da muss ich auch nochmal nachhaken ...

Zu blöd, die Chance auf Regen sinkt gerade stetig 
Und meine Frau glaubt inzwischen, dass ich nicht mehr alle Tassen im Schrank habe, weil ich ständig hoffe, dass es regnet 

Bzgl. Aufbau.
Welchen Rohrdurchmesser verwendest du?
Der Abstand zwischen Antenne und Kunststoffdeckel sollte 6 mm betragen (=Lambda/2).

Ein ganz normales HT-Rohr DN50.
Der Abstand dürfte aktuell ca. 5mm sein.

Ich fürchte nur, dass die Temperatur keine unwesentliche Rolle spielen wird - fragt sich nur ob es primär vom Sensor oder dem OPV kommt.

Ich könnte uns vom LGW noch einen der Temperatursensoren dran packen (BMP180 oder BME280 oder LM75) wenn Du eine Temperaturkompensation einbauen willst.

[chunter1]

Ab 23:15 kamen keine Daten mehr, das WF war heute morgen auch nicht mehr erreichbar. Der ESP32 ist wohl stehen geblieben.

Dass der ESP32 stehen geblieben ist, hatte ich bisher 3 mal aber nur innerhalb einer Stunde in der es intensiv geblitzt hatte - sonst noch nie.
Deshalb vermute ich, dass Störimpulse auf den langen Kabeln die Ursache bei mir waren?

Zu blöd, die Chance auf Regen sinkt gerade stetig 
Und meine Frau glaubt inzwischen, dass ich nicht mehr alle Tassen im Schrank habe, weil ich ständig hoffe, dass es regnet 

Du bist nicht alleine. 

Ein ganz normales HT-Rohr DN50.
Der Abstand dürfte aktuell ca. 5mm sein.

Ok, dann haben die nahe am Sensor herunterlaufenden/fallenden Tropfen einen stärkeren Einfluss als bei meinem DN70 Rohr.
Werd auch auf ein DN50 umsteigen.
Über den genauen Aufbau sollten wir uns dann mal abstimmen.

Ich könnte uns vom LGW noch einen der Temperatursensoren dran packen (BMP180 oder BME280 oder LM75) wenn Du eine Temperaturkompensation einbauen willst.

Wäre der DS18S20 auch möglich?
Den könnte man direkt an das Schirmblech des Radar-Sensors kleben.
Je besser sich das Rauschen eliminieren lässt, desto sensibler kann die Erkennung werden.

Anbei noch ein kurzes Update zur Detection.

Erster Screenshot:
Das obere Diagramm zeigt bis ca. 1h AM den Detektionsalgorithmus der aktuell im Code integriert ist - danach folgt der neue.
Das Diagramm darunter zeigt eine alternative Auswertung der durchschnittlichen bin-Magnitudes inkl. FOV-Korrekturfaktor.
Hier kann man schön das temperaturabhängige Rauschen beobachten.

Zweiter Screenshot:
Zeigt einen gezoomten Ausschnitt vom ersten Diagramm wo man die Details erkennen kann.

[chunter1]

Folgendes Diagramm solltet ihr euch für's Testen ebenfalls anlegen.
Dadurch hat man immer einen Überblick über die wichtigsten ADC-Parameter.
Also primär ob der ADC übersteuert wurde (clipping counter) und wie gut der ADC-Range bei Regen ausgenutzt wird.
Ebenfalls enthalten ist der Ringbuffer-Overflow Counter.

Wie schon mal erwähnt, können die ADCpeak Werte auch über 100% gehen.
Das ist so gewollt und tritt um so stärker auf, je größer der DC-Offset Fehler ist.

Code Auswählen Erweitern

# Created by FHEM/98_SVG.pm, 2017-07-24 14:54:58
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title 'ADC parameters'
set ytics
set y2tics
set grid y2tics
set ylabel ""
set y2label "peak [%]"
set yrange [-20:20]
set y2range [0:100]

#FileLog_PRECIPITATION_SENSOR 4:PRECIPITATION_SENSOR.ADCpeak\x3a::
#FileLog_PRECIPITATION_SENSOR 4:PRECIPITATION_SENSOR.ADCoffset\x3a::
#FileLog_PRECIPITATION_SENSOR 4:PRECIPITATION_SENSOR.ADCclipping\x3a::
#FileLog_PRECIPITATION_SENSOR 4:PRECIPITATION_SENSOR.RBoverflows\x3a::

plot "<IN>" using 1:2 axes x1y2 title 'ADCpeak' ls l1fill lw 0.5 with steps,\
     "<IN>" using 1:2 axes x1y1 title 'ADCoffset' ls l2 lw 2 with steps,\
     "<IN>" using 1:2 axes x1y2 title 'ADCclipping' ls l0 lw 2 with steps,\
     "<IN>" using 1:2 axes x1y2 title 'RBoverflows' ls l5 lw 2 with steps


[HCS]

Wäre der DS18S20 auch möglich?

Könnte es ein DS18B20 werden?
Der würde bei 9 Bit Auflösung (0.5°C sollten hier ja reichen) nur 94ms für eine Messung benötigen (statt 750ms beim S20)

[chunter1]

Könnte es ein DS18B20 werden?
Der würde bei 9 Bit Auflösung (0.5°C sollten hier ja reichen) nur 94ms für eine Messung benötigen (statt 750ms beim S20)

Den DS18S20 hätt ich halt schon da gehabt. 

[HCS]

Den DS18S20 hätt ich halt schon da gehabt. 

Zu blöd, vor mir mir hier liegt ein DS18B20. 
Er ist aber wirklich für diesen Fall besser geeignet.

Zitat Maxim:

Code Auswählen Erweitern

The DS18B20 differs from the DS18S20 in an important respect: the designer can select the desired resolution by using the configuration register.
This flexibility allows the user to reduce the ADC conversion time and conserve power if higher resolutions are not required.
Table 1 shows the temperature conversion time and LSB for each possible resolution setting.

Table 1. DS18B20 Conversion Times and Resolution Settings

Resolution            9 bit   10 bit 11 bit 12 bit
Conversion Time (ms)  93.75   187.5     375     750
LSB (°C)              0.5     0.25      0.125   0.0625

Und 9 bit würden uns reichen.

[chunter1]

Den DS18S20 hätt ich halt schon da gehabt. 

Grade sicherheitshalber nochmal kontrolliert, was Aliexpress mir tatsächlich geliefert hat...
Und es ist ein DS18B20!      (statt des bestellten DS18S20)
Ist das erste Mal, dass ich mich über eine abweichende Lieferung aus China freue.

[chunter1]

Momentan würd ich zum InnoSent IPM-170 mit einer selbst entwickelten Elektronik tendieren.
Der RSM-1700 (vom großen C oder V) scheint der gleiche zu sein.
Das abgebildete PCB ist zwar geringfügig anders, die Daten und das radiation-pattern jedoch ident.
Sogar das B+B Logo ist beim RSM-1700 abgebildet.
Werd mir einen RSM-1700 besorgen und anstelle des IPM-165 auf die Preamp Platine löten.

Der RSM-1700 ist soeben eingetroffen und es ist ein... IPM-170 von B+B.

[PeMue]

Hallo zusammen,

Ist das der gleiche Sensor, nur ohne Preamp?

Ich denke, man sollte sich auf einen bestimmten Sensor festlegen, ggf. in der Variante mit und ohne Preamp (den kann man ja recht einfach selbst machen).

mir scheint, dass der CDM324 und der IPM165=RSM-177 sehr ähnlich oder sogar gleich sind, siehe auch hier:

Code Auswählen Erweitern

This motion sensor can easily be purchased on eBay under the name CDM324. Oddly enough, looking for "cdm324" on your favorite search engine won't bring any interesting results.
I therefore spent several hours tracing the origins of this tiny sensor. I finally arrived to the conclusion that it likely is a clone of the InnoSenT IPM 165, which is itself very similar to the AP96 from Agilsense.
Da könnte man ja eine pream-Platine entwickeln (oder abkupfern) und mal mit beiden Sensoren probieren, wie sich diese so verhalten, oder?

Ist es richtig, dass der einzige Sensor mit pream der im ersten Post verlinkte ist?
Gruß PeMue

[chunter1]

Da könnte man ja eine pream-Platine entwickeln (oder abkupfern) und mal mit beiden Sensoren probieren, wie sich diese so verhalten, oder?

Ja, wobei ich derzeit den IPM-170 für die Rohr-Version wegen des symmetrischen und breiteren radiation-pattern bevorzuge.

Ist es richtig, dass der einzige Sensor mit pream der im ersten Post verlinkte ist?

Abgesehen von Bastelprojekten ist mir nur der bekannt.
Eine eigene, kompaktere Entwicklung mit bereits integrierter, an den ESP32 angepasster, bias-Spannung sowie steilerem Bandpass (als jetzt) wäre mein Wunsch.

[PeMue]

Eine eigene, kompaktere Entwicklung mit bereits integrierter, an den ESP32 angepasster, bias-Spannung sowie steilerem Bandpass (als jetzt) wäre mein Wunsch.

Huch, das ist ja dann Analogtechnik pur  Kann das noch jemand? 

Gruß PeMue

[HCS]

Und es ist ein DS18B20!      (statt des bestellten DS18S20)
Ist das erste Mal, dass ich mich über eine abweichende Lieferung aus China freue.

Dann ist der DS18B20 gesetzt?

Eine eigene, kompaktere Entwicklung mit bereits integrierter, an den ESP32 angepasster, bias-Spannung sowie steilerem Bandpass (als jetzt) wäre mein Wunsch.

Ja, sinnvoll, incl. einer sauberen 5V Spannungsaufbereitung für das Radar und evtl. sogar einem Hardware-Watchdog auf NE7555 Basis. Ports haben wir ja mehr als genug auf dem ESP32.

Huch, das ist ja dann Analogtechnik pur  Kann das noch jemand? 

ja, klar. Ist wie Digital, nur mit weiteren Werten dazwischen 

Ach ja, zu meinen Crashes: nachdem er heute Morgen wieder stehen geblieben ist, habe ich das Rohr reingeholt und an den Rechner gehängt, dass ich die Exception sehe. Rate mal - er läuft immer noch. Aber jetzt habe ich einen Verdacht. Das USB-Steckernetzteil, das ich draußen verwendet habe, hatte ich vorher für einen ESP32 verwendet, auf dem ein LGW-Prototyp lief. Und der ist auch ab und zu völlig ohne geistreichen Grund stehen geblieben. Es wird doch nicht mal wieder die Spannungsversorgung sein ...