Forum: Projekte & Code IRMP - Infrared Multi Protocol Decoder

Sehr geil, ich werde mal schauen, ob ich es zum laufen bekomme. Ich habe 
eine ähnliche Sache gebaut: Eine lernbare Fernbedienung.

Ich verwende jedoch keine 10000Hz Routine, die die Sachen einscannt, 
sondern ich lege den IR Eingang auf den externen IRQ0 Pin und erkenne 
das Ende des IR Codes mit dem ISR(TIMER1_OVF_vect). Die Hauptroutine hat 
in dieserm Fall gar nichts mehr zu machen und kann sich auf etwas ganz 
anderes konzentrieren, man spart sich die Preprozessor-Konstante:

int main(){
    TCNT1 = 0;          //Timer1 gestoppt lassen, bei 65ms Überlauf
    IRQ0_aktivieren();    //INT0_vect wartet auf erste IR Signal flanke


    while (etwas_empfangen){
        empfangspuffer_auswerten();
        ausgabe_auf_dem_lcd_display();
        etwas_empfangen = 0;
    }
}

ISR(INT0_vect){
    empfangspuffer(position) = TCNT1;   //gemessene Flankenlänge
                                        // abspeichern
    position++          //für die nächste Abspeicherung vorbereiten
    TCNT1 = 0;                //Timer auf 0 zur Messung der nächsten
                              //Flankenlänge
    Timer1_aktivieren();
}

ISR(TIMER1_OVF_vect){         //IR Ende wenn 65ms keine Flankenänderung
    Timer1_deaktivieren();
    etwas_empangen = 1;       //nun kann main es auswerten
    empfangspuffer(position) = 60000  //IR Ende Markierung in den Puffer
                                      // schreiben. Eindeutig, weil
                                      //keine IR Flanke wäre 60ms lang
}


Der Empfangspuffer sieht dann so aus:

17382   //erste Messung ist müll, je nach dem wann erste IR Flanke kam
09000   //Start Bit 9000ms
00560   //erstes Pausensignal 560ms
00560   //erstes Datenbit
00560   //Pausensignal zum Datenbit
01200   //zweites Datenbit
00560   //Pausensignal zum Datenbit
.
.
.
60000   //Ende Markierung

Die Auswertung ist dann einfach, wie z.B. Du sie selbst geschrieben 
hast. Ich selbst habe keine Auswerung geschrieben, sondern ich lege die 
Daten in einem EEPROM ab und sende sie auf Befehl wieder raus:

int main(){
    pin_ir = 0;
    position ++        //erste Müllmessung im Puffer ignorieren
    TCNT1 = empfangspuffer(position);  //Timer1 füttern
    position ++        //Puffer auf nächste Position
    Timer1_aktivieren();

    while (1);               //keine weiteren Aktionen mehr,
                             // sendung erfolgt automatisch über IRQ
}

ISR(TIMER1_OVF_vect){
    port_ir ^= (1<<pin_ir);           //IR Ausgang einfach nur toggeln
    TCNT1 = (65535-empfangspuffer(position));     //Timer neu füttern
    if (empfangspuffer(position) == 60000) timer1_deaktivieren;
    position++           //Puffer auf nächste Position
}

eku schrieb:
> In Deiner ISR wird bereits das Protokoll erkannt. Ist das sinnvoll?
> Könnte man nicht den IR-Eingang im konstanten Timerraster abtasten und
> das Ergebnis in eine FIFO legen.

Das verbraucht aber dann evtl. ne Menge Speicherplatz. Wenn ich da ans 
Kaseikyo-Protokoll mit 48 Bit denke, müsste ich 48 x 2 = 92 Bytes haben, 
um die Timingwerte für jede Hell-/Dunkelsequenz zu speichern.

> Eine Dekoderfunktion sammelt die Werte
> aus der FIFO, erkennt das Protokoll und dekodiert die Sequence. Worin
> liegt der Vorteil Deiner Implementierung?

Der Vorteil liegt beim niedrigen Speicherbedarf. Nach dem eingetroffenen 
Startbit wird das Protokoll sofort erkannt und dann werden die weiteren 
Hell-Dunkelphasen nur noch als einzelne Bits gespeichert, weil sich die 
ISR aufs Protokoll "eingeschossen" hat. So kommt man mit 5 Bytes aus, in 
denen alles nötige gespeichert ist - hier als struct definiert:

1

typedef struct

2

{

3

  uint8_t   protocol;          // protocol, i.e. IRMP_NEC_PROTOCOL

4

  uint16_t  address;           // address

5

  uint16_t  command;           // command

6

} IRMP_DATA;

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

1

   if (irmp_data.protocol == IRMP_NEC_PROTOCOL &&     // NEC-Protokoll

2

       irmp_data.address == 0x00FF)                   // Adresse 0x00FF

3

   {

4

      switch (irmp_data.command)

5

      {

6

         case 0x0001: key1_pressed(); break;          // Taste 1

7

         case 0x0002: key2_pressed(); break;          // Taste 2

8

         ...

9

         case 0x0009: key9_pressed(); break;          // Taste 9

10

      }

11

   }

Die Werte muss man natürlich für eine unbekannte Fernbedienung einmal 
auslesen und dann über ein UART oder LC-Display ausgeben, um sie dann im 
Programm hart zu kodieren. Oder man hat eine Anlernroutine, wo man 
einmal die gewünschten Tasten drücken muss, um sie anschließend im 
EEPROM abzuspeichern.

Einfacher gehts doch nicht, oder?

Gruß,

Frank

Sebastian___ schrieb:
> Hallo Frank,
> wie erkennst du zb wenn per Fernbedienung ein Lautstärkekomando kommt.
> Soweit ich das bei deinem Code erkennen konnte wird der empfangene Code
> nur 1x ausgewertet.

Der Code wird lediglich innerhalb einer gewissen Zeitspanne ignoriert, 
nämlich innerhalb der Wiederholungszeitspanne.

> Wie geht das beim Sircs Protokoll? ein Kommando wird 3x wiederholt, nach
> der wiederholung müsste man das kommando erneut auslösen.

Nein, soviel ich weiß, wird bei SIRCs nach den Wiederholungen dann das 
Kommando erneut gesandt, wenn Du die Taste gedrückt hältst. Aber erst 
nach einer gewissen Pause, die wesentlich größer ist als die Zeitspanne 
zwischen 2 Wiederholungen. Und dann greift die ISR wieder zu.

Gruß,

Frank

eku schrieb:
> Das habe ich soweit verstanden. Würdest Du die Daten jedes Protokolls
> in einer Struktur zusammenfassen, bräuchtest Du nur einen Zeiger auf
> die jeweilie Struktur (=Protokoll) setzen und nicht so viele statisch
> Variablen in der ISR initialisieren. [...]

Stimmt.

> [...] Die einen Indirektion bei der
> Adressierung sollte auf Grund der anderen Ersparnis nicht ins Gewicht
> fallen. Der Code würde noch dazu leserlicher.

Hm, ob ich da tatsächlich was einspare? Werde mir den Code diesbezüglich 
demnächst nochmal anschauen.

Gruß,

Frank

eku schrieb:
> Mir gefällt dieses Ping-Pong zwischen ISR und main() nicht. Die ISR
> wartet mit der Erkennung bis main() vorheriges abgeholt hat. Eine
> FIFO entkoppelt die Routinen.

Die ISR wartet nicht (eine ISR sollte niemals warten), sie ignoriert 
halt IR-Befehle, bis die main das letzte Kommando abgeholt hat.

Wenn der Mensch an der Fernbedienung schnell hintereinander 2 Tasten 
drückt, dann willst Du das tatsächlich durch ein FIFO puffern? Zwischen 
den beiden Tastendrücken vergeht für den µC eine Ewigkeit.... bis dahin 
hat er die erste Taste längst abgearbeitet.

Bei einer RS232 halte ich ja ein FIFO für sinnvoll, aber für eine IR-FB? 
Willst Du etwa mit einem IR-Sender Daten mit konstanter Geschwindigkeit 
übermitteln? Ja, dann wäre das sinnvoll. Sonst nicht - für mich 
jedenfalls.

Gruß,

Frank

Sebastian___ schrieb:
> bei SIRC  ist es jeden fall so das man da nicht zwischen den Repeats
> unterscheiden kann.
> Taste kurz gedrückt = 3x command im 45ms Raster.
> Taste länger gedrückt = nx command im 45ms Raster.

Hm, das ist wirklich blöd. Leider habe ich keine Sony-Fernbedienung, um 
das zu testen, hatte da lediglich die Scans von Vlad Tepesch.

Ich habe da gerade nochmal in den Source geschaut:

1

#define SIRCS_REPETITION_TIME                 (uint16_t)(F_INTERRUPTS * 50.0e-3 + 0.5)          // repetition after ~45-50 msec

2

...

3

        // if SIRCS protocol and the code will be repeated inside of 50 ms, we will ignore it.

4

        if (irmp_protocol != IRMP_SIRCS_PROTOCOL || last_irmp_command != irmp_tmp_command || repetition_counter > SIRCS_REPETITION_TIME)

5

...

Wenn also die Zeiten bei heruntergedrückter Taste tatsächlich nicht 
größer sind als die Wiederholzeit, muss man wirklich erst die Taste 
loslassen....

Dumm gelaufen. Man könnte natürlich bis 3 zählen und die vierte 
Wiederholung wieder zulassen. Fragt sich nur, ob das definitiv immer so 
ist, dass Sony-Fernbedienungen grundsätzlich jeden Code 3 mal 
wiederholen.

Gruß,

Frank

Michael M. schrieb:
> um sowas zu testen und solche codes zu simulieren würde ich einen
> simulator für AVRs benutzen - namentlich proteus isis.

Ist erstmal eine gute Idee, aber der Code von irmp trägt den Simulator 
in sich mit :-) Ich kann dem Code (wenn man ihn unter Linux übersetzt) 
einfach eine Datei zum Fraß vorwerfen. Diese Datei kann ein echter Scan 
einer Fernbedienung sein oder eine künstlich erzeugte.

Ein weiterer Simulator wäre daher kein Gewinn für mich - sehe ich 
jedenfalls momentan so. Und er beantwortet mir auch nicht die Frage, ob 
jede Sony-Fernbedienung den Code immer genau 3x wiederholt.

Trotzdem danke für den Tipp, vielleicht kann ich ihn bei Gelegenheit für 
ein ganz anderes Projekt verwenden :-)

@Sebastian___

Ich werde einfach mal meine SIRCS-Scandatei nehmen, ein Telegramm 
(sprich Zeile) ver-N-fachen mit dem Editor, wobei ich eine Pause von 
45ms einbaue. Dann den Code dahingehend ändern, dass er die 4te, 7te, 
10te (usw) Wiederholung wieder auswertet statt sie zu ignorieren.

Wäre Dir damit geholfen?

Gruß,

Frank

Ich habe mir gerade nochmal die gängigen Quellen angeschaut, wo SIRCS 
als Code beschrieben wird. Nirgendwo steht da was von 2 weiteren 
automatischen Wiederholungen (also 3 Telegramme), immer liest man nur 
solches wie dieses:

 "Commands are repeated every 45ms(measured from start to start) for as 
long as the key on the remote control is held down."

Ich habe mir daraufhin nochmal die Scan-Datei Sony_Bravia_RM-ED0009.txt 
näher angeschaut. Da sind die Wiederholungen auch drin, aber offenbar 
nicht für alle Tasten wird wiederholt, z.B.

power, rot, gelb, grün, blau, up, down, left, right, vol+, vol-: keine 
Wiederholung

theatre, digital, tools, buch(?): 2 Wiederholungen, also insg. 3 
Telegramme

Rätselhaft das ganze...

Gruß,

Frank

Ich kann das ganze ja bei gelegenheit nochmal wiederholen.

vielleicht sind auch zu viele einsen zwischen den wiederholungen, so 
dass meine Scan-Routine, den scan schon vorher abgebrochen hat.
ich hatte da 200 samples gewartet

wenn man sich die wiederholten scans aber anschaut, sieht man, dass die 
wiederholungen nach 190 einsen kommen.
wenn das Kommando also am Ende ein paar einsen hat, dann wird die 
Abrruchbedingung überschritten.


