IRMP

2011-07-05T07:58:53Z

79.192.205.99: + Kategorie:AVR-Projekte

Von '''Frank M. ([http://www.mikrocontroller.net/user/show/ukw ukw])'''

= IRMP - Infrarot-Multiprotokoll-Decoder =

[[Datei:irmp-title.png| |Scan eines NEC-kompatiblen Fernbedienungssignals]]

== Einleitung ==

[[Datei:IRMP-TSOP1736.png|miniatur|Anschluß eines IR-Empfängers an µC]]

Da RC5 nicht nur veraltet, sondern mittlerweile obsolet ist und immer mehr die elektronischen Geräte der fernöstlichen Unterhaltungsindustrie in unseren Haushalten Einzug finden, ist es an der Zeit, einen IR-Decoder zu entwickeln, der ca. 90% aller bei uns im täglichen Leben zu findenden IR-Fernbedienungen "versteht".

IRMP - der Infrarot-Fernbedienungsdecoder, der mehrere Protokolle auf einmal decodieren kann, beherrscht folgende Protokolle:

{| class="wikitable"
! Protokoll || Hersteller
|-
| SIRCS || Sony
|-
| NEC || NEC, Yamaha, Canon, Tevion, Harman/Kardon, Hitachi, JVC, Pioneer, Toshiba, Xoro, Orion, NoName und viele weitere japanische Hersteller.
|-
| SAMSUNG || Samsung
|-
| SAMSUNG32 || Samsung
|-
| MATSUSHITA || Matsushita
|-
| KASEIKYO || Panasonic, Technics, Denon und andere japanische Hersteller, welche Mitglied der "Japan's Association for Electric Home Application" sind.
|-
| RECS80 || Philips, Nokia, Thomson, Nordmende, Telefunken, Saba
|-
| RECS80EXT || Philips, Technisat, Thomson, Nordmende, Telefunken, Saba
|-
| RC5 || Philips und andere europäische Hersteller
|-
| DENON || Denon, Sharp
|-
| RC6 || Philips und andere europäische Hersteller
|-
| RC6A || Philips, Kathrein und andere Hersteller, z.B. XBOX ('''NEU!''')
|-
| APPLE || Apple
|-
| NUBERT || Nubert, z.B. Subwoofer System
|-
| B&O || Bang & Olufsen
|-
| GRUNDIG || Grundig
|-
| NOKIA || Nokia, z.B. D-Box
|-
| SIEMENS || Siemens, z.B. Gigaset M740AV (ab ~15kHz, siehe Bemerkungen zu F_INTERRUPTS)
|-
| FDC || FDC Keyboard (ab ~15kHz)
|-
| RCCAR || RC Car: IR Fernbedienung für Modellfahrzeuge
|-
| JVC || JVC ('''NEU!''')
|-
| NIKON || NIKON ('''NEU!''')
|-
| RUWIDO || RUWIDO (z.B. T-Home-Mediareceiver) ('''NEU, nur im SVN!''')
|-
| KATHREIN || KATHREIN ('''NEU, nur im SVN!''')
|-
| NEC16 || JVC ('''NEU, nur im SVN!''')
|-
| NEC42 || JVC ('''NEU, nur im SVN!''')
|-
| LEGO || Lego ('''NEU, nur im SVN!''')
|}

Jedes dieser Protokolle ist einzeln aktivierbar. Wer möchte, kann alle Protokolle aktivieren. Wer nur ein Protokoll braucht, kann alle anderen deaktivieren. Es wird nur das vom Compiler übersetzt, was auch benötigt wird.

'''Ein paar Bemerkungen zu den einzelnen Protokollen:'''

Einige Hersteller verwenden ihr eigenes Protokoll, dazu gehören u.a. Sony, Samsung und Matsushita. Philips hat RC5 entwickelt und natürlich auch selbst benutzt. RC5 galt damals in Europa als ''das'' Standard-IR-Protokoll, welches von vielen europäischen Herstellern übernommen wurde. Mittlerweile ist RC5 fast gar nicht mehr anzutreffen - man kann es eigentlich als "ausgestorben" abhaken.

Auch die japanischen Hersteller haben versucht, einen eigenen Standard zu etablieren, nämlich das sog. Kaseikyo- (oder auch "Japan-") Protokoll. Dieses ist mit einer Bitlänge von 48 sehr universell und allgemein verwendbar. Richtig durchgesetzt hat es sich aber bis heute nicht. Ich selbst habe jedenfalls noch keine einzige Fernbedienung gesehen, die das Kaseikyo-Protokoll nutzt.

Heutzutage wird vornehmlich das NEC-Protokoll verwendet - und zwar von den unterschiedlichsten (Marken- und auch Noname-)Herstellern. Ich schätze den "Marktanteil" auf ca. 80% beim NEC-Protokoll. Fast alle Fernbedienungen im alltäglichen Einsatz verwenden bei mir den NEC-IR-Code. Das fängt beim Fernseher an, geht über vom DVD-Player zur Notebook-Fernbedienung und reicht bis zur Noname-MultiMedia-Festplatte - um nur einige Beispiele zu nennen.

Der auf AVR- und PIC-µCs einsetzbare Source zu IRMP entstand im Rahmen des [[Word Clock]] Projektes.

'''Anlass für einen eigenen IRMP-Artikel ist folgender Thread in der Codesammlung: [http://www.mikrocontroller.net/topic/162119 Beitrag: IRMP - Infrared Multi Protocol Decoder]'''

== Protokolle ==

[[Datei:nec-protocol.png|miniatur|NEC-Protokoll, Reichelt RGB-LED-Fernbedienung, T->A: 9,14ms, A->B: 4,42ms, B->C: 660us]]

Die von IRMP decodierten Protokolle haben etwas gemeinsames: Sie weisen alle ein Start-Bit auf, welches vom Timing her ausgezeichnet, d.h. einmalig ist.

Anhand dieses Start-Bit-Timings werden die verschiedenen Protokolle unterschieden. IRMP misst also das Timing des Start-Bits und stellt dann "on-thy-fly" seine Timingtabellen auf das erkannte Protokoll um, damit die nach dem Start-Bit gesandten Daten in einem Rutsch eingelesen werden können, ohne das komplette Telegramm (Frame) erst speichern zu müssen.

IRMP unterstützt folgende IR-Codings:

* '''Pulse Distance''', typ. Beispiel: NEC, Sony
* '''Bi-Phase''' (Manchester), typ. Beispiel: RC5, RC6
* '''Serial''' (ab 1.9.5), typ. Beispiel: Netbox

Ein '''Puls-Distance-Protokoll''' erkennt man an folgenden Regeln:

* es gibt nur '''eine Pulslänge''' und '''zwei verschiedene Pausenlängen''' oder

* es gibt '''zwei verschiedene Pulslängen''' und nur '''eine Pausenlänge'''

Ein '''Bi-Phase-Protokoll''' erkennt man an:

* es kommen genau '''eine''' Pausen- und eine Pulslänge, sowie jeweils die '''doppelten''' Puls-/Pausenlängen vor

Typisches Kriterium für ein '''bitserielles Protokoll''' ist:

* es kommen '''Vielfache''' einer Grund-Puls-/Pausenlänge vor

'''Eine tabellarische Aufstellung der verschiedenen IR-Protokolle findet man hier: [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail Die IR-Protokolle im Detail].'''

Die angegebenen Timingwerte sind Idealwerte. Bei einigen Fernbedienungen in der Praxis weichen sie um bis zu 40% voneinander ab. Deshalb arbeitet IRMP mit Minimum-/Maximumsgrenzen, um bzgl. des Zeitverhaltens tolerabel zu sein.

== Download ==

Version 1.9.0, Stand vom 18.01.2011

Download Release-Version: [http://www.mikrocontroller.net/wikifiles/7/79/Irmp.zip Irmp.zip]

IRMP & IRSND sind nun auch über SVN abrufbar: [http://www.mikrocontroller.net/svnbrowser/irmp/ IRMP im SVN], Download [http://www.mikrocontroller.net/svnbrowser/irmp/?view=tar Tarball]

'''Achtung:'''

Die Version im SVN kann eine Zwischen- oder Test-Version sein, die nicht den hier dokumentierten Stand widerspiegelt! Im Zweifel verwendet man besser den obigen Download-Link auf Irmp.zip.

'''Die Software-Änderungen kann man sich hier anschauen: [http://www.mikrocontroller.net/articles/IRMP#Software-Historie_IRMP Software-Historie IRMP]'''

== Source-Code ==

Der Source-Code lässt sich einfach für AVR-µCs übersetzen, indem man die Projekt-Datei irmp.aps in den WinAVR lädt.

Aber auch für die Codevision Nutzer ist IRMP entsprechend angepasst: hier muss man die Zeile

<c>
//#define CODEVISION
</c>

in main.c aktivieren, das heisst, die Kommentarzeichen entfernen.

Auch auf PIC-Prozessoren ist IRMP lauffähig. Für den PIC-CCS-Compiler sind entsprechende Preprocessor-Konstanten bereits gesetzt, so dass man irmp.c direkt in der CCS-Entwicklungsumgebung verwenden kann. Lediglich eine kleine Interrupt-Routine wie

<c>
void TIMER2_isr(void)
{
irmp_ISR ();
}
</c>

ist hinzuzufügen, wobei man den Interrupt auf 100µs (also 10kHz) stellt.

Für AVR-Prozessoren ist ein Beispiel für die Anwendung von IRMP in main.c zu finden - im wesentlichen geht es da um die Timer-Initialisierung und den Abruf der empfangenen IR-Telegramme.

Die Konfiguration von IRMP wird über Parameter in irmpconfig.h vorgenommen, nämlich:

* Anzahl Interrupts pro Sekunde
* Unterstützte IR-Protokolle
* Hardware-Pin zum IR-Empfänger
* IR-Logging

=== Speicherplatzoptimierung ===

IRMP decodiert sämtliche oben aufgelisteten Protokolle in einer ISR, siehe irmpconfig.h. Standardmäßig sind nur die meistgebrauchten Protokolle aktiviert. Möchte man zusätzliche Protokolle nutzen, oder weitere Protokolle abschalten, um Speicherplatz zu sparen, sind die entsprechenden Werte in irmpconfig.h durch Setzen von 1 (aktiviert) oder 0 (deaktiviert) neu einzustellen:

<c>
// Protocol Enable Remarks F_INTERRUPTS Program Space
#define IRMP_SUPPORT_SIRCS_PROTOCOL 1 // Sony SIRCS >= 10000 ~100 bytes
#define IRMP_SUPPORT_NEC_PROTOCOL 1 // NEC + APPLE >= 10000 ~250 bytes
#define IRMP_SUPPORT_SAMSUNG_PROTOCOL 1 // Samsung + Samsung32 >= 10000 ~250 bytes
#define IRMP_SUPPORT_MATSUSHITA_PROTOCOL 1 // Matsushita >= 10000 ~50 bytes
#define IRMP_SUPPORT_KASEIKYO_PROTOCOL 1 // Kaseikyo >= 10000 ~250 bytes
#define IRMP_SUPPORT_DENON_PROTOCOL 1 // DENON, Sharp >= 10000 ~250 bytes
#define IRMP_SUPPORT_JVC_PROTOCOL 1 // JVC >= 10000 ~250 bytes
#define IRMP_SUPPORT_RC5_PROTOCOL 1 // RC5 >= 10000 ~250 bytes
#define IRMP_SUPPORT_RC6_PROTOCOL 1 // RC6 & RC6A >= 10000 ~200 bytes
#define IRMP_SUPPORT_GRUNDIG_PROTOCOL 1 // Grundig >= 10000 ~150 bytes
#define IRMP_SUPPORT_NOKIA_PROTOCOL 1 // Nokia >= 10000 ~150 bytes
#define IRMP_SUPPORT_NUBERT_PROTOCOL 0 // NUBERT >= 10000 ~50 bytes
#define IRMP_SUPPORT_BANG_OLUFSEN_PROTOCOL 0 // Bang & Olufsen >= 10000 ~200 bytes
#define IRMP_SUPPORT_NIKON_PROTOCOL 0 // NIKON >= 10000 ~250 bytes
#define IRMP_SUPPORT_FDC_PROTOCOL 0 // FDC3402 keyboard >= 10000 (better 15000) ~50 bytes (~400 in combination with RC5)
#define IRMP_SUPPORT_RCCAR_PROTOCOL 0 // RC Car >= 10000 (better 15000) ~150 bytes (~500 in combination with RC5)
#define IRMP_SUPPORT_SIEMENS_PROTOCOL 0 // Siemens Gigaset >= 15000 ~150 bytes
#define IRMP_SUPPORT_RECS80_PROTOCOL 0 // RECS80 >= 20000 ~50 bytes
#define IRMP_SUPPORT_RECS80EXT_PROTOCOL 0 // RECS80EXT >= 20000 ~50 bytes
</c>

Jedes von IRMP unterstützte IR-Protokoll "verbrät" ungefähr den oben angegebenen Speicher an Code. Hier kann man Optimierungen vornehmen: Zum Beispiel ist die Modulationsfrequenz von 455kHz beim B&O-Protokoll weitab von den Frequenzen, die von den anderen Protokollen verwendet werden. Hier braucht man evtl. andere IR-Empfänger, anderenfalls kann man diese Protokolle einfach deaktiveren. Zum Beispiel kann man mit einem TSOP1738 kein B&O-Protokoll (455kHz) mehr empfangen.

Ausserdem werden die Protokolle SIEMENS/FDC/RCCAR erst ab einer Scan-Frequenz von ca. 15kHz zuverlässig erkannt. Bei RECS80/REC80EXT sind es sogar 20kHz. Wenn man also diese Protokolle nutzen will, muss man F_INTERRUPTS entsprechend anpassen, sonst erscheint beim Übersetzen eine entsprechende Warnung und die entsprechenden Protokolle werden dann automatisch abgeschaltet.

=== Anwendung von IRMP ===

Die von IRMP unterstützten Protokolle weisen Bitlängen - teilweise variabel, teilweise fest - von 12 bis 48 Bit auf. Diese werden über Preprocessor-Defines beschrieben.

IRMP trennt diese IR-Telegramme prinzipiell in 3 Bereiche:

1. ID für verwendetes Protokoll
2. Adresse bzw. Herstellercode
3. Kommando

Mittels der Funktion

irmp_get_data (IRMP_DATA * irmp_data_p)

kann man ein decodiertes Telegramm abrufen. Der Return-Wert ist 1, wenn ein Telegramm eingelesen wurde, sonst 0. Im ersten Fall werden die Struct-Members

<c>
irmp_data_p->protocol
irmp_data_p->address
irmp_data_p->command
irmp_data_p->flags
</c>

gefüllt.

Das heisst: am Ende bekommt man dann über irmp_get_data() einfach drei
Werte (Protokoll, Adresse und Kommando-Code), die man über ein if oder switch checken kann, z. B. hier eine Routine, welche die Tasten 1-9 auf einer Fernbedienung auswertet:

<c>
IRMP_DATA irmp_data;

if (irmp_get_data (&irmp_data))
{
if (irmp_data.protocol == IRMP_NEC_PROTOCOL && // NEC-Protokoll
irmp_data.address == 0x1234) // Adresse 0x1234
{
switch (irmp_data.command)
{
case 0x0001: key1_pressed(); break; // Taste 1
case 0x0002: key2_pressed(); break; // Taste 2
...
case 0x0009: key9_pressed(); break; // Taste 9
}
}
}
</c>

Hier die möglichen Werte für irmp_data.protocol, siehe auch irmp.h:

<c>
#define IRMP_SIRCS_PROTOCOL 1 // Sony
#define IRMP_NEC_PROTOCOL 2 // NEC, Pioneer, JVC, Toshiba, NoName etc.
#define IRMP_SAMSUNG_PROTOCOL 3 // Samsung
#define IRMP_MATSUSHITA_PROTOCOL 4 // Matsushita
#define IRMP_KASEIKYO_PROTOCOL 5 // Kaseikyo (Panasonic etc)
#define IRMP_RECS80_PROTOCOL 6 // Philips, Thomson, Nordmende, Telefunken, Saba
#define IRMP_RC5_PROTOCOL 7 // Philips etc
#define IRMP_DENON_PROTOCOL 8 // Denon, Sharp
#define IRMP_RC6_PROTOCOL 9 // Philips etc
#define IRMP_SAMSUNG32_PROTOCOL 10 // Samsung32: no sync pulse at bit 16, length 32 instead of 37
#define IRMP_APPLE_PROTOCOL 11 // Apple, very similar to NEC
#define IRMP_RECS80EXT_PROTOCOL 12 // Philips, Technisat, Thomson, Nordmende, Telefunken, Saba
#define IRMP_NUBERT_PROTOCOL 13 // Nubert
#define IRMP_BANG_OLUFSEN_PROTOCOL 14 // Bang & Olufsen
#define IRMP_GRUNDIG_PROTOCOL 15 // Grundig
#define IRMP_NOKIA_PROTOCOL 16 // Nokia
#define IRMP_SIEMENS_PROTOCOL 17 // Siemens, e.g. Gigaset
#define IRMP_FDC_PROTOCOL 18 // FDC keyboard
#define IRMP_RCCAR_PROTOCOL 19 // RC Car
#define IRMP_JVC_PROTOCOL 20 // JVC
#define IRMP_RC6A_PROTOCOL 21 // RC6A, e.g. Kathrein, XBOX
#define IRMP_NIKON_PROTOCOL 22 // Nikon
</c>

Die Werte für die Adresse und das Kommando muss man natürlich einmal für eine unbekannte Fernbedienung auslesen und dann über ein UART oder LC-Display ausgeben, um sie dann im Programm hart zu kodieren. Oder man hat eine kleine Anlernroutine, wo man einmal die gewünschten Tasten drücken muss, um sie anschließend im EEPROM abzuspeichern. Ein Beispiel dazu findet man im Artikel [http://www.mikrocontroller.net/articles/DIY_Lernfähige_Fernbedienung_mit_IRMP Lernfähige IR-Fernbedienung mit IRMP].

Eine weitere Beispiel-Main-Funktion ist im Zip-File enthalten, da sieht man dann auch die Initialisierung des Timers.

=== "Entprellen" von Tasten ===

Um zu unterscheiden, ob eine Taste lange gedrückt wurde oder lediglich einzeln, dient das Bit IRMP_FLAG_REPETITION. Dieses wird im Struct-Member '''flags''' gesetzt, wenn eine Taste auf der Fernbedienung längere Zeit gedrückt wurde und dadurch immer wieder dasselbe Kommando innerhalb kurzer Zeitabstände ausgesandt wird.

Beispiel:

<c>
if (irmp_data.flags & IRMP_FLAG_REPETITION)
{
// Benutzer hält die Taste länger runter
// entweder:
// ich ignoriere die (Wiederholungs-)Taste
// oder:
// ich benutze diese Info, um einen Repeat-Effekt zu nutzen
}
else
{
// Es handelt sich um eine neue Taste
}
</c>

Dies kann zum Beispiel dafür genutzt werden, um die Tasten 0-9 zu "entprellen", indem man Kommandos mit gesetztem Bit IRMP_FLAG_REPETITION ignoriert. Bei dem Drücken auf die Tasten VOLUME+ oder VOLUME- kann die wiederholte Auswertung ein und desselben Kommandos aber durchaus gewünscht sein - zum Beispiel, um LEDs zu faden.

Wenn man nur Einzeltasten auswerten will, kann man obigen IF-Block reduzieren auf:

<c>
if (! (irmp_data.flags & IRMP_FLAG_REPETITION))
{
// Es handelt sich um eine neue Taste
// ACTION!
}
</c>

== Arbeitsweise ==

Das "Working Horse" von IRMP ist die Interrupt Service Routine irmp_ISR() welche 10.000 mal pro Sekunde aufgerufen werden sollte. Weicht dieser Wert ab, muss die Preprocessor-Konstante F_INTERRUPTS in irmpconfig.h angepasst werden. Dieser kann durchaus höher werden, aber nicht wesentlich kleiner. Sonst wird es kritisch mit der Protokoll-Erkennung.

irmp_ISR detektiert zunächst die Länge und die Form des/der Startbits und ermittelt daraus das verwendete Protokoll. Sobald das Protokoll erkannt wurde, werden die weiter einzulesenden Bits parametrisiert, um dann möglichst effektiv in den weiteren Aufrufen das komplette IR-Telegramm einzulesen.

Um direkt Kritikern den Wind aus den Segeln zu nehmen:

Ich weiss, die ISR ist ziemlich groß. Aber da sie sich wie eine State Machine verhält, ist der tatsächlich ausgeführte Code pro Durchlauf relativ gering. Solange es "dunkel" ist (und das ist es ja die meiste Zeit ;-)) ist die aufgewendete Zeit sogar verschwindend gering. Im WordClock-Projekt werden mit ein- und demselben Timer 8 ISRs aufgerufen, davon ist die irmp_ISR() nur eine unter vielen. Bei mindestens 8 MHz CPU-Takt traten bisher keine Timining-Probleme auf. Daher sehe ich bei der Länge von irmp_ISR überhaupt kein Problem.

Ein Quarz ist nicht unbedingt notwendig, es funktioniert auch mit dem internen Oszillator des AVRs, wenn man die Prescaler-Fuse entsprechend gesetzt hat, dass die CPU auch mit 8MHz rennt ... Die Fuse-Werte für einen ATMEGA88 findet man in main.c

Zur Hardware: IRMP sollte so ziemlich für alle ATMegas übersetzbar sein,
das Beispiel-Projekt wurde auf ATMEGA88 eingestellt.

Der Pin, an dem der IR-Empfänger angeschlossen wird, ist frei wählbar
und wird in irmpconfig.h über

<c>
#define IRMP_PORT PORTB
#define IRMP_DDR DDRB
#define IRMP_PIN PINB
#define IRMP_BIT 6 // use PB6 as IR input
</c>

eingestellt.

== Scannen von unbekannten Protokollen ==

Stellt man in irmpconfig.h in der Zeile

<c>
#define IRMP_LOGGING 0 // 1: log IR signal (scan), 0: do not (default)
</c>

den Wert für IRMP_LOGGING auf 1, wird in IRMP eine Protokollierung eingeschaltet: Es werden dann die Hell- und Dunkelphase auf dem UART des Microntrollers mit 9600Bd ausgegeben: 1=Dunkel, 0=Hell. Eventuell müssen dann die Konstanten in den Funktionen uart_init() und uart_putc() angepasst werden; das kommt auf den verwendeten AVR-µC an.

'''Hinweis: Die IRMP-Logging-Funktion (insb. die Ausgabe über UART) ist nicht für PIC-Prozessoren angepasst. Wer immer dies tun möchte, kann sich gerne bei mir (Benutzer [http://www.mikrocontroller.net/user/show/ukw ukw]) per PN melden.

Nimmt man diese Protokoll-Scans mit einem Terminal-Emulationsprogramm auf und speichert sie dann als normale Datei ab, kann man diese Scan-Dateien zur Analyse verwenden, um damit IRMP an das unbekannte Protokoll anzupassen - siehe nächstes Kapitel.

Wer eine Fernbedienung hat, die nicht von IRMP unterstützt wird, kann mir ([http://www.mikrocontroller.net/user/show/ukw ukw]) gern die Scan-Dateien zuschicken. Ich schaue dann, ob das Protokoll in das IRMP-Konzept passt und passe gegebenenfalls den Source an.

== IRMP unter Linux und Windows ==

irmp.c lässt sich auch unter Linux direkt kompilieren, um damit Infrarot-Scans, welche in Dateien gespeichert sind, direkt zu testen. Im Unterordner IR-Data finden sich solche Dateien, die man dem IRMP direkt zum "Fraß" vorwerfen kann.

Das Übersetzen von IRMP geht folgendermaßen:

make -f makefile.lnx

Dabei werden 3 IRMP-Versionen erzeugt:

* irmp: Version für 10kHz Scans
* irmp-15kHz: Version für 15kHz Scans
* irmp-20kHz: Version für 20kHz Scans

Der Aufruf geschieht dann über:

./irmp [-l|-p|-a|-v] < scan-file

Die angegebenen Optionen schließen sich aus, das heisst, es kann jeweils nur eine Option zu einer Zeit angegeben werden:

Option:

-l List gibt eine Liste der Pulse und Pausen aus
-a analyze analysiert die Puls-/Pausen und schreibt ein "Spektrum" in ASCII-Form
-v verbose ausführliche Ausgabe
-p Print Timings gibt für alle Protokolle eine Timing-Tabelle aus

Beispiele:

'''Normale Ausgabe:'''

./irmp < IR-Data/orion_vcr_07660BM070.txt

<c>
-------------------------------------------------------------------------
# Taste 1
00000001110111101000000001111111 p = 2, a = 0x7b80, c = 0x0001, f = 0x00
-------------------------------------------------------------------------
# Taste 2
00000001110111100100000010111111 p = 2, a = 0x7b80, c = 0x0002, f = 0x00
-------------------------------------------------------------------------
# Taste 3
00000001110111101100000000111111 p = 2, a = 0x7b80, c = 0x0003, f = 0x00
-------------------------------------------------------------------------
# Taste 4
00000001110111100010000011011111 p = 2, a = 0x7b80, c = 0x0004, f = 0x00
-------------------------------------------------------------------------
...
</c>

'''Listen-Ausgabe:'''

./irmp -l < IR-Data/orion_vcr_07660BM070.txt

<c>
# Taste 1
pulse: 91 pause: 44
pulse: 6 pause: 5
pulse: 6 pause: 6
pulse: 6 pause: 5
pulse: 6 pause: 5
pulse: 6 pause: 5
pulse: 6 pause: 6
pulse: 6 pause: 5
pulse: 6 pause: 16
...
</c>

'''Analyse:'''

./irmp -a < IR-Data/orion_vcr_07660BM070.txt

<c>
-------------------------------------------------------------------------------
START PULSES:
90 o 1
91 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 33
92 ooo 2
pulse avg: 91.0=9102.8 us, min: 90=9000.0 us, max: 92=9200.0 us, tol: 1.1%
-------------------------------------------------------------------------------
START PAUSES:
43 oo 1
44 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 25
45 oooooooooooooooooooooooo 10
pause avg: 44.2=4425.0 us, min: 43=4300.0 us, max: 45=4500.0 us, tol: 2.8%
-------------------------------------------------------------------------------
PULSES:
5 o 17
6 ooooooooooooooooooooooooooooooooooooooooooooooooooooooo 562
7 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 609
pulse avg: 6.5= 649.8 us, min: 5= 500.0 us, max: 7= 700.0 us, tol: 23.1%
-------------------------------------------------------------------------------
PAUSES:
4 ooooooooooooooooooooooo 169
5 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 412
6 oooo 31
pause avg: 4.8= 477.5 us, min: 4= 400.0 us, max: 6= 600.0 us, tol: 25.7%
15 oooooo 43
16 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 425
17 oooooooooo 72
pause avg: 16.1=1605.4 us, min: 15=1500.0 us, max: 17=1700.0 us, tol: 6.6%
-------------------------------------------------------------------------------
</c>

Hier sieht man die gemessenen Zeiten aller Pulse und Pausen als (liegende) Glockenkurven, welche natürlich wegen der ASCII-Darstellung nicht gerade einer Idealkurve entsprechen. Je schmaler die gemessenen Kanäle, desto besser ist das Timing der Fernbedienung.

Aus obigem Output kann man herauslesen:

* Das Start-Bit hat eine Pulslänge zwischen 9000 und 9200 usec, im Mittel sind es 9102 usec. Die Abweichung von diesem Mittelwert liegt bei 1,1 Prozent.

* Das Start-Bit hat eine Pausenlänge zwischen 4300 usec und 4500 usec, der Mittelwert beträgt 4424 usec. Der Fehler liegt bei 2,8 Prozent.

* Die Pulslänge eines Datenbits liegt zwischen 500 usec und 700 usec, im Mittel sind es 650 usec, der Fehler liegt bei (stolzen) 23,1 Prozent!

Desweiteren gibt es noch 2 verschieden lange Pausen (für die Bits 0 und 1), das Ablesen der Werte überlasse ich dem geneigten Leser ;-)

'''Ausführliche Ausgabe:'''

./irmp -v < IR-Data/orion_vcr_07660BM070.txt

<c>
-------------------------------------------------------------------------------
# Taste 1
26084 [starting pulse]
start-bit: pulse = 91, pause = 44
protocol = NEC, start bit timings: pulse: 53 - 127, pause: 26 - 64
pulse_1: 2 - 9
pause_1: 9 - 25
pulse_0: 2 - 9
pause_0: 2 - 9
command_offset: 16
command_len: 16
complete_len: 32
stop_bit: 1
26230 [bit 0: pulse = 6, pause = 5] 0
26242 [bit 1: pulse = 6, pause = 6] 0
26253 [bit 2: pulse = 6, pause = 5] 0
26264 [bit 3: pulse = 6, pause = 5] 0
...
26749 [bit 31: pulse = 6, pause = 17] 1
stop bit detected
code detected, length = 32
p = 2, a = 0x7b80, c = 0x0001, f = 0x00
-------------------------------------------------------------------------------
</c>

'''Timing-Tabelle:'''

./irmp -p

<c>
IRMP_TIMEOUT_LEN: 165
IRMP_KEY_REPETITION_LEN 1500

PROTOCOL S S-PULSE S-PAUSE PULSE-0 PAUSE-0 PULSE-1 PAUSE-1
====================================================================================
SIRCS 1 21 - 27 4 - 7 4 - 8 4 - 8 10 - 14 4 - 8
NEC 1 53 - 127 26 - 64 2 - 9 2 - 9 2 - 9 9 - 25
NEC (rep) 1 53 - 127 13 - 32 2 - 9 2 - 9 2 - 9 9 - 25
SAMSUNG 1 40 - 51 40 - 51 3 - 8 2 - 7 3 - 8 9 - 20
MATSUSHITA 1 27 - 43 27 - 43 4 - 13 4 - 13 4 - 13 15 - 38
KASEIKYO 1 29 - 38 14 - 20 1 - 8 1 - 7 1 - 8 5 - 20
RECS80 1 1 - 3 66 - 83 0 - 3 43 - 55 0 - 3 66 - 83
RC5 1 7 - 11 7 - 11 7 - 11
DENON 1 1 - 4 1 - 4 6 - 10 1 - 4 16 - 22
RC6 1 23 - 30 7 - 11 3 - 6
RECS80EXT 1 1 - 3 34 - 39 0 - 3 43 - 55 0 - 3 66 - 83
NUBERT 1 10 - 17 2 - 5 3 - 7 9 - 17 10 - 17 2 - 5
BANG_OLUFSEN 1 1 - 3 27 - 35
BANG_OLUFSEN 2 1 - 3 27 - 35
BANG_OLUFSEN 3 1 - 3 140 - 165
BANG_OLUFSEN 4 1 - 3 27 - 35
BANG_OLUFSEN - 1 - 3 27 - 35 1 - 3 83 - 104
GRUNDIG/NOKIA 1 3 - 7 22 - 33 3 - 7
SIEMENS 1 2 - 4 2 - 4 2 - 4
FDC 1 18 - 24 8 - 12 1 - 5 1 - 3 1 - 5 5 - 10
RCCAR 1 17 - 23 17 - 23 4 - 8 5 - 13 4 - 8 2 - 7
</c>

Bei längeren Ausgaben sollte man das Programm "less" verwenden, um seitenweise zu blättern, z.B.:

./irmp -v < IR-Data/Samsung_DVD_Rec_00062C.txt | less

Diese Scan-Dateien halfen mir nicht nur bei der Entwicklung des IRMP, sondern können auch bei der Anpassung des Sources an neue IR-Protokolle sehr hilfreich sein.

Mittlerweile kann man IRMP auch unter Windows nutzen, nämlich folgendermaßen:

* Eingabeaufforderung starten
* In das Verzeichnis irmp wechseln
* Aufruf von:
irmp.exe < IR-Data\rc5x.txt

Da manche Ausgaben sehr lang werden, empfiehlt es sich auch hier, die Ausgabe in eine Datei zu lenken oder in den more weiterzuleiten, damit man seitenweise blättern kann:

irmp.exe < IR-Data\rc5x.txt | more

Auch hier gelten dieselben Optionen wie für die Linux-Version.

Zusatz:

Der Decoder für das RECS80- und RECS80-Extended-Protokoll ist ungetestet, wurde anhand von Dokumentationen im Internet erstellt und lediglich mittels
künstlich erzeugten Scan-Dateien getestet... daher: keine Gewähr!

== Fernbedienungen ==

{| class="wikitable"
! Protokoll || Bezeichnung || Gerät || Device Address
|-
| NEC || Toshiba CT-9859 || Fernseher || 765
|-
| || Toshiba VT-728G || V-728G Videorekorder || 8925
|-
| || Elta 8848 MP 4 || DVD-Player || 255
|-
| || AS-218 || Askey TV-View CHP03X (TV-Karte) || 25046
|-
| || Cyberhome ??? || Cyberhome DVD Player || 20147
|-
| || WD TV Life || Western Digital Multimediaplayer || 7984
|-
| KASEIKYO || Technics EUR646497 || AV Receiver SA-AX 730 || 8194
|-
| RC5 || Loewe Assist/RC3/RC4 || Fernseher (FB auf TV-Mode) || 0
|-
| RC6 || Philips Television || Fernseher (FB auf TV-Mode) || 0
|-
| SIRCS || Sony RM-816 || Fernseher (FB auf TV-Mode) || 0 (siehe Beschreibung)
|-
| DENON || DENON RC970 || AVR3805 (Verstärker) || 8
|-
| || DENON RC970 || DVD/CD-Player || 2
|-
| || DENON RC970 || Tuner || 6
|-
|}

----
== IR-Tastaturen ==

[[Datei:irmp-fdc3402.jpg|miniatur|FDC-3402-Tastatur]]

IRMP unterstützt ab Version 1.7.0 auch IR-Tastaturen, nämlich die Infrarot-Tastatur FDC-3402 - erhältlich bei Pollin (Art. 711 056) für weniger als 2 EUR.

Beim Erkennen einer Taste gibt IRMP folgende Daten zurück:

Protokoll-Nummer (irmp_data.protocol): 18
Addresse (irmp_data.address): 0x003F

Als Kommando (irmp_data.command) werden folgende Werte zurückgeliefert:

{| class="wikitable"
! Code || Taste || Code || Taste || Code || Taste || Code || Taste || Code || Taste || Code || Taste || Code || Taste || Code || Taste
|-
| 0x0000 || || 0x0010 || TAB || 0x0020 || 's' || 0x0030 || 'c' || 0x0040 || || 0x0050 || HOME || 0x0060 || || 0x0070 || MENUE
|-
| 0x0001 || '^' || 0x0011 || 'q' || 0x0021 || 'd' || 0x0031 || 'v' || 0x0041 || || 0x0051 || END || 0x0061 || || 0x0071 || BACK
|-
| 0x0002 || '1' || 0x0012 || 'w' || 0x0022 || 'f' || 0x0032 || 'b' || 0x0042 || || 0x0052 || || 0x0062 || || 0x0072 || FORWARD
|-
| 0x0003 || '2' || 0x0013 || 'e' || 0x0023 || 'g' || 0x0033 || 'n' || 0x0043 || || 0x0053 || UP || 0x0063 || || 0x0073 || ADDRESS
|-
| 0x0004 || '3' || 0x0014 || 'r' || 0x0024 || 'h' || 0x0034 || 'm' || 0x0044 || || 0x0054 || DOWN || 0x0064 || || 0x0074 || WINDOW
|-
| 0x0005 || '4' || 0x0015 || 't' || 0x0025 || 'j' || 0x0035 || ',' || 0x0045 || || 0x0055 || PAGE_UP || 0x0065 || || 0x0075 || 1ST_PAGE
|-
| 0x0006 || '5' || 0x0016 || 'z' || 0x0026 || 'k' || 0x0036 || '.' || 0x0046 || || 0x0056 || PAGE_DOWN || 0x0066 || || 0x0076 || STOP
|-
| 0x0007 || '6' || 0x0017 || 'u' || 0x0027 || 'l' || 0x0037 || '-' || 0x0047 || || 0x0057 || || 0x0067 || || 0x0077 || MAIL
|-
| 0x0008 || '7' || 0x0018 || 'i' || 0x0028 || 'ö' || 0x0038 || || 0x0048 || || 0x0058 || || 0x0068 || || 0x0078 || FAVORITES
|-
| 0x0009 || '8' || 0x0019 || 'o' || 0x0029 || 'ä' || 0x0039 || SHIFT_RIGHT || 0x0049 || || 0x0059 || RIGHT || 0x0069 || || 0x0079 || NEW_PAGE
|-
| 0x000A || '9' || 0x001A || 'p' || 0x002A || '#' || 0x003A || CTRL || 0x004A || || 0x005A || || 0x006A || || 0x007A || SETUP
|-
| 0x000B || '0' || 0x001B || 'ü' || 0x002B || CR || 0x003B || || 0x004B || INSERT || 0x005B || || 0x006B || || 0x007B || FONT
|-
| 0x000C || 'ß' || 0x001C || '+' || 0x002C || SHIFT_LEFT || 0x003C || ALT_LEFT || 0x004C || DELETE || 0x005C || || 0x006C || || 0x007C || PRINT
|-
| 0x000D || '´' || 0x001D || || 0x002D || '<' || 0x003D || SPACE || 0x004D || || 0x005D || || 0x006D || || 0x007D ||
|-
| 0x000E || || 0x001E || CAPSLOCK || 0x002E || 'y' || 0x003E || ALT_RIGHT || 0x004E || || 0x005E || || 0x006E || ESCAPE || 0x007E || ON_OFF
|-
| 0x000F || BACKSPACE || 0x001F || 'a' || 0x002F || 'x' || 0x003F || || 0x004F || LEFT || 0x005F || || 0x006F || || 0x007F ||
|-
|}

Zusatztasten links:

{| class="wikitable"
! Code || Taste
|-
|-
| 0x0400 || KEY_MOUSE_1
|-
| 0x0800 || KEY_MOUSE_2
|}

Dabei gelten die obigen Werte für das Drücken einer Taste. Wird die Taste wieder losgelassen, setzt IRMP zusätzlich das 8. Bit im Kommando.

Beispiel:

Taste 'a' drücken: 0x001F
Taste 'a' loslassen: 0x009F

Ausnahme ist die EIN/AUS-Taste: Diese sendet nur beim Drücken einen Code, nicht beim Loslassen.

Wird eine Taste länger gedrückt, wird das in irmp_data.flag angezeigt.

Beispiel:

command flag
Taste 'a' drücken: 0x001F 0x00
Taste 'a' drücken: 0x001F 0x01
Taste 'a' drücken: 0x001F 0x01
Taste 'a' drücken: 0x001F 0x01
....
Taste 'a' loslassen: 0x009F 0x00

Werden Tastenkombinationen (zum Beispiel für ein großes 'A') gedrückt, dann sind die Rückgabewerte von IRMP in folgendem Ablauf zu sehen:

Linke SHIFT-Taste drücken: 0x0002
Taste 'a' drücken: 0x001F
Taste 'a' loslassen: 0x009F
Linke SHIFT-Taste loslassen: 0x0082

In irmp.c findet man für die LINUX-Version eine Funktion get_fdc_key(), welche als Vorlage dienen mag, die Keycodes einer FDC-Tastatur in die entsprechenden ASCII-Codes umzuwandeln. Diese Funktion kann man entweder lokal auf dem µC nutzen, um die Keycodes zu decodieren, oder auf einem Hostsystem (z.B. PC), an welches die IRMP-Data-Struktur gesandt wird. Dafür sollte man die Funktion incl. der dazugehörenden Preprozessor-Konstanten in seinen Applikations-Quelltext kopieren.

Hier der entsprechende Auszug:
<c>
#define STATE_LEFT_SHIFT 0x01
#define STATE_RIGHT_SHIFT 0x02
#define STATE_LEFT_CTRL 0x04
#define STATE_LEFT_ALT 0x08
#define STATE_RIGHT_ALT 0x10

#define KEY_ESCAPE 0x1B // keycode = 0x006e
#define KEY_MENUE 0x80 // keycode = 0x0070
#define KEY_BACK 0x81 // keycode = 0x0071
#define KEY_FORWARD 0x82 // keycode = 0x0072
#define KEY_ADDRESS 0x83 // keycode = 0x0073
#define KEY_WINDOW 0x84 // keycode = 0x0074
#define KEY_1ST_PAGE 0x85 // keycode = 0x0075
#define KEY_STOP 0x86 // keycode = 0x0076
#define KEY_MAIL 0x87 // keycode = 0x0077
#define KEY_FAVORITES 0x88 // keycode = 0x0078
#define KEY_NEW_PAGE 0x89 // keycode = 0x0079
#define KEY_SETUP 0x8A // keycode = 0x007a
#define KEY_FONT 0x8B // keycode = 0x007b
#define KEY_PRINT 0x8C // keycode = 0x007c
#define KEY_ON_OFF 0x8E // keycode = 0x007c

#define KEY_INSERT 0x90 // keycode = 0x004b
#define KEY_DELETE 0x91 // keycode = 0x004c
#define KEY_LEFT 0x92 // keycode = 0x004f
#define KEY_HOME 0x93 // keycode = 0x0050
#define KEY_END 0x94 // keycode = 0x0051
#define KEY_UP 0x95 // keycode = 0x0053
#define KEY_DOWN 0x96 // keycode = 0x0054
#define KEY_PAGE_UP 0x97 // keycode = 0x0055
#define KEY_PAGE_DOWN 0x98 // keycode = 0x0056
#define KEY_RIGHT 0x99 // keycode = 0x0059
#define KEY_MOUSE_1 0x9E // keycode = 0x0400
#define KEY_MOUSE_2 0x9F // keycode = 0x0800

static uint8_t
get_fdc_key (uint16_t cmd)
{
static uint8_t key_table[128] =
{
// 0 1 2 3 4 5 6 7 8 9 A B C D E F
0, '^', '1', '2', '3', '4', '5', '6', '7', '8', '9', '0', 'ß', '´', 0, '\b',
'\t','q', 'w', 'e', 'r', 't', 'z', 'u', 'i', 'o', 'p', 'ü', '+', 0, 0, 'a',
's', 'd', 'f', 'g', 'h', 'j', 'k', 'l', 'ö', 'ä', '#', '\r', 0, '<', 'y', 'x',
'c', 'v', 'b', 'n', 'm', ',', '.', '-', 0, 0, 0, 0, 0, ' ', 0, 0,

0, '°', '!', '"', '§', '$', '%', '&', '/', '(', ')', '=', '?', '`', 0, '\b',
'\t','Q', 'W', 'E', 'R', 'T', 'Z', 'U', 'I', 'O', 'P', 'Ü', '*', 0, 0, 'A',
'S', 'D', 'F', 'G', 'H', 'J', 'K', 'L', 'Ö', 'Ä', '\'','\r', 0, '>', 'Y', 'X',
'C', 'V', 'B', 'N', 'M', ';', ':', '_', 0, 0, 0, 0, 0, ' ', 0, 0
};
static uint8_t state;

uint8_t key = 0;

switch (cmd)
{
case 0x002C: state |= STATE_LEFT_SHIFT; break; // pressed left shift
case 0x00AC: state &= ~STATE_LEFT_SHIFT; break; // released left shift
case 0x0039: state |= STATE_RIGHT_SHIFT; break; // pressed right shift
case 0x00B9: state &= ~STATE_RIGHT_SHIFT; break; // released right shift
case 0x003A: state |= STATE_LEFT_CTRL; break; // pressed left ctrl
case 0x00BA: state &= ~STATE_LEFT_CTRL; break; // released left ctrl
case 0x003C: state |= STATE_LEFT_ALT; break; // pressed left alt
case 0x00BC: state &= ~STATE_LEFT_ALT; break; // released left alt
case 0x003E: state |= STATE_RIGHT_ALT; break; // pressed left alt
case 0x00BE: state &= ~STATE_RIGHT_ALT; break; // released left alt

case 0x006e: key = KEY_ESCAPE; break;
case 0x004b: key = KEY_INSERT; break;
case 0x004c: key = KEY_DELETE; break;
case 0x004f: key = KEY_LEFT; break;
case 0x0050: key = KEY_HOME; break;
case 0x0051: key = KEY_END; break;
case 0x0053: key = KEY_UP; break;
case 0x0054: key = KEY_DOWN; break;
case 0x0055: key = KEY_PAGE_UP; break;
case 0x0056: key = KEY_PAGE_DOWN; break;
case 0x0059: key = KEY_RIGHT; break;
case 0x0400: key = KEY_MOUSE_1; break;
case 0x0800: key = KEY_MOUSE_2; break;

default:
{
if (!(cmd & 0x80)) // pressed key
{
if (cmd >= 0x70 && cmd <= 0x7F) // function keys
{
key = cmd + 0x10; // 7x -> 8x
}
else if (cmd < 64) // key listed in key_table
{
if (state & (STATE_LEFT_ALT | STATE_RIGHT_ALT))
{
switch (cmd)
{
case 0x0003: key = '²'; break;
case 0x0008: key = '{'; break;
case 0x0009: key = '['; break;
case 0x000A: key = ']'; break;
case 0x000B: key = '}'; break;
case 0x000C: key = '\\'; break;
case 0x001C: key = '~'; break;
case 0x002D: key = '|'; break;
case 0x0034: key = 'µ'; break;
}
}
else if (state & (STATE_LEFT_CTRL))
{
if (key_table[cmd] >= 'a' && key_table[cmd] <= 'z')
{
key = key_table[cmd] - 'a' + 1;
}
else
{
key = key_table[cmd];
}
}
else
{
int idx = cmd + ((state & (STATE_LEFT_SHIFT | STATE_RIGHT_SHIFT)) ? 64 : 0);

if (key_table[idx])
{
key = key_table[idx];
}
}
}
}
break;
}
}

return (key);
}
</c>

Als letztes noch ein Beispiel einer Anwendung der Funktion get_fdc_key():

<c>
if (irmp_get_data (&irmp_data))
{
uint8_t key;

if (irmp_data.protocol == IRMP_FDC_PROTOCOL &&
(key = get_fdc_key (irmp_data.command)) != 0)
{
if ((key >= 0x20 && key < 0x7F) || key >= 0xA0) // show only printable characters
{
printf ("ascii-code = 0x%02x, character = '%c'\n", key, key);
}
else // it's a non-printable key
{
printf ("ascii-code = 0x%02x\n", key);
}
}
}
</c>

Alle nicht-druckbaren Zeichen werden dabei folgendermaßen codiert:

{| class="wikitable"
! Taste || Konstante || Wert
|-
| ESC || KEY_ESCAPE || 0x1B
|-
| Menü || KEY_MENUE || 0x80
|-
| Zurück || KEY_BACK || 0x81
|-
| Vorw. || KEY_FORWARD || 0x82
|-
| Adresse || KEY_ADDRESS || 0x83
|-
| Fenster || KEY_WINDOW || 0x84
|-
| 1. Seite || KEY_1ST_PAGE || 0x85
|-
| Stop || KEY_STOP || 0x86
|-
| Mail || KEY_MAIL || 0x87
|-
| Fav. || KEY_FAVORITES || 0x88
|-
| Neue Seite || KEY_NEW_PAGE || 0x89
|-
| Setup || KEY_SETUP || 0x8A
|-
| Schrift || KEY_FONT || 0x8B
|-
| Druck || KEY_PRINT || 0x8C
|-
| Ein/Aus || KEY_ON_OFF || 0x8E
|-
| Backspace || '\b' || 0x08
|-
| CR/ENTER || '\r' || 0x0C
|-
| TAB || '\t' || 0x09
|-
| Einfg || KEY_INSERT || 0x90
|-
| Entf || KEY_DELETE || 0x91
|-
| Cursor links || KEY_LEFT || 0x92
|-
| Pos1 || KEY_HOME || 0x93
|-
| Ende || KEY_END || 0x94
|-
| Cursor rechts || KEY_UP || 0x95
|-
| Cursor runter || KEY_DOWN || 0x96
|-
| Bild hoch || KEY_PAGE_UP || 0x97
|-
| Bild runter || KEY_PAGE_DOWN || 0x98
|-
| Cursor links || KEY_RIGHT || 0x99
|-
| Linke Maustaste || KEY_MOUSE_1 || 0x9E
|-
| Rechte Maustaste || KEY_MOUSE_2 || 0x9F
|-
|}

Die Funktion get_fdc_key berücksichtigt das Gedrückthalten der Shift-, Strg- und ALT-Tasten. Damit funktioniert nicht nur das Schreiben von Großbuchstaben, sondern auch das Auswählen der Sonderzeichen mit der Tastenkombination ALT + Taste, z.B. ALT + m = µ oder ALT + q = @. Ebenso kann man mit der Strg-Taste die Control-Zeichen CTRL-A bis CTRL-Z senden. Die CapsLock-Taste wird ignoriert, da ich sie sowieso für die überflüssigste Taste überhaupt halte ;-)

----

= IRSND - Infrarot-Multiprotokoll-Encoder =

[[Datei:irmp-title.png| |Scan eines NEC-kompatiblen Fernbedienungssignals]]

== Einleitung IRSND ==

[[Datei:ir-sender.png|miniatur|Anschluß eines einfachen IR-Senders an µC]]

IRSND ist das Gegenstück zu IRMP: es reproduziert aus den Daten, die mit IRMP empfangen wurden, wieder den Original Frame, der dann über eine Infrarot-Diode ausgegeben werden kann.

IRSND unterstützt die folgenden Protokolle:

* SIRCS
* NEC
* SAMSUNG
* SAMSUNG32
* MATSUSHITA
* RC5
* KASEIKYO
* DENON
* JVC
* APPLE
* NUBERT
* BANG_OLUFSEN
* GRUNDIG
* NOKIA
* SIEMENS (bei mind. ~15kHz)
* FDC (bei mind. ~15kHz)
* RCCAR (bei mind. ~15kHz)
* RECS80 (bei mind. ~20kHz)
* RECS80EXT (bei mind. ~20kHz)
* NIKON ('''NEU!''')
* RC6 ('''NEU!''')
* RC6A ('''NEU!''')

== Download IRSND ==

Version 1.9.0, Stand vom 18.01.2011

Download Release-Version: [http://www.mikrocontroller.net/wikifiles/c/c7/Irsnd.zip Irsnd.zip]

IRMP & IRSND sind nun auch über SVN abrufbar: [http://www.mikrocontroller.net/svnbrowser/irmp/ IRMP im SVN]

'''Achtung:'''

Die Version im SVN kann eine Zwischen- oder Test-Version sein, die nicht den hier dokumentierten Stand widerspiegelt! Im Zweifel verwendet man besser den obigen Download auf Irsnd.zip.

'''Die Software-Änderungen kann man sich hier anschauen: [http://www.mikrocontroller.net/articles/IRMP#Software-Historie_IRSND Software-Historie IRSND]'''

== Source-Code IRSND ==

Der Source-Code lässt sich einfach übersetzen, indem man die Projekt-Datei irsnd.aps in den WinAVR lädt. Aber auch für die Codevision Nutzer ist IRSND entsprechend angepasst: hier muss man die Zeile

<c>
//#define CODEVISION
</c>

in irsndmain.c aktivieren, das heisst, die Kommentarzeichen entfernen.

IRSND encodiert sämtliche oben aufgelisteten Protokolle in einer ISR, siehe irsnd.c. Welche Protokolle aktiv sein sollen, wird in irsndconfig.h eingestellt. Die Standardprotokolle sind bereits aktiv. Möchte man weitere Protokolle einschalten bzw. einige aus Speicherplatzgründen deaktivieren, sind die entsprechenden Werte in irsndconfig.h ...

<c>
// Protocol Enable Remarks F_INTERRUPTS Program Space
#define IRSND_SUPPORT_SIRCS_PROTOCOL 1 // Sony SIRCS >= 10000 uses ~150 bytes
#define IRSND_SUPPORT_NEC_PROTOCOL 1 // NEC + APPLE >= 10000 uses ~100 bytes
#define IRSND_SUPPORT_SAMSUNG_PROTOCOL 1 // Samsung + Samsung32 >= 10000 uses ~300 bytes
#define IRSND_SUPPORT_MATSUSHITA_PROTOCOL 1 // Matsushita >= 10000 uses ~200 bytes
#define IRSND_SUPPORT_KASEIKYO_PROTOCOL 1 // Kaseikyo >= 10000 uses ~150 bytes
#define IRSND_SUPPORT_RC5_PROTOCOL 1 // RC5 >= 10000 uses ~150 bytes
#define IRSND_SUPPORT_DENON_PROTOCOL 1 // DENON, Sharp >= 10000 uses ~200 bytes
#define IRSND_SUPPORT_JVC_PROTOCOL 1 // JVC >= 10000 uses ~150 bytes
#define IRSND_SUPPORT_RC6_PROTOCOL 1 // RC6 >= 10000 uses ~250 bytes
#define IRSND_SUPPORT_RC6A_PROTOCOL 1 // RC6A >= 10000 uses ~250 bytes
#define IRSND_SUPPORT_BANG_OLUFSEN_PROTOCOL 1 // Bang&Olufsen >= 10000 uses ~250 bytes
#define IRSND_SUPPORT_GRUNDIG_PROTOCOL 1 // Grundig >= 10000 uses ~300 bytes
#define IRSND_SUPPORT_NOKIA_PROTOCOL 1 // Nokia >= 10000 uses ~400 bytes
#define IRSND_SUPPORT_NUBERT_PROTOCOL 0 // NUBERT >= 10000 uses ~100 bytes
#define IRSND_SUPPORT_NIKON_PROTOCOL 0 // NIKON >= 10000 uses ~150 bytes
#define IRSND_SUPPORT_FDC_PROTOCOL 0 // FDC IR keyboard >= 10000 (better 15000) uses ~150 bytes
#define IRSND_SUPPORT_RCCAR_PROTOCOL 0 // RC CAR >= 10000 (better 15000) uses ~150 bytes
#define IRSND_SUPPORT_SIEMENS_PROTOCOL 0 // Siemens, Gigaset >= 15000 uses ~150 bytes
#define IRSND_SUPPORT_RECS80_PROTOCOL 0 // RECS80 >= 20000 uses ~100 bytes
#define IRSND_SUPPORT_RECS80EXT_PROTOCOL 0 // RECS80EXT >= 20000 uses ~100 bytes
</c>

auf 0 (deaktiviert) oder auf 1 (aktiviert) zu setzen. Die deaktivierten Protokolle werden dann nicht mitübersetzt.

Um das APPLE-Protokoll zu unterstützen, ist IRSND_SUPPORT_NEC_PROTOCOL auf 1 zu setzen, da es sich hier lediglich um einen Spezialfall vom NEC-Protokoll handelt.

Wenn man Speicherplatz sparen möchte, gelten natürlich hier dieselben Tipps wie für den IRMP.

IRSND baut den zu sendenden Frame "on-the-fly" aus der IRMP-Datenstruktur wieder zusammen. Dazu zählen:

1. ID für verwendetes Protokoll
2. Adresse bzw. Herstellercode
3. Kommando

Mittels der Funktion

irsnd_send_data (IRMP_DATA * irmp_data_p)

kann man ein zu encodierendes Telegramm versenden. Der Return-Wert ist 1, wenn das Telegramm versendet werden kann, sonst 0. Im ersten Fall werden die Struct-Members

<c>
irmp_data_p->protocol
irmp_data_p->address
irmp_data_p->command
irmp_data_p->flags
</c>

ausgelesen und dann als Frame im jeweils gewünschten Protokoll gesendet.

'''NEU ab Version 1.5.0:'''

irmp_data_p->flags gibt die Anzahl der Wiederholungen an, z.B.

irmp_data_p->flags = 0: Verhalten wie bisher
irmp_data_p->flags = 1: 1 Wiederholung
irmp_data_p->flags = 2: 2 Wiederholungen
usw.

'''Zu beachten: Da bisher irmp_data_p->flags von IRSND nicht ausgewertet wurde, ist unbedingt ab Version 1.5.0 darauf zu achten, dass irmp_data_p->flags vor dem Aufruf von irsnd_send_data() einen definierten Wert hat!'''

Hier ein Beispiel:

<c>
IRMP_DATA irmp_data;

irmp_data.protocol = IRMP_NEC_PROTOCOL; // sende im NEC-Protokoll
irmp_data.address = 0x00FF; // verwende Adresse 0x00FF
irmp_data.command = 0x0001; // sende Kommando 0001
irmp_data.flags = 0; // keine Wiederholung!

(void) irsnd_send_data (&irmp_data); // versende ohne Prüfung
</c>

Der Frame wird asynchron über die Interrupt-Routine irsnd_ISR() verschickt, so dass die Funktion irsnd_send_data() sofort zurückkommt.

Sind Wiederholungen angegeben, wird entweder der Frame nach einer Pause (protokollabhängig) neu ausgegeben oder ein protokollspezifischer Wiederholungsframe (z.B. für NEC) gesendet.

Wird erneut irsnd_send_data() aufgerufen, wartet diese, bis der vorhergenhende Frame vollständig verschickt wurde. Man kann aber auch selbst prüfen, ob IRSND gerade "busy" ist oder nicht:

<c>
while (irsnd_is_busy ())
{
; // selber warten oder was anderes tun...
}
(void) irsnd_send_data (&irmp_data); // versende ohne Prüfung

</c>

Im Beispiel-Source irsndmain.c findet man neben der Verwendung von irsnd_send_data() auch den Timer-Aufruf:

<c>
ISR(TIMER1_COMPA_vect)
{
irsnd_ISR()) // call irsnd ISR
// call other timer interrupt routines...
}
</c>

Möchte man IRMP und IRSND parallel verwenden (also als Sender und Empfänger) schreibt man die ISR folgendermaßen:

<c>
ISR(TIMER1_COMPA_vect)
{
if (! irsnd_ISR()) // call irsnd ISR
{ // if not busy...
irmp_ISR(); // call irmp ISR
}
// call other timer interrupt routines...
}
</c>

Das heisst: Nur wenn irsnd_ISR() nichts zu tun hat, dann rufe die ISR des Empfängers auf. Damit ist der Empfänger solange abgeschaltet, während irsnd_ISR() noch Daten sendet. Die Timer-Initialisierungsroutine ist für IRMP und IRSND dann natürlich dieselbe.

Eine gemeinsame main-Funktion könnte dann zum Beispiel folgendermaßen aussehen:

<c>
int
main (void)
{
IRMP_DATA irmp_data;

irmp_init(); // initialize irmp
irsnd_init(); // initialize irsnd
timer_init(); // initialize timer
sei (); // enable interrupts

for (;;)
{
if (irmp_get_data (&irmp_data))
{
irmp_data.flags = 0; // reset flags!
irsnd_send_data (&irmp_data);
}
}
}
</c>

Die Funktion des obigen Sources ist offensichtlich: Ein empfangenes Telegramm wird nach vollständiger Decodierung wieder encodiert und dann wieder über die IR-Diode ausgesandt. Somit können dann zum Beispiel Signale "um die Ecke" oder streckenweise drahtgebunden übertragen werden.

Desweiteren könnte man auch Protokolle transformieren, zum Beispiel NEC-Telegramme in RC5 umwandeln, wenn man seine Original-RC5-FB zu seinem Philips-Gerät verlegt hat...

Der Rest bleibt der Phantasie des geneigten Lesers überlassen ;-)

Hier noch die möglichen Werte für irmp_data.protocol, siehe auch irmp.h:

<c>
#define IRMP_SIRCS_PROTOCOL 1 // Sony
#define IRMP_NEC_PROTOCOL 2 // NEC, Pioneer, JVC, Toshiba, NoName etc.
#define IRMP_SAMSUNG_PROTOCOL 3 // Samsung
#define IRMP_MATSUSHITA_PROTOCOL 4 // Matsushita
#define IRMP_KASEIKYO_PROTOCOL 5 // Kaseikyo (Panasonic etc)
#define IRMP_RECS80_PROTOCOL 6 // Philips, Thomson, Nordmende, Telefunken, Saba
#define IRMP_RC5_PROTOCOL 7 // Philips etc
#define IRMP_DENON_PROTOCOL 8 // Denon, Sharp
#define IRMP_RC6_PROTOCOL 9 // Philips etc
#define IRMP_SAMSUNG32_PROTOCOL 10 // Samsung32: no sync pulse at bit 16, length 32 instead of 37
#define IRMP_APPLE_PROTOCOL 11 // Apple, very similar to NEC
#define IRMP_RECS80EXT_PROTOCOL 12 // Philips, Technisat, Thomson, Nordmende, Telefunken, Saba
#define IRMP_NUBERT_PROTOCOL 13 // Nubert
#define IRMP_BANG_OLUFSEN_PROTOCOL 14 // Bang & Olufsen
#define IRMP_GRUNDIG_PROTOCOL 15 // Grundig
#define IRMP_NOKIA_PROTOCOL 16 // Nokia
#define IRMP_SIEMENS_PROTOCOL 17 // Siemens, e.g. Gigaset
#define IRMP_FDC_PROTOCOL 18 // FDC keyboard
#define IRMP_RCCAR_PROTOCOL 19 // RC Car
#define IRMP_JVC_PROTOCOL 20 // JVC
#define IRMP_RC6A_PROTOCOL 21 // RC6A, e.g. Kathrein, XBOX
#define IRMP_NIKON_PROTOCOL 22 // Nikon
</c>

Die Daten für die Adresse und das Kommando ermittelt man am besten über IRMP, siehe weiter oben ;-)

== Modulation ==

IRSND moduliert das Signal mit der Trägerfrequenz des jeweiligen IR-Protokolls über PWM, siehe auch Tabelle [http://www.mikrocontroller.net/articles/IRMP#Protokolle]. Dazu benutzt IRSND den Timer2 des ATMEGAs. Beim ATMEGA 48/88/168/328 liegt das OC2A-Signal am PB3, siehe Datenblatt.

Das muss bei anderen ATMEGAs eventuell angepasst werden. Dazu dienen die Zeilen

<c>
#define IRSND_PORT PORTB // port B
#define IRSND_DDR DDRB // ddr B
#define IRSND_BIT 3 // OC2A
</c>

in irsnd.c.

== IRSND unter Linux und Windows ==

irsnd.c lässt sich auch unter Linux direkt kompilieren, um damit Telegramme in Form von IRMP-Scan-Dateien zu erzeugen. Das geht folgendermaßen:

cc irsnd.c -o irsnd # IRSND compilieren

Der Aufruf geht dann folgendermaßen:

./irsnd protocol-number hex-address hex-command [repeat] > filename.txt

also zum Beispiel für das NEC-Protokoll, Adresse 0x00FF, Kommando 0x0001

./irsnd 2 00FF 0001 > nec.txt # irsnd ausführen

IRSND kann man auch unter Windows nutzen, nämlich folgendermaßen:

* Eingabeaufforderung starten
* In das Verzeichnis von irsnd wechseln
* Aufruf von:

irsnd.exe 2 00FF 0001 > nec.txt

Nun kann man direkt mit IRMP anschließend testen, ob das erzeugte Telegramm auch korrekt ist:

./irmp < nec.txt

bzw. unter Windows:

irmp.exe < nec.txt

Das Ganze geht auch ohne Zwischendatei, nämlich:

./irsnd 2 00FF 0001 | ./irmp

bzw. unter Windows:

irsnd.exe 2 00FF 0001 | irmp.exe

IRMP gibt dann als Ergebnis folgendes aus:

11111111000000001000000001111111 p = 2, a = 0x00ff, c = 0x0001, f = 0x00

IRMP konnte also aus dem von IRSND generierten Frame wieder das Protokoll 2, Adresse 0x00FF und Kommando 0x0001 decodieren.

Bitte beachten: Je nach benutztem Protokoll sind die Bit-Breiten der Adressen bzw. Kommandos verschieden, siehe obige Tabelle [http://www.mikrocontroller.net/articles/IRMP#Protokolle].

Man kann also nicht mit jedem IR-Protokoll komplett 16-Bit breite Adressen oder Kommandos transparent übertragen.

----

= Anhang =

== Die IR-Protokolle im Detail ==

=== Pulse-Distance Protokolle ===

{| class="wikitable"
! '''SIRCS''' || Wert
|-
| Frequenz || 40 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 12-20 Daten-Bits, kein Stop-Bit
|-
| Daten || 7 Kommando-Bits + 5 Adress-Bits + bis zu 8 zusätzliche Bits
|-
| Start-Bit || 2400µs Puls, 600µs Pause
|-
| 0-Bit || 600µs Puls, 600µs Pause
|-
| 1-Bit || 1200µs Puls, 600µs Pause
|-
| Wiederholung || zweimalig nach ca. 25ms, d.h. 2. und 3. Frame
|-
| Tasten-Wiederholung || ab dem 4. identischen Frame, Abstand ca. 25ms
|-
| Bit-Order || LSB first
|-
! '''NEC + extended NEC''' || Wert
|-
| Frequenz || 36 kHz / 38 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 32 Daten-Bits + 1 Stop-Bit
|-
| Daten NEC || 8 Adress-Bits + 8 invertierte Adress-Bits + 8 Kommando-Bits + 8 invertierte Kommando-Bits
|-
| Daten ext. NEC || 16 Adress-Bits + 8 Kommando-Bits + 8 invertierte Kommando-Bits
|-
| Start-Bit || 9000µs Puls, 4500µs Pause
|-
| 0-Bit || 560µs Puls, 560µs Pause
|-
| 1-Bit || 560µs Puls, 1690µs Pause
|-
| Stop-Bit || 560µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || 9000µs Puls, 2250µs Pause, 560µs Puls, ~100ms Pause
|-
| Bit-Order || LSB first
|-
! '''JVC''' || Wert
|-
| Frequenz || 38 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 16 Daten-Bits + 1 Stop-Bit
|-
| Daten || 4 Adress-Bits + 12 Kommando-Bits
|-
| Start-Bit || 9000µs Puls, 4500µs Pause, 6000µs Pause bei Tasten-Wiederholung
|-
| 0-Bit || 560µs Puls, 560µs Pause
|-
| 1-Bit || 560µs Puls, 1690µs Pause
|-
| Stop-Bit || 560µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || Wiederholung nach Pause von 25ms
|-
| Bit-Order || LSB first
|-
! '''NEC16''' || Wert
|-
| Frequenz || 38 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 8 Adress-Bits + 1 Sync-Bit + 8 Daten-Bits + 1 Stop-Bit
|-
| Start-Bit || 9000µs Puls, 4500µs Pause
|-
| Sync-Bit || 560µs Puls, 4500µs Pause
|-
| 0-Bit || 560µs Puls, 560µs Pause
|-
| 1-Bit || 560µs Puls, 1690µs Pause
|-
| Stop-Bit || 560µs Puls
|-
| Wiederholung || keine/eine/zwei nach 25ms?
|-
| Tasten-Wiederholung || Wiederholung nach Pause von 25ms?
|-
| Bit-Order || LSB first
|-
! '''NEC42''' || Wert
|-
| Frequenz || 38 kHz?
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 42 Daten-Bits + 1 Stop-Bit
|-
| Daten || 13 Adress-Bits + 13 invertierte Adress-Bits + 8 Kommando-Bits + 8 invertierte Kommando-Bits
|-
| Start-Bit || 9000µs Puls, 4500µs Pause
|-
| 0-Bit || 560µs Puls, 560µs Pause
|-
| 1-Bit || 560µs Puls, 1690µs Pause
|-
| Stop-Bit || 560µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || (unbekannt)
|-
| Bit-Order || LSB first
|-
! '''SAMSUNG''' || Wert
|-
| Frequenz || ?? kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 16 Daten(1)-Bits + 1 Sync-Bit + 20 Daten(2)-Bits + 1 Stop-Bit
|-
| Daten(1) || 16 Adress-Bits
|-
| Daten(2) || 4 ID-Bits + 8 Kommando-Bits + 8 invertierte Kommando-Bits
|-
| Start-Bit || 4500µs Puls, 4500µs Pause
|-
| 0-Bit || 550µs Puls, 450µs Pause
|-
| 1-Bit || 550µs Puls, 1450µs Pause
|-
| Sync-Bit || 550µs Puls, 4500µs Pause
|-
| Stop-Bit || 550µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || N-fache Wiederholung des Original-Frames innerhalb von 100ms
|-
| Bit-Order || LSB first
|-
! '''SAMSUNG32''' || Wert
|-
| Frequenz || ?? kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 32 Daten-Bits + 1 Stop-Bit
|-
| Daten || 16 Adress-Bits + 16 Kommando-Bits
|-
| Start-Bit || 4500µs Puls, 4500µs Pause
|-
| 0-Bit || 550µs Puls, 450µs Pause
|-
| 1-Bit || 550µs Puls, 1450µs Pause
|-
| Stop-Bit || 550µs Puls
|-
| Wiederholung || einmalig nach 45ms
|-
| Tasten-Wiederholung || dritter, fünfter, siebter usw. identischer Frame
|-
| Bit-Order || LSB first
|-
! '''MATSUSHITA''' || Wert
|-
| Frequenz || 36 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 24 Daten-Bits + 1 Stop-Bit
|-
| Daten || 6 Hersteller-Bits + 6 Kommando-Bits + 12 Adress-Bits
|-
| Start-Bit || 3488µs Puls, 3488µs Pause
|-
| 0-Bit || 872µs Puls, 872µs Pause
|-
| 1-Bit || 872µs Puls, 2616µs Pause
|-
| Stop-Bit || 872µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || N-fache Wiederholung des Original-Frames innerhalb von 100ms
|-
| Bit-Order || LSB first?
|-
! '''KASEIKYO''' || Wert
|-
| Frequenz || 38 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 48 Daten-Bits + 1 Stop-Bit
|-
| Daten || 16 Hersteller-Bits + 4 Parity-Bits + 4 Genre1-Bits + 4 Genre2-Bits + 10 Kommando-Bits + 2 ID-Bits + 8 Parity-Bits
|-
| Start-Bit || 3380µs Puls, 1690µs Pause
|-
| 0-Bit || 423µs Puls, 423µs Pause
|-
| 1-Bit || 423µs Puls, 1269µs Pause
|-
| Stop-Bit || 423µs Puls
|-
| Wiederholung || einmalig nach 74ms
|-
| Tasten-Wiederholung || N-fache Wiederholung des Original-Frames innerhalb von 74ms
|-
| Bit-Order || LSB first?
|-
! '''RECS80''' || Wert
|-
| Frequenz || 38 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bits + 10 Daten-Bits + 1 Stop-Bit
|-
| Daten || 1 Toggle-Bit + 3 Adress-Bits + 6 Kommando-Bits
|-
| Start-Bit || 158µs Puls, 7432µs Pause
|-
| 0-Bit || 158µs Puls, 4902µs Pause
|-
| 1-Bit || 158µs Puls, 7432µs Pause
|-
| Stop-Bit || 158µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || N-fache Wiederholung des Original-Frames innerhalb von 100ms
|-
| Bit-Order || MSB first
|-
! '''RECS80EXT''' || Wert
|-
| Frequenz || 38 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 2 Start-Bits + 11 Daten-Bits + 1 Stop-Bit
|-
| Daten || 1 Toggle-Bit + 4 Adress-Bits + 6 Kommando-Bits
|-
| Start-Bit || 158µs Puls, 3637µs Pause
|-
| 0-Bit || 158µs Puls, 4902µs Pause
|-
| 1-Bit || 158µs Puls, 7432µs Pause
|-
| Stop-Bit || 158µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || N-fache Wiederholung des Original-Frames innerhalb von 100ms
|-
| Bit-Order || MSB first
|-
! '''DENON''' || Wert
|-
| Frequenz || 38 kHz (in der Praxis, lt. Dokumentation: 32 kHz)
|-
| Kodierung || Pulse Distance
|-
| Frame || 0 Start-Bits + 15 Data-Bits + 1 Stop-Bit + 65ms Pause + 15 invertierte Daten-Bits + 1 Stop-bit
|-
| Daten || 5 Address-Bits + 10 Kommando-Bits
|-
| Start-Bit || kein Start-Bit
|-
| 0-Bit || 310µs Puls, 745µs Pause (in der Praxis, lt. Doku: 275µs Puls, 775µs Pause)
|-
| 1-Bit || 310µs Puls, 1780µs Pause (in der Praxis, lt. Doku: 275µs Puls, 1900µs Pause)
|-
| Stop-Bit || 310µs Puls (310µs Puls, 745µs Pause (in der Praxis, lt. Doku: 275µs Puls)
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || N-fache Wiederholung des Original-Frames innerhalb von 100ms
|-
| Bit-Order || MSB first
|-
! '''APPLE''' || Wert
|-
| Frequenz || 38 kHz?
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 32 Daten-Bits + 1 Stop-Bit
|-
| Daten || 16 Adress-Bits + 11100000 + 8 Kommando-Bits
|-
| Start-Bit || siehe NEC
|-
| 0-Bit || siehe NEC
|-
| 1-Bit || siehe NEC
|-
| Stop-Bit || siehe NEC
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || N-fache Wiederholung des Original-Frames innerhalb von 100ms
|-
| Bit-Order || LSB first
|-
! '''NUBERT''' || Wert
|-
| Frequenz || 36 kHz?
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 10 Daten-Bits + 1 Stop-Bit
|-
| Daten || 0 Adress-Bits + 10 Kommando-Bits ?
|-
| Start-Bit || 1340µs Puls, 340µs Pause
|-
| 0-Bit || 500µs Puls, 1300µs Pause
|-
| 1-Bit || 1340µs Puls, 340µs Pause
|-
| Stop-Bit || 500µs Puls
|-
| Wiederholung || einmalig nach 35ms
|-
| Tasten-Wiederholung || dritter, fünfter, siebter usw. identischer Frame
|-
| Bit-Order || MSB first?
|-
! '''B&O''' || Wert
|-
| Frequenz || 455 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 4 Start-Bits + 16 Daten-Bits + 1 Trailer-Bit + 1 Stop-Bit
|-
| Daten || 0 Adress-Bits + 16 Kommando-Bits
|-
| Start-Bit 1 || 200µs Puls, 2925µs Pause
|-
| Start-Bit 2 || 200µs Puls, 2925µs Pause
|-
| Start-Bit 3 || 200µs Puls, 15425µs Pause
|-
| Start-Bit 4 || 200µs Puls, 2925µs Pause
|-
| 0-Bit || 200µs Puls, 2925µs Pause
|-
| 1-Bit || 200µs Puls, 9175µs Pause
|-
| R-Bit || 200µs Puls, 6050µs Pause, wiederholt das letzte Bit (repetition)
|-
| Trailer-Bit || 200µs Puls, 12300µs Pause
|-
| Stop-Bit || 200µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || N-fache Wiederholung des Original-Frames innerhalb von 100ms
|-
| Bit-Order || MSB first
|-
! '''FDC''' || Wert
|-
| Frequenz || 38 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 40 Daten-Bits + 1 Stop-Bit
|-
| Daten || 8 Adress-Bits + 12 x 0-Bits + 4 Press/Release-Bits + 8 Kommando-Bits + 8 invertierte Kommando-Bits
|-
| Start-Bit || 2085µs Puls, 966µs Pause
|-
| 0-Bit || 300µs Puls, 220µs Pause
|-
| 1-Bit || 300µs Puls, 715µs Pause
|-
| Stop-Bit || 300µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Drücken || Press/Release-Bits = 0000
|-
| Tasten-Loslassen || Press/Release-Bits = 1111
|-
| Tasten-Wiederholung || Wiederholung nach Pause von 60ms
|-
| Bit-Order || LSB first
|-
! '''RCCAR''' || Wert
|-
| Frequenz || 38 kHz?
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 13 Daten-Bits + 1 Stop-Bit
|-
| Daten || C0 C1 A0 A1 D0 D1 D2 D3 D4 D5 D6 D7 V
|-
| Start-Bit || 2000µs Puls, 2000µs Pause
|-
| 0-Bit || 600µs Puls, 900µs Pause
|-
| 1-Bit || 600µs Puls, 450µs Pause
|-
| Stop-Bit || 600µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || keine?
|-
| Bit-Order || LSB first
|-
|}

=== Bi-Phase Protokolle ===

{| class="wikitable"
! '''RC5 + RC5X''' || Wert
|-
| Frequenz || 36 kHz
|-
| Kodierung || Bi-Phase (Manchester)
|-
| Frame RC5 || 2 Start-Bits + 12 Daten-Bits + 0 Stop-Bits
|-
| Daten RC5 || 1 Toggle-Bit + 5 Adress-Bits + 6 Kommando-Bits
|-
| Frame RC5X || 1 Start-Bit + 13 Daten-Bits + 0 Stop-Bit
|-
| Daten RC5X || 1 invertiertes Kommando-Bit + 1 Toggle-Bit + 5 Adress-Bits + 6 Kommando-Bits
|-
| Start-Bit || 889µs Pause, 889µs Puls
|-
| 0-Bit || 889µs Puls, 889µs Pause
|-
| 1-Bit || 889µs Pause, 889µs Puls
|-
| Stop-Bit || kein Stop-Bit
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || N-fache Wiederholung des Original-Frames innerhalb von 100ms
|-
| Bit-Order || MSB first
|-
! '''RC6''' + '''RC6A''' || Wert
|-
| Frequenz || 36 kHz
|-
| Kodierung || Bi-Phase (Manchester)
|-
| Frame RC6 || 1 Start-Bit + 1 Bit "1" + 3 Mode-Bits (000) + 1 Toggle-Bit + 16 Daten-Bits + 2666µs pause
|-
| Frame RC6A || 1 Start-Bit + 1 Bit "1" + 3 Mode-Bits (110) + 1 Toggle-Bit + 31 Daten-Bits + 2666µs pause
|-
| Daten RC6 || 8 Adress-Bits + 8 Kommando Bits
|-
| Daten RC6A || "1" + 14 Hersteller-Bits + 8 System-Bits + 8 Kommando-Bits
|-
| Start-Bit || 2666µs Puls, 889µs Pause
|-
| Toggle 0-Bit || 889µs Pause, 889µs Puls
|-
| Toggle 1-Bit || 889µs Puls, 889µs Pause
|-
| 0-Bit || 444µs Pause, 444µs Puls
|-
| 1-Bit || 444µs Puls, 444µs Pause
|-
| Stop-Bit || kein Stop-Bit
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || N-fache Wiederholung des Original-Frames innerhalb von 100ms
|-
| Bit-Order || MSB first
|-
! '''GRUNDIG + NOKIA''' || Wert
|-
| Frequenz || 38 kHz (?)
|-
| Kodierung || Bi-Phase (Manchester)
|-
| Frame-Paket || 1 Start-Frame + 19,968ms Pause + N Info-Frames + 117,76ms Pause + 1 Stop-Frame
|-
| Start-Frame || 1 Pre-Bit + 1 Start-Bit + 9 Daten-Bits (alle 1) + 0 Stop-Bits
|-
| Info-Frame || 1 Pre-Bit + 1 Start-Bit + 9 Daten-Bits + 0 Stop-Bits
|-
| Stop-Frame || 1 Pre-Bit + 1 Start-Bit + 9 Daten-Bits (alle 1) + 0 Stop-Bits
|-
| Daten Grundig || 9 Kommando-Bits
|-
| Daten Nokia || 8 Kommando-Bits + 8 Address-Bits
|-
| Pre-Bit || 528µs Puls, 2639µs Pause
|-
| Start-Bit || 528µs Puls, 528µs Pause
|-
| 0-Bit || 528µs Pause, 528µs Puls
|-
| 1-Bit || 528µs Puls, 528µs Pause
|-
| Stop-Bit || kein Stop-Bit
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || N-fache Wiederholung des Info-Frames mit einem Pausenabstand von 117,76ms
|-
| Bit-Order || LSB first
|-
! '''SIEMENS + RUWIDO''' || Wert
|-
| Frequenz || 36 kHz?
|-
| Kodierung || Bi-Phase (Manchester)
|-
| Frame Siemens || 1 Start-Bit + 22 Daten-Bits + 0 Stop-Bits
|-
| Frame Ruwido || 1 Start-Bit + 17 Daten-Bits + 0 Stop-Bits
|-
| Daten Siemens || 11 Adress-Bits + 10 Daten-Bits + 1 invertiertes Bit (letztes Bit davor nochmal invertiert)
|-
| Daten Ruwido || 9 Adress-Bits + 7 Daten-Bits + 1 invertiertes Bit (letztes Bit davor nochmal invertiert)
|-
| Start-Bit || 275µs Puls, 275µs Pause
|-
| 0-Bit || 275µs Pause, 275µs Puls
|-
| 1-Bit || 275µs Puls, 275µs Pause
|-
| Stop-Bit || kein Stop-Bit
|-
| Wiederholung || 1-malige Wiederholung mit gesetztem Repeat-Bit (?)
|-
| Tasten-Wiederholung || N-fache Wiederholung des Original-Frames innerhalb von 100ms (?)
|-
| Bit-Order || MSB first
|-
|}

=== Serial Protokolle ===

{| class="wikitable"
! '''NETBOX''' || Wert
|-
| Frequenz || 38 kHz?
|-
| Kodierung || Serial
|-
| Frame || 1 Start-Bit + 16 Daten-Bits, kein Stop-Bit
|-
| Daten || 3 Adress-Bits + 13 Kommando-Bits
|-
| Start-Bit || 2400µs Puls, 800µs Pause
|-
| Bitlänge || 800µs
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || Abstand ca. 35ms?
|-
| Bit-Order || LSB first
|-
|}

== Software-Historie IRMP ==

Änderungen IRMP:

* 18.01.2011: Korrekturen für Siemens-Protokoll
* 18.01.2011: '''Neues Protokoll''': NIKON
* 18.01.2011: Speichern der zusätzlichen Bits (>12) im SIRCS-Protokoll in der Adresse
* 18.01.2011: Timing-Korrekturen für Denon-Protokoll

* 04.09.2010: Bugfix für F_INTERRUPTS >= 16000

* 02.09.2010: '''Neues Protokoll''': RC6A

* 29.08.2010: '''Neues Protokoll''': JVC
* 29.08.2010: Kaseikyo-Protokoll: Berücksichtigung der Genre-Bits. '''ACHTUNG: dadurch neue Command-Codes!'''
* 29.08.2010: Kaseikyo-Protokoll: Verbesserte Behandlung von Wiederholungs-Frames
* 29.08.2010: Verbesserte Unterstützung des APPLE-Protokolls. '''ACHTUNG: dadurch neue Adress-Codes!'''

* 01.07.2010: Bugfix: Einführen eines Timeouts für NEC-Repetition-Frames, um "Geisterkommandos" zu verhindern.

* 26.06.2010: Bugfix: Deaktivieren von RECS80, RECS80EXT & SIEMENS bei geringer Interrupt-Rate

* 25.06.2010: '''Neues Protokoll''': RCCAR
* 25.06.2010: Tastenerkennung für FDC-Protokoll (IR-keyboard) erweitert
* 25.06.2010: Interrupt-Frequenz nun bis zu 20kHz möglich

* 09.06.2010: '''Neues Protokoll''': FDC (IR-keyboard)
* 09.06.2010: Timing für DENON-Protokoll korrigiert

* 02.06.2010: '''Neues Protokoll''': Siemens (Gigaset)

* 26.05.2010: '''Neues Protokoll''': Nokia
* 26.05.2010: Bugfix Auswertung von langen Tastendrücken bei Grundig-Protokoll

* 17.05.2010: Bugfix SAMSUNG32-Protokoll: Kommando-Bit-Maske korrigiert

* 16.05.2010: '''Neues Protokoll''': Grundig
* 16.05.2010: Behandlung von automatischen Frame-Wiederholungen beim SIRCS-, SAMSUNG32- und NUBERT-Protokoll verbessert.

* 28.04.2010: Nur einige kosmetische Code-Optimierungen

* 16.04.2010: Sämtliche Timing-Toleranzen angepasst/optimiert

* 12.04.2010: '''Neues Protokoll''': Bang & Olufsen

* 29.03.2010: Bugfix beim Erkennen von mehrfachen NEC-Repetition-Frames
* 29.03.2010: Konfiguration in irmpconfig.h ausgelagert
* 29.03.2010: Einführung einer Programmversion in README.txt: Version 1.0

* 17.03.2010: '''Neues Protokoll''': Nubert

* 16.03.2010: Korrektur der RECS80-Startbit-Timings
* 16.03.2010: '''Neues Protokoll''': RECS80 Extended

* 15.03.2010: Codeoptimierung

* 14.03.2010: Portierung auf PIC

* 11.03.2010: Anpassungen an verschiedene ATMega-Typen durchgeführt

* 07.03.2010: Bugfix: Zurücksetzen der Statemachine nach einem unvollständigen RC5-Frame

* 05.03.2010: '''Neues Protokoll''': Apple
* 05.03.2010: Die Daten irmp_data.addr + irmp_data.command werden nun in der jeweiligen Bit-Order des verwendeten Protokolls gespeichert

* 04.03.2010: '''Neues Protokoll''': SAMSUNG32 (Mix aus SAMSUNG & NEC-Protokoll)
* 04.03.2010: Änderung der SIRCS- und Kaseikyo-Toleranzen

* 02.03.2010: SIRCS: Korrekte Erkennung und Unterdrückung von automatischen Frame-Wiederholungen
* 02.03.2010: SIRCS: Device-ID-Bits werden nun in irmp_data.command und nicht mehr in irmp_data.address gespeichert
* 02.03.2010: Vergrößerung des Scan Buffers (zwecks Protokollierung)

* 24.02.2010: Neue Variable flags in IRMP_DATA zur Erkennung von langen Tastendrücken

* 20.02.2010: Bugfix Denon-Protokoll: Wiederholungsframe grundsätzlich invertiert

* 19.02.2010: Erkennung von NEC-Protokoll-Varianten, z. B. Apple-Fernbedienung
* 19.02.2010: Erkennung von RC6- und Denon-Protokoll
* 19.02.2010: Verbesserung des RC5-Decoders (Bugfixes)

* 13.02.2010: Bugfix: Puls/Pausen-Counter um 1 zu niedrig, nun bessere Erkennung bei Protokollen mit sehr kurzen Pulszeiten
* 13.02.2010: Erkennung der NEC-Wiederholungssequenz

* 12.02.2010: RC5-Protokoll-Decoder hinzugefügt

* 05.02.2010: Konflikt zwischen Samsung- und Matsushita-Protokoll beseitigt

== Software-Historie IRSND ==

Änderungen:

* 18.01.2011: '''Neues Protokoll''': RC6A
* 18.01.2011: '''Neues Protokoll''': RC6
* 18.01.2011: '''Neues Protokoll''': NIKON
* 18.01.2011: Beachten der zusätzlichen Bits (>12) im SIRCS-Protokoll
* 18.01.2011: Korrektur der Pausenlängen
* 18.01.2011: Timing-Korrekturen für Denon-Protokoll

* 02.09.2010: Neues Protokoll: JVC
* 02.09.2010: Anpassung des APPLE-Encoders an IRMP-Version 1.7.3.

* 29.08.2010: Neues Protokoll: Kaseikyo (Panasonic u.a.)

* 01.07.2010: Bugfix: Deaktivieren von RECS80, RECS80EXT & SIEMENS bei geringer Interrupt-Rate

* 25.06.2010: Neues Protokoll: RCCAR

* 09.06.2010: Neues Protokoll: FDC (IR-keyboard)
* 09.06.2010: Timing für DENON-Protokoll korrigiert

* 02.06.2010: Neues Protokoll: Siemens (Gigaset)
* 02.06.2010: Simulation von langen Tastendrücken

* 26.05.2010: Neues Protokoll: Nokia

* 17.05.2010: Neues Protokoll: Grundig
* 17.05.2010: Behandlung von Frame-Wiederholungen für SIRCS, SAMSUNG32 und NUBERT korrigiert

* 28.04.2010: Unterstützung des APPLE-Protokolls
* 28.04.2010: Konfiguration über irmpconfig.h

* 16.04.2010: Sämtliche Timing-Toleranzen angepasst/optimiert

* 14.04.2010: Neues Protokoll: Bang & Olufsen

* 17.03.2010: Neues Protokoll: Nubert
* 17.03.2010: Korrektur der Pausen zwischen Frame-Wiederholungen

* 16.03.2010: Korrektur des Timer-Registers TCCR2
* 16.03.2010: Korrektur der RECS80-Startbit-Timings
* 16.03.2010: Neues Protokoll: RECS80 Extended

* 11.03.2010: Anpassungen an verschiedene ATMega-Typen durchgeführt

* 07.03.2010: Alpha-Version

== Literatur ==

''' IR-Übersicht ''':

* http://www.epanorama.net/links/irremote.html
* http://www.elektor.de/jahrgang/2008/juni/cc2-avr-projekt-%283%29-unsichtbare-kommandos.497184.lynkx?tab=4 (IR Übersicht & RC5)

'''SIRCS-Protokoll''':

* http://www.sbprojects.com/knowledge/ir/sirc.htm
* http://www.ustr.net/infrared/sony.shtml
* http://users.telenet.be/davshomepage/sony.htm
* http://picprojects.org.uk/projects/sirc/

'''NEC-Protokoll:'''

* http://www.sbprojects.com/knowledge/ir/nec.htm
* http://www.ustr.net/infrared/nec.shtml
* http://www.celadon.com/infrared_protocol/infrared_protocols_samples.pdf

'''NEC16-Protokoll (JVC):'''

* http://www.ustr.net/infrared/jvc.shtml

'''SAMSUNG-Protokoll:'''

(wurde aus diversen Protokollen (Daewoo u.ä.) zusammengereimt, daher kein direkter Link auf irgendwelche SAMSUNG-Dokumentation verfügbar)

Hier ein Link zum Daewoo-Protokoll, welches dasselbe Prinzip des Sync-Bits in der Mitte eines Frames nutzt, jedoch mit anderen Timing-Werten arbeitet:

* http://users.telenet.be/davshomepage/daewoo.htm

'''MATSUHITA-Protokoll:'''

* http://www.celadon.com/infrared_protocol/infrared_protocols_samples.pdf

'''KASEIKYO-Protokoll (auch "Japan-Protokoll"):'''

* http://www.mikrocontroller.net/attachment/4246/IR-Protokolle_Diplomarbeit.pdf
* http://www.roboternetz.de/phpBB2/files/entwicklung_und_realisierung_einer_universalinfrarotfernbedienung_mit_timerfunktionen.pdf

'''RECS80- und RECS80-Extended-Protokoll:'''

* http://www.sbprojects.com/knowledge/ir/recs80.htm

'''RC5- und RC5x-Protokoll:'''

* http://www.sbprojects.com/knowledge/ir/rc5.htm
* http://users.telenet.be/davshomepage/rc5.htm

'''Denon-Protokoll:'''

* http://www.mikrocontroller.com/de/IR-Protokolle.php#DENON

'''RC6 und RC6A-Protokoll:'''

* http://www.sbprojects.com/knowledge/ir/rc6.htm
* http://slycontrol.ru/scr/kb/rc6.htm
* http://www.picbasic.nl/info_rc6_uk.htm

'''Bang & Olufsen:'''

* http://www.mikrocontroller.net/attachment/33137/datalink.pdf

'''Grundig'''

* http://www.mikrocontroller.net/attachment/77507/Grundig_10bit.pdf

'''Nokia'''

* http://www.sbprojects.com/knowledge/ir/nrc17.htm

'''Diverse Protokolle:'''

* http://www.mikrocontroller.net/attachment/4246/IR-Protokolle_Diplomarbeit.pdf
* http://www.celadon.com/infrared_protocol/infrared_protocols_samples.pdf
* http://www.opendcc.de/info/rc5/rc5.html
* http://www.roboternetz.de/phpBB2/files/entwicklung_und_realisierung_einer_universalinfrarotfernbedienung_mit_timerfunktionen.pdf

== Hardware / IRMP-Projekte ==

Eine Implementierung auf Basis IRMP und IRSND als Multiprotokoll Dekoder mit LCD
von Klaus Leidinger:
* http://www.mikrocontroller-projekte.de/Mikrocontroller/index.html

Ähnliche Implementierung wie von Klaus Leidinger für Pollin AVR-NET-IO mit Pollin ADD-ON Board:
* http://son.ffdf-clan.de/include.php?path=forumsthread&threadid=703

USB IR Remote Receiver von Hugo Portisch:
* http://www.mikrocontroller.net/articles/USB_IR_Remote_Receiver

Servo-gesteuerter IR Sender mit Anlernfunktion von Stefan Pendsa:
* http://forum.mikrokopter.de/topic-21060.html
* (SVN) http://svn.mikrokopter.de/listing.php?repname=Projects&path=%2FServo-Controlled+IR-Transmitter%2F&#Ad2417800d6aa14bf08c571a896e9def7

Lernfähige IR-Fernbedienung von Robert und Frank M.
* http://www.mikrocontroller.net/articles/DIY_Lernfähige_Fernbedienung_mit_IRMP

== Danksagung ==

Ganz herzlich bedanken möchte ich mich bei Vlad Tepesch, Klaus Leidinger und Peter K., die mich mit Scan-Dateien ihrer Infrarot-Fernbedienungen versorgt haben. Dank auch an Klaus für seine nächtelangen Tests von IRMP & IRSND.

Ebenso bedanken möchte ich mich bei Christian F. für seine Tipps zur PIC-Portierung.

== Diskussion ==

Meinungen, Verbesserungsvorschläge, harsche Kritik und ähnliches kann im [http://www.mikrocontroller.net/topic/162119 Beitrag: Infrared Multi Protocol Decoder] geäussert werden.

Viel Spaß mit IRMP!

[[Kategorie:Datenübertragung]]
[[Kategorie:AVR-Projekte]]

Mikrocontroller.net - Benutzerbeiträge [de]

IRMP