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

[Matsch]

Bitte um Aufklärung zur Wirkung des FreqTest:

Ich bin bisher davon ausgegangen, dass im Zuge des FreqTest Abweichungen des CC1101-Bausteins, bedingt durch Quarz- und/oder LC-Toleranzen ermittelt und mittels eines Eintrags in ein Steuerregisters des CC1101 korrigiert werden. Dann dürfte die Taktfrequenz des Atmega keine Rolle spielen.

Wie ist nun folgendes zu erklären:

Seit längerem suche ich ein Problem mit 5 selbstgebauten Steckdosen vom Typ HM-LC-Sw1-Pl-DN-R1-S26. Aber dieses Problem ist ein anderes Thema.
Ich habe den FreqTest bei allen Geräten ausgeführt unter möglichst ungünstigen Abstand. So wurde bei einem Gerät trotz mehrfachem Durchlaufen immer ein Wert von 0x2165E2 ermittelt und gespeichert.

Versuchsweise habe ich nun in diesem Gerät statt der Takt-Originallösung (interner Oszillator) mal einen Resonator 8 MHz bestückt und die Fuses angepaßt.
Nun wieder FreqTest mehrmals unter identischen Randbedingungen laufen lassen. Diesmal ein Wert von 0x2165AA!
Kann mir jemand erklären, wie der Prozessortakt deutliche Auswirkungen auf den Korrekturwert haben kann?

[stan23]

Kann mir jemand erklären, wie der Prozessortakt deutliche Auswirkungen auf den Korrekturwert haben kann?

Nein. Hat er zumindest im Programmablauf nicht.
Ob der ATmega den CC1101 so stark stören kann? Ich glaube es zumindest nicht.

Hast du zufällig einen SDR-Stick und kannst dort die Frequenzen mitschneiden?

[Matsch]

Nein, Stick habe ich nicht.

Ja, das war auch meine Hypothese, dass die unterschiedliche Takterzeugung Auswirkung auf unterschiedliche Empfangstörungen haben könnte. Dass dabei auch das PCB-Layout eine Rolle spielen kann, ist durchaus denkbar.
Prozessor und CC1101 sollten aber aktuell gut abgeblockt sein.

Ich beobachte jetzt mal den Betrieb der Steckdose mit Quarz (bzw. 8 MHz-Resonator CSTCC). Bislang hatte ich nach dem Umbau keine Kommunikationsstörungen mehr mit dem Teil. Die Testzeit ist aber zu kurz, um Schlussfolgerungen zu ziehen.

Vielleicht teste ich danach auch noch mal mit Uhrenquarz.

Sollte es zum beobachteten Gerät neue Erkenntnisse geben, würde ich das dann mal als neuen Beitrag einstellen.
Ich wollte mich nur noch mal vergewissern, dass meine Ansicht nicht falsch ist, dass der Prozessortakt eigentlich keine unmittelbare Auswirkung auf den Test haben kann. Evtl. hat die Art der Takterzeugung aber Einfluß auf Empfangsstörungen.

[HMSteve]

Sollte es zum beobachteten Gerät neue Erkenntnisse geben, würde ich das dann mal als neuen Beitrag einstellen.

Ja, wuerde ich sehr gut finden. Habe auch eine ganze Reihe der normalen S26-Umbauten im Einsatz, einige auch dauerhaft ausserhalb der Weihnachtszeit. Alle habe ich manuell auf 868.3 MHz abgeglichen und nicht den FrequTest benutzt. Dennoch stellen sie sporadisch die Reaktion auf Funksignale ein. Schalte ich sie in dann 1x mit dem Geraetetaster, reagieren sie wieder auf Funksignale unter funktechnisch praktisch identischen Bedingungen. Leider ist das Problem nicht gezielt reproduzierbar…

Viele Gruesse,
Stephan

[Matsch]

Alle habe ich manuell auf 868.3 MHz abgeglichen und nicht den FrequTest benutzt. Dennoch stellen sie sporadisch die Reaktion auf Funksignale ein. Schalte ich sie in dann 1x mit dem Geraetetaster, reagieren sie wieder auf Funksignale unter funktechnisch praktisch identischen Bedingungen.

Ich freue mich, dass es auch noch anderen so geht wie mir.
GENAU deine Schilderung ist auch meine Beobachtung! Völlig stochastisch setzt die Kommunikation aus, durchaus stundenlang. In der Zeit sind sie nicht ansprechbar, antworten nicht und tun nichts. Urplötzlich geht wieder alles, wieder stundenlang.
Und identisch auch meine Beobachtung: Nur einmal die Gerätetaste drücken und schon funktioniert die Kommunikation wieder längere Zeit.

Also wohl doch eher kein Einzelproblem evtl. meiner eigenen Hardware (soweit war ich gedanklich ohnehin schon), sondern irgendein systematisches Problem der Firmware? Zudem spielt auch der Abstand des Gerätes zur Zentrale keine Rolle, passiert weit weg genauso wie nah dran.

Was mich irritiert:
Im Betrieb am Programmieradapter und anzeigen der seriellen Ausgaben wird immer wieder mal eine Meldung angezeigt, die ich so m.E. früher noch nie gesehen habe:

packet too big 39