Pack doch den code zum Scannen nochmal mit rein, dann können die anderen 
auch ein paar Scans machen.

Vlad Tepesch schrieb:

> Pack doch den code zum Scannen nochmal mit rein, dann können die anderen
> auch ein paar Scans machen.

Ich war einfach bisher zu faul, den Code fürs Scanning aus dem 
WordClock-Code zu extrahieren, so dass er isoliert zur Verfügung 
steht...
gebe ich ja zu :-)

Hole ich jetzt nach.

Es wäre klasse, wenn die anderen ihre Fernbedienungen, die bisher nicht 
unterstützt werden, einscannen würden. Dann kann ich den Code diesbzgl. 
erweitern.

Gruß,

Frank

Aktualisierung
Die IRMP-Software kann unter IRMP | Download
heruntergeladen werden.



Vlad Tepesch schrieb:

> Pack doch den code zum Scannen nochmal mit rein, dann können die anderen
> auch ein paar Scans machen.

Okay, ich habe nun die nötigen Routinen aus dem WordClock-Source 
extrahiert und direkt mit in irmp.c integriert.

In der Zeile

1

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

kann nun das Logging eingeschaltet werden, wenn man den Wert auf 1 
setzt.

Dann werden die Hell- und Dunkelphase auf dem UART mit 9600Bd 
ausgegeben:

1=Dunkel, 0=Hell. Eventuell müssen dann die Konstanten in den Funktionen 
uart_init() und uart_putc() angepasst werden, kommt auf den verwendeten 
AVR-µC an.

README.txt ist entsprechend angepasst - am Ende der Datei.

Getestet habe ich es allerdings noch nicht... sollte aber passen.

Gruß,

Frank

Sebastian___ schrieb:
> Ich bin gerade dabei den IRMP Code auf Interrups umzubauhen.

Verstehe ich jetzt nicht so recht. Das Ding läuft doch auf 
Interrupt-Basis, nämlich einem Timer-Interrupt.

> Die Zeitbasis commt aus einem Counter mit 25Khz (per IRQ).
> Somit kann das Polling entfallen und man hat eine Speichersparende
> lösung.

Warum ist das speichersparend?

Gruß,

Frank

Sebastian___ schrieb:
> Daher ist es meiner meinung nach besser einen richtigen Init zu nehmen
> der flankengesteuert reagiert.

Ahso, flankengetriggert. Ich hatte da eben was von Zeitbasis gelesen... 
deshalb hatte ich das nicht direkt kapiert. Aber klar, Du brauchst bei 
jeder Flanke auch die dazugehörige Zeit.

Klingt ja ganz gut, bin gespannt.

Aber ich sehe da immer noch nicht die Speichereinsparung, ich lass mich 
da von Dir überraschen ;-)

Gruß,

Frank

Sebastian___ schrieb:
> die Defines für das erkennen der start Bits haben eine zu große
> Toleranz, wenn man die für :
> [...] auf 20% setzt, geht die Protokollerkennung.

Super, danke für den Tipp! Werde ich anpassen.

Gruß,

Frank

Frank M. schrieb:
> Sebastian___ schrieb:
>> die Defines für das erkennen der start Bits haben eine zu große
>> Toleranz, wenn man die für :
>> [...] auf 20% setzt, geht die Protokollerkennung.
>
> Super, danke für den Tipp! Werde ich anpassen.

Habe ich gerade mal gemacht und gegen die Scan-Datei
Samsung_DVD_Rec_00062C.txt laufen lassen: Bei 20% Toleranz für SAMSUNG 
erkennt die Routine keine Samsung mehr. Selbst bei 40% klappt das nicht 
mehr, erst bei 50% geht es. Das liegt wohl daran, dass Vlads Samsung-FB 
stark von den Timingwerten abweicht... Die 50%, die ich da eingestellt 
hatte, kamen nicht von ungefähr ;-)

Das heisst: Wir haben hier einen Konflikt, beide Startbits (von Samsung 
und Matsushita) sind ähnlich lang - jedenfalls innerhalb der großzügigen 
Toleranzen von 50%.

Wenn Du in der Zeile

#define IRMP_SUPPORT_SAMSUNG_PROTOCOL      1

die 1 auf 0 setzt, sollte die Matsushita auch erkannt werden - ohne 
Änderung der Toleranzen. Hat natürlich den Nachteil, dass immer nur eins 
von beiden Protokollen gleichzeitig erkannt werden kann....

Es gibt einen großen Unterschied zwischen Samsung und Matsushita:

Die Anzahl der Bits pro Telegramm und das Sync-Bit mit sehr langer 
Dunkelphase zwischendrin bei der Samsung, d.h. nach den ersten 16 Bit. 
Damit kann man beide Protokolle definitiv auseinanderhalten.

Kannst Du mir so eine Scan-Datei für die Matsushita erstellen? Dann 
würde ich die Unterscheidung anhand des Sync-Bits einbauen.

Gruß,

Frank

Sebastian___ schrieb:
> Das ist leider nicht so einfach mit den Daten schicken. Da ich nur
> kleine Teile aus deinem Code nutze und die Codes auf einem Oszi anschaue
> und mit einer Universalfernbedinung teste.

Auch gut, dann erstelle ich die Matsushita-Daten künstlich. Die 
Timing-Daten zur Matsushita-FB kannst Du aber schon so bestätigen, oder?

Gruß,

Frank

hast du die Abbruchbedingung für die Scans ein wenig angehoben?
200 scheint ja zu kurz zu sein.

Vlad Tepesch schrieb:
> hast du die Abbruchbedingung für die Scans ein wenig angehoben?
> 200 scheint ja zu kurz zu sein.

Nein, habe ich nicht gemacht. Werde ich nachholen.

Gruß,

Frank

IR schrieb:
> Ich fände es sehr hilfreich, wenn du den Code mit ein paar kleinen
> Erläuterungen als Artikel hier mit reinstellst und am Besten im "Word
> Clock" Artikel darauf verweist. Das ganze kann man ja schon als
> eigenständig betrachten.

Ich hatte den Code für die IR-Decodierung absichtlich isoliert und hier 
reingestellt, damit er unabhängig vom WordClock-Projekt Verwendung 
findet.

Gern lege ich einen Artikel an, hatte mir Vlad sowieso schon 
vorgeschlagen ;-)

Mache ich am Wochenende.

Gruß,

Frank

Es gibt nun einen eigenen Artikel zu IRMP. Das hat auch den Vorteil, 
dass die Software zum Download immer auf dem neuesten Stand ist und hier 
der Leser nicht immer erst alle Beiträge lesen muss, um die letzte 
Version zu finden.

Artikel-Link: http://www.mikrocontroller.net/articles/IRMP

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

Software-Stand: 05.02.2010

In dieser Version wurde auch der Konflikt zwischen dem Samsung- und dem 
Matsushita-Protokoll ausgeräumt, beide Protokolle werden nun ohne 
Klimmzüge zuverlässig erkannt.

@Vlad: Sorry, die Scan-Länge habe ich noch nicht vergrößert, hole ich 
nach.

Gruß,

Frank

Hi!

Erstmal: danke für dieses schöne Stück code :)

Damit kann ich endlich die Reichelt-RGB-Fernbedienung lesen, die ich mir 
bestellt habe ;)
Leider (bestimmt mache ich irgendwas falsch) kann ich mit der IRMP-Lib 
meine "alte" rc5-Fernbedienung nichtmehr auslesen, die ich bisher für 
meine Steuerung verwendet habe. Gibt es eine möglichkeit, dass das alte 
rc5-protokoll auch von der IRMP-Lib erkannt wird?

Gruß, DiPi

p.s.: bisher habe ich diese rc5-routine benutzt: 
Beitrag "Fernbedien RC5 Empfänger"

Di Pi schrieb:

> Damit kann ich endlich die Reichelt-RGB-Fernbedienung lesen, die ich mir
> bestellt habe ;)

Sag mal bitte die Bestellnummer, interessiert mich immer wieder, welche 
FBs damit so laufen...

> Leider (bestimmt mache ich irgendwas falsch) kann ich mit der IRMP-Lib
> meine "alte" rc5-Fernbedienung nichtmehr auslesen, die ich bisher für
> meine Steuerung verwendet habe. Gibt es eine möglichkeit, dass das alte
> rc5-protokoll auch von der IRMP-Lib erkannt wird?

RC5 wird von IRMP nicht unterstützt, weil ich RC5 als obsolet ansehe, 
sorry. Wenn Du mir einen triftigen Grund nennst, überlege ich es mir 
nochmal ;-)

Gruß,

Frank

Frank M. schrieb:

> RC5 wird von IRMP nicht unterstützt, weil ich RC5 als obsolet ansehe,
> sorry. Wenn Du mir einen triftigen Grund nennst, überlege ich es mir
> nochmal ;-)
>
Stimmt schon, wenn man sich so umsieht bentutzen nur noch die "soliden 
alten deutschen Marken" den RC5 Code. Auf der anderen Seite, ist er sehr 
verbreitet gewesen und deswegen sind Massenhaft gebrauchte RC5 im 
Umlauf, die noch gut weiter verwendet werden könnten. Das spricht für 
RC5.
Ist aber auch so ein Super "gemeinnütziges Projekt".

GrußWilli

Ich meinte genau die Remote, die Michael M. genannt hat.

Es wäre eine schöne sache, wenn neben den sechs bereits implementierten 
Protokollen auch noch RC5 vertreten wäre (genauso ein- und 
ausschaltbar), um letztlich so gut wie alle gängigen Protokolle mit 
einer Lib abzudecken.
Dem Programmierer ist dann überlassen, welche Protokolle "gehört" werden 
sollen.

Viele Grüße, DiPi

Stimmt: Es wird code 2 (NEC, Pioneer, JVC, Toshiba, NoName etc.) 
erkannt.

Michael M. schrieb:
> ich vermute übrigens, die RGB FB sendet NEC-code.
> hier mal ein csv-file und bild mit einem scan der off-taste. sample rate
> 50kHz.
> T->A: 9,14ms
> A->B: 4,42ms
> B->C: 660us

Ja, das ist das NEC-Protokoll.

Ich habe nun die einzelnen Protokolle vom Timing her im IRMP-Artikel 
dokumentiert. Wäre nett, wenn ich Dein Bildchen da mit reinhängen dürfte 
:-)

Gruß,

Frank

Michael M. schrieb:
> Frank M. schrieb:
>> Ich habe nun die einzelnen Protokolle vom Timing her im IRMP-Artikel
>> dokumentiert. Wäre nett, wenn ich Dein Bildchen da mit reinhängen dürfte
>> :-)
> klar, gerne!

Danke, ist eingebaut:

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

Gruß,

Frank

Michael M. schrieb:
> ui, da hat es aber eine prominente position bekommen =)

Ich wollte ein wenig Farbe in den Artikel bekommen ;-)

Aber das Bild ist zweimal drin, weiter unten nochmal miniaturisiert 
unter Angabe Deiner gemessenen Zeiten.

Gruß,

Frank

Michael M. schrieb:
> in dem bild "Anschluß eines IR-Empfängers an µC" ist der im datenblatt
> vorgeschlagene RC tiefpass falsch aufgebaut.

Du hast Recht: eigentlich gehört der Kondensator direkt zwischen Pin1 
und Pin2 des TSOP, mein Fehler.

> der aufbau in dem bild dürfte die empfindlichkeit um einiges
> verschlechtern.

Davon ist witzigerweise nichts zu merken ;-) Genau mit diesem Fehler 
habe ich mir einen IR-Empfänger aufgebaut, der bei einer Distanz von 5m 
überhaupt keine Probleme hat.

Trotzdem danke für den Tipp, ich habe das Schaltbild korrigiert (evtl. 
muss man einmal im Browser Refresh drücken). Ich werde das bei 
zukünftigen Schaltungen berücksichtigen.

Gruß,

Frank

Werden jetzt auch Wiederholungen beim NEC-Protokoll erkannt? (der 
Hinweis auf eine noch fehlende Implementierung ist weg.)

Di Pi schrieb:
> Werden jetzt auch Wiederholungen beim NEC-Protokoll erkannt? (der
> Hinweis auf eine noch fehlende Implementierung ist weg.)

Nein, der Hinweis ist mir leider beim Bearbeiten der Tabellen 
flötengegangen. Ist nun wieder drin.

