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

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

Vorheriges Thema - Nächstes Thema

HCS

Zitat von: Maista am 01 August 2017, 20:51:26
Habt ihr schon einmal nach Watchdog mit NE555 geschaut?
Ja. Die NE555 Watchdogs haben üblicherweise das Problem, dass sie auf Pegel triggern und nicht wie der 74HC123 auf Flanke.
Das bedeutet, dass, wenn man Pech hat, und der Port ausgerechnet auf HIGH stehen bleibt, der Reset nicht kommt.

Den 74HC123 kann man als gesetzt betrachten. Da kommt man auch mit weniger externer Beschaltung aus. (zwei Widerstände und ein Kondensator)

Und mir ist gerade klar geworden, dass der Timeout recht lang sein muss. Habe mich gerade gwundert, warum der Firmware-Upoad zwei mal kurz vor dem Ende abgebrochen ist.
Ja, der Watchdog hatte die Geduld verloren.  :)

Und es ist gerade ein Gewitter durchgezogen.
Das klappt doch schon recht gut.

@chunter1:
Schaut Dein Radar aktuell nach oben oder 45° rauf oder runter?
Kannst Du bitte noch diesen (https://forum.fhem.de/index.php?action=dlattach;topic=73016.0;attach=82398) SVG posten?
Es sollte doch mit beiden Radars alternativ gehen, nur wenn man Volumen rechnen möchte, müsste dann ein Konfiguration her, oder?

Zitat von: chunter1 am 01 August 2017, 21:36:25
Das wird wohl heute nix mehr mit dem Test - hab grade meinen IPM-165 gegrillt.  :(
Ohh, übel. Ist es also wahr, dass der Ausgang sehr empfindlich ist.



chunter1

Zitat von: HCS am 01 August 2017, 21:46:49
@chunter1:
Schaut Dein Radar aktuell nach oben oder 45° rauf oder runter?
Der RSM-1700 sitzt im DN70 und schaut senkrecht in den Himmel.
...und der IPM-165 schaut vom Himmel senkrecht herunter.  ;)

Zitat
Es sollte doch mit beiden Radars alternativ gehen, nur wenn man Volumen rechnen möchte, müsste dann ein Konfiguration her, oder?
Genau - aber erst mal das Rauschen abklären und dann das DN40 Rohr Setup fertigstellen.

Zitat
Ohh, übel. Ist es also wahr, dass der Ausgang sehr empfindlich ist.
Auf den hab ich penibel aufgepasst; aber am Netzteil waren noch 12V statt 5V beim Einschalten eingestellt.

Zitat
Kannst Du bitte noch diesen (https://forum.fhem.de/index.php?action=dlattach;topic=73016.0;attach=82398) SVG posten?

# Created by FHEM/98_SVG.pm, 2017-08-01 17:43:10
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 'FFT-bin group avg magnitude corrected by FOV-factor (MagAVGkorr)'
set ytics
set y2tics
set grid y2tics
set ylabel ""
set y2label ""
set y2range [0:]

#FileLog_PRECIPITATION_SENSOR 4:PRECIPITATION_SENSOR.GroupMagAVGkorr\x3a::
#FileLog_PRECIPITATION_SENSOR 5:PRECIPITATION_SENSOR.GroupMagAVGkorr\x3a::
#FileLog_PRECIPITATION_SENSOR 6:PRECIPITATION_SENSOR.GroupMagAVGkorr\x3a::
#FileLog_PRECIPITATION_SENSOR 7:PRECIPITATION_SENSOR.GroupMagAVGkorr\x3a::
#FileLog_PRECIPITATION_SENSOR 8:PRECIPITATION_SENSOR.GroupMagAVGkorr\x3a::
#FileLog_PRECIPITATION_SENSOR 9:PRECIPITATION_SENSOR.GroupMagAVGkorr\x3a::
#FileLog_PRECIPITATION_SENSOR 10:PRECIPITATION_SENSOR.GroupMagAVGkorr\x3a::
#FileLog_PRECIPITATION_SENSOR 11:PRECIPITATION_SENSOR.GroupMagAVGkorr\x3a::
#FileLog_PRECIPITATION_SENSOR 12:PRECIPITATION_SENSOR.GroupMagAVGkorr\x3a::
#FileLog_PRECIPITATION_SENSOR 19:PRECIPITATION_SENSOR.GroupMagAVGkorr\x3a::
#FileLog_PRECIPITATION_SENSOR 28:PRECIPITATION_SENSOR.GroupMagAVGkorr\x3a::
#FileLog_PRECIPITATION_SENSOR 35:PRECIPITATION_SENSOR.GroupMagAVGkorr\x3a::

plot "<IN>" using 1:2 axes x1y2 title 'G0' ls l0fill lw 0.2 with histeps,\
     "<IN>" using 1:2 axes x1y2 title 'G1' ls l1fill lw 0.2 with histeps,\
     "<IN>" using 1:2 axes x1y2 title 'G2' ls l2fill lw 0.2 with histeps,\
     "<IN>" using 1:2 axes x1y2 title 'G3' ls l3fill lw 0.2 with histeps,\
     "<IN>" using 1:2 axes x1y2 title 'G4' ls l4fill lw 0.2 with histeps,\
     "<IN>" using 1:2 axes x1y2 title 'G5' ls l5fill lw 0.2 with histeps,\
     "<IN>" using 1:2 axes x1y2 title 'G6' ls l6fill lw 0.2 with histeps,\
     "<IN>" using 1:2 axes x1y2 title 'G7' ls l0dot lw 2 with histeps,\
     "<IN>" using 1:2 axes x1y2 title 'G8' ls l1dot lw 2 with histeps,\
     "<IN>" using 1:2 axes x1y2 title 'G15' ls l5 lw 1 with points,\
     "<IN>" using 1:2 axes x1y2 title 'G24' ls l2 lw 1 with points,\
     "<IN>" using 1:2 axes x1y2 title 'G31' ls l0 lw 1 with points



HCS

Zitat von: chunter1 am 01 August 2017, 22:29:49
...und der IPM-165 schaut vom Himmel senkrecht herunter.  ;)
;D ;D ;D ;D ;D
Der ist gut ...

OK, nachdem ich es nun mit 45° gesehen habe, könnte ich das 50er Rohr auch mal nach oben ausrichten. Mal schauen, wie das dann beim nächsten Regen aussieht.

Zitat von: chunter1 am 01 August 2017, 22:29:49
Auf den hab ich penibel aufgepasst; aber am Netzteil waren noch 12V statt 5V beim Einschalten eingestellt.
Aha, nicht 12V tolerant.  :)


