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.

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

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

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


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

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

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


Der Empfangspuffer sieht dann so aus:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Gruß,

Frank

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

Stimmt.

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

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

Gruß,

Frank

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

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

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

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

Gruß,

Frank

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

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

Ich habe da gerade nochmal in den Source geschaut:

#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

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

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

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

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

@Sebastian___

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

Wäre Dir damit geholfen?

Gruß,

Frank

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

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

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

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

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

Rätselhaft das ganze...

Gruß,

Frank

Ich kann das ganze ja bei gelegenheit nochmal wiederholen.

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

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


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

Vlad Tepesch schrieb:

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

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

Hole ich jetzt nach.

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

Gruß,

Frank

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

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

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

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

Warum ist das speichersparend?

Gruß,

Frank

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

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

Klingt ja ganz gut, bin gespannt.

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

Gruß,

Frank

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

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

Gruß,

Frank

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

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

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

Wenn Du in der Zeile

#define IRMP_SUPPORT_SAMSUNG_PROTOCOL      1

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

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

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

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

Gruß,

Frank

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

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

Gruß,

Frank

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

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

Nein, habe ich nicht gemacht. Werde ich nachholen.

Gruß,

Frank

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

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

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

Mache ich am Wochenende.

Gruß,

Frank

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

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

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

Software-Stand: 05.02.2010

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

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

Gruß,

Frank

Hi!

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

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

Gruß, DiPi

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

Di Pi schrieb:

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

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

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

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

Gruß,

Frank

Frank M. schrieb:

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

GrußWilli

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

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

Viele Grüße, DiPi

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

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

Ja, das ist das NEC-Protokoll.

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

Gruß,

Frank

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

Danke, ist eingebaut:

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

Gruß,

Frank

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

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

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

Gruß,

Frank

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

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

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

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

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

Gruß,

Frank

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

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

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

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

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

Gruß,

Frank

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

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

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

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

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

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

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

pressen. Sondern:

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

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

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

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

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

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

Aber:

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

Damit sehen die beiden ersten Bits folgendermaßen aus:

Entweder:

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

oder:

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

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

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

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

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

Gruß,

Frank

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

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

Gruß,

Frank

Frank M. schrieb:

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

Gruß Willi

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

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

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

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

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

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

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

Gruß,

Frank

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

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

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

Gruß Willi

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

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

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

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

Dank und Gruß,

Frank

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

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

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

Noch ein Tipp am Rande:

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

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

Viel Spaß,

Frank

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

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

Gruß,

Frank

Habe noch einen Bug korrigiert:

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

Download-Zip-Datei habe ich aktualisiert.

Gruß,

Frank

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

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

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

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

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

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

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

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

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

Gruß,

Frank

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

Genau so ist es!

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

Gruß Willi

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

Da wäre ich mir nicht so sicher. Laut

http://www.mikrocontroller.net/attachment/67261/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

siegmar schrieb:

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

Mein erster Gedanke wäre die Lirc-DB.

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

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

Gruß,

Frank

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

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

Hallo Frank,

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

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

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

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

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

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

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

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

Grüße,
Klaus

Hallo Klaus,

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

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

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

Dito.

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

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

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

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

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

Prima.

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

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

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

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

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

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

Gruß,

Frank

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

Grüße,
Albert

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

Du hast Post.

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

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

Mal sehen wieviel Aufwand das wird ;-)

Grüße,
Klaus

Klaus Leidinger schrieb:

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

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

Gruß,

Frank

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

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

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

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

Gruß,

Frank

Es gibt eine neue Version von IRMP zum Download:

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

Änderungen:

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

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

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

Beispiel:

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

   irmp.exe <rc5x.txt

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

   irmp.exe <rc5x.txt | more


Viel Spaß,

Frank

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

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

Klaus

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

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

Gruß,

Frank

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

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

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

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

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

Gruß,

Frank

Frank M. schrieb:

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

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

Moin,

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

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

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

Viele Grüsse
Michael

Michael Urban schrieb:

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

Ist das generell sinnvoll und damit von allgemeinem Interesse?

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

@Michael: Für was brauchst Du das?

Gruß,

Frank

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

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

b)

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

Gruß,

Frank

Moin,

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

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

Ich habe das ganz einfach gelöst:

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

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

Ach ja, vergessen:

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

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

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

#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

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

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

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

dann setze das Repetition-Flag.

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

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

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

Gruß,

Frank

Es gibt eine neue Version von IRMP zum Download:

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

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

Um zu unterscheiden, ob eine Taste lange gedrückt wurde oder lediglich
einzeln, dient das Bit IRMP_FLAG_REPETITION. Dieses wird im
Struct-Member flags gesetzt, wenn eine Taste auf der Fernbedienung
längere Zeit gedrückt wurde und dadurch immer wieder dasselbe Kommando
innerhalb kurzer Zeitabstände ausgesandt wird.

