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

[Horbi]

Ich finde der Timer hat seinen Charm, ich würde nicht 10000 mal pro Sekunde ein Config-Flag über SPI lesen wollen, evtl fangen wir uns durch die Last am Bus wieder andere Probleme ein. Und wenn wir es im Poll begrenzen, brauchts doch wieder einen Timer
Irgendwo hatten wir doch die Info das EQ3 das Modul alle 500ms pollt.

Ich teste jetzt noch ein bisschen weiter, vielleicht kann ja der Buffer Überlauf aus dem Watchdog raus.
Ich sehe zwar ab und an das ein paar Bytes auftauchen und ganz selten wird auch das READ flag gesetzt, dass kann aber auch an dem 50ms Timeout liegen.

[HMSteve]

Ich finde der Timer hat seinen Charm, ich würde nicht 10000 mal pro Sekunde ein Config-Flag über SPI lesen wollen, evtl fangen wir uns durch die Last am Bus wieder andere Probleme ein. Und wenn wir es im Poll begrenzen, brauchts doch wieder einen Timer
Irgendwo hatten wir doch die Info das EQ3 das Modul alle 500ms pollt.

Ich teste jetzt noch ein bisschen weiter, vielleicht kann ja der Buffer Überlauf aus dem Watchdog raus.
Ich sehe zwar ab und an das ein paar Bytes auftauchen und ganz selten wird auch das READ flag gesetzt, dass kann aber auch an dem 50ms Timeout liegen.

Konntest Du den Pufferueberlauf mit Taubheit des Empfaengers in Verbindung bringen? Bei mir stieg er trotz (sehr weniger) Ueberlaeufe nicht aus, demnach koennte der Check also raus. Wuerde dann auch eher das FSCAL1 so selten wie moeglich per Timer ueberwachen. Wenn schon von Uebersprechen vom CSn die Rede ist, sollten wir sicher keine unnoetigen Stoerungen durch hohen Bustraffic generieren, den wir fuer die eigentliche Funktion gar nicht brauchen. Frage ist, ob der WD sogar seltener als 500ms testen kann, wenn wir von i.d.R. mehr als zwei eingestellten Sendewiederholungen bei unseren Geraeten ausgehen (ich hab meist 6).

[papa]

Ich finde der Timer hat seinen Charm, ich würde nicht 10000 mal pro Sekunde ein Config-Flag über SPI lesen wollen, evtl fangen wir uns durch die Last am Bus wieder andere Probleme ein. Und wenn wir es im Poll begrenzen, brauchts doch wieder einen Timer

Müssen halt sehen, wieviel Platz das kostet. Einige Sketche sind beim 328P schon arg an der Grenze.

[Horbi]

Konntest Du den Pufferueberlauf mit Taubheit des Empfaengers in Verbindung bringen? Bei mir stieg er trotz (sehr weniger) Ueberlaeufe nicht aus, demnach koennte der Check also raus.

Ich teste gerade ohne Überlaufschutz

Frage ist, ob der WD sogar seltener als 500ms testen kann, wenn wir von i.d.R. mehr als zwei eingestellten Sendewiederholungen bei unseren Geraeten ausgehen (ich hab meist 6).

Ich denke 500ms ist schon ein guter Mittelweg. Statistisch merken wir Taubheit nach 250ms, dann braucht es knapp 100ms zum kalibrieren.
Das heisst, der Empfänger reagiert nach 350ms wieder. Das ist auch im Moment des Schalter betätigen noch akzeptabel.

Müssen halt sehen, wieviel Platz das kostet. Einige Sketche sind beim 328P schon arg an der Grenze.

Ohne Debug Meldungen bin ich derzeit bei 170 Byte, vielleicht geht weniger wenn ich im Timer auf das SPI Interface zugreife
Aber jetzt testen wir erst mal wie es läuft.

[HMSteve]

Ich teste gerade ohne Überlaufschutz

