CUL SlowRF hängt -> kein in PLL lock

[grobiballon]

Hallo,

die letzte Version von noansi läuft auch unproblematisch. Es gibt nur das PLL0 reporting. Die anderen PLL-Nachrichten erscheinen nicht. Ich würde mir wünschen wenn du Rudolf, diese Modifikationen in ein Release einbauen könntest. Leider hören meine Programmierkenntnisse bei QBASIC auf  weshalb ich Euch hier nicht weiterhelfen kann. Als Testobjekt stehe ich weiterhin gerne zur Verfügung.

Vielen Dank an Euch Beide für die Mühen die Ihr in dieses Projekt steckt!

Gruß, Andreas

[noansi]

Hallo Rudolf,

- es aendert vieles, was mit dem Problem nichts zu tun hat (Kommentare, Formatierung etc). So kann ich es gar nicht pruefen.

Ja, kann ich bezüglich etwas erhöhtem Aufwand verstehen. Aber ich habe versucht es strukturiert aufzubauen und mit Kommentaren verständlich zu machen (schon aus Eigennutz, denn mit zunehmender Weisheit steigt auch die Vergesslichkeit  ).
Es ist halt eine Sammlung verschiedener RX/TX Umschalt- und Prüfmöglichkeiten für den CC1101 PLL Lockzustand. Die defines geben die Möglichkeit der Auswahl bzw. Speicherplatzminimierung, um auch CULV2 noch eine Chance zu lassen (sofern generell genug freie Bytes raus zu quetschen sind).
Deswegen gibt es in cc1101_pllcheck.h eine Erklärung der möglichen defines und dann noch ein Abhängigkeitscheck, der fehlende ggf. ergänzt, damit es auch zu kompilieren ist.

- der Loesungsaufwand ist im Verhaeltnis zur Aufgabe viel zu gross. Ein 5-Zeiler, der CC1100_FSCAL1 auf 0x3f prueft, und dann set_ccoff/ccRX aufruft, muesste reichen. Ja, man verliert die detailliertere Debug-Ausgabe, aber der Code bleibt verstaendlich, und klein. Am besten aus clock.c/Minute_Task aufgerufen, dann profitieren alle Protokolle davon, und die  MCU pollit die CC1101 nicht dauernd.

Nun ccRX und ccTX werden häufiger über die verschiedenen Module verwendet. Um nicht alle anpacken zu müssen, und trotzdem bei jeder Umschaltung direkt prüfen zu können, habe ich in cc1100.h/-.c die Abfrage der defines HAS_CC1101_TX_INTDIS und HAS_CC1101_RX_INTEN ergänzt, damit der Präprozessor einfach den Modulaufruftext umwandelt.
Werden die beiden nicht in board.h definiert, dann wird die alte Variante benutzt, wie bekannt.
Das nach einer Kalibrierung der Lockzustand überprüft werden sollte, steht auch in den Chipdokus, hatte ich schon mal erwähnt, meine ich. Und daher ist das die Lösung mit den Nägeln mit Köpfen (für CULV2 platztechnisch leider nicht in allen Varianten, deswegen für das Kompilieren abschaltbar, ist ja nicht jeder Chip so empfindlich).

Wenn jemand einen superempfindlichen cc1101 hat, dann kann auch der Recoverversuch schief gehen und daher gibt es die Testcheckfunktionen sowohl für RX, als auch mit etwas Blick nach vorne auch für TX.

Der Taskcheck auf PLL-Lock im RX Zustand kommt mit den Änderungen nur im RfAnalyze_Task (rf_receive.c) und rf_asksin_task (rf_asksin.c) vor und prüft auch nur, wenn jeweils die Empfangsfunktionalität aktiviert ist. Also effektiv einmal pro Hauptschleifendurchlauf. Aus meiner Sicht sollte der Chip möglichst schnell wieder auf Empfang gehen, egal ob im Slow-RF, Fast-RF oder ASKSIN. Ansonsten ist die gesparte Zeit nichts Wert (für die mit empfindlichem cc1101).

In der Prüfung selbst wird auch erst nachgeschaut, ob der cc1101 im Empfangszustand ist und nur dann wird auch das SCAL1 Register geprüft. So gesehen kann man es generell einmal als Task in die Hauptschleife einbauen und bei asksin und Slow-RF wieder raus werfen. Das hatte ich schon mal vorgeschlagen, wurde aber abgelehnt, da damals nicht bekannt war, dass auch andere Modi betroffen sein können.
Wenn man bei jeder Zustandumschaltung noch den letzten Zustand in einer globalen Variablen ablegen würde, dann könnte auch das Lesen des MARCSTATE Registers dafür entfallen, nur muss dann auch jeder die Umschaltroutinen benutzen. Ich fürchte, dass ist so nicht ganz realistisch, so weit ich es im Code bisher gesehen habe.

Wenn man es komplett einbaut, braucht man die Debugausgabe nicht zwingend und kann sie per löschen der defines dazu aus dem Kompilat entfernen.
Derzeit werden es die Betroffenen gar nicht merken, das sie es sind und tauschen Netzteile, suchen die Schuld beim Rechner, versuchen Störsender zu minimieren etc. . Das grobiballon überhaupt auf dieses Problem, respektive die Threads dazu gestoßen ist, ist schon ein günstiger Zufall für ihn.

Für die Umschaltung nach TX mit CCA ist eine eigene Variante erforderlich, respektive es fehlen noch die Varianten mit Interrupt, wenn sie mal jemand benutzen möchte. Und streng genommen sind sie dafür noch nicht ganz sauber, weil eigentlich zur Problembehebung erst mal nach IDLE, dann nach RX und dann erst wieder nach TX geschaltet werden dürfte, damit auch dann der CCA wieder durchgeführt wird.
Hier ist in jedem Fall ein einstellbarer Timeout sinnvoll, da ich selber schon über den Watchdog gemerkt habe, dass das bei ASKSIN recht lang werden kann (was auch immer da so lange gesendet oder gestört hat).

set_ccoff/ccRX darfst Du zur Problemlösung nicht aufrufen, weil Du entweder was Abschaltest, was Du gar nicht willst (asksin, moritz, ccon) oder den Interrupt aktivierst, was in ASKSIN nicht willkommen ist, da dort gepollt wird und Slow-RF damit nichts zu tun hat. Respektive es wird Folgecode erforderlich und das für jedes Modul was sich noch einer ausdenkt.

Man könnte die Autocalibrierung rauswerfen und das auf eine Umschaltvariante, also nach RX, mit manueller Kalibrierung beschränken und somit auch die Prüfung. Eigentlich wird sie auch nur dann gebraucht, wenn die Chiptemperatur oder Spannungsversorgung deutlich schwankt, wenn ich die Chipdoku da richtig verstanden habe. Nur wer berücksichtigt das in Zukunft immer und benutzt die Umschaltroutinen?

Aus unter anderem diesen Gründen ist das ganze so umfangreich geworden, auch, wenn es erst nicht danach aussieht. Viel aufwändiger ist aber, erst mal das Problem zu ergründen, wenn man es hat.

Gruß, Ansgar.

[grobiballon]

Viel aufwändiger ist aber, erst mal das Problem zu ergründen, wenn man es hat.

Das habe ich gemerkt  .

Wenn ich die Tage Zeit habe beteilige ich mich auch mal mit meinen bescheidenen Möglichkeiten und füge einen Eintrag in das FHEMwiki unter bekannte Probleme. Dann haben es andere in Zukunft einfacher.

Gruß, Andreas

[grobiballon]

Hallo,

ich habe seit Beginn der Tests zwei PLL1-Meldungen erhalten. Hier ein Log als Beispiel:

Code Auswählen Erweitern

2014.09.30 10:25:15 5: CUL_0: T020300B000 -49
2014.09.30 10:25:15 5: CUL_0 dispatch 810c04xx0909a00102030000b000
2014.09.30 10:25:15 4: FHT hz.Kueche actuator: 0%
2014.09.30 10:25:15 5: Triggering hz.Kueche (1 changes)
2014.09.30 10:25:15 5: Notify loop for hz.Kueche actuator: 0%
2014.09.30 10:25:15 4: eventTypes: FHT hz.Kueche actuator: 0% -> actuator: .*%
2014.09.30 10:25:38 5: CUL/RAW: /T020400BA000A

2014.09.30 10:25:38 5: CUL_0: T020400BA00 -69
2014.09.30 10:25:38 5: CUL_0 dispatch 810c04xx0909a00102040000ba00
2014.09.30 10:25:38 4: FHT hz.Wohnzimmer actuator: 0%
2014.09.30 10:25:38 5: Triggering hz.Wohnzimmer (1 changes)
2014.09.30 10:25:38 5: Notify loop for hz.Wohnzimmer actuator: 0%
2014.09.30 10:25:38 4: eventTypes: FHT hz.Wohnzimmer actuator: 0% -> actuator: .*%
2014.09.30 10:27:04 5: CUL/RAW: /T020100BA00F1

2014.09.30 10:27:04 5: CUL_0: T020100BA00 -81.5
2014.09.30 10:27:04 5: CUL_0 dispatch 810c04xx0909a00102010000ba00
2014.09.30 10:27:04 4: FHT hz.Schlafzimmer actuator: 0%
2014.09.30 10:27:04 5: Triggering hz.Schlafzimmer (1 changes)
2014.09.30 10:27:04 5: Notify loop for hz.Schlafzimmer actuator: 0%
2014.09.30 10:27:04 4: eventTypes: FHT hz.Schlafzimmer actuator: 0% -> actuator: .*%
2014.09.30 10:27:05 5: CUL/RAW: /T02014269DEF1

2014.09.30 10:27:05 5: CUL_0: T02014269DE -81.5
2014.09.30 10:27:05 5: CUL_0 dispatch 810c04xx0909a0010201420069de
2014.09.30 10:27:05 5: CUL/RAW: /T0201436900F1

2014.09.30 10:27:05 5: CUL_0: T0201436900 -81.5
2014.09.30 10:27:05 5: CUL_0 dispatch 810c04xx0909a001020143006900
2014.09.30 10:27:05 4: FHT hz.Schlafzimmer measured-temp: 22.2
2014.09.30 10:27:05 5: Triggering hz.Schlafzimmer (2 changes)
2014.09.30 10:27:05 5: Notify loop for hz.Schlafzimmer measured-temp: 22.2
2014.09.30 10:27:05 4: eventTypes: FHT hz.Schlafzimmer measured-temp: 22.2 -> measured-temp: .*
2014.09.30 10:27:05 4: eventTypes: FHT hz.Schlafzimmer temperature: 22.2 -> temperature: .*
2014.09.30 10:27:05 5: CUL/RAW: /T0201446900F1

