Hi,
ich habe mir das ganze jetzt mal bei mir angeschaut (auf einem CCD und CUL-V3):
Tippe ich krS ein, kommt wie erwartet:
krS-ReceiveStart
Danach drücke ich 2 unterschiedliche Tasten in folgender Reihenfolge: Taste 1, Taste 2, Taste1 und bekomme folgende Ausgabe:
kr07F1295030CC0F01D7
kr07F1295120CC0F01C6
kr07F1295230CC0F01D5
Splittet man die Blöcke wie folg auf:
kr07 F129 50 30 CC0F 01 D7
kr07 F129 51 20 CC0F 01 C6
kr07 F129 52 30 CC0F 01 D5
sieht man den Tastendruckzähler von 50, 51, 52 wandern
Der Tastencode ist 30, dann 20, dann wieder 30.
-> Dein Problem muss am nanoCUL oder CC1101 Modul liegen.
Nachtrag:
Hab mir nochmal meinen Code angeschaut.
Mir ist völlig unklar, wie folgende Botschaft rausgehen kann:
kr000000000000000000
Eigentlich müsste eine Empfangsbotschaft mit lauter Nullen spätestens bei der Checksummenprüfung rausgefilter werden.
Das erklärt dann auch warum jede Botschaft 13 x übertragen wird.
Meine Software "meldet" einen empfangen Block nur dann wenn dieser sicht geändert hat, identische Blöcke werden unterdrückt (das bedeutet nur 1x übertragen, da auch der Tastendruckzähler nicht verändert wurde).
Bleibt nur die Frage woher der Block mit den "Nullen" kommt.
Den kann ich mir beim besten Willen nicht erklären.
Nachtrag 3.4.2016
Nach zigmaligem Codereview muss ich leider gestehen, ich kann mir das jetzt doch erklären.
Wenn ein HW Fehler vorliegt (der GD02 Pin ist falsch verdrahtet) können derartige Botschaften entstehen.
Meine Empfangsroutine gibt dann einen Block aus, obwohl 0 Bytes empfangen wurden.
Dieser Block ist ein "Null Block", da der Empfangsbuffer per default mit "0" initialisiert wird. Ich habe die culfw inzwischen verbessert. Habe eben aber festgestellt: theoretisch können noch immer falsche Blöcke empfangen werden wenn die Verdrahtung falsch ist (allerdings nur extrem selten, wenn gleichzeitig auch ein Kopp Sender aktiv ist).
Ich richte das mal bei Gelegenheit.