Exaktes Timing trotz PowerDown und externer Interrupts?

[HMSteve]

Hallo zusammen,

ich sitze an einem Wetterdatensensor (moechte mein ELV-Teil mit neuer Hardware auf Basis des 1284P reanimieren). Ziel ist moeglichst Batteriebetrieb. Software orientiert sich stark an Jérômes Wetterstation, allerdings mit Schlafenlegen in der loop. Dann bringen jedoch die haeufigen Interrupts des Anemometer-Reedkontaktes das Sleep-Timing arg durcheinander, so dass viel zu viele Messages gesendet werden. Erscheint mir (inzwischen) logisch, da man nicht ermitteln kann, wie lange vor WDT-Ablauf ein ext. Interrupt zugeschlagen hat, um das zu korrigieren.

Nun die Frage, bevor ich umsonst einen Uhrenquarz bestelle und den CSTNE wieder von der Platine rupfe: Wird das Timing der Messages wieder deterministisch trotz externer Interrupts, wenn ich auf AskSinRTC umsteige? Konnte leider den Code nicht so weit durchdringen, um sicher zu sein, ob da eine entsprechende Korrektur existiert.

Danke und viele Gruesse,
Stephan

[papa]

Das wird wahrscheinlich auch nicht viel bringen, da die ständigen Interrupts die CPU immer wieder aufwecken.
Ich empfehle Dir einen PCF8583P - der kann zählen und wird per I2C ausgelesen. Arduino Unterstützung gint es hier https://bitbucket.org/xoseperez/pcf8583/src/master/

[FUEL4EP]

.. oder einen ABLIC S35770 24-Bit Binary Counter.

Software gibt es hier https://github.com/FUEL4EP/HomeAutomat ... LIC_S35770

[HMSteve]

Danke fuer Eure Empfehlungen, ein separater Zaehler ist vermutlich wirklich sinnvoll, auch wenn's wieder mal ein PCB Redesign erfordert.

Da die Regenwippe seltener umkippt, wuerde ich die wahrscheinlich weiterhin ueber die Interrupts zaehlen lassen - der Stromverbrauch fuers Aufwachen allein zum Zaehlen ist hier vernachlaessigbar. Wuerde hier die AskSinRTC das gewuenschte erreichen, also keine (nennenswerte) Beinflussung der Clock durch die Interrupts, so dass der Sendetakt des Sensors konstant bleibt?

Viele Gruesse,
Stephan

[papa]

mit AskSinRTC kannst Du den Sendetakt ja direkt an den RTC-Timer koppeln. Dann sendetst Du auch immer schön im richtigen Takt. Das geht auch, wenn viele andere Interrupts kommen. Aber die versauen Dir halt den Deep-Sleep, der für Batterie nötig ist.

[HMSteve]

mit AskSinRTC kannst Du den Sendetakt ja direkt an den RTC-Timer koppeln. Dann sendetst Du auch immer schön im richtigen Takt. Das geht auch, wenn viele andere Interrupts kommen. Aber die versauen Dir halt den Deep-Sleep, der für Batterie nötig ist.

Super, danke. Fand nach einigem Suchen noch einen alten Uhrenquarz und konnte das -erstmal testweise- so umsetzen.

Viele Gruesse,
Stephan

[HMSteve]

.. oder einen ABLIC S35770 24-Bit Binary Counter.

Software gibt es hier https://github.com/FUEL4EP/HomeAutomat ... LIC_S35770

Hallo Ewald,

Danke. Vorteil dieses Zaehlers fuer meinen Zweck waere, dass er noch etwas sparsamer als der PCF8583 und sogar der RAM-lose PCF8593 ist. Hast Du mit dem S35770 praktische Erfahrungen mit dem Zaehlen flacher Flanken? Denn was mich im Datenblatt irritiert: Es wird zwar ein Schmitt-Trigger-Eingang hingemalt, aber als maximale Anstiegszeit 300ns angegeben. Das schaffe ich "nicht ganz" mit einem Reedkontakt mit RC-Tiefpass.

Viele Gruesse,
Stephan

[FUEL4EP]