Aber bis jetzt habe ich noch keine FB in der Hand gehabt, wo wirklich 
die spezielle Wiederholungs-Sequenz augesandt wird. Bei meiner Toshiba-, 
Xoro- und Media-Player-Fernbedienung, die allesamt das NEC-Protokoll 
benutzen, wird davon jedenfalls kein Gebrauch gemacht. Stattdessen wird 
einfach der jeweilige Code solange wiederholt, bis man die Taste 
loslässt.

Die Sache mit Erkennung der Wiederholungssequenz steht trotzdem auf 
meiner TODO-Liste.

Gruß,

Frank

Di Pi schrieb:
> Es wäre eine schöne sache, wenn neben den sechs bereits implementierten
> Protokollen auch noch RC5 vertreten wäre (genauso ein- und
> ausschaltbar), um letztlich so gut wie alle gängigen Protokolle mit
> einer Lib abzudecken.
> Dem Programmierer ist dann überlassen, welche Protokolle "gehört" werden
> sollen.

Der Meinung bin ich auch. Das sollte ja kein großer Mehraufwand sein und 
macht das Projekt auf jeden Fall nicht uninteressanter.

Frank M. schrieb:
> Aber bis jetzt habe ich noch keine FB in der Hand gehabt, wo wirklich
> die spezielle Wiederholungs-Sequenz augesandt wird.

Meine "Cyberhome" (alter DVD-Player) sendet sie.

Michael K. schrieb:
> [RC5]
> Der Meinung bin ich auch. Das sollte ja kein großer Mehraufwand sein und
> macht das Projekt auf jeden Fall nicht uninteressanter.

Leider ist das schon einiges an Mehraufwand, denn RC5 passt überhaupt 
nicht in das Schema rein, wie die meisten anderen Protokolle aufgebaut 
sind. RC5 ist bi-phasen-kodiert (Manchester) und damit kann man die Bits 
nicht in das Schema:

0-Bit: m µsec hell, n µsec dunkel
1-Bit: x µsec hell, y µsec dunkel

pressen. Sondern:

0-Bit: m µsec hell, n µsec dunkel
1-Bit: x µsec dunkel(!), y µsec hell(!)

Und da liegt das Problem: je nach Folge der 1en und 0en gibt es 
verschieden lange Hell- oder Dunkelphasen.

Siehe auch: http://www.sbprojects.com/knowledge/ir/rc5.htm

Konsequenz: RC5 muss durch einen Extra-Code geschleust werden. Allein 
schon die Erkennung des Start-Bits als RC5-Code gestaltet sich als 
schwierig. Ursprünglich gab es 2 Start-Bits, die beide "1" sein mussten:

1. Start-Bit: 889µs dunkel, 889µs hell
2. Start-Bit: 889µs dunkel, 889µs hell

Daran ist aussergewöhnlich, dass das Bit mit einer Dunkelphase beginnt, 
das "sieht" man also schon mal gar nicht. Aber man kann das als RC5 
durchaus erkennen, da ja nach den 889µs immer eine Dunkelphase von 
konstant 889µs folgt. Bis dahin passt das alles noch...

Aber:

Das RC5-Protokoll wurde nach einiger Zeit abgeändert ("RC5-Extended") - 
nämlich derart, dass das 2. Start-Bit zu einem invertierten Kommando-Bit 
6 umfunktioniert wurde, um mehr Kommandos umsetzen zu können.

Damit sehen die beiden ersten Bits folgendermaßen aus:

Entweder:

  Start-Bit:      889µs dunkel, 889µs hell
  Kommando-Bit 6: 889µs dunkel, 889µs hell

oder:

  Start-Bit:      889µs dunkel, 889µs hell
  Kommando-Bit 6: 889µs hell, 889µs dunkel

Das heisst: wir haben entweder eine Hellphase von 1 x 889µs bei den 
ersten beiden Bits oder eine Hellphase von 2 x 889µs.

Peter Daneggers RC5-Decoder hat es da wesentlich einfacher: Dieser ist 
fest auf RC5 und dessen Manchester-Codierung fixiert und hart drauf 
programmiert. Wenn man nichts anderes berücksichtigen muss, ist das sehr 
sehr einfach.

Ich werde mir jedoch erst einmal Gedanken machen müssen, wie man 
RC5-Code als solchen überhaupt erkennen kann. Der Rest ist dann einfach: 
sobald klar ist, dass es sich um RC5 handelt, muss dann in der 
State-Machine in einen Manchester-Decoder gesprungen werden - also in 
eine Sonderbehandlung. Da kann dann der Code von Peter Dannegger 
herhalten.

Also bitte etwas Geduld, RC5 kann man nicht einfach durch 
Preprocessor-Konstanten parametrisieren, wie ich das mit den anderen 
Protokollen gemacht habe.

Gruß,

Frank

Frank Boe schrieb:
>> [Wiederholungs-Sequenz beim NEC-Protokoll]
> Meine "Cyberhome" (alter DVD-Player) sendet sie.
Michael M. schrieb:
> meine yamaha-fb auch.

Okay, ich baus ein, ist ja nicht wirklich schwierig :-)

Gruß,

Frank

Frank M. schrieb:

> Daran ist aussergewöhnlich, dass das Bit mit einer Dunkelphase beginnt,
> das "sieht" man also schon mal gar nicht. Aber man kann das als RC5
> durchaus erkennen, da ja nach den 889µs immer eine Dunkelphase von
> konstant 889µs folgt. Bis dahin passt das alles noch...
>
Du tastest doch recht oft ab, wenn Du 1x 889µs erkennst passt das doch 
nur als RC5 Startbit.
Danach muß man ja nicht "ala" Peter weitermachen. Ich zähle einfach die 
ankommenden Pulse, wobei ein 889µs mit 1 und ein 1778µs mit 2 gezählt 
wird. Beim erkannten Startbit schiebe ich die erste 1 in den Bitspeicher 
und dann wird immer wenn der Pulszähler ungerade ist, bei einem 889µs 
Puls das letzte Bit erneut bzw. bei 1778µs letzte Bit invertiert in den 
Bitspeicher eingeschoben. Das dann bis alle 14 Bits eingesammelt sind.

Gruß Willi

P.s.: ich bewundere Euch, was ihr so alles auf die Reihe bekommt. Seit 
Ihr alle noch ledig, oder habt ihr einfach nur tollerante Frauen? Meine 
hat diese Woche Nachtdienst, da bleibt dann auch mal wieder etwas mehr 
Zeit.

Toralf Wilhelm schrieb:
> Du tastest doch recht oft ab, wenn Du 1x 889µs erkennst passt das doch
> nur als RC5 Startbit.

Fast: es können 1x889µs oder 2x889µs sein - jedenfalls beim extended 
RC5, also da, wo das ursprüngliche 2. StartBit als Kommando-Bit No. 6 
benutzt wird. Aber vielleicht vernachlässige ich das und kümmere mich 
erstmal einfach um das Classic-RC5.

> Danach muß man ja nicht "ala" Peter weitermachen. Ich zähle einfach die
> ankommenden Pulse, wobei ein 889µs mit 1 und ein 1778µs mit 2 gezählt
> wird. Beim erkannten Startbit schiebe ich die erste 1 in den Bitspeicher
> und dann wird immer wenn der Pulszähler ungerade ist, bei einem 889µs
> Puls das letzte Bit erneut bzw. bei 1778µs letzte Bit invertiert in den
> Bitspeicher eingeschoben. Das dann bis alle 14 Bits eingesammelt sind.

Danke für den Tipp, das werde ich mir nochmal durch die Gehirnwendungen 
laufen lassen.

> P.s.: ich bewundere Euch, was ihr so alles auf die Reihe bekommt. Seit
> Ihr alle noch ledig, oder habt ihr einfach nur tollerante Frauen?

Verheiratet, Frau ist tolerant und auch toll-erant ;-)

Gruß,

Frank

Frank M. schrieb:
> Fast: es können 1x889µs oder 2x889µs sein - jedenfalls beim extended
> RC5, also da, wo das ursprüngliche 2. StartBit als Kommando-Bit No. 6
> benutzt wird. Aber vielleicht vernachlässige ich das und kümmere mich
> erstmal einfach um das Classic-RC5.

Genauso mache ich es, einfach immer extended RC5 und das Bit invertiert 
als Bit6 einfügen.

> Verheiratet, Frau ist tolerant
Du glücklicher!
> und auch toll-erant ;-)
Mist da war sie wieder, meine Legasthenie.

Gruß Willi

Toralf Wilhelm schrieb:
> Frank M. schrieb:
> Danach muß man ja nicht "ala" Peter weitermachen. Ich zähle einfach die
> ankommenden Pulse, wobei ein 889µs mit 1 und ein 1778µs mit 2 gezählt
> wird. Beim erkannten Startbit schiebe ich die erste 1 in den Bitspeicher
> und dann wird immer wenn der Pulszähler ungerade ist, bei einem 889µs
> Puls das letzte Bit erneut bzw. bei 1778µs letzte Bit invertiert in den
> Bitspeicher eingeschoben.

Habe das jetzt so eingebaut, aber mit einer leichten Änderung des 
Algorithmus: ob das neue Bit invertiert oder nicht invertiert neu 
eingeschoben wird bei einem kurzen Puls, ist nicht abhängig von der 
letzten Pulsdauer, sondern von der Pause davor.

Lange Pause vor kurzem Puls: neues Bit = letztes Bit invertiert
Kurze Pause vor kurzem Puls: neues Bit = letztes Bit

Wahrscheinlich hatte ich Dich da nicht genau verstanden, auf jeden Fall 
läuft das nun. Den Code stelle ich heute abend oder morgen zum Download 
bereit.

Dank und Gruß,

Frank

Frank M. schrieb:
> Toralf Wilhelm schrieb:
>> Frank M. schrieb:
>
> Lange Pause vor kurzem Puls: neues Bit = letztes Bit invertiert
> Kurze Pause vor kurzem Puls: neues Bit = letztes Bit
>
> Wahrscheinlich hatte ich Dich da nicht genau verstanden, auf jeden Fall
> läuft das nun. Den Code stelle ich heute abend oder morgen zum Download
> bereit.
>
Ja da habe ich mich nicht sehr deutlich ausgedrückt, ich messe jeden 
Flankenwechsel egal ob Puls oder Pause. Mich interessiert nur die Länge. 
Aber Du hast das schon richtig verstanden.
Gruß Willi

RC5 ist nun implementiert, der vom Compiler generierte Code ist kaum 
größer geworden, weil ich noch ein paar Sachen optimiert habe. Download 
findet Ihr im IRMP-Artikel:

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

Noch ein Tipp am Rande:

Jedes von IRMP unterstützte IR-Protokoll "verbrät" ungefähr 200 Byte an 
Code. Wer sparen muss, weil ihm der Flash-Speicher ausgeht, der sollte 
die Unterstützung von KASEIKYO und/oder RECS80 ausschalten. Beides sind 
eher exotische Protokolle, ausserdem ist die Modulationsfrequenz von 
56Khz beim Kaseikyo-Protokoll weit ab von den Frequenzen, die von den 
anderen Protokollen verwendet werden.

Über Feedback zum RC5 würde ich mich freuen, ich habe hier nur mit 
künstlich generierten Scan-Dateien getestet, da ich selbst keine RC5-FB 
habe.

Viel Spaß,

Frank

Neue Version unter http://www.mikrocontroller.net/articles/IRMP#Download 
:

Beim NEC-Protokoll werden nun auch die "Repetition Frames" erkannt. Wenn 
die FB so eine Wiederholungssequenz aussendet, ersetzt IRMP diese 
einfach durch das zuletzt empfangene Kommando.

Gruß,

Frank

Habe noch einen Bug korrigiert:

Die Puls/Pausen-Counter waren immer um 1 zu niedrig, das gab manchmal 
Probleme bei der SIRCS-Erkennung bei Sony-FBs mit stark abweichenden 
Timings.

Download-Zip-Datei habe ich aktualisiert.

Gruß,

Frank

Wie testest du das eigentlich? Hast du von jedem Protokoll ne 
Fernbedienung zuhause? ;) Oder haste bei nem Pollin 
1kg-Fernbedienungspaket zugegriffen hehe.