2014.09.30 10:27:05 5: CUL_0: T0201446900 -81.5
2014.09.30 10:27:05 5: CUL_0 dispatch 810c04xx0909a001020144006900
2014.09.30 10:27:05 4: FHT hz.Schlafzimmer battery: ok
2014.09.30 10:27:05 4: FHT hz.Schlafzimmer lowtemp: ok
2014.09.30 10:27:05 4: FHT hz.Schlafzimmer window: closed
2014.09.30 10:27:05 4: FHT hz.Schlafzimmer windowsensor: ok
2014.09.30 10:27:05 4: FHT hz.Schlafzimmer warnings: none
2014.09.30 10:27:05 5: Triggering hz.Schlafzimmer (5 changes)
2014.09.30 10:27:05 5: Notify loop for hz.Schlafzimmer battery: ok
2014.09.30 10:27:05 4: eventTypes: FHT hz.Schlafzimmer battery: ok -> battery: ok
2014.09.30 10:27:05 4: eventTypes: FHT hz.Schlafzimmer lowtemp: ok -> lowtemp: ok
2014.09.30 10:27:05 4: eventTypes: FHT hz.Schlafzimmer window: closed -> window: closed
2014.09.30 10:27:05 4: eventTypes: FHT hz.Schlafzimmer windowsensor: ok -> windowsensor: ok
2014.09.30 10:27:05 4: eventTypes: FHT hz.Schlafzimmer warnings: none -> warnings: none
2014.09.30 10:27:07 5: CUL/RAW: /PLL0

2014.09.30 10:27:07 5: CUL_0: PLL0
2014.09.30 10:27:07 5: Triggering CUL_0 (1 changes)
2014.09.30 10:27:07 5: Notify loop for CUL_0 UNKNOWNCODE PLL0
2014.09.30 10:27:07 4: eventTypes: CUL CUL_0 UNKNOWNCODE PLL0 -> UNKNOWNCODE PLL0
2014.09.30 10:27:07 2: CUL_0: unknown message PLL0
2014.09.30 10:27:07 5: CUL/RAW: /PLL1

2014.09.30 10:27:07 5: CUL_0: PLL1
2014.09.30 10:27:07 5: Triggering CUL_0 (1 changes)
2014.09.30 10:27:07 5: Notify loop for CUL_0 UNKNOWNCODE PLL1
2014.09.30 10:27:07 4: eventTypes: CUL CUL_0 UNKNOWNCODE PLL1 -> UNKNOWNCODE PLL1
2014.09.30 10:27:07 2: CUL_0: unknown message PLL1
2014.09.30 10:27:09 5: CUL/RAW: /T020200B20031

2014.09.30 10:27:09 5: CUL_0: T020200B200 -49.5
2014.09.30 10:27:09 5: CUL_0 dispatch 810c04xx0909a00102020000b200
2014.09.30 10:27:09 4: FHT hz.Badezimmer actuator: 0%
2014.09.30 10:27:09 5: Triggering hz.Badezimmer (1 changes)
2014.09.30 10:27:09 5: Notify loop for hz.Badezimmer actuator: 0%
2014.09.30 10:27:09 4: eventTypes: FHT hz.Badezimmer actuator: 0% -> actuator: .*%
2014.09.30 10:27:11 5: CUL/RAW: /T020300B00032

2014.09.30 10:27:11 5: CUL_0: T020300B000 -49
2014.09.30 10:27:11 5: CUL_0 dispatch 810c04xx0909a00102030000b000
2014.09.30 10:27:11 4: FHT hz.Kueche actuator: 0%
2014.09.30 10:27:11 5: Triggering hz.Kueche (1 changes)
2014.09.30 10:27:11 5: Notify loop for hz.Kueche actuator: 0%
2014.09.30 10:27:11 4: eventTypes: FHT hz.Kueche actuator: 0% -> actuator: .*%
2014.09.30 10:27:34 5: CUL/RAW: /T020400BA000C

2014.09.30 10:27:34 5: CUL_0: T020400BA00 -68
2014.09.30 10:27:34 5: CUL_0 dispatch 810c04xx0909a00102040000ba00
2014.09.30 10:27:34 4: FHT hz.Wohnzimmer actuator: 0%
2014.09.30 10:27:34 5: Triggering hz.Wohnzimmer (1 changes)
2014.09.30 10:27:34 5: Notify loop for hz.Wohnzimmer actuator: 0%
2014.09.30 10:27:34 4: eventTypes: FHT hz.Wohnzimmer actuator: 0% -> actuator: .*%
2014.09.30 10:29:00 5: CUL/RAW: /T020100BA00F1

2014.09.30 10:29:00 5: CUL_0: T020100BA00 -81.5
2014.09.30 10:29:00 5: CUL_0 dispatch 810c04xx0909a00102010000ba00
2014.09.30 10:29:00 4: FHT hz.Schlafzimmer actuator: 0%
2014.09.30 10:29:00 5: Triggering hz.Schlafzimmer (1 changes)
2014.09.30 10:29:00 5: Notify loop for hz.Schlafzimmer actuator: 0%
2014.09.30 10:29:00 4: eventTypes: FHT hz.Schlafzimmer actuator: 0% -> actuator: .*%
2014.09.30 10:29:05 5: CUL/RAW: /T020200B20030

2014.09.30 10:29:05 5: CUL_0: T020200B200 -50
2014.09.30 10:29:05 5: CUL_0 dispatch 810c04xx0909a00102020000b200
2014.09.30 10:29:05 4: FHT hz.Badezimmer actuator: 0%
2014.09.30 10:29:05 5: Triggering hz.Badezimmer (1 changes)
2014.09.30 10:29:05 5: Notify loop for hz.Badezimmer actuator: 0%
2014.09.30 10:29:05 4: eventTypes: FHT hz.Badezimmer actuator: 0% -> actuator: .*%
2014.09.30 10:29:06 5: CUL/RAW: /T02024269E830

2014.09.30 10:29:06 5: CUL_0: T02024269E8 -50
2014.09.30 10:29:06 5: CUL_0 dispatch 810c04xx0909a0010202420069e8
2014.09.30 10:29:06 5: CUL/RAW: /T020243690030

2014.09.30 10:29:06 5: CUL_0: T0202436900 -50
2014.09.30 10:29:06 5: CUL_0 dispatch 810c04xx0909a001020243006900
2014.09.30 10:29:06 4: FHT hz.Badezimmer measured-temp: 23.2
2014.09.30 10:29:06 5: Triggering hz.Badezimmer (2 changes)
2014.09.30 10:29:06 5: Notify loop for hz.Badezimmer measured-temp: 23.2
2014.09.30 10:29:06 4: eventTypes: FHT hz.Badezimmer measured-temp: 23.2 -> measured-temp: .*
2014.09.30 10:29:06 4: eventTypes: FHT hz.Badezimmer temperature: 23.2 -> temperature: .*
2014.09.30 10:29:06 5: CUL/RAW: /T020244690030

2014.09.30 10:29:06 5: CUL_0: T0202446900 -50
2014.09.30 10:29:06 5: CUL_0 dispatch 810c04xx0909a001020244006900
2014.09.30 10:29:06 4: FHT hz.Badezimmer battery: ok
2014.09.30 10:29:06 4: FHT hz.Badezimmer lowtemp: ok
2014.09.30 10:29:06 4: FHT hz.Badezimmer window: closed
2014.09.30 10:29:06 4: FHT hz.Badezimmer windowsensor: ok
2014.09.30 10:29:06 4: FHT hz.Badezimmer warnings: none
2014.09.30 10:29:06 5: Triggering hz.Badezimmer (5 changes)
2014.09.30 10:29:06 5: Notify loop for hz.Badezimmer battery: ok
2014.09.30 10:29:06 4: eventTypes: FHT hz.Badezimmer battery: ok -> battery: ok
2014.09.30 10:29:06 4: eventTypes: FHT hz.Badezimmer lowtemp: ok -> lowtemp: ok
2014.09.30 10:29:06 4: eventTypes: FHT hz.Badezimmer window: closed -> window: closed
2014.09.30 10:29:06 4: eventTypes: FHT hz.Badezimmer windowsensor: ok -> windowsensor: ok
2014.09.30 10:29:06 4: eventTypes: FHT hz.Badezimmer warnings: none -> warnings: none
2014.09.30 10:29:08 5: CUL/RAW: /T020300B00032

2014.09.30 10:29:08 5: CUL_0: T020300B000 -49
2014.09.30 10:29:08 5: CUL_0 dispatch 810c04xx0909a00102030000b000
2014.09.30 10:29:08 4: FHT hz.Kueche actuator: 0%
2014.09.30 10:29:08 5: Triggering hz.Kueche (1 changes)
2014.09.30 10:29:08 5: Notify loop for hz.Kueche actuator: 0%
2014.09.30 10:29:08 4: eventTypes: FHT hz.Kueche actuator: 0% -> actuator: .*%
2014.09.30 10:29:31 5: CUL/RAW: /T020400BA0007

2014.09.30 10:29:31 5: CUL_0: T020400BA00 -70.5
2014.09.30 10:29:31 5: CUL_0 dispatch 810c04xx0909a00102040000ba00
2014.09.30 10:29:31 4: FHT hz.Wohnzimmer actuator: 0%
2014.09.30 10:29:31 5: Triggering hz.Wohnzimmer (1 changes)
2014.09.30 10:29:31 5: Notify loop for hz.Wohnzimmer actuator: 0%
2014.09.30 10:29:31 4: eventTypes: FHT hz.Wohnzimmer actuator: 0% -> actuator: .*%
2014.09.30 10:31:01 5: CUL/RAW: /T020200B20030

2014.09.30 10:31:01 5: CUL_0: T020200B200 -50
2014.09.30 10:31:01 5: CUL_0 dispatch 810c04xx0909a00102020000b200
2014.09.30 10:31:01 4: FHT hz.Badezimmer actuator: 0%
2014.09.30 10:31:01 5: Triggering hz.Badezimmer (1 changes)
2014.09.30 10:31:01 5: Notify loop for hz.Badezimmer actuator: 0%
2014.09.30 10:31:01 4: eventTypes: FHT hz.Badezimmer actuator: 0% -> actuator: .*%
2014.09.30 10:31:04 5: CUL/RAW: /T020300B00031

2014.09.30 10:31:04 5: CUL_0: T020300B000 -49.5
2014.09.30 10:31:04 5: CUL_0 dispatch 810c04xx0909a00102030000b000
2014.09.30 10:31:04 4: FHT hz.Kueche actuator: 0%
2014.09.30 10:31:04 5: Triggering hz.Kueche (1 changes)
2014.09.30 10:31:04 5: Notify loop for hz.Kueche actuator: 0%
2014.09.30 10:31:04 4: eventTypes: FHT hz.Kueche actuator: 0% -> actuator: .*%
2014.09.30 10:31:28 5: CUL/RAW: /T020400BA0003

2014.09.30 10:31:28 5: CUL_0: T020400BA00 -72.5
2014.09.30 10:31:28 5: CUL_0 dispatch 810c04xx0909a00102040000ba00
2014.09.30 10:31:28 4: FHT hz.Wohnzimmer actuator: 0%
2014.09.30 10:31:28 5: Triggering hz.Wohnzimmer (1 changes)
2014.09.30 10:31:28 5: Notify loop for hz.Wohnzimmer actuator: 0%
2014.09.30 10:31:28 4: eventTypes: FHT hz.Wohnzimmer actuator: 0% -> actuator: .*%
2014.09.30 10:32:51 5: CUL/RAW: /T020100BA00F3

2014.09.30 10:32:51 5: CUL_0: T020100BA00 -80.5
2014.09.30 10:32:51 5: CUL_0 dispatch 810c04xx0909a00102010000ba00
2014.09.30 10:32:51 4: FHT hz.Schlafzimmer actuator: 0%
2014.09.30 10:32:51 5: Triggering hz.Schlafzimmer (1 changes)
2014.09.30 10:32:51 5: Notify loop for hz.Schlafzimmer actuator: 0%
2014.09.30 10:32:51 4: eventTypes: FHT hz.Schlafzimmer actuator: 0% -> actuator: .*%
2014.09.30 10:32:57 5: CUL/RAW: /T020200B20030

2014.09.30 10:32:57 5: CUL_0: T020200B200 -50
2014.09.30 10:32:57 5: CUL_0 dispatch 810c04xx0909a00102020000b200
2014.09.30 10:32:57 4: FHT hz.Badezimmer actuator: 0%
2014.09.30 10:32:57 5: Triggering hz.Badezimmer (1 changes)
2014.09.30 10:32:57 5: Notify loop for hz.Badezimmer actuator: 0%
2014.09.30 10:32:57 4: eventTypes: FHT hz.Badezimmer actuator: 0% -> actuator: .*%
2014.09.30 10:33:01 5: CUL/RAW: /T020300B00030

2014.09.30 10:33:01 5: CUL_0: T020300B000 -50
2014.09.30 10:33:01 5: CUL_0 dispatch 810c04xx0909a00102030000b000
2014.09.30 10:33:01 4: FHT hz.Kueche actuator: 0%
2014.09.30 10:33:01 5: Triggering hz.Kueche (1 changes)
2014.09.30 10:33:01 5: Notify loop for hz.Kueche actuator: 0%
2014.09.30 10:33:01 4: eventTypes: FHT hz.Kueche actuator: 0% -> actuator: .*%
2014.09.30 10:33:25 5: CUL/RAW: /T020400BA0003

2014.09.30 10:33:25 5: CUL_0: T020400BA00 -72.5
2014.09.30 10:33:25 5: CUL_0 dispatch 810c04xx0909a00102040000ba00
2014.09.30 10:33:25 4: FHT hz.Wohnzimmer actuator: 0%
2014.09.30 10:33:25 5: Triggering hz.Wohnzimmer (1 changes)
2014.09.30 10:33:25 5: Notify loop for hz.Wohnzimmer actuator: 0%
2014.09.30 10:33:25 4: eventTypes: FHT hz.Wohnzimmer actuator: 0% -> actuator: .*%
2014.09.30 10:33:40 5: CUL/RAW: /T02014269DEF1

2014.09.30 10:33:40 5: CUL_0: T02014269DE -81.5
2014.09.30 10:33:40 5: CUL_0 dispatch 810c04xx0909a0010201420069de
2014.09.30 10:33:41 5: CUL/RAW: /T0201436900F0

2014.09.30 10:33:41 5: CUL_0: T0201436900 -82
2014.09.30 10:33:41 5: CUL_0 dispatch 810c04xx0909a001020143006900
2014.09.30 10:33:41 4: FHT hz.Schlafzimmer measured-temp: 22.2
2014.09.30 10:33:41 5: Triggering hz.Schlafzimmer (2 changes)
2014.09.30 10:33:41 5: Notify loop for hz.Schlafzimmer measured-temp: 22.2
2014.09.30 10:33:41 4: eventTypes: FHT hz.Schlafzimmer measured-temp: 22.2 -> measured-temp: .*
2014.09.30 10:33:41 4: eventTypes: FHT hz.Schlafzimmer temperature: 22.2 -> temperature: .*
2014.09.30 10:33:41 5: CUL/RAW: /T0201446900F1

2014.09.30 10:33:41 5: CUL_0: T0201446900 -81.5
2014.09.30 10:33:41 5: CUL_0 dispatch 810c04xx0909a001020144006900
2014.09.30 10:33:41 4: FHT hz.Schlafzimmer battery: ok
2014.09.30 10:33:41 4: FHT hz.Schlafzimmer lowtemp: ok
2014.09.30 10:33:41 4: FHT hz.Schlafzimmer window: closed
2014.09.30 10:33:41 4: FHT hz.Schlafzimmer windowsensor: ok
2014.09.30 10:33:41 4: FHT hz.Schlafzimmer warnings: none
2014.09.30 10:33:41 5: Triggering hz.Schlafzimmer (5 changes)
2014.09.30 10:33:41 5: Notify loop for hz.Schlafzimmer battery: ok
2014.09.30 10:33:41 4: eventTypes: FHT hz.Schlafzimmer battery: ok -> battery: ok
2014.09.30 10:33:41 4: eventTypes: FHT hz.Schlafzimmer lowtemp: ok -> lowtemp: ok
2014.09.30 10:33:41 4: eventTypes: FHT hz.Schlafzimmer window: closed -> window: closed
2014.09.30 10:33:41 4: eventTypes: FHT hz.Schlafzimmer windowsensor: ok -> windowsensor: ok
2014.09.30 10:33:41 4: eventTypes: FHT hz.Schlafzimmer warnings: none -> warnings: none
2014.09.30 10:34:46 5: CUL/RAW: /T020100BA00F2

2014.09.30 10:34:46 5: CUL_0: T020100BA00 -81
2014.09.30 10:34:46 5: CUL_0 dispatch 810c04xx0909a00102010000ba00
2014.09.30 10:34:46 4: FHT hz.Schlafzimmer actuator: 0%
2014.09.30 10:34:46 5: Triggering hz.Schlafzimmer (1 changes)
2014.09.30 10:34:46 5: Notify loop for hz.Schlafzimmer actuator: 0%
2014.09.30 10:34:46 4: eventTypes: FHT hz.Schlafzimmer actuator: 0% -> actuator: .*%
2014.09.30 10:34:53 5: CUL/RAW: /T020200B20031

2014.09.30 10:34:53 5: CUL_0: T020200B200 -49.5
2014.09.30 10:34:53 5: CUL_0 dispatch 810c04xx0909a00102020000b200
2014.09.30 10:34:53 4: FHT hz.Badezimmer actuator: 0%
2014.09.30 10:34:53 5: Triggering hz.Badezimmer (1 changes)
2014.09.30 10:34:53 5: Notify loop for hz.Badezimmer actuator: 0%
2014.09.30 10:34:53 4: eventTypes: FHT hz.Badezimmer actuator: 0% -> actuator: .*%
2014.09.30 10:34:54 5: CUL/RAW: /T02024269E830

2014.09.30 10:34:54 5: CUL_0: T02024269E8 -50
2014.09.30 10:34:54 5: CUL_0 dispatch 810c04xx0909a0010202420069e8
2014.09.30 10:34:54 5: CUL/RAW: /T020243690030

2014.09.30 10:34:54 5: CUL_0: T0202436900 -50
2014.09.30 10:34:54 5: CUL_0 dispatch 810c04xx0909a001020243006900
2014.09.30 10:34:54 4: FHT hz.Badezimmer measured-temp: 23.2
2014.09.30 10:34:54 5: Triggering hz.Badezimmer (2 changes)
2014.09.30 10:34:54 5: Notify loop for hz.Badezimmer measured-temp: 23.2
2014.09.30 10:34:54 4: eventTypes: FHT hz.Badezimmer measured-temp: 23.2 -> measured-temp: .*
2014.09.30 10:34:54 4: eventTypes: FHT hz.Badezimmer temperature: 23.2 -> temperature: .*
2014.09.30 10:34:54 5: CUL/RAW: /T020244690030

Wie zu sehen ist, kommt - wie erwartet - die PLL1 Nachricht direkt nach der PLL0. Die Kommunikation geht danach aber normal weiter. Verstehe ich es richtig, dass wenn mein CUL bei einer PLL1 Nachricht einen schlechten Tag hat er immernoch aus dem Tritt  kommen kann?

Gruß, Andreas

[noansi]

Hallo Andreas,

es sollte mit den Änderungen nicht passieren, dass die Kommunikation einschläft, so lange der CUL sich noch in den PLL-Lock bringen lässt, was offenbar geht. Dafür sorgt der zyklische Test über den Taskaufruf, falls die TX/RX-Umschaltung schief geht.

Wenn er empfindlicher würde, könnte die Kommunikation aber holpriger werden.

Dein Log zeigt aber, dass es passieren kann, dass die erneute Kalibrierung mit Schalten nach IDLE und dann SCAL tatsächlich schief gehen kann und mehrere RX/TX TX/RX Schaltversuche nicht ganz sinnlos sind.

Ist dein CUL eigentlich höheren Temperaturschwamkungen ausgesetzt? Z.B. weil die Sonne drauf scheinen kann?

Gruß, Ansgar.

[noansi]

Hallo Rudolf,

die in der letzten Nachricht von Andreas aufgetretenen PLL-Lock Fehler müssen beim jetzigen Stand bei der Umschaltung nach TX aufgetreten sein.

fht80b_sendpacket schaltet nach IDLE und löst damit die nächste Autokalibrierung aus.

Ich habe es mit meinem Problem-CUL nachgestellt, indem ich mit dem RandomTimer alle 2 Minuten eine K... Temperaturmessage rausgeschickt habe. Ergebnis: 4 Tage lang nichts (da in meiner Umschaltung nach RX bzw TX mit Interrupt kein IDLE vorkommt und damit die Autokalibrierung nicht angestoßen wird, sofern die Umschaltung erfolgreich ist und diese daher jeweils direkt erfolgt). Empfang ist danach immer brav weiter gelaufen.

In ks_send habe ich nun mal testweise zu Anfang ein ccStrobe(CC1100_SIDLE); eingebaut und damit das Verhalten von fht80b_sendpacket nachgestellt.
Im Log tauchen bei mir nun alle paar Stunden PLL0 Einträge auf, d.h. die Umschaltung nach TX klappt nicht immer ohne PLL-Lock Fehler.

Für Andreas würde das ohne Umschalt-Check bedeuten, dass der CUL nicht immer sendet, sprich er dem FHT nicht zuverlässig antworten würde.

Damit macht der PLL-Lock Check bei der State-Umschaltung in beide Richtungen, TX oder RX, Sinn, wenn ich die ASKSIN Erfahrung mit einbeziehe.

In Summe machen also nach jetziger Betrachtung alle Checks Sinn, die ich eingebaut habe. Ob es mit noch weniger Code umzusetzen ist, steht auf einem anderen Blatt. 
Für CULs mit härteren Umgebungsbedingungen (Temperatur und Spannungsschwankungen) würde es noch Sinn machen, zu RX über IDLE zu wechseln und damit regelmäßig eine Kalibrierung zu erzwingen.

Vielleicht ist es noch eine Überlegung wert, den CC1100_OUT_PIN (vgl. cc1101 errata) als Indikator für den PLL Lock zu benutzen, da er ja nur während des Sendens benötigt wird um die Bits raus zu schieben. Dann würde aus dem cc1101 Register Lesen eine Portbitabfrage, die natürlich mit der zusätzlichen Umschaltung der GDO0 Funktion bei der RX/TX Umschaltung erkauft wird. Und da der Pin dann trotz Lock noch toggeln kann (vgl. errata) muss die Flanke noch ausgewertet werden und ein entsprechendes Merkbit bereit gestellt werden. Gefühlt schneller, aber eher mehr Code?!?

Gruß, Ansgar.

[grobiballon]

Hallo,

mein CUL ist eigentlich keinen großen Temperaturschwankungen ausgesetzt. Er steht an einem Ort, wo er keine direkte Sonne abbekommen kann.

Zu Deinen weiteren Ausführungen kann ich leider nichts beitragen. Da hört es dann bei mir auf 

Gruß, Andreas

[noansi]

Hallo Andreas, hallo Rudolf,

ich habe die Änderungen jetzt nochmal überarbeitet.

Wenn ich es richtig gesehen habe, dann ist der Tranceiver in der Hauptschleife immer auf Empfang.
Daher habe ich den zyklischen Check in die Hauptschleife als Task eingebaut (und dementsprechend in rf_receive.c und rf_asksin.c raus genommen).
Es ganz an den Anfang des Minute-Tasks zu legen, wäre auch eine Möglichkeit um die Änderung in CUL.c zu vermeiden.

Die Umschaltung RX und TX mit check habe ich umgebaut und dabei ist mir auch noch eine Unschärfe in meiner letzten Version aufgefallen. Wenn bei der TX Umschaltung ein PLL-Lockproblem auftrat, wurde zwar das Lock-Problem zu beheben versucht, wenn das direkt mit angestoßener Kalibrierung gelang jedoch nicht wieder in TX geschaltet, sondern blieb in IDLE. Das sollte jetzt nicht mehr passieren.

Der Umbau auf Basis von Trunk459 hat dazu geführt, dass auf Kosten der Lesbarkeit wenigstens der zyklische Test/Recover in absoluter Minimalversion und ohne PLL_Meldungen auch für CUL_V2 compilierbar wurde und bei der gcc Version 4.7.2 mit 12176 + 8 Bytes gerade noch so zu flashen sein sollte (Funktion kann ich leider nicht testen, mangels Hardware).

Außerdem habe ich nicht benötigte Funktionen raus geworfen, bis auf einen zyklischen TX Lock Check, falls das doch mal gebraucht würde.

Die Meldungen sind geändert, fangen aber weiterhin mit PLL an und dann kommen zwei hex Ziffern, so dass damit genauer das Auftreten des PLL Problems nachvollziehbar wird (Senden, Empfang, Umschaltung, Recover etc.). PLL01 entspricht dem bisherigen PLL0. Ein TX Recover sollte nun mit PLLB5 auffallen.

@Andreas: wäre schön, wenn Du nochmal testen könntest.

@Rudolf: Damit einfach nachvollziehbar wird, was nach allen #defines im Code übrig bleibt, habe ich #warning Compilerausgaben eingebaut, so dass die aktiven defines ausgegeben werden. Das ist am Anfang von cc1101_pllcheck.h auch abschaltbar.

Gruß, Ansgar.

[grobiballon]

Hallo Ansgar,

Ich bekomme in der letzten Version nur die V2 compiliert. Vielleicht bin ich aber auch einfach nur zu blöde...

Gruß, Anderas

[grobiballon]

Hi,

mit dem aktuellen trunk hat es nun funktioniert. Ich werde berichten...

Gruß, Andreas

[grobiballon]

...es geht schon los:

Code Auswählen Erweitern

2014.10.09 22:07:02 3: set CUL_0 raw B01
2014.10.09 22:07:02 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL_0)
2014.10.09 22:07:30 3: Setting CUL_0 baudrate to 9600
2014.10.09 22:07:30 1: /dev/ttyACM0 reappeared (CUL_0)
2014.10.09 22:07:30 3: CUL_0: Possible commands: BbCFiAZEGMKUYRTVWXefmltux
2014.10.09 22:16:50 2: CUL_0: unknown message PLL01
2014.10.09 22:16:50 2: CUL_0: unknown message PLLB5
2014.10.09 22:33:58 2: CUL_0: unknown message PLL01
2014.10.09 22:33:58 2: CUL_0: unknown message PLLB5
2014.10.09 22:34:46 2: CUL_0: unknown message PLL01
2014.10.09 22:34:46 2: CUL_0: unknown message PLLB5
2014.10.09 22:38:04 2: CUL_0: unknown message PLL01
2014.10.09 22:38:04 2: CUL_0: unknown message PLLB5
2014.10.09 22:38:04 2: CUL_0: unknown message PLL01
2014.10.09 22:38:04 2: CUL_0: unknown message PLLB5

Gruß
Andreas

[noansi]

Hallo Andreas,

PLL01 -> Check auf PLL-Lock hat das Lock Problem aufgedeckt
PLLB5 -> Es ist bei der Umschaltung nach TX aufgetreten, Recover nach RX hat funtkioniert. (Und danach wurde erneut, aber erfolgreich auf TX geschaltet.)

Die Folge kurz hintereinander (gleiche Sekunde) müssen zwei FHT Sendepakete gewesen sein.

Das ist in der Tat recht häufig. Da ein PLLF5 fehlt hat aber jedes mal der Recover funktioniert und somit wurde doch ein funktionierender TX Sendezustand erreicht.
Da ein PLL74 und PLL02 fehlt, hat der RX Recover in cc1101_checkPLL funktioniert. Und der nächste TX Umschaltversuch war erfolgreich.
Bekommst Du jetzt auch mehr Daten rein?

Mein Problem CUL bringt das nicht so häufig (mit dem ergänzten switch nach IDLE am Anfang von ks_send).

Das es nur bei TX passiert liegt an der Umschaltung nach IDLE vor dem FHT Senden, was eine Autokalibrierung bei der Umschaltung nach TX auslöst.

Bekommst Du nun auch mehr/stabiler Daten rein? Wäre zu erwarten, wenn das Senden stabiler funktioniert.
Ist auch noch ein PLL74, PLL02 oder PLLF5 aufgetreten?

Gruß, Ansgar.

[grobiballon]

Hallo Ansgar,

es kommen bis jetzt keine weiteren Meldungen als die PLL01/B5. Ich habe auch nie wirklich Empfangsprobleme gehabt - also es war nicht so, dass ich erwartete regelmäßige Updates der FHTs nicht bekommen habe. Das hat immer funktioniert, bis der CUL es irgendwann mal nicht in den PLL lock geschafft hat.

Also kurzum, deine Modifikation hat nicht den Empfang verbessert, sondern im Wesentlichen sorgt er nur dafür, dass der CUL überhaupt aktiv bleibt. Und letzteres macht dein Patch gut. Auf jeden Fall habe ich seit deiner ersten Modifikation keine Aussetzer mehr gehabt.

Vielleicht sollte man später nur die Meldungen anzeigen lassen, wenn ein Recover nicht geklappt hat (debugging ausgenommen) . Wenn es klappt ist es ja nicht so wild und bedarf keiner Info.

Gruß
Andreas

EDIT: PS: Dieser Therad hat gefühlt im Vergleich zu Anderen eine recht hohe Anzahl an Aufrufen. Gibt es hier noch weitere die ein ähnliches Problem haben, bzw die den Patch angewand haben?

[grobiballon]

Moin,

jetzt gab es auch mal folgendes:

Code Auswählen Erweitern

2014.10.11 23:17:47 2: CUL_0: unknown message PLL01
2014.10.11 23:17:48 2: CUL_0: unknown message PLL74
2014.10.11 23:17:48 2: CUL_0: unknown message PLL02
2014.10.11 23:17:48 2: CUL_0: unknown message PLLB5
2014.10.11 23:17:48 2: CUL_0: unknown message PLL01
2014.10.11 23:17:48 2: CUL_0: unknown message PLLB5

Gruß, Andreas

[noansi]

Hallo Andreas, hallo Rudolf,

Der Log Auszug sagt:

PLL01 -> Check auf PLL-Lock hat das Lock Problem aufgedeckt
PLL74 -> Nach schalten von IDLE auf RX (State RX erreicht) in cc1101_checkPLL() war der Chip nicht in PLL Lock. (Schalten nach IDLE und dann nach RX ist der PLL-Lock Recoverversuch von cc1101_checkPLL(), wenn Autokalibrierung IDLE nach RX/TX aktiv ist)
PLL02 -> Recoverversuch nach RX in cc1101_checkPLL() hat nicht funktioniert (zusammen mit PLL74: obwohl der Chip in RX State ist)
PLLB5 -> das Lock Problem ist beim Umschalten nach TX aufgetreten, es wird (bis zu 254 mal) nochmal versucht nach TX zu schalten
PLL01 -> Check auf PLL-Lock hat das Lock Problem aufgedeckt (neuer Schaltversuch von RX nach TX, aber ohne PLL Lock von vorher!)
PLLB5 -> das Lock Problem ist beim Umschalten nach TX aufgetreten, aber da PLL74 und PLL02 fehlen hat diesmal der Recover nach RX funktioniert. Es wird erneut versucht nach TX zu schalten
keine weiteren Meldungen -> nächster Schaltversuch nach TX war erfolgreich mit PLL Lock.

Das zeigt, dass auch die wiederholten Schalt-/Recover-Versuche Sinn machen, um erfolgreich, d.h. mit PLL-Lock, in den gewünschten Zielzustand zu schalten. Denn ohne den PLL-Lock geht weder Senden noch Empfang.


Damit stellt sich mir nun noch die Frage, die Anzahl der #defines zu reduzieren und den jetzigen Stand zu zementieren, um den Code besser lesbar zu machen oder es in der Form zu lassen, um künftig bei Nutzung nur eines Teils der Funktionen ggf. ein paar Bytes Programmspeicher sparen zu können.

Ergänzen sollte ich noch eine regelmäßige Zwangs-Kalibrierung, z.B. indem das Schalten nach RX in den toRX Funktionen (wegen CCA) immer über ein vorheriges Schalten nach IDLE (oder autocal-unabhängig zusätzlich SCAL) läuft. Denn wenn nur direkt nach TX oder nur direkt nach RX geschaltet wird, was die jeweiligen Schaltfunktionen jetzt regulär machen, dann wird nicht neu (auto)kalibriert.
Notwendig ist das aber nur, wenn Versorgungsspannung oder Temperatur des CC1101 schwanken, vgl. Chip Doku. Damit kommt es zwar vermutlich nicht zu einem Lock Problem, aber unerwünschte Frequenzschwankungen sind möglich.

CC1101 Doku:

The VCO characteristics vary with temperature
and  supply  voltage  changes  as  well  as  the
desired  operating  frequency.  In  order  to
ensure  reliable  operation,  CC1101  includes
frequency synthesizer self-calibration circuitry.
This calibration should be done regularly, and
must be performed after turning on power and
before  using  a  new  frequency  (or  channel).

The frequency synthesizer must be calibrated
regularly.

Since  the  current  calibration  values  are  only
valid  for  a  finite  temperature  range  (typically
±40C) the PLL must be re-calibrated if the lock
indicator does not indicate PLL lock.

Bei COC z.B. der auf dem RasPi montiert ist (meist in einem Gehäuse) gibt es den Warmlauf von kaltem stromlosen System nach Dauerbetrieb, wo immerhin eine Erwärmung um mehrere 10°C möglich ist. Da würde es für den Betrieb mit reinem Empfang (KS300, TX3) sogar Sinn machen, die Kalibrierung nach dem Empfang eines gültigen Datenpakets z.B. alle halbe Stunde (um den Empfang nicht unnötig häufig zu stören) zu erzwingen. (rf_receive: Im Interrupt geht es leider nicht, weil cc1101 Registerzugriffe über die SPI Schnittstelle im Interrupt nicht möglich sind)
Beides kostet natürlich noch einige Bytes mehr Programmspeicher.

Gruß, Ansgar.