CUL HM empfängt nicht oder sendet Empfangsdaten nicht an den Rechner

tpm88 · 05 Juni 2014, 12:22:36

Zitat von: noansi am 05 Juni 2014, 00:15:04
Das vorläufige Testergebnis nach über 4 Tagen Test zeigt bisher nur bei dem ersten CUL das Problem mit dem fehlenden PLL Lock.
Der neue CUL hat als Unterschied zum ersten noch den Metall-Schirm. Da ich aber in der Nähe keine großen erkennbaren Störsender/-quellen habe, denk ich nicht, dass das den Unterschied ausmacht.

Vielleicht habe ich auf dem CUL eine "Montags" cc1101 drauf oder eine Lötstelle ist nicht ganz sauber oder ein Pufferkondensator etwas schwach... und einen Software Workaround gefunden.

Hallo Ansgar,

ich glaube (noch) nicht an deine "Montags"-CUL.

Zwischenzeitlich habe ich jetzt auch PLLNOLOCK geloggt. Insgesamt 4x in 3 Tagen, davon je 2x mit der modifizierten CUL FW 1.59 und 2x mit der 99.60.

Code Auswählen


2014.06.02 14:58:30.497 4: CUL_send:  CUL_HMAs 0B 19 8670 119901 000000 00CC
2014.06.02 14:58:34.255 4: CUL_Parse: CUL_HM A 0F 75 8610 220839 000000 0A98CB0E060D37 -46.5
2014.06.02 14:58:35.579 4: CUL_Parse: CUL_HM A 0F 41 8610 21DE95 000000 0A88C50F005838 -46
2014.06.02 14:59:14.963 4: CUL_Parse: CUL_HM A 0F 37 8610 21DC30 000000 0A88CF0E005831 -49.5
2014.06.02 15:00:36.894 4: CUL_Parse: CUL_HM A 0F E9 8610 21F220 000000 0A88CC09006321 -57.5
2014.06.02 15:01:06.257 4: CUL_Parse: CUL_HM A 0F 76 8610 220839 000000 0A98CB0E060D37 -46.5
2014.06.02 15:01:08.827 4: CUL_Parse: CUL_HM P LL NO LOCK   
2014.06.02 15:01:08.872 2: CUL_HM: unknown message PLLNOLOCK
2014.06.02 15:01:08.879 4: CUL_Parse: CUL_HM A 0F 42 8610 21DE95 000000 0A88C50F005838 -46
2014.06.02 15:01:22.973 4: CUL_send:  CUL_HMAs 0B 1A 8670 119901 000000 00CC
2014.06.02 15:02:17.715 4: CUL_Parse: CUL_HM A 0F 38 8610 21DC30 000000 0A88CF0E005830 -50
2014.06.02 15:02:58.145 4: CUL_Parse: CUL_HM A 0F EA 8610 21F220 000000 0A88CC09006321 -57.5
2014.06.02 15:03:23.754 4: CUL_Parse: CUL_HM A 0F 77 8610 220839 000000 0A98CB0E070D36 -47
2014.06.02 15:03:27.578 4: CUL_Parse: CUL_HM A 0F 43 8610 21DE95 000000 0A88C50F005837 -46.5
...
2014.06.03 18:40:00 2: CUL_HM set wz_vT_Sensor1 virtTemp 20.8
2014.06.03 18:45:00 2: CUL_HM set wz_vT_Sensor1 virtTemp 20.8
2014.06.03 18:46:00 2: CUL_HM: unknown message PLLNOLOCK
2014.06.03 18:50:00 2: CUL_HM set wz_vT_Sensor1 virtTemp 20.8
2014.06.03 18:55:00 2: CUL_HM set wz_vT_Sensor1 virtTemp 20.8
...
2014.06.04 10:30:00 2: CUL_HM set wz_vT_Sensor1 virtTemp 20.4
2014.06.04 10:35:00 2: CUL_HM set wz_vT_Sensor1 virtTemp 20.4
2014.06.04 10:38:31 2: CUL_HM: unknown message PLLNOLOCK
2014.06.04 10:38:31 2: CUL_HM: unknown message PLLNOLOCK
2014.06.04 10:40:00 2: CUL_HM set wz_vT_Sensor1 virtTemp 20.4
2014.06.04 10:45:00 2: CUL_HM set wz_vT_Sensor1 virtTemp 20.4
...
2014.06.04 20:52:22 3: ku_Switch1_off return value: OK
2014.06.04 20:52:52 2: CUL_HM: unknown message PLLNOLOCK
2014.06.04 20:52:52 2: CUL_HM: unknown message PLLNOLOCK
2014.06.04 20:53:16 0: Server shutdown

Ich habe den Umzug meines produktiven FHEM auf den RPi jetzt fast fertig. Wenn das stabil läuft, kann ich mit dem CUL auf der FB7390 künftig nach Herzenslust testen. Als nächsten Step werde ich die von Martin mit Timing versehene 00_CUL.pm aus http://forum.fhem.de/index.php/topic,24225.0.html einspielen.

Gruss
Tobias

noansi · 06 Juni 2014, 00:35:59

Hallo Tobias,

danke für's mutige mit Testen.

Dann hat mein Workaround wohl doch seine Berechtigung, auch wenn nicht jede CUL davon betroffen zu sein scheint. Dann wäre die Mühe nicht vergebens gewesen.

Für eine Empfangsaussetzter Aussage ist es bei Dir wohl noch etwas früh, denke ich. Bei mir wirkts zumindest gut. Es besteht also Hoffnung auch für Dich.
Dann werde ich meine PLLNOLOCK Ausgabe wohl auch drin lassen. Vielleicht mache ich sie abschaltbar.

Kannst Du bitte mal get raw C99 prüfen und Deine Ausgabe hier posten zum Registervergleich.

Gruß, Ansgar.

tpm88 · 06 Juni 2014, 09:01:52

Hallo Ansgar,

hier im Vergleich meine (CUL_HM) Registerwerte zu den von dir bereits weiter oben berichteteten (CUL_0 und CUL_1):

CUL_0 raw => 072E2E0DE9CAFF0C450000060021656AC8930322F834073318166C434091876BF85610AE2A16114100597F3E81350B00
CUL_1 raw => 072E2E0DE9CAFF0C450000060021656AC8930322F834073318166C434091876BF85610AC2B16114100597F3E81350B00
CUL_HM raw => 072E2E0DE9CAFF0C450000060021656AC8930322F834073318166C434091876BF85610AD2B17114100597F3E81350B00

Kann der "Laie" aus den unterschiedlichen Registerwerten etwas herauslesen?

Gruss
Tobias

PS: Die von Martin angepasste 00_CUL.pm mit Timing habe ich seit gestern auch in Betrieb. Ein Update der gesamten FHEM Installation war aus meiner Sicht bisher nicht notwendig. Die Kombination läuft mit deiner CUL FW 99.60 bisher ohne Auffälligkeiten.

noansi · 06 Juni 2014, 21:27:15

Hallo Tobias,

mich interessieren die Registerwerte nur in sofern, als es interessant gewesen wäre, ein auffälliges Verhalten für weniger PLL-stabile CULs zu erkennen. Aber es sieht nicht danach aus. Die Register sind auch in der Chip-Doku nicht im Detail beschrieben.
Vielleicht sind manche Transceiver bei der Abstimmung nahe an der Grenze zwischen verschiedenen Einstellungen und kippen dann über Temperatur und Spannungsschwankungen, während andere satt mitten in ener Einstellung liegen und dann stabil mit PLL Lock laufen? Aber das ist nur eine schwache Vermutung.
Bei meiner Problem CUL ändern sich die Werte schon mal mit der Rekalibrierung nach einem PLLNOLOCK Event.

Da die Chipdoku aber empfiehlt, den PLL-Lock Zustand vor Senden und Empfang zu prüfen, was bisher in der Firmware 1.58 nicht drin war, bewegen wir uns nicht in einem fehlerhaften Verhalten.

Bei mir sieht der Test mit TimeStamp Firmware und Test 00_CUL auch gut aus. Resends sehe ich nur noch ganz selten. Und die können durch zeitfressende Aktionen anderer Module verursacht sein, so dass es nicht mehr möglich ist eine Ack Nachricht rechtzeitig auf den Weg zu bringen. Apptime gibt Hinweise dazu mit mittleren und maximalen Ausführungszeiten. Sendefehler habe bei nunmehr über 600 Sendeevents nicht gesehen.

Es bringt übrigens nichts, die Test 00_CUL mit einer älteren Firmware zu testen, da dann im besten Fall nichts passiert und bei Test der älteren Varianten der Empfang wegen des unbekannten Einschaltbefehls zur "Strafe" abgeschaltet wird.

Gruß, Ansgar

tpm88 · 11 Juni 2014, 16:58:42

Hallo Ansgar,

deine PLLNOLOCK Erweiterungen zur CUL-Firmware haben bei mir definitiv die Stabilität verbessert. Vorher mit CUL FW 1.58 hatte ich häufig schlagartig Komplettausfälle (kein Empfang, kein Senden mehr möglich) der CUL Kommunikatiotion. Der ActionDetector meldet dann den gleichzeitigen Ausfall meiner 4 HM Thermostate. Hier alle Ausfälle vom Mai:

Code Auswählen

2014-05-04_13:03:47 ActionDetector alive:0 dead:4 unkn:0 off:0
2014-05-07_09:10:49 ActionDetector alive:0 dead:4 unkn:0 off:0
2014-05-08_16:11:42 ActionDetector alive:0 dead:4 unkn:0 off:0
2014-05-08_22:51:50 ActionDetector alive:0 dead:4 unkn:0 off:0
2014-05-12_10:57:21 ActionDetector alive:0 dead:4 unkn:0 off:0
2014-05-14_07:17:49 ActionDetector alive:0 dead:4 unkn:0 off:0
2014-05-20_03:37:23 ActionDetector alive:0 dead:4 unkn:0 off:0
2014-05-20_19:57:32 ActionDetector alive:0 dead:4 unkn:0 off:0
2014-05-28_21:12:27 ActionDetector alive:0 dead:4 unkn:0 off:0

Meist hat es dann zwischen einer und mehreren Stunden gedauert, bis die Kommunikation plötzlich wieder funktioniert hat. Seit 29.05. teste ich jetzt die CUL-Firmware mit den PLLNOLOCK Erweiterungen von noansi. Seitdem hat der ActionDetektor keinen einzigen Ausfall mehr registriert. Die PLLNOLOCK Routine wurde seither einige Mal aufgerufen:

Code Auswählen

# grep -i pll fhem-2014-06.log
2014.06.02 15:01:08.872 2: CUL_HM: unknown message PLLNOLOCK
2014.06.03 18:46:00 2: CUL_HM: unknown message PLLNOLOCK
2014.06.04 10:38:31 2: CUL_HM: unknown message PLLNOLOCK
2014.06.04 10:38:31 2: CUL_HM: unknown message PLLNOLOCK
2014.06.04 20:52:52 2: CUL_HM: unknown message PLLNOLOCK
2014.06.04 20:52:52 2: CUL_HM: unknown message PLLNOLOCK
2014.06.09 09:03:52.392 2: CUL_HM: unknown message PLLNOLOCK
2014.06.10 08:22:44.579 2: CUL_HM: unknown message PLLNOLOCK
2014.06.11 00:14:16.083 2: CUL_HM: unknown message PLLNOLOCK
2014.06.11 14:17:02.237 2: CUL_HM: unknown message PLLNOLOCK

Die in v1.61 ebenfalls eingebaute Timingfunktionalität für CUL hat zusammen mit der von Martin hierfür modifizierten 00_CUL.pm zu messbar (HMinfo protoEvents Auswertung) weniger HomeMatic Resends bei meiner Konfiguration gesorgt. Vom Gefühl tragen die Timinganpassungen gerade für meine langsame Plattformen FritzBox7390 deutlich zur Stabilität von HM mit CUL bei.

Probleme (Senden) hatte ich nur mit CUL FW v1.59 (siehe mein Beitrag vom 01.06. hier)

Bitte beide Erweiterungen unbedingt in das FHEM Repository aufnehmen.

Gruss
Tobias

noansi · 15 Juni 2014, 21:05:04

Hallo Leute,

Rudolf hat mit der Version 1.59 der CUL Firmware heute die Änderungen bezüglich PLL Lock Problematik für AskSin eingecheckt.

Damit sollte das ursprüngliche Problem dieses Threads mit Homematik Aussetzern bei Empfang und Versand nun gelöst sein.

Die Meldung im Hauptlog, falls das PLL Lock Problem erkannt wurde (und die CUL auf verbose 2 eingestellt ist) lautet nun "PLL0" statt "PLLNOLOCK". Das ist nur ein Hinweis und mit der Rekalibrierung, die dann erfolgt, sollte der Tranceiver wieder in den Tritt kommen.

Falls die dann versuchte Rekalibrierung scheitert erscheint zusätzlich "PLL1".

Wenn "PLL1" abwechselnd mit "PLL0" in kurzen Abständen wiederholt auftaucht, dann ist was faul mit der Hardware, wenn ich meine "Problem" CUL mal als Maßstab nehmen darf. "PLL1" ist noch nicht vorgekommen. Dafür pro Tag bis zu 10 mal "PLL0" in wechselnden Zeitabständen.

Gruß, Ansgar.

PS: Noch nicht drin ist die TimeStamp Option. Damit habe ich noch etwas Arbeit.

frank · 13 Dezember 2023, 14:41:28

Zitat von: noansi am 15 Juni 2014, 21:05:04Rudolf hat mit der Version 1.59 der CUL Firmware heute die Änderungen bezüglich PLL Lock Problematik für AskSin eingecheckt.

wegen diesem feature habe ich meinen cul gerade von culfw 1.58 auf die aktuelle culfw 1.67 (cul_v3.hex) updated.

da ich seit einem jahr 2x einen "ausfall" des cul hatte, habe ich die hoffnung, dass es eventuell ebenfalls ein PLL-Lock problem war.

ist dieses feature in der cul_v3.hex von culfw 1.67 noch aktiv?
gibt es in fhem.log noch eine mitteilung, falls das problem erkannt wurde?
wie sieht die meldung genau aus, damit ich ein notify triggern kann?

zeigen die beiden culs aus diesem thread immer noch das problem?
oder hat es sich eventuell erledigt, da zb eine neue "cul-umgebung" existiert?
oder sind sie mittlerweile sogar "verstorben"?

im forum kann ich zu "PLL" nicht viel finden. kann aber auch an der forumssuche liegen.

gruss frank

noansi · 13 Dezember 2023, 17:45:07

Hallo Frank,

Zitatist dieses feature in der cul_v3.hex von culfw 1.67 noch aktiv?

Ist zumindest im Code vorhanden und bei aktivem ASKSIN Empfang dann auch aktiv. Das hex File habe ich nicht rückwärts danach untersucht.

Zitatgibt es in fhem.log noch eine mitteilung, falls das problem erkannt wurde?

Es sind weiterhin die PLL0 und PLL1 messages vom CUL, die in 00_CUL.pm schlicht an die Dispatch Funktion weiter gereicht werden. Und falls sich kein Modul dafür zuständig fühlt, sollte ein UNKNOWN PLL0 oder UNKNOWN PLL1 Trigger ausgelöst werden.

Code Auswählen

      DoTrigger($name, "UNKNOWNCODE $dmsg");
      Log3 $name, 3, "$name: Unknown code $dmsg".
                     (defined($addvals) && defined($addvals->{RSSI})?", RSSI $addvals->{RSSI}":'').
                     ', help me!';

Meine CULs laufen noch prima, erfreuen sich aber der tsculfw.

Gruß, Ansgar.

frank · 27 Januar 2024, 16:37:45

danke, hat wunderbar funktioniert.

nach gut 6 wochen mit culfw 1.67 hat es heute nacht ein erstes PLL0 ereignis gegeben und der cul läuft weiterhin ohne probleme.

Code Auswählen

2024.01.27 02:37:48.041 4: CUL_Parse: cul868 A 0C 70 8670 20DFE1 000000 003556E8 -86
2024.01.27 02:37:48.048 5: cul868: dispatch A0C70867020DFE1000000003556::-86:cul868
2024.01.27 02:37:48.169 0: HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:F2281016 d:FF r:FFAE     m:70 8670 20DFE1 000000 003556
2024.01.27 02:37:56.011 0: HMLAN_Send:  hmlan1 S:S4890F6B8 stat:  00 t:00000000 d:01 r:4890F6B8 m:D8 A258 B6B6B6 1F91AA 0017
2024.01.27 02:37:56.051 4: CUL_Parse: cul868 A 0B D8 A258 B6B6B6 1F91AA 001739 -45.5
2024.01.27 02:37:56.054 5: cul868: dispatch A0BD8A258B6B6B61F91AA0017::-45.5:cul868
2024.01.27 02:37:56.060 4: CUL_Parse: cul868 P LL 0    
2024.01.27 02:37:56.063 5: cul868: dispatch PLL0
2024.01.27 02:37:56.065 3: cul433 IT_set: IT06 on
2024.01.27 02:37:56.833 3: cul868: Unknown code PLL0, help me!
2024.01.27 02:37:56.835 3: cul433 IT_set: IT06 on
2024.01.27 02:37:57.518 0: HMUARTLGW hmuart1 recv: 01 05 00 00 25 msg: D8 A2 58 B6B6B6 1F91AA 0017
2024.01.27 02:37:57.523 0: HMUARTLGW hmuart1 recv: 01 05 00 00 4B msg: D8 82 02 1F91AA B6B6B6 010114003D
2024.01.27 02:37:57.581 0: HMUARTLGW hmuart1 recv: 01 05 00 00 25 msg: D8 A2 58 B6B6B6 1F91AA 0017
2024.01.27 02:37:57.587 0: HMUARTLGW hmuart1 recv: 01 05 00 00 25 msg: D8 A2 58 B6B6B6 1F91AA 0017
2024.01.27 02:37:57.594 4: CUL_Parse: cul868 A 0E D8 8202 1F91AA B6B6B6 010114003DF0 -82
2024.01.27 02:37:57.598 5: cul868: dispatch A0ED882021F91AAB6B6B6010114003D::-82:cul868
2024.01.27 02:37:57.650 4: CUL_Parse: cul868 A 0B D8 A258 B6B6B6 1F91AA 001738 -46
2024.01.27 02:37:57.653 5: cul868: dispatch A0BD8A258B6B6B61F91AA0017::-46:cul868
2024.01.27 02:37:57.658 4: CUL_Parse: cul868 A 0B D8 A258 B6B6B6 1F91AA 001738 -46
2024.01.27 02:37:57.660 5: cul868: dispatch A0BD8A258B6B6B61F91AA0017::-46:cul868
2024.01.27 02:37:57.664 4: CUL_Parse: cul868 A 14 3E 805E 266EA5 1ACE1F 000000000000000000000028 -54
2024.01.27 02:37:57.667 5: cul868: dispatch A143E805E266EA51ACE1F0000000000000000000000::-54:cul868
2024.01.27 02:37:57.682 0: HMUARTLGW hmuart1 recv: 01 05 00 00 31 msg: 3E 80 5E 266EA5 1ACE1F 0000000000000000000000
2024.01.27 02:37:57.687 0: HMLAN_Parse: hmlan1 R:E1F91AA   stat:0000 t:F2282FD9 d:FF r:FFC3     m:D8 8202 1F91AA B6B6B6 010114003D
2024.01.27 02:37:57.709 0: HMLAN_Parse: hmlan1 R:R4890F6B8 stat:0008 t:00000000 d:FF r:7FFF     m:D8 A258 B6B6B6 1F91AA 0017
2024.01.27 02:37:57.711 0: HMLAN_Parse: hmlan1 no ACK from 1F91AA
2024.01.27 02:37:57.713 0: HMLAN_Parse: hmlan1 R:E266EA5   stat:0000 t:F228354B d:FF r:FFC2     m:3E 805E 266EA5 1ACE1F 0000000000

somit könnte der berichtete ausfall tatsächlich durch ein PLL problem verursacht worden sein.
als verursacher habe ich jetzt einen aktiven usb hub in verdacht, den ich kurz vor dem ersten cul ausfall zusätzlich am pi angeschlossen habe.
vorher gab es jahre lang null probleme.

ausserdem habe ich nun mit der neuen fw 2x err:cca gehabt.
mich wundert allerdings, dass es dabei jedes mal ein "reconnect" gegeben hat.
wenn ich mir logs im forum mit err:cca meldungen anschaue, sehe ich dort keine reconnects.

ist das verhalten durch die fw erklärbar, zb ein reopen?

Code Auswählen

2024.01.13 20:28:00.472 4: CUL_Parse: cul868 A 14 D6 805E 266EA5 1ACE1F 000000000000000000000029 -53.5
2024.01.13 20:28:00.477 5: cul868: dispatch A14D6805E266EA51ACE1F0000000000000000000000::-53.5:cul868
2024.01.13 20:28:00.490 0: HMUARTLGW hmuart1 recv: 01 05 01 00 2F msg: D6 80 5E 266EA5 1ACE1F 0000000000000000000000
2024.01.13 20:28:00.495 0: HMLAN_Parse: hmlan1 R:E266EA5   stat:0000 t:ADE07F15 d:FF r:FFC6     m:D6 805E 266EA5 1ACE1F 0000000000000000000000
2024.01.13 20:28:16.604 5: cul868 sending As0BDBA258B4B4B41CE9F500FD
2024.01.13 20:28:16.607 5: DevIo_SimpleWrite cul868: As0BDBA258B4B4B41CE9F500FD
2024.01.13 20:28:18.117 4: CUL_Parse: cul868 E RR :C CA   
2024.01.13 20:28:18.123 5: cul868: dispatch ERR:CCA
2024.01.13 20:28:18.221 3: cul868: Unknown code ERR:CCA, help me!
2024.01.13 20:28:18.567 1: /dev/serial/by-id/usb-busware.de_CUL868-if00 disconnected, waiting to reappear (cul868)
2024.01.13 20:28:19.334 3: Setting cul868 serial parameters to 38400,8,N,1
2024.01.13 20:28:19.442 5: DevIo_SimpleWrite cul868: V
2024.01.13 20:28:19.448 5: DevIo_SimpleWrite cul868: ?
2024.01.13 20:28:19.498 3: cul868: Possible commands: ABbCeFGhiKkLlMmNRTtUuVWXxYZ
2024.01.13 20:28:19.501 5: DevIo_SimpleWrite cul868: X21
2024.01.13 20:28:19.505 5: DevIo_SimpleWrite cul868: Ar
2024.01.13 20:28:19.509 5: DevIo_SimpleWrite cul868: T01
2024.01.13 20:28:19.515 5: GOT CUL fhtid: 0000
2024.01.13 20:28:19.555 1: /dev/serial/by-id/usb-busware.de_CUL868-if00 reappeared (cul868)
2024.01.13 20:28:19.591 0: HMLAN_Parse: hmlan1 R:E266EA5   stat:0000 t:ADE0C8C2 d:FF r:FFC6     m:D7 805E 266EA5 1ACE1F 0000000000000000000000
2024.01.13 20:28:19.600 0: HMUARTLGW hmuart1 recv: 01 05 01 00 2F msg: D7 80 5E 266EA5 1ACE1F 0000000000000000000000

gruss frank

noansi · 27 Januar 2024, 23:09:59

Hallo Frank,

Zitatals verursacher habe ich jetzt einen aktiven usb hub in verdacht, den ich kurz vor dem ersten cul ausfall zusätzlich am pi angeschlossen habe.

Da das PLL-Lock Problem ein in den Erratas zum CC1101 dokumentiertes Verhalten ist, halte ich den USB Hub für die PLL0 Meldung für wenig verdächtig?!

Natürlich kann ein USB-Hub für USB-Kommunikationsprobleme sorgen. Was sagt das Log vom Host dazu?

Zitatmich wundert allerdings, dass es dabei jedes mal ein "reconnect" gegeben hat.

Dein Log deutet fast 2 Sekunden ab dem As... bis zum reconnect. Der Watchdog des CUL würde bei 2s +/-Ungenauigkeit zuschlagen.
Möglich, dass das die Ursache ist?
Die CCA Wartezeit beim ASKSIN Senden ist in der Firmware zu 752ms gewählt, das alleine kann es also bezüglich Watchdog nicht sein.

Gruß, Ansgar.

frank · 02 Februar 2024, 13:13:32

moin ansgar,

Zitat von: noansi am 27 Januar 2024, 23:09:59Da das PLL-Lock Problem ein in den Erratas zum CC1101 dokumentiertes Verhalten ist, halte ich den USB Hub für die PLL0 Meldung für wenig verdächtig?!

Natürlich kann ein USB-Hub für USB-Kommunikationsprobleme sorgen. Was sagt das Log vom Host dazu?

wenn du diese errata info meinst, verstehe ich die aussage nicht wirklich.

ZitatSWRZ020E–April 2007–Revised September 2015
PLL Lock Detector Output —PLL lock detector output is not 100% reliable

dort wird ja "nur" auf einen "unsicheren" pll-lock-check hingewiesen.
hinweise auf eine ursache für den verlust des pll-lock gibt es hier ja nicht.

im syslog gibt es zu dieser zeit gar nichts. auch grundsätzlich gibt es nichts ungewöhnliches zum usb.

bei den homebrew entwicklern von asksin++ wurde das pll_out_of_lock problem letztens übrigens auch entdeckt und ähnlich gefixt.
im thread etwa ab diesem post: https://homematic-forum.de/forum/viewtopic.php?f=76&t=78078&start=80#p767754
die ursache bleibt auch hier im dunkeln.
interessant finde ich die dort gefundenene aussage eines ti mitarbeiters zu diesem thema (scheinbar etwas voodoo

):

ZitatFrom what you describe I can't give a good explanation why a few devices fails to calibrate some times. For a constant environment (temp, voltage etc) it should be sufficient with one calibration and not having to do a calibration again but for practical applications we always advice to calibrate at given time intervals since it's not possible to know all the reasons if/ why the PLL could go out of lock.

###################### zum reopen bei err:cca

Zitat von: noansi am 27 Januar 2024, 23:09:59Dein Log deutet fast 2 Sekunden ab dem As... bis zum reconnect. Der Watchdog des CUL würde bei 2s +/-Ungenauigkeit zuschlagen.
Möglich, dass das die Ursache ist?
Die CCA Wartezeit beim ASKSIN Senden ist in der Firmware zu 752ms gewählt, das alleine kann es also bezüglich Watchdog nicht sein.

ich hatte diese aussage von michael gefunden, da waren es scheinbar noch 2 sekunden.

Zitat von: mgernoth am 12 November 2016, 11:33:05ihr habt einen Störsender auf 868,35MHz, der CUL wechselt nicht in den Sendemodus, weil das Clear Channel Assessment nicht innerhalb von 2s erfolg hatte.

ich werde weiter beobachten, bisher keine neuen ereignisse.

noansi · 06 Februar 2024, 21:54:57

Hallo Frank,

dafür Hinweise im Datenblatt:

Zitat22.1 VCO and PLL Self-Calibration
... This calibration should be done regularly,
... The PLL must be re-calibrated until PLL lock is achieved if the PLL
does not lock the first time.
... 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

Und praktisch hatte ich geloggt, dass es bei meinen CULs gelegentlich zu PLL Lock Verlust gekommen ist.

Zitatbei den homebrew entwicklern von asksin++ wurde das pll_out_of_lock problem letztens übrigens auch entdeckt und ähnlich gefixt.

Warum sollte es anderen besser gehen, als mir. In dem Thread interessante Theorieansätze zur Ursache...

Zitatich hatte diese aussage von michael gefunden, da waren es scheinbar noch 2 sekunden.

Code Auswählen

  // enable TX, wait for CCA
  get_timestamp(&ts1);
  do {
    ccStrobe(CC1100_STX);
    if (cc1100_readReg(CC1100_MARCSTATE) != MARCSTATE_TX) {
      get_timestamp(&ts2);
      if (((ts2 > ts1) && (ts2 - ts1 > ASKSIN_WAIT_TICKS_CCA)) ||
          ((ts2 < ts1) && (ts1 + ASKSIN_WAIT_TICKS_CCA < ts2))) {
        DS_P(PSTR("ERR:CCA\r\n"));
        goto out;
      }
    }
  } while (cc1100_readReg(CC1100_MARCSTATE) != MARCSTATE_TX);

mit

Code Auswählen

#define ASKSIN_WAIT_TICKS_CCA	188	//125 Hz

und ups, 8ms, statt 4ms, wie bei der tsculfw -> macht 1504ms bei der culfw.
Immer noch keine 2s, aber mit blödem Zufall und 360ms Burst + Sendenachricht nicht mehr weit weg...
In der tsculfw ist der watchdog übrigens auf 8s statt 2s eingestellt. Den watchdog könntest Du also verändern und neu compilieren.
Außerdem hatte ich den USB Registerzugriff und Ringbufferzugriff atomarer gestaltet und generell "Textausgabe" aus Interrupts raus eliminiert, weil die Ausgaberoutinen dafür nie gemacht waren.

Gruß, Ansgar.

frank · 11 Februar 2024, 15:19:02

hallo ansgar,

letztens habe ich dieses pdf von eq3 gefunden: https://www.homematic-inside.de/media/download/legacy/meetup_2018/sendeverhalten
auf seite 9 wird der aufbau von hmip telegrammen beschrieben, die demnach bis zu 61 Byte lang sein können.

in rf_asksin.c gibt es diese behandlung von "zu langen" (>= 30/50 byte) telegrammen:

Code Auswählen

  // see if a CRC OK pkt has been arrived
  if (bit_is_set( CC1100_IN_PORT, CC1100_IN_PIN )) {
    msg[0] = cc1100_readReg( CC1100_RXFIFO ) & 0x7f; // read len

    if (msg[0] >= MAX_ASKSIN_MSG) {
      // Something went horribly wrong, out of sync?
      rf_asksin_reset_rx();
      return;
    }

nun frage ich mich, ob der empfang langer hmip messages und der damit verursachte aufruf von rf_asksin_reset_rx() zu verzögerungen führt, wodurch der watchdog auslöst.

ich denke man sollte hier die maximale länge ändern, so dass auch alle hmip messages erfasst werden.

nützlich könnte eine zusätzlich hmip erkennung sein, um diese messages erst gar nicht weiter zu leiten. vermutlich sind sie über die ersten 3 byte nach dem längen-byte eindeutig zu unterscheiden. vielleicht reicht schon das 2. byte, wenn ich mir die hmip messages anschaue, die ich hin und wieder in meinem log sehe.

gruss frank

noansi · 11 Februar 2024, 23:23:21

Hallo Frank,

Zitatauf seite 9 wird der aufbau von hmip telegrammen beschrieben, die demnach bis zu 61 Byte lang sein können.

Danke für die Info, auch die vor Seite 9.

Zitatin rf_asksin.c gibt es diese behandlung von "zu langen" (>= 30/50 byte) telegrammen

Was nach der Info vor Seite 9 nicht ganz passt, weder die 30, noch die 50. Lediglich als Pufferüberlaufschutz funktional.
26 wäre max. für ein Datentelegramm für das Längenbyte. Bei FUP können es 39 für das Längenbyte sein, nach meinem bisherigen Erfahrungsstand.

rssi und lqi werden vom cc1101 nur im fifo angehangen, zählen also ebenso wenig mit, wie die crc bytes.

Zitatnun frage ich mich, ob der empfang langer hmip messages und der damit verursachte aufruf von rf_asksin_reset_rx() zu verzögerungen führt, wodurch der watchdog auslöst.

Code Auswählen

static void
rf_asksin_reset_rx(void)
{
  ccStrobe( CC1100_SFRX  );
  ccStrobe( CC1100_SIDLE );
  ccStrobe( CC1100_SNOP  );
  ccStrobe( CC1100_SRX   );
}

Das sind nur 4 Kommando Bytes, die nacheinander über den SPI an den cc1101 gejagt werden. Das kratzt nicht am watchdog.

Allerdings können die längeren HMIP messages eher zu

ZitatRXFIFO_OVERFLOW Issue

in den erratas führen. Und dazu ist dann die Empfehlung

ZitatWhen the radio is stuck in RX state like this, it will draw current as in RX state, but it will
not be able to receive any more data. The only way to get out of this state is to issue an
SIDLE strobe and then flush the FIFO (SFRX).

Was obiger Code nicht macht.

In der tsculfw ist dazu mehr Code drin.

Zitatnützlich könnte eine zusätzlich hmip erkennung sein, um diese messages erst gar nicht weiter zu leiten. vermutlich sind sie über die ersten 3 byte nach dem längen-byte eindeutig zu unterscheiden. vielleicht reicht schon das 2. byte, wenn ich mir die hmip messages anschaue, die ich hin und wieder in meinem log sehe.

Fände ich auch nützlich.
Und was sind die eindeutigen Merkmale zur Unterscheidung in den 3 Bytes?
Ab Seite 9 sehe ich leider zu wenig Details zur Unterscheidung.

Zum Telegrammzähler hat der CUL null Sinninfo.
Bei den Steuerungsbits darf nur Bit 3 nicht gesetzt sein.
Die bekannten Rahmentypen sind begrenzt.

Der CUL Flashspeicher und Speicher ist auch begrenzt.

Gruß, Ansgar.

noansi · 12 Februar 2024, 21:49:19

Hallo Frank.

die maximale Paketlänge sollte sich filtern lassen, indem das PKTLEN Register 0x06 des cc1101 benutzt wird. Siehe auch "15.3.2 Maximum Length Filtering" Im cc1101 datasheet. rf_asksin.c Änderung:

Code Auswählen

const uint8_t PROGMEM ASKSIN_CFG[] = {
     0x00, 0x07,
     0x02, 0x2e,
     0x03, 0x0d,
     0x04, 0xE9,
     0x05, 0xCA,
     0x06, 26, // maximum lenght of data without length byte. Set also to avoid RXFIFO_OVERFLOW issue in errata
     0x07, 0x0C,
     0x0B, 0x06,
     0x0D, 0x21,
     0x0E, 0x65,
     0x0F, 0x6A,
     0x10, 0xC8,
     0x11, 0x93,
     0x12, 0x03,
     0x15, 0x34,
     0x17, 0x33, // go into RX after TX, CCA; EQ3 uses 0x03
     0x18, 0x18,
     0x19, 0x16,
     0x1B, 0x43,
     0x21, 0x56,
     0x25, 0x00,
     0x26, 0x11,
     0x29, 0x59,
     0x2c, 0x81,
     0x2D, 0x35,
     0x3e, 0xc3
};

#ifdef HAS_ASKSIN_FUP
const uint8_t PROGMEM ASKSIN_UPDATE_CFG[] = {
     0x06, 39, // maximum lenght of data without length byte. Set also to avoid RXFIFO_OVERFLOW issue in errata
     0x0B, 0x08,
     0x10, 0x5B,
     0x11, 0xF8,
     0x15, 0x47,
     0x19, 0x1D,
     0x1A, 0x1C,
     0x1B, 0xC7,
     0x1C, 0x00,
     0x1D, 0xB2,
     0x21, 0xB6,
     0x23, 0xEA,
};

Also minimaler Eingriff.

Gruß, Ansgar.