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

Horbi
Beiträge: 199
Registriert: 29.05.2019, 12:51
Hat sich bedankt: 19 Mal
Danksagung erhalten: 65 Mal

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

Beitrag von Horbi » 25.05.2023, 15:37

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
Beiträge: 537
Registriert: 20.08.2019, 06:23
Hat sich bedankt: 13 Mal
Danksagung erhalten: 95 Mal

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

Beitrag von HMSteve » 25.05.2023, 18:44

Horbi hat geschrieben:
25.05.2023, 15:37
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
Beiträge: 705
Registriert: 22.05.2018, 10:23
Hat sich bedankt: 24 Mal
Danksagung erhalten: 120 Mal

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

Beitrag von papa » 25.05.2023, 19:02

Horbi hat geschrieben:
25.05.2023, 15:37
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.
Anfragen zur AskSin++ werden nur im Forum beantwortet

Horbi
Beiträge: 199
Registriert: 29.05.2019, 12:51
Hat sich bedankt: 19 Mal
Danksagung erhalten: 65 Mal

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

Beitrag von Horbi » 25.05.2023, 19:27

HMSteve hat geschrieben:
25.05.2023, 18:44
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
HMSteve hat geschrieben:
25.05.2023, 18:44
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.
papa hat geschrieben:
25.05.2023, 19:02
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
Beiträge: 537
Registriert: 20.08.2019, 06:23
Hat sich bedankt: 13 Mal
Danksagung erhalten: 95 Mal

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

Beitrag von HMSteve » 25.05.2023, 22:13

Horbi hat geschrieben:
25.05.2023, 19:27
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 :x 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
Beiträge: 199
Registriert: 29.05.2019, 12:51
Hat sich bedankt: 19 Mal
Danksagung erhalten: 65 Mal

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

Beitrag von Horbi » 26.05.2023, 06:52

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
Beiträge: 537
Registriert: 20.08.2019, 06:23
Hat sich bedankt: 13 Mal
Danksagung erhalten: 95 Mal

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

Beitrag von HMSteve » 26.05.2023, 22:20

Horbi hat geschrieben:
26.05.2023, 06:52
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.
Horbi hat geschrieben:
26.05.2023, 06:52
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
Beiträge: 199
Registriert: 29.05.2019, 12:51
Hat sich bedankt: 19 Mal
Danksagung erhalten: 65 Mal

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

Beitrag von Horbi » 29.05.2023, 12:40

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
Beiträge: 537
Registriert: 20.08.2019, 06:23
Hat sich bedankt: 13 Mal
Danksagung erhalten: 95 Mal

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

Beitrag von HMSteve » 05.06.2023, 23:15

Horbi hat geschrieben:
29.05.2023, 12:40
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.

Matsch
Beiträge: 5360
Registriert: 30.05.2019, 11:37
System: Alternative CCU (auf Basis OCCU)
Wohnort: Chemnitz
Hat sich bedankt: 113 Mal
Danksagung erhalten: 722 Mal

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

Beitrag von Matsch » 11.06.2023, 16:43

Ich habe jetzt auch mal eine der Steckdosen (um die es mir ja ursprünglich ging) damit geflasht. Ich betreibe sie zunächst mal an einem Labornetzteil mit 12 V, um Einflüsse durch das Schaltnetzteil auszuschließen.
Zuerst habe ich die Variante ohne CalibratedRadio geflasht. Schon nach 6 h war das Gerät eine Stunde lang nicht mehr erreichbar - wie bekannt.
Nun mit der Calibrierung. Bisher ohne Ausfälle, aber da muß schon noch eine längere Zeit vergehen, bevor man wirklich was aussagen kann. Also demnächst Rückmeldung. Werde auch mal die restlichen 4 Steckdosen umflashen. 5 Tests gleichzeitig bringen vielleicht noch mehr Aussagen.

Antworten

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