Hallo Stephan,

ich habe den S35770 Zähler erst seit kurzer Zeit in einer Applikation erfolgreich im Betrieb. Welche Anstiegszeit brauchst Du denn? Ich kann dann eine Messung mit einem Signalgenerator aufsetzen. Kannst Du einen Signalverlauf bereitstellen?

Nachtrag 22. März 2021 11:29 Uhr: Der S35770 zählt ein Dreieckssignal mit 100 kHz, 3.3Vpp, 50% DutyCycle korrekt. 50 kHz gehen auch. 1 MHz auch. 10 kHz auch. Also sind langsame Flanken kein Problem. Die 300 ns scheinen ein Fehler im Datenblatt zu sein. Es liest sich ja auch ziemlich Chinglisch

[HMSteve]

Hallo Ewald,

ich habe einen Tiefpass mit 100n/100R vorgesehen, da sollte ich unter 50us bleiben, insofern danke fuer Deinen 10kHz-Versuch, sollte also ohne zusaetzliche Schaltungstechnik klappen. Muss nur dran denken, alles umzudrehen, da der S35770 steigende Flanken zaehlt.

Viele Gruesse,
Stephan

[Gnu_]

Hallo zusammen,

ich möchte das ganze nochmal aufgreifen, weil ich genau das selbe Problem habe.

Mein Arduino schläft und wird auch von den interrupts meines Windsensors aufgeweckt.

Dabei ist mir nun aufgefallen, dass der Arduino verschiedene "Intervalle" schlafen kann (siehe Sleep Klasse in Activity.h)

Code: Alles auswählen

class Sleep : public Idle<ENABLETIMER2> {
public:
  static uint32_t doSleep (uint32_t ticks) {
    uint32_t offset = 0;
    period_t sleeptime = SLEEP_FOREVER;

    if( ticks > seconds2ticks(8) ) { offset = seconds2ticks(8); sleeptime = SLEEP_8S; }
//    else if( ticks > seconds2ticks(4) )  { offset = seconds2ticks(4);  sleeptime = SLEEP_4S; }
//    else if( ticks > seconds2ticks(2) )  { offset = seconds2ticks(2);  sleeptime = SLEEP_2S; }
    else if( ticks > seconds2ticks(1) )  { offset = seconds2ticks(1);  sleeptime = SLEEP_1S; }
//    else if( ticks > millis2ticks(500) ) { offset = millis2ticks(500); sleeptime = SLEEP_500MS; }
//    else if( ticks > millis2ticks(250) ) { offset = millis2ticks(250); sleeptime = SLEEP_250MS; }
    else if( ticks > millis2ticks(120) ) { offset = millis2ticks(120); sleeptime = SLEEP_120MS; }
//    else if( ticks > millis2ticks(60)  ) { offset = millis2ticks(60);  sleeptime = SLEEP_60MS; }
//    else if( ticks > millis2ticks(30)  ) { offset = millis2ticks(30);  sleeptime = SLEEP_30MS; }
    else if( ticks > millis2ticks(15)  ) { offset = millis2ticks(15);  sleeptime = SLEEP_15MS; }

    if( ENABLETIMER2 == false ) {
      LowPower.powerDown(sleeptime,ADC_OFF,BOD_OFF);
    }
    else {
      LowPower.powerExtStandby(sleeptime,ADC_OFF,BOD_OFF,TIMER2_ON);
    }
    return offset;
  }

Das intervall wählt er basierend auf der "Restzeit" die noch zu schlafen ist. Z.b. bei 60 Sekunden wählt er zunächst immer die "8 Sekunden" (800 Ticks) aus. Wenn jetzt ein Interrupt kommt, ist der Fehler (offset) maximal 8 Sekunden falsch. Das ist enorm.

Wenn ich jetzt aber alles auskommentiere und immer das kleinste Intervall (15 ms) schlafen lasse, so ist der Fehler in der Offset-Berechnung nur maximal 15ms, was mir nicht weh tut!

Jetzt ist die Frage, ob das kleine Intervalll auf Dauer schädlich ist, oder nicht..