Beispiel:

    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.

Es gibt eine neue Version vom IRMP zum Download:

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

Änderungen:

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

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

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

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

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

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

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

Gruß,

Frank

Hi Frank,

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

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

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

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

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

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

-Peter

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

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

Hi Peter,

Peter Kostov schrieb:

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

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

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

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

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

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

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

Bitte Scans her. Ich passe das dann an.

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

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

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

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

Auch hier helfen mir nur Scans.

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

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

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

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

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

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

Danke im voraus für die Scans ;-)

Gruß,

Frank

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

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

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

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

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

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

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

Gruß,

Frank

Hallo Frank,

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

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

Getestet wurde das Ganze mit einem ATMEGA32@16MHz.

-Peter

Hallo Peter,

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

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

Gruß,

Frank

Ich habe nun die einzelnen Scans von Peter durchgearbeitet:

Sony-RM-S-310:

  Protokoll: SIRCS
  Erkennung: 100%

Sony-RMT-V406:

  Protokoll: SIRCS
  Erkennung: 100%

Sony-RM-U305C:

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

Sony-RMT-D142P-DVD:

  Protokoll: SIRCS
  Erkennung : 100%

Panasonic-Blue-Ray:

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

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

Yamaha-RAV388:

  Protokoll: NEC
  Erkennung: 100%

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

Samsung_TV:

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

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

  Siehe auch IRMP-Artikel, wurde angepasst bzgl. SAMSUNG2

Kathrein-UFS-912-Remote:

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

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

Gruß,

Frank

Hi Frank,

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

-Peter

Hi Peter,

Peter K. schrieb:

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

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

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

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

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

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

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

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

Kannst Du gerne machen.

Gruß,

Frank

Neue Version von IRMP zum Download verfügbar:

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

Erweiterungen/Änderungen:

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

Dank an Peter K. für die Scans.

Gruß,

Frank

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

Hallo Peter,

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

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

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

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

Hi Klaus,

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

-Peter

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

Ciao - Peter

Mehr Zeit müsste man haben :)

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

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

Danke für die Info,
Klaus

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

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

-Michael

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

IRSND - diese hat gerade Klaus im Test ;-)

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

Gruß,

Frank

Hi Peter,

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

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

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

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

> Aber: Samsung wird jetzt gut erkannt, prima!

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

> Mehr Zeit müsste man haben :)

Wie wahr...

Gruß,

Frank

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

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

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

Klaus

Hi!

Zuerst: super Arbeit hier!

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

1. F_CPU, benutze einen Quarz 12MHz:

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!

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

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

Sollte dann also passen, danke!

Eine neue Version von IRMP ist unter

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

verfügbar.

Änderungen:

1) Neues Protokoll: Apple

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

Zu 1)

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

Zu 2)

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

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

Gruß,

Frank

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

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

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

Klaus

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

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

Den Download habe ich eben aktualisiert.

Gruß,

Frank

Eine neue Version von IRMP ist unter

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

verfügbar.

Grund:

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

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

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

Gruß,

Frank

Hallo,

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

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

IRSND unterstützt die folgenden Protokolle:

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

IRSND unterstützt folgende Protokolle (noch) nicht:

    * KASEIKYO
    * RC6


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

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

Der Download-Link ist dort auch zu finden.

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

Gruß,

Frank

Hi,

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

Ich habe Irmp mit V-USB kombiniert.

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

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

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!

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.

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

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

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

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

Gruß,

Frank

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

Direkt in der Zeile darunter:

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

Gruß,

Frank

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

Da ich leider den Beitrag nicht editieren kann:

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

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

Hugo Portisch schrieb:

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

Richtig.

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

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

Gruß,

Frank

Man O Man, ich dreh noch durch!

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

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

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

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

Danke!

Hugo Portisch schrieb:

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

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

  _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

Habe es geschafft!

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

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

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

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

Ist zwar nicht so schön geht aber nun!

Anbei das neue Projekt!

Danke für Hilfe und für Irmp!

Hi, nochmal ich!

Kann die Beiträge einfach nicht editieren :(

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

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

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

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

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.

Hallo Frank,

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

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

-Peter

Hallo Peter,

Peter K. schrieb:

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

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

Gruß,

Frank

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

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

IRMP löft auch auf einen PIC

danke für die Arbeit

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

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

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

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.

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

Frank fettes Danke für die schnelle Antwort und für IRMP  :-)

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

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
}

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

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 ;-)

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

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

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.

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

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

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

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

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

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

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

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

@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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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.

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

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

Um nicht noch mehr OT zu produzieren antworte ich dir privat

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.

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

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

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.

#include "irmp.c" 

gefunden in main.c im Codevison Teil.

Warum das ?

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

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

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

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.

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____________

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

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

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

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.

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

Gruß
f

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

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

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.

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

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

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

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

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

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

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