networker

Könntest du die relevanten SVG's bitte mit in das GitHub legen?
:)


chunter1

Zitat
OK, nachdem ich es nun mit 45° gesehen habe, könnte ich das 50er Rohr auch mal nach oben ausrichten. Mal schauen, wie das dann beim nächsten Regen aussieht.
Platzier den Sensor möglichst weit unten damit der Abstand zum oberen Rohrende maximal ist.
Dadurch haben die am Deckel oben auftreffenden Tropfen weniger Einfluss.
Ich denke, ideal wäre eine Spitze die das Aufprallen, den Körperschall und die Schneeablagerung vermindert.

chunter1


HCS

Heute um 07:03 ist er wieder stehen geblieben.
Aktuell ist eine originale V0.7 drauf, ohne DS18B20, Watchdog usw.
Auf das WebFrontend hat zu dem Zeitpunkt definitiv niemand zugegriffen.
Der scheint einfach zu stehen, keine Antwort auf Ping und nichts.

Ich stelle mal DS18B20 und Watchdog zurück, bis geklärt ist, was da passiert.
Macht eher keinen Sinn, noch mehr einzubauen, solange das nicht stabil läuft.
Muss das Rohr doch wieder rein holen und an einem Terminalprogramm laufen lassen, um zu sehen, was da passiert.

Ich werde aber die Klassen für den DS18B20 und den Watchdog (in Kürze) commiten und die Aufrufe auskommentiert drin lassen, wegwerfen will ich es jetzt auch nicht.
Vorübergehend auskommentierten Code kommentiere ich immer mit //// aus, im Gegensatz zu normalen // Kommentaren. Damit kann man es leicht finden, wenn man prüfen will, wo noch Dinge zu reaktivieren oder wegzuwerfen sind.

Beispiel:
  // Get the temperature
  //// if (ds18b20.IsPresent() && ds18b20.ShouldMeasureNow()) {
  ////   stopCapture();
  ////   temperature = ds18b20.GetTemperature();
  ////   startCapture();
  //// }


JoWiemann

Hallo,

hier mal ein paar Hinweise von: http://stefanfrings.de/esp8266/index.html#fallstricke


Fallstricke
Wenn dein Programm unzuverlässig läuft, kontrolliere zuerst meine Ratschläge aus dem Kapitel Maßnahmen gegen Fehlfunktionen. Wenn das alles Ok ist, dann kontrolliere die folgenden Aspekte in deinem eigenen Programm:
Es ist wichtig, das die Firmware genügend Rechenzeit ab bekommt, sonst fällt das Modul aus. Alle eigenen Programmteile müssen spätestens nach 50ms (empfohlen werden 20ms) die Kontrolle an die Firmware abgeben, indem entweder die loop() Funktion verlassen wird, oder delay(ms) oder yield() aufgerufen wird.

Für eigene Programme stehen nur ungefähr 4k Byte Stack zur Verfügung. Wenn lokale Variablen in Prozeduren mehr Platz belegen, stürzt das Programm ab. Größere Datenmengen (z.B. Puffer für Daten) sollen daher vorzugsweise global deklariert werden, damit sie außerhalb des Stack liegen.

