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

[chunter1]

Ist damt der Detection threshold gemeint?

Ja, genau.
In deinem untersten Diagramm sieht man auch schön das Limit der aktuellen 4 Nachkommastellen (die Stufen).
Anbei mein aktueller Regen mit magAVGkorrThresh auf 8 Nachkommastellen erhöht.

Ergänzung:
magAVGkorrThresh ist übrigens nichts anderes als magAVGkorr über den Detection threshold "gethresholded", abzüglich dem Detection threshold selbst.
magAVGkorrThresh habe ich eingeführt, um mit der Regenmenge zu experimentieren.
Dafür darf natürlich bei fehlendem Regen das Rauschen keinen Regen "zählen".
Das ist aber noch im frühen, experimentellen Stadion.

Nächster Schritt ist eher eine automatische Threshold level calibration einzuführen, die sich auf jedes System anpasst ohne dass man den Threshold selber "suchen" muss.
Voraussetzung dafür ist allerdings, dass die Temperaturabhängigkeit des Preamp-Rauschens möglichst gering ist.

[HCS]

Ich habe mal zum Testen den DataPort eingebaut.
Die Firmware stellt nun, wenn man es auf der Setup-Page eingeschaltet hat, den TCP Port 81 bereit, auf dem sie, falls ein FHEM drauf verbunden ist, die Daten (aktuell den "compact" Umfang) ausliefert und Kommandos entgegen nimmt.
Die Übermittlung der Daten ist schon deutlich schneller, die "http post" Variante benötigt für die Daten ca 6ms, über den DataPort ist es in ca. 1ms durch, ist auch klar, der Verbindungsauf- und Abbau bei jeder Übermittlung entfällt und es sind weniger bytes, da das ganze "setreading Gedöns drum rum nicht gebraucht wird."
Das Ganze läuft auch parallel zur bisherigen post-Variante, man kann also z.B. ein Produktiv-FHEM auf den DataPort setzen und den Rest für Testzwecke an ein Test-FHEM posten.
Es dürfen sich auch mehrere FHEM auf den DataPort verbinden.

Das Gegegstück auf FHEM-Seite gibt es hier: https://github.com/chunter1/precipitationSensorESP32/blob/master/FHEM/36_PrecipitationSensor.pm
Beispielkonfiguration:

Code: [Auswählen]

define Radar208 PrecipitationSensor 192.168.31.208:81
attr Radar208 disable 0
attr Radar208 stateFormat {ReadingsVal("Radar208", "state", "") . " UpTime: " . InternalVal("Radar208", "UPTIME", "?"). " detections: " . ReadingsVal("Radar208", "detections", "?");;}
attr Radar208 timeout 30
Die Kommunikation ist ähnlich ist beim KeyValueProtocol-Modul

Das Attribut timeout legt fest, in welchem Intervall geprüft wird, ob die Firmware noch antwortet und ggf. die TCP-Verbindung neu aufgebaut wird (nach reboot, "WiFi weg", ...)
Mit dem Attribut disable kann man es vorübergehend stilllegen (also jeglichen Verbindungsaufba unterdrücken)

Set Befehle:

set Radar208 connect
baut die TCP-Verbindung (neu) auf

set Radar208 flash
lädt die Firmware hoch. Dazu muss auf dem ESP32 mindestens schon V9.0 drauf sein und die precipitationSensor32.bin in FHEM/firmware liegen

set Radar208 reboot
löst einen Neustart der Firmware aus

set Radar208 treshold xx setzt den treshold auf xx. Er wird aktuell nur gesetzt und angewendet, aber nicht gespeichert. Wenn man ihn speichern will, muss man auf der Setup Page speichern. Damit kann man, bis es eine Automatik gibt, einfacher den richtigen treshold suchen.
Beispiel: set Radar208 treshold 1.2

Das internal VERSION zeigt die firmware-Version an
Das internal UPTIME die uptime.
Zu beachten ist, dass in FHEM die Internals nur bei einem Browser refresh neu angezeigt werden.

Ist eingecheckt, incl der 8 decimals für magAVGkorrThresh

[networker]

Bei MagAVGkorrThresh hab ich weiterhin 4 Decimals,  bei GroupMagAVGkorrThresh hab ich 8 Decimals.

[HCS]

Bei MagAVGkorrThresh hab ich weiterhin 4 Decimals,  bei GroupMagAVGkorrThresh hab ich 8 Decimals.

@chunter1: sollten beide?
Falls ja, Du oder ich?

[PeMue]

Hallo chunter1,

ich versuche mich gerade, in die Schaltung (bzw. den PreAmp) einzuarbeiten und habe noch folgende Fragen:

Anbei nochmal ein Vergleich des Rauschens der beiden Preamp Varianten, diesmal bei Erhitzung des Rohres durch die Sonne.
Der speziell für diese Anwendung entworfene, diskret aufgebaute Preamp steckt in einem DN40 daneben.

- Ich vermute mal, dass der eine der Verstärker ist, der bei dem ersten Radarsensor dabei ist und der andere der in Post #273 erwähnte.

- Zum Verstärker in Post #273:
* Ich vermute mal, dass der +Eingang von U2 eine 2,5 V Gleichspannung bekommt, damit man keine bipolare Spannungsversorgung braucht. Daher sollte man hier die Versorgungsspannung des Verstärkers bzw. des ESP32 entkoppeln.
* Die zwei Dioden dienen vermutlich zum "clippen" der Sensorspannungsspitzen, ich gehe mal davon aus, dass der Sensor weniger als 0,6 V liefert.

- Ansonsten versuche ich mal, den Verstärker in LTSpice zu simulieren.
- Wie hast Du derzeit den Verstärker aufgebaut? Auf Steckbrett? Kannst Du bitte ein Bild posten?

Danke + Gruß

PeMue

[chunter1]

Bei MagAVGkorrThresh hab ich weiterhin 4 Decimals,  bei GroupMagAVGkorrThresh hab ich 8 Decimals.
@chunter1: sollten beide?
Falls ja, Du oder ich?

Würds vorerst so belassen.
Bin momentan an der Umstellung der .ino in C++ und Signalverarbeitungsthemen dran.
Würde das dann beim nächsten Update mit einfließen lassen.

- Ich vermute mal, dass der eine der Verstärker ist, der bei dem ersten Radarsensor dabei ist und der andere der in Post #273 erwähnte.

Richtig

* Ich vermute mal, dass der +Eingang von U2 eine 2,5 V Gleichspannung bekommt, damit man keine bipolare Spannungsversorgung braucht. Daher sollte man hier die Versorgungsspannung des Verstärkers bzw. des ESP32 entkoppeln.

Richtig.
Einfach einen eigenen 5V Linearregler für den Radar-Sensor + Preamp verwenden.
Die Verwendung eines zu gering gefilterten Schaltreglers (egal ob Buck oder Boost) kann zu Störungen führen, auch wenn dieser weit oberhalb von 5 kHz arbeitet (Aliasing!).

* Die zwei Dioden dienen vermutlich zum "clippen" der Sensorspannungsspitzen, ich gehe mal davon aus, dass der Sensor weniger als 0,6 V liefert.

Die Ausgangsspannung liegt deutlich unterhalb von 0,6 V.
Die antiparallelen Dioden sind zum Schutz der Mischerdioden im Sensor gedacht und leiten allfällige Lade-/Entladeströme des 10uF Kondensators (ist auf 2,5 V aufgeladen) kontrolliert ab.

- Ansonsten versuche ich mal, den Verstärker in LTSpice zu simulieren.

Wenn du weißt, wie man ein Model des LME49720 in LTSpice rein bekommt, lass es mich bitte wissen.

- Wie hast Du derzeit den Verstärker aufgebaut? Auf Steckbrett? Kannst Du bitte ein Bild posten?

Momentan existiert nur der Aufbau aus Post #269.

[chunter1]

Achtung!
In folgendem Datenblatt zum IPM-170 ist die Pinbelegung bei der oberen Ansicht falsch herum beschriftet!
https://shop.bb-sensors.com/out/media/Datenblatt_IPM-170_DB-DE_Rev01.pdf

[chunter1]

Anbei die Noise-level meines geschirmten Testaufbaus bei Raumtemperatur mit einem IPM-170 als Referenz.
Wäre interessant, wenn ihr eure Messwerte auch posten könntet, damit wir Verbesserungen diskutieren können.

EDIT:
Anbei noch ein Foto vom Aufbau.
Ja, ich weiß, der Aufbau schaut hässlich aus - hatte aber nur mehr das alte Gehäuse parat.
Beim endgültigen Aufbau möchte ich den Sensor komplett versenken damit er "plan" zur Gehäuseoberfläche ist.
...und evtl. noch einen HF-Absorber rund um die Antenne auf das Blechgehäuse kleben.

[chunter1]

Noch ein Hinweis bzgl. der verwendeten Kondensatoren.
Bin von den keramischen Kondensatoren weggegangen, da mir der Piezo-Effekt zu stark war.
Soll heißen - wenn man leicht auf das Schirmgehäuse geklopft hat, konnte man die mechanische Schwingungen, die die Kerkos aufnehmen, deutlich am Ausgang hören.
Könnt ihr selber testen indem ihr keinen Radar-Sensor am Eingang anschließt, sondern stattdessen den Eingang auf GND kurzschließt und auf euren Aufbau klopft.

[Maista]

Sieht gut aus 
Ich hole nacher meine zwei Sensoren ab.

Welchen Kondensator Typ schlägst du dann vor?
MKT oder gleich in SMD?
Für den 1n habe ich Kerko genommen

Schau mehr mal ..

Gruss Gerd

[PeMue]

Hallo Gerd,

MKT oder gleich in SMD?

aber die SMDs sind doch auch keramisch  Entweder NP0 oder X5/7R?

Gruß PeMue

[Maista]

Ich habe nun das Modul geholt.

Im Datenblatt steht "Aufgrund des Aufbaus sind die Module empfindlich gegen Körperschall. Eine Befestigung über die Pins ist nicht ausreichend, das Modul sollte zusätzlich auch mechanisch fixiert werden".

Das kommt dann noch dazu wenn tatsächlich die Kondensatoren schwingen sollten!?

ESD-SCHUTZ hat das Modul keinen. Muss ich meine ESD UNTERLAGE erst einmal erden
Man sollte nicht einmal die Anschluss Pins mit einem Multimeter Durchmesser!

Hm....

Mal sehen ob der Verstärker funktioniert.

Aber heute ist warm ...

[chunter1]

Welchen Kondensator Typ schlägst du dann vor?
MKT oder gleich in SMD?

Bei SMD kann man das nicht pauschal sagen.
Aber X5R, X7R... MLCCs im Signalpfad sind auf alle Fälle übel.

Ich würde folgendes empfehlen:
Für 1 nF: Folienkondensator, NPO oder COG
Für 10 uF: gepolter/bipolarer Elko, Folienkondensator (groß!)

Das kommt dann noch dazu wenn tatsächlich die Kondensatoren schwingen sollten!?

Der Radar-Sensor "hört" sowieso das Schwingen des Rohres als Dopplersignal.
Da bieten vermutlich dickwandigere/stabilere Rohre einen Vorteil.
Wie einige Posts zuvor beschrieben, ziehe ich funktionell sowieso das DN70 dem DN40 vor.
Im direkten Vergleich meiner beiden Setups hat das DN40 bei Wind deutlich mehr Schwingungen aufgenommen als das DN70.

ESD-SCHUTZ hat das Modul keinen. Muss ich meine ESD UNTERLAGE erst einmal erden
Man sollte nicht einmal die Anschluss Pins mit einem Multimeter Durchmesser!

Ja, nimm das wirklich ernst, sonst freuen sich die Radar-Sensor Verkäufer doppelt.

[networker]

Wäre interessant, wenn ihr eure Messwerte auch posten könntet, damit wir Verbesserungen diskutieren können.

Hier meine für den mitgelieferten Preamp ungeschirmt bei ca. 23° Indoor am Arbeitstisch.

Bild 1 = alle Gruppen von 0 - 31
Bild 2 = Gruppen 2 -30, da die 0,1 und 31 streuen.

[Per]

Im direkten Vergleich meiner beiden Setups hat das DN40 bei Wind deutlich mehr Schwingungen aufgenommen als das DN70.

Das großere Rohr kann durchaus in sich steifer (Wind!) sein.