Simon K. schrieb:
> Wie testest du das eigentlich?

Steht im ersten Beitrag ganz oben, nicht gelesen? ;-)

irmp kann man auch unter Linux compilieren und dann mit einer Scan-Datei 
füttern. Wie man eine Scan-Datei mit IRMP erstellt, ist ebenso oben 
beschrieben. Ich teste den Code ausschließlich unter Linux, das geht 
wesentlich einfacher und schneller. Wenn dann alles wie gewünscht läuft, 
schicke ich den Source noch einmal durch den AVR-Compiler und flashe ihn 
dann.

> Hast du von jedem Protokoll ne Fernbedienung zuhause? ;)

Nein, 7 von 9 Fernbedienungen bei mir arbeiten mit dem NEC-Protokoll. 
Dann habe ich noch eine Samsung. Den Rest teste ich entweder mit 
Scan-Dateien, die mir Vlad Tepesch zur Verfügung gestellt hat (steht 
auch oben) oder mit künstlich erzeugten Dateien, die man einfach mit 
einem ASCII-Editor erstellt. Jedes Telegramm wird einfach pro Zeile mit 
0en (Puls) und 1en (Pause) beschrieben, fertig. Beispiel-Dateien sind im 
ZIP-Archiv enthalten.

> Oder haste bei nem Pollin 1kg-Fernbedienungspaket zugegriffen hehe.

Tatsächlich habe ich mir einen Packen Technisat-FBs für 95 Cent das 
Stück von Pollin kommen lassen, diese wurden (jedenfalls vor ein paar 
Wochen) nicht von IRMP erkannt. Entweder ist das RC5 (welches erst 
kürzlich auf besonderen Wunsch dazukam) oder noch was anderes... Mal 
sehen, bin zum Testen mit realer Hardware schon länger nicht mehr 
gekommen.

Wenn mir jemand Scan-Dateien schickt, welche von IRMP nicht erkannt 
wird, prüfe ich das und baue den Decoder dafür ein, wenn ich das für 
sinnvoll halte. Aber ich bin der Meinung, dass IRMP bereits jetzt über 
90% aller Fernbedienungen, die heutzutage so im Umlauf sind, bereits 
erkennt.

Gruß,

Frank

> Tatsächlich habe ich mir einen Packen Technisat-FBs für 95 Cent das
> Stück von Pollin kommen lassen, diese wurden (jedenfalls vor ein paar
> Wochen) nicht von IRMP erkannt. Entweder ist das RC5 (welches erst
> kürzlich auf besonderen Wunsch dazukam)

Genau so ist es!

RC5: fast alle Philips, Grundig, Metz, Loewe, Technisat, (ich glaube 
auch alles was Thomson war - Telefunken/Saba/Nordmende)

Gruß Willi

Toralf Wilhelm schrieb:
> Genau so ist es!
>
> RC5: fast alle Philips, Grundig, Metz, Loewe, Technisat, (ich glaube
> auch alles was Thomson war - Telefunken/Saba/Nordmende)

Da wäre ich mir nicht so sicher. Laut

http://www.mikrocontroller.net/attachment/67261/Pollin-IR-Codes.txt

gibt es bei der Fernbedienung "Technisat DSR-B" (Pollin-Bestellnummer 
620062) zwei Ausführungen. Da bei mir kein 9V-Block einzusetzen ist, 
nehme ich an, dass es die erste im Text aufgeführte FB ist. Und diese 
enthält einen SAA3004 (SA2004 gibt es nicht, das scheint ein Vertipper 
zu sein) als IR-Encoder. Durch das Datenblatt steige ich noch nicht ganz 
durch, habe auch erstmal nur flüchtig draufgeguckt.

Kandidat könnte RECS80 sein, welches ja die zweite FB mit der 
Bestellnummer 620062 benutzt. Spricht auch deswegen dafür, weil eine 
LED, die beim damaligen Test vom µC synchron geschaltet wurde, um das 
Signal sichtbar zu machen, nur ganz ganz schwach leuchtete, wenn ich 
eine Taste drückte. Bei RECS80 sind die Impulse ultrakurz, nämlich nur 
158µs. Die Pausen hingegen sind 32 mal länger! Ein echter Batteriesparer 
also ;-)

Bei einer Timerfrequenz von 10000 kHz macht das gerade mal 1 oder 2 
Impulse. Da ich erst gestern den Bug gefixed habe, dass der Pulscounter 
immer 1 zu niedrig war, könnte das schon der Grund sein, warum die FB 
damals beim flüchtigen Test nach dem Auspacken nicht erkannt wurde. Da 
wurde nämlich schnell mal aus einem Puls gar keiner mehr ;-)

Da hilft alles nix: Ich muss das mit der "echten" Hardware und mit dem 
aktuellen IRMP-Code nochmal testen, im Notfall einen Scan machen...
Wenn sie dann aber funktionieren, sind das unschlagbar billige Teile ;-)

Gruß,

Frank

siegmar schrieb:

> Hintergrund meiner Frage ist, das ich einen Digital Sat receiver
> (Philips DIS 2221) ohne Fernbedienung rumliegen habe und keine bisher
> von mir getestete Universalfernbedienung funktioniert.

Mein erster Gedanke wäre die Lirc-DB.

Sicher, dass der Receiver tatsächlich was empfängt?

Google sagt, dass der Receiver öfters Wärmeprobleme hat und deswegen 
sehr oft der IR-Empfang nach einiger Zeit ausfällt. Andere konnten den 
Empfang verbessern, indem sie die Blende vor dem IR-Sensor ausgebaut 
haben. Aber einen Hinweis, wie man eine Universal-FB damit zum Laufen 
bekommt, habe ich nicht gefunden.

Gruß,

Frank

Von der Philips-Universal-FB-Seite (http://www.pronto.philips.com) 
gibt's einen Link auf http://onlyoneremote.com. Dort kann eine Datenbank 
für sehr viele Hersteller heruntergeladen werden, darunter auch viele 
Philips-Codesets. Öffnen kann man die Datei mit den Konfigurationstools 
von Philips, die man kostenlos herunterladen kann, nachdem man sich 
registriert hat.

Leider kann man in den Philips-Tools nur die Bitfolgen ansehen, die man 
selbst aufgezeichnet hat. Vielleicht kannst du ja aber mit etwas reverse 
engineering was brauchbares aus der Datenbank holen. Vielleicht kennst 
du ja auch jemanden mit einer Philips-UFB der dir helfen könnte.

Hallo Frank,

cooles Projekt, ich habe es gestern mal provisorisch aufgebaut und 
gleich ein paar Anmerkungen und Fragen dazu:
RC5: wird weitgehend erkannt, allerdings habe ich festgestellt, das z.B. 
die Taste 2 einer Löwe FB öfter mal 4 oder 5 zurückgibt, manchmal stimmt 
auch die Adresse nicht. Die 6 "spinnt" ebenfalls öfter, andere Tasten 
gehen sehr stabil.
Eine andere RC5 FB (Inverto) zeigt ein fast identisches Verhalten (auch 
Taste 2 und 6 besonders auffällig)

Außerdem habe ich noch eine neuere Philips FB (TV) die nicht erkannt 
wird, er versucht RC5, findet aber nichts. ich habe einen Portscan mal 
angehängt, vielleicht kommt Dir die bekannt vor? Achtung, der Portscan 
ist invertiert, dann wird das Bitvergleichen einfacher.

An Protokollen fehlt mir noch DENON, zumindest die älteren DENON Codes 
werden nicht erkannt. Link zum Protokoll kann ich mal raussuchen, wenn 
Du hier unterstützen kannst/möchtest.

SIRCS und NEC werden anscheinend sicher erkannt, andere FB konnte ich 
noch nicht testen.

Mangels GCC "Übung" habe ich das Projekt nach Codevision "portiert" und 
auch gleich den DEBUG Mode in die AVR Variante eingebaut. Ich denke mal 
dabei ist nichts schiefgegangen. Allerdings scheint der output manchmal 
das Ergebnis zu beinflussen. Die Abweichungen habe ich allerdings auch 
ohne DEBUG bzw. IRMP_LOGGING

Kann das an dem von mir verwendeten Quarz liegen? Du hattest ja den 
Oszillaor benutzt. Könnte am Timing etwas verändern, oder? Ich habe um 
die Abarbeitung zu beschleunigen einen 16MHz Quarz und den Compiler auf 
maximalen speed optimiert.
Der Interrupt ist ebenfalls mit 10kHz eingestellt.

Kannst Du mir ein paar Tipps geben wo ich ansetzen kann?

Vielen Dank für den Code und Deine Unterstützung.

Grüße,
Klaus

Hallo Klaus,

Klaus Leidinger schrieb:
> RC5: wird weitgehend erkannt, allerdings habe ich festgestellt, das z.B.
> die Taste 2 einer Löwe FB öfter mal 4 oder 5 zurückgibt, manchmal stimmt
> auch die Adresse nicht. Die 6 "spinnt" ebenfalls öfter, andere Tasten
> gehen sehr stabil.

Da wäre eine über den UART übertragene Scan-Datei klasse, wenn Du da mal 
die Tasten 0-9 aufzeichnen könntest.

> Eine andere RC5 FB (Inverto) zeigt ein fast identisches Verhalten (auch
> Taste 2 und 6 besonders auffällig)

Dito.

> Außerdem habe ich noch eine neuere Philips FB (TV) die nicht erkannt
> wird, er versucht RC5, findet aber nichts. ich habe einen Portscan mal
> angehängt, vielleicht kommt Dir die bekannt vor? Achtung, der Portscan
> ist invertiert, dann wird das Bitvergleichen einfacher.

Werde ich mir mal näher anschauen und dann noch was dazu schreiben. Wenn 
Du schon beim Einscannen über UART bist, kannst Du das ja auch direkt 
mal für diese FB tun.

> An Protokollen fehlt mir noch DENON, zumindest die älteren DENON Codes
> werden nicht erkannt. Link zum Protokoll kann ich mal raussuchen, wenn
> Du hier unterstützen kannst/möchtest.

Doku zu älterem DENON-Protokoll ist mir mal über den Weg gelaufen, wenn 
Du da einen Link hättest, wäre nett.

> SIRCS und NEC werden anscheinend sicher erkannt, andere FB konnte ich
> noch nicht testen.

Prima.

> Mangels GCC "Übung" habe ich das Projekt nach Codevision "portiert" und
> auch gleich den DEBUG Mode in die AVR Variante eingebaut.

Das ist schlecht. Die DEBUG-Variante ist eigentlich nur zum Testen unter 
Linux gedacht, auf dem AVR verändern Dir direkte printf-Ausgaben zu sehr 
das Zeitverhalten. Daher halte ich das für überhaupt nicht sinnvoll.

> Ich denke mal
> dabei ist nichts schiefgegangen. Allerdings scheint der output manchmal
> das Ergebnis zu beinflussen.

Eben. Lass das besser mit dem DEBUG-Modus auf dem AVR. Schalte lediglich 
IRMP_LOGGING ein. Die empfangenen Bytes werden gepuffert und sollten 
daher das Zeitverhalten während der Aufzeichnung nicht beeinflussen.

> Kann das an dem von mir verwendeten Quarz liegen? Du hattest ja den
> Oszillaor benutzt. Könnte am Timing etwas verändern, oder?

Mit einem Quarz sollte es eher besser sein. Wie gesagt, der DEBUG-Modus 
ist nicht für die Ausgabe geeignet, da er in der ISR direkt ausgeführt 
ist. Unter Linux oder Windows ist das absolut zeitunkritisch, weil da 
die Daten ja dann aus der Datei gelesen werden.

Gruß,

Frank

Hallo Klaus, steht die "portierte" Version für CV zum Download an?

Grüße,
Albert

Albert K. schrieb:
> Hallo Klaus, steht die "portierte" Version für CV zum Download an?
>
Hallo Albert,

Du hast Post.

Wennn der Code "stabil" ist, stelle ich die gerne zur Verfügung.

Falls mehr Leute Interesse daran haben, könnte Frank dann die
#ifdef CV
vielleicht in den Original Code mit reinnehmen?

Mal sehen wieviel Aufwand das wird ;-)

Grüße,
Klaus

Klaus Leidinger schrieb:

> Falls mehr Leute Interesse daran haben, könnte Frank dann die
> #ifdef CV
> vielleicht in den Original Code mit reinnehmen?

Klar, mache ich. Schick mir bitte die geänderten Dateien zu.

Gruß,

Frank

Frank M. schrieb:
> Di Pi schrieb:
>> Werden jetzt auch Wiederholungen beim NEC-Protokoll erkannt? (der
>> Hinweis auf eine noch fehlende Implementierung ist weg.)
>
> Nein, der Hinweis ist mir leider beim Bearbeiten der Tabellen
> flötengegangen. Ist nun wieder drin.
>
> Aber bis jetzt habe ich noch keine FB in der Hand gehabt, wo wirklich
> die spezielle Wiederholungs-Sequenz augesandt wird. Bei meiner Toshiba-,
> Xoro- und Media-Player-Fernbedienung, die allesamt das NEC-Protokoll
> benutzen, wird davon jedenfalls kein Gebrauch gemacht. Stattdessen wird
> einfach der jeweilige Code solange wiederholt, bis man die Taste
> loslässt.

Die Reichelt-RGB-FB sendet die spezielle Wiederholungssequenz. :)

Di Pi schrieb:
> Die Reichelt-RGB-FB sendet die spezielle Wiederholungssequenz. :)

Danke für die Info. Mit der Download-Version vom 13.02. im IRMP-Artikel 
sollte das auch von IRMP erkannt werden.

Gruß,

Frank

Es gibt eine neue Version von IRMP zum Download:

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

Änderungen:

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

Vielen Dank an  Klaus Leidinger, der mich mit den entsprechenden 
Scan-Dateien versorgte ;-)

Desweiteren gibt es nun im Unterverzeichnis IR-Data ein irmp.exe, mit 
dem man Scan-Dateien auch unter Windows analysieren kann.

Beispiel:

1. Eingabeaufforderung starten
2. In das Verzeichnis irmp\IR-Data wechseln
3. Aufruf von:

   irmp.exe <rc5x.txt

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

   irmp.exe <rc5x.txt | more


Viel Spaß,

Frank

...
und für die Codevision Nutzer ist die main.c entsprechend angepasst...
einfach das //#define CODEVISION auskommentieren.

Danke an Frank, auch für die Nachtschichten ;-)

Klaus

Klaus Leidinger schrieb:
> ...
> und für die Codevision Nutzer ist die main.c entsprechend angepasst...
> einfach das //#define CODEVISION auskommentieren.

Upps, hab ich doch tatsächlich vergessen... ich schreibs noch mit in den 
Artikel.

Gruß,

Frank

ich habe mal eine Liste von 6 Fernbedienungen dem Artikel hinzugefügt - 
u.a. auch eine mit KASEIKYO Protokoll - die ich mal spontan 
durchgetestet habe.

Chris M. schrieb:
> ich habe mal eine Liste von 6 Fernbedienungen dem Artikel hinzugefügt -
> u.a. auch eine mit KASEIKYO Protokoll - die ich mal spontan
> durchgetestet habe.

Hey, und es hat funktioniert? Das Kaseikyo-Protokoll hatte ich lediglich 
nach Infos aus dem Internet implementiert, ohne es jemals testen zu 
können.

Gute Idee, eine Liste von Fernbedienungen in den Artikel einzufügen, 
vielleicht ist die Angabe der Adresse aber besser in Hex sinnvoll?

Wer noch weitere FBs mit IRMP getestet hat, kann diese ja auch noch im 
Artikel eintragen, zum Beispiel die Reichelt-RGB-FB.

Gruß,

Frank

Frank M. schrieb:

> Hey, und es hat funktioniert? Das Kaseikyo-Protokoll hatte ich lediglich
> nach Infos aus dem Internet implementiert, ohne es jemals testen zu
> können.

Ja problemlos - mit der Version die Du um den 10.02. veröffentlicht 
hattest ging noch nichts und ich dachte schon die wird noch ein ganz 
anderes Protokol nutzen. Auch die RC5 Codes stimmen nun mit der anderen 
Software von Peter Dannegger die ich nutze überein.

Moin,

habe den Code heute zum ersten Mal ausprobiert. Läuft auf einem Atmega16 
einwandfrei mit NEC Protokoll.

Eine kleine Erweiterung habe ich eingebaut: Die Datenstruktur irmp_data 
habe ich um ein Flag erweitert, das anzeigt, ob das Kommando aus einem 
Repetition-Frame stammt. Damit kann ich dann im Programm entscheiden, ob 
ich einen Auto-Repeat haben möchte oder nicht.

Mag vielleicht auch noch für andere hilfreich sein...

Viele Grüsse
Michael

Michael Urban schrieb:

> Eine kleine Erweiterung habe ich eingebaut: Die Datenstruktur irmp_data
> habe ich um ein Flag erweitert, das anzeigt, ob das Kommando aus einem
> Repetition-Frame stammt. Damit kann ich dann im Programm entscheiden, ob
> ich einen Auto-Repeat haben möchte oder nicht.

Ist das generell sinnvoll und damit von allgemeinem Interesse?

Ich meine, nicht nur für NEC, auch bei RC5 und RC6 könnte man das gewiss 
einbauen...

@Michael: Für was brauchst Du das?

Gruß,

Frank

was versteht ihr unter Wiederholung?
a) den mehrfachen Empfang eines Frames, weil das Protokoll so 
implementiert ist, dass es jeden Frame 3x verschickt
b) eine Wiederholung durch dauerhaft gedrückte Taste

Vlad Tepesch schrieb:
> was versteht ihr unter Wiederholung?
> a) den mehrfachen Empfang eines Frames, weil das Protokoll so
> implementiert ist, dass es jeden Frame 3x verschickt
> b) eine Wiederholung durch dauerhaft gedrückte Taste

b)

Das Protokoll "darunter" soll ja gerade für die Applikation 
unsichtbar/uninteressant sein.

Gruß,

Frank

Moin,

ich meinte die Erkennung, ob ein Kommando erstmalig gesendet wird oder 
aufgrund eines Wiederholungsframes erzeugt wurde.

Ich brauchte das, weil ich die Fernbedienung zur Eingabe von Daten 
verwende - und wenn man da nicht kurz genug drückt, dann "prellt" die 
Sache eben...

Ich habe das ganz einfach gelöst:

Die Datenstruktur IRMP_DATA habe ich durch ein viertes Feld ergänzt:

1

typedef struct

2

{

3

  uint8_t               protocol;                                                               // protocol, i.e. NEC_PROTOCOL

4

  uint16_t              address;                                                                // address

5

  uint16_t              command;                                                                // command

6

  uint8_t               repetition;                                                               // repetition frame

7

} IRMP_DATA;

an der entsprechenden Stelle für die Erkennung von repetition frames:

1

          if (irmp_tmp_protocol == IRMP_NEC_PROTOCOL && irmp_bit == 0)                            // repetition frame

2

          {

3

            irmp_protocol = irmp_tmp_protocol;

4

            irmp_address = last_irmp_address;                                                     // address is last address

5

            irmp_command = last_irmp_command;                                                     // command is last command

6

            irmp_repetition = 1;   // Marker repetition flag

7

          }

(Variablendeklarationen, etc. habe ich hier jetzt mal weggelassen)

Das funktioniert bei allen Protokollen, die einen repetition frame 
besitzen

In der Auswerteroutine im Programm kann mann jetzt irmp_data.repetition 
auswerten und selbst entscheiden, ob man die Wiederholung haben will 
oder nicht.

Ich habe z.B. für die Zahlentasten, die ich zur Eingabe verwende, die 
Wiederholungen ignoriert, für Cursortasten sie aber eingeschaltet 
gelassen.

Ob das jetzt Allgemein interessant ist, mag ich nicht beurteilen - für 
mich ist es ein nutzbares Feature.

Viele Grüsse
Michael

Ach ja, vergessen:

Variante b) - das "Auto-Repeat" bei länger gedrückter Taste (schlägt bei 
mir schon bei einer gefühlten 1/10 Sek. zu...

> Ob das jetzt Allgemein interessant ist, mag ich nicht beurteilen - für
> mich ist es ein nutzbares Feature.

Okay, ich bau das so ähnlich ein, aber etwas allgemeingültiger:

1

#define IRMP_FLAG_REPETITION    0x01

2

#define IRMP_FLAG_WASWEISSICH   0x02

3

....

4

5

typedef struct

6

{

7

  uint8_t          protocol;           // protocol, i.e. NEC_PROTOCOL

8

  uint16_t         address;            // address

9

  uint16_t         command;            // command

10

  uint8_t          flags;              // flags, e.g. repetition frame

11

} IRMP_DATA;

Denn wer weiß, vielleicht kommen da noch ein paar Flags hinzu?

Dann wird bei länger gedrückter Taste das Bit IRMP_FLAG_REPETITION in 
flags gesetzt - nicht nur bei NEC, sondern auch bei RC5 und RC6. Bei den 
anderen Protokollen ist das schwerlich möglich, ausser ich arbeite mit 
Timeouts ("wenn derselbe Befehl innerhalb X Millisekunden reinkommt, 
dann hat der User schon länger den Finger auf der Taste")... mal sehen.

In main() kann man das dann so abfragen:

1

   if (irmp_data.flags & IRMP_FLAG_REPETITION)

2

   {

3

      finger_blau();

4

   }

5

   else

6

   {

7

      normale_taste();

8

   }

Gruß,

Frank

Di Pi schrieb:
> Timeouts würde ich dafür nicht verwenden (oder abschaltbar machen). Was
> ich an diesem Projekt nämlich am meisten schätze ist die Möglichkeit,
> alles nicht benötigte per Flag abzuschalten.

Ich dachte einfach an einen Zähler, der bei jedem Call der ISR 
hochgezählt wird. Wenn

a) ein neuer Frame erkannt wird und
b) der Zähler einen gewissen Wert (REP_TIMEOUT) nicht übersteigt und
c) erkanntes ProtoKoll = letztes Protokoll und
d) Adresse = letzte Adresse und
e) Kommando = letztes Kommando

dann setze das Repetition-Flag.

Der Zähler wird bei jedem erkannten Protokoll einfach wieder auf 0 
gesetzt.

REP_TIMEOUT müsste auf ca. 0,2 Sekunden stehen. Jede FB schafft bei 
Festhalten einer Taste ca. 10 Frames pro Sekunde. Aber keiner klickt so 
schnell einzeln auf der FB rum.

Meinetwegen kann ich das auch abschaltbar machen, aber ich schätze den 
zusätzlichen Aufwand an µC-Code auf max. 50 Bytes.

Gruß,

Frank

Es gibt eine neue Version von IRMP zum Download:

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

Einzige Änderung: Neue Variable flags in IRMP_DATA zur Erkennung von 
langen Tastendrücken

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:

1

    if (irmp_data.flags & IRMP_FLAG_REPETITION)

2

    {

3

      finger_blau (irmp_data.command);

4

    }

5

    else

6

    {

7

      einzeln (irmp_data.command);

8

    }

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

Es gibt eine neue Version vom IRMP zum Download:

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

Änderungen:

1. SIRCS: Korrekte Erkennung und Unterdrückung von automatischen 
Frame-Wiederholungen

Eine Sony-Fernbedienung wiederholt automatisch jeden Frame 2-3 mal. Das 
wurde nicht immer korrekt als solche erkannt. Solche Wiederholungen 
werden nun weggefiltert.

2. SIRCS: Device-ID-Bits werden nun in irmp_data.command und nicht mehr 
in irmp_data.address gespeichert

Je nach Sony-FB-Tasten (z.B. für TV-Kanal oder für Videotext) werden 
unterschiedliche ID-Kennungen mitgeschickt. IRMP hat diese bisher in der 
Adresse abgebildet. Das ist aber nicht praxisgerecht, weil dann ein- und 
dieselbe Fernbedienung unterschiedliche Adressen aufweist. Die 
ID-Kennung wird nun zusammen mit dem Kommando in der Variablen 
irmp_data.command abgelegt. Somit hat nun jede Sony-FB ein- und dieselbe 
Adresse, nämlich 0.

Ausnahme: Ist der Frame 20 Bits statt 12 oder 15 Bits lang (nur bei 
neueren FBs), werden die letzten 5 Bits in der Adresse abgelegt.

3. Vergrößerung des Scan-Buffers (zwecks Protokollierung)

Der Scan-Buffer wurde vergrößert, um solche automatischen 
Wiederholungen, wie sie z.B. von Sony-FBs ausgesandt werden, überhaupt 
zu erkennen und als solche für Scans zu protokollieren. Da der 
Scan-Buffer im Normalfall abgeschaltet ist, hat das keine Auswirkung auf 
die Größe des Programms.

Gruß,

Frank

Hi Frank,

zunächst mal vielen Dank für das große Engagement bei diesem 
Softwareprojekt. Das trifft genau mein Thema, ich habe gerade ein 
Projekt geatartet um verschiedene Kommandos der "vielen" Fernbedienungen 
meiner Anlage aufzufangen um dann Zusatzfunktionen auszulösen.
Vielleicht hier mal kurz meine Erfahrungen mit deiner Software nach den 
ersten 2..3 h herumspielen:
Mit 8Mhz internem Oszillator hatte ich massive Probleme mit dem Timing, 
(gleiche Tastendrücke führen zu unterschiedlichen Codes). Nun, mit 16MHz 
externem Quarz läuft es wesentlich besser.

Zu den Protokollen, die ich mit original FB testen kann:

SIRCS läuft gut, allerdings ist eine Sony Videorecorder-FB offenbar mit 
ihrem Timing etwas grenzwertig, es kommt immer mal vor, daß verschiedene 
Codes bei gleichem Tastendruck gezeigt werden.
NEC von einer Yamaha-FB läuft richtig super.
KASEIKYO von einer Panasonic Blueray FB läuft auch super.
SAMSUNG von einer TV-FB geht überhaupt nicht, null Output.
Dann kann ich noch eine Kathrein-Sat-Rx FB bieten - dort meldet IRMP zu 
90% RC5(x) und ab und zu RC6. (Timing-Problem?) Am funktionieren dieses 
Protokolls wäre ich am stärksten interessiert...

Noch eine Anmerkung zu der neuesten Änderung vom 2.3.: Meiner Meinung 
nach hat der Wegfall der Systemadresse bei SIRCS keinen Sinn bzw. es 
kommt auf den Anwendungsfall (?) an. Wenn ich an der TV-FB Power drücke 
will ich das doch von z.B. Power beim DVD-Player unterscheiden. Das geht 
nun nicht mehr, alles sieht gleich aus.

Und eine letzte Sache ist mir noch aufgefallen: Die Kommandos die IRMP 
ausgibt sind in der Bitorder verdreht. Ok, das mag egal sein, denn 
eindeutig ist es auch so, aber typischerweise haben Zifferntasten 1..9 
aufsteigende Codes, in welchem Bereich auch immer. Daran kann man das 
Problem ganz gut erkennen. Dreht man die Bits um, sieht es sowohl bei 
SIRCS, NEC und KASEIKYO "schön" aus. Ggf. sind auch die Systemadressen 
bitverdreht, konnte ich noch nicht checken.

Ok, langer Beitrag, sorry ;) Wenn ich mit meinem FB-Fundus irgendwie zum 
Fortgang dieses Projektes beitragen kann, würde ich es im Rahmen meines 
Zeitbudgets gerne tun.

-Peter

Peter Kostov schrieb:
> typischerweise haben Zifferntasten 1..9
> aufsteigende Codes

Da habe ich mit einer NoName-RC5 FB andere Erfahrungen gemacht. Da 
scheinem mir die Kommandos rein zufällig vergeben worden zu sein (sowohl 
1..9 als auch alle anderen Tasten). Sicher, dass dein Hersteller nicht 
vllt einfach absteigend nummeriert?

Hi Peter,

Peter Kostov schrieb:

> Mit 8Mhz internem Oszillator hatte ich massive Probleme mit dem Timing,
> (gleiche Tastendrücke führen zu unterschiedlichen Codes). Nun, mit 16MHz
> externem Quarz läuft es wesentlich besser.

Interessant, die anderen, die mich mit IR-Scans und anderen Infos 
versorgen, benutzen den internen Oszillator und haben keine 
Timing-Probleme.

> SIRCS läuft gut, allerdings ist eine Sony Videorecorder-FB offenbar mit
> ihrem Timing etwas grenzwertig, es kommt immer mal vor, daß verschiedene
> Codes bei gleichem Tastendruck gezeigt werden.

Da bräuchte ich einen Scan von mehreren Tasten. Dazu bitte IRMP_LOGGING 
einschalten, über den UART mitprotokollieren und mir die Scans schicken 
- am besten mit einem Kommentar "# Taste 1" vor jeder Zeile. 
Beispiel-Dateien sind im Ordner IR-Data.

> KASEIKYO von einer Panasonic Blueray FB läuft auch super.

Hier würden mich auch Scans interessieren, weil ich nämlich gerade das 
Programm für eine IR-Sende-Funktion schreibe, welcher man die 
IRMP-Datenstruktur übergibt. Diese Funktion rekonstruiert aus den 
IRMP-Daten wieder den Original-Frame und gibt diesen dann über eine 
IR-Diode aus. Beim Kaseikyo-Protokoll sind das aber 48 Bits, von welchen 
ich beim Decodieren einige ignoriere, um sie überhaupt in die 
IRMP-Datenstruktur pressen zu können. D.h. beim Decodieren gehen 
Informationen verloren. Diese sind zwar fürs Decodieren der Tasten nicht 
wichtig, aber für das Encodieren des kompletten Frames. Wäre also nett, 
wenn Du mir da entsprechende Scans schicken könntest, da ich selber noch 
nie eine Kaseikyo-kompatible FB gesehen habe ;-)

> SAMSUNG von einer TV-FB geht überhaupt nicht, null Output.

Bitte Scans her. Ich passe das dann an.

> Dann kann ich noch eine Kathrein-Sat-Rx FB bieten - dort meldet IRMP zu
> 90% RC5(x) und ab und zu RC6. (Timing-Problem?) Am funktionieren dieses
> Protokolls wäre ich am stärksten interessiert...

RC6 sieht verschiedene Modes vor und kann ziemlich kompliziert werden. 
Ich habe bisher nur Mode 0 implementiert, der auch hier

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

dokumentiert ist. Da RC6 teilweise(!) dieselben Timings wie RC5 benutzt, 
kann das dann schnell "verwechselt" werden - jedenfalls dann, wenn der 
Frame nicht den Mode 0, sondern irgendeinen anderen verwendet.

Auch hier helfen mir nur Scans.

> Noch eine Anmerkung zu der neuesten Änderung vom 2.3.: Meiner Meinung
> nach hat der Wegfall der Systemadresse bei SIRCS keinen Sinn bzw. es
> kommt auf den Anwendungsfall (?) an. Wenn ich an der TV-FB Power drücke
> will ich das doch von z.B. Power beim DVD-Player unterscheiden. Das geht
> nun nicht mehr, alles sieht gleich aus.

Die Infos gehen ja nicht verloren, die Device-IDs landen halt nun im 
Byte "command" statt "address". Daher sollte die TV-Power- und die 
DVD-Power-Taste durchaus ein unterschiedliches Kommando liefern. Vor 
dieser Änderung waren halt die Adressen verschieden aber die Kommandos 
gleich.

Bist Du sicher, dass da alles gleich aussieht? Dann muss es auch vor 
dieser Änderung gleich ausgesehen haben.

> Und eine letzte Sache ist mir noch aufgefallen: Die Kommandos die IRMP
> ausgibt sind in der Bitorder verdreht. Ok, das mag egal sein, denn
> eindeutig ist es auch so, aber typischerweise haben Zifferntasten 1..9
> aufsteigende Codes, in welchem Bereich auch immer. Daran kann man das
> Problem ganz gut erkennen. Dreht man die Bits um, sieht es sowohl bei
> SIRCS, NEC und KASEIKYO "schön" aus. Ggf. sind auch die Systemadressen
> bitverdreht, konnte ich noch nicht checken.

Einige Protokolle senden mit MSB-First, andere mit LSB-First. Die 
Arbeit, die Bits in der jeweils "richtigen" Reihenfolge zu speichern, 
wollte ich mir nicht machen. Hauptsache, die empfangenen Codes sind 
verschieden. Ist die Bitreihenfolge für Dich wichtig?

> Ok, langer Beitrag, sorry ;) Wenn ich mit meinem FB-Fundus irgendwie zum
> Fortgang dieses Projektes beitragen kann, würde ich es im Rahmen meines
> Zeitbudgets gerne tun.

Danke im voraus für die Scans ;-)

Gruß,

Frank

Di Pi schrieb:
> Da habe ich mit einer NoName-RC5 FB andere Erfahrungen gemacht. Da
> scheinem mir die Kommandos rein zufällig vergeben worden zu sein (sowohl
> 1..9 als auch alle anderen Tasten).

Interessant, bei RC5 sind die Codes für die Tasten eigentlich fest 
definiert, d.h. jede RC5-FB sollte das gleiche Command senden, wenn man 
die Taste "1" drückt. Die Adressen können natürlich voneinander 
abweichen.

> Sicher, dass dein Hersteller nicht vllt einfach absteigend nummeriert?

Das Problem ist die Bitreihenfolge. Einige Protokolle arbeiten mit 
MSB...LSB, andere mit LSB...MSB. Diese verschiedenen Bitreihenfolgen 
beachte ich nicht. Halte ich auch (bisher) nicht für wichtig. 
Hauptsache, jede Taste wird mit einem unterschiedlichen Code empfangen.

RC5 sendet übrigens mit MSB first, d.h. die Bitreihenfolge ist hier im 
IRMP "richtig" herum. Die Commands müssen dann für die Tasten 1-9 immer 
folgendermaßen aussehen:

Taste 1: command 0x0001
Taste 2: command 0x0002
...
Taste 9: command 0x0009

Ich werde die Bitreihenfolge im IRMP-Artikel mal dokumentieren. Dann 
kann sich jeder selbst überlegen, ob er die Bits nach dem Empfang 
nochmal "drehen" will oder nicht. Ich würde es nicht tun, halte ich für 
unnötigen Verschleiss des µCs ;-)

Gruß,

Frank

Hallo Frank,

anbei Scans von verschiedensten Codes. Insbesondere die letzten Tests 
mit der Kathrein FB sehen sehr merkwürdig aus, da IRMP meistens SIRCS 
meldet, es ist definitiv kein SIRCS. Ich vermute sehr stark RC5 / RC6, 
irgendetwas mit einem Toggle-Bit, damit kommt meine programmierbare FB 
nicht klar.

Interessant auch die Samsung Scans, die vom IRMP auf "höherem Layer" gar 
nicht angezeigt werden.

Getestet wurde das Ganze mit einem ATMEGA32@16MHz.

-Peter

Hallo Peter,

Peter K. schrieb:
> anbei Scans von verschiedensten Codes.

Vielen Dank für die Arbeit, die Du Dir gemacht hast. Ich schaue sie mir 
im Laufe des Tages an und melde mich dann.

Gruß,

Frank

Ich habe nun die einzelnen Scans von Peter durchgearbeitet:

Sony-RM-S-310:

  Protokoll: SIRCS
  Erkennung: 100%

Sony-RMT-V406:

  Protokoll: SIRCS
  Erkennung: 100%

Sony-RM-U305C:

  Protokoll: SIRCS
  Erkennung : 100% (nach Anpassung der SIRCS-Toleranzen)

Sony-RMT-D142P-DVD:

  Protokoll: SIRCS
  Erkennung : 100%

Panasonic-Blue-Ray:

  Protokoll: KASEIKYO
  Erkennung: 100% (nach Anpassung der Kaseikyo-Toleranzen)

  Prinzipiell kommt jeder Code 2x, beim 2. Mal ist Repetition-Flag
  gesetzt.
  @Peter: Du hast die Tasten aber nur kurz gedrückt? Wenn ja, muss ich
  Kaseikyo-Wiederholungen wegfiltern

Yamaha-RAV388:

  Protokoll: NEC
  Erkennung: 100%

  Auch hier kommt jeder Code 2x, Repetition-Flag ist ebenso gesetzt.
  Beim NEC-Protokoll habe ich das bisher aber noch nicht erlebt, dass
  Frames wiederholt werden.
  @Peter: Nochmal die Frage: auch da jede Taste nur 1x kurz gedrückt?

