www.mikrocontroller.net

Forum: Projekte & Code IRMP - Infrared Multi Protocol Decoder


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

Bewertung
4 lesenswert
nicht lesenswert
Aktualisierung
Die IRMP-Software kann unter IRMP --> Download
heruntergeladen werden.


Hallo zusammen,

Anmerkung:

Dieser Source entstand im Rahmen des Projektes "WordClock", siehe

Artikel

   http://www.mikrocontroller.net/articles/Word_Clock

bzw. Thread, der alles zum Auslösen gebracht hat:

   Beitrag "Brauche Hilfe beim Bau einer Uhr"

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

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

SIRCS:      Sony.
NEC:        NEC, Yamaha, Canon, Tevion, Harman/Kardon, Hitachi, JVC,
            Pioneer, Toshiba, Xoro, Orion, NoName
            und viele weitere japanische Hersteller.
SAMSUNG:    Samsung
MATSUSHITA: Matsushita
KASEIKYO:   Panasonic, Denon und andere japanische Hersteller, welche 
Mitglied
            der  "Japan's Association for Electric Home Application" 
sind.
RECS80      Philips, Nokia, Thomson, Nordmende, Telefunken, Saba


Zum Source-Code

irmp.c:

Zu Anfang werden die verschiedenen Signalformen und -Zeiten 
dokumentiert. Ein Blick darauf zum Verständnis ist bestimmt ganz 
interessant :-)

IRMP decodiert sämtliche oben aufgelisteten Protokolle in einer ISR. 
Möchte man davon einige aus Platzgründen deaktivieren, sind die 
entsprechenden Werte in irmp.c

#define IRMP_SUPPORT_SIRCS_PROTOCOL           1 // flag: support SIRCS, 
1=yes, 0=no
#define IRMP_SUPPORT_NEC_PROTOCOL             1 // flag: support NEC, 
1=yes, 0=no
#define IRMP_SUPPORT_SAMSUNG_PROTOCOL         1 // flag: support 
Samsung, 1=yes, 0=no
#define IRMP_SUPPORT_MATSUSHITA_PROTOCOL      1 // flag: support 
Matsushita, 1=yes, 0=no
#define IRMP_SUPPORT_KASEIKYO_PROTOCOL        1 // flag: support 
Kaseikyo, 1=yes, 0=no
#define IRMP_SUPPORT_RECS80_PROTOCOL          1 // flag: support RECS80, 
1=yes, 0=no

auf 0 zu setzen. Dann wird der Decoder für diese Protokolle nicht 
mitübersetzt.

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

IRMP trennt diese IR-Telegramme prinzipiell in 3 Bereiche:

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

Mittels der Funktion

   irmp_get_data (IRMP_DATA * irmp_data_p)

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

      irmp_data_p->protocol
      irmp_data_p->address
      irmp_data_p->command

gefüllt, einen Beispiel-Aufruf nebst Erklärung findet man in main.c, 
welches lediglich ein Grundgerüst darstellen soll.

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

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

Um direkt Kritikern den Wind aus den Segeln zu nehmen:

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

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

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

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

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

eingestellt.

Als letztes:

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

  cc irmp.c -o irmp                              # IRMP compilieren
  ./irmp.c < IR-Data/Samsung_DVD_Rec_00062C.txt  # irmp ausführen

IRMP gibt dann das erkannte Protokoll und weitere Timing-Daten aus. 
Diese Dateien haben mir bei der Entwicklung des IRMP enorm geholfen, 
Dank an Vlad Tepesch, der diese Dateien mittels 10000Hz-ISR gescannt und 
über UART protokolliert hat!

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

Viel Spaß damit!

Frank M.

Autor: I. E. (anfaenger69)
Datum:

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

Autor: eku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank!

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. Eine Dekoderfunktion sammelt die Werte 
aus der FIFO, erkennt das Protokoll und dekodiert die Sequence. Worin 
liegt der Vorteil Deiner Implementierung?

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

Bewertung
0 lesenswert
nicht lesenswert
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:
typedef struct
{
  uint8_t   protocol;          // protocol, i.e. IRMP_NEC_PROTOCOL
  uint16_t  address;           // address
  uint16_t  command;           // command
} 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:
   if (irmp_data.protocol == IRMP_NEC_PROTOCOL &&     // NEC-Protokoll
       irmp_data.address == 0x00FF)                   // Adresse 0x00FF
   {
      switch (irmp_data.command)
      {
         case 0x0001: key1_pressed(); break;          // Taste 1
         case 0x0002: key2_pressed(); break;          // Taste 2
         ...
         case 0x0009: key9_pressed(); break;          // Taste 9
      }
   }

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

Autor: Sebastian___ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
Wie geht das beim Sircs Protokoll? ein Kommando wird 3x wiederholt, nach 
der wiederholung müsste man das kommando erneut auslösen.

Autor: eku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank!

Frank M. schrieb:
> 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

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. Die einen Indirektion bei der 
Adressierung sollte auf Grund der anderen Ersparnis nicht ins Gewicht 
fallen. Der Code würde noch dazu leserlicher.

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

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

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

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

Autor: eku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank!

Frank M. schrieb:
> 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.

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.

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

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

Autor: Sebastian___ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
Ich habe mir das mal auf dem Oszi angeschaut. (ist ein Sony DVD Player)

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

Bewertung
0 lesenswert
nicht lesenswert
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:
#define SIRCS_REPETITION_TIME                 (uint16_t)(F_INTERRUPTS * 50.0e-3 + 0.5)          // repetition after ~45-50 msec
...
        // if SIRCS protocol and the code will be repeated inside of 50 ms, we will ignore it.
        if (irmp_protocol != IRMP_SIRCS_PROTOCOL || last_irmp_command != irmp_tmp_command || repetition_counter > SIRCS_REPETITION_TIME)
...

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

Autor: Michael M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
um sowas zu testen und solche codes zu simulieren würde ich einen 
simulator für AVRs benutzen - namentlich proteus isis.
gibt viele möglichkeiten, sich dort eine passende quelle 
zusammenzubauen.

demo und info unter: 
http://www.labcenter.co.uk/products/vsm_overview.cfm

frank, falls du das machen willst und ich dir helfen kann, schreib mich 
doch kurz an.

holli

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

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

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

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

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

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

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

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

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

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

Autor: Sebastian___ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin gerade dabei den IRMP Code auf Interrups umzubauhen.
Die Zeitbasis commt aus einem Counter mit 25Khz (per IRQ).
Somit kann das Polling entfallen und man hat eine Speichersparende 
lösung.
Das ist aber nicht ganz so einfach. ;)

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

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

Autor: Sebastian___ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja eben,
das frisst rechenleistung wen man keinen timer irq damit blockieren 
will.
Daher ist es meiner meinung nach besser einen richtigen Init zu nehmen 
der flankengesteuert reagiert. Und nur noch ab und zu mal im timer IRQ 
auf timeout zu prüfen.

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

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

Autor: Sebastian___ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Speichereinsparung war drauf bezogen im Vergleich zu der hier geposteten 
Interruptgesteuerten Routine die ja das komplette data Frame gesichert 
hat und dann in der Main auswertet.

im prinzip geht deine Routine auch flankengetriggert, man muss nur ne 
zeitbasis hinzufügen (aus timer) und für ne abbuchbedingung sorgen wenn 
keine flanken mehr kommen.
Wenn ich soweit bin werde ich mal ein bischen was dazu posten.
Deine Defines der verschiedenen protokolle sind auf jeden fall sehr 
hilfreich.

Autor: Sebastian___ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo ich habe noch einen kleine Fehler gefunden, das 
MATSUSHITA_PROTOCOL wird nie erkannt, nur das SAMSUNG_PROTOCOL.

die Defines für das erkennen der start Bits haben eine zu große 
Toleranz, wenn man die für :

#define MATSUSHITA_START_BIT_PULSE_LEN_MIN
#define MATSUSHITA_START_BIT_PULSE_LEN_MAX
#define MATSUSHITA_START_BIT_PAUSE_LEN_MIN
#define MATSUSHITA_START_BIT_PAUSE_LEN_MAX

und

#define SAMSUNG_START_BIT_PULSE_LEN_MIN
#define SAMSUNG_START_BIT_PULSE_LEN_MAX
#define SAMSUNG_START_BIT_PAUSE_LEN_MIN
#define SAMSUNG_START_BIT_PAUSE_LEN_MAX

auf 20% setzt, geht die Protokollerkennung.

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

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

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

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

Autor: Sebastian___ (Gast)
Datum:

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

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

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

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

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

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

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

Autor: Bastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat evtl. jemand von euch ne Apple Fernbedienung aus Alu?

Autor: IR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Frank M. (ukw):
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.

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

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

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

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

Autor: Di Pi (drpepper) Benutzerseite
Datum:

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

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

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

Autor: RC5 (Gast)
Datum:

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

So ziemlich alle FB bei mir laufen auf RC5. Gerade bei Universal-FBs ist 
das noch weit verbreitet und sollte der Vollstädigkeit halber mit 
eingebunden werden. Gerade einfache Projekte im µC Bereich nutzen of 
noch RC5.

Autor: Michael M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. 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...
LED RGB REMOTE
http://www.reichelt.de/?;ARTICLE=92594

Autor: Toralf Wilhelm (willi)
Datum:

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

Autor: Di Pi (drpepper) Benutzerseite
Datum:

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

Autor: Michael M. (Gast)
Datum:
Angehängte Dateien:

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

Autor: Di Pi (drpepper) Benutzerseite
Datum:

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

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

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

Autor: Michael M. (Gast)
Datum:

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

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

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

Autor: Michael M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Danke, ist eingebaut
ui, da hat es aber eine prominente position bekommen =)
danke!

grüße,
michael

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

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

Autor: Michael M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
da fällt mir grade was auf:
in dem bild "Anschluß eines IR-Empfängers an µC" ist der im datenblatt 
vorgeschlagene RC tiefpass falsch aufgebaut.
der aufbau in dem bild dürfte die empfindlichkeit um einiges 
verschlechtern.

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

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

Autor: Di Pi (drpepper) Benutzerseite
Datum:

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

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

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

Autor: Michael K. (kichi)
Datum:

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

Autor: Frank Boe (frank_boe)
Datum:

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

Autor: Michael M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
meine yamaha-fb auch.

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

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

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

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

Autor: Toralf Wilhelm (willi)
Datum:

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

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

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

Autor: Toralf Wilhelm (willi)
Datum:

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

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

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

Autor: Toralf Wilhelm (willi)
Datum:

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

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

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

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

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

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

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

Autor: Simon K. (simon) Benutzerseite
Datum:

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

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

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

Autor: Toralf Wilhelm (willi)
Datum:

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

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

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

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

Autor: siegmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Leute,
tolles Projekt !!
Ich habe aber leider ein gänzlich anderes Problem.
Weiß Jemand ob es eine Art Datenbank gibt, wo man herausfinden kann, 
welches IR Protokoll ein Gerät benutzt ?
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.
Der IR Epfänger funktioniert.
Habe mir die Signale mit dem Scope angeschaut.
Würde den Sat Receiver ungern wegwerfen, denn wenn ich bedenke wieviel 
Dreck bei der Produktionen einen Neuen ensteht ...
Vielleicht hat ja Jemand einen guten Tip.

Wünsche allen noch schönen Tag
Gruß
Siegmar

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

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

Autor: siegmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Sicher, dass der Receiver tatsächlich was empfängt?

Hallo Frank,
ja, ich hab das Oszi dran gehabt und saubere Impulse gesehn.
Eine Universalfernbedienung hat alle mölichen Protokolle durchgepulst 
und ich hab mir dann auf dem Oszi die Signale angeschaut.
Die Originalfernbedienung hab ich leider nicht mehr !!

Danke für deinen Tipp
Noch einen schönen Abend
Gruß
Siegmar

Autor: Michael K. (kichi)
Datum:

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

Autor: Klaus Leidinger (klausleidinger)
Datum:
Angehängte Dateien:

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

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

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

Autor: Albert K. (datasec)
Datum:

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

Grüße,
Albert

Autor: Klaus Leidinger (klausleidinger)
Datum:

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

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

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

Autor: siegmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael K. schrieb:
> 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.

Danke für den Tip.
Ob es micht weiter bringt ?
Wenn ich nur wüßte, welche Codierung der SAT Receiver benutzt.
Nun ja ....... mal sehn.
Trotzdem Danke und noch einen schönen Tag
Gruß
Siegmar

Autor: Di Pi (drpepper) Benutzerseite
Datum:

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

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

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

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

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

Autor: Klaus Leidinger (klausleidinger)
Datum:

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

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

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

Autor: Chris M. (shortie)
Datum:

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

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

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

Autor: Chris M. (shortie)
Datum:

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

Autor: Michael Urban (murban)
Datum:

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

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

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

Autor: Di Pi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin sehr daran interessiert, unterscheiden zu können, ob es eine 
Wiederholung oder ein neuer tastendruck (auch derselben taste) ist.

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

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

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

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

Autor: Michael Urban (murban)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
typedef struct
{
  uint8_t               protocol;                                                               // protocol, i.e. NEC_PROTOCOL
  uint16_t              address;                                                                // address
  uint16_t              command;                                                                // command
  uint8_t               repetition;                                                               // repetition frame
} IRMP_DATA;

