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

@HCS
Laufen deine ESP32 ohne reboots durch?
Bei mir fängt das internal "UPTIME" immer wieder mal bei 0 an.
Die Reboots erkennt man auch an sporadischen Resets der intern akkumulierten Regenmenge.
Ich schätze mal, dass hier der Wifi-Connect Workaround o.Ä. zuschlägt?

HCS

Zitat von: chunter1 am 04 Dezember 2017, 11:13:41
@HCS
Laufen deine ESP32 ohne reboots durch?
Noch schwer zu sagen. Läuft erst seit gestern wieder.
1Tg. 1Std. 47Min. 9Sek. Uptime, das passt seit ich es gestern gestartet habe.
Das Ganze bei einem RSSI von um -80 rum, also eher grenzwertig weit vom AP entfernt.
Ich werde es mal beobachten.

Zitat von: chunter1 am 04 Dezember 2017, 09:55:03
Könnte sein, dass zu dem Zeitpunkt etwas Wind auftrat und die Flocken direkt vor die Sensorfläche geweht hat.
Das könnte sein. Manchmal hatte ich den Eindruck, dass es von unten nach oben schneit, der Schnee war federleicht

networker

Habe diese Restarts auch.
Wenn ich aber das OTAUpdate ausommentiere läuft er durch

Zitat von: HCS am 22 Oktober 2017, 19:56:59
Kann es auch reproduzieren. Mit dem Core Rev. 643 selten, mit dem aktuellen häufiger.

Gleiche Exception:
Starting frontend
Starting OTA
Starting data port
Setup done
E (7421) esp_pthread: pthread_getspecific: not supported!
E (7421) esp_pthread: pthread_setspecific: not supported!
abort() was called at PC 0x400deee3 on core 1

Backtrace: 0x400878f4:0x3ffdc6d0 0x400879f3:0x3ffdc6f0 0x400deee3:0x3ffdc710 0x400def2a:0x3ffdc730 0x400df62e:0x3ffdc750 0x400df6b7:0x3ffdc770 0x400deb3a:0x3ffdc790 0x400deaf1:0x3ffdc7b0 0x400daca4:0x3ffdc7d0 0x400dbaea:0x3ffdc810 0x400d597a:0x3ffdc830 0x400d2c98:0x3ffdc850 0x4012d358:0x3ffdc870


Ich habe mal den backtrace rausgelesen:
Das kommt aus ArduinoOTAClass wenn der handle() aufgerufen wird.

Kannst Du mal in OtaUpdate.cpp den handle stillegen und verifizieren, dass es dann weg ist?
void OTAUpdate::Handle() {
  ////ArduinoOTA.handle();
}


Stimmt. Das ist der Unterschied zwischen RSSI=-40 und RSSI=-75
Habe den Lautsprecher dran gemacht. Bei der Position weiter weg höre ich das WiFi deutlich, in zwei Meter Abstand zum AP ist Ruhe.

JoWiemann

Hallo, ich hatte das Problem in einem meiner Sketche auch. Wenn der OTA mehrmals definiert wird, z.B. weil der Server kurzzeitig gestoppt wird für zeitkritische Verarbeitungen, dann allokiert der OTA immer wieder Speicher. Das läuft solange, bis nicht mehr genügend Speicher verfügbar ist. Und dann gibt es einen Restart.




Gesendet von iPad mit Tapatalk

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: JoWiemann am 04 Dezember 2017, 12:57:58
Wenn der OTA mehrmals definiert wird, z.B. weil der Server kurzzeitig gestoppt wird für zeitkritische Verarbeitungen, dann allokiert der OTA immer wieder Speicher. Das läuft solange, bis nicht mehr genügend Speicher verfügbar ist. Und dann gibt es einen Restart.

Hmmm, aus void setup() wird OTAUpdate::Begin() genau einmal aufgerufen was dann ArduinoOTA.begin() genau ein mal aufruft.
Mein letztes Ergebnis war, dass der ArduinoOTA.handle() nicht aufgerufen werden darf, um das Problem zu vermeiden.