Ich auch seit ca 15 Minuten mit zwei Schaltbefehlen pro Minute an eine S26. Der WD wertet alle 500ms FSCAL1 aus und rekalibriert bei 0x3F. Bislang 5 Kommunikationsstoerungen Ich dachte wirklich, wir haben's.
Schaust Du auch auf FSCAL1 oder auf VCO_VC_DAC?

Jérôme hat Recht, werde mir einen Trenntrafo bestellen (wenn auch nicht den vergossenen, da bin ich zu skeptisch), und dann hoffentlich uebernaechste Woche richtig testen koennen.

[Horbi]

Prima, kann nicht schaden wenn mehrere testen. Ich teste jetzt nur noch den FSCAL1 auf 3F und recalibriere dann. Klappt bisher ohne Probleme.
Ich meine auch eine Abhängigkeit zwischen Fehlerhäufigkeit und Traffic auf dem SPI Bus zu erkennen, kann aber auch Zufall sein.
Ich werde mir heute Mal Gedanken machen wie ich den Timer nach Radio-cc1101 bekomme und elegant starte. Letztendlich wird er ja nur bei cc1101 Funkmodulen benötigt.

Hast Du ein Log der Kommunikationsstörungen?
Wäre interessant zu sehen was gesendet wird und wie darauf reagiert wird und auch wie viel Funkverkehr generell los ist. Kann ja auch sein das irgendwas überlagert.

Welche Bedenken hast Du bei dem Trenntrafo von Jerome?

[HMSteve]

Hast Du ein Log der Kommunikationsstörungen?
Wäre interessant zu sehen was gesendet wird und wie darauf reagiert wird und auch wie viel Funkverkehr generell los ist. Kann ja auch sein das irgendwas überlagert.

Hab vom gestrigen Test leider kein log. Da die Stoerungen grob geschaetzt 10% der Schaltbefehle betrafen und sechs Versuche eingestellt waren, scheint mir eine Kollision mit anderen Paketen in allen Faellen jedoch eher unwahrscheinlich.

Welche Bedenken hast Du bei dem Trenntrafo von Jerome?

Ich moechte bei so einem sicherheitsrelevanten Teil unbekannter Herkunft gern wenigstens zwei sauber getrennte Wicklungen in separaten Kammern sehen. Das spricht gegen die vergossene Bauweise, bei der man glauben muss, dass nicht zu sehr gespart/gepfuscht wurde, auch wenn sich unter der Vergussmasse eine Trennwand anzudeuten scheint auf dem Foto. Ob der https://www.amazon.de/ELMA-TT-514829-TR ... 003A63GIY/ am Ende ordentlich ist, weiss ich auch noch nicht, werde meinen Eindruck teilen, wenn er da ist.

[Horbi]

So wie es aussieht löst der Calibration Watchdog tatsächlich das Problem der nicht Erreichbarkeit einiger meiner Aktoren.
Holger hatte eine prima Idee bzgl der Konfiguration, bzw. des Einbindens des Watchdogs.
@papa - Danke für die Idee und die Hilfe bei der Umsetzung!

Der Calibrationwatchdog wird ab sofort nicht mehr per #define eingebunden, sondern als "Wrapper" Klasse.

Calibrationwatchdog eingeschaltet sieht dann so aus:

Code: Alles auswählen

typedef CalibratedRadio<RadioSPI, CC1101_GDO0_PIN> RadioType;
typedef AskSin<LedType, NoBattery, RadioType> HalType;

Ohne Calibrationwatchdog:

Code: Alles auswählen

typedef Radio<RadioSPI, CC1101_GDO0_PIN> RadioType;
typedef AskSin<LedType, NoBattery, RadioType> HalType;

[HMSteve]

So wie es aussieht löst der Calibration Watchdog tatsächlich das Problem der nicht Erreichbarkeit einiger meiner Aktoren.