an der entsprechenden Stelle für die Erkennung von repetition frames:
          if (irmp_tmp_protocol == IRMP_NEC_PROTOCOL && irmp_bit == 0)                            // repetition frame
          {
            irmp_protocol = irmp_tmp_protocol;
            irmp_address = last_irmp_address;                                                     // address is last address
            irmp_command = last_irmp_command;                                                     // command is last command
            irmp_repetition = 1;   // Marker repetition flag
          }

(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

Autor: Michael Urban (murban)
Datum:

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

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

Bewertung
0 lesenswert
nicht lesenswert
> 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:
#define IRMP_FLAG_REPETITION    0x01
#define IRMP_FLAG_WASWEISSICH   0x02
....

typedef struct
{
  uint8_t          protocol;           // protocol, i.e. NEC_PROTOCOL
  uint16_t         address;            // address
  uint16_t         command;            // command
  uint8_t          flags;              // flags, e.g. repetition frame
} 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:
   if (irmp_data.flags & IRMP_FLAG_REPETITION)
   {
      finger_blau();
   }
   else
   {
      normale_taste();
   }

Gruß,

Frank

Autor: Di Pi (Gast)
Datum:

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

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

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

Autor: Di Pi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn es wirklich nur 50 Bytes sind, ists meiner Meinung nach nicht 
nötig, es per Flag abschaltbar zu machen.

Ich habe mir noch nicht so detaillierte Gedanken über die konkrete 
Umsetzung gemacht. Dein Ansatz aber klingt für mich sehr plausibel und 
wirklich klein.

Er könnte sogar diverse Togglebits komplett ablösen (und dadurch den 
code verkleinern), wenn man davon ausgeht, dass

"
>Jede FB schafft bei
>Festhalten einer Taste ca. 10 Frames pro Sekunde. Aber keiner klickt so
>schnell einzeln auf der FB rum.
"

immer gilt.

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

Bewertung
0 lesenswert
nicht lesenswert
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:
    if (irmp_data.flags & IRMP_FLAG_REPETITION)
    {
      finger_blau (irmp_data.command);
    }
    else
    {
      einzeln (irmp_data.command);
    }

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.

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

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

Autor: Peter K. (peko)
Datum:

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

Autor: Di Pi (drpepper) Benutzerseite
Datum:

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

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

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

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

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

Autor: Peter K. (peko)
Datum:
Angehängte Dateien:

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

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

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

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

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

Autor: Peter K. (peko)
Datum:

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

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

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

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

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

Autor: Klaus Leidinger (klausleidinger)
Datum:

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

Autor: Peter K. (peko)
Datum:

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

Autor: Peter K. (peko)
Datum:
Angehängte Dateien:

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

Autor: Klaus Leidinger (klausleidinger)
Datum:

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

Autor: Michael Haberler (mah)
Datum:

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

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

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

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

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

Autor: Klaus Leidinger (klausleidinger)
Datum:

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

Autor: Hugo Portisch (portisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
main.c: #define F_CPU       12000000

2. Timer Register geändert:
TIMSK  = 1 << OCIE1A;                                                    // OCIE1A: Interrupt by timer compare (use TIMSK for ATMEGA162)

3. PD3 als Input:
/*---------------------------------------------------------------------------------------------------------------------------------------------------
 * Change hardware pin here:
 *---------------------------------------------------------------------------------------------------------------------------------------------------
 */
#define IRMP_PORT                               PORTD
#define IRMP_DDR                                DDRD
#define IRMP_PIN                                PIND
#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!

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

Bewertung
0 lesenswert
nicht lesenswert
Hugo Portisch schrieb:

> 1. F_CPU, benutze einen Quarz 12MHz:
>
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

Autor: Hugo Portisch (portisch)
Datum:

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

Sollte dann also passen, danke!

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

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

Autor: Klaus Leidinger (klausleidinger)
Datum:

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

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

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

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

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

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

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

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

Autor: Hugo Portisch (portisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
int main(void)
{
uchar   i;


    wdt_enable(WDTO_2S);
    /* Even if you don't use the watchdog, turn it off here. On newer devices,
     * the status of the watchdog (on/off, period) is PRESERVED OVER RESET!
     */
    DBG1(0x00, 0, 0);       /* debug output: main starts */
    /* RESET status: all port bits are inputs without pull-up.
     * That's the way we need D+ and D-. Therefore we don't need any
     * additional hardware initialization.
     */
    odDebugInit();
    usbInit();
    usbDeviceDisconnect();  /* enforce re-enumeration, do this while interrupts are disabled! */
    i = 0;
    while(--i){             /* fake USB disconnect for > 250 ms */
        wdt_reset();
        _delay_ms(1);
    }
    usbDeviceConnect();

  //clear irmp_data
  irmp_data.protocol = 0;
  irmp_data.address = 0;
  irmp_data.command = 0;
  irmp_data.flags = 0;

  irmp_init();                                                              // initialize irmp code
  //timer_init();                                                             // initialize timer

    sei();

    DBG1(0x01, 0, 0);       /* debug output: main loop starts */
    for(;;){                /* main event loop */
        DBG1(0x02, 0, 0);   /* debug output: main loop iterates */
        wdt_reset();
        usbPoll();
    }
    return 0;
}

Wie kann ich das Problem umgehen? Danke!

Autor: Michael M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
vermutlich bekommst du probleme mit dem timing seitens usb, wenn die 
v-usb routinen vom timer interrupt unterbrochen werden.
die v-usb routinen müsstest du also mit cli()...sei() umklammern. ob das 
der funktion guttut, steht auf einem anderen blatt.

Autor: Hugo Portisch (portisch)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Schaffe es einfach nicht!

Habe schon vieles Probiert - jedoch kein Erfolg.

Es geht Problemlos bei diesem Board:
http://www.gigabyte.com.tw/Products/Motherboard/Pr...

Bei diesem geht es nicht:
http://www.gigabyte.com.tw/Products/Motherboard/Pr...

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

Autor: Michael M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja, das wird ein timing-problem sein.
erstell doch einfach einen eigenen thread, das wird sicher noch ne 
längere angelegenheit.

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

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

Autor: Michael M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hm, wo steht das denn? ich hab nur das hier gefunden:
> No UART, timer, input capture unit or other special hardware is required

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

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

Autor: Michael M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
puh... dann nehm ich mal die tomaten runter ^^
sorry

Autor: Hugo Portisch (portisch)
Datum:

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

Gruß,

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 
:(

Autor: Hugo Portisch (portisch)
Datum:

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

Autor: Sebastian___ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das problem beim V-USB ist, das ein anderer IRQ den externen IRQ für den 
USB um max 20µs verzögern darf. Dh. wenn man andere IRQs mit dem USB 
nutzen will muß man dafür sorgen das der USB IRQ immer möglichst ohne 
latenz abgearbeitet werden kann, sonst passt das timeing für die USB 
frames nicht mehr.
Das Polling vom usb in der Main ist unktitisch. Wichtig ist NUR das der 
externe IRQ für den USB immer sofort bearbeitet werden kann.

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

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

Autor: Hugo Portisch (portisch)
Datum:

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

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

Bewertung
0 lesenswert
nicht lesenswert
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:
  _delay_ms (2000);
  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

Autor: Hugo Portisch (portisch)
Datum:
Angehängte Dateien:

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

Autor: Hugo Portisch (portisch)
Datum:

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

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hugo Portisch schrieb:
> Habe es geschafft!
Ich habe mir deinen Quelltext nicht im Detail angesehen: betreibst du 
den AVR als USB-HID, sprich "Tastaturersatz"? Falls ja wofür und 
funktioniert es einwandfrei?

Hugo Portisch schrieb:
> Kann die Beiträge einfach nicht editieren :(
Das geht nur ein paar Minuten (10?) nach dem Verfassen eines Beitrages, 
danach nicht mehr.

Autor: Michael M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Micha schrieb:
> Hugo Portisch schrieb:
>> Habe es geschafft!
> Ich habe mir deinen Quelltext nicht im Detail angesehen: betreibst du
> den AVR als USB-HID, sprich "Tastaturersatz"? Falls ja wofür und
HID ist nicht zwingend eine tastatur oder maus.
siehe http://en.wikipedia.org/wiki/USB_human_interface_d...

> Hugo Portisch schrieb:
>> Kann die Beiträge einfach nicht editieren :(
> Das geht nur ein paar Minuten (10?) nach dem Verfassen eines Beitrages,
> danach nicht mehr.
15 min sind es. und es geht auch dann nicht mehr, wenn jemand nach dem 
zu editierenden betrag etwas geschrieben hat.
dass der link zum editieren auch nach 15min noch angezeigt wird, ist ein 
(schon bekannter) fehler.

sry für den OTp

Autor: Hugo Portisch (portisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mir deinen Quelltext nicht im Detail angesehen: betreibst du
den AVR als USB-HID, sprich "Tastaturersatz"? Falls ja wofür und
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.

Autor: Peter K. (peko)
Datum:
Angehängte Dateien:

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

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

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

Autor: Hugo Portisch (portisch)
Datum:

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

Autor: Christian F. (bleuicebox)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
IRMP löft auch auf einen PIC

danke für die Arbeit

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

Bewertung
0 lesenswert
nicht lesenswert
Christian F. schrieb:
> IRMP löft auch auf einen PIC

Super! Kann man Deine Portierung irgendwie in den Source übernehmen? 
Wäre doch eine echte Bereicherung.

Gruß,

Frank

Autor: eku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank!

irmp_ISR() macht mehrfach IRMP_PIN & (1 << IRMP_BIT) zu 
unterschiedlichen (Lauf-)Zeiten bei immer gleichen irmp_pulse_time. 
Außerdem geht der Code davon aus, dass der IR-Empfänger low-aktiv ist.

Ich würde den Code zum Einlesen aus irmp_ISR() herausziehen und den 
aktuellen Wert per Argument übergeben, z.B.:
--- Irmp.org/irmp.c     2010-03-07 11:54:40.000000000 +0100
+++ Irmp/irmp.c 2010-03-12 18:06:15.105627851 +0100
@@ -668,7 +668,7 @@
  *---------------------------------------------------------------------------------------------------------------------------------------------------
  */
 void
-irmp_ISR (void)
+irmp_ISR (const uint8_t data)
 {
     static uint8_t    irmp_start_bit_detected;                                  // flag: start bit detected
     static uint8_t    wait_for_space;                                           // flag: wait for data bit space
@@ -705,7 +705,7 @@
     {                                                                           // yes... wait for application to get data
         if (! irmp_start_bit_detected)                                          // start bit detected?
         {                                                                       // no...
-            if (!(IRMP_PIN & (1 << IRMP_BIT)))                                  // receiving burst?
+            if (!data)                                                          // receiving burst?
             {                                                                   // yes...
                 irmp_pulse_time++;                                              // increment counter
             }
@@ -734,7 +734,7 @@
         {
             if (wait_for_start_space)                                           // we have received start bit and are counting the dark...
             {
-                if (IRMP_PIN & (1 << IRMP_BIT))                                 // still dark?
+                if (data)                                                       // still dark?
                 {                                                               // yes
                     irmp_pause_time++;                                          // increment counter

@@ -1111,7 +1111,7 @@
             {                                                                   // counting the dark....
                 uint8_t got_light = FALSE;

-                if (IRMP_PIN & (1 << IRMP_BIT))                                 // still dark?
+                if (data)                                                       // still dark?
                 {                                                               // yes...
                     if (irmp_bit == complete_len && stop_bit == 1)
                     {
@@ -1368,7 +1368,7 @@
             }
             else
             {                                                                   // counting the light (pulse)...
-                if (!(IRMP_PIN & (1 << IRMP_BIT)))                              // still light?
+                if (!data)                                                      // still light?
                 {                                                               // yes...
                     irmp_pulse_time++;                                          // increment counter
                 }
diff -rBuw Irmp.org/irmp.h Irmp/irmp.h
--- Irmp.org/irmp.h     2010-03-05 11:24:18.000000000 +0100
+++ Irmp/irmp.h 2010-03-12 17:40:14.600896408 +0100
@@ -194,7 +194,7 @@
  *  ISR routine
  *  @details  ISR routine, called 10000 times per second
  */
-extern void                           irmp_ISR (void);
+extern void                           irmp_ISR (const uint8_t);

 #ifdef __cplusplus
 }

Der Aufrufer kann dann auch die Phase umkehren, falls der IR-Empfänger 
high-aktiv ist.

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

Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> irmp_ISR() macht mehrfach IRMP_PIN & (1 << IRMP_BIT) zu
> unterschiedlichen (Lauf-)Zeiten bei immer gleichen irmp_pulse_time.
> Außerdem geht der Code davon aus, dass der IR-Empfänger low-aktiv ist.

In meinem aktuellen Source ist es mittlerweile ein Makro. Das habe ich 
im Zusammenhang mit Christians PIC-Portiertung gemacht. Ich werde dafür 
sorgen, dass dieses Makro zukünftig nur noch einmal aufgerufen wird, 
nämlich am Anfang von irmp_ISR().

> Der Aufrufer kann dann auch die Phase umkehren, falls der IR-Empfänger
> high-aktiv ist.

Das kann er dann im Makro direkt tun.

Danke für die Anregung,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
Eine neue Version von IRMP ist unter

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

verfügbar.

Zum einen ist die PIC-Portierung von Christian F. (blueicebox) in den 
Source eingeflossen, zum anderen habe ich die Anregung von eku 
übernommen, den Input-Pin nur noch an einer Stelle und immer zur 
gleichen Zeit abzufragen.

Vielen Dank an Christian für seine Tipps zur PIC-Portierung.

Gruß,

Frank

Autor: Markus B. (mb27)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

könnte mir jemand einen Tip oder Code geben wie ich die drei Telegramme

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

auf meinem LCD ausgebe. Benutze das Programm von Peter Fleury.
So bekomme ich immer eine Fehlermeldung:
if (irmp_get_data (&irmp_data))
    {
    /* clear display and home cursor */
        lcd_clrscr();
        // ir signal decoded, do something here...

        // irmp_data.protocol is the protocol, see irmp.h
    lcd_puts(irmp_data.protocol);
        // irmp_data.address is the address/manufacturer code of ir sender
        lcd_puts(irmp_data.address);
        // irmp_data.command is the command code
        lcd_puts(irmp_data.command);

../../main.c:182: warning: passing argument 1 of 'lcd_puts' makes 
pointer from integer without a cast
muss ich hier itoa anwenden?

Bin Anfänger und sitze schon drei Tage dran und bekomms nicht hin.

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

Bewertung
0 lesenswert
nicht lesenswert
Markus B. schrieb:
> ../../main.c:182: warning: passing argument 1 of 'lcd_puts' makes
> pointer from integer without a cast
> muss ich hier itoa anwenden?

lcd_puts möchte einen C-String, Du übergibst aber Zahlen. Das geht 
nicht. Also musst Du vorher die Zahlen in Strings - z.B. mit itoa() - 
umwandeln, z.B. so:
#include <stdlib.h>
...

main ()
{
   char protocol[10];
   char address[10];
   char command[10];

...
   if (irmp_get_data (&irmp_data))
   {
        itoa(irmp_data.protocol, protocol, 10);
        itoa(irmp_data.address, address, 10);
        itoa(irmp_data.command, command, 10);

        lcd_clrscr();
        lcd_puts(protocol);
        lcd_puts (" ");
        lcd_puts(address);
        lcd_puts (" ");
        lcd_puts(command);
   }

Das dritte Argument gibt die Zahlenbasis an. Eventuell ist es 
sinnvoller, address & command in Hex auszugeben statt dezimal. Dann muss 
das dritte Argument für itoa() 16 sein.

Gruß,

Frank

Autor: Michael M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
lcd_putS puttet einen string. was es als parameter erwartet ist eine 
adresse (pointer) zum ersten zeichen dieses strings, den es anzeigen 
soll.
was du übergibst, ist eine zahl.

du kannst also entweder deine zahlen zu einem string konvertieren (itoa) 
und dann anzeigen lassen.
oder du schaust mal, ob peter nicht genau für diesen falle eine funktion 
geschrieben hat, die zahlen aus einer variablen anzeigen lässt.

Autor: Markus B. (mb27)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank fettes Danke für die schnelle Antwort und für IRMP  :-)

Autor: Michael M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
:*-(

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe Probleme mit den Timer-Einstellungen auf einem Atmega8. Timer 1 
ist leider schon durch PWM belegt, so dass ich Timer 2 verwenden muss. 
Ich verwende als F_CPU 8Mhz (interner Takt).

Ich habe mit einer Universalfernbedienung getestet. Manche Protokolle 
kennt er anscheinend, auf andere reagiert er nicht.

Grundsätzlich die Frage: Geht das mit dem 8-Bit Timer überhaupt?

Hier meine Timer-Init mit Prescaler 8:
OCR2   =  ((F_CPU/8) / F_INTERRUPTS) - 1; // compare value: 1/10000 of CPU frequency/prescaler  = 99
  
TCCR2  |= (1 << WGM21); // switch CTC Mode on, 
TCCR2  |= (1 << CS20); 
TCCR2  |= (1 << CS21); //set prescaler to 8 mit cs20 und cs21
  
TIMSK  |= (1 << OCIE2); // OCIE1A: Interrupt by timer compare

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

Bewertung
0 lesenswert
nicht lesenswert
Chris schrieb:

> Ich habe mit einer Universalfernbedienung getestet. Manche Protokolle
> kennt er anscheinend, auf andere reagiert er nicht.

Welche Protokolle werden von IRMP erkannt, welche nicht?

> Grundsätzlich die Frage: Geht das mit dem 8-Bit Timer überhaupt?

Ja, solange er hinreichend genau geht.

> Hier meine Timer-Init mit Prescaler 8:
>
> OCR2   =  ((F_CPU/8) / F_INTERRUPTS) - 1; // compare value: 1/10000 of
> CPU frequency/prescaler  = 99
> 
> TCCR2  |= (1 << WGM21); // switch CTC Mode on,
> TCCR2  |= (1 << CS20);
> TCCR2  |= (1 << CS21); //set prescaler to 8 mit cs20 und cs21
> 
> TIMSK  |= (1 << OCIE2); // OCIE1A: Interrupt by timer compare
> 

Das sieht eigentlich ganz gut aus...

Gruß,

Frank

Autor: Werner B. (werner-b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich musste bei lsb in irsnd.c lange grübeln um herauszufinden was da 
erreicht werden soll (IMHO ist der Name auch irreführend).
Darum habe ich mir auch gleich eine (wenigstens für mich) leichter 
vertändliche Version gebastelt. Die hat auch ein besseres 
Laufzeitverhalten da für jedes Bit nur zwei mal geschoben wird. Die 
Bitschiebe-Orgie entfällt ;-).
static uint16_t
lsb (uint16_t x, uint8_t len)
{
#if 0
    uint16_t    xx = 0;
    uint8_t     i;

    for (i = 0; i < len; i++)
    {
        if (x & (1<<i))
        {
            xx |= (1<<(len - i - 1));
        }
    }
    return xx;
#else
    uint16_t    xx = 0;

    while(len)
    {
        xx <<= 1;
        if (x & 1)
        {
            xx |= 1;
        }
        x >>= 1;
        len--;
    }
    return xx;
#endif
}

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe per Interrupt einen Pin "blinken" lassen und die Frequenz 
gemessen: Weit von 10khz entfernt. Durch Probieren kam ich auf OCR2=25.

Verstehe ich nicht. F_CPU stimmt auf jeden Fall, sonst würden andere 
Sachen auch nicht funktionieren.

Damit konnte ich folgende Protokolle empfangen:
Code: 9 Address: 0x00 Command: 0x00
Code: A Address: 0x2D2D Command: 0xA758
Code: 7 Address: 0x05 Command: 0x02
Code: 2 Address: 0xF708 Command: 0x02

Ein Preset auf der Fernbedienung wird nicht erkannt, wahrscheinlich ist 
das ein Exot.

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

Bewertung
0 lesenswert
nicht lesenswert
Chris schrieb:
> Ich habe per Interrupt einen Pin "blinken" lassen und die Frequenz
> gemessen: Weit von 10khz entfernt. Durch Probieren kam ich auf OCR2=25.

Dein Denkfehler liegt wohl hier:

  TCCR2  |= (1 << CS20);
  TCCR2  |= (1 << CS21); //set prescaler to 8 mit cs20 und cs21

Damit wird der Prescaler lt. ATMega8-Datenblatt nicht auf 8, sondern auf 
32 gesetzt. Demnach müsste OCR2 dann 24 sein:

OCR2   =  ((F_CPU/32) / F_INTERRUPTS) - 1; // compare value: 1/10000 of

Mit Deinem empirisch ermittelte Wert von 25 lagst Du also schon fast 
richtig ;-)

Um den Prescaler auf 8 zu setzen, müsstest Du lediglich CS21 setzen.

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
Werner B. schrieb:
> Ich musste bei lsb in irsnd.c lange grübeln um herauszufinden was da
> erreicht werden soll (IMHO ist der Name auch irreführend).

Nenne mir bitte einen besser geeigneten Namen, mir ist auch kein 
besserer eingefallen ;-)

> Darum habe ich mir auch gleich eine (wenigstens für mich) leichter
> vertändliche Version gebastelt. Die hat auch ein besseres
> Laufzeitverhalten da für jedes Bit nur zwei mal geschoben wird. Die
> Bitschiebe-Orgie entfällt ;-).

Wow, Deine Version spart wirklich einiges ein!

Vielen Dank, werde ich so übernehmen.

Gruß,

Frank

P.S.
Es gibt noch eine kürzere (und damit auch schnellere) Version:
static uint16_t
lsb_neu (uint16_t x)
{
   x = ((x >>  1) & 0x5555) | ((x <<  1) & 0xaaaa);
   x = ((x >>  2) & 0x3333) | ((x <<  2) & 0xcccc);
   x = ((x >>  4) & 0x0f0f) | ((x <<  4) & 0xf0f0);
   x = ((x >>  8) & 0x00ff) | ((x <<  8) & 0xff00);
   return x;
}

Nur arbeitet hat das Ding einen Nachteil: es arbeitet konstant mit der 
Länge 16 ;-)

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

Bewertung
0 lesenswert
nicht lesenswert
Da ich heute zufällig beim Durchforsten des Sources nach 
Optimierungsmöglichkeiten bemerkt habe, dass die RECS80-Startbit-Timings 
komplett falsch in IRMP definiert waren, habe ich die Timings nicht nur 
angeglichen, sondern auch noch zusätzlich die Erkennung des "RECS80 
Extended-Protokolls" eingebaut, damit ich endlich mal selbst ein paar 
Technisat-FBs von Pollin (für 95 Cent!), die den SAA3008 (und damit das 
RECS80EXT-Protokoll) benutzen, testen kann.

Vorab schon mal eine neue Version von IRMP unter

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

Die Erweiterung auf RECS80EXT kostete nur 50 Bytes im Binary, ist aber 
selbstverständlich - wie alle anderen Protokolle auch - abstellbar.

Und noch eine Neuigkeit:

Das kompilierte Binary von IRMP ist - trotz der Erweiterung auf 
RECS80EXT - durch diverse Code-Optimierungen, die ich in den letzten 
Tagen vorgenommen habe, nun ca. 350 Bytes kleiner geworden :-)

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
IRSND ist nun auch angepasst, Änderungen:

 - Korrektur der RECS80-Startbit-Timings
 - Neues Protokoll: RECS80 Extended
 - Diverse Codeoptimierungen, u.a. die von Werner, siehe oben.

Download:

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

Gruß,

Frank

Autor: Werner B. (werner-b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Nenne mir bitte einen besser geeigneten Namen, mir ist auch kein
> besserer eingefallen ;-)

z.B. bitsreverse

Edit:
  ich sehe gerade deinen Coding Style. Also besser bits_reverse.

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

Bewertung
0 lesenswert
nicht lesenswert
Werner B. schrieb:

> z.B. bitsreverse

Sehr gut. Habe ich gerade übernommen. Ebenso noch eine Korrektur für 
TCCR2,
Dank an Werner. Download ist aktualisiert.

> Edit:
>   ich sehe gerade deinen Coding Style. Also besser bits_reverse.

Nö, die erste Version finde ich besser. Man kanns mit den Underscores 
auch übertreiben ;-)

Gruß,

Frank

Autor: DiPi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In der Anwendung beim CRC wird diese Prozedur "reflect" genannt...

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

Bewertung
0 lesenswert
nicht lesenswert
DiPi schrieb:
> In der Anwendung beim CRC wird diese Prozedur "reflect" genannt...

mirror() bzw. mirror_bits() habe ich auch schon mal gesehen, 
bitsreverse() finde ich aber am aussagekräftigsten.

Gruß,

Frank

Autor: Peter K. (peko)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

habe heute die neuen IRMP für neue scans genutzt. Anbei 2 scans, einmal 
von meiner Kathrein UFS912 FB - ein RC6 Code. Da stimmt wohl irgendetwas 
noch nicht... Ich habe 2 Tasten jeweils 3mal einzeln gedrückt. Das 
Einzige, was sich im Command ändert, ist das LSB. Dies ist jedoch das 
Togglebit wie es mir scheint. Mehr ändert sich am Command nicht, egal 
welche Taste gedrückt wird. Auch bei RC5 Commands habe ich den Effekt 
beobachtet. Leider kann ich keinen RC5 scan machen weil der Controller 
abstürzt.

Der zweite scan in der zip ist ein bisher von IRMP nicht erkanntes 
Protokoll von einer Nubert (Lautsprecherhersteller) Subwoofer-FB.

Soviel für heute...

-Peter

Autor: Peter K. (peko)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

hier noch ein Nachtrag zum Thema IRMP und IRSND: Habe einige Tests mit 
Kaseikyo (Panasonic Blue Ray) gemacht.
Die Commands werden weitestgehend stabil decodiert und angezeigt (Ob sie 
jedoch stimmen?). Wenn ich mit einer solchen IRMP_DATA Struktur den Code 
wieder mit IRSND aussende, passiert am Player nichs.
IRSND läuft dagegen gut und schaltet mein Samsung TV mit Samsung32 
Protocol ein. Auch SIRCS und NEC werden von IRSND zuverlässig erzeugt.

Gerne würde ich IRMP / IRSND mit RC6 nutzen, jedoch gibts da ja noch 
einige Problemchen - siehe meinen vorherigen post.

-Peter

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

Bewertung
0 lesenswert
nicht lesenswert
Hi Peter,

Peter K. schrieb:

> Die Commands werden weitestgehend stabil decodiert und angezeigt (Ob sie
> jedoch stimmen?). Wenn ich mit einer solchen IRMP_DATA Struktur den Code
> wieder mit IRSND aussende, passiert am Player nichs.

Siehe IRMP-Artikel:

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

Zitat:

| IRSND unterstützt folgende Protokolle (noch) nicht:
|
|     * KASEIKYO
|     * RC6

Um aus den 32-bit-IRMP-Daten wieder das 48-Bit-Kaseikyo-Protokoll zu 
reproduzieren, ist noch ein wenig Gehirnschmalz bzw. Verständnis 
meinerseits bzgl. Kaseikyo notwendig. IRMP filtert aus dem 
Kaseikyo-Protokoll nur das raus, was zum Decodieren interessant ist, 
Parity-Bits und andere Infos gehen dabei verloren. Beim Encodieren 
braucht man sie dann aber wieder. Da muss ich noch ein wenig forschen, 
um die Parity-Bits und den Rest im IRSND wieder zu rekonstruieren: 32 
Bit IRMP -> 48 Bit Kaseikyo.

> IRSND läuft dagegen gut und schaltet mein Samsung TV mit Samsung32
> Protocol ein. Auch SIRCS und NEC werden von IRSND zuverlässig erzeugt.

Freut mich :-)

> Gerne würde ich IRMP / IRSND mit RC6 nutzen, jedoch gibts da ja noch
> einige Problemchen - siehe meinen vorherigen post.

RC6 ist ein komplexes System von variablen Modi: je nach RC6-Modus sind 
die RC6-Daten komplett anderes strukturiert. Im Moment ist RC6 ein 
erhebliches Problem, da IRMP im Moment nur den sogenannten Mode0 
unterstützt. Die Kathrein-FB benutzt aber einen anderen Mode - mit 
erheblich mehr Bits im Telegramm. Da sind dann nur spärliches Infos zu 
finden. Ich bin aber weiterhin dran.

Danke für die Scans, werde ich mir anschauen.

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
Peter K. schrieb:

> Der zweite scan in der zip ist ein bisher von IRMP nicht erkanntes
> Protokoll von einer Nubert (Lautsprecherhersteller) Subwoofer-FB.

Ich habe mir das Protokoll angeschaut, das ist was ganz Neues, aber auch 
ziemlich triviales. Ich habe es mal eingebaut in den IRMP, verbrät 
zusätzliche 50 Bytes an Code, ist natürlich abschaltbar.

Wie die anderen Protokolle auch ist das "NUBERT-Protokoll" (so habe ich 
das mal getauft, solange es da keine Vergleichsvariante gibt) im 
IRMP-Artikel dokumentiert.

Es hat 1 Start-Bit + 10 Daten-Bits + 1 Stop-Bit und wird immer 2x 
gesendet.
Die Timings habe ich empirisch aus dem Scan ermittelt.

Die automatische Wiederholung wird von IRMP unterdrückt, eine 
Wiederholung durch langen Tastendruck wird von IRMP im Flags-Byte 
gekennzeichnet - so wie sich das gehört ;-)

Wie sich diese 10 Bit Daten in Adresse + Kommando aufteilen, weiß ich 
nicht, da ich keine Dokumentation dazu gefunden habe. Hat Deine 
Nubert-FB noch mehr Tasten? Deine 2 Tasten zur Analyse, wie sich Adresse 
und Kommando aufteilen, sind da als Vergleich ziemlich mager ;-)

Ich habe daher alle 10 Daten-Bits in das Kommando gelegt, d.h. als 
Adresse gibt IRMP immer 0 zurück.

Achja: Deine beiden Volume-Tasten senden das Kommando 0x0082 und 0x0084.

Neue Version von IRMP unter

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

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
Nun gibt es auch eine neue Version von IRSND.

Download:

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

Änderungen:

* Neues Protokoll: Nubert

  Damit kann Peter nun seine Subwoofer auch über IRSND voll
  aufdrehen ;-)

* Korrektur der Pausen zwischen Wiederholungen von Frames

Gruß,

Frank

Autor: Klaus Leidinger (klausleidinger)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

damit zur Software auch ein Stück Hardware zum ausprobieren kommt, habe 
ich heute mein kleines IR-LCD Projekt online gestellt.

Die Hardware basiert auf der IRMP und IRSND Software von Frank mit ein 
paar kleinen Erweiterungen. Die Software wird auch noch ein bischen 
wachsen ;-)

Schaut es Euch mal an, Feedback auch gerne hier im Forum, so lange es 
Frank nicht zu lästig wird ;-) sonst eröffne ich einen neuen Beitrag.

Viele Grüße und viel Spaß,
Klaus

Das komplette Projekt findet Ihr hier:
http://www.mikrocontroller-projekte.de -> IR-LCD

Autor: Werner B. (werner-b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Klaus Leidinger,

da IR Sendedioden (zumindest meine hier) im Impulsbetrieb bis zu 3A für 
10uS verkraften, kannst du R2 auf fast 1 Ohm verkleiner (Ich verwende 
1,2 Ohm).
Das erhöht die Reichweite beträchtlich. R3 begrenzt den Strom falls sich 
der AVR mal "aufhängt" (Wobei ich nicht verstehe warum die Sendediode 
und der TSOP beide hinter R3 liegen. Lieber den TSOP mit 100 Ohm an Vcc 
und die Sendediode mit ca. 40 Ohm direkt an Vcc und noch einen weiteren 
C spendieren).

Gruß
Werner

Autor: Klaus Leidinger (klausleidinger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Werner B. schrieb:
> (Wobei ich nicht verstehe warum die Sendediode
> und der TSOP beide hinter R3 liegen. Lieber den TSOP mit 100 Ohm an Vcc
> und die Sendediode mit ca. 40 Ohm direkt an Vcc und noch einen weiteren
> C spendieren)

Senden und Empfangen wird ja nicht gleichzeitig benutzt, und die 
Sendediode soll ja aus dem Elko gespeist werden. Außerdem war es schon 
recht eng ;-)

Je nach Verwendungszweck ist ja eine unterschiedliche Bestückung 
machbar. Für eine Entwicklungsplattform war mir der Weg mit lieber "zu 
großen" Widerständen sicherer.

Reichweitentests habe ich noch nicht gemacht, ich werde aber gerne Deine 
/ Eure Erfahrungen dokumentieren.

Danke für Dein Feedback.

Viele Grüße,
Klaus

Autor: eku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank!

Eine Frage zum Source von IRMP:
#define DEBUG_PUTCHAR(a)                        { if (! silent) { putchar (a);              } }
#define DEBUG_PRINTF1(a)                        { if (! silent) { printf (a);               } }
#define DEBUG_PRINTF2(a,b)                      { if (! silent) { printf (a,b);             } }
#define DEBUG_PRINTF3(a,b,c)                    { if (! silent) { printf (a,b,c);           } }
#define DEBUG_PRINTF4(a,b,c,d)                  { if (! silent) { printf (a,b,c,d);         } }
#define DEBUG_PRINTF5(a,b,c,d,e)                { if (! silent) { printf (a,b,c,d,e);       } }
#define DEBUG_PRINTF6(a,b,c,d,e,f)              { if (! silent) { printf (a,b,c,d,e,f);     } }
#define DEBUG_PRINTF7(a,b,c,d,e,f,g)            { if (! silent) { printf (a,b,c,d,e,f,g);   } }

Warum verwendest Du keine Variadic Macros 
(http://en.wikipedia.org/wiki/Variadic_macro) in der Form:
#define DEBUG_PRINTF(...)   {if (!silent) printf(__VA__ARGS__);}

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

Bewertung
0 lesenswert
nicht lesenswert
Hi eku,

eku schrieb:

> Warum verwendest Du keine Variadic Macros

Weil ich ein alter Knochen bin, der C 1984 unter UNIX kennengelernt 
habe. Die Variadic Macros gibt es erst seit 1999. Ich hatte es zwar mal 
am Rande mitbekommen, dann aber wieder verdrängt, da ich es damals nicht 
brauchte.

Ich werde es bei Gelegenheit umstellen, vielen Dank für den Hinweis.

Gruß,

Frank

Autor: eku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank!

Zwei meiner Fernbedienungen können nicht dekodiert werden:

 Nokia Dbox2
 Siemens Gigaset M740AV

Reicht für die Analyse wenn ich die UART-Ausgaben mit IRMP_LOGGING=1 
aufzeichne?

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

was hältst du davon sämtliche Konfigurationsmöglichkeiten in eine 
separate Header-Datei (z.B. irmpconfig.h) auszulagern? Ich finde das 
momentan etwas unübersichtlich: jede Menge defines und diese dann auch 
noch im .h und im .c verteilt, so dass man (zumindest ich) nicht so 
recht weiß an welcher Schraube man drehen kann und was man besser so 
belassen sollte.

Ansonsten finde ich dieses Projekt großartig und möchte mich vielmals 
dafür bedanken.

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

Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> Reicht für die Analyse wenn ich die UART-Ausgaben mit IRMP_LOGGING=1
> aufzeichne?

Ja, müsste reichen, am besten so viele Tasten wie möglich und dann in 
der Form:

# Taste 1
000011110000.......
# Taste 2
000011110000.......

Also pro Taste ein Kommentar, eingeleitet mit '#' und alle Tasten einer 
FB in derselben Datei.

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
Micha schrieb:

> was hältst du davon sämtliche Konfigurationsmöglichkeiten in eine
> separate Header-Datei (z.B. irmpconfig.h) auszulagern?

Ja, ist wohl sinnvoll. Mache ich.

Gruß,

Frank

Autor: Christoph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wäre es nicht eine gute Idee den Sourcecode in das neue svn 
einzustellenß
Dann müsste man nicht immer den aktuelllen Sourcecode herunterladen.

Autor: Peter K. (peko)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

ich habe gestern mal bezüglich RC6 etwas im IRMP geforscht und komme mit 
dem Verhalten von IRMP irgendwie nicht klar. Dazu anbei die kleine 
Log-Datei. Ich habe mal jedes Bit, das irmp_store_bit bekommt, in ein 
Array schreiben lassen und schaue es mir nach empfangenen Code an.

Beim RC5 sieht das richtig gut aus, alle Bits kommen so wie sie sollen 
und man kann am Binärcode Adresse und Command gut erkennen.

Beim RC6 trudeln allerdings irgendwelche Bits herein, die ich mir 
überhaupt nicht erklären kann. Vor allem das Togglebit, das ja auch 
relativ weit vorne im RC6-Frame kommt erscheint, (wenn es das überhaupt 
ist...) erst an 21. Stelle.

Könntest Du da bitte etwas Aufklärungsarbeit leisten? Danke... ;)

-Peter

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

Bewertung
0 lesenswert
nicht lesenswert
Peter K. schrieb:

> ich habe gestern mal bezüglich RC6 etwas im IRMP geforscht und komme mit
> dem Verhalten von IRMP irgendwie nicht klar.

Ich bin selbst nicht mit der Umsetzung des RC6-Protokolls im IRMP 
zufrieden. Es funktioniert zwar mit der RC6-Fernbedienung von Klaus 
Leidinger, welche im sog. "Mode 0" läuft, aber nicht mit RC6-FBs, die 
einen anderen Mode benutzen.

Der "Mode 0" ist hier dokumentiert:

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

Dabei ist da was ganz fieses drin, nämlich:

"Finally the header is terminated by the trailer bit TR. Please note 
that the bit time of this symbol is twice as long as normal bits! This 
bit also serves as the traditional toggle bit, which will be inverted 
whenever a key is released. This allows the receiver to distinguish 
between a new key or a repeated key. "

Das Toggle-Bit ist also doppelt so breit wie die anderen Bits. Im 
Zusammenhang mit der Bi-Phase-Codierung haben dann die Pulse und die 
Pausen ganz blöde Längen, nämlich - je nach Nachbar-Bits(!) - die ein- 
oder 1,5-fache Länge. Das bringt den Code von IRMP arg ins Schleudern. 
Ich hatte das damals anhand der Scans von Klaus dann so "hingefrickelt", 
aber mir war klar, dass dieser Code nicht allgemeingültig funktionieren 
könne.

Mangels anderer RC6-Scans habe ich da aber nichts mehr weiter dran 
getan, hat mich schon so genug Nerven gekostet ;-)

Nun habe ich von Dir die Kathrein-Scans erhalten und musste einsehen, 
dass meine Art, wie ich Bi-Phase-Signale decodiere, an seine Grenzen 
stößt - was auch wieder mit der doppelten Länge des Toggle-Bits zu tun 
hat. Dieses folgt nämlich den sog. drei Mode-Bits. Und die haben bei Dir 
andere Werte - eben nicht "Mode 0". Und damit funktioniert die Art und 
Weise, wie ich die doppelte Länge des Toggle-Bits "behandle", nicht 
mehr.

Ich werde also den RC6-Part im IRMP neu schreiben müssen, so hat das 
keinen Zweck... einfach zu viel Code-Gebastel und Rumprobiererei.

> Beim RC5 sieht das richtig gut aus, alle Bits kommen so wie sie sollen
> und man kann am Binärcode Adresse und Command gut erkennen.

Ja, bei gleichen Signal-Längen (RC5) funktioniert der Code, bei 
wechselnden Bit-Breiten (RC6) macht er die Grätsche.

> Beim RC6 trudeln allerdings irgendwelche Bits herein, die ich mir
> überhaupt nicht erklären kann. Vor allem das Togglebit, das ja auch
> relativ weit vorne im RC6-Frame kommt erscheint, (wenn es das überhaupt
> ist...) erst an 21. Stelle.

Das sollte eigentlich überhaupt nicht auftauchen, da IRMP die 
Toggle-Bits (RC5 und RC6) ignoriert.

> Könntest Du da bitte etwas Aufklärungsarbeit leisten? Danke... ;)

Ich bin gerade an einem anderen Algorithmus für RC6 dran, habe Dich und 
Deine Kathrein-FB nicht vergessen. Allerdings wolltest Du mir noch Scans 
von einer weiteren Kathrein-FB zur Verfügung stellen, wenn ich das 
richtig in Erinnerung habe.

Achja: dass IRMP "zwischendurch" bei Deiner RC6-FB meint, da plötzlich 
RC5-Code zu erkennen, ist leicht erklärt: RC6 benutzt exakt die Hälfte 
der Bit-Breite von RC5, nämlich 444µs. Bei einer Bi-Phase-Codierung 
addieren sich dann oft die Pulse von 2 Nachbar-Bits auf die doppelte 
Breite - und damit exakt auf die Puls-Breite eines RC5-Bits von 889µs.

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
Christoph schrieb:
> Wäre es nicht eine gute Idee den Sourcecode in das neue svn
> einzustellenß

Danke für die Anregung, ich habe das direkt beantragt und auch schon 
einen Platz für IRMP auf dem SVN-Server von mikrocontroller.net von 
Andreas erhalten. Ich schiebe den Source demnächst ins SVN und melde 
mich dann nochmal dazu.

Trotzdem wird man die Sources auch weiterhin "klassisch" über den 
Download-Link herunterladen können.

> Dann müsste man nicht immer den aktuelllen Sourcecode herunterladen.

Das müsstest Du bei SVN ja auch ;-)

Die Verwendung eines SVN bietet eigentlich genau dann Vorteile, wenn 
mehrere Leute an einem Source arbeiten. Dafür ist es eigentlich gedacht 
- nicht zum Publizieren von Code. Das ist nur ein Seiteneffekt von SVN.

Gruß,

Frank

Autor: eku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank!


> Zwei meiner Fernbedienungen können nicht dekodiert werden:
>
>  Nokia Dbox2
>
>  Siemens Gigaset M740AV

LIRCD kennt die Siemens Gigaset Fernbedienung als

  bits           8
  eps            30
  aeps          100

  one             0     0
  zero            0     0
  pre_data_bits   24
  pre_data       0x10
  gap          210000
  min_repeat      2
  toggle_bit      25

Autor: Peter K. (peko)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,
danke für die prompte Antwort. Ja, die zweite Kathrein-FB... Die ist 
etwas ein Sorgenkind, wahrscheinlich ist es kein RC6 Code. Ich kann mit 
der neuesten Version von IRMP nichts scannen. IRMP in einer 
Test-Compilierung reagiert gar nicht darauf. Allerdings - und das ist 
merkwürdig, habe ich die gleiche IRMP-Version in meinem eigentlichen 
Projekt zusammen mit Softwaremodulen des U.Radig-Webservers compiliert. 
Dort zeigt IRMP an, dass diese FB RC5 machen würde. Allerdings reportet 
IRMP jedes Mal andere Cmd / Addr, so dass ich annehme, das da irgendwas 
in der Decodierung nicht stimmt. Leider ist bei diesem Projekt der RAM 
schon so voll, dass ich kein IRMP Logging mehr machen kann. Also komme 
ich momentan beim Scannen dieser 2. FB nicht so richtig voran. Mal 
schaun was ich da noch machen kann.

Hier nun auch noch ein allgemeiner Vorschlag von mir: Eine schöne 
Versionsnumerierung von IRMP / IRSND wäre gut, dann könnte man sich 
immer genau auf bestimmte Releases beziehen.

-Peter

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

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

Peter K. schrieb:

> Hier nun auch noch ein allgemeiner Vorschlag von mir: Eine schöne
> Versionsnumerierung von IRMP / IRSND wäre gut, dann könnte man sich
> immer genau auf bestimmte Releases beziehen.

Ja, hatte ich auch schon mal dran gedacht. Die nächste Version wird dann 
einfach mal 1.0 heißen ;-)

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
Hi eku,

eku schrieb:

>> Zwei meiner Fernbedienungen können nicht dekodiert werden:
>>
>>  Nokia Dbox2
>>
>>  Siemens Gigaset M740AV
>
> LIRCD kennt die Siemens Gigaset Fernbedienung als
> [...]

Ich hatte Dir darauf schon mal geantwortet:

  Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"

Schick mir einfach Scans und ich versuche, diese FBs einzubauen - 
entweder durch Vergrößerung der Toleranzen des jeweiligen (bekannten) 
Protokolls oder durch neue Parametrisierung.

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
IRMP ist jetzt auch im SVN auf mikrocontroller.net:

http://www.mikrocontroller.net/svnbrowser/irmp/

Ich werde den Link auch noch in den IRMP-Artikel einfügen, den 
Download-Link im Artikel wird es aber auch weiterhin geben.

Gruß,

Frank

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du kannst auch direkt auf einen aktuellen Snapshot als .tar.gz 
verlinken, dann musst du nicht von Hand ein Paket erstellen:
http://www.mikrocontroller.net/svnbrowser/irmp/?view=tar

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

Bewertung
0 lesenswert
nicht lesenswert
Andreas Schwarz schrieb:
> Du kannst auch direkt auf einen aktuellen Snapshot als .tar.gz
> verlinken, dann musst du nicht von Hand ein Paket erstellen:
> http://www.mikrocontroller.net/svnbrowser/irmp/?view=tar

Danke für den Tipp, hatte ich schon gesehen bzw. kenne ich schon aus 
anderen Open-Source-Projekten. Das tar.gz-Format ist in der Windows-Welt 
leider nicht so geläufig, mein Filzip kann damit jedenfalls nichts 
anfangen - erst wenn ich die Datei in .tgz umbenenne.

Wäre es auch möglich, den Tarball als "Zipball" zur Verfügung zu 
stellen? Dann wäre es ideal.

Gruß,

Frank

Autor: Michael K. (kichi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Das tar.gz-Format ist in der Windows-Welt
> leider nicht so geläufig, mein Filzip kann damit jedenfalls nichts
> anfangen - erst wenn ich die Datei in .tgz umbenenne.

Mit 7-Zip funktioniert es auch unter Windows ohne Probleme.

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das größere Problem an dem SVN repository ist, dass auf Top-Level-Ebene 
keine Ordner für Branches oder Tags angelegt wurden.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stimmt. Und leider sind alle Dateien lieblos in ein Verzeichnis geworfen 
worden. Die Binaries und der Code für den PC könnte man doch in ein 
Unterverzeichnis packen. Genauso mit dem AVR-spezifischen Code.

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

Bewertung
0 lesenswert
nicht lesenswert
Simon K. schrieb:
> Stimmt. Und leider sind alle Dateien lieblos in ein Verzeichnis geworfen
> worden. Die Binaries und der Code für den PC könnte man doch in ein
> Unterverzeichnis packen. Genauso mit dem AVR-spezifischen Code.

Es gibt keinen "Code für den PC" und auch keinen "AVR-spezifischen 
Code", der Source ist für beide derselbe. Das einzige, was hier 
PC-spezifisch ist, sind die beiden Executables irmp.exe bzw. irsnd.exe. 
Dafür bedarf es meiner Meinung nach keines Unterverzeichnisses.

Aber wie immer bei Simon K.: Er liest nur oberflächlich, stromert in 
vielen Threads herum, lässt seinen Mecker los und verschwindet dann 
wieder für Wochen auf Nimmerwiedersehen. Sowas kann ich nicht ernst 
nehmen.

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
Hi Vlad,

Vlad Tepesch schrieb:
> Das größere Problem an dem SVN repository ist, dass auf Top-Level-Ebene
> keine Ordner für Branches oder Tags angelegt wurden.

Hätte ich diese anlegen können/müssen? Das Repository hat Andreas 
Schwarz auf meine Bitte hin angelegt. Ich musste dann nur noch die 
Dateien reinschieben. Muss Andreas als SVN-Verwalter da was tun oder 
kann ich das auch als reiner "SVN-Anwender"?

Gruß,

Frank

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Um nicht noch mehr OT zu produzieren antworte ich dir privat

Autor: Jens C. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

erstmal höchstes Lob für dieses Projekt an Frank M. und seine Helfer!

Ich teste derzeit ein wenig mit dem IRMP und mir stellt sich folgende 
Frage:

Durch das IRMP_FLAG_REPETITION kann ich auswerten, ob eine Taste kurz 
oder lange gedrückt wurde. Aber wie erfahre ich wann sie losgelassen 
wird/wurde?

> Beispiel:
>
>    if (irmp_data.flags & IRMP_FLAG_REPETITION)
>    {
>      finger_blau (irmp_data.command);
>    }
>    else
>    {
>      einzeln (irmp_data.command);
>    }

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

Wenn ich mit meiner FB im NEC Protokoll die "Plus" oder "Minus" Taste 
länger gedrückt halte, bekomme ich zwar bei der zweiten Auswertung das 
Repetition Flag gesetzt, aber weiter bekomme ich keine Auswertungen, 
d.h.ich bekomme nicht mit, wann die Taste losgelassen wurde :-)

Oder habe ich da einen falschen Denkansatz...

Gruß Jens

Autor: Di Pi (drpepper) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
naja, wenn das signal nicht mehr kommt, wurde die taste losgelassen. Die 
FBs senden ja keine extra-sequenz, wenn man eine taste loslässt.
Sie senden nur solange die taste gedrückt ist immer wieder in festen 
zeitabständen eine bestimmte bitfolge, die IRMP immer wieder aufs neue 
interpretiert.

Autor: Jens C. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Di Pi

Guten Morgen,

die Taste wurde nicht losgelassen, die Sequenzen werden noch empfangen 
(mit Oszi beobachtet) aber irmp_get_data(...) liefert mir nach dem 
IRMP_FLAG_REPETITION gesetzt wird FALSE zurück.

Also, das/mein Problem muss woanders liegen

Gruß Jens

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

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jens,

Jens C. schrieb:

> die Taste wurde nicht losgelassen, die Sequenzen werden noch empfangen
> (mit Oszi beobachtet) aber irmp_get_data(...) liefert mir nach dem
> IRMP_FLAG_REPETITION gesetzt wird FALSE zurück.

Ich habe das mal gerade emuliert mit dem IRMP-Executable und 
IR-Data/nec-repetition.txt. Da gibt es tatsächlich ein Problem mit den 
Wiederholungen von Repetition-Frames. Diese werden zwar erkannt, aber 
bis auf den ersten Repetition-Frame werden alle weitere verworfen.

Ich schaue gleich mal nach dem Grund und melde mich dann nochmal.

Gruß,

Frank

P.S.
Ich hatte Dein Schreiben auch erstmal so verstanden wie Di Pi...

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

Bewertung
0 lesenswert
nicht lesenswert
Das Problem mit den Wiederholungen von NEC-Repetition-Frames konnte ich 
lösen. Daher gibt es eine neue Version zum Download:

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

Änderungen:
  - Bugfix beim Erkennen von mehrfachen NEC-Repetition-Frames
  - Konfiguration in irmpconfig.h ausgelagert, siehe Doku im
    IRMP-Artikel
  - Einführung einer Programmversion in README.txt: Version 1.0

Autor: Jens C. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

herzlichen Dank für´s Update/BugFix.
Jetzt funktioniert´s problemlos...

Schönen Tag noch
Gruß Jens

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Simon K. schrieb:
>> Stimmt. Und leider sind alle Dateien lieblos in ein Verzeichnis geworfen
>> worden. Die Binaries und der Code für den PC könnte man doch in ein
>> Unterverzeichnis packen. Genauso mit dem AVR-spezifischen Code.
>
> Es gibt keinen "Code für den PC" und auch keinen "AVR-spezifischen
> Code", der Source ist für beide derselbe. Das einzige, was hier
> PC-spezifisch ist, sind die beiden Executables irmp.exe bzw. irsnd.exe.

Ach so. Aber die Source Files kann man doch von den Executables 
separieren.

> Aber wie immer bei Simon K.: Er liest nur oberflächlich, stromert in
> vielen Threads herum, lässt seinen Mecker los und verschwindet dann
> wieder für Wochen auf Nimmerwiedersehen. Sowas kann ich nicht ernst
> nehmen.

Was lässt dich das annehmen? Soll ich mich dafür entschuldigen, dass ich 
nicht den ganzen Tag im Forum bin und alle Threads lese und beantworte?
Außerdem: Wenn man schon ein Projekt ins Forum stellt, dann sollte man 
sich auch der Kritik annehmen können. Ansonsten könntest du deinen Kram 
nämlich auch für dich behalten, wenn du auf sowas allergisch reagierst.
Ansonsten finde ich die Bemerkung ziemlich unangebracht und macht auf 
mich einen ziemlich eingebildeten Eindruck.

Autor: ... ... (docean) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
#include "irmp.c" 

gefunden in main.c im Codevison Teil.

Warum das ?

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

Bewertung
0 lesenswert
nicht lesenswert
... ... schrieb:
>
> #include "irmp.c"
> 
>
> gefunden in main.c im Codevison Teil.
>
> Warum das ?

Ich kenne CV nicht, das hat Klaus Leidinger so angepasst, vermutlich um 
die Sources alle ins main zu integrieren, damit man sie dann alle durch 
einmaliges Compilieren des main-Sources mitzuübersetzen kann. Ob es eine 
andere Möglichkeit gibt (Erstellen eines Makefiles etc), um die einzeln 
zu übersetzenden Module zusammenzulinken, entzieht sich meiner Kenntnis.

Wenn Du es besser weisst, wäre ich für Verbesserungsvorschläge dankbar.

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
Simon K. schrieb:
> Frank M. schrieb:
>> Simon K. schrieb:
>>> Stimmt. Und leider sind alle Dateien lieblos in ein Verzeichnis geworfen
>>> worden. Die Binaries und der Code für den PC könnte man doch in ein
>>> Unterverzeichnis packen. Genauso mit dem AVR-spezifischen Code.
>>
>> Es gibt keinen "Code für den PC" und auch keinen "AVR-spezifischen
>> Code", der Source ist für beide derselbe. Das einzige, was hier
>> PC-spezifisch ist, sind die beiden Executables irmp.exe bzw. irsnd.exe.
>
> Ach so. Aber die Source Files kann man doch von den Executables
> separieren.

Schauen wir mal in die Liste der Dateien im SVN:

IR-Data/
README.txt
irmp.aps
irmp.c
irmp.exe
irmp.h
irmpconfig.h
irsnd.aps
irsnd.c
irsnd.exe
irsnd.h
irsndmain.c
main.c

Es sind also gerade mal 10 Dateien (und ein Ordner) im SVN-Repository, 
die übrigens im dazugehörenden Artikel 
http://www.mikrocontroller.net/articles/IRMP ausführlichst dokumentiert 
sind. Gestern waren es übrigens sogar noch lediglich 9 Dateien.

Was ist daran "lieblos in ein Verzeichnis geworfen"? Du hast vermutlich 
nur die Ignore-List unter 
http://www.mikrocontroller.net/svnbrowser/irmp/ gesehen und hast daraus 
dann vorschnell geschlossen, dass da "Code für den PC" extra drin ist. 
Die Dateien der Ignore-List sind ja gar nicht im SVN enthalten - ganz im 
Gegenteil: sie sind ausgeschlossen. Das meinte ich mit "oberflächlich 
lesen".

Und die beiden EXE-Dateien sind mit voller Absicht im Hauptverzeichnis, 
um auf die dazugehörenden Scan-Dateien unter IR-Data einfach zugreifen 
zu können - wie es auch im IRMP-Artikel dokumentiert ist. Lägen sie in 
einem weiteren Unterverzeichnis, dann wäre der Zugriff auf den Ordner 
IR-Data ein wenig komplizierter und für den Anwender unverständlicher - 
Stichwort: "../IR-Data".

>> Aber wie immer bei Simon K.: Er liest nur oberflächlich, stromert in
>> vielen Threads herum, lässt seinen Mecker los und verschwindet dann
>> wieder für Wochen auf Nimmerwiedersehen. Sowas kann ich nicht ernst
>> nehmen.
>
> Was lässt dich das annehmen?

Weil es mir schon mal sauer aufgestoßen ist, nämlich im 
WordClock-Thread:

Beitrag "Re: Brauche Hilfe beim Bau einer Uhr"

Zitat:

| Nehmt es mir nicht übel, aber im Moment kommt mir der Thread ein wenig
| "Amateurhaft" vor. Nicht, dass ich es spontan besser könnte, aber solche
| "Dann sammeln wir mal, was drauf kommt"-Projekte enden nicht selten im
| Desaster.

Mittlerweile wurden 320 Platinen der "amateuerhaften" 
WordClock-Schaltung sammelbestellt und auch verteilt! Desweiteren sind 
180 dazugehörende Frontplatten produziert worden. Die "amateurhafte" 
Schaltung funktioniert nicht nur reibungslos, macht Farbe mittels 
HUE-Fading, sondern sie ist auch für Anfänger absolut nachbausicher.

Auf Deine oberlehrerhaften Töne bzgl. der Behandlung der ISP will ich 
erst gar nicht eingehen. Merkst Du eigentlich gar nicht mehr, wie Du die 
Leute von oben herab behandelst?

> Soll ich mich dafür entschuldigen, dass ich
> nicht den ganzen Tag im Forum bin und alle Threads lese und beantworte?

Nein, mich stört das 
Einmal-Drüberfliegen-und-dann-Senf-dazugeben-Gehabe. Erinnert mich an 
das Markieren-Gehabe von Katzen.

> Außerdem: Wenn man schon ein Projekt ins Forum stellt, dann sollte man
> sich auch der Kritik annehmen können.

Du nennst das "Kritik". Ich nicht.

> Ansonsten könntest du deinen Kram
> nämlich auch für dich behalten, wenn du auf sowas allergisch reagierst.

Wenn Du Dir diesen Thread (oder auch den WordClock-Thread) mal 
genauestens durchlesen würdest, wirst Du feststellen, dass ich auf 
angebrachte Kritik immer eingegangen bin. Deine Kritik ist aber 
einfach nur von oben herablassend, deshalb schreibst Du ja jetzt hier 
auch wieder mal "deinen Kram". Diese Formulierung spricht Bände.

> Ansonsten finde ich die Bemerkung ziemlich unangebracht und macht auf
> mich einen ziemlich eingebildeten Eindruck.

Glashaus, Steine.

Gruß,

Frank

Autor: Klaus Leidinger (klausleidinger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
>>> #include "irmp.c"
>> >
>> gefunden in main.c im Codevison Teil.
>>
>> Warum das ?
>
> Ich kenne CV nicht, das hat Klaus Leidinger so angepasst, vermutlich um
> die Sources alle ins main zu integrieren, damit man sie dann alle durch
> einmaliges Compilieren des main-Sources mitzuübersetzen kann. Ob es eine

Ja, genau das ist der Grund.
Alle die sich mit CV auskennen, wissen natürlich das das auch im Setup 
eingestellt werden kann... und können es problemlos ändern. So brauche 
ich das Projektfile nicht dazupacken.

Viele Grüße,
Klaus

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Es sind also gerade mal 10 Dateien (und ein Ordner) im SVN-Repository,

Du bist echt nicht kritikfähig. Beruhig dich, lass es halt so, aber 
unterlasse solche dämlichen Bemerkungen, dass ich nicht ernst zu nehmen 
sei.
EDIT: Der einzige der hier Leute von oben herab behandelt bist du, wenn 
überhaupt.

> Was ist daran "lieblos in ein Verzeichnis geworfen"? Du hast vermutlich
> nur die Ignore-List unter
> http://www.mikrocontroller.net/svnbrowser/irmp/ gesehen und hast daraus
> dann vorschnell geschlossen, dass da "Code für den PC" extra drin ist.
> Die Dateien der Ignore-List sind ja gar nicht im SVN enthalten - ganz im
> Gegenteil: sie sind ausgeschlossen. Das meinte ich mit "oberflächlich
> lesen".

Nö habe ich nicht.

> Und die beiden EXE-Dateien sind mit voller Absicht im Hauptverzeichnis,
> um auf die dazugehörenden Scan-Dateien unter IR-Data einfach zugreifen
> zu können - wie es auch im IRMP-Artikel dokumentiert ist. Lägen sie in
> einem weiteren Unterverzeichnis, dann wäre der Zugriff auf den Ordner
> IR-Data ein wenig komplizierter und für den Anwender unverständlicher -
> Stichwort: "../IR-Data".

Ist doch wunderbar, wie gesagt, dann lass es halt so. Es ist ja dein 
Projekt.

>>> Aber wie immer bei Simon K.: Er liest nur oberflächlich, stromert in
>>> vielen Threads herum, lässt seinen Mecker los und verschwindet dann
>>> wieder für Wochen auf Nimmerwiedersehen. Sowas kann ich nicht ernst
>>> nehmen.
>>
>> Was lässt dich das annehmen?
>
> Weil es mir schon mal sauer aufgestoßen ist, nämlich im
> WordClock-Thread:
>
> Beitrag "Re: Brauche Hilfe beim Bau einer Uhr"
>
> Zitat:
>
> | Nehmt es mir nicht übel, aber im Moment kommt mir der Thread ein wenig
> | "Amateurhaft" vor. Nicht, dass ich es spontan besser könnte, aber solche
> | "Dann sammeln wir mal, was drauf kommt"-Projekte enden nicht selten im
> | Desaster.

Ganz toll, da kann selbst ich mich nicht mehr dran erinnern.

> Mittlerweile wurden 320 Platinen der "amateuerhaften"
> WordClock-Schaltung sammelbestellt und auch verteilt! Desweiteren sind
> 180 dazugehörende Frontplatten produziert worden. Die "amateurhafte"
> Schaltung funktioniert nicht nur reibungslos, macht Farbe mittels
> HUE-Fading, sondern sie ist auch für Anfänger absolut nachbausicher.

Schön, habe ich mich halt geirrt. Irren ist menschlich. Zu dem Zeitpunkt 
wo ich das gepostet hat, war das auch (von mir) so noch nicht abzusehen.
Oder willst du mir jetzt vorhalten, dass ich mich geirrt habe? Ich habe 
nämlich kein Problem damit.

Außerdem: Wo denn sonst noch? Liest du alle Threads in denen ich poste?

> Auf Deine oberlehrerhaften Töne bzgl. der Behandlung der ISP will ich
> erst gar nicht eingehen. Merkst Du eigentlich gar nicht mehr, wie Du die
> Leute von oben herab behandelst?

Haha, ist klar! Kritikfähigkeit, wo bist du? Oberlehrerhaft? Ich denke 
wir missverstehen uns.

>> Soll ich mich dafür entschuldigen, dass ich
>> nicht den ganzen Tag im Forum bin und alle Threads lese und beantworte?
>
> Nein, mich stört das
> Einmal-Drüberfliegen-und-dann-Senf-dazugeben-Gehabe. Erinnert mich an
> das Markieren-Gehabe von Katzen.

Und mich stört das: Du urteilst über Sachen die du nicht weißt. Ich habe 
ein paar Wochen lang den Thread verfolgt, bis es mir zu viele Posts 
wurden pro Tag.

>> Ansonsten finde ich die Bemerkung ziemlich unangebracht und macht auf
>> mich einen ziemlich eingebildeten Eindruck.
>
> Glashaus, Steine.

Ja, oder so ähnlich.
Der schlauere gibt auch nach. In dem Sinne.

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Och mensch Frank,
füttere solche Trolle doch nicht auch noch.
Die werden noch übermütiger, wohlgenährter und am ende vielleicht auch 
noch geschlechtsreif.

                            _________________________
                   /|  /|  |                          |
                   ||__||  |       Please don't       |
                  /   O O\__           feed           |
                 /          \       the trolls        |
                /      \     \                        |
               /   _    \     \ ----------------------
              /    |\____\     \     ||
             /     | | | |\____/     ||
            /       \|_|_|/   |    __||
               \            |____| ||
          /   |   | /|        |      --|
          |   |   |//         |____  --|
   * _    |  |_|_|_|          |     \-/
*-- _--\ _ \     //           |
  /  _     \\ _ //   |        /
*  /   \_ /- | -     |       |
  *      _ c_c_c_C/ \C_c_c_c____________

Autor: Hugo Portisch (portisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

jetzt muss ich wegen der Logging Funtkion einmal nachfragen:
                if (s_ctr > c_endBits)
                {                                                       // if stop condition (200 sequenced ones) meets, output on uart
                    uint16_t i;

                    for (i = 0; i < c_startcycles; ++i)
                    {
                        irmp_uart_putc ('0');                                   // the ignored starting zeros
                    }

Also werden immer 2 '0' ausgegeben? Denn c_startcycles = 2 ist fix 
defined!?
#define c_startcycles                     2                         // min count of zeros before start of logging

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

Bewertung
0 lesenswert
nicht lesenswert
Hugo Portisch schrieb:
> jetzt muss ich wegen der Logging Funtkion einmal nachfragen:
> Also werden immer 2 '0' ausgegeben? Denn c_startcycles = 2 ist fix
> defined!?

Ja, momentan sind es zwei. Früher waren es mal 4, aber dann lief der 
Scanner bei sehr kurzen Impulsen erst gar nicht los. Daher hab ich das 
auf 2 geändert. Davon solltest Du aber nicht ausgehen, dass das so 
bleibt. Vielmehr solltest Du für das Logging über USB einfach die Zahl 
c_startcycles übertragen und nicht das c_startcycles x Nullen. Der PC 
kann dann aus der Zahl 2 (oder 4 oder wasweiss ich) einfach zwei 0en 
machen.

Gruß,

Frank

Autor: Frank Lorenzen (florenzen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Das Problem mit den Wiederholungen von NEC-Repetition-Frames konnte ich
> lösen.
[...]

Auch von mir ein Dankeschön, auch wenn's erst spät kommt. Ich bin zur 
Zeit "etwas" überlastet und erst heute zum ausprobieren gekommen.

Gruß
f

Autor: Florian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

das Projekt ist echt supper Großes lob!
Eine frage hätte ich allerdings.
Ist es theroretisch auch möglich die IR-Signale einer
Bang & Olufsen FB zu erkennen?
Problem könnte sein das die Trägerfrequenz bei 455Khz liegt,
und ich nix brauchbares zum Protokoll gefunden habe.
(Kann mann da evtl die eingangsschaltung anpassen oder
geht das mit dem aufbau)

Gruß

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Trägerfrequenz ist ja egal, solange du den passenden Empfänger dafür 
hast. Die Frage ist halt, wie die Daten darauf kodiert sind.

Autor: Frank Lorenzen (florenzen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Morgen oder übermorgen werde ich eine B&O FB aufzeichnen und die Daten 
an Frank schicken.

Gruß
f

Autor: Florian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da bin ich mal gespannt...
Hatte noch vergessen zu erwähnen das ich im Forum
ein Projekt von Rene
(http://www.gutwenger.com/ -> Projekt Beo2pc) gefunden habe
Da stört halt das Beolink "Auge",welches er als
empfänger nutzt, für 70,- =)

Autor: Klaus Leidinger (klausleidinger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank Lorenzen schrieb:
> Morgen oder übermorgen werde ich eine B&O FB aufzeichnen und die Daten
> an Frank schicken.

Hi Frank,

welchen Empfänger zum demodulieren benutzt Du für die B&O Signale? Die 
IR sendet ja mit 455KHz. Hast Du den von B&O oder einen TSOP7000 
aufgetrieben? (wo?)

Danke für eine Info,
Klaus

Autor: Frank Lorenzen (florenzen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe einen TSOP7000 den ich vor einiger Zeit mal bei Farnell 
bestellt hatte. Wie ich gerade sehe ist der aber bei Farnell nicht mehr 
erhältlich weil abgekündigt.

TME hat ihn noch im Programm aber z.Z. 0 Stück auf Lager, vielleicht 
fragst du bei denen mal an ob sie erwarten nochmal welche zu bekommen?
Bei TME nicht von den Preisen verwirren lassen! Die muß man erst von 
Zloty auf Euro umstellen ;-)

HtH.

Danke Klaus. Ohne deine Nachfrage wüsste ich nicht das der TSOP7000 
abgekündigt ist

Gruß
f

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt hier http://www.vishay.com/ir-receiver-modules/agc-list ein 
Hilfstool zur Auswahl, aber ich bin etwas verunsichert. Ich würde gerne 
möglichst viele Protokolle empfangen können, daher sollte es ein 
AGC1-Receiver werden. Auf der anderen Seite ist dieser am 
empfindlichsten ggü. Störungen - stellt dies für IRMP ein Problem dar?

Der Empfänger läuft als IR-Tastatur von ione und ich habe (noch) keine 
Ahnung welches Protokoll das ist. Ein TSOP17xx kommt nicht in Frage, da 
ich nur 3,3V zur Verfügung habe.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
455KHz ist eine gängige Frequenz für ZF-Verstärker im HF-Bereich. Im 
Prinzip kann man also alles aus diesem Bereich übernehmen. Eine 
Fotodiode mit TCA440 beispielsweise.

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich weiß leider nicht einmal die Frequenz. Ich habe beim Hersteller aber 
eben wegen des Protokolls angefragt - mal sehen was die antworten. 
Vielleicht ist es ja irgendein bereits unterstütztes Standardprotokoll.

Autor: Frank Lorenzen (florenzen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zum Thema B&O Fernbedienungen habe ich gestern von einem Bekannten recht 
interessante Informationen bekommen:

Das B&O Fernbedienungs-System wurde wohl bisher von Loewe hergestellt. 
Da Loewe aber mittlerweile zu großen Teilen von Sharp aufgekauft wurde 
und Sharp an der Produktion von Baugruppen für B&O wohl wenig Interesse 
zeigt wird es in Zukunft wohl ein neues FB-System von B&O geben.

Man munkelt die Fernbedienung soll der Harmony sehr ähnlich sehen ;-)
Ob dieses System dann aber noch 455kHz IR unterstützt?

Gruß
f

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

Bewertung
0 lesenswert
nicht lesenswert
Frank Lorenzen hat mir die B&O-Daten geschickt, ein Scan hat aber erst 
mit einer Interrupt-Frequenz von 15kHz funktioniert, da die Pulsdauern 
extrem kurz sind und die Scan-Routine erst bei einer Mindestlänge 
startet.

Interessantes Protokoll, was da benutzt wird. Die Pulsdauern sind immer 
gleich, im Durchschnitt lediglich 210 usec, das spart Strom. Die Pausen 
bestimmen die Wertigkeit der Bits - wie bei den meisten anderen 
Protokollen auch.

Der Aufbau ist:

4 Startbits + 18 Datenbits.

1. Startbit: Pause  3000 usec, entspricht einer 0
2. Startbit: Pause  3000 usec, entspricht einer 0
3. Startbit: Pause 15000 usec, das eigentliche Startbit
4. Startbit: Pause  3000 usec, entspricht einer 0

Die Werte der 18 Datenbits selbst werden über drei statt zwei 
verschiedenen Pausenzeiten gebildet, das macht das ganze so besonders:

Pause 3000 usec: 0
Pause 9000 usec: 1
Pause 6000 usec: Wiederholung des letzten Bits

Mit dieser Regel werden aus den Tasten "0" bis "9" die numerischen Werte 
0 bis 9, das passt also ganz gut. Eine Adresse scheint die FB nicht 
auszusenden, die ersten drei Datenbits sind immer 0, so passen die 18 
Bits glücklicherweise gut in die 16 Code-Bits von IRMP.

War nicht ganz einfach, das Ding zu knacken - wegen der dritten 
Pausenzeit von 6000 usec, die ich erstmal verstehen musste. Morgen baue 
ich den Algorithmus in den IRMP ein, vervollständige die Protokoll-Doku 
im IRMP-Artikel und stelle eine neue Version zum Download zur Verfügung.

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
Version 1.1 von IRMP ist verfügbar:

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

Änderungen:
  - Neues Protokoll: BANG_OLUFSEN (B&O)

@Frank Lorentzen: Würde mich über Feedback freuen, ob es klappt. Bitte 
einmal für 10kHz und einmal für 15kHz testen, da ich selbst nur mit der 
Scan-Datei testen konnte. Danke Dir noch einmal für die Scan-Datei, 
diese ist nun auch im Verzeichnis IR-Data abgelegt, einmal als 10kHz- 
und einmal als 15kHz-Verion.

Gruß,

Frank

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Frank M.
Würde es sich bzgl. deiner Änderung von eben 
http://www.mikrocontroller.net/wikisoftware/index.... 
nicht anbieten ein enum zu verwenden, oder gibt es bestimmte Gründe 
warum du das nicht machst?

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

Bewertung
0 lesenswert
nicht lesenswert
Micha schrieb:
> Würde es sich bzgl. deiner Änderung von eben [...] nicht anbieten ein enum
> zu verwenden, oder gibt es bestimmte Gründe warum du das nicht machst?

Natürlich kann ich auch ein enum nehmen. So habe ich halt die Zahlen 
konkret vor mir und muss nicht immer mit dem Finger abzählen, was denn 
nun die IRMP-Ausgabe "protocol = 14" konkret bedeutet ;-)

Okay, ich stelle das beim nächsten Update um.

Gruß,

Frank

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> was denn
> nun die IRMP-Ausgabe "protocol = 14" konkret bedeutet

Du kannst ja auch dort den (?) enum nehmen... Also z.B.
"protocol = IRMP_BANG_OLUFSEN_PROTOCOL"

Siehe: 
http://openbook.galileocomputing.de/c_von_a_bis_z/...

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

Bewertung
0 lesenswert
nicht lesenswert
Micha schrieb:

> Du kannst ja auch dort den (?) enum nehmen... Also z.B.
> "protocol = IRMP_BANG_OLUFSEN_PROTOCOL"

Ja, das ist mir schon klar, dass ich das kann. Mir ging es darum, dass 
jeder - egal ob er den Wert auf einem LCD, auf dem UART oder auf einer 
numerischen 7-Segment-Anzeige ausgibt, sofort sehen kann, was denn die 
"14" bedeutet.

> Siehe:
> http://openbook.galileocomputing.de/c_von_a_bis_z/...

Mir sind enums nach mittlerweile 25 Jahren C-Programmierng wohlbekant, 
aber danke für den schönen Link ;-)

Gruß,

Frank

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachteilig ist allerdings der erhöhte Speicherbedarf, da enums 16bit 
haben (können?)...

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Mir ging es darum, dass
> jeder - egal ob er den Wert auf einem LCD, auf dem UART oder auf einer
> numerischen 7-Segment-Anzeige ausgibt, sofort sehen kann, was denn die
> "14" bedeutet.

Verstehe. Damit hast du natürlich recht. Das war nur ein Vorschlag und 
deswegen stellte ich oben die Frage nach den Gründen...

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

Bewertung
0 lesenswert
nicht lesenswert
Micha schrieb:
> Nachteilig ist allerdings der erhöhte Speicherbedarf, da enums 16bit
> haben (können?)...

enums werden immer auf den kleinst-möglichen Typ abgebildet, der möglich 
ist.

Beispiel A:
enum zahl { NU_LL, EINS, ZWEI, DREI, VIER};

uint8_t
funktion (enum zahl xx)
{
  xx >>= 4;
  return xx;
}

Dann steht in der lss-Datei:
00000046 <funktion>:
uint8_t funktion (enum zahl xx)
{
  xx >>= 4;
  return xx;
}
  46:  82 95         swap  r24
  48:  8f 70         andi  r24, 0x0F  ; 15
  4a:  08 95         ret

Die lss-Datei ist dann identisch beim Code von:
uint8_t funktion (uint8_t xx)
{
  xx >>= 4;
  return xx;
}

Die Variable xx ist also in beiden Fällen 8 Bit breit.

Beispiel B:
enum zahl { NU_LL = -2, EINS, ZWEI, DREI, VIER};

uint8_t
funktion (enum zahl xx)
{
  xx >>= 4;
  return xx;
}

Jetzt braucht die Beispiel-Funktion wesentlich mehr Speicherplatz:
00000046 <funktion>:
uint8_t
funktion (enum zahl xx)
{
  xx >>= 4;
  return xx;
}
  46:  85 95         asr  r24
  48:  85 95         asr  r24
  4a:  85 95         asr  r24
  4c:  85 95         asr  r24
  4e:  08 95         ret

EDIT:

Hier wird 4x mittels asr geschoben, weil nun int8_t statt uint8_t 
verwendet wird.

Beispiel C:
enum zahl { NU_LL = 300, EINS, ZWEI, DREI, VIER};

uint8_t
funktion (enum zahl xx)
{
  46:  24 e0         ldi  r18, 0x04  ; 4
  48:  96 95         lsr  r25
  4a:  87 95         ror  r24
  4c:  2a 95         dec  r18
  4e:  e1 f7         brne  .-8        ; 0x48 <funktion+0x2>
  xx >>= 4;
  return xx;
}
  50:  08 95         ret

Hier wird dann tatsächlich eine 16-Bit-Operation verwendet, weil der 
Wertebereich von 0-255 überschritten wurde.

Ergo: Wenn man den Wertebereich von 0 bis 255 nicht überschreitet, ist 
alles in Butter. Trotzdem lasse ich das so, wie es ist - aus obigen 
Gründen.

Gruß,

Frank

Autor: Frank Lorenzen (florenzen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
[...]
> Änderungen:
>   - Neues Protokoll: BANG_OLUFSEN (B&O)
>
> @Frank Lorentzen: Würde mich über Feedback freuen, ob es klappt. Bitte
> einmal für 10kHz und einmal für 15kHz testen, da ich selbst nur mit der
> Scan-Datei testen konnte.

Das ging aber schnell! Ich teste selbstverständlich - leider nicht mehr 
heute sondern erst morgen, mein Testaufbau hat aus unerfindlichen 
Gründen den Geist aufgegeben.

Ich habe noch eine zweite B&O Fernbedienung gefunden, sieht von Design 
auch wie eine Beolink 1000 aus hat aber weniger und anders beschriftete 
Tasten ("Video Terminal Bang & Olufsen" steht drauf). Die Teste ich 
morgen gleich mal mit.


Ich bin außerdem noch auf ein Problem gestossen: SIRCS scheint nur für 
die ersten ein, zwei Frames zu funktionieren obschon die FB dauerhaft 
ein Signal aussendet. Ich habe aber noch nicht geschaut woran das liegen 
könnte.


Gruß,

f

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

Bewertung
0 lesenswert
nicht lesenswert
Frank Lorenzen schrieb:

> Ich bin außerdem noch auf ein Problem gestossen: SIRCS scheint nur für
> die ersten ein, zwei Frames zu funktionieren obschon die FB dauerhaft
> ein Signal aussendet. Ich habe aber noch nicht geschaut woran das liegen
> könnte.

Die kannst Du ja dann bei der Gelegenheit mal direkt scannen und mir die 
Datei zuschicken.

Gruß,

Frank

Autor: Frank Lorenzen (florenzen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
[...]
>> @Frank Lorentzen: Würde mich über Feedback freuen, ob es klappt. Bitte
>> einmal für 10kHz und einmal für 15kHz testen, da ich selbst nur mit der
>> Scan-Datei testen konnte.
[...]

Funktioniert wunderbar sowohl mit 10 als auch mit 15kHz.
Danke dir.

Sorry daß ich so Wortkarg bin, aber ich bin heute wirklich hundemüde.
Gruß,
f

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

Bewertung
0 lesenswert
nicht lesenswert
Frank Lorenzen schrieb:

> Funktioniert wunderbar sowohl mit 10 als auch mit 15kHz.

Freut mich.

> Sorry daß ich so Wortkarg bin, aber ich bin heute wirklich hundemüde.

Danke für den Test - auch wenn ich Dir nicht den Schlaf rauben wollte 
;-)

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
Analog zum IRMP ist nun das Bang&Olufsen-Protokoll auch im IRSND 
integriert.

Download:

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

Viel Spaß,

Frank

Autor: J. Kum (kum)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen,

habe einige Probleme IRMP+IRSND für einen IR-Tranciever gemeinsam zum 
Laufen zu bewegen.

AVR-GCC, Atmega8, lfuse0xe2, hfuse0xd9, Kompilleren klappt, Flashen 
auch, irsndmain.c wird nicht mitkompilliert.

Mangels MAX232 und LCD wollte ich einfach eine Led toggeln, damit ich 
erkennen kann, ob definierter Tastendruck erkannt wird. Das habe ich 
ohne Erfolg mit TSOP7000 (B&O) und TSOP1738 (Apple) probiert. Output 
TSOP hängt an Pin9. Der TSOP1738 könnte auch ein TSOP1736 sein. Kam aus 
der Bastelkiste und ich kann mich nicht mehr genau erinnern, welchen ich 
damals bestellt hatte.

In der Steckbrett-Schaltung ist zusätzlich ein BC548 mit Fotodiode oder 
einfache Led an Pin17 untergebracht. Ein irmp_send_data lässt die 
normale Led zumindest wie ein IR-Code blinken, aber mit einer Fotodiode 
reagiert kein getestetes Gerät.

Jetzt ein anderer Test: Direktes Durchschleifen des IR-Signals auf eine 
normale Led, die dann in der Theorie genauso blinken sollte wie der 
empfangene Code. TSOP7000 keine Reaktion. Beim  TSOP1738 reagiert die 
Led ab und zu mal auf einen Tastendruck - die Led blinkt aber nur sehr 
kurz auf und das sieht keinesfalls wie ein IR-Code-Blinken aus. Auf eine 
RC5-FB reagiert er gar nicht.

Entweder liegt ein einem fehlerhaften zusammenfügen der Sourcen von IRMP 
und IRSND und der Anpassungen an den Atmega8 oder an der Schaltung? Oder 
beides ;-)

Habe den Quell-Code mal angehängt. Wäre für einen Hinweis dankbar.

Gruß, Kum

Autor: J. Kum (kum)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo noch mal,

also ich vermute ein Timing-Problem. Beim Empfang funktioniert es schon 
nicht richtig und ab und zu denkt irmp es hätte was dekodiert und 
schickt dieses verkrüppelte Paket an irsnd und daher blinkt es mal kurz 
auf. Lasse ich ein definiertes Paket direkt von irsnd abarbeiten, dann 
erscheint es wie IR-Code-Blinken, aber wahrscheinlich zu langsam bzw. 
irgendwie fehlerhaft. Komme einfach nicht dahinter...

Viele Grüße, Kum

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

Bewertung
0 lesenswert
nicht lesenswert
J. Kum schrieb:

> AVR-GCC, Atmega8, lfuse0xe2, hfuse0xd9

Habe die Werte gerade mal in den Fuse-Calculator

   http://www.engbedded.com/fusecalc/

eingegeben.

2 MHz ist ein bisschen zu wenig, oder?

Gruß,

Frank

Autor: Frank Lorenzen (florenzen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nicht nur das. Zu allem Übel ist im Makefile 8MHz angegeben.
Das kann nicht funktionieren.
Fuse doch bitte mal auf h=0xD9 l=0xE4

Gruß,
f

Autor: J. Kum (kum)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lieber Frank, Lieber Frank,

wie peinlich. Den Kalkulator von Mark (<-- auch ein ganz, ganz netter 
Kerl) habe ich benutzt und war mir da auch ganz sicher. Oje, oje, ist 
das peinlich ... vielen, vielen Dank für den Hinweis. Neue Fuses: die 
Schaltung und das noch viel tollere Stück Software rennt wie der Teufel!

Dann kann ich jetzt weiter damit rumspielen ... ich freu mich.

Viele Grüße, Kum

Autor: Klaus Leidinger (klausleidinger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank L. und B&O Anwender,

Frank Lorenzen schrieb:
> Ich habe einen TSOP7000 den ich vor einiger Zeit mal bei Farnell
> bestellt hatte. Wie ich gerade sehe ist der aber bei Farnell nicht mehr
> erhältlich weil abgekündigt.
>
> TME hat ihn noch im Programm aber z.Z. 0 Stück auf Lager, vielleicht
> ...
> Danke Klaus. Ohne deine Nachfrage wüsste ich nicht das der TSOP7000
> abgekündigt ist
>

Ich hab den TSOP7000 gerade von Darisus http://www.darisus.de erhalten, 
dort gibt es auch den TSOP1156 und der Shop ist auch sonst bestens 
sortiert (nicht nur) im Bereich IR-Empfänger.

Ich hoffe das war keine unzulässige Werbung...

Viele Grüße,
Klaus

Autor: siegmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus Leidinger schrieb:
> Ich hab den TSOP7000 gerade von Darisus http://www.darisus.de erhalten,
> dort gibt es auch den TSOP1156 und der Shop ist auch sonst bestens
> sortiert (nicht nur) im Bereich IR-Empfänger.
>
> Ich hoffe das war keine unzulässige Werbung...


Gerade diese Tips, bezüglich Lieferquellen, finde ich besonders wertvoll 
!!

Noch einen schönen Abend
Gruß
Siegmar

Autor: J. Kum (kum)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen,

stehe bzgl. IRSND und der Unterstützung für Apple auf dem Schlauch. Im 
Artikel ist das Protokoll als "supported" beschrieben, aber kann im Code 
kein

#define IRSND_SUPPORT_APPLE_PROTOCOL

finden. Auch kein umswitchen von NEC zu Apple analog zu IRMP. Dort wird 
zunächst NEC geprüft, und dann auf Apple geswitched, weil Protokolle 
sehr ähnlich. Bei IRSND müsste es doch eine ähnliche Vorgehensweise 
geben, oder nicht? Wenn Apple --> switch zu NEC. Diesen Part kann ich 
aber nirgends finden.

Vielen Dank, Kum

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

Bewertung
0 lesenswert
nicht lesenswert
J. Kum schrieb:

> stehe bzgl. IRSND und der Unterstützung für Apple auf dem Schlauch. Im
> Artikel ist das Protokoll als "supported" beschrieben, aber kann im Code
> kein
>
> #define IRSND_SUPPORT_APPLE_PROTOCOL
>
> finden.

Tut mir leid, das hat historische Gründe:

Das Apple-Protokoll lief früher im IRMP als NEC-Protokoll mit einem 
bestimmten Bit-Muster in den Datenbits des Frames (keine Invertierung, 
sondern festes Bitmuster in den Datenbits 24 bis 31). Später habe ich 
das Apple-Protokoll im IRMP separiert, das aber im IRSND einfach 
vergessen. Ich werde das im IRSND nachholen.

Gruß,

Frank

Autor: J. Kum (kum)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:

> Später habe ich
> das Apple-Protokoll im IRMP separiert, das aber im IRSND einfach
> vergessen. Ich werde das im IRSND nachholen.

Mach dir keinen Stress ;-) Hatte versucht mich selbst darum zu bemühen 
es in irsnd.c einzupflegen, aber das ging vollends in die Hose.

Vielen lieben Dank für dein Engagement.

Viele Grüße, Kum

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

Bewertung
0 lesenswert
nicht lesenswert
J. Kum schrieb:

> Mach dir keinen Stress ;-) Hatte versucht mich selbst darum zu bemühen
> es in irsnd.c einzupflegen, aber das ging vollends in die Hose.

Hier ist der Fix, den kannst Du in irsnd selbst einbauen:

Wie bisher:
        case IRMP_NEC_PROTOCOL:
        {
           ...
        }

Darunter einfügen (also noch vor dem #endif:
        case IRMP_APPLE_PROTOCOL:
        {
            irsnd_protocol = IRMP_NEC_PROTOCOL; // APPLE protocol is NEC with fix bitmask instead of inverted command

            address = bitsrevervse (irmp_data_p->address, NEC_ADDRESS_LEN);
            command = bitsrevervse (irmp_data_p->command, NEC_COMMAND_LEN);

            irsnd_buffer[0] = (address & 0xFF00) >> 8;                                                          // AAAAAAAA
            irsnd_buffer[1] = (address & 0x00FF);                                                               // AAAAAAAA
            irsnd_buffer[2] = (command & 0xFF00) >> 8;                                                          // CCCCCCCC
            irsnd_buffer[3] = 0x8B;                                                                             // 10001011
            irsnd_busy      = TRUE;
            break;
        }


Das wars. Ein IRSND_SUPPORT_APPLE_PROTOCOL wird es nicht geben, denn es 
ist einfach IRSND_SUPPORT_NEC_PROTOCOL auf 1 zu setzen. Ich werde das 
auch so nochmal im IRMP-Artikel erläutern.

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
Neue Version von IRSND im Downloadbereich:

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

Änderungen:

 - Unterstützung des APPLE-Protokolls
 - Konfiguration über irmpconfig.h - analog zum IRMP
 - Einige Codeoptimierungen, um Flash-Speicher zu sparen

Viel Spaß,

Frank

Autor: Patrick Hh (patrickhh)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

endlich bin ich heute dazu gekommen den IRMP mal aufzubauen und zu 
testen. Hab mal alle FB aus meinem Sortiment zu Hause rausgekramt, um zu 
sehen, was die alle so "senden". Da kamen schon einige Protokolle 
zusammen:
NEC, RC5x, RC5, SIRC, RC6, KASEIKYO

Jetzt noch zu einer FB (wahrscheinlich Fernseher) von Grundig (FB Typ: 
TP 715). Die wurde von IRMP nicht erkannt. Kannst du mal schauen, ob es 
möglich ist, diese mit in IRMP zu integrieren.
Im Anhang findest du die Scans.

Außerdem habe ich in meinen Dokus noch ein Grundig-Protokoll gefunden.
Vielleicht kann das ja mal einer gebrauchen.


Danke schon mal für deine/eure Unterstützung...


Gruß

PatrickHH

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

Bewertung
0 lesenswert
nicht lesenswert
Hallo Patrick,

Patrick Hh schrieb:

> Jetzt noch zu einer FB (wahrscheinlich Fernseher) von Grundig (FB Typ:
> TP 715). Die wurde von IRMP nicht erkannt. Kannst du mal schauen, ob es
> möglich ist, diese mit in IRMP zu integrieren.
> Im Anhang findest du die Scans.

Ich habe mir die Scans angeschaut: Das ist eine Manchester-Codierung - 
ähnlich zu RC5, aber doch wieder ganz anders...

> Außerdem habe ich in meinen Dokus noch ein Grundig-Protokoll gefunden.
> Vielleicht kann das ja mal einer gebrauchen.

Die Doku ist spitze, sie beschreibt genau die Signale, die ich in Deinen 
Scans fand. :-)

Ich schaue mal, dass ich das Grundig-Protokoll in den IRMP integriere. 
Leider ist es wegen der Manchester-Codierung nicht damit getan, einfach 
nur die Preprocessor-Konstanten für die Timings zu definieren.

Gruß,

Frank

Autor: Patrick Hh (patrickhh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ging ja schnell!

Das hört sich ja schon mal ganz gut an. Ist auch nicht so eilig für 
mich.

Dann viel Erfolg. Mal sehen ob es klappt.

Schönen Abend noch...


PatrickHH

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

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:

> Ich schaue mal, dass ich das Grundig-Protokoll in den IRMP integriere.

Habe es erfolgreich einbauen können, kostet auch nur "150" weitere Bytes 
im Binary.

@Patrick:
Bevor ich nun ein neues Release mache, würde ich das gerne einmal von 
Dir testen lassen, deshalb hänge