Dynamische Speicherverwaltung auf dem Heap verlangt besondere Sorgfalt, damit der Heap nicht fragmentiert wird. Mein Tipp: Schreibe Dein Programm so, dass es gar keinen Heap belegt. Verzichte möglichst auf malloc(), calloc(), den new Operator und die Verwendung der String Klasse.

Wenn man Daten sendet, wird aus jedem Client::print() und Client::write() Aufruf ein einzelnes Ethernet Paket. Viele kleine Pakete reduzieren die Performance, da sie genau so lange dauern, wie große Pakete. Die maximale Paketgröße steht in WIFICLIENT_MAX_PACKET_SIZE und ist 1460 Bytes. Wenn man in einem Aufruf zu viele Daten sendet, teilt die Firmware sie automatisch auf mehrere Pakete auf und wartet ggf. auch darauf, dass Platz im Sendepuffer frei wird.

Da der Empfangspuffer mehrere Pakete aufnehmen kann, muss man bei der Programmierung davon ausgehen, dass Client::available() und Client::readBytes() einige Kilobytes zurück liefern können, vor allem wenn die Daten schnell aufeinander folgend eintreffen. Passe beim Auslesen der Daten auf, weder deine Puffer noch den Stack zu überladen.

Benutze die Methoden readString(), readStringUntil() am besten gar nicht, weil sie beliebig lange Strings ansammeln, die leicht einen Speicher-Überlauf auslösen.

Verlasse Dich nicht darauf, dass gesendete TCP Nachrichten den Empfänger in der gleichen Segmentierung erreichen, wie sie gesendet wurden. Die Netzwerk-Komponenten dürfen die Segmente des TCP Datenstromes zerlegen und neu zusammenfügen. In dieser Diskussion wurden die Effekte der Segmentierung sehr schön erklärt.

Beim UDP Protokoll kann man nur einzelne Nachrichten mit maximal 1460 Bytes senden oder empfangen. Unter Umständen schränken Netzwerk-Komponenten die maximale Paketgröße weiter ein. Im heimischen WLAN Netz kannst du dich jedoch auf die 1460 Bytes verlassen.

SSID und Passwort von AP und softAP werden automatisch dauerhaft gespeichert, aber nur wenn sie gültig sind. Das Passwort muss entweder ein Leerstring ("") sein oder mindestens 8 Zeichen lang sein.


Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM


HCS

Zitat von: Per am 02 August 2017, 12:59:22
Danke, gleich mal gespeichert!
Wobei man beachten muss, dass es bei den Hinweisen um den ESP8266 geht und wir hier über den ESP32 reden, der teils eine andere Situation hat, z.B. zwei cores wo einer den TCP-Stack und das ganze Gedöns macht, wegen dem man beim ESP8266 delay und yield braucht und auf dem zweiten core die loop macht.

Und der stack wurde gerade gestern auf 8k hochgesetzt  8)
xTaskCreatePinnedToCore(loopTask, "loopTask", 8192, NULL, 1, NULL, ARDUINO_RUNNING_CORE);

networker

ZitatUnd der stack wurde gerade gestern auf 8k hochgesetzt  8)

ist das schon im GitHub eingecheckt?  :)

chunter1

Zitat von: networker am 02 August 2017, 17:09:45
ist das schon im GitHub eingecheckt?  :)
Wenn ich nicht irre, musst du die Anpassung im ESP32 dev modul (in der "main.cpp") selbst vornehmen?



chunter1

#254
Zitat von: networker am 02 August 2017, 18:15:20
ok, Danke

Die verschiedenen Boards haben nicht das gleiche Pinout!
Bild 1:(https://www.banggood.com/ESP32-Development-Board-WiFiBluetooth-Ultra-Low-Power-Consumption-Dual-Cores-ESP-32-ESP-32S-Board-p-1109512.html?p=DQ30066511122014069J&utm_campaign=educ8stv&utm_content=huangwenjie)

Bild 2:(https://de.aliexpress.com/item/Official-DOIT-ESP32-Development-Board-WiFi-Bluetooth-Ultra-Low-Power-Consumption-Dual-Core-ESP-32-ESP/32801621054.html)

Ja, das ist blöd.
Zumindest Vin (+5V) und GND liegen bei beiden Boards an der selben Stelle.
Wie wäre es wenn wir den "Board-Typ/das Pin-mapping" per Software selektierbar machen (zumindest für die beiden obigen ESP32 Dev.-Board Varianten)?
Die drei IOs (32=Watchdog, 33=DS18B20, 34=ADC) flexibel zu gestalten, hält sich vom Aufwand her in Grenzen.

Oder via simpler Lötbrücken die entsprechenden Pins "aktivieren".

Ich hatte mich damals für das obige Board wegen der kompakten Bauform, der größeren Pinanzahl und dem günstigen Preis entschieden.
Aber Flexibilität ist immer gut! :)