Autor Thema: Radar basierter WiFi-Niederschlagssensor für Regen, Hagel und Schnee  (Gelesen 90935 mal)

Offline chunter1

  • Sr. Member
  • ****
  • Beiträge: 806
@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.  ;)

Offline HCS

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3040
Wenns schnell geht, ist das sicher nützlich.
Ich beeile mich ...  ;D ;D

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.
« Letzte Änderung: 27 Juli 2017, 19:53:56 von HCS »

Offline chunter1

  • Sr. Member
  • ****
  • Beiträge: 806
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.
« Letzte Änderung: 28 Juli 2017, 01:24:31 von chunter1 »

Offline HCS

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3040
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  ;D

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.


Offline chunter1

  • Sr. Member
  • ****
  • Beiträge: 806
Zitat
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?

Zitat
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  ;D
Du bist nicht alleine.  ;)

Zitat
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.

Zitat
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.
« Letzte Änderung: 28 Juli 2017, 09:21:13 von chunter1 »

Offline chunter1

  • Sr. Member
  • ****
  • Beiträge: 806
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.

# 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
« Letzte Änderung: 28 Juli 2017, 10:23:59 von chunter1 »

Offline HCS

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3040
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)

Offline chunter1

  • Sr. Member
  • ****
  • Beiträge: 806
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.  :)

Offline HCS

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3040
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:
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.

Offline chunter1

  • Sr. Member
  • ****
  • Beiträge: 806
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.
« Letzte Änderung: 28 Juli 2017, 13:17:31 von chunter1 »

Offline chunter1

  • Sr. Member
  • ****
  • Beiträge: 806
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. :)

Offline PeMue

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4896
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:
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
1x FB7170 (29.04.88) 5.7 1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F)
1x RPi BV2LCDCSM 1.63 5.7 2xMAX HKT, 1xMAX RT, V200KW1
1xFB 7490 (113.06.05) 5.7 1xCUL V3 1.63 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 1xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU 1xRFXtrx 90 1xWT440H 1xCM160 3xTFA30.3150 5xFA21

Offline chunter1

  • Sr. Member
  • ****
  • Beiträge: 806
Zitat
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.
« Letzte Änderung: 28 Juli 2017, 15:05:24 von chunter1 »

Offline PeMue

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4896
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?  ;D ;D ;D

Gruß PeMue
1x FB7170 (29.04.88) 5.7 1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F)
1x RPi BV2LCDCSM 1.63 5.7 2xMAX HKT, 1xMAX RT, V200KW1
1xFB 7490 (113.06.05) 5.7 1xCUL V3 1.63 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 1xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU 1xRFXtrx 90 1xWT440H 1xCM160 3xTFA30.3150 5xFA21

Offline HCS

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3040
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?  ;D ;D ;D
ja, klar. Ist wie Digital, nur mit weiteren Werten dazwischen  ;D ;D ;D

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 ...