Infrarot-Fernbedienung auslesen: Den PIC als Universal-Empfänger

Wer eine Infrarot-Fernbedienung auslesen möchte, stößt schnell auf zwei typische Hürden: Erstens wirken IR-Signale wie ein „Rauschteppich“, weil die Trägerfrequenz (meist um 38 kHz) unsichtbar moduliert wird. Zweitens existieren zahlreiche Protokolle, die sich in Pulsbreiten, Startsequenzen und Wiederholtelegrammen unterscheiden. Genau hier ist ein PIC-Mikrocontroller als Universal-Empfänger besonders praktisch: Er kann die demodulierten Pulse eines IR-Empfangsmoduls präzise vermessen, daraus Bits rekonstruieren und anschließend unterschiedliche Protokolle automatisch erkennen oder zumindest robust „lernen“. Das Ergebnis ist ein flexibler IR-Decoder, der nicht auf eine einzige Fernbedienung festgelegt ist. Mit einem PIC lassen sich zudem Komfortfunktionen umsetzen, die fertige Module selten bieten: Entprellung von Wiederholcodes, Speicherung der Tasten in EEPROM, Ausgabe über UART an den PC oder direkte Weiterverarbeitung (z. B. Relais schalten, Menü navigieren). Dieser Artikel zeigt den praxisnahen Weg von der Hardware bis zur Firmware: Welche IR-Receiver-Module geeignet sind, wie Sie Timer und Interrupts einsetzen, wie Protokolle wie NEC oder RC5 grundlegend aufgebaut sind und wie Sie Ihren PIC so programmieren, dass er als zuverlässiger Universal-Empfänger für unterschiedlichste IR-Fernbedienungen funktioniert.

Wie IR-Fernbedienungen wirklich senden: Träger, Modulation und Demodulation

Die meisten klassischen IR-Fernbedienungen senden nicht einfach „Licht an/aus“, sondern modulieren das Licht mit einer Trägerfrequenz, typischerweise 36–40 kHz (am häufigsten 38 kHz). Diese Trägerfrequenz hilft, Umgebungslicht (Sonne, Lampen, Displays) herauszufiltern. Auf die Trägerfrequenz wird dann das eigentliche Nutzsignal aufmoduliert, meist als Puls-/Pausenfolge (On-Off-Keying) oder als bi-phasencodiertes Signal (z. B. Manchester bei RC5).

Für den Mikrocontroller ist es unpraktisch, direkt 38-kHz-Bursts mit Fotodiode und Verstärker auszuwerten. Deshalb nutzt man nahezu immer ein demodulierendes IR-Empfangsmodul (häufig als TSOP/VS1838/ähnlich bekannt). Diese Module enthalten Fotodiode, Vorverstärker, Bandpass, AGC und Demodulator. Am Ausgang liefern sie ein digitales Signal: typischerweise aktiv Low (bei erkanntem IR-Signal zieht der Ausgang auf Low) und ansonsten High.

• Praktischer Effekt: Der PIC misst nicht die 38 kHz, sondern die Dauer von Low-/High-Phasen am Ausgang des Empfängers.
• Störfestigkeit: Gute Module reduzieren Flackern und Umgebungslicht erheblich, sind aber nicht unfehlbar.
• Wichtig: Wählen Sie ein Modul, dessen Mittenfrequenz (z. B. 38 kHz) zur Fernbedienung passt.

Hardware-Bausteine: IR-Receiver, PIC, Versorgung und Signalführung

Ein stabiler Universal-Empfänger beginnt mit sauberer Hardware. Viele Probleme, die später wie „Softwarefehler“ wirken, entstehen in Wirklichkeit durch Versorgungseinbrüche, fehlende Entkopplung oder ungünstige Kabelführung.

IR-Empfangsmodul auswählen

Typische demodulierende IR-Receiver sind z. B. Varianten aus der Vishay-TSOP-Familie oder kompatible 38-kHz-Module. Achten Sie auf:

• Mittenfrequenz: 38 kHz ist der verbreitetste Standard.
• Versorgung: viele Module laufen an 3,3 V und 5 V, prüfen Sie jedoch das Datenblatt.
• Ausgangspegel: meist Open-Collector/Push-Pull, oft aktiv Low.
• AGC-Verhalten: einige Module sind empfindlicher gegenüber Dauerträgern oder bestimmten Störmustern.

Eine leicht zugängliche Übersicht zu IR-Empfängern und Protokollen finden Sie beispielsweise hier: IR Receiver Modules (Vishay). Für allgemeine Protokollinformationen sind folgende Einstiege hilfreich: Consumer IR (Übersicht) und RC-5 Protokoll.

Entkopplung und Layout-Regeln

• 100 nF direkt am IR-Modul: so nah wie möglich an VCC/GND des Empfängers.
• Zusätzlicher Elko: 4,7–10 µF in der Nähe, wenn Leitungen länger sind.
• Kurzer Signalleiter: OUT möglichst nicht parallel zu Motor-/Relaisleitungen führen.
• Saubere Masse: gemeinsamer Sternpunkt reduziert Störimpulse.

Welcher PIC eignet sich?

Für IR-Decoding reichen 8-Bit-PICs meist aus. Entscheidend sind Timer, Interruptfähigkeit und – je nach Komfort – UART für Debug-Ausgaben.

• PIC16/PIC18: ideal für Einsteiger, ausreichend Timer/Interrupts, einfache Toolchain (XC8).
• PIC24/dsPIC: komfortabler bei komplexeren Analysen/Filtern, aber nicht zwingend nötig.

Werkzeuge: MPLAB X IDE und MPLAB XC Compiler.

Messprinzip: Pulsbreiten messen statt Bits „raten“

Ein Universal-Empfänger erkennt Protokolle, indem er Pulse und Pausen misst und daraus ein zeitliches Muster bildet. Das Kernproblem lautet: Wie messe ich die Dauer von High/Low-Phasen zuverlässig? Dafür haben sich zwei robuste Methoden etabliert:

• Interrupt auf Flanke + freilaufender Timer: Bei jeder Flanke (High→Low oder Low→High) lesen Sie den Timerwert und bilden die Zeitdifferenz.
• Input Capture (wenn vorhanden): Hardware erfasst Timerwerte bei Flanken, reduziert Jitter und ISR-Last.

Für viele PICs ist „Interrupt + Timer“ der pragmatische Einstieg. Wichtig ist eine ausreichend feine Auflösung. Typische IR-Pulsbreiten liegen grob zwischen ~400 µs und mehreren Millisekunden, je nach Protokoll.

Timer-Auflösung berechnen

Wenn der PIC mit Taktfrequenz Fosc läuft, ist die Instruktionsfrequenz bei vielen PICs (klassisch) näherungsweise Fcy = Fosc/4. Ein Timer mit Prescaler P tickt dann mit:

$ftick=\frac{Fosc}{4\times P}$

Die Tickdauer ist Ttick = 1/ftick. Mit 16 MHz und Prescaler 8 ergibt sich: Fcy = 4 MHz, ftick = 500 kHz, also 2 µs pro Tick. Damit können Sie Pulsbreiten sehr gut unterscheiden.

Protokoll-Basics: NEC, RC5 und „was da draußen so läuft“

Ein Universal-Empfänger muss nicht jedes Protokoll vollständig „verstehen“, aber er sollte typische Muster erkennen: Startsequenz, Bitcodierung, Wiederholungscode. Zwei häufige Familien:

• Pulse-Distance (z. B. NEC): Bits werden über unterschiedliche Pausenlängen bei ähnlicher Pulsbreite kodiert.
• Biphase/Manchester (z. B. RC5): Jede Bitperiode enthält eine Flanke, die Information steckt im Übergangsmuster.

NEC-Prinzip in der Praxis

Das NEC-Protokoll arbeitet typischerweise mit einer markanten Startsequenz (langer Burst + lange Pause) und danach Bits, bei denen „0“ und „1“ über unterschiedliche Pausenlängen unterschieden werden. Für den Decoder bedeutet das: Sie messen eine Sequenz aus (Pulsdauer, Pausendauer)-Paaren und klassifizieren sie anhand von Toleranzfenstern.

Ein guter Einstieg in IR-Protokolle ist die Dokumentation der bekannten Arduino-IRremote-Bibliothek, auch wenn Sie keinen Arduino nutzen. Sie hilft, Begriffe, Timing und typische Protokollformen einzuordnen: Arduino-IRremote (Protokollübersicht und Timing).

RC5-Prinzip in der Praxis

RC5 nutzt Manchester-Codierung (Biphase). Das heißt: Die Zeitbasis ist konstanter, dafür ist die Dekodierung logischer. Sie messen Flanken in gleichmäßigen Bitfenstern und rekonstruieren die Bits aus dem Übergangsverhalten. Der Vorteil: Robust gegenüber Amplitudenschwankungen; der Nachteil: Timing muss sauber auf eine Grundperiode (T) synchronisiert werden.

„Universal“ umsetzen: Zwei Strategien, die sich bewähren

Es gibt zwei praktikable Wege, den PIC als Universal-Empfänger zu nutzen. Welche Variante Sie wählen, hängt davon ab, ob Sie bekannte Protokolle direkt dekodieren oder einfach Codes „lernen“ und wiedererkennen möchten.

Strategie A: Protokollbasierte Decoder mit Auto-Detection

Sie implementieren Decoder für 2–4 gängige Protokolle (z. B. NEC, RC5, RC6, Sony SIRC) und entscheiden anhand der Startsequenz und Bitstruktur, welcher Decoder aktiv wird. Dafür benötigen Sie:

• Startsequenz-Erkennung (Pre-Amble/Leader)
• Bitdecodierung mit Toleranzfenstern
• Wiederholungscode-Behandlung (Repeat Frames)
• Plausibilitätschecks (Bitlänge, Inversbits, Parität je nach Protokoll)

Vorteil: Sie erhalten strukturierte Ergebnisse (Adresse, Command). Nachteil: Mehr Entwicklungsaufwand, mehr Protokollwissen nötig.

Strategie B: Roh-Timing „lernen“ und matchen

Hier speichert der PIC nicht das Protokoll, sondern das zeitliche Muster als Sequenz von Puls-/Pausendauern (quantisiert). Beim Drücken einer Taste wird die neue Sequenz mit gespeicherten Mustern verglichen (Pattern Matching). Das ist erstaunlich robust, wenn Sie:

• Zeiten auf Raster quantisieren (z. B. 50 µs-Schritte)
• Vergleich mit Toleranz (z. B. ±20%) durchführen
• Repeat-Frames erkennen und ignorieren oder als „Taste gehalten“ markieren

Vorteil: Protokollunabhängig und schnell zu implementieren. Nachteil: Sie bekommen keine semantischen Felder (Adresse/Command), nur ein „Fingerprint“.

Firmware-Design: Interrupt-Routine, Ringbuffer und Decoder-Task

Damit das System stabil bleibt, sollten Sie zeitkritische Messung und komplexe Auswertung trennen. Ein bewährtes Architekturpattern:

• ISR (Flankeninterrupt): Timerwert lesen, Delta berechnen, in Buffer schreiben, minimal logik.
• Main Loop: Buffer auswerten, Frames erkennen, Protokoll dekodieren oder Pattern matchen.
• Optional: Ausgabe über UART (Debug) oder Aktualisierung eines Displays.

Frame-Erkennung: Wann ist ein Telegramm „zu Ende“?

IR-Frames haben zwischen Telegrammen längere Pausen. Eine einfache und sehr wirksame Regel: Wenn die gemessene Pause länger als ein definierter Schwellenwert ist (z. B. 20–40 ms, abhängig vom Protokoll), betrachten Sie den Frame als abgeschlossen und starten die Auswertung. Für Universalbetrieb ist es sinnvoll, den Grenzwert nicht zu knapp zu wählen.

Toleranzen: Ohne Toleranzfenster kein stabiler Decoder

Fernbedienungen, Empfänger-AGC und Timerauflösung sorgen für Streuungen. Arbeiten Sie daher mit Fensterwerten statt fixen Zeiten. Für eine gemessene Dauer t und Sollwert T ist eine relative Toleranz ε praktisch:

$|t-T|\le \epsilon \times T$

Typische Startwerte sind 15–25% je nach Modulqualität und Umgebungsbedingungen. Für Pattern-Matching kann ein noch etwas breiteres Fenster sinnvoll sein.

Praxis: Wiederholcodes und „Taste gehalten“ sauber behandeln

Viele Protokolle senden beim Gedrückthalten nicht dauerhaft komplette Frames, sondern kurze Wiederholtelegramme. Ein Universal-Empfänger sollte das unterscheiden können, sonst wird aus „Lauter“ schnell ein unkontrolliertes Springen.

• Repeat erkennen: anhand kürzerer Frames oder charakteristischer Startsequenz.
• Key-Hold-Logik: wenn Repeat innerhalb eines Zeitfensters kommt, behandeln Sie es als „Taste weiterhin aktiv“.
• Rate-Limit: Aktionen im Gerät (z. B. Menü) mit definierter Wiederholrate ausführen, nicht bei jedem Repeat sofort.

Störquellen im Alltag: Warum es manchmal „spinnt“

IR-Decoding ist in realen Räumen störanfällig. Typische Ursachen:

• LED-Beleuchtung: manche LED-Treiber erzeugen Flimmern im IR-Bereich.
• Sonnenlicht: erhöht Grundrauschen, kann Empfänger-AGC beeinflussen.
• Plasma-/OLED-/Displaystörungen: je nach Technik können IR-Komponenten auftreten.
• Zu lange Leitungen: Signalreflexionen und Einstreuungen, wenn OUT ungeschirmt geführt wird.

Abhilfe schaffen: besseres IR-Modul, bessere Entkopplung, kurze Leitungen, ggf. Gehäuse/Blende (reduziert Fremdlicht), und in der Software robuste Frame-Grenzen sowie Plausibilitätschecks.

Codes ausgeben und nutzen: UART, LCD und Speicherung

Damit der PIC wirklich als Universal-Empfänger taugt, brauchen Sie eine Möglichkeit, die erkannten Codes sichtbar zu machen oder zu speichern. Drei praxistaugliche Wege:

• UART-Ausgabe: Rohzeiten oder dekodierte Werte als Hex an den PC senden.
• LCD/Display: Taste anzeigen, z. B. „VOL+“, wenn Sie Mapping pflegen.
• EEPROM: gelernte Codes persistent speichern, damit nach Neustart alles verfügbar ist.

Für die serielle Diagnose ist UART unschlagbar, weil Sie Timingprobleme und Protokollformen sofort sehen. In MPLAB X können Sie außerdem mit Debugger/Simulator arbeiten, wobei echtes IR-Timing in Hardware immer realistischer ist als Simulation.

Mehrere Fernbedienungen unterstützen: Mapping und Konfiguration

Ein Universal-Empfänger wird besonders nützlich, wenn Sie verschiedene Geräte/Fernbedienungen „vereinheitlichen“. Dafür braucht es ein Mapping:

• Abstrakte Aktionen: PLAY, STOP, UP, DOWN, OK, POWER, MODE.
• Pro Fernbedienung ein Profil: Profil-ID + Codesatz.
• Lernmodus: Nutzer drückt eine Taste, PIC speichert sie unter einer Aktion.
• Konfliktlösung: wenn zwei Tasten sehr ähnliche Muster liefern, erhöhen Sie Vergleichskriterien oder speichern zusätzliche Merkmale (Frame-Länge, Leader, Repeat-Verhalten).

Leistungsfähiger werden: Input Capture, DMA und feinere Zeitbasen

Wenn Sie an Grenzen stoßen (hohe ISR-Last, viele Achsen/Tasks gleichzeitig), gibt es technische Upgrades:

• Input Capture: Flankenzeitstempel in Hardware, weniger Jitter.
• Größerer Buffer: Ringbuffer mit Overflow-Erkennung, um Frames zuverlässig aufzunehmen.
• Bessere Zeitbasis: feinere Ticks (z. B. 1–2 µs) und klare Maximalwerte, um Überläufe zu handhaben.
• Prioritäten: IR-Flankeninterrupt höher priorisieren als UI/Kommunikation (je nach PIC-Familie).

Outbound-Links für Protokolle, Module und Praxiswissen

• Vishay IR Receiver Modules (Übersicht und Auswahl)
• Arduino-IRremote (Protokolle, Timing, Beispiele)
• Consumer IR – Überblick über Infrarot-Fernbedienungen
• RC-5 Protokoll (Manchester/Biphase-Grundlagen)
• MPLAB X IDE
• MPLAB XC Compiler

IoT-PCB-Design, Mikrocontroller-Programmierung & Firmware-Entwicklung

PCB Design • Arduino • Embedded Systems • Firmware

Ich biete professionelle Entwicklung von IoT-Hardware, einschließlich PCB-Design, Arduino- und Mikrocontroller-Programmierung sowie Firmware-Entwicklung. Die Lösungen werden zuverlässig, effizient und anwendungsorientiert umgesetzt – von der Konzeptphase bis zum funktionsfähigen Prototyp.

Diese Dienstleistung richtet sich an Unternehmen, Start-ups, Entwickler und Produktteams, die maßgeschneiderte Embedded- und IoT-Lösungen benötigen. Finden Sie mich auf Fiverr.

Leistungsumfang:

• IoT-PCB-Design & Schaltplanerstellung

• Leiterplattenlayout (mehrlagig, produktionstauglich)

• Arduino- & Mikrocontroller-Programmierung (z. B. ESP32, STM32, ATmega)

• Firmware-Entwicklung für Embedded Systems

• Sensor- & Aktor-Integration

• Kommunikation: Wi-Fi, Bluetooth, MQTT, I²C, SPI, UART

• Optimierung für Leistung, Stabilität & Energieeffizienz

Lieferumfang:

• Schaltpläne & PCB-Layouts

• Gerber- & Produktionsdaten

• Quellcode & Firmware

• Dokumentation & Support zur Integration

Arbeitsweise:Strukturiert • Zuverlässig • Hardware-nah • Produktorientiert

CTA:
Planen Sie ein IoT- oder Embedded-System-Projekt?
Kontaktieren Sie mich gerne für eine technische Abstimmung oder ein unverbindliches Angebot. Finden Sie mich auf Fiverr.