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

[Horbi]

Hier mal ein kompletter Satusregister Auszug des CC1101.

Empfang läuft

Code: Alles auswählen

CC: 0x30:0x00, PARTNUM: 0
CC: 0x31:0x14, VERSION: 20
CC: 0x32:0xF2, FREQEST: 242
CC: 0x33:0x00, LQI: 0
CC: 0x34:0xC2, RSSI: 194
CC: 0x35:0x0D, MARCSTATE_RX
CC: 0x36:0x2D, WORTIME1: 45
CC: 0x37:0x0A, WORTIME0: 10
CC: 0x38:0x30, PKTSTATUS, CCA, PQT_REACHED
CC: 0x39:0xCD, VCO_VC_DAC: 205
CC: 0x3A:0x00, TXBYTES: 0
CC: 0x3B:0x00, RXBYTES: 0
CC: 0x3C:0x50, RCCTRL1_STATUS: 80
CC: 0x3D:0x0B, RCCTRL0_STATUS: 11

Empfang geht nicht:

Code: Alles auswählen

CC: 0x30:0x00, PARTNUM: 0
CC: 0x31:0x14, VERSION: 20
CC: 0x32:0x0E, FREQEST: 14
CC: 0x33:0x00, LQI: 0
CC: 0x34:0xE7, RSSI: 231
CC: 0x35:0x0D, MARCSTATE_RX
CC: 0x36:0x10, WORTIME1: 16
CC: 0x37:0x51, WORTIME0: 81
CC: 0x38:0x60, PKTSTATUS, PQT_REACHED, CS
CC: 0x39:0xFF, VCO_VC_DAC: 255
CC: 0x3A:0x00, TXBYTES: 0
CC: 0x3B:0x00, RXBYTES: 0
CC: 0x3C:0x50, RCCTRL1_STATUS: 80
CC: 0x3D:0x08, RCCTRL0_STATUS: 8

Die beiden Punkte die sich unterscheiden sind VCO_VC_DAC und was mir gerade auffällt, auch das CS Flag im Paketstatus.
CS = Carrier sense. Cleared when entering IDLE mode

[HMSteve]

In Kap 14.1 des Datenblattes steht etwas zu automatischer Traegerfrequenznachfuehrung bei FSK, wenn ein Traeger detektiert wird. Ich verstehe das so, dass das Feature deaktiviert ist bei CS=low. Reine Spekulation: Wenn ein Stoersignal nahe dem gewuenschten Traeger CS high werden laesst, zieht die Nachfuehrung den Oszillator weg und der Empfaenger wird fuer unsere Frequenz taub. Koennte das plausibel sein?

Vor Deiner Info zu CS war mein Gedanke, dass man gem. Errata-Doc auch das FSCAL1 config Register auslesen und schauen sollte, ob es != 0x3F ist, was definitiv bedeuten wuerde, dass die PLL ausgerastet ist. Die Bedeutung von VCO_VC_DAC ist ja nirgends richtig beschrieben. Da man den Grund dafuer dann offenbar kaum finden kann, waere somit die von Dir vorgesehene recalib der einzig sinnvolle Weg.

[HMSteve]

Sehr feine Sache, der serielle Input-Parser!
Leider gelingt es mir mit meinem Testboard (das grosse von Gerd, ATMega328P, gruenes chinesisches CC1101-Modul, 1 NiMH-Zelle und MAX1724-33) nicht, das Problem zu reproduzieren. Sehr selten bei hohem Funkaufkommen durch E-Paper-Update im Haus schlaegt der Watchdog an und meldet "RX:nn, CRC failed", aber das Testobjekt bleibt empfangsbereit.
Ich habe mal versucht, einen pull request auf Dein dev branch zu machen, der den Wert von FSCAL1 mit ausgibt. Wenn Du meinen Gedanken auch sinnvoll findest, koenntest Du den ja mal mergen und schauen, was dort ausgegeben wird, wenn das Problem auf Deiner Hardware auftritt. Da ich keinen Trenntrafo da habe, moechte ich nicht an der S26 rumtesten, die das Fehlverhalten zeigt.

Viele Gruesse,
Stephan

[jp112sdl]

Da ich keinen Trenntrafo da habe, moechte ich nicht an der S26 rumtesten, die das Fehlverhalten zeigt.

