Probleme mit HM-LC-Sw1-Pl-DN, stochastische längere Kommunikationsausfälle

[HMSteve]

Wenn aber vorher die Kalibrierung wirksam geworden ist, warum habe ich dann keine entsprechende Monitorausgabe erhalten? Das bleibt mir ein Rätsel. Wirkt zwar, aber gibt keine Meldung aus?

Anders ist dann ja nur die zyklische Abfrage des config-Registers, vielleicht “macht” das schon etwas mit dem CC1101 und verhindert das Weglaufen der Kalibrierung? Dokumentiert ist da m.E. aber nichts.

Meine beiden Teststeckdosen zeigen unveraendert nur sehr kurze Kommunikationsstoerungen und sind nicht laengerfristig ganz taub, da teilw. im Umkreis weniger Sekunden um den fehlenden Empfang des Schaltbefehls diverse ignorierte Telegramme enpfangen werden gem. seriellem Log. Denke zunehmend, wir suchen zwei unterschiedliche Probleme.

[HMSteve]

Kannst Du mal den seriellen Debugger mit in deinen Sketch nehmen und den Status vom Funkmodul abfragen wenn es zur Störung kommt?

Wuerde ich gern machen, aber das Geraet erkennt die Funkstoerung ja nicht, um genau dann eine Abfrage zu triggern, und nach bspw 1 Minute ist die Stoerung wieder weg. Hast Du da noch etwas dran gebastelt, um bspw einen Interrupt durch ein extern bei erkannter Stoerung zugefuehrtes Signal auszuloesen, oder wie meinst Du das?

[Horbi]

Wenn aber vorher die Kalibrierung wirksam geworden ist, warum habe ich dann keine entsprechende Monitorausgabe erhalten? Das bleibt mir ein Rätsel. Wirkt zwar, aber gibt keine Meldung aus?

Ein Versuch der Erklärung - ich hatte die Sende- und Empfangsroutine etwas verschlankt um ein paar Bytes für das Calibrated Radio zu sparen.
Beim Empfang gibt es folgende Sequenz die das Radio nach dem auslesen des Buffers wieder auf Empfang schaltet:

Code: Alles auswählen

    spi.strobe(CC1101_SFRX);
    _delay_us(190);
    flushrx();
    spi.strobe(CC1101_SRX);

Nach Auslesen des Buffers schaltet der CC1101 sich in IDLE, dann senden wir ein SFRX das nochmal sicherheitshalber den Empfangsbuffer löscht. Es könnte ja sein, das das Paket zu groß war und deshalb im Buffer stehen bleibt.

Im flushrx() wird dann

Code: Alles auswählen

  void flushrx () {
    spi.strobe(CC1101_SIDLE);
    spi.strobe(CC1101_SNOP);
    spi.strobe(CC1101_SFRX);
  }

in den IDLE mode geschaltet (da sind wir zwar eigentlich schon, ausser wir haben den Speicher nicht ausgelesen weil das Paket zu groß war.
Dann ein SNOP, das steht für no operation, gefolgt von SFRX das wieder den Buffer löscht.

Im dev-trilu habe ich das etwas zusammengekürzt:

Code: Alles auswählen

    // clear CC1101 buffer and go back in receive mode
    flushrx();
    spi.strobe(CC1101_SRX); 

Ich habe ja die Theorie das das häufige Strobe auf dem CSN für die Aussetzer verantwortlich ist, bzw dazu beiträgt. Dann sparen wir uns mit der Modifikation bei jedem Empfang einen Strobe Befehl ein, bzw bei jedem zu großem Paket, einen Strobe SFRX im aktiven Empfangsmodus.

Im Sende-Modus wurde das Strobe noch viel stärker genutzt, zum Teil in loops.
Vielleicht tragen die Änderungen bereits dazu bei, das die Aussetzer seltener kommen.

Meine beiden Teststeckdosen zeigen unveraendert nur sehr kurze Kommunikationsstoerungen und sind nicht laengerfristig ganz taub, da teilw. im Umkreis weniger Sekunden um den fehlenden Empfang des Schaltbefehls diverse ignorierte Telegramme enpfangen werden gem. seriellem Log. Denke zunehmend, wir suchen zwei unterschiedliche Probleme.

Ich denke auch du hast ein anderes Problem. Bei dem Kalibrierungsproblem bleibt der Empfänger taub, er bekommt ja keinen externen Trigger mehr für die Rekalibrierung und die zyklischen Statusmeldungen, bei denen gesendet wird, sind definitiv nicht alle paar Minuten.

Kannst Du mal den seriellen Debugger mit in deinen Sketch nehmen und den Status vom Funkmodul abfragen wenn es zur Störung kommt?

Wuerde ich gern machen, aber das Geraet erkennt die Funkstoerung ja nicht, um genau dann eine Abfrage zu triggern, und nach bspw 1 Minute ist die Stoerung wieder weg. Hast Du da noch etwas dran gebastelt, um bspw einen Interrupt durch ein extern bei erkannter Stoerung zugefuehrtes Signal auszuloesen, oder wie meinst Du das?

Nutz doch die zyklische Abfrage des Calibrated Radio in der Radio-CC1101.h.

Code: Alles auswählen

  void recalibrate() {
    uint8_t fscal1val = spi.readReg(CC1101_FSCAL1, CC1101_CONFIG);
    if (fscal1val == 0x3F) {
      DPRINT(F("\nforce calibration - ")); DPRINTLN(millis()); DPRINT('\n');
      spi.strobe(CC1101_SIDLE);
      spi.strobe(CC1101_SCAL);
      spi.strobe(CC1101_SRX);
    }
  }
  

Mit spi.readReg(CC1101_FSCAL1, CC1101_CONFIG) kannst Du Dir ja jedes beliebige Config, oder auch Status Register auslesen und über DPRINT ausgeben. So habe ich ja auch das Kalibrierproblem gefunden.

[Matsch]

Danke für die Erläuterungen.

Momentan wieder auf Calibrated geflasht, keine Aussetzer mehr.
Zunächst hatte ich immer wieder kurze Aussetzer (wohl nur für einen Befehl) bei einer der Steckdosen, allerdings war das auch ein anderes Problem. Im Frequenzkorrekturregister stand (warum auch immer) ein eher schräger Wert (0x65EA). Nochmal FreqTest und dann war ein plausibler Wert drin.
Nun ist wieder Langzeitbeobachtung angesagt.

[Nighthawk]

Hallo zusammen,

gibt es schon Ergebnisse der Langzeitbetrachtung?
Gibt es auch bereits den Code mit den ganzen Optimierungen, den man evtl. breiter testen kann?

Gruß
Alex