LIRC-Box

Wer den heimischen Medienserver aus mehreren Zimmern fernsteuern will, muss neue Infrarotsensoren aufstellen und neue Kabel ziehen. Sind schon Netzwerkanschlüsse vorhanden, dann kann man die Fernsteuerbefehle mit zusätzlicher Hardware leicht darüber transportieren.

In Pocket speichern vorlesen Druckansicht 1 Kommentar lesen
Lesezeit: 10 Min.
Von
Inhaltsverzeichnis

Einen dauerlaufenden Server, der digitale TV-Aufzeichnungen direkt aus dem TV-Kabel respektive der Sat-TV-Anlage speichert [1] oder der die umfangreiche Musiksammlung via LAN bereitstellt, platziert man am besten dort, wo er am wenigsten stört - etwa im Arbeitszimmer oder im Keller. Allerdings hapert es dann an der bequemen Steuerung per Infrarot-Fernbedienung vom Sofa aus, weil IR-Licht nicht durch Wände geht. Zwar unterstützt LIRC [2] - Linux Infrared Remote Control, ein Open-Source-Projekt zum Fernsteuern von Linux-Rechnern und Programmen mittels gewöhnlicher Infrarot-Fernbedienungen [2] - verschiedene IR-Sensoren, die man per Kabel an die serielle oder parallele Schnittstelle anschließen kann. Bis jetzt war jedoch keiner dabei, den man an einen vorhandenen Twisted-Pair-Netzwerkanschluss hängen kann.

Um die Infrarot-Befehle aus der Fernbedienung zu dekodieren und LIRC-gerecht so aufzubereiten, dass sie ohne übermäßigen Datenverkehr übers LAN gehen, braucht es etwas Rechenleistung. Die stellt ein streichholzschachtelkleiner Controller auf 80186-Basis zur Verfügung [3]. Auf dem IPC@Chip läuft ein echtzeitfähiger DOS-Ableger mit TCP/IP-Stack. Den Controller setzt man am einfachsten auf einer Experimentierplatine DK40 ein [4]. Zwar sind Controller und DK40 mit zusammen etwa 135 Euro nicht eben billig, aber unter Umständen der einzige Weg, das IR-Signal vom dritten Stock in den Keller zu bekommen.

Das IR-Gateway ist nur wenig größer als eine Streichholzschachtel. Den IR-Empfänger muss man jedoch selbst nachrüsten.

Die Entwicklung einer eigenen Platine für das IR-Gateway hätte nicht gelohnt und würde auch kaum billiger kommen, da die DK40 bis auf den IR-Dekoder alles Nötige enthält. Obendrein ersparen sich so im Umgang mit Lötkolben weniger Erfahrene das fehlerträchtige Bestücken - es genügt, den IPC@Chip richtig herum einzusetzen (mit Punkt gekennzeichneter Pin 1 zur Kerbe in der Fassung).

Außer der DK40 benötigt man noch: ein ungeregeltes Steckernetzteil, das etwa 2 Watt bei 15 bis 30 Volt Gleichspannung liefern kann, einen IR-Decoder TSOP1740 sowie einen Tantal-Elko mit 10 µF/16 V. Zwar gibt das Handbuch zur DK40 eine Speisespannung ab 15 Volt vor, doch läuft unsere Platine auch mit 12 Volt zuverlässig. Den IR-Decoder bekommt man etwa bei Reichelt Elektronik (0,74 Euro) oder Conrad Electronic (1,51 Euro). Auf dem IPC@Chip läuft als Gateway-Applikation das Programm lircbox.exe, das auf dem c't-Projektserver kompiliert und im Quelltext liegt (siehe Soft-Link).

Beim Anschluss ans LAN holt sich der IPC@Chip standardmäßig per DHCP eine IP-Nummer. Linux-Anwender können nach einem Ping-Broadcast (zum Beispiel „ping -b -c 1 192.168.0.0“) die vergebene IP über den Shell-Befehl „arp -a“ herausfinden. Die Ethernet-Adresse des IPC@Chip hat in den ersten drei Bytes die Werte 00:30:56, die letzten drei Byte entsprechen der Seriennummer des Controllers. Das Verfahren klappt genauso in der Windows-Kommandozeile, allerdings lauten die Befehle minimal anders: „ping -n 1 192.168.0.0“ und „arp -a“. Windows-Anwender können alternativ das Programm Chiptool nutzen (siehe Soft-Link), seine Find-Funktion zeigt alle im LAN gefundenen Controller mit ihrer Seriennummer an.

Bei der Inbetriebnahme teilt man dem IPC@Chip eine feste IP-Nummer zu.

Eine feste IP-Nummer erleichtert den späteren Zugriff per Telnet (Standard-Username und Passwort: tel) und FTP (User/Passwort: ftp). Diese schreibt man in die Konfigurationsdatei chip.ini aus dem Projektarchiv (siehe Beispiele unten). In autoexec.bat trägt man hinter dem Aufruf von lircbox.exe noch die Adresse des LIRC-Servers ein und lädt alle drei Dateien per FTP auf den Controller. Wer den Upload unter Windows bequem per GUI erledigen möchte, kann mit Filezilla einen komfortablen Freeware-FTP-Client hernehmen. Nach einem Reset läuft dann die Applikation automatisch an.

Eigene Account-Daten für die im IPC@Chip laufenden Telnet- und FTP-Server kann man optional in der Datei chip.ini festlegen. Die dafür nötigen Einträge listet die auf der Website zu findende Dokumentation.

chip.ini:

[IP] DHCP=0 ADDRESS=192.168.111.99 GATEWAY=192.168.111.1 [STDIO] STDIN=EXT TELNET STDOUT=EXT TELNET

autoexec.bat:

lircbox 192.168.111.1 

Die Zeilen mit „EXT TELNET“ in der Konfigurationsdatei chip.ini weisen den Controller an, die zweite serielle Schnittstelle und das Telnet-Interface als Bedienerzugang zu verwenden. Dies vermindert die Wahrscheinlichkeit, dass zufällige Zeichen (Garbage) an der COM-Schnittstelle das Programm versehentlich beenden. Wie bei vielen dauerlaufenden Rechnern kann es gelegentlich nötig werden, den Controller per Strom aus/Strom zurückzusetzen. Im Normalfall sollte das IR-Gateway aber alle zwei Sekunden ein Paket senden, was es durch kurzes Blinken der Traffic/Link-LED anzeigt.

IR-Fernbedienungen senden die Befehle als eine etwa 2 kHz schnelle Pulsfolge von Infrarot-Licht, das mit typisch 38 bis 40 kHz moduliert ist. LIRC verarbeitet diese 2-kHz-Pulsfolge als Folge von „Pulse“- (38-kHz-Signal vorhanden) und „Space“-Zeiten (38-kHz-Signal nicht vorhanden). Normalerweise wertet LIRC dazu das Ausgangssignal eines IR-Decodermoduls selbst aus, lircbox.exe berechnet die Zeiten jedoch intern und schickt die Pulse/Space-Daten über das Netzwerk.

Damit das mit hinreichender Genauigkeit klappt, hängt das IR-Dekoder-IC am interruptfähigen INTA-Pin des IPC@Chip (siehe Schaltplan). Abhängig vom Flankenwechsel am INTA-Pin startet einer der beiden Timer des Controllers (Timer 0 läuft, wenn INTA high ist, Timer 1 bei low). Das Programm muss also beim Flankenwechsel nur den gerade laufenden Timer auslesen, um die gerade empfangene Puls- respektive Space-Zeit zu ermitteln.

Als Eingang für die dekodierten Infrarot-Pulse dient der Interrupt-Pin /INTA des IPC@Chip, der sonst das /CTS-Signal der seriellen Schnittstelle COM auswertet.

Da die normalerweise vom Systemtakt getriebenen Timer aber nur 16 Bit breit sind, laufen sie schnell über. Deshalb programmiert lircbox.exe sie so um, dass sie etwa im Millisekundentakt per Soft-Interrupt einen Überlaufzähler hochzählen. Beim Flankenwechsel verrechnet das Programm dessen Inhalt dann mit dem aktuellen Timer-Wert.

Um den Netzwerk-Verkehr gering zu halten, schickt lircbox.exe seine Daten in einem komprimierten 16-Bit-Format. Das höchstwertige Bit gibt an, ob Pulse oder Space vorliegen, die restlichen 15 Bit enthalten die Länge in 16384stel Sekunden. Das ist selbst für kürzeste IR-Pulse (61 Mikrosekunden) noch genau genug, reicht aber auch für sehr lange Pausen (zwei Sekunden).

Die Messdaten schickt lircbox.exe über UDP auf Port 8765. UDP ist hier günstiger als TCP, weil es weniger Overhead mitbringt und keine stehende Verbindung aufbauen muss. Es funktioniert auch, wenn der empfangende Server mal „geistesabwesend“ ist. Zwar gibt es bei UDP keine sichere Zustellung, aber das sind Anwender von IR-Fernbedienungen auch nicht anders gewohnt. Man drückt bei einem verschluckten Paket einfach nochmal das Knöpfchen.

Damit nun nicht jeder Flankenwechsel am INTA-Pin ein Datenpaket aufs Netz schickt und das Netz so zustopft, speichert die Interrupt-Routine die Daten erstmal zwischen. Das Hauptprogramm schaut nun zehnmal pro Sekunde nach, ob Sendedaten anstehen und schickt diese gegebenenfalls ab. Weil auch der Überlaufzähler irgendwann selbst überläuft, sendet das Programm nach zwei Sekunden ein Paket, wenn es keine Infrarotsignale empfängt. Dieses Feature kann man beispielsweise als Lebenszeichen für einen Soft-Watchdog auf dem LIRC-Server nutzen.

Will man lircbox.exe um eigene Funktionen erweitern, ist derzeit noch das Borland-C-Entwicklungspaket des IPC@Chip-Herstellers nötig. Das Kompilieren mittels freier Tools (ältere Turbo-C-Versionen, GCC) sollte nach Anpassungen möglich sein.

Da LIRC die IR-Pulse selbst auswertet, braucht es einen neuen Hardware-Treiber (hw_udp). Dessen Einbindung erleichtert die Architektur: LIRC braucht lediglich eine Funktion zum Initialisieren des Sockets und eine zur Datenübergabe, wenn diese anstehen. hw_udp ist bereits in den CVS-Tree eingebracht, die Release-Version von LIRC wird den Treiber ab 0.7.0pre1 enthalten.

Den zusätzlichen Stützelko bringt man direkt an den Pins des Infrarot-Decoders TSOP1740 an.

Die Umsetzung der Fernbedienungssignale übernimmt der Daemon lircd anhand der Konfigurationsdatei lirc.conf. Die ausgewerteten Tastencodes können sich eigene Programme oder der Video-Disk-Recorder [2] in /dev/lircd abholen. Wer bereits eine funktionierende LIRC-Konfiguration hat, die beispielsweise Signale über die serielle Schnittstelle ausliest, braucht nur lircd mit der Option für UDP (-H udp) zu starten und schon funktioniert das Fernsteuern übers Netz.

Wer experimentierfreudig ist, kann sich auch an einer selbst gebauten Fernspeisung des IR-Gateways versuchen. Da das DK40 problemlos an Gleichspannungen von 10 bis 30 Volt läuft, kann man es mit etwas Bastelei an seiner Platine sowie am LAN-Switch über die bei Fast Ethernet freien Aderpaare 4/5 und 7/8 speisen. Allerdings sollte man an den entsprechenden Port des Switches keine anderen Netzwerkgeräte mehr anschließen. Nach dem Aufbau sollte man sicherheitshalber mit einem Multimeter überprüfen, ob die Eingangsspannung am DK40 hoch genug ist. Falls nicht, muss man switchseitig etwas mehr Spannung einspeisen.

[1] Peter Siering, TV-Pinguin, Linux als digitaler Videorecorder mit VDR 1.2, c't 14/03, S. 214

[2] Christoph Bartelmus, Ein Pinguin sieht (infra)rot, PC als fernbedienbare Hifi-Anlage, c't 18/00, S. 208

[3] Ernst Ahlers, Netz-Zwerg, Web-Server in der Zigarettenschachtel, c't 2/00, S. 84

[4] Evaluation Module DK40, www.beck-ipc.com/ipc/products/category/index.asp?cat=2&sp=de (ju)