Ich hatte mir für solche Zwecke, um an 230V-Aktoren ohne angeschlossene Lasten zu basteln, dieses Teil gekauft:
https://www.amazon.de/gp/product/B01AC1YR8W

Kann zwar nur ca. 20W, aber für den Preis und den bedachten Zweck völlig ausreichend.
Kostet zurzeit 16 EUR, ich hatte im letzten Jahr noch fünf Euro mehr bezahlt.

[Matsch]

So, hatte jetzt ein kurioses Ereignis, das ich geneigt bin, auch diesem Thema zuzuordnen.

Vor geraumer Zeit hatte ich ja den Dimmer-Drehsteller von papa ( viewtopic.php?p=724474#p724474 ) nachgebaut. Dieser ist nun fast ein Jahr störungsfrei in Betrieb, doch seit vorgestern zeigt er eine Erscheinung, die sich darin äußert, dass er sich nach einer gewissen Zeit von 1...3 h plötzlich dauerhaft taub stellt. Nichts geht mehr, kein Drehen, kein Drücken. LED bleibt finster.

Zunächst hatte ich den Verdacht, das (chinesische) Netzteil hat eine Hacke. Bestätigte sich aber nicht, die Spannung steht eisern und korrekt an.
Die Logik-LP am Labornetzteil schien aber auch zu funktionieren - aber fuhr dann nach längerer Zeit doch wieder fest. Hardwaremäßig war nichts feststellbar.
Ich habe deshalb mal versucht, die neueste dev-trilu Version zu flashen. Bis jetzt ( ca. 20 h) funktioniert der Steller wieder ohne Probleme.

Nur, warum passierte das nach fast einem Jahr, permanent reproduzierbar? Da sich in dem Homematic-System lange nichts mehr geändert hat, weder Geräte örtlich verändert oder hinzugekommen sind - was könnte die Ursache sein? Naheliegend ist ja wieder ein funktechnisches Problem.
Was hat sich im "Äther" verändert?

Was habe ich in den letzten Tagen gemacht? Richtig, ich habe in der Hauptverteilung der Wohnung einen Unterzähler Eastron SDM72D-M-2 (saldierender Zweirichtungszähler) wegen eines BKWs eingebaut und dessen Daten per seriellem Server EW11 von Modbus RTU (RS485) auf Modbus TCP (WLAN) umgesetzt und diese in der CCU per RedMatic ausgelesen. Hier gibt es einen zeitlichen Zusammenhang und der verwendete Serverstick Elfin EW11 ist nur ca. 2 m vom Steller entfernt. Aber da geht's ja um WLAN 2,4 GHz, nicht um 868 MHz! Da aller 5s die Daten aktualisiert werden, könnte der Funkverkehr womöglich doch einen Einfluß haben? Mir fällt kein anderer zeitlicher Zusammenhang für das plötzliche Auftreten des Problems ein.
Könnten also auch andere Frequenzen außerhalb 868 MHz das Problem verursachen?

Ich beobachte jetzt mal weiter, ob das Problem mit der dev-trilu-Version nun wirklich dauerhaft verschwunden ist.

PS: Wenn ich jetzt die neueste dev-trilu schon mal drauf habe, könnte ich auch das Thema Funksteckdosen damit noch mal testen ...

[Matsch]

Ich hatte mir für solche Zwecke, um an 230V-Aktoren ohne angeschlossene Lasten zu basteln, dieses Teil gekauft:
https://www.amazon.de/gp/product/B01AC1YR8W

Oh, danke für den Tipp! Gerade für die Bastelei an netzbetriebenen HM-Geräten angesichts des Preises durchaus überlegenswert.

[Horbi]

Leider gelingt es mir mit meinem Testboard (das grosse von Gerd, ATMega328P, gruenes chinesisches CC1101-Modul, 1 NiMH-Zelle und MAX1724-33)

Ich glaube der Fehler tritt nur bei Netzteilen auf, mit Batterie oder USB Spannungsversorgung tritt der Fehler bei mir auch nicht auf.
Ich habe vom FTDI auch VCC nicht angeklemmt, so dass der Strom auch wirklich übers Schaltnetzteil kommt.

Zunächst hatte ich den Verdacht, das (chinesische) Netzteil hat eine Hacke. Bestätigte sich aber nicht, die Spannung steht eisern und korrekt an.

Meine Vermutung liegt mittlerer Weile eher im Bereich der Glitches als in der Funkstrecke.

Nur, warum passierte das nach fast einem Jahr, permanent reproduzierbar? Da sich in dem Homematic-System lange nichts mehr geändert hat, weder Geräte örtlich verändert oder hinzugekommen sind - was könnte die Ursache sein? Naheliegend ist ja wieder ein funktechnisches Problem.
Was hat sich im "Äther" verändert?

Ich habe irgendwo im TI Forum was von den Entkopplungskondensatoren gelesen im Zusammenhang mit Strobe auf dem CSn.
Kondensatoren in Netzteilen altern, vielleicht liegts daran?

Das alles spricht eigentlich für Glitches, oder?

[Matsch]

Meine Vermutung liegt mittlerer Weile eher im Bereich der Glitches als in der Funkstrecke.

Das würde ich an einem Labornetzteil ausschließen, aber auch da tritt es ja auf.

Für mich steht noch die Frage, ob es nicht auch der Hardwareunterschied des Transceivermoduls ist. Bei den Homematic-Modulen befindet sich auf der HF-Seite des CC1101 noch so ein Keramikbaustein in der Antennenleitung, den es auf unseren Modulen nicht gibt. Irgendein Filter, der vielleicht störende Frequenzen nicht nur am Abstrahlen hindert, sondern auch beim Empfang abhält?

CC1101_HM.jpg (43.78 KiB) 437 mal betrachtet

[Horbi]

Hardwareseitig habe ich bei mir nichts bemerkt - ich habe etwa 10 AskSinDuino32 Dimmer im Einsatz, 8 funktionieren zuverlässig, zwei nicht.
Das Setup mit dem Schaltnetzteil habe ich für 3 Dimmer im Einsatz. 1 funktioniert, zwei nicht.
Irgendwann hatte ich ein Modul mehrere Tage am FTDI zum Testen, ohne ein Problem. Baue es dann in die Lampe und ein paar Stunden später der erste Hänger.
Könnte jetzt mit dem Standort Funkbedingungen zu tun haben, oder eben mit dem Netzteil.

In Kap 14.1 des Datenblattes steht etwas zu automatischer Traegerfrequenznachfuehrung bei FSK, wenn ein Traeger detektiert wird. Ich verstehe das so, dass das Feature deaktiviert ist bei CS=low. Reine Spekulation: Wenn ein Stoersignal nahe dem gewuenschten Traeger CS high werden laesst, zieht die Nachfuehrung den Oszillator weg und der Empfaenger wird fuer unsere Frequenz taub. Koennte das plausibel sein?

Vor Deiner Info zu CS war mein Gedanke, dass man gem. Errata-Doc auch das FSCAL1 config Register auslesen und schauen sollte, ob es != 0x3F ist, was definitiv bedeuten wuerde, dass die PLL ausgerastet ist. Die Bedeutung von VCO_VC_DAC ist ja nirgends richtig beschrieben. Da man den Grund dafuer dann offenbar kaum finden kann, waere somit die von Dir vorgesehene recalib der einzig sinnvolle Weg.

Code: Alles auswählen

FSCAL1 before forced calib: 3F
calibration forced... - 3398179
FSCAL1 before forced calib: 17

Damit ist dein Verständnis bestätigt, die Frage ist jetzt was machen wir damit
Config lesen oder Status lesen und danach Kalibrieren anstossen...

[papa]

Das muss auf jeden Fall schnellestens rüber in den Master.

Können wir nicht einfach das Rekalibrieren hier anstoßen - https://github.com/pa-pa/AskSinPP/blob/ ... dio.h#L490
Das read() wird ja regelmäßig von pollRadio() aufgerufen. Ist jetzt nichts zum Lesen da - checken wir den Status und rekalibrieren, wenn nötig.
Dann brauchen wir keinen Watchdog usw.

Damit wir da regelmäßig vorbei kommen, müsste hier https://github.com/pa-pa/AskSinPP/blob/ ... ity.h#L109 noch von SLEEP_FOREVER auf SLEEP_8S umgestellt werden.