Es handelt sich dabei um Messages von HmIP-Geräten (verschiedene!), die tatsächlich bis zu 39 Byte lang sind (AskSinAnalyzer), AskSinPP akzeptiert aber wohl nur 28 Byte, scheint aber erstmal alle Bytes in den Empfangspuffer einzulesen.
Hoffentlich kommt es dabei nicht zum Speicherüberlauf des Empfangsbuffers, weiß nicht wie groß der definiert ist.

Bei sehr ähnlichen Projekten wie die Teelicht-/Lichterkettensteuerung HM-LC-SW1-BA-PCB passiert dies nicht, obwohl ja auch die Library Switch.h verwendet wird - allerdings ist das ein Batteriegerät.

[HMSteve]

Weiss nicht, mit welcher AskSin-Version Packet too big kam, wuerde aber erstmal annehmen, dass das beim Einbau der Meldung korrekt behandelt wurde.

Eine zu geringe Feldstaerke an der Empfaengerantenne schliesse ich auch aus, Problem bleibt bestehen, wenn eine direkt verknuepfte Fernbedienung direkt neben dem Aktor betaetigt wird.

Eine unqualifizierte Vermutung waeren noch Oberwellen des eingebauten Netzteils, die den CC1101-Empfaenger dicht machen. Dieser Zustand koennte sich durch Lastaenderung in Folge des Tastendrucks ja aendern. Das messtechnisch nachzuweisen, fehlt mir jedoch Wissen und Equipment. Aber vielleicht hat ja jemand das gleiche Problem und zudem einen Specki mit Schnueffelsonde rumstehen…

Viele Gruesse,
Stephan

[Matsch]

Eine unqualifizierte Vermutung waeren noch Oberwellen des eingebauten Netzteils, die den CC1101-Empfaenger dicht machen.

Schließe ich auch aus. Ich habe ein VIPER06-Netzteil verbaut und auch dieses zuerst in Verdacht. Deshalb habe ich so ein Gerät mal nicht am 230V-Netz betrieben, sondern am 12V-Labornetzteil. Identisches Fehlverhalten, hat keinen Einfluß.

Ich habe mal probeweise in der loop() das Versetzen in Idle auskommentiert, vielleicht liegt es am Aufwecken?
Schien dadurch viel besser zu gehen, aber trat trotzdem noch auf.

Weitere Vermutung: Ungenaue Taktfrequenz, weil interner Oszillator. Deshalb wie schon eingangs geschrieben, Quarz rangebastelt, Fuses angepaßt.
Auch da eine deutliche Verbesserung, aber wieder keine vollständige Heilung. Wieder nur Zufall, da ja nicht reproduzierbar?

[jp112sdl]

Dennoch stellen sie sporadisch die Reaktion auf Funksignale ein. Schalte ich sie in dann 1x mit dem Geraetetaster, reagieren sie wieder auf Funksignale unter funktechnisch praktisch identischen Bedingungen. Leider ist das Problem nicht gezielt reproduzierbar…

Kenn ich auch.
Bei mir reagiert das Gerät plötzlich nicht mehr auf die CCU Telegramme.
Schalte ich 1x mit einem direktverknüpftem Sender, geht es. Und dann auch wieder von der CCU.

Eine Erklärung habe ich auch absolut nicht.

[HMSteve]

Kenn ich auch.
Bei mir reagiert das Gerät plötzlich nicht mehr auf die CCU Telegramme.
Schalte ich 1x mit einem direktverknüpftem Sender, geht es. Und dann auch wieder von der CCU.

Eine Erklärung habe ich auch absolut nicht.

Dann scheint Dein Geraet wenigstens nicht voellig "funktaub" zu werden. Das ist bei mir -soweit bisher beobachtet- anders: Das Geraet reagiert weder auf Telegramme von der CCU noch auf solche eines direkt verknuepften Senders, auch wenn dessen Position geaendert wird, sondern nur noch auf die eigene Geraetetaste. Nach Betaetigung dieser reagiert es wieder auf Funk. Nach laengerem Warten (Minuten oder mehr) reagiert es i.d.R. auch wieder auf Funk ohne zwischenzeitliches Druecken der Geraetetaste.

Unsere Beobachtungen in Summe stuetzen m.E. die These eines fiesen HF-seitigen Problems.

[Matsch]

Kenn ich auch.
Bei mir reagiert das Gerät plötzlich nicht mehr auf die CCU Telegramme.

Noch kurioser:

Testweise laufen bei mir die 5 Geräte an einem Testprogramm, wo alle Geräte, zeitlich gestaffelt, aller 8 min getoggelt werden.
Tritt so ein Fall ein, dass keine Reaktion über das Programm stattfindet, kann ich manchmal (keinesfalls immer) durch einen Befehl aus der Gerätestatus-Seite der WebUI das Gerät aber schalten, obwohl es das eben per Programm nicht tat!
Wieder nur Zufall, dass da gerade kurz vorher die "Heilung" stattfand?

Ich habe immer noch das Gefühl, dass es was mit dem Empfangspuffer bzw. dessen Auswertung zu tun hat. Wenn zufällig vorher eine nicht für das Geräte vorgesehene Message eintrifft und plötzlich die für das Gerät bestimmte dazwischen platzt (ist bei HM ja möglich), dass dann vielleicht das Botschaftsende der ersten Botschaft nicht erkannt wird und das Gerät in der Auswertung hängen bleibt statt diese verunglückte Botschaft zu verwerfen?
Das würde auch die Zufälligkeit erklären.