Mir gelingt das Nachstellen des Problems fuer die Loesung bislang leider nicht. Habe als Testaufbau 2 Stueck S26-Umbau am Trenntrafo nebeneinander, eine davon mit der CalibratedRadio-Version am seriellen Monitor. Beide erhalten pro Minute zwei Schaltbefehle, alles versetzt mit krummen Abstaenden, um systematische Funktoerungen zu minimieren. Beide generieren etwa gleich viele Kommunikationsstoerungen.
CCU und Analyzer stehen nah beieinander, aber weit weg von den S26.

• Der Analyzer zeigt im Fall einer Stoerung des ueberwachten Testobjektes vier Sendeversuche der CCU und keine Response des Testobjektes.

• Im rfd-log der CCU finden sich m.E. nichts Spannendes:

  Code: Alles auswählen

  Jun  5 22:29:36 ccu3-webui user.debug rfd: TX:  @2369796196 0xxxxxxx -> 0xyyyyyy CENTRAL_RAMP_START [aaaaaaaaaa]:   CNT=84,RPTEN=1,RPTED=0,BIDI=1,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=0,TYPE=0x11   CHANNEL = 1   LEVEL = 0   RAMPTIME = 0   ONTIME = 0
  Jun  5 22:29:37 ccu3-webui user.debug rfd: (aaaaaaaaaa) Response status: Send failed.
  Jun  5 22:29:37 ccu3-webui user.debug rfd: Event: bbbbbbbbbb:0.UNREACH=true
  Jun  5 22:29:37 ccu3-webui user.debug rfd: HSSXmlRpcEventDispatcher::Handle send 1 events
  Jun  5 22:29:37 ccu3-webui user.debug rfd: HSSXmlRpcEventDispatcher::Handle send 1 events
  Jun  5 22:29:37 ccu3-webui user.debug rfd: Event: bbbbbbbbbb:0.STICKY_UNREACH=true
  Jun  5 22:29:37 ccu3-webui user.debug rfd: SendFrame failed 1 times:  @2369796197 0xxxxxxx -> 0xyyyyyy CENTRAL_RAMP_START [aaaaaaaaaa]:   CNT=84,RPTEN=1,RPTED=0,BIDI=1,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=0,TYPE=0x11   CHANNEL = 1   LEVEL = 0   RAMPTIME = 0   ONTIME = 0
  Jun  5 22:29:37 ccu3-webui user.err rfd: HSSParameter::SetValue() false Put failed
  Jun  5 22:29:37 ccu3-webui local0.warn ReGaHss: WARNING: XMLRPC 'setValue': rpcClient.isFault() failed (url: xmlrpc_bin://127.0.0.1:32001, params: {"bbbbbbbbbb:1","STATE",false}, result: [faultCode:-1,faultString:"Failure"]) [CallXmlrpcMethod():iseXmlRpc.cpp:2608]
  Jun  5 22:29:37 ccu3-webui local0.err ReGaHss: ERROR: XMLRPC 'setValue' call failed (interface: 1007, params: {"bbbbbbbbbb:1","STATE",false}) [CallSetValue():iseXmlRpc.cpp:1505]
  Jun  5 22:29:37 ccu3-webui local0.err ReGaHss: ERROR: rpc.CallSetValue failed; address = bbbbbbbbbb:1 [WriteValue():iseDOMdpHSS.cpp:76]

• Im seriellen Monitor hingegen sieht man den Empfang des Befehls und die Sendung der Antwort.

• Ob die Steckdose trotz der Stoerung schaltet oder irgend etwas tatsaechlich sendet, weiss ich mangels Extra-Monitoring-Hardware nicht.

• Im seriellen Monitor sieht man nie eine forced recalibration.

Fazit: Ich beobachte "ganz normale" Funkstoerungen (vermutlich Reichweitenproblem) und dokumentiere das hier so ausfuehrlich, damit es ggf. Anderen bei der Fehlereingrenzung hilft. Werde bei Gelegenheit mal mit Testsetup naeher an der CCU testen.