"Geisterimpulse" vom Pluviometer mit ESP32 und ESPEasy

[TheTrumpeter]

Mal wieder ein Update...

Mit der "Alternativschaltung" von zuletzt war das Problem leider auch nicht weg.

Ich habe der Vollständigkeit halber dann die Schaltung ans andere Ende der Leitung gepackt, also direkt beim Sensor.
Da ist mir dann aufgefallen, dass bei Störungen der Zähler nur 1 hochzählt, bei "echten" Impulsen aber 2. Zuerst dachte ich an ein "Prellen", da ich dzt. keinen echten Reed dran habe, sondern einfach zwei kurze Kabelenden, die ich zum Simulieren des Reed-Kontakts "zusammenhalte". Aber es werden immer 2 Impulse gezählt, egal wie sehr ich "wackle". (Wenn ich 2x kurz hintereinander kontaktiere, kommen trotzdem nur 2 Impulse (verwende R=10k und C=100µF um lange genug Zeit zu haben) und nicht etwa 3 oder 4.)

Ich gehe davon aus, dass das Verhalten auch so ist, wenn ich die Schaltung zum ESP packe; dort habe ich es nur nie so genau beobachtet.

Diesen Effekt kann ich nun ausnutzen, um Softwareseitig zwischen "Wackler" und "echtem Impuls" zu unterscheiden, wenngleich das nicht wirklich schön ist.

PS: Der Test mit sensorseitig platzierter Transistorschaltung steht noch aus, vielleicht löst sich das Problem ja damit. Ehrlich gesagt gehe ich aber nicht davon aus.

[Papa Romeo]

Da ist mir dann aufgefallen, dass bei Störungen der Zähler nur 1 hochzählt, bei "echten" Impulsen aber 2.

... stellt sich dar wie ein Monoflop-Verhalten, bei der sowohl die steigenden als auch die fallenden Flanken ausgewertet werden.

Da die "Entprellung" durch den 100 uF ja aber anscheinend tadellos funktioniert

... Wenn ich 2x kurz hintereinander kontaktiere, kommen trotzdem nur 2 Impulse

kann für diesen Effekt dann eigentlich nur noch die "softwareseitige" Auswertung der Impulse verantwortlich sein.

LG
Papa Romeo

[TheTrumpeter]

kann für diesen Effekt dann eigentlich nur noch die "softwareseitige" Auswertung der Impulse verantwortlich sein.

Tja, ich habe jetzt noch einen Versuch gemacht und glaube an gar nichts mehr.

Flankenauswertung war immer "rising".
SW-Debounce-Zeit auf 0ms => >50 Inkremente
SW-Debounce-Zeit auf 100ms => >2 Inkremente, bei erneuter Kontaktierung innerhalb 1s kommen noch mal >2 Inkremente
SW-Debounce-Zeit auf 500ms => 2 Inkremente
SW-Debounce-Zeit auf 5000ms => 1 Inkrement

Habe dann auf R=25k geändert, da kommt es bei SW-Debounce 500ms meist zu 3 Inkrementen bei kurzer Kontaktierung.
Wenn ich den Kontakt länger schließe, kommt es zu 1 Inkrement beim Schließen und nach dem Öffnen zu 2-3 weiteren Inkrementen.
Mit R=4k7 sind es bei 500ms Debounce 2 Inkremente bei kurzzeitiger Kontaktierung bzw. 1+1 beim langen Schließen und Öffnen.
Schmeisse ich den Kondensator raus, kommt es beim Schließen zu keiner Änderung und erst beim Öffnen kommt genau 1 Inkrement.

Eine Änderung des Vorwiderstands von R=162 auf R=400 brachte keine Änderung.

Schaut also so aus als ob es durch den Kondensator zu einem "Schwingen" nahe des High-Pegels (2V) kommt???

Nachdem ich unschlüssig war ob die Angabe "mSec" beim Debounce-Wert in ESPEasy auch wirklich Milli- und nicht etwa Microsekunden meint, habe ich das im Code nachgeschaut, aber das passt:

Code Auswählen Erweitern

/*********************************************************************************************\
* Check Pulse Counters (called from irq handler)
\*********************************************************************************************/
void Plugin_003_pulsecheck(byte Index)
{
  noInterrupts(); // s0170071: avoid nested interrups due to bouncing.

  //  s0170071: the following gives a glitch if millis() rolls over (every 50 days) and there is a bouncing to be avoided at the exact same
  // time. Very rare.
  //  Alternatively there is timePassedSince(Plugin_003_pulseTimePrevious[Index]); but this is not in IRAM at this time, so do not use in a
  // ISR!
  const unsigned long PulseTime = millis() - Plugin_003_pulseTimePrevious[Index];

if (PulseTime > (unsigned long)Settings.TaskDevicePluginConfig[Index][0]) // check with debounce time for this task
  {
    Plugin_003_pulseCounter[Index]++;
    Plugin_003_pulseTotalCounter[Index]++;
    Plugin_003_pulseTime[Index]         = PulseTime;
    Plugin_003_pulseTimePrevious[Index] = millis();
  }
  interrupts(); // enable interrupts again.
}

Und aus der Arduino-Referenz:

millis()
[Time]
Description

Returns the number of milliseconds passed since the Arduino board began running the current program. This number will overflow (go back to zero), after approximately 50 days.

[Papa Romeo]

Schmeisse ich den Kondensator raus, kommt es beim Schließen zu keiner Änderung und erst beim Öffnen kommt genau 1 Inkrement.

Dieses würde dem "Rising" entsprechen und wäre auch o.k. so ...  aaaber ... der zum REED parallel liegende Elko wirkt dem entgegen, da er durch seine lange Ladekonstante kein richtiges "Rising" des Impulses zulässt. Da der Spannungsanstieg langsam den Schwellwert durchläuft, den der GPIO als HIGH erkennt und somit immer wieder neue Spannungswerte registriert, ist es durchaus möglich dass mehrere Impulse erkannt werden. Ist natürlich auch wieder von den Debounce-Einstellungen abhängig. Kleines oder kein Debounce --> viele Impulse, großes Debounce  --> weniger Impulse.

Stell mal die Flankenauswertung auf "Falling".

LG
Papa Romeo

[TheTrumpeter]

Stell mal die Flankenauswertung auf "Falling".

R=4k7, C=100µF

SW-Debounce 0 => 1 Impuls beim Schließen & >30 Impulse nach dem Öffnen
SW-Debounce 100 => 1 Impuls beim Schließen & 2 Impulse nach dem Öffnen
SW-Debounce 200/300/400 => 1 & 1
SW-Debounce 450/500 => 1 & 1 bzw. 2 bei "Tippen"
SW-Deboucce 550/600/1000 => 1 & 1 bzw. 1 beim "Tippen"

Habe das dann nochmal mit "rising" wiederholt, exakt die gleichen Ergebnisse.

Das passt nun insofern in mein Bild, als gemäss R=4k7 und C=100µF die HW-Debounce-Zeit bei 470ms liegen sollte, bisschen Toleranz ist auf den Bauteilen sicher drauf bzw. ist das kurze "Tippen" ja auch nicht 0ms sondern ggf. ein paar ms. (Oder anders, danach müsste der Kondensator wieder voll geladen sein und ein stabiler Pegel wie vor dem Schliessen des Kontakts eingetreten sein.)
Beim kurzen Tippen wird das "Schwingen" durch den Kondensator offenbar durch das SW-Debouncing ausgeblendet, sobald dies in etwa so groß ist wie das HW-Debouncing.

Entsprechend könnte ich das Verhalten wohl tatsächlich zum Unterscheiden von Störungen und "echten Impulsen" verwenden, indem ich die SW-Debounce-Zeit knapp unter der HW-Debounce-Zeit wähle, z.B. 400ms.

[TheTrumpeter]

So, nachdem auch die Transistorschaltung bei sensorseitiger Platzierung "Geisterimpulse" verursacht hat, habe ich vor einigen Tagen die "Kondensator-Schaltung" ESP-seitig platziert und das Verhalten eine Weile beobachtet. Jegliche Störung hat nur zu einem Impuls geführt. Diese Einzel-Impulse filtere ich SW-seitig weg.

Nun habe ich statt der "offenen Kabelenden" (2 Adern eines geschirmten Stern-Vierers) wieder das echte Pluviometer (ungeschirmte selbst ausgekreuzte 2 Adern) angeschlossen, um auch "echte Impulse" testen zu können. Damit fange ich zwar mehr "Geisterimpulse" ein, aber trotzdem wird jeder als Einzelimpuls erkannt und daher rausgefiltert.

Damit werde ich wohl bei der Schaltung bleiben, wobei sich nur noch ein Frage für mich stellt:
In dem Schaltungsentwurf ist ein Vorwiderstand R=100 vorgesehen, den ich dzt. mittels Parallelschaltung mehrerer Widerstände realisiert habe, ca. R=162. Bei einer vorübergehenden Änderung auf R=400 konnte ich kein geändertes Verhalten feststellen. Daher: Brauche ich den Vorwiderstand überhaupt und wenn ja kann ich auch R=400 verwenden?

[Papa Romeo]

Brauche ich den Vorwiderstand überhaupt und wenn ja kann ich auch R=400 verwenden?

...kannst auch 400 Ohm nehmen. Der Widerstand ist nur dazu da, um den Entladestrom des C´s über den Reed-Kontakt zu begrenzen und Diesen etwas zu schonen.

Du kannst ihn so groß machen, dass beim Schließen des Reed´s noch ein "LOW" erkannt wird.

LG
Papa Romeo