www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Frage zu Remote-Control / NEC-Code


Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ? 
Und welche IR-Dioden werden hier üblicherweise verwendet ? Danke 
schonmal, Tom.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

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

Unter

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

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

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Gruß Tom

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja dann wird's wohl NEC-extended sein und die anderen Adressbits des 
zweiten Bytes sind quasi nur zufällig invertiert. Es handelt sich 
übrigens um einen Opticum HD-C10 mit der Adresse 04F3.

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.

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?

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: DE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi !

Eine schöne Beschriebung des NEC Protokolls gibt es auch hier:

http://www.sbprojects.com/knowledge/ir/nec.htm

Es lohnt sich.

DE

Autor: Kramlade (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> 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.

Hallo UKW, ist dir eine Beschreibung des Protokolls bekannt? Ich möchte 
einen  Encoder schreiben.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kramlade schrieb:

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

Siehe:

http://www.mikrocontroller.net/articles/IRMP#Die_I...
http://www.mikrocontroller.net/articles/IRMP#Literatur

> Ich möchte einen Encoder schreiben.

Gibt es schon:

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

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

Gruß,

Frank

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.