CUL_IR: Bug & Problem

[Uli]

[Das Folgende hatte ich zunächst aus Versehen in FHEM Users gepostet; sorry, falls jemand hier jetzt zum zweiten Mal darüber stolpert … !]

Hallo allerseits,

ich habe heute den ganzen Tag an einem neuen CUNO2 (mit aktueller culfw) rumgepfrimelt, um ihm meine Fernbedienungen beizubringen. Dabei bin ich auf einen Bug und ein seltsames Problem gestoßen.

Ich muss vorausschicken, dass ich zwar vom Programmieren im Allgemeinen leidlich Ahnung habe, aber bislang null Schimmer, was IR-Fernbedienungen betrifft. Entsprechend elementar ;–) mögen meine Punkte sein. Ich bin mir auch nicht sicher, ob die Bugs/Probleme culfw/CUNO2-spezifisch sind oder einfach Probleme im IRMP-Code, die dann besser auf mikrocontroller.net zu stellen wären. Aber ich dachte mir, ich gehe vom Konkreten zum Allgemeinen und fange erstmal hier an.

Zunächst mal zu dem Bug: Wenn man in irmpconfig.h (bei dem voreingestellten F_INTERRUPTS Wert von15625) IRMP_SUPPORT_NEC42_PROTOCOL aktiviert, funktioniert überhaupt kein Protokoll mehr (weder NEC42 noch irgendein anderes – zumindest war das bei allen Protokollen so, für die ich überhaupt Fernbedienungen habe). Ich habe nur zwei Lösungen dafür gefunden: IRMP_SUPPORT_NEC42_PROTOCOL ausschalten oder F_INTERRUPTS auf <= 10000 setzen.

Auf http://www.mikrocontroller.net/articles/IRMP#Diskussion heißt es in der History:

Ältere Versionen:

13.02.2012: Bugfix: oberstes Bit in Adresse falsch bei NEC-Protokoll, wenn auch NEC42-Protokoll eingeschaltet ist.

Könnte es sein, dass die aktuelle culfw noch eine IRMP-Version von vor dem 13.02.2012 benutzt? Dann ist das vielleicht der Bug, sonst ist es ein anderer …

Nun zu meinem Problem:

Eine meiner Fernbedienungen, von einem Hitachi-Projektor von 2006, hergestellt von Interlink Electronics, wurde vom CUNO2 zunächst stets ignoriert (kein Aufleuchten der gelben Ethernet-LED bei Befehlseingabe auf der Fernbedienung). Nach langem Probieren kam ich schließlich darauf, dass diese FernbedienungRC5 nutzt, aber nur bei F_INTERRUPTS <= 10000 funktioniert. Bei höheren Werten reagiert der CUNO2 wie gesagt schlicht nicht.

Das Dumme ist nur: Auch bei F_INTERRUPTS auf <= 10000 lösen die ca. 30 Tasten auf der Fernbedienung nur 3 verschiedene Codes aus; es werden also nur 3 Buttons angelegt. Noch verrückter: der genaue Wert dieser 3 Codes hängt von F_INTERRUPTS ab; verändere ich diesen Wert (stets <= 10000), verändern sich auch die empfangenen Codes. Ist hier noch was zu retten, oder muss ich diese Fernbedienung abschreiben?

Und selbst wenn es hier eine Lösung gäbe: Ich habe leider einige andere Fernbedienungen, die Protokolle verwenden, die F_INTERRUPTS >= 15000 benötigen. Müsste ich dann also zwei CUNOS verwenden? Wenn ich das richtig sehe, lassen sich die Interrupts ja nur global einstellen, nicht pro Protokoll. Wobei ich, wenn ich die IR-Codes einmal entschlüsselt habe, den CUNO2 nur noch zum Senden verwenden will. Was "Interrupts" im Zusammenhang mit Senden bedeuten sollen, ist mir aber eh nicht ganz klar. Vielleicht gäbe es hier ja doch eine Möglichkeit, mit einem CUNO2 auszukommen?

Vielen Dank im Voraus für alle evtl. Infos oder Ideen!

Uli

[Uli]

Ich führe hier mal ein Selbstgespräch mit mir und teile mit, was ich währenddessen herausgefunden habe.

Meiner Einschätzung nach ist das Ganze ein Hardwareproblem des CUNO2, das zu eingeschränkt ist, was IR-Frequenz und vielleicht auch noch andere Parameter betrifft.

Grund für diese Einschätzung ist, dass ich jetzt alternativ das Ganze mit einem ELV FS20 IRF probiert habe, und der funktioniert „out of the box“ vollkommen problemlos, auch mit den beiden oben angeführten Fernbedienungen gleichzeitig. Das Gerät arbeitet ebenfalls (wie das CUNO2) mit einem Atmel-Controller, und da ELV es für lediglich 18 EUR anbietet, bin ich mir sehr sicher, dass die für die IR-Verarbeitung keine Eigenentwicklung benutzen, sondern ebenso IRMP wie auch die CUNO2-Firmware.

Da sollte sich ein zukünftiger CUNO3 also was von ELV abgucken …

Uli