IR-Code Transfer Protokoll

    Hallo liebe Gemeinde,


    bisher war es alles so einfach mit meinem Intel Board DP67DEB3. Ich bekomme die IR-Codes per rc-core und kann den Rechner, nach einmaligem Installieren des Treiber unter Windows, mit der Fernbedinung aus S5 aufwecken. Da ich zu gegebener Zeit auf ein Q1900M umsteigen möchte beginnen diesbezüglich die Probleme. Ich würde es gerne vermeiden Software laufen zu lassen, die die empfangenen IR-Codes nach /dev/input/eventx mappt (lircd, irmplircd etc.) Das Mapping der Events auf den lircd Socket soll per eventlircd geschehen. Der Empfänger soll per USB angeschlossen werden. Dementsprechend fallen folgende Sachen für mich raus:

    • yausbir: gepatchter lircd
    • usbasp: irmplircd (usb-hid)
    • attric: lircd (irman)
    • yard: eigener daemon
    • mcesub: kann kein Wakeup aus S5

    Habe ich etwas übersehen? Falls nicht bleibt wohl nur Marke Eigenbau. Bezüglich der Hardware dachte ich an STM32: billig, verfügbar, spricht ordentliches (kein emuliertes) USB und zumindest mit dem größeren STM32-Board hat man auch noch massig I/O-Ports zum Wakeup per PC-Einschalter, zum IR-Blasting (erstmal nicht so wichtig) und zum Spielen. ;)
    Jetzt bleibt nur die Frage wie vermittelt man dem Kernel die IR-Codes? Hier sehe ich momentan zwei Möglichkeiten:

    • usb-hid: Liefert der direkt events die man nutzen kann? Wie setze ich den WakeUp-Code? Worüber realisiert man IR-Blasting? Jeweils neue USB Endpoints?
    • mceusb: Kann man den WakeUp-Code einstellen und wie? Wie läuft das IR-Blasting? Implementiert ist es im Kernel, die Frage ist nur wie spricht man es vom Userspace aus an?
    Zitat von olebowle

    Ich würde es gerne vermeiden Software laufen zu lassen, die die empfangenen IR-Codes nach /dev/input/eventx mappt (lircd, irmplircd etc.)

    Das machen die ja normalerweise gar nicht, sondern legen direkt einen Lirc-Sockel an, von dem der VDR und andere lesen können. lircd lässt sich zwar mit --uinput starten, um ein Event-Device über uinput zu erstellen, aber das verursacht scheußliches Tastenprellen.

    Zitat von olebowle

    Das Mapping der Events auf den lircd Socket soll per eventlircd geschehen.
    Der Empfänger soll per USB angeschlossen werden. Dementsprechend fallen folgende Sachen für mich raus:
    yausbir: gepatchter lircd
    usbasp: irmplircd (usb-hid)
    attric: lircd (irman)
    yard: eigener daemon

    Brauchst du den Umweg über eventlircd, wenn du auch direkt lircd oder einen anderen Daemon laufen lassen kannst, der einen lirc-Sockel bereitstellt? Eventlircd ist ja primär für HID-Geräte gedacht, für die ein Kernel Input Device angelegt wird.
    Bei yaVDR habe ich dann noch alles, was selbst einen Lirc-Sockel erstellt, über lircd2uinput an eventlircd gehängt, aber mit vdr4arch hast du ja alle Freiheiten, wie du dein System konfigurierst ohne Rücksicht auf ein Webfrontend, Vorkonfiguration für Fernbedienungen usw. nehmen zu müssen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Beim STM32 ist es auch möglich, statt USB-HID USB-CDC/VCP zu benutzen, auf dem F105 habe ich das in einem frühen Entwicklungsstadium gemacht, bevor ich auf USB-HID umgestiegen bin, weil ich dachte Kompabilität zu bestehender Software (irmplircd, yavdr) wäre besser. IIRC benutzt yard auch einen virtuellen Com-Port (/dev/ttyACM).

    Ok selbst einen Socket anzulegen ist natürlich besser, das hatte ich wohl übersehen. Ich brauche nicht unbedingt eventlircd, aber irgendwer muss es halt auf den Socket umlegen. Was ich keinenfalls haben will ist lirc patchen zu müssen. Mit dem lircd steh ich ohnehin ein wenig auf Kriegsfuß, weil der sich früher mit meinem CIR in xbmc nach kurzer Zeit aufgehangen hat, wenn man dauerhaft eine Taste gedrückt hat.


    Andererseits hab ich mir nun schonmal ein STM32F103C8T6 bei ebay gekauft und will damit jetzt auch Spielen. Ich frage mich schon, warum noch niemand auf die Idee gekommen ist das MCE-Protokoll auf einem µC nach zu bauen. Das IR-Code empfangen jedenfalls sieht durchaus machbar aus. Zusätzlich hätte es den netten Nebeneffekt auch unter Windows zu laufen, wenn man denn alles nötige implementiert hat.


    EDIT: Wahrscheinlich ist der Weg über irmplircd doch gangbarer, weil das Setzen eines Wakeup-Codes mit MCE nicht wirklich universell ist (nur RC6 und Quatro Pulse, siehe verlinkte PDF, Seite 105-108). Man würde dann wieder ein Userspace Programm benötigen, um man es universell zu machen und gerade das will ich ja nicht - ganz nach dem Motto: https://xkcd.com/927/

    Zitat von olebowle

    Ich frage mich schon, warum noch niemand auf die Idee gekommen ist das MCE-Protokoll auf einem µC nach zu bauen.

    Es gibt da soweit ich weiß zwei Kategorien von MCE-Empfängern - die eine sind die rc-core Empfänger, die mit dem mceusb-Kerneltreiber laufen und der Rest sind MCE-kompatible HID-Geräte, die den Vorgaben für die Tastencodes von Microsoft folgen (die Zusatztasten werden dabei über recht wilde Tastenkombinationen umgesetzt, wie man z.B. an der evmap für den Hama MCE-Empfänger sieht: https://github.com/yavdr/yavdr…ter/evmaps/hama-mce.evmap )


    Ich denke bei den Bastelprojekten ist dann oft auch die Motivation da, möglichst viele Protokolle zu unterstützen, weil das RC-6 MCE Protokoll mit 32 Bit länge allein dann schon wieder Probleme machen kann, wenn man mehr als einen Rechner steuern können möchte (die Decoder von Lirc und rc-core ignorieren ja normalerweise die Address-Bits, die die Fernbedienung sendet).


    Aber ein richtiger RC-6 Decoder auf dem µC, der die Länge der Start-Pulse auswertet und dann anhand eines gemessenen Timeouts auch sauber erkennt und signalisiert, wenn eine Taste wieder losgelassen wurde hat durchaus seine Vorteile - gerade wenn man daraus sauber Events für ein HID-Gerät generieren möchte (da habe ich bei IRMP noch nicht nachgesehen, ob man an die Information kommt, dass der für das IR-Protokoll vorgegebene Timeout für eine losgelassene Taste erreicht wurde)

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Ich bezog mich auf solche, die vom mceusb Modul angesprochen werden. Laut mceusb.c können diese Art von Empfängern alle möglichen Protkolle übertragen, da sie die Pulse- und Spacelängen mit eine Auflösung von 50µs an den Kernel weitergeben und keine eigene Dekodierung per Firmware machen (siehe Bespiel auf Seite 132). Dementsprechend sollte man alle Protokolle empfangen können, die der Kernel dekodieren kann.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden