Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.43

[yersinia]

eventuell gab es kontaktprobleme bei den steckkontakten durch "korrosion", die durch die mechanischen steckbewegungen beim wechseln verschwunden sind.

kurios aber nicht abwegig und durchaus möglich, denn bisher läuft es unauffällig.

Code Auswählen Erweitern

2024.09.27 10:49:55 1: PERL WARNING: Use of uninitialized value $1 in addition (+) at ./FHEM/10_CUL_HM.pm line 2086.lasse ich in CUL_HM unverändert, weil das nur die erweiterten unknown Readings (letztes Ziel, laufende Anzahl, letzte Länge und RSSI) in der VCCU betrifft und wenn Du die vorhandenen alle nochmal empfangen hast, verschwindet das von selbst.

Imho iO, dann weiss man (ich) zumindest, woher es kommt und wieso es da ist. Danke.

und 98_HMinfo.pm und 98_HMtemplate.pm.

ihgs, da muss ich wohl nochmal ran. Die hab ich übersehen beim Datumsvergleich....

[Ralf9]

Hallo Ansgar,

beim SIGNALduino auf dem ESP32 gibts bei jemanden das Problem, dass es beim Empfang von einem Bresser Wettersensor sporadisch zu Ausfällen kommt.
Der Empfänger ist aktiv und wenn der cc1101 über ein strobe Befehl nach IDLE und wieder nach RX gesetzt wird, empfängt er wieder.
 
Ich habe dazu folgendes gefunden:
"read register 0x25 FSCAL1. The PLL is in lock if the register content is different from 0x3F"

Ich hab bei mir mit einem sduino mit Maple Mini und einem LAN Modul auch mal getestet. Hab dazu eine Abfrage vom FSCAL1 und Ausgabe bei 0x3F eingebaut.
Beim Empfang von einem Temperatursensor mit dem Bresser Protokoll konnte ich es nachvollziehen, wenn der Empfang ausfällt ist FSCAL1 = 0x3F.
Bei einem anderem Protokoll mit Bodenfeuchte Sensoren ist zwar auch sporatisch FSCAL1 = 0x3F, aber es kommt zu keinem Ausfall des Empfangs.

Das ganze ist sehr sporadisch, es kann nach einigen Stunden oder erst nach über einem Tag kommen.

cc1101 Register 0x17 = 0 und Reg 0x18 = 0x18
Nach dem Empfang einer Nachricht geht er nach IDLE und wird dann wieder nach RX gesetzt
Kann es ein Unterschied machen ob er direkt nach RX gesetzt wird oder ob vorher noch ein SFRX (Flush the RX FIFO buffer) gemacht wird.
Das SFRX dürfte eingentlich, wenn kein überlauf, nicht nötig sein.

Ich habe gesehn, dass beim ASKSIN ein Abfrage auf FSCAL1 = 0x3F drin ist.
Gibt es Erkenntnisse was die Ursache für das PLL not locked sein kann?

Gruß Ralf

[noansi]

Hallo Ralf,

schau im CC1101 Manual in Kapitel 22.1. Da steht beschrieben, dass der PLL lock nicht immer erreicht wird und dann erneut kalibriert werden muss. Weiterhin, dass der LOCK verloren gehen kann und (spätestens) dann rekalibriert werden muss.
Es ist als Ursache nur angegeben, dass die kalibrierten Registerwerte nur für einen eigentlich recht großen Temperaturbereich (aber nicht den kompletten Temperaturbereich nach technischen Daten) funktionieren, also starke Temperaturschwankungen für einen LOCK Verlust verantwortlich sein können.

Rein praktisch hat es sich zuer Erhaltung der Empfangsbereitschaft als sinnvoll erwiesen, beim Umschalten von IDLE nach RX (oder TX) AUTOCAL zu nutzen und auch auf LOCK zu prüfen und in größeren regelmäßigen Abständen (nicht ständig) via FSCAL1 Check auf != 0x3f den LOCK zu checken (siehe CC1101 ERRATA Seite 3) und ggf. zu rekalibrieren bis LOCK erreicht ist.

Es gibt Unterschiede zwischen CULs bezüglich der Anfälligkeit für PLL LOCK Verlust und meinen besonders auffälligen Problemkandidaten konnte ich damit zu zuverlässiger Zusammenarbeit überreden. Was konkret zu der erhöhten Anfälligkeit führt, kann ich nicht sagen.

Gruß, Ansgar.