Mikrocontroller.net - Benutzerbeiträge [de]

HD44780

2017-07-29T06:45:23Z

Oliver s: Link nicht mehr exsistent

Der HD44780 ist ein Steuer-IC für Textdisplays (siehe [[LCD]]). Praktisch alle Textdisplays werden mit diesem oder einem kompatiblen Controller (z. B. KS0066) angesteuert.

== Allgemeine Ansteuerung ==

=== Pinbelegung ===

Die Pinbelegung des ICs selber ist für den Anwender praktisch uninteressant. Hier ist die häufigste Anschluss-Belegung der damit ausgestatteten LCD-Module angegeben.

ACHTUNG: Es gibt Displays mit abweichender Anschluss-Belegung, falscher Anschluss kann zur Zerstörung führen! Daher immer das zugehörige Datenblatt zu Rate ziehen.

{| class="wikitable"
!style="width:5%" | Pin || style="width:10%" | Funktion || Beschreibung
|-
|1 || | Vss || Versorgungsspannung 0 Volt
|-
|2 || | Vcc || Versorgungsspannung + 5 Volt

|-
|3 || | V0 ||Kontrastspannung, zwischen VEE und VCC, kann auf VSS gelegt oder via Poti angeschlossen werden. Bei großflächigen LCDs oder LCDs für den erweiterten Temperaturbereich kann auch eine negative Kontrastspannung nötig sein.
|-
|4 || | RS || Registerauswahl 0 = Befehlsregister, 1 = Datenregister
|-
|5 || | R/W || Lese- oder Schreibzugriff; kann fest auf GND gelegt werden, wenn Busy-Auswertung durch Timing ersetzt wird 0 = Schreiben, 1 = Lesen
|-
|6 || | E || Taktleitung (Achtung! Diese Leitung hat im Gegensatz zu den anderen bei einigen Displays keinen internen Pullup, man muss also einen externen vorsehen, falls man mit Open-Drain-Ausgängen arbeitet.)
|-
|7 || | DB0 || Datenleitung (bleibt im 4-Bit-Modus offen)
|-
|8 || |DB1 || Datenleitung (bleibt im 4-Bit-Modus offen)
|-
|9 || |DB2 || Datenleitung (bleibt im 4-Bit-Modus offen)
|-
|10 || |DB3 || Datenleitung (bleibt im 4-Bit-Modus offen)
|-
|11 || |DB4 || Datenleitung
|-
|12 || |DB5 || Datenleitung
|-
|13 || |DB6 || Datenleitung
|-
|14 || |DB7 || Datenleitung
|-
|15 || A || Anode der LED-Hintergrundbeleuchtung (fakultativ)
|-
|16 || K || Kathode der LED-Hintergrundbeleuchtung (fakultativ)
|-
| || || Es gibt auch Displays ohne die Datenleitungen DB0-3 (werden nur im 4-Bit-Modus angesteuert), dann rutschen die Bezeichnungen dann entsprechend nach unten
|}

===Speicher===

Ein HD44780 besitzt mehrere Speicher. In ihnen wird der Inhalt des Displays sowie das Aussehen von Sonderzeichen gespeichert.

==== CGROM ====

Der '''C'''haracter '''G'''enerator '''ROM''' enthält die Zeichen in Form von 5x8 oder 5x10 Punktmatrizen. Er kann nicht geändert werden, ausser man sendet einen EEPROM zu Hitachi für eine Massenproduktion. Es sind viele verschiedene ROMs (Zeichensätze, engl. Fonts) verfügbar. Er ist für den Anwender nicht zugänglich.

==== CGRAM ====

Im '''C'''haracter '''G'''enerator '''RAM''' können acht 5x8 Pixel oder vier 5x10 Pixel große benutzerdefinierte Zeichen abgelegt werden. Braucht man keine benutzerdefinierten Zeichen, kann man diesen Bereich als Auslagerungsspeicher für den ansteuernden Mikrocontroller benutzen. Dazu muss aber die '''R/W''' Leitung angesteuert werden.

==== DDRAM ====

Im '''D'''isplay '''D'''ata '''RAM''' ist der Inhalt des LCDs gespeichert. Die Kodierung orientiert sich weitestgehend am ASCII Zeichensatz.

Das DDRAM hat üblicherweise mehr Speicherstellen als das Display gleichzeitig anzeigt. Durch Anwenden der Display-Shift-Befehle können die nicht sichtbaren Zeichen zur Anzeige gebracht werden.

Benachbarte Zeichen haben im DDRAM nicht zwangsweise auch aufeinanderfolgende Adressen. So ist etwa bei 1x16-Displays (1 Zeile, 16 Zeichen) oft in der Mitte des Displays ein Adresssprung von 0x07 auf 0x40; bei 2x16-Displays ist der Sprung auf 0x40 normalerweise (programmiererfreundlich) zwischen Ende der ersten und Beginn der zweiten Zeile. Näheres ist dem Datenblatt zu entnehmen.

=== Kommandos ===

{| class="wikitable"
|+ '''HD44780 Befehlssatz'''
!style="width:30%" | Befehl
!RS
!RW
!D7
!D6
!D5
!D4
!D3
!D2
!D1
!D0
|-
|Bildschirminhalt löschen
|0
|0
|0
|0
|0
|0
|0
|0
|0
|1
|-
|Cursor auf Startpos
|0
|0
|0
|0
|0
|0
|0
|0
|1
|X
|-
|Modus festlegen
|0
|0
|0
|0
|0
|0
|0
|1
|I/D
|S
|-
|Display/Cursor
|0
|0
|0
|0
|0
|0
|1
|D
|C
|B
|-
|Cursor/Display schieben
|0
|0
|0
|0
|0
|1
|S/C
|R/L
|X
|X
|-
|Funktionen
|0
|0
|0
|0
|1
|DL
|N
|F
|X
|X
|-
|CGRAM Adresse setzen
|0
|0
|0
|1
|colspan ="6" align="center"|CGRAM-Adresse
|-
|DDRAM Adresse setzen
|0
|0
|1
|colspan="7" align="center"|DDRAM-Adresse
|-
|Adresse/Status lesen
|0
|1
|BF
|colspan="7" align="center"|CG-/DDRAM-Adresse
|-
|Daten in DDRAM/CGRAM schreiben
|1
|0
|colspan="8" align="center"|Daten
|-
|Daten aus DDRAM/CGRAM lesen
|1
|1
|colspan="8" align="center"|Daten
|}

{| class="wikitable"
|+ '''Kodierung der Steuerbits'''
!Bit
!0
!1
|-
|I/D
|Cursorposition dekrementieren
|Cursorposition inkrementieren
|-
|S
|Displayinhalt fest
|Displayinhalt weiterschieben
|-
|D
|Display aus
|Display an
|-
|C
|Cursor aus
|Cursor an
|-
|B
|Cursor blinkt nicht
|Cursor blinkt
|-
|S/C
|Cursor bewegen
|Displayinhalt schieben
|-
|R/L
|Nach links schieben
|Nach rechts schieben
|-
|DL
|4-Bit Interface
|8-Bit Interface
|-
|N
|1-zeiliges Display
|2/4-zeiliges Display
|-
|F
|5×7-Font
|5×10-Font
|-
|BF
|Kann Kommandos annehmen
|Ist beschäftigt
|}

== Ansteuerung per Microcontroller ==

Die Ansteuerung eines HD44780-basierten Displays gestaltet sich sowohl in Bezug auf den Hardware- als auch den Softwareaufwand recht einfach. Sie eignet sich somit sehr gut als Übungsprojekt für Anfänger.

Das HD44780-Interface besteht aus acht Datenleitungen (D0-D7) sowie den drei Steuerleitungen RS ('''R'''egister '''S'''elect), R/W ('''R'''ead/'''W'''rite) und E ('''E'''nable). Die Displays werden mit 5V Betriebsspannung versorgt, die Kontrastspannung V0 bekommt man, indem man ein 10kΩ-[[Potentiometer]] zwischen VCC und GND anschließt und den mittleren Anschluss als Kontrastspannung verwendet. Bei ca. 0,5 Volt werden dann die Pixel sichtbar. Optional haben viele Displays noch eine LED-Beleuchtung eingebaut, diese kann manchmal direkt an 5V angeschlossen werden, da der Vorwiderstand auf der LCD-Platine integriert ist. Oft ist aber auch ein externer Vorwiderstand nötig! Darum vorher besser im Datenblatt nachschauen.

Möchte man IO-Pins am Mikrocontroller sparen, kann das Display im 4-Bit-Modus betrieben werden, die Dateneingänge D0 bis D3 bleiben dann offen. Durch zusätzliche Bauteile ([[AVR-Tutorial:_Schieberegister]]) kann die Zahl der benötigten Port-Pins noch weiter reduziert werden.

Beispielprogramme zur Ansteuerung findet man zuhauf im Internet, u.a. auch hier: [[AVR-Tutorial: LCD]] und [[AVR-GCC-Tutorial/LCD-Ansteuerung|AVR-GCC-Tutorial: LCD-Ansteuerung]]

=== Fertige Projekte oder Bibliotheken ===

* Peter Fleurys [http://homepage.hispeed.ch/peterfleury/avr-software.html LCD library for HD44780 based LCDs]
* avr-libc [http://www.nongnu.org/avr-libc/user-manual/group__stdiodemo.html Demo-Projekt für stdio]
* [http://www.ipd.uka.de/~buchmann/microcontroller/lcd.htm Grundlagen und Code für 8051] von Erik Buchmann
* [http://www.ekenrooi.net/lcd/lcd.shtml ''How to control a HD44780-based Character-LCD''] von Peter Ouwehand. Beispiele für 8051, PIC16C54, AT90S2313
* Firma wickenhäuser [http://www.wickenhaeuser.de 8051 Compiler und Treiber für LCDs ]

== Sonderzeichen ==
{| class="wikitable"
|-
| \40 ! || \41 " || \42 # || \43 $ || \44 % || \45 & || \50 ( || \51 ) || \52 * || \53 Plus-Zeichen
|-
| \54 Komma || \55 Minus-Zeichen || \56 Punkt || \57 Schrägstrich || \72 Doppelpunkt || \73 Semikolon || \74 < || \75 Gleichheitszeichen || \76 > || \77 ?
|-
| \100 @ || \134 eckige Klammer links || \136 eckige Klammer rechts || \137 accent circonflexe || \138 Unterstrich || \140 accent grave || \173 geschweifte Klammer links || \174 senkrechter Strich || \175 geschweifte Klammer rechts || \176 Pfeil nach rechts
|-
| \177 Pfeil nach links || \260 Minuszeichen || \333 Kastenrahmen || \337 hochgestellter Kastenrahmen(wie Potenz) || \340 gr. alpha || \341 ä || \342 ß || \343 klein epsilon || \344 µ || \350 Wurzelzeichen
|-
| \351 hoch minus 1 || \353 hoch x || \356 n mit Oberstrich ( spanisch ) || \357 ö || \363 Zeichen unendlich || \364 Ohm || \365 ü || \366 gr.Summe || \367 pi ( klein ) || \371 u mit strich rechts unten
|-
| \375 geteilt durch || \377 alle Leuchtpunkte eingeschaltet || || || || || || || ||
|}
=== Benutzerdefinierte Sonderzeichen ===
* Benutzerspezifische Zeichen für den HD44780 mit dem [http://www.mugui.de/bin/menu.php?link=hd44780_demo&lang=de Font and Bitmap Generator] erstellen
* http://www.parallax.com/ProductInfo/Microcontrollers/BASICStampSoftware/LCDCharacterCreator/tabid/482/Default.aspx

== Siehe auch ==

* [[AVR-GCC-Tutorial/LCD-Ansteuerung]]
* [[Erweiterte LCD-Ansteuerung]]
* [[Pseudo-Graphische LCD-Ansteuerung]]
* [http://www.mikrocontroller.net/topic/316826#3431235 Forumsbeitrag]: Ermittlung der Startadresse der einzelnen Zeilen
* [https://www.mikrocontroller.net/topic/387596?goto=4438017#4438017 Forumsbeitrag]: HD44780 Extender, transparente Serialisierung der Ansteuerung im 4 oder 8 Bit Modus
* [https://omerk.github.io/lcdchargen/ Custom Character Generator for HD44780 LCD Modules]
* [http://blog.riyas.org/2013/12/online-led-matrix-font-generator-with.html Online led matrix font generator with binary and hex codes for Arduino ]

== Weblinks ==

* [http://www.sprut.de/electronic/lcd/ Ausführliche Beschreibung des HD44780]
* [http://homepage.hispeed.ch/peterfleury/avr-software.html#libs Lib zur HD44780 Ansteuerung (AVR)]
* [http://pic-projekte.de/wordpress/?p=908 Ansteuern des HD44780 mit den XC8/C18-Libraries - PIC]
* [http://www.fonts2u.com/hd44780-regular.font TTF Matrix Pixel Font]

[[Category:Bauteile]]
[[Category:Displays und Anzeigen]]
[[Category:LCD]]

Versorgung aus einer Zelle

2016-11-25T19:56:45Z

Oliver s: Link aktualisiert

Bei batteriebetriebenen Anwendungen stellt sich oft das Problem der Spannungsversorgung. Darauf soll hier näher eingegangen werden.

== Erste Ideen ==

=== 9V-Block mit Linearregler ===

Die erste Idee ist, einen 9V-Block mit dahintergehängtem Linearregler à la 7805 zu verwenden. Dieser Ansatz ist einfach, er hat aber einen sehr schlechten Wirkungsgrad. Bei Abwärtsregelung auf 5V verbrät der Regler immerhin 45% => 55% Wirkungsgrad, bei 3,3V verbrät er 64% => nur noch 36% Wirkungsgrad), und auch der Platzbedarf auf der Leiterplatte ist erheblich. Angesichts dessen kann man schon fast vernachlässigen, dass der klassische 7805 ca. 5mA für sich selber braucht. Das ist meist mehr als ein Mikrocontroller! Diesbezüglich besser sind Low Power Linearregler wie z. B. der [http://www.national.com/mpf/LP/LP2950.html LP2950] (ca. 75μA Eigenverbrauch) oder gar ein [http://focus.ti.com/docs/prod/folders/print/tps71501.html TPS715xx] von [http://www.ti.com Texas Instuments], der mit unglaublich geringen 3,2 μA auskommt.
Statt des Linearreglers könnte man natürlich auch einen Step-Down-Schaltregler benutzen, dann hätte man zumindest einen besseren Wirkungsgrad von 80-90%. Last but not least ist die Energiedichte von 9V-Blocks im Verhältnis zu Mignonzellen eher gering.

http://data.energizer.com/ (Auf Technical Info oben rechts klicken, dann die Batteriefamilie links auswählen, z. B. Alkaline)

{| class="wikitable"
|-
! width="18%" | Batterietyp
! Volumen [cm³]
! Kapazität [mAh]
! mittlere Ausgangs- spannung [V]
! Energiegehalt [mWh]
! Energiedichte [mWh/cm³]
! Masse [g]
|-
|9V Alkaline
| align="center" | 21,1
| align="center" | 625
| align="center" | 7
| align="center" | 4375
| align="center" | 207
| align="center" | 45,6
|-
|Mono Alkaline [D]
| align="center" | 56
| align="center" | 20500
| align="center" | 1,3
| align="center" | 26650
| align="center" | 475
| align="center" | 148
|-
|Baby Alkaline [C]
| align="center" | 26,9
| align="center" | 8350
| align="center" | 1,3
| align="center" | 10855
| align="center" | 404
| align="center" | 26,2
|-
|Mignon Alkaline [AA]
| align="center" | 8,1
| align="center" | 2850
| align="center" | 1,3
| align="center" | 3705
| align="center" | 457
| align="center" | 23
|-
|Micro Alkaline [AAA]
| align="center" | 3,8
| align="center" | 1250
| align="center" | 1,3
| align="center" | 1625
| align="center" | 428
| align="center" | 11,5
|-
|Lithiumzelle, 2032
| align="center" | 1
| align="center" | 240
| align="center" | 2,9
| align="center" | 496
| align="center" | 653
| align="center" | 3
|-
|Lithium-Thionylchlorid [C]
| align="center" | 26.9
| align="center" | 8500
| align="center" | 3.6
| align="center" | 28000
| align="center" | 1040
| align="center" | 50
|}

=== Vier Mignonzellen mit LowDrop-Linearregler ===

Als weitere Möglichkeit wären vier Mignonzellen (leer 3,6V, voll 6V) mit nachgeschaltetem LowDrop-Linearregler zu verwenden. Wenn die Schaltung mit 3,3V auskommt, dann ist man mit dieser Möglichkeit bestens bedient. Die Batterien können bis zum Ende ausgenutzt werden und der Wirkungsgrad liegt bei ca. 75%.
Allerdings bleibt ein Nachteil, wenn man 5V braucht: Die Batterien werden nicht einmal annähernd geleert, weil sie bereits bei 1,25V pro Zelle zusammen gerade noch 5V ergeben, der Regler aber auch gern noch seinen Teil abhaben will (Dropout Voltage). Zu bedenken sind hierbei die Entladekennlinien von Batterien oder noch schlimmer, die von Akkus.

{| class="wikitable sortable" id="Versorgung_aus_einer_Zelle_LowDrop"
|+ '''Sparsame Spannungsregler'''
!Bezeichnung || Ausgangsspannung [V] || Stromverbrauch [µA] || DropOut [mV] @ 50/150/250mA || max. Strom [mA] || Lieferant
|-
|LP2950
| align="center" |3 / 3,3 / 5
| align="center" |75
| align="center" |380 / - / -
| align="center" |160
| [[Elektronikversender#Reichelt | Rei]]
|-
|LF33
| align="center" |3,3
| align="center" |500
| align="center" |100 / 175 / 250
| align="center" |1000
| [[Elektronikversender#Reichelt | Rei]], [[Elektronikversender#IT-WNS | I]]
|-
|LF50
| align="center" |5
| align="center" |500
| align="center" |100 / 175 / 250
| align="center" |500-1000
| [[Elektronikversender#Reichelt | Rei]]
|-
|TPS715xx
| align="center" |1,2..5
| align="center" |3.2
| align="center" |415 / - / -
| align="center" |50-500
| [[Elektronikversender#RS Components | RS]]
|-
| [http://www.robotikhardware.de/download/tps78233.pdf TPS78233]
| align="center" |3.3
| align="center" |0.42
| align="center" |130
| align="center" |150
| [[Elektronikversender#Robotikhardware | RH]]
|-
|MCP1702
| align="center" |1,2..5
| align="center" |2
| align="center" |15 / 40 / 650
| align="center" |200
| [[Elektronikversender#Reichelt | Rei]],[[Elektronikversender#IT-WNS | I]]
|-
|MCP1824
| align="center" |0,8..5
| align="center" |120
| align="center" |30 / 90 / 150
| align="center" |300
| [[Elektronikversender#RS Components | RS]]
|-
|ZLDO330
| align="center" |3,3
| align="center" |1000
| align="center" |20 / 50 / 85
| align="center" |300
| [[Elektronikversender#Reichelt | Rei]]
|-
|UCC283
| align="center" |3,3 5
| align="center" |650
| align="center" |80 (ca.) / 50mV@0,01A 200mV@1,5A 400mV@3A
| align="center" |3000
| [[Elektronikversender#RS_Components | RS]], [[Elektronikversender#Conrad | Con]]
|}

=== Drei Mignonzellen ohne Spannungsregler ===

Die meisten modernen [[Mikrocontroller]] haben einen sehr breiten Versorgungsspannungsbereich, teilweise von 1,8V bis 5,5V. Daher können sie direkt mit drei in Reihe geschalteten Zellen betrieben werden. Während der Entladung sinkt die Betriebsspannung (3×0,8V = 2,4V), was der Mikrocontroller aber verkraftet, sofern er nicht mit maximalem Takt läuft. Wenn man keine weiteren ICs in der Schaltung benötigt oder diese ebenso tolerant bezüglich einer veränderlichen Versorgungsspannung sind, ist diese Methode die einfachste und günstigste (100% Wirkungsgrad). Vor allem wird bei [[Ultra low power | Low Power]] Anwendungen mit [[Sleep Mode]] kein Mikroampere für einen Spannungsregler verschwendet.

=== Lithiumzelle ===

Lithiumzellen haben eine sehr geringe Selbstentladung und eine hohe Spannung von typisch 3V. Damit kann man einen sparsamen Mikrocontroller betreiben. Meist werden diese Zellen für Echtzeituhren und zum Datenerhalt von RAMs genutzt, da hier nur sehr geringe Ströme im Mikroamperebereich benötigt werden. Darauf sind diese Zellen ausgelegt. Aus den meisten kann man nur einige mA entnehmen, bei 10mA und mehr sinkt die verfügbare Kapazität rapide.

Um ein Gerät nur im Notfall mit einer Lithiumzelle zu betreiben (Pufferbetrieb, Netzausfallsicherung), braucht man eine unterbrechungsfreie Umschaltung zwischen Netzteilbetrieb und Batteriebetrieb. Kritisch ist das vor allem für die Lithiumzelle (damit ist kein Lithiumakku gemeint!), da diese nicht aufgeladen werden darf. Sie wird dabei mit heftiger Reaktion zerstört! Eine einfache Schaltung ist die Nutzung von zwei Schottkydioden zur Entkopplung von Batterie und Netzteil, wie es im Artikel ''Speicher'' über [[Speicher#EEPROM_Schreibzugriffe_minimieren | EEPROM]] gezeigt wird.

Der Nachteil dieser Lösung ist der relativ hohe Spannungsabfall von 300..400mV über den Dioden. Besser ist der Einsatz eines P-Kanal MOSFETs zum Schalten der Batteriespannung. Dadurch kann der Spannungsabfall auf wenige Millivolt gesenkt werden. Die Schaltung dazu ist im diesem [http://www.mikrocontroller.net/topic/72275#591483 Beitrag] zu finden.

== Bessere Lösungsansätze ==

Wie man sehen kann, sind oben dargestellte Methoden nur bedingt zufriedenstellend. Vor allem der Platzbedarf dürfte ein k.-o.-Kriterium sein. Besser wäre es, nur eine oder zwei Zellen zu verwenden.

=== Step-Down-Schaltregler (Abwärtsregler, Tiefsetzsteller) ===

Falls die Batteriespannung auch am Ende der Entladung höher als die Versorgungsspannung ist, bieten sich Step-down Regler an.
* TPS62056 : Uin 2,7 .. 10 V, Uout=0,7 .. 6 V, 12 µA Eigenverbrauch, SMD-Gehäuse MSOP10
* TPS62202 : Uin 2,5 .. 6 V, Uout 1,8V, 12 µA Eigenverbrauch, SMD-Gehäuse SOT23-5
* OKI-78SR-xx : Uin 7 .. 36 V, Uout 3.3V/5V, Module mit Standard 78xx Anschluss.

=== Step-Up-Schaltregler (Aufwärtsregler, Hochsetzsteller) ===

Step-Up-Schaltregler bringen die Spannung, wie der Name schon sagt, 'einen Schritt nach oben'. Ideal also, um aus 1,5V oder 3V z. B. 5V zu erzeugen. Desweiteren sind sie auch geeignet, um höhere Ströme (bis 0,5 A, je nach Aufbau und Spule) zu entnehmen. Das Arbeitsprinzip bei Step-Up-Schaltreglern ist immer gleich: Eine Spule wird ständig an- und abgeschaltet und durch Eigeninduktion eine höhere Spannung erzeugt. Um einen Step-Up-Schaltregler aufzubauen, gibt es verschiedene Möglichkeiten:

==== ICs ====

'''Vorteile'''

* zuverlässig
* meist wenig Außenbeschaltung nötig
* geringe Größe, auch der Spule, da hohe Schaltfrequenzen verwendet werden

'''Nachteile'''

* teuer, vor allem die, welche ab 1V arbeiten
* teilweise schwer zu bekommen
* benötigen mehr Aufwand für Filterung und Schirmung als Linearregler.

[[Kategorie:Bauteile]]
{| class="wikitable"
|+ '''Schaltregler-ICs'''
|-
! style="width: 10%"| IC !! style="width:*"| Bemerkung !! style="width:7em"| Lieferant
|-
| [http://www.tranzistoare.ro/datasheets/2300/57048_DS.pdf LT1073-5]
| 1V (1 Zelle) auf 5V, 40mA
|-
| [http://cds.linear.com/docs/en/datasheet/1111fd.pdf LT1111]
| 2V-12V Step-Up, bis 30V Step-Down, 72kHz Schaltfrequenz, Bezeichnung -5 und -12 mit fester Ausgangsspannung 5V bzw. 12V
| R
|-
| [http://www.ortodoxism.ro/datasheets/lineartechnology/lt1301.pdf LT1301]
| 2V (2 Zellen) auf 5V oder 12V, 250mA
| C
|-
| [http://www.ortodoxism.ro/datasheets/lineartechnology/lt1302.pdf LT1302] ||2V (2 Zellen) auf 5V oder 12V, 250mA
| C, R, RobHard<ref name="plat_mod">Platinen/ Module</ref>
|-
| [http://cds.linear.com/docs/en/datasheet/3401fb.pdf LTC3401] ||ziemlich geniales Teil, weil es mit hoher Schaltfrequenz arbeitet, dadurch kann eine kleine Spule verwendet und ein sehr hoher Wirkungsgrad erzielt werden. 0.5...5.5V Vin, 1,0V Startup-Voltage, 2,6...5,5V Vout, bis 1A
|-
| [http://cds.linear.com/docs/Datasheet/3429fa.pdf LTC3429]||0,5...4,4V Vin, 1,0V Startup-Voltage, 2,5...4,3V Vout, 100mA aus einer Zelle, 250mA aus zwei Zellen bei 3,3V Vout
|-
| [http://www.linear.com/pc/downloadDocument.do?navId=H0,C1,C1003,C1042,C1031,C1060,P13393,D9338 LTC3525-5] ||
|-
| [http://datasheets.maxim-ic.com/en/ds/MAX866-MAX867.pdf MAX866/MAX867] ||ziemlich geniales Teil, weil es mit hoher Schaltfrequenz arbeitet, ab 0.8V, bei 0.9V Start-Up-Voltage
|-
|-
| [http://www.maximintegrated.com/datasheet/index.mvp/id/1207] || wie MAX866/867 jedoch 85% Wirkungsgrad bei 100mA und 500kHz Schaltgeschwindigkeit
|-
| [http://datasheets.maxim-ic.com/en/ds/MAX1595.pdf MAX1595] || dito, benötigt lediglich 3 Kondensatoren als Außenbeschaltung
|-
| [http://datasheets.maxim-ic.com/en/ds/MAX1674-MAX1676.pdf MAX1674-1676] ||bis zu ein Ampere, bei einer Zelle ist aber bei 100mA Schluss, und das auch nur, wenn die Spannung beim "Hochfahren" höher war und die richtige Spule verwendet wird
|I (MAX1674)
|-
| [http://datasheets.maxim-ic.com/en/ds/MAX1759.pdf MAX1759] || noch ein Hochfrequenz-Teil
|-
| [http://datasheets.maxim-ic.com/en/ds/MAX1722-MAX1724.pdf MAX1722-1724] || bis 150 mA
|-
| [http://ww1.microchip.com/downloads/en/DeviceDoc/22234B.pdf MCP1640] ||ab 0.35V bei 0.65V startup, einfache Beschaltung, regelbare Ausgangsspannung, bis 350 mA, 19µA quiescent current, nur kleine Induktivität (4,7µH) nötig
| C, R
|-
| [http://www.prema.com/Application/whiteleddriver.html PR4401/PR4402]||22 und 44 mA, benötigen lediglich 1 externes Bauteil, die Spule. Einfach zu handhaben
| R, I
|-
| [http://www.prema.com/Application/pr4404_e.html PR4404]||150 mA von einer, und 300 mA von zwei Zellen. Preiswert
| R, I
|-
| [http://www.sipex.com/Files/DataSheets/sp6648.pdf SP6648]
||
|-
| [http://focus.ti.com/lit/ds/symlink/tps61200.pdf TPS61200/201/202] ||1,8..5,5V out, Quellspannung bis herunter auf 0,3V, ?>90%, 0,5mm Pinabstand, 3,15*3,15mm, 10-Pin QFN
|
|-
| [http://focus.ti.com/lit/ds/symlink/tps61220.pdf TPS61220] ||1,8..5,5V out, Quellspannung bis herunter auf 0,7V, >90%, 6-pin SC-70(DCK),2mm*2mm
|R
|-
| [http://focus.ti.com/docs/prod/folders/print/tps61006.html TPS6100x]||Single- and Dual-Cell Boost Converster, min 0,8V Vin, 1,5V...3,3V Vout, min. 100mA aus einer Zelle, min.250mA auf zwei Zellen, Gehäuse 10MSOP
|-
| [http://focus.ti.com/docs/prod/folders/print/tps61016.html TPS6101x]||1-Cell and 2-Cell Boost Converters, TPS61006 and TPS61016 are functionally equivalent. TPS61006 is non-synchronous. TPS61016 is synchronous and does not require an external Schottky diode.
|-
| TPS6030x, TPS6031x, [http://www.ortodoxism.ro/datasheets/lineartechnology/15023f.pdf LTC1502-3.3] ||(typ. 3,x V bei 15-20 mA)
|-
| [http://www.ortodoxism.ro/datasheets2/7/0y1y62f9lzj79rs7uuf28jq4xtwy.pdf LM2621]
||
|-
| [[MC34063]]||(ungeeignet, läuft erst ab 3V)
| R, I
|-
| [http://atmel.com/dyn/products/product_card.asp?part_id=4523 ATtiny43U]||AVR-Microcontroller, der einen Boost-Converter eingebaut hat und damit eine Batterie bis auf 0.7V aussaugen kann.
|-
| [http://www.onsemi.com/pub_link/Collateral/NCP1400A-D.PDF NCP1400A]||Startup 0.8V / |
| W<ref name="plat_mod" />
|-
| [http://www.onsemi.com/pub_link/Collateral/NCP1402-D.PDF NCP1402]||Startup 0.8V, 200mA, Preis < 1 Euro
| W<ref name="plat_mod" />
|-
| [http://cds.linear.com/docs/en/datasheet/338813f.pdf LTC3388] ||Nanopower Step Down Regulator, weniger als 1µA Leerlaufstrom, 50mA Ausgangsstrom
|}
Lieferanten '''C'''onrad, '''R'''eichelt, '''W'''atterott, '''Rob'''otik'''Hard'''ware.de, '''I'''T-WNS <references />

'''Dioden'''

*Prakisch kann nahezu jede Schottkydiode mit ausreichend Strombelastbarkeit genutzt werden, siehe [[Dioden-Übersicht]].

==== Diskrete Schaltungen ====

'''Vorteile:'''
* größtmögliche Anpassung an Verwendungszweck
* teilweise schon mit Standardhühnerfutter aufzubauen

'''Nachteile:'''

* kompliziert
* nicht garantierte Funktion (z. B. wegen gepulster Gleichspannung)
* schlechte EMV-Eigenschaften

'''Auflistung diskreter Step-Up-Schaltregler:'''

* http://www.elektronik-kompendium.de/forum/forum_entry.php?id=17395
* http://www.joretronik.de/Web_NT_Buch/Kap6_2/Kapitel6_2.html#6.2
* http://www.mikrocontroller.net/topic/73532#604774
* [http://www.nxp.com/documents/application_note/AN10218.pdf NXP AN10218] (PDF) (Philips LPC900 microcontroller) single cell power supply
* [http://www.b-kainka.de/bastel36.htm Der LED-Spannungswandler] von B. Kainka
* [http://www.bigclive.com/joule.htm Make a Joule Thief] - Versorgung einer LED aus einer 1,5V Zelle
* Diskussionen von '''Joule-Thief''' Schaltungen im Forum
** [http://www.mikrocontroller.net/topic/47224 Sensor autark betreiben mit einem Thermogenerator]
** [http://www.mikrocontroller.net/topic/55041 LEDs mit Akku(s) effizient betreiben]
** [http://www.mikrocontroller.net/topic/38163 Wie kann man eine Knopfzellenspannung um ca. 1 Volt erhöhen]
** [http://www.mikrocontroller.net/topic/62158 Spannungsanhebung 1,2V -> 2V]
** [http://www.mikrocontroller.net/topic/77154 Step-Up Transistorschaltung für LED Lampe]
** [http://www.mikrocontroller.net/topic/56523 3x 2,9V LEDs mit 2xAAA versorgen]
** [http://www.mikrocontroller.net/topic/55962 Gibt es eine Möglichkeit LEDs bei 1V zu betreiben]
** [http://cappels.org/dproj/ledpage/leddrv.htm#Rusty_Nail_Night_Light Rusty Nail Night Light]

=== Ladungspumpen ===

Ladungspumpen erhöhen die Spannung, indem sie Kondensatoren zyklisch parallel laden, umpolen und in Reihe entladen.

'''Vorteile:'''
* geringer Stromverbrauch, deshalb für Low-Power-Anwendungen gut geeignet
* keine Spulen, deshalb kein magnetisches Störfeld

'''Nachteile:'''
* nur geringe Ausgangsströme möglich (100mA)
* ICs nur für höhere Eingangspannungen erhältlich, ab 3V
* Teilweise starke Strompulse beim Umladen der Kondensatoren, womit empfindliche Analogschaltungen gestört werden können (Funkempfänger etc.)

'''Auflistung von Ladungspumpen:'''
* TPS60300 - Vin 0,9-1,8V
* TPS60100 - Vin 1,8-3,6V (200mA)
* MAX1759 - Vin 1,6-5,5V (2-3 Zellen)
* ICL7660 - Vin 1,5-10V (10mA) [Pollin]

== Forumsbeiträge zum Thema ==

*[http://www.mikrocontroller.net/topic/45101 3v3 Volt aus einer 1v2 Volt Zelle]
*[http://www.mikrocontroller.net/topic/18789 Stromversorgung aus einer Zelle]
*[http://www.mikrocontroller.net/topic/73532 Step-Up Mignon zu 5V]
*[http://www.mikrocontroller.net/topic/141635 Stepup/-down: Konstante 5V aus 4xMonozelle]
*[http://www.mikrocontroller.net/topic/189526 Ersatz 9V-Block durch Mikrozelle]

== Externe Links zu Step-Up / µCs ==
* http://www.linear.com/products/Step-Up_(Boost)_Regulators
* http://www.ti.com/power
* http://www.maxim-ic.com/products/power/
* [http://focus.ti.com/lit/an/slaa105/slaa105.pdf TI Application Report SLAA 105] Simple 1.5-V Boost Converter for MSP430
* 2-6V DC nach 5V DC Konverter auf der Basis des '''LT1302''' als [http://www.shop.robotikhardware.de/shop/catalog/product_info.php?cPath=83&products_id=195 Fertigmodul] bzw. [http://www.shop.robotikhardware.de/shop/catalog/product_info.php?products_id=194 Platine] (Shop robotikhardware.de)
* [http://spritesmods.com/?art=ucboost Run an uC from an AA-battery] auf spritesmods.com
* [http://ww1.microchip.com/downloads/en/AppNotes/01416a.pdf AN1416: Low-Power Design Guide] von Microchip (PDF)


== Externe Links zu Batterien allgemein ==
* [http://batteryshowdown.com/ Battery Showdown] Sehr ausführlicher Test zu Entladekennlinien von Batterien
* [http://www.powerstream.com/BatteryFAQ.html PowerStream Battery Chemistry FAQ]
* [http://www.heise.de/mobil/Langzeittest-von-NiMH-Akkus-mit-reduzierter-Selbstentladung--/artikel/143297 Langzeittest von NiMH-Akkus mit reduzierter Selbstentladung] auf heise.de

[[Kategorie:Bauteile]]
[[Kategorie:Spannungsversorgung und Energiequellen]]

IRMP

2015-09-21T13:56:28Z

Oliver s:

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

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

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".

Im folgenden wird IRMP als "Infrarot-Multiprotokoll-Decoder" in allen Einzelheiten vorgestellt. Auch das Gegenstück, nämlich IRSND als IR-Encoder, wird in diesem Artikel behandelt.

= IRMP - Infrarot-Multiprotokoll-Decoder =

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

=== Unterstützte µCs ===

[[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] ist u.a. lauffähig auf folgenden AVR µCs:

* ATtiny87, ATtiny167
* ATtiny45, ATtiny85
* ATtiny44, ATtiny84
* ATmega8, ATmega16, ATmega32
* ATmega162
* ATmega164, ATmega324, ATmega644, ATmega644P, ATmega1284
* ATmega88, ATmega88P, ATmega168, ATmega168P, ATmega328P

Es gibt aber auch Portierungen auf diverse PIC µCs - für den CCS- und C18-Compiler. Auch ist [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] mittlerweile auf AVR XMega, ARM STM32 und Stellaris LM4F120 Launchpad von TI (ARM Cortex M4) lauffähig.

=== Unterstützte IR-Protokolle ===

[[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] - der Infrarot-Fernbedienungsdecoder, der mehrere Protokolle auf einmal decodieren kann, beherrscht folgende Protokolle (in alphabetischer Reihenfolge):

{| {{Tabelle}}
|+ '''Unterstützte Protokolle'''
|- style="background-color:#eeeeee"
! style="width:15%" | Protokoll || Hersteller
|-
| [[IRMP#A1TVBOX|A1TVBOX]] || ADB (Advanced Digital Broadcast), z.B. A1 TV Box
|-
| [[IRMP#APPLE|APPLE]] || Apple
|-
| [[IRMP#ACP24|ACP24]] || Stiebel Eltron
|-
| [[IRMP#B&O|B&O]] || Bang & Olufsen
|-
| [[IRMP#BOSE|BOSE]] || Bose
|-
| [[IRMP#DENON|DENON]] || Denon, Sharp
|-
| [[IRMP#FAN|FAN]] || FAN, Fernsteuerung für Ventilatoren
|-
| [[IRMP#FDC|FDC]] || FDC Keyboard
|-
| [[IRMP#GRUNDIG_+_NOKIA|GRUNDIG]] || Grundig
|-
| [[IRMP#GRUNDIG_+_NOKIA|NOKIA]] || Nokia, z.B. D-Box
|-
| [[IRMP#IR60 (SDA2008)|IR60 (SDA2008)]] || Diverse europäische Hersteller
|-
| [[IRMP#JVC|JVC]] || JVC
|-
| [[IRMP#KASEIKYO|KASEIKYO]] || Panasonic, Technics, Denon und andere japanische Hersteller, welche Mitglied der "Japan's Association for Electric Home Application" sind.
|-
| [[IRMP#KATHREIN|KATHREIN]] || KATHREIN
|-
| [[IRMP#LEGO|LEGO]] || Lego
|-
| [[IRMP#LGAIR|LGAIR]] || LG Air Conditioner
|-
| [[IRMP#MATSUSHITA|MATSUSHITA]] || Matsushita
|-
| [[IRMP#NEC16|NEC16]] || JVC, Daewoo
|-
| [[IRMP#NEC42|NEC42]] || JVC
|-
| [[IRMP#MERLIN|MERLIN]] || MERLIN Fernbedienung (Pollin Bestellnummer: 620 185)
|-
| [[IRMP#NEC_+_extended_NEC|NEC]] || NEC, Yamaha, Canon, Tevion, Harman/Kardon, Hitachi, JVC, Pioneer, Toshiba, Xoro, Orion, NoName und viele weitere japanische Hersteller.
|-
| [[IRMP#NETBOX|NETBOX]] || Netbox
|-
| [[IRMP#NIKON|NIKON]] || NIKON
|-
| [[IRMP#NUBERT|NUBERT]] || Nubert, z.B. Subwoofer System
|-
| [[IRMP#ORTEK|ORTEK]] || Ortek, Hama
|-
| [[IRMP#PENTAX|PENTAX]] || PENTAX ('''NEU!''')
|-
| [[IRMP#RC5_+_RC5X|RC5]] || Philips und andere europäische Hersteller
|-
| [[IRMP#RC6_+_RC6A|RC6A]] || Philips, Kathrein und andere Hersteller, z.B. XBOX
|-
| [[IRMP#RC6_+_RC6A|RC6]] || Philips und andere europäische Hersteller
|-
| [[IRMP#RCCAR|RCCAR]] || RC Car: IR Fernbedienung für Modellfahrzeuge
|-
| [[IRMP#RECS80|RECS80]] || Philips, Nokia, Thomson, Nordmende, Telefunken, Saba
|-
| [[IRMP#RECS80EXT|RECS80EXT]] || Philips, Technisat, Thomson, Nordmende, Telefunken, Saba
|-
| [[IRMP#RCMM|RCMM]] || Fujitsu-Siemens z.B. Activy keyboard
|-
| [[IRMP#ROOMBA|ROOMBA]] || iRobot Roomba Staubsauger
|-
| [[IRMP#S100|S100]] || Ähnlich zu RC5, aber 14 statt 13 Bits und 56kHz Modulation. Hersteller unbekannt.
|-
| [[IRMP#SAMSUNG32|SAMSUNG32]] || Samsung
|-
| [[IRMP#SAMSUNG48|SAMSUNG48]] || Div. Klimaanlagen Hersteller
|-
| [[IRMP#SAMSUNG|SAMSUNG]] || Samsung
|-
| [[IRMP#SIEMENS_+_RUWIDO|RUWIDO]] || RUWIDO (z.B. T-Home-Mediareceiver, MERLIN-Tastatur (Pollin))
|-
| [[IRMP#SIEMENS_+_RUWIDO|SIEMENS]] || Siemens, z.B. Gigaset M740AV
|-
| [[IRMP#SIRCS|SIRCS]] || Sony
|-
| [[IRMP#SPEAKER|SPEAKER]] || Lautsprecher Systeme wie z.B. X-Tensions
|-
| [[IRMP#TECHNICS|TECHNICS]] || Technics '''(NEU!)'''
|-
| [[IRMP#TELEFUNKEN|TELEFUNKEN]] || Telefunken
|-
| [[IRMP#THOMSON|THOMSON]] || Thomson
|}

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.

=== Entstehung ===

Der auf AVR- und PIC-µCs einsetzbare Source zu [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] entstand im Rahmen des [[Word Clock]] Projektes.

=== Thread im Forum ===

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

== IR-Protokolle ==

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

Einige Hersteller verwenden ihr eigenes hausinterne Protokoll, dazu gehören u.a. Sony, Samsung und Matsushita. Philips hat [[IRMP#RC5 + RC5X|RC5]] entwickelt und natürlich auch selbst benutzt. [[IRMP#RC5 + RC5X|RC5]] galt damals in Europa als ''das'' Standard-IR-Protokoll, welches von vielen europäischen Herstellern übernommen wurde. Mittlerweile ist [[IRMP#RC5 + RC5X|RC5]] fast gar nicht mehr anzutreffen - man kann es eigentlich als "ausgestorben" abhaken. Der Nachfolger [[IRMP#RC6_+_RC6A|RC6]] wird zwar noch in einigen aktuellen europäischen Geräten eingesetzt, ist aber auch nur vereinzelt vorzufinden.

Auch die japanischen Hersteller haben versucht, einen eigenen Standard zu etablieren, nämlich das sog. [[IRMP#KASEIKYO|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 - auch wenn man es hier und da im heimischen Haushalt vorfindet.

Heutzutage wird (auch vornehmlich bei japanischen Geräten) das [[IRMP#NEC_+_extended_NEC|NEC]]-Protokoll verwendet - und zwar von den unterschiedlichsten (Marken- und auch Noname-)Herstellern. Ich schätze den "Marktanteil" auf ca. 80% beim [[IRMP#NEC_+_extended_NEC|NEC]]-Protokoll. Fast alle Fernbedienungen im alltäglichen Einsatz verwenden bei mir den [[IRMP#NEC_+_extended_NEC|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.

== Kodierungen ==

[[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] unterstützt folgende IR-Codings:

* [[IRMP#Pulse Distance|Pulse Distance]], typ. Beispiel: [[IRMP#NEC_+_extended_NEC|NEC]]
* [[IRMP#Pulse Width|Pulse Width]], typ. Beispiel: [[IRMP#SIRCS|Sony SIRCS]]
* [[IRMP#Biphase|Biphase (Manchester)]], typ. Beispiel: Philips [[IRMP#RC5_+_RC5X|RC5]], [[IRMP#RC6_+_RC6A|RC6]]
* [[IRMP#Pulse Position|Pulse Position (NRZ)]], typ. Beispiel: [[IRMP#NETBOX|Netbox]]
* [[IRMP#Pulse Distance Width|Pulse Distance Width]], typ. Beispiel: [[IRMP#NUBERT|Nubert]]

Die Pulse werden dabei moduliert - üblicherweise mit 36kHz oder 38kHz - um Umwelteinflüsse wie Raum- oder Sonnenlicht ausfiltern zu können.

=== Pulse Distance ===

[[Datei:Pulse-Distance.png|miniatur|Pulse Distance Coding]]

Eine Pulse Distance Kodierung erkennt man an der folgenden Regel:

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

=== Pulse Width ===

[[Datei:Pulse-Width.png|miniatur|Pulse Width Coding]]

Bei der Pulse Width Kodierung gilt die Regel:

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

=== Pulse Distance Width ===

[[Datei:Pulse-Distance-Width.png|miniatur|Pulse Distance Width Coding]]

Dies ist ein Mischmasch aus Pulse Distance und Pulse Width Coding.

Also:

* es gibt '''zwei verschiedene Pulslängen''' und '''zwei verschiedene Pausenlängen.'''

=== Biphase ===

[[Datei:Biphase-Coding.png|miniatur|Biphase Coding]]

Bei der Biphase Kodierung entscheidet die Reihenfolge von Puls und Pause über den Wert des Bits.

Damit erkennt man ein Biphase-Coding an folgendem Kriterium:

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

Normalerweise sind die Längen für die Pulse und Pausen gleich, d.h. die Signalform ist symmetrisch. IRMP erkennt aber auch Protokolle, die mit unterschiedlichen Puls-/Pause-Längen arbeiten. Dies ist zum Beispiel bei dem [[IRMP#A1TVBOX|A1TVBOX]]-Protokoll der Fall.

=== Pulse Position ===

[[Datei:Pulse-Position.png|miniatur|Pulse Position Coding]]

Die Pulse Position Kodierung kennt man von den üblichen UARTs. Hier hat jedes Bit eine feste Länge. Je nach Wert (0 oder 1) ist es ein Puls oder eine Pause.

Typisches Kriterium für ein '''Pulse Position Protokoll''' ist:

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

'''Eine tabellarische Aufstellung der verschiedenen IR-Protokolle findet man hier: [[IRMP#Die_IR-Protokolle_im_Detail|Die IR-Protokolle im Detail]].'''

Die dort angegebenen Timingwerte sind Idealwerte. Bei einigen Fernbedienungen in der Praxis weichen sie um bis zu 40% voneinander ab. Deshalb arbeitet [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] mit Minimum-/Maximumsgrenzen, um bzgl. des Zeitverhaltens tolerabel zu sein.

== Protokoll-Erkennung ==

Die meisten der von [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] decodierten Protokolle haben etwas gemeinsames: Sie weisen ein Start-Bit auf, welches vom Timing her ausgezeichnet, d.h. einmalig ist.

Anhand dieses Start-Bit-Timings werden meistens die verschiedenen Protokolle unterschieden. [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|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#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] wartet also nicht darauf, dass ein kompletter Frame eingelesen wurde, sondern legt direkt nach der ersten Pulserkennung los.

Ist das gelesene Start-Bit nicht eindeutig, fährt [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] "mehrspurig", d.h. es werden zum Beispiel zwei mögliche Protokolle gleichzeitig verfolgt. Sobald aus Plausibilitätsgründen eines der beiden Protokolle nicht mehr möglich sein kann, wird komplett auf das andere Protokoll gewechselt.

Realisiert wird die Erkennung über eine [[Statemachine]], die [[AVR-GCC-Tutorial/Die_Timer_und_Zähler_des_AVR|timergesteuert]] über eine [[Interrupt|Interruptroutine]] in regelmäßigen Abständen (üblicherweise 15.000 mal in der Sekunde) aufgerufen wird. Die [[Statemachine]] kennt (unter anderem) folgende Zustände:

* Erkenne den ersten Puls des Start-Bits
* Erkenne die Pause des Start-Bits
* Erkenne den Puls des ersten Datenbits

Danach sind die Puls/Pause-Längen des Startbits bekannt. Nun werden alle vom Anwender aktivierten Protokolle nach diesen Längen durchsucht. Wurde ein Protokoll gefunden, werden die Timing-Tabellen dieses Protokolls geladen und im weiteren geprüft, ob die nachfolgenden Puls-/Pause-Zeiten innerhalb der geladenen Werte übereinstimmen.

Es geht also weiter in der [[Statemachine]] mit folgenden Zuständen

* Erkenne die Pausen der Datenbits
* Erkenne die Pulse der Datenbits
* Prüfe Timing. Wenn abweichend, schalte um auf ein anderes noch in Frage kommendes IR-Protokoll, ansonsten schalte [[Statemachine]] komplett zurück
* Erkenne das Stop-Bit, falls das Protokoll eines vorsieht
* Prüfe Daten auf Plausibilität, wie CRC oder andere redundante Datenbits
* Wandle die Daten in Geräte-Adresse und Kommando
* Erkenne Wiederholungen durch längere Tastendrücke, setze entsprechendes Flag

Tatsächlich ist die [[Statemachine]] noch etwas komplizierter, da manche Protokolle gar kein Start-Bit (z.B. [[IRMP#DENON|Denon]]) bzw. mehrere Start-Bits (z.B. 4 bei [[IRMP#B.26O|B&O]]) haben bzw. mitten im Frame ein weiteres Synchronisierungs-Bit (z.B. [[IRMP#SAMSUNG|Samsung]]) vorsehen. Diese besonderen Bedingungen werden durch protokollspezifische "Spezialbehandlungen" im Code abgefangen.

Das Umschalten auf ein anderes Protokoll kann mehrfach während des Empfangs des Frames geschehen, z.B. von [[IRMP#NEC42|NEC42]] (42 Bit) auf [[IRMP#NEC16|NEC16]] (8 Bit + Sync-Bit + 8 Bit), wenn vorzeitig ein zusätzliches Synchronisierungsbit erkannt wurde, oder von [[IRMP#NEC + extended NEC|NEC]]/[[IRMP#NEC42|NEC42]] (32/42 Bit) auf [[IRMP#JVC|JVC]] (16 Bit), wenn das Stop-Bit vorzeitig auftrat. Schwierig wird es dann, wenn zwei mögliche Protokolle nach Erkennung des Start-Bits unterschiedliche Kodierungen verwenden, z.B. wenn das eine Protokoll ein [[IRMP#Pulse Distance|Pulse Distance Coding]] und das andere ein [[IRMP#Biphase|Biphase Coding (Manchester)]] benutzt. Hier speichert [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] die jeweils völlig verschieden ermittelten Bits für beide Codierungen, um dann später die einen oder anderen
Werte wieder zu verwerfen.

Desweiteren senden einige Fernbedienungen bei bestimmten Protokollen aus Gründen der Redundanz (Fehlererkennung) oder wegen längeren Tastendrucks Wiederholungsframes. Diese werden von IRMP unterschieden: Die für die Fehlererkennung zuständigen Frames werden von IRMP geprüft, aber nicht an die Anwendung zurückgegeben, die anderen werden als langer Tastendruck erkannt und entsprechend von IRMP gekennzeichnet.

== Download ==

Version 2.9.5, Stand vom 20.09.2015

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

[[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] & [[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|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], Git: [https://github.com/svn2github/irmp IRMP auf GitHub]

'''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 unter Windows die Projekt-Datei irmp.aps in das AVR Studio 4 lädt.

Für andere Entwicklungsumgebungen ist leicht ein Projekt bzw. Makefile angelegt. Zum Source gehören:

* [http://www.mikrocontroller.net/svnbrowser/irmp/irmp.c?view=markup irmp.c] - Der eigentliche IR-Decoder
* [http://www.mikrocontroller.net/svnbrowser/irmp/irmpprotocols.h?view=markup irmpprotocols.h] - Sämtliche Definitionen zu den IR-Protokollen
* [http://www.mikrocontroller.net/svnbrowser/irmp/irmpsystem.h?view=markup irmpsystem.h] - Vom Zielsystem abhängige Definitionen für AVR/PIC/STM32
* [http://www.mikrocontroller.net/svnbrowser/irmp/irmp.h?view=markup irmp.h] - Include-Datei für die Applikation
* [http://www.mikrocontroller.net/svnbrowser/irmp/irmpconfig.h?view=markup irmpconfig.h] - Anzupassende Konfigurationsdatei

* [http://www.mikrocontroller.net/svnbrowser/irmp/main.c?view=markup main.c] - Beispiel Anwendung

{{Warnung|
;WICHTIG: Im Applikations-Source sollte nur irmp.h per include eingefügt werden, also lediglich:
<syntaxhighlight lang="c">
#include "irmp.h"
</syntaxhighlight>

Alle anderen Include-Dateien werden automatisch über irmp.h "eingefügt". Siehe dazu auch die Beispieldatei main.c.

Desweiteren muss die Preprocessor-Konstante '''F_CPU im Projekt bzw. Makefile''' gesetzt werden. Diese sollte mindestens den Wert 8000000UL haben, der Prozessor sollte also zumindest mit 8 MHz laufen.
}}

Auch auf PIC-Prozessoren ist [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] lauffähig. Für den PIC-CCS-Compiler sind entsprechende Preprocessor-Konstanten bereits gesetzt, so dass man [http://www.mikrocontroller.net/svnbrowser/irmp/irmp.c?view=markup irmp.c] direkt in der CCS-Entwicklungsumgebung verwenden kann. Lediglich eine kleine Interrupt-Routine wie

<syntaxhighlight lang="c">
void TIMER2_isr(void)
{
irmp_ISR ();
}
</syntaxhighlight>

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

Für AVR-Prozessoren ist ein Beispiel für die Anwendung von [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] in [http://www.mikrocontroller.net/svnbrowser/irmp/main.c?view=markup main.c] zu finden - im wesentlichen geht es da um die [[AVR-GCC-Tutorial/Die_Timer_und_Zähler_des_AVR|Timer]]-Initialisierung und den Abruf der empfangenen IR-Telegramme. Das empfangene Protokoll, die Geräte-Adresse und der Kommando-Code wird dann in der AVR-Version auf dem HW-UART ausgegeben.

Für das Stellaris LM4F120 Launchpad von TI (ARM Cortex M4) ist eine entsprechende Timer-Initialisierungsfunktion in [http://www.mikrocontroller.net/svnbrowser/irmp/main.c?view=markup main.c] bereits integriert.

Ebenso kann [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] auf STM32-Mikroprozessoren eingesetzt werden.

=== avr-gcc-Optimierungen ===

Ab Version avr-gcc 4.7.x kann die [https://gcc.gnu.org/onlinedocs/gccint/LTO.html#LTO LTO-Option] genutzt werden, um den Aufruf der externen Funktion irmp_ISR() aus der eigentlichen ISR effizienter zu machen. Das verbessert das Zeitverhalten der ISR etwas.

Zu den sonst schon üblichen Compiler- und Linker-Optionen kommen noch folgende dazu:

* Zusätzliche Compiler-Option: -flto
* Zusätzliche Linker-Optionen: -flto -Os

Vergisst man (unter Windows?) die zusätzliche Linker-Option -Os, wird das Binary allerdings wesentlich größer, da dann nicht mehr optimiert wird. Auch muss -flto an den Linker übergeben werden, weil sonst die LTO-Optimierung nicht mehr greift.

=== Konfiguration ===

Die Konfiguration von [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] wird über Parameter in [http://www.mikrocontroller.net/svnbrowser/irmp/irmpconfig.h?view=markup irmpconfig.h] vorgenommen, nämlich:

* [[IRMP#F_INTERRUPTS|Anzahl Interrupts pro Sekunde]]
* [[IRMP#IRMP_SUPPORT_xxx_PROTOCOL|Unterstützte IR-Protokolle]]
* [[IRMP#IRMP_PORT_LETTER + IRMP_BIT_NUMBER|Hardware-Pin zum IR-Empfänger]]
* [[IRMP#IRMP_LOGGING|IR-Logging]]

=== Einstellungen in irmpconfig.h ===

[[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] decodiert sämtliche oben aufgelisteten Protokolle in einer ISR. Dafür sind einige Angaben nötig. Diese werden in [http://www.mikrocontroller.net/svnbrowser/irmp/irmpconfig.h?view=markup irmpconfig.h] eingestellt.

==== F_INTERRUPTS ====

Anzahl der Interrupts pro Sekunde. Der Wert kann zwischen 10000 und 20000 eingestellt werden. Je höher der Wert, desto besser die Auflösung und damit die Erkennung. Allerdings erkauft man sich diesen Vorteil mit erhöhter CPU-Last. Der Wert 15000 ist meist ein guter Kompromiss.

Standardwert:
<syntaxhighlight lang="c">
#define F_INTERRUPTS 15000 // interrupts per second
</syntaxhighlight>

Auf AVR-Prozessoren wird in der Beispielroutine in [http://www.mikrocontroller.net/svnbrowser/irmp/main.c?view=markup main.c] der Timer1 mit 16-Bit-Genauigkeit verwendet. Sollte der Timer1 aus irgendwelchen Gründen nicht verfügbar sein, kann man alternativ auch den Timer2 mit 8-Bit-Genauigkeit verwenden.

In diesem Fall wird dieser dann konfiguriert über:

<syntaxhighlight lang="c">
OCR2 = (uint8_t) ((F_CPU / F_INTERRUPTS) / 8) - 1 + 0.5); // Compare Register OCR2
TCCR2 = (1 << WGM21) | (1 << CS21); // CTC Mode, prescaler = 8
TIMSK = 1 << OCIE2; // enable timer2 interrupt
</syntaxhighlight>

Das obige Beispiel gilt für ATmega88/ATmega168/ATmega328. Bei anderen AVR-µCs empfiehlt sich ein Blick ins Datenblatt.

Man sollte in diesem Fall nicht vergessen, auch die Interrupt-Routine an den Timer2 anzupassen:

<syntaxhighlight lang="c">
ISR(TIMER2_COMP_vect)
{
(void) irmp_ISR();
}
</syntaxhighlight>

==== IRMP_SUPPORT_xxx_PROTOCOL ====

Hier lässt sich einstellen, welche Protokolle von [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] unterstützt werden sollen. Die Standardprotokolle sind bereits aktiv. Möchte man weitere Protokolle einschalten bzw. einige aus Speicherplatzgründen deaktivieren, sind die entsprechenden Werte in [http://www.mikrocontroller.net/svnbrowser/irmp/irmpconfig.h?view=markup irmpconfig.h] anzupassen.

<syntaxhighlight lang="c">
// typical protocols, disable here! Enable Remarks F_INTERRUPTS Program Space
#define IRMP_SUPPORT_SIRCS_PROTOCOL 1 // Sony SIRCS >= 10000 ~150 bytes
#define IRMP_SUPPORT_NEC_PROTOCOL 1 // NEC + APPLE >= 10000 ~300 bytes
#define IRMP_SUPPORT_SAMSUNG_PROTOCOL 1 // Samsung + Samsung32 >= 10000 ~300 bytes
#define IRMP_SUPPORT_MATSUSHITA_PROTOCOL 1 // Matsushita >= 10000 ~50 bytes
#define IRMP_SUPPORT_KASEIKYO_PROTOCOL 1 // Kaseikyo >= 10000 ~250 bytes

// more protocols, enable here! Enable Remarks F_INTERRUPTS Program Space
#define IRMP_SUPPORT_DENON_PROTOCOL 0 // DENON, Sharp >= 10000 ~250 bytes
#define IRMP_SUPPORT_RC5_PROTOCOL 0 // RC5 >= 10000 ~250 bytes
#define IRMP_SUPPORT_RC6_PROTOCOL 0 // RC6 & RC6A >= 10000 ~250 bytes
#define IRMP_SUPPORT_JVC_PROTOCOL 0 // JVC >= 10000 ~150 bytes
#define IRMP_SUPPORT_NEC16_PROTOCOL 0 // NEC16 >= 10000 ~100 bytes
#define IRMP_SUPPORT_NEC42_PROTOCOL 0 // NEC42 >= 10000 ~300 bytes
#define IRMP_SUPPORT_IR60_PROTOCOL 0 // IR60 (SDA2008) >= 10000 ~300 bytes
#define IRMP_SUPPORT_GRUNDIG_PROTOCOL 0 // Grundig >= 10000 ~300 bytes
#define IRMP_SUPPORT_SIEMENS_PROTOCOL 0 // Siemens Gigaset >= 15000 ~550 bytes
#define IRMP_SUPPORT_NOKIA_PROTOCOL 0 // Nokia >= 10000 ~300 bytes

// exotic protocols, enable here! Enable Remarks F_INTERRUPTS Program Space
#define IRMP_SUPPORT_BOSE_PROTOCOL 0 // BOSE >= 10000 ~150 bytes
#define IRMP_SUPPORT_KATHREIN_PROTOCOL 0 // Kathrein >= 10000 ~200 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_RECS80_PROTOCOL 0 // RECS80 (SAA3004) >= 15000 ~50 bytes
#define IRMP_SUPPORT_RECS80EXT_PROTOCOL 0 // RECS80EXT (SAA3008) >= 15000 ~50 bytes
#define IRMP_SUPPORT_THOMSON_PROTOCOL 0 // Thomson >= 10000 ~250 bytes
#define IRMP_SUPPORT_NIKON_PROTOCOL 0 // NIKON camera >= 10000 ~250 bytes
#define IRMP_SUPPORT_NETBOX_PROTOCOL 0 // Netbox keyboard >= 10000 ~400 bytes (PROTOTYPE!)
#define IRMP_SUPPORT_ORTEK_PROTOCOL 0 // ORTEK (Hama) >= 10000 ~150 bytes
#define IRMP_SUPPORT_TELEFUNKEN_PROTOCOL 0 // Telefunken 1560 >= 10000 ~150 bytes
#define IRMP_SUPPORT_FDC_PROTOCOL 0 // FDC3402 keyboard >= 10000 (better 15000) ~150 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_ROOMBA_PROTOCOL 0 // iRobot Roomba >= 10000 ~150 bytes
#define IRMP_SUPPORT_RUWIDO_PROTOCOL 0 // RUWIDO, T-Home >= 15000 ~550 bytes
#define IRMP_SUPPORT_A1TVBOX_PROTOCOL 0 // A1 TV BOX >= 15000 (better 20000) ~300 bytes
#define IRMP_SUPPORT_LEGO_PROTOCOL 0 // LEGO Power RC >= 20000 ~150 bytes
#define IRMP_SUPPORT_RCMM_PROTOCOL 0 // RCMM 12,24, or 32 >= 20000 ~150 bytes
</syntaxhighlight>

Jedes von [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|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 [[IRMP#B&O|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 [[IRMP#B&O|B&O]]-Protokoll (455kHz) mehr empfangen.

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

==== IRMP_PORT_LETTER + IRMP_BIT_NUMBER ====

Über diese Konstanten wird der Pin am µC beschrieben, an welchem der IR-Empfänger angeschlossen ist.

Standardwert ist PORT B6:
<syntaxhighlight lang="c">
/*---------------------------------------------------------------------------
* Change hardware pin here for ATMEL AVR
*---------------------------------------------------------------------------
*/
#if defined (ATMEL_AVR) // use PB6 as IR input on AVR
# define IRMP_PORT_LETTER B
# define IRMP_BIT_NUMBER 6
</syntaxhighlight>

Diese beiden Werte sind an den tatsächlichen Hardware-Pin des µCs anzupassen.

Dies gilt ebenso für die STM32-µCs:

<syntaxhighlight lang="c">
/*----------------------------------------------------------------------------
* Change hardware pin here for ARM STM32
*----------------------------------------------------------------------------
*/
#elif defined (ARM_STM32) // use C13 as IR input on STM32
# define IRMP_PORT_LETTER C
# define IRMP_BIT_NUMBER 13
</syntaxhighlight>

Bei den PIC-Prozessoren gibt es lediglich die anzupassende Konstante '''IRMP_PIN''' - je nach Compiler:

<syntaxhighlight lang="c">
/*----------------------------------------------------------------------------
* Change hardware pin here for PIC C18 compiler
*----------------------------------------------------------------------------
*/
#elif defined (PIC_C18) // use RB4 as IR input on PIC
# define IRMP_PIN PORTBbits.RB4

/*----------------------------------------------------------------------------
* Change hardware pin here for PIC CCS compiler
*----------------------------------------------------------------------------
*/
#elif defined (PIC_CCS) // use PB4 as IR input on PIC
# define IRMP_PIN PIN_B4
</syntaxhighlight>

==== IRMP_USE_CALLBACK ====

Standardwert:
<syntaxhighlight lang="c">
#define IRMP_USE_CALLBACK 0 // flag: 0 = don't use callbacks, 1 = use callbacks, default is 0
</syntaxhighlight>

Wenn man Callbacks einschaltet, wird bei jeder Pegeländerung des Eingangs eine Callback-Funktion aufgerufen. Dies kann zum Beispiel dafür verwendet werden, das eingehende IR-Signal sichtbar zu machen, also als Signal an einem weiteren Pin auszugeben.

Hier ein Beispiel:

<syntaxhighlight lang="c">
#define LED_PORT PORTD // LED at PD6
#define LED_DDR DDRD
#define LED_PIN 6

/*-----------------------------------------------------------------------------------------------------------------------
* Called (back) from IRMP module
* This example switches a LED (which is connected to Vcc)
*-----------------------------------------------------------------------------------------------------------------------
*/
void
led_callback (uint8_t on)
{
if (on)
{
LED_PORT &= ~(1 << LED_PIN);
}
else
{
LED_PORT |= (1 << LED_PIN);
}
}

int
main ()
{
...
irmp_init ();

LED_DDR |= (1 << LED_PIN); // LED pin to output
LED_PORT |= (1 << LED_PIN); // switch LED off (active low)
irmp_set_callback_ptr (led_callback);

sei ();
...
}
</syntaxhighlight>

==== IRMP_LOGGING ====

Mit IRMP_LOGGING kann das Protokollieren von eingehenden IR-Frames eingeschaltet werden.

Standardwert:
<syntaxhighlight lang="c">
#define IRMP_LOGGING 0 // 1: log IR signal (scan), 0: do not. default is 0
</syntaxhighlight>

Weitere Erläuterungen siehe [[IRMP#Scannen_von_unbekannten_IR-Protokollen|Scannen von unbekannten IR-Protokollen]].

=== Anwendung von IRMP ===

Die von [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] unterstützten Protokolle weisen Bitlängen - teilweise variabel, teilweise fest - von 2 bis 48 Bit auf. Diese werden über Preprocessor-Defines beschrieben.

[[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|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

<syntaxhighlight lang="c">
irmp_data_p->protocol (8 Bit)
irmp_data_p->address (16 Bit)
irmp_data_p->command (16 Bit)
irmp_data_p->flags (8 Bit)
</syntaxhighlight>

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:

<syntaxhighlight lang="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
}
}
}
</syntaxhighlight>

Hier die möglichen Werte für irmp_data.protocol, siehe auch [http://www.mikrocontroller.net/svnbrowser/irmp/irmpprotocols.h?view=markup irmpprotocols.h]:

<syntaxhighlight lang="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 (NEC with 16 bits)
#define IRMP_RC6A_PROTOCOL 21 // RC6A, e.g. Kathrein, XBOX
#define IRMP_NIKON_PROTOCOL 22 // Nikon
#define IRMP_RUWIDO_PROTOCOL 23 // Ruwido, e.g. T-Home Mediareceiver
#define IRMP_IR60_PROTOCOL 24 // IR60 (SDA2008)
#define IRMP_KATHREIN_PROTOCOL 25 // Kathrein
#define IRMP_NETBOX_PROTOCOL 26 // Netbox keyboard (bitserial)
#define IRMP_NEC16_PROTOCOL 27 // NEC with 16 bits (incl. sync)
#define IRMP_NEC42_PROTOCOL 28 // NEC with 42 bits
#define IRMP_LEGO_PROTOCOL 29 // LEGO Power Functions RC
#define IRMP_THOMSON_PROTOCOL 30 // Thomson
#define IRMP_BOSE_PROTOCOL 31 // BOSE
#define IRMP_A1TVBOX_PROTOCOL 32 // A1 TV Box
#define IRMP_ORTEK_PROTOCOL 33 // ORTEK - Hama
#define IRMP_TELEFUNKEN_PROTOCOL 34 // Telefunken (1560)
#define IRMP_ROOMBA_PROTOCOL 35 // iRobot Roomba vacuum cleaner
#define IRMP_RCMM32_PROTOCOL 36 // Fujitsu-Siemens (Activy remote control)
#define IRMP_RCMM24_PROTOCOL 37 // Fujitsu-Siemens (Activy keyboard)
#define IRMP_RCMM12_PROTOCOL 38 // Fujitsu-Siemens (Activy keyboard)
#define IRMP_SPEAKER_PROTOCOL 39 // Another loudspeaker protocol, similar to Nubert
#define IRMP_LGAIR_PROTOCOL 40 // LG air conditioner
#define IRMP_SAMSUNG48_PROTOCOL 41 // air conditioner with SAMSUNG protocol (48 bits)
</syntaxhighlight>

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 [http://www.mikrocontroller.net/svnbrowser/irmp/main.c?view=markup 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:

<syntaxhighlight lang="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
}
</syntaxhighlight>

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 [[LED-Fading|LEDs zu faden]].

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

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

== Arbeitsweise ==

Das "Working Horse" von [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] ist die Interrupt Service Routine irmp_ISR() welche 15.000 mal pro Sekunde aufgerufen werden sollte. Weicht dieser Wert ab, muss die Preprocessor-Konstante [[IRMP#F_INTERRUPTS|F_INTERRUPTS]] in [http://www.mikrocontroller.net/svnbrowser/irmp/irmpconfig.h?view=markup irmpconfig.h] angepasst werden. Der Wert kann zwischen 10kHz und 20kHz eingestellt werden.

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 Timing-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 [http://www.mikrocontroller.net/svnbrowser/irmp/main.c?view=markup main.c].

== Scannen von unbekannten IR-Protokollen ==

Stellt man in [http://www.mikrocontroller.net/svnbrowser/irmp/irmpconfig.h?view=markup irmpconfig.h] in der Zeile

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

den Wert für [[IRMP#IRMP_LOGGING|IRMP_LOGGING]] auf 1, wird in [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|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: Für PIC-Prozessoren gibt es ein eigenes Logging-Modul namens [http://www.mikrocontroller.net/svnbrowser/irmp/irmpextlog.c?view=markup irmpextlog.c]. Dieses ermöglicht das Logging über USB. Für AVR-Prozessoren ist [http://www.mikrocontroller.net/svnbrowser/irmp/irmpextlog.c?view=markup irmpextlog.c] irrelevant'''

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#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] an das unbekannte Protokoll anzupassen - siehe nächstes Kapitel.

Wer eine Fernbedienung hat, die nicht von [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|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 ==

=== Übersetzen ===

[http://www.mikrocontroller.net/svnbrowser/irmp/irmp.c?view=markup 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#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] direkt zum "Fraß" vorwerfen kann.

Das Übersetzen von [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] geht folgendermaßen:

make -f makefile.lnx

Dabei werden 3 IRMP-Versionen erzeugt:

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

=== Aufruf von IRMP ===

Der Aufruf geschieht dann über:

./irmp-nnkHz [-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-10kHz < IR-Data/orion_vcr_07660BM070.txt

<syntaxhighlight lang="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
-------------------------------------------------------------------------
...
</syntaxhighlight>

=== Listen-Ausgabe ===

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

<syntaxhighlight lang="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
...
</syntaxhighlight>

=== Analyse ===

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

<syntaxhighlight lang="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%
-------------------------------------------------------------------------------
</syntaxhighlight>

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-10kHz -v < IR-Data/orion_vcr_07660BM070.txt

<syntaxhighlight lang="c">
-------------------------------------------------------------------------------
# 1 - IR-cmd: 0x0001
0.200ms [starting pulse]
13.700ms [start-bit: pulse = 91, pause = 44]
protocol = NEC, start bit timings: pulse: 62 - 118, pause: 30 - 60
pulse_1: 3 - 8
pause_1: 11 - 23
pulse_0: 3 - 8
pause_0: 3 - 8
command_offset: 16
command_len: 16
complete_len: 32
stop_bit: 1
14.800ms [bit 0: pulse = 6, pause = 5] 0
16.000ms [bit 1: pulse = 6, pause = 6] 0
17.100ms [bit 2: pulse = 6, pause = 5] 0
18.200ms [bit 3: pulse = 6, pause = 5] 0
19.300ms [bit 4: pulse = 6, pause = 5] 0
20.500ms [bit 5: pulse = 6, pause = 6] 0
21.600ms [bit 6: pulse = 6, pause = 5] 0
23.800ms [bit 7: pulse = 6, pause = 16] 1
26.100ms [bit 8: pulse = 6, pause = 17] 1
28.300ms [bit 9: pulse = 6, pause = 16] 1
29.500ms [bit 10: pulse = 6, pause = 6] 0
31.700ms [bit 11: pulse = 6, pause = 16] 1
34.000ms [bit 12: pulse = 6, pause = 17] 1
36.200ms [bit 13: pulse = 6, pause = 16] 1
38.500ms [bit 14: pulse = 6, pause = 17] 1
39.600ms [bit 15: pulse = 6, pause = 5] 0
41.900ms [bit 16: pulse = 6, pause = 17] 1
43.000ms [bit 17: pulse = 6, pause = 5] 0
44.100ms [bit 18: pulse = 6, pause = 5] 0
45.200ms [bit 19: pulse = 6, pause = 5] 0
46.400ms [bit 20: pulse = 7, pause = 5] 0
47.500ms [bit 21: pulse = 6, pause = 5] 0
48.600ms [bit 22: pulse = 6, pause = 5] 0
49.800ms [bit 23: pulse = 6, pause = 6] 0
50.900ms [bit 24: pulse = 5, pause = 6] 0
53.100ms [bit 25: pulse = 6, pause = 16] 1
55.400ms [bit 26: pulse = 6, pause = 17] 1
57.600ms [bit 27: pulse = 6, pause = 16] 1
59.900ms [bit 28: pulse = 6, pause = 17] 1
62.100ms [bit 29: pulse = 6, pause = 16] 1
64.400ms [bit 30: pulse = 6, pause = 17] 1
66.700ms [bit 31: pulse = 6, pause = 17] 1
stop bit detected
67.300ms code detected, length = 32
67.300ms p = 2, a = 0x7b80, c = 0x0001, f = 0x00
-------------------------------------------------------------------------------
</syntaxhighlight>

=== Aufruf unter Windows ===

[[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] kann man auch unter Windows nutzen, nämlich folgendermaßen:

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

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

=== Längere Ausgaben ===

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

Linux:

./irmp-10kHz < IR-Data/rc5x.txt | less

Windows:

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

== Fernbedienungen ==

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! Protokoll || Bezeichnung || Gerät || Device Address
|-
| [[IRMP#NEC_+_extended_NEC|NEC]] || Toshiba CT-9859 || Fernseher || 0x5F40
|-
| || Toshiba VT-728G || V-728G Videorekorder || 0x5B44
|-
| || Elta 8848 MP 4 || DVD-Player || 0x7F00
|-
| || AS-218 || Askey TV-View CHP03X (TV-Karte) || 0x3B86
|-
| || Cyberhome ??? || Cyberhome DVD Player || 0x6D72
|-
| || WD TV Live || Western Digital Multimediaplayer || 0x1F30
|-
| || Canon WL-DC100 || Kamera Canon PowerShot G5 || 0xB1CA
|-
| [[IRMP#NEC16|NEC16]] || Daewoo || Videorekorder || 0x0015
|-
| [[IRMP#KASEIKYO|KASEIKYO]] || Technics EUR646497 || AV Receiver SA-AX 730 || 0x2002
|-
| || Panasonic TV || Fernseher TX-L32EW6 || 0x2002
|-
| [[IRMP#RC5_+_RC5X|RC5]] || Loewe Assist/RC3/RC4 || Fernseher (FB auf TV-Mode) || 0x0000
|-
| [[IRMP#RC6_+_RC6A|RC6]] || Philips Television || Fernseher (FB auf TV-Mode) || 0x0000
|-
| [[IRMP#SIRCS|SIRCS]] || Sony RM-816 || Fernseher (FB auf TV-Mode) || 0x0000
|-
| [[IRMP#DENON|DENON]] || DENON RC970 || AVR3805 (Verstärker) || 0x0008
|-
| || DENON RC970 || DVD/CD-Player || 0x0002
|-
| || DENON RC970 || Tuner || 0x0006
|-
| [[IRMP#SAMSUNG32|SAMSUNG32]] || Samsung AA59-00484A || LE40D550 Fernseher || 0x0707
|-
| || LG AKB72033901 || Blu-Ray Player BD370 || 0x2D2D
|-
| [[IRMP#APPLE|APPLE]] || Apple || Apple Dock (iPod 2) || 0x0020
|-
|}

----

== Kameras ==

[[Datei:Irmp-pentax.png|miniatur|Pentax-Protokoll]]

[[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] unterstützt zunehmend auch die Fernsteuerung von Kameras, nämlich:

* [[IRMP#PENTAX|PENTAX]]
* [[IRMP#NIKON|NIKON]]

Die Kommando-Vielfalt ist nicht gerade groß. Normalerweise verstehen die Kameras gerade mal das Kommando "Auslösen".

Hier eine kleine Tabelle für [[IRMP#PENTAX|PENTAX]]-Kameras:

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! Kommando || Funktion
|-
| 0x0000 || Auslösen
|-
| 0x0001 || Zoomlevel umschalten
|-
|}

Da keine Adresse im [[IRMP#PENTAX|PENTAX]]-Protokoll vorgesehen ist, sollte man am diese beim Senden mittels [[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|IRSND]] am besten auf 0x0000 setzen. Ebenso sollte man in diesem Fall einen Quarz verwenden, da gerade die Nikons bezüglich des Timings sehr penibel sind.

== IR-Tastaturen ==

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

[[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|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#IRMP_-_Infrarot-Multiprotokoll-Decoder|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:

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! 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:

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! 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#IRMP_-_Infrarot-Multiprotokoll-Decoder|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#IRMP_-_Infrarot-Multiprotokoll-Decoder|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 [http://www.mikrocontroller.net/svnbrowser/irmp/irmp.c?view=markup 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:
<syntaxhighlight lang="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);
}
</syntaxhighlight>

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

<syntaxhighlight lang="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);
}
}
}
</syntaxhighlight>

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

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! 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:irsnd-sender.png|miniatur|Anschluß eines einfachen IR-Senders an µC.]]

[[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|IRSND]] ist das Gegenstück zu IRMP: es reproduziert aus den Daten, die mit [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] empfangen wurden, wieder den Original Frame, der dann über eine Infrarot-Diode ausgegeben werden kann.

=== Von IRSND unterstützte µCs ===

[[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|IRSND]] ist lauffähig auf folgenden AVR µCs:

* ATtiny87, ATtiny167
* ATtiny45, ATtiny85
* ATtiny44, ATtiny84
* ATmega8, ATmega16, ATmega32
* ATmega162
* ATmega164, ATmega324, ATmega644, ATmega644P, ATmega1284
* ATmega88, ATmega88P, ATmega168, ATmega168P, ATmega328P

Es gibt aber auch Portierungen auf diverse PIC µCs - für den CCS- und C18-Compiler. Auch ist [[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|IRSND]] mittlerweile auf ARM STM32 lauffähig.

=== Von IRSND unterstützte Protokolle ===

[[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|IRSND]] unterstützt die folgenden Protokolle:

* [[IRMP#SIRCS|SIRCS]]
* [[IRMP#NEC_+_extended_NEC|NEC]]
* [[IRMP#SAMSUNG|SAMSUNG]]
* [[IRMP#SAMSUNG32|SAMSUNG32]]
* [[IRMP#SAMSUNG48|SAMSUNG48]]
* [[IRMP#MATSUSHITA|MATSUSHITA]]
* [[IRMP#RC5_+_RC5X|RC5]]
* [[IRMP#KASEIKYO|KASEIKYO]]
* [[IRMP#DENON|DENON]]
* [[IRMP#JVC|JVC]]
* [[IRMP#APPLE|APPLE]]
* [[IRMP#NUBERT|NUBERT]]
* [[IRMP#B&O|BANG_OLUFSON]]
* [[IRMP#GRUNDIG_+_NOKIA|GRUNDIG]]
* [[IRMP#GRUNDIG_+_NOKIA|NOKIA]]
* [[IRMP#SIEMENS_+_RUWIDO|SIEMENS]] (bei mind. ~15kHz)
* [[IRMP#FDC|FDC]] (bei mind. ~15kHz)
* [[IRMP#RCCAR|RCCAR]] (bei mind. ~15kHz)
* [[IRMP#RECS80|RECS80]] (bei mind. ~20kHz)
* [[IRMP#RECS80EXT|RECS80EXT]] (bei mind. ~20kHz)
* [[IRMP#NIKON|NIKON]]
* [[IRMP#RC6_+_RC6A|RC6]]
* [[IRMP#RC6_+_RC6A|RC6A]]
* [[IRMP#THOMSON|THOMSON]]
* [[IRMP#NEC16|NEC16]]
* [[IRMP#NEC42|NEC42]]
* [[IRMP#LEGO|LEGO]]
* [[IRMP#IR60 (SDA2008)|IR60 (SDA2008)]]
* [[IRMP#A1TVBOX|A1TVBOX]]
* [[IRMP#ROOMBA|ROOMBA]]
* [[IRMP#SPEAKER|SPEAKER]]
* [[IRMP#TELEFUNKEN|TELEFUNKEN]]
* [[IRMP#LGAIR|LGAIR]]
* [[IRMP#PENTAX|PENTAX]] '''(NEU!)'''
* [[IRMP#FAN|FAN]] '''(NEU!)'''
* [[IRMP#AP24|ACP24]] '''(NEU!)'''

[[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|IRSND]] unterstützt die folgenden Protokolle derzeit (noch) '''NICHT''':

* [[IRMP#KATHREIN|KATHREIN]]
* [[IRMP#NETBOX|NETBOX]]
* [[IRMP#ORTEK|ORTEK]]
* [[IRMP#RCMM|RCMM]]
* [[IRMP#MERLIN|MERLIN]]

== Download IRSND ==

Version 2.9.5, Stand vom 20.09.2015

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

[[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] & [[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|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 unter Windows die Projekt-Datei irsnd.aps in das AVRStudio 4 lädt.

Auch für andere Entwicklungsumgebungen lässt sich leicht ein Projekt bzw. Makefile zusammenstellen. Zum IRSND-Source gehören folgende Dateien:

* [http://www.mikrocontroller.net/svnbrowser/irmp/irsnd.c?view=markup irsnd.c] - Der eigentliche IR-Encoder
* [http://www.mikrocontroller.net/svnbrowser/irmp/irmpprotocols.h?view=markup irmpprotocols.h] - Sämtliche Definitionen zu den IR-Protokollen
* [http://www.mikrocontroller.net/svnbrowser/irmp/irmpsystem.h?view=markup irmpsystem.h] - Vom Zielsystem abhängige Definitionen für AVR/PIC/STM32
* [http://www.mikrocontroller.net/svnbrowser/irmp/irsnd.h?view=markup irsnd.h] - Include-Datei für die Applikation
* [http://www.mikrocontroller.net/svnbrowser/irmp/irsndconfig.h?view=markup irsndconfig.h] - Anzupassende Konfigurationsdatei

* [http://www.mikrocontroller.net/svnbrowser/irmp/irsndmain.c?view=markup irsndmain.c] - Beispiel Anwendung

'''WICHTIG:'''

'''Im Applikations-Source sollte nur [http://www.mikrocontroller.net/svnbrowser/irmp/irsnd.h?view=markup irsnd.h] per include eingefügt werden, also lediglich:'''

<syntaxhighlight lang="c">
#include "irsnd.h"
</syntaxhighlight>

Alle anderen Include-Dateien werden automatisch über [http://www.mikrocontroller.net/svnbrowser/irmp/irsnd.h?view=markup irsnd.h] "eingefügt". Siehe dazu auch die Beispieldatei [http://www.mikrocontroller.net/svnbrowser/irmp/irsndmain.c?view=markup irsndmain.c].

[[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|IRSND]] encodiert sämtliche oben aufgelisteten Protokolle in einer ISR, siehe [http://www.mikrocontroller.net/svnbrowser/irmp/irsnd.c?view=markup irsnd.c].

=== Einstellungen in irsndconfig.h ===

==== F_INTERRUPTS ====

Anzahl der Interrupts pro Sekunde. Der Wert kann zwischen 10000 und 20000 eingestellt werden.

Standardwert:
<syntaxhighlight lang="c">
#define F_INTERRUPTS 15000 // interrupts per second
</syntaxhighlight>

==== IRSND_SUPPORT_xxx_PROTOCOL ====

Hier lässt sich einstellen, welche Protokolle von [[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|IRSND]] unterstützt werden sollen. Die Standardprotokolle sind bereits aktiv. Möchte man weitere Protokolle einschalten bzw. einige aus Speicherplatzgründen deaktivieren, sind die entsprechenden Werte in [http://www.mikrocontroller.net/svnbrowser/irmp/irsndconfig.h?view=markup irsndconfig.h] anzupassen.

<syntaxhighlight lang="c">
// typical protocols, disable here! Enable Remarks F_INTERRUPTS Program Space
#define IRSND_SUPPORT_SIRCS_PROTOCOL 1 // Sony SIRCS >= 10000 ~200 bytes
#define IRSND_SUPPORT_NEC_PROTOCOL 1 // NEC + APPLE >= 10000 ~100 bytes
#define IRSND_SUPPORT_SAMSUNG_PROTOCOL 1 // Samsung + Samsung32 >= 10000 ~300 bytes
#define IRSND_SUPPORT_MATSUSHITA_PROTOCOL 1 // Matsushita >= 10000 ~200 bytes
#define IRSND_SUPPORT_KASEIKYO_PROTOCOL 1 // Kaseikyo >= 10000 ~300 bytes

// more protocols, enable here! Enable Remarks F_INTERRUPTS Program Space
#define IRSND_SUPPORT_DENON_PROTOCOL 0 // DENON, Sharp >= 10000 ~200 bytes
#define IRSND_SUPPORT_RC5_PROTOCOL 0 // RC5 >= 10000 ~150 bytes
#define IRSND_SUPPORT_RC6_PROTOCOL 0 // RC6 >= 10000 ~250 bytes
#define IRSND_SUPPORT_RC6A_PROTOCOL 0 // RC6A >= 10000 ~250 bytes
#define IRSND_SUPPORT_JVC_PROTOCOL 0 // JVC >= 10000 ~150 bytes
#define IRSND_SUPPORT_NEC16_PROTOCOL 0 // NEC16 >= 10000 ~150 bytes
#define IRSND_SUPPORT_NEC42_PROTOCOL 0 // NEC42 >= 10000 ~150 bytes
#define IRSND_SUPPORT_IR60_PROTOCOL 0 // IR60 (SDA2008) >= 10000 ~250 bytes
#define IRSND_SUPPORT_GRUNDIG_PROTOCOL 0 // Grundig >= 10000 ~300 bytes
#define IRSND_SUPPORT_SIEMENS_PROTOCOL 0 // Siemens, Gigaset >= 15000 ~150 bytes
#define IRSND_SUPPORT_NOKIA_PROTOCOL 0 // Nokia >= 10000 ~400 bytes

// exotic protocols, enable here! Enable Remarks F_INTERRUPTS Program Space
#define IRSND_SUPPORT_KATHREIN_PROTOCOL 0 // Kathrein >= 10000 DON'T CHANGE, NOT SUPPORTED YET!
#define IRSND_SUPPORT_NUBERT_PROTOCOL 0 // NUBERT >= 10000 ~100 bytes
#define IRSND_SUPPORT_BANG_OLUFSEN_PROTOCOL 0 // Bang&Olufsen >= 10000 ~250 bytes
#define IRSND_SUPPORT_RECS80_PROTOCOL 0 // RECS80 >= 15000 ~100 bytes
#define IRSND_SUPPORT_RECS80EXT_PROTOCOL 0 // RECS80EXT >= 15000 ~100 bytes
#define IRSND_SUPPORT_THOMSON_PROTOCOL 0 // Thomson >= 10000 ~250 bytes
#define IRSND_SUPPORT_NIKON_PROTOCOL 0 // NIKON >= 10000 ~150 bytes
#define IRSND_SUPPORT_NETBOX_PROTOCOL 0 // Netbox keyboard >= 10000 DON'T CHANGE, NOT SUPPORTED YET!
#define IRSND_SUPPORT_FDC_PROTOCOL 0 // FDC IR keyboard >= 10000 (better 15000) ~150 bytes
#define IRSND_SUPPORT_RCCAR_PROTOCOL 0 // RC CAR >= 10000 (better 15000) ~150 bytes
#define IRSND_SUPPORT_ROOMBA_PROTOCOL 0 // iRobot Roomba >= 10000 ~150 bytes
#define IRSND_SUPPORT_RUWIDO_PROTOCOL 0 // RUWIDO, T-Home >= 15000 ~250 bytes
#define IRSND_SUPPORT_A1TVBOX_PROTOCOL 0 // A1 TV BOX >= 15000 (better 20000) ~200 bytes
#define IRSND_SUPPORT_LEGO_PROTOCOL 0 // LEGO Power RC >= 20000 ~150 bytes
</syntaxhighlight>

Mit Setzen auf 0 wird das Protokoll deaktiviert, mit Setzen auf 1 wird es aktiviert. Die deaktivierten Protokolle werden dann nicht mitübersetzt. Das spart Speicherplatz im Flash, siehe Angaben in obigen Kommentaren. Wenn man unbedingt Speicherplatz sparen muss, gelten natürlich hier dieselben Tipps wie für IRMP.

Um das [[IRMP#APPLE|APPLE]]-Protokoll zu unterstützen, ist IRSND_SUPPORT_NEC_PROTOCOL auf 1 zu setzen, da es sich hier lediglich um einen Spezialfall vom [[IRMP#NEC_+_extended_NEC|NEC]]-Protokoll handelt.

==== IRSND_OCx ====

Für das Senden der IR-Signale benötigt [[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|IRSND]] einen PWM-fähigen Output-Pin, da das Signal moduliert werden muss. Möglich sind eine der folgenden Einstellungen:

<syntaxhighlight lang="c">
#define IRSND_OCx IRSND_OC2 // OC2 on ATmegas supporting OC2, e.g. ATmega8
#define IRSND_OCx IRSND_OC2A // OC2A on ATmegas supporting OC2A, e.g. ATmega88
#define IRSND_OCx IRSND_OC2B // OC2B on ATmegas supporting OC2B, e.g. ATmega88
#define IRSND_OCx IRSND_OC0 // OC0 on ATmegas supporting OC0, e.g. ATmega162
#define IRSND_OCx IRSND_OC0A // OC0A on ATmegas/ATtinys supporting OC0A, e.g. ATtiny84, ATtiny85
#define IRSND_OCx IRSND_OC0B // OC0B on ATmegas/ATtinys supporting OC0B, e.g. ATtiny84, ATtiny85
</syntaxhighlight>

Standardwert:
<syntaxhighlight lang="c">
#define IRSND_OCx IRSND_OC2B
</syntaxhighlight>

Für die PIC- und STM32-µCs sind entsprechende Werte anzupassen, siehe Kommentare in [http://www.mikrocontroller.net/svnbrowser/irmp/irsndconfig.h?view=markup irsndconfig.h].

==== IRSND_USE_CALLBACK ====

Standardwert:
<syntaxhighlight lang="c">
#define IRSND_USE_CALLBACK 0 // flag: 0 = don't use callbacks, 1 = use callbacks, default is 0
</syntaxhighlight>

Wenn man Callbacks einschaltet, wird bei jeder Änderung des Signals (IR-Modulation ein/aus) eine Callback-Funktion aufgerufen. Dies kann zum Beispiel dafür verwendet werden, ein unmoduliertes Signal an einem weiteren Pin auszugeben.

Hier ein Beispiel:

<syntaxhighlight lang="c">
#define LED_PORT PORTD // LED at PD6
#define LED_DDR DDRD
#define LED_PIN 6

/*-----------------------------------------------------------------------------------------------------------------------
* Called (back) from IRSND module
* This example switches a LED (which is connected to Vcc)
*-----------------------------------------------------------------------------------------------------------------------
*/
void
led_callback (uint8_t on)
{
if (on)
{
LED_PORT &= ~(1 << LED_PIN);
}
else
{
LED_PORT |= (1 << LED_PIN);
}
}

int
main ()
{
...
LED_DDR |= (1 << LED_PIN); // LED pin to output
LED_PORT |= (1 << LED_PIN); // switch LED off (active low)
irsnd_init ();
irsnd_set_callback_ptr (led_callback);
sei ();
...
}

</syntaxhighlight>

=== Anwendung von IRSND ===

[[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|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

<syntaxhighlight lang="c">
irmp_data_p->protocol
irmp_data_p->address
irmp_data_p->command
irmp_data_p->flags
</syntaxhighlight>

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

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

irmp_data_p->flags = 0: keine Wiederholung
irmp_data_p->flags = 1: 1 Wiederholung
irmp_data_p->flags = 2: 2 Wiederholungen
usw.

'''Zu beachten: Es ist unbedingt darauf zu achten, dass irmp_data_p->flags vor dem Aufruf von irsnd_send_data() einen definierten Wert hat!'''

Hier ein Beispiel:

<syntaxhighlight lang="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, FALSE); // versende ohne Prüfung und ohne Warten
</syntaxhighlight>

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 [[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|IRSND]] gerade "busy" ist oder nicht:

<syntaxhighlight lang="c">
while (irsnd_is_busy ())
{
; // selber warten oder was anderes tun...
}
(void) irsnd_send_data (&irmp_data, FALSE); // versende ohne Prüfung und ohne Warten
</syntaxhighlight>

Wird irsnd_send_data() mit dem 2. Argument TRUE aufgerufen, kommt diese Funktion erst zurück, wenn der Frame komplett ausgesendet wurde.

Im Beispiel-Source irsndmain.c findet man neben der Verwendung von irsnd_send_data() auch den [[AVR-GCC-Tutorial/Die_Timer_und_Zähler_des_AVR|Timer]]-Aufruf:

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

=== Paralleles Betreiben von IRMP und IRSND ===

Möchte man [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] und [[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|IRSND]] parallel verwenden (also als Sender und Empfänger) schreibt man die ISR folgendermaßen:

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

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 [[AVR-GCC-Tutorial/Die_Timer_und_Zähler_des_AVR|Timer]]-Initialisierungsroutine ist für [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] und [[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|IRSND]] dann natürlich dieselbe.

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

<syntaxhighlight lang="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);
}
}
}
</syntaxhighlight>

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 [http://www.mikrocontroller.net/svnbrowser/irmp/irmpprotocols.h?view=markup irmpprotocols.h]:

<syntaxhighlight lang="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 (NEC with 16 bits)
#define IRMP_RC6A_PROTOCOL 21 // RC6A, e.g. Kathrein, XBOX
#define IRMP_NIKON_PROTOCOL 22 // Nikon
#define IRMP_RUWIDO_PROTOCOL 23 // Ruwido, e.g. T-Home Mediareceiver
#define IRMP_IR60_PROTOCOL 24 // IR60 (SDA2008)
#define IRMP_KATHREIN_PROTOCOL 25 // Kathrein
#define IRMP_NETBOX_PROTOCOL 26 // Netbox keyboard (bitserial)
#define IRMP_NEC16_PROTOCOL 27 // NEC with 16 bits (incl. sync)
#define IRMP_NEC42_PROTOCOL 28 // NEC with 42 bits
#define IRMP_LEGO_PROTOCOL 29 // LEGO Power Functions RC
#define IRMP_THOMSON_PROTOCOL 30 // Thomson
#define IRMP_BOSE_PROTOCOL 31 // BOSE
#define IRMP_A1TVBOX_PROTOCOL 32 // A1 TV Box
#define IRMP_ORTEK_PROTOCOL 33 // ORTEK - Hama
#define IRMP_TELEFUNKEN_PROTOCOL 34 // Telefunken (1560)
#define IRMP_ROOMBA_PROTOCOL 35 // iRobot Roomba vacuum cleaner
#define IRMP_RCMM32_PROTOCOL 36 // Fujitsu-Siemens (Activy remote control)
#define IRMP_RCMM24_PROTOCOL 37 // Fujitsu-Siemens (Activy keyboard)
#define IRMP_RCMM12_PROTOCOL 38 // Fujitsu-Siemens (Activy keyboard)
#define IRMP_SPEAKER_PROTOCOL 39 // Another loudspeaker protocol, similar to Nubert
#define IRMP_LGAIR_PROTOCOL 40 // LG air conditioner
#define IRMP_SAMSUNG48_PROTOCOL 41 // air conditioner with SAMSUNG protocol (48 bits)
</syntaxhighlight>

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

== IRSND unter Linux und Windows ==

=== Übersetzen von IRSND ===

[http://www.mikrocontroller.net/svnbrowser/irmp/irsnd.c?view=markup 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:

make -f makefile.unx

=== Aufruf von IRSND ===

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 unter Windows ===

[[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|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#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] anschließend testen, ob das erzeugte Telegramm auch korrekt ist:

./irmp-15kHz < nec.txt

bzw. unter Windows:

irmp.exe < nec.txt

Das Ganze geht auch ohne Zwischendatei, nämlich:

./irsnd-15kHz 2 00FF 0001 | ./irmp-15kHz

bzw. unter Windows:

irsnd.exe 2 00FF 0001 | irmp.exe

[[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] gibt dann als Ergebnis folgendes aus:

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

[[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] konnte also aus dem von [[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|IRSND]] generierten Frame wieder das Protokoll 2, Adresse 0x00FF und Kommando 0x0001 decodieren.

Tatsächlich simuliert [[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|IRSND]] unter Linux/Windows immer das zweimalige Drücken einer Taste - mit einer Pause dazwischen. Als Egebnis erscheint daher:

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

Der Grund ist einfach: Damit kann man wunderbar testen, ob bei Protokollen mit Toggle-Bit dieses von [[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|IRSND]] auch korrekt behandelt wird:

./irsnd-15kHz 7 2 3 0 | ./irmp-15kHz
1100010000011 p= 7 (RC5), a=0x0002, c=0x0003, f=0x00 '''Erster Tastendruck'''
1000010000011 p= 7 (RC5), a=0x0002, c=0x0003, f=0x00 '''Zweiter Tastendruck'''
^
Toggle-Bit

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 ==
[[Datei:Pulse-Distance.png|miniatur|Pulse Distance Coding]]

=== Pulse Distance Protokolle ===
''' '''
==== NEC + extended NEC ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''[[IRMP#NEC-Protokoll|NEC + extended NEC]]''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| 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 (4500µ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 ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''[[IRMP#NEC16-Protokoll (JVC)|JVC]]''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| 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 ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''NEC16''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| 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 ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''NEC42''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| 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 || nach 110ms (ab Start-Bit), 9000µs Puls, 2250µs Pause, 560µs Puls
|-
| Bit-Order || LSB first
|-
|}

==== ACP24 ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''[[IRMP#ACP24-Protokoll|ACP24]]''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz?
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 70 Daten-Bits + 1 Stop-Bit
|-
| Daten || 0 Adress-Bits + 70 Kommando-Bits
|-
| Start-Bit || 390µs Puls, 950µs Pause
|-
| 0-Bit || 390µs Puls, 950µs Pause
|-
| 1-Bit || 390µs Puls, 13000µs Pause
|-
| Stop-Bit || 390µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || unbekannt
|-
| Bit-Order || MSB first
|-
|}

==== LGAIR ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''[[IRMP#LGAIR-Protokoll|LGAIR]]''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 28 Daten-Bits + 1 Stop-Bit
|-
| Daten || 8 Adress-Bits + 16 Kommando-Bits + 4 Checksum-Bits
|-
| Start-Bit || 9000µs Puls, 4500µs Pause (identisch mit [[IRMP#NEC_.2B_extended_NEC|NEC]])
|-
| 0-Bit || 560µs Puls, 560µs Pause (identisch mit [[IRMP#NEC_.2B_extended_NEC|NEC]])
|-
| 1-Bit || 560µs Puls, 1690µs Pause (identisch mit [[IRMP#NEC_.2B_extended_NEC|NEC]])
|-
| Stop-Bit || 560µs Puls (identisch mit [[IRMP#NEC_.2B_extended_NEC|NEC]])
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || unbekannt
|-
| Bit-Order || MSB first ('''abweichend''' zu [[IRMP#NEC_.2B_extended_NEC|NEC]])
|-
|}

==== SAMSUNG ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''[[IRMP#SAMSUNG-Protokoll|SAMSUNG]]''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| 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, 550µs Pause
|-
| 1-Bit || 550µs Puls, 1650µ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 ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''SAMSUNG32''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 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, 550µs Pause
|-
| 1-Bit || 550µs Puls, 1650µs Pause
|-
| Stop-Bit || 550µs Puls
|-
| Wiederholung || eine nach ca. 47 msec
|-
| Tasten-Wiederholung || dritter, fünfter, siebter usw. identischer Frame
|-
| Bit-Order || LSB first
|-
|}

==== SAMSUNG48 ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''SAMSUNG48''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 48 Daten-Bits + 1 Stop-Bit
|-
| Daten || 16 Adress-Bits + 32 Kommando-Bits
|-
| Kommando || 8 Bits + 8 invertierte Bits + 8 Bits + 8 invertierte Bits
|-
| Start-Bit || 4500µs Puls, 4500µs Pause
|-
| 0-Bit || 550µs Puls, 550µs Pause
|-
| 1-Bit || 550µs Puls, 1650µs Pause
|-
| Stop-Bit || 550µs Puls
|-
| Wiederholung || eine nach ca. 5 msec
|-
| Tasten-Wiederholung || dritter, fünfter, siebter usw. identischer Frame
|-
| Bit-Order || LSB first
|-
|}

==== MATSUSHITA ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''[[IRMP#MATSUHITA-Protokoll|MATSUSHITA]]''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 36 kHz
|-
| Kodierung || Pulse Distance, Timing identisch mit [[IRMP#TECHNICS|TECHNICS]]
|-
| 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 nach 40ms Pause
|-
| Bit-Order || LSB first?
|-
|}

==== TECHNICS ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''TECHNICS''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 36 kHz?
|-
| Kodierung || Pulse Distance, Timing identisch mit [[IRMP#MATSUSHITA|MATSUSHITA]]
|-
| Frame || 1 Start-Bit + 22 Daten-Bits + 1 Stop-Bit
|-
| Daten || 11 Kommando-Bits + 11 invertierte Kommando-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 nach 40ms Pause
|-
| Bit-Order || LSB first?
|-
|}

==== KASEIKYO ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''[[IRMP#KASEIKYO-Protokoll (auch "Japan-Protokoll")|KASEIKYO]]''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| 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 Pause
|-
| Tasten-Wiederholung || N-fache Wiederholung des 1. Original-Frames nach ca. 80ms Pause
|-
| Bit-Order || LSB first?
|-
|}

==== RECS80 ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''[[IRMP#RECS80- und RECS80-Extended-Protokoll|RECS80]]''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| 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 ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''[[IRMP#RECS80- und RECS80-Extended-Protokoll|RECS80EXT]]''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| 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 ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''[[IRMP#Denon-Protokoll|DENON]]''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz (in der Praxis, lt. Dokumentation: 32 kHz)
|-
| Kodierung || Pulse Distance
|-
| Frame || 0 Start-Bits + 15 Daten-Bits + 1 Stop-Bit
|-
| Daten || 5 Address-Bits + 10 Kommando-Bits
|-
| Kommando || 6 Datenbits + 2 Extension Bits + 2 Data Construction Bits (normal: 00, invertiert: 11)
|-
| 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 || Nach 65ms Wiederholung des Frames mit invertieren Kommando-Bits (Data Construction Bits = 11)
|-
| Tasten-Wiederholung || N-fache Wiederholung der beiden Original-Frames nach 65ms
|-
| Bit-Order || MSB first
|-
|}

==== APPLE ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''APPLE''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| 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 [[IRMP#NEC_+_extended_NEC|NEC]]
|-
| 0-Bit || siehe [[IRMP#NEC_+_extended_NEC|NEC]]
|-
| 1-Bit || siehe [[IRMP#NEC_+_extended_NEC|NEC]]
|-
| Stop-Bit || siehe [[IRMP#NEC_+_extended_NEC|NEC]]
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || N-fache Wiederholung des Original-Frames innerhalb von 100ms
|-
| Bit-Order || LSB first
|-
|}

==== BOSE ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''BOSE''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz?
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 16 Daten-Bits + 1 Stop-Bit
|-
| Daten || 0 Adress-Bits + 8 Kommando-Bits + 8 invertierte Kommando-Bits
|-
| Start-Bit || 1060µs Puls, 1425µs Pause
|-
| 0-Bit || 550µs Puls, 437µs Pause
|-
| 1-Bit || 550µs Puls, 1425µs Pause
|-
| Stop-Bit || 550µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || noch ungeklärt
|-
| Bit-Order || LSB first
|-
|}

==== B&O ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''[[IRMP#Bang & Olufsen|B&O]]''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| 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 ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''FDC''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| 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
|-
|}

==== NIKON ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''NIKON''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz?
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 2 Daten-Bits + 1 Stop-Bit
|-
| Daten || 2 Kommando-Bits
|-
| Start-Bit || 2200µs Puls, 27100µs Pause
|-
| 0-Bit || 500µs Puls, 1500µs Pause
|-
| 1-Bit || 500µs Puls, 3500µs Pause
|-
| Stop-Bit || 500µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || unbekannt
|-
| Bit-Order || MSB first
|-
|}

==== PENTAX ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''PENTAX''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 6 Daten-Bits + 1 Stop-Bit
|-
| Daten || 6 Kommando-Bits
|-
| Start-Bit || 2200µs Puls, 27100µs Pause
|-
| 0-Bit || 1000µs Puls, 1000µs Pause
|-
| 1-Bit || 1000µs Puls, 3000µs Pause
|-
| Stop-Bit || 1000µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || unbekannt
|-
| Bit-Order || MSB first
|-
|}

==== KATHREIN ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''KATHREIN''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz?
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 11 Daten-Bits + 1 Stop-Bit
|-
| Daten || 4 Adress-Bits + 7 Kommando-Bits
|-
| Start-Bit || 210µs Puls, 6218µs Pause
|-
| 0-Bit || 210µs Puls, 1400µs Pause
|-
| 1-Bit || 210µs Puls, 3000µs Pause
|-
| Stop-Bit || 210µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || nach 35ms?
|-
| Bit-Order || MSB first
|-
|}

==== LEGO ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''[[IRMP#LEGO Power Functions RC|LEGO]]''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz?
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 16 Daten-Bits + 1 Stop-Bit
|-
| Daten || 16 Kommando-Bits
|-
| Start-Bit || 158µs Puls, 1026µs Pause
|-
| 0-Bit || 158µs Puls, 263µs Pause
|-
| 1-Bit || 158µs Puls, 553µs Pause
|-
| Stop-Bit || 158µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || unbekannt
|-
| Bit-Order || MSB first
|-
|}

==== THOMSON ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''THOMSON''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 33 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 0 Start-Bits + 12 Daten-Bits + 1 Stop-Bit
|-
| Daten || 4 Adress-Bits + 1 Toggle-Bit + 7 Kommando-Bits
|-
| 0-Bit || 550µs Puls, 2000µs Pause
|-
| 1-Bit || 550µs Puls, 4500µs Pause
|-
| Stop-Bit || 550µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || Framewiederholung nach 35ms
|-
| Bit-Order || vermutlich MSB first
|-
|}

==== TELEFUNKEN ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''TELEFUNKEN''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz?
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 15 Daten-Bits + 1 Stop-Bit
|-
| Daten || 0 Adress-Bits + 15 Kommando-Bits
|-
| Start-Bit || 600µs Puls, 1500µs Pause
|-
| 0-Bit || 600µs Puls, 600µs Pause
|-
| 1-Bit || 600µs Puls, 1500µs Pause
|-
| Stop-Bit || 600µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || unbekannt
|-
| Bit-Order || vermutlich MSB first
|-
|}

==== RCCAR ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''RCCAR''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz?
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 13 Daten-Bits + 1 Stop-Bit
|-
| Daten || 13 Kommando-Bits
|-
| 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 || nach 40ms?
|-
| Bit-Order || LSB first
|-
|}

==== RCMM ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''[[IRMP#RCMM-Protokoll|RCMM]]''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 36 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame RCMM32 || 1 Start-Bit + 32 Daten-Bits + 1 Stop-Bit
|-
| Frame RCMM24 || 1 Start-Bit + 24 Daten-Bits + 1 Stop-Bit
|-
| Frame RCMM12 || 1 Start-Bit + 12 Daten-Bits + 1 Stop-Bit
|-
| Daten RCMM32 || 16 Adress-Bits (= 4 Mode-Bits + 12 Device-Bits) + 1 Toggle-Bit + 15 Kommando-Bits
|-
| Daten RCMM24 || 16 Adress-Bits (= 4 Mode-Bits + 12 Device-Bits) + 1 Toggle-Bit + 7 Kommando-Bits
|-
| Daten RCMM12 || 4 Adress-Bits (= 2 Mode-Bits + 2 Device-Bits) + 8 Kommando-Bits
|-
| Start-Bit || 500µs Puls, 220µs Pause
|-
| 00-Bits || 230µs Puls, 220µs Pause
|-
| 01-Bits || 230µs Puls, 380µs Pause
|-
| 10-Bits || 230µs Puls, 550µs Pause
|-
| 11-Bits || 230µs Puls, 720µs Pause
|-
| Stop-Bit || 230µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || nach 80ms
|-
| Bit-Order || LSB first
|-
|}

[[Datei:Pulse-Width.png|miniatur|Pulse Width Coding]]

=== Pulse Width Protokolle ===
''' '''
==== SIRCS ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''[[IRMP#SIRCS-Protokoll|SIRCS]]''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
|Frequenz ||40 kHz
|-
| Kodierung || Pulse Width
|-
| 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
|-
|}

[[Datei:Pulse-Distance-Width.png|miniatur|Pulse Distance Width Coding]]

=== Pulse Distance Width Protokolle ===
''' '''
==== NUBERT ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''NUBERT''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 36 kHz?
|-
| Kodierung || Pulse Distance Width
|-
| 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?
|-
|}

==== FAN ====

Das Protokoll ist sehr ähnlich zu [[IRMP#NUBERT|NUBERT]], jedoch wird nur ein Frame gesandt. Außerdem werden 11 statt 10 Datenbits verwendet und kein Stop-Bit versandt. Die Pause zwischen Frame-Wiederholungen ist wesentlich geringer.

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''FAN ''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 36 kHz
|-
| Kodierung || Pulse Distance Width
|-
| Frame || 1 Start-Bit + 11 Daten-Bits + 0 Stop-Bits
|-
| Daten || 0 Adress-Bits + 11 Kommando-Bits
|-
| Start-Bit || 1280µs Puls, 380µs Pause
|-
| 0-Bit || 380µs Puls, 1280µs Pause
|-
| 1-Bit || 1280µs Puls, 380µs Pause
|-
| Stop-Bit || 500µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || nach 6,6ms Pause
|-
| Bit-Order || MSB first
|-
|}

==== SPEAKER ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''SPEAKER''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz?
|-
| Kodierung || Pulse Distance Width
|-
| Frame || 1 Start-Bit + 10 Daten-Bits + 1 Stop-Bit
|-
| Daten || 0 Adress-Bits + 10 Kommando-Bits ?
|-
| Start-Bit || 440µs Puls, 1250µs Pause
|-
| 0-Bit || 440µs Puls, 1250µs Pause
|-
| 1-Bit || 1250µs Puls, 440µs Pause
|-
| Stop-Bit || 440µs Puls
|-
| Wiederholung || einmalig nach ca. 38ms
|-
| Tasten-Wiederholung || dritter, fünfter, siebter usw. identischer Frame
|-
| Bit-Order || MSB first?
|-
|}

==== ROOMBA ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''ROOMBA''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz?
|-
| Kodierung || Pulse Distance Width
|-
| Frame || 1 Start-Bit + 7 Daten-Bits + 0 Stop-Bit
|-
| Daten || 0 Adress-Bits + 7 Kommando-Bits
|-
| Start-Bit || 2790µs Puls, 930µs Pause
|-
| 0-Bit || 930µs Puls, 2790µs Pause
|-
| 1-Bit || 2790µs Puls, 930µs Pause
|-
| Stop-Bit || kein Stop-Bit
|-
| Wiederholung || dreimalig nach jeweils 18ms?
|-
| Tasten-Wiederholung || noch unbekannt
|-
| Bit-Order || MSB first
|-
|}

[[Datei:Biphase-Coding.png|miniatur|Biphase Coding]]

=== Biphase Protokolle ===
''' '''
==== RC5 + RC5X ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''[[IRMP#RC5- und RC5x-Protokoll|RC5 + RC5X]]''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 36 kHz
|-
| Kodierung || Biphase (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
|-
|}

==== S100 ====

Ähnlich zu RC5x, aber 14 statt 13 Daten-Bits und 56kHz Modulation

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''S100''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 56 kHz
|-
| Kodierung || Biphase (Manchester)
|-
| Frame || 1 Start-Bit + 14 Daten-Bits + 0 Stop-Bit
|-
| Daten || 1 invertiertes Kommando-Bit + 1 Toggle-Bit + 5 Adress-Bits + 7 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 ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''[[IRMP#RC6 und RC6A-Protokoll|RC6 + RC6A]]''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 36 kHz
|-
| Kodierung || Biphase (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
|-
| Daten RC6A Pace (Sky) || "1" + 3 Mode-Bits ("110") + 1 Toggle-Bit(UNUSED "0") + 16 Bit + 1 Toggle(!) + 15 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 ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''[[IRMP#Grundig-Protokoll|GRUNDIG + NOKIA]]''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz (?)
|-
| Kodierung || Biphase (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 + 0 Adress-Bits
|-
| Daten Nokia || 8 Kommando-Bits + 8 Adress-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
|-
|}

==== IR60 (SDA2008) ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''[[IRMP#IR60 (SDA2008 bzw. MC14497P)|IR60 (SDA2008)]]''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 30 kHz
|-
| Kodierung || Biphase (Manchester)
|-
| Start Frame || 1 Start-Bit + 101111 + 0 Stop-Bits + 22ms Pause
|-
| Daten Frame || 1 Start-Bit + 7 Daten-Bits + 0 Stop-Bits
|-
| Daten || 0 Adress-Bits + 7 Kommando-Bits
|-
| Start-Bit || 528µs Puls, 2639µ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 ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''SIEMENS + RUWIDO''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 36 kHz? (Merlin-Tastatur mit Ruwido-Protokoll: 56 kHz)
|-
| Kodierung || Biphase (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 Kommando-Bits + 1 invertiertes Bit (letztes Bit davor nochmal invertiert)
|-
| Daten Ruwido || 9 Adress-Bits + 7 Kommando-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
|-
|}

==== A1TVBOX ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''A1TVBOX''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz?
|-
| Kodierung || Biphase (Manchester) asymmetrisch
|-
| Frame || 2 Start-Bits + 16 Daten-Bits + 0 Stop-Bits
|-
| Daten || 8 Adress-Bits + 8 Kommando-Bits
|-
| Start-Bits || "10", also 250µs Puls, 150µs + 150µs Pause, 250µs Puls
|-
| 0-Bit || 150µs Pause, 250µs Puls
|-
| 1-Bit || 250µs Puls, 150µs Pause
|-
| Stop-Bit || kein Stop-Bit
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || unbekannt
|-
| Bit-Order || MSB first
|-
|}

==== MERLIN ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''MERLIN''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz?
|-
| Kodierung || Biphase (Manchester) asymmetrisch
|-
| Frame || 2 Start-Bits + 18 Daten-Bits + 0 Stop-Bits
|-
| Daten || 8 Adress-Bits + 10 Kommando-Bits
|-
| Start-Bits || "10", also 210µs Puls, 210µs + 210µs Pause, 210µs Puls
|-
| 0-Bit || 210µs Pause, 210µs Puls
|-
| 1-Bit || 210µs Puls, 210µs Pause
|-
| Stop-Bit || kein Stop-Bit
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || unbekannt
|-
| Bit-Order || MSB first
|-
|}

==== ORTEK ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''ORTEK''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz?
|-
| Kodierung || Biphase (Manchester) symmetrisch
|-
| Frame || 2 Start-Bits + 18 Daten-Bits + 0 Stop-Bits
|-
| Daten || 6 Adress-Bits + 2 Spezial-Bits + 6 Kommando-Bits + 4 Spezial-Bits
|-
| Start-Bit || 2000µs Puls, 1000µs Pause
|-
| 0-Bit || 500µs Pause, 500µs Puls
|-
| 1-Bit || 500µs Puls, 500µs Pause
|-
| Stop-Bit || kein Stop-Bit
|-
| Wiederholung || 2 zusätzliche Frames mit gesetzten Spezial-Bits
|-
| Tasten-Wiederholung || N-fache Wiederholung des 2. Frames
|-
| Bit-Order || MSB first
|-
|}

=== Pulse Position Protokolle ===

==== NETBOX ====

{| {{Tabelle}}
|- style="background-color:#eeeeee"
! '''NETBOX''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz?
|-
| Kodierung || Pulse Position
|-
| 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 in 2.9.x:

Version 2.9.5:

* 20.09.2015: '''Neues Protokoll''': [[IRMP#TECHNICS|TECHNICS]]

Version 2.9.4:

* 15.06.2015: '''Neues Protokoll''': [[IRMP#ACP24|ACP24]]

Version 2.9.2:

* 29.05.2015: '''Neues Protokoll''': [[IRMP#S100|S100]]
* 29.05.2015: Kleinere Korrekturen

Version 2.9.1:

* 28.05.2015: Logging für XMega hinzugefügt
* 28.05.2015: Timing-Korrekturen für FAN-Protokoll

Version 2.9.0:

* 27.05.2015: '''Neues Protokoll''': [[IRMP#MERLIN|MERLIN]]
* 27.05.2015: '''Neues Protokoll''': [[IRMP#FAN|FAN]]

Ältere Versionen:

* 18.05.2015: F_CPU Macro für STM32L1XX hinzugefügt
* 18.05.2015: Korrekturen zur XMega-Portierung
* 23.04.2015: '''Neues Protokoll''': [[IRMP#PENTAX|PENTAX]]
* 23.04.2015: Portierung auf AVR XMega
* 19.09.2014: Kleineren Bug behoben: Fehlendes Newline vor #else eingefügt
* 18.09.2014: Logging für ARM STM32F10X hinzugefügt
* 17.09.2014: PROGMEM-Zugriff für Array irmp_protocol_names[] korrigiert.
* 15.09.2014: Timing-Toleranzen für [[IRMP#KASEIKYO|KASEIKYO]]-Protokoll vergrößert
* 15.09.2014: Wechsel von irmp_protocol_names auf PROGMEM, zusätzliche UART Routinen in main.c
* 21.07.2014: Portierung auf PIC 12F1840
* 09.07.2014: '''Neues Protokoll''': [[IRMP#SAMSUNG48|SAMSUNG48]]
* 09.07.2014: Kleine Syntaxfehlerkorrektur
* 01.07.2014: Logging für ARM_STM32F4XX eingebaut
* 01.07.214: IRMP port für PIC XC8 compiler, Variadic Macros herausgenommen wg. dummen XC8-Compiler :-(
* 05.06.2014: '''Neues Protokoll''': [[IRMP#LGAIR|LGAIR]]
* 30.05.2014: '''Neues Protokoll''': [[IRMP#SPEAKER|SPEAKER]]
* 30.05.2014: Timings für [[IRMP#SAMSUNG|SAMSUNG]]-Protokolle optimiert
* 20.02.2014: Fehlerhaftes Decodieren des [[IRMP#SIEMENS_+_RUWIDO|SIEMENS]]-Protokolls korrigiert
* 19.02.2014: '''Neue Protokolle''': [[IRMP#RCMM|RCMM32, RCMM24 und RCMM12]]
* 17.09.2014: Timing für [[IRMP#ROOMBA|ROOMBA]] verbessert
* 09.04.2013: '''Neues Protokoll''': [[IRMP#ROOMBA|ROOMBA]]
* 09.04.2013: Verbesserte Frame-Erkennung für [[IRMP#ORTEK|ORTEK (Hama)]]
* 19.03.2013: '''Neues Protokoll''': [[IRMP#ORTEK|ORTEK (Hama)]]
* 19.03.2013: '''Neues Protokoll''': [[IRMP#TELEFUNKEN|TELEFUNKEN]]
* 12.03.2013: Geänderte Timing-Toleranzen für [[IRMP#RECS80|RECS80]]- und [[IRMP#RECS80EXT|RECS80EXT]]-Protokoll
* 21.01.2013: Korrekturen Erkennung des Wiederholungsframes beim [[IRMP#DENON|DENON]]-Protokoll
* 17.01.2013: Korrekturen Frame-Erkennung beim [[IRMP#DENON|DENON]]-Protokoll
* 11.12.2012: '''Neues Protokoll''': [[IRMP#A1TVBOX|A1TVBOX]]
* 07.12.2012: Verbesserte Erkennung von [[IRMP#DENON|DENON]]-Wiederholungsframes
* 19.11.2012: Portierung auf Stellaris LM4F120 Launchpad von TI (ARM Cortex M4)
* 06.11.2012: Korrektur [[IRMP#DENON|DENON]]-Frame-Erkennung
* 26.10.2012: Einige Timer-Korrekturen, Anpassungen an Arduino
* 11.07.2012: '''Neues Protokoll''': [[IRMP#BOSE|BOSE]]
* 18.06.2012: Unterstützung für ATtiny87/167 hinzugefügt
* 05.06.2012: Kleinere Korrekturen Portierung auf ARM STM32
* 05.06.2012: Include-Korrektur in [http://www.mikrocontroller.net/svnbrowser/irmp/irmpextlog.c?view=markup irmpextlog.c]
* 05.06.2012: Bugfix, wenn nur [[IRMP#NEC_+_extended_NEC|NEC]] und [[IRMP#NEC42|NEC42]] aktiviert
* 23.05.2012: Portierung auf ARM STM32
* 23.05.2012: Bugfix Frame-Erkennung beim [[IRMP#DENON|DENON]]-Protokoll
* 27.02.2012: Bug in IR60-Decoder behoben
* 27.02.2012: Bug in CRC-Berechnung von [[IRMP#KASEIKYO|KASEIKYO]]-Frames behoben
* 27.02.2012: Portierung auf C18 Compiler für PIC-Mikroprozessoren
* 13.02.2012: Bugfix: oberstes Bit in Adresse falsch bei [[IRMP#NEC_+_extended_NEC|NEC]]-Protokoll, wenn auch [[IRMP#NEC42|NEC42]]-Protokoll eingeschaltet ist.
* 13.02.2012: Timing von [[IRMP#SAMSUNG|SAMSUNG]]- und [[IRMP#SAMSUNG32|SAMSUNG32]]-Protokoll korrigiert
* 13.02.2012: [[IRMP#KASEIKYO|KASEIKYO]]: Genre2-Bits werden nun im oberen Nibble von flags gespeichert.
* 20.09.2011: '''Neues Protokoll''': [[IRMP#KATHREIN|KATHREIN]]
* 20.09.2011: '''Neues Protokoll''': [[IRMP#SIEMENS_+_RUWIDO|RUWIDO]]
* 20.09.2011: '''Neues Protokoll''': [[IRMP#THOMSON|THOMSON]]
* 20.09.2011: '''Neues Protokoll''': [[IRMP#IR60 (SDA2008)|IR60 (SDA2008)]]
* 20.09.2011: '''Neues Protokoll''': [[IRMP#LEGO|LEGO]]
* 20.09.2011: '''Neues Protokoll''': [[IRMP#NEC16|NEC16]]
* 20.09.2011: '''Neues Protokoll''': [[IRMP#NEC42|NEC42]]
* 20.09.2011: '''Neues Protokoll''': [[IRMP#NETBOX|NETBOX]]
* 20.09.2011: Portierung auf ATtiny84 und ATtiny85
* 20.09.2011: Verbesserung von Tastenwiederholungen bei [[IRMP#RC5_+_RC5X|RC5]]
* 20.09.2011: Verbessertes Decodieren von [[IRMP#Biphase|Biphase]]-Protokollen
* 20.09.2011: Korrekturen am [[IRMP#RECS80|RECS80]]-Decoder
* 20.09.2011: Korrekturen beim Erkennen von zusätzlichen Bits im SIRCS-Protocol
* 18.01.2011: Korrekturen für [[IRMP#SIEMENS_+_RUWIDO|SIEMENS]]-Protokoll
* 18.01.2011: '''Neues Protokoll''': [[IRMP#NIKON|NIKON]]
* 18.01.2011: Speichern der zusätzlichen Bits (>12) im [[IRMP#SIRCS|SIRCS]]-Protokoll in der Adresse
* 18.01.2011: Timing-Korrekturen für [[IRMP#DENON|DENON]]-Protokoll

* 04.09.2010: Bugfix für F_INTERRUPTS >= 16000

* 02.09.2010: '''Neues Protokoll''': [[IRMP#RC6_+_RC6A|RC6A]]

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

* 01.07.2010: Bugfix: Einführen eines Timeouts für [[IRMP#NEC_+_extended_NEC|NEC]]-Repetition-Frames, um "Geisterkommandos" zu verhindern.

* 26.06.2010: Bugfix: Deaktivieren von [[IRMP#RECS80|RECS80]], [[IRMP#RECS80EXT|RECS80EXT]] & [[IRMP#SIEMENS_+_RUWIDO|SIEMENS]] bei geringer Interrupt-Rate

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

* 09.06.2010: '''Neues Protokoll''': [[IRMP#FDC|FDC]] (IR-keyboard)
* 09.06.2010: Timing für [[IRMP#DENON|DENON]]-Protokoll korrigiert

* 02.06.2010: '''Neues Protokoll''': [[IRMP#SIEMENS_+_RUWIDO|SIEMENS]] (Gigaset)

* 26.05.2010: '''Neues Protokoll''': [[IRMP#GRUNDIG_+_NOKIA|NOKIA]]
* 26.05.2010: Bugfix Auswertung von langen Tastendrücken bei [[IRMP#GRUNDIG_+_NOKIA|GRUNDIG]]-Protokoll

* 17.05.2010: Bugfix [[IRMP#SAMSUNG32|SAMSUNG32]]-Protokoll: Kommando-Bit-Maske korrigiert

* 16.05.2010: '''Neues Protokoll''': [[IRMP#GRUNDIG_+_NOKIA|GRUNDIG]]
* 16.05.2010: Behandlung von automatischen Frame-Wiederholungen beim [[IRMP#SIRCS|SIRCS]]-, [[IRMP#SAMSUNG32|SAMSUNG32]]- und [[IRMP#NUBERT|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''': [[IRMP#B&O|Bang & Olufsen]]

* 29.03.2010: Bugfix beim Erkennen von mehrfachen [[IRMP#NEC_+_extended_NEC|NEC]]-Repetition-Frames
* 29.03.2010: Konfiguration in [http://www.mikrocontroller.net/svnbrowser/irmp/irmpconfig.h?view=markup irmpconfig.h] ausgelagert
* 29.03.2010: Einführung einer Programmversion in README.txt: Version 1.0

* 17.03.2010: '''Neues Protokoll''': [[IRMP#NUBERT|NUBERT]]

* 16.03.2010: Korrektur der RECS80-Startbit-Timings
* 16.03.2010: '''Neues Protokoll''': [[IRMP#RECS80EXT|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 [[IRMP#RC5_+_RC5X|RC5]]-Frame

* 05.03.2010: '''Neues Protokoll''': [[IRMP#APPLE|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''': [[IRMP#SAMSUNG32|SAMSUNG32]] (Mix aus [[IRMP#SAMSUNG|SAMSUNG]] & [[IRMP#NEC_+_extended_NEC|NEC]]-Protokoll)
* 04.03.2010: Änderung der [[IRMP#SIRCS|SIRCS]]- und [[IRMP#KASEIKYO|KASEIKYO]]-Toleranzen

* 02.03.2010: [[IRMP#SIRCS|SIRCS]]: Korrekte Erkennung und Unterdrückung von automatischen Frame-Wiederholungen
* 02.03.2010: [[IRMP#SIRCS|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 [[IRMP#DENON|DENON]]-Protokoll: Wiederholungsframe grundsätzlich invertiert

* 19.02.2010: Erkennung von [[IRMP#NEC_+_extended_NEC|NEC]]-Protokoll-Varianten, z. B. [[IRMP#APPLE|APPLE]]-Fernbedienung
* 19.02.2010: Erkennung von [[IRMP#RC6_+_RC6A|RC6]]- und [[IRMP#DENON|DENON]]-Protokoll
* 19.02.2010: Verbesserung des [[IRMP#RC5_+_RC5X|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 [[IRMP#NEC_+_extended_NEC|NEC]]-Wiederholungssequenz

* 12.02.2010: [[IRMP#RC5_+_RC5X|RC5]]-Protokoll-Decoder hinzugefügt

* 05.02.2010: Konflikt zwischen [[IRMP#SAMSUNG|SAMSUNG]]- und [[IRMP#MATSUSHITA|MATSUSHITA]]-Protokoll beseitigt

* 07.01.2010: Erste Version

== Software-Historie IRSND ==

Version 2.9.5:

* 20.09.2015: '''Neues Protokoll''': [[IRMP#TECHNICS|TECHNICS]]

Version 2.9.4:

* 15.06.2015: '''Neues Protokoll''': [[IRMP#ACP24|ACP24]]

Änderungen IRSND in 2.9.x:

Version 2.9.1:

* 28.05.2015: Timing-Korrekturen für FAN-Protokoll

Version 2.9.0:

* 27.05.2015: '''Neues Protokoll''': [[IRMP#MERLIN|MERLIN]]
* 27.05.2015: '''Neues Protokoll''': [[IRMP#FAN|FAN]]

Ältere Versionen:

* 18.05.2015: F_CPU Macro für STM32L1XX hinzugefügt
* 07.05.2015: Korrekturen zur XMega-Portierung
* 23.04.2015: '''Neues Protokoll''': [[IRMP#PENTAX|PENTAX]]
* 23.04.2015: Portierung auf AVR XMega
* 10.07.2014: Einige GPIO Änderungen für STM32F10x (in IRSND).
* 10.07.2014: '''Neues Protokoll''': [[IRMP#SAMSUNG48|SAMSUNG48]]
* 23.06.2014: '''Neues Protokoll''': [[IRMP#LGAIR|LGAIR]]
* 03.06.2014: '''Neues Protokoll''': [[IRMP#TELEFUNKEN|TELEFUNKEN]]
* 30.05.2014: '''Neues Protokoll''': [[IRMP#SPEAKER|SPEAKER]]
* 30.05.2014: Timings für [[IRMP#SAMSUNG|SAMSUNG]]-Protokolle optimiert
* 20.02.2014: '''Neues Protokoll''': [[IRMP#SIEMENS_+_RUWIDO|RUWIDO]]
* 09.04.2013: '''Neues Protokoll''': [[IRMP#ROOMBA|ROOMBA]]
* 12.03.2013: 15kHz für [[IRMP#RECS80|RECS80]]- und [[IRMP#RECS80EXT|RECS80EXT]]-Protokoll ist nun auch erlaubt
* 17.01.2013: Unterstützung für ATtiny44 hinzugefügt
* 12.12.2012: '''Neues Protokoll''': [[IRMP#A1TVBOX|A1TVBOX]]
* 07.12.2012: Korrektur Timing beim [[IRMP#NIKON|NIKON]]-Protokoll
* 26.10.2012: Einige Timer-Korrekturen, Anpassungen an Arduino
* 18.06.2012: Unterstützung für ATtiny87/167 hinzugefügt
* 05.06.2012: Korrekturen Portierung auf ARM STM32 - nun getestet
* 23.05.2012: Portierung auf ARM STM32 (ungetestet!)
* 23.05.2012: Bugfix Timing für 2. Frame beim Denon-Protokoll
* 27.02.2012: '''Neues Protokoll''': [[IRMP#IR60 (SDA2008)|IR60 (SDA2008)]]
* 27.02.2012: Bug beim Senden von [[IRMP#Biphase|Biphase]]-Frames (Manchester) behoben
* 27.02.2012: Portierung auf C18 Compiler für PIC-Mikroprozessoren
* 15.02.2012: Bugfix: Nur der 1. Frame wurde gesendet
* 13.02.2012: Timing von [[IRMP#SAMSUNG|SAMSUNG]]- und [[IRMP#SAMSUNG32|SAMSUNG32]]-Protokoll korrigiert
* 13.02.2012: [[IRMP#KASEIKYO|KASEIKYO]]: Genre2-Bits werden nun im oberen Nibble von flags gespeichert.
* 13.02.2012: Zusätzliche Pause nach dem Senden des letzten Frames
* 20.09.2011: '''Neues Protokoll''': [[IRMP#THOMSON|THOMSON]]
* 20.09.2011: '''Neues Protokoll''': [[IRMP#LEGO|LEGO]]
* 20.09.2011: '''Neues Protokoll''': [[IRMP#NEC16|NEC16]]
* 20.09.2011: '''Neues Protokoll''': [[IRMP#NEC42|NEC42]]
* 20.09.2011: Portierung auf ATtiny84 und ATtiny85
* 20.09.2011: Korrektur von Pausenlängen
* 20.09.2011: Korrekturen von irsnd_stop()
* 20.09.2011: Korrektur des [[IRMP#SIEMENS_+_RUWIDO|SIEMENS]]-Timings
* 20.09.2011: Umstellung auf 36kHz Modulationsfrequenz für [[IRMP#DENON|DENON]]-Protokoll
* 20.09.2011: Korrektur Behandlung zusätzlicher Bits im [[IRMP#SIRCS|SIRCS]]-Protokoll
* 18.01.2011: '''Neues Protokoll''': [[IRMP#RC6_+_RC6A|RC6A]]
* 18.01.2011: '''Neues Protokoll''': [[IRMP#RC6_+_RC6A|RC6]]
* 18.01.2011: '''Neues Protokoll''': [[IRMP#NIKON|NIKON]]
* 18.01.2011: Beachten der zusätzlichen Bits (>12) im [[IRMP#SIRCS|SIRCS]]-Protokoll
* 18.01.2011: Korrektur der Pausenlängen
* 18.01.2011: Timing-Korrekturen für [[IRMP#DENON|DENON]]-Protokoll

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

* 29.08.2010: Neues Protokoll: [[IRMP#KASEIKYO|KASEIKYO]] (Panasonic u.a.)

* 01.07.2010: Bugfix: Deaktivieren von [[IRMP#RECS80|RECS80]], [[IRMP#RECS80EXT|RECS80EXT]] & [[IRMP#SIEMENS_+_RUWIDO|SIEMENS]] bei geringer Interrupt-Rate

* 25.06.2010: Neues Protokoll: [[IRMP#RCCAR|RCCAR]]

* 09.06.2010: Neues Protokoll: [[IRMP#FDC|FDC]] (IR-keyboard)
* 09.06.2010: Timing für [[IRMP#DENON|DENON]]-Protokoll korrigiert

* 02.06.2010: Neues Protokoll: [[IRMP#SIEMENS_+_RUWIDO|SIEMENS]] (Gigaset)
* 02.06.2010: Simulation von langen Tastendrücken

* 26.05.2010: Neues Protokoll: [[IRMP#GRUNDIG_+_NOKIA|NOKIA]]

* 17.05.2010: Neues Protokoll: [[IRMP#GRUNDIG_+_NOKIA|GRUNDIG]]
* 17.05.2010: Behandlung von Frame-Wiederholungen für [[IRMP#SIRCS|SIRCS]], [[IRMP#SAMSUNG32|SAMSUNG32]] und [[IRMP#NUBERT|NUBERT]] korrigiert

* 28.04.2010: Unterstützung des [[IRMP#APPLE|APPLE]]-Protokolls
* 28.04.2010: Konfiguration über [http://www.mikrocontroller.net/svnbrowser/irmp/irsndconfig.h?view=markup irsndconfig.h]

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

* 14.04.2010: Neues Protokoll: [[IRMP#B&O|Bang & Olufsen]]

* 17.03.2010: Neues Protokoll: [[IRMP#NUBERT|NUBERT]]
* 17.03.2010: Korrektur der Pausen zwischen Frame-Wiederholungen

* 16.03.2010: Korrektur des Timer-Registers TCCR2
* 16.03.2010: Korrektur der [[IRMP#RECS80|RECS80]]-Startbit-Timings
* 16.03.2010: Neues Protokoll: [[IRMP#RECS80EXT|RECS80 Extended]]

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

* 07.03.2010: Alpha-Version

== Literatur ==

=== IR-Übersicht ===

* http://www.sbprojects.com/knowledge/ir/index.php
* 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.php
* http://www.ustr.net/infrared/sony.shtml
* http://users.telenet.be/davshomepage/sony.htm
* http://picprojects.org.uk/projects/sirc/
* http://www.celadon.com/infrared_protocol/infrared_protocols_samples.pdf

=== NEC-Protokoll ===

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

=== ACP24-Protokoll ===

Das ACP24-Protokoll wird von Stiebel-Eltron-Klimaanlagen verwendet.

Die 70 Datenbits sind folgendermaßen aufgebaut:

1 2 3 4 5 6
0123456789012345678901234567890123456789012345678901234567890123456789
N VVMMM ? ??? t vmA x y TTTT
0011001000000111000010001010000000000000000010000000000000000000001111on, temp=30

Diese werden in die folgenden 16 Bits von irmp_data.command gewandelt:

5432109876543210
NAVVvMMMmtxyTTTT

Bedeutung der Symbole:

TTTT = Temperatur + 15 Grad
TTTT
----------
0000 ???
0001 ???
0010 ???
0011 18 Grad
0100 19 Grad
0101 20 Grad
0110 21 Grad
...
1111 30 Grad

N = Nacht-Modus
N
----------
0 aus
1 ein

VV = Luefter-Stufe, v muss 1 sein!
VV v
----------
00 1 Stufe 1
01 1 Stufe 2
10 1 Stufe 3
11 1 Automatik

MMM = Modus
MMM m
----------
000 0 Ausschalten
001 0 Einschalten
001 1 Kuehlen
010 1 Lueften
011 1 Entfeuchten
100 1 ???
101 1 ---
110 1 ---
111 1 ---

A = Automatik-Programm
A
----------
0 aus
1 ein

t = Timer
t x y
----------
1 1 0 Timer 1
1 0 1 Timer 2

Um die Klimaanlage mittels IRSND anzusteuern, kann man folgende Funktionen verwenden:

<syntaxhighlight lang="c">
#include "irmp.h"
#include "irsnd.h"

#define IRMP_ACP24_TEMPERATURE_MASK 0x000F // TTTT

#define IRMP_ACP24_SET_TIMER_MASK (1<<6) // t
#define IRMP_ACP24_TIMER1_MASK (1<<5) // x
#define IRMP_ACP24_TIMER2_MASK (1<<4) // y

#define IRMP_ACP24_SET_MODE_MASK (1<<7) // m
#define IRMP_ACP24_MODE_POWER_ON_MASK (1<<8) // MMMm = 0010 Einschalten
#define IRMP_ACP24_MODE_COOLING_MASK (IRMP_ACP24_SET_MODE_MASK | (1<<8)) // MMMm = 0011 Kuehlen
#define IRMP_ACP24_MODE_VENTING_MASK (IRMP_ACP24_SET_MODE_MASK | (1<<9)) // MMMm = 0101 Lueften
#define IRMP_ACP24_MODE_DEMISTING_MASK (IRMP_ACP24_SET_MODE_MASK | (1<<10) | (1<<8)) // MMMm = 1001 Entfeuchten

#define IRMP_ACP24_SET_FAN_STEP_MASK (1<<11) // v
#define IRMP_ACP24_FAN_STEP_MASK 0x3000 // VV
#define IRMP24_ACP_FAN_STEP_BIT 12 // VV
#define IRMP_ACP24_AUTOMATIC_MASK (1<<14) // A
#define IRMP_ACP24_NIGHT_MASK (1<<15) // N

// possible values for acp24_set_mode();
#define ACP24_MODE_COOLING 1
#define ACP24_MODE_VENTING 2
#define ACP24_MODE_DEMISTING 3

static uint8_t temperature = 18; // 18 degrees

static void
acp24_send (uint16_t cmd)
{
IRMP_DATA irmp_data;

cmd |= (temperature - 15) & IRMP_ACP24_TEMPERATURE_MASK;

irmp_data.protocol = IRMP_ACP24_PROTOCOL;
irmp_data.address = 0x0000;
irmp_data.command = cmd;
irmp_data.flags = 0;

irsnd_send_data (&irmp_data, 1);
}

void
acp24_set_temperature (uint8_t temp)
{
uint16_t cmd = IRMP_ACP24_MODE_POWER_ON_MASK;

temperature = temp;
acp24_send (cmd);
}

void
acp24_off (void)
{
uint16_t cmd = 0;
acp24_send (cmd);
}

#define ACP_FAN_STEP1 0
#define ACP_FAN_STEP2 1
#define ACP_FAN_STEP3 2
#define ACP_FAN_AUTOMATIC 3

void
acp24_fan (uint8_t fan_step)
{
uint16_t cmd = IRMP_ACP24_MODE_POWER_ON_MASK;

cmd |= IRMP_ACP24_SET_FAN_STEP_MASK | ((fan_step << IRMP24_ACP_FAN_STEP_BIT) & IRMP_ACP24_FAN_STEP_MASK);

acp24_send (cmd);
}

void
acp24_set_mode (uint8_t mode)
{
uint16_t cmd = 0;

switch (mode)
{
case ACP24_MODE_COOLING: cmd = IRMP_ACP24_MODE_COOLING_MASK; break;
case ACP24_MODE_VENTING: cmd = IRMP_ACP24_MODE_VENTING_MASK; break;
case ACP24_MODE_DEMISTING: cmd = IRMP_ACP24_MODE_DEMISTING_MASK; break;
default: return;
}
acp24_send (cmd);
}

void
acp24_program_automatic (void)
{
uint16_t cmd = IRMP_ACP24_MODE_POWER_ON_MASK | IRMP_ACP24_AUTOMATIC_MASK;
acp24_send (cmd);
}

void
acp24_program_night (void)
{
uint16_t cmd = IRMP_ACP24_MODE_POWER_ON_MASK | IRMP_ACP24_NIGHT_MASK;
acp24_send (cmd);
}
</syntaxhighlight>

=== LGAIR-Protokoll ===

Der LG Air Conditioner ist eine Klimaanlage, die durch eine "intelligente" Fernbedienung gesteuert wird.
Dies sind die "entschlüsselten" Daten:

<code>
Befehl AAAAAAAA PW Z S T mmm tttt vvvv PPPP
--------------------------------------------------------------------
ON 23C 10001000 00 0 0 0 000 1000 0100 1100
ON 26C 10001000 00 0 0 0 000 1011 0100 1111

OFF 10001000 11 0 0 0 000 0000 0101 0001
TURN OFF 10001000 11 0 0 0 000 0000 0101 0001 (18C currently, identical with off)

TEMP DOWN 23C 10001000 00 0 0 1 000 1000 0100 0100
MODE (to mode0, 23C) 10001000 00 0 0 1 000 1000 0100 0100

TEMP UP (24C) 10001000 00 0 0 1 000 1001 0100 0101
TEMP DOWN 24C 10001000 00 0 0 1 000 1001 0100 0101

TEMP UP (25C) 10001000 00 0 0 1 000 1010 0100 0110
TEMP DOWN 25C 10001000 00 0 0 1 000 1010 0100 0110

TEMP UP (26C) 10001000 00 0 0 1 000 1011 0100 0111

MODE 10001000 00 0 0 1 011 0111 0100 0110 (to mode1, 22C - when switching to mode1 temp automaticall sets to 22C)
ON (mode1, 22C) 10001000 00 0 0 0 011 0111 0100 1110

MODE 10001000 00 0 0 1 001 1000 0100 0101 (to mode2, no temperature displayed)
ON (mode2) 10001000 00 0 0 0 001 1000 0100 1101
MODE (to mode3, 23C) 10001000 00 0 0 1 100 1000 0100 1000
ON (mode3, 23C) 10001000 00 0 0 0 100 1000 0100 0000

VENTILATION SLOW 10001000 00 0 0 1 000 0011 0000 1011
VENTILATION MEDIUM 10001000 00 0 0 1 000 0011 0010 1101
VENTILATION HIGH 10001000 00 0 0 1 000 0011 0100 1111
VENTILATION LIGHT 10001000 00 0 0 1 000 0011 0101 0000

SWING ON/OFF 10001000 00 0 1 0 000 0000 0000 0001

Format: 1 start bit + 8 address bits + 16 data bits + 4 checksum bits + 1 stop bit

Address: AAAAAAAA = 0x88 (8 bits)

Data: PW Z S T MMM tttt vvvv PPPP (16 bits)

PW: Power: 00 = On, 11 = Off

Z: N/A: Always 0

S: Swing: 1 = Toggle swing, all other data bits are zeros.

T: Temp/Vent: 1 = Set temperature and ventilation

MMM: Mode, can be combined with temperature
000=Mode 0
001=Mode 2
010=????
011=Mode 1
100=Mode 3
101=???
111=???

tttt: Temperature:
0000=used by OFF command
0001=????
0010=????
0011=18°C
0100=19°C
0101=20°C
0110=21°C
0111=22°C
1000=23°C
1001=24°C
1010=25°C
1011=26°C
1011=27°C
1100=28°C
1101=29°C
1111=30°C

vvvv: Ventilation:
0000=slow
0010=medium
0011=????
0100=high
0101=light
0110=????
0111=????
...
1111=????

Checksum: PPPP = (DataNibble1 + DataNibble2 + DataNibble3 + DataNibble4) & 0x0F
</code>

=== NEC16-Protokoll (JVC) ===

* http://www.sbprojects.com/knowledge/ir/jvc.php
* 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.php

=== RC5- und RC5x-Protokoll ===

* http://www.sbprojects.com/knowledge/ir/rc5.php
* http://users.telenet.be/davshomepage/rc5.htm
* http://www.celadon.com/infrared_protocol/infrared_protocols_samples.pdf
* http://www.opendcc.de/info/rc5/rc5.html

=== Denon-Protokoll ===

* http://www.mikrocontroller.com/de/IR-Protokolle.php#DENON
* http://www.manualowl.com/m/Denon/AVR-3803/Manual/170243

=== RC6 und RC6A-Protokoll ===

* http://www.sbprojects.com/knowledge/ir/rc6.php
* http://www.picbasic.nl/info_rc6_uk.htm

=== Bang & Olufsen ===

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

=== Grundig-Protokoll ===

* http://www.see-solutions.de/sonstiges/Grundig_10bit.pdf

=== Nokia-Protokoll ===

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

=== IR60 (SDA2008 bzw. MC14497P) ===

* http://www.datasheetcatalog.org/datasheet/motorola/MC14497P.pdf

=== LEGO Power Functions RC ===

* http://www.philohome.com/pf/LEGO_Power_Functions_RC_v110.pdf

=== RCMM-Protokoll ===

* http://www.sbprojects.com/knowledge/ir/rcmm.php

=== Diverse Protokolle ===

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

== IRMP auf Youtube ==

Einige Videos zu [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] habe ich auf Youtube gefunden:

* http://www.youtube.com/watch?v=Q7DJvLIyTEI

* http://www.youtube.com/watch?v=1tQ_aqayWZk

* http://www.youtube.com/watch?v=W4tI2axR3-w

* http://www.youtube.com/watch?v=SRs98dIe2WE

== Weitere Artikel zu IRMP ==

[http://www.infineon.com/dgdl/RF2ir+WhitePaper+V1.0.pdf?folderId=db3a3043191a246301192dd3ee2c2ae4&fileId=db3a30432b57a660012b5c16272c2e81 Whitepaper von Martin Gotschlich, Infineon Technologies AG]

== Hardware / IRMP-Projekte ==

=== Remote IRMP ===

Netzwerkfähiger Infrarot-Sender und Empfänger mit Android Handy als Fernbedienung:

* http://www.mikrocontroller.net/articles/Remote_IRMP

=== IR-Tester ===

Eine Implementierung auf Basis [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] und [[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|IRSND]] als Multiprotokoll Dekoder mit LCD
von Klaus Leidinger:
* http://www.mikrocontroller-projekte.de/Mikrocontroller/index.html

=== IR-Tester mit AVR-NET-IO ===

Ä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 ===

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

=== USB IR Empfänger/Sender/Einschalter mit Wakeup-Timer ===

* http://www.vdr-portal.de/board18-vdr-hardware/board13-fernbedienungen/123572-fertig-irmp-auf-stm32-ein-usb-ir-empf%C3%A4nger-sender-einschalter-mit-wakeup-timer/

* http://www.mikrocontroller.net/articles/IRMP_auf_STM32_-_ein_USB_IR_Empf%C3%A4nger/Sender/Einschalter_mit_Wakeup-Timer

=== USBASP ===

IR-Einschalter auf Grundlage des USBasp
* http://wiki.easy-vdr.de/index.php?title=USBASP_Einschalter

=== Servo-gesteuerter IR-Sender ===

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

=== Lernfähige IR-Fernbedienung ===

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

=== AVR Moodlight ===

AVR Moodlight von Axel Schwenke
* http://www.mikrocontroller.net/topic/244768

=== Infinity-Mirror-LED-Deckenlampe ===

Infinity-Mirror-LED-Deckenlampe mit Fernbedienung von Philipp Meißner
* http://digital-nw.de/Infinity-Mirror.htm

=== Kinosteuerung ===

Kinosteuerung von Owagner
* http://ccc.zerties.org/index.php/Benutzer:Owagner

=== Phasenanschnittsdimmer ===

Phasenanschnittsdimmer - steuerbar über IR-Fernbedienung:

* http://flosserver.dyndns.org/phasenanschnittsdimmer.php

=== IRDioder – Ikea Dioder Hack ===

Ikea Dioder Hack mit Atmel und Infrarotempfaenger:

* http://marco-difeo.de/tag/infrared/

=== Expedit Coffee Bar ===

Ikea Expedit Regal - umgebaut zur Kaffee-Bar:

* http://chaozlabs.blogspot.de/2013/09/expedit-coffee-bar.html

=== Arduino als IR-Empfänger ===

Arduino als IR-Empfänger:

* http://www.vdr-portal.de/board18-vdr-hardware/board13-fernbedienungen/110918-arduino-als-ir-empf%C3%A4nger-einsetzen/

=== IR-Lautstärkesteuerung mit Stellaris Launchpad ===

IR-Lautstärkesteuerung mit Stellaris Launchpad (ARM Cortex-M4F):

* http://www.anthonyvh.com/2013/03/31/ir-volume-control/

=== RemotePi Board ===

Herunterfahren eines RaspPI mittels Fernbedienung:

* http://www.msldigital.com/pages/more-information

=== Ethernut & IRMP ===

IRMP unter dem RTOS Ethernut:

* http://www.klkl.de/ethernut.html

=== LED strip Remote Control ===

LED-Beleuchtung per Fernbedienung steuern:

* http://www.solderlab.de/index.php/misc/led-strip-remote-control

=== ADAT Audio Mixer ===

Audio Mixer:

* http://mailtonne.de/adat-audio-mixer/

=== Ethersex & IRMP ===

IRMP + IRSND Modul in Ethersex, einer modularen Firmware für AVR MCUs

* http://ethersex.de/index.php/IRMP

=== Mastermind Solver ===

Mastermind-Solver mit LED-Streifen und IR-Fernbedienung

* http://www.mystrobl.de/Plone/basteleien/weitere-bulls-and-cows-mastermind-implementationen/mm-v1821/mastermind-solver-mit-led-streifen-und-ir-fernbedienung

=== A MythTV Remote Control without LIRC ===

PC Remote Control mit ATtiny85

* http://tomscircuits.blogspot.de/2014/12/a-mythtv-remote-control-without-lirc.html

=== IRMP + IRSND Library für STM32F4 ===

IRMP für STM32F4

* http://mikrocontroller.bplaced.net/wordpress/?page_id=1516

IRSND für STM32F4

* http://mikrocontroller.bplaced.net/wordpress/?page_id=1940

=== IRMP auf STM32 - Bauanleitung ===

* http://www.mikrocontroller.net/articles/IRMP_auf_STM32_-_Bauanleitung

=== Studienarbeit - Erweiterung der Arduino Plattform ===

* www.eislab.fim.uni-passau.de/files/publications/2010/StudentDiener_ErweiterungDerArduinoPlattform.pdf

== 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#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] & [[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|IRSND]].

Ebenso bedanken möchte ich mich bei Christian F. für seine Tipps zur PIC-Portierung. Vielen Dank auch an gera für die Portierung auf den PIC-C18 Compiler. Für die Portierung auf ARM STM32 bedanke ich mich herzlich bei kichi (Michael K.). Vielen Dank auch an Markus Schuster für die Portierung auf Stellaris LM4F120 Launchpad von TI (ARM Cortex M4). Danke an Matthias Frank für die Portierung auf XMega.

Mein Dank geht auch an Dániel Körmendi, welcher mich nicht nur immer wieder fleißig mit Scans versorgt, sondern auch das LG-AIR-Protokoll in den IRSND eingebaut hat. Danke auch hier an Ulrich v.d. Kammer für die IRSND-Variante des Pentax-Protokolls.

== 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:Infrarot]]
[[Kategorie:AVR-Projekte]]

Entprellung

2015-07-09T06:50:47Z

Oliver s: Link korrigiert

== Problembeschreibung ==
Mechanische [[Schalter]] wie [[Drehgeber]] neigen beim Ein- und Ausschalten zum sogenannten '''Prellen''', d.h sie schalten schnell mehrfach aus und ein, verursacht durch mechanische Vibrationen des Schaltkontaktes, sofern sie nicht dagegen geschützt sind. Vereinfacht dargestellt, sieht eine von einem Schalter oder Taster geschaltete Spannung beim Schalten wie folgt aus:

[[Bild:Entprellen.png]]

Für die Vermeidung bzw. Auswertung dieses unsauberen Signals gibt es verschiedene Ansätze:

== Hardwareentprellung ==

===Prellfreie Schalter===

Für Spezialanwendungen hält die elektromechanische Industrie verschiedene Sonderkonstruktionen bereit, die saubere Schaltzustände nach Aussen generieren, indem sie entweder eine mechanische Dämpfung in Form eines selbsthemmenden Federmechanismus oder eine integrierte elektronische Signalverzögerung benutzen.

Solche Systeme sind jedoch teuer und werden meist nur im Leistungsbereich eingesetzt.

===Wechselschalter===

Für die Entprellung von Wechselschaltern (engl. Double Throw Switch) kann ein klassisches RS-[[Flipflop]] genutzt werden. Bei dieser Variante werden neben zwei NAND-Gattern nur noch zwei Pull-Up Widerstände benötigt.

[[Bild:NAND_debouncer.png|thumb|left|350px|'''Taster entprellen mit NAND-RS-Flipflop''']]

 

In der gezeigten Schalterstellung liegt an der Position /S der Pegel 0 an. Damit ist das Flipflop gesetzt und der Ausgang auf dem Pegel 1. Schließt der Schalter zwischen den Kontakten 2 und 3, liegt an der Postion /R der Pegel 0 an. Dies bedeutet, dass der Ausgang des Flipflops auf den Pegel 0 geht. Sobald der Schalter von einem zum anderen Kontakt wechselt, beginnt er in der Regel zu prellen. Während des Prellens wechselt der Schalter zwischen den beiden Zuständen "Schalter berührt Kontakt" und "Schalter ist frei in der Luft". Der Ausgang des Flipflops bleibt in dieser Prellzeit aber stabil, da der Schalter während des Prellens nie den gegenüberliegenden Kontakt berührt und das RS-Flipflop seinen Zustand allein halten kann. Die Prellzeit ist stark vom Schaltertyp abhängig und liegt zwischen 0,1 und 10ms. Die Dimensionierung der Widerstände ist relativ unkritisch. Als Richtwert können hier 100kOhm verwendet werden.

====Wechselschalter ohne Flip-Flop====

Wenn man mal gerade kein Flip-Flop zur Hand hat, kann man sich auch mit dieser Schaltung behelfen.

[[Bild:WechselEntprellC.PNG|thumb|left|350px|'''Wechsler entprellen mit Kondensator''']]

 

Zur Funktionsweise:
Beim Umschalten wird der Kondensator immer sofort umgeladen.
Während der Kontakt prellt, befindet er sich in der Luft und hat keinerlei Verbindung. Während dieser Zeit übernimmt der Kondensator das halten des Pegels.

Dimensionierung:
Ist der entprellte Taster an ein IC Angeschlossen, ist der ''Input Leakage Current'' der ausschlaggebende Strom. Falls weitere Ströme fließen sind diese mit zu berücksichtigen. Bei einem Mikrocontroller von Atmel sind 1µA typisch.
Es gilt:
:<math>\frac{dU}{dt} = \frac{I}{C}</math>
Da eine Prellung ca. 10ms dauert und die Spannung in dieser Zeit beispielsweise um maximal 0,5V fallen soll kommt man auf folgende Kapazität:
:<math> C = \frac{I \cdot dt}{dU} = \frac{1\mu A \cdot 10ms}{0,5V} = 20nF </math>

Um Stromspitzen zu verringern kann ein Widerstand mit eingefügt werden. Eine Zeitkonstante von 1µs bis 1ms scheint sinnvoll. Also 500 Ohm bis 500kOhm sind nutzbar, wobei bei niedrigem Widerstand die Stromspitzen höher sind, und bei 500kOhm der Pinstrom störend wird.

===Einfacher Taster===

Auch wenn das RS-Flipflop sehr effektiv ist, wird diese Variante der Entprellung nur selten angewendet. Grund dafür ist, dass in Schaltungen häufiger einfache Taster eingesetzt werden. Diese sind oft kleiner und preisgünstiger. Um einfache Taster (engl. Single Throw Switch) zu entprellen, kann ein einfacher RC-Tiefpass eingesetzt werden. Hierbei wird ein Kondensator über einen Widerstand je nach Schalterstellung auf- oder entladen. Das RC-Glied bildet einen Tiefpass, sodass die Spannung über den Kondensator nicht von einen Pegel auf den anderen springen kann.

[[Bild:RC_debouncer.png|thumb|left|300px|Taster entprellen mit RC-Entpreller]]

[[Datei:Entprellen1a.png|thumb|350px| Entstehender Spannungsverlauf]]
{{Absatz}}

Wenn der Schalter geöffnet ist, lädt sich der Kondensator langsam über die beiden Widerstände R1 und R2 auf Vcc auf. Beim Erreichen der Umschaltschwelle springt der Ausgang auf den Pegel 0. Wird der Schalter geschlossen, entlädt sich der Kondensator langsam über den Widerstand R2. Demnach ändert sich der Ausgang des Inverters auf den Pegel 1. Während der Taster prellt, kann sich die Spannung über dem Kondensator nicht sprunghaft ändern, da das Auf- und Entladen eher langsam über die Widerstände erfolgt. Außerdem sind die Schaltschwellen für den Übergang LOW->HIGH und HIGH->LOW stark verschieden (Hysterese, siehe Artikel [[Schmitt-Trigger]]). Bei richtiger Dimensionierung der Bauelemente wird somit der Ausgang des Inverters prellfrei.

Zu beachten ist, dass der Inverter '''unbedingt''' einer mit [[Schmitt-Trigger]]-Eingängen sein muss, weil bei Standard-Logikeingängen im Bereich von üblicherweise 0,8V - 2,0V der Ausgang nicht definiert ist. Als Inverter kann zum Beispiel der 74HC14 oder der CD40106 (pinkompatibel) eingesetzt werden. Alternativ kann auch ein CD4093 eingesetzt werden. Bei dem CD4093 handelt es sich um NAND-Gatter mit Schmitt-Trigger-Eingängen. Um aus einem NAND-Gatter einen Inverter zu machen, müssen einfach nur die beiden Eingänge verbunden werden oder ein Eingang fest auf HIGH gelegt werden.

Für eine geeignete Dimensionierung muss man etwas mit den Standardformeln für einen Kondensator jonglieren. Die Spannung über den Kondensator beim Entladen berechnet sich nach:
:<math>U_C(t) = U_0 \cdot e^{\frac{-t}{R_2 C_1}}</math>

Damit der Ausgang des Inverters stabil ist, muss die Spannung über den Kondensator und damit die Spannung am Eingang des Inverters über der Spannung bleiben, bei welcher der Inverter umschaltet. Diese Schwellwertspannung ist genau die zeitabhängige Spannung über den Kondensator.
:<math>U_C(t)\!\ = U_{th}</math>

Durch Umstellen der Formel ergibt sich nun:
:<math>R_2=\frac{-t}{C_1 \cdot ln\left(\frac{U_{th}}{U_0} \right)}</math>

Ein Taster prellt üblicherweise etwa 10ms. Zur Sicherheit kann bei der Berechnung des Widerstandes eine Prellzeit von 20ms angenommen werden. U_0 ist die Betriebsspannung also Vcc. Die Schwellwertspannung muss aus dem Datenblatt des eingesetzten Schmitt-Triggers abgelesen werden. Beim 74HC14 beträgt der gesuchte Wert 2,0V. Nimmt man für den Kondensator 1µF und beträgt die Betriebsspannung 5V, ergibt sich für den Widerstand ein Wert von etwa 22kOhm.

Wird der Schalter geöffnet, lädt sich der Kondensator nach folgender Formel auf:
:<math>U_C(t) = U_0 \cdot \left( 1-e^{\frac{-t}{(R_1+R_2)\cdot C_1}} \right)</math>

Mit U_th=U_C ergibt das Umstellen nach (R_1+R_2):
:<math>R_1+R_2 = \frac{-t}{C_1 \cdot ln\left(1-\frac{U_{th}}{U_0} \right)} </math>

Für die Schwellspannung lässt sich aus dem Datenblatt ein Wert von 2,3V ablesen. Mit diesem Wert und den Annahmen von oben ergibt sich für R_1+R_2 ein Wert von 32kOhm. Somit ergibt sich für R_1 ein Wert von etwa 10kOhm.

Anmerkung: Beim 74LS14 von Hitachi z. B. sind die oberen und unteren Schaltschwellwerte unterschiedlich. Es muss darauf geachtet werden, dass U_{th} beim Entladen die untere Schwelle und U_{th} beim Laden die obere Schwelle einnimmt.

== Softwareentprellung ==

In den Zeiten der elektronischen Auswertung von Tastern und Schaltern ist das softwaretechnische Entprellen oft billiger, als die Benutzung eines teuren Schalters. Daher werden heute z.B. auch Computertastaturen nicht mehr mit prellarmen Tasten oder Entprellkondensatoren ausgestattet.

Bei Verwendung des in den meisten Geräten ohnehin vorhandenen Mikrocontrollers z.B., kann man sich die zusätzliche Hardware sparen, da die Entprellung in Software praktisch genauso gut funktioniert. Dabei ist nur zu beachten, dass zusätzliche Rechenleistung und je nach Umsetzung auch einige Hardwareressourcen (z.B. Timer) benötigt werden. Dafür hat man aber den Vorteil, das man kurze Fehlpulse, die offensichtlich keine Tastenbetätigung sein können sondern zb durch Einstreuungen hervorgerufen werden, einfach ausfiltern zu können.

=== Flankenerkennung ===
Bei einem Taster gibt es insgesamt 4 theoretische Zustände:

* 1. war nicht gedrückt und ist nicht gedrückt
* 2. war nicht gedrückt und ist gedrückt (steigende Flanke)
* 3. war gedrückt und ist immer noch gedrückt
* 4. war gedrückt und ist nicht mehr gedrückt (fallende Flanke)

Diese einzelnen Zustände lassen sich jetzt bequem abfragen/durchlaufen. Die Entprellung geschieht dabei durch die ganze Laufzeit des Programms. Die Taster werden hierbei als Active-Low angeschlossen, um die internen Pull-Ups zu nutzen.

Diese Routine gibt für den Zustand "steigende Flanke" den Wert "1" zurück, sonst "0"

<syntaxhighlight lang="c">
#define TASTERPORT PINC
#define TASTERBIT PINC1

char taster(void)
{
static unsigned char zustand;
char rw = 0;

if(zustand == 0 && !(TASTERPORT & (1<<TASTERBIT))) //Taster wird gedrueckt (steigende Flanke)
{
zustand = 1;
rw = 1;
}
else if (zustand == 1 && !(TASTERPORT & (1<<TASTERBIT))) //Taster wird gehalten
{
zustand = 2;
rw = 0;
}
else if (zustand == 2 && (TASTERPORT & (1<<TASTERBIT))) //Taster wird losgelassen (fallende Flanke)
{
zustand = 3;
rw = 0;
}
else if (zustand == 3 && (TASTERPORT & (1<<TASTERBIT))) //Taster losgelassen
{
zustand = 0;
rw = 0;
}

return rw;
}
</syntaxhighlight>

Eine Erweiterung, damit beliebig lange das Halten einer Taste erkannt wird kann man ganz einfach so implementieren:

<syntaxhighlight lang="c">
// zustand kann entweder zum ersten mal als gehalten detektiert werden oder aber jedes weitere mal
else if (((zustand == 1) || (zustand == 2)) && !(TASTERPORT & (1<<TASTERBIT))) //Taster wird gehalten
{
zustand = 2;
rw = 0;
}
</syntaxhighlight>

=== Warteschleifen-Verfahren ===

Soll nun mit einem Mikrocontroller gezählt werden, wie oft ein Kontakt oder ein Relais geschaltet wird, muss das Prellen des Kontaktes exakt berücksichtigt - und von einem gewollten Mehrfachschalten abgegrenzt werden, da sonst möglicherweise Fehlimpulse gezählt- oder andererseits echte Schaltvorgänge übersprungen werden. Dies muss beim Schreiben des Programms hinsichtlich des Abtastens des Kontaktes unbedingt Rechnung getragen werden.

Beim folgenden einfachen Beispiel für eine Entprellung ist zu beachten, dass der AVR im Falle eines Tastendrucks 200ms wartet, also brach liegt. Bei zeitkritischen Anwendungen sollte man ein anderes Verfahren nutzen (z. B. Abfrage der Tastenzustände in einer Timer-Interrupt-Service-Routine).

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <inttypes.h>
#ifndef F_CPU
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */
#endif
#include <util/delay.h> /* bei alter avr-libc: #include <avr/delay.h> */

/* Einfache Funktion zum Entprellen eines Tasters */
inline uint8_t debounce(volatile uint8_t *port, uint8_t pin)
{
if ( !(*port & (1 << pin)) )
{
/* Pin wurde auf Masse gezogen, 100ms warten */
_delay_ms(50); // Maximalwert des Parameters an _delay_ms
_delay_ms(50); // beachten, vgl. Dokumentation der avr-libc
if ( *port & (1 << pin) )
{
/* Anwender Zeit zum Loslassen des Tasters geben */
_delay_ms(50);
_delay_ms(50);
return 1;
}
}
return 0;
}

int main(void)
{
DDRB &= ~( 1 << PB0 ); /* PIN PB0 auf Eingang Taster) */
PORTB |= ( 1 << PB0 ); /* Pullup-Widerstand aktivieren */
...
if (debounce(&PINB, PB0))
{
/* Falls Taster an PIN PB0 gedrueckt */
/* LED an Port PD7 an- bzw. ausschalten: */
PORTD = PORTD ^ ( 1 << PD7 );
}
...
}
</syntaxhighlight>

Die obige Routine hat leider mehrere Nachteile:
* sie detektiert nur das Loslassen (unergonomisch)
* sie verzögert die Mainloop immer um 100ms bei gedrückter Taste
* sie verliert Tastendrücke, je mehr die Mainloop zu tun hat.

Eine ähnlich einfach zu benutzende Routine, aber ohne all diese Nachteile findet sich im Forenthread
[http://www.mikrocontroller.net/topic/164194#new Entprellung für Anfänger]

Der ''DEBOUNCE'' Befehl in dem BASIC-Dialekt BASCOM für AVR ist ebenfalls nach dem Warteschleifen-Verfahren programmiert. Die Wartezeit beträgt standardmäßig 25 ms, kann aber vom Anwender überschrieben werden. Vgl. [http://avrhelp.mcselec.com/bascom-avr.html?DEBOUNCE BASCOM Online-Manual zu DEBOUNCE].

Eine C-Implementierung für eine Tastenabfrage mit Warteschleife ist im Artikel [[AVR-GCC-Tutorial#IO-Register_als_Parameter_und_Variablen|AVR-GCC-Tutorial: IO-Register als Parameter und Variablen]] angeben.

Der Nachteil dieses Verfahrens ist, dass der Controller durch die Warteschleife blockiert wird. Günstiger ist die Implementierung mit einem Timer-Interrupt.

==== Warteschleifenvariante mit Maske und Pointer (nach Christian Riggenbach) ====

Hier eine weitere Funktion, um Taster zu entprellen: Durch den zusätzlichen Code kann eine Entprellzeit von durchschnittlich 1-3ms (mindestens 8*150µs = 1ms) erreicht werden. Grundsätzlich prüft die Funktion den Pegel der Pins auf einem bestimmten Port. Wenn die/der Pegel 8 Mal konstant war, wird die Schleife verlassen. Diese Funktion kann sehr gut eingesetzt werden, um in einer Endlosschleife Taster anzufragen, da sie, wie erwähnt, eine kurze Wartezeit hat.

<syntaxhighlight lang="c">
void entprellung( volatile uint8_t *port, uint8_t maske ) {
uint8_t port_puffer;
uint8_t entprellungs_puffer;

for( entprellungs_puffer=0 ; entprellungs_puffer!=0xff ; ) {
entprellungs_puffer<<=1;
port_puffer = *port;
_delay_us(150);
if( (*port & maske) == (port_puffer & maske) )
entprellungs_puffer |= 0x01;
}
}
</syntaxhighlight>
Die Funktion wird wie folgt aufgerufen:
<syntaxhighlight lang="c">
// Bugfix 20100414
// http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_port_pass
entprellung( &PINB, (1<<PINB2) ); // ggf. Prellen abwarten
if( PINB & (1<<PINB2) ) // dann stabilen Wert einlesen
{
// mach was
}
else
{
// mach was anderes
}
</syntaxhighlight>
Als Maske kann ein beliebiger Wert übergeben werden. Sie verhindert, dass nichtverwendete Taster die Entprellzeit negativ beeinflussen.

==== Debounce-Makro von Peter Dannegger ====

Peter Dannegger hat in [http://www.mikrocontroller.net/topic/164194#1566921 "Entprellen für Anfänger"] folgende vereinfachtes Entprellverfahren beschrieben. Das Makro arbeitet in der Originalversion mit ''active low'' geschalteten Tastern, kann aber einfach für ''active high'' geschaltete Taster angepasst werden ([[Pollin Funk-AVR-Evaluationsboard#Tasty Reloaded|Tasty Reloaded]]).

<syntaxhighlight lang="c">
/************************************************************************/
/* */
/* Not so powerful Debouncing Example */
/* No Interrupt needed */
/* */
/* Author: Peter Dannegger */
/* */
/************************************************************************/
// Target: ATtiny13

#include <avr/io.h>
#define F_CPU 9.6e6
#include <util/delay.h>

#define debounce( port, pin ) \
({ \
static uint8_t flag = 0; /* new variable on every macro usage */ \
uint8_t i = 0; \
\
if( flag ){ /* check for key release: */ \
for(;;){ /* loop ... */ \
if( !(port & 1<<pin) ){ /* ... until key pressed or ... */ \
i = 0; /* 0 = bounce */ \
break; \
} \
_delay_us( 98 ); /* * 256 = 25ms */ \
if( --i == 0 ){ /* ... until key >25ms released */ \
flag = 0; /* clear press flag */ \
i = 0; /* 0 = key release debounced */ \
break; \
} \
} \
}else{ /* else check for key press: */ \
for(;;){ /* loop ... */ \
if( (port & 1<<pin) ){ /* ... until key released or ... */ \
i = 0; /* 0 = bounce */ \
break; \
} \
_delay_us( 98 ); /* * 256 = 25ms */ \
if( --i == 0 ){ /* ... until key >25ms pressed */ \
flag = 1; /* set press flag */ \
i = 1; /* 1 = key press debounced */ \
break; \
} \
} \
} \
i; /* return value of Macro */ \
})

/*
Testapplication
*/
int main(void)
{
DDRB &= ~(1<<PB0);
PORTB |= 1<<PB0;
DDRB |= 1<<PB2;
DDRB &= ~(1<<PB1);
PORTB |= 1<<PB1;
DDRB |= 1<<PB3;
for(;;){
if( debounce( PINB, PB1 ) )
PORTB ^= 1<<PB2;
if( debounce( PINB, PB0 ) )
PORTB ^= 1<<PB3;
}
}

</syntaxhighlight>

Wenn das Makro für die gleiche Taste (Pin) an mehreren Stellen aufgerufen werden soll, muss eine Funktion angelegt werden, damit beide Aufrufe an die gleiche Zustandsvariable ''flag'' auswerten [http://www.mikrocontroller.net/topic/195914#1918727]:

<syntaxhighlight lang="c">
// Hilfsfunktion
uint8_t debounce_C1( void )
{
return debounce(PINC, PC1);
}

// Beispielanwendung
int main(void)
{
DDRB |= 1<<PB2;
DDRB |= 1<<PB3;
DDRC &= ~(1<<PC1);
PORTC |= 1<<PC1; // Pullup für Taster

for(;;){
if( debounce_C1() ) // nicht: debounce(PINC, PC1)
PORTB ^= 1<<PB2;
if( debounce_C1() ) // nicht: debounce(PINC, PC1)
PORTB ^= 1<<PB3;
}
}
</syntaxhighlight>

=== Timer-Verfahren (nach Peter Dannegger) ===

==== Grundroutine (AVR Assembler) ====

Siehe dazu: [http://www.mikrocontroller.net/forum/read-4-20435.html#new Forum]

Vorteile
* besonders kurzer Code
* schnell

Außerdem können 8 Tasten (aktiv low) gleichzeitig bearbeitet werden, es dürfen also
alle exakt zur selben Zeit gedrückt werden. Andere Routinen können z. B. nur eine Taste verarbeiten, d.h. die zuerst oder zuletzt gedrückte gewinnt, oder es kommt Unsinn heraus.

Die eigentliche Einlese- und Entprellroutine ist nur 8 Instruktionen
kurz. Der entprellte Tastenzustand ist im Register ''key_state''. Mit nur 2 weiteren Instruktionen wird dann der Wechsel von ''Taste offen'' zu
''Taste gedrückt'' erkannt und im Register ''key_press'' abgelegt. Im Beispielcode werden dann damit 8 LEDs ein- und ausgeschaltet. Jede Taste entspricht einem Bit in den Registern, d.h. die Verarbeitung erfolgt bitweise mit logischen Operationen. Zum Verständnis empfiehlt es sich daher, die Logikgleichungen mit Gattern für ein Bit = eine Taste aufzumalen. Die Register kann man sich als Flipflops denken, die mit der Entprellzeit als Takt arbeiten. D.h. man kann das auch so z. B. in einem GAL22V10 realisieren.

Als Kommentar sind neben den einzelnen Instruktionen alle 8 möglichen
Kombinationen der 3 Signale dargestellt.

Beispielcode für AVR (Assembler):

<syntaxhighlight lang="avrasm">
.nolist
.include "c:\avr\inc\1200def.inc"
.list
.def save_sreg = r0
.def iwr0 = r1
.def iwr1 = r2

.def key_old = r3
.def key_state = r4
.def key_press = r5

.def leds = r16
.def wr0 = r17

.equ key_port = pind
.equ led_port = portb

rjmp init
.org OVF0addr ;timer interrupt 24ms
in save_sreg, SREG
get8key: ;/old state iwr1 iwr0
mov iwr0, key_old ;00110011 10101010 00110011
in key_old, key_port ;11110000
eor iwr0, key_old ; 11000011
com key_old ;00001111
mov iwr1, key_state ; 10101010
or key_state, iwr0 ; 11101011
and iwr0, key_old ; 00000011
eor key_state, iwr0 ; 11101000
and iwr1, iwr0 ; 00000010
or key_press, iwr1 ;store key press detect
;
; insert other timer functions here
;
out SREG, save_sreg
reti
;-------------------------------------------------------------------------
init:
ldi wr0, 0xFF
out ddrb, wr0
ldi wr0, 1<<CS02 | 1<<CS00 ;divide by 1024 * 256
out TCCR0, wr0
ldi wr0, 1<<TOIE0 ;enable timer interrupt
out TIMSK, wr0

clr key_old
clr key_state
clr key_press
ldi leds, 0xFF
main: cli
eor leds, key_press ;toggle LEDs
clr key_press ;clear, if key press action done
sei
out led_port, leds
rjmp main
;-------------------------------------------------------------
</syntaxhighlight>

==== Komfortroutine (C für AVR) ====

Siehe dazu: [http://www.mikrocontroller.net/forum/read-4-310276.html Forum]

'''Anmerkung''' Wenn statt active-low (Ruhezustand High) active-high (Ruhezustand Low) verwendet wird muss eine Zeile geändert werden siehe:
[http://www.mikrocontroller.net/forum/read-4-310276.html gesamter Beitrag im Forum],
[http://www.mikrocontroller.net/topic/48465#606555 Stelle 1 im Beitrag], ([http://www.mikrocontroller.net/topic/48465#2306398 Stelle 2 im Beitrag] muss *nicht* geändert werden, da hier die Polarität gar keinen Einfluß hat).

'''Anmerkung 2''' Zur Initialisierung siehe [http://www.mikrocontroller.net/topic/48465#3572793 Forum]

Funktionsprinzip wie oben plus zusätzliche Features:
* Kann Tasten sparen durch unterschiedliche Aktionen bei kurzem oder langem Drücken
* Wiederholfunktion, z. B. für die Eingabe von Werten

Das Programm ist für avr-gcc/avr-libc geschrieben, kann aber mit ein paar Anpassungen auch mit anderen Compilern und Mikrocontrollern verwendet werden. Eine Portierung für den AT91SAM7 findet man [http://www.google.com/codesearch?q=show:ac2viP-2E2Y:pzkOO5QRsoc:RPICuprYy-A&sa=N&cd=1&ct=rc&cs_p=svn://mikrocontroller.net/mp3dec/trunk&cs_f=keys.c#a0 hier] (aus dem Projekt [[ARM MP3/AAC Player]]).
<syntaxhighlight lang="c">
/************************************************************************/
/* */
/* Debouncing 8 Keys */
/* Sampling 4 Times */
/* With Repeat Function */
/* */
/* Author: Peter Dannegger */
/* danni@specs.de */
/* */
/************************************************************************/

#include <stdint.h>
#include <avr/io.h>
#include <avr/interrupt.h>

#ifndef F_CPU
#define F_CPU 1000000 // processor clock frequency
#warning kein F_CPU definiert
#endif

#define KEY_DDR DDRB
#define KEY_PORT PORTB
#define KEY_PIN PINB
#define KEY0 0
#define KEY1 1
#define KEY2 2
#define ALL_KEYS (1<<KEY0 | 1<<KEY1 | 1<<KEY2)

#define REPEAT_MASK (1<<KEY1 | 1<<KEY2) // repeat: key1, key2
#define REPEAT_START 50 // after 500ms
#define REPEAT_NEXT 20 // every 200ms

#define LED_DDR DDRA
#define LED_PORT PORTA
#define LED0 0
#define LED1 1
#define LED2 2

volatile uint8_t key_state; // debounced and inverted key state:
// bit = 1: key pressed
volatile uint8_t key_press; // key press detect

volatile uint8_t key_rpt; // key long press and repeat

ISR( TIMER0_OVF_vect ) // every 10ms
{
static uint8_t ct0, ct1, rpt;
uint8_t i;

TCNT0 = (uint8_t)(int16_t)-(F_CPU / 1024 * 10e-3 + 0.5); // preload for 10ms

i = key_state ^ ~KEY_PIN; // key changed ?
ct0 = ~( ct0 & i ); // reset or count ct0
ct1 = ct0 ^ (ct1 & i); // reset or count ct1
i &= ct0 & ct1; // count until roll over ?
key_state ^= i; // then toggle debounced state
key_press |= key_state & i; // 0->1: key press detect

if( (key_state & REPEAT_MASK) == 0 ) // check repeat function
rpt = REPEAT_START; // start delay
if( --rpt == 0 ){
rpt = REPEAT_NEXT; // repeat delay
key_rpt |= key_state & REPEAT_MASK;
}
}

///////////////////////////////////////////////////////////////////
//
// check if a key has been pressed. Each pressed key is reported
// only once
//
uint8_t get_key_press( uint8_t key_mask )
{
cli(); // read and clear atomic !
key_mask &= key_press; // read key(s)
key_press ^= key_mask; // clear key(s)
sei();
return key_mask;
}

///////////////////////////////////////////////////////////////////
//
// check if a key has been pressed long enough such that the
// key repeat functionality kicks in. After a small setup delay
// the key is reported being pressed in subsequent calls
// to this function. This simulates the user repeatedly
// pressing and releasing the key.
//
uint8_t get_key_rpt( uint8_t key_mask )
{
cli(); // read and clear atomic !
key_mask &= key_rpt; // read key(s)
key_rpt ^= key_mask; // clear key(s)
sei();
return key_mask;
}

///////////////////////////////////////////////////////////////////
//
// check if a key is pressed right now
//
uint8_t get_key_state( uint8_t key_mask )

{
key_mask &= key_state;
return key_mask;
}

///////////////////////////////////////////////////////////////////
//
uint8_t get_key_short( uint8_t key_mask )
{
cli(); // read key state and key press atomic !
return get_key_press( ~key_state & key_mask );
}

///////////////////////////////////////////////////////////////////
//
uint8_t get_key_long( uint8_t key_mask )
{
return get_key_press( get_key_rpt( key_mask ));
}

int main( void )
{
LED_PORT = 0xFF;
LED_DDR = 0xFF;

// Configure debouncing routines
KEY_DDR &= ~ALL_KEYS; // configure key port for input
KEY_PORT |= ALL_KEYS; // and turn on pull up resistors

TCCR0 = (1<<CS02)|(1<<CS00); // divide by 1024
TCNT0 = (uint8_t)(int16_t)-(F_CPU / 1024 * 10e-3 + 0.5); // preload for 10ms
TIMSK |= 1<<TOIE0; // enable timer interrupt

sei();

while(1){
if( get_key_short( 1<<KEY1 ))
LED_PORT ^= 1<<LED1;

if( get_key_long( 1<<KEY1 ))
LED_PORT ^= 1<<LED2;

// single press and repeat

if( get_key_press( 1<<KEY2 ) || get_key_rpt( 1<<KEY2 )){
uint8_t i = LED_PORT;

i = (i & 0x07) | ((i << 1) & 0xF0);
if( i < 0xF0 )
i |= 0x08;
LED_PORT = i;
}
}
}
</syntaxhighlight>

Das single-press-und-repeat-Beispiel geht nicht in jeder Beschaltung; folgendes Beispiel sollte universeller sein (einzelne LED an/aus):
<syntaxhighlight lang="c">
// single press and repeat
if( get_key_press( 1<<KEY2 ) || get_key_rpt( 1<<KEY2 ))
LED_PORT ^=0x08;
</syntaxhighlight>

===== Funktionsweise =====
Der Code basiert auf 8 parallelen vertikalen Zählern, die über die Variablen ct0 und ct1 aufgebaut werden

[[Bild:VertCount.png|framed|center|'''8 vertikale Zähler in 2 8-Bit Variablen''']]

wobei jeweils ein Bit in ct0 mit dem gleichwertigen Bit in ct1 zusammengenommen einen 2-Bit-Zähler bildet.
Der Code der sich um die 8 Zähler kümmert, ist so geschrieben, daß er alle 8 Zähler gemeinsam parallel behandelt.

<syntaxhighlight lang="c">
i = key_state ^ ~KEY_PIN; // key changed ?
</syntaxhighlight>
i enthält an dieser Stelle für jede Taste, die sich im Vergleich mit dem vorhergehenden entprellten Zustand (keystate) verändert hat, ein 1 Bit.

<syntaxhighlight lang="c">
ct0 = ~( ct0 & i ); // reset or count ct0
ct1 = ct0 ^ (ct1 & i); // reset or count ct1
</syntaxhighlight>

Diese beiden Anweisungen erniedrigen den 2-Bit Zähler ct0/ct1 für jedes Bit um 1, welches in i gesetzt ist. Liegt an der entsprechenden Stelle in i ein 0 Bit vor (keine Änderung des Zustands), so wird der Zähler ct0/ct1 für dieses Bit auf 1 gesetzt.
Der Grundzustand des Zählers ist als ct0 == 1 und ct1 == 1 (Wert 3). Der Zähler zählt daher mit jedem ISR Aufruf, bei dem die Taste im Vergleich zu keystate als verändert erkannt wurde

ct1 ct0
1 1 // 3
1 0 // 2
0 1 // 1
0 0 // 0
1 1 // 3

<syntaxhighlight lang="c">
i &= ct0 & ct1; // count until roll over ?
</syntaxhighlight>
in i bleibt nur dort ein 1-Bit erhalten, wo sowohl in ct1 als auch in ct0 ein 1 Bit vorgefunden wird, der betreffende Zähler also bis 3 zählen konnte. Durch die zusätzliche Verundung mit i wird der Fall abgefangen, dass ein konstanter Zählerwert von 3 in i ein 1 Bit hinterlässt. Im Endergebnis bedeutet dass, dass nur ein Zählerwechsel von 0 auf 3 zu einem 1 Bit an der betreffenden Stelle in i führt, aber auch nur dann, wenn in i an dieser Bitposition ebenfalls ein 1 Bit war (welches wiederrum deswegen auf 1 war, weil an diesem Eingabeport eine Veränderung zum letzten bekannten entprellten Zustand festgestellt wurde). Alles zusammengenommen heißt das, dass ein Tastendruck dann erkannt wird, wenn die Taste 4 mal hintereinander in einem anderen Zustand vorgefunden wurde als dem zuletzt bekannten entprellten Tastenzustand.

An dieser Stelle ist i daher ein Vektor von 8 Bits, von denen jedes einzelne der Bits darüber Auskunft gibt, ob die entsprechende Taste mehrmals hintereinander im selben Zustand angetroffen wurde, der nicht mit dem zuletzt bekannten Tastenzustand übereinstimmt. Ist das der Fall, dann wird eine entsprechende Veränderung des Tastenzustands in key_state registriert
<syntaxhighlight lang="c">
key_state ^= i; // then toggle debounced state
</syntaxhighlight>
und wenn sich in key_state das entsprechende Bit von 0 auf 1 verändert hat, wird dieses Ereignis als 'Taste wurde niedergedrückt' gewertet.
<syntaxhighlight lang="c">
key_press |= key_state & i; // 0->1: key press detect
</syntaxhighlight>

Damit ist der Tasteneingang entprellt. Und zwar sowohl beim Drücken einer Taste als auch beim Loslassen (damit Tastenpreller beim Loslassen nicht mit dem Niederdrücken einer Taste verwechselt werden). Der weitere Code beschäftigt sich dann nur noch damit, diesen entprellten Tastenzustand weiter zu verarbeiten.

Der Codeteil sieht durch die Verwendung der vielen bitweisen Operationen relativ komplex aus. Behält man aber im Hinterkopf, dass einige der bitweisen wie ein 'paralles If' gleichzeitig auf allen 8 Bits eingesetzt werden, dann vereinfacht sich vieles. Ein
<syntaxhighlight lang="c">
key_press |= key_state & i;
</syntaxhighlight>
ist nichts anderes als ein
<syntaxhighlight lang="c">
// teste ob Bit 0 sowohl in key_state als auch in i gesetzt ist
// und setze Bit 0 in key_press, wenn das der Fall ist
if( ( key_state & ( 1 << 0 ) ) &&
( i & ( 1 << 0 ) )
key_press |= ( 1 << 0 );

// Bit 1
if( ( key_state & ( 1 << 1 ) ) &&
( i & ( 1 << 1 ) )
key_press |= ( 1 << 1 );

// Bit 2
if( ( key_state & ( 1 << 2 ) ) &&
( i & ( 1 << 2 ) )
key_press |= ( 1 << 2 );

...
</syntaxhighlight>
nur als wesentlich kompaktere Operation ausgeführt und für alle 8 Bits gleichzeitig.
Die Kürze und Effizienz dieser paar Codezeilen ergibt sich aus dem Umstand, dass jedes Bit in den Variablen für eine Taste steht und alle 8 (maximal möglichen) Tasten gleichzeitig die Operationen durchlaufen.

===== Reduziert auf lediglich 1 Taste =====
Diskussionen im Forum zeigen immer wieder, dass viele eine Abneigung gegen diesen Code haben, weil er ihnen sehr kompliziert vorkommt.

Der Code ist nicht leicht zu analysieren und er zieht alle Register dessen, was möglich ist, um sowohl Laufzeit als auch Speicherverbrauch einzusparen. Oft hört man auch das Argument: Ich benötige ja nur eine Entprellung für 1 Taste, gibt es da nichts Einfacheres?

Hier ist die 'Langform' des Codes, so wie man das für lediglich 1 Taste schreiben würde, wenn man exakt dasselbe Entprellverfahren einsetzen würde. Man sieht: Da ist keine Hexerei dabei: In key_state wird der letzte bekannte entprellte Zustand der Taste gehalten. Der Pin-Eingang wird mit diesem Zustand verglichen und wenn sich die beiden unterscheiden, dann wird ein Zähler heruntergezählt. Produziert dieses herunterzählen einen Unterlauf des Zählers, dann gilt die Taste als entprellt und wenn dann auch noch die Taste gerade gedrückt ist, dann wird dieses in key_press entsprechend vermerkt.

<syntaxhighlight lang="c">
uint8_t key_state;
uint8_t key_counter;
volatile uint8_t key_press;

ISR( ... Overflow ... )
{
uint8_t input = KEY_PIN & ( 1 << KEY0 );

if( input != key_state ) {
key_counter--;
if( key_counter == 0xFF ) {
key_counter = 3;
key_state = input;
if( input )
key_press = TRUE;
}
}
else
key_counter = 3;

}

uint8_t get_key_press()
{
uint8_t result;

cli();
result = key_press;
key_press = FALSE;
sei();

return result;
}
</syntaxhighlight>

Der vollständige Entprellcode, wie weiter oben gelistet, besticht jetzt aber darin, dass er compiliert kleiner ist als diese anschaulichere Variante für lediglich 1 Taste. Und das bei gleichzeitig erhöhter Funktionalität. Denn zb. ein Autorepeat ist in diesem Code noch gar nicht eingebaut. Und spätestens wenn man dann eine 2.te Taste entprellen möchte, dann ist auch der SRAM-Speicherverbrauch dieser Langform höher als der des Originals für 8 Tasten. Daraus folgt: Selbst für lediglich 1 Taste ist die Originalroutine die bessere Wahl.

Und wegen der Komplexität mal eine Frage: Sind Sie selbst in der Lage eine entsprechend effiziente sqrt() Funktion zu schreiben, wie die, die sie in der Standard-C-Bibliothek vorfinden? Nein? Dann dürften Sie eigentlich Ihrer Argumentation nach die Bibliotheksfunktion sqrt() nicht verwenden, sondern müssten sich statt dessen selbst eine Wurzel-Funktion schreiben.

=== Selbstsättigender Filter (nach Jürgen Schuhmacher) ===
Durch die Nutzung der diskreten Signalanalyse in Software kann die Funktionalität einer einfachen Entprellung mit einem Widerstand, einem Kondensator und einem Schmitttrigger wie in Hardware nachgebildet werden, indem ein abstrakter IIR-Filter benutzt wird, der eine Kondensatorladekurve emuliert. Mit der Vorschrift Y(t) = k Y(t-1) + Input wird ein einfaches Filter erzeugt, dass dem Eingangswert träge folgt. Bei Überschreiten eines bestimmten Wertes erfolgt mit einer einfachen Abfrage das Schalten des Ausgangssignals.

Für Assembler und VHDL bei FPGAs eignet sich aufgrund der leicht zu implementierenden binären Operationen folgende Darstellung mit einer Auflösung des Filterwertspeichers von nur 8 bit: Wert_Neu = Wert_Alt - Wert_Alt/16 + 16*(Taste = True). Der Filterwert bildet dann den gedämpften Verlauf des Eingangs (flankenverschliffen) ab und kann Prellen bis nahe an den Grenzbereich zum schnellen Tasten unterdrücken. Der Ausgangswert ist dann einfach das höchstwertige Bit des Filterwertes.

[[Datei:Entprellung mit IIR-Filter.gif]]

Dazu muss das Signal des Tasters idealerweise um den Faktor 10-20 schneller abgetastet werden, als die höchste gewünschte Tippgeschwindigkeit vorgibt. Noch schneller abzutasten ist möglich, führt aber zu mehr Bedarf an Bits beim Filter. Die Schmittriggerfunktion kann dadurch gebildet werden, dass eine 1 am Ausgang bei z.B. Überschreiten einer 55% Grenze und eine 0 bei Unterschreitung der 45%-Grenze ausgeben wird. Im Zwischenbereich wird der alte Wert gehalten.

=== Einfacher Mittelwertfilter (nach Lothar Miller) ===
Für digitale Schaltungen oder PLDs empfiehlt sich ein FIR-Filter mit aneinandergereihten FlipFlops. Man schiebt das Eingangssignal in eine FlipFlop-Kette und schaltet oberhalb der Mitte um:

SignalInput -> FF1 -> FF2 -> FF3 -> FF4 -> FF5 -> FF6 -> FF7 -> FF8

Wenn alle FFs = 1 (Summe der FFs=8) dann SignalOutput = 1 
Wenn alle FFs = 0 (Summe der FFs=0) dann SignalOutput = 0

Dieses Verfahren kann sehr einfach in Logik abgebildet werden, weil für die Berechnung des Ausgangs nur ein NOR bz. ein AND Gatter nötig ist.

== Gegenüberstellung der Verfahren ==
* HW - "entprellte Schalter": Sehr teuer, grosse Bauform, verschleissbelastet, geringe Haltbarkeit
* HW - "Umschalter" : benötigt aufwändigeren Schalter, benötigt Elektronik
* HW - "Umschalter ohne FF" : benötigt aufwändigeren Schalter und kleinen Kondensator
* HW - "Kondensatorentprellung" : benötigt etwas mehr Platz, kommt mit schlechten Schaltern zurecht

* SW - Flankenverfahren:
* SW - Warteschleife: Durch die Warteschleifen eine nicht zu vernachlässigende Verzögerung im Code. Speziell wenn mehrere Tasten zu überwachen sind, nicht unproblematisch
* SW - Timer: Universalfunktionalität, die durch geringen Speicherverbrauch, geringen Rechenzeitverbrauch und gute Funktion besticht. Der 'Verbrauch' eines Timers sieht auf den ersten Blick schlimmer aus, als er ist, denn in den meisten Programmen hat man sowieso einen Basistimer für die Zeitsteuerung des Programms im Einsatz, der für die Tastenentprellung mitbenutzt werden kann.
* SW - Filter: sehr geringer Platzbedarf in FPGAs, relativ gute Wirkung
* SW - Filter 2: sehr geringer Platzbedarf, gute Wirkung

== Links zum Thema ==

* [http://www.edn.com/design/analog/4324067/Contact-debouncing-algorithm-emulates-Schmitt-trigger Contact-debouncing algorithm (Artikel)], [http://www.edn.com/Pdf/ViewPdf?contentItemId=4324067 als PDF]
* [[AVR-Tutorial: Tasten]]
* [[AVR-GCC-Tutorial#.28Tasten-.29Entprellung|AVR-GCC-Tutorial Tastenentprellung]]
* [http://www.mikrocontroller.net/forum/read-4-20435.html Beitrag im Forum, AVR Assembler]
* [http://www.ganssle.com/debouncing.pdf A guide to debouncing (engl.), praktische Erläuterungen zum Entprellen in Soft- und Hardware]
* [http://www.pololu.com/docs/0J16/all Understanding Destructive LC Voltage Spikes]

[[Kategorie:AVR]]
[[Kategorie:Signalverarbeitung]]

Mcruler

2013-11-17T11:04:30Z

Oliver s: /* Vorbestellungen */

== Infos ==

Hier soll eine Community Variante eines Lineals entstehen, nach Vorbild des µRuler von EEVBlog/Dave Jones:

[[Datei:uRuler.jpg|1200px]]

'''Aktueller Stand:'''

[https://raw.github.com/maugsburger/ucruler/master/ucruler_top.png]
[https://raw.github.com/maugsburger/ucruler/master/ucruler_bot.png]

'''Thread im Forum:''' http://www.mikrocontroller.net/topic/313642

'''Projekt-Seite auf GitHub:''' https://github.com/maugsburger/ucruler

== Spezifikationen ==

{| class="wikitable"
|-
| Maße || 200 x 32 mm
|-
| PCB || 0.5mm oder 0.8mm FR4 '''1-Layer''' 35µ (TBD)
|-
| Oberfläche || gold (ENIG)
|-
| Lötstop || beidseitig, Farbe TBD
|-
| Bestückungsdruck || beidseitig, weiß
|-
| '''Preise''' || ca. 2 € / MOQ: 5 Stück oder vielfaches von 3 (TBD)
|}

== Farbe des Lötstopplackes ==
<pre>
grün |
gelb |
schwarz |+++++++++++++++
weiß |+
rot |+++++++++
blau |++++
</pre>

einfach bitte ein Plus hinter die Farbe die euch als Lötstoplack am besten gefallen würde.

== minimale Schriftgröße ==

http://www.mikrocontroller.net/attachment/196856/ucruler.pdf ausdrucken und die eigenen Augen testen.

Dann bitte eintragen, welche Größe gerade noch lesbar ist. Die normale Schrift wird eins größer werden, aber falls mal wirklich kein Platz mehr sein sollte würde ich darauf zurückgreifen.

<pre>
1,8 |
1,6 |
1,4 |
1,2 | +++++
1,0 | ++++++
0,8 |
</pre>

== Anpassungen/Ergänzungen ==

Bitte einfach ein + oder - ergänzen oder gar nichts eintragen (wichtig, brauch ich nicht, egal), so dass am Ende ein Stimmungsbild entsteht. Daraus ergeben sich dann Prioritäten, in deren Reihenfolge der Platz aufgefüllt wird.

{| class="wikitable"

|-
! Name !! Wertung !! Beschreibung

|-
| Formelsamlung
||
<pre>
+| +++++
-| ------
</pre>
||
Vllt. könnte man auch ein paar Formeln unterbringen die oft verwendet werden und trotzdem gerne vergessen werden

Vorschläge [[Mcnet-ruler#Vorschl.C3.A4ge_f.C3.BCr_Formelsammlung|siehe unten]].

|-
| ✓ Leiterbahnstärken
||
<pre>
1| +
2| ++++++++++++++++++
3|
4|
5|
</pre>
||
Bitte genau eine Möglichkeit mit + wählen:
# Bahnen in mm und mil, beschriftet in mm und mil
# Bahnen in mm, beschriftet in mm und mil
# Bahnen in mil, beschriftet in mm und mil
# Bahnen in mm, beschriftet in mm
# Bahnen in mil, beschriftet in mil

|-
| ✓ Inches in mm
||
<pre>
+| +++++++++++++++++
-| -
</pre>
||
Bitte generell Inches in mm umrechnen.

|-
| Isolationsabstände
||
<pre>
+| +++++++++++++++++++++++
-|
</pre>
||
Die Tabelle für Isolationsabstände (Luft-/Kriechstrecken) ggf. an in Deutschland geltende Normen anpassen.

|-
| Kabel-Widerstände
||
<pre>
+| ++++++++++++
-| -----
</pre>
||
Wenn noch Platz ist, wäre eine Tabelle für Kabel-Widerstände gut (sortiert nach gängigen Querschnitten, pro m oder 10m Kabellänge).

|-
| Widerstands-Farbcode-Tabelle
||
<pre>
+| ++++++++++++++
-| -------------
</pre>
||
Rückseite Widerstands-Farbcode-Tabelle

|-
| LM317
||
<pre>
+| +++++
-| ---------------
</pre>
||
Tabelle für LM317-Widerstandswerte

|-
| Kapazitäts-/Induktivitätsbelag
||
<pre>
+|++++++++
-|---
</pre>
||
Tabellen zum Kapazitäts-/Induktivitätsbelag von Leiterbahnen

|-
| Wellenwiderstände
||
<pre>
+|+++++++
-|----
</pre>
||
Richtwerttabellen für Wellenwiderstände, Micro Striplines (insbes. für USB/Ethernet Routing), etc. auf gängigen PCBs

|-
| Wechselstrom Ueff, Upp
||
<pre>
+| +++
-| ---------------
</pre>
||
Wenn immer noch Platz ist: Tabelle zur Umrechnung von Wechselstromgrößen (Ueff, Upp für gängige Trafowicklungen, 110V, 230V, 240V, 400V, 600V)

Anm.: Sinnvoll für gängige Elko-Spannungen 16VDC, 25VDC, 50VDC, 63VDC, 80VDC.

|-
| f/T-Umrechnung
||
<pre>
+| ++++
-| --------------
</pre>
||
Und wenn dann noch Platz wäre: Tabelle mit f und T für gängige µC-Frequenzen und Samplingraten

Anm.: Sinnvoll und platzsparend, wenn wie vorgeschlagen für einige wenige gängige Werte (z.B. "8 MHz / 125 ns" und "48 kHz / 20,8 µs").

|-
| PCB-Kühlkörper
||
<pre>
+| +++++++++++++++++
-| --
</pre>
||
Was auch interessant waere ist eine Tabelle fuer Leiterplattenkuehlkoerper. K/W pro cm² für div. Kupferstärken!

|-
| SMD-Footprints R
||
<pre>
+| +++++++++++++++++++++++++
-| -
</pre>
||
Die Idee mit den SMD Footprints auf der Rückseite finde ich auch sehr gut.

|-
| ✓ SMD-Größen R
||
<pre>
+| +++++++++++++++
-| -
</pre>
||
Eine Tabelle mit den Größen (im Sinne von Maßen) von SMD Widerständen ist auch manchmal ganz gut.

|-
| SMD-Footprints ElKo
||
<pre>
+| ++++++++++++++++++++++
-|
</pre>
||
Zudem wäre der Footprint von SMD Elkos wenn möglich auf der Rückseite auch ganz praktisch

|-
| SMD-Größen Elko
||
<pre>
+| ++++++++++++++++++++
-|
</pre>
||
Eine Tabelle mit den Größen (im Sinne von Maßen) von SMD Elkos ist auch manchmal ganz gut.

|-
| E-Reihen
||
<pre>
+| ++++++++++
-| --------
</pre>
||
Abdruck der E24-Reihe mit Markierungen für E12, E6.

|-
| TQFP, SOP und SOT Footprint
||
<pre>
+| +++++++++++++++++
-| -
</pre>
||
Der Footprint von TQFP, SOT und SOP Bauteilen auf der Rückseite könnte sich auch als nützlich erweisen

Vorschläge für Footprints [[Mcnet-ruler#Vorschl.C3.A4ge_f.C3.BCr_Footprints|siehe unten]].

|-
| ✓ THT Lochreihe
||
<pre>
+| ++++++++
-| -----
</pre>
||
Ebenso eine kurze Lochreihe im 2,54mm-Raster für THT.

Anm.: Bitte eine lange Lochreihe ähnlich wie von [http://www.mikrocontroller.net/topic/313642#3389830 Chris gezeigt].

|-
| ✓ Kleines Namensfeld
||
<pre>
+| ++++++++++++++++++
-| --
</pre>
||
Damit die Lineale nicht "verschwinden", zum selbst beschriften.

|-
| Tabelle Leitfähigkeit/spezifischer Widerstand
||
<pre>
+| ++++
-| ------
</pre>
||
Eine Tabelle mit der Leitfähigkeit/spezifischer Widerstand von zb. Kufer, Aluminium, Eisen ...

|-
| Temperaturkoeffizent
||
<pre>
+| +++
-| ------
</pre>
||
Eine Tabelle mit den Temperaturkoeffizenten (alpha in 1/k) von zb. Kufer, Aluminium, Eisen ...

|-
| ✓ Transistor-Schaltungssymbole
||
<pre>
+| +++++++
-| --
</pre>
||
Aufdruck von Transistor-Schaltungssymbolen (bipolar/FET) und THT-LEDs, [http://www.adafruit.com/index.php?main_page=popup_image_additional&pID=1554&pic=1&products_image_large_additional=images/large/1554bottom_LRG.jpg siehe hier]

|-
| Pin-Beschriftung für einige Footprints
||
<pre>
+| +++++
-|
</pre>
||
Einige Footprints (z.B. TO-92, SOT-23 etc.) sollten Beschriftungen für BCE/GDS für gängige Transistortypen bekommen, siehe [http://dmohankumar.files.wordpress.com/2011/05/table-showing-the-pins-of-common-transistors.pdf hier] und [http://www.radiomuseum.org/forum/transistor_connections.html hier]

|-
| Kabelschablone
||
<pre>
+| +++++
-|
</pre>
||
Ähnlich dem [http://www.adafruit.com/index.php?main_page=popup_image_additional&pID=1554&pic=1&products_image_large_additional=images/large/1554bottom_LRG.jpg Adafruit Ruler], aber als Tabelle in AWG und mm.

|}

== Vorschläge für Formelsammlung ==

{| class="wikitable"

|-
! Name !! Wertung !! Beschreibung

|-
| C/L
||
<pre>
+| +
-| -
</pre>
||
http://upload.wikimedia.org/math/d/5/5/d550b39c146790974bae8a9a2e1830fb.png

http://upload.wikimedia.org/math/0/9/a/09ab806c34320b749ddadca35a32fc8a.png

http://de.wikipedia.org/wiki/Elektrische_Kapazit%C3%A4t#Kapazit.C3.A4t_bestimmter_Leiteranordnungen

http://de.wikipedia.org/wiki/Induktivit%C3%A4t#Induktivit.C3.A4t_einer_Zylinderspule

|-
| Eckfrequenz RC-Glied HP/LP
||
<pre>
+| +
-| --
</pre>
||
http://upload.wikimedia.org/math/5/d/1/5d1295e236a3c860416fbdb9940fb043.png

http://de.wikipedia.org/wiki/RC-Glied#Tiefpass

|-
| I(t) / U(t) für C/L
||
<pre>
+| ++
-| -
</pre>
||
http://upload.wikimedia.org/math/0/b/9/0b93b4a1ce2832629d42509b43184894.png

http://upload.wikimedia.org/math/9/e/6/9e6ea02a73a08f263454786c1c9d7e44.png

http://de.wikipedia.org/wiki/Zeitkonstante#Kondensator

|-
| Wärmewiderstand
||
<pre>
+| +
-| -
</pre>
||
http://upload.wikimedia.org/math/8/7/b/87b98460f0867373471f540167591ebb.png

http://de.wikipedia.org/wiki/W%C3%A4rmewiderstand#Definition

|}

== Vorschläge für Footprints ==

Vorschläge für Footprints auf der Rückseite. Es werden die Pads in Kupfer ausgeführt (also theoretisch lötbar), der Rand des Bauteils im Bestückungsdruck.

* http://www.fairchildsemi.com/package/
* http://www.maximintegrated.com/design/packaging/
* http://www.infineon.com/cms/de/product/technology/packages/index.html
* http://www.nxp.com/packages
* http://www.topline.tv/Drawings/PDF/QFP/TQFP_Library.pdf
* http://www.linear.com/designtools/packaging/
* http://ww1.microchip.com/downloads/en/PackagingSpec/00049AR.pdf

=== Standardisierungen ===
* http://www.jedec.org/category/technology-focus-area/registered-outlines-jep95

=== Inspirationen ===

Siehe auch [http://www.adafruit.com/blog/2013/10/11/new-product-adafruit-pcb-ruler-6/ Adafruit Ruler].

http://www.adafruit.com/images/large/1554bottom_LRG.jpg

=== Widerstände & Kondensatoren ===
Maße siehe z.B. http://www.panasonic.com/industrial/components/pdf/AOA0000CE1.pdf

* 0201 (wenn der Fertiger des Lineal das kann...)
* 0402
* 0603
* 0805
* 1206
* 1210
* 1812 (wenn noch Platz ist)
* 2010 (wenn noch Platz ist)
* 2512 (wenn noch Platz ist)

=== Transistoren & ICs ===

* ✓ SC-70
* ✓ SOT-23
* ✓ SOT-23-6
* ✓ SOT-89
* ✓ SOT-223
* TO-252 / DPAK http://www.fairchildsemi.com/dwg/TO/TO252A03.pdf
* TO-263 / D2PAK http://www.fairchildsemi.com/dwg/TO/TO263A02.pdf

=== Dioden & LEDs ===

* SMA / DO-214AC http://www.fairchildsemi.com/dwg/DO/DO214AC.pdf
* SMB / DO-214AA http://www.fairchildsemi.com/dwg/DO/DO214AA.pdf
* SMC / DO-214AB http://www.fairchildsemi.com/dwg/DO/DO214AB.pdf
* Melf http://www.cdil.com/package/do213ab_dwng.pdf
* MiniMelf http://www.cdil.com/package/sod_80c.pdf
* MicroMelf http://www.vishay.com/docs/20003/smm0102.pdf
* PLCC-4 / 3528 http://catalog.osram-os.com/media/_en/Graphics/00042269_0.pdf
* PLCC-6 / 5050 http://ledversand24.de/media/pdf/ws2812preliminary51337f1c83131.pdf

=== ICs ===

* SOIC-24, 3.9mm-Body, ein Footprint, aber mit Bestückungsdruck-Linien die kleineren Varianten für 8,14,16,20,24 Pins anzeichen, Pinzahl ranschreiben
* SOIC-24, 7.5mm-Body, ein Footprint, aber mit Bestückungsdruck-Linien die kleineren Varianten für 8,14,16,20,24 Pins anzeichen, Pinzahl ranschreiben
Diese beiden SOIC-Breiten wenn möglich in einem Footprint zusammenfassen, also z.B. die linken Pins gemeinsam verwenden. Die beiden
Breiten dann über Bestückungsdruck-Linien kennzeichnen.

* SSOP-24, 5,3mm-Body, 0,65mm Pitch. Das ist die gängigste Variante, es gibt aber leider auch einige Abweichler mit anderem Pitch und Bodybreite die sich auch SSOP nennen :(
* TSSOP-28, 4,4mm-Body, 0,65mm Pitch
Auch bei diesen beiden: ein Footprint, aber mit Bestückungsdruck-Linien die kleineren Varianten für 8,14,16,20,24,28 Pins anzeichen, Pinzahl ranschreiben

Für die Maße: http://www.microchip.com/stellent/groups/techpub_sg/documents/packagingspec/en012702.pdf

Wenn noch Platz:
* TQFP32, 0.8mm Pitch http://www.microchip.com/stellent/groups/techpub_sg/documents/packagingspec/en012702.pdf
* TQFP48 / LQFP48, 0.5mm Pitch http://www.nxp.com/documents/outline_drawing/sot313-2_po.pdf
* QFN32, 0.5mm Pitch http://www.linear.com/docs/38749

== Vorbestellungen ==
Interessenten tragen sich bitte '''am Ende der Liste ein und aktualisieren den Zwischenstand'''!

Mindestbestellmenge ist nach aktuellem Stand 5 Stück.

<pre>
10 Dominik S. (dasd)
5 Dennis X. (debegr92)
2 Arne M. (armut)
3 Benedikt K. (benek)
5 AVR (Gast)
5 Jürgen (Gast)
5 Uwe ... (uwegw)
15 Rene H. (promeus)
5 hum (Gast)
3 Werner A. (homebrew)
2 Frank Werner (wesoft)
5 Jan B. (diphthong)
5 Thomas J. (tom16)
10 Felix Schulze (pepe)
3 Patrick Berninghaus (patricck)
5 B. B. (morgenmuffel)
5 Bernd D. (bernd_d56)
5 Daniel (Gast)
5 Jan Dressler (keyman)
3 Gerd E. (robberknight)
10 Ralf Engelhardt (r_e)
5 D. S. (compuvidy)
5 Michael R. (elektr-hobbyist)
5 Samuel Hildebrandt (musicsammy)
5 Martin H. (marrtn)
5 Michael Becker (mich_at_el)
5 Marco André (marphy)
5 Chris (Gast)
5 mr. mo (Gast)
10 René B. (reneb)
5 Martin R. (martin84)
3 J. S. (voochee)
5 Andreas H. (ahz)
5 Ronny Spiegel (duselbaer)
10 G. L. (lele)
3 Axel Jäger (axeljaeger)
5 Stephan G. (stephan_g35)
5 Gibts Ne (schneeblau)
5 Sascha G. (sascha-g)
5 Richard Zink (Gast)
5 Stephan K. (nightowl)
5 Martin Wende (Firma: fritzler-avr.de) (fritzler)
5 Jörg S. (Gast)
10 J. L. (lindenbaum)
10 Jan M. (mueschel)
5 Bad Urban (bad_urban)
5 Daniel M. (amad)
5 Sascha S. (dec)
5 A. S. (rava)
10 Jens M. (jens-m)
5 Sascha E. (baracuss)
5 avr avr (colombo010)
5 Michael B. (michael_b25)
5 Thomas Sch. (doschi_)
5 K. J. (theborg0815)
5 Daniel C. (cecky)
3 Philipp E. (erlang)
5 Thorsten Ostermann (Firma: mechapro GmbH) (ostermann)
10 vophatec (Manuel Z.)
3 Carsten Peschke
2 J.O. (Gast)
10 F. Fo (foldi)
5 D. Braun (garag)
5 Michael.S. (michael0307)
5 Didi S. (kokisan2000)
5 Thomas L. (ics1702)
5 Sebastian Engel (s-engel)
5 Peter Sieg (petersieg)
5 Martin S. (martin_s91)
5 Manuel Steiner (steinerhippo)
5 Nico B. (vegetico)
5 Axel P. (axel_p)
5 Mh. M. (mhm)
5 Friedrich K (*)
5 O.Hagendorf (ohagendorf)
5 Jonas K. (jonas k)
5 Sam .. (sam1994)
5 Jens A. (Nepi)
5 Tom Z. (tom_z)
5 Sven K. (herbivore)
5 Steffen A (*)
3 Stephan Henning (stephan-) notfalls auch 5
5 Benjamin Jung (benjamin_j)
5 Kai D. (kai1972)
5 Gerd B. (bertr2d2)
5 Martin G. (magoe)
5 Stefan K. (oxid)
5 S. Q. (frido2001)
5 D. K. (elektricar)
5 Markus C. (ljmarkus)
5 Alexander K. (minjaman)
10 Dominic A. (neo123)
3 Oliver S. (Oliver_S) notfalls auch 5
-------------------------------------
501 ZWISCHENSTAND
</pre>

Transistor-Übersicht

2010-01-23T11:37:17Z

Oliver s: /* Transistor-Array */

Im Forum wird immer wieder gefragt, welcher [[Transistor]] für eine bestimmte Anwendung passend ist, deswegen lege ich hier mal diesen Wikieintrag an. Wie in der [[Mosfet-Übersicht]] und der [[Dioden-Übersicht]] soll hier eine Liste entstehen mit gängigen Transistoren, die auch für den Bastler erhältlich sind. Für die Typbezeichnung siehe [[Kennzeichnung von Halbleitern]]. Eine allgemeine Übersicht über verschiedene Bauteile gibt es hier: [[Standardbauelemente]].

''Bei den Spalten für die Liste bin ich mir nicht sicher, was jetzt am wichtigsten ist. Ich hab einfach mal angefangen. Wenn noch etwas fehlt, dann füge bitte die entsprechende Spalte ein, und entferne diesen Hinweis. Danke.''

== NPN ==

{| {{Tabelle}} class="sortable" id="pkanalmosfets"
|- style="background-color:#eeeeee"
! Bezeichnung || Package || UCE/V || IC/A || β (Beta)|| Ptot/W|| fG/MHz|| Bemerkung|| Lieferant|| Datenblatt|| ca. Preis/€
|-
|2N3904
|TO-92
|60
|0.2
|100-300
|0.5
|300
|Schalttransistor
|Rei
|[http://www.alldatasheet.com/datasheet-pdf/pdf/15077/PHILIPS/2N3904.html alldatasheet.com]
|0.04
|-
|2N3055
|TO-3
|60
|15
|20-70
|115
|2.5
|Leistungstransistor
|Rei
|[http://pdf1.alldatasheet.com/datasheet-pdf/view/2466/MOSPEC/2N3055.html alldatasheet.com]
|0.40
|-
|BC107B
|TO-18
|45
|0.1
|200-450
|0.3
|300
|
|Rei
|[http://pdf1.alldatasheet.com/datasheet-pdf/view/45348/SIEMENS/BC107B.html alldatasheet.com]
|0.23
|-
|BC547B
|TO-92
|45
|0.1
|125-500
|0.625
|300
|Schalttransistor
|Rei
|[http://pdf1.alldatasheet.com/datasheet-pdf/view/16104/PHILIPS/BC547B.html alldatasheet.com]
|0.03
|-
|BD679A
|SOT-32
|80
|4
|750
|40
|
|Darlington
|Rei
|[http://pdf1.alldatasheet.com/datasheet-pdf/view/11588/ONSEMI/BD679A.html alldatasheet.com]
|0.21
|-
|MPSA42
|TO-92
|300
|0.5
|40
|0.625
|50
|hohe Spannung
|Rei
|[http://www.fairchildsemi.com/ds/MP/MPSA42.pdf Fairchild]
|0.05
|-
|BC337
|TO-92
|45
|0.8
|100-630
|0.625
|210
|
|Rei
|[http://alldatasheet.com/view.jsp?Searchword=BC337 alldatasheet.com]
|0.04
|-
|FMMT617
|SOT-23
|15
|3
|60-300
|0.625
|
|Schalttransistor
|Rei
|[http://www.zetex.com/3.0/pdf/FMMT617.pdf Zetex]
|0.27
|-
| MJ15003
| TO-3
| 140
| 20
| 25-150
| 250
| 2
| Leistungstransistor
| Rei, Far
| [http://www.alldatasheet.com/datasheet-pdf/pdf/4799/MOTOROLA/MJ15004.html alldatasheet.com]
| 1.55
|-
| BD131
| TO-126
| 45
| 3
| 30-70
| 15
| 60
| Mittlere Leistung, guter Allrounder
| Rei,?
| [http://www.alldatasheet.com/datasheet-pdf/view/16167/PHILIPS/BD131.html alldatasheet.com]
| 0.131
|-
|BC517
|TO-92
|30
|1
|30000
|0.6
|200
|Darlington
|Rei
|[http://www.alldatasheet.com/datasheet-pdf/pdf/2890/MOTOROLA/BC517.html alldatasheet.com]
|0.07
|-
|BCW66
|SOT-23
|45
|0.8
|100-630
|0.36
|170
|
|Rei
|[http://pdf1.alldatasheet.com/datasheet-pdf/view/21975/STMICROELECTRONICS/BCW66.html alldatasheet.com]
|0.041
|-
|BFR92
|SOT-23
|15
|0.3
|50
|0.2
|5000
| Hochfrequenz
|Rei ...
|
|0.16
|}

(Tabelle mit Klick im Kopfbereich sortierbar)

== PNP ==

{| {{Tabelle}} class="sortable" id="pkanalmosfets"
|- style="background-color:#eeeeee"
! Bezeichnung
! Package
! UCE/V
! IC/A
! β (Beta)
! Ptot/W
! fG/MHz
! Bemerkung
! Lieferant
! Datenblatt
! ca. Preis/€
|-
|2N3906
|TO-92
|40
|0.2
|100-300
|0.5
|250
|
|Rei
|[http://pdf1.alldatasheet.com/datasheet-pdf/view/15078/PHILIPS/2N3906.html alldatasheet.com]
|0.05
|-
|BC560
|TO-92
|45
|0,1
|110-800
|0.5
|150
|
|Rei
|[http://alldatasheet.com/view.jsp?Searchword=BC560 alldatasheet.com]
|0.04
|-
|BC327
|TO-92
|45
|0.8
|100-630
|0.625
|
|Komplement zu BC337
|Rei
|[http://alldatasheet.com/view.jsp?Searchword=BC327 alldatasheet.com]
|0.04
|-
|FMMT717
|SOT-23
|12
|2.5
|50-300
|0.625
|
|Komplement zu FMMT617
|Rei
|[http://www.zetex.com/3.0/pdf/FMMT717.pdf Zetex]
|0.19
|-
|BD438
|TO-126
|45
|4
|30-140
|36
|3
|
|Rei
|[http://alldatasheet.com/view.jsp?Searchword=BD438 alldatasheet.com]
|0.17
|-
|MJ2955
|TO-3
|60
|15
|20-70
|115
|2.5
|2N3055 Komplement
|Rei
|[http://alldatasheet.com/view.jsp?Searchword=MJ2955 alldatasheet.com]
|0.40
|-
| BD132
| TO-126
| 45
| 3
| 30-120
| 15
| 60
| Komplement zu BD131
| Rei,?
| [http://www.alldatasheet.com/datasheet-pdf/pdf/16168/PHILIPS/BD132.html alldatasheet.com]
| 0.20
|-
|BC516
|TO-92
|30
|0.5
|30000
|0.5
|220
|Komplement zum BC517
|Rei
|[http://pdf1.alldatasheet.com/datasheet-pdf/view/15078/PHILIPS/2N3906.html alldatasheet.com]
|-
|BCP53
|SOT223
|80
|1
|
|1.3
|115
|
|Rei
|[http://www.datasheetcatalog.net/de/datasheets_pdf/B/C/P/5/BCP52-16.shtml datasheetcatalog.com]
|-
|BDP950
|SOT223
|60
|3
|
|3
|100
|
|Rei
|[http://www.datasheetcatalog.com/datasheets_pdf/B/D/P/9/BDP950.shtml datasheetcatalog.com]
|0.29
|-
|BCW67
|SOT-23
|42
|0.8
|100-630
|0.32
|200
|
|Rei
|[http://pdf1.alldatasheet.com/datasheet-pdf/view/79166/INFINEON/BCW67.html alldatasheet.com]
|0.041
|}

(Tabelle mit Click im Kopfbereich sortierbar)

== Transistor-Array ==

{| {{Tabelle}} class="sortable" id="pkanalmosfets"
|- style="background-color:#eeeeee"
! Bezeichnung
! Package
! UCE/V
! IC/A
! β (Beta)
! Ptot/W
! fT/MHz
! Bemerkung
! Lieferant
! Datenblatt
! ca. Preis/€
|-
| NTE912
| DIL-14
| -
| -
| -
| -
| -
| 5 NPN-Transistoren
| Far
| [http://www.nteinc.com/specs/900to999/pdf/nte912.pdf NTE]
| 3.50
|-
| CA3086
| DIL-14
| -
| -
| -
| -
| -
| 5 NPN-Transistoren, abgekündigt
| ?
| [http://www.google.de/search?q=CA%203086 Google]
| 0.50
|-
| BCV61
| SOT143
| 30
| 0.1
| 100-800
| 0.25
| 100
| 2 NPN-Transistoren für Stromspiegel
| Rei, Far
| [http://www.alldatasheet.com/view.jsp?Searchword=BCV61 alldatasheet.com]
| 0.14
|-
| BCV62
| SOT143
| 30
| 0.1
| 100-800
| 0.25
| 100
| 2 PNP-Transistoren für Stromspiegel
| Rei, Far
| [http://www.alldatasheet.com/view.jsp?Searchword=BCV62 alldatasheet.com]
| 0.19
|-
|}

(Tabelle mit Click im Kopfbereich sortierbar)

== Bemerkungen ==

*UCE = Maximale Kollektor-Emitter-Spannung bei IC = 0
*IB = Maximaler Basisstrom
*IC = Maximaler Kollektorstrom
*SOT-32 = TO-126

== Lieferantenübersicht ==

* [Rei] Reichelt: http://www.reichelt.de
* [Kes] Kessler: http://www.kessler-elektronik.de
* [csd] CSD-Electronics: http://www.csd-electronics.de/
* [Con] Conrad-Elektronik: http://www.conrad.de
* [Far] Farnell: http://www.farnell.de (gewerbl. oder Student)

[[Category:Bauteile]]

MOSFET-Übersicht

2010-01-23T10:33:33Z

Oliver s: /* N-Kanal MOSFET */

Im Forum wird immer wieder gefragt, welchen Mosfet-Transistor man für ein Projekt einsetzen sollte. Und wo man die herbekommt. Deshalb soll hier eine Übersicht mit gängigen Mosfet-Transistoren entstehen, wo auch die Bezugsquellen angegeben sind. Bezugsquellen sollten nach Möglichkeit solche sein, die auch für den privaten Bastler in Frage kommen.

Der Thread zum Thema: http://www.mikrocontroller.net/topic/41588

siehe auch : [[Transistor-Übersicht]] - [[Dioden-Übersicht]] - [[Standardbauelemente]]

== P-Kanal MOSFET==

{| border="1" class="sortable" id="pkanalmosfets"
|-
! Bezeichnung
! Package
! Hersteller
! UGS/V
! UDS/V
! ID/A
! P/W
! RDS,on/mOhm
! Bemerkung
! Lieferant
! Preis/EUR
|-
| BS250
| TO-92
| Siliconix
| 4.0
| 60
| 0.12
| 0.35
| 10000
| -
|[[Elektronikversender#Reichelt|Rei]]
| 0.32
|-
| BSH205
| SOT23
| Phi
| 1.0
| 12
| 0.75
| 0.4
| 500
| kleine Gatekapazität (3.8nC)
| [[Elektronikversender#csd-electronics|csd]] (a.A.)
| 0.30
|-
| IRLML6302PBF
| SOT23
| IRF
| 1.5
| 20
| 0.75
| 0.54
| 600
| ähnlich BSH205
| [[Elektronikversender#csd-electronics|csd]]
| 0.18
|-
| BSS83P
| SOT23
| Inf
| 3.0
| 60
| 0.33
| 0.35
| 2000
| -
| [[Elektronikversender#Reichelt|Rei]]
| 0.11
|-
| BSS84
| SOT23
| Fairchild,NXP
| 2.0
| 50
| 0.13
| 0.35
| 10000
| -
| [[Elektronikversender#Farnell|Fa]]
| 0.28
|-
| BSS83
| TO-97, SOT23
| Phi
| 3.0
| 50
| 0.13
| 0.35
| 10000
| -
| [[Elektronikversender#Conrad|Con]],[[Elektronikversender#Reichelt|Rei]]
| 0.07
|-
| BSS110
| TO-97, SOT23
| Phi
| 3.0
| 50
| 0.17
| 0.35
| 10000
| -
| ?
| ?
|-
| PMV65XP
| SOT23
| Phi
| 1.4
| 20
| 3.9
| ?
| 76
| grosser ID für Bauform
| [[Elektronikversender#Spoerle|Spo]], [[Elektronikversender#RS_Components|RS]]
| 0.10 (bei 3000er-Rolle)
|-
| IRF4905S
| D2Pack
| irf
| 4.0
| 55
| 64
| 3.8
| 20
| -
| [[Elektronikversender#Conrad|Con]]
| 2.60
|-
| IRF4905
| TO-220AB
| irf
| 4.0
| 55
| 74
| 3.8
| 20
| -
|[[Elektronikversender#Reichelt|Rei]]
| 0.93
|-
| IRF5210S
| D2Pack
| irf
| 10.0
| 100
| 40
| ?
| 60
| -
|[[Elektronikversender#Reichelt|Rei]]
| 1.25
|-
| IRF7104
| SO-8
| irf
| 3.0
| 20
| 2.3
| 2.0
| 250
| 2 FETs im Gehäuse
|[[Elektronikversender#Reichelt|Rei]]
| 0.36
|-
| IRF7205
| SO-8
| irf
| 3.0
| 30
| 4.6
| 2.5
| 70
| ?
|[[Elektronikversender#Reichelt|Rei]]
| 0.34
|-
| FDC604P
| SuperSOT-6
| Fairchild
| 1.5
| 20
| 5.5
| 0.8/1.6
| 33
| -
| [[Elektronikversender#csd-electronics|csd]] (a.A.)
| 0.70
|-
| NDS0610
| SOT-23
| Fairchild
| 1.8
| 60
| 0.12
| 0.36
| 10000
| -
| [[Elektronikversender#csd-electronics|csd]]
| 0.07
|-
| IRF5305
| TO-220AB
| irf
| 3.0
| 55
| 31
| 110
| 60
| -
|[[Elektronikversender#Reichelt|Rei]]
| 0.59
|-
| NDS352P
| SOT23
| Fairchild
| 4.5
| 20
| 0.85
| 0.5
| 500
| -
| [[Elektronikversender#Conrad|Con]]
| 0.76
|-
| [http://crio.mib.infn.it/wig/electronics/Componenti/Siemens/MOS%20Transistor/BSP171.pdf BSP 171]
| SOT-223
| Siemens
| 1.4
| 60
| 1.7
| 1.8
| 350
| -
|[[Elektronikversender#Reichelt|Rei]]
| 0.51
|-
| IRFD9014
| HEXDIP/DIP4
| irf
| 2.0
| 60
| 1.1
| 1.3
| 500
| -
| [[Elektronikversender#Conrad|Con]]
| 0.65
|-
| IRFD9024
| HEXDIP/DIP4
| irf
| 2.0
| 60
| 1.6
| 1.3
| 280
| -
| [[Elektronikversender#Conrad|Con]],[[Elektronikversender#Reichelt|Rei]]
| 0.50
|-
| IRF7416
| SO-8
| irf
| 1.0
| 30
| 10
| 2.5
| 20
| -
| [[Elektronikversender#Conrad|Con]],[[Elektronikversender#Reichelt|Rei]]
| 0.60
|-
| SUP75P03-007
| TO-220AB
| VISHAY
| 3.0
| 30
| 75
| 187
| 7
| -
| nessel-elektronik.de
| 2.30
|}

(Tabelle mit Click im Kopfbereich sortierbar; a.A. = Auf Anfrage)

== N-Kanal MOSFET==

{| border="1" class="sortable" id="nkanalmosfets"
|-
! Bezeichnung
! Package
! Hersteller
! UGS(th)/V
! UDS/V
! ID/A
! P/W
! RDS,on/mOhm
! Bemerkung
! Lieferant
! Preis/EUR
|-
| IRF 530
| TO-220
| irf
| 2,9
| 100
| 16
| 94
| 160
|
| [[Elektronikversender#Reichelt|Rei]]
| 0.44
|-
| IRL3103
| TO-220AB
| irf
| 1.0
| 30
| 64
| 94
| 12
| Qg=33nC (!)
| [[Elektronikversender#Segor-electronics|Seg]]
| 0.95
|-
| IRF730A
| TO-220AB
| irf
| 2.0
| 400
| 5.5
| 74
| 1000
| Qg=22nC (!)
| [[Elektronikversender#Reichelt|Rei]]
| 0.54
|-
| IRFP064
| TO-247AC
| irf
| 2.0
| 60
| 70
| 300
| 9
| Qg=190 nC
| [[Elektronikversender#Reichelt|Rei]]
| 1.65
|-
| IRF3205
| TO-220AB
| irf
| 2.0
| 55
| 110
| 200
| 8
|
| [[Elektronikversender#Reichelt|Rei]]
| 1.10
|-
| IRL3803
| TO-220AB
| irf
| 1.0
| 30
| 140
| 200
| 6
| Qg=140nC
| [[Elektronikversender#Reichelt|Rei]]
| 1.15
|-
| IRF540
| TO-220AB
| irf
| 10
| 100
| 28
| 150
| 77
|
| [[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#Kessler|Kes]]
| 0.52
|-
| IRF7401
| SO-8
| irf
| 2.7
| 20
| 8.7
| 2.0
| 22
|
| [[Elektronikversender#Reichelt|Rei]]
| 0.565
|-
| IRF7403
| SO-8
| irf
| 4.85
| 30
| 8.5
| 2.5
| 22
|
| [[Elektronikversender#Reichelt|Rei]]
| 0.42
|-
| IRF7413
| SO-8
| irf
| 3.0
| 30
| 13.0
| 2.5
| 11
|
| [[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#Kessler|Kes]]
| 0.65
|-
| BUZ11
| TO-220
| ST
| 5.0
| 50
| 33.0
| 90.0
| 30
|
| [[Elektronikversender#Reichelt|Rei]]
| 0.41
|-
| BS170
| TO-92
| gs
| 2.0
| 60
| 0.3
| 0.83
| 5000
|
| [[Elektronikversender#Reichelt|Rei]]
| 0.13
|-
| BSN20
| SOT-23
| gs
| 1.8
| 50
| 0.18
| 0.35
| 6000
|
| [[Elektronikversender#Reichelt|Rei]]
| 0.092
|-
| BSS138
| SOT-23
| div
| 0.8-1.6
| 50
| 0.22
| 0.36
| ~2000
| Rds=1,4-3,6Ohm je nach Hersteller
| [[Elektronikversender#Reichelt|Rei]]
| 0.06
|-
| IRFP2907
| TO-247AC
| irf
| 4.0
| 75
| 209
| 470
| 4.5
|
| [[Elektronikversender#Reichelt|Rei]]
| 4.70
|-
| 2N7000
| TO-92
| ON
| 3.0
| 60
| 0.2
| 0.35
| 5000
|
| [[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#Kessler|Kes]]
| 0.13
|-
| BS107
| TO-92
| ON, Phi
| 3.0
| 200
| 0.25
| 0.35
| 6400/14000
| -
| [[Elektronikversender#Reichelt|Rei]]
| 0.18
|-
| BS108
| TO-92
| ON, Phi
| 2.0
| 200
| 0.25
| 0.35
| 8000
| -
| [[Elektronikversender#Reichelt|Rei]]
| 0.14
|-
| BUK100
| TO-220
| Phi
| 3.0
| 50
| 13.5
| 40
| 125
| Overload-Protection, ESD-Protection
| [[Elektronikversender#Reichelt|Rei]]
| 1.40
|-
| IRL3705N
| TO-220AB
| irf
| 2.0
| 55
| 89
| 170
| 10
| Qg=98nC
| [[Elektronikversender#Reichelt|Rei]]
| 1.20
|-
| BUZ72A
| TO-220
| Infineon
| 4.0
| 100
| 9.0
| 40
| 250
| -
| [[Elektronikversender#Reichelt|Rei]]
| 0.45
|-
| IRLZ34N
| TO-220
| irf
| 2.5
| 55
| 30
| 68
| 35.0
| Logic-Level
| [[Elektronikversender#Reichelt|Rei]]
| 0.42
|-
| IRF1404
| TO-220AB
| irf
| 4.0
| 40
| 202
| 333
| 4
| -
| [[Elektronikversender#Reichelt|Rei]]
| 1.65
|-
| IRL1004
| TO-220
| irf
| 2.7
| 40
| 130
| 200
| 6.5
| -
| [[Elektronikversender#Reichelt|Rei]]
| 1.25
|-
| IRL530
| TO220, D2Pack
| irf
| 2
| 100
| 15.0
| 88
| 160
|
| [[Elektronikversender#Reichelt|Rei]]
| 0.51
|-
| IRF830
| TO220AB
| irf
| 2.0-4.5
| 500
| 5.0
| 74
| 1400
|
| [[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#Kessler|Kes]]
| 0.57
|-
| IRF840
| TO220AB
| irf
| 2.0-4.0
| 500
| 8.0
| 125
| 850
|
| [[Elektronikversender#Reichelt|Rei]]
| 0.57
|-
| FDC645N
| SuperSOT-6
| Fairchild
| 1.5
| 30
| 5.5
| 0.8/1.6
| 30
| -
| [[Elektronikversender#csd-electronics|csd]] (a.A.), Far
| 0.7
|-
| BSP297
| SOT-223
| Siemens/Infineon
| 0.8-2.4
| 200
| 0.65
| 1.8
| 6000
| 200V UDS, SMT und LL (seltene Kombi)
| [[Elektronikversender#Farnell|Far]], [[Elektronikversender#Schuricht|Schu]], [[Elektronikversender#RS_Components|RS]]
| 0.56
|-
| IRF7455
| SO-8
| irf
| 4.5
| 30
| 15
| 2.5
| 7.5
|
| [[Elektronikversender#Kessler|Kes]]
| 1.04
|-
| SI4442DY
| SO-8
| vis
| 2.5
| 30
| 22
| 2.5
| 5/4.5V
|
| [[Elektronikversender#Kessler|Kes]]
| 1.64
|-
| IRLU2905
| TO251, DPack
| irf
| 2,0
| 55
| 42
| 1,5
| 27
| Logic-Level
| [[Elektronikversender#Reichelt|Rei]]
| 0.67
|-
| IRFD014
| HEXDIP/DIP4
| irf
| 2.0-4.0
| 60
| 1.7
| 1.3
| 200
|
| [[Elektronikversender#Conrad|Con]],[[Elektronikversender#Reichelt|Rei]]
| 0.52
|-
| IRFD024
| HEXDIP/DIP4
| irf
| 2.0-4.0
| 60
| 2.5
| 1.3
| 100
|
| [[Elektronikversender#Conrad|Con]],[[Elektronikversender#Reichelt|Rei]]
| 0.54
|-
| IRLD024
| HEXDIP/DIP4
| irf
| 1.0-2.0
| 60
| 2.5
| 1.3
| 100
|
| [[Elektronikversender#Conrad|Con]],[[Elektronikversender#Reichelt|Rei]]
| 0.47
|-
| IRLU3717
| I-Pak
| irf
| 2.0
| 20
| 120
| 1.5/89
| 4
| Qg=21nC
| [[Elektronikversender#Conrad|Con]]
| 0.86
|-
| IRFP3703
| TO-247AC
| irf
| 4.0
| 30
| 210
| 230
| 2.8
|
| [[Elektronikversender#Conrad|Con]]
| 5.08
|-
| IRF3710
| TO-220AB
| irf
| 5
| 100
| 57
| 200
| 23
|
| [[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#Conrad|Con]]
| 0.83

|}

(Tabelle mit Click im Kopfbereich sortierbar, a.A.=Auf Anfrage)

== N-Kanal J-FET==

{| border="1" class="sortable" id="nkanalmosfets"
|-
! Bezeichnung
! Package
! Hersteller
! UGS(co)/V
! UDS/V
! ID(max)/mA
! Lieferant
! Preis/EUR
|-
| BF245A
| TO-92
| diverse
| -2,2
| 30
| 6,5
| ??
| ??
|-
| BF245B
| TO-92
| diverse
| -3,8
| 30
| 15
| [[Elektronikversender#Reichelt|Rei]]
| 0,15
|-
| BF245C
| TO-92
| diverse
| -7,5
| 30
| 25
| [[Elektronikversender#Reichelt|Rei]]
| 0,15
|-
| BF246A
| TO-92
| diverse
| -4
| 25
| 80
| [[Elektronikversender#Reichelt|Rei]]
| 0,15
|-
| BF246B
| TO-92
| diverse
| -7
| 25
| 140
| [[Elektronikversender#Reichelt|Rei]]
| 0,17
|-
| BF246C
| TO-92
| diverse
| -12
| 25
| 250
| ??
| ??
|-
| BF511
| SOT-23
| diverse
| -1,5
| 20
| 7
| [[Elektronikversender#Reichelt|Rei]]
| 0,36
|-
| BFR30
| SOT-23
| diverse
| -4
| 25
| 10
| ?
| ?
|-
| BFR31
| SOT-23
| diverse
| -2
| 25
| 5
| ?
| ?
|}

(Tabelle mit Click im Kopfbereich sortierbar)

== FET-Paare ==

{| border="1" class="sortable" id="fetpaare"
|-
! Bezeichnung
! Package
! Hersteller
! UGS/V
! UDS/V
! ID/A
! P/W
! RDSon/mOhm
! Bemerkung
! Lieferant
! Preis/EUR
|-
| IRF7389
| SO-8
| IRF
| 3.0
| 30
| 7.3/-5.3
| 2.0
| 29/58
| P+N
| [[Elektronikversender#Reichelt|Rei]]
| 0.56
|-
| IRF7501
| micro8
| IRF
| 2,7
| 20
| 2,4
| ?
| 135/4,5V
| 2*N
| [[Elektronikversender#Kessler|Kessler]], [[Elektronikversender#Conrad|Con]]
| 1,64
|-
| IRF7506
| micro8
| IRF
| 4,5
| 30
| 1,7
| ?
| 270/10V
| 2*P
| [[Elektronikversender#Kessler|Kessler]], [[Elektronikversender#Conrad|Con]]
| 0,56
|-
| IRF7103
| SO-8
| IRF
| 4,5
| 50
| 2,3
| 2
| 130/10V
| 2*N
|[[Elektronikversender#Reichelt|Rei]], [[Elektronikversender#Conrad|Con]]
| 0,32
|-
| IRF7104
| SO-8
| IRF
| 4,5
| 20
| 2,3
| 2
| 250/10V
| 2*P
|[[Elektronikversender#Reichelt|Rei]]
| 0,32
|-
| IRF7316
| SO-8
| IRF
| 4,5
| 30
| 4,9
| ?
| 58/10V
| 2*P
|[[Elektronikversender#Reichelt|Rei]]
| 0,49
|-
| IRF7313
| SO-8
| IRF
| 4,5
| 30
| 6,5
| ?
| 46/4,5V
| 2*N
| [[Elektronikversender#Kessler|Kessler]], [[Elektronikversender#Conrad|Con]]
| 0,66
|-
| FDD8424H
| Dual DPAK4L
| Fairchild
| +-20/+-20
| 40/-40
| 9/-6,5
| 3,1
| 24/54 @+ -10V(GS) 30/70 @ + - 4,5V(GS)
| P+N
| [[Elektronikversender#Digi-Key|Digi-Key]]
| 0,73
|}

(Tabelle mit Click im Kopfbereich sortierbar)

== Mosfet-Treiber ==

Bitte falls möglich auch bei den MOSFET-Treibern einen Händler nennen!

{| border="1" class="sortable" id="fetpaare"
|-
! Bezeichnung
! Bemerkung
! Lieferant / Datenblatt
! Preis/EUR
|-
| IR2101
| High & Low-Side Driver, 130/270mA
| [[Elektronikversender#Conrad|Con]]
|-
| IR2104
| Half Bridge Driver, 130/270mA
| [[Elektronikversender#Conrad|Con]]
|-
| IR2110
| High & Low-Side Driver, 2A
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]]
| 1,55 EUR
|-
| IR2111
| Half Bridge Driver 200/430mA
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]]
| 1,10 EUR
|-
| IR2112
| High & Low-Side Driver, 200/420mA
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]]
| 1,45 EUR
|-
| IR2113
| High & Low-Side Driver, 2A
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]]
| 1,85 EUR
|-
| IR2117
| Single Channel Driver, 200/420mA (High-Side)
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]]
| 1,20 EUR
|-
| IR2121
| Low Side Driver, 1A/2A
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]]
|-
| IR2125
| Single Channel Driver, 1A/2A (High-Side, Current-Limiting)
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]]
|-
| IR2127
| Single Channel Driver, 200/420mA (High-Side) 3,3V und 5V Input Logic Kompatibel
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]]
|-
| IR2130
| 3-Phase Bridge Driver 200/420mA
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]]
|-
| IR2151
| Self Oscillating Half Bridge Driver
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]]
|-
| IR2153
| Self Oscillating Half Bridge Driver
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]]
|-
| IR2155
| Self Oscillating Half Bridge Driver
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]]
|-
| IR2181
| High & Low-Side Driver, 1.4A/1.8A
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]]
|-
| IR2183
| Half Bridge Driver, 1.4A/1.8A, Ton/Toff=180ns/220ns
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]] (günstiger als Reichelt)
|-
| IR2184
| Half Bridge Driver, 1.4A/1.8A, Ton/Toff=680ns/270ns
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]] (günstiger als Reichelt)
|-
| IR2136
| 3 Phase Driver, DIP28 SOIC28, 120/250mA, Ton/Toff=400ns/380ns
| [[Elektronikversender#Conrad|Con]]
|-
| ICL7667
| Dual Power MOSFET Driver (VCC = 4.5V-15V, 7 Ohm)
| [[Elektronikversender#Reichelt|Rei]]
|-
| HIP4080
| Full Bridge Driver & PWM Generator 80V 2,5A DIP20 SOIC20
| [http://www.intersil.com/data/an/an9324.pdf Datenblatt], veraltet->[http://www.intersil.com/data/fn/fn3658.pdf 4080A]
|-
| HIP4080A
| Full Bridge Driver 80V 2,5A DIP20 SOIC20
| [http://www.intersil.com/data/fn/fn3/fn3658/ Datenblatt]
|-
| HIP4081
| Full Bridge Driver 80V 2,5A DIP20 SOIC20
| [http://www.intersil.com/data/tb/tb321.pdf Datenblatt], veraltet->[http://www.intersil.com/data/fn/fn3/fn3178/fn3178.pdf 4081A]
|-
| HIP4081A
| Full Bridge Driver 80V 2,5A DIP20 SOIC20
| [http://www.intersil.com/data/fn/fn3/fn3659/ Datenblatt]
|-
| HIP4082
| Full Bridge Driver 80V 1,2A DIP16 SOIC16
| [http://www.intersil.com/data/fn/fn3676.pdf Datenblatt]; [http://www.intersil.com/data/an/an9611.pdf App-Note]
|-
| HIP4083
| 3 Phase High side N-channel MOSFET driver 80V 0.3A DIP16 SOIC16
| [http://www.intersil.com/data/fn/fn4223.pdf Datenblatt]
|-
| HIP4084
| 4 Phase Driver 80V 0.5A DIP28 SOIC28
|
|-
| HIP4086
| 3 Phase Driver 80V 0.5A DIP24 SOIC24
|
|-
| VNH3ASP30-E
| Automotive Fully Integrated H-Bridge Motor Driver (30A, 41V, STMicroelectronics)
| [[Elektronikversender#Spoerle|Spo]], ca. 320 EUR/100 Stk. ohne MwSt [http://www.st.com/stonline/stappl/productcatalog/app?path=/pages/stcom/PcStComPartNumberSearch.searchPartNumber&search=vnh3asp30-e Datasheet VNH3ASP30-E]
|-
| TC4451 / TC4452
| 12A High-Speed MOSFET Drivers, Microchip (8-Pin PDIP/SOIC, 8-Pin DFN, TO-220
| [[Elektronikversender#Farnell|Far]]
|-
| LM5104
| High Voltage Half-Bridge Gate Driver (SO8). Ist im MD23 Motorboard verbaut
| RS, [http://de.rs-online.com/web/search/searchBrowseAction.html?method=searchProducts&searchTerm=lm5104&x=0&y=0 Produktansicht]
| 5Stk 12,88 EUR -> 3 Eur Stk.
|}

== Anmerkungen ==

* UGS - minimale Gatespannung, bei welcher der MOSFET zu leiten anfängt (100µA..1mA, nicht genormt). Zur vollständigen Durchschaltung bei maximalem Strom braucht es höhere Spannungen.
* Logic Level - FET schaltet bei niedrigen Gatespannungen von typisch 4,5V (z.B. CMOS Logikpegel) hinreichend durch. Normale MOSFETs brauchen hierfür typisch 10V.
* UGS(co) - Gate Source Cut Off Spannung, bei welcher der Drainstrom ID eines JFETs praktisch Null ist. Die Messbedingung ist jedoch nicht genormt (0,5nA..200µA).
* N-Kanal MOSFETs mit niedrigem RDS,On sind technologisch einfacher herzustellen als P-Kanal MOSFETs. Deshalb gibt es bei P-Kanal keine so große Auswahl und oft werden Schaltungen angestrebt, in denen ausschließlich N-Kanal MOSFETs verwendet werden. Es gibt spezielle Treiberbausteine, die über eine Ladungspumpe für entsprechend hohe Gatespannung auch für die High-Side N-Fets sorgen ("Bootstrap Circuits", siehe Artikel [[Treiber]]).
* Bei der Dimensionierung ist zu beachten, dass die Stromangabe im allgemeinen für 25°C gilt. Geht man davon aus, dass der MOSFET mit maximal zulässigem Strom betrieben wird und mit passend dimensioniertem [[Kühlkörper]] ausgestattet ist, so beträgt die Sperrschichttemperatur bis zu 150°C, folglich gilt z.B. für den IRF540 nicht mehr 28A, sondern nur noch ca. 12-15A.
* Restströme sind auch stark von der Temperatur abhängig. Bei höherer Temperatur nehmen die Restströme exponentiell zu. So können bei 100°C durchaus 100 µA zwischen Source und Drain auch im gesperrten Zustand fließen. Bei 25°C ist dieser Reststrom meist bei 1µA spezifiziert. Real sind es meist weniger.
* Die Gate-Charge-Werte (s. Datenblatt) bestimmen, wie schnell das Gate beim Schalten umgeladen werden kann. Auch wenn MOSFETs stromlos den durchgeschalteten Zustand halten können, braucht man während des Umschaltvorganges einen Strom, der das Gate umlädt (ähnlich wie ein Kondensator). Je höher dieser Strom, um so schneller ist der Umschaltvorgang und um so geringer die Verlustleistung während dieser Phase. Leistungs-MOSFETs können bei höheren Frequenzen (>1KHz) oft nur mit höheren Gateströmen von 0,1A-2A sinnvoll geschaltet werden. Man kann das Gate also nicht direkt an einen Digitalpin anschließen. Man braucht einen [[MOSFET-Übersicht#MOSFET-Treiber | MOSFET-Treiber]]. Manche MOSFETs haben eine sehr geringe Total Gate Charge (z.B. 4-10nC). Diese können in gewissen Grenzen recht gut direkt an digitalen [[Ausgangsstufen Logik-ICs | Logikausgängen]] betrieben werden. Zur Abschätzung kann man sich merken: Wenn man das Gate eines MOSFETs mit einer Eingangskapazität von 1nF (~10nC) in 100ns auf 10V aufladen will, braucht man dazu 100mA.

== Lieferantenübersicht ==

* [[Elektronikversender#Reichelt|Rei]]<nowiki>chelt</nowiki>
* [[Elektronikversender#Conrad|Con]]<nowiki>rad</nowiki>
* [[Elektronikversender#Kessler|Kes]]<nowiki>sler</nowiki>
* [[Elektronikversender#csd-electronics|csd]]<nowiki>-electronics</nowiki>
* [[Elektronikversender#Farnell|Far]]<nowiki>nell</nowiki> (nur gewerbliche Kunden oder Studenten)
* [[Elektronikversender#Schuricht|Schu]]<nowiki>richt</nowiki>
* [[Elektronikversender#RS_Components|RS]]
* [[Elektronikversender#Spoerle|Spo]]<nowiki>erle</nowiki>
* HBE-Shop_FARNELL-Fachhändler, auch als nichtgewerblicher Kunde

== Herstellerübersicht ==

* [irf] [http://www.irf.com International Rectifier]
* [Siliconix] [http://www.vishay.com/company/brands/siliconix/ Vishay Siliconix]

== Links ==
* [[FET]]
* [[IGBT]]
* [[Treiber]]

== Weblinks ==
* [http://www.sprut.de/electronic/switch/nkanal/nkanal.html N-Kanal MOSFET leicht erklärt bei sprut.de]
* [http://www.sprut.de/electronic/switch/pkanal/pkanal.html P-Kanal MOSFET leicht erklärt bei sprut.de]
* [http://elektronik-kompendium.de/sites/bau/0510161.htm MOSFET im ElKo]
* [http://elektronik-kompendium.de/public/schaerer/battoff.htm Abschaltverzögerung beim ElKo]
* [http://elektronik-kompendium.de/sites/bau/0207011.htm FET beim ElKo]
* [http://de.wikipedia.org/wiki/Mosfet MOSFET bei Wikipedia]
* [http://www.irf.com/product-info/auto/autogdic.html IR21xx Familienvergleich]

[[Category:Bauteile]]