Samsung_TV:

  Diese FB benutzt zwar die gleichen Timings wie das bisherige SAMSUNG-
  Protokoll, aber es fehlt das längere Sync-Bit an 16. Stelle. Ausserdem
  ist die Länge nur 32 statt 37 Bits.

  Protokoll: SAMSUNG2 (NEU!)
  Erkennung: 100% (nach Anpassung des Source auf IRMP_SAMSUNG2_PROTOKOL)

  Siehe auch IRMP-Artikel, wurde angepasst bzgl. SAMSUNG2

Kathrein-UFS-912-Remote:

  Das ist echt ein harter Brocken. Das Protokoll ist RC6, aber der Frame
  besteht nicht aus 20 Bits, sondern aus 36 Bits. Der RC6-Mode ist ein
  anderer als der bisher bekannte, ausserdem liegt das Timing der
  Start-Bits sehr nahe am SIRCS-Protokoll. Da muss ich noch ein wenig
  Arbeit reinstecken...

Den Download im IRMP-Artikel werde ich heute abend aktualisieren, dann 
klappt es auch mit allen oben genannten Fernbedienungen einwandfrei. 
Ausnahme: Kathrein-FB, da kann es evtl. länger dauern.

Gruß,

Frank

Hi Frank,

na das Verarbeiten der Infos geht ja schnell... Ich werde heute abend 
nochmal einige Scans jeweils mit "Taste kurz gedrückt" vs. "Taste lang 
gedrückt" schicken. Wenns interessiert, kann ich auch noch verschiedene 
andere FB mal einscannen. Z.B. noch 'ne Kathrein, Thomson und Skymaster.

-Peter

Hi Peter,

Peter K. schrieb:

> na das Verarbeiten der Infos geht ja schnell...

Die meiste Arbeit war das Separieren in verschiedene Dateien und die 
Anpassung der Kommentare mit dem Editor ;-)

> Ich werde heute abend
> nochmal einige Scans jeweils mit "Taste kurz gedrückt" vs. "Taste lang
> gedrückt" schicken.

Prima, wäre klasse, wenn Du folgende Form wählen würdest:

1. Für jede FB eine eigene Datei
2. Vor jedem Scan eine Kommentar-Zeile, die mit '#' beginnt.

Beispiel für Sony-RM-S-310.txt:

# Taste: Power
00000000000000000000000000111100000000000000111100000000...
# Taste: 1
00000000000000000000000000111100000000000000111100000000...
usw.

> Wenns interessiert, kann ich auch noch verschiedene
> andere FB mal einscannen. Z.B. noch 'ne Kathrein, Thomson und Skymaster.

Kannst Du gerne machen.

Gruß,

Frank

Neue Version von IRMP zum Download verfügbar:

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

Erweiterungen/Änderungen:

- Neues Protokoll: SAMSUNG32 (Mix aus SAMSUNG & NEC-Protokoll)
- Änderung/Anpassung der SIRCS- und Kaseikyo-Timing-Toleranzen

Dank an Peter K. für die Scans.

Gruß,

Frank

Peter K. schrieb:
> KASEIKYO von einer Panasonic Blueray FB läuft auch super.

Hallo Peter,

Du hast anscheinend eine KASEIKYO FB, die müsste ja mit 56KHz senden. 
Hast Du einen TSOP1756 als Empfänger? Oder was sonst?

Ich hatte hier gerade ein Problem mit einem SFH 5110-36, der hat nicht 
mal mehr die 40KHz der Sony FB erkannt, ein TSOP1736 geht bei Sony noch, 
aber nicht bei 56KHz.

Hat eventuell jemand einen Tipp für einen breitbandigeren Empfänger?

Vielen Dank und viele Grüße an die IR Fans ;-)
Klaus

Hi Klaus,

ich habe hier so eine kleine Blechbüchse 1,5x1,5x1 cm als IR-Rx, vor 
Jahren mal bei "C" gekauft. Die funktioniert mit allen FB (Sony, 
Samsung, Yamaha, Panasonic) in ca. 50cm Entfernung. Das "DX"-Verhalten 
aus mehreren Metern Entfernung hab ich noch nicht getestet.

-Peter

Hi Frank,
anbei noch mal ein kurzer Scan von der Panasonic FB. Es gibt dort einen 
Unterschied bei Taste 3: Einmal ganz kurz gedrückt, einmal einen Moment 
länger. Ich wollte auch Dauerdrück aufzeichnen, allerdings stürzt dabei 
das Prog. anscheinend ab. Genauso hängt sich wohl was auf, wenn ich auf 
der Samsung32 dauernd drücke. Ich vermute, da läuft der scan-buffer 
über? Ich muss gestehen daß ich bisher mir noch nicht näher angucken 
konnte wie du das ganze implementiert hast.
Aber: Samsung wird jetzt gut erkannt, prima!

Ciao - Peter

Mehr Zeit müsste man haben :)

Peter K. schrieb:
> ich habe hier so eine kleine Blechbüchse 1,5x1,5x1 cm als IR-Rx, vor

OK, so ein Teil habe ich auch noch aus einem alten Fernseher, aber so 
was gibts wohl nicht mal mehr bei P*llin...

Danke für die Info,
Klaus

ich möchte mit einer Anwendung einige wenige Tasten einer (vorab 
unbekannten) Fernbedienung aufzeichnen und diese später wiedergeben 
können (in genau diesem Protokoll).

Hat jemand einen Tip für eine dazupassende generische *Sende*routine?

-Michael

Michael Haberler schrieb:
> ich möchte mit einer Anwendung einige wenige Tasten einer (vorab
> unbekannten) Fernbedienung aufzeichnen und diese später wiedergeben
> können (in genau diesem Protokoll).
>
> Hat jemand einen Tip für eine dazupassende generische *Sende*routine?

IRSND - diese hat gerade Klaus im Test ;-)

IRSND ist das Gegenstück zu IRMP. IRSND generiert aus der 
IRMP-Datenstruktur den Frame und schickt ihn auf eine IR-LED. Ich werde 
spätestens am Wochenende den IRSND zum Download ablegen.

Gruß,

Frank

Hi Peter,

Peter K. schrieb:
> anbei noch mal ein kurzer Scan von der Panasonic FB. Es gibt dort einen
> Unterschied bei Taste 3: Einmal ganz kurz gedrückt, einmal einen Moment
> länger.

Vielen Dank, sehr aufschlussreich. Der Frame wird nur 1x geschickt, wenn 
Du kurz drückst. Bei der Taste 3 (länger gedrückt) gab es zwei Frames, 
wobei IRMP dann korrekterweise das Repetition-Flag in irmp_data.flags 
gesetzt hat. Ist also alles okay.

> Ich wollte auch Dauerdrück aufzeichnen, allerdings stürzt dabei
> das Prog. anscheinend ab. Genauso hängt sich wohl was auf, wenn ich auf
> der Samsung32 dauernd drücke. Ich vermute, da läuft der scan-buffer
> über?

Könnte sein, da muss ich mir die Log-Funktion nochmal näher ansehen. 
Diese hatte Vlad Tepesch für das WordClock-Projekt erstellt und ich habe 
sie kurzerhand "assimiliert" ;-)

> Aber: Samsung wird jetzt gut erkannt, prima!

Freut mich. Ohne Logging stürzt das Programm auch nicht ab, oder?

> Mehr Zeit müsste man haben :)

Wie wahr...

Gruß,

Frank

Ich zitiere mich mal selbst ;-)
>OK, so ein Teil habe ich auch noch aus einem alten Fernseher, aber so
>was gibts wohl nicht mal mehr bei P*llin...

Als universeller Empfänger wäre wohl der U2538B prinzipiell geeignet:
Beitrag "Schaltung mit IR-Empfänger (LED) gesucht"

Mal sehen, wann der verfügbar wird, im Moment hat ihn digikey auch 
nicht.

Klaus

Hi!

Zuerst: super Arbeit hier!

Ich bin ain AVR Anfänger und habe dazu nun etwas Unsicherheit um den 
Code für den Atmeg8 zu verwenden!

1. F_CPU, benutze einen Quarz 12MHz:

1

main.c: #define F_CPU       12000000

2. Timer Register geändert:

1

TIMSK  = 1 << OCIE1A;                                                    // OCIE1A: Interrupt by timer compare (use TIMSK for ATMEGA162)

3. PD3 als Input:

1

/*---------------------------------------------------------------------------------------------------------------------------------------------------

2

 * Change hardware pin here:

3

 *---------------------------------------------------------------------------------------------------------------------------------------------------

4

 */

5

#define IRMP_PORT                               PORTD

6

#define IRMP_DDR                                DDRD

7

#define IRMP_PIN                                PIND

8

#define IRMP_BIT                                3                             // use PD3 as IR input

Habe aber etwas weiter oben im irmp.c das gefunden: static int PINB;
Muss ich denn auch auf PIND ändern?

Danke für Hilfe!

Hugo Portisch schrieb:

> 1. F_CPU, benutze einen Quarz 12MHz:
>

1

main.c: #define F_CPU       12000000

Wenn Du genau hinschaust, gilt das nur für den Codevision Compiler, Du 
siehst da was von

#ifdef CODEVISION
...
#define F_CPU 8000000
...
#endif

Hier nützt eine Änderung gar nichts, wenn Du den WinAVR (gcc) als 
Compiler nutzt. In diesem Fall musst Du im Projekt unter

    Project -> Configuration Options

den Processor_ und die _Taktrate einstellen.

> 2. Timer Register geändert:

Sieht gut aus.

> 3. PD3 als Input:
>  * Change hardware pin here:

Korrekt.

> Habe aber etwas weiter oben im irmp.c das gefunden: static int PINB;
> Muss ich denn auch auf PIND ändern?

Das ist nicht für Dich relevant, da dieses Statement im Block

#ifdef DEBUG
...
#endif

eingebettet ist. Das ist nur zum Debuggen unter Linux oder Windows.

Gruß,

Frank

Das mit F_CPU habe ich mir schon gedacht. Benutze GCC und habe in den 
Optionen Atmega8+12MHz eingestellt.

Sollte dann also passen, danke!

Eine neue Version von IRMP ist unter

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

verfügbar.

Änderungen:

1) Neues Protokoll: Apple

2) Bit-Order ist nun dem jeweiligen Protokoll angepasst.

Zu 1)

Das Apple-Protokoll ist bis auf eine Kleinigkeit identisch mit dem 
NEC-Protokoll und wird mit IRMP_SUPPORT_NEC_PROTOCOL == 1 erschlagen. 
Bisher wurde die Apple-FB immer als NEC-Protokoll ausgegeben, was aber 
eigentlich "gelogen" ist. Die Apple-FB hat daher jetzt einen eigenen 
Bezeichner IRMP_APPLE_PROTOCOL erhalten, damit der zukünftige Encoder 
IRSND den Apple-Frame wieder reproduzieren kann.

Zu 2)

Es hat hier schon einige gestört, dass bei Protokollen, welche das LSB 
zuerst ausgeben, die Tasten 1-9 scheinbar willkürliche Muster in 
irmp_data.command haben. Die gesendete Bitreihenfolge wird nun von IRMP 
berücksichtigt, bisher wurde immer mit MSB first gespeichert. Nun haben 
bei vielen FBs die Tasten 1-9 auch eine aufsteigende Reihenfolge in 
irmp_data.command. Dasselbe gilt natürlich auch für die Adresse.

Nachteil: Diejenigen, die Adressen und Kommandos von bestimmten 
Fernbedienungen bisher schon aufgezeichnet, gespeichert und verwendet 
haben, müssen das leider noch mal wiederholen, da nun für die 
LSB-Protokolle (siehe IRMP-Artikel) ganz andere Werte als bisher 
herauskommen. Sorry, aber Klaus Leidinger hat mich mittlerweile davon 
überzeugt, dass diese Lösung die bessere ist ;-)

Gruß,

Frank

Frank M. schrieb:
> Änderungen:
>
> 1) Neues Protokoll: Apple

Für alle CV Nutzer: damit stimmt diese Sequenz im aktuellen Download für 
den CodeVision Teil natürlich nicht mehr. Ich werde das anpassen und 
Frank schicken.