chunter1

#695
Zitat von: HCS am 03 Dezember 2017, 21:30:42
Dass dieser feine Schnee sichtbar wird und auch noch die geringen Intensitätsunterschiede erkennbar sind, ist mehr als ich erwartet hatte.  8)
Bitte poste bei Gelegenheit mal deine Werte vom "Threshold Offset" und "GroupMagThresh".
Dein publish interval ist wie gehabt auf 30s eingestellt?

HCS

Oh vergessen gehabt  :-[

Zitat von: chunter1 am 04 Dezember 2017, 16:33:51
Bitte poste bei Gelegenheit mal deine Werte vom "Threshold Offset" und "GroupMagThresh".
GroupMagThresh: 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
Threshold Offset: 2
Und Mounting angle: 45°  ;) ;D ;D

Zitat von: chunter1 am 04 Dezember 2017, 16:33:51
Dein publish interval ist wie gehabt auf 30s eingestellt?
Nein, inzwischen ist es 60s

Frage: wie kommen wir denn zu einem Endergebnis in Form von:
schneit / regnet / hagelt
und
leicht / mittel / stark oder etwas auf einer Skala von 1 ... x

Ach ja: Uptime 3Tg. 3Std. 37Min. 51Sek

chunter1

#697
Zitat von: HCS am 06 Dezember 2017, 14:03:06
Frage: wie kommen wir denn zu einem Endergebnis in Form von:
schneit / regnet / hagelt
und
leicht / mittel / stark oder etwas auf einer Skala von 1 ... x
Dafür muss die Frage geklärt werden, wie sich die Störsignale, verursacht durch Vögel, Insekten, Tropfenbildung etc. am besten herausfiltern lassen, ohne die Empfindlichkeit und Ansprechzeit des Sensors zu stark zu beeinträchtigen.
Aktuell hoffe ich, dass eine Kombination aus den beiden Readings "GroupMagAVGkorr" und "GroupMagAboveThreshCnt" zum Ziel führen könnte.
Zu beachten ist, dass der "GroupMagAboveThreshCnt" Wert nach oben hin begrenzt ist!

Ich versuch mal kurz zu erklären, wie der Wert errechnet wird.
Vereinfacht gesagt wird alle 25 ms ein Snapshot von ADC-Werten FFT transformiert.
Die resultierenden FFT-bins innerhalb der Gruppen werden dann einzeln mit dem Threshold verglichen und bei Überschreiten wird der GroupMagAboveThreshCnt der entsprechenden Gruppe erhöht.
Der Wert um den erhöht wird, ist abhängig von der bin-Nummer ("in FOV"-Wert - gibt die Anzahl der Snapshots an, die das Objekt sichtbar ist)
So sind z.B. die am langsamsten fliegenden Schneeflocken (bin1 = 20 Hz = 0.12 m/s) in bis zu 323 aufeinanderfolgenden 25 ms Snapshots sichtbar und der Wert um den erhöht wird beträgt damit 1/323.
Schnell fliegende Tropfen belegen hingegen weniger als 2 aufeinanderfolgende 25 ms Snapshots und erhöhen den Zähler um 1/2.
Natürlich ist die tatsächliche Anzahl der Snapshots, in denen das Objekt sichtbar ist, von der Entfernung und Größe des Objektes abhängig.
Über einen genügend langen Zeitraum betrachtet, sollte das jedoch statistisch (hoffentlich) keine große Rolle mehr spielen.

Ob dieser Algo der Weisheit letzter Schluss ist, lass ich mal zur Diskussion offen. :)

Geht man von 60 s publish-interval aus, dann erhält man 60 s / 25 ms = 2400 snapshots.
Angenommen es fällt innerhalb dieser 60 s nur eine Schneeflocke (mit 0.12 m/s), dann steht in der Group0 des GroupMagAboveThreshCnt Readings der Wert "1" (323 snapshots mit bin1 über dem threshold ergibt 323 x (1/323) = 1).
Sobald jedoch mehr als 2400 / 323 = 7 Schneeflocken brav hintereinander mit Abstand fallen, befindet man sich am Limit und es kann schnein was es will - mehr als 7 wird nicht gezählt.

Aus diesem Grund gibts das Reading "GroupMagAVGkorr".
Bei dem werden vereinfacht gesagt die Magnituden der einzelnen bins, korrigiert um den "in FOV"-Wert, akkumuliert.


(Auf die Schnelle erklärt, ohne dass ich jetzt den letzten code vor mir hatte... ;) )

HCS

Zitat von: chunter1 am 06 Dezember 2017, 16:03:17
(Auf die Schnelle erklärt, ohne dass ich jetzt den letzten code vor mir hatte... ;) )
Ich glaube, man kann es weder auf die Schnelle erklären noch auf die Schnelle verstehen und beurteilen  ;D

chunter1

Zitat von: HCS am 06 Dezember 2017, 14:03:06
Ach ja: Uptime 3Tg. 3Std. 37Min. 51Sek
Wenn ich die uptime des STATE anschaue laufen meine Module auch durch aber wenn ich das UPTIME internal anschaue sehe ich immer wieder reboots?
Wie sind denn die beiden uptime Werte genau zu verstehen?

STATE:     initialized UpTime: 1Tg. 17Std. 13Min. 48Sek.
UPTIME:  0Tg. 0Std. 13Min. 46Sek.

HCS

Zitat von: chunter1 am 07 Dezember 2017, 09:34:24
Wenn ich die uptime des STATE anschaue laufen meine Module auch durch aber wenn ich das UPTIME internal anschaue sehe ich immer wieder reboots?
Wie sind denn die beiden uptime Werte genau zu verstehen?

Internals:
   Alive      2017-12-07 09:39:38
   DEF        192.168.31.208:81
   DeviceName 192.168.31.208:81
   ...
   STATE      initialized UpTime: 3Tg. 23Std. 14Min. 44Sek.  detections: ?
   ...
   UPTIME     3Tg. 23Std. 15Min. 32Sek.
   VERSION    0.16.2
...
Attributes:
   disable    0
   event-min-interval 120
   event-on-update-reading .*
   group      .Radar208
   room       .Radar
   stateFormat {ReadingsVal("Radar208", "state", "") . " UpTime: " . InternalVal("Radar208", "UPTIME", "?"). " detections: " . ReadingsVal("Radar208", "detections", "?");}
   timeout    15


OK, die detections muss ich jetzt mal ausbauen, die gibt es ja nicht mehr  :(

HCS

Zitat von: HCS am 07 Dezember 2017, 09:46:31
OK, die detections muss ich jetzt mal ausbauen, die gibt es ja nicht mehr  :(
Und statt dessen vorerst mal MagAVGkorr nehmen?
Daran müsste man doch zumindest sehen, das irgendwas am Radar vorbeifliegt?

chunter1

Zitat von: HCS am 07 Dezember 2017, 09:49:10
Und statt dessen vorerst mal MagAVGkorr nehmen?
Daran müsste man doch zumindest sehen, das irgendwas am Radar vorbeifliegt?
Ja, mach das.
Am besten du erstellst dir für beide Readings Diagramme untereinander um die Unterschiede bewerten zu können.

chunter1

Anbei eine vereinfachte Skizze, welche die Berechnung des GroupMagAboveThreshCnt Readings (hoffentlich) etwas verständlicher macht.  ;)

PeMue

So, vermutlich wird sich jetzt in Kürze auch Susi wundern, warum ihr Strolch auf dem Dach rumkrabbelt und irgendwelche Platinen verbaut  ;)
Somit sind alle Verstärkerplatinen ausgeliefert ...

Gruß PeMue
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser