Kopp Free Control und NanoCUL

[stoffel]

mit dem neuen 868Mhz Modul, brauch ich eigentlich nichts mehr einzustellen...
da verlass' ich mich auf die "kopp-fc.c", Frequenz lass' ich "original".


Gruß
Stef

[RaspII]

Hi,
hab Dir die kopp-fc.c geändert (gibt jetzt keine Checksummenfehler mehr aus, keine Debugausgaben mehr).

Getestet hab ich nicht, allerdings hält sich die Änderung in Grenzen (2 Zeilen auskommentiert).

Gruß
RaspII

[stoffel]

Hallo RaspII,
funktioniert jetzt gut...
mir ist jetzt aufgefallen, es kommen die richtigen Tastencodes jeweils einmal
beim langen drücken kommt der richtige Code direkt und erst nach loslassen der Taste kommen
jetzt zwei Zeilen mit Tastencode ...F7...

kr0788102501CC0F02D0  <-- kurz gedrückt
kr0788102681CC0F0253  <-- lang dedrückt
kr07881027F7CC0F0224  <-- loslassen der lang gedrückten Taste
kr07881028F7CC0F022B

vielleicht hilft dir das irgendwo.... ich kann in meinem Programm gezielt darauf reagieren, also kein Problem.

Gruß
Stef

[RaspII]

Hi
der Sender sendet nach langem Tastendruck den Stopp Block (z.b. beim Dimmen) 2x, d.h. ich Empfange hier 26 Botschaften.
Das ist wohl eine Art Absicherungsmassnahme, damit Rollos auch ganz sicher den Stopp Befehl empfangen.
Ich gebe das genau so weiter.
Ich wollte das auch nicht ändern, macht m.E. schon Sinn.


Gesendet von meinem SM-G900F mit Tapatalk

[stoffel]

Ja, verstanden...kann so bleiben,
ist kein Problem für mich, ich kann darauf reagieren...


Vielen Dank
Stef

[Feuerdrache]

Hi RaspII,
Ich hab mir eine FHEM testumgebung aufgebaut und dort das Phänomen mit kr00000... Und dem Checksummenfehler jetzt auch. Hast du Deine codeänderungen schon im Sven eingecheckt?

Zusätzlich habe ich immer wieder das komische Verhalten das der nanocul einfach"abstürzt". Dann blinkt die led auf dem Nano nur noch ganz hektisch und nichts geht mehr mit dem Ding, bis man es kurz vom Strom trennt.
Da mir das heute mit zwei nanocul ( beide im Kopp Modus an zwei FHEM Installationen )gleichzeitig passiert ist, vermute ich das ein empfangenes Datenbanken dafür verantwortlich ist. Bisher konnte ich das nicht reproduzieren, werde das mal weiter beobachten. Hast du schonmal was ähnliches gehabt?

[RaspII]

Hi,
ich habe ja leider keine nanoCUL.
Bei mir laufen zwei ProMicro Atmega mit CC1101 Modul seit Wochen stabil.
Einer davon mit dem Kopp Protokoll (da passiert aber nicht viel, nur ab und an ein Telegramm)
Ein original CUL läuft ebenfalls mir dem Kopp Protokoll, ebenfalls ohne Problrme.
Ich habe bei mir auch nie Checksummenfehler gesehen,
Nullbotschaften habe ich nur gesehen wenn ich am ProMicro den GDO2 Pin falsch angeschlossen habe.

Gab es bei Dir im Fehlerfall eine bestimmte Aktivität?

Einen Atmega Nano Clone hab ich, vielleicht Bau ich mir mal einen nanoCUL auf

[RaspII]

Hi,
Du könntest nochmal etwas testen.
Nutze mal die kopp-fc.c aus meiner Antwort #85
https://forum.fhem.de/index.php/topic,47846.msg430402.html#msg430402

Wenn dort ununterbrochen die "Nullbotschaften" kommen, ohne dass eine Taste an der Fernbedienung gedrückt wird liegt das Problem irgendwo auf dem Pfad des GDO2 Pins.
Die Empfangsroutine liest das Fifo des CC1101 aus wenn dieser Pin "aktiv" wird.
Kommen lauter Nullbotschaften ist dieser Pin falsch angeschlossen, falsch konfiguriert oder hat einen kurzschluss etc.

[Feuerdrache]

Hi,
probier ich bei nächster Gelegenheit aus.

Zu dem Schnell blinken der LED 13 hab ich auch noch was gefunden, aber nachdem ich das hier (https://forum.fhem.de/index.php?topic=49177.0) gesehen habe bist Du schon auf dem Weg, die Ursache dafür zu verfolgen.
Soweit ich das gelesen habe kommt es dazu, wenn der Watchdog ausgelöst hat, aber der Bootloader nicht mit dem Watchdog umgehen kann.

Siehe : http://www.mikrocontroller.net/topic/390509

Lösung für die Bootschleife, soweit ich das gesehen habe, ist einen andere bootloader zu verwenden.
z.B. Optiboot (https://github.com/Optiboot/optiboot)
(https://andreasrohner.at/posts/Electronics/How-to-make-the-Watchdog-Timer-work-on-an-Arduino-Pro-Mini-by-replacing-the-bootloader/)

Ich werde demnächst mal auf meinem produktiv NanoCul den Bootloader tauschen, mal sehen ob es was bringt.

Bleibt aus meiner Sicht nur noch die Frage, warum der Watchdog überhaupt ausgelöst wird, wenn Du da Hilfe beim Testen brauchst, sag bescheid, Kontaktdaten hast Du ja.

Gruß FD

[RaspII]

Wenn ich einen der "Problem namoCULs" auf dem Tisch hätte könnte ich mir selbst ein Bild machen.
(ich zieren mich noch meine verbleibende 866Mhz Briefmarke an einen 5V nanoCUL anzuschließen.
Keiner kann sagen ob night doch Schutzstrukturen etc zerstört werden

Gesendet von meinem SM-G900F mit Tapatalk

[RaspII]

Bzgl. Watchdogschleife,
wenn Du Kopp Botschaften empfangen kannst, gibt es bei Dir vermutlich keine Bootschleife.
Ich habe die Bootschleife so verstanden, dass laufend Watchdog Resets ausgeführt werden, das Anwenderprogramm aber nicht ausgeführt wird.
Ich hatte mal in einem Implementierungsstand die culfw sehr lange für das Kopp Protokoll beschäftigt, da hatte dann auch der Watchdog zugeschlagen.
Gesehen hatte mann dann "Teilantworten" vom CUL zu FHEM/Terminal. aber nie eine schnell blinkende LED.
Eine schnell blinkende LED könnte zwar durchaus vom Wathdog kommen, dann würde aber vermutlich kein Protokoll mehr funtionieren.

Ich tippe inzwischen eher auf eine falsche Frequenzapassung etc.

[Feuerdrache]

Wenn die led schnell bringt macht der nanocul nichts mehr, auch drücken des Resettasters bringt keine Veränderung. Nur vom Strom trennen ändert das Verhalten. In sofern glaube ich eher an die bootschleife.

[RaspII]

Ok

Gesendet von meinem SM-G900F mit Tapatalk

[Feuerdrache]

So, die Nullbotschaften und die crc Fehler lagen an einem wackeligen Kabel, der betreffende nanocul ist auf einem breadbord aufgebaut.

Bezüglich des watchdogs und der bootschleife bin ich nun schlauer und kann den Fehler auch reproduzieren.

Vorraussetzung ist eine Arduino nano mit original bootloader.
Der Nano wird nach Anleitung mit einem cc1101 verbunden und die aktuelle culfw geflascht.
Wenn dieser nanoCUL um Kopp_FC Modus auf Empfang steht und viele Botschaften empfangen muss, dann passiert es das der nanoCul abstürzt und in einer Bootschleife stecken bleibt.
Als Lösung habe ich auf den Nano den bootloader von Arduino UNO (optiboot) geflascht und den Fehler versucht erneut zu provozieren. Ohne Erfolg. Nachdem ich den Standart bootloader wieder drauf getan habe, konnte ich den Fehler wieder provozieren.

Ich hoffe das hilft weiter.

Gruß FD

[RaspII]

Nö,
das verstehe ich gar nicht.

Könntest Du mit dem Optiboot nochmal überprüfen ob der auch abstürzt,  wenn viele Botschaften empfangen werden?
(das musste man über die CUL aktiv Zeit rausbekommen.)
Evt. fängt dieser Bootloader nur die Watchdogresets besser ab.

Kennst Du die Watchdog Periode beim NanoCUL?




Gesendet von meinem SM-G900F mit Tapatalk