@Frank: Du bist immer für eine Überraschung gut ;-)

Klaus

Klaus Leidinger schrieb:
> @Frank: Du bist immer für eine Überraschung gut ;-)

Sorry, aber danke für Deine Anpassung in der main-Funktion des 
Codevision-Teils. Beim nächsten mal denke ich dran :-)

Den Download habe ich eben aktualisiert.

Gruß,

Frank

Eine neue Version von IRMP ist unter

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

verfügbar.

Grund:

Bugfix: Zurücksetzen der Statemachine nach einem unvollständigen 
RC5-Frame oder anderen "Schrott-Daten"

Der Fehler sorgte dafür, dass bei nachfolgenden Frames anderer 
Protokolle das Bit 6 im command prinzipiell immer gesetzt war. Durch 
Plausibilitätskontrollen wurden dann weitere empfangene Nicht-RC5-Frames 
verworfen oder falsch abgebildet - bis zum Reset des AVR oder bis wieder 
ein vollständiger RC5-Frame empfangen wurde.

Vielen Dank an Klaus Leidinger, der diesem Fehler durch unermüdliches 
nächtelanges Suchen auf die Spur kam :-)

Gruß,

Frank

Hallo,

wie bereits angekündigt, gibt es nun eine Alpha-Version von IRSND.

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

IRSND unterstützt die folgenden Protokolle:

    * SIRCS
    * NEC
    * SAMSUNG
    * SAMSUNG32
    * MATSUSHITA
    * RECS80
    * RC5
    * DENON
    * APPLE

IRSND unterstützt folgende Protokolle (noch) nicht:

    * KASEIKYO
    * RC6


Näheres dazu steht im IRMP-Artikel, nämlich unter

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

Der Download-Link ist dort auch zu finden.

Vielen Dank an Klaus Leidinger, der mich bei der Entwicklung von IRSND 
tatkräftig als Tester unterstützt hat :-)

Gruß,

Frank

Hi,

ich hätte da noch eine Frage zu dem Timer.

Ich habe Irmp mit V-USB kombiniert.

Bei einem PC geht es ohne Probleme, bei einem anderen PC wird der AVR 
nicht als USB-Gerät erkannt.

Durch testen habe ich rausgefunden, wenn ich den Timer-Init raus lasse, 
geht es:

1

int main(void)

2

{

3

uchar   i;

4

5

6

    wdt_enable(WDTO_2S);

7

    /* Even if you don't use the watchdog, turn it off here. On newer devices,

8

     * the status of the watchdog (on/off, period) is PRESERVED OVER RESET!

9

     */

10

    DBG1(0x00, 0, 0);       /* debug output: main starts */

11

    /* RESET status: all port bits are inputs without pull-up.

12

     * That's the way we need D+ and D-. Therefore we don't need any

13

     * additional hardware initialization.

14

     */

15

    odDebugInit();

16

    usbInit();

17

    usbDeviceDisconnect();  /* enforce re-enumeration, do this while interrupts are disabled! */

18

    i = 0;

19

    while(--i){             /* fake USB disconnect for > 250 ms */

20

        wdt_reset();

21

        _delay_ms(1);

22

    }

23

    usbDeviceConnect();

24

25

  //clear irmp_data

26

  irmp_data.protocol = 0;

27

  irmp_data.address = 0;

28

  irmp_data.command = 0;

29

  irmp_data.flags = 0;

30

31

  irmp_init();                                                              // initialize irmp code

32

  //timer_init();                                                             // initialize timer

33

34

    sei();

35

36

    DBG1(0x01, 0, 0);       /* debug output: main loop starts */

37

    for(;;){                /* main event loop */

38

        DBG1(0x02, 0, 0);   /* debug output: main loop iterates */

39

        wdt_reset();

40

        usbPoll();

41

    }

42

    return 0;

43

}

Wie kann ich das Problem umgehen? Danke!

Schaffe es einfach nicht!

Habe schon vieles Probiert - jedoch kein Erfolg.

Es geht Problemlos bei diesem Board:
http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?ProductID=2624

Bei diesem geht es nicht:
http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?ProductID=3141

Im Anhang der derzeitige Source.
Atmega8 mit 12MHz Quarz.

Michael M. schrieb:
> die v-usb routinen müsstest du also mit cli()...sei() umklammern. ob das
> der funktion guttut, steht auf einem anderen blatt.

Vermutlich geht das so nicht, weil die V-USB-Funktionen laut 
http://www.obdev.at/products/vusb/index-de.html einen "edge triggered 
interrupt" benötigen.

Da müsste man schon gezielt den Timer1-Interrupt ein-/ausschalten.

@Hugo: Klappt es denn mit der USB-Erkennung, wenn Du in irmp_ISR() einen 
vorzeitigen return einbaust?

Gruß,

Frank

Michael M. schrieb:
> hm, wo steht das denn? ich hab nur das hier gefunden:
>> No UART, timer, input capture unit or other special hardware is required

Direkt in der Zeile darunter:

"No UART, timer, input capture unit or other special hardware is 
required (except one edge triggered interrupt)."

Gruß,

Frank

1

@Hugo: Klappt es denn mit der USB-Erkennung, wenn Du in irmp_ISR() einen

2

vorzeitigen return einbaust?

3

4

Gruß,

5

6

Frank

Ja, wenn ich irmp_ISR(); auskommentiere dann geht es!

Das komische ist halt, dass an einem PC ohne Probleme geht.
An dem PC wo ich den Empfänger eigentlich einsetzen will geht es nicht 
:(

Da ich leider den Beitrag nicht editieren kann:

V-USB benötigt ja die D+ Line auf einen Interrupt Pin. Am besten INT0.
Beim Atmega8 PD2.

Die TSOP1736 habe ich auf PD3 (INT1) gelegt.
Irmp braucht ja keinen Interrupt Pin da es ja mit Polling arbeitet, 
oder?
Vielleicht hilft es, wenn man einen anderen Port als PD3 verwendet?

Hugo Portisch schrieb:

> Irmp braucht ja keinen Interrupt Pin da es ja mit Polling arbeitet,
> oder?

Richtig.

> Vielleicht hilft es, wenn man einen anderen Port als PD3 verwendet?

Nein, das wird nichts bringen. Aber da es mit dem einen Board geht und 
mit dem anderen nicht, liegt der AVR wohl knapp am Timing vorbei. 
Schalte doch mal in irmp.c diejenigen Protokolle ab, die Du nicht 
brauchst. Vielleicht hilft das schon... obwohl, solange kein IR-Signal 
reinkommt, macht die ISR auch so gut wie gar nichts.

Gruß,

Frank

Man O Man, ich dreh noch durch!

Bei auskommentieren des irmp_ISR(); geht es bei beiden PCs.
Mit der Funktion geht es nur bei einem.

Auch ein "Abspecken" der IR-Funktionen auf NEC, RC5 & RC6 bringt nichts.

Kann man es irgendwie machen, dass der Timer1 erst ~ 2 Sekunden nach dem 
Reset/Boot gestartet wird?

Ich schätze einmal, das wenn nach dem Einstecken (Reset) das USB-Init 
mit dem Host vorbei ist es keine Probleme mehr geben sollte...

Danke!

Hugo Portisch schrieb:

> Kann man es irgendwie machen, dass der Timer1 erst ~ 2 Sekunden nach dem
> Reset/Boot gestartet wird?

Dafür gibt es mehrere Möglichkeiten, zum Beispiel könntest Du 
timer_init() erst nach 2 Sekunden aufrufen, z.B. so:

1

  _delay_ms (2000);

2

  timer_init ();

> Ich schätze einmal, das wenn nach dem Einstecken (Reset) das USB-Init
> mit dem Host vorbei ist es keine Probleme mehr geben sollte...

Gruß,

Frank

Habe es geschafft!

Dem _delay habe ich nicht getraut, da warscheinlich auch das USBPoll 
benötigt wird.

Ich starte nun den Timer0 beim Reset.
Nach 0xFF durchläufen wird Timer0 abgeschaltet und der Timer1 für das IR 
Polling gestartet.

Somit fängt der IR Timer erst ~5s nach dem Reset an.

AVR wird als USB Gerät erkannt und funktioniert einwandfrei!

Ist zwar nicht so schön geht aber nun!

Anbei das neue Projekt!

Danke für Hilfe und für Irmp!

Hi, nochmal ich!

Kann die Beiträge einfach nicht editieren :(

Da es nun am zweiten PC läuft habe ich mir den Empfang der IR Codes 
angesehen.
Es geht sehr träge und es wird nicht jeder Code erkannt.

Beim anderen PC geht es ohne Probleme, schnelle Erkennung und es werden 
auch alle Tasten erkannt.

NEC wird z.B am 2. PC gar nicht erkannt.

Woran kann das jetzt noch liegen, oder wie kann ich dem Problem auf die 
Spur kommen?

1

Ich habe mir deinen Quelltext nicht im Detail angesehen: betreibst du

2

den AVR als USB-HID, sprich "Tastaturersatz"? Falls ja wofür und

3

funktioniert es einwandfrei?

Kein "Tastaturersatz"...

Per USB-Polling des AVRs können die Codes gelesen werden (Protokoll, 
Adress, Command & Flags). Er wird als USB-HID betrieben, somit sind 
keine Treiber notwendig.

Bei HID ist ein Feature Transfer von <=8 Bytes recht einfach. Die 
Struckt von Irmp sind ja nur 6Bytes ;).

Was man mit den Daten dann macht ist jedem selber überlassen.
Ich z.B. benütze es als Input-Plugin für DVBViewer.
Der AVR lernt auch den ersten empfangen Befehl. Per Flag kann dann 
dieser Befehl zum schalten eines Optokopplers verwendet werden um die 
Powertaste des PCs zu betätigen (Einschalten des PCs per Fernbedienung).
Werde dann noch eine Beispiel-Host Anwendung bereitstellen.

Man könnte aber auch ein Programm schreiben, dass die Codes in 
Tastendrücke umwandelt. So ist ja die Idee von Irmp.
Jedoch will ich das nicht im AVR machen, sondern auf der Host Seite.
Somit muss ich für neue Befehle den AVR nicht neu programmieren.

Ein kleines Update zu dem USB Problem bei dem einem Mainboard.
Ich glaube fast, dass es am USB von Mainbaord liegt.
Die Codes werden schon richtig vom AVR ausgewertet, jedoch funktioniert 
das Polling über USB nur sehr träge.

Beim anderen PC flutschen die Daten sofort rüber. Steuerung des 
DVBViewer geht Super.

Werde mir einmal eine PCI-USB Karte ausleihen, damit ich den Fehler 
weiter eingrenzen kann.

Hallo Frank,

geniale Sache, dieses IRSND. Habe heute mal damit etwas rumgespielt und 
kann bestätigen, daß SIRCS funktioniert (andere Protos hab ich noch 
nicht getestet). Allerdings ist es ziemlich unempfindlich, kann sein daß 
es an meiner IR-Diode liegt oder aber am Timing. Zu weitergehenden 
Untersuchungen bin ich leider noch nicht gekommen.

Da einige Timerregister insbesondere beim Mega32 anders heißen und auch 
der Output-Pin anders liegt, habe ich mal in die beiden *.c - files ein 
paar "if defined" reingebaut. Es wäre schön, wenn du dies in deine 
sourcen übernehmen könntest, das würde helfen, die Software leicht auf 
einem Mega32 oder Mega644P (mit den beiden hab ich herumgespielt) laufen 
zu lassen. Weitere AVR-Typen könnte man bei Bedarf hinzufügen.
Die modifizierten sourcefiles sind hier angehängt.

-Peter

Hallo Peter,

Peter K. schrieb:

> Da einige Timerregister insbesondere beim Mega32 anders heißen und auch
> der Output-Pin anders liegt, habe ich mal in die beiden *.c - files ein
> paar "if defined" reingebaut.

Danke für Deine Vorschläge, werde ich so übernehmen.

Gruß,

Frank

Um nicht zu sehr Off-Topic zu werden habe ich einmal einen neuen Thread 
aufgemacht: Beitrag "Irmp + V-USB, geht nicht an jedem USB-Port"

Es geht um Irmp + V-USB, Probleme an verschiedenen USB-Ports.

IRMP löft auch auf einen PIC

danke für die Arbeit