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

Entwicklung und Bau von Hardware aller Art, die im HM-Umfeld eingesetzt werden kann

Moderator: Co-Administratoren

HMSteve
Beiträge: 541
Registriert: 20.08.2019, 06:23
Hat sich bedankt: 13 Mal
Danksagung erhalten: 96 Mal

Re: Abhängigkeit Ergebnis FreqTest von Atmega-Takt? Probleme mit HM-LC-Sw1-Pl-DN

Beitrag von HMSteve » 14.06.2023, 06:45

Matsch hat geschrieben:
13.06.2023, 22:31
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
Beiträge: 541
Registriert: 20.08.2019, 06:23
Hat sich bedankt: 13 Mal
Danksagung erhalten: 96 Mal

Re: Abhängigkeit Ergebnis FreqTest von Atmega-Takt? Probleme mit HM-LC-Sw1-Pl-DN

Beitrag von HMSteve » 14.06.2023, 06:51

Horbi hat geschrieben:
13.06.2023, 17:36
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
Beiträge: 201
Registriert: 29.05.2019, 12:51
Hat sich bedankt: 19 Mal
Danksagung erhalten: 65 Mal

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

Beitrag von Horbi » 14.06.2023, 13:12

Matsch hat geschrieben:
13.06.2023, 22:31
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.


HMSteve hat geschrieben:
14.06.2023, 06:45
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.
HMSteve hat geschrieben:
14.06.2023, 06:51
Horbi hat geschrieben:
13.06.2023, 17:36
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
Beiträge: 5695
Registriert: 30.05.2019, 11:37
System: Alternative CCU (auf Basis OCCU)
Wohnort: Chemnitz
Hat sich bedankt: 125 Mal
Danksagung erhalten: 798 Mal

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

Beitrag von Matsch » 14.06.2023, 13:37

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
Beiträge: 6
Registriert: 18.02.2022, 11:15
System: Alternative CCU (auf Basis OCCU)

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

Beitrag von Nighthawk » 28.07.2023, 08:22

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

frank!
Beiträge: 21
Registriert: 09.03.2021, 10:05
System: Alternative CCU (auf Basis OCCU)

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

Beitrag von frank! » 18.06.2024, 17:52

moin,

wenn ich das noch richtig in erinnerung habe, wurden in diesem thread mit dem pll-lock-check nicht alle probleme gelöst.
für die ungelösten empfangsausfälle hilft eventuell folgende beobachtung:

bei meinem cul mit culfw 1.67 führt der default wert (0xFF) im register PKTLEN regelmässig zu RXFIFO_OVERFLOW zuständen.
wahrscheinlich ist das längenbyte beim empfang hin und wieder korrupt.
vielleicht kommt es ja auch zu den im errata dokument von TI beschriebenen hängern im empfangsmodul.

zumindestens sind meine RXFIFO_OVERFLOW zustände seit dem ändern des registers komplett verschwunden.
https://forum.fhem.de/index.php?topic=138543.0

gruss frank

Antworten

Zurück zu „Hardwareentwicklung und Selbstbau von Aktoren und Sensoren“