Frage zu Remote-Control / NEC-Code

Tom schrieb:
> Hallo, ich möchte mir zu Fernsteuerzwecken einen IR-Sender für meinen
> Receiver basteln. Die Original-Fernbedienung sendet im NEC-Code. Zum
> Protokoll-Nachbau hier die Frage wie kritisch die Einhaltung der 38 kHz
> Carrierfrequenz  sowie die Einhaltung des 1:2 Tastverhältnisses ist ?

Normalerweise ist das nicht soooo kritisch, kommt aber auch auf Deinen 
Receiver an.

> Und welche IR-Dioden werden hier üblicherweise verwendet ?

Schau Dir mal den Abschnitt

  http://www.mikrocontroller.net/articles/IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder

aus dem IRMP-Artikel an. Da ist eine simple Beispiel-Schaltung 
enthalten.

Unter

http://www.mikrocontroller.net/articles/IRMP#Hardware_.2F_IRMP-Projekte

findest Du auch noch einen Link zum IR-Decoder/Encoder von Klaus 
Leidinger, welcher IRMP/IRSND zum Empfang und Senden einsetzt. Da ist 
die Sende-Schaltung etwas aufwendiger, hat aber den Vorteil, dass bei 
einem Softwarefehler (Signal liegt nicht gepulst, sondern im 
Dauerzustand an der Fotodiode) Dir nicht die Fotodiode durchbrennt...

Gruß,

Frank

Tom schrieb:
> Danke Frank, mehr kann man sich als Support ja gar nicht wünschen :-)

:-)

> Eine spezielle Frage dann aber doch noch! Bei der Analyse der Signale
> meiner FB habe ich festgestellt, daß der Custom-Code im 2.Byte an
> Position C'3 identisch mit C3 im 1.Byte ist (sollte doch eigentlich
> invertiert sein wie die anderen auch). Beim Data-Code passt alles. Ist
> das irgendeine besondere Spezialität der hier verwendeten NEC-Codierung?

Es gibt wohl einige Hersteller, die das NEC-Prtokoll für ihre eigene 
Zwecke leicht abwandeln. Gutes Beispiel ist die APPLE-Fernbedienung, 
welche auch das NEC-Protokoll benutzt, aber als 3. Byte (in welchem 
eigentlich das Kommando-Byte steht) immer die Bitfolge 11100000 sendet 
und erst im 4. Byte (welches normalerweise das invertierte Kommando ist) 
das eigentliche Kommando-Byte aussendet.

Nun zurück zu Deiner Frage. Das NEC-Protokoll sieht eigentlich vor:

8 Adress-Bits + 8 invertierte Adress-Bits + 8 Kommando-Bits + 8 
invertierte Kommando-Bits

Es gibt aber noch das sogenannte NEC-extended-Protokoll, welches 
folgendermaßen aussieht:

16 Adress-Bits + 8 Kommando-Bits + 8 invertierte Kommando-Bits

Das zweite Byte ist also nicht zwingend das invertierte erste Byte!
Daher prüfe ich in meiner Empfangsroutine von IRMP die Invertierung für 
die Adresse nicht, sondern fasse prinzipiell die ersten beiden Bytes als 
Komplett-Adresse auf.

Ich prüfe aber sehr wohl die Invertierung des dritten Bytes gegen das 
vierte Byte. Ausnahme: APPLE-Protokoll, siehe oben ;-)

Auch solltest Du Dich mit den sog. NEC-Repetition-Frames 
auseinandersetzen. Die meisten NEC-kompatiblen Fernbedienungen 
wiederholen nicht den kompletten Frame, wenn man eine Taste länger 
drückt, sondern senden einen ganz kurzen Frame aus, der lediglich aus

   9000µs Puls, 2250µs Pause, 560µs Puls, ~100ms Pause

besteht.

Eine Aufzählung der mir bekannten IR-Protokolle findest Du unter

  http://www.mikrocontroller.net/articles/IRMP#Protokolle

Dort habe ich versucht, auch auf die Eigenarten einzugehen.

Gruß,

Frank

P.S.
Falls es Dich interessiert: erst heute habe ich von einer weiteren 
Besonderheit erfahren: Eine Skymaster-FB sendet grundsätzlich immer 
einen NEC-Frame gefolgt von einem NEC-Repetition-Frame. Fehlt dieser, 
reagiert der Empfänger im Skymaster-Gerät nicht.

Links dazu:

Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"
Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"
Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"
Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"
Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"

Tom schrieb:
> Ja dann wird's wohl NEC-extended sein und die anderen Adressbits des
> zweiten Bytes sind quasi nur zufällig invertiert.

Ja, so wird es sein, über die "Zufälligkeit" wird man wohl streiten 
können ;-)

> Deine Aussage zu den NEC-Repetition-Frames kann ich auch bestätigen.
> Da es aber nur um eine einfache, AVR-ferngesteuerte Programmierung von
> Aufnahmen gehen soll ist das Thema zum Glück ohne Belang für mich.

Na dann ist ja alles easy.

> Die Vielfalt der Codierungen ist schon erschreckend. Gibt es dafür
> irgendeine technische Begründung oder gehts dabei immer nur um die
> bewußte Pflege von Inkompatibilitäten?

Technische Gründe sehe ich da nicht. Jeder Hersteller will da wohl sein 
eigenes Süppchen kochen.

Es gibt zwar Standardisierungsbemühungen der Japan's Association for 
Electric Home Application für ein gemeinsames IR-Protokoll (Stichwort 
"Kaseikyo"), aber richtig durchgesetzt hat sich trotz der Mitgliedschaft 
solcher namhaften Firmen wie Panasonic, Technics und Denon das 
Kaseikyo-Protokoll nicht. Ich selbst habe so eine FB noch nicht in der 
Hand gehabt. Es muss sie aber wohl geben, denn ein IRMP-Anwender hatte 
mir mal so eine Kaseikyo-Scan-Datei, die er mit IRMP erstellt hat, 
zugeschickt.

Gruß,

Frank

Kramlade schrieb:

> Hallo UKW, ist dir eine Beschreibung des Protokolls bekannt?

Siehe:

http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail
http://www.mikrocontroller.net/articles/IRMP#Literatur

> Ich möchte einen Encoder schreiben.

Gibt es schon:

http://www.mikrocontroller.net/articles/IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder

IRSND kann (fast) alles, was IRMP decodieren kann, wieder encodieren.

Gruß,

Frank