CUL SlowRF hängt -> kein in PLL lock

Begonnen von grobiballon, 24 September 2014, 14:04:22

Vorheriges Thema - Nächstes Thema

grobiballon

Hallo,

ich bin absoluter FHEM & CUL  & Linux-Laie und bin hier vielleicht auf dem Holzweg. Alles was ich hier zu Tage bringe sind Schnipsel die ich irgendwie zusammengesetzt habe. Vielleicht bin ich ja nicht auf dem holzweg, aber wenn etwas nicht stimmt oder unklar beschrieben ist, bitte ich um Verständnis.

Ich habe hier einen CUL FW1.61 am Rpi und der CUL schläft nach einiger Zeit ein. Ich hatte dazu schon einmal etwas geposted, die Sache aber aus den Augen verloren. Nun habe ich mich nochmal ausgiebig damit beschäftigt.

Siehe auch http://forum.fhem.de/index.php/topic,21599.msg150840.html#msg150840

Wenn der CUL nach einiger Zeit (verschieden) "einschläft" kann er durch ein X21 oder ähnlich wieder erweckt werden. Ein C99 ergibt im "eingeschlafenen Zustand" und nach einem X21 folgendes:

vor Stop  0D2E2D07D3913D04320000060021656A35E43023B900070018146C070091876BF85611EF2C3F1F4100597F3F88310B00
nach Stop 0D2E2D07D3913D04320000060021656A35E43023B900070018146C070091876BF85611EF2C161F4100597F3F88310B00
DEC       000102030405060708091011121314151617181920212223242526272829303132333435363738394041424344454647
HEX       000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F
                                                                                    ^^
                                                                                    !!


Dementsprechend ist das Register FSCAL1=x25 -> x3F. Nach Doku des CC1101 ist er damit nicht in PLL lock was aber nach meinem Verständnis für den Betrieb notwendig ist, da er so nicht mehr kalibriert ist.

hier der Putty- "info timer" Log:2014-09-23 20:31:59 FHT hz.Badezimmer actuator: 0%
2014-09-23 20:31:59 FHT hz.Badezimmer actuator: 0%
2014-09-23 20:32:11 FHT hz.Badezimmer start-xmit: 2
2014-09-23 20:32:11 FHT hz.Badezimmer FHZ:start-xmit: 2
2014-09-23 20:32:12 FHT hz.Badezimmer ack2: 2
2014-09-23 20:32:12 FHT hz.Badezimmer FHZ:ack2: 2
2014-09-23 20:32:16 FHT hz.Schlafzimmer actuator: 0%
2014-09-23 20:32:16 FHT hz.Schlafzimmer actuator: 0%
2014-09-23 20:32:16 FHT hz.Schlafzimmer start-xmit: 2
2014-09-23 20:32:17 FHT hz.Schlafzimmer FHZ:start-xmit: 2
2014-09-23 20:32:17 FHT hz.Schlafzimmer measured-temp: 21.7
2014-09-23 20:32:17 FHT hz.Schlafzimmer temperature: 21.7
2014-09-23 20:32:17 FHT hz.Schlafzimmer FHZ:measured-temp: 21.7
2014-09-23 20:32:17 FHT hz.Schlafzimmer ack: 0
2014-09-23 20:32:17 FHT hz.Schlafzimmer FHZ:ack: 0
2014-09-23 20:32:18 FHT hz.Schlafzimmer FHZ:ack: 0
fhem> 2014-09-23 21:47:13 CUL CUL_0 raw X67
2014-09-23 21:47:18 FHT hz.Kueche actuator: 0%
2014-09-23 21:47:18 FHT hz.Kueche actuator: 0%
2014-09-23 21:47:20 FHT hz.Schlafzimmer actuator: 0%
2014-09-23 21:47:20 FHT hz.Schlafzimmer actuator: 0%
2014-09-23 21:47:23 FHT hz.Badezimmer actuator: 0%
2014-09-23 21:47:24 FHT hz.Badezimmer actuator: 0%
2014-09-23 21:47:41 FHT hz.Wohnzimmer actuator: 0%
2014-09-23 21:47:41 FHT hz.Wohnzimmer actuator: 0%
2014-09-23 21:49:14 FHT hz.Kueche actuator: 0%


Kann es sein, dass hier der gleiche Fehler auftritt wie in diesem Thread  http://forum.fhem.de/index.php/topic,23223.0.html beschrieben? Leider ist der PLLcheck nur für die HM Version eingebaut und nicht für die FHT-Version. Es wird wahrscheinlich nur eine kleine Änderung im Code sein - aber dabei hört es bei mir auf. Vielleicht kann mir jemand dabei helfen. Zum Testen (unter Anleitung) bin ich gerne bereit.

Ich habe den rPi mehrmals auf unterschiedliche Arten mit FHEM ausgerüstet. Der CUL wurde mit verschiedenen FW zwischen 1.57 und 1.61 geflashed. Die FHEM-config auf ein absolutes Minimum reduziert und mit verschiedenen FHT's getestet, auch einzeln. Immer das Gleiche. Die Position der Geräte wurden auch verändert. Netzteile habe ich nun schon drei (bis 2A) durch.

Danke und Gruß
Andreas

noansi

#1
Hallo Rudolf,

wenn Du die in der angehängten zip Datei vorhanden Dateien mit den in den Firmware Code aufnimmst und dann

in board.h zum CUL (und anderen board.h)

#define HAS_CC1101_TX_INTDIS
#define HAS_CC1101_RX_INTEN

mit einbaust (und wenn der Platz bei CUL_V2 nicht reicht die entsprechenden #undef)

dann könntest Du grobiballon mit dem PLL check wohl helfen.

mit
#define HAS_CC1101_PLL_LOCK_CHECK_MSG_RXTX

tauchen dann auch entsprechende Problemhinweise dazu im Log auf.

@grobiballon:
Natürlich kannst Du Dir den Quelltext der Firmware auf http://culfw.de runterladen. Und es dann selber versuchen die Firmware mit den Änderungen zu compilieren und zu flashen.

Da es ein seltenes Phänomen mit dem PLL Lock ist, fände ich es besser, es in die offizielle Firmware einfließen zu lassen. Dass sie Umschalten, habe ich mit COC getestet (KS300 gesendet und das kam bei einer IPWE-1 an, anschließend weiter braver Empfang bei COC), ob es gegen das PLL-Lock Problem hilft, kann ich damit nicht testen, da ich normalerweise nur auf Homematic sende. Grundsätzlich ist es aber das gleiche Problem und sollte auf gleichem Weg zu beheben sein.

Gruß, Ansgar.

Edit: alter Anhang gelöscht

noansi

#2
Hallo Rudolf,

und weil der copy&paste Fehlerteufel zugeschlagen hatte hier noch eine kleine Korrektur ergänzt um eine board.h für CUL.
grobiballon hat es kompiliert und im Test und ich bin auf das Feedback gespannt.

Gruß, Ansgar.

Edit: alter Anhang gelöscht

grobiballon

Hallo,

ich habe die Änderungen eingefügt und FHEM läuft wieder. Spätestens nach dem Wochenende sehen wir, ob es was geholfen hat.

Großen Dank an noansi für die geänderten Dateien und die ausfühliche Hilfe für einen Linux-Dummie im Hintergrund.

Gruß, Andreas

noansi

Hallo Rudolf,

noch mal ein Update.
Nun wird nicht nur die RX/TX TX/RX Umschaltung überwacht, sondern auch der PLL-Lock an sich, mit Recover Versuch.
Das machte den kleinen Eingriff in RF-Receive erforderlich, so dass in RF_Analyze_Task regelmässig de Check läuft, wenn der SlowRF Empfang aktiv ist.

Gruß, Ansgar

grobiballon

Hallo,

ich habe die erste von noansi geänderte Version getestet (RX/TX TX/RX Umschaltungsüberwachung). Der CUL hängt wieder, im Log ist aber mal wieder nichts ungewöhnliches (außer das besagte Register). Nach X61 geht es weiter, als wenn nichts gewesen wäre.

2014-09-26 21:27:51 FHT FHT_0202 FHZ:end-xmit: 0T_0202 FHZ:ack: 0
2014-09-26 21:27:51 FHT FHT_0202 battery: ok
2014-09-26 21:27:51 FHT FHT_0202 lowtemp: ok
2014-09-26 21:27:51 FHT FHT_0202 window: closed
2014-09-26 21:27:51 FHT FHT_0202 windowsensor: ok
2014-09-26 21:27:51 FHT FHT_0202 warnings: none
2014-09-26 21:27:51 FHT FHT_0202 battery: ok
2014-09-26 21:27:51 FHT FHT_0202 lowtemp: ok
2014-09-26 21:27:51 FHT FHT_0202 window: closed
2014-09-26 21:27:51 FHT FHT_0202 windowsensor: ok
2014-09-26 21:27:51 FHT FHT_0202 FHZ:warnings: none
2014-09-26 21:27:51 FHT FHT_0202 ack: 0
2014-09-26 21:27:51 FHT FHT_0202 FHZ:ack: 0
2014-09-26 21:27:51 FHT FHT_0202 end-xmit: 0
2014-09-26 21:27:51 FHT FHT_0202 FHZ:end-xmit: 0
2014-09-26 21:27:52 FHT FHT_0202 FHZ:end-xmit: 0
2014-09-26 21:28:16 FHT FHT_0204 actuator: 0%
2014-09-26 21:28:18 FHT FHT_0203 actuator: 0%
2014-09-26 21:28:54 FHT FHT_0202 actuator: 0%
2014-09-26 21:29:36 FHT FHT_0201 actuator: 0%
2014-09-26 21:30:13 FHT FHT_0204 actuator: 0%
2014-09-26 21:30:15 FHT FHT_0203 actuator: 0%
2014-09-26 21:30:49 FHT FHT_0204 start-xmit: 16
2014-09-26 21:30:49 FHT FHT_0204 FHZ:start-xmit: 16
2014-09-26 21:30:50 FHT FHT_0204 measured-temp: 23.9
2014-09-26 21:30:50 FHT FHT_0204 temperature: 23.9
2014-09-26 21:30:50 FHT FHT_0204 FHZ:measured-temp: 23.9
2014-09-26 21:30:51 FHT FHT_0204 FHZ:measured-temp: 23.9


fhem> get CUL_0 raw C99
CUL_0 raw => 0D2E2D07D3913D04320000060021656A55E43023B900070018146C070090876BF85611EF2C3F1F4100597F3F88310B00
fhem> get CUL_0 raw C25
CUL_0 raw => C25 = 3F / 63
fhem> get CUL_0 ccconf
CUL_0 ccconf => freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB
fhem> set CUL_0 raw X61
2014-09-27 10:34:14 CUL CUL_0 raw X61
fhem> 2014-09-27 10:34:42 FHT FHT_0203 actuator: 0%


2014.09.26 21:30:50 5: CUL/RAW: /T02044279EFFA

2014.09.26 21:30:50 5: CUL_0: T02044279EF -77
2014.09.26 21:30:50 5: CUL_0 dispatch 810c04xx0909a0010204420079ef
2014.09.26 21:30:50 5: CUL/RAW: /T020443690033

2014.09.26 21:30:50 5: CUL_0: T0204436900 -48.5
2014.09.26 21:30:50 5: CUL_0 dispatch 810c04xx0909a001020443006900
2014.09.26 21:30:50 4: FHT FHT_0204 measured-temp: 23.9
2014.09.26 21:30:50 5: Triggering FHT_0204 (2 changes)
2014.09.26 21:30:50 5: Notify loop for FHT_0204 measured-temp: 23.9
2014.09.26 21:30:50 4: eventTypes: FHT FHT_0204 measured-temp: 23.9 -> measured-temp: .*
2014.09.26 21:30:50 4: eventTypes: FHT FHT_0204 temperature: 23.9 -> temperature: .*
2014.09.26 21:30:50 5: CUL/RAW: /T0204437900FA

2014.09.26 21:30:50 5: CUL_0: T0204437900 -77
2014.09.26 21:30:50 5: CUL_0 dispatch 810c04xx0909a001020443007900
2014.09.26 21:30:50 4: FHT FHT_0204 FHZ:measured-temp: 23.9
2014.09.26 21:30:50 5: Triggering FHT_0204 (1 changes)
2014.09.26 21:30:50 5: Notify loop for FHT_0204 FHZ:measured-temp: 23.9
2014.09.26 21:30:50 4: eventTypes: FHT FHT_0204 FHZ:measured-temp: 23.9 -> FHZ:measured-temp: .*
2014.09.26 21:30:51 5: CUL/RAW: /T0204437900FA

2014.09.26 21:30:51 5: CUL_0: T0204437900 -77
2014.09.26 21:30:51 5: CUL_0 dispatch 810c04xx0909a001020443007900
2014.09.26 21:30:51 4: FHT FHT_0204 FHZ:measured-temp: 23.9
2014.09.26 21:30:51 5: Triggering FHT_0204 (1 changes)
2014.09.26 21:30:51 5: Notify loop for FHT_0204 FHZ:measured-temp: 23.9
2014.09.26 21:30:51 4: eventTypes: FHT FHT_0204 FHZ:measured-temp: 23.9 -> FHZ:measured-temp: .*
2014.09.27 10:31:57 5: Cmd: >apt-get get CUL_0 raw C99<
2014.09.27 10:32:12 5: Cmd: >get CUL_0 raw C99<
2014.09.27 10:32:12 5: SW: C99
2014.09.27 10:32:12 5: CUL/RAW (ReadAnswer): 0D2E2D07D3913D04
320000060021656A
55E43023B9000700
18146C070090876B
F85611EF2C3F1F41
00597F3F88310B00

2014.09.27 10:32:46 5: Cmd: >get CUL_0 raw C25<
2014.09.27 10:32:46 5: SW: C25
2014.09.27 10:32:46 5: CUL/RAW (ReadAnswer): C25 = 3F / 63

2014.09.27 10:33:59 5: Cmd: >get CUL_0 ccconf<
2014.09.27 10:33:59 5: SW: C0D
2014.09.27 10:33:59 5: CUL/RAW (ReadAnswer): C0D = 21 / 33


Ich flashe gerade die letzte Version (mit PLL lock recover)

Gruß, Andreas

grobiballon

Hallo,

die letzte Version hat bei mir schon unerwartet früh ein PLL0 ergeben:

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2014.09.27 11:20:53 =~=~=~=~=~=~=~=~=~=~=~=

fhem> info timer
fhem> get CUL_0 ccconf
CUL_0 ccconf => freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB
get CUL_0 raw V
CUL_0 raw => V 1.78 CUL868
fhem> get CUL_=0 raw C99
CUL_0 raw => 0D2E2D07D3913D04320000060021656A55E43023B900070018146C070090876BF85611EF2C161F4100597F3F88310B00
fhem> get CUL_0 raw C25
CUL_0 raw => C25 = 16 / 22
fhem> 2014-09-27 11:22:12 FHT FHT_0202 actuator: 0%
2014-09-27 11:22:54 FHT FHT_0204 actuator: 0%
[...]

2014-09-27 11:28:45 FHT FHT_0204 actuator: 0%
2014-09-27 11:28:56 FHT FHT_0201 actuator: 0%
2014-09-27 11:29:04 FHT FHT_0203 actuator: 0%
2014-09-27 11:29:56 FHT FHT_0202 actuator: 0%
2014-09-27 11:30:42 FHT FHT_0204 actuator: 0%
2014-09-27 11:30:51 FHT FHT_0201 actuator: 0%
2014-09-27 11:31:01 FHT FHT_0203 actuator: 0%
2014-09-27 11:31:02 FHT FHT_0203 measured-temp: 23.6
2014-09-27 11:31:02 FHT FHT_0203 temperature: 23.6
2014-09-27 11:31:02 FHT FHT_0203 battery: ok
2014-09-27 11:31:02 FHT FHT_0203 lowtemp: ok
2014-09-27 11:31:02 FHT FHT_0203 window: closed
2014-09-27 11:31:02 FHT FHT_0203 windowsensor: ok
2014-09-27 11:31:02 FHT FHT_0203 warnings: none
2014-09-27 11:31:38 FHT FHT_0201 measured-temp: 21.3
2014-09-27 11:31:38 FHT FHT_0201 temperature: 21.3
2014-09-27 11:31:39 CUL CUL_0 UNKNOWNCODE PLL0
2014-09-27 11:31:52 FHT FHT_0202 actuator: 0%


ich lasse nun mal alles so weiter laufen...

Gruß, Andreas

grobiballon

Hallo nochmal,

ich habe jetzt in 2 Stunden 4 PLL0 Nachrichten erhalten. Gefühlt ist das zu oft, der Fehler mit dem "schlafen" trat nicht so häufig aus. Kann es sein, dass ohne die PLL-Lock Erkennung der CUL sich in der Vergangenheit manchmal selber wieder "gefangen" hat und jetzt die PLL-Lock Erkennung schon vorher eingreift? Stehengeblieben könnte er dann in der Vergangenheit nur sein, wenn er sich halt mal nicht "erholt" hat...

Im übrigen kommen die PLL0 willkürlich, also nicht immer nach oder vor einem bestimmten FHT.

Gruß, Andreas

rudolfkoenig

@noansi: Gruppen mit "Fehler" im Namen abonniere ich nicht, deswegen bin ich nur versehentlich auf diese Diskussion aufmerksam geworden.

Wenn ich mich recht erinnere ist das CC1101 so konfiguriert, dass es bei jedem Sendevorgangn (bzw. danach) eine PLL Kalibration durchfuehrt. Das funktioniert hervorragend, wenn man z.Bsp. wg. einer FHT regelmaesig was sendet oder wenn man ein CUL als RFR einsetzt. Es kann sein, dass es in "READ-Only" Umgebungen es zu Problemen fuehrt.

Bevor ich aber ein Patch einspiele (bzw. anschaue), moechte wissen, ob es geholfen hat. Auf Verdacht baue ich nichts ein, da ich diese Beschwerden bisher zu selten gehoert habe, und es sind geschaetzt ueber 10.000 CULs mit culfw in Umlauf.

noansi

Hallo Rudolf,

gut, dass Du es doch gefunden hast.  :)

ZitatWenn ich mich recht erinnere ist das CC1101 so konfiguriert, dass es bei jedem Sendevorgang (bzw. danach) eine PLL Kalibration durchführt. Das funktioniert hervorragend, wenn man z.Bsp. wg. einer FHT regelmäßig was sendet oder wenn man ein CUL als RFR einsetzt. Es kann sein, dass es in "READ-Only" Umgebungen es zu Problemen fuehrt.
Wenn ich den Firmware Code für FHT beim groben überfliegen richtig verstehe, dann wird beim FHT Senden erst mal au IDLE geschaltet.
Damit wird auch vor dem Senden eine Autokalibrierung durchgeführt und nicht erst danach bei der gewählten cc1101 Einstellung dazu.

Mit X21 oder ähnlich wieder aufwecken ist auch klar, da dann der cc1101 neu initialisiert wird.

Dass der PLL beim Empfangszustand bei grobiballon nicht immer im Lock ist (sondern recht häufig nicht), ist schon nachgewiesen anhand der PLL0 Logeinträge bei ihm. Recovered wird auch, da er bisher keine PLL1 Einträge hat und auch keine PLL0 in sehr kurzen Abständen, die auf ein Problem bei der erneuten Kalibrierung hindeuten würden.

Leider kenne ich das FHT Protokoll nicht wirklich, um zu verstehen, ob da auch regelmäßig was gesendet wird. In fht.c steht so was im Kommentar.
Wenn das der Fall ist, könnte auch das Senden mit PLL Lock Problem schief gehen, wäre aber mit entsprechendem Testcode in der TX Umschaltung noch nachzuweisen.
Außerdem würde jedes Senden (ohne dass dazu vorher ein Empfang nötig ist) die Chance bieten, das der cc1101 sich per Autokalibrierung wieder erholt, d.h. nicht jeder Nicht-Lock Zustand würde dann auch zum sichtbaren Problem führen. (Nur bei der RX/TX/RX Umschaltung sollte es nach bisheriger Erfahrung überhaupt dazu kommen).
Weisst Du Näheres zum FHT Protokoll?

Gruß, Ansgar.

rudolfkoenig

ZitatWeisst Du Näheres zum FHT Protokoll?

Ja, leider, es ist ziemlich kaputt.

Es sind FS20 Telegramme mit einem anderen Checksum aber jeweils nur einmal gesendet, Die Kommunikation laeuft als Frage/Antwort ab, fuer die alle 15Minuten stattfindende Temperaturuebermittlung sind 7 Telegramm-Paare notwendig. Also 7-mal auf TX und dann auf RX schalten.
Wenn eine Nachricht verlorengeht, dann wird sie einmal wiederholt, wenn das auch schiefgeht, dann faengt das Ganze in 2 Minuten von vorne an.
Siehe auch http://www.fhemwiki.de/wiki/Maximal_nutzbare_Ger%C3%A4te#detailierte_Betrachtung

grobiballon

Hallo,

ich melde mich jetzt zurück nach 25h Betrieb zurück. Es sind 47 PLL0 Meldungen aufgetreten, keine PLL1. Der CUL ist nicht - wie sonst üblich ausgestiegen. Der PLL Lock recover scheint bei meinem CUL wirklich etwas zu bewirken. Ich habe mal die Dämpfungen vor den PLL0 Nachrichten überflogen und es ist da keine Abhängigkeit zu erkennen (-80 bis -40). Es ist auch nicht auszumachen, dass ein bestimmtes Gerät die PLL0-Meldung auslöst.

Seit dem Kauf des CUL vor ca. einem Jahr hatte ich keine 25h Betrieb ohne Aussetzer. Der Betrieb in der Vergangenheit war nur durch ein regelmäßig abgesetztes X21 möglich. Dementsprechend scheinen die Änderungen tatsächlich etwas bewirkt zu haben.

Gruß, Andreas

noansi

#12
Hallo Rudolf,

im Anhang nun noch eine Version, die auch bei der RX/TX und TX/RX Umschaltung den PLL-Lock checkt und ggf. einen Recoverversuch unternimmt.

Mit dem zusätzlichen define HAS_CC1101_SWITCH_STATE_PLL_LOCK_CHECK ist das zuschaltbar.

Wenn grobiballon damit noch bessere Empfangserfolge hat, dann wäre das die Variante der Wahl.

Getestet hab ich wieder, dass damit KS300 Nachrichten auch gesendet (und empfangen) werden können.

Gruß, Ansgar.

PS: In bisher ungenutzten Funktionen habe ich auch noch die Rückgabelogik umgedreht bzw. vereinheitlicht. D.h. vom Code her ist es die Variante der Wahl und nur der "#define HAS_CC1101_SWITCH_STATE_PLL_LOCK_CHECK" in board.h sollte dann den Unterschied machen.

Edit: Anhang gelöscht

grobiballon

Hallo,

bis jetzt lief der CUL wie gehabt. Habe nun die letzte Revision von noansi drauf geflashd.

Gruß, Andreas

rudolfkoenig

Ich habe das Patch angeschaut, und es stoeren mich 2 Sachen:
- es aendert vieles, was mit dem Problem nichts zu tun hat (Kommentare, Formatierung etc). So kann ich es gar nicht pruefen.
- 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.

Ich nehme es auf meine TODO-Liste.