Forum: Projekte & Code IRMP - Infrared Multi Protocol Decoder


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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


Hallo zusammen,

Anmerkung:

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

Artikel

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

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

   http://www.mikrocontroller.net/topic/156661

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.

von I. E. (anfaenger69)


Lesenswert?

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

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

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


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

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

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


Der Empfangspuffer sieht dann so aus:

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

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

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

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

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

von eku (Gast)


Lesenswert?

Hallo Frank!

In Deiner ISR wird bereits das Protokoll erkannt. Ist das sinnvoll? 
Könnte man nicht den IR-Eingang im konstanten Timerraster abtasten und 
das Ergebnis in eine FIFO legen. Eine Dekoderfunktion sammelt die Werte 
aus der FIFO, erkennt das Protokoll und dekodiert die Sequence. Worin 
liegt der Vorteil Deiner Implementierung?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

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

Der Vorteil liegt beim niedrigen Speicherbedarf. Nach dem eingetroffenen 
Startbit wird das Protokoll sofort erkannt und dann werden die weiteren 
Hell-Dunkelphasen nur noch als einzelne Bits gespeichert, weil sich die 
ISR aufs Protokoll "eingeschossen" hat. So kommt man mit 5 Bytes aus, in 
denen alles nötige gespeichert ist - hier als struct definiert:
1
typedef struct
2
{
3
  uint8_t   protocol;          // protocol, i.e. IRMP_NEC_PROTOCOL
4
  uint16_t  address;           // address
5
  uint16_t  command;           // command
6
} IRMP_DATA;

Das heisst: am Ende bekommt man dann über irmp_get_data() einfach drei 
Werte, die man über ein if oder switch checken kann, z.B. hier eine 
Routine, welche die Tasten 1-9 auf einer Fernbedienung auswertet:
1
   if (irmp_data.protocol == IRMP_NEC_PROTOCOL &&     // NEC-Protokoll
2
       irmp_data.address == 0x00FF)                   // Adresse 0x00FF
3
   {
4
      switch (irmp_data.command)
5
      {
6
         case 0x0001: key1_pressed(); break;          // Taste 1
7
         case 0x0002: key2_pressed(); break;          // Taste 2
8
         ...
9
         case 0x0009: key9_pressed(); break;          // Taste 9
10
      }
11
   }

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

Einfacher gehts doch nicht, oder?

Gruß,

Frank

von Sebastian___ (Gast)


Lesenswert?

Hallo Frank,
wie erkennst du zb wenn per Fernbedienung ein Lautstärkekomando kommt.
Soweit ich das bei deinem Code erkennen konnte wird der empfangene Code 
nur 1x ausgewertet.
Wie geht das beim Sircs Protokoll? ein Kommando wird 3x wiederholt, nach 
der wiederholung müsste man das kommando erneut auslösen.

von eku (Gast)


Lesenswert?

Hallo Frank!

Frank M. schrieb:
> eku schrieb:
>
>> In Deiner ISR wird bereits das Protokoll erkannt. Ist das sinnvoll?
>
>> Könnte man nicht den IR-Eingang im konstanten Timerraster abtasten und
>
>> das Ergebnis in eine FIFO legen.
>
>
>
> Das verbraucht aber dann evtl. ne Menge Speicherplatz. Wenn ich da ans
>
> Kaseikyo-Protokoll mit 48 Bit denke, müsste ich 48 x 2 = 92 Bytes haben,
>
> um die Timingwerte für jede Hell-/Dunkelsequenz zu speichern.
>
>
>
>> Eine Dekoderfunktion sammelt die Werte
>
>> aus der FIFO, erkennt das Protokoll und dekodiert die Sequence. Worin
>
>> liegt der Vorteil Deiner Implementierung?
>
>
>
> Der Vorteil liegt beim niedrigen Speicherbedarf. Nach dem eingetroffenen
>
> Startbit wird das Protokoll sofort erkannt und dann werden die weiteren
>
> Hell-Dunkelphasen nur noch als einzelne Bits gespeichert, weil sich die
>
> ISR aufs Protokoll "eingeschossen" hat. So kommt man mit 5 Bytes aus, in
>
> denen alles nötige gespeichert ist

Das habe ich soweit verstanden. Würdest Du die Daten jedes Protokolls
in einer Struktur zusammenfassen, bräuchtest Du nur einen Zeiger auf
die jeweilie Struktur (=Protokoll) setzen und nicht so viele statisch 
Variablen in der ISR initialisieren. Die einen Indirektion bei der 
Adressierung sollte auf Grund der anderen Ersparnis nicht ins Gewicht 
fallen. Der Code würde noch dazu leserlicher.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

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

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

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

Stimmt.

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

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

Gruß,

Frank

von eku (Gast)


Lesenswert?

Hallo Frank!

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

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

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

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

Gruß,

Frank

von Sebastian___ (Gast)


Lesenswert?

bei SIRC  ist es jeden fall so das man da nicht zwischen den Repeats 
unterscheiden kann.
Taste kurz gedrückt = 3x command im 45ms Raster.
Taste länger gedrückt = nx command im 45ms Raster.
Ich habe mir das mal auf dem Oszi angeschaut. (ist ein Sony DVD Player)

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

Ich habe da gerade nochmal in den Source geschaut:
1
#define SIRCS_REPETITION_TIME                 (uint16_t)(F_INTERRUPTS * 50.0e-3 + 0.5)          // repetition after ~45-50 msec
2
...
3
        // if SIRCS protocol and the code will be repeated inside of 50 ms, we will ignore it.
4
        if (irmp_protocol != IRMP_SIRCS_PROTOCOL || last_irmp_command != irmp_tmp_command || repetition_counter > SIRCS_REPETITION_TIME)
5
...

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

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

Gruß,

Frank

von Michael M. (Gast)


Lesenswert?

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

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

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

holli

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

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

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

@Sebastian___

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

Wäre Dir damit geholfen?

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

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

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

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

Rätselhaft das ganze...

Gruß,

Frank

von Vlad T. (vlad_tepesch)


Lesenswert?

Ich kann das ganze ja bei gelegenheit nochmal wiederholen.

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

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


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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Vlad Tepesch schrieb:

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

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

Hole ich jetzt nach.

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

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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



Vlad Tepesch schrieb:

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

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

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

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

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

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

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

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

Gruß,

Frank

von Sebastian___ (Gast)


Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

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

Warum ist das speichersparend?

Gruß,

Frank

von Sebastian___ (Gast)


Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

Klingt ja ganz gut, bin gespannt.

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

Gruß,

Frank

von Sebastian___ (Gast)


Lesenswert?

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

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

von Sebastian___ (Gast)


Lesenswert?

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

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

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

und

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

auf 20% setzt, geht die Protokollerkennung.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

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

Wenn Du in der Zeile

#define IRMP_SUPPORT_SAMSUNG_PROTOCOL      1

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

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

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

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

Gruß,

Frank

von Sebastian___ (Gast)


Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

Gruß,

Frank

von Vlad T. (vlad_tepesch)


Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

Nein, habe ich nicht gemacht. Werde ich nachholen.

Gruß,

Frank

von Bastler (Gast)


Lesenswert?

Hat evtl. jemand von euch ne Apple Fernbedienung aus Alu?

von IR (Gast)


Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

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

Mache ich am Wochenende.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

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

Software-Stand: 05.02.2010

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

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

Gruß,

Frank

von Di P. (drpepper) Benutzerseite


Lesenswert?

Hi!

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

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

Gruß, DiPi

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Di Pi schrieb:

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

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

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

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

Gruß,

Frank

von RC5 (Gast)


Lesenswert?

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

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

von Michael M. (Gast)


Lesenswert?

Frank M. schrieb:
>> Damit kann ich endlich die Reichelt-RGB-Fernbedienung lesen, die ich mir
>> bestellt habe ;)
>
> Sag mal bitte die Bestellnummer, interessiert mich immer wieder, welche
> FBs damit so laufen...
LED RGB REMOTE
http://www.reichelt.de/?;ARTICLE=92594

von Toralf W. (willi)


Lesenswert?

Frank M. schrieb:

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

GrußWilli

von Di P. (drpepper) Benutzerseite


Lesenswert?

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

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

Viele Grüße, DiPi

von Michael M. (Gast)


Angehängte Dateien:

Lesenswert?

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

von Di P. (drpepper) Benutzerseite


Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

Ja, das ist das NEC-Protokoll.

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

Gruß,

Frank

von Michael M. (Gast)


Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

Danke, ist eingebaut:

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

Gruß,

Frank

von Michael M. (Gast)


Lesenswert?

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

grüße,
michael

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

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

Gruß,

Frank

von Michael M. (Gast)


Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

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

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

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

Gruß,

Frank

von Di P. (drpepper) Benutzerseite


Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

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

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

Gruß,

Frank

von M. K. (kichi)


Lesenswert?

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

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

von Frank B. (frank_boe)


Lesenswert?

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

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

von Michael M. (Gast)


Lesenswert?

meine yamaha-fb auch.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

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

pressen. Sondern:

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

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

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

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

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

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

Aber:

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

Damit sehen die beiden ersten Bits folgendermaßen aus:

Entweder:

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

oder:

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

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

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

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

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

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

Gruß,

Frank

von Toralf W. (willi)


Lesenswert?

Frank M. schrieb:

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

Gruß Willi

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

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

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

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

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

Gruß,

Frank

von Toralf W. (willi)


Lesenswert?

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

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

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

Gruß Willi

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

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

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

Dank und Gruß,

Frank

von Toralf W. (willi)


Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

Noch ein Tipp am Rande:

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

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

Viel Spaß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Habe noch einen Bug korrigiert:

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

Download-Zip-Datei habe ich aktualisiert.

Gruß,

Frank

von Simon K. (simon) Benutzerseite


Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

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

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

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

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

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

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

Gruß,

Frank

von Toralf W. (willi)


Lesenswert?

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

Genau so ist es!

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

Gruß Willi

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

Da wäre ich mir nicht so sicher. Laut

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

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

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

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

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

Gruß,

Frank

von siegmar (Gast)


Lesenswert?

Hi Leute,
tolles Projekt !!
Ich habe aber leider ein gänzlich anderes Problem.
Weiß Jemand ob es eine Art Datenbank gibt, wo man herausfinden kann, 
welches IR Protokoll ein Gerät benutzt ?
Hintergrund meiner Frage ist, das ich einen Digital Sat receiver 
(Philips DIS 2221) ohne Fernbedienung rumliegen habe und keine bisher 
von mir getestete Universalfernbedienung funktioniert.
Der IR Epfänger funktioniert.
Habe mir die Signale mit dem Scope angeschaut.
Würde den Sat Receiver ungern wegwerfen, denn wenn ich bedenke wieviel 
Dreck bei der Produktionen einen Neuen ensteht ...
Vielleicht hat ja Jemand einen guten Tip.

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

siegmar schrieb:

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

Mein erster Gedanke wäre die Lirc-DB.

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

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

Gruß,

Frank

von siegmar (Gast)


Lesenswert?

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

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

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

von M. K. (kichi)


Lesenswert?

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

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

von Klaus L. (kllei)


Angehängte Dateien:

Lesenswert?

Hallo Frank,

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

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

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

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

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

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

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

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

Grüße,
Klaus

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Klaus,

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

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

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

Dito.

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

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

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

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

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

Prima.

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

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

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

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

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

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

Gruß,

Frank

von Albert K. (datasec)


Lesenswert?

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

Grüße,
Albert

von Klaus L. (kllei)


Lesenswert?

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

Du hast Post.

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

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

Mal sehen wieviel Aufwand das wird ;-)

Grüße,
Klaus

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Klaus Leidinger schrieb:

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

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

Gruß,

Frank

von siegmar (Gast)


Lesenswert?

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

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

von Di P. (drpepper) Benutzerseite


Lesenswert?

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

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Es gibt eine neue Version von IRMP zum Download:

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

Änderungen:

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

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

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

Beispiel:

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

   irmp.exe <rc5x.txt

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

   irmp.exe <rc5x.txt | more


Viel Spaß,

Frank

von Klaus L. (kllei)


Lesenswert?

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

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

Klaus

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

Gruß,

Frank

von Chris M. (shortie)


Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

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

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

Gruß,

Frank

von Chris M. (shortie)


Lesenswert?

Frank M. schrieb:

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

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

von Michael U. (murban)


Lesenswert?

Moin,

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

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

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

Viele Grüsse
Michael

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Michael Urban schrieb:

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

Ist das generell sinnvoll und damit von allgemeinem Interesse?

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

@Michael: Für was brauchst Du das?

Gruß,

Frank

von Di Pi (Gast)


Lesenswert?

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

von Vlad T. (vlad_tepesch)


Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

b)

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

Gruß,

Frank

von Michael U. (murban)


Lesenswert?

Moin,

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

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

Ich habe das ganz einfach gelöst:

Die Datenstruktur IRMP_DATA habe ich durch ein viertes Feld ergänzt:
1
typedef struct
2
{
3
  uint8_t               protocol;                                                               // protocol, i.e. NEC_PROTOCOL
4
  uint16_t              address;                                                                // address
5
  uint16_t              command;                                                                // command
6
  uint8_t               repetition;                                                               // repetition frame
7
} IRMP_DATA;

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

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

Das funktioniert bei allen Protokollen, die einen repetition frame 
besitzen

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

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

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

Viele Grüsse
Michael

von Michael U. (murban)


Lesenswert?

Ach ja, vergessen:

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

Okay, ich bau das so ähnlich ein, aber etwas allgemeingültiger:
1
#define IRMP_FLAG_REPETITION    0x01
2
#define IRMP_FLAG_WASWEISSICH   0x02
3
....
4
5
typedef struct
6
{
7
  uint8_t          protocol;           // protocol, i.e. NEC_PROTOCOL
8
  uint16_t         address;            // address
9
  uint16_t         command;            // command
10
  uint8_t          flags;              // flags, e.g. repetition frame
11
} IRMP_DATA;

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

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

In main() kann man das dann so abfragen:
1
   if (irmp_data.flags & IRMP_FLAG_REPETITION)
2
   {
3
      finger_blau();
4
   }
5
   else
6
   {
7
      normale_taste();
8
   }

Gruß,

Frank

von Di Pi (Gast)


Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

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

dann setze das Repetition-Flag.

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

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

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

Gruß,

Frank

von Di Pi (Gast)


Lesenswert?

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

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

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

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

immer gilt.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Es gibt eine neue Version von IRMP zum Download:

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

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

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

Beispiel:
1
    if (irmp_data.flags & IRMP_FLAG_REPETITION)
2
    {
3
      finger_blau (irmp_data.command);
4
    }
5
    else
6
    {
7
      einzeln (irmp_data.command);
8
    }

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Es gibt eine neue Version vom IRMP zum Download:

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

Änderungen:

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

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

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

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

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

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

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

Gruß,

Frank

von Peter K. (peko)


Lesenswert?

Hi Frank,

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

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

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

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

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

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

-Peter

von Di P. (drpepper) Benutzerseite


Lesenswert?

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

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi Peter,

Peter Kostov schrieb:

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

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

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

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

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

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

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

Bitte Scans her. Ich passe das dann an.

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

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

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

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

Auch hier helfen mir nur Scans.

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

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

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

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

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

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

Danke im voraus für die Scans ;-)

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

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

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

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

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

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

Gruß,

Frank

von Peter K. (peko)


Angehängte Dateien:

Lesenswert?

Hallo Frank,

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

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

Getestet wurde das Ganze mit einem ATMEGA32@16MHz.

-Peter

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Peter,

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

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

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Ich habe nun die einzelnen Scans von Peter durchgearbeitet:

Sony-RM-S-310:

  Protokoll: SIRCS
  Erkennung: 100%

Sony-RMT-V406:

  Protokoll: SIRCS
  Erkennung: 100%

Sony-RM-U305C:

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

Sony-RMT-D142P-DVD:

  Protokoll: SIRCS
  Erkennung : 100%

Panasonic-Blue-Ray:

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

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

Yamaha-RAV388:

  Protokoll: NEC
  Erkennung: 100%

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

Samsung_TV:

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

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

  Siehe auch IRMP-Artikel, wurde angepasst bzgl. SAMSUNG2

Kathrein-UFS-912-Remote:

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

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

Gruß,

Frank

von Peter K. (peko)


Lesenswert?

Hi Frank,

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

-Peter

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi Peter,

Peter K. schrieb:

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

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

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

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

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

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

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

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

Kannst Du gerne machen.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Neue Version von IRMP zum Download verfügbar:

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

Erweiterungen/Änderungen:

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

Dank an Peter K. für die Scans.

Gruß,

Frank

von Klaus L. (kllei)


Lesenswert?

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

Hallo Peter,

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

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

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

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

von Peter K. (peko)


Lesenswert?

Hi Klaus,

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

-Peter

von Peter K. (peko)


Angehängte Dateien:

Lesenswert?

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

Ciao - Peter

Mehr Zeit müsste man haben :)

von Klaus L. (kllei)


Lesenswert?

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

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

Danke für die Info,
Klaus

von Michael H. (mah)


Lesenswert?

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

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

-Michael

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

IRSND - diese hat gerade Klaus im Test ;-)

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

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi Peter,

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

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

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

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

> Aber: Samsung wird jetzt gut erkannt, prima!

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

> Mehr Zeit müsste man haben :)

Wie wahr...

Gruß,

Frank

von Klaus L. (kllei)


Lesenswert?

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

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

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

Klaus

von Hugo P. (portisch)


Lesenswert?

Hi!

Zuerst: super Arbeit hier!

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

1. F_CPU, benutze einen Quarz 12MHz:
1
main.c: #define F_CPU       12000000

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

3. PD3 als Input:
1
/*---------------------------------------------------------------------------------------------------------------------------------------------------
2
 * Change hardware pin here:
3
 *---------------------------------------------------------------------------------------------------------------------------------------------------
4
 */
5
#define IRMP_PORT                               PORTD
6
#define IRMP_DDR                                DDRD
7
#define IRMP_PIN                                PIND
8
#define IRMP_BIT                                3                             // use PD3 as IR input

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

Danke für Hilfe!

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hugo Portisch schrieb:

> 1. F_CPU, benutze einen Quarz 12MHz:
>
1
main.c: #define F_CPU       12000000

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

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

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

    Project -> Configuration Options

den Processor_ und die _Taktrate einstellen.

> 2. Timer Register geändert:

Sieht gut aus.

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

Korrekt.

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

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

#ifdef DEBUG
...
#endif

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

Gruß,

Frank

von Hugo P. (portisch)


Lesenswert?

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

Sollte dann also passen, danke!

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Eine neue Version von IRMP ist unter

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

verfügbar.

Änderungen:

1) Neues Protokoll: Apple

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

Zu 1)

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

Zu 2)

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

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

Gruß,

Frank

von Klaus L. (kllei)


Lesenswert?

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

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

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

Klaus

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

Den Download habe ich eben aktualisiert.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Eine neue Version von IRMP ist unter

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

verfügbar.

Grund:

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

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

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

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo,

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

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

IRSND unterstützt die folgenden Protokolle:

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

IRSND unterstützt folgende Protokolle (noch) nicht:

    * KASEIKYO
    * RC6


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

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

Der Download-Link ist dort auch zu finden.

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

Gruß,

Frank

von Hugo P. (portisch)


Lesenswert?

Hi,

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

Ich habe Irmp mit V-USB kombiniert.

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

Durch testen habe ich rausgefunden, wenn ich den Timer-Init raus lasse, 
geht es:
1
int main(void)
2
{
3
uchar   i;
4
5
6
    wdt_enable(WDTO_2S);
7
    /* Even if you don't use the watchdog, turn it off here. On newer devices,
8
     * the status of the watchdog (on/off, period) is PRESERVED OVER RESET!
9
     */
10
    DBG1(0x00, 0, 0);       /* debug output: main starts */
11
    /* RESET status: all port bits are inputs without pull-up.
12
     * That's the way we need D+ and D-. Therefore we don't need any
13
     * additional hardware initialization.
14
     */
15
    odDebugInit();
16
    usbInit();
17
    usbDeviceDisconnect();  /* enforce re-enumeration, do this while interrupts are disabled! */
18
    i = 0;
19
    while(--i){             /* fake USB disconnect for > 250 ms */
20
        wdt_reset();
21
        _delay_ms(1);
22
    }
23
    usbDeviceConnect();
24
25
  //clear irmp_data
26
  irmp_data.protocol = 0;
27
  irmp_data.address = 0;
28
  irmp_data.command = 0;
29
  irmp_data.flags = 0;
30
31
  irmp_init();                                                              // initialize irmp code
32
  //timer_init();                                                             // initialize timer
33
34
    sei();
35
36
    DBG1(0x01, 0, 0);       /* debug output: main loop starts */
37
    for(;;){                /* main event loop */
38
        DBG1(0x02, 0, 0);   /* debug output: main loop iterates */
39
        wdt_reset();
40
        usbPoll();
41
    }
42
    return 0;
43
}

Wie kann ich das Problem umgehen? Danke!

von Michael M. (Gast)


Lesenswert?

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

von Hugo P. (portisch)


Angehängte Dateien:

Lesenswert?

Schaffe es einfach nicht!

Habe schon vieles Probiert - jedoch kein Erfolg.

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

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

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

von Michael M. (Gast)


Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

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

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

Gruß,

Frank

von Michael M. (Gast)


Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

Direkt in der Zeile darunter:

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

Gruß,

Frank

von Michael M. (Gast)


Lesenswert?

puh... dann nehm ich mal die tomaten runter ^^
sorry

von Hugo P. (portisch)


Lesenswert?

1
@Hugo: Klappt es denn mit der USB-Erkennung, wenn Du in irmp_ISR() einen
2
vorzeitigen return einbaust?
3
4
Gruß,
5
6
Frank

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

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

von Hugo P. (portisch)


Lesenswert?

Da ich leider den Beitrag nicht editieren kann:

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

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

von Sebastian___ (Gast)


Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hugo Portisch schrieb:

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

Richtig.

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

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

Gruß,

Frank

von Hugo P. (portisch)


Lesenswert?

Man O Man, ich dreh noch durch!

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

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

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

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

Danke!

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hugo Portisch schrieb:

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

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

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

Gruß,

Frank

von Hugo P. (portisch)


Angehängte Dateien:

Lesenswert?

Habe es geschafft!

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

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

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

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

Ist zwar nicht so schön geht aber nun!

Anbei das neue Projekt!

Danke für Hilfe und für Irmp!

von Hugo P. (portisch)


Lesenswert?

Hi, nochmal ich!

Kann die Beiträge einfach nicht editieren :(

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

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

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

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

von Micha (Gast)


Lesenswert?

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

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

von Michael M. (Gast)


Lesenswert?

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

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

sry für den OTp

von Hugo P. (portisch)


Lesenswert?

1
Ich habe mir deinen Quelltext nicht im Detail angesehen: betreibst du
2
den AVR als USB-HID, sprich "Tastaturersatz"? Falls ja wofür und
3
funktioniert es einwandfrei?

Kein "Tastaturersatz"...

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

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

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

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

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

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

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

von Peter K. (peko)


Angehängte Dateien:

Lesenswert?

Hallo Frank,

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

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

-Peter

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Peter,

Peter K. schrieb:

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

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

Gruß,

Frank

von Hugo P. (portisch)


Lesenswert?

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

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

von Christian F. (bleuicebox)


Lesenswert?

IRMP löft auch auf einen PIC

danke für die Arbeit

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Christian F. schrieb:
> IRMP löft auch auf einen PIC

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

Gruß,

Frank

von eku (Gast)


Lesenswert?

Hallo Frank!

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

Ich würde den Code zum Einlesen aus irmp_ISR() herausziehen und den 
aktuellen Wert per Argument übergeben, z.B.:
1
--- Irmp.org/irmp.c     2010-03-07 11:54:40.000000000 +0100
2
+++ Irmp/irmp.c 2010-03-12 18:06:15.105627851 +0100
3
@@ -668,7 +668,7 @@
4
  *---------------------------------------------------------------------------------------------------------------------------------------------------
5
  */
6
 void
7
-irmp_ISR (void)
8
+irmp_ISR (const uint8_t data)
9
 {
10
     static uint8_t    irmp_start_bit_detected;                                  // flag: start bit detected
11
     static uint8_t    wait_for_space;                                           // flag: wait for data bit space
12
@@ -705,7 +705,7 @@
13
     {                                                                           // yes... wait for application to get data
14
         if (! irmp_start_bit_detected)                                          // start bit detected?
15
         {                                                                       // no...
16
-            if (!(IRMP_PIN & (1 << IRMP_BIT)))                                  // receiving burst?
17
+            if (!data)                                                          // receiving burst?
18
             {                                                                   // yes...
19
                 irmp_pulse_time++;                                              // increment counter
20
             }
21
@@ -734,7 +734,7 @@
22
         {
23
             if (wait_for_start_space)                                           // we have received start bit and are counting the dark...
24
             {
25
-                if (IRMP_PIN & (1 << IRMP_BIT))                                 // still dark?
26
+                if (data)                                                       // still dark?
27
                 {                                                               // yes
28
                     irmp_pause_time++;                                          // increment counter
29
30
@@ -1111,7 +1111,7 @@
31
             {                                                                   // counting the dark....
32
                 uint8_t got_light = FALSE;
33
34
-                if (IRMP_PIN & (1 << IRMP_BIT))                                 // still dark?
35
+                if (data)                                                       // still dark?
36
                 {                                                               // yes...
37
                     if (irmp_bit == complete_len && stop_bit == 1)
38
                     {
39
@@ -1368,7 +1368,7 @@
40
             }
41
             else
42
             {                                                                   // counting the light (pulse)...
43
-                if (!(IRMP_PIN & (1 << IRMP_BIT)))                              // still light?
44
+                if (!data)                                                      // still light?
45
                 {                                                               // yes...
46
                     irmp_pulse_time++;                                          // increment counter
47
                 }
48
diff -rBuw Irmp.org/irmp.h Irmp/irmp.h
49
--- Irmp.org/irmp.h     2010-03-05 11:24:18.000000000 +0100
50
+++ Irmp/irmp.h 2010-03-12 17:40:14.600896408 +0100
51
@@ -194,7 +194,7 @@
52
  *  ISR routine
53
  *  @details  ISR routine, called 10000 times per second
54
  */
55
-extern void                           irmp_ISR (void);
56
+extern void                           irmp_ISR (const uint8_t);
57
58
 #ifdef __cplusplus
59
 }

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

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

Das kann er dann im Makro direkt tun.

Danke für die Anregung,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Eine neue Version von IRMP ist unter

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

verfügbar.

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

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

Gruß,

Frank

von Markus B. (mb27)


Lesenswert?

Hallo,

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

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

auf meinem LCD ausgebe. Benutze das Programm von Peter Fleury.
So bekomme ich immer eine Fehlermeldung:
1
if (irmp_get_data (&irmp_data))
2
    {
3
    /* clear display and home cursor */
4
        lcd_clrscr();
5
        // ir signal decoded, do something here...
6
7
        // irmp_data.protocol is the protocol, see irmp.h
8
    lcd_puts(irmp_data.protocol);
9
        // irmp_data.address is the address/manufacturer code of ir sender
10
        lcd_puts(irmp_data.address);
11
        // irmp_data.command is the command code
12
        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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

lcd_puts möchte einen C-String, Du übergibst aber Zahlen. Das geht 
nicht. Also musst Du vorher die Zahlen in Strings - z.B. mit itoa() - 
umwandeln, z.B. so:
1
#include <stdlib.h>
2
...
3
4
main ()
5
{
6
   char protocol[10];
7
   char address[10];
8
   char command[10];
9
10
...
11
   if (irmp_get_data (&irmp_data))
12
   {
13
        itoa(irmp_data.protocol, protocol, 10);
14
        itoa(irmp_data.address, address, 10);
15
        itoa(irmp_data.command, command, 10);
16
17
        lcd_clrscr();
18
        lcd_puts(protocol);
19
        lcd_puts (" ");
20
        lcd_puts(address);
21
        lcd_puts (" ");
22
        lcd_puts(command);
23
   }

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

von Michael M. (Gast)


Lesenswert?

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

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

von Markus B. (mb27)


Lesenswert?

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

von Michael M. (Gast)


Lesenswert?

:*-(

von Chris (Gast)


Lesenswert?

Hallo,

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

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

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

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Chris schrieb:

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

Welche Protokolle werden von IRMP erkannt, welche nicht?

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

Ja, solange er hinreichend genau geht.

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

Das sieht eigentlich ganz gut aus...

Gruß,

Frank

von Werner B. (werner-b)


Lesenswert?

Ich musste bei lsb in irsnd.c lange grübeln um herauszufinden was da 
erreicht werden soll (IMHO ist der Name auch irreführend).
Darum habe ich mir auch gleich eine (wenigstens für mich) leichter 
vertändliche Version gebastelt. Die hat auch ein besseres 
Laufzeitverhalten da für jedes Bit nur zwei mal geschoben wird. Die 
Bitschiebe-Orgie entfällt ;-).
1
static uint16_t
2
lsb (uint16_t x, uint8_t len)
3
{
4
#if 0
5
    uint16_t    xx = 0;
6
    uint8_t     i;
7
8
    for (i = 0; i < len; i++)
9
    {
10
        if (x & (1<<i))
11
        {
12
            xx |= (1<<(len - i - 1));
13
        }
14
    }
15
    return xx;
16
#else
17
    uint16_t    xx = 0;
18
19
    while(len)
20
    {
21
        xx <<= 1;
22
        if (x & 1)
23
        {
24
            xx |= 1;
25
        }
26
        x >>= 1;
27
        len--;
28
    }
29
    return xx;
30
#endif
31
}

von Chris (Gast)


Lesenswert?

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

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

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

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

Dein Denkfehler liegt wohl hier:

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

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

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

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

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

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

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

Wow, Deine Version spart wirklich einiges ein!

Vielen Dank, werde ich so übernehmen.

Gruß,

Frank

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

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

Vorab schon mal eine neue Version von IRMP unter

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

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

Und noch eine Neuigkeit:

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

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

IRSND ist nun auch angepasst, Änderungen:

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

Download:

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

Gruß,

Frank

von Werner B. (werner-b)


Lesenswert?

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

z.B. bitsreverse

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Werner B. schrieb:

> z.B. bitsreverse

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

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

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

Gruß,

Frank

von DiPi (Gast)


Lesenswert?

In der Anwendung beim CRC wird diese Prozedur "reflect" genannt...

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

Gruß,

Frank

von Peter K. (peko)


Angehängte Dateien:

Lesenswert?

Hallo Frank,

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

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

Soviel für heute...

-Peter

von Peter K. (peko)


Lesenswert?

Hallo Frank,

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

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

-Peter

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi Peter,

Peter K. schrieb:

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

Siehe IRMP-Artikel:

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

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Peter K. schrieb:

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

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

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

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

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

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

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

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

Neue Version von IRMP unter

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

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Nun gibt es auch eine neue Version von IRSND.

Download:

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

Änderungen:

* Neues Protokoll: Nubert

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

* Korrektur der Pausen zwischen Wiederholungen von Frames

Gruß,

Frank

von Klaus L. (kllei)


Angehängte Dateien:

Lesenswert?

Hallo,

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

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

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

Viele Grüße und viel Spaß,
Klaus

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

von Werner B. (werner-b)


Lesenswert?

@Klaus Leidinger,

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

Gruß
Werner

von Klaus L. (kllei)


Lesenswert?

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

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

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

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

Danke für Dein Feedback.

Viele Grüße,
Klaus

von eku (Gast)


Lesenswert?

Hallo Frank!

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

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi eku,

eku schrieb:

> Warum verwendest Du keine Variadic Macros

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

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

Gruß,

Frank

von eku (Gast)


Lesenswert?

Hallo Frank!

Zwei meiner Fernbedienungen können nicht dekodiert werden:

 Nokia Dbox2
 Siemens Gigaset M740AV

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

von Micha (Gast)


Lesenswert?

Hallo Frank,

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

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

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

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

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Micha schrieb:

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

Ja, ist wohl sinnvoll. Mache ich.

Gruß,

Frank

von Christoph (Gast)


Lesenswert?

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

von Peter K. (peko)


Angehängte Dateien:

Lesenswert?

Hallo Frank,

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

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

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

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

-Peter

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Peter K. schrieb:

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

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

Der "Mode 0" ist hier dokumentiert:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

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

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

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

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

Gruß,

Frank

von eku (Gast)


Lesenswert?

Hallo Frank!


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

LIRCD kennt die Siemens Gigaset Fernbedienung als

  bits           8
  eps            30
  aeps          100

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

von Peter K. (peko)


Lesenswert?

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

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

-Peter

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Peter,

Peter K. schrieb:

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

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

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi eku,

eku schrieb:

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

Ich hatte Dir darauf schon mal geantwortet:

  Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"

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

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

IRMP ist jetzt auch im SVN auf mikrocontroller.net:

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

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

Gruß,

Frank

von Andreas S. (andreas) (Admin) Benutzerseite


Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

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

Gruß,

Frank

von M. K. (kichi)


Lesenswert?

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

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

von Vlad T. (vlad_tepesch)


Lesenswert?

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

von Simon K. (simon) Benutzerseite


Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

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

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi Vlad,

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

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

Gruß,

Frank

von Vlad T. (vlad_tepesch)


Lesenswert?

Um nicht noch mehr OT zu produzieren antworte ich dir privat

von Jens C. (Gast)


Lesenswert?

Hallo zusammen,

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

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

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

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

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

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

Oder habe ich da einen falschen Denkansatz...

Gruß Jens

von Di P. (drpepper) Benutzerseite


Lesenswert?

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

von Jens C. (Gast)


Lesenswert?

@ Di Pi

Guten Morgen,

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

Also, das/mein Problem muss woanders liegen

Gruß Jens

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Jens,

Jens C. schrieb:

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

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

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

Gruß,

Frank

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

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

von Jens C. (Gast)


Lesenswert?

Hallo Frank,

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

Schönen Tag noch
Gruß Jens

von Simon K. (simon) Benutzerseite


Lesenswert?

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

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

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

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

von ... .. (docean) Benutzerseite


Lesenswert?

1
#include "irmp.c"

gefunden in main.c im Codevison Teil.

Warum das ?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

... ... schrieb:
>
1
> #include "irmp.c"
2
>
>
> 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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

Schauen wir mal in die Liste der Dateien im SVN:

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

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

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

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

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

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

http://www.mikrocontroller.net/topic/156661#1482557

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

von Klaus L. (kllei)


Lesenswert?

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

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

Viele Grüße,
Klaus

von Simon K. (simon) Benutzerseite


Lesenswert?

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

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

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

Nö habe ich nicht.

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

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

>>> Aber wie immer bei Simon K.: Er liest nur oberflächlich, stromert in
>>> vielen Threads herum, lässt seinen Mecker los und verschwindet dann
>>> wieder für Wochen auf Nimmerwiedersehen. Sowas kann ich nicht ernst
>>> nehmen.
>>
>> Was lässt dich das annehmen?
>
> Weil es mir schon mal sauer aufgestoßen ist, nämlich im
> WordClock-Thread:
>
> http://www.mikrocontroller.net/topic/156661#1482557
>
> 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.

von Vlad T. (vlad_tepesch)


Lesenswert?

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

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

von Hugo P. (portisch)


Lesenswert?

Hi,

jetzt muss ich wegen der Logging Funtkion einmal nachfragen:
1
                if (s_ctr > c_endBits)
2
                {                                                       // if stop condition (200 sequenced ones) meets, output on uart
3
                    uint16_t i;
4
5
                    for (i = 0; i < c_startcycles; ++i)
6
                    {
7
                        irmp_uart_putc ('0');                                   // the ignored starting zeros
8
                    }

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

Gruß,

Frank

von Frank L. (florenzen)


Lesenswert?

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

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

Gruß
f

von Florian (Gast)


Lesenswert?

Hallo Frank,

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

Gruß

von Vlad T. (vlad_tepesch)


Lesenswert?

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

von Frank L. (florenzen)


Lesenswert?

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

Gruß
f

von Florian (Gast)


Lesenswert?

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

von Klaus L. (kllei)


Lesenswert?

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

Hi Frank,

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

Danke für eine Info,
Klaus

von Frank L. (florenzen)


Lesenswert?

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

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

HtH.

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

Gruß
f

von Micha (Gast)


Lesenswert?

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

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

von Abdul K. (ehydra) Benutzerseite


Lesenswert?

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

von Micha (Gast)


Lesenswert?

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

von Frank L. (florenzen)


Lesenswert?

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

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

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

Gruß
f

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

Der Aufbau ist:

4 Startbits + 18 Datenbits.

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

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

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

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

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

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Version 1.1 von IRMP ist verfügbar:

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

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

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

Gruß,

Frank

von Micha (Gast)


Lesenswert?

@ Frank M.
Würde es sich bzgl. deiner Änderung von eben 
http://www.mikrocontroller.net/wikisoftware/index.php?title=IRMP&diff=46141&oldid=prev 
nicht anbieten ein enum zu verwenden, oder gibt es bestimmte Gründe 
warum du das nicht machst?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

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

Gruß,

Frank

von Micha (Gast)


Lesenswert?

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

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

Siehe: 
http://openbook.galileocomputing.de/c_von_a_bis_z/015_c_strukturen_010.htm

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Micha schrieb:

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

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

> Siehe:
> http://openbook.galileocomputing.de/c_von_a_bis_z/015_c_strukturen_010.htm

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

Gruß,

Frank

von Micha (Gast)


Lesenswert?

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

von Micha (Gast)


Lesenswert?

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

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

Beispiel A:
1
enum zahl { NU_LL, EINS, ZWEI, DREI, VIER};
2
3
uint8_t
4
funktion (enum zahl xx)
5
{
6
  xx >>= 4;
7
  return xx;
8
}

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

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

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

Beispiel B:
1
enum zahl { NU_LL = -2, EINS, ZWEI, DREI, VIER};
2
3
uint8_t
4
funktion (enum zahl xx)
5
{
6
  xx >>= 4;
7
  return xx;
8
}

Jetzt braucht die Beispiel-Funktion wesentlich mehr Speicherplatz:
1
00000046 <funktion>:
2
uint8_t
3
funktion (enum zahl xx)
4
{
5
  xx >>= 4;
6
  return xx;
7
}
8
  46:  85 95         asr  r24
9
  48:  85 95         asr  r24
10
  4a:  85 95         asr  r24
11
  4c:  85 95         asr  r24
12
  4e:  08 95         ret

EDIT:

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

Beispiel C:
1
enum zahl { NU_LL = 300, EINS, ZWEI, DREI, VIER};
2
3
uint8_t
4
funktion (enum zahl xx)
5
{
6
  46:  24 e0         ldi  r18, 0x04  ; 4
7
  48:  96 95         lsr  r25
8
  4a:  87 95         ror  r24
9
  4c:  2a 95         dec  r18
10
  4e:  e1 f7         brne  .-8        ; 0x48 <funktion+0x2>
11
  xx >>= 4;
12
  return xx;
13
}
14
  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

von Frank L. (florenzen)


Lesenswert?

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

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

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


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


Gruß,

f

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Frank Lorenzen schrieb:

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

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

Gruß,

Frank

von Frank L. (florenzen)


Lesenswert?

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

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

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Frank Lorenzen schrieb:

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

Freut mich.

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

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

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

Download:

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

Viel Spaß,

Frank

von J. K. (kum)


Angehängte Dateien:

Lesenswert?

Hallo Zusammen,

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

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

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

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

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

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

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

Gruß, Kum

von J. K. (kum)


Lesenswert?

Hallo noch mal,

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

Viele Grüße, Kum

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

J. Kum schrieb:

> AVR-GCC, Atmega8, lfuse0xe2, hfuse0xd9

Habe die Werte gerade mal in den Fuse-Calculator

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

eingegeben.

2 MHz ist ein bisschen zu wenig, oder?

Gruß,

Frank

von Frank L. (florenzen)


Lesenswert?

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

Gruß,
f

von J. K. (kum)


Lesenswert?

Lieber Frank, Lieber Frank,

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

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

Viele Grüße, Kum

von Klaus L. (kllei)


Lesenswert?

Hallo Frank L. und B&O Anwender,

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

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

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

Viele Grüße,
Klaus

von siegmar (Gast)


Lesenswert?

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


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

Noch einen schönen Abend
Gruß
Siegmar

von J. K. (kum)


Lesenswert?

Hallo Zusammen,

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

#define IRSND_SUPPORT_APPLE_PROTOCOL

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

Vielen Dank, Kum

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

J. Kum schrieb:

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

Tut mir leid, das hat historische Gründe:

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

Gruß,

Frank

von J. K. (kum)


Lesenswert?

Frank M. schrieb:

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

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

Vielen lieben Dank für dein Engagement.

Viele Grüße, Kum

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

J. Kum schrieb:

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

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

Wie bisher:
1
        case IRMP_NEC_PROTOCOL:
2
        {
3
           ...
4
        }

Darunter einfügen (also noch vor dem #endif:
1
        case IRMP_APPLE_PROTOCOL:
2
        {
3
            irsnd_protocol = IRMP_NEC_PROTOCOL; // APPLE protocol is NEC with fix bitmask instead of inverted command
4
5
            address = bitsrevervse (irmp_data_p->address, NEC_ADDRESS_LEN);
6
            command = bitsrevervse (irmp_data_p->command, NEC_COMMAND_LEN);
7
8
            irsnd_buffer[0] = (address & 0xFF00) >> 8;                                                          // AAAAAAAA
9
            irsnd_buffer[1] = (address & 0x00FF);                                                               // AAAAAAAA
10
            irsnd_buffer[2] = (command & 0xFF00) >> 8;                                                          // CCCCCCCC
11
            irsnd_buffer[3] = 0x8B;                                                                             // 10001011
12
            irsnd_busy      = TRUE;
13
            break;
14
        }

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

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Neue Version von IRSND im Downloadbereich:

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

Änderungen:

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

Viel Spaß,

Frank

von Patrick H. (patrickhh)


Angehängte Dateien:

Lesenswert?

Hallo Frank,

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

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

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


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


Gruß

PatrickHH

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Patrick,

Patrick Hh schrieb:

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

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

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

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

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

Gruß,

Frank

von Patrick H. (patrickhh)


Lesenswert?

Das ging ja schnell!

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

Dann viel Erfolg. Mal sehen ob es klappt.

Schönen Abend noch...


PatrickHH

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Frank M. schrieb:

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

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

@Patrick:
Bevor ich nun ein neues Release mache, würde ich das gerne einmal von 
Dir testen lassen, deshalb hänge ich hier nur mal die geänderten Sources 
dran, bevor ich ein neues Download-Paket zusammenstelle.

Wäre auch nicht schlecht zu wissen, wie IRMP auf längere Tastendrücke 
reagiert, eventuell muss ich da noch nacharbeiten. Hilfreich wäre da ein 
Scan mit länger gedrückter Taste - aber nicht zu lang, da sonst der 
Log-Buffer überläuft.

Das Grundig-Protokoll hat einiges gemeinsam mit RC5. Ich werde mal 
schauen, ob ich da noch einiges an gemeinsamen Code für RC5 und Grundig 
zusammenfassen kann, um noch etwas an Flash-Speicher einzusparen.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Lesenswert?

Sorry, Anhang vergessen.

von Patrick H. (patrickhh)


Lesenswert?

Super,

ich werde es heute Vormittag mal testen (Jetzt ist es schon zu spät).

Eine andere Frage hätte ich da auch noch. Ist es möglich den Controller, 
wenn er gerade nichts Empfängt, schlafen zu legen? Ich denke da an den 
externen Interrupt. Wenn der TSOP ein Signal bekommt, dann erwacht der 
Controller und macht dann seine IR-Erkennung.
Die Funktion währe für den Batterie/Akku Betrieb sehr von Vorteil.
Denn jetzt ist der Sromverbrauch schon bei 15mA.

Wenn dies Funktionieren würde, was muß ich dann im Programm hinzu fügen. 
Leider hab ich es nicht so mit der C Programmierung (mache lieber .asm)


Gruß

PatrickHH

von Patrick H. (patrickhh)


Angehängte Dateien:

Lesenswert?

Hallo Frank,

es Fuktioniert! Codes werden Zuverlässig erkannt. Wenn eine Taste länger 
gedrückt wird, dann wird der Code erneut zurückgegeben. Das Repetition 
Flag wird dann aber nicht gesetzt.
Ich habe nochmal ein Scan gemacht, wo ich die Taste etwas länger 
gedrückt habe.

Bezüglich Repetition Flag und SIRC:
Bei mir wird bei einem längeren Tastendruck der Code nur einmal 
Ausgegeben. Auch wenn ich eine Taste länger drücke. Ich bekomme keine 
Wiederholung! Ist das so gewollt?
Da ich ja schon mal mit dem Logging beschäftigt war, habe ich auch noch 
von meiner SonyFB einige Scans gemacht.

Danke nochmal und Gruß


PatrickHH

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Patrick,

Patrick Hh schrieb:

> Eine andere Frage hätte ich da auch noch. Ist es möglich den Controller,
> wenn er gerade nichts Empfängt, schlafen zu legen?

Ja, wäre möglich.

> Die Funktion währe für den Batterie/Akku Betrieb sehr von Vorteil.
> Denn jetzt ist der Sromverbrauch schon bei 15mA.

Das Problem ist aber, dass der TSOP allein schon permanent 5mA zieht. 
Und den kannst Du nicht "schlafen legen".

> Wenn dies Funktionieren würde, was muß ich dann im Programm hinzu fügen.
> Leider hab ich es nicht so mit der C Programmierung (mache lieber .asm)

Muss ich mir erstmal selbst anschauen, ich habe mich bisher damit noch 
nicht beschäftigt.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Patrick Hh schrieb:

> es Fuktioniert! Codes werden Zuverlässig erkannt.

Freut mich :-)

> Wenn eine Taste länger
> gedrückt wird, dann wird der Code erneut zurückgegeben. Das Repetition
> Flag wird dann aber nicht gesetzt.

Hatte ich befürchtet. Aus Deinen Scans ging das nämlich nicht hervor.

> Ich habe nochmal ein Scan gemacht, wo ich die Taste etwas länger
> gedrückt habe.

Prima, werde ich mir anschauen.

> Bezüglich Repetition Flag und SIRC:
> Bei mir wird bei einem längeren Tastendruck der Code nur einmal
> Ausgegeben. Auch wenn ich eine Taste länger drücke. Ich bekomme keine
> Wiederholung! Ist das so gewollt?

Nein, aber ich muss zugeben, dass ich das mangels Sony-FB auch niemals 
austesten konnte.

> Da ich ja schon mal mit dem Logging beschäftigt war, habe ich auch noch
> von meiner SonyFB einige Scans gemacht.

Sehr schön, dann bekomme ich das dann wohl auch für SIRCs endlich mal 
richtig gelöst.

Gruß und Dank,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Patrick Hh schrieb:

> es Fuktioniert!

Eins vergaß ich noch zu fragen: mit welchem IR-Empfänger hast Du die 
Signale aufgenommmen? In der Grundig-Doku las ich was von 485kHz, das 
ist genaz schön viel für einen "normalen" TSOP.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Patrick Hh schrieb:

> Wenn eine Taste länger
> gedrückt wird, dann wird der Code erneut zurückgegeben. Das Repetition
> Flag wird dann aber nicht gesetzt.

Ich habe gerade Deine Scans mit

./irmp < IR-Data/Grundig_TP715_lange.txt |less

unter Linux getestet.

Da bei längerem Drücken der Scan-Buffer irgendwann überläuft, geht der 
Scan zwar nach 3 Frames einer jeden Taste voll in die Hose, aber irmp 
setzt bei mir trotzdem das Repetition-Flag beim zweiten Frame:

# 1 lange (wird in IRMP als 11 Dezimal ausgewertet)
protcol = 15, address = 0x0000, code = 0x0011, flags = 0x00
protcol = 15, address = 0x0000, code = 0x0011, flags = 0x01
-------------------------------------------------------------------
# 2 lange (wird in IRMP als 12 Dezimal ausgewertet)
protcol = 15, address = 0x0000, code = 0x0012, flags = 0x00
protcol = 15, address = 0x0000, code = 0x0012, flags = 0x01
-------------------------------------------------------------------
# 0 ganz lange (wird in IRMP als 10 Dezimal ausgewertet)
protcol = 15, address = 0x0000, code = 0x0010, flags = 0x00
protcol = 15, address = 0x0000, code = 0x0010, flags = 0x01

Kannst Du das nochmal überprüfen?

Gruß,

Frank

von Patrick H. (patrickhh)


Lesenswert?

Hi Frank,

also ich benutze den TSOP mit 38KHz. Mit 36KHz habe ich es eben auch 
noch mal getestet -> Funktioniert auch.

Ich habe auch nochmal den langen Tastendruck getestet, aber ich bekomme 
das Flag nicht gesetzt. Hoffe es liegt nicht an meinem Programm. Ich 
habs (noch) nicht so mit der "C" Programmierung.
Ich lasse mir den Code und das Flag (wie im Artikel beschrieben) via 
RS232 (danke an Klaus Leidinger) senden. Eigentlich nicht viel.

> Das Problem ist aber, dass der TSOP allein schon permanent 5mA zieht.
> Und den kannst Du nicht "schlafen legen".

Mein TSOP verbraucht im Ruhezustand nur ca. 1mA!


Gruß

PatrickHH

von Tishima (Gast)


Lesenswert?

Patrick Hh schrieb:
> Bezüglich Repetition Flag und SIRC:
> Bei mir wird bei einem längeren Tastendruck der Code nur einmal
> Ausgegeben. Auch wenn ich eine Taste länger drücke. Ich bekomme keine
> Wiederholung! Ist das so gewollt?
> Da ich ja schon mal mit dem Logging beschäftigt war, habe ich auch noch
> von meiner SonyFB einige Scans gemacht.

Hallo!

Ich beschaeftige mich zur Zeit auch mit dem IRMP Code.
Das Phänomen mit dem SIRC Protocoll kann ich auch bei mir beobachten, 
und der Samsung Empfang verhält sich genauso, es werden keine neuen 
Codes bei langem Tastendruck ausgewertet.

Scans kann ich leider nicht machen da aus unerklärlichen gründen die 
eingebauten UART Funktionen bei mir nicht funktionieren wollen, ich zeig 
die empfangenen Bytes mit der UART Routine von Peter Flury an.


mfg,
Bjoern

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Tishima schrieb:

> Ich beschaeftige mich zur Zeit auch mit dem IRMP Code.
> Das Phänomen mit dem SIRC Protocoll kann ich auch bei mir beobachten,
> und der Samsung Empfang verhält sich genauso, es werden keine neuen
> Codes bei langem Tastendruck ausgewertet.

Das Problem mit dem SIRCs-Code habe ich dank Patricks Scan-Datei 
reproduzieren können. Sony-FBs senden bei jedem (kurzem) Tastendruck 2 
bis 3 Wiederholungen. IRMP erkennt aber auch die vierte, fünfte usw. 
Wiederholung als Low-Level-Wiederholung statt als langen Tastendruck und 
unterdrückt diese dann.

In manchen SIRCs-Dokus steht, dass jeder Frame 2mal (in anderen Dokus 
steht 3mal) automatisch wiederholt wird.

Jetzt habe ich ein Problem: Patrick hat 3 Tasten lange gedrückt.

Taste A: 8 Frames aufgezeichnet
Taste B: 9 Frames aufgezeichnet
Taste C: 9 Frames aufgezeichnet

Wie habe ich das nun zu verstehen?

Möglichkeit 1:

Taste A: 1 Frame + 1 automatische Wiederholung - das ganze 4 mal?
Taste B: 1 Frame + 2 automatische Wiederholungen - das ganze 3 mal?
Taste C: 1 Frame + 2 automatische Wiederholungen - das ganze 3 mal?

Warum wiederholt die FB bei Taste A jeden Tastendruck nur 2mal, bei den 
Tasten B und C dreimal? Das widerspricht sich.

Möglichkeit 2:

Taste A: 1 Frame + 1 automatische Wiederholung + 6 Wiederholungen wegen 
langer Taste

Taste B: 1 Frame + 1 automatische Wiederholung + 7 Wiederholungen wegen 
langer Taste

Taste C: 1 Frame + 1 automatische Wiederholung + 7 Wiederholungen wegen 
langer Taste

Das hieße dann: Der erste Frame wird automatisch wiederholt, alle 
weiteren geben die Länge des Tastendrucks wieder und werden daher nicht 
automatisch 2- bzw. 3-fach gesendet...

Ich tendiere zu Möglichkeit 2, habe leider nichts spezielles darüber 
gefunden, wie lange Tastendrücke codiert werden.

Dein Problem mit der Samsung-FB scheint ähnlich gelagert zu sein, werde 
ich mir näher anschauen.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi Patrick,

Patrick Hh schrieb:

> also ich benutze den TSOP mit 38KHz. Mit 36KHz habe ich es eben auch
> noch mal getestet -> Funktioniert auch.

Okay, dann habe ich das mit den 485kHz falsch interpretiert.

> Ich habe auch nochmal den langen Tastendruck getestet, aber ich bekomme
> das Flag nicht gesetzt. Hoffe es liegt nicht an meinem Programm. Ich
> habs (noch) nicht so mit der "C" Programmierung.

Gut, dann muss ich nochmal den Source prüfen. Danke für Deine 
Bestätigung.

> Mein TSOP verbraucht im Ruhezustand nur ca. 1mA!

Laut Datenblatt zieht der 5mA. Nun gut, da scheint der Wert im 
Datenblatt ein Maximalwert zu sein.

Gruß,

Frank

von Patrick H. (patrickhh)


Lesenswert?

Hallo,

was ich noch in meinen Unterlagen zu SIRC gefunden habe ist:

"Die Übertragung muss nach einer Pause noch mindestens zweimal (fünfmal 
bei Camcorder) wiederholt werden, sonst wird von einem Übertragunsfehler 
ausgegangen."

Das hört sich so an, als ob die Wiederholungen von Gerät zu Gerät 
unterschiedlich sein können.

Vielleicht hilft die Info...


Gruß

PatrickHH

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Patrick Hh schrieb:

> "Die Übertragung muss nach einer Pause noch mindestens zweimal (fünfmal
> bei Camcorder) wiederholt werden, sonst wird von einem Übertragunsfehler
> ausgegangen."

"Zweimalige Wiederholung" heisst 3x derselbe Frame, okay.

Aber was passiert bei längerem Tastendruck? Habe ich dann N x 3 Frames?
Oder 3 Frames + N weitere?

Gegen N x 3 Frames spricht, dass die erste Taste aus Deinem Scan exakt 8 
Frames erzeugt hat. Das ist nicht durch 3 teilbar.

> Das hört sich so an, als ob die Wiederholungen von Gerät zu Gerät
> unterschiedlich sein können.

Noch schlimmer. Wie lange unterdrücke ich also Wiederholungen, bevor ich 
sie wieder an die Applikation mit gesetztem Repetition-Bit weitergebe?

Ich habe mir jetzt nochmal sämtliche Sony-FB-Scans im Verzeichnis 
IR-Data angeschaut, die ich von verschiedenen Leuten bekommen habe.

Dort habe ich folgende Häufigkeiten finden können:

49 x 3 Frames
65 x 4 Frames
18 x 5 Frames
 2 x 6 Frames
 4 x 7 Frames
 2 x 8 Frames
 3 x 9 Frames

Auffallend ist:

1. Es werden mindestens 3 Frames gesandt.

2. Danach kann jede x-beliebige Anzahl von Frames erfolgen, es gibt
   keine ganzzahligen Vielfachen von 2 oder 3 Frames.

Ergo werde ich den Code derart ändern, dass die erste und zweite 
Wiederholung des Original-Frames ignoriert wird und anschließend jede 
weitere Wiederholung des Frames (innerhalb des Zeitrahmens natürlich) 
mit gesetztem Repetition-Bit an die Applikation wieder zurückgemeldet 
wird.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Tishima schrieb:

> Das Phänomen mit dem SIRC Protocoll kann ich auch bei mir beobachten,
> und der Samsung Empfang verhält sich genauso, es werden keine neuen
> Codes bei langem Tastendruck ausgewertet.

Frage: geht es um SAMSUNG oder SAMSUNG32?

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Eine neue Version von IRMP ist unter

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

verfügbar.

Änderungen:

1) Neues Protokoll: Grundig

2) Behandlung von automatischen Frame-Wiederholungen beim SIRCS-,
   SAMSUNG32- und NUBERT-Protokoll verbessert.

Zu Punkt 2:

Beim SIRCS-Protokoll werden nun bei Frame-Wiederholungen nur noch der 
zweite und der dritte Frame ignoriert, alle weiteren Wiederholungen 
werden als langer Tastendruck gewertet und das entsprechende 
Repetition-Flag gesetzt.

Bei SAMSUNG32 und NUBERT wird jeder 2. Wiederholungsframe ignoriert, 
weil hier wohl immer 2 Frames gesendet werden. Ein dritter, fünfter usw. 
Frame wird als langer Tastendruck gewertet und das entsprechende 
Repetition-Flag gesetzt.

Viel Spaß,

Frank

P.S.

@Patrick:

Da bei meinen Tests mit Grundig einwandfrei das Repetition-Flag gesetzt 
wird, wenn derselbe Frame N-fach wiederholt wird, kann ich das 
Verhalten, was bei Dir auftritt, nicht nachvollziehen. Hilfreich wäre da 
ein Auszug des Sources, den Du zur Ausgabe von irmp_data.flags 
verwendest.

von Tishima (Gast)


Lesenswert?

Ha

Frank M. schrieb:
> Frage: geht es um SAMSUNG oder SAMSUNG32?
>
> Gruß,
>
> Frank

Hallo!

Kann ich jetzt momentan garnicht sagen. Der Ausgabestring ist ja bei 
beiden SAMSUNG im Beispiel Code gleich. An das Protkoll Byte kann ich 
mich garnicht erinnern. Wenn ich meine Universalfernbedienung nochmal 
dazu überedet kriege SAMSUNG Codes auszuspucken, werde ich mal aufs 
Protokoll Byte achten.

gruß,
Bjoern

von Tishima (Gast)


Lesenswert?

Hallo!

So habe eben den neuen Code getestet.

Sirc wird nun sauber bei mir erkannt, jedoch beim Samsung32 Code haut 
ein langer Tastendruck immer noch nicht hin.

gruß,
Bjoern

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Neue Version 1.3.1 von IRMP verfügbar, Download unter

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

Änderungen:

 - Bit-Maske für SAMSUNG32 korrigiert, das niederwertigste Bit wurde 
bisher
   komplett ignoriert

 - Timing-Werte für SAMSUNG32 geändert

Ebenso ist nun die Version 1.3.1 von IRSND verfügbar, Download unter

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

Änderungen:

 - GRUNDIG-Protokoll hinzugefügt

 - Behandlung von Frame-Wiederholungen für SIRCS, SAMSUNG32 und NUBERT
   korrigiert

Viel Spaß,

Frank

von Patrick H. (patrickhh)


Angehängte Dateien:

Lesenswert?

Hi Frank,

> zu: Grundig
also hier mal meine main.c.
Als Compiler nehme ich GCC. Als Controller nehme ich einen Mega8.

Wenn ich eine Taste lange drücke, dann bekomme ich auch nacheinander die 
Codes angezeigt, jedoch ohne das Flag.

> zu: SIRC
Den Code kann ich erst am Wochenende testen. Dann gibts Feedback.


Gruß


Patrick

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Tishima schrieb:

> Sirc wird nun sauber bei mir erkannt,

Prima, freut mich.

> jedoch beim Samsung32 Code haut ein langer Tastendruck immer noch nicht hin.

Was bekommst du stattdessen? N x denselben Befehl? Oder nur 1x?
Und es handelt sich definitiv um SAMSUNG32?

IRMP erkennt lange Tastendrücke bei Protokollen, die nicht explizit 
einen Repetition-Frame oder einen anderen Mechanismus dafür bieten, 
einfach daran, dass die Frame-Wiederholungen innerhalb von 100 msec 
reinkommen.

Um da jetzt weiterzukommen, bräuchte ich einen Scan von Dir. Du sagtest, 
Du benutzt die Fleury-Lib auf dem UART? Lass die mal weg, dann sollte es 
gehen. Der Scan wird mit 9600Baud, 8bit, no parity ausgegeben.

Gruß,

Frank

P.S.
Ich habe gerade eben eine neue Version 1.3.1 hochgeladen, da war sowieso 
noch ein Fehler beim Erkennen des SAMSUNG-Kommando-Codes. Das 
niederwertigste Bit wurde verschlabbert. Dürfte aber keine Änderung bei 
Dir bzgl. langer Tastendrücke bringen.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi Patrick,

Patrick Hh schrieb:

> Wenn ich eine Taste lange drücke, dann bekomme ich auch nacheinander die
> Codes angezeigt, jedoch ohne das Flag.

Bei jeder FB? Oder nur bei Grundig? Wenn es bei jeder FB ist, dann liegt 
die Vermutung nahe, dass in Deiner main-Funktion der Wurm drin ist. 
Schaue ich mir an.

Gruß,

Frank

von Patrick H. (patrickhh)


Lesenswert?

Hi Frank,

> Bei jeder FB? Oder nur bei Grundig? Wenn es bei jeder FB ist, dann liegt
> die Vermutung nahe, dass in Deiner main-Funktion der Wurm drin ist.

Bis jetzt nur bei der Grundig. Bei Anderen z.B. RC5 oder NEC bekomme ich 
beim dauer Drücken das Flag gesetzt.


PatrickHH

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Patrick Hh schrieb:

> Bis jetzt nur bei der Grundig. Bei Anderen z.B. RC5 oder NEC bekomme ich
> beim dauer Drücken das Flag gesetzt.

Hm, dann kann es nicht an der main-Funktion liegen, habe sie mir auch 
angeschaut, sieht alles okay aus.

Bin nun etwas ratlos. Warum klappt das bei mir mit den Scans und bei Dir 
nicht?

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Patrick Hh schrieb:

> Bis jetzt nur bei der Grundig. Bei Anderen z.B. RC5 oder NEC bekomme ich
> beim dauer Drücken das Flag gesetzt.

Ich habe mir nochmal die Doku zum Grundig-Protokoll angeschaut. Dort 
haben die Info-Frames, die bei längerem Tastendruck wiederholt werden, 
einen Abstand von 117,76ms.

In der Scan-Datei müssten die Info-Frames bei einem so großem Abstand 
eigentlich alle in einer separaten Zeile stehen. Tun sie aber nicht, sie 
sind alle in einer Zeile.

Meine Frage: Hast Du da vielleicht mittels Editor etwaige Mehrfachzeilen 
zu einer einzigen Zeile zusammenkopiert - zum Beispiel zwecks 
Übersichtlichkeit? In den Scans haben die Info-Frames nämlich lediglich 
einen Abstand von 2ms. Dieser Zeitrahmen liegt weit unterhalb der 100ms, 
die ich zur Erkennung von langen Tastendrücken als obere Grenze 
definiert habe. Das würde auch erklären, warum bei der Auswertung der 
Scans das Repetition-Bit auch gesetzt wird.

Meine Bitte: Ändere mal in irmp.c die Zeile
1
#define IRMP_REPETITION_TIME  (uint16_t)(F_INTERRUPTS * 100.0e-3 + 0.5)  // autodetect key repetition within 100 msec

in
1
#define IRMP_REPETITION_TIME  (uint16_t)(F_INTERRUPTS * 150.0e-3 + 0.5)  // autodetect key repetition within 150 msec

ab und teste die Grundig-FB nochmals mit langen Tastendrücken.

Die 100ms sind als Grenze wohl zu knapp, denn laut Grundig-Doku sind wir 
mit 117ms knapp drunter. Fragt sich nur, warum in den Scans nur 2ms als 
Pausen zwischen den Frames zu sehen sind....

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Bjoern,

Tishima schrieb:

> [...] jedoch beim Samsung32 Code haut
> ein langer Tastendruck immer noch nicht hin.

Für Dich gilt dasselbe: Ändere bitte mal die 100 msec in 150 msec, siehe 
Code im vorherigen Posting. Der Grund, warum beim SAMSUNG32-Protokoll 
keine langen Tastendrücke erkannt werden, könnte derselbe wie bei der 
Grundig-FB sein.

Gruß,

Frank

von Patrick H. (patrickhh)


Lesenswert?

Hi Frank,

> Meine Frage: Hast Du da vielleicht mittels Editor etwaige Mehrfachzeilen
> zu einer einzigen Zeile zusammenkopiert - zum Beispiel zwecks
> Übersichtlichkeit?

Ich habe, glaube ich, bei den Scan-Daten alles in eine Zeile gemacht. 
Denn mein Terminal Programm setzt nach jeder Übertragung ein "CR/LF" am 
Ende. Das habe ich eigentlich nur entfernt. Vielleicht lag es ja daran.
Kann am Wochenende ja nochmal ein anderes Terminal Programmm benutzen 
und nochmals einen Scan machen.

> Meine Bitte: Ändere mal in irmp.c die Zeile......
Werde ich testen. Wird aber erst am Wochenende was.

Gruß

PatrickHH

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi Patrick,

Patrick Hh schrieb:

> Ich habe, glaube ich, bei den Scan-Daten alles in eine Zeile gemacht.

Jau, dann hattest Du mich mit der Scan-Datei auf die falsche Fährte 
geführt und ich dachte, 100ms reichen völlig aus ;-)

> Werde ich testen. Wird aber erst am Wochenende was.

Bin mir nun ziemlich sicher, dass es mit der Änderung funktionieren 
wird.

Gruß,

Frank

von Tishima (Gast)


Lesenswert?

Frank M. schrieb:
> Für Dich gilt dasselbe: Ändere bitte mal die 100 msec in 150 msec, siehe
> Code im vorherigen Posting. Der Grund, warum beim SAMSUNG32-Protokoll
> keine langen Tastendrücke erkannt werden, könnte derselbe wie bei der
> Grundig-FB sein.

Hallo!

Habe soeben die neue Version getestet mit ner Phillips 
Universalfernbedienung, der Samsung32 Code wird nun richtig erkannt, 
auch ohne das ich den Wert auf 150 geaendert habe.
Meine Pollin UFB will nun garkeinen SAMSUNG32 Code mehr ausspucken 
obwohl ich mir sicher bin den selben device Code eingeben zu haben, wie 
bei den letzten Tests.
Aber die UFB ist eh der letzte Chinaschrott und wird von mir nicht mehr 
verwendet.

So, ich klink mich hier erstmal aus und bastle mit Eventghost rum um 
meine Software zu steuern die ich benötige.


Viel, Spaß noch....

mfg,
Bjoern

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Tishima schrieb:

> Habe soeben die neue Version getestet mit ner Phillips
> Universalfernbedienung, der Samsung32 Code wird nun richtig erkannt,
> auch ohne das ich den Wert auf 150 geaendert habe.

Freut mich :-)

> So, ich klink mich hier erstmal aus und bastle mit Eventghost rum um
> meine Software zu steuern die ich benötige.

Viel Spaß, ich hoffe, Du erzählst nachher etwas über Dein Projekt, wenn 
es dann fertig ist.

Frank

von Patrick H. (patrickhh)


Lesenswert?

Hi Frank,

ich habe die neue Version getestet:

SIRC funktioniert jetzt auch mit langen Tastendruck. Das Flag wird nun 
auch gesetzt.

Bei Grundig wird nun auch das REPETITION Flag gesetzt, wenn ich die 
REPETITION TIME auf mindestens 120ms setzte. Also stimmen die Werte, die 
im Datenblatt stehen.


Vielen Dank nochmal für deine Unterstützung...


Gruß

PatrickHH

von eku (Gast)


Angehängte Dateien:

Lesenswert?

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

Anbei die Protokolle für Gigaset M740AV (gigaset.txt) ud Nokia D-Box 2 
(dbox.txt). Letztere wird seit der Unterstützung des Grundig-Protokolls 
wechselnd als RC(x) und Grundig erkannt. Die Codes sind aber Müll.

Die Unterstützung sowohl in IRMP als auch in IRSND wäre super!

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi Patrick,

Patrick Hh schrieb:

> SIRC funktioniert jetzt auch mit langen Tastendruck. Das Flag wird nun
> auch gesetzt.

Freut mich.

> Bei Grundig wird nun auch das REPETITION Flag gesetzt, wenn ich die
> REPETITION TIME auf mindestens 120ms setzte. Also stimmen die Werte, die
> im Datenblatt stehen.

Gut. Dann werde ich auf Nummer sicher gehen und die REPETITION TIME fürs 
nächste Release auf 130ms setzen.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:

> Anbei die Protokolle für Gigaset M740AV (gigaset.txt) ud Nokia D-Box 2
> (dbox.txt). Letztere wird seit der Unterstützung des Grundig-Protokolls
> wechselnd als RC(x) und Grundig erkannt. Die Codes sind aber Müll.

Ich habe gerade mal reingeschaut. Das Gigaset-Protokoll scheint auch 
Manchester-codiert zu sein, da sowohl Pulsdauern als auch Pausen in ein- 
und zweifacher Länge vorkommen. Die Zeiten sind sehr knapp, da ist die 
Abtastrate von 10000/sec fast zuwenig. Muss ich mal schauen, dass ich da 
ein System reinbekomme.

Die D-Box scheint eine Abart des Grundig-Protokolls zu verwenden, 
offenbar ist hier einfach das Telegramm länger als 10 Bits, nämlich 16. 
Deshalb steigt der Grundig-Code nach 10 Bits aus und die restlichen 6 
Bits werden als RC5 erkannt, da die verbliebenen Daten-Bits ohne 
Start-Bit so "aussehen" wie RC5. Ich schaue, dass ich die beiden 
Protokolle über eine variable Längenerkennung auseinanderdividiert 
bekomme. Dann sollte die Erkennung sowoh für D-Box als auch für Grundig 
funktionieren.

Gruß,

Frank

von eku (Gast)


Lesenswert?

Frank M. schrieb:
> Ich habe gerade mal reingeschaut. Das Gigaset-Protokoll scheint auch
> Manchester-codiert zu sein, da sowohl Pulsdauern als auch Pausen in ein-
> und zweifacher Länge vorkommen. Die Zeiten sind sehr knapp, da ist die
> Abtastrate von 10000/sec fast zuwenig. Muss ich mal schauen, dass ich da
> ein System reinbekomme.

Laut LIRC Datensatz gelten folgende Parameter:
1
  bits           8
2
  eps            30
3
  aeps          100
4
  one             0     0
5
  zero            0     0
6
  pre_data_bits   24
7
  pre_data       0x10
8
  gap          210000
9
  min_repeat      2
10
  toggle_bit      25

und für doe DBox
[code]
  bits           8
  eps            30
  aeps          100

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

Hilft Dir das?

von eku (Gast)


Lesenswert?

eku schrieb:
> und für doe DBox

kleiner Fehler im Posting
1
name  D-BOX2
2
  bits            8
3
  flags SHIFT_ENC|CONST_LENGTH
4
  eps            10
5
  aeps          300
6
7
  header        510  2520
8
  one           450   550
9
  zero          450   550
10
  pre_data_bits   1
11
  pre_data       0x0
12
  post_data_bits  8
13
  post_data      0xC5
14
  gap          59500
15
  repeat_bit      0

von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Lesenswert?

eku schrieb:

> Anbei die Protokolle für Gigaset M740AV (gigaset.txt) ud Nokia D-Box 2
> (dbox.txt). Letztere wird seit der Unterstützung des Grundig-Protokolls
> wechselnd als RC(x) und Grundig erkannt. Die Codes sind aber Müll.

Ich habe das Nokia-Protokoll in den IRMP integriert. Mein erster 
Eindruck hat sich bestätigt: Das Nokia-Protokoll unterscheidet sich nur 
durch 16 Datenbits (8 Adressbits + 8 Kommandobits) statt 9 Datenbits (0 
Adressbits + 9 Kommandobits) beim Grundig-Protokoll. Das Timing ist 
annähernd gleich.

Anbei die geänderten Sources. Kannst Du das mal testen, auch was lange 
Tastendrücke angeht? Wenn es bei Dir funktioniert, werde ich ein neues 
Release für IRMP erstellen.

Gruß,

Frank

P.S.
An der Gigaset-FB bin ich noch dran.

von eku (Gast)


Lesenswert?

Hallo Frank!

Frank M. schrieb:
> Anbei die geänderten Sources. Kannst Du das mal testen, auch was lange
> Tastendrücke angeht? Wenn es bei Dir funktioniert, werde ich ein neues
> Release für IRMP erstellen.

Die Dekodierung funktioniert nun. Aus Mangel einer Grundig-FB kann ich 
nicht testen, ob diese auch noch geht. Die dekodierten Codes 
unterscheiden sich allerdings von 
http://lirc.sourceforge.net/remotes/nokia/DBOX2. Hat das was zu 
bedeuten?

Mit den Änderungen kann ich irsnd.c nicht länger übersetzen.
1
irmp/irsnd.c: In function 'ir_tx_process':
2
irmp/irsnd.c:526: error: 'SIRCS_REPETITION_CNT' undeclared (first use in this function)
3
irmp/irsnd.c:526: error: (Each undeclared identifier is reported only once
4
irmp/irsnd.c:526: error: for each function it appears in.)
5
irmp/irsnd.c:527: error: 'SIRCS_REPETITION_TIME' undeclared (first use in this function)
6
irmp/irsnd.c:576: error: 'SAMSUNG32_REPETITION_CNT' undeclared (first use in this function)
7
irmp/irsnd.c:577: error: 'SAMSUNG32_REPETITION_TIME' undeclared (first use in this function)
8
irmp/irsnd.c:661: error: 'DENON_REPETITION_CNT' undeclared (first use in this function)
9
irmp/irsnd.c:662: error: 'DENON_REPETITION_TIME' undeclared (first use in this function)
10
irmp/irsnd.c:678: error: 'NUBERT_REPETITION_CNT' undeclared (first use in this function)
11
irmp/irsnd.c:679: error: 'NUBERT_REPETITION_TIME' undeclared (first use in this function)
12
irmp/irsnd.c:713: error: 'GRUNDIG_REPETITION_CNT' undeclared (first use in this function)
13
irmp/irsnd.c:714: error: 'GRUNDIG_REPETITION_TIME' undeclared (first use in this function)

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:

> Die Dekodierung funktioniert nun.

Freut mich!

> Aus Mangel einer Grundig-FB kann ich nicht testen, ob diese
> auch noch geht.

Macht nix, das habe ich bereits mit den mir vorliegenden 
Grundig-Scan-Dateien gemacht. War ein wenig Arbeit, eine vernünftige 
Abbruchbedingung zu finden, um Grundig und Nokia zu unterscheiden, die 
sich tatsächlich nur in der Anzahl der Bits unterscheiden ;-)

> Die dekodierten Codes
> unterscheiden sich allerdings von
> http://lirc.sourceforge.net/remotes/nokia/DBOX2.

Ich weiß nicht, wie lirc die Codes generiert, ich vermute, die haben da 
noch einen weiteren Abstraktionslayer mit drin.

Die Codes, die IRMP ausspuckt, halte ich jedoch für absolut plausibel, 
da Taste 0 = 0x00, Taste 1 = 0x01, .... Taste 9 = 0x09 ist. Ausserdem 
habe ich heute morgen noch eine weitere Nokia-TV-Scan-Datei per Mail von 
einem anderen IRMP-Anwender erhalten, so dass ich da einen Quercheck 
machen konnte. Lediglich die Adresse unterschied sich, passt also alles 
wunderbar.

> Mit den Änderungen kann ich irsnd.c nicht länger übersetzen.

Das liegt daran, dass ich den IRMP-/IRSND-Source in der Zwischenzeit 
weiterbearbeitet und optimiert habe, deshalb hatte ich auch nur die 3 
Dateien zwecks Test hier ins Zip-Archiv gepackt. Mit dem nächsten 
Release gibt es dann wieder einen einheitlichen Stand.

Vielen Dank fürs Feedback,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Neue Version 1.4.0 von IRMP verfügbar, Download unter

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

Änderungen:

 - Neues Protokoll: NOKIA

 - Erkennung von langen Tastendrücken beim Grundig-Protokoll

Ebenso ist nun die Version 1.4.0 von IRSND verfügbar, Download unter

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

Änderungen:

 - NOKIA-Protokoll hinzugefügt

Viel Spaß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:

> Anbei die Protokolle für Gigaset M740AV (gigaset.txt) [...]

Wie gestern schon angedeutet: Die Pulse/Pausen sind arg kurz. Es handelt 
sich um ein 23-bittiges Manchester-Protokoll, wobei jeder Frame einmal 
zusätzlich wiederholt wird. Leider ist die Aufzeichnungsrate von 
10000/sec hier zu niedrig, um eindeutige Werte zu erhalten. Fast jede 
Wiederholung ist nicht identisch mit dem Original-Frame, weil ein Puls 
mehr oder weniger schon das Bit im Frame kippen lässt.

Kannst Du dieselben Scans nochmal mit F_INTERRUPTS 15000 machen? Dann 
sollte die Genauigkeit ausreichen.

Gruß,

Frank

von eku (Gast)


Angehängte Dateien:

Lesenswert?

Frank M. schrieb:
> Kannst Du dieselben Scans nochmal mit F_INTERRUPTS 15000 machen? Dann
> sollte die Genauigkeit ausreichen.

Samplerate 15kHz anbei.

von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Lesenswert?

eku schrieb:

> Samplerate 15kHz anbei.

Vielen Dank, die Datei ist echt brauchbar. Ich habe das Protokoll soweit 
"enschlüsseln" und den IRMP-Source anpassen können. Ich habe mal zum 
Testen die geänderten Sources angehängt.

Leider bleibt noch eine klitzekleine Unklarheit:

In der 10kHz-Datei wurde jeder Frame wiederholt, wobei in der 
Wiederholung immer das 15te Bit invertiert wurde. Dieses Bit hat 
offenbar eine ähnliche Bedeutung wie das Toggle-Bit beim RC5-Protokoll.

In der 15kHz-Datei gibt es diese Frame-Wiederholungen nicht.

Das kann zwei Gründe haben:

  a) Du hast beim 10kHz-Scan die Tasten länger gedrückt. Dann ist das
     15. Bit ein Flag für langen Tastendruck.

oder

  b) Die Wiederholungen wurden wegen der höheren Samplerate
     "verschluckt", d.h. es werden immer (auch bei kurzen
     Tastendrücken) 2 Frames verschickt, wobei das 15. Bit den
     automatischen Wiederholungs-Frame kenntlich macht.

Ich tippe mal auf Fall b).

Aber das lässt sich leicht herausfinden:

Sollten beim angehängten Source auch bei kurzem(!) Tastendruck 
konsequent immer 2 identische Frames erkannt werden und IRMP beim 
zweiten Frame das REPETION-Flag setzen, dann handelt es sich um Fall b) 
und ich muss das im Source noch gesondert behandeln.

Meine Bitte: Kannst Du das bitte testen? Am besten mit F_INTERRUPTS = 
15000. Wenn Du dann noch Lust/Zeit hast, kannst Du das ganze auch mal 
bei F_INTERRUPTS = 10000 testen und eine Aussage über die Erkennungsrate 
bei der niedrigeren Samplerate treffen.

Gruß,

Frank

von eku (Gast)


Lesenswert?

Frank M. schrieb:
> Sollten beim angehängten Source auch bei kurzem(!) Tastendruck
> konsequent immer 2 identische Frames erkannt werden und IRMP beim
> zweiten Frame das REPETION-Flag setzen, dann handelt es sich um Fall b)
> und ich muss das im Source noch gesondert behandeln.
>
> Meine Bitte: Kannst Du das bitte testen? Am besten mit F_INTERRUPTS =
> 15000. Wenn Du dann noch Lust/Zeit hast, kannst Du das ganze auch mal
> bei F_INTERRUPTS = 10000 testen und eine Aussage über die Erkennungsrate
> bei der niedrigeren Samplerate treffen.

Mit 15kHz wird zuverlässig erkannt. Die FB sendet nur ein Frame. 
Allerdings braucht es nur wenige Millisekunden für die 
Tastenwiederholung, die dann zuverlässig als solche von IRMP erkannt 
wird.

Mit 10kHz stimmen zwar die Codes, aber die Wiederholung wird nur 
sporadisch von IRMP als solche erkannt. Das ganze ist also, wie Du schon 
vermutetest, grenzwertig.

Ich habe kein Problem, IRMP mit 15kHz abtasten zu lassen. Siehst Du noch 
eine Stellschraube, um vielleicht mit 10kHz hinzukommen?

von eku (Gast)


Lesenswert?

eku schrieb:
> Mit 10kHz stimmen zwar die Codes, aber die Wiederholung wird nur
> sporadisch von IRMP als solche erkannt.

Gerade noch einmal getestet. Der Gerätecode wird nicht zuverlässig 
decodiert.

von eku (Gast)


Lesenswert?

Mit 15kHz werden keine anderen Protokolle erkannt. Woran kann das 
liegen?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:

> Mit 15kHz wird zuverlässig erkannt. Die FB sendet nur ein Frame.

Prima.

> Allerdings braucht es nur wenige Millisekunden für die
> Tastenwiederholung, die dann zuverlässig als solche von IRMP erkannt
> wird.

Dann lasse ich das mit der Extra-Auswertung des 15. Bits. Da ich dieses 
nur "ab und zu" im 10kHz-Scan gesehen habe, kann es auch sein, dass es 
einfach ein zufällig gekipptes Bit war. Wie gesagt, bei 10kHz liegen die 
Zeiten zu nah beieinander, um noch zuverlässig 0 oder 1 erkennen zu 
können.

> Mit 10kHz stimmen zwar die Codes, aber die Wiederholung wird nur
> sporadisch von IRMP als solche erkannt. Das ganze ist also, wie Du schon
> vermutetest, grenzwertig.

Okay, dann werde ich das im Source so machen, dass bei 10kHz der 
SIEMENS-Gigaset-Decoder unter Angabe einer Warnung deaktiviert wird.

> Ich habe kein Problem, IRMP mit 15kHz abtasten zu lassen. Siehst Du noch
> eine Stellschraube, um vielleicht mit 10kHz hinzukommen?

Nein. Bei dem 10kHz-Scan überlappen sich die Puls-/Pausenlängen 
teilweise. Hat einfach keinen Zweck.

Danke für Dein Feedback,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:
> Mit 15kHz werden keine anderen Protokolle erkannt. Woran kann das
> liegen?

Upps, weiß ich nicht. Es kann höchstens sein, dass eine gemessene 
Puls-/Pausen-Länge die 255 überschreitet. Ich dachte aber bisher, dass 
bis 15kHz noch alle Variablen mit uint8_t reichen... muss ich nochmal 
gegenchecken.

Welche anderen Protokolle hast Du denn getestet?

Notfalls könntest Du mal auf 14kHz runtergehen.

Gruß,

Frank

von Torsten K. (nobby)


Angehängte Dateien:

Lesenswert?

Hy,

ich versuche gerade das IRMP zu benutzen um damit NEC Codes zu meinem 
Receiver zu schicken. Der will aber nicht reagierren.
Ich habe das Modul von Klaus Leidinger nachgebaut, das zeigt mir den 
richtigen Code an, den ich sende, aber der Receiver mag nicht.
Ich hab mir das Signal der echten FB mal angeschaut und hier als Bild 
abgelegt. Da sieht man, das der eigentliche Befehl nur einmal kommt, und 
danach nur noch sowas wie "Taste noch gedrückt" ?

Das Timing der Repeats ist dieses:
9,1mS low, 2,1mS High, 700µS Low, 95,6mS High, dann gehts wieder mit 
9,1mS Low los.

Könnte die "Nichtfunktion" damit zusammenhängen, bzw. ist es möglich 
dieses Signal noch anzuhängen ??

Gruß
Torsten

von eku (Gast)


Lesenswert?

Frank M. schrieb:
> Upps, weiß ich nicht. Es kann höchstens sein, dass eine gemessene
> Puls-/Pausen-Länge die 255 überschreitet. Ich dachte aber bisher, dass
> bis 15kHz noch alle Variablen mit uint8_t reichen... muss ich nochmal
> gegenchecken.

Ich bin mir sicher, dass es da Überläufe gibt. Entferne mal den Cast 
uint8_t vor den Konstanten (Timing) an drehe die Compilerwarnungen hoch.

> Welche anderen Protokolle hast Du denn getestet?

NEC, Nubert, Denon, RC5, Grundig, Nokia

> Notfalls könntest Du mal auf 14kHz runtergehen.

Bring nichts. Bei 11kHz funktionieren die anderen, aber Siemens wird 
nicht zuverlässig erkannt. Wir werden die Konstanten auf 16 Bit 
verbreitern
müssen. Ob das generell so ist oder nur wenn F_INTERRUPTS > 10000 
überlasse ich Dir.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Torsten Kalbe schrieb:

> Ich habe das Modul von Klaus Leidinger nachgebaut, das zeigt mir den
> richtigen Code an, den ich sende, aber der Receiver mag nicht.

Das heisst also, der reagiert überhaupt nicht? Oder nur 1mal auf eine 
Taste?

> Ich hab mir das Signal der echten FB mal angeschaut und hier als Bild
> abgelegt. Da sieht man, das der eigentliche Befehl nur einmal kommt, und
> danach nur noch sowas wie "Taste noch gedrückt" ?
> Das Timing der Repeats ist dieses:
> 9,1mS low, 2,1mS High, 700µS Low, 95,6mS High, dann gehts wieder mit
> 9,1mS Low los.

Das entspricht genau dem, was in

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

unter Protokoll "NEC, Tastenwiederholung" steht:

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

Dieser Frame wird eigentlich nur geschickt, um eine Taste zu 
wiederholen, also dem Empfänger mitzuteilen, dass Du noch immer die 
Taste drückst.

> Könnte die "Nichtfunktion" damit zusammenhängen, bzw. ist es möglich
> dieses Signal noch anzuhängen ??

Schickt Deine Original-FB denn diesen Wiederholungsframe auch aus, wenn 
Du die Taste nur kurz drückst? Wenn nicht, reagiert dann der Empfänger 
in Deinem Gerät?

Wenn Deine FB diesen Wiederholungsframe generell sendet, egal wie lange 
Du die Taste drückst, dann würde ich dieses absonderliche Verhalten 
Deiner FB über ein Bit in irmp_data.flags nachbilden.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:

> Ich bin mir sicher, dass es da Überläufe gibt. Entferne mal den Cast
> uint8_t vor den Konstanten (Timing) an drehe die Compilerwarnungen hoch.

Werde ich mir ansehen.

> Bring nichts. Bei 11kHz funktionieren die anderen, aber Siemens wird
> nicht zuverlässig erkannt. Wir werden die Konstanten auf 16 Bit
> verbreitern müssen. Ob das generell so ist oder nur wenn F_INTERRUPTS
> 10000 überlasse ich Dir.

Das wäre bitter, denn nicht nur der Code würde größer werden, sondern 
auch das Laufzeitverhalten könnte kritisch werden.

Ich werde das überprüfen und dann nach einer geeigneten Lösung suchen.

Gruß,

Frank

von eku (Gast)


Lesenswert?

Gerade mal die Timings und Zählervariablen auf 16Bit verbreitert. Bis 
auf Denon funktioniert wieder alles bei 15kHz. Mehrverbrauch etwa 1kByte 
Flash.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:

> Ich bin mir sicher, dass es da Überläufe gibt. Entferne mal den Cast
> uint8_t vor den Konstanten (Timing) an drehe die Compilerwarnungen hoch.

Entfernen darf man die Casts auf keinen Fall, denn dann sind die 
Konstanten alle Floats und die Floating-Point-Lib wird dann aktiv.

Die größten Werte im Source sind

NEC_START_BIT_PULSE_TIME mit 9000e-6

bzw.

BANG_OLUFSEN_START_BIT3_PAUSE_TIME mit 15625e-6

Damit rechne ich jetzt mal aus:
1
#define NEC_START_BIT_PULSE_LEN_MAX             ((uint8_t)(F_INTERRUPTS * NEC_START_BIT_PULSE_TIME * MAX_TOLERANCE_40 + 0.5) + 1)

Da kommt heraus bei 15kHz:

15000 x 9000e-6 x 1.4 + 0.5 + 1 = 136,5 -> 137

Jetzt noch:
1
#define BANG_OLUFSEN_START_BIT3_PAUSE_LEN_MAX   ((uint8_t)(F_INTERRUPTS * BANG_OLUFSEN_START_BIT3_PAUSE_TIME * MAX_TOLERANCE_05 + 0.5) + 1)

Bei 15kHz:

15000 x 15625e-6 x 1.05 + 1 = 247,09375 -> 247

Das passt also alles noch in den Wertebereich von 0 bis 255. Das Problem 
muss woanders liegen. Irgendwas läuft bei 15kHz über, aber was? Ich habe 
auch in Erinnerung, dass Klaus Leidinger den IRMP damals auch mit 15kHz 
erfolgreich getestet hat...

Ich werde weitersuchen,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:
> Gerade mal die Timings und Zählervariablen auf 16Bit verbreitert. Bis
> auf Denon funktioniert wieder alles bei 15kHz. Mehrverbrauch etwa 1kByte
> Flash.

1 kByte sind 30%. Das ist mir zuviel. Ich vermute auch, dass diese 
"Gewaltaktion" eigentlich nicht notwendig ist, siehe meine Berechnungen 
oben.
Es gibt irgendwo ein 8-Bit-Problem im Source bei 15kHz, aber mir wäre es 
lieber, den Übeltäter zu finden statt den Teufel mit dem Bezelbub 
auszutreiben...

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Frank M. schrieb:

> Da kommt heraus bei 15kHz:
>
> 15000 x 9000e-6 x 1.4 + 0.5 + 1 = 136,5 -> 137

Rechenfehler, korrekt ist:

15000 x 9000e-6 x 1.4 + 0.5 + 1 = 190,5 -> 190.

Der Wert bleibt trotzdem unter 256...

Ich habe auch eben mal ein kleines Programm geschrieben, um mir alle 
Timingwerte ausgeben zu lassen. Keines erzeugt bei 15kHz einen 
8-Bit-Überlauf.

Also weiter suchen...

Gruß,

Frank

von Simon K. (simon) Benutzerseite


Lesenswert?

Sind es denn auch genau 15kHz? Zum Beispiel mit 15,625kHz (Ist ja eine 
durchaus übliche Frequenz, wenn man einen 2^n Vorteiler benutzt).

Bang & Olufsen:
15625 x 15625e-6 x 1.05 + 1 = 257,3

von Torsten K. (nobby)


Lesenswert?

Zur Tastenwiederholung bei NEC.

Der Receiver reagiert garnicht.

Wenn ich die Taste an der FB dauerhaft drücke bekomme ich auch dauernd 
das Wiederholungssignal.

Die Taste so kurz zu drücken ist nicht wirklich einfach, außerdem sehe 
ich das dann ja auch nicht, was tatsächlich gesendet wird.
Ich müßte mal den zusätzlichen IR Empfänger direkt über den Receiver 
legen, damit ich dann mit dem Scope das Signal nachmessen kann.
Ich hab aber mal versucht die Taste ganz kurz zu drücken, da scheint der 
auch zu reagieren.

Das Signal selber, welches ich verschicke sieht vom Timing nahezu gleich 
aus, da habe ich an den Defines extra nachverändert, aber der Receiver 
reagiert trotzdem nicht.
Ich habe auch schonmal die IR Diode aus der FB an meiner Schaltung 
benutzt, weil ich eine ungewöhnliche Wellenlänge vermutet habe.
Das wars auch nicht.
Sehr merkwürdig.....

Gruß
Torsten

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Torsten Kalbe schrieb:
> Zur Tastenwiederholung bei NEC.
>
> Der Receiver reagiert garnicht.

Kannst Du mir Scan-Dateien zukommen lassen? Die Tasten 0-9 würden 
reichen.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:
> Gerade mal die Timings und Zählervariablen auf 16Bit verbreitert. Bis
> auf Denon funktioniert wieder alles bei 15kHz. Mehrverbrauch etwa 1kByte
> Flash.

Ich habe gerade mal stichprobenweise einige der mir vorliegenden 
Scan-Dateien mit dem Editor von 10kHz auf 15kHz "gestreckt", indem ich 
immer 00 durch 000 und 11 durch 111 ersetzt habe. Dann IRMP mit 15kHz 
unter Linux übersetzt und gegen die Scan-Dateien laufen lassen.

Ergebnis: überhaupt kein Problem, alle Scans wurden einwandfrei erkannt 
und dekodiert. Das NEC-Protokoll lief bei mir sogar noch bei 20kHz 
korrekt (mit entsprechend gestreckten Scan-Dateien).

Allerdings habe ich beim 20kHz-Test dann auch vom Compiler Warnungen 
bzgl. IRMP_TIMEOUT_LEN bekommen. Das läuft über ab 15425 Hz:
1
#define IRMP_TIMEOUT_TIME                       16500.0e-6                    // timeout after 16.5 ms darkness
2
#define IRMP_TIMEOUT_LEN                        (uint8_t)(F_INTERRUPTS * IRMP_TIMEOUT_TIME + 0.5)

F_INTERRUPTS darf also durchaus zwischen den Werten 10000 und 15000 
liegen.

Das Problem bei Dir muss woanders liegen. Ein Grund könnte sein, dass 
bei 15kHz der Time-Slot für die 15kHz-ISR zu eng wird, d.h. also 
Interrupts verlorengehen. Dagegen spricht, dass das Siemens-Protokoll 
immer noch korrekt erkannt wird. Ausserdem dürfte Deine 16-Bit-Version 
das Laufzeitverhalten noch weiter verschlimmern. Hattest Du vielleicht 
bei der 8-Bit-Version und F_INTERRUPTS = 15kHz noch das IRMP_LOGGING 
aktiviert? Das kostet natürlich auch noch einiges an Zeit.

Gruß,

Frank

von Torsten K. (nobby)


Lesenswert?

ähm, ja, eigentlich schon.
Muß ich dann nur die Zeile
#define IRMP_LOGGING                            0 
// 1: log IR signal (scan), 0: do not (default)
verändern in #define IRMP_LOGGING                            1 
// 1: log IR signal (scan), 0: do not (default)

Und dann den Empfäng mit Hterm pro Taste Speichern ?
oder kannst Du mit vielleicht die fertige Hex mailen ?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Torsten Kalbe schrieb:
> ähm, ja, eigentlich schon.
> Muß ich dann nur die Zeile
> #define IRMP_LOGGING                            0
> // 1: log IR signal (scan), 0: do not (default)
> verändern in #define IRMP_LOGGING                            1
> // 1: log IR signal (scan), 0: do not (default)
>
> Und dann den Empfäng mit Hterm pro Taste Speichern ?

Ja, genau, siehe auch IRMP-Artikel.

Am besten schreibst Du dann am Schluss noch jeweils einen Kommentar vor 
jede Zeile, eingeleitet mit '#', z.B.

# Taste 1
0000011100000....

Gruß,

Frank

von Torsten K. (nobby)


Angehängte Dateien:

Lesenswert?

So, da ist dann mal der Scan von der FB mit NEC Protokoll.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Torsten Kalbe schrieb:
> So, da ist dann mal der Scan von der FB mit NEC Protokoll.

Danke, habe es mir angeschaut, bei jeder Taste wird nicht nur der 
normale NEC-Protokoll-Frame geschickt, sondern immer auch zusätzlich 
noch ein Repetition-Frame. Da ich annehme, dass Du die Tasten (bis auf 
Taste 1) immer nur kurz gedrückt hast, will Dein Empfänger wohl auch 
immer den Repetition-Frame "sehen", bevor er reagiert.

Ich werde in den IRSND einbauen, dass man über das Setzen eines Flags 
genau dieses (atypische) Verhalten reproduzieren kann.

Vielen Dank für den Scan,

Frank

von Torsten K. (nobby)


Lesenswert?

Oh, so eine Anpassung wäre ja Klasse, aber es würde ja auch erstmal eine 
"Testversion" reichen, vielleicht liegt es ja doch noch an was anderem.

von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Lesenswert?

Torsten Kalbe schrieb:
> Oh, so eine Anpassung wäre ja Klasse, aber es würde ja auch erstmal eine
> "Testversion" reichen, vielleicht liegt es ja doch noch an was anderem.

Ich dachte auch an eine "Testversion", nur war die mal nicht eben in 5 
Minuten zusammengehackt ;-)

Ich habe nun irsnd folgendermaßen erweitert, dass irmp_data.flags die 
Anzahl der Tasten-Wiederholungen angibt, also:

flags = 0: Normales Senden des Frames - wie bisher
flags = 1: 1-malige Wiederholung
flags = 2: 2-malige Wiederhulung
usw.

Dabei gelten folgende Besonderheiten:

Bei SIRCS werden sowieso immer 3 Frames gesandt - so erfordert es das 
Protokoll. Bei flags = 1 werden dann daraus 4 Frames, bei flags = 2 dann 
5 Frames usw.

Bei NEC werden die Wiederholungen als Repetition-Frames gesandt, also 
nicht der komplette Frame n-mal wiederholt.

Für Grundig und Nokia werden im Moment noch alle Pakete (welche aus 3 
Frames bestehen, nämlich Start-Frame + Info-Frame + Stop-Frame) n-malig 
wiederholt, also nicht nur der Info-Frame, wie es sein soll. Da muss ich 
noch nacharbeiten.

Bei allen anderen Protokollen wird einfach der Original-Frame n-mal 
wiederholt, mit entweder (mir) bekannten Pause-Zeiten zwischen den 
Frames oder mit der (von mir willkürlich gewählten) Pause-Zeit von 
45msec.

Um nun Dein Problem mit dem Skymaster-Empfänger zu lösen, musst Du vor 
dem Aufruf von irsnd_send_data() einfach irmp_data.flags = 1 setzen. 
Dann wird erst der Original-Frame gesandt, anschließend eine Pause von 
40ms gemacht und letztendlich der Repetition-Frame gesandt.

Im Anhang die Testversion.

Viel Glück!

Frank

von Torsten K. (nobby)


Lesenswert?

Hallo Frank,

erstmal vielen Dank für die schnelle Anpassung !!

Das Problem lag aber an einer anderen Stelle, manchmal kann es so 
einfach sein.
Nachdem ich den Receiver auseinander geschraubt hatte, und direkt am 
Empfänger gemessen habe, ist mir noch eine andere Idee eingefallen.

Diese neue Atmelgeneration hat ja einen elendigen Jitter vom RC 
Oszilator, daher habe ich mal einen 8mHz Quarz an den Prozessor gelötet, 
und schon hat es sofort funktioniert !!
Auch das einfache Senden des NEC-Codes, auch ohne Wiederholung hat 
gereicht !!
Ich denke aber, diese Fähigkeit der Wiederholungseinstellung sollte 
erhalten bleiben, denn das könnte vielleicht auch mal in anderen Fällen 
zu gebrauchen sein.

Ich werde jetzt mal an die Schaltung von Klaus auch einen Quarz hängen, 
da nämlich der RC5 Code bei mir nicht immer gut erkannt wird.

Gruß
Torsten

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Torsten Kalbe schrieb:

> Diese neue Atmelgeneration hat ja einen elendigen Jitter vom RC
> Oszilator, daher habe ich mal einen 8mHz Quarz an den Prozessor gelötet,
> und schon hat es sofort funktioniert !!

Danke für die Rückmeldung :-)

> Auch das einfache Senden des NEC-Codes, auch ohne Wiederholung hat
> gereicht !!

Prima.

> Ich denke aber, diese Fähigkeit der Wiederholungseinstellung sollte
> erhalten bleiben, denn das könnte vielleicht auch mal in anderen Fällen
> zu gebrauchen sein.

Ja, auf jeden Fall, damit kann man dann direkt ein Kommando n-fach 
schicken, was durchaus sinnvoll sein kann, z.B. zur Regelung von 
Lautstärken oder Helligkeiten etc.

> Ich werde jetzt mal an die Schaltung von Klaus auch einen Quarz hängen,
> da nämlich der RC5 Code bei mir nicht immer gut erkannt wird.

Ich werde im IRMP-Artikel entsprechend vermerken, dass die ganze 
Geschichte mit Quarz um einiges stabiler ist.

Gruß,

Frank

von Torsten K. (nobby)


Lesenswert?

Dann kannst Du vielleicht auch mal auf diese Seite verlinken:
http://www.scienceprog.com/avr-internal-oscillator-jitter-research/
Da sind ein paar erschreckende Bilder zu sehen !

von Klaus L. (kllei)


Lesenswert?

Torsten Kalbe schrieb:
> Hallo Frank,
>
> Ich werde jetzt mal an die Schaltung von Klaus auch einen Quarz hängen,
> da nämlich der RC5 Code bei mir nicht immer gut erkannt wird.
>
Hallo Torsten,
die Xtal Pins sind in meiner Schaltung leider für das LCD benutzt (wegen 
Kompatibilität mit Codevision). Für GCC kann die Pinbelegung natürlich 
auch einfach geändert werden. Ein Kalibrieren des Oszillators würde 
vielleicht auch helfen?

Gruß,
Klaus

von Torsten K. (nobby)


Angehängte Dateien:

Lesenswert?

Ich hatte den mit dem internen Wert calibriert, das hat aber nicht 
geholfen.
Das bringt auch nichts, wenn der am Jittern ist. Der Mega8 ist da noch 
gut, der Mega48/88/168 ist total am Jittern, wenn das dann bei der 
Signalgenerierung passiert, könnte ich mir gut vorstellen, das da 
vielleicht ein paar Bits nicht mehr erkannt werden ??
Ich hab hier das dazu passende Mesbild mal angehängt, Quelle dazu ist:
http://www.scienceprog.com/avr-internal-oscillator-jitter-research/

Sagt mal, hat schon jemand das Protokol einer Siku Controll angeschaut. 
Das ist eine Infrarot Fernbedienung für Modellauutos, wird gerner im 
1/87 bereich benutzt. Das läuft allerdings mit 455khz und ist ständig am 
senden.

Gruß

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Neue Version 1.5.0 von IRMP verfügbar, Download unter

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

Änderungen:

 - Neues Protokoll: SIEMENS (Gigaset)

Ebenso ist nun die Version 1.5.0 von IRSND verfügbar, Download unter

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

Änderungen:

 - Neues Protokoll: Siemens (Gigaset)
 - Simulation von langen Tastendrücken durch Angabe von Wiederholungen
   in der Variablen irmp_data.flags.

irmp_data_p.flags gibt die Anzahl der Wiederholungen an, z.B.

 irmp_data_p.flags = 0: Verhalten wie bisher
 irmp_data_p.flags = 1: 1 Wiederholung, d.h. Ausgabe von 2 Frames
 irmp_data_p.flags = 2: 2 Wiederholungen, d.h. Ausgabe von 3 Frames
 usw.

Sind Wiederholungen angegeben, wird entweder der Frame nach einer Pause 
(protokollabhängig) neu ausgegeben oder ein protkollspezifischer 
Wiederholungsframe (z.B. für NEC) gesendet.

ZU BEACHTEN:

Da bisher irmp_data_p.flags von IRSND nicht ausgewertet wurde, ist 
unbedingt ab Version 1.5.0 darauf zu achten, dass irmp_data_p.flags vor 
dem Aufruf von irsnd_send_data() einen definierten Wert hat!

Viel Spaß,

Frank

von eku (Gast)


Lesenswert?

Hallo Frank!

Frank M. schrieb:
> Das Problem bei Dir muss woanders liegen. Ein Grund könnte sein, dass
> bei 15kHz der Time-Slot für die 15kHz-ISR zu eng wird, d.h. also
> Interrupts verlorengehen. Dagegen spricht, dass das Siemens-Protokoll
> immer noch korrekt erkannt wird. Ausserdem dürfte Deine 16-Bit-Version
> das Laufzeitverhalten noch weiter verschlimmern. Hattest Du vielleicht
> bei der 8-Bit-Version und F_INTERRUPTS = 15kHz noch das IRMP_LOGGING
> aktiviert? Das kostet natürlich auch noch einiges an Zeit.


Ich bin am verzweifeln. Nutze Timer0 eines Mega32 als freilaufende 
Zähler (gemäß Peter Danegger) für die 15kHz-Interruptquelle. Will 
einfach nicht funktionieren. An der Interrupthäufigkeit kann es 
eigentlich nicht liegen.
Hast Du noch 'ne Idee, wo ich suchen könnte?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi eku,

> Ich bin am verzweifeln. Nutze Timer0 eines Mega32 als freilaufende
> Zähler (gemäß Peter Danegger) für die 15kHz-Interruptquelle. Will
> einfach nicht funktionieren. An der Interrupthäufigkeit kann es
> eigentlich nicht liegen.

Es ist also weiterhin so, dass bei 15kHz nur das Siemens-Protokoll 
funktioniert? Die anderen nur bei Verbreiterung der Zählervariablen auf 
16 Bit?

Zeigst Du mal Deine Timer-(Initialisierungs-)Routinen?

Gruß,

Frank

von eku (Gast)


Lesenswert?

Frank M. schrieb:
> Zeigst Du mal Deine Timer-(Initialisierungs-)Routinen?
1
#define IR_HZ          15000    /* interrupts per second */
2
3
#define MAX_OVERFLOW   255UL
4
#if (F_CPU/IR_HZ) < MAX_OVERFLOW
5
#define HW_PRESCALER   1UL
6
#define HW_PRESCALER_MASK  _BV(CS00)
7
#elif (F_CPU/IR_HZ/8) < MAX_OVERFLOW
8
#define HW_PRESCALER   8UL
9
#define HW_PRESCALER_MASK  _BV(CS01)
10
#elif (F_CPU/IR_HZ/64) < MAX_OVERFLOW
11
#define HW_PRESCALER   64UL
12
#define HW_PRESCALER_MASK  _BV(CS01)|_BV(CS00)
13
#elif (F_CPU/IR_HZ/256) < MAX_OVERFLOW
14
#define HW_PRESCALER   256UL
15
#define HW_PRESCALER_MASK  _BV(CS02)
16
#elif (F_CPU/IR_HZ/1024) < MAX_OVERFLOW
17
#define HW_PRESCALER   1024UL
18
#define HW_PRESCALER_MASK  _BV(CS02)|_BV(CS00)
19
#else
20
#error F_CPU to large
21
#endif
22
#define SW_PRESCALER   ((F_CPU/HW_PRESCALER)/IR_HZ)
23
24
static uint16_t prescaler;
25
26
init()
27
{
28
  /* init timer0 to expire after 1000/IR_HZ ms */
29
  TCCR0 = HW_PRESCALER_MASK;
30
  OCR0 = SW_PRESCALER - 1;
31
  TCNT0 = 0;
32
  prescaler = (uint16_t) IR_HZ;
33
34
  /* enable interrupt */
35
  TIMSK |= _BV (OCIE0);
36
}
37
38
ISR (TIMER0_COMP_vect)
39
{
40
  uint8_t data = PIN (IR_RX_PORT) & _BV (IR_RX_PIN);
41
42
  if (data == IR_RX_MARK)
43
    IR_RX_LED_ON; /* Kontroll-LED */
44
  else
45
    IR_RX_LED_OFF;
46
47
  ir_rx_process (data);
48
49
  if (--prescaler == 0)
50
    prescaler = (uint16_t) IR_HZ;
51
#if (F_CPU/HW_PRESCALER) % IR_HZ
52
  if (prescaler <= (F_CPU / HW_PRESCALER) % IR_HZ)
53
    OCR0 += SW_PRESCALER + 1;   /* um 1 Takt längere Periode um
54
                                   den Rest abzutragen */
55
  else
56
#endif
57
    OCR0 += SW_PRESCALER;       /* kurze Periode */
58
}

von eku (Gast)


Lesenswert?


von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:
1
> #define IR_HZ          15000    /* interrupts per second */

Ich verstehe nicht, warum Du es Dir so schwer machst. Du musst nicht 
genau auf 15000 Hz kommen, es ist nur wichtig, dass F_INTERRUPTS exakt 
ist. Wenn
also für ein bestimmtes TCCR0 und OCR0 etwa 14750 Hz rauskommen, dann 
stellst Du halt F_INTERRUPTS auf 14750 und gut ist.
1
> #error F_CPU to large

Ohne die Angabe von F_CPU sind die Preprocessor-Makros für mich schlecht 
nachvollziehbar. Sind es 8MHz mit internem Oszillator?
1
  ir_rx_process (data);

Was ist ir_rx_process()? Entspricht das der ISR vom IRMP? Ich vermute, 
Du hast soviel im Source umgebaut, dass es vielleicht deshalb nicht mehr 
funktioniert.

Ausserdem hast Du meine beiden Fragen nicht beantwortet, hier nochmal:

Es ist also weiterhin so, dass bei 15kHz nur das Siemens-Protokoll
funktioniert? Die anderen nur bei Verbreiterung der Zählervariablen auf
16 Bit?

Also:

A. Berechne einfach geeignete Werte für TCCR0 und OCR0, so dass das
   Ergebnis möglichst knapp unter 15000 ist.

B. Setze F_INTERRUPTS auf den exakten berechneten Wert.

C. Rufe in ISR(TIMER0_COMP_vect) einfach nur irmp_ISR() auf


Gruß,

Frank

von eku (Gast)


Lesenswert?

Frank M. schrieb:
> eku schrieb:
>> #define IR_HZ          15000    /* interrupts per second */
>
> Ich verstehe nicht, warum Du es Dir so schwer machst. Du musst nicht
> genau auf 15000 Hz kommen, es ist nur wichtig, dass F_INTERRUPTS exakt
> ist. Wenn also für ein bestimmtes TCCR0 und OCR0 etwa 14750 Hz
> rauskommen, dann stellst Du halt F_INTERRUPTS auf 14750 und gut ist.
>> #error F_CPU to large

Mein AVR soll neben IRMP noch andere Aufgaben erfüllen, mit nur einer
ISR. Warum soll ich Werte selbst berechnen, wenn es der Präprozessor 
übernimmt.

> Ohne die Angabe von F_CPU sind die Preprocessor-Makros für mich
> schlecht nachvollziehbar. Sind es 8MHz mit internem Oszillator?

16MHz Quarz

>   ir_rx_process (data);
>
> Was ist ir_rx_process()? Entspricht das der ISR vom IRMP? Ich vermute,
> Du hast soviel im Source umgebaut, dass es vielleicht deshalb nicht
> mehr funktioniert.

Nö, ich habe IRMP und IRSND in eine Bibliothek gepackt. Den eingelesenen 
Wert gebe ich an irmp_ISR(). Ansonsten habe ich nichts verändert.

> Ausserdem hast Du meine beiden Fragen nicht beantwortet, hier nochmal:
>
> Es ist also weiterhin so, dass bei 15kHz nur das Siemens-Protokoll
> funktioniert? Die anderen nur bei Verbreiterung der Zählervariablen
> auf 16 Bit?

Ja, bis auf Denon funktionieren die anderen Protokolle mit 15kHz und 
16Bit-Zählern.

> Also:
>
> A. Berechne einfach geeignete Werte für TCCR0 und OCR0, so dass das
>    Ergebnis möglichst knapp unter 15000 ist.
>
> B. Setze F_INTERRUPTS auf den exakten berechneten Wert.
>
> C. Rufe in ISR(TIMER0_COMP_vect) einfach nur irmp_ISR() auf

Probeweise werde ich das mal so machen. Mittelfristig soll IRMP/IRSND 
aber im Kontext meiner Anwendung für den AVR laufen. Ich stelle mir das 
als Modul für Ethersex auf einem Pollin Net-IO vor. Kommando- und 
Webinterface zur Fernbedienung der HiFi-Geräte.

von eku (Gast)


Lesenswert?

Frank M. schrieb:
> A. Berechne einfach geeignete Werte für TCCR0 und OCR0, so dass das
>    Ergebnis möglichst knapp unter 15000 ist.
>
> B. Setze F_INTERRUPTS auf den exakten berechneten Wert.

F_INTERUPTS=16000000/8/133=15037

Siemens, Nokia, RCx, Nec, Grundig gehen, nur Denon nicht. Hilft ein 
IRMP_LOGGING zur Analyse?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:

> Siemens, Nokia, RCx, Nec, Grundig gehen

Auch mit 8-Bit-Zählern? Freut mich.

> nur Denon nicht. Hilft ein IRMP_LOGGING zur Analyse?

Ja.

Gruß,

Frank

von eku (Gast)


Angehängte Dateien:

Lesenswert?

Frank M. schrieb:
>> Siemens, Nokia, RCx, Nec, Grundig gehen
>
> Auch mit 8-Bit-Zählern? Freut mich.

Ja. Mit 20kHz läuft dann aber der Pausenzähler über. Bemerkt schon der 
Compiler

>> nur Denon nicht. Hilft ein IRMP_LOGGING zur Analyse?
>
> Ja.

Anbei. Diesmal habe ich die bei 10kHz dekodierten Codes vor die Sequenz 
geschrieben. Hoffe das hilft. Bei 20kHz wird es mit Denon nicht besser. 
Ich hatte zu8nächste Rundungsfehler bei den Konstanten (10kHz +50%) in 
Verdacht, aber die Verdoppelung macht es nicht besser.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:

> Ja. Mit 20kHz läuft dann aber der Pausenzähler über. Bemerkt schon der
> Compiler

Gut, das habe ich auch erwartet.

> Anbei. Diesmal habe ich die bei 10kHz dekodierten Codes vor die Sequenz
> geschrieben. Hoffe das hilft. Bei 20kHz wird es mit Denon nicht besser.

Ersetze in irmp.c die Zeile
1
#define DENON_1_PAUSE_LEN_MIN                   ((uint8_t)(F_INTERRUPTS * DENON_1_PAUSE_TIME * MIN_TOLERANCE_20 + 0.5) - 1)

durch
1
#define DENON_1_PAUSE_LEN_MIN                   ((uint8_t)(F_INTERRUPTS * DENON_1_PAUSE_TIME * MIN_TOLERANCE_30 + 0.5) - 1)

Dann geht es.

Gruß,

Frank

von eku (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Frank!

Frank M. schrieb:
> Ersetze in irmp.c die Zeile

Geht. Pefekt. Ich hoffe, auch den Sendeteil bald testen zu können.

PS: Es kommt keine Warnung wenn, Siemens mit 10kHz compiliert wird.

PS2: Einen hab' ich noch :-) Siehe Anhang. Ist eine IR-Tastatur aus 
China (Pollin 711 056). IRMP dekodiert bei 15kHz RCx + Siemens je Taste.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:

> Geht. Pefekt. Ich hoffe, auch den Sendeteil bald testen zu können.

Na slso.

> PS: Es kommt keine Warnung wenn, Siemens mit 10kHz compiliert wird.

Das verstehe ich nicht. Wann kommt denn eine Warnung? Die Aussage, wann 
keine Warnung kommt, hilft mir nicht weiter. Redest Du von IRMP oder 
IRSND?

Am besten zeigst Du mal den Compiler-Output.

> PS2: Einen hab' ich noch :-) Siehe Anhang. Ist eine IR-Tastatur aus
> China (Pollin 711 056). IRMP dekodiert bei 15kHz RCx + Siemens je Taste.

Ein 42-Bit-Protokoll, keine Ahnung, was das sein soll. Aber relativ 
einfach zu dekodieren - allerdings nicht mehr bei 10 kHz. Ich schaue mir 
das mal näher an.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Lesenswert?

Frank M. schrieb:
> eku schrieb:
>> PS2: Einen hab' ich noch :-) Siehe Anhang. Ist eine IR-Tastatur aus
>> China (Pollin 711 056). IRMP dekodiert bei 15kHz RCx + Siemens je Taste.
>
> Ein 42-Bit-Protokoll, keine Ahnung, was das sein soll. Aber relativ
> einfach zu dekodieren - allerdings nicht mehr bei 10 kHz. Ich schaue mir
> das mal näher an.

Habe das Protokoll soweit dekodiert. Von den insgesamt 42 Bits (1 
Start-Bit, 40 Daten-Bits, 1 Stop-Bit) werden nur effektiv 12 Bits 
genutzt. Anbei eine Testversion. Nette Geschichte, damit kann man eine 
PC-Tastatur einfach an einen µC anbinden.

Wäre klasse, wenn Du mal sämtliche Tasten scannen könntest, ich habe 
noch nicht entscheiden können, ob das Protokoll mit LSB- oder MSB-first 
funktioniert. Meine Vermutung ist LSB-first, aber richtig kann man das 
erst erkennen, wenn sämtliche Tasten der Matrix (es sieht nach einem 
Matrix-Code aus) bekannt ist.

Auf jeden Fall bestelle ich mir mal ein paar von den Dingern. Bei 1,95 
EUR ist das ja kein großes Risiko ;-)

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Frank M. schrieb:

> Ersetze in irmp.c die Zeile
1
> #define DENON_1_PAUSE_LEN_MIN     ((uint8_t)(F_INTERRUPTS * DENON_1_PAUSE_TIME * MIN_TOLERANCE_20 + 0.5) - 1)
> durch
1
> #define DENON_1_PAUSE_LEN_MIN     ((uint8_t)(F_INTERRUPTS * DENON_1_PAUSE_TIME * MIN_TOLERANCE_30 + 0.5) - 1)
> Dann geht es.

Nach nochmaligem Studium von

   http://www.mikrocontroller.com/de/IR-Protokolle.php#DENON

habe ich festgestellt, dass die obige Lösung den Fehler nur vertuscht 
hat. In Wirklichkeit ist der Timing-Wert in irmp.h
1
#define DENON_0_PAUSE_TIME                       1050.0e-6                      //  1050 usec pause

falsch. Es muss heissen:
1
#define DENON_0_PAUSE_TIME                       775.0e-6                       //  775 usec pause

Dann kann man den Toleranzwert für DENON_1_PAUSE_LEN_MIN wieder auf 20 
Prozent zurückschrauben, also die obige Änderung in irmp.c wieder 
rückgängig machen, denn die Abweichungen der Denon-FB von den 
Idealwerten sind dann wieder wesentlich geringer.

Sorry, mein Fehler. Werde ich im nächsten Release berücksichtigen.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Neue Version 1.6.0 von IRMP verfügbar, Download unter

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

Änderungen:

 - Neues Protokoll: FDC (IR keyboard)
 - Timings vom DENON-Protokoll korrigiert

Ebenso ist nun die Version 1.5.0 von IRSND verfügbar, Download unter

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

Änderungen:

 - Neues Protokoll: FDC (IR keyboard)
 - Timings vom DENON-Protokoll korrigiert

Damit kann man nun die bei Pollin erhältliche Infrarot-Tastatur FDC-3402 
(Bestellnr. 711 056) auch am µC nutzen.

Achtung:

Die Protokolle SIEMENS und FDC werden sowohl für IRMP als auch für IRSND 
beim Compilieren automatisch abgeschaltet, wenn F_INTERRUPTS kleiner als 
14500 Hz ist. Grund: Die Erkennung bei niedrigeren Scan-Raten ist nicht 
stabil.

Das ganze erkennt man in irmpconfig.h an folgendem Block:
1
/*--------------------------------------------------------------------------------------------------------------
2
 * Change settings from 1 to 0 if you want to disable one or more decoders.
3
 * This saves program space.
4
 * 1 enable  decoder
5
 * 0 disable decoder
6
 *---------------------------------------------------------------------------------------------------------------
7
 */
8
#define IRMP_SUPPORT_SIRCS_PROTOCOL             1       // flag: support SIRCS                 uses ~100 bytes
9
#define IRMP_SUPPORT_NEC_PROTOCOL               1       // flag: support NEC + APPLE           uses ~250 bytes
10
#define IRMP_SUPPORT_SAMSUNG_PROTOCOL           1       // flag: support Samsung + Samsung32   uses ~250 bytes
11
#define IRMP_SUPPORT_MATSUSHITA_PROTOCOL        1       // flag: support Matsushita            uses  ~50 bytes
12
#define IRMP_SUPPORT_KASEIKYO_PROTOCOL          1       // flag: support Kaseikyo              uses  ~50 bytes
13
#define IRMP_SUPPORT_RECS80_PROTOCOL            1       // flag: support RECS80                uses  ~50 bytes
14
#define IRMP_SUPPORT_RC5_PROTOCOL               1       // flag: support RC5                   uses ~250 bytes
15
#define IRMP_SUPPORT_DENON_PROTOCOL             1       // flag: support DENON                 uses ~250 bytes
16
#define IRMP_SUPPORT_RC6_PROTOCOL               1       // flag: support RC6                   uses ~200 bytes
17
#define IRMP_SUPPORT_RECS80EXT_PROTOCOL         1       // flag: support RECS80EXT             uses  ~50 bytes
18
#define IRMP_SUPPORT_NUBERT_PROTOCOL            1       // flag: support NUBERT                uses  ~50 bytes
19
#define IRMP_SUPPORT_BANG_OLUFSEN_PROTOCOL      1       // flag: support Bang & Olufsen        uses ~200 bytes
20
#define IRMP_SUPPORT_GRUNDIG_PROTOCOL           1       // flag: support Grundig               uses ~150 bytes
21
#define IRMP_SUPPORT_NOKIA_PROTOCOL             1       // flag: support Nokia                 uses ~150 bytes
22
23
/*--------------------------------------------------------------------------------------------------------------
24
 * THE FOLLOWING DECODERS WORK ONLY FOR F_INTERRUPTS > 14500!
25
 *---------------------------------------------------------------------------------------------------------------
26
 */
27
#if F_INTERRUPTS >= 14500
28
#define IRMP_SUPPORT_SIEMENS_PROTOCOL           1       // flag: support Siemens Gigaset       uses ~150 bytes
29
#define IRMP_SUPPORT_FDC_PROTOCOL               1       // flag: support FDC keyboard          uses ~150 bytes
30
#else
31
#define IRMP_SUPPORT_SIEMENS_PROTOCOL           0       // DO NOT CHANGE! F_INTERRUPTS too low!
32
#define IRMP_SUPPORT_FDC_PROTOCOL               0       // DO NOT CHANGE! F_INTERRUPTS too low!
33
#endif

Analoges gilt für irsndconfig.h.

Den IRMP-Artikel habe ich an den entsprechenden Stellen angepasst.

@Hugo Portisch:

Warte bitte noch ein wenig mit der Umsetzung auf die V-USB-Version, ich 
schätze, dass ich bzgl. des FDC-Protokolls noch etwas anpassen muss.

Gruß,

Frank

von eku (Gast)


Lesenswert?

Hallo Frank!

Vielen Danke für die prompte Reaktion. Ich komme erst am Abend zum 
Testen.

Ich hätte da noch ein paar Änderungswünsche für IRMP um mir dsa Patchen 
der Quellen zu ersparen:
1
Index: irmpconfig.h
2
===================================================================
3
--- irmpconfig.h        (Revision 21)
4
+++ irmpconfig.h        (Arbeitskopie)
5
@@ -81,6 +81,8 @@
6
  * Set IRMP_LOGGING to 1 if want to log data to UART with 9600Bd^M
7
  *---------------------------------------------------------------------------------------------------------------------------------------------------^M
8
  */^M
9
+#ifndef IRMP_LOGGING^M
10
 #define IRMP_LOGGING                            0                             // 1: log IR signal (scan), 0: do not (default)^M
11
+#endif^M
12
 ^M
13
 #endif /* _WC_IRMPCONFIG_H_ */^M

Der UART-Code kompoliert nicht auf einem Mega32. Die Registernamen 
enthalten keine Null ('0'). Die Initialisierung der Baudrate besser wie 
folgt (Mega32, andere Registernamen anpassen):
1
#define BAUD UART_BAUD
2
#include <util/setbaud.h>
3
4
  UBRRH = UBRRH_VALUE;          /* set baud rate */
5
  UBRRL = UBRRL_VALUE;
6
#if USE_2X
7
  UCSRA = _BV (U2X);
8
#else
9
  UCSRA = 0;
10
#endif
11
#ifdef URSEL
12
  UCSRC = _BV (UCSZ1) ^ _BV (UCSZ0) ^_BV (URSEL);
13
#else
14
  UCSRC = _BV (UCSZ1) ^ _BV (UCSZ0);    /* 8 Bit */
15
#endif
16
  UCSRB = _BV (TXEN);           /* enable TX */

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:
> Ich hätte da noch ein paar Änderungswünsche für IRMP um mir dsa Patchen
> der Quellen zu ersparen:

Ich habe Deine Änderungswünsche eingearbeitet und bei der Gelegenheit 
die UART-Register bzw. -Kontanten portabel definiert, so dass das 
Übersetzen nun auf jedem ATMEGA funktionieren sollte.

Kommt dann im nächsten Release.

Gruß,

Frank

von Hugo P. (portisch)


Lesenswert?

>>@Hugo Portisch:

>>Warte bitte noch ein wenig mit der Umsetzung auf die V-USB-Version, ich
>>schätze, dass ich bzgl. des FDC-Protokolls noch etwas anpassen muss.

Ok, danke für die Info!

Wie sieht denn dann der empfange Code der FDC aus?
Also als IRMP_DATA Struct?

Stehen in Command dann die ASCII Werte?
Was für Werte hat z.B. die Windows Taste, STRG, Alt,...

Entsprechen diese dieser Liste:
http://msdn.microsoft.com/en-us/library/ms645540.aspx

Bitte 1-2 Beispiele als irmp_data posten damit ich das sehen kann. 
Danke!

Ich hätte nähmlich die Idee, wenn das FDC Protokoll empfangen wird dies 
direkt von der DLL in Tastendrücke umzuwandeln damit es wie eine 
"normale" Tastatur funktioniert.

Da bin ich einmal gespannt. Beim letzten Protokoll (Siemens) waren nur 
mehr 98 Bytes von meinem Atmega8 frei (8k - 2k Bootloader). Jetzt wird 
es schon happig alle Protokolle mit hineinzupacken...

von eku (Gast)


Lesenswert?

Hugo Portisch schrieb:
> Wie sieht denn dann der empfange Code der FDC aus?
> Also als IRMP_DATA Struct?
>
> Stehen in Command dann die ASCII Werte?
> Was für Werte hat z.B. die Windows Taste, STRG, Alt,...

Eher nicht. Bislang ist noch unklar, ob fürs Drücken und Loslassen 
getrennte Codes gesendert werden.

von Hugo P. (portisch)


Lesenswert?

>>Eher nicht. Bislang ist noch unklar, ob fürs Drücken und Loslassen
>>getrennte Codes gesendert werden.

Auch wär interressant wie es dann mit mehreren Tastendrücke aussieht. 
Also z.B. STRG-C, WIN-D, SHIFT-A, STRG-ALT-ENTF,....

von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Lesenswert?

Hugo Portisch schrieb:

> Wie sieht denn dann der empfange Code der FDC aus?
> Also als IRMP_DATA Struct?

Ich habe mal den Output vom IRMP unter Linux angehängt.

> Stehen in Command dann die ASCII Werte?
> Was für Werte hat z.B. die Windows Taste, STRG, Alt,...

Nein, für mich sieht das wie ein Matrix-Code aus, halt so, wie die 
Tastatur verdrahtet ist. Vielleicht kannst Du ja mehr damit anfangen.

Im Moment werte ich die Bits 0-15 als Adresse, die Bits 25-36 als 
Kommando aus. Wenn man sich den Scan der FDC-Tastatur im Detail (siehe 
irmp-fdc-detail.txt) anschaut, dann sieht man, dass bei der 
"Wiederholung" sich in den Bits 20-24 etwas ändert. Ob das jetzt ein 
Repetition-Code ist, der durch längeres Drücken entstanden ist, oder 
tatsächlich die Zustände "Drücken" und "Loslassen" beschreibt, weiss ich 
noch nicht. Dazu habe ich noch zu wenig Infos.

> Ich hätte nähmlich die Idee, wenn das FDC Protokoll empfangen wird dies
> direkt von der DLL in Tastendrücke umzuwandeln damit es wie eine
> "normale" Tastatur funktioniert.

Jau :-)

Eher noch interessanter finde ich, einen µC einfachst mit einer 
kompletten PC-Tastatur auszustatten - für die Bedienung von Menüs, 
Konfigurationen etc.

> Da bin ich einmal gespannt. Beim letzten Protokoll (Siemens) waren nur
> mehr 98 Bytes von meinem Atmega8 frei (8k - 2k Bootloader). Jetzt wird
> es schon happig alle Protokolle mit hineinzupacken...

Das wird knapp.

Ich sehe da aber noch Einsparungspotential. Durch geeignete 
Parametrisierung könnte ich die Behandlung der Manchester-basierten 
Protokolle (Bi-Phase) für RC5, RC6, GRUNDIG, NOKIA und SIEMENS noch 
weiter zusammenfassen und dadurch Code einsparen. Könnte dann aber etwas 
CPU-intensiver werden.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Lesenswert?

Hier nochmal eine kompaktere Darstellung, siehe Anhang. Sehr schön sieht 
man hier, dass die 4 Bits 20-23 in der Wiederholung von 0 auf 1 
wechseln.

Entweder ist das ein "Loslassen"-Flag oder das Zeichen für eine 
Wiederholung. Das müsste eku mal systematisch testen - durch kurze und 
lange Tastendrücke.

Da bei einigen Tasten der zweite Frame fehlt, nehme ich mal an, dass eku 
hier die jeweilige Taste nur kurz gedrückt hat. Damit wären die 4 
1er-Bits ein Zeichen für die Wiederholung, nicht das Loslassen.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Frank M. schrieb:

> Nein, für mich sieht das wie ein Matrix-Code aus, halt so, wie die
> Tastatur verdrahtet ist. Vielleicht kannst Du ja mehr damit anfangen.

Es ist definitiv ein Matrix-Code, ich habe mal die mir zur Verfügung 
stehenden Tasten-Scans bitweise gruppiert:
1
# 1
2
  ADRESSE        ??????   REPEAT ?????    SPALTE  ZEILE  ?
3
11111100000000   000000   0000   010000    00101  1111   1
4
11111100000000   000000   1111   010000    00101  1111   1
5
-------------------------------------------------------------------
6
# 2
7
11111100000000   000000   0000   110000    00001  1111   1
8
11111100000000   000000   1111   110000    00001  1111   1
9
-------------------------------------------------------------------
10
# 3
11
11111100000000   000000   0000   001000    00110  1111   1
12
11111100000000   000000   1111   001000    00110  1111   1

Dann ergibt sich folgende Matrix, die genau zu obigem Schema passt:

1
         Spalte   Spalte   Spalte   Spalte   Spalte   Spalte   Spalte             Spalte   Spalte   Spalte   Spalte
2
          00011    00101    00001    00110    00010    00100    00000              00111    00011    00101    00001
3
       +--------+--------+--------+--------+--------+--------+--------+         +--------+--------+--------+--------+--------+--------+
4
       +        +        +        +        +        +        +        +         +        +        +        +        +        +        +
5
 ZEILE +        +   1    +   2    +   3    +   4    +   5    +   6    +   ZEILE +    7   +    8   +    9   +   0    +        +        +
6
  1111 +        +        +        +        +        +        +        +    0111 +        +        +        +        +        +        +
7
       +--------+--------+--------+--------+--------+--------+--------+         +--------+--------+--------+--------+--------+--------+
8
         Spalte   Spalte   Spalte   Spalte   Spalte   Spalte   Spalte             Spalte   Spalte   Spalte   Spalte
9
          00011    00101    00001    00110    00010    00100    00000              00111    00011    00101    00001
10
       +--------+--------+--------+--------+--------+--------+--------+         +--------+--------+--------+--------+--------+--------+
11
       +        +        +        +        +        +        +        +         +        +        +        +        +        +        +
12
 ZEILE +   Q    +   W    +   E    +   R    +   T    +   Z    +   U    +   ZEILE +    I   +    O   +    P   +        +        +        +
13
  1011 +        +        +        +        +        +        +        +    0011 +        +        +        +        +        +        +
14
       +--------+--------+--------+--------+--------+--------+--------+         +--------+--------+--------+--------+--------+--------+
15
         Spalte   Spalte   Spalte   Spalte   Spalte   Spalte   Spalte             Spalte   Spalte   Spalte   Spalte
16
          00011    00101    00001    00110    00010    00100    00000              00111    00011    00101    00001
17
       +--------+--------+--------+--------+--------+--------+--------+         +--------+--------+--------+--------+--------+--------+
18
       +        +        +        +        + LEER   +        +        +         +        +        +        +        +        +        +
19
 ZEILE +        +        +        +        + TASTE  +        +        +   ZEILE +        +        +        +        +        +        +
20
  0001 +        +        +        +        +        +        +        +    ???? +        +        +        +        +        +        +
21
       +--------+--------+--------+--------+--------+--------+--------+         +--------+--------+--------+--------+--------+--------+

Leider hat eku nur die Tasten 1234567890, qwertzuiop und die Leertaste 
gescannt. Bis dahin passt das Schema aber wie die Faust aufs Auge.

Fragt sich nur, was die Bits bedeuten, die ich mit Fragezeichen versehen 
habe. Vielelicht die Bits für STRG, ALT, SHIFT?

Bin gespannt auf mehr Input von eku.

Gruß,

Frank

von eku (Gast)


Lesenswert?

Frank M. schrieb:
> Leider hat eku nur die Tasten 1234567890, qwertzuiop und die Leertaste
> gescannt. Bis dahin passt das Schema aber wie die Faust aufs Auge.

Nun sei doch nicht su ungeduldig :-) Kommt Zeit, kommt Scan :-)

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:
> Nun sei doch nicht su ungeduldig :-) Kommt Zeit, kommt Scan :-)

Och, lass mich doch... das ist spannender als Sudoku-Spielen ;-)

Gruß,

Frank

von Torsten K. (nobby)


Lesenswert?

Hallo,

ich bekomme leider mit der Pollin Tastatur immer nur RC5 oder Siemens 
Protokoll angezeigt. Bei mit läuft das ganze auf einem Mega 168 mit 8mHz 
Quarz.
Hab natürlich die Version 1.6 und den  F_INTERRUPTS auf 15000 gestellt.

Gruß
Torsten

von eku (Gast)


Lesenswert?

Frank M. schrieb:
> Ich habe Deine Änderungswünsche eingearbeitet und bei der Gelegenheit
> die UART-Register bzw. -Kontanten portabel definiert, so dass das
> Übersetzen nun auf jedem ATMEGA funktionieren sollte.
>
> Kommt dann im nächsten Release.

Ich nutze SVN und freue mich über jeden Commit. Ich brauche kein 
Release, Zwischenstand aus SVN reicht mit.

von Torsten K. (nobby)


Angehängte Dateien:

Lesenswert?

Ich hab hier mal einen kleinen Scan von den Tasten 0 bis 9 eingestellt, 
vielleicht hilft das für eine kurze Analyse.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Torsten Kalbe schrieb:
> Ich hab hier mal einen kleinen Scan von den Tasten 0 bis 9 eingestellt,
> vielleicht hilft das für eine kurze Analyse.

Deine Tastatur hat ein ganz anderes Timing.

Die Pulszeiten in Deinem Scan sind etwa doppelt so lang wie die bei eku. 
Ausserdem gibt es zwischendurch "Aussetzer", wo die Pulszeiten sogar auf 
die 4-fache Länge anwachsen.

Dagegen haben die Pause-Zeiten nur die Hälfte der Länge wie bei der 
Tastatur von eku - und das mit einer erheblichen Streuung.

Ein paar Fragen dazu:

1. Bist Du sicher, dass der Interrupt-Takt 15kHz und nicht mehr beträgt?

2. Welchen Timer benutzt Du?

3. Werden andere FBs bei 15kHz und 8MHz-Takt ohne Probleme erkannt?

4. Gab es Compiler-Warnungen?

5. Bist Du sicher, dass der Quarz auch genutzt wird und nicht nur der
   interne Oszillator läuft?

Vielleicht reicht auch bei der Vielzahl der mittlerweile unterstützten 
Protokolle und dem erhöhten Interrupt-Takt von 15kHz der Takt von 8MHz 
nicht mehr aus.

Schalte mal soviel wie möglich an Protokollen ab und teste dann nochmal.

Ich habe mir die Tastatur mittlerweile selbst bestellt, damit ich in den 
nächsten Tagen auch mal selbst testen kann.

Gruß,

Frank

von Torsten K. (nobby)


Lesenswert?

Na,

also was den Quarz angeht, das habe ich im AVR Studio so eingestellt, 
bzw. die Fuse so gesetzt.

Ob der Proz. wirklich den Interrupt-Takt 15kHz hat müßte ich mal 
nachschauen/messen.
Ich nutze den OCR1A.
Andere FBs mit 15kHz habe ich nicht.

Ich werde morgen mal nachmessen, ich kann auch den wirklichen Takt des 
IR Signals mal mit dem Scope nachmessen, dann sehen wir ja was los ist.

Gruß
Torsten

von eku (Gast)


Lesenswert?

Hallo Frank!

Änderungswunsch für irmp_ISR(): return irmp_ir_detected;

Vorteil: nach Aufruf von irmp_ISR() weiß der Aufrufer sofort, ob eine 
Sequenz dekodiert wurde und muss nicht extra irmp_get_data() aufrufen. 
Konsequenterweise könnte der Test auf irmp_ir_detected in 
irmp_get_data() entfallen. "Geradeaus-" uns "Kasko-"Programmierer 
benötigen den Test.

Vergelcihe mit irsnd_ISR(): liefert irsnd_busy zurück. Die 
while-Schleife in irsnd_send_data() finde ich schlecht. Sowas regelt man 
über Return-Codes. Soll doch der Aufrufer entscheiden, wie er darauf 
reagiert.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:

> Änderungswunsch für irmp_ISR(): return irmp_ir_detected;

Kann ich gerne einbauen. Ich selbst würde das aber nicht nutzen und auch 
nicht in Beispielen dokumentieren. Denn normalerweise wird irmp_ISR() 
aus einer Interrupt-Funktion aufgerufen... und diese ist 
definitionsgemäß void.

Okay, Du könntest Dir dann in der Applikation eine globale Variable 
setzen und dann irmp_get_data() gezielt aufrufen.

Aber wo ist der Unterschied? irmp_get_data() macht sofort einen return, 
wenn irmp_ir_detected == FALSE. Das einzige, was Du maximal sparst, ist 
ein Funktionsaufruf.

> Vorteil: nach Aufruf von irmp_ISR() weiß der Aufrufer sofort, ob eine
> Sequenz dekodiert wurde und muss nicht extra irmp_get_data() aufrufen.

Ich sehe da keinen Vorteil, sorry. Ich sehe da nur schlechten 
Programmierstil.

> Konsequenterweise könnte der Test auf irmp_ir_detected in
> irmp_get_data() entfallen.

Nein, werde ich auf keinen Fall rausnehmen, sonst muss der Programmierer 
genau das machen, was ich oben beschrieb: irmp_ISR() aufrufen, den 
Return-Wert in einer globalen Variablen speichern und in der 
main-Routine dann auf diese globale Variable testen.

Da ich mich schon seit 25 Jahren mit UNIX beschäftige, selbst auch schon 
einige Device-Treiber für UNIX und LINUX geschrieben habe, denke ich, 
dass mein Verfahren eher einem vernünftigen Interface entspricht.

> "Geradeaus-" uns "Kasko-"Programmierer benötigen den Test.

Was sind "Geradeaus-" uns "Kasko-"Programmierer? ;-)

Beschreibe bitte ein Szenario, wo das nötig ist. Das einzige, was Du mit 
Deinem Verfahren sparst, ist ein Funktionsaufruf aus Deiner 
Main-Routine.

> Vergelcihe mit irsnd_ISR(): liefert irsnd_busy zurück.

Ja, aber nur deshalb, damit man irmp_ISR() und irsnd_ISR() so 
kombinieren kann, dass sie sich nicht ins Gehege kommen, vergleiche dazu 
den IRMP-Artikel:

http://www.mikrocontroller.net/articles/IRMP#Source-Code_2

<zitat>

Möchte man IRMP und IRSND parallel verwenden (also als Sender und 
Empfänger) schreibt man die ISR folgendermaßen:
1
ISR(TIMER1_COMPA_vect)
2
{
3
  if (! irsnd_ISR())          // call irsnd ISR
4
  {                           // if not busy...
5
      irmp_ISR();             // call irmp ISR
6
  }
7
  // call other timer interrupt routines...
8
}

Das heisst: Nur wenn irsnd_ISR() nichts zu tun hat, dann rufe die ISR 
des Empfängers auf. Damit ist der Empfänger solange abgeschaltet, 
während irsnd_ISR() noch Daten sendet. Die Timer-Initialisierungsroutine 
ist für IRMP und IRSND dann natürlich dieselbe.

</zitat>

> Die
> while-Schleife in irsnd_send_data() finde ich schlecht. Sowas regelt man
> über Return-Codes. Soll doch der Aufrufer entscheiden, wie er darauf
> reagiert.

Naja, darüber kann man streiten. Wenn der Ausgangsbuffer eines seriellen 
Kanals voll ist, dann wartet die UNIX-Systemfunktion write() auch, bis 
wieder "Platz" da ist. Jedenfalls im Normalfall - solange man das nicht 
mittels eines ioctl-Aufrufs umstellt. Dasselbe gilt in der Regel 
eigentlich auch für Windows-Systemfunktionen. Analoges gilt auch für 
TCPIP-Stacks, wenn Du da auf Sockets schreibst. Die Dinger warten immer, 
wenn das Gerät (z.B. Ethernet-Karte) zu langsam ist.

<EDIT>
Die Dinger warten immer aus Sicht der Applikation, nicht aus der Sicht 
des Kernels natürlich.
</EDIT>

Ich schlage da folgenden Kompromiss vor:
1
uint8_t irsnd_send_data (IRMP_DATA * irmp_data_p, uint8_t do_wait)

Das heisst: mittels TRUE oder FALSE für do_wait kannst du selbst 
bestimmen, ob irsnd_send_data() sofort mit einem Fehler zurückkommen 
soll oder selbst wartet, bis das "Ausgabegerät" - also die IR-Diode - 
wieder frei ist.

Gruß,

Frank

P.S.
Ich werde im Laufe des Tages mal ein Update im SVN einspielen.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Frank M. schrieb:

> Es ist definitiv ein Matrix-Code, ich habe mal die mir zur Verfügung
> stehenden Tasten-Scans bitweise gruppiert:

Mittlerweile bin ich bei der "Entschlüsselung" weiter. Die Matrix ist 
noch einfacher, als ich zunächst gedacht habe. Ausserdem steckt in dem 
IR-Telegramm der Tastatur Redundanz drin, nämlich nicht nur Zeile und 
Spalte, sondern auch noch ein Key-Code, der sich eigentlich aus Zeile 
und Spalte berechnen lässt.

Im Moment sieht das bisher entschlüsselte Format folgendermaßen aus:
1
-------------------------------------------------------------------
2
# 1
3
  ADRESSE        STATUS   REPEAT KEYCODE   SPALTE ZEILE   KEYCODE Spalte Zeile
4
11111100000000   000000   0000   01000000  1011   1111       2      13    15
5
11111100000000   000000   1111   01000000  1011   1111
6
-------------------------------------------------------------------
7
# 2
8
11111100000000   000000   0000   11000000  0011   1111       3      12    15
9
11111100000000   000000   1111   11000000  0011   1111
10
-------------------------------------------------------------------
11
# 3
12
11111100000000   000000   0000   00100000  1101   1111       4      11    15
13
11111100000000   000000   1111   00100000  1101   1111
14
-------------------------------------------------------------------

(Alle Binärzahlen mit LSB-first lesen!)

Verbleibt nur noch die Entschlüsselung der 6 Bits, die ich mit "STATUS" 
bezeichnet habe. Da vermute ich mal, dass dort die Zustände der 
Sondertasten - wie SHIFT, STRG, ALT usw. - gesendet werden. Es kann 
natürlich auch sein, dass die ADRESSE im Telegramm in Wirklichkeit 
kürzer ist und weitere Bits des Blocks ADRESSE mit Infos versehen sind. 
Die bekomme ich aber erst raus, wenn weitere Scans vorliegen.

Da obige Binär-Zahlengruppen immer mit LSB-first gelesen werden müssen, 
ergibt sich folgende Matrix:
1
         Spalte
2
         15   14   13   12   11   10   9    8    7    6    5    4    3    2    1    0
3
       +----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+
4
 ZEILE +    +    + 1  + 2  + 3  + 4  + 5  + 6  + 7  + 8  + 9  + 0  +    +    +    +    +
5
  15   + 0  + 1  + 2  + 3  + 4  + 5  + 6  + 7  + 8  + 9  + 10 + 11 + 12 + 13 + 14 + 15 +
6
       +----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+
7
 ZEILE +    + Q  + W  + E  + R  + T  + Z  + U  + I  + O  + P  +    +    +    +    +    +
8
  14   + 16 + 17 + 18 + 19 + 20 + 21 + 22 + 23 + 24 + 25 + 26 + 27 + 28 + 29 + 30 + 31 +
9
       +----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+
10
 ZEILE +    +    +    +    +    +    +    +    +    +    +    +    +    +    +    +    +
11
  13   + 32 + 33 + 34 + 35 + 36 + 37 + 38 + 39 + 40 + 41 + 42 + 43 + 44 + 45 + 46 + 47 +
12
       +----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+
13
 ZEILE +    +    +    +    +    +    +    +    +    +    + -  +    +    +LEER+    +    +
14
  12   + 48 + 49 + 50 + 51 + 52 + 53 + 54 + 55 + 56 + 57 + 58 + 59 + 60 + 61 + 62 + 63 +
15
       +----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+

In den Kästchen ist - soweit bekannt - eingetragen:

1. Aufdruck der Taste, also 1234567890, QWERTZUIOP und LEER
2. Keycode der Taste

Gruß,

Frank

von eku (Gast)


Lesenswert?

Frank M. schrieb:
> Okay, Du könntest Dir dann in der Applikation eine globale Variable
> setzen und dann irmp_get_data() gezielt aufrufen.

Interruptroutine und Anwendung (main) sind bei mir über FIFOs sowohl in 
Sende- als auch in Empfangsrichtung ge/ent-koppelt. Das erklärt 
hoffentlich meine Änderungswünsche:
1
ISR (TIMER0_COMP_vect)
2
{
3
  uint8_t data = PIN (IR_RX_PORT) & _BV (IR_RX_PIN);
4
5
  if (data == IR_RX_MARK)
6
    IR_RX_LED_ON;
7
  else
8
    IR_RX_LED_OFF;
9
10
  if (irmp_ISR (data) != 0)
11
    { // Sequenz dekodiert -> umspeichern
12
      uint8_t tmphead = FIFO_NEXT (ir_rx_fifo.write);
13
      if (tmphead != ir_rx_fifo.read)
14
        {
15
          if (irmp_get_data (&ir_rx_fifo.buffer[tmphead]))
16
            ir_rx_fifo.write = tmphead;
17
        }
18
    }
19
#ifdef IR_TX_PORT
20
  if (irsnd_ISR () == 0)
21
    { // Sender frei -> neue Sequenz laden
22
      if (ir_tx_fifo.read != ir_tx_fifo.write)
23
        irsnd_send_data (&ir_tx_fifo.buffer[ir_tx_fifo.read = FIFO_NEXT (ir_tx_fifo.read)]);
24
    }
25
#endif

Eine Verriegelung von Sender und Empfänger habe ich bewusst "ausgebaut".

Ich kann auch weiterhin auf den SVN-Stand meinen Patch anwenden und Du 
lässt alles so wie es ist.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:

> Interruptroutine und Anwendung (main) sind bei mir über FIFOs sowohl in
> Sende- als auch in Empfangsrichtung ge/ent-koppelt. Das erklärt
> hoffentlich meine Änderungswünsche:

Nett, Du könntest damit ja Megabytes an Daten übertragen ;-)

> Ich kann auch weiterhin auf den SVN-Stand meinen Patch anwenden und Du
> lässt alles so wie es ist.

Nein, ich baue den Return-Wert in irmp_ISR() ja ein, kann ja durchaus 
für manche Szenarien sinnvoll sein. Ebenso das wait-Flag in irsnd_ISR().

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Sodele, Version 1.6.1 ist nun im SVN.

Änderungen:

 - Interface von irmp_ISR() geändert: gibt flag zurück, ob Frame
   empfangen wurde

 - Interface von irsnd_send_data() geändert: Nun auch Senden ohne
   Warteschleife möglich

 - UART-Routinen angepasst, damit das IRMP-Logging ohne Änderung
   auf allen ATMEGAs läuft

 - Debug-Output-Format angepasst für:

     Silent-Mode:  Option -s
     Verbose-Mode: Option -v
     Normal-Mode:  <keine Option>

Da diese (teils gravierenden) Änderungen noch nicht im IRMP-Artikel 
dokumentiert sind, gibt es auch noch keinen Download über den Artikel. 
Vielmehr werde ich dort vermerken, dass die SVN-Version keine 
Release-Version ist.

Gruß,

Frank

von eku (Gast)


Lesenswert?

Frank M. schrieb:
> Ich werde im Laufe des Tages mal ein Update im SVN einspielen.

Danke, aber UART0_UDR ist nicht definiert. Fehlt im Block '#ifdef 
UBRR0H'.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:
> Danke, aber UART0_UDR ist nicht definiert. Fehlt im Block '#ifdef
> UBRR0H'.

Upps, ich hatte das durch eine schematische Änderung in die Konstante 
UART0_UDR_BIT_VALUE geändert... war natürlich Käse.

Ist korrigiert,

Frank

von Torsten K. (nobby)


Lesenswert?

Hallo,

ich habe jetzt meine Tastatur mal vermessen, direkt am IR Empfänger.
Gemessen mit einem Tektronix 2014.

2120 mS Low
920 µS High
330 µS Low
690 µS High
310 µS Low
680 µS High

Die 690 µS High, 310 µS Low wiederholen sich 6 mal.
Dann kommt

190 µS High
350 µS Low

Das wiederholt sich auch viele male und wird dann auch mal von einer
690 µS High, 310 µS Low Kombination unterbrochen.

Ich hab das mal so ins define umgesetzt

#define FDC_START_BIT_PULSE_TIME                2120.0e-6
#define FDC_START_BIT_PAUSE_TIME                 920.0e-6
#define FDC_PULSE_TIME                           330.0e-6
#define FDC_1_PAUSE_TIME                         690.0e-6
#define FDC_0_PAUSE_TIME                         190.0e-6

Ich bin mir nicht sicher ob ich das richtig gemacht habe, aber immerhin 
bekomme ich damit auch mal einen FDC Datensatz, allerdings tauchen dann 
auch noch RC5 und Siemens mit auf.

Wenn ich RC5 und Siemens beim compilieren deaktiviere erhalte ich die 
FDC Datensätze. Soweit mir das aussieht auch bei jeder Taste einen 
anderen.

Gruß
Torsten

von eku (Gast)


Lesenswert?

Hallo Frank und Torsten!

Auch ich kann mit IRMP keinen FDC-Code dekodieren, wechselnd RCx und 
SIEMENS. Beim Testen ist mir noch aufgefallen, dass last_pause noch von 
anderen Protkollen als RCx und SIEMENS benötigt wird -> Compilerfehler.

von Torsten K. (nobby)


Lesenswert?

Hy eku,

dann versuch doch mal die defines von mir und schalte den Siemens und 
RC5 ab, dann sollte es gehen.
Vielleicht hilft das Frank um zu erkennen woran es noch liegen kann.
Ich bin gerne bereit das hier weiter mit dem Scope zu vermessen.

Um nochmal auf die Taktung zu kommen.
Ich habe bei mir mal einen Pin wechseln lassen, wenn der in den OCR 
Interrupt geht.
Mit dem 8mhz Quarz habe ich exakt 15kHz, mache ich das mit dem internen 
RC Oscal bin ich bei 15,6kHz.
Daran ändern auch das auslesen des Oscal Calibration Byte nichts, das 
kann an der Toleranz liegen.

Gruß

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Torsten,

Torsten Kalbe schrieb:

> ich habe jetzt meine Tastatur mal vermessen, direkt am IR Empfänger.
> Gemessen mit einem Tektronix 2014.
>
> 2120 mS Low

Sicher, dass es nicht 2120 µs waren? ms kommt mir verdammt lang vor ;-)

> 920 µS High
> 330 µS Low
> 690 µS High
> 310 µS Low
> 680 µS High
>
> Die 690 µS High, 310 µS Low wiederholen sich 6 mal.
> Dann kommt
>
> 190 µS High
> 350 µS Low
>
> Das wiederholt sich auch viele male und wird dann auch mal von einer
> 690 µS High, 310 µS Low Kombination unterbrochen.

Das sieht ziemlich kaputt aus. Diese Timings habe ich auch im Scan 
gesehen, konnte es aber kaum glauben, denn bei ekus Tastatur waren 
Timings:

Start-Bit   1390µs Puls, 640µs Pause
0-Bit        200µs Puls, 145µs Pause
1-Bit        200µs Puls, 475µs Pause
Stop-Bit     200µs Puls

Siehe auch IRMP-Artikel:

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

Dort habe ich alle Timings dokumentiert.

Bis auf das Start-Bit waren also alle Pulse gleich lang. Bei Dir ist das 
komplett anders. Die 190µs-Pause fällt auch komplett aus dem Rahmen.

> Ich hab das mal so ins define umgesetzt
>
> #define FDC_START_BIT_PULSE_TIME                2120.0e-6

Korrekt

> #define FDC_START_BIT_PAUSE_TIME                 920.0e-6

Korrekt.

> #define FDC_PULSE_TIME                           330.0e-6

Jepp.

> #define FDC_1_PAUSE_TIME                         690.0e-6
> #define FDC_0_PAUSE_TIME                         190.0e-6

Da glaube ich eher, dass es umgekehrt ist. Die 0en kommen öfter vor als 
die 1en. Aber das ist erstmal nebensächlich, dann ist das bei Dir halt 
erstmal invertiert.

> Ich bin mir nicht sicher ob ich das richtig gemacht habe, aber immerhin
> bekomme ich damit auch mal einen FDC Datensatz, allerdings tauchen dann
> auch noch RC5 und Siemens mit auf.

Das passiert, wenn sich ein Bit im Frame nicht an die vorgegebenen 
Zeiten hält. Dann "sucht" IRMP nach dem nächsten Start-Bit, um sich 
wieder zu synchronisieren. Dabei "erkennt" IRMP dann ein Daten-Bit des 
FDC-Stroms als Start-Bit von RC5 oder Siemens und klinkt sich dann dort 
wieder ein - fälschlicherweise. Da muss man dann die Toleranzen für die 
Daten-Bits höher drehen - nicht für die Start-Bits. Ich schicke Deinen 
Scan gleich nochmal durch den IRMP unter Linux und passe die Toleranzen 
an. Vielleicht klappt das. Allerdings sind bei Deiner Tastatur 
erhebliche Streungen im Timing. Vielleicht ist das Ding ja einfach nur 
kaputt?

> Wenn ich RC5 und Siemens beim compilieren deaktiviere erhalte ich die
> FDC Datensätze. Soweit mir das aussieht auch bei jeder Taste einen
> anderen.

Gut, ein Hoffnungsschimmer. Dann probiere ich mal, das als 
"FDC2"-Protokoll zu implementieren. Blöd, dass es da wieder eine 
Variante gibt. Bin mal gespannt, was meine bestellten Tastaturen 
aussenden... hoffentlich nicht noch eine dritte Variante...

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi eku,

eku schrieb:
> Auch ich kann mit IRMP keinen FDC-Code dekodieren, wechselnd RCx und
> SIEMENS. Beim Testen ist mir noch aufgefallen, dass last_pause noch von
> anderen Protkollen als RCx und SIEMENS benötigt wird -> Compilerfehler.

Wieso das? Das lief doch vorgestern noch bei Dir... ich habe die Timings 
seitdem nicht mehr geändert... merkürdig.

Habe gerade nochmal den Source im SVN gegen die Scan-Datei von Dir 
laufen lassen: FDC wird eindeutig erkannt. Du musst da noch irgendwas 
geändert haben... eine andere Erklärung habe ich nicht. Oder spinnt 
Deine Tastatur jetzt auch so rum wie die von Torsten?

Gibt es da vielleicht auf der Unterseite der Tastatur einen 
Schiebeschalter, mit dem man das Protokoll umschalten kann, damit sich 2 
baugleiche Tastaturen in einem Raum nicht ins Gehege kommen? Bei 
Funktastaturen habe ich das schon öfter mal gesehen...

Gruß,

Frank

von Torsten K. (nobby)


Angehängte Dateien:

Lesenswert?

Ich hab hier mal Taste 1 in "Bildform".

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Torsten Kalbe schrieb:

> 190 µS High
> 350 µS Low

Hier mal der irmp-Output von Deinem Scan (Option -a zeigt nur Timings):
1
# Model No.:FDC-3402
2
-------------------------------------------------------------------
3
# Taste 1
4
pulse: 33 pause: 12
5
pulse: 7 pause: 9
6
pulse: 5 pause: 10
7
pulse: 5 pause: 10
8
pulse: 6 pause: 10
9
pulse: 5 pause: 10
10
pulse: 6 pause: 9
11
pulse: 5 pause: 3
12
pulse: 5 pause: 3
13
pulse: 5 pause: 2
14
pulse: 6 pause: 2
15
pulse: 6 pause: 2
16
pulse: 6 pause: 2
17
pulse: 6 pause: 2
18
pulse: 5 pause: 3
19
pulse: 6 pause: 1
20
pulse: 6 pause: 3
21
pulse: 6 pause: 1
22
pulse: 6 pause: 2
23
pulse: 6 pause: 2
24
pulse: 5 pause: 3
25
pulse: 14 pause: 1
26
pulse: 6 pause: 2
27
pulse: 6 pause: 2
28
pulse: 5 pause: 3
29
pulse: 5 pause: 10
30
pulse: 6 pause: 2
31
pulse: 6 pause: 2
32
pulse: 5 pause: 3
33
pulse: 5 pause: 3
34
pulse: 5 pause: 3
35
pulse: 5 pause: 2
36
pulse: 6 pause: 10
37
pulse: 4 pause: 3
38
pulse: 5 pause: 11
39
pulse: 6 pause: 9
40
pulse: 6 pause: 9
41
pulse: 5 pause: 10
42
pulse: 6 pause: 10
43
pulse: 5 pause: 10

Das Start-Bit ist okay, die Pulsdauern schwanken zwischen 5 und 7, also 
zwischen 330µs und ca. 470µs.

Die Pausen sind offenbar:

9 - 11 = 600µs - 733µs  für 1-Bit
1 - 3  =  66µs - 200µs  für 0-Bit

Und diese Zeile ist der Knackpunkt (s.o.):

pulse: 14 pause: 1

Hier wurde gar keine Pause aufgezeichnet, weil sie einfach zu kurz war!
Dadurch "verlängert" sich die Pulsdauer auf ziemlich genau das Doppelte. 
In Wirklichkeit sind das aber 2 Bits, nämlich in etwa so was:

pulse: 7 pause: 0 <--- Pause zu kurz, wird nicht erkannt
pulse: 7 pause: 1 <--- Pause wird erkannt

Fazit: 15kHz sind zu kurz, um diese Frames mit den sehr kurzen Pulsen 
verlässlich zu detektieren. Das obige Phänomen tritt bei fast allen 
Tasten in Deinem Scan auf, nämlich ungefähr bei 50% der Scans.

Du könntest mal auf 20kHz hochgehen - und die Compiler-Warnungen 
entweder ignorieren oder vermeiden, indem Du z.B. BANG_OLUFSEN (und 
evtl. weitere) abschaltest, bis alle Compiler-Warnungen weg sind.

Gruß,

Frank

von Torsten K. (nobby)


Angehängte Dateien:

Lesenswert?

Ich hab alle Protokolle ausser dem FDC abgeschaltet, aber trotzdem zwei 
Warnungen bekommen.

Tasten 1 bis 4 hängen hier an.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Torsten Kalbe schrieb:
> Ich hab alle Protokolle ausser dem FDC abgeschaltet, aber trotzdem zwei
> Warnungen bekommen.

Okay, darum kümmern wir uns später.

> Tasten 1 bis 4 hängen hier an.

Danke, habe ich mir angeschaut, Deine ausgewählten Timings nochmal ein 
wenig abgeändert, die Toleranzen geändert und das Ganze als Protokol 
FDC2 (= 19) implementiert. Der Source ist im SVN. Damit werden Deine 
Tasten bei 20kHz erkannt. Das Ergebnis der Codes ist identisch mit denen 
von eku.

Deine Tastatur encodiert die Tasten also genauso wie die von eku, aber 
das Timing ist verschieden.

Nochmals meine Frage: Kein Schiebeschalter unter der Tastatur, wo man 
das Timing vielleicht umschalten kann, damit man 2 baugleiche Tastaturen 
in einem Raum nutzen kann?

Test bitte mal den Source bei 20kHz. Sollte Deine Tasten nun einwandfrei 
erkennen.

Ein Knackpunkt ist aber da noch: Ich musste die Toleranzen für RC5 auf 
0% runterschrauben, da das FDC2-Protokoll vom Startbit her mit dem 
RC5x-Protokoll kollidiert. Da muss ich mir also was einfallen lassen, 
denn im Moment wird bei Toleranz von 0% kein RC5 mehr erkannt :-(

Naja, erstmal ist die SVN-Version als Testversion zu sehen.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi eku,

eku schrieb:
> Auch ich kann mit IRMP keinen FDC-Code dekodieren, wechselnd RCx und
> SIEMENS.

Ich bin mir ziemlich sicher, dass Du es geschafft hast, Deine Tastatur 
auf das Timing von Torsten umzuschalten, welches ich mittlerweile als 
FDC2 implementiert habe (siehe SVN). Das Timing von FDC2 kollidiert 
tatsächlich mit RC5 - vom Startbit her. Da suche ich noch nach einer 
Lösung.

> Beim Testen ist mir noch aufgefallen, dass last_pause noch von
> anderen Protkollen als RCx und SIEMENS benötigt wird -> Compilerfehler.

Danke für den Tipp, tatsächlich wird es bei allen Manchester-codierten 
Protokollen benutzt, also auch noch für Grundig und Nokia. Werde ich 
korrigieren.

Gruß,

Frank

von Torsten K. (nobby)


Lesenswert?

Einen Schalter finde ich nicht, vielleicht hat das Ding intern einen 
Jumper oder ähnliches.
EKU schrieb doch aber, das es bei Ihm auch nicht funktioniert hat.

Könnte es vielleicht auch am IR Empfänger liegen 36/38kHz ?

Pollin schreibt zu der Tastatur, das man Applikationen im Internet 
finden könnte, hat da schonmal jemand etwas gefunden. Vielleicht ist da 
auch was übers Timing zu sehen. Ich hab leider bisher nichts gefunden.
Sonst warten wir mal ab, wie es mit weiteren Tastaturen aussieht.

Es gibt übrigens bei Pollin noch einen weiteren Tastaturentyp für 1 
Euro.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Torsten Kalbe schrieb:
> Einen Schalter finde ich nicht, vielleicht hat das Ding intern einen
> Jumper oder ähnliches.

Hm, blöd.

> EKU schrieb doch aber, das es bei Ihm auch nicht funktioniert hat.

Es funktioniert aber bei mir mit den Scan-Dateien, die eku hier

Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"

angehängt hat.

Hier die Timing-Daten, die ich aus ekus Scan-Dateien gewonnen habe:
1
#define FDC1_START_BIT_PULSE_TIME                1390.0e-6                       // 1390 usec pulse
2
#define FDC1_START_BIT_PAUSE_TIME                 640.0e-6                       //  640 usec pause
3
#define FDC1_PULSE_TIME                           200.0e-6                       //  200 usec pulse
4
#define FDC1_1_PAUSE_TIME                         475.0e-6                       //  475 usec pause
5
#define FDC1_0_PAUSE_TIME                         145.0e-6                       //  145 usec pause

Und hier Deine:
1
#define FDC2_START_BIT_PULSE_TIME                2120.0e-6                       // 2120 usec pulse
2
#define FDC2_START_BIT_PAUSE_TIME                 920.0e-6                       //  920 usec pause
3
#define FDC2_PULSE_TIME                           400.0e-6                       //  400 usec pulse
4
#define FDC2_1_PAUSE_TIME                         660.0e-6                       //  660 usec pause
5
#define FDC2_0_PAUSE_TIME                         145.0e-6                       //  140 usec pause

Zwischen diesen Werten liegt ungefähr ein Faktor 1,5.

Dafür gibt es folgende Möglichkeiten als Erklärung:

1. Beide Tastaturen arbeiten vom Timing her tatsächlich identisch
   und einer von Euch beiden arbeitete bei der Scan-Aufnahme mit
   einem Fehler von 150% bei der Timerparametrisierung.

2. Die Tastaturen arbeiten mit einer Abweichnung von 150% - vielleicht
   kosten sie deshalb nur knapp 2 EUR bei Pollin ;-)

Das FDC1-Timing (von eku) kollidiert aber seit Version 1.6.1 nicht mehr 
mit RC5 (weil ich die Toleranzen für RC5 auf 10% reduziert habe), das 
ist nur beim FDC2-Timing (von Dir) der Fall. Also könnte es sein, dass 
die Möglichkeit 1 bei eku der Fall war (zum Zeitpunkt des Scannens), er 
den Fehler mittlerweile korrigiert hat und deshalb nun in dieselbe 
RC5-Falle reinläuft wie Du.

Oder seine Tastatur hat sich umgestellt auf das andere Timing. Nur ein 
neuer Scan von eku kann das aufklären.

Ich bin gespannt auf die Lieferung meiner Tastaturen - ich hatte einfach 
mal frech 5 Stück bestellt. Dann hoffe ich, dass wir mehr Licht ins 
Dunkel bringen.

> Könnte es vielleicht auch am IR Empfänger liegen 36/38kHz ?

Glaube ich nicht.

> Pollin schreibt zu der Tastatur, das man Applikationen im Internet
> finden könnte, hat da schonmal jemand etwas gefunden. Vielleicht ist da
> auch was übers Timing zu sehen. Ich hab leider bisher nichts gefunden.

Nein, da habe ich nichts gefunden.

> Sonst warten wir mal ab, wie es mit weiteren Tastaturen aussieht.

Ja.

> Es gibt übrigens bei Pollin noch einen weiteren Tastaturentyp
> für 1 Euro.

Nämlich welchen?

Gruß,

Frank

von Torsten K. (nobby)


Lesenswert?

Moin,

das Signal selber habe ich mit dem Scope gemessen, und da hatte sich ja 
das Timing bestätigt, welches ich mit der Schaltung gescant habe.

Die Tastatur hat ja ein paar "Funktionstasten", vielleicht kann man 
durch drücken einer solchen gefolgt von einer zweiten das Timing 
verstellen, das wäre eine Möglichkeit.


Die zweite Tastatur ist diese:
http://www.pollin.de/shop/dt/MDk5ODgyOTk-/Computer_und_Zubehoer/Hardware/Tastaturen/Infrarot_Tastatur_SWK_8650.html

Die scheint aber ein ganz einfaches Signal zu haben, könnte ich Dir auch 
mal einen Scan zu schicken.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Torsten Kalbe schrieb:

> das Signal selber habe ich mit dem Scope gemessen, und da hatte sich ja
> das Timing bestätigt, welches ich mit der Schaltung gescant habe.

Stimmt. Wenn Du aber ekus 15kHz-Scan-Datei und Deine 15-kHz-Scan-Datei 
einfach mal in den Editor lädst, siehst Du, dass sowohl Pausen und auch 
Pulsdauern bei eku um den Faktor 1,5 kürzer sind. Dafür haben die Pausen 
in ekus Scan-Datei eine wesentlich geringere Schwankung, so dass der 
Fall "Pause=0" bei ihm trotz kürzerer Zeiten nicht auftritt. Deshalb 
funktionierte es mit seinen Scan-Dateien und meinem linux-irmp mit 15kHz 
perfekt.

Damit bleiben als Möglichkeiten übrig:

1. Beide Tastaturen arbeiten vom Timing her identisch und eku hat
   versehentlich mit 10kHz statt 15kHz (wie angegeben) gescannt.

2. Die Tastaturen arbeiten tatsächlich mit einer Abweichnung von 150%

> Die Tastatur hat ja ein paar "Funktionstasten", vielleicht kann man
> durch drücken einer solchen gefolgt von einer zweiten das Timing
> verstellen, das wäre eine Möglichkeit.

Jau.

Frage: Hattest Du die 1.6.2 mit den von mir angepassten Timings und dem 
neuen Protokoll "FDC2" (=19) aus dem SVN nochmal testen können?

> Die zweite Tastatur ist diese:
> 
http://www.pollin.de/shop/dt/MDk5ODgyOTk-/Computer_und_Zubehoer/Hardware/Tastaturen/Infrarot_Tastatur_SWK_8650.html

Ahja. Die Beschriftung der Tasten ist laut Pollin aber verschieden. Hast 
Du da eine mit deutschem Layout?

> Die scheint aber ein ganz einfaches Signal zu haben, könnte ich Dir auch
> mal einen Scan zu schicken.

Gern!

Gruß,

Frank

von eku (Gast)


Lesenswert?

Frank M. schrieb:
> Wenn Du aber ekus 15kHz-Scan-Datei und Deine 15-kHz-Scan-Datei
> einfach mal in den Editor lädst, siehst Du, dass sowohl Pausen und auch
> Pulsdauern bei eku um den Faktor 1,5 kürzer sind.

Ich komme erst am Wochenende dazu, weitere Scans aufzuzeichnen. Das 
FDC-Protokoll mag zwar im Linux-IRMP erkannt werden, bei mir mit 15kHz 
definiitiv nicht, auch wenn ich RCx und SIEMENS abklemme. Mehr dazu 
morgen.

von eku (Gast)


Angehängte Dateien:

Lesenswert?

Anbei die Tastaturbelegung meiner FDC.

von eku (Gast)


Lesenswert?

15kHz und FDC: return von irmp_ISR() und irmp_get_data() ist jeweils 1, 
aber proto, address und command sind Null

20kHz und FDC: dito

kurze Tastendruck: 3 Frames, 2. und 3. mit Repeat
langer Tastendurck: n Frames, 2. bis n. mit Repeat

20kHz und FDC2: proto FDC2, address 3F, command 0x00-0xFF

kurze Tastendruck: 2 Frames, 2. mit Repeat
langer Tastendurck: n Frames, 2. bis n. mit Repeat

Mit 20kHz liefert irmp_ISR() häufig 1 (irmp_detected), auch wenn keine 
IR-Signale gesendet werden.

von Torsten K. (nobby)


Angehängte Dateien:

Lesenswert?

Hallo Leute,

die Tastatur habe ich noch nicht mit dem neuen FD2 getestet, mache ich 
aber heute noch.

Meine andere Tastatur von Pollin hat eine QWERTY Layout, die Return und 
Sondertasten sind in einer mir momentan fremden Sprache :-)


Ich habe soeben einen neuen Scan einer IR Fernbedienung für 
Modellfahrzeuge aufgenommen, die würde ich sehr gerne entschlüsseln 
können, dann kann ich nämlich endlich meine Rennbahn entsprechend 
verbessern !!

Das ganze sieht auch sehr sehr übersichtlich aus, hab das schon fast 
selber entschlüsselt :-))

Hier eine erste Analyse:

Eine Fernbedienung kann eine Senderadresse von 0 bis 3 haben,
daher 4 Fahrzeuge.

Es können 3 AD Werte und 8 Schalterstellungen gesendet werden.

Die oberen zwei bits scheinen festzulegen, was gesendet wird.
Davon ausgehend das ein langer Puls, 900µS, 1 entspricht:

00, 10, 01, hier werden die AD Werte gesendet
11, dann werden die Schalterstellungen gesendet.

Die nächsten zwei Bits sind dann die vier möglichen Adressen.


Ist das vielleicht zu implementieren ?

von Torsten K. (nobby)


Lesenswert?

Habe jetzt die neu SVN installiert und das funktioniert sehr gut !
Ich bekomme immer FDC2 Codes angezeigt und auch plausible Hex-Zahlen.
Taste 1 entspricht 0x02 und Taste a ist 0x1F.

Frank, Du hast irgendwo geschrieben, ich könnte meinen Scan auch in 
einen Editor laden und könnte dann das Diagramm sehen ?
Was ist damit gemeint ? Kann ich damit so "schöne" Bilder erzeugen wie 
in Deiner Doku zu sehen ist ?
Ich habe allerdings nur Windows laufen.

Gruß
Torsten

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi Torsten,

Torsten Kalbe schrieb:

> Das ganze sieht auch sehr sehr übersichtlich aus, hab das schon fast
> selber entschlüsselt :-))

Sieht sehr einfach aus, sag mir noch die Frequenz, mit der Du das 
gescannt hast.

> Ist das vielleicht zu implementieren ?

Jau, das kriege ich hin. Ich melde mich dann, komme aber wohl frühestens 
heute abend dazu.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Torsten Kalbe schrieb:
> Habe jetzt die neu SVN installiert und das funktioniert sehr gut !

Freut mich.

> Ich bekomme immer FDC2 Codes angezeigt und auch plausible Hex-Zahlen.
> Taste 1 entspricht 0x02 und Taste a ist 0x1F.

Passt, das ist der "Keycode", den ich oben in die Matrix geladen habe.

> Frank, Du hast irgendwo geschrieben, ich könnte meinen Scan auch in
> einen Editor laden und könnte dann das Diagramm sehen ?

Nein, kein Diagramm, Du siehst im Editor halt Folgen von 0en (Puls) und 
1en
(Pause). Bei Dir sind sie 1,5mal länger, also z.B.

00000000000000000000
0000000000000

> Was ist damit gemeint ? Kann ich damit so "schöne" Bilder erzeugen wie
> in Deiner Doku zu sehen ist ?

Die Bilder sind ein Oszi-Bild, nix weiter.

> Ich habe allerdings nur Windows laufen.

Dann scanne Deine Rennbahn-FB mit 10kHz ein und gebe dann ein:

irmp.exe -a < rennbahn.txt

Dann siehst Du eine Häufigkeitsverteilung als "Spektrum", das Ding 
"malt" Dir dann mit ASCII-Zeichen ein paar (unförmige) Glockenkurven. 
Geht aber erst mit Version 1.6.3, die ich gestern nachmittag ins SVN 
eingecheckt habe.

Beispiel für eine ekus Scan mit 15kHz:
1
--------------------------------------------------------------------------------------------------------------
2
START PULSES:
3
 20 oooooooooooooooo 3
4
 21 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 18
5
average: 20.86 = 1390.48 usec
6
--------------------------------------------------------------------------------------------------------------
7
START PAUSES:
8
  9 ooooooooooooooooooooooo 4
9
 10 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 17
10
average: 9.81 = 653.97 usec
11
--------------------------------------------------------------------------------------------------------------
12
PULSES:
13
  3 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 1517
14
  4 oo 41
15
average: 3.03 = 201.75 usec
16
 20  1
17
 21 o 16
18
average: 20.94 = 1396.08 usec
19
--------------------------------------------------------------------------------------------------------------
20
PAUSES:
21
  2 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 741
22
  3 oooooooooooooooooooooooo 179
23
average: 2.19 = 146.30 usec
24
  7 ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 515
25
  8 ooooooooooo 85
26
  9 o 10
27
 10  7
28
average: 7.20 = 480.28 usec
29
--------------------------------------------------------------------------------------------------------------

Daraus kann man die Länge der Pulse/Pausen dann direkt ablesen :-)

irmp.exe -l <rennbahn.txt

Dann siehst Du die Längen der Pulse und Pausen in Zahlen - als Listing.

irmp.exe -v <rennbahn.txt

Zeigt Dir dann Protokoll-Infos an - aber nur, wenn irmp das Protokoll 
bereits kennt.

irmp.exe <rennbahn.txt

Dasselbe, aber kompakter, Fehler werden unterdrückt.

Zusammenfassung:

  -a  analyze
  -l  list
  -v  verbose

Das oben beschriebene gilt - wie gesagt - nur mit der neuesten 
SVN-Version, bei den vorherigen Versionen haben die Optionen andere 
Bedeutungen/Ausgabeformate.

Gruß,

Frank

von Torsten K. (nobby)


Lesenswert?

Hallo,

der Scan von meiner FB ist mit 20kHz gemacht, war noch so eingestellt 
von dern vorherigen Versuchen mit der Tastatur.

Gruß

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Torsten,

Torsten Kalbe schrieb:

> Ich habe soeben einen neuen Scan einer IR Fernbedienung für
> Modellfahrzeuge aufgenommen, die würde ich sehr gerne entschlüsseln
> können, dann kann ich nämlich endlich meine Rennbahn entsprechend
> verbessern !!

Habe das Protokoll in IRMP eingebaut, den Source findest Du im SVN. 
Protocol RCCAR (=20), RC5 muss dafür abgeschaltet werden.

Jeder Frame hat 13 Bits, ich habe sie allesamt mit MSB in irmp_data.code 
abgelegt. Das Ermitteln der Bedeutung der Bits überlasse ich damit Dir, 
Du brauchst Dir ja einfach nur mal die von IRMP ausgegebenen Codes als 
Binärzahl hinzuschreiben.

Viel Spaß,

Frank

von Torsten K. (nobby)


Lesenswert?

Hy,

das funktioniert klasse !!!

Die 13 bits sind auch sehr einfach aufgeteilt. Es müßte aber so 
eingebaut werden, das auch irmp_data.address benutzt wird.

Da es ja in Summe nur 13 bits insgesamt sind, sind die oberen drei immer 
null.
Dann folgen zwei, die die Art der Daten angeben, dann folgen die 
eigentlichen zwei Adressbits, dann 7 Datenbits, das letzte Bit ist wohl 
sowas wie ein Verify, das sorgt dafür, das immer eine ungerade Zahl an 1 
bits gesendet wird.
Aufgeteilt ist es also so:

xxxCCAADDDDDDDDV

Ich weis jetzt nicht, wie kompliziert es ist, aber ich fände es am 
besten, wenn die mit AA bezeichneten bits im irmp_data.address 
übertragen werden, dort wo jetzt immer Null kommt:
xxxxxxxx xxxxxxAA

Ins irmp_data.command käme dann:
xxxxxCCV DDDDDDDD

Gruß
Torsten

von Torsten K. (nobby)


Lesenswert?

Mir ist jetzt noch etwas aufgefallen.
Bei den Datenbits scheint es LSB first zu sein, also so:
xxxCCAA D0 D1 D2 D3 D4 D5 D6 D7 V

besser wäre dann, wenn das irmp_data.command so aussähe:

xxxxxCCV D7 D6 D5 D4 D3 D2 D1 D0

Natürlich kann man diese ganze Bitmanipulation auch im Hauptprogramm 
machen, aber bei den anderen Protokollen wird das ja auch entprechend 
übergeben.

von Torsten K. (nobby)


Lesenswert?

Was ich gerade feststelle ist, das es bei den Adress IDs auch so ist.
Bei den Commandbits wird es dann genauso sein, daher wäre auch da eine 
entsprechende Sortierung besser.

Also nochmal, bisher kommt das alles so im irmp_data.command an:

xxx C0 C1 A0 A1 D0 D1 D2 D3 D4 D5 D6 D7 V

Demnach sollte irmp_data.address so aussehen:
xxxxxxxx xxxxxx A1 A0


Das irmp_data.command würde ich so aufbauen:

xxxxx V C1 C0 D7 D6 D5 D4 D3 D2 D1 D0

Das verify-Bit habe ich ganz nach vorne gestellt. Damit ergibt sich, das 
der zweite Char dann die Daten sind und im ersten steht der Befehl und 
das Verify. Der Befehl kann dann direkt ausmaskiert werden, ohne danach 
noch geschoben zu werden.

Wäre das so ok, bzw. hab ich das verständlich rübergebracht ?

von eku (Gast)


Lesenswert?

Frank M. schrieb:
> Habe das Protokoll in IRMP eingebaut, den Source findest Du im SVN.
> Protocol RCCAR (=20), RC5 muss dafür abgeschaltet werden.

Hier machts sich eine Designschwäche des Dekoders bemerkbar. Dies 
passierte nicht, wenn zunächst die Pegelzeiten gespeichert und getrennt 
auswertet werden, d.h. alle Protokolle auf den Puffer testen. Das 
Festlegen auf ein Protokoll an Hand des Startbits führt bei mehreren 
Protokollen in die Sackgasse.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi Torsten,

Torsten Kalbe schrieb:

> Also nochmal, bisher kommt das alles so im irmp_data.command an:
>
> xxx C0 C1 A0 A1 D0 D1 D2 D3 D4 D5 D6 D7 V
>
> Demnach sollte irmp_data.address so aussehen:
> xxxxxxxx xxxxxx A1 A0
>
>
> Das irmp_data.command würde ich so aufbauen:
>
> xxxxx V C1 C0 D7 D6 D5 D4 D3 D2 D1 D0

Du kannst in irmp.h folgendes einstellen:
1
#define RCCAR_LSB               1   // LSB...MSB

Dann hast Du das schon mal auf LSB first umgestellt.

Der Frame sieht nach Deinen Ausführungen so aus:

Bit 0  1  2  3  4  5  6  7  8  9  10 11 12
    C0 C1 A0 A1 D0 D1 D2 D3 D4 D5 D6 D7 V

Damit die Adresse in irmp_data.address landet, könntest Du schreiben:
1
#define RCCAR_ADDRESS_OFFSET    2   // skip 2 bits
2
#define RCCAR_ADDRESS_LEN       2   // read 2 address bits

Dann sollte in irmp_data.address die Adresse stehen.

Jetzt zu den Kommando-Bits, das ist ein wenig schwierig, denn IRMP kann 
über die Preprocessor-Konstanten bisher nur Adress-Bits und 
Kommando-Bits in irmp_data.address und irmp_data.command aufteilen, wenn 
sie direkt aufeinanderfolgend sind.

Wenn Du schreibst:
1
#define RCCAR_COMMAND_OFFSET     4      // skip 4 bits
2
#define RCCAR_COMMAND_LEN        9      // read 9 bits

... dann fehlen Dir C0 und C1. Das Ganze funktioniert also nicht.

Daher empfehle ich, die Preprocessor-Konstanten bis auf die 
LSB-Geschichte unangetastet zu lassen und erstmal alles als data 
aufzufassen, also bitte nur ändern:
1
#define RCCAR_LSB               1   // LSB...MSB


Die Aufteilung in Adresse und Kommando kannst Du erst am Ende machen, 
nämlich in irmp_get_data().

Dazu fügst Du folgenden Block in irmp_get_data im case-switch ein - 
analog zu den anderen:
1
#if IRMP_SUPPORT_RCCAR_PROTOCOL == 1
2
            case IRMP_RCCAR_PROTOCOL:
3
                // frame in irmp_data:
4
                // Bit 12 11 10 9  8  7  6  5  4  3  2  1  0
5
                //     V  D7 D6 D5 D4 D3 D2 D1 D0 A1 A0 C1 C0   //         10 9  8  7  6  5  4  3  2  1  0
6
                irmp_address = (irmp_command & 0x000C) >> 2;    // addr:   0  0  0  0  0  0  0  0  0  A1 A0
7
                irmp_command = (irmp_command & 0x1000) >> 2 ||  // V-Bit:  V  0  0  0  0  0  0  0  0  0  0
8
                               (irmp_command & 0x0003) << 8 ||  // C-Bits: 0  C1 C0 0  0  0  0  0  0  0  0
9
                               (irmp_command & 0x0FF0) >> 4;    // D-Bits:          D7 D6 D5 D4 D3 D2 D1 D0
10
                rtc = TRUE;                                     // Summe:  V  C1 C0 D7 D6 D5 D4 D3 D2 D1 D0
11
#endif

Baue das bitte so ein. Wenn es klappt, übernehme ich die Änderungen in 
IRMP.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:
> Hier machts sich eine Designschwäche des Dekoders bemerkbar.

Ja, ich weiss, das hatte Dich ja schon vor Monaten (im Januar) gestört.

> Dies passierte nicht, wenn zunächst die Pegelzeiten gespeichert und getrennt
> auswertet werden, d.h. alle Protokolle auf den Puffer testen. Das
> Festlegen auf ein Protokoll an Hand des Startbits führt bei mehreren
> Protokollen in die Sackgasse.

Du hast nur zu einem Teil recht. In diesem Fall (RC5 und FDC2) würde 
auch das nachträgliche Auswerten des Gesamtframes nichts bringen. Es gab 
nämlich im FDC2-Protokoll durchaus Scans, die komplett ohne Fehler 
durch den RC5-Decoder durch laufen. Diese würden auch mit Deiner 
nachträglichen Methode fälschlicherweise als RC5 erkannt werden.

Der Grund liegt am Manchester-Code. Dieser besetzt leider mit den 4 
möglichen Abfolgen

  1-fach Länge Puls
  2-fach Länge Puls
  1-fach Länge Pause
  2-fach Länge Pause

ein breites Spektrum an möglichen Zeiten. Da bei RC5 das Start-Bit nicht 
ausgezeichnet ist (es hat dieselben Timings wie die nachfolgenden 
Daten), ist das geradezu ein Multiprotokoll-Decoder-Killer. Die 
Entwickler bei Siemens haben aus den Erfahrungen auch gelernt und das 
bei RC6 geändert: dort gibt es ein Start-Bit mit einem Timing, das nicht 
in den Daten selbst verwendet wird.

Bei den Pulse-Distance-Protokollen ist das anders. Da gibt es nur 2 
Möglichkeiten (im Start-Bit):

  1-fach Länge Puls
  1-fach Länge Pause

Daher gibt es hier naturgemäß untereinander wesentlich weniger Konflikte 
- bisher nämlich keine.

Deine damals schon vorgeschlagene Methode, den Frame erst nachträglich 
zu bewerten und zu dekodieren, ist wesentlich aufwendiger und kostet 
nicht nur einen Buffer zum Speichern des Frames, sondern auch einen 
wesentlichen Mehraufwand an Code. Ausserdem würde Deine Methode in der 
Kombination RC5+FDC2 oder RC5+RCCAR genauso kläglich versagen, denn auch 
bei der nachträglichen Auswertung würdest Du bestimmte FDC- und 
RCCAR-Frames komplett als RC5 auffassen können, ohne eine Regel zu 
verletzen.

IRMP wechselt sogar on-the-fly das erkannte Protokoll, z.B. vom SAMSUNG 
auf das SAMSUNG32-Protokoll, ebenso vom Grundig- auf das 
Nokia-Protokoll, wenn plötlzich mitten im Frame andere Bedingungen 
auftreten. Was IRMP nicht kann, ist von einem Manchester-Protokoll auf 
ein Puls-Distanz-Protokoll zu wechseln, da hier die bisher decodierten 
Bits nicht mehr "umzurechnen" sind.

Mein Fazit: Aus obigen Gründen halte ich an der Methode, wie IRMP die 
Protokolle detektiert, fest. Dass es bei mittlerweile 20 Protokollen, 
die IRMP "versteht", zu Konflikten kommen kann, halte ich für durchaus 
normal. Wenn diese Konflikte auch nur bei exotischen Protokollen (bzw. 
Kombinationen) auftreten, halte ich das auch für durchaus akzeptabel. 
Ich kann mir auch nicht vorstellen, dass ein Decoder für eine Rennbahn 
auch noch RC5 kennen muss.

Bei den Main-Stream-Protokollen gibt es im IRMP keine Konflikte. Das 
reicht für die meisten Anwendungen aus.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Frank M. schrieb:

> Dazu fügst Du folgenden Block in irmp_get_data im case-switch ein -
> analog zu den anderen:
>
1
> #if IRMP_SUPPORT_RCCAR_PROTOCOL == 1
2
> ...
3
> #endif

Ein blöder Tippfehler: Statt den beiden "||" muss es natürlich jedesmal 
"|" heissen, also:
1
#if IRMP_SUPPORT_RCCAR_PROTOCOL == 1
2
            case IRMP_RCCAR_PROTOCOL:
3
                // frame in irmp_data:
4
                // Bit 12 11 10 9  8  7  6  5  4  3  2  1  0
5
                //     V  D7 D6 D5 D4 D3 D2 D1 D0 A1 A0 C1 C0   //         10 9  8  7  6  5  4  3  2  1  0
6
                irmp_address = (irmp_command & 0x000C) >> 2;    // addr:   0  0  0  0  0  0  0  0  0  A1 A0
7
                irmp_command = (irmp_command & 0x1000) >> 2 |   // V-Bit:  V  0  0  0  0  0  0  0  0  0  0
8
                               (irmp_command & 0x0003) << 8 |   // C-Bits: 0  C1 C0 0  0  0  0  0  0  0  0
9
                               (irmp_command & 0x0FF0) >> 4;    // D-Bits:          D7 D6 D5 D4 D3 D2 D1 D0
10
                rtc = TRUE;                                     // Summe:  V  C1 C0 D7 D6 D5 D4 D3 D2 D1 D0
11
                break;
12
#endif

Gruß,

Frank

von eku (Gast)


Angehängte Dateien:

Lesenswert?

eku schrieb:
> Ich komme erst am Wochenende dazu, weitere Scans aufzuzeichnen.

Die versprochenen Scans bei 20kHz, Reihe für Reihe von oben nach unten 
(vgl. Beitrag "Re: IRMP - Infrared Multi Protocol Decoder").

von eku (Gast)


Lesenswert?

Hallo Frank!

Könntest Du bitte die Variable irmp_pause_time auf uint16_t setzen um 
den Überlauf bei höheren Sampleraten zu verhindern.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:
> Die versprochenen Scans bei 20kHz, Reihe für Reihe von oben nach unten

Danke, schaue ich mir an, bin gespannt...

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:
> Könntest Du bitte die Variable irmp_pause_time auf uint16_t setzen um
> den Überlauf bei höheren Sampleraten zu verhindern.

Habe ich mir auch schon überlegt, die Variable last_pause muss dann aber 
auch auf 16 Bit erhöht werden.

Kostet zusätzliche 220 Programmcode und mehr Prozessorlast.

Ich überlege es mir noch (bzw. suche nach einer Alternativlösung, evtl. 
unter Benutzung einer Überlaufvariablen). Umschalten auf 16 Bit würde 
ich das auch erst ab F_INTERRUPT > 15000. Darunter braucht man es nicht.

Gruß,

Frank

von Torsten K. (nobby)


Lesenswert?

Hallo Frank,

jo das funktioniert.

Aber warum soll denn die Adresse nicht schon damit ummaskiert werden, 
das würde doch immerhin eine gewisse Gleichmäßigkeit zu den anderen 
Protokollen haben.

Damit die Adresse in irmp_data.address landet, könntest Du schreiben:
#define RCCAR_ADDRESS_OFFSET    2   // skip 2 bits
#define RCCAR_ADDRESS_LEN       2   // read 2 address bits

von Torsten K. (nobby)


Lesenswert?

Um das ganze zu vervollständigen möchte ich das RCCar jetzt auch noch in 
den IRSND einfügen.

Das habe ich schon gemacht:

in der irsndconfig.h habe ich eingefügt:
1
#define IRMP_SUPPORT_RCCAR_PROTOCOL             1       // flag: support RC car

in der irsnd.h habe ich eingefügt:
1
#define RCCAR_START_BIT_PULSE_LEN               (uint8_t)(F_INTERRUPTS * RCCAR_START_BIT_PULSE_TIME + 0.5)
2
#define RCCAR_START_BIT_PAUSE_LEN               (uint8_t)(F_INTERRUPTS * RCCAR_START_BIT_PAUSE_TIME + 0.5)
3
#define RCCAR_PULSE_LEN                         (uint8_t)(F_INTERRUPTS * RCCAR_PULSE_TIME + 0.5)       
4
#define RCCAR_1_PAUSE_LEN                       (uint8_t)(F_INTERRUPTS * RCCAR_1_PAUSE_TIME + 0.5)   
5
#define RCCAR_0_PAUSE_LEN                       (uint8_t)(F_INTERRUPTS * RCCAR_0_PAUSE_TIME + 0.5) 
6
#define RCCAR_FRAME_REPEAT_PAUSE_LEN            (uint8_t)(F_INTERRUPTS * RCCAR_FRAME_REPEAT_PAUSE_TIME + 0.5)

in der irsnd.c habe ich eingefügt:
1
#if IRMP_SUPPORT_RCCAR_PROTOCOL == 1
2
          case IRMP_RCCAR_PROTOCOL:
3
                    {
4
                        startbit_pulse_len          = RCCAR_START_BIT_PULSE_LEN;
5
                        startbit_pause_len          = RCCAR_START_BIT_PAUSE_LEN;
6
                        complete_data_len           = RCCAR_COMPLETE_DATA_LEN;
7
                        pulse_1_len                 = RCCAR_PULSE_LEN;
8
                        pause_1_len                 = RCCAR_1_PAUSE_LEN;
9
                        pulse_0_len                 = RCCAR_PULSE_LEN;
10
                        pause_0_len                 = RCCAR_0_PAUSE_LEN;
11
                        // has_stop_bit                = FDC1_STOP_BIT;
12
                        n_auto_repetitions          = 1;                                            // 1 frame
13
                        auto_repetition_pause_len   = 0;
14
                        repeat_frame_pause_len      = RCCAR_FRAME_REPEAT_PAUSE_LEN;
15
                        irsnd_set_freq (IRSND_FREQ_38_KHZ);
16
                        break;
17
                    }
18
#endif

Was muß mit dem has_stop_bit gemacht werden und wie ist es mit den 
repetitions, sowas gibt es da alles nicht.

Was wohl noch fehlt sind die eigentlichen Daten, da blicke ich aber noch 
nicht ganz durch was da gemacht werden muß ?
Auf jeden Fall müßte da ja auch wieder "zurückgeschoben" werden, aber 
ich weis nicht genau wo das dann hin muß

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi eku,

eku schrieb:
> Die versprochenen Scans bei 20kHz, Reihe für Reihe von oben nach unten
> (vgl. Beitrag "Re: IRMP - Infrared Multi Protocol Decoder").

Danke, habe sie nun mal durch den IRMP geschickt, Deine Tastatur hat 
dasselbe Timing wie Torsten, die Tasten werden alle als FDC2-Protokoll 
erkannt.

Das heisst, dass Dein damaliger Scan key15.txt aus

  Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"

tatsächlich nur mit 10kHz erzeugt wurde - und nicht mit 15kHz, wie Du 
angegeben hast.

Was auffällig ist: die Timings Deiner Tastatur sind wesentlich exakter, 
sie würde auch bei 10kHz von IRMP einwandfrei erkannt werden. Die 
Streuungen der Puls-/Pausenlängen sind bei Torstens Tastatur wesentlich 
breiter, gerade die Pausen werden zwischendurch arg kurz, so dass hier 
20kHz als Scan-Rate benutzt werden muss.

Woran liegt das? Vielleicht doch am benutzten IR-Empfänger?

Daher Frage an Euch beide (eku und Torsten): welche IR-Empfänger nutzt 
Ihr?

Ich werde das FDC2-Protokoll in FDC umbenennen und das FDC1-Protokoll 
aus dem IRMP wieder rausnehmen. Es gibt keine zwei verschiedenen 
Timings, es gibt nur eins.

Ich melde mich dann später wegen der Tastatur-Matrix nochmal.

Gruß,

Frank

von Torsten K. (nobby)


Lesenswert?

Hy,

ich benutze diesen hier von Reichelt, ich ein 36kHz Typ.

SFH 5110-36
http://www.reichelt.de/?ACTION=3;GROUP=A54;GROUPID=3045;ARTICLE=37920;SID=26P0XrvqwQARoAAALlQXEa9209424a0712a39830a3d1b2f204a48

Ich würde das streuende Timing von mir aber nicht überbewerten, das 
liegt vielleicht auch irgendwo an meiner Platine/Prozessor, oder aber am 
RS232/USB Adapter ?

Ich hatte mir das Signal ja auch auf dem Oszilloskop angeschaut, und da 
konnte ich solche Ausreisser ja garnicht sehen.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi Torsten,

Torsten Kalbe schrieb:

> ich benutze diesen hier von Reichelt, ich ein 36kHz Typ.
>
> SFH 5110-36

Danke für die Info. Bin gespannt, ob eku einen mit höherer Frequenz 
benutzt und deshalb sein Timing besser ist.

> Ich hatte mir das Signal ja auch auf dem Oszilloskop angeschaut, und da
> konnte ich solche Ausreisser ja garnicht sehen.

Ich habe die Analyze-Funktion von IRMP mal ein wenig ausgebaut, hier die 
Timings von ekus Tastatur:
1
PULSES:
2
  6 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 4169
3
  7 oo 156
4
avg: 6.0 = 301.8 usec, min: 6 = 300.0, max: 7 = 350.0  tol: 16.0%
5
PAUSES:
6
  4 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 1575
7
  5 oooooooooooooooooooooooooooooooooooooooo 1072
8
avg: 4.4 = 220.2 usec, min: 4 = 200.0, max: 5 = 250.0  tol: 13.5%

Die (liegenden Glockenkurven) sind praktisch ein Strich, die 
Abweichungen liegen bei 13 - 16%.

Und jetzt das Timing Deiner Tastatur:
1
PULSES:
2
  6 oooooooooooooo 43
3
  7 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 184
4
  8 oooooooooooooooooooooooooooo 88
5
  9 ooo 10
6
 10  3
7
avg: 7.2 = 361.3 usec, min: 6 = 300.0, max: 10 = 500.0  tol: 38.4%
8
PAUSES:
9
  1  1
10
  2 oooooooooooooooooooo 28
11
  3 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 83
12
  4 oooooooooooooooooooooooooooooooooooooooooooooooooooooooo 78
13
  5 o 2
14
avg: 3.3 = 163.5 usec, min: 1 = 50.0, max: 5 = 250.0  tol: 69.4%

Hier sind die Kurven breiter und die Abweichhungen liegen bei 38 - 70%. 
Das ist schon happig.

Gruß,

Frank

von eku (Gast)


Lesenswert?

Hallo Frank,

ich benutze das Pollin ATMEL Addon-Board V1.0 (810 053) mit TSOPxx36, 
der breitbandiger als der SFH 5110-36 ist.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:
> ich benutze das Pollin ATMEL Addon-Board V1.0 (810 053) mit TSOPxx36,
> der breitbandiger als der SFH 5110-36 ist.

Das könnte der Unterschied sein:

Wenn das FDC-Keyboard mit 40kHz oder höher sendet, könnte der 
SFH-Empfänger seine Probleme damit haben. Beim TSOP1736 gibt es keine 
Probleme mit einer 40kHz-Modulation, da wird "nur" die Reichweite ein 
wenig geringer.

Ich habe zu Hause sowohl TSOP1736 als auch TSOP1738 zum Testen.... aber 
leider ist immer noch keine FDC-Tastatur angekommen. Pollin lässt sich 
mal wieder ein wenig Zeit...

Gruß,

Frank

von Torsten K. (nobby)


Lesenswert?

Ich schraube die nächsten Tagen nochmal meine Tastatur auseinander und 
hänge das Scope an die IR-LED, dann sehen wir was da für eine Frequenz 
drauf liegt.

Pollin hat bei meiner letzten Lieferung auch über eine Woche gebraucht, 
die haben wohl momentan gut zu tun....

von Max M. (max_m)


Lesenswert?

hallo,

sorry schon mal für die dumme frage aber:

was läuft hier beim Kompilieren falsch?

meine makefile (arbeite unter linux und will es für einen atmega168 
erstellen)
1
# controller
2
MCU = atmega168
3
4
# frequency
5
F_CPU = 20000000UL
6
7
# main application name (without .hex)
8
# eg 'test' when the main function is defined in 'test.c'
9
TARGET = main
10
11
# c sourcecode files
12
# eg. 'test.c foo.c foobar/baz.c'
13
SRC = $(TARGET).c irmp.c
14
15
# asm sourcecode files
16
# eg. 'interrupts.S foobar/another.S'
17
ASRC =
18
19
# headers which should be considered when recompiling
20
# eg. 'global.h foobar/important.h'
21
HEADERS =
22
23
# include directories (used for both, c and asm)
24
# eg '. usbdrv/'
25
INCLUDES =
26
27
28
# use more debug-flags when compiling
29
DEBUG = 1
30
31
32
# avrdude programmer protocol
33
PROG = usbasp
34
# avrdude programmer device
35
DEV = usb
36
# further flags for avrdude
37
AVRDUDE_FLAGS =
38
39
####################################################
40
# 'make' configuration
41
####################################################
42
CC = avr-gcc
43
OBJCOPY = avr-objcopy
44
OBJDUMP = avr-objdump
45
AS = avr-as
46
SIZE = avr-size
47
CP = cp
48
RM = rm -f
49
RMDIR = rm -rf
50
MKDIR = mkdir
51
AVRDUDE = avrdude
52
53
# flags for automatic dependency handling
54
DEPFLAGS = -MD -MP -MF .dep/$(@F).d
55
56
# flags for the compiler (for .c files)
57
CFLAGS += -g -Os -mmcu=$(MCU) -DF_CPU=$(F_CPU) -std=gnu99 -fshort-enums $(DEPFLAGS)
58
CFLAGS += $(addprefix -I,$(INCLUDES))
59
# flags for the compiler (for .S files)
60
ASFLAGS += -g -mmcu=$(MCU) -DF_CPU=$(F_CPU) -x assembler-with-cpp $(DEPFLAGS)
61
ASFLAGS += $(addprefix -I,$(INCLUDES))
62
# flags for the linker
63
LDFLAGS += -mmcu=$(MCU)
64
65
# fill in object files
66
OBJECTS += $(SRC:.c=.o)
67
OBJECTS += $(ASRC:.S=.o)
68
69
# include config file
70
-include $(CURDIR)/config.mk
71
72
# include more debug flags, if $(DEBUG) is 1
73
ifeq ($(DEBUG),1)
74
  CFLAGS += -Wall -W -Wchar-subscripts -Wmissing-prototypes
75
  CFLAGS += -Wmissing-declarations -Wredundant-decls
76
  CFLAGS += -Wstrict-prototypes -Wshadow -Wbad-function-cast
77
  CFLAGS += -Winline -Wpointer-arith -Wsign-compare
78
  CFLAGS += -Wunreachable-code -Wdisabled-optimization
79
  CFLAGS += -Wcast-align -Wwrite-strings -Wnested-externs -Wundef
80
  CFLAGS += -Wa,-adhlns=$(basename $@).lst
81
  CFLAGS += -DDEBUG
82
endif
83
84
####################################################
85
# avrdude configuration
86
####################################################
87
ifeq ($(MCU),atmega8)
88
  AVRDUDE_MCU=m8
89
endif
90
ifeq ($(MCU),atmega48)
91
  AVRDUDE_MCU=m48
92
endif
93
ifeq ($(MCU),atmega88)
94
  AVRDUDE_MCU=m88
95
endif
96
ifeq ($(MCU),atmega168)
97
  AVRDUDE_MCU=m168
98
endif
99
100
AVRDUDE_FLAGS += -p $(AVRDUDE_MCU)
101
102
####################################################
103
# make targets
104
####################################################
105
106
.PHONY: all clean distclean avrdude-terminal
107
108
# main rule
109
all: $(TARGET).hex
110
111
$(TARGET).elf: $(OBJECTS)
112
  $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^
113
114
# all objects (.o files)
115
$(OBJECTS): $(HEADERS)
116
117
# remove all compiled files
118
clean:
119
  $(RM) $(foreach ext,elf hex eep.hex map,$(TARGET).$(ext)) \
120
    $(foreach file,$(patsubst %.o,%,$(OBJECTS)),$(foreach ext,o lst lss,$(file).$(ext)))
121
122
# additionally remove the dependency makefile
123
distclean: clean
124
  $(RMDIR) .dep
125
126
# avrdude-related targets
127
install program: program-$(TARGET)
128
129
avrdude-terminal:
130
  $(AVRDUDE) $(AVRDUDE_FLAGS) -c $(PROG) -P $(DEV) -t
131
132
program-%: %.hex
133
  $(AVRDUDE) $(AVRDUDE_FLAGS) -c $(PROG) -P $(DEV) -U flash:w:$<
134
135
program-eeprom-%: %.eep.hex
136
  $(AVRDUDE) $(AVRDUDE_FLAGS) -c $(PROG) -P $(DEV) -U eeprom:w:$<
137
138
# special programming targets
139
%.hex: %.elf
140
  $(OBJCOPY) -O ihex -R .eeprom $< $@
141
  @echo "========================================"
142
  @echo "$@ compiled for: $(MCU)"
143
  @echo -n "size for $< is "
144
  @$(SIZE) -A $@ | grep '\.sec1' | tr -s ' ' | cut -d" " -f2
145
  @echo "========================================"
146
147
%.eep.hex: %.elf
148
  $(OBJCOPY) --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 -O ihex -j .eeprom $< $@
149
150
%.lss: %.elf
151
  $(OBJDUMP) -h -S $< > $@
152
153
-include $(shell $(MKDIR) .dep 2>/dev/null) $(wildcard .dep/*)

und das ergibt ein make
1
avr-gcc -g -Os -mmcu=atmega168 -DF_CPU=20000000UL -std=gnu99 -fshort-enums -MD -MP -MF .dep/main.o.d  -Wall -W -Wchar-subscripts -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wstrict-prototypes -Wshadow -Wbad-function-cast -Winline -Wpointer-arith -Wsign-compare -Wunreachable-code -Wdisabled-optimization -Wcast-align -Wwrite-strings -Wnested-externs -Wundef -Wa,-adhlns=main.lst -DDEBUG   -c -o main.o main.c
2
main.c:61: Warnung: kein vorheriger Prototyp für »timer_init«
3
avr-gcc -g -Os -mmcu=atmega168 -DF_CPU=20000000UL -std=gnu99 -fshort-enums -MD -MP -MF .dep/irmp.o.d  -Wall -W -Wchar-subscripts -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wstrict-prototypes -Wshadow -Wbad-function-cast -Winline -Wpointer-arith -Wsign-compare -Wunreachable-code -Wdisabled-optimization -Wcast-align -Wwrite-strings -Wnested-externs -Wundef -Wa,-adhlns=irmp.lst -DDEBUG   -c -o irmp.o irmp.c
4
irmp.c:1204: Fehler: expected identifier or »(« before »volatile«
5
irmp.c:1204: Fehler: expected »)« before »(« token
6
irmp.c:1296: Warnung: Redundante Redeklaration von »irmp_bit«
7
irmp.c:1193: Warnung: Vorherige Deklaration von »irmp_bit« war hier
8
irmp.c:2326: Warnung: kein vorheriger Prototyp für »print_spectrum«
9
irmp.c: In Funktion »print_spectrum«:
10
irmp.c:2368: Warnung: format »%0.2f« erwartet Typ »double«, aber Argument 3 hat Typ »float«
11
irmp.c: In Funktion »main«:
12
irmp.c:2565: Warnung: Übergabe des Arguments 1 von »print_spectrum« entfernt Kennzeichner von Zeiger-Ziel-Typ
13
irmp.c:2566: Warnung: Übergabe des Arguments 1 von »print_spectrum« entfernt Kennzeichner von Zeiger-Ziel-Typ
14
irmp.c:2567: Warnung: Übergabe des Arguments 1 von »print_spectrum« entfernt Kennzeichner von Zeiger-Ziel-Typ
15
irmp.c:2568: Warnung: Übergabe des Arguments 1 von »print_spectrum« entfernt Kennzeichner von Zeiger-Ziel-Typ
16
make: *** [irmp.o] Fehler 1

wo liegt da das problem?

von eku (Gast)


Lesenswert?

Max M. schrieb:
> wo liegt da das problem?

Welche Version? Release oder SVN Top?

von Michael M. (Gast)


Lesenswert?

scheint, als würde die irmp.c nicht mitkompiliert werden.
header-datei eingebunden?

von Max M. (max_m)


Lesenswert?

version 1.6
ich glaub versucht sie mit kompilieren sonst würde er doch in der irmp.c 
keine fehler finden oder?



header-dateien werden eingebunden

von Torsten K. (nobby)


Lesenswert?

Tastatur läuft auf 38kHz, hab ich grad nachgemessen.

Gruß
Torsten

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Max M. schrieb:

> was läuft hier beim Kompilieren falsch?
> # use more debug-flags when compiling
> DEBUG = 1

Das muss weg oder auf 0. Debuggen kann man unter Linux nur, wenn man 
IRMP nativ für Linux übersetzt.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi Torsten,

Torsten Kalbe schrieb:
> Tastatur läuft auf 38kHz, hab ich grad nachgemessen.

Danke für die Info. Das sollte Dein IR-Empfänger aber noch packen. Oder 
hast Du alternativ einen 38kHz-Empfänger zur Hand?

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Torsten,

Torsten Kalbe schrieb:
> Um das ganze zu vervollständigen möchte ich das RCCar jetzt auch noch in
> den IRSND einfügen.

Du hast das schon ganz gut hinbekommen, aber ein paar wichtige Sachen 
fehlen noch. Solange es dafür keine Doku gibt, wie man einen Encoder in 
IRSND einbaut, wirds auch schwierig.

Ich schaue, dass ich RCCAR diese Woche in den IRSND einbaue. Vielleicht 
kannst Du das dann "abgucken" und im IRMP-Artikel dokumentieren ;-)

Gruß,

Frank

von Torsten K. (nobby)


Lesenswert?

Hy,

also ich habe einen TSOP1738 Empfänger hier, mit dem könnte ich ein paar 
Scans machen. Ich bin mir aber garnicht sicher, welchen ich ursprünglich 
mal verwendet hatte....

Zum RCCar und der Doku, das kann ich dann sicherlich mal versuchen.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi eku,

eku schrieb:
> Könntest Du bitte die Variable irmp_pause_time auf uint16_t setzen um
> den Überlauf bei höheren Sampleraten zu verhindern.

Wird jetzt abhängig von F_INTERRUPTS gemacht, sobald IRMP_TIMEOUT_LEN 
(das ist die Konstante mit dem höchsten Zeitwert) droht überzulaufen, 
werden irmp_pause_time und last_pause als uint16_t definiert.

So kommt der erhöhte Codebedarf nur bei höheren Frequenzen zum Tragen - 
aktuell ab 15875Hz und mehr. Ist eingecheckt im SVN als Version 1.6.5.

Gruß,

Frank

von eku (Gast)


Lesenswert?

Hallo Frank!

Schade das sich RC5 und FDC ausschließen. Im

Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"

beschreibst Du ja, woran es liegt. Fällt Dir vielleicht noch ein Kniff 
ein, wie es doch gehen könnte?

Zum FDC-Protokoll noch ein paar Punkte: Jede Taste wird als zwei Frames 
erkannt, egal wie kurz ich sie betätige. Alle Maustasten werden immer 
als 0000 dekodiert. Ich vermute, dass beides an den nicht dekodierten 
Bits begründet sind.

In Beitrag "Re: IRMP - Infrared Multi Protocol Decoder" schreibst Du noch 
was von anderen Bits,

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Frank M. schrieb:
> Ich schaue, dass ich RCCAR diese Woche in den IRSND einbaue. Vielleicht
> kannst Du das dann "abgucken" und im IRMP-Artikel dokumentieren ;-)

FDC- und RCCAR-Protokoll sind nun auch im IRSND drin - eingecheckt im 
SVN.

Demnächst gibt es dann ein neues Release.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:

> Schade das sich RC5 und FDC ausschließen.

Ja, sehr schade.

> Fällt Dir vielleicht noch ein Kniff ein, wie es doch gehen könnte?

Im Moment "verrennt" sich der IRMP im RC5, weil er das Start-Bit früher 
gegen RC5 checkt als gegen FDC. Vielleicht drehe ich die Reihenfolge 
rum, denn ein FDC-Frame ist länger als ein RC5-Frame. Ich könnte ihn 
also zunächst in den FDC-Decoder reinlaufen lassen und wenn plötzlich 
völlige Dunkelheit herrscht, aber noch nicht alle vermeintlichen 
FDC-Bits empfangen wurden, die bisherigen Bits in RC5-Manchester-Code 
"umrechnen". Das könnte vielleicht gehen, ich werde mal drüber 
nachdenken.

> Zum FDC-Protokoll noch ein paar Punkte: Jede Taste wird als zwei Frames
> erkannt, egal wie kurz ich sie betätige.

Im Deinen Scans sehe ich die Wiederholung nur ab und zu, nicht 
ausnahmslos. Ich könnte die Regel einbauen, dass ein Frame mindestens 2x 
reinkommen muss (einmal mit vier 0-en im REPEAT-Block des Frames, einmal 
mit vier 1-en). Erst alle weiteren Repeat-Frames werden dann als 
tatsächlicher langer Tastendruck erkannt werden. Meinst Du das so?

Wenn Du meinst, dass das so besser wäre, mache ich das. Allerding 
wundere ich mich, dass ich diesen 2. Frame nur bei manchen Tastendrücken 
gesehen habe....

> Alle Maustasten werden immer
> als 0000 dekodiert. Ich vermute, dass beides an den nicht dekodierten
> Bits begründet sind.

Ja, die Maustasten werden noch nicht ausgewertet. Dafür werden die 
bisher nicht dekodierten Bits genutzt. Diese werden noch ignoriert.

Mich hätte aber schon mal interessiert, wie z.B. eine Tastenkombination 
STRG-C gesandt wird. Es kann nicht sein, dass zunächst der Keycode für 
STRG, dann der für C gesandt wird. Was ist bei der nächsten Taste? Da 
muss der Empfänger doch wissen, ob die STRG-Taste überhaupt noch 
gedrückt ist. Kannst Du das mal testen, evtl. mit Kombinationen von 
STRG, ALT, SHIFT?

Gruß,

Frank

von Max M. (max_m)


Lesenswert?

Frank M. schrieb:
> Max M. schrieb:
>
>> was läuft hier beim Kompilieren falsch?
>> # use more debug-flags when compiling
>> DEBUG = 1
>
> Das muss weg oder auf 0. Debuggen kann man unter Linux nur, wenn man
> IRMP nativ für Linux übersetzt.
>
> Gruß,
>
> Frank

Danke für den Hinweis hab es gerade abgeändert.

nun bekomm ich aber immer noch fehler... woran liegt jetzt bitte das?
1
avr-gcc -g -Os -mmcu=atmega168 -DF_CPU=20000000UL -std=gnu99 -fshort-enums -MD -MP -MF .dep/main.elf.d  -mmcu=atmega168 -o main.elf main.o irmp.o irmp.h
2
irmp.h:342: Fehler: expected specifier-qualifier-list before »uint8_t«
3
irmp.h:361: Fehler: expected »=«, »,«, »;«, »asm« or »__attribute__« before »irmp_get_data«
4
irmp.h:367: Fehler: expected »=«, »,«, »;«, »asm« or »__attribute__« before »irmp_ISR«
5
make: *** [main.elf] Fehler 1

von eku (Gast)


Lesenswert?

Frank M. schrieb:
>> Zum FDC-Protokoll noch ein paar Punkte: Jede Taste wird als zwei Frames
>> erkannt, egal wie kurz ich sie betätige.
>
> Im Deinen Scans sehe ich die Wiederholung nur ab und zu, nicht
> ausnahmslos.

Könnte das an IRMP_LOGGION=1 liegen? Die Uart-Ausgabe bremst die 
Interruptroutine aus und es werden weniger Sequenzen 
erkannt/protkolliert?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:
> Könnte das an IRMP_LOGGION=1 liegen? Die Uart-Ausgabe bremst die
> Interruptroutine aus und es werden weniger Sequenzen
> erkannt/protkolliert?

Die Uart-Ausgabe wird erst gestartet, wenn über eine längere Zeit kein 
Signal mehr am IR-Eingang anliegt. Bis dahin wird gepuffert. In Deinem 
allerersten Scan sandte fast jede Taste 2 Frames. Der lief mit 10kHz. In 
Deinem Scan mit 20kHz kam es nur vereinzelt zu Frame-Wiederholungen. Das 
kann daran liegen, dass bei 20kHz der Logging-Buffer schneller voll ist, 
denn hier wird das Doppelte an Speicher für einen Frame benötigt.

Okay, Du hast zwar meine Frage nicht beantwortet, aber ich nehme mal an, 
dass Du es auch für besser hältst, den ersten und zweiten Frame zusammen 
zu betrachten und erst weitere Frames (ab dem 3.) als Wiederholungen - 
analog zum SIRCS-Protokoll.

Gruß,

Frank

P.S.
Meine Pollin-Tastaturen sind gestern eingetroffen. Leider bin ich in den 
nächsten Tagen viel unterwegs und werde es wohl auch nicht am Wochenende 
schaffen, die Dinger mal selbst zu testen.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Max M. schrieb:
> nun bekomm ich aber immer noch fehler... woran liegt jetzt bitte das?
1
> avr-gcc -g -Os -mmcu=atmega168 -DF_CPU=20000000UL -std=gnu99
2
> -fshort-enums -MD -MP -MF .dep/main.elf.d  -mmcu=atmega168 -o
3
> main.elf main.o irmp.o irmp.h

Die Zeile ist irgendwie Unsinn.

Hier soll ein main.elf gelinkt werden, welches sich aus main.o, irmp.o 
und irmp.h zusammensetzt. So versucht nun der avr-gcc, das irmp.h für 
sich allein zu übersetzen. Das ist aber Quatsch, denn irmp.h ist kein 
eigenständiger Source, sondern nur eine Include-Datei. Das ist in der 
Zeile definitiv zu viel.

Da der make ja schon beim Linken angekommen ist, müsste die Compilierung 
von irmp.c und main.c bereits geschehen sein und Du müsstest dort 
bereits ein main.o und irmp.o vorliegen haben. Ist dem so?

Gruß,

Frank

von Max M. (max_m)


Lesenswert?

ja das ist so aber warum will er die header datei linken?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Max M. schrieb:
> ja das ist so aber warum will er die header datei linken?

Keine Ahnung, ich habe mal eben Dein Makefile unter Linux abgespeichert, 
die führenden Blanks in den Kommando-Zeilen durch TABs ersetzt und 
anschließend eingegeben:
1
make -n -f Makefile.Max

Der Output dazu:
1
$ make -n -f Makefile.Max
2
avr-gcc -g -Os -mmcu=atmega168 -DF_CPU=20000000UL -std=gnu99 -fshort-enums -MD -MP -MF .dep/main.o.d  -Wall -W -Wchar-subscripts -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wstrict-prototypes -Wshadow -Wbad-function-cast -Winline -Wpointer-arith -Wsign-compare -Wunreachable-code -Wdisabled-optimization -Wcast-align -Wwrite-strings -Wnested-externs -Wundef -Wa,-adhlns=main.lst -DDEBUG   -c -o main.o main.c
3
avr-gcc -g -Os -mmcu=atmega168 -DF_CPU=20000000UL -std=gnu99 -fshort-enums -MD -MP -MF .dep/irmp.o.d  -Wall -W -Wchar-subscripts -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wstrict-prototypes -Wshadow -Wbad-function-cast -Winline -Wpointer-arith -Wsign-compare -Wunreachable-code -Wdisabled-optimization -Wcast-align -Wwrite-strings -Wnested-externs -Wundef -Wa,-adhlns=irmp.lst -DDEBUG   -c -o irmp.o irmp.c
4
avr-gcc -g -Os -mmcu=atmega168 -DF_CPU=20000000UL -std=gnu99 -fshort-enums -MD -MP -MF .dep/main.elf.d  -Wall -W -Wchar-subscripts -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wstrict-prototypes -Wshadow -Wbad-function-cast -Winline -Wpointer-arith -Wsign-compare -Wunreachable-code -Wdisabled-optimization -Wcast-align -Wwrite-strings -Wnested-externs -Wundef -Wa,-adhlns=main.lst -DDEBUG -mmcu=atmega168 -o main.elf main.o irmp.o
5
...

Wie man hier in der letzten Zeile sieht, werden nur main.o und irmp.o 
zusammen gelinkt - kein irmp.h. Das ist so vollkommen korrekt. Hast Du 
vielleicht Dein Makefile, was Du hier gepostet hattest, nochmal nachher 
geändert? Für mich sieht es so aus, als ob Du entweder die SRC-Variable 
im Makefile um irmp.h erweitert hast oder gar OBJECTS. Überprüfe das 
bitte nochmal oder nimm das Makefile, was Du hier gepostet hattest und 
setze lediglich DEBUG auf 0.

Gruß,

Frank

P.S.
Wenn Du das hiesige Makefile nimmst, musst Du wohl die führenden TABs 
reparieren. Ich musste das jedenfalls, bevor ich Dein Makefile testen 
konnte. Du kannst natürlich die letzte angezeigte Zeile auch einfach per 
Copy&Paste in der Shell ausführen ;-)

von eku (Gast)


Lesenswert?

Hallo Frank!

Mit der SVN-Version von IRMP werden nicht mehr alle Codes des 
Siemens-Protokolls erkannt. Samplerate ist 15kHz, kein anderes Protkoll 
aktiv.


DOS-Zeileenden in test-suite.sh sind Mist

./test-suite.sh
-bash: ./test-suite.sh: /bin/sh^M: bad interpreter: Datei oder 
Verzeichnis nicht gefunden
1
$ ../irmp-15kHz -v < Siemens-Gigaset-M740AV-15kHz.txt|grep error
2
error 1: pause after start bit pulse 3 too long: 249
3
error 1: pause after start bit pulse 3 too long: 249
4
error 2: pause 249 after data bit 24 too long
5
error 1: pause after start bit pulse 3 too long: 249
6
error 2: pause 249 after data bit 24 too long
7
error 1: pause after start bit pulse 4 too long: 249
8
error 2: pause 249 after data bit 24 too long
9
error 1: pause after start bit pulse 4 too long: 249
10
error 2: pause 249 after data bit 24 too long
11
error 1: pause after start bit pulse 4 too long: 249
12
error 2: pause 249 after data bit 24 too long
13
error 1: pause after start bit pulse 4 too long: 249
14
error 2: pause 249 after data bit 24 too long
15
error 2: pause 249 after data bit 24 too long
16
error 2: pause 249 after data bit 24 too long
17
error 1: pause after start bit pulse 3 too long: 249
18
error 2: pause 249 after data bit 24 too long
19
error 1: pause after start bit pulse 3 too long: 249
20
error 1: pause after start bit pulse 3 too long: 249
21
error 1: pause after start bit pulse 3 too long: 249
22
error 1: pause after start bit pulse 4 too long: 249
23
error 2: pause 249 after data bit 24 too long
24
error 1: pause after start bit pulse 4 too long: 249
25
error 2: pause 249 after data bit 24 too long
26
error 1: pause after start bit pulse 3 too long: 249
27
error 2: pause 249 after data bit 24 too long
28
error 1: pause after start bit pulse 3 too long: 249
29
error 2: pause 249 after data bit 24 too long
30
error 1: pause after start bit pulse 3 too long: 249
31
error 2: pause 249 after data bit 24 too long

Das ging schon mal besser ;-(

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi eku,

eku schrieb:

> DOS-Zeileenden in test-suite.sh sind Mist

Weiß ich schon seit 25 Jahren ;-)

Nee, im Ernst, ich nutze unter Linux noch meinen eigenen CVS-Server. 
Wenn ich dann unter Windows das Script wieder auschecke, geraten die 
DOS-Zeilenenden da rein. Wenn ich dann anschließend über SVN (unter 
Windows) das Script wieder einchecke, isses dann kaputt. Ich werde das 
Script im CVS explizit auf binary setzen, dann passiert das nicht mehr.

> [code]
> $ ../irmp-15kHz -v < Siemens-Gigaset-M740AV-15kHz.txt|grep error

Kann ich nicht nachvollziehen. Ich habe mir dazu extra nochmal die 
SVN-Version geholt, aus test-suite.sh die DOS-Zeilenenden entfernt und 
dann laufen lassen. Geht ganz normal durch.

Auch Deine obitge Zeile mit Siemens-Gigaset-M740AV-15kHz.txt läuft 
anstandslos durch. Wie hast Du denn irmp-15kHz erzeuhgt? Wenn, dann 
solltest Du die Linux-Binaries mit

  make -f makefile.lnx

erstellen.

> Das ging schon mal besser ;-(

Das geht immer noch so gut ;-)

Gruß,

Frank

von eku (Gast)


Lesenswert?

Frank M. schrieb:
>> [code]
>> $ ../irmp-15kHz -v < Siemens-Gigaset-M740AV-15kHz.txt|grep error
>
>
> Kann ich nicht nachvollziehen. Ich habe mir dazu extra nochmal die
> SVN-Version geholt, aus test-suite.sh die DOS-Zeilenenden entfernt und
> dann laufen lassen. Geht ganz normal durch.

Bitte setze in irmpconfg.h alle Protokolle außer Siemens auf 0 und
teste noch einmal!

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:
> Bitte setze in irmpconfg.h alle Protokolle außer Siemens auf 0 und
> teste noch einmal!

Sag mal, kannst Du mit solchen Infos nicht sofort rauskommen, damit ich 
mir nicht einen Wolf suchen muss?

Sobald DENON eingeschaltet ist, funktioniert die SIEMENS-Erkennung.

Bin dran,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:
> Bitte setze in irmpconfg.h alle Protokolle außer Siemens auf 0 und
> teste noch einmal!

Ist korrigiert und eingecheckt. Es fehlte ein else im Code. Der Fehler 
trat nur auf bei deaktiviertem DENON-Protokoll.

Gruß,

Frank

von eku (Gast)


Lesenswert?

Frank M. schrieb:
> Der Fehler trat nur auf bei deaktiviertem DENON-Protokoll.

Danke. Die Testsuite sollte zusätzlich jedes Protokoll für sich testen, 
damit solche Fehler früher auffallen. Dazu braucht es aber Binaries für 
jedes Protokoll. Sollte per Makefile nichht zu kompliziert sein.

Fehlt noch ein Lösung für den Ausschluss von RC5 und FDC/RCCAR wie in
Beitrag "Re: IRMP - Infrared Multi Protocol Decoder" geschrieben.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Im SVN ist eine neue Testversion, welche den Konflikt zwischen RC5 und 
FDC bzw. RCCAR aufhebt.

Kurze Schilderung der Lösung:

Wird RC5 erkannt und passt das Start-Bit zeitlich auch als 
FDC-Protokoll, dann laufen 2 Decoder los. Sobald einer von beiden einen 
Timing-Fehler erkennt, beendet er sich und der andere gewinnt. Dasselbe 
gilt für das RCCAR-Protokoll. Funktioniert mit meinen vorliegenden 
Scan-Daten tadellos.

Man sollte sich aber wirklich überlegen, ob man RC5 und FDC bzw. RC5 und 
RCCAR in Kombination einschalten sollte. Der Decoder für FDC kostet nur 
50 Bytes im Binary, wenn RC5 deaktiviert ist. Ist sowohl RC5 als auch 
FDC eingeschaltet, dann erhöht sich der Platzbedarf des "dualen 
Decoders" auf 500 Bytes. Dasselbe gilt für das RCCAR-Protokoll.

Naja, wer RC5 unbedingt braucht... ich brauchs nicht ;-)

Viel Spaß,

Frank

von eku (Gast)


Lesenswert?

Frank M. schrieb:
> Naja, wer RC5 unbedingt braucht...

Das hängt doch in erster Linie von den rumliegenden Fernbedienungen ab. 
Und so alt ist mein DVD-Spieler nun auch nicht. Problematisch ist in 
meinen Augen, dass es so viele unterschiedliche Protokolle existieren.

von eku (Gast)


Lesenswert?

Hallo Frank!

Wenn man die "static PROGMEM IRMP_PARAMETER" Blöcke in ein Array 
ir_protos legt und darüber das Protkoll detektiert, spart das noch 
einmal Flash für die vielen Vergleiche:
1
          uint8_t i;
2
          for (i = 0; i < NELEMS (ir_protos); i++)
3
            {
4
              if (pulse_time >= ir_protos[i].start_len_min &&
5
                  pulse_time <= ir_protos[i].start_len_max &&
6
                  pause_time >= ir_protos[i].pause_len_min &&
7
                  pause_time <= ir_protos[i].pause_len_max)
8
                {
9
                  DPRINTF ("protocol %d\n", i);
10
                  ir_data.protocol = i;
11
                  ir_protop = &ir_protos[i];
12
                  break;
13
                }
14
            }
15
          if (i == NELEMS (ir_protos))
16
            {
17
              DPRINTF ("protocol UNKNOWN\n");
18
              /* wait for another start bit */
19
              start_bit_detected = 0;
20
            }

Bitte Variablennamen **kreativ** an irmp anpassen.

von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Lesenswert?

Ich habe gestern abend mal meine FDC-Pollin-Tastatur mit IRMP getestet. 
Dabei konnte ich noch ein paar Geheimnisse lüften. Die vermeintlichen 
REPEAT-Bits im Frame kennzeichnen keine Wiederholung, sondern das 
Drücken bzw. Loslassen einer Taste. Damit können dann auch 
Tasten-Kombinationen wie

  SHIFT + A
  ALT + M
  STRG + C
  usw.

erkannt werden.

Ich habe IRMP dahingehend angepasst, dass in den untersten 7 Bit der 
Keycode der Taste gespeichert ist und im oberen 8. Bit vermerkt wird, ob 
die Taste gedrückt oder losgelassen wird. Die entsprechende Änderungen 
im IRMP habe ich als Version 1.6.9 ins SVN eingecheckt.

Ebenso habe ich prototypisch eine kleine C-Funktion geschrieben, welche 
aus einem Keycode oder einer Keycode-Folge (bei obigen 
Tastenkombinationen) den zugehörigen ASCII-Code ermittelt, siehe Anhang.

Diese kann entweder direkt auf dem µC zur Ermittlung der Taste oder auf 
dem Host, wo die irmp-Datenstruktur hin übertragen wird, eingesetzt 
werden.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi eku,

eku schrieb:
> Wenn man die "static PROGMEM IRMP_PARAMETER" Blöcke in ein Array
> ir_protos legt und darüber das Protkoll detektiert, spart das noch
> einmal Flash für die vielen Vergleiche:

Gute Idee, geht zwar nicht ganz so glatt, wie Du es darstellst, aber das 
kann durchaus was bringen. Werde ich testen.

Gruß,

Frank

von eku (Gast)


Lesenswert?

Noch ein Vorschlag:
1
#if F_INTERRUPTS >= 14500
2
#define IRMP_SUPPORT_SIEMENS_PROTOCOL           0       // flag: support Siemens Gigaset       uses ~150 bytes
3
#else
4
#define IRMP_SUPPORT_SIEMENS_PROTOCOL           0       // DO NOT CHANGE! F_INTERRUPTS too low!
5
#endif

ändern in
1
#if F_INTERRUPTS < 14500
2
#undef IRMP_SUPPORT_SIEMENS_PROTOCOL
3
#define IRMP_SUPPORT_SIEMENS_PROTOCOL 0
4
#pragma warning: F_INTERRUPTS too low, disapling SIEMENS protocol
5
#endif

und den eigentlichen
1
#define IRMP_SUPPORT_SIEMENS_PROTOCOL           0       // flag: support Siemens Gigaset       uses ~150 bytes

hoch zu den anderen Protokollen. Analog die anderen Problemprotokolle.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Neue Version 1.7.0 von IRMP verfügbar, Download unter

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

Änderungen gegenüber 1.6.0:

  - Neues Protokoll: RCCAR
  - Tastenerkennung für FDC-Protokoll (IR-keyboard) erweitert
  - Konflikte FDC <--> RC5 beseitigt
  - Interrupt-Frequenz nun bis zu 20kHz (und mehr) möglich

Ebenso ist nun die Version 1.7.0 von IRSND verfügbar, Download unter

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

Änderungen gegenüber 1.6.0:

  - Neues Protokoll: RCCAR


Die Dokumentation im IRMP-Artikel habe ich auch angepasst bzw. 
erweitert, siehe:

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

Für die Pollin-FDC-Tastatur habe ich im Artikel ein eigenes Kapitel 
vorgesehen, wo sämtliche Tasten/Keycodes und die Anwendung mit IRMP 
dokumentiert sind:

  http://www.mikrocontroller.net/articles/IRMP#IR-Tastaturen

@Hugo Portisch:

Kannst loslegen mit der USB-Portierung ;-)

@eku & @ Torsten Kalbe:

Ich habe bei der FDC-Tastatur und einem TSOP1736 als Empfänger nur eine 
Reichweite von max. 15cm, das ist viel zu wenig. Klar, die 
Modulationsfrequenz der FDC-Tastatur ist 38kHz, daher sollte die 
Reichweite bei meinem Aufbau schon eingeschränkt sein. Aber ich dachte 
schon, dass ein paar Meter drin sein müssten. Naja, ich werden den 
TSOP1736 mal durch einen TSOP1738 ersetzen und dann nochmal testen. 
Welche Reichweite schafft Ihr mit der Tastatur?

Viel Spaß,

Frank

von eku (Gast)


Lesenswert?

Hallo Frank!

Frank M. schrieb:
> Tastenerkennung für FDC-Protokoll (IR-keyboard) erweitert

Was liefert eigentlich das Steuerkreuz rechts der Tastatur? Soweit ich 
mich erinnere sind da mehr als nur 4 Richtungen möglich.
1
#if IRMP_SUPPORT_SIEMENS_PROTOCOL == 1 && F_INTERRUPTS < 15000
2
#warning F_INTERRUPTS too low, SIEMENS protocol disabled (should be at least 15000)
3
#endif
4
5
#if IRMP_SUPPORT_RECS80_PROTOCOL == 1 && F_INTERRUPTS < 20000
6
#warning F_INTERRUPTS too low, RECS80 protocol disabled (should be at least 20000)
7
#endif
8
9
#if IRMP_SUPPORT_RECS80EXT_PROTOCOL == 1 && F_INTERRUPTS < 20000
10
#warning F_INTERRUPTS too low, RECS80EXT protocol disabled (should be at least 20000)
11
#endif

Wo sind denn die undefs für das 'disabled' geblieben?

Prinzipiell sollte F_INTERRUPTS auf den höchsten benötigten Wert anhand 
der aktivierten Protokolle automatisch gesetzt werden. Warum den 
Benutzer damit belasten. Dann entfallen auch die Warnungen und 
Automatismen zur Deaktivierung von Protkollen. Gegenteilige Meinungen?

von eku (Gast)


Lesenswert?

Frank M. schrieb:
> eku schrieb:
>> Wenn man die "static PROGMEM IRMP_PARAMETER" Blöcke in ein Array
>> ir_protos legt und darüber das Protkoll detektiert, spart das noch
>> einmal Flash für die vielen Vergleiche:
> Gute Idee, geht zwar nicht ganz so glatt, wie Du es darstellst, aber das
> kann durchaus was bringen. Werde ich testen.

Gibt es schon Erkenntnisse bezüglich Speicherverbrauch?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi eku,

eku schrieb:
> Was liefert eigentlich das Steuerkreuz rechts der Tastatur? Soweit ich
> mich erinnere sind da mehr als nur 4 Richtungen möglich.

Das Ding ist nach meinen Versuchen her ziemlich unbrauchbar, da kommen 
relativ wirkürlich 4 verschiedene Bits für oben, unten, rechts, oben und 
bei Zwischenstellungen dann die Summen davon. Leider ist das aber so 
ungenau, dass da beim Drücken des Steuerkreuzes nach rechts so ziemlich 
alles kommt zwischen unten, unten-rechts, rechts, oben-rechts und oben.
Daher habe ich aufgegeben, das Steuerkreuz zu decodieren. Es wird 
schlichtweg ignoriert.

> Wo sind denn die undefs für das 'disabled' geblieben?

Vergessen ;-)

Werde ich dieses Wochenende korrigieren.

> Prinzipiell sollte F_INTERRUPTS auf den höchsten benötigten Wert anhand
> der aktivierten Protokolle automatisch gesetzt werden. Warum den
> Benutzer damit belasten. Dann entfallen auch die Warnungen und
> Automatismen zur Deaktivierung von Protkollen. Gegenteilige Meinungen?

Du kommst jedesmal, wenn ich was umbaue nach Deinen Wünschen, mit einer 
neuen Idee. ;-)

Ob eine 20kHz-Interrupt-Rate bei einer CPU-Frequenz von 8MHz noch 
sinnvoll ist, kann ich nicht beurteilen. Wenn man alle Protokolle 
einschaltet, könnte es dabei eng werden. Um das herauszubekommen, müsste 
man mal die Belastung der CPU in der ISR messen.

Ich halte wenig von Deiner Idee, die Interrupt-Frequenz selbst zu 
bestimmen, denn ich möchte den Anwender von IRMP nicht übermäßig 
bevormunden. Vielleicht hat er durchaus Gründe, die ISR mit 15kHz 
anzusprechen statt mit 10kHz, auch wenn 10kHz reichen würde. Auch kommt 
es darauf an, welchen Timer er nimmt. Die Wahl des Timers und die Wahl 
der Vorteiler/Timing-Register bestimmt die Frequenz und nicht umgekehrt.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:
> Frank M. schrieb:
>> eku schrieb:
>>> Wenn man die "static PROGMEM IRMP_PARAMETER" Blöcke in ein Array
>>> ir_protos legt und darüber das Protkoll detektiert, spart das noch
>>> einmal Flash für die vielen Vergleiche:
>> Gute Idee, geht zwar nicht ganz so glatt, wie Du es darstellst, aber das
>> kann durchaus was bringen. Werde ich testen.
>
> Gibt es schon Erkenntnisse bezüglich Speicherverbrauch?

Nein, da habe ich mich noch nicht durchringen können, das umzusetzen. 
Ich schwanke nämlich mittlerweile, ob ich diese "Optimierung" überhaupt 
machen soll, nämlich aus folgenden Gründen:

1. Jetzt werden die Startbit-Timings gegen Konstanten geprüft. Das ist
   mit nur wenigen CPU-Takten möglich. Beim Testen der Timings gegen
   Variablen in einer for-Schleife dauert der Check eines Protokolls
   gegen die Startbit-Timings wesentlich länger, weil dann erstmal
   die Variablen in Register geladen werden müssen, um sie gegen die
   ermittelten Timing-Werte zu testen. Bei knapp 20 Protokollen kommt
   da einiges an Laufzeit zusammen, was da zusätzlich verbraten wird.
   Da dies alles innerhalb eines einzigen ISR-Laufes passieren muss,
   kann das arg knapp werden. Man spart zwar Speicherplatz, aber auf
   Kosten von Laufzeit.

2. Wenn Du Dir die Startbit-Timing-Checks anschaust, wirst Du sehen,
   dass nur die wenigsten aller Tests identisch sind. Bei den
   Manchester-Protokollen (RC5, RC6, Grundig, usw.) sind 4 Tests
   notwendig, bei den anderen nur 2 Tests - aber nur, wenn sie
   ausgezeichnete Startbits haben. Beim Denon-Protokoll, welches
   keine Startbits aufweist, muss ich hingegen wieder 4 Tests machen,
   weil das erste Bit schon eine 0 oder eine 1 sein kann. Ausserdem
   kommen dann evtl. weitere Tests hinzu, beim RC5-Protokoll können
   (wegen des erweiterten RC5-X-Protokolls) auch die ersten beiden
   Puls-Pausen-Werte schon verschieden sein. Desweiteren kommt dann
   noch das "Starten" eines zweiten Parallel-Decoders hinzu, um
   den Konflikt zwischen RC5<->FDC und RC5<->RCCAR zu lösen.
   Wenn man diese ganzen Sonderbedingungen in die for-Schleife
   zusätzlich einbaut, wird das ähnlich viel Code verschlingen
   wie jetzt auch.

Man könnte einen Kompromiss eingehen:

Diejenigen Pulse-Distance-Protokolle, für die keine Sonderbedingungen 
anfallen, kann man in einer for-Schleife zusammenfassen - also SIRCs,
NEC, SAMSUNG, MatSUSHITA, KASEIKYO und noch ein paar andere. Aber ob 
sich das dann noch lohnt? Weiß ich nicht.

Mir schwebt eine andere Optimierung vor: Im Moment ist die Ermittlung 
des Protokolls aus den Startbit-Timings eine lineare Suche. Ab einer 
bestimmten Anzahl wird dies ineffektiv, weil dann N Tests gemacht werden 
müssen. Wenn man die lineare Suche gegen eine baumartige Suche ersetzen 
würde, geht das effektiver und spart Zeit. Die ISR kommt nämlich 
irgendwann ab einem bestimmten N (Anzahl der Protokolle) an seine 
Grenzen, und zwar genau nach dem Empfang des Startbits: hier geht die 
Sucherei los... und das kann lang dauern. Wenn man das durch eine 
Intervallschachtelung ersetzt, braucht man nur noch log2(N) viele Tests.

Ungefährer Algorithmus:

Man teilt die Protokolle in 2 Gruppen: Diejenigen mit kurzen und 
diejenigen mit langen Startbits. Dann kann man schon mal 50% der 
Protokolle auf einen Schlag ausschließen. Dann werden die diese 2 
Gruppen wieder in Untergruppen zerschlagen, so dass man mit einem 
weiteren Test von den 50% wieder 50% ausschließen kann. Dann bleiben nur 
noch 25% übrig usw.

Die Kunst besteht nun darin, diesen Abfragebaum zur Compilezeit 
zusammenzustellen - oder zumindest in der init-Funktion. Da denke ich 
noch drüber nach, wie ich das bewerkstellige.

Gruß,

Frank

von eku (Gast)


Lesenswert?

Hi Frank!

Frank M. schrieb:
> Du kommst jedesmal, wenn ich was umbaue nach Deinen Wünschen, mit einer
> neuen Idee. ;-)

In den 25 Jahren Deiner Softwareentwicklung hast Du bestimmt 
mitbekommen:
  * Softwareentwicklung ist ein iterativer Prozess
  * der Kunde hat immer neue Wünsche an die Software
  * ein Programm, das fertig ist, ist veraltet

Lass Dich von mir nicht entmutigen!

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:

> Lass Dich von mir nicht entmutigen!

Nönö, alles noch im grünen Bereich ;-)

Ich hatte Dich noch gefragt, welche Reichweite Deine FDC-Tastatur hat, 
wahrscheinlich hast Du es überlesen... mit meinem TSOP1736 und einer 
Reichweite von nur 15cm bin ich nicht zufrieden. Ich weiß, dass ein 
TSOP1738 bei der Tastatur besser geeignet wäre, jedoch kann ich mir 
diese geringe Reichweite damit nicht allein erklären.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:
> Gibt es schon Erkenntnisse bezüglich Speicherverbrauch?

Ich habe das gerade mal getestet:

Alle Startbit-Timings in eine struct gepackt und dann zwei for-Schleifen 
(eine mit ausgezeichneten Startbits: 2 Tests, eine für diejenigen 
Protokolle, die direkt mit den Daten beginnen: 4 Tests) gebaut.

Ergebnis: Wenn alle Protokolle aktiviert sind, liegt die Ersparnis bei 
150 Bytes. Leider steigt die Größe des Datensegments dabei um 140 Byte. 
Wenn weniger Protokolle aktiviert sind, dann ist der Gewinn noch 
geringer.

Das kann man also vergessen: es bringt nichts. Im Gegenteil: die 
Laufzeit vergrößert sich drastisch wegen des Ladens aller Startbit-Werte 
aus der struct in die Register, um den Vergleich durchführen zu können. 
Das Einzige, was mir an der Änderung gefällt, ist, dass der Source 
"schöner" aussieht ;-)

Ich werde daher diese Änderung erstmal auf Eis legen und später 
vielleicht wieder aufgreifen, nämlich dann, wenn ich die lineare Suche 
durch eine Intervallschachtelung ersetzen werde.

Gruß,

Frank

von eku (Gast)


Lesenswert?

Frank M. schrieb:
> Ich hatte Dich noch gefragt, welche Reichweite Deine FDC-Tastatur hat,
> wahrscheinlich hast Du es überlesen... mit meinem TSOP1736 und einer
> Reichweite von nur 15cm bin ich nicht zufrieden.

Nicht überlesen, nur gerade den AVR nicht dabei :-)
Also mein TSOP1736 auf dem Pollin AVR Add-On reagiert noch am anderen 
Ende des Zimmers, d.h. mehr als drei Meter sind kein Problem.

von Torsten K. (nobby)


Lesenswert?

Hy,

ich kann die Reichweite auch nicht so einfach testen, was größer als ein 
paar Meter sein sollte. Dann müßte ich meinen Testempfänger mal mit 
einem 9Volt Block betreiben und die Straße unsicher machen.

Gruß
Torsten

von Micha (Gast)


Lesenswert?

Gehört zwar vielleicht nicht direkt hierher, hat aber mit IRMP zu tun:
wie lässt sich effektiv (speicher- und laufzeittechnisch) eine Art 
Lookup-Tabelle erstellen, die anhängig von empfangenen IR-Daten ein 
Zeichen über die UART sendet?

Ich will nicht den kompletten IR-Frame senden, sondern wirklich nur ein 
einzelnes 8-bit-Zeichen. Nach Möglichkeit sollte das Ganze lernbar sein, 
d.h. nicht festgelegt auf bestimmte IR-Protokolle/-Kommandos. Auch 
verschiedene Protokolle sollten möglich sein.

BTW: IRMP ist ein richtig feines Stück Software... Vielen Dank dafür!

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:
> Also mein TSOP1736 auf dem Pollin AVR Add-On reagiert noch am anderen
> Ende des Zimmers, d.h. mehr als drei Meter sind kein Problem.

Torsten Kalbe schrieb:

> ich kann die Reichweite auch nicht so einfach testen, was größer als ein
> paar Meter sein sollte. Dann müßte ich meinen Testempfänger mal mit
> einem 9Volt Block betreiben und die Straße unsicher machen.

Danke fürs Feedback, da muss meine Tastatur (eine von 5, die ich 
bestellt hatte) nicht in Ordnung sein, normale Fernbedienungen werden 
nämlich auch bei mir auf 3-5 Meter erkannt. Muss ich heute abend mal die 
zweite Tastatur auspacken....

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Micha schrieb:
> wie lässt sich effektiv (speicher- und laufzeittechnisch) eine Art
> Lookup-Tabelle erstellen, die anhängig von empfangenen IR-Daten ein
> Zeichen über die UART sendet?

Das ginge mit einer Hash-Funktion. Da hatte mal jemand so etwas im 
Februar diesen Jahres hier in der Codesammlung vorgestellt:

   Beitrag "Universeller IR-Receiver für viele Protokolle"

Hier wird aus dem IR-Frame ein 32-Bit-Hash-Wert berechnet - ohne 
Kenntnis des Protokolls. Hat aber ein paar Stolpersteine... z.B. die 
Behandlung von Repetition-Frames, Eindeutigkeit usw.

Da Du sogar alles in ein einziges Byte packen möchtest, sind doppelte 
Rückgabewerte vorprogrammiert. Auch bei einem 32-Bit-Hash-Wert kann man 
nicht ausschließen, dass zwei verschiedene Fernbedienungen auf 
irgendwelchen Tasten denselben Hash-Wert ergeben. Aber es ist halt 
relativ unwahrscheinlich - jedenfalls dann, wenn die Hash-Funktion "gut" 
ist. Aber eine Hash-Funktion, die nur einen eindeutigen 8-Bit-Wert 
zurückgeben soll - und das ohne Kenntnisse irgendwelcher Protokolle - 
kannste vergessen.

Gruß,

Frank

von Micha (Gast)


Lesenswert?

Frank M. schrieb:
> Aber eine Hash-Funktion, die nur einen eindeutigen 8-Bit-Wert
> zurückgeben soll - und das ohne Kenntnisse irgendwelcher Protokolle -
> kannste vergessen.
Und wenn ich nur ein Protokoll "gleichzeitig" zulassen würde? Wie 
schätzt du die Chancen dann ein?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Micha schrieb:
> Frank M. schrieb:
> Und wenn ich nur ein Protokoll "gleichzeitig" zulassen würde? Wie
> schätzt du die Chancen dann ein?

Das kommt darauf an, wieviele Tasten Du unterscheiden möchtest. Sind es 
lediglich die Tasten 0-9, kommst Du mit 4 Bit aus. Wenn wir uns noch das 
NEC-Protokoll anschauen, dann ist die Chance, dass Du in Deinem Haushalt 
2 NEC-kompatible Fernbedienungen hast, schon relativ groß. Dass es 
Überschneidungen bei den Tasten '0' bis '9' gibt, ist auch relativ 
wahrscheinlich.

Du müsstest Dich also nicht nur auf ein Protokoll einschränken, sondern 
auch noch auf eine Adresse konzentrieren, um ein Kommando einer FB 
eindeutig zu erkennen. Wenn Du bis zu 32 Tasten unterscheiden möchtest, 
sind 5 Bit weg und Du hast noch 3 Bit, um verschiedene FBs anhand ihrer 
Adresse zu unterscheiden. Das wird arg knapp.

IRMP nutzt nicht umsonst 16 Bit für die Adresse und 16 Bit für das 
Kommando. Meist kommt man mit 8 Bit für die Adresse und 8 Bit für das 
Kommando aus - aber nicht immer.

Warum willst Du Dich unbedingt auf 8 Bit beschränken? Hugo Portisch, der 
den IRMP im USB-IR-Receiver nutzt, überträgt einfach 6 Bytes, nämlich:

1. Byte: irmp_data.protocol
2. und 3. Byte: irmp_data.address
4. und 5. Byte: irmp_data.command
6. Byte: irmp_data.flags

Du könntest natürlich auch mittels IRMP alles in ein Byte packen:

a) Nur ein Protokoll aktivieren, alle anderen deaktivieren

b) irmp_data.address auf einen festen Wert prüfen, also nur
   eine Adresse zulassen

c) Für die Tasten, die Du übertragen willst, einen case-switch
   bauen, der bestimmte Werte von irmp_data.command in die Werte
   1, 2, 3, 4, usw. übersetzt.

Man könnte noch einen Schritt weiter gehen: Bei 32 verschiedenen Tasten 
hast Du dann noch 3 Bits übrig. Damit könntest Du in den 8 Bits 
folgendes codieren:

   RAACCCCC

wobei:

   R    =  Repetition Flag
   AA   =  00 Adresse FB Nr. 1
           01 Adresse FB Nr. 2
           10 Adresse FB Nr. 3
           11 Adresse FB Nr. 4
   CCCCC = 32 verschiedene Tasten

Somit könntest Du dann zumindest für 4 verschiedene FBs 32 verschiedene 
Tasten-Codes übertragen.

Das obige gilt aber nur für IRMP - unter der Voraussetzung, dass man 
nicht nur das Protokoll, sondern auch schon die Tastencodes kennt. Eine 
Hash-Funktion zu finden, die ohne Kenntnis des Protokolls alles in 8 Bit 
ohne Dubletten stopft, halte ich für illusorisch. Und dann auch noch 
"anlernbar"? Da müsste sich die Hash-Funktion selbst modifizieren, 
sobald ein neuer Code angelernt werden soll, um Dubletten zu vermeiden.

Okay, letzter Versuch:

Du nimmst die 32-Bit-Hashfunktion aus

     Beitrag "Universeller IR-Receiver für viele Protokolle"

und trägst den ermittelten 32-Bit-Hash-Wert in eine 256 x 4 Byte große 
Tabelle ein. Dann kannst Du den 8-Bit-breiten Index auf diese Tabelle 
nutzen, um eine Taste zu identifizieren. Kostet Dich leider 1KB RAM ;-)

Gruß,

Frank

von Micha (Gast)


Lesenswert?

Frank M. schrieb:
> Warum willst Du Dich unbedingt auf 8 Bit beschränken? Hugo Portisch, der
> den IRMP im USB-IR-Receiver nutzt, überträgt einfach 6 Bytes, nämlich:
Ich habe ähnliches vor wie Hugo, allerdings wollte ich den AVR (einen 
ATtiny84) "direkt als Tastatur" nutzen, also ohne dlls und dergleichen.

Anlernbar sollte heißen, dass man die IR-Kommandos beliebig einer Taste 
zuweisen kann, à la "Drücken Sie jetzt die Taste für 'a' auf Ihrer 
FB"...

von Micha (Gast)


Lesenswert?

Im Prinzip wollte ich das hier 
http://www.obdev.at/products/vusb/hidkeys.html ohne Tasten und 
stattdessen mit IR-Empfänger bauen.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Micha schrieb:
> Anlernbar sollte heißen, dass man die IR-Kommandos beliebig einer Taste
> zuweisen kann, à la "Drücken Sie jetzt die Taste für 'a' auf Ihrer
> FB"...

Wo ist das Problem? Du nimmst IRMP und eine NEC-kompatible 
Fernbedienung. Da sind die Codes zwischen 0x00 und 0xFF.

Zu jeder Taste (z.B. 'a') merkst Du Dir imrp_data.command.

Gruß,

Frank

von Micha (Gast)


Lesenswert?

Frank M. schrieb:
> Du nimmst IRMP und eine NEC-kompatible Fernbedienung. Da sind die Codes
> zwischen 0x00 und 0xFF.
Das wäre natürlich eine Möglichkeit. Nachdem ich eine 
Universal-Fernbedienung habe ist das Protokoll eh relative egal - ich 
muss mir halt ein entsprechendes Gerät aus der Datenbank suchen.

Wenn ich so darüber nachdenke müsste es sogar möglich sein mir was 
eigenes zu basteln.

Ich werd mal verschiedenes testen. Vielen Dank für die Tipps!

von Micha (Gast)


Lesenswert?

Frank M. schrieb:
> Du nimmst IRMP und eine NEC-kompatible Fernbedienung. Da sind die Codes
> zwischen 0x00 und 0xFF.
Das wäre natürlich eine Möglichkeit. Nachdem ich eine 
Universal-Fernbedienung habe ist das Protokoll eh relative egal - ich 
muss mir halt ein entsprechendes Gerät aus der Datenbank suchen.

Wenn ich so darüber nachdenke müsste es sogar möglich sein mir was 
eigenes zu basteln.

Ich werd mal Verschiedenes testen. Vielen Dank für die Tipps!

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo zusammen,

es gibt einen Bugfix für IRMP - Version 1.7.2, Download unter

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

Änderungen gegenüber 1.7.1:

 - Bugfix: Einführen eines Timeouts für NEC-Repetition-Frames, um
   "Geisterkommandos" zu verhindern.

Was ist ein "Geisterkommando"?

Folgende Situation:

1. IRMP empfängt NEC-Kommonda A und weitere Repetition-Frames

2. Danach wird die Taste B lange gedrückt und IRMP empfängt das
   Kommando nicht vollständig - z.B. wegen zu geringer Reichweite oder
   weil die Katze durch den Strahl läuft.

3. Die FB sendet nun Repetition-Frames für Kommando B und IRMP
   interpretiert diese Wiederholungen als Wiederholungen für Kommando A!

Frank Lorenzen hat mich auf den Fehler aufmerksam gemacht, denn er 
konnte dieses Phänomen tatsächlich im "real life" erleben... naja... 
nicht die Katze war schuld ;-) Vielen Dank dafür!

Viel Spaß,

Frank

von eku (Gast)


Lesenswert?

Frank M. schrieb:
> Version 1.7.2

In irsndconfig.h ist noch die alte Behandlung für 
IRSND_SUPPORT_SIEMENS_PROTOCOL. Würdest Du das bitte an irmpconfig.h 
anpassen, d.h. Ausgabe einer Warnung mit Deaktivierung des Protokolls.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:
> In irsndconfig.h ist noch die alte Behandlung für
> IRSND_SUPPORT_SIEMENS_PROTOCOL. Würdest Du das bitte an irmpconfig.h
> anpassen, d.h. Ausgabe einer Warnung mit Deaktivierung des Protokolls.

Ich hatte nur IRMP angepasst. IRSND hat noch die alte Version ;-)
Aber klar, ich korrigiere das.

Gruß,

Frank

von Frank L. (florenzen)


Lesenswert?

Frank M. schrieb:

[...]
> Änderungen gegenüber 1.7.1:
>
>  - Bugfix: Einführen eines Timeouts für NEC-Repetition-Frames, um
>    "Geisterkommandos" zu verhindern.
[...]

Funktioniert einwandfrei :-)

> Viel Spaß,
>
> Frank

Vielen Dank für den schnellen Bugfix.

Viele Grüße,
Frank

von jar (Gast)


Lesenswert?

puh alles durchgelesen,

nur habe ich das mit dem Widerholungsflag noch nicht gesehen

kein loslassen, Lautstärke Helligkeit geht ja mit repeat, aber bei 
Programmwahl wäre das ja unglücklich, ergo muss das Bit loslasen 
interpretieren

ist da schon was eingebaut ?

IRMP ist erstmal geil, bin schon am nachbauen,

Probleme bereitet mit bis jetzt nur der heftige Aufwand (für mich)

entweder, Neubau, + Codeumschreibung, denn im Prinzip liegen hier 2(3) 
Geräte mit mega644(32), TSOP1736, LCD, LED, Triber für LCD HG-LED und 
Taster

alle Codes zeigen auf einen mega 88 der einzige Plan (den ich bis jetzt 
gefunden hatte) aber auf einen mega 168

klar könnte ich aus dem Code für mega 88 die Ports ohne Plan extrahieren

da meine HW quasi schon fast steht mal eben die beiden Codes und Quellen 
verheiratet, was aber logisch schief ging, ich nutze halt timer1 für die 
LCD HG LED per pwm OCRA und OCRB für den Kontrast

Ziel ist es aber nach Dekodierung meiner pansonic FB einen FB Sender zu 
generieren der per PC aktiviert wird, über VNC meinen HD Recorder 
fernzuprogramieren, aber da ich nicht noch mehr IR Sendedioden frei 
plazieren möchte, was ist mit IR zu RF 433 MHz Umsetzung, 433 Empfänger 
und IR Sender sind vorhanden, da die ja auf alle FB reagiren vermute ich 
die Trägerfrequenz 30 - 40 kHz ist denen egal, morsen die in 433 Mhz nur 
das an und aus der IR LED ?, wie könnte man ein RF(m?) 12 Modul den 
Transmitter dafür nutzen ?

hier gibt es ja Beispiele für Atmel atmel mit Sender und Empfänger, also 
per seriell Umsetzung, aber ich weiss nicht ob es digital oder analog 
ist was da gesendet wird, habe so eine Funk FB mal belaucht mit dem Oszi 
und Empfängermodul, aber nur Grundrauschen bekommen oder Störsignale, 
weiss aber nicht ob die 433 Module dafür gehen.


wenn sich dazu jemand äussern kann würde mich freuen,

den PC als fernbedienten IR/433 MHz Sender zu nutzen aus dem ganzen 
I-Net muss doch mehr interessieren ?

Rückmeldung der Programmierung geht natürlich toll per winTV und den HD 
Rec am AV Modulator ins Subkabelnetz gespeist, muss also auf dem PC nur 
winTV starten, den HDrec Kanal einstellen und schon kann ich alles 
programmieren, mit 433 MHz brauch ich nicht mal ne Sichtverbindung PC 
HDrec (das macht die IR Pyramide)

von jar (Gast)


Lesenswert?

so
1 Nachbau läuft mit 644 intern 8MHz

meine panasonic DVD wird als KASEIKYO erkannt

nur warum die Tasten OFF (2002/3d0) und TV OFF (2002/3d0) denselben Code 
bringen obwohl 2 getrennte Tasten ist mir noch unklar

loggen kann ich (noch) nicht, kein Maxim spendiert und keine Ahnung wie 
ich das dem PC erkläre

erst mal das Prototypeboard auf Akku umstellen und heim alle FB testen

von jar (Gast)


Lesenswert?

alle in Urlaub ? oder sind meine Fragen zu doof ?

egal, noch ein Versuch

so nun verschiedenste FB durchprobiert

Samsung wird als solche erkannt
drei Panasonic als Kaseikyo

nur alle OFF Knöpfe bringen den selben Code (2002/3d0)

aber natürlich reagieren die Geräte nicht so

VHS off Kaseikyo 2002/3d0 nur der VHS geht aus
HDrec off Kaseikyo 2002/3d0 nur der HDrec geht aus
TV off Kaseikyo 2002/3d0 weder der HDrec noch der VHS geht aus

alle RC5 FB zeigen im IRMP nix an (interner 8MHz), dabei geht "meine" 
andere Schaltung mit 8 MHz Quarz und Fleury RC5 Lib wohl

wo soll ich nun suchen ?

Jitter ? auf 8 MHz Quarz umstricken ?
internen auf 8 MHz kalibrieren (keine Ahnung wie das geht) meine andere 
Idee, einfach an den Teilern drehen bis 1s Blink LED 1s auf dem Oszi 
wird ?

1s soll ja nach 10000 ISR aufrufen vergangen sein

ergo lasse ich eine uint16 VAR immer wieder von 0-10000 laufen

in ISR wird uint16 VAR++
in main auf uint16 VAR >= 10000 abgefragt und 0 gesetzt und LED Bit xor 
gesetzt

muss ja 1s Puls / Pause rauskommen

von Joachim B. (jar)


Lesenswert?

so, mal wieder angemeldet das ich Antworten per mail bekomme

danke

gruss
jar

von Joachim B. (jar)


Lesenswert?

jar schrieb:
>
> 1s soll ja nach 10000 ISR aufrufen vergangen sein
>
> ergo lasse ich eine uint16 VAR immer wieder von 0-10000 laufen
>
> muss ja 1s Puls / Pause rauskommen

Kommando zurück, man sollte RC5 auch enabeln

hatte ich schon mal dann aber neu angefangen und vergessen

wer also noch Codes braucht kann sich ja melden, ich versuche dann den 
Max nachzurüsten und aufzuzeichnen

und suche immer noch ne Lösung für 433 MHz send statt IR (das IR 
überlasse ich den IR Pyramiden)

hat schon jemand IRSND am PC zu USB mit Atmel ?

wenn hier keiner ne bessere Idee hat nehme ich einen Atmal als USB zu 
rs232 Umsetzer und frickel da IRSND ein, ggffs mit 433 MHz Modul

von Joachim B. (jar)


Angehängte Dateien:

Lesenswert?

puh, schwerer als gedacht

also die JVC RM C085 wird nicht erkannt, obwohl JVC unter Nec als RC5 
geführt wird, aus dem TSOP1736 kommt schönes Signal raus so das ich die 
Frequenz erst mal nicht vermessen hab,

Interrupt auf 15k hochgesetzt hat nix gebracht, den Rest nicht 
verschlechtert aber der JVC nicht geholfen.

Der Oszi liefert schönen Stream sieht aber dem RC5 der erkannt wird 
nicht ähnlich

Anlage in der Zip:
ein PIC vom Oszi
hardcopy -> Ref1 ist unbekannte JVC und Ref2 ist bekannte Pinnacle RC5

und die Daten als 2x CSV (JVC-FB und Pinnacle FB RC5) und einmal zu XLS 
umgesetzt

ich hoffe das Projekt lebt noch und sind alle nur in Urlaub

ich mache mich nun an die 433 MHz Umsetzung und hoffe weiter auf 
Antworten auf meine Fragen

liebe gruesse
jar

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

jar schrieb:

> meine panasonic DVD wird als KASEIKYO erkannt

Prima.

> nur warum die Tasten OFF (2002/3d0) und TV OFF (2002/3d0) denselben Code
> bringen obwohl 2 getrennte Tasten ist mir noch unklar

Beim Kaseikyo-Protokoll (48 Bit!) werfe ich sämtliche CRCs raus. 
Vielleicht etwas zuviel...

Aktiviere bitte IRMP_LOGGING und schicke mir die Scan-Dateien. Dann 
werde ich den Unterschied schon finden.

> loggen kann ich (noch) nicht, kein Maxim spendiert und keine Ahnung wie
> ich das dem PC erkläre

Du startest einfach ein Terminal-Emulationsprogramm (z.B. HyperTerm) und 
speicherst die Ausgabe.

jar schrieb:

> alle in Urlaub ? oder sind meine Fragen zu doof ?

Ja, bis gestern :-)

> Samsung wird als solche erkannt

Gut.

> drei Panasonic als Kaseikyo

Auch gut.

> nur alle OFF Knöpfe bringen den selben Code (2002/3d0)

Wie gesagt: ich brauche die Scans dazu.

> alle RC5 FB zeigen im IRMP nix an (interner 8MHz), dabei geht "meine"
> andere Schaltung mit 8 MHz Quarz und Fleury RC5 Lib wohl

Scan schicken. Vielleicht haben wir hier nur eine zu starke Abweichung 
vom RC5-Timing.

> Jitter ? auf 8 MHz Quarz umstricken ?

Quarz ist auf jeden Fall gut. Bitte auch hier die Scan-Datei schicken, 
dann kann ich Dir mehr sagen.

> internen auf 8 MHz kalibrieren (keine Ahnung wie das geht) meine andere
> Idee, einfach an den Teilern drehen bis 1s Blink LED 1s auf dem Oszi
> wird ?

IRMP ist vom Timing her ziemlich tolerant. Bist Du sicher, dass Dein 
Timer mit der richtigen Frequenz läuft? Zeigst Du bitte mal die Passagen 
Deiner Timer-Initialisierung?

Joachim B. schrieb:

> Kommando zurück, man sollte RC5 auch enabeln

RC5 geht also jetzt?

> wer also noch Codes braucht kann sich ja melden, ich versuche dann den
> Max nachzurüsten und aufzuzeichnen

Ja, wäre nicht schlecht.

> und suche immer noch ne Lösung für 433 MHz send statt IR (das IR
> überlasse ich den IR Pyramiden)

Du meinst die 433 MHz-Sender/Empfänger von Pollin, die RFM12?
Sag mal genau, was Du willst. Sowas vielleicht:

         IR               Funk
IR-FB ---------> RFM12 ---------> RFM12 ------> Und was dann????


> hat schon jemand IRSND am PC zu USB mit Atmel ?

Meines Wissens nicht. Nur IRMP zu USB, siehe

Beitrag "USB IR Remote Receiver (V-USB + IRMP)"

> wenn hier keiner ne bessere Idee hat nehme ich einen Atmal als USB zu
> rs232 Umsetzer und frickel da IRSND ein, ggffs mit 433 MHz Modul

Male bitte mal ein Schaubild, ich verstehe nicht ganz, was Du vorhast.

Joachim B. schrieb:

> also die JVC RM C085 wird nicht erkannt, obwohl JVC unter Nec als RC5
> geführt wird, aus dem TSOP1736 kommt schönes Signal raus so das ich die
> Frequenz erst mal nicht vermessen hab,

Bitte Scan schicken.

> Anlage in der Zip:
> ein PIC vom Oszi

Nützt mir nichts.

> hardcopy -> Ref1 ist unbekannte JVC und Ref2 ist bekannte Pinnacle RC5

Nützt mir nichts.

> und die Daten als 2x CSV (JVC-FB und Pinnacle FB RC5) und einmal zu XLS
> umgesetzt

Nützt mir nichts.

> ich hoffe das Projekt lebt noch und sind alle nur in Urlaub

Jau :-)

> ich mache mich nun an die 433 MHz Umsetzung und hoffe weiter auf
> Antworten auf meine Fragen

Siehe oben.

Gruß,

Frank

von Joachim B. (jar)


Lesenswert?

hmmm, schade das die die CSV Dateien nix nutzen
jede Zeile ist 10µs also ist bei Zeile 70 der Wechsel bei 700 µs und so 
weiter, ist das für dich nicht lesbar ?

ist Exelformat und die XLS ist schon zu µs umgesetzt

oszi zu CSV oder XLS ist halt schneller als HW bauen

ich verstehe auch nicht manche Kommentare im Quellcode

mal wird JVC als RC5 bezeichnet mal als NEC aber hier steht was anderes
http://www.sbprojects.com/knowledge/ir/jvc.htm

JVC unterscheidet in 1 und Null bits zu 1 ms und 2 ms und das sehe ich 
auf dem Oszi, aber im Quellcode nicht ???

ich dachte auch mein JVC hat zu große Abweichung im Timing, aber ! 1ms 
und 2ms sind nahezu exakt nur warum werden die nicht erkannt ?

also wenn es nicht anders geht muss ich den MAX wohl noch nachrüsten

433 MHz

Ziel ist es später im PC den Code nicht auf eine IR Diode auszugeben 
sondern statt IR Diode auf einen 433 MHz Sender ähnlich den 
Funkfernedienungen oder der FB Transmitter (IR Empfänger - Funkstrecke 
433 MHz - IR Sender)

da zwei 433 MHz Empfänger mit IR Sendedioden schon im Zimmer stehen wäre 
es doch schön wenn der PC den IR Code statt in IR zu senden 433 MHz 
senden würde, dann spart man sich die PC IR Sendediode Ausrichtung zu 
den Geräten. ausgerichtet sind die Pyramiden ja schon

Ziel des ganzen, per PC den HD Recorder zu programmieren, auch übers 
I-Net (VNC)

war der Urlaub schön ?

liebe gruesse
achim

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:
> hmmm, schade das die die CSV Dateien nix nutzen
> jede Zeile ist 10µs also ist bei Zeile 70 der Wechsel bei 700 µs und so
> weiter, ist das für dich nicht lesbar ?

Es muss nicht für mich, sondern für IRMP lesbar sein, ich analysiere die 
Scans mit IRMP unter Linux, siehe auch Artikel:

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

Du kannst natürlich Deine XLS-Dateien wieder ins IRMP-Format umwandeln, 
das geht so: für jede zehntausendstel Sekunde schreibst Du eine 1, wenn 
der Empfänger aus war, für jede zehntausendstel Sekunde schreibst Du 
eine 0, wenn der Empfänger aktiv war. Das gibt dann eine Folge von 0en 
und 1en in einer langen Zeile z.B. so:

000000011111111111111000111000111.....

Davor schreibst Du noch einen Kommentar:

# OFF-Taste TV
000000011111111111111000111000111.....
# OFF-Taste VCR
000000011111111111111000111000111.....

> ist Exelformat und die XLS ist schon zu µs umgesetzt

Nützt mir nichts. IRMP "versteht" halt nur das IRMP-Format selbst.

> oszi zu CSV oder XLS ist halt schneller als HW bauen

Naja, einen MAX232 dranbauen ist auch nicht soooo schwierig.

> ich verstehe auch nicht manche Kommentare im Quellcode

Welche?

> mal wird JVC als RC5 bezeichnet mal als NEC aber hier steht was anderes
> http://www.sbprojects.com/knowledge/ir/jvc.htm

JVC ist nicht notwendigerweise RC5 oder NEC. JVC ist einfach ein 
Hersteller, der verschiedene IR-Protokolle verwendet. Meist jedoch NEC.

> JVC unterscheidet in 1 und Null bits zu 1 ms und 2 ms und das sehe ich
> auf dem Oszi, aber im Quellcode nicht ???

Schau Dir im IRMP-Artikel folgende Tabelle an:

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

Da sind alle Timings der von IRMP unterstützten Protokolle aufgeführt.

Im Quellcode findest Du diese Timings wieder in irmp.h. Sie sind in der 
Header-Datei, da sie auch von IRSND verwendet werden.

> ich dachte auch mein JVC hat zu große Abweichung im Timing, aber ! 1ms
> und 2ms sind nahezu exakt nur warum werden die nicht erkannt ?

Wie gesagt: Scan-Datei hilft weiter.

> also wenn es nicht anders geht muss ich den MAX wohl noch nachrüsten

Jepp :-)

> Ziel ist es später im PC den Code nicht auf eine IR Diode auszugeben
> sondern statt IR Diode auf einen 433 MHz Sender ähnlich den
> Funkfernedienungen oder der FB Transmitter (IR Empfänger - Funkstrecke
> 433 MHz - IR Sender)

Also:

        IR                        Funk                        IR
IR-FB -----> RFM-Sender mit IRMP -----> RFM-Empf. mit IRSND ------> 
fernzubedienendes Gerät

Geht mit IRSND, siehe IRMP-Artikel.

Das einzige, was fehlt, ist der Code für die RFM-Module. Aber da gibt es 
ja hier im Forum genügend Quellcode, wo man sich bedienen kann.

Gruß,

Frank

von Joachim B. (jar)


Lesenswert?

Sag mal genau, was Du willst. Sowas vielleicht:

         IR               Funk
IR-FB ---------> RFM12 ---------> RFM12 ------> Und was dann????


so ähnlich,

wenn der Atmel oder PC erst mal alle KASEIKYO Codes kennt soll der PC 
diese senden (notfalls über den Umweg eines Atmels)

aber es soll KASEIKYO nicht in IR gesendet werden, sondern in 433 MHz 
und ja ich denke an die RM12 Module, diese senden dann ungerichtet vom 
PC auf die Empfängerpyramiden die das dann zu IR Strahlung gerichtet 
umsetzen bis zum HD Recorder

Kaseikyo Code von PC (ggffs mit Hilfe eines ATMEGA) als 433 MHz an 
Funkempfängerpyramide - in IR an HDrec
PC kaseikyo Code ---------> RFM12 ---------> Funkempfängerpyramide 
------> IR ------> HD Rec

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:
> Ziel des ganzen, per PC den HD Recorder zu programmieren, auch übers
> I-Net (VNC)

Dann würde doch folgendes reichen:

USB-to-RS232 -> MAX232 -> AVR

Den USB-to-RS232-Wandler bekommst Du überall für ein paar Euros 
nachgeworfen. Dann kannst Du über die COM-Schnittstelle Befehle an den 
AVR senden. Dort läuft IRSND, welcher die Befehle per IR-LED wieder 
aussendet.

Anregungen findest Du vielleicht hier:

  http://www.klaus-leidinger.de/mp/Mikrocontroller/IR-LCD/IR-LCD.html

> war der Urlaub schön ?

Danke, oft über 40°C und viel Sonne :-)

Gruß,

Frank


P.S.
Ausgerechnet Kaseikyo unterstützt IRSND (das Gegenstück zu IRMP) noch 
nicht. Könnte sich aber ändern, wenn ich genügend "Futter" in Form von 
Scans bekomme ;-)

von Joachim B. (jar)


Lesenswert?

Frank M. schrieb:
> Joachim B. schrieb:
>> Ziel des ganzen, per PC den HD Recorder zu programmieren, auch übers
>> I-Net (VNC)
>
> Dann würde doch folgendes reichen:
>
> USB-to-RS232 -> MAX232 -> AVR

>> war der Urlaub schön ?
> Danke, oft über 40°C und viel Sonne :-)
> Gruß,
> Frank
>
> P.S.
> Ausgerechnet Kaseikyo unterstützt IRSND (das Gegenstück zu IRMP) noch
> nicht. Könnte sich aber ändern, wenn ich genügend "Futter" in Form von
> Scans bekomme ;-)

also da denke ich eher an:
http://www.embedded-projects.net/index.php?page_id=135

mit
http://www.embedded-projects.net/index.php?page_id=160

da habe ich etwas mitgewirkt (Platinengröße für USB Stickgehäuse), der 
kann auch als USB zu RS232 Umsetzer arbeiten (über virtcom Treiber) und 
statt den Code als RS232 auzugeben wird das Kommando direkt als KASEIKYO 
ausgegeben (mittels IRSND an 433 MHz)

Ich muss dann eben die RS232 Schnitte nachrüsten in meinem IRMP (seufs 
geht nicht wirklich leicht auf dem Steckbrett, muss wohl erst ne Platine 
schnitzen) damit ich dich mit KASEIKYO Codes füttern kann

dann ist da noch das 433 MHz Problem, senden empfangen mag ja in den 
RS232 Atmel Funkstrecken gehen, ist aber digital, meine Versuche eine 
China Funk FB (Cam RF Remote Auslöser , Canon Pentax, alle nach dem 
selben Prinzip, 4 DIP für Sende/Empfang an Cam mit kleinen Handsender 
mit Stabantenne) zu belauchen mit den Modulen war erfolglos, scheint mir 
analog zu sein....

von Joachim B. (jar)


Lesenswert?

Frank M. schrieb:
> Du kannst natürlich Deine XLS-Dateien wieder ins IRMP-Format umwandeln,
>
> das geht so: für jede zehntausendstel Sekunde schreibst Du eine 1, wenn
>
> der Empfänger aus war, für jede zehntausendstel Sekunde schreibst Du
>
> eine 0, wenn der Empfänger aktiv war. Das gibt dann eine Folge von 0en
>
> und 1en in einer langen Zeile z.B. so:
>
>
>
> 000000011111111111111000111000111.....
>
>
>
> Davor schreibst Du noch einen Kommentar:
>
>
>
> # OFF-Taste TV
>
> 000000011111111111111000111000111.....
>
> # OFF-Taste VCR
>
> 000000011111111111111000111000111.....
>
>
>
>> ist Exelformat und die XLS ist schon zu µs umgesetzt
>
>
>
> Nützt mir nichts. IRMP "versteht" halt nur das IRMP-Format selbst.
>
>
>
>> oszi zu CSV oder XLS ist halt schneller als HW bauen
>
>
>
> Naja, einen MAX232 dranbauen ist auch nicht soooo schwierig.


zu umwandeln, low aktiv oder high aktiv ?

in Ruhe kommen 5V aus dem TSOP 1736 wenn IR Signale erkannt werden 
wechselt es zu low


also 1 = 0 ? und 0 = 1 ?

dem MAX anbauen ist schwierig, weil 1. kein max232 in der Kiste, aber in 
der Datenbank, aber max233 in der Kiste aber nur SMD und da muss ich 
löten, dito macht sub-d in dem steckbrett keinen sinn und in smd hab ich 
den nicht, also muss ich max233 auf SMD und dann auf Lochraster mit 
SUB-D verheiraten bevor es ans Steckbrett geht, ist schon nicht trivial 
für mich mit meene ollen ogen :|

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:

> zu umwandeln, low aktiv oder high aktiv ?

low aktiv, also genau so, wie sie aus dem TSOP rauskommen.

Gruß,

Frank

von Joachim B. (jar)


Lesenswert?

so, ich baue grad mit dem max233 auf (murphy, natürlich habe ich den nur 
als SO und in der LBR gibt es den nur in DIL und die SO Variante hat 
andere Pinbelegung, deswegen erst mal Symbol und Dev in Eagle bauen, 
mann mann mann, das Leben könnte doch einfacher sein)

kann jemand kurz sagen wozu der Taster ist vergessen ? :o (Plan von Hr. 
Leidinger ?)

und warum muss Vcc an Ri ?

mit den Datenrichtungen DTE / DCE komme ich regelmäßig durcheinander

wer ist hier eigendlich was ? ich denke mal Atmel spielt Modem und 
betrachte ihn als DCE und nicht als DTE

glücklicherweise scheint bis jetzt im Plan alles zu stimmen

liebe gruesse
jar

von Joachim B. (jar)


Lesenswert?

Joachim B. schrieb:
> kann jemand kurz sagen wozu der Taster ist vergessen ? :o (Plan von Hr.
> Leidinger ?)

gefunden bootloader, SW nachladen, kann also raus,
bleibt also die Frage:

> und warum muss Vcc an Ri ?


liebe gruesse
jar

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:

> bleibt also die Frage:
>> und warum muss Vcc an Ri ?

Wovon redest Du? Vom Pullup am Reset-Pin in der Schaltung von Klaus 
Leidinger?

Gruß,

Frank

von Joachim B. (jar)


Angehängte Dateien:

Lesenswert?

Frank M. schrieb:
> Joachim B. schrieb:
>
>> bleibt also die Frage:
>>> und warum muss Vcc an Ri ?
>
> Wovon redest Du? Schaltung von Klaus Leidinger?
>
> Gruß,
>
> Frank

ja schrieb ich das nicht ?

bald kann ich scans von den FB loggen, dann schick ich alles was ich an 
FB finde

liebe gruesse
jar

von Joachim B. (jar)


Lesenswert?

und nun ? ich wusste ich hasse logging

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


ich verstehe logging auf 1 ?

steht ja auch da, 1 log IR


aber dann :

  #if IRMP_LOGGING == 0
  // USART initialization has to be done here if Logging is off
  // Communication Parameters: 8 Data, 1 Stop, No Parity
  // USART Receiver: Off
  // USART Transmitter: On
  // USART0 Mode: Asynchronous
  // USART Baud Rate: 9600
  #define BAUDRATE 9600L
  UCSR0A=0x00;
  UCSR0B=0x08;
  UCSR0C=0x06;
  UBRR0H = ((F_CPU+BAUDRATE*8)/(BAUDRATE*16)-1) >> 8;            // 
store baudrate (upper byte)
  UBRR0L = ((F_CPU+BAUDRATE*8)/(BAUDRATE*16)-1) & 0xFF;
  #endif


also wird das UART init wenn logging off ?

nix verstehen.....


bei build gibt:

../irmp.c:645: error: 'U2X' undeclared (first use in this function)

    UART0_UCSRA &= ~(1<<U2X);

ich finde die DEF von U2X nirgends ,

wo gehört sie wie hin ?

danke (sorry das ich blöd bin, ist immer schwer sich in fremden code 
zurechtzufinden und mit dem uart hab ich noch nie im atmel gearbeitet, 
tippe da muss irgendwo ein init vergessen sein)

liebe grüße jar

von Joachim B. (jar)


Lesenswert?

so uart ausgabe läuft,

irgendwie uart.c und .h vergessen

da der at644 irgendwie nicht drin lief eben ein paar defs geändert

egal läuft

nur com terminal spuckt nix aus

aber hterm aber mit sonderzeichen


nun weiss ich leider immer noch nicht wie ich mitloggen soll

entweder es ist zu dünne erklärt oder ich bin unfähig....


blicke grad nicht durch warum com terminal nix zeigt aber hterm und 
welches pc log prgramm laufen muss und unter xp laufen kann, mal eben 
linus booten ist grad nicht möglich und den rücken verdrehen zum anderen 
rechner auch nicht so lang sind meine kabel nicht

gruss
jar

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:

> aber hterm aber mit sonderzeichen

Du musst hterm auf 9600 Bd 8 Bit no Parity stellen.

> entweder es ist zu dünne erklärt oder ich bin unfähig....

Da ich von den IRMP-Anwendern bereits Dutzende Scan-Dateien erhalten 
habe, sollten die Erklärungen im IRMP-Artikel eigentlich reichen ;-)

Gruß,

Frank

von Joachim B. (jar)


Angehängte Dateien:

Lesenswert?

so

versuch mal dein Glück bitte

wenn das erfolgreich ist scanne ich alle Tasen und mher FBs

ich glaube meine Schaltung spinnt noch ein bissl,
nicht so leicht scans einzufangen wenn irgendjemand
irgendwo auf die FB drückt,
muss wohl in ein dunkles Zimmer ohne Fenster
und ohne IR Pyramiden,
die fangen sich offensichtlich auch was ein

lg
jar

: Wiederhergestellt durch Moderator
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb im Beitrag #1813217:
> so ?
> 11111111111111111110000......

Klasse, Du hast es geschafft, dass die Fensterbreite dieses Threads 
enorm gewachsen ist ;-)

Wäre wohl besser, den Beitrag zu löschen, sonst muss man zum Antworten 
erstmal eine halbe Stunde scrollen...

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:

> versuch mal dein Glück bitte

Habe es mir eben mal kurz angeschaut: Der Scan ist mit 15kHz 
aufgezeichnet worden... hättest Du auch sagen können ;-)

> nicht so leicht scans einzufangen wenn irgendjemand
> irgendwo auf die FB drückt,
> muss wohl in ein dunkles Zimmer ohne Fenster
> und ohne IR Pyramiden,
> die fangen sich offensichtlich auch was ein

Allerdings... die erste Zeile ist nur ein Fragment, die kann man nur in 
die Tonne stopfen. Die anderen 3 Zeilen sind brauchbar, allerdings hat 
sich da in die zweite Zeile neben eines Kaseikyo-Frames auch noch ein 
kompletter SAMSUNG32-Frame mit reingeschmuggelt. Ausserdem ist da auch 
noch ab und an anderer Schrott zwischendurch zu sehen.

Ich muss Deine Scans erstmal ein wenig säubern, bevor ich da näheres 
erkenne. Besser wäre es allerdings, mit 10kHz zu scannen (reicht für 
Kaseikyo vollkommen aus) und wirklich dafür zu sorgen, dass keine 
anderen IR-Sender dazwischenfunken.

Gruß,

Frank

von Joachim B. (jar)


Angehängte Dateien:

Lesenswert?

Frank M. schrieb:
> Joachim B. schrieb im Beitrag #1813217:
>> so ?
>> 11111111111111111110000......
>
> Klasse, Du hast es geschafft, dass die Fensterbreite dieses Threads
> enorm gewachsen ist ;-)
>
> Wäre wohl besser, den Beitrag zu löschen, sonst muss man zum Antworten
> erstmal eine halbe Stunde scrollen...
>
> Gruß,
>
> Frank

ich hab versucht zu löschen, geht nicht, ist mir ja auch peinlich, aber 
ich wollte kein Umbrüche drin haben

ich habe den Beitrag gemeldet, wenn ein Mod bitte diesen löscht !

kannst du mit den Scans was anfangen ?

hier noch mal

alle meine FB
die Kaseikyo würde ich scannen wenn du sagst du kannst sie auswerten, 
muss ich dann wirklich alle Tasten scannen ? ist ein Haufen Arbeit

warum wird die JVC immer noch nicht erkannt ? der Code sollte doch drin 
sein ?

habe mal jvc dazugelinkt

von Joachim B. (jar)


Angehängte Dateien:

Lesenswert?

Joachim B. schrieb:
> habe mal jvc dazugelinkt

hat nicht geklappt, neuer versuch

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:

> ich habe den Beitrag gemeldet, wenn ein Mod bitte diesen löscht !

Ich hatte ihn auch schon gemeldet ;-)

> kannst du mit den Scans was anfangen ?

Ja, habe ein Ergebnis. Die beiden verschiedenen OFF-Tasten bringen 
folgende 48 Daten-Bits:
1
         1         2         3         4
2
123456789012345678901234567890123456789012345678
3
010000000000010000001101000000001011110010110001 p =  5, a = 0x2002, c = 0x03d0, f = 0x00
4
010000000000010000000001000000001011110010111101 p =  5, a = 0x2002, c = 0x03d0, f = 0x00
5
ccccccccccccccccPPPPssssppppppppffffffffCCCCCCCC

IRMP ermittelt daraus jeweils die Adresse 0x2002 und das Kommando 
0x03d0. Tatsächlich unterscheiden sich aber die 48 Bits genau an 4 
Stellen, nämlich Bit21-22 und Bit45-46.

Dabei haben die 48 Bits folgenden Aufbau:

c = 16 Hersteller (customer) Bits
P = 4 Parity Bits
s = 4 System-Bits
p = 8 Produkt-Bits
f = 8 Funktions-Bits
C = 8 Datenüberprüfungs-Bits

Der signifikante Unterschied der beiden Tasten liegt in den 4 
System-Bits, die von IRMP bisher komplett ignoriert wurden - einfach, 
weil ich dafür keine genauen Infos herausgefunden habe, was diese Bits 
genau bedeuten. Dass IRMP überhaupt Datenbits bei Kaseikyo ignoriert, 
hat einen einfachen Grund: Ich muss die 48 bit irgendwie in 16 Adress- 
und 16 Kommando-Bits pressen. Ich muss mir also überlegen, wie ich die 4 
Systembits da noch unterbringe. Gib mir also bitte etwas Zeit ;-)

> alle meine FB
> die Kaseikyo würde ich scannen wenn du sagst du kannst sie auswerten,
> muss ich dann wirklich alle Tasten scannen ? ist ein Haufen Arbeit

10 Tasten reichen. Bitte aber nicht einfach nur die Zahlen 0-9 ;-)

> warum wird die JVC immer noch nicht erkannt ? der Code sollte doch drin
> sein ?

Ich werde mir den JVC-Scan anschauen. Ist der auch mit 15kHz gescannt?

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Frank M. schrieb:

> Ich werde mir den JVC-Scan anschauen.

Das Ding benutzt zwar die NEC-Timings, das Protokoll ist aber komplett 
anders aufgebaut: Nach jeweils 16 der insgesamt 50 Bits wird eine 
längere Pause von ca. 22msec eingelegt. Ausserdem scheinen die Daten 
(die nur eine Länge von 16 Bit haben) insgesamt 2x wiederholt zu werden.

Also ist der Aufbau:

 1 NEC-Start-Bit
16 Daten-Bits
 1 Stop-Bit + Pause (Synchronisation?)
16 Daten-Bits
 1 Stop-Bit + Pause (Synchronisation?)
16 Daten-Bits

Näheres kann ich Dir erst sagen, wenn Du mich mit mehr JVC-Scans 
versorgst.

Gruß,

Frank

von Joachim B. (jar)


Lesenswert?

Frank M. schrieb:
> 10 Tasten reichen. Bitte aber nicht einfach nur die Zahlen 0-9 ;-)

mach ich nach Wunsch oder Querbeet ?


Frank M. schrieb:
> Frank M. schrieb:
>
>> Ich werde mir den JVC-Scan anschauen.
>
> Das Ding benutzt zwar die NEC-Timings,...
> Gruß,
> Frank


auch das, s.o.
mach ich nach Wunsch oder Querbeet ?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:

> mach ich nach Wunsch oder Querbeet ?

Querbeet - halt die Tasten, die Du für am wichtigsten erachtestest. Wäre 
nicht schlecht, wenn die Nummerntasten 0, 1, 2 dabeiwären, da kann man 
meist gut eine Systematik ablesen.

Gruß,

Frank

von Joachim B. (jar)


Angehängte Dateien:

Lesenswert?

Frank M. schrieb:
> Joachim B. schrieb:
>> mach ich nach Wunsch ?
>
> Querbeet - halt die Tasten, die Du für am wichtigsten erachtestest. Wäre
> nicht schlecht, wenn die Nummerntasten 0, 1, 2 dabeiwären, da kann man
> meist gut eine Systematik ablesen.
> Gruß,
> Frank

so getan, aber nicht alle 10er Tasten 1-5 jeweils doppelt

ich hoffe ich habe mich nicht ver C&P und verguckt

ich sehe Jitter ? oder Frequenzabweichung, da ich ja doppelt gescant 
hatte erwarte ich 1 und 0 immer fast gleich, mal eine mehr oder weniger 
muss dann Jitter sein ? oder Frequenzabweichung ?

so ich werde dann mal das 128 x 64 gLCD anfrickeln mit LED Beleuchtung
jetzt hängt ja nur das 4x20 Z dran unbeleuchtet

wenn dir Scans fehlerhaft scheinen oder fehlen, bitte sofort melden, 
schick ich dann nach

die pana VCR FB fehlt mir noch, muss ich nachreichen, habe nur noch 3 
Tage Zugriff drauf

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:

> ich sehe Jitter ? oder Frequenzabweichung,

Ich sehe da zwischendurch viel Schrott, auch mal zwischendurch 
Samsung32-Frames. Ausserdem sind da bei den ersten paar Tasten 
unerklärliche Zeilenumbrüche drin. Funkt da was dazwischen?

Hatte ich auch heute vormittag in

Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"

geschrieben.

Bitte ausschließen, dass Deine "Pyramiden" dazwischenfunken und bitte 
auch die Scan-Frequenz auf 10kHz zurückschrauben. 15kHz sind hier nicht 
notwendig und verlängert die Scans unnötig.

Gruß,

Frank

von Joachim B. (jar)


Lesenswert?

Frank M. schrieb:
> Bitte ausschließen, dass Deine "Pyramiden" dazwischenfunken und bitte
> auch die Scan-Frequenz auf 10kHz zurückschrauben. 15kHz sind hier nicht
> notwendig und verlängert die Scans unnötig.
> Gruß,
> Frank

die heutigen scans ohne OFF Taste ohne Störungen von den Pyramiden, die 
sind daheim (die zuvor gescanten OFF Tasten hab ich aber reinkopiert um 
Arbeit zu sparen)

auf 10kHz umgestellt, nach Durchsicht der config brauche ich die wohl 
nicht

IRMP_SUPPORT_FDC_PROTOCOL
IRMP_SUPPORT_RCCAR_PROTOCOL
IRMP_SUPPORT_SIEMENS_PROTOCOL
IRMP_SUPPORT_RECS80_PROTOCOL
SUPPORT_RECS80EXT_PROTOCOL

Siemens könnte evt. noch kommen, dann wird man sehen

>15kHz sind hier nicht
> notwendig und verlängert die Scans unnötig.
> Gruß,
> Frank

aber hilft das nicht der Genauigkeit der Auswertung, weniger 
Jitterfehler ?

von Joachim B. (jar)


Lesenswert?

Frank M. schrieb:
> Allerdings... die erste Zeile ist nur ein Fragment, die kann man nur in
> die Tonne stopfen. Die anderen 3 Zeilen sind brauchbar, allerdings hat
> sich da in die zweite Zeile neben eines Kaseikyo-Frames auch noch ein
> kompletter SAMSUNG32-Frame mit reingeschmuggelt. Ausserdem ist da auch
> noch ab und an anderer Schrott zwischendurch zu sehen.
> Gruß,
> Frank

das hatte ich wohl überlesen,

ist halt doof wenn Frau beim Scan der Panasonic die Samsung bedient weil 
sie lauter oder leiser haben will (ich hatte vesucht aufzupassen, 
klappte wohl nicht immer) ausserdem sehe ich ab und an unmotiviert die 
IR Pyramiden blinken, war wohl keine gute Idee die alten scans 
dazuzulinken, OK und 15 kHz hatte ich verschwiegen, aber du findest 
offensichtlich alle Gemeinheiten die dir die User wohl unterjubeln (ohne 
Absicht)

also wie gesagt,

auf 10 kHz ist umgestellt (immer noch die Frage, wäre für Scan nicht 15 
kHz genauer?)
IR Pyramiden sind nicht hier und @work kann kein weiteres IR Signal 
stören, ausser Schmutz auf der Versorgungsleitung oder 
Maschineninduktion, hier sind schon irgendwo heftige Stanzen zu hören, 
aber wo die sind habe ich noch nicht rausgefunden, so ein Stahlbetonbau 
lääst die Gräusche zwar weit durch aber schlecht ortbar

ich sanne neu bei Bedarf

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:

> auf 10 kHz ist umgestellt

Gut.

> (immer noch die Frage, wäre für Scan nicht 15 kHz genauer?)

Nein, 10kHz reicht bei Deinen FBs vollkommen aus.

> ich sanne neu bei Bedarf

Ich baue erstmal die angekündigten Änderungen für Kaseikyo ein 
(Berücksichtigung der 4 System-Bits) und implementiere das 
JVC-Protokoll. Da wäre es aber klasse, wenn Du mir von der JVC ein paar 
10kHz-Scans liefern würdest.

Gruß,

Frank

von Joachim B. (jar)


Angehängte Dateien:

Lesenswert?

Frank M. schrieb:
> Ich baue erstmal die angekündigten Änderungen für Kaseikyo ein
> (Berücksichtigung der 4 System-Bits)

super DANKE dafür ! und bitte bitte IRSND nicht vergessen darauf kommt 
es ja hauptsächlich an (Ziel nicht aus den Augen verlieren will)

>und implementiere das
> JVC-Protokoll. Da wäre es aber klasse, wenn Du mir von der JVC ein paar
> 10kHz-Scans liefern würdest.

klaro das hat Zeit ist weniger für mich mehr für alle deren FB nicht 
mehr geht

ich hoffe ich habe keine copy paste Fehler drin

(einige scans waren zu lang und dann läuft hterm leicht über, im scroll 
fenster und man erwischt den anfang nicht)

heute frisch gescant 10 kHz ohne IR Pyramiden

#Sondertasten (VCR/DVD play rec usw.) unter Schiebeklappe bitte nicht 
noch auch, nur wenn die Not gross ist :-)

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:

> heute frisch gescant 10 kHz ohne IR Pyramiden

Die Scans sehen sehr gut aus. Die Abweichungen (Jitter) sind normal, die 
FBs senden nicht soooo genau. Ausserdem kommt schon durch das Pollen in 
der ISR ein Fehler von +/- 1 zustande. IRMP arbeitet aber mit 
Toleranzen, deshalb ist das überhaupt nicht tragisch.

Ich kümmere mich erstmal um Kaseikyo, dann melde ich mich wieder.

Gruß,

Frank

von Joachim B. (jar)


Lesenswert?

Frank M. schrieb:
> Ich kümmere mich erstmal um Kaseikyo, dann melde ich mich wieder.
> Gruß,
> Frank

fein morgen scanne ich alle meine Panasonic FB Kaseikyo neu
VCR NV FJ630 VHS
TV TX-L32S10ES
DVD/HDrec Panasonic DMR-EX 79

10 kHz ohne IR Pyramidenstörungen

von Joachim B. (jar)



Lesenswert?

Frank M. schrieb:
> Ich baue erstmal die angekündigten Änderungen für Kaseikyo ein
> (Berücksichtigung der 4 System-Bits)
> Gruß,
> Frank

brauchst du noch was ?

hier die KASEIKYO Panasonic VCR FB

von Joachim B. (jar)


Lesenswert?

Frank M. schrieb:
> Die Scans sehen sehr gut aus. Die Abweichungen (Jitter) sind normal,
> Gruß,
> Frank

das wundert mich nun etwas,

sagte ich nicht das an dem MAX nur +5 und NULL rauskamen ?

nun nachdem ich den Schluss unter dem SMD PAD (MAX233 9 GND nach 10 
irgendein int. Kondi) gefunden hatte habe ich jetzt endlich +-10V

aber wenn die Scans schon vorher gut waren soll das nicht weiter stören

von Michael H. (michael_h45)


Lesenswert?


von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:
> hier die KASEIKYO Panasonic VCR FB

Danke, habe ich mir angeschaut, leider sind nur 161 von 216 Scans okay. 
55 Scans weisen einen abweichenden Herstellercode auf, welcher für 
Panasonic 0x2002 ist. Ist die Datei auch schon mit dem MAX-Kurzschluss 
erstellt worden?

Macht nix, der Rest ist echt brauchbar.

Achja, noch eine Bitte: Beim Scannen bitte immer die Tasten so kurz wie 
möglich drücken. Beim JVC-Scan hast Du da offenbar des öfteren ziemlich 
lange den Finger auf den Tasten gehabt - jedenfalls zu Anfang bei den 
ersten Tasten ;-)

Dank und Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Michael H. schrieb:
> http://de.wikipedia.org/wiki/Jitter

Ja, und? Ist hier die Bezeichnung "Jitter" falsch, wenn es um
Messabweichungen von Rechtecksignalen wie bei den folgenden geht?
1
1. Messung: 000000000000000111111111000000000011111111110000000
2
2. Messung: 000000000000000011111111100000000111111111100000000
3
3. Messung: 000000000000001111111110000000000011111111110000000

Trotzdem danke für den interessanten Link.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Lesenswert?

Frank M. schrieb:
> Ich baue erstmal die angekündigten Änderungen für Kaseikyo ein
> (Berücksichtigung der 4 System-Bits) und implementiere das
> JVC-Protokoll.

Anbei die geänderten Sources zum Test.

Neu:

 - Kaseikyo: es werden nun die 4 System-Bits (Genre2) im Frame
   ausgewertet

 - Neues Protokoll: JVC

Viel Spaß,

Frank

von Joachim B. (jar)


Lesenswert?

Frank M. schrieb:
> Joachim B. schrieb:
>> hier die KASEIKYO Panasonic VCR FB
>
> Danke, habe ich mir angeschaut, leider sind nur 161 von 216 Scans okay.
> 55 Scans weisen einen abweichenden Herstellercode auf, welcher für
> Panasonic 0x2002 ist.

hmm, welche ?, könnte die ja nachliefern, hast ja die #Headerzeile dazu

>Ist die Datei auch schon mit dem MAX-Kurzschluss
> erstellt worden?

ja leider, wollte erst liefern, dann hat mich der Pegel doch nicht ruhen 
lassen und ich ging auf Fehlersuche

> Macht nix, der Rest ist echt brauchbar.
> Achja, noch eine Bitte: Beim Scannen bitte immer die Tasten so kurz wie
> möglich drücken. Beim JVC-Scan hast Du da offenbar des öfteren ziemlich
> lange den Finger auf den Tasten gehabt - jedenfalls zu Anfang bei den
> ersten Tasten ;-)
> Dank und Gruß,
> Frank

na ja man wartet immer auf Bestätigung, ich hab ne LED Quittung 
eingebaut, 1s LED Blink wenn Code erkannt, nur im Logging Mode erkennt 
er ja nix und ich warte vergebens und im HTERM kommen die Daten 
offensichtlich erst verzögert, also bleib ich zu lang drauf und dann 
wollen die Daten nicht enden

einige Tasten sind auch versenkt um Fehlbedienungen zu meiden, deren 
Druckpunkt ist schwer zu fühlen

ich weiss, alles Ausreden, aber wer so lange im Beruf ist der kann wohl 
nicht anders

danke und gruß zurück
jar

von Joachim B. (jar)


Lesenswert?

Frank M. schrieb:
> Frank M. schrieb:
> Ich baue erstmal die angekündigten Änderungen für Kaseikyo ein
> (Berücksichtigung der 4 System-Bits)
> Neu:
>  - Kaseikyo: es werden nun die 4 System-Bits (Genre2) im Frame
>    ausgewertet

hmm, aber scheinbar noch etwas wackelig (muss ich mir meine 
Abblockkondis ansehen oder meine 5V Versorgung ?), wenn die FB nicht 
genau ausgerichtet ist und man nicht lange drückt erkennt er viele 
Zufallscodes, ist nicht so stabil wie RC5, da kenne ich nur ja / erkannt 
oder nein / eben nicht, aber Zufallscodes seh ich nie


> und implementiere das
> JVC-Protokoll.
>  - Neues Protokoll: JVC
ah, erst verwundert, wird nicht angezeigt, dann aber

meine JVC wird erkannt , A + C wird angezeigt aber unter Code nicht JVC 
!

> Viel Spaß,
> Frank

danke den hab ich schon

von Michael H. (michael_h45)


Lesenswert?

Frank M. schrieb:
> Ja, und? Ist hier die Bezeichnung "Jitter" falsch, wenn es um
> Messabweichungen von Rechtecksignalen wie bei den folgenden geht?
Nein, nicht bei dir.
Nur bei Joachim klang es danach, dass er damit die 
Spannungs-Sonderheiten wegen seiner MAX-Beschaltung meinte.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:

> meine JVC wird erkannt ,

Gut.

> A + C wird angezeigt

Auch gut.

> aber unter Code nicht JVC

Den Satz verstehe ich nicht. Hast Du im main() eine Text-Ausgabe über 
ein Text-Array drin und vermisst nun das Wörtchen "JVC"? Das gehört 
nicht wirklich zu den IRMP-Sources dazu, denn:

irmp_get_data liefert lediglich

   uint8_t protocol
   uint16_t address
   uint16_t command

protocol hat den Wert 20 bei JVC, siehe irmp.h, da sind alle Protokolle 
drin.

Du müsstest bei Deiner Textausgabe das Text-Array auf 20 vergrößern und 
dort den String "JVC" eintragen.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:

> hmm, aber scheinbar noch etwas wackelig (muss ich mir meine
> Abblockkondis ansehen oder meine 5V Versorgung ?), wenn die FB nicht
> genau ausgerichtet ist und man nicht lange drückt erkennt er viele
> Zufallscodes, ist nicht so stabil wie RC5,

Was für einen IR-Empfänger nutzt Du? TSOP1736 oder 1738? Das Problem 
ist, dass Kaseikyo mit 56 kHz moduliert wird und der TSOP mit seinen 
36kHz bzw. 38kHz ziemlich daneben liegt. Die Entfernung sinkt drastisch 
und die Fehlerquote nimmt zu.

Gruß,

Frank

von Joachim B. (jar)


Lesenswert?

Frank M. schrieb:
> Den Satz verstehe ich nicht. Hast Du im main() eine Text-Ausgabe über
> ein Text-Array drin und vermisst nun das Wörtchen "JVC"? Das gehört
> nicht wirklich zu den IRMP-Sources dazu, denn:
>
> irmp_get_data liefert lediglich
>
>    uint8_t protocol
>    uint16_t address
>    uint16_t command
> protocol hat den Wert 20 bei JVC, siehe irmp.h, da sind alle Protokolle
> drin.
> Du müsstest bei Deiner Textausgabe das Text-Array auf 20 vergrößern und
> dort den String "JVC" eintragen.
> Gruß,
> Frank

sowas dachte ich schon, nur hab ich die Zuweisung nicht gefunden

aber nun

static char 
*Proto[]={"SIRCS","NEC","SAMSUNG","MATSUSH","KASEIKYO","RECS80","RC5(x)" 
,"DENON","RC6","SAMSG32","APPLE","RECS80x","NUBERT","JVC"};

> Du müsstest bei Deiner Textausgabe das Text-Array auf 20 vergrößern

wie das ich finde nirgends eine Zuweisung von Array auf 20

soweit wie ich C gelernt habe ist durch anhängen von ,"JVC" das Array 
schon ab compile vergrößert, da es ja statisch initialisiert wird, eine 
seperate Zuweisung dürfte nicht (nötig) sein und finde ich auch nicht

hmm es funzt jedenfalls noch nicht

ich tippe auf NEC erkannt und JVC eben nicht

von Joachim B. (jar)


Lesenswert?

Frank M. schrieb:
> Was für einen IR-Empfänger nutzt Du? TSOP1736 oder 1738? Das Problem
> ist, dass Kaseikyo mit 56 kHz moduliert wird und der TSOP mit seinen
> 36kHz bzw. 38kHz ziemlich daneben liegt. Die Entfernung sinkt drastisch
> und die Fehlerquote nimmt zu.
> Gruß,
> Frank


TSOP 1736 , aber mein Scan an einer BPW21 lieferte 36 kHz Schwingungen

ich könnte ja noch mal einen OP vorschalten und eine FFT machen

gruss
jar

von Joachim B. (jar)


Lesenswert?

peinlich peinlich

sind ja nur 14 Text STR definiert, hab nicht nachgezählt

musste also 6x "", einfügen das 20 auf "JVC" zeigt ......

ja ich bin aus der Übung und sehe nicht immer alles (sofort)

gruss
jar

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:
> aber nun
>
> static char
> *Proto[]={"SIRCS","NEC","SAMSUNG","MATSUSH","KASEIKYO","RECS80","RC5(x)" 
,"DENON","RC6","SAMSG32","APPLE","RECS80x","NUBERT","JVC"};

Du hast "JVC" an 14. Stelle statt an 20. Stelle eingetragen, damit das 
Array auch nur auf 14 Elemente vergrößert.

>
>> Du müsstest bei Deiner Textausgabe das Text-Array auf 20 vergrößern
>
> wie das ich finde nirgends eine Zuweisung von Array auf 20

Eben, die Dimension von Proto[] ist nicht angegeben.

> hmm es funzt jedenfalls noch nicht

Trage alle fehlenden Namen ein (die einzelnen nicht zu lang machen!) und 
sorge dafür, dass "JVC" an 20. Stelle steht, siehe Nummern der 
Protokolle 1-20 in irmp.h.

Gruß,

Frank

von Joachim B. (jar)


Lesenswert?

Frank M. schrieb:
> Eben, die Dimension von Proto[] ist nicht angegeben.
> Trage alle fehlenden Namen ein (die einzelnen nicht zu lang machen!) und
> sorge dafür, dass "JVC" an 20. Stelle steht, siehe Nummern der
> Protokolle 1-20 in irmp.h.
> Gruß,
> Frank


hatte ich doch schon,

Joachim B. schrieb:
> peinlich peinlich
> sind ja nur 14 Text STR definiert, hab nicht nachgezählt
> musste also 6x "", einfügen das 20 auf "JVC" zeigt ......
> ja ich bin aus der Übung und sehe nicht immer alles (sofort)
> gruss
> jar



ich denke ich werde trotzdem noch mal einen Frequenz Scan aller FB 
machen

wie geschrieben mit BPW21 OP und FFT
und mal alle meine FB scannen

von Joachim B. (jar)


Lesenswert?

Frank M. schrieb:
> Das Problem ist, dass Kaseikyo mit
>> 56 kHz
> moduliert wird und der TSOP mit seinen 36kHz bzw. 38kHz
> ziemlich daneben liegt.
> und die Fehlerquote nimmt zu.
> Gruß,
> Frank

wo hast du die Daten her ?

ich kann hier machen was ich will

ich messe burst von 26-28 µs was 35,9 - 38,5 kHz gibt

übrigens alle
>> meine Kaseikyo liegen eher bei 36 kHz ,
nur die JVC scheint um 38 kHz zu liegen

bin verwirrt von deinen 56 kHz

gruss
jar

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:

> bin verwirrt von deinen 56 kHz

Laut
http://www.mikrocontroller.net/attachment/4246/IR-Protokolle_Diplomarbeit.pdf

auf Seite 26 (hier "Japan-Code" genannt) sind es 56 kHz. Da habe ich das 
her.

Aber es gibt noch eine zweite Quelle, nach welcher ich das 
Kaseikyo-Protokoll implementiert habe, nämlich:

http://www.roboternetz.de/phpBB2/files/entwicklung_und_realisierung_einer_universalinfrarotfernbedienung_mit_timerfunktionen.pdf

Und tatsächlich wird hier von 38kHz (auf Seite 8) geredet. Entweder 
werden verschiedene Modulationsfrequenzen bei Kaseikyo eingesetzt oder 
meine erste Quelle hat schlichtweg einen Fehler. Leider habe ich 
persönlich keine Kaseikyo-kompatible FB, kann daher nix dazu sagen.

Leider habe ich auch nicht mehr Doku als diese beiden Quellen. Wenn Du 
da noch irgendeine Doku ausgraben könntest, würde ich mich freuen.

Gruß,

Frank

von Wolfgang Dunczewski (midi-rakete) (Gast)


Lesenswert?

Ich lese oben, dass es Probleme gibt/gab mit dem Code einer Kathrein 
UFS-922 Fernbedienung. Wurde das Problem gelöst? Ich habe beim Bau einer 
FB diesen Code enträtselt.....

von Joachim B. (jar)


Lesenswert?


von Joachim B. (jar)


Lesenswert?

ach ja , vergessen

irgendwer schrieb mal was von 450 kHz IR Modulation, aber ich bin nicht 
sicher ob das so stimmt, weil :

einige modilieren auch mit x-facher Frequenz wegen oversampling

da können die paar 100 kHz auch vielfache von 36 oder 38 - 40 oder 56 
kHz sein

ggffs kann man später mal in IRSND oversampling einstellen und schauen 
was aus den TSOP rauskommt, ich vermute mit exakt doppelter oder gerade 
Vielfache werden die auch output liefern.......

gruss
jar

von Samuel (Gast)


Lesenswert?

Joachim B. schrieb:
> peinlich peinlich
Spiegelt deinen Auftritt hier gut wieder.
Du hast mal von jar nüscht Ahnung.

von Joachim B. (jar)


Lesenswert?

Samuel schrieb:
> Joachim B. schrieb:
>> peinlich peinlich
> Spiegelt deinen Auftritt hier gut wieder.
> Du hast mal von jar nüscht Ahnung.

danke danke, von nüscht würde ich nüscht sagen.....

OK ich bin nicht so der Softi und aus der Übung

aber war der Kommentar nötig ?

na egal wer anonym so was schreibt braucht das wohl

ich komm schon klar, hab halt nicht die Arrays ausgezählt

wer so perfekt ist wie du kann sich anmelden und auch besser Fragen 
beantworten und zum Rest höflich schweigen....

freundlichen gruss
jar

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Wolfgang Dunczewski (midi-rakete) schrieb:
> Ich lese oben, dass es Probleme gibt/gab mit dem Code einer Kathrein
> UFS-922 Fernbedienung. Wurde das Problem gelöst?

Nein, die Kathrein benutzt einen RC6-Mode, der nicht oder nur spärlich 
dokumentiert ist. IRMP unterstützt nur den sog. Mode 0 von RC6, siehe 
auch:

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

> Ich habe beim Bau einer FB diesen Code enträtselt.....

Dann schieß mal los.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:

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

Keine Infos zum Kaseikyo-Protokoll.

> http://www.hifi-remote.com/forums/viewtopic.php?t=6401

Keine Infos zum Kaseikyo-Protokoll.

> 
http://www.hifi-remote.com/forums/viewtopic.php?t=12233&sid=cdf5a421a7ecc165af055f6555019261

Keine Infos zum Kaseikyo-Protokoll.

> http://www.google.de/url?sa=t&source=web&cd=6&ved=0CEMQFjAF&url=http%3A%2F......

Nette Tabelle, aber keine Infos zum Kaseikyo-Protokoll selbst.

> http://usa.denon.com/AVR-4308CI_IRCodes.pdf

Dito.

> sehr interessant:
> http://ecee.colorado.edu/~mcclurel/vishay_ir_data_formats.pdf

Danke, immerhin steht da drin, dass Kaseikyo mit 36.7kHz moduliert wird. 
Werde ich im IRMP-Artikel anpassen.

> Kaseikyo 56 kHz muss ein Fehler sein, finde nix, ausser beim Klaus

Der hat es wahrscheinlich von mir....

Insgesamt ist Deine Liste nicht so der Renner, trotzdem danke dafür.

Vielleicht hättest Du Dir vorher mal die Literatur-Hinweise aus dem 
IRMP-Artikel angucken sollen, um entsprechend auszufiltern und nicht 
jeden Google-Treffer einfach hier reinzukopieren ;-)

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


Gruß,

Frank

von Wolfgang Dunczewski (midi-rakete) (Gast)


Lesenswert?

Frank M. schrieb:
> Nein, die Kathrein benutzt einen RC6-Mode, der nicht oder nur spärlich..
>
> http://www.sbprojects.com/knowledge/ir/rc6.htm
>
>> Ich habe beim Bau einer FB diesen Code enträtselt.....
>

Ich fand im Web Infos über den RC-6 Mode 6A 20:

[[http://www.guiott.com/wrc/RC6-6.html]]

mit 20 Bit Nutzrate

Die Kathrein nutzt "in etwa" diesen als 32 Bit Version (RC-6 mode 6a 
32), aber nicht nach Norm:

Die FB vom UFS-922 macht folgendes:

Leader Pulse (ok)
Start Bit (ok)
Mode Bits 2,1,0 (H,H,L = Mode 6)
Trailer Bit: Flanke immer L>H (nicht offiziell, soll normal toggeln)

Dann folgen 4 Bytes:

Das erste Byte ist immer 10000000 (von links nach rechts wird gesendet)
Das zweite Byte ist immer 01000110

Das dritte Byte enthält das Toggle-Bit TB und
die Ebene/Adresse falls man mehrere FBs hat

TB AD2 AD1 AD0 0000

also normal bei Adresse 0:

10000000
und abwechselnd
00000000

Eigenlich gehört das Togglebit an eine andere Stelle. Das Trailer Bit 
soll eigentlich toggeln. Aber Kathrein lässt ein Bit togglen. Deshalb 
funtioniert fast keine programmierbare FB mit dem Kathrein.

Und im 4. Byte kommen die Befehe 00-FF

nnnnnnnn

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Wolfgang Dunczewski (midi-rakete) schrieb:

> Die Kathrein nutzt "in etwa" diesen als 32 Bit Version (RC-6 mode 6a
> 32), aber nicht nach Norm:
> [...]

Vielen Dank für die Infos, werde ich mir mal zu Gemüte führen.

Gruß,

Frank

von Joachim B. (jar)


Lesenswert?

Frank M. schrieb:
>> Joachim B. schrieb:
>> sehr interessant:
>> http://ecee.colorado.edu/~mcclurel/vishay_ir_data_formats.pdf
>
> Danke, immerhin steht da drin, dass Kaseikyo mit 36.7kHz moduliert wird.
> Werde ich im IRMP-Artikel anpassen.

> Insgesamt ist Deine Liste nicht so der Renner, trotzdem danke dafür.
> Vielleicht hättest Du Dir vorher mal die Literatur-Hinweise aus dem
> IRMP-Artikel angucken sollen, um entsprechend auszufiltern und nicht
> jeden Google-Treffer einfach hier reinzukopieren ;-)
> Gruß,
> Frank

immerhin hab trotzdem noch was gefunden, sorry das es mir nicht möglich 
war alle Infos mit den vorhandenen abzugleichen, ich hab hier grad Land 
unter und bin deswegen nur sehr begrenzt konzentriert dabei, ich hoffe 
das geht trotzdem i.O.

gruss
jar

von Joachim B. (jar)


Lesenswert?

Frank M. schrieb:
> Vielen Dank für die Infos, werde ich mir mal zu Gemüte führen.
> Gruß,
> Frank

hallo,

wie siehts aus mit KASEIKYO im IRSND ?

würde dann bald ein IRSND Modul aufbauen für

PC -> RS232 -> Atmel IRSND -> IS Sendediode

ich grübel gerade ob der Umweg über Atmel sein muss weil,

kennst du den CT Artikel IRDEO ?
http://www.heise.de/ct/projekte/Fernregie-IRdeo-284185.html
http://irdeo.de/

dort wurde IR Empfang und Senden mit der seriellen Schnitte gemacht, 
funzte so leidlich (sogut win das eben zulässt) mit W2k und XP musste 
der IO (giveio o.ä.) Treiber installiert werden
http://irdeo.de/ntdriver.zip
GIVEIO.SYS (Dale Roberts), LOADDRV (Paula Tomlinson)


senden war übrigens tricky, die IR Modulation 36  38  40 kHz wurde per 
Baudrate / respektive geschickte 1/0 Wahl eingestellt, je nach 1/0 Folge 
und Baudrate ist ja quasi jede IR Modulation machbar, die Start oder 
Stoppbits, wenn sie einzeln erfolgen, scheinen nicht zu stören

leider war es nur eine lernbare FB welche die Codes nur gelernt wieder 
abspielen konnte und mit der Erkennung haperte es leider auch, da ist 
dein Projekt viel weiter und besser, aber ggffs kann man die beiden 
Konzepte zusammenbringen

für mich wäre ja nur IR Sender nötig wenn ich das ohne Atmel am RS232 
Port erreiche spart das Arbeit und Geld (nix gegen die Atnelbastelleien)

freundliche Grüße
jar

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:

> wie siehts aus mit KASEIKYO im IRSND ?

Wie ich schon schrieb: dafür brauche ich Futter, damit ich sämtliche 
Paritätsbits aus den Daten wieder erzeugen kann. Nur so kann ich die 32 
Bit IRMP-Datenstruktur auf die vollen 48bit-Kaseikyo-Frames aufblasen.

Ich warte daher immer noch auf die Scan-Dateien Deiner 3 
Kaseikyo-Fernbedienungen, die Du mir schon vor ein paar Tagen 
angekündigt hattest.

Ich brauche von jeder dieser 3 FB ca. 10 Tasten, wie ich schon mal 
schrieb.

Du hattest hier mal für die Panasonic VCR FB Scans reingestellt, wo aber 
noch erhebliche Störungen drin waren. Du hattest den Grund wohl gefunden 
und wolltest den Scan wiederholen. Bisher hab ich da aber nix neues von 
Dir gesehen.

> kennst du den CT Artikel IRDEO ?

Ja, habe ich mal vor Jahren überflogen.

> für mich wäre ja nur IR Sender nötig wenn ich das ohne Atmel am RS232
> Port erreiche spart das Arbeit und Geld (nix gegen die Atnelbastelleien)

Sorry, wüsste ich jetzt nicht, wie. Du kannst natürlich den IRSND-Code 
auf eine andere Plattform portieren.

Gruß,

Frank

von Joachim B. (jar)


Lesenswert?

Frank M. schrieb:
> Joachim B. schrieb:
>> wie siehts aus mit KASEIKYO im IRSND ?

> Wie ich schon schrieb: dafür brauche ich Futter, damit ich sämtliche
> Paritätsbits aus den Daten wieder erzeugen kann. Nur so kann ich die 32
> Bit IRMP-Datenstruktur auf die vollen 48bit-Kaseikyo-Frames aufblasen.
>
> Ich warte daher immer noch auf die Scan-Dateien Deiner 3
> Kaseikyo-Fernbedienungen, die Du mir schon vor ein paar Tagen
> angekündigt hattest.
>
> Ich brauche von jeder dieser 3 FB ca. 10 Tasten, wie ich schon mal
> schrieb.
>
> Du hattest hier mal für die Panasonic VCR FB Scans reingestellt, wo aber
> noch erhebliche Störungen drin waren. Du hattest den Grund wohl gefunden
> und wolltest den Scan wiederholen. Bisher hab ich da aber nix neues von
> Dir gesehen.
> Gruß,
> Frank


war wohl ein Missverständniss

auf die VCR FB hab ich nun kein Zugriff mehr, ich hab noch im Ohr, sind 
zwar Störungen drin aber brauchbar

Frank M. schrieb:
> Joachim B. schrieb:
>> hier die KASEIKYO Panasonic VCR FB
>
> Danke, habe ich mir angeschaut, leider sind nur 161 von 216 Scans okay.
> 55 Scans weisen einen abweichenden Herstellercode auf, welcher für
> Panasonic 0x2002 ist. Ist die Datei auch schon mit dem MAX-Kurzschluss
> erstellt worden?
>
> Macht nix, der Rest ist echt brauchbar.
> Dank und Gruß,
> Frank

die 161 scans reichen nicht von der VCR ?

Ich kann also nur noch
Panasonic TV liefern und Panasonic HDrec/DVD

muss mal sehen ob ich den VCR noch mal bekomme

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:
> die 161 scans reichen nicht von der VCR ?

Wenn es diese FB ist, welche Du über IRSND auch emulieren willst - ja, 
dann reicht es.

> Ich kann also nur noch
> Panasonic TV liefern und Panasonic HDrec/DVD

Wenn Du die für IRSND nicht brauchst, dann nicht. Wäre aber trotzdem 
nett, wenn Du davon jedoch auch noch je 10 Scans machen könntest, dann 
kann ich das allgemeiner in IRSND machen.

Sag mir bitte auch, welche FB Du mit IRSND emulieren möchtest.

Gruß,

Frank

von Joachim B. (jar)


Lesenswert?

Frank M. schrieb:
> Sag mir bitte auch, welche FB Du mit IRSND emulieren möchtest.
> Gruß,
> Frank

eigendlich genau diese

Panasonic HDrec/DVD

und die sollst du noch mal bekommen

zur Fernprogrammierung über PC


TV hat ja aus der Ferne irgendie keinen Sinn, da könnte ich gleich winTV 
im Rechner starten

ich hab den IRMP so schön auf 4x MiMh Akku laufen, damit wäre mobiles 
logging auch für den VCR möglich, aber seit der MAX dranhängt läuft der 
TSOP nicht mehr, der MAX braucht 1W sind 200mA und zieht offensichtlich 
den Pegel runter, ohne externe Versorgung geht da leider nix

ich grübel gerade ob ich den MAX rausschmeisse und einfach mit 2 Trasis, 
simple RS232 Konverter baue
http://picprojects.org.uk/projects/simpleSIO/ssio.htm

1W ist schon heftig
alternativ ginge ja die RS232 anzuzapfen, einige Dioden nach P5 sollte 
wieder mehr Strom liefern, DTR und RTS kann man ja setzen, nur auf + 
setzen , sollten ja ungefähr je 20mA liefern können

so ähnlich hatte ich auch meine PONY Elektronik aus der parallelen 
gespeist, einfach 15 BAT42 an jede signalführende Leitung auf einen 
Pufferkondi, reicht für CMOS Logik und Signal LED 3mA

von Joachim B. (jar)


Angehängte Dateien:

Lesenswert?

Halbzeit

versucht alle Tasten je 2x zu scannen, Tastendruck so kurz wie möglich

musste leider im logging CR LF einfügen, ich hoffe das stört nicht

morgen verm. den Rest

freundliche Grüße
jar

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:

> versucht alle Tasten je 2x zu scannen, Tastendruck so kurz wie möglich

Sehr sauberer Scan: keine Störungen, keine Erkennungsfehler. Bei der 
Gelegenheit habe ich erkannt, dass bei Kaseikyo auch bei kurzen 
Tastendrücken immer mindestens zwei Frames verschickt werden. Bei 
längeren Tastendrücken werden drei Frames und mehr gesandt. Ich hatte 
das bisher zwar schon immer vermutet, hatte aber da noch nie geeignete 
Kaseikyo-Scans.

Ich muss da im IRMP bzgl. Kaseikyo noch nacharbeiten: die erste 
Wiederholung des Frames muss unterdrückt werden. Erst alle weiteren 
Wiederholungsframes sind als langer Tastendruck auszuwerten. Sonst 
bekommt man immer einen langen Tastendruck zurück - auch wenn man die 
Taste nur kurz gedrückt hat.

> musste leider im logging CR LF einfügen, ich hoffe das stört nicht

Passt perfekt.

Wann ich das Enkodieren in den IRSND einbaue, kann ich Dir noch nicht 
genau sagen. Habe im Moment viel um die Ohren.

Gruß,

Frank

von Joachim B. (jar)


Angehängte Dateien:

Lesenswert?

so der 2te Teil

viel Erfolg mit den CRC

gruss
jar

von Joachim B. (jar)


Angehängte Dateien:

Lesenswert?

Frank M. schrieb:
> Ich muss da im IRMP bzgl. Kaseikyo noch nacharbeiten: die erste
> Wiederholung des Frames muss unterdrückt werden. Erst alle weiteren
> Wiederholungsframes sind als langer Tastendruck auszuwerten. Sonst
> bekommt man immer einen langen Tastendruck zurück - auch wenn man die
> Taste nur kurz gedrückt hat.

gibt es da keine Toggel Bits wie in RC5 ? dort klappt das hervorragend 
mit der Toggelbitauswertung, habe meinen Timer ja mit

Peters RC5 gebaut
Beitrag "Fernbedien RC5 Empfänger"

da klappt das einfach mit toogle Bit auswerten, muss ja nicht erkennen 
ob lang oder kurz

> Wann ich das Enkodieren in den IRSND einbaue, kann ich Dir noch nicht
> genau sagen. Habe im Moment viel um die Ohren.
> Gruß,
> Frank

OK danke erst Mal, ich bekomm ja Bescheid wenn du hier weiterbist und 
postest

viel um die Ohren, wer nicht ;-) (wenn du wüsstest)

gruss
jar

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:

> gibt es da keine Toggel Bits wie in RC5 ?

Nein, gibt es nur in RC5, RC6 und RECS80. In den anderen 17 Protokollen, 
die IRMP "versteht", gibt es kein Toggle-Bit. Dort gibt es u.a. 
alternative Mechanismen wie zum Beispiel Repetition-Frames (NEC). 
Kaseikyo hat hier nichts, hier arbeite ich mit Timeouts, um längere 
Tastendrücke von X-maligen Tastendrücken zu unterscheiden.

>> Wann ich das Enkodieren in den IRSND einbaue, kann ich Dir noch nicht
>> genau sagen. Habe im Moment viel um die Ohren.
> OK danke erst Mal, ich bekomm ja Bescheid wenn du hier weiterbist und
> postest

Bin doch schon fertig damit. Ich lade hier gleich den Test-Source hoch.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Lesenswert?

Anbei die geänderten Sources (gegenüber der Download-Version) mit 
verbesserter Unterstützung des Kaseikyo-Protokolls als Test-Version.

Änderungen IRMP
---------------

- Kaseikyo-Protokoll:
  Unterschiedliche Behandlung des 1. Wiederholungsframes (kein langer
  Tastendruck) von nachfolgenden Wiederholungsframes (langer
  Tastendruck).

- Kaseikyo-Protokoll:
  Auswertung der 4 + 8 = 12 "Parity-Bits", um Empfangsfehler zu
  erkennen.

Änderungen IRSND
----------------

- Unterstütrung des Kaseikyo-Protokolls inkl. Parity- und Genre1-Bits.
- Keine Unterstützung der Genre2-Bits beim Kaseikyo-Protokoll

Schwächen
---------

Das Kaseikyo-Protokoll enthält von den 48 Bit insgesamt 36 
Nutzdatenbits. Da die IRMP-Datenstruktur nur 32 Bits (16 Adresse, 16 
Kommando) davon speichern kann, gehen leider 4 Bits verloren. Dabei 
handelt es sich um die sog. Genre2-Bits, die aber meist 0000 sind.

Relevant kann diese Schwäche beim Senden per IRSND werden, da dann die 
Codes einiger bestimmter Tasten (wie MENÜ und OK bei Panasonic) nicht 
gesandt werden können.

Abhilfe könnte hier die Erweiterung der IRMP-Datenstruktur um ein neues 
Byte namens "product" bringen. Muss ich nochmal nachdenken, ob ich das 
einbaue. Wahrscheinlich wird es im nächsten Release enthalten sein.

Gruß,

Frank

von Dirk W. (dirkw)


Angehängte Dateien:

Lesenswert?

Hallo,

Ist IRMP eigentlich mit der neuen Apple Remote (Unibody) kompatibel?

Hab mir gestern eine gekauft und wollte sie in meinem aktuellen Projekt 
verwenden; funktionierte aber leider nicht. Keinerlei Reaktion von IRMP.

Einen Debug Trace der Apple Remote habe ich mal angehängt (Trace enthält 
noch eine Taste einer anderen FB zum Vergleich), sowie einen 
aufbereiteten Oszilloskop-Mitschnitt.

CU Dirk

von Klaus L. (kllei)


Lesenswert?

Hallo Dirk,

diese Seite: http://en.wikipedia.org/wiki/Apple_remote
lässt darauf schliessen das beide gleich sind.
Laut Apple Seite ist die Unibody Remote mit allen Produkten nach 2005 
eingeführt wurden kompatibel, was nicht das gleiche ist...

Ich hatte die alte (Plastik) FB mit dem iPod 5 Generation getestet, der 
im Oktober 2005 vorgestellt wurde, hatte funktioniert. Diese scans waren 
auch die "Referenz" für Frank. (falls nicht jemand neue scans geliefet 
hat).

Ich glaube dem Wiki Artikel und bin sicher das beide Remote das gleiche 
Protokoll haben.

HTH,
Klaus

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Dirk W. schrieb:

> Hab mir gestern eine gekauft und wollte sie in meinem aktuellen Projekt
> verwenden; funktionierte aber leider nicht. Keinerlei Reaktion von IRMP.

Ich habe mir gerade den Scan angeschaut. Das Timing ist NEC- und 
APPLE-kompatibel, allerdings verwendet Deine APPLE-FB eine andere ID als 
die APPLE-FB von Klaus - nämlich genau da, wo NEC eigentlich die Bits 
nochmal invertiert ausgibt.

Das ist ein Klacks, die neue ID in den IRMP einzubauen. Mache ich am 
Wochenende.

Gruß,

Frank

von Dirk W. (dirkw)


Lesenswert?

Hi,

Danke Frank :-).


Hab gerade mal ein bisschen gesucht und beim LIRC Projekt folgendes
gefunden:

http://lirc.sourceforge.net/remotes/apple/A1294

> pre_data        0x77E1
> UP                       0x50
> DOWN                     0x30
> LEFT                     0x90
> RIGHT                    0x60
> PLAY                     0xFA
> MENU                     0xC0
> OK                       0x3A


Das würde dem von mir ausgelesenen Protokoll entsprechen.
Scheinbar hat Apple wohl verschiedene Codes in seinen Produkten
hinterlegt.

Wünsche ein schönes WE...


CU Dirk

von Klaus L. (kllei)


Lesenswert?

Frank M. schrieb:
> APPLE-kompatibel, allerdings verwendet Deine APPLE-FB eine andere ID als
> die APPLE-FB von Klaus - nämlich genau da, wo NEC eigentlich die Bits
> nochmal invertiert ausgibt.

Laut der lirc Seite sind die Adressen von alter und neuer FB gleich, nur 
die Kommandos der Tasten unterscheiden sich:
http://lirc.sourceforge.net/remotes/apple/A1156
http://lirc.sourceforge.net/remotes/apple/A1294

Allerdings stimmen die "Lirc" Werte der alten FB mit der Wiki Seite 
überein, wenn man LSB berücksichtigt.

Ich habe noch mal meine Aufzeichnungen gecheckt, die alte FB wurde von 
IRMP ebenfalls mit Adresse 0x77E1 erkannt,
0x87EE (von der Wiki Seite) in LSB gelesen ergibt 0x77E1

Ach ja, die "alte" FB gibt es wohl auch erst seit Oktober 2005, das 
hatte ich überlesen.
Mal wieder raffiniert gemacht von A**le...

Grüße,
Klaus

von eku (Gast)


Lesenswert?

Hallo!

Hat schon jemand IRMP und IRSND in ethersex eingebaut?

von Graf-von-Socke (Gast)


Lesenswert?

Hallo und supper Arbeit.

So weit leuft alles bei mir mit dem einlesen der codes. Aber die 
Ferbedinung von der XBOX 360 macht schwierwigkeiten.Egal welche Taste 
ich drücke kommt immer der Code

irmp_data.protoco =9
irmp_data.address =0
irmp_data.command =31

Vieleicht kann mir von euch Jemand helfen

danke

Graf-von-Socke

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Frank M. schrieb:

> Das ist ein Klacks, die neue ID in den IRMP einzubauen. Mache ich am
> Wochenende.

Habe gerade mal IRMP an den APPLE-Scan angepasst.

@Dirk:

Ersetze bitte die Zeile:
1
    else if ((irmp_command & 0xFF00) == 0xD100)

durch
1
    else if ((irmp_command & 0xFF00) == 0xD100 || (irmp_command & 0xFF00) == 0x4600)

in irmp.c. Dann sollte die FB erkannt werden.

Ich werde das aber anders im nächsten IRMP-Release implementieren. Das 
Problem ist nämlich, dass beide FBs dieselbe NEC-Adresse (0x87ee) haben, 
aber eine unterschiedliche ID verwenden. Damit dann später auch IRSND 
APPLE-Frames versenden kann, welche beide (und auch weitere!) APPLE-FBs 
unterstützt, werde ich zukünftig die bisher von IRMP zurückgegebene 
Adresse 0x87ee ersetzen durch die ID. Das wäre dann bei der FB von Klaus 
die 0xD100 und bei Dirk die 0x4600. Nur so kann eine IRMP-Anwendung auch 
beide APPLE-FBs auseinanderhalten. Daher bitte den obigen Patch erstmal 
als Test/Notlösung sehen...

Die korrekte Fassung kommt dann am Sonntag.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Graf-von-Socke schrieb:

> So weit leuft alles bei mir mit dem einlesen der codes. Aber die
> Ferbedinung von der XBOX 360 macht schwierwigkeiten.Egal welche Taste
> ich drücke kommt immer der Code
>
> irmp_data.protoco =9
> irmp_data.address =0
> irmp_data.command =31

IRMP glaubt da anhand des Timings einen RC6-Code zu empfangen. Ich 
glaube aber nicht, dass Microsoft tatsächlich einen von Philips 
entwickelten Code verwendet, sondern (wie so oft) sich etwas eigenes 
ausgedacht hat.

> Vieleicht kann mir von euch Jemand helfen

Da helfen nur Scans. Wie Du diese erstellen kannst, steht im 
IRMP-Artikel:

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

Gruß,

Frank

von Graf-von-Socke (Gast)


Angehängte Dateien:

Lesenswert?

Hallo hier ist nein Scan ergbis fielicht finden sie etwas


gruß

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Graf-von-Socke schrieb:
> Hallo hier ist nein Scan ergbis fielicht finden sie etwas

Danke, scheint ein simpler 32-Bit-Code zu sein. Zwei Tasten reichen da 
aber nicht, ich bräuchte schon so um die 10 Tasten-Scans, um da auch 
eine Struktur zu erkennen. Dann kann ich das in den IRMP integrieren.

Noch als Tipp:
Bitte vor und hinter jedem Kommentar eine neue Zeile beginnen und den 
Kommentar selbst mit dem #-Zeichen einleiten, also:

# Die X Taste
000000000000000000000000000000000000000000000000001111...
# Die Play Taste
000000000000000000000000000000000000000000000000001111...

Ist der Scan mit 10kHz aufgenommen worden?

Gruß,

Frank

von Graf-von-Socke (Gast)


Lesenswert?

Ok werde ich morgen abend nochmal durchführen
habe was nettes im Internet gefunden fielicht hilft das weiter


........................................................................ 
..
lircd.conf für USB-Empfänger (MCEUSB2)

# this config file was automatically generated
# using lirc-0.8.0-CVS(mceusb2) on Tue Jan 17 15:14:11 2006
#
# contributed by Kyle at shadowmage.org
#
# brand: Microsoft
# model no. of remote control: Xbox 360 Universal Media Remote
# devices being controlled by this remote: Xbox 360
#
# This probably works for the normal Xbox 360 remote too.
#
# TV button sends no signal and toggles Xbox 360/TV mode. TV mode can be
# signals for any device the remote supports. Volume Up, Volume Down and
# Mute always use the TV mode while the Xbox live guide button always 
sends
# to the xbox.

begin remote

  name  Microsoft_Xbox360
  bits           16
  flags RC6|CONST_LENGTH
  eps            30
  aeps          100

  header       2676   870
  one           454   429
  zero          454   429
  pre_data_bits   21
  pre_data       0x37FF0
  gap          106291
  min_repeat      1
  toggle_bit      0

  rc6_mask    0x100000000

      begin codes
          OpenClose                0x8BD7
          XboxFancyButton          0x0B9B
          OnOff                    0x8BF3
          Stop                     0x0BE6
          Pause                    0x8BE7
          Rewind                   0x0BEA
          FastForward              0x8BEB
          Prev                     0x0BE4
          Next                     0x8BE5
          Play                     0x0BE9
          Display                  0x8BB0
          Title                    0x0BAE
          DVD_Menu                 0x8BDB
          Back                     0x0BDC
          Info                     0x8BF0
          UpArrow                  0x0BE1
          LeftArrow                0x8BDF
          RightArrow               0x0BDE
          DownArrow                0x8BE0
          OK                       0x0BDD
          Y                        0x8BD9
          X                        0x0B97
          A                        0x8B99
          B                        0x0BDA
          ChUp                     0x8BED
          ChDown                   0x0BEC

          Start                    0x0BF2
          Play                     0x8BE9
          Enter                    0x0BF4
          Record                   0x8BE8
          Clear                    0x0BF5
          1                        0x8BFE
          2                        0x0BFD
          3                        0x8BFC
          4                        0x0BFB
          5                        0x8BFA
          6                        0x0BF9
          7                        0x8BF8
          8                        0x0BF7
          9                        0x8BF6
          100                      0x0BE2
          0                        0x8BFF
          Reload                   0x8BE3
      end codes

end remote
........................................................................ 
..
Quelle

http://www.vdr-wiki.de/wiki/index.php/Fernbedienung_-_Microsoft_XBOX_360_Universal_Media_Remote

von Dirk W. (dirkw)


Angehängte Dateien:

Lesenswert?

Hi,

@Frank:

Danke dir; die Apple-FB klappt jetzt wunderbar :-)

@Frank, Graf-von-Socke

Weiß nicht ob's euch hilft, aber ich hatte vor meiner Apple FB
mit dem Gedanken gespielt die XBOX360 FB zu nehmen.
Hab meinen Trace mal angehängt. Wurde mit 15000 gemacht
und jede Taste 3x aufgezeichnet.

CU Dirk

Zusatz:
Hatte ich ganz vergessen; Im Trace sind noch an einigen Zeilenenden
</n>'s
Bitte vorher ersetzen, falls es den Parser stören sollte ?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Dirk W. schrieb:

> Danke dir; die Apple-FB klappt jetzt wunderbar :-)

Freut mich. Wie angekündigt, habe ich das mittlerweile allgemeiner 
gelöst: die ID wird nun als Adresse zurückgegeben. So sind Deine 
Fernbedienung und die von Klaus (und auch weitere APPLE-FBs) 
unterscheidbar. Nachteil ist: Die Adresse Deiner FB wird dann eine 
andere sein, nämlich 0x0046. Die von Klaus ist dann 0x00D1.

Update kommt in Kürze als Download im Artikel bzw. über SVN.

> Weiß nicht ob's euch hilft, aber ich hatte vor meiner Apple FB
> mit dem Gedanken gespielt die XBOX360 FB zu nehmen.
> Hab meinen Trace mal angehängt. Wurde mit 15000 gemacht
> und jede Taste 3x aufgezeichnet.

Vielen Dank! Deine Scans sind wunderbar, Graf-von-Socke hat offenbar 
eine ganz andere Scan-Frequenz genutzt, so dass ich mit seinen Scans 
wenig bis gar nichts anfangen konnte, weil IRMP mit 10kHz erst gar nicht 
RC6 erkannt hat.

Die XBOX benutzt tatsächlich RC6-Code, wer hätte das gedacht. Aber ich 
habe hier genau dieselben Probleme wie mit der Kathrein-FB, deren Scans 
hier schon mal gepostet wurden. Das ist leider kein Mode-0-RC6, wie er 
in

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

beschrieben ist. Ich werde mich nochmal mit der RC6-Decodierung 
beschäftigen und hoffe damit, die Kathrein-FB und die XBOX erschlagen zu 
können. Im Moment werden nämlich nur Mode-0-FBs mit 7 + 16 Datenbits 
erkannt. Die XBOX und die Kathrein-FB benutzen einen abweichenden Mode 
mit wesentlich mehr Datenbits. Wenn da jemand irgendeine Doku findet, 
wie die Struktur der Datenbits (Länge der Adresse und der Kommandos) 
ist, würde ich mich freuen.

> Hatte ich ganz vergessen; Im Trace sind noch an einigen Zeilenenden
> </n>'s
> Bitte vorher ersetzen, falls es den Parser stören sollte ?

Das war kein Problem :-)

Gruß,

Frank

von Achim (Gast)


Lesenswert?

Ich habe eine Dokumentation zum Mode 6A von RC6 gefunden: 
http://slycontrol.ru/scr/kb/rc6.htm. Ich hoffe die hilft dir weiter.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Achim schrieb:
> Ich habe eine Dokumentation zum Mode 6A von RC6 gefunden:
> http://slycontrol.ru/scr/kb/rc6.htm. Ich hoffe die hilft dir weiter.

Vielen Dank, das ist ja schon mal ein wenig mehr. Habe den URL direkt 
mal im IRMP-Artikel verlinkt. Jetzt muss ich nur schauen, ob ich den 
Mode 6A mit den Scans in Einklang bringen kann...

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Es gibt eine neue Version 1.7.3 von IRMP.

Download:

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

Änderungen gegenüber 1.7.2:

 - Neues Protokoll: JVC

 - Kaseikyo-Protokoll: Berücksichtigung der Genre-Bits.
   ACHTUNG: dadurch neue Command-Codes!

 - Kaseikyo-Protokoll: Verbesserte Behandlung von Wiederholungs-Frames

 - Verbesserte Unterstützung des APPLE-Protokolls.
   ACHTUNG: dadurch neue Adress-Codes!

Analog dazu gibt es auch eine neue Version 1.7.3 von IRSND.

Download:

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

Änderungen gegenüber 1.7.2:

 - Neues Protokoll: Kaseikyo (Panasonic u.a.)

Viel Spaß,

Frank

von Graf-von-Socke (Gast)


Lesenswert?

Hallo
und danke für den richtigen scan war mein fehler hatte den scan auf 
20000 eingestellt.

Nun wenn es euch intersesiert bastel ich gerade eine schaltung damit ich 
den
mikrocontroller über mein Handy dazu auffoder die geräere (TV usw) zu 
steuern.

bis dann

von Dirk W. (dirkw)


Angehängte Dateien:

Lesenswert?

Hi,

noch interessant ist eventuell folgende Seite:
http://www.picbasic.nl/info_rc6_uk.htm

und folgendes Dokument (Seite: 28)
http://home.hccnet.nl/m.majoor/files/pronto.pdf

Hatte vor kurzem auch mal probiert RC6a per Hand zu dekodieren ..
Hab wohl allerdings einen Fehler gemacht, denn das Ergebnis
das ich zum Vergleich herangezogen hatte war unterschiedlich.

Hab's trotzdem mal angehängt; vielleicht hilft es ??


CU Dirk

von Graf-von-Sokce (Gast)


Lesenswert?

Hallo zusammen

Habe nun ein anders Problem auf meine ATMEGA8 leuft alles supper.
Bin nun wegen platzmagel auf einen ATMGA 168 umgestigen nun leuft nur 
noch ISR aber es werden keine IR-CODES Ausgeben

gruß

Graf-von-Socke

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Dirk W. schrieb:

> noch interessant ist eventuell folgende Seite:
> http://www.picbasic.nl/info_rc6_uk.htm

Super Link! Danke. Damit werde ich RC6/RC6A wohl endlich in den Griff 
bekommen.

> Hatte vor kurzem auch mal probiert RC6a per Hand zu dekodieren ..
> Hab wohl allerdings einen Fehler gemacht, denn das Ergebnis
> das ich zum Vergleich herangezogen hatte war unterschiedlich.
>
> Hab's trotzdem mal angehängt; vielleicht hilft es ??

Danke, werde ich mir anschauen.

Gruß,

Frank

von Joachim B. (jar)


Lesenswert?

hattest du meine Frage per Mail bekommen ?
darf man dich per Mail fragen ?

gruss
jar

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:
> hattest du meine Frage per Mail bekommen ?
> darf man dich per Mail fragen ?

Habe ich bekommen. Da ich aber erst Freitag aus dem Urlaub gekommen bin 
und eine Antwort auf Deine Mail etwas länger dauert, bin ich noch nicht 
dazu gekommen, Deine Mail zu beantworten.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Lesenswert?

So, ich habe RC6A als extra Protokoll No. 21 eingebaut. Damit sollte 
nicht nur die XBOX-FB funktionieren, sondern endlich auch die 
Kathrein-FB, an der ich schon längere Zeit rumdoktere.

Anbei die gegenüber der Download-Version geänderten Sources als 
Testversion. Sobald mir jemand sagt, dass es läuft, gibt es ein neues 
Release.

Viel Spaß,

Frank

von Graf-von-Socke (Gast)


Lesenswert?

Suppi
werde es mal gleich ausprobieren ob es geht

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Graf-von-Socke schrieb:
> werde es mal gleich ausprobieren ob es geht

Nimm aber 10kHz, das reicht vollkommen. 20kHz braucht man nur für 
Protokolle, die enorm kurze Pulse nutzen. Ds ist bisher bisher lediglich 
bwi RECS80 der Fall.

15kHz sind auch okay, verbät aber schon mehr CPU-Zeit.

Gruß,

Frank

von Graf-von-Socke (Gast)


Lesenswert?

Nochnal Hallo

habe es gestest und funktioniert supper gemacht.

Und haben Sie schon mal wegen den ATMGA 168 nachgeschaut warum es mit 
dem nicht leüft !

gruß

Graf-von-Socke

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Graf-von-Socke schrieb:
> habe es gestest und funktioniert supper gemacht.

Freut mich :-)

> Und haben Sie schon mal wegen den ATMGA 168 nachgeschaut warum es mit
> dem nicht leüft !

irmp läuft auch auf einem ATMEGA 162 ohne Codeänderung, z.B. im 
WordClock-Projekt. Hast Du denn auch den Prozessor-Typ im WinAVR-Projekt 
ausgewechselt? Man kann i.a. nicht einfach das HEX-File für einen 
ATMEGA8 auf einen 168er laden.

Und unbedingt die Fuses beachten! Siehe 
http://www.engbedded.com/fusecalc/

Gruß,

Frank

von Graf-von-Socke (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Frank

Jo habe habe ich gemach siehe an den 2 Bildern. Habe eine jungfreulichen 
ATMEGA 168 genommen den ich noch hatte wie müssen die  Fuses-bits 
aussehn

gruß

Graf-von-Socke

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Graf-von-Socke schrieb:
> Jo habe habe ich gemach siehe an den 2 Bildern. Habe eine jungfreulichen
> ATMEGA 168 genommen den ich noch hatte wie müssen die  Fuses-bits
> aussehn

Ein jungfräulicher 168er läuft mit 1MHz internem Oszillator. Benutzt Du 
tatsächlich einen 3,686400 MHz Quarz, wie Du das im Projekt angegeben 
hast?

Ich kann Dir erst die Fuses-Einstellung nennen, wenn Du obige Frage 
beantwortet hast.

Gruß,

Frank

von Graf-von-Socke (Gast)


Lesenswert?

Jo da es auf der Testplatine drauf ist. Hatte damit noch keine Probelem 
da ich schon fiel mt UART gemach habe und die frequenz mit UART sehr gut 
leuft

siehe http://www.wormfood.net/avrbaudcalc.php


gruß

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Graf-von-Socke schrieb:
> Jo da es auf der Testplatine drauf ist.

Vorausgesetzt, der µC läuft mit 5V, würde ich wählen:

Low:      0xc7
High:     0xdc
Extended: 0xf9

Achtung: der µC lässt sich dann auch nur noch flashen, wenn der Quarz 
auch wirklich angeschlossen ist.

Du kannst Dir die Werte aber auch selbst ausrechnen lassen, siehe

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

Gruß,

Frank

von Graf-von-Socke (Gast)


Lesenswert?

Danke

nun leuft alles Danke

hatte ein nettes erreignis. Mein Quartz wolte nicht  muste erst mit dem 
Frequenz Generator einen Beipass legen. Muss bestimmt nachlöten


Kennst du eigendlich den X-PORT


gruß
Graf-von-Socke

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Graf-von-Socke schrieb:

> nun leuft alles Danke

Prima.

> hatte ein nettes erreignis. Mein Quartz wolte nicht  muste erst mit dem
> Frequenz Generator einen Beipass legen. Muss bestimmt nachlöten

Deshalb meine obige Warnung :-)

> Kennst du eigendlich den X-PORT

Du meinst den "XPORT Ethernet Wandler Ethernet zu seriell" von 
Lantronix?

Gruß,

Frank

von Graf-von-Socke (Gast)


Lesenswert?

Jo

Den meine ich finde den ganz nett aber er ist halt bischen teuer. Aber 
was man geschenkt bekommt sagt man nicht nein.

Bin nun dabei eine Schalung zu entwickeln damit jeder PC (auch Handy) 
auf den µC zu greifen kann und die Infrarot Befehle absetzen kann.

Der Grund dafür ist meine Frau die findt das die vielen Gräte aus den 
Blickfang verschwinden und daher fand ich deinen Ansatz hier sehr 
hilfreich.


Gruß

Graf-von-Socke

von Dirk W. (dirkw)


Lesenswert?

Hi Frank,

auch hier Bestätigung. Super gemacht; System und Command Byte 
funktionieren.

Bist du dir allerdings bei der Customer ID sicher ?
Ich bekomme hier als Ausgabe 0xffef bin mir aber
ziemlich sicher daß die MS ID 0x800F ist.


CU Dirk

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Dirk W. schrieb:

> auch hier Bestätigung. Super gemacht; System und Command Byte
> funktionieren.

Sehr schön, danke für die Rückmeldung :-)

Achja, das MSB der 14 Bits (das ist das MSB des System-Bytes) ignoriere 
ich: das scheint nämlich zu togglen - ähnlich dem Toggle-Bit "TR" bei 
Mode 0, was dort ziemlich weit vorne direkt hinter den Mode-Bits liegt. 
Das ist mir beim XBOX-Scan als auch bei der Kathrein-FB aufgefallen: 
Beim Mode 6A wechselt das eigentliche Toggle-Bit nicht, dafür aber das 
oberste Bit vom System-Byte.

> Bist du dir allerdings bei der Customer ID sicher ?

Nein, sonst hätte ich ja keine Testversion gemacht ;-)

> Ich bekomme hier als Ausgabe 0xffef bin mir aber
> ziemlich sicher daß die MS ID 0x800F ist.

Okay, ich überprüfe das nochmal. Ich stehe echt auf Kriegsfuß mit der 
Manchester-Deokodierung. Wenn ein Bit falsch ist, kippen alle Bits 
dahinter mit :-(

Die Hölle ist nämlich das "eigentliche" RC6-Toggle-Bit "TR", welches die 
doppelte Länge der anderen Bits hat. Da ich mir immer nur Längen 
zwischen zwei Flankenwechseln anschaue, macht mir diese wechselnde 
Frequenz das Leben schwer, denn es kann da als Länge nicht nur 1-fache 
und 2-fache Länge, sondern auch die 1,5-fache Länge auftreten. Ich 
vermute mal, dass genau da das Bit kippt - und damit auch die 
Custtomer-ID, die danach folgt.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Dirk W. schrieb:
> Bist du dir allerdings bei der Customer ID sicher ?

Fehler gefunden und behoben.

Ersetze in irmp.c die Zeilen 2078/2079
1
    irmp_store_bit (0);
2
    last_value = 0;

durch folgendes:
1
    if (irmp_param.complete_len == RC6_COMPLETE_DATA_LEN_LONG) // RC6 mode 6A
2
    {
3
        irmp_store_bit (1);
4
        last_value = 1;
5
    }
6
    else    // RC6 mode 0
7
    {
8
        irmp_store_bit (0);
9
        last_value = 0;
10
    }

Nun kommt als Customer-ID auch 0x800F raus - wie gewünscht ;-)

Gruß,

Frank

von Dirk W. (dirkw)


Lesenswert?

Hi,

jetzt funktioniert es ... ^_^

Ich protokollier dann gerade mal die Tasten, damit
ich meine alte PC FB gegen die XBOX FB tauschen kann ^_^


CU Dirk

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Neue Version 1.8.0 von IRMP verfügbar, Download unter

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

Änderungen gegenüber 1.7.3:

  - Neues Protokoll: RC6A

Damit werden nun die XBOX und auch die Kathrein-FBs unterstützt.

Ebenso ist nun die Version 1.8.0 von IRSND verfügbar, Download unter

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

Änderungen gegenüber 1.7.3:

  - Neues Protokoll: JVC
  - Anpassung des APPLE-Encoders an IRMP-Version 1.7.3.

Im IRSND fehlt jetzt nur noch die Unterstützung des 
RC6-/RC6A-Protokolls, dann sind beide Software-Module wieder 
"symmetrisch". Bin da nun dran.

Die Dokumentation im IRMP-Artikel habe ich angepasst bzw.
erweitert, siehe:

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

Viel Spaß,

Frank

von Joachim B. (jar)


Lesenswert?

wollte nur noch mal danke sagen,

deine Tipps wo ich meinen source anpassen musste waren erfolgreich, 
brauchte wirklich nur noch die irmp.c/.h einbinden und die irmpconfig.h 
anpassen und es funzt sofort, RC6 hab ich noch nicht testen können, aber 
der Rest läuft wie gehabt was ein gutes Zeichen ist......


gruss
jar

von eku (Gast)


Lesenswert?

Frank M. schrieb:
> Neue Version 1.8.0 von IRMP verfügbar,

Ganz toll ,Frank. Nur leider wird irmp_ISR immer länger. Wie steht es 
mit den Optmierungen aus 
Beitrag "Re: IRMP - Infrared Multi Protocol Decoder" ?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:
> Ganz toll ,Frank. Nur leider wird irmp_ISR immer länger. Wie steht es
> mit den Optmierungen aus
> Beitrag "Re: IRMP - Infrared Multi Protocol Decoder" ?

Schlecht. Ich hatte mal testweise so eine Version gemacht, wo (nach 
Deiner Idee) in einer Schleife über die Protokolle mittels Timingwerten 
das richtige Protokoll ermittelt werden sollte. Dabei mussten noch 
Pulse-Distance-Protokolle mit Start-Bit von denen ohne Start-Bit (z.B. 
Denon) und auch die Manchester-codierten Protokolle extra abgearbeitet 
werden. Also gab es schon einmal 3 Schleifen...

Ergebnis:

1. Keine Flash-Speicher-Ersparnis, da die Konstruktion der 3 Schleifen
   inkl. zusätzlichen Speicherbedarf der Startbit-Werte für die
   einzelnen Protokolle alles wieder auffraß. Am Ende wurde sogar mehr
   Flash-Speicher benötigt als vorher.

2. Viel Größere Laufzeiten, da die Pulse-/Pause-Werte nicht mehr mit
   Konstanten, sondern mit Variableninhalten abgeglichen werden
   mussten. Der Variablenzugriff war wegen Indirektion über

            startbitstructarray[idx]->value

   nicht gerade effizient.

Kampakter bekommt man den Code wohl nicht, da kann man nur an Feinheiten 
tunen. Ab und zu stolpere ich mal über eine Stelle, die optimiere ich 
dann "on-the-fly", wenn es ohne größeren Aufwand geht.

Ich erwähnte damals zwar, dass man die linearen Vergleiche, die 
unmittelbar nach Eintreffen des Startbits auftreteten, noch optimieren 
könnte. Das würde aber auch keine Verkleinerung des Codes verursachen, 
eher eine (leichte) Vergrößerung. Lediglich die "Suche" nach dem 
richtigen Protokoll ginge dann etwas schneller. Die Arbeit habe ich mir 
aber noch nicht gemacht, da hier der Gewinn bei 20 Protokollen eher 
marginal ist. Bei 1000 Protokollen wäre das was anderes ;-)

Mein Fazit:

Wenn Dir der Code zu groß ist, schalte die nicht benötigten Protokolle 
ab. Dann wirst Du sehen, dass IRMP selbst eigentlich nicht größer ist 
als vorher. Ein neues Protokoll im IRMP verursacht im allgemeinen keine 
Vergrößerung des Codes - solange man es ausgeschaltet(!) lässt ;-)

Wenn jemand ein neu implementiertes Protokoll tatsächlich nutzen will, 
kann er schlecht erwarten, dass der Code gleich groß bleibt.


Gruß,

Frank

von Simon B. (nomis)


Lesenswert?

Frank, vielen Dank für IRMP, das leistet bei mir gerade gute Dienste 
:-)

In irmpconfig.h steht als Maximum für F_INTERRUPTS 15000 - das ist aber 
eher ein veralteter Wert, oder? Oder muss man was spezielles tun, wenn 
man darüber hinausgeht (Manche Protokolle verlangen ja 20kHz)?

Ich habe übrigens beobachtet, dass bei F_INTERRUPTS=16000 eine 
Verringerung der Codegröße eintritt (um ca. 130-135 Bytes). Was passiert 
denn da?

Viele Grüße,
        Simon

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Simon Budig schrieb:
> Frank, vielen Dank für IRMP, das leistet bei mir gerade gute Dienste
> :-)

Freut mich :-)

> In irmpconfig.h steht als Maximum für F_INTERRUPTS 15000 - das ist aber
> eher ein veralteter Wert, oder? Oder muss man was spezielles tun, wenn
> man darüber hinausgeht (Manche Protokolle verlangen ja 20kHz)?

Ja, es sind auch 20kHz möglich, habe ich vergessen, das zu 
aktualisieren. Allerdings wird dann etwas mehr Speicherplatz benötigt, 
da dann einige Variablen vom Typ her automatisch über den Preprocessor 
von uint8_t auf uint16_t wechseln. Auch wird mehr CPU-Zeit verbraten. 
RECS80, das einzige Protokoll, welches 20kHz erfordert, ist auch noch 
nicht in der Praxis getestet worden.

> Ich habe übrigens beobachtet, dass bei F_INTERRUPTS=16000 eine
> Verringerung der Codegröße eintritt (um ca. 130-135 Bytes). Was passiert
> denn da?

Du meinst bei Erhöhung auf 16000? Müsste dann eigentlich größer werden, 
siehe oben.

Gruß,

Frank

von Simon B. (nomis)


Lesenswert?

Frank M. schrieb:
> Simon Budig schrieb:
>> Ich habe übrigens beobachtet, dass bei F_INTERRUPTS=16000 eine
>> Verringerung der Codegröße eintritt (um ca. 130-135 Bytes). Was passiert
>> denn da?
>
> Du meinst bei Erhöhung auf 16000? Müsste dann eigentlich größer werden,
> siehe oben.

Deswegen war ich ja irritiert...

Aber ich beobachte hier das Gegenteil. Ich habe gerade mal eine kleine 
Reihe gemacht:

F_INTERRUPTS  |   text  | data  |  bss  |    dec  |  vgl. zu 16000
--------------+---------+-------+-------+---------+----------------
        6000  |  11108  |  180  |  113  |  11401  |  +118
        7000  |  11124  |  180  |  113  |  11417  |  +134
        8000  |  11112  |  180  |  113  |  11405  |  +122
        9000  |  11126  |  180  |  113  |  11419  |  +136
       10000  |  11126  |  180  |  113  |  11419  |  +136
       11000  |  11130  |  180  |  113  |  11423  |  +140
       12000  |  11130  |  180  |  113  |  11423  |  +140
       13000  |  11130  |  180  |  113  |  11423  |  +140
       14000  |  11126  |  180  |  113  |  11419  |  +136
       15000  |  11130  |  180  |  113  |  11423  |  +140
       16000  |  10990  |  180  |  113  |  11283  |     0
       17000  |  10990  |  180  |  113  |  11283  |     0
       18000  |  10990  |  180  |  113  |  11283  |     0
       19000  |  10988  |  180  |  113  |  11281  |    -2
       20000  |  10988  |  180  |  113  |  11281  |    -2
       21000  |  10982  |  180  |  113  |  11275  |    -8
       22000  |  10982  |  180  |  113  |  11275  |    -8
       23000  |  10982  |  180  |  113  |  11275  |    -8
       24000  |  10982  |  180  |  113  |  11275  |    -8

Mhm. Ich habe mir gerade mal den Assembler angeguckt. Offensichtlich 
verschwindet bei F_INTERRUPTS = 16000 die gesamte if-Abfrage bei Zeile 
2020 (if (irmp_pause_time > IRMP_TIMEOUT_LEN)) in irmp.c, anscheinend 
beschließt der Compiler, dass das nicht eintreffen kann und schmeißt den 
Code weg.

Viele Grüße,
        Simon

PS: Zur Klarstellung: In der Codegröße ist natürlich noch jede Menge 
anderer Kram drin (LUFA, Displayansteuerung). Die Zahlen dürfen nicht 
zur Beurteilung der Größe von IRMP herangezogen werden, interessant sind 
hier nur die relativen Änderungen.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Simon Budig schrieb:
> Mhm. Ich habe mir gerade mal den Assembler angeguckt. Offensichtlich
> verschwindet bei F_INTERRUPTS = 16000 die gesamte if-Abfrage bei Zeile
> 2020 (if (irmp_pause_time > IRMP_TIMEOUT_LEN)) in irmp.c, anscheinend
> beschließt der Compiler, dass das nicht eintreffen kann und schmeißt den
> Code weg.

Das darf nicht sein, eigentlich wird ab ca. 16000 Hz IRMP_TIMEOUT_LEN 
größer als 255 und deshalb auch irmp_pause_time dann vom Typ uint16_t. 
Das scheint aber nicht zu funktionieren. Kein Wunder, dass der Compiler 
dann das if-Statement wegwirft. Ich werde das überprüfen.

Danke für den Tipp und Deine "Messungen" :-)

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Fehler gefunden, es ist eine Änderung in irmp.c notwendig.

Alt:
1
#include "irmp.h"
2
#ifndef IRMP_USE_AS_LIB
3
#include "irmpconfig.h"
4
#endif

Neu:
1
#ifndef IRMP_USE_AS_LIB
2
#include "irmpconfig.h"
3
#endif
4
#include "irmp.h"

Werde ich noch am Wochenende im Paket ändern.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Frank M. schrieb:
> Fehler gefunden, es ist eine Änderung in irmp.c notwendig.
> Werde ich noch am Wochenende im Paket ändern.

[x] Done

Download-Version ist nun 1.8.1.

Gruß,

Frank

von Simon B. (nomis)


Lesenswert?

Sieht besser aus:

  F_INTR |   text  | data  |  bss  |    dec  |  vgl. zu 16000
---------+---------+-------+-------+---------+-----------------
   5000  |  11104  |  180  |  113  |  11397  |  -268
   6000  |  11108  |  180  |  113  |  11401  |  -264
   7000  |  11124  |  180  |  113  |  11417  |  -248
   8000  |  11112  |  180  |  113  |  11405  |  -260
   9000  |  11126  |  180  |  113  |  11419  |  -246
  10000  |  11126  |  180  |  113  |  11419  |  -246
  11000  |  11130  |  180  |  113  |  11423  |  -242
  12000  |  11130  |  180  |  113  |  11423  |  -242
  13000  |  11130  |  180  |  113  |  11423  |  -242
  14000  |  11126  |  180  |  113  |  11419  |  -246
  15000  |  11130  |  180  |  113  |  11423  |  -242
  16000  |  11370  |  180  |  115  |  11665  |     0
  17000  |  11370  |  180  |  115  |  11665  |     0
  18000  |  11372  |  180  |  115  |  11667  |    +2
  19000  |  11372  |  180  |  115  |  11667  |    +2
  20000  |  11376  |  180  |  115  |  11671  |    +6
  21000  |  11370  |  180  |  115  |  11665  |     0
  22000  |  11370  |  180  |  115  |  11665  |     0
  23000  |  11372  |  180  |  115  |  11667  |    +2
  24000  |  11372  |  180  |  115  |  11667  |    +2
  25000  |  11372  |  180  |  115  |  11667  |    +2

Vielen Dank und viele Grüße,
        Simon

von Joachim B. (jar)


Lesenswert?

der Bug bei U2X ist leider immer noch da, habe wie gesagt nur irmp.c/h 
eingebunden, meine main und die irmpconfig geändert sowie logging on und 
defines fürs steckbrett, , muss am verwendeten m644 liegen, ich weiss 
nur nicht wann und warum dieser U2X Fehler im irmp-uart kommt, wenn ich 
das einfach auskommentier gehts ja, aber der code sollte ja so laufen

Fehlermeldung:
../irmp.c:593:26: error: util/setbaud.h: No such file or directory

finde ich auch in meinem winAVR nicht
1
void
2
irmp_uart_init (void)
3
{
4
    UART0_UBRRH = UBRRH_VALUE;                                                                      // set baud rate
5
    UART0_UBRRL = UBRRL_VALUE;
6
/*
7
#if USE_2X
8
    UART0_UCSRA |= (1<<U2X);
9
#else
10
    UART0_UCSRA &= ~(1<<U2X);
11
#endif
12
*/
13
#if USE_2X
14
    UART0_UCSRA |= (1<<U2X0);
15
#else
16
    UART0_UCSRA &= ~(1<<U2X0);
17
#endif
18
19
    UART0_UCSRC = UART0_UCSZ1_BIT_VALUE | UART0_UCSZ0_BIT_VALUE | UART0_URSEL_BIT_VALUE;
20
    UART0_UCSRB |= UART0_TXEN_BIT_VALUE;                                                            // enable UART TX
21
}

so gehts, nur warum

lg
jar

von Joachim B. (jar)


Lesenswert?

als helfende krücke noch

#if IRMP_LOGGING != 0       // 1: log IR signal (scan), 0: do not 
(default)
    uart_init(UART_BAUD_SELECT(9600,F_CPU));
#endif


mit uart.c/h eingebunden Peter Fleury
modified by Patrick Kaplan for ATMega644 usage

und uart_init aufruf statt irmp-uart_init

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:

> Fehlermeldung:
> ../irmp.c:593:26: error: util/setbaud.h: No such file or directory

Meines liegt unter 
C:\Programme\WinAVR-20100110\avr\include\util\setbaud.h

und ist Bestand der avr-libc.

Wo liegt Dein avr\include-Verzeichnis? Überprüfe mal Deine Version - 
damit meine ich jetzt nicht die WinAVR-Version, sondern Deine 
avr-gcc-Version.

> finde ich auch in meinem winAVR nicht

Dann fehlt da was bei Dir. setbaud.h gibt es schon länger.

> so gehts, nur warum

Weil genau die U2X-Geschichte in setbaud.h definiert wird.

Gruß,

Frank

von Joachim B. (Gast)


Lesenswert?

Frank M. schrieb:
> Meines liegt unter
> C:\Programme\WinAVR-20100110\avr\include\util\setbaud.h
> und ist Bestand der avr-libc.
> Wo liegt Dein avr\include-Verzeichnis? Überprüfe mal Deine Version -
> damit meine ich jetzt nicht die WinAVR-Version, sondern Deine
> avr-gcc-Version.
>> finde ich auch in meinem winAVR nicht
> Dann fehlt da was bei Dir. setbaud.h gibt es schon länger.

setbaud.h fehlt, ergo muss bei meiner letzten Installation was schief 
gelaufen sein
1
 Verzeichnis von C:\Programme\atmel
2
3
10.12.2008  01:11    <DIR>          .
4
10.12.2008  01:11    <DIR>          ..
5
07.01.2010  21:50    <DIR>          AVR Tools
6
17.03.2008  20:32    <DIR>          BASCOM-AVR
7
02.09.2008  14:23           432.040 CodeCompareSetup.exe
8
25.11.2008  01:00    <DIR>          Grafikkonverter
9
07.03.2008  21:01    <DIR>          PonyProg2000
10
04.03.2008  20:25    <DIR>          WinAVR


komisch nur das alle meine anderen Projekte laufen, also habe ich nie 
was vermisst
was muss ich also noch wie einbinden ?

vielen Dank

von Joachim B. (jar)


Lesenswert?

so, setbaud ist wieder da, neuste winAVR installiert

muss noch testen

von Joachim B. (jar)


Lesenswert?

bin leider noch nicht weiter, so siehts aus:
1
Build started 9.9.2010 at 15:33:42
2
3
avr-gcc -I"C:\Programme\atmel\WinAVR\avr\include\util"  -mmcu=atmega644 -Wall -gdwarf-2 -std=gnu99                                                     -DF_CPU=8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT main.o
4
 -MF dep/main.o.d  -c  ../main.c
5
6
avr-gcc -I"C:\Programme\atmel\WinAVR\avr\include\util"  -mmcu=atmega644 -Wall -gdwarf-2 -std=gnu99                                                     -DF_CPU=8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT irmp.o
7
8
 -MF dep/irmp.o.d  -c  ../irmp.c
9
10
../irmp.c: In function 'irmp_uart_init':
11
../irmp.c:657: error: 'U2X' undeclared (first use in this function)
12
../irmp.c:657: error: (Each undeclared identifier is reported only once
13
../irmp.c:657: error: for each function it appears in.)
14
make: *** [irmp.o] Error 1
15
Build failed with 3 errors and 0 warnings...

was muss ich noch machen ?

include file search path, hab ich doch in project options ??? grübel
C:\Programme\atmel\WinAVR\avr\include\util\

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:
> bin leider noch nicht weiter, so siehts aus:

> ../irmp.c: In function 'irmp_uart_init':
> ../irmp.c:657: error: 'U2X' undeclared (first use in this function)

Du hast offenbar nicht die aktuelle IRMP-Version vom 04.09.2010. Da wird 
für bestimmte µCs U2X als U2X0 definiert.

Gruß,

Frank

von Joachim B. (jar)


Lesenswert?

stimmt da war ich unterwegs, habs also nicht mitbekommen

so geladen, eingespielt, aber immer noch Probleme...

ich glaub ich lasse meine Einbindung von P.Fleury UART.C/H damit klappts 
ja

DAANNKEEE

von Fabi S (Gast)


Lesenswert?

Hey,
super geile Sache.
Wollt nur kurz mitteilen das meine LG Fernbedienung vom TV und BluRay 
Player mit dem Samsung(32) Protokoll einwandfrei funktionieren.

von Fabi S (Gast)


Lesenswert?

Ahhh noch was vergessen,
meine beiden Fernbedienungen (sind verschiedene) der Marke Smart 
Electronics (Receiver usw.) funktionieren mit dem NEC Protokoll.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Fabi S schrieb:
> Wollt nur kurz mitteilen das meine LG Fernbedienung vom TV und BluRay
> Player mit dem Samsung(32) Protokoll einwandfrei funktionieren.

Freut mich.

> meine beiden Fernbedienungen (sind verschiedene) der Marke Smart
> Electronics (Receiver usw.) funktionieren mit dem NEC Protokoll.

Aber sie werden unterschiedliche Adressen haben, oder?

Gruß,

Frank

von Fabi S (Gast)


Lesenswert?

uiuiui jetzt fragst mich was :)
ich hab mir nur per debugfunktion die werte ausgeben lassen und alle 
tasten durchgedrückt um zu kucken ob alle erkannt werden, protokoll war 
2 aber die adresse weiss ich nichtmehr.
soll ich nochmal kucken?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Fabi S schrieb:
> soll ich nochmal kucken?

Nö, brauchst Du nicht.

von Joachim B. (jar)


Angehängte Dateien:

Lesenswert?

kleines Problem (oder eher großes)

dein Code ist doch ähnlich meinem gefundenen für IRSND start stop

meiner funktioniert, getestet mit Oszi 500µs 36kHz on off
meiner:
1
void timer0_init(void)
2
{
3
    OCR0A  = (F_CPU / ( 2 * IR_FREQUENZ )) - 1;               // compare value: 
4
#if !FB_LCD_STECKBRETT
5
  IR_SND_DDR |= (1<<IR_SND);                                  // set DDR to output
6
    IR_SND_PORT &= ~(1<<IR_SND);                                // set pin to low
7
#endif
8
}
9
10
void timer0_start(void)
11
{
12
    TCCR0A  |= (1 << WGM01) | (1 << WGM00) | (1 << COM0A0);   // switch CTC Mode on, set prescaler to 1
13
  TCCR0B   |= (1 << WGM02) | (1<<CS00);
14
    TIMSK0  |= (1 << OCIE0A);                                   // OCIE0A: Interrupt by timer compare
15
}
16
17
void timer0_stop(void)
18
{
19
  TIMSK0  &= ~(1 << OCIE0A);                                   // OCIE0A: Interrupt by timer compare
20
  TCCR0B   &= ~(1 << WGM02) | (1<<CS00);
21
    TCCR0A  &= ~(1 << WGM01) | (1 << WGM00) | (1 << COM0A0);

deiner:
1
static void
2
irsnd_on (void)
3
{
4
    if (! irsnd_is_on)
5
    {
6
#ifndef DEBUG
7
#if defined (__AVR_ATmega32__)
8
        TCCR2 |= (1<<COM20)|(1<<WGM21);                 // = 0x42: toggle OC2A on compare match, clear Timer 2 at compare match OCR2A
9
#else
10
        TCCR2A |= (1<<COM2A0)|(1<<WGM21);               // = 0x42: toggle OC2A on compare match, clear Timer 2 at compare match OCR2A
11
#endif  // __AVR...
12
#endif // DEBUG
13
        irsnd_is_on = TRUE;
14
    }
15
}
16
17
/*---------------------------------------------------------------------------------------------------------------------------------------------------
18
 *  Switch PWM off
19
 *  @details  Switches PWM off
20
 *---------------------------------------------------------------------------------------------------------------------------------------------------
21
 */
22
static void
23
irsnd_off (void)
24
{
25
    if (irsnd_is_on)
26
    {
27
#ifndef DEBUG
28
#if defined (__AVR_ATmega32__)
29
        TCCR2 &= ~(1<<COM20);                                                           // normal port operation, OC2A disconnected.
30
#else
31
        TCCR2A &= ~(1<<COM2A0);                                                         // normal port operation, OC2A disconnected.
32
#endif  // __AVR...
33
        IRSND_PORT  &= ~(1<<IRSND_BIT);                                                 // set IRSND_BIT to low
34
#endif // DEBUG
35
        irsnd_is_on = FALSE;
36
    }
37
}


ergo dachte ich ich ersetzte dein ON/OFF durch meines

aber klappt nicht, irgendwo ist noch der Wurm drin,

nach play +5 sekunden hängt die routine

wenn einer mal schauen mag ?

danke
gruss
jar

von Joachim B. (jar)


Lesenswert?

mit static volatile usw. muss ich noch üben

am irsnd_busy hats gelegen

Routine läuft erst mal, nur das Gerät fühlt sich noch nicht angesprochen

muss erst mal ein 2ten IRMP bauen zum testen

die Pulse sind nun zu kurz um sie mit der digital cam hilfe zu sehen, im 
gegensatz zu vorher 500µs on/off

von Bruno I. (bjnas)


Lesenswert?

Das ist ja ein super Projekt, Gratulation an alle. Das ganze läuft ja 
auch mit B&O Codes. Nun hab ich einen IR Sender-Empfänger aus einem 
alten B&O Fernseher geschraubt.

Die Frage nun, kann man Ihn anstelle eines TSOP-7000 verwenden. Kennt 
jemand die Anschlüsse. Beim Empfänger ist auch ein Lichtsensor.

Kann über die beiden IR-Empfänger (TFK B  PW82) keine Datenblätter 
finden.

Danke für eine kleine Unterstützung.

von Bruno I. (bjnas)


Angehängte Dateien:

Lesenswert?

Hier noch die Platine

von Michael H. (michael_h45)


Lesenswert?


von Bruno I. (bjnas)


Lesenswert?

Man, das ging ja fix. Da war ich wohl schlampig.

von eku (Gast)


Lesenswert?

Hallo Frank,

hast Du Pläne, IRMP_USE_AS_LIB bis zu ende zu implementieren. Im Moment 
ist das nur ein Feigenblatt :-) Ich habe zwar eine Einbindung in 
ethersex laufen, einen Bibliothek würde aber das ganze vereinfachen.

von Peter D. (pdiener) Benutzerseite


Lesenswert?

Hallo Frank,

ich teste IRMP gerade auf einem ATmega324P.
Dieser sollte in der irsndconfig noch eingetragen werden, da auch hier 
die Pins nicht stimmen:
1
#if defined (__AVR_ATmega32__) || defined (__AVR_ATmega644P__) || defined (__AVR_ATmega324P__)
2
// usw.

Vielen Dank für dieses schöne Projekt!!!

Grüße,

Peter

von eku (Gast)


Lesenswert?

Hallo Frank!

Mit dem Nubert-Protokoll gibt es Probleme. Die von IRSND gesendete 
Sequenz wird von IRMP falsch dekodiert. Welche der Komponenten nun den 
Fehler macht, kann ich allerdings nicht sagen. Hier ein Beispiel:

irmp send 13 9 9 0
OK
IRMP: proto NUBERT, address 0000, command 0009, flags 00
IRMP 13:0000:0009:00

irmp send 13 1 1 0
OK
IRMP: proto NUBERT, address 0000, command 0001, flags 00
IRMP 13:0000:0001:00

Zum Vergleich ein Denon-Code:

irmp send 8 1 2 0
OK
IRMP: proto DENON, address 0001, command 0002, flags 00
IRMP 08:0001:0002:00

von Uwe R. (Gast)


Lesenswert?

Pollin-IR-Tastatur FDC-3402: Mausknubbel enträtselt

IR-Daten:
1
8 Adress-Bits
2
8 Mouse-Bits (Bit0=lButtonDown, Bit1=rButtonDown, Bit3=IsMouse, Bit4=IsLeftMove, Bit5=IsDownMove)
3
4 RightMove-Bits
4
4 LeftMove-Bits (wenn IsMouse in Mouse-Bits gesetzt, sonst Press/Release)
5
4 UpMove-Bits   (wenn IsMouse in Mouse-Bits gesetzt, sonst Low-Nibble von Command
6
4 DownMove-Bits (wenn IsMouse in Mouse-Bits gesetzt, sonst High-Nibble von Command
7
8 Invertierte Command-Bits
Mit X=RightMove-LeftMove und Y=UpMove-DownMove
bekommt man dann Werte, mit denen man auch etwas anfangen kann.
Mehr dazu in den nächsten Tagen, bin noch am Testen.

Gruß
Uwe

von djmaster (Gast)


Lesenswert?

Hi, bin mal ganz neu hier. ;) Und habe leider ein Problem wo ich alleine 
absolut nicht mehr weiterkomme. Suche schon seit tagen.^^ Programmieren 
kann ich leider nicht wirklich, ich versuche mich mit gesunden 
Menschenverstand durch die Codes durch zu arbeiten. Beruf: 
Nachrichtentechniker, also eher der Funksektor.

Ich habe ein etherrape mit ethersex im Einsatz und ich versuche gerade 
irmp auf meinem atmega644 zu compilen. Leider kein gutes Ergebnis.
1
hardware/ir/irmp/irmp.c:114: Warnung: #pragma push_macro  wird ignoriert
2
hardware/ir/irmp/irmp.c:118: Warnung: #pragma push_macro  wird ignoriert
3
hardware/ir/irmp/irmp.c:133: Warnung: #pragma pop_macro  wird ignoriert
4
hardware/ir/irmp/irmp.c:134: Warnung: #pragma pop_macro  wird ignoriert
5
hardware/ir/irmp/irmp.c:328: Warnung: »TIMER0_COMP_vect« scheint ein falsch geschriebener Signal-Handler zu sein
6
hardware/ir/irmp/irmp.c: In Funktion »TIMER0_COMP_vect:

Nun hab ich gelesen das dieser Timer0 beim atmega644 TIMER0_COMPA_vect 
heißt.
Ich glaube zumindest das ich am Richtigen weg bin aber, ehrlich gesagt 
keine Ahnung, Habe nun in der irmp.c TIMER0_COMP_vect in 
TIMER0_COMPA_vect geändert aber Ergebnis bleibt das gleiche.. es folgt 
ein Fehler mit __vector_16.
Nun hab ich keine Ahnung mehr wie ich weitermachen soll. Deswegen hab 
ich mir eure Codes hier angesehen aber irgendwie werde ich da auch nicht 
Schlau daraus.

Gehalten hab ich mich an dieses hier: 
http://www.ethersex.de/index.php/IRMP
Meine irmp.c --> http://paste2.org/p/1050578

Vielleicht könnt ihr mir ja weiterhelfen hab schon soooo viel tolle 
Sachen hier erlesen ;)

Grüße aus Wien

von eku (Gast)


Lesenswert?

Hallo,

djmaster schrieb:
> Ich habe ein etherrape mit ethersex im Einsatz und ich versuche gerade
> irmp auf meinem atmega644 zu compilen. Leider kein gutes Ergebnis.

die Portierung nach ethersex ist von mir. Hilfe bekommst Du im IRC 
(Details siehe ethersex WIKI).

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi eku,

eku schrieb:
> hast Du Pläne, IRMP_USE_AS_LIB bis zu ende zu implementieren. Im Moment
> ist das nur ein Feigenblatt :-) Ich habe zwar eine Einbindung in
> ethersex laufen, einen Bibliothek würde aber das ganze vereinfachen.

Dieses define ist eher gedacht, irmp als sog. "Include-Lib" zu nutzen. 
Das heisst, man hat irgendwo in seinem Projekt sämtliche Defines, die 
normalerweise in irmpconfig.h stehen, in seinem project-irmp.c und macht 
anschließend einfach ein
1
#include "../irmp/irmp.c"

Ich benutze diese Methode selbst öfters, um bestimmte Sources, welche 
projektunabhängig sind, in mein konkretes Projekt einzubinden. Das hat 
zwar nichts mit "echten" Libs im C-Sinne zu tun, hat aber den Vorteil, 
dass nur das vom Code übernommmen/compiliert wird, was man gerade 
braucht - bei IRMP zum Beispiel nur den NEC-Decoder. Mein Projekt bleibt 
dann unabhängig von den Standard-Werten in irmpconfig.h. Das ist 
sinnvoll bei µCs, wo es auf jedes gesparte Byte ankommt. Hier wird also 
kein Object-File dazugelinkt, sondern der Source selbst mit ins Projekt 
eingebunden. Meinetwegen kannst Du das Includen von C-Files (xxx.c) als 
No-Go ansehen, für mich ist das aber eine durchaus anwendbare Methode.

Eine "klassische" Lib aus IRMP zu machen, die man dazubindet, halte ich 
für einen µC unpraktikabel, da ja dann schon bei Erstellung der Lib klar 
sein muss, welche IR-Decoder ich brauche. Es ist aber bei der 
universellen Konfigurierbarkeit von IRMP gar nicht möglich, dies vorab 
zu entscheiden.

Um auf Deine Frage zurückzukommen: das IRMP_USE_AS_LIB ist für mich kein 
Feigenblatt, sondern für mich soweit bereits anwendbar ;-)

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Peter,

Peter Diener schrieb:
> ich teste IRMP gerade auf einem ATmega324P.
> Dieser sollte in der irsndconfig noch eingetragen werden, da auch hier
> die Pins nicht stimmen:
>
1
> #if defined (__AVR_ATmega32__) || defined (__AVR_ATmega644P__) ||
2
> defined (__AVR_ATmega324P__)
3
> // usw.
4
>

Danke, habe ich so übernommen, kommt ins nächste Release.

> Vielen Dank für dieses schöne Projekt!!!

Danke fürs Danke :-)

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:

> Mit dem Nubert-Protokoll gibt es Probleme. Die von IRSND gesendete
> Sequenz wird von IRMP falsch dekodiert. Welche der Komponenten nun den
> Fehler macht, kann ich allerdings nicht sagen. Hier ein Beispiel:
>
> irmp send 13 9 9 0
> OK
> IRMP: proto NUBERT, address 0000, command 0009, flags 00
> IRMP 13:0000:0009:00

Habe ich gerade versucht, nachzuvollziehen (unter Linux):

# ./irsnd 13 9 9 0 | ./irmp
0000001001 p = 13, a = 0x0000, c = 0x0009, f = 0x00

Stimmt, die dekodierte Adresse ist immer 0, aber das ist kein Wunder:

Nach

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

gibt es beim Nubert-Protokoll keine Adress-Bits, sondern nur 
Kommando-Bits. Daher ist das Verhalten von IRSND korrekt, es ignoriert 
nämlich Deine angegebene Adresse und IRMP zeigt immer 0 an.

Beachte auch meine Bemerkungen oberhalb der Tabelle im Artikel, Zitat:

| Bitte beachten: Je nach benutztem Protokoll sind die Bit-Breiten der
| Adressen bzw. Kommandos verschieden, siehe obige Tabelle [2].
| Man kann also nicht mit jedem IR-Protokoll komplett 16-Bit breite
| Adressen oder Kommandos transparent übertragen.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Uwe R. schrieb:
> Pollin-IR-Tastatur FDC-3402: Mausknubbel enträtselt

Sehr interessant!

> Mehr dazu in den nächsten Tagen, bin noch am Testen.

Ich hoffe, da kommen noch weitere Infos zu.

Gruß,

Frank

von Simon K. (simon) Benutzerseite


Lesenswert?

Hat jemand die URC Zapper (gibts bei Reichelt günstig) mal ausprobiert?

http://www.reichelt.de/?ARTICLE=77492

Dort steht:

----
Geeignet für die Bedienung von infrarotgesteuerten Fernsehgeräten aller 
Marken.
----

Also nehme ich mal an, dass da auf jeden Fall mindestens irgendein 
Protokoll unterstützt wird, richtig?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Simon K. schrieb:
> Also nehme ich mal an, dass da auf jeden Fall mindestens irgendein
> Protokoll unterstützt wird, richtig?

Davon gehe ich aus.

von eku (Gast)


Lesenswert?

Hallo Frank!

Nochmal zum Nubert Protokoll. IRMP dekodiert von der Original-FB 
Adressbits, die es laut Deines Artikels nich gibt. Erklär diesen 
Widerspruch doch bitte.

Mit dem Siemens-Protokoll habe ich das Problem, dass nicht alle von 
IRSND gesendeten Kommandos von der M740AV akzeptiert werden (im 
Gegensatz zur Original-FB). Die Dekodierung durch IRMP erscheint logisch 
(Anordnung der COdes auf der FB). Scheinbar ist das Timing kritisch beim 
Senden oder IRSND hat danoch einen Fehler. Anmerkung: IRMP dekodiert die 
durch IRSND gesendeten Kommandos fehlerfrei, nur eben der originale 
Empfänger nicht.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:
> Hallo Frank!
>
> Nochmal zum Nubert Protokoll. IRMP dekodiert von der Original-FB
> Adressbits, die es laut Deines Artikels nich gibt. Erklär diesen
> Widerspruch doch bitte.

Du schriebst weiter oben:

irmp send 13 9 9 0
OK
IRMP: proto NUBERT, address 0000, command 0009, flags 00
IRMP 13:0000:0009:00

irmp send 13 1 1 0
OK
IRMP: proto NUBERT, address 0000, command 0001, flags 00
IRMP 13:0000:0001:00

Hier erkennt IRMP als Adresse den Wert 0. Wo ist da ein Widerspruch?
Bitte gib genauere Infos an, mit "Adressbits, die es laut Deines 
Artikels" kann ich nichts anfangen.

> Mit dem Siemens-Protokoll habe ich das Problem, dass nicht alle von
> IRSND gesendeten Kommandos von der M740AV akzeptiert werden (im
> Gegensatz zur Original-FB). Die Dekodierung durch IRMP erscheint logisch
> (Anordnung der COdes auf der FB). Scheinbar ist das Timing kritisch beim
> Senden oder IRSND hat danoch einen Fehler. Anmerkung: IRMP dekodiert die
> durch IRSND gesendeten Kommandos fehlerfrei, nur eben der originale
> Empfänger nicht.

Benutzt Du einen Quartz am µC zum Senden? IRMP ist beim Timing 
wesentlich toleranter als die Hersteller-Empfänger es sind. Daher kann 
IRMP da durchaus "besser" sein als die Hersteller selbst.

Gruß,

Frank

von eku (Gast)


Lesenswert?

Hallo Frank!

> Benutzt Du einen Quartz am µC zum Senden? IRMP ist beim Timing
> wesentlich toleranter als die Hersteller-Empfänger es sind. Daher kann
> IRMP da durchaus "besser" sein als die Hersteller selbst.

Ich verwende einen m168 mit 16MHz quarzgetaktet. Laut Protkoldetails im 
IRMP-Artikel setzen sich die Daten aus

13 Adress-Bits + 1 Repeat-Bit + 7 Daten-Bits + 1 unbekanntes Bit

zusammen. Könnte es sein, dass es sich bei dem "unbekannten Bit" um die 
Parität handelt? Das würde zumindest erklären, warum nur die von IRSND 
gesendeten Zeichen vom M740AV erkannt werden, bei denen zufällig die 
Parität stimmt. Wie müsste man IRSND ändern, um diese These zu 
verifizieren?


Gruß, eku

von Simon B. (nomis)


Lesenswert?

Haben wir eigentlich eine Vorstellung davon, welche Adressen- und 
Datenwerte eigentlich generell so verwendet werden?

Hintergrund ist, dass ich gerade an einem USB-Empfänger bastele, der ein 
konfigurierbares HID-Keyboard darstellen soll. Wenn ich beliebige 
Fernbedienungen zulassen möchte, habe ich eine Lookup-Tabelle für die 
Keycodes, die 5-Byte-Keys (Protokoll + 16-bit Adresse + 16-bit Kommando) 
auf 1-2 Bytes Keycode abbildet.

Bei einem 512-Byte-EEprom kriege ich also etwa 70-80 Zuordnungen unter, 
was vielleicht reicht, sich aber trotzdem wie Verschwendung anfühlt.

Es wäre also nett, z.B. sagen zu können "das MSB von dem Kommando 
braucht man eh nie" oder "das Protokoll kann man in die Adresse mit 
reinverodern" und trotzdem noch eine gute Erkennung von beliebigen 
Fernbedienungen zu haben.

Leider habe ich keine klare Vorstellung davon, was die häufigste 
Verwendung von Address- und Kommandonummern ist, und welche 
"Zusammenfassung" erfolgversprechend wäre. Habt ihr da Ideen?

Viele Grüße,
        Simon

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:

> 13 Adress-Bits + 1 Repeat-Bit + 7 Daten-Bits + 1 unbekanntes Bit
>
> zusammen. Könnte es sein, dass es sich bei dem "unbekannten Bit" um die
> Parität handelt?

Das kann durchaus sein. Ich habe mir gerade nochmal die Scans von der 
M740AV angeschaut. Dabei haben ca. 50% der Frames als letztes Bit den 
Wert 0, die anderen haben als letztes Bit den Wert 1.

> Das würde zumindest erklären, warum nur die von IRSND
> gesendeten Zeichen vom M740AV erkannt werden, bei denen zufällig die
> Parität stimmt.

Ja, sehr gut erkannt!

> Wie müsste man IRSND ändern, um diese These zu verifizieren?

Füge die mit +++ gekennzeichneten Zeilen in irsnd.c ein:
1
#if IRSND_SUPPORT_SIEMENS_PROTOCOL == 1
2
        case IRMP_SIEMENS_PROTOCOL:
3
        {
4
            irsnd_buffer[0] = ((irmp_data_p->address & 0x0FFF) >> 5);                                           // SAAAAAAA
5
            irsnd_buffer[1] = ((irmp_data_p->address & 0x1F) << 3) | ((irmp_data_p->command & 0x7F) >> 5);      // AAAAA0CC
6
            irsnd_buffer[2] = (irmp_data_p->command << 3);                                                      // CCCCC0
7
8
            if ((irmp_data_p->command % 2) == 0)         // +++
9
            {                                            // +++
10
                irsnd_buffer[2] |= 0x04;                 // +++
11
            }                                            // +++
12
            irsnd_busy      = TRUE;
13
            break;
14
        }
15
#endif

Hier wird nun zusätzlich geprüft, ob das Kommando gerade oder ungerade 
ist. Zumindest für die M740AV scheint das zu stimmen, wenn ich das 
letzte Bit betrachte. Aber es könnte auch sein, dass beim 
Siemens-Protokoll im letzten Bit tatsächlich die Parität von Adresse + 
Kommando herangezogen wird. Um das zu beurteilen, bräuchte ich den Scan 
von einer anderen Siemens-FB, welche eine andere Adresse verwendet.

Kannst Du mal testen, ob es nun stimmt?

[/c]

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Simon Budig schrieb:

> Es wäre also nett, z.B. sagen zu können "das MSB von dem Kommando
> braucht man eh nie" oder "das Protokoll kann man in die Adresse mit
> reinverodern" und trotzdem noch eine gute Erkennung von beliebigen
> Fernbedienungen zu haben.

Das kann man leider überhaupt nicht sagen, wie man die Daten da noch 
weiter "komprimieren" kann. Du kannst Dir ja mal selbst ein Bild machen 
mit

  ./irmp <IR-Data/xxxx.txt

bzw.

  irmp.exe <IR-Data/xxxx.txt

was da alles so vorkommen kann. Beim Kaseikyo-Protokoll fehlen mir sogar 
noch 2 Bits, die ich in irmp_data.command gar nicht unterbringen kann. 
Glücklicherweise haben diese bei den bisherigen FB-Scans, die mir 
zugesandt wurden, keine relevanten Daten (immer "00").

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Frank M. schrieb:
> Hier wird nun zusätzlich geprüft, ob das Kommando gerade oder ungerade
> ist. Zumindest für die M740AV scheint das zu stimmen, wenn ich das
> letzte Bit betrachte.

Das letzte Bit ist eigentlich kein Paritätsbit, sondern einfach die 
Invertierung des davor zuletzt gesandten Bits, welches das 
niederwertigste Bit des Kommandocodes ist.

Daher ist die folgende Schreibweise als Codekorrektur von IRSND 
plausibler (führt aber zu demselben Ergebnis):
1
#if IRSND_SUPPORT_SIEMENS_PROTOCOL == 1
2
        case IRMP_SIEMENS_PROTOCOL:
3
        {
4
            irsnd_buffer[0] = ((irmp_data_p->address & 0x0FFF) >> 5);                                           // SAAAAAAA
5
            irsnd_buffer[1] = ((irmp_data_p->address & 0x1F) << 3) | ((irmp_data_p->command & 0x7F) >> 5);      // AAAAA0CC
6
            irsnd_buffer[2] = (irmp_data_p->command << 3);                                                      // CCCCC?
7
8
            if (!(irmp_data_p->command & 0x01))   // +++
9
            {                                     // +++
10
                irsnd_buffer[2] |= 0x04;          // +++  // 00000c
11
            }                                     // +++
12
            irsnd_busy      = TRUE;
13
            break;
14
        }
15
#endif

Im IRMP-Artikel habe ich nun folgendes zum SIEMENS-Prtokoll angemerkt:

13 Adress-Bits + 1 Repeat-Bit + 7 Daten-Bits + 1 invertiertes Bit 
(letztes Bit davor nochmal invertiert)

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Noch kürzer:

Alt:
1
  irsnd_buffer[2] = (irmp_data_p->command << 3);                                                      // CCCCC?

Neu:
1
  irsnd_buffer[2] = (irmp_data_p->command << 3) | ((~irmp_data_p->command & 0x01) << 2);              // CCCCCc

Dann kann der ganze nachfolgende if-Block entfallen. Ich habe das so nun 
im IRSND übernommen. Kommt ins nächste Release.

von Simon K. (simon) Benutzerseite


Lesenswert?

Hast du mal ausprobiert, was weniger Code verbraucht? Ich vermute fast, 
dass die if-Anweisung effizienter ist.

von eku (Gast)


Lesenswert?

Hallo Frank,

Frank M. schrieb:
> Frank M. schrieb:
>> Hier wird nun zusätzlich geprüft, ob das Kommando gerade oder ungerade
>> ist. Zumindest für die M740AV scheint das zu stimmen, wenn ich das
>> letzte Bit betrachte.
>
> Das letzte Bit ist eigentlich kein Paritätsbit, sondern einfach die
> Invertierung des davor zuletzt gesandten Bits, welches das
> niederwertigste Bit des Kommandocodes ist.

das war es nicht. Versuche es nun mit der Parität, d.h. die Einsen 
zählen ( (parity_even_bit aus der avrlibc). Allerdings muss ich noch 
testen, ob die Parität auch über die Adresse gebildet wird.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:
>> Das letzte Bit ist eigentlich kein Paritätsbit, sondern einfach die
>> Invertierung des davor zuletzt gesandten Bits, welches das
>> niederwertigste Bit des Kommandocodes ist.
>
> das war es nicht. Versuche es nun mit der Parität, d.h. die Einsen
> zählen ( (parity_even_bit aus der avrlibc). Allerdings muss ich noch
> testen, ob die Parität auch über die Adresse gebildet wird.

Komisch, schau Dir mal diesen Output an:
1
 ./irmp-15kHz <IR-Data/Siemens-Gigaset-M740AV-15kHz.txt
2
-------------------------------------------------------------------
3
# Power
4
00011011000100000010110 p = 17, a = 0x06c4, c = 0x000b, f = 0x00
5
-------------------------------------------------------------------
6
# 1
7
00011011000100000000010 p = 17, a = 0x06c4, c = 0x0001, f = 0x00
8
-------------------------------------------------------------------
9
#2
10
00011011000100000000101 p = 17, a = 0x06c4, c = 0x0002, f = 0x00
11
-------------------------------------------------------------------
12
# 3
13
00011011000100000000110 p = 17, a = 0x06c4, c = 0x0003, f = 0x00
14
-------------------------------------------------------------------
15
# 4
16
00011011000100000001001 p = 17, a = 0x06c4, c = 0x0004, f = 0x00
17
-------------------------------------------------------------------
18
# 5
19
00011011000100000001010 p = 17, a = 0x06c4, c = 0x0005, f = 0x00
20
-------------------------------------------------------------------
21
# 6
22
00011011000100000001101 p = 17, a = 0x06c4, c = 0x0006, f = 0x00
23
-------------------------------------------------------------------
24
# 7
25
00011011000100000001110 p = 17, a = 0x06c4, c = 0x0007, f = 0x00
26
-------------------------------------------------------------------
27
# 8
28
00011011000100000010001 p = 17, a = 0x06c4, c = 0x0008, f = 0x00
29
-------------------------------------------------------------------
30
# 9
31
00011011000100000010010 p = 17, a = 0x06c4, c = 0x0009, f = 0x00
32
-------------------------------------------------------------------
33
# 0
34
00011011000100000010101 p = 17, a = 0x06c4, c = 0x000a, f = 0x00
35
-------------------------------------------------------------------
36
# HELP
37
00011011000100000100110 p = 17, a = 0x06c4, c = 0x0013, f = 0x00
38
-------------------------------------------------------------------
39
# Hoch
40
00011011000100000101101 p = 17, a = 0x06c4, c = 0x0016, f = 0x00
41
-------------------------------------------------------------------
42
# Links
43
00011011000100000011001 p = 17, a = 0x06c4, c = 0x000c, f = 0x00
44
-------------------------------------------------------------------
45
# OK
46
00011011000100000011101 p = 17, a = 0x06c4, c = 0x000e, f = 0x00
47
-------------------------------------------------------------------
48
# Rechts
49
00011011000100000011110 p = 17, a = 0x06c4, c = 0x000f, f = 0x00
50
-------------------------------------------------------------------
51
# Runter
52
00011011000100000100001 p = 17, a = 0x06c4, c = 0x0010, f = 0x00
53
-------------------------------------------------------------------
54
# EXIT
55
00011011000100000011010 p = 17, a = 0x06c4, c = 0x000d, f = 0x00
56
-------------------------------------------------------------------
57
# Mute
58
00011011000100000101110 p = 17, a = 0x06c4, c = 0x0017, f = 0x00
59
-------------------------------------------------------------------
60
# Menu
61
00011011000100000110010 p = 17, a = 0x06c4, c = 0x0019, f = 0x00
62
-------------------------------------------------------------------
63
# EPG
64
00011011000100000110110 p = 17, a = 0x06c4, c = 0x001b, f = 0x00
65
-------------------------------------------------------------------
66
# INFO
67
00011011000100000111001 p = 17, a = 0x06c4, c = 0x001c, f = 0x00
68
-------------------------------------------------------------------
69
# REW
70
00011011000100000111010 p = 17, a = 0x06c4, c = 0x001d, f = 0x00
71
-------------------------------------------------------------------
72
# STOP
73
00011011000100000111101 p = 17, a = 0x06c4, c = 0x001e, f = 0x00
74
-------------------------------------------------------------------
75
# FF
76
00011011000100000111110 p = 17, a = 0x06c4, c = 0x001f, f = 0x00
77
-------------------------------------------------------------------
78
# Rot
79
00011011000100001000001 p = 17, a = 0x06c4, c = 0x0020, f = 0x00
80
-------------------------------------------------------------------
81
# Gruen
82
00011011000100001000010 p = 17, a = 0x06c4, c = 0x0021, f = 0x00
83
-------------------------------------------------------------------
84
# Gelb
85
00011011000100001000101 p = 17, a = 0x06c4, c = 0x0022, f = 0x00
86
-------------------------------------------------------------------
87
# Blau
88
00011011000100001000110 p = 17, a = 0x06c4, c = 0x0023, f = 0x00

Hier ist das letzte Bit immer das invertierte des vorletzten. Oder ist 
da noch ein Bug in der Manchester-Codierung des IRMP? Glaube ich 
eigentlich nicht, denn RS5 und RC6 funktionieren ja....

Kannst Du mal sagen, welche Kommando-Codes gerade nicht akzeptiert 
werden?

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Simon K. schrieb:
> Hast du mal ausprobiert, was weniger Code verbraucht? Ich vermute fast,
> dass die if-Anweisung effizienter ist.

Beide Varianten führen beim ATmega88 zu dem Codezuwachs von je 16 Bytes 
- es kommt also exakt auf dasselbe raus.

von eku (Gast)


Lesenswert?

Hallo Frank,

> Kannst Du mal sagen, welche Kommando-Codes gerade nicht akzeptiert werden?

war mein Fehler. In der Scandatei Siemens-Gigaset-M740AV-15kHz.txt sind 
einige Tasten falsch beschriftet. Werde bei Gelegenheit mal eine neue 
aufzeichnen. In http://www.m740.de/wiki/Lircd wird das besagte Bit dem 
Kommando zugeordnet. Geschmackssache. Bitte aktualisiere IRSND im SVN 
mit Deinem Fix.

Bei Dekodieren mit IRMP gibt es Interferenzen mit anderen Dekodern. Ich 
habe nur noch nicht rausbekommen mit welchem. Siemens alleine dekodiert 
meist zuverlässig. Alle Dekoder aktiviert und die Dekodierung gerät zum 
Glückspiel.
Siehst Du eine Möglichkeit, die Anzahl der zu testenden Kombinationen 
von vorn herein einzuschränken?

Gruß, eku

von eku (Gast)


Lesenswert?

Hallo Frank,

> In http://www.m740.de/wiki/Lircd wird das besagte Bit dem
> Kommando zugeordnet. Geschmackssache. Bitte aktualisiere IRSND im SVN
> mit Deinem Fix.

mittlerweile bin ich der Überzeugung, dass entweder dieses Bit den Daten 
zugeschlagen wird oder aber IRMP dessen Gültigkeit, nach der von Dir 
aufgestellten Regel, prüft. Ich persönlich plädiere für 1.


Gruß, Erik

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:

> mittlerweile bin ich der Überzeugung, dass entweder dieses Bit den Daten
> zugeschlagen wird oder aber IRMP dessen Gültigkeit, nach der von Dir
> aufgestellten Regel, prüft. Ich persönlich plädiere für 1.

Mir gefällt es eigentlich nicht, wenn es dem Kommando zugeschlagen wird.

Gründe:

1. Das Prüfbit gehört offensichtlich nicht zum Kommando

2. Es stört mein Symmetrie-Empfinden (die Kommando-Codes sind nicht
   mehr fortlaufend)

3. Die LIRCS-Leute haben sich das Leben da sehr einfach gemacht ;-)

Dass IRMP konsequenterweise das letzte Bit prüfen soll, halte ich für 
sinnvoller. Denn genau dafür ist das letzte Bit offenbar da: zur 
Prüfung. Genau das macht IRMP auch teilweise bei anderen Protokollen, 
z.B. NEC, wo sämtliche invertierten Kommandobits gegengecheckt werden.

Wenn ich das Prüfbit dem Kommando zuschlage, dann hat das folgende 
Nachteile:

1. Prüfung auf Gültigkeit nicht mehr sinnvoll
2. Es können irreguläre Codes sowohl empfangen als auch gesendet werden

Daher plädiere ich für 2 ;-)

Ich habe bereits den Check des Prüfbits auf meiner TODO-Liste.

Gruß,

Frank

von eku (Gast)


Lesenswert?

Hallo Frank,

danke für das Update im SVN. Funktioniert soweit, aqllerdings ist das 
Timing bei IRSND kritisch denn die M740AV reagiert nicht zuverlässig. 
Könnten die 200usec Bitlänge falsch sein?

Und noch ein Problem: Ist nur Nokia und nicht Grundig aktiv (die 
Protokolle teilen sich die Timings) wird trotzdem Grundig detektiert. Da 
ist die Logik "Grundig annehmen und später auf Nokia umschalten" falsch. 
Würdest Du das bitte korrigieren.


Gruß, eku

von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Lesenswert?

eku schrieb:

> danke für das Update im SVN. Funktioniert soweit, aqllerdings ist das
> Timing bei IRSND kritisch denn die M740AV reagiert nicht zuverlässig.
> Könnten die 200usec Bitlänge falsch sein?

Schau Dir bitte die Text-Datei im Anhang an (im Notepad Zeilenumbruch 
aktivieren).

Die erste Zeile enthält Deinen Scan von der Taste "Rechts", die Zeile 
darunter enthält den von IRSND generierten Frame.

Die Zeilen sind fast identisch. An IRSND kann es also nicht liegen, es 
reproduziert das Telegramm perfekt - sogar besser als das Original ;-)
Vielleicht ist Dein damaliger Scan nicht genau genug? Oder stimmt 
vielleicht die Modulationsfrequenz nicht?

Du kannst ja mal die Parameter variieren, vielleicht kannst du das 
Resultat somit optimieren?

> Und noch ein Problem: Ist nur Nokia und nicht Grundig aktiv (die
> Protokolle teilen sich die Timings) wird trotzdem Grundig detektiert.

Habe ich gerade versucht zu reproduzieren: bei mir wird Nokia (protocol 
= 16) erkannt. Nokia und Grundig werden auch im Source absolut 
gleichberechtigt behandelt. Ich sehe da keine Stelle im Code, wo Dein 
beschriebenes Verhalten greifen sollte.

> Da ist die Logik "Grundig annehmen und später auf Nokia umschalten"
> falsch.

Kann ich leider nicht reproduzieren.

Gruß,

Frank

von Müller (Gast)


Lesenswert?

Guten Tag

finde dein Projeckt so weit sehr gut.
Habe da mal ne Frage an euch. Wann wird RC6 in IRSEND eingebaut.

Da ich zum größten teil  meiner Fernbedinungen RC6 sind


mfg

Müller

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Müller schrieb:

> Habe da mal ne Frage an euch. Wann wird RC6 in IRSEND eingebaut.

Einen Prototypen für RC6 habe ich laufen, bei RC6A (FBs von Kathrein & 
Co) habe ich noch ein Problem, da weiss ich leider noch nicht, ob ich 
den Fehler im IRSND oder vielleicht sogar im IRMP habe, da ich den IRSND 
immer mit dem IRMP selbst testen muss.

Ich versuche mal, das Problem in den Griff zu bekommen, dann würde ich 
hier im Laufe der Woche eine Testversion reinstellen, damit Du das 
testen kannst ;-)

Gruß,

Frank

von Müller (Gast)


Lesenswert?

Hallo Frank

Ich danke dir schon mal im voraus. dann bin ich mal gespannt und fiel 
glück das du es hin bekommts

mfg

Müller

von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Lesenswert?

Anbei eine Testversion von IRSND, welche auch das RC6- und 
RC6A-Protokoll (Protokollnummern 9 u. 21) unterstützt. Im Zip-Archiv 
sind nur die gegenüber der Download-Version geänderten Dateien.

Hier ist auch noch eine Korrektur für IRMP drin, nämlich für das 
RC6A-Protokoll. Hier hatte bisher IRMP immer automatisch das 
höchstwertige Adressbit gesetzt, wenn es sich um RC6A handelte. Das ist 
nun nicht mehr der Fall. Bei der Kathrein-FB wurde bisher als Adresse 
0x8046 ausgegeben, nun ist es 0x0046.

Wäre Klasse, wenn jemand IRSND bzgl. RC6 und RC6 testen könnte. Dieses 
Manchester-Protokoll mit wechselnden Periodenzeiten (im T-Bit) raubt mir 
mal wieder den letzten Nerv...

Gruß,

Frank

von Müller (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Frank

Habe deine neune Datein bei mir ins Projeckt übernommen
nun habe ich ein Problem mein IR-Empfanger geht nicht mehr hast du was 
am eingang geändert ?

Hier ist mein codes

im IRBORD ist das halt mit den normalen programm
im IRBORD2 ist das mit den neune Programmcode von dir


kannst du mal nachschauen ob ich was falsch gemacht habe

von eku (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Frank,

habe hier Probleme mit einem Sharp TV. IRMP meint, dass es sich um 
Denon-Protkoll handelt, der TV reagiert aber nicht auf die von IRSND 
gesendeten Sequenzen.

Was mich an Denon zweifeln lässt, ist die Tatsache, dass IRMP bei 
einigen Tasten einen völlig andere Geräteadresse dekodiert (z.B. MENU).

Anbei ein Scan der wichtigsten Tasten bei 15kHz.

Gruß, eku

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:
> habe hier Probleme mit einem Sharp TV. IRMP meint, dass es sich um
> Denon-Protkoll handelt, der TV reagiert aber nicht auf die von IRSND
> gesendeten Sequenzen.

Ja, das sieht sehr nach DENON aus, auch die invertierten 
Frame-Wiederholungen sind drin. Allerdings sind viele Scans 
offensichtlich kaputt, da kommen dann sehr oft lange "Dunkelphasen" 
innerhalb der Frames.

Das kann zweierlei Gründe haben:

1. FB war zu weit weg vom IR-Empfänger
2. Modulationsfrequenz der FB passt schlecht zum TSOP.

Denon benutzt da ja 32kHz, das ist schon eine Ecke weg vom TSOP1736 oder 
gar TSOP1738...

> Was mich an Denon zweifeln lässt, ist die Tatsache, dass IRMP bei
> einigen Tasten einen völlig andere Geräteadresse dekodiert (z.B. MENU).

Das findet man öfter bei einigen FBs, da werden dann geräteübergreifende 
Adressen benutzt. Das können zum Beispiel Fernseher sein, die Funktionen 
einzelner Produkte desselben Herstellers in einem Gerät vereinen, z.B. 
Festplatten-Recorder im TV, irgendwelche Spezial-Tuner, Timer oder 
sonstwas...

> Anbei ein Scan der wichtigsten Tasten bei 15kHz.

Das ist eindeutig Denon-Code. Allerdings ist die Aufzeichnungsqualität 
sehr schlecht.

Reagiert das TV auf keines der ausgesandten Kommandos? Vielleicht 
benutzt der Sharp zwar das Denon-Protokoll, aber eine andere 
Modulationsfrequenz? Hast Du ein Oszilloskop, um Dir das näher 
anzuschauen?

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Müller schrieb:
> Habe deine neune Datein bei mir ins Projeckt übernommen
> nun habe ich ein Problem mein IR-Empfanger geht nicht mehr hast du was
> am eingang geändert ?

Nein, aber Du scheinst den neuen Code nicht an Deine Hardware angepasst 
zu haben:

irmpconfig.h:
1
< #define IRMP_PORT                               PORTC
2
< #define IRMP_DDR                                DDRC
3
< #define IRMP_PIN                                PINC
4
< #define IRMP_BIT                                0       // use PB6 as IR input on AVR
5
---
6
> #define IRMP_PORT                               PORTB
7
> #define IRMP_DDR                                DDRB
8
> #define IRMP_PIN                                PINB
9
> #define IRMP_BIT                                6       // use PB6 as IR input on AVR


irsndconfig.h
1
< #define IRSND_PORT                              PORTB   // port D
2
< #define IRSND_DDR                               DDRB    // ddr D
3
< #define IRSND_BIT                               3       // OC2A
4
---
5
> #define IRSND_PORT                              PORTD   // port D
6
> #define IRSND_DDR                               DDRD    // ddr D
7
> #define IRSND_BIT                               7       // OC2A

Damals hattest Du es wohl angepasst (siehe obige Unterschiede), dieses 
Mal hast Du das offenbar versäumt.

Gruß,

Frank

von eku (Gast)


Lesenswert?

Frank M. schrieb:
> eku schrieb:
>> habe hier Probleme mit einem Sharp TV. IRMP meint, dass es sich um
>> Denon-Protkoll handelt, der TV reagiert aber nicht auf die von IRSND
>> gesendeten Sequenzen.
>
> Ja, das sieht sehr nach DENON aus, auch die invertierten
> Frame-Wiederholungen sind drin. Allerdings sind viele Scans
> offensichtlich kaputt, da kommen dann sehr oft lange "Dunkelphasen"
> innerhalb der Frames.
>
> Das kann zweierlei Gründe haben:
>
> 1. FB war zu weit weg vom IR-Empfänger

War sie nicht.

> 2. Modulationsfrequenz der FB passt schlecht zum TSOP.

Schon möglich.

> Denon benutzt da ja 32kHz, das ist schon eine Ecke weg vom TSOP1736 oder
> gar TSOP1738...

Mit der selben Hardware kann ich eine originale Denon-FB problemlos 
einlesen und auch die Geräte mit IRSND bedienen. Null Probleme.

> Reagiert das TV auf keines der ausgesandten Kommandos? Vielleicht
> benutzt der Sharp zwar das Denon-Protokoll, aber eine andere
> Modulationsfrequenz? Hast Du ein Oszilloskop, um Dir das näher
> anzuschauen?

Auf keines der ausgesandten Kommandos reagiert der TV. Zugriff auf einen 
Oszi habe ich nicht.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:

>> 2. Modulationsfrequenz der FB passt schlecht zum TSOP.
> Schon möglich.

Welchen IR-Empfänger benutzt Du denn?

Wenn man sich die Scans mit einem Text-Editor anschaut (einer, der auch 
mit langen Zeilen bestens zurechtkommt, also nicht Notepad o.ä.), sieht 
man sehr schön, dass es immer wieder "Aussetzer" gibt, d.h. dass 
IR-Impulse dort, wo sie eigentlich sein sollten, komplett fehlen. Das 
Timing von der FB ist ungeheuer exakt, selbst nach über 2300 Scanpunkten 
passen die empfangenen Impulse noch ziemlich genau übereinander.

Eigentlich werden nur die ersten beiden Tasten (power + radio) Deines 
Scans von IRMP "verstanden", alles andere wird als fehlerhaft verworfen 
- was man auch nachvollziehen kann, wenn man mit dem Editor reinschaut.

Hast Du denn beim IRMP auch derart schlechte Ergebnisse bei der 
Sharp-FB? Oder war das einfach nur ein "Montags-Scan"? Kannst Du den 
Scan wiederholen, damit man eine Aussage über die Qualität der 
Reproduzierung machen kann?

> Mit der selben Hardware kann ich eine originale Denon-FB problemlos
> einlesen und auch die Geräte mit IRSND bedienen. Null Probleme.

Sehr schön :)

> Auf keines der ausgesandten Kommandos reagiert der TV.

Das Timing der Sharp-FB ist zwar exakt, jedoch ermittelt IRMP leicht vom 
DENON-Protokoll abweichende Timingwerte, die aber alle noch in der 
IRMP-Toleranz liegen, für das Sharp-TV aber vielleicht schon zu stark 
abweichen.

Ersetze mal in irmp.h folgende Zeilen
1
#define DENON_PULSE_TIME                        275.0e-6                        //  275 usec pulse
2
#define DENON_1_PAUSE_TIME                      1900.0e-6                       // 1900 usec pause

durch
1
#define DENON_PULSE_TIME                        300.0e-6                        //  300 usec pulse
2
#define DENON_1_PAUSE_TIME                      1800.0e-6                       // 1800 usec pause

und teste IRSND erneut.

> Zugriff auf einen Oszi habe ich nicht.

Das ist schade.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:
> Auf keines der ausgesandten Kommandos reagiert der TV.

Habe da noch eine Idee:

Die Sharp-FB sendet offenbar 3 Frames pro Tastendruck - und nicht nur 
zwei, wie es bei DENON wohl sonst üblich ist. IRSND sendet jedenfalls 
nur zwei Frames, nämlich:

1. Frame: Adresse + Kommando
2. Frame: Adresse + invertiertes Kommando

Die Sharp FB sendet:

1. Frame: Adresse + Kommando
2. Frame: Adresse + invertiertes Kommando
3. Frame: Adresse + Kommando

Dieses Verhalten könnte man mit dem IRSND simulieren, indem man 
irmp_data.flags = 1 setzt, dann wiederholt IRSND nämlich die beiden 
obigen Frames und es käme raus:

1. Frame: Adresse + Kommando
2. Frame: Adresse + invertiertes Kommando
3. Frame: Adresse + Kommando
4. Frame: Adresse + invertiertes Kommando

Das ist zwar dann ein Frame zuviel (der letzte), aber wenn Du Glück 
hast, ist das Sharp-TV nach dem 3. Frame zufrieden und führt das 
Kommando aus.

Gruß,

Frank

von eku (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Frank,

danke für deine Analyse. Der TV lässt sich weder von den geänderten 
Timings noch von der Framewiederholung beindrucken :-(

Anbei ein erneuter Scan, diesmal beo 10KkHz. Auf der FB steht ga323wjsa. 
Man kann sie an allen Ecken des Internets kaufen, aber das Protkoll wird 
nicht beschrieben.

Gruß,
eku

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi eku,

eku schrieb:

> danke für deine Analyse. Der TV lässt sich weder von den geänderten
> Timings noch von der Framewiederholung beindrucken :-(

Hm, erstmal habe ich jetzt keine Idee mehr, muss ich nochmal drüber 
nachdenken.

> Anbei ein erneuter Scan, diesmal beo 10KkHz.

Dieses Mal ist der Scan perfekt und läuft ohne Fehler durch den IRMP 
durch.

Hier eine Beispiel-Ausgabe, wo man sehr gut sieht, dass es 3 Frames 
sind.
1
# ./irmp < sharp.log
2
-------------------------------------------------------------------
3
# power
4
100000110100010
5
100001001011101 p =  8, a = 0x0010, c = 0x01a2, f = 0x00
6
100000110100010
7
-------------------------------------------------------------------
8
...

IRMP detektiert also nach dem 2. Frame (in welchem die Kommando-Bits 
negiert sind) bereits die Daten. Es folgt aber nochmal der 
Original-Frame. So geht das bei allen Tasten im Scan.

In meinen Augen kann das eigentlich nur daran liegen. Vielleicht baue 
ich dieses 3-Frame-Telegramm mal als Besonderheit in den IRMP ein - 
vielleicht hilft das weiter. Dabei würde ich dann auch die Pausen 
zwischen dem 2. und dem 3. Frame mal genau umsetzen - nicht mit dem 
Trick der Wiederholung.

Gruß,

Frank

von eku (Gast)


Lesenswert?

Hallo Frank,

passt die Beschreibung von 
http://www.sbprojects.com/knowledge/ir/sharp.htm auf meinen Scan? Ist es 
am Ende doch ein eigenständiges Protokoll und nur ähnlich dem Denon?

von eku (Gast)


Lesenswert?

Hallo Frank,

noch eine Quelle: S.15 in 
http://tinkerish.com/docs/ir%20remote%20control%20details.pdf

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:
> passt die Beschreibung von
> http://www.sbprojects.com/knowledge/ir/sharp.htm auf meinen Scan? Ist es
> am Ende doch ein eigenständiges Protokoll und nur ähnlich dem Denon?

Diese Beschreibung ist tatsächlich sehr ähnlich zum Denon-Protokoll. Im 
obigen Link wird von

  0 Start-Bits
  5 Adress-Bits
  8 Daten-Bits
  1 Expansion-Bit - immer 1
  0 Check-Bit - immer 0

gesprochen. Das macht zusammen 15 Bits.

Das Denon-Protokoll setzt sich zusammen aus:

  0 Start-Bits
  5 Adress-Bits
 10 Daten-Bits

macht also zusammen auch 15 Bits.

Tatsächlich sind die beiden letzten Bits auch "10" in deinen Scans, das 
passt also auf die Beschreibung des Expansion- und Check-Bits.

Die Timings sind auch sehr ähnlich:

          Denon       Sharp
Pulse     275µs       320µs
Pause 0   775µs       680µs
Pause 1  1900µs       1680µs

Tatsächlich sind diese Timings innerhalb der IRMP-Toleranzen identisch, 
IRMP kann diese also gar nicht auseinanderhalten. Es passt alles: Anzahl 
der Bits und die Timings.

Wenn ich mir die Timings innerhalb Deines Scans anschaue, so liegen sie 
ziemlich zwischen den obigen Werten, ich kann also auch nicht genau 
sagen, ob es eher Denon- oder Sharp-Timings sind.

Aber was gar nicht passt, ist die Modulationsfrequenz, bei Denon ist sie 
32 kHz, bei Sharp ist sie 38 kHz.

Ändere also bitte folgendes zum Testen des IRSND:

1. Modulationsfrequenz von 32 kHz auf 38 kHz:

Alt:
1
   case IRMP_DENON_PROTOCOL:
2
   {
3
       ...
4
       irsnd_set_freq (IRSND_FREQ_32_KHZ);

Neu:
1
   case IRMP_DENON_PROTOCOL:
2
   {
3
       ...
4
       irsnd_set_freq (IRSND_FREQ_38_KHZ);

2. Timings in irmp.h:
1
#define DENON_PULSE_TIME                        320.0e-6                        //  320 usec pulse
2
#define DENON_1_PAUSE_TIME                      1680.0e-6                       // 1680 usec pause
3
#define DENON_0_PAUSE_TIME                       680.0e-6                       //   680 usec pause
4
#define DENON_FRAMES                            2                               // DENON sends each frame 2 times

Probiere das einmal mit irmp_data.flags = 0 und dann, wenn das nichts 
hilft, mit irmp_data.flags = 1.

Gruß,

Frank

von eku (Gast)


Lesenswert?

Hallo Frank,

Frank M. schrieb:
> Ändere also bitte folgendes zum Testen des IRSND:

funktioniert. Es bedarf noch nicht einmal der Framewiederholung.

Die Erweiterung von IRSND stellt sicher kein Problem dar. Wie IRMP Sharp 
von Dennon unterscheiden kann, ist, sieht man mal von den Timings ab, 
unklar. Vielleicht kann IRMP es am Expansion- und Check-Bit oder den 
40ms zwischen ersten und zweitem Frame identifizieren. Du kennst Deinen 
Code besser und findest bestimmt einen Weg.

Gruß, eku

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi eku,

eku schrieb:

> funktioniert. Es bedarf noch nicht einmal der Framewiederholung.

Reicht vielleicht die Änderung der Modulationsfrequenz unter Einhaltung 
der Original-Denon-Timings? Wäre klasse, wenn Du das noch separat testen 
würdest.

> Die Erweiterung von IRSND stellt sicher kein Problem dar. Wie IRMP Sharp
> von Dennon unterscheiden kann, ist, sieht man mal von den Timings ab,
> unklar. Vielleicht kann IRMP es am Expansion- und Check-Bit oder den
> 40ms zwischen ersten und zweitem Frame identifizieren. Du kennst Deinen
> Code besser und findest bestimmt einen Weg.

Ja, ich werde da nochmal die genauen Unterschiede untersuchen. Mit 
Codekenntnis hat das weniger zu tun, eher mit meinen (bescheidenen) 
Protokollkenntnissen ;-)

Das Expansion- und Check-Bit sind leider nur ein notwendiges, aber kein 
hinreichendes Kriterium für Sharp. Die "10"-Kombi kann durchaus auch bei 
Denon vorkommen. Bleiben dann noch die Pausen zwischen den Frames. Da 
habe ich noch nicht so genau hingeschaut...

Gruß,

Frank

von eku (Gast)


Lesenswert?

Hallo Frank,

Frank M. schrieb:
> Reicht vielleicht die Änderung der Modulationsfrequenz unter Einhaltung
> der Original-Denon-Timings?

nein. Es bedarf definitiv der Sharp-Timings.

Denon (65ms) und Sharp (40ms) unterscheiden sich in der Pause zwischen 
den Frames. Könnte IRMP zur Unterscheidung heranziehen. Bei 10kHz 
Abtastung kein Problem dies zu unterscheiden, sofern sich die FB auch 
daran halten.

Gruß, eku

von Müller (Gast)


Lesenswert?

Danke Frank

für deine Hilfe nun da kann woll mal wieder alles aufeindander.

Nun leuft es habe meine Hardware angepasst danke.

mfg
Müller

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Müller schrieb:

> Nun leuft es habe meine Hardware angepasst danke.

Prima. Hast Du die RC6- und RC6A-Protokolle im IRSND schon testen 
können?

Gruß,

Frank

von form (Gast)


Lesenswert?

Hallo, nettes Projekt.
Sehe ich das richtig, das sowohl bei IRMP als auch bei IRSND die Pins 
für den Empfänger und die IR-Diode frei wählbar sind?

Keine Interrupt-Pins beim Empfangen nötig?
Keine PWM-Pins beim Senden nötig?

MfG
Stefan

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

form schrieb:

> Sehe ich das richtig, das sowohl bei IRMP als auch bei IRSND die Pins
> für den Empfänger und die IR-Diode frei wählbar sind?

Beim IRMP: ja.
Beim IRSND: jain, s.u.

> Keine Interrupt-Pins beim Empfangen nötig?

Korrekt, es wird gepollt.

> Keine PWM-Pins beim Senden nötig?

Doch, es ist ein PWM-Pin nötig - wegen der Modulationsfrequenz.

Siehe auch den entsprechenden Abschnitt "Modulation" im IRMP-Artikel:

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

Gruß,

Frank

von jar (Gast)


Lesenswert?

Frank M. schrieb:
> Doch, es ist ein PWM-Pin nötig - wegen der Modulationsfrequenz.

wenn nötig ginge auch soft PWM - dazu gibts hier Beispiele in der 
Codesammlung

von eku (Gast)


Lesenswert?

Hallo Frank,

hast Du schon Zeit und Muse gehabt, das SHARP Protokoll zu 
implemetieren?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:

> Denon (65ms) und Sharp (40ms) unterscheiden sich in der Pause zwischen
> den Frames.

Das kann ich nicht bestätigen. Wenn ich mir IR-Data/denon-15kHz.txt 
anschaue, ist die Pause zwischen dem ersten und dem zweiten Frame 
ziemlich genau 653 Ticks, das macht dann wg. der Scanrate 653/15 = 44ms.

Wenn ich Deine sharp.log dagegenhalte, bekomme ich da ca. 40-43 ms 
heraus, also fast denselben Wert.

> Könnte IRMP zur Unterscheidung heranziehen. Bei 10kHz
> Abtastung kein Problem dies zu unterscheiden, sofern sich die FB auch
> daran halten.

Das ist mir zu eng. 40ms vs. 65ms wären wirklich schön gewesen, aber du 
hast da bei der Denon-FB wohl den Faktor 15 statt 10 wg. der Abtastrate 
vergessen :-)

Oder hast Du da mehr Scans von Denon-FBs?

Gruß,

Frank

von eku (Gast)


Lesenswert?

Hallo Frank,

Frank M. schrieb:
> Das ist mir zu eng. 40ms vs. 65ms wären wirklich schön gewesen, aber du
> hast da bei der Denon-FB wohl den Faktor 15 statt 10 wg. der Abtastrate
> vergessen :-)

das ist gut möglich. Die Standardabtastrate für Denon beträgt doch aber 
10kHz. Eine Implementierung des SHARP-Protokolls in IRSND mit den 
Timings laut Proktollspezifikation würde mir ein Stück weiterhelfen.

> Oder hast Du da mehr Scans von Denon-FBs?

Ich besitze genau eine Denon-FB, die sich per Schiebeschalter auf 
verschiedene Geräte umstellen lässt und genau eine Sharp. Über die 
Feiertage werde ich mal ein paar Scans aufzeihnen.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi eku,

eku schrieb:

> Eine Implementierung des SHARP-Protokolls in IRSND mit den
> Timings laut Proktollspezifikation würde mir ein Stück weiterhelfen.

Klar, das kann ich gern machen. Aber wie erkläre ich den Anwendern, dass 
man das Sharp-Protokoll nehmen muss, wenn IRMP zuvor das Denon-Protokoll 
erkannt hat?

> Ich besitze genau eine Denon-FB, die sich per Schiebeschalter auf
> verschiedene Geräte umstellen lässt und genau eine Sharp. Über die
> Feiertage werde ich mal ein paar Scans aufzeihnen.

Das ist gut. Vielleicht kann man das besser an der Anzahl der Frames 
erkennen, die pro Taste geschickt werden. Mein Denon-Scan enthielt da 
immer 2 Frames pro Taste, die Sharp-FB schickte immer 3 Frames, nämlich:

Denon:

1. Frame: Adresse + Kommando
2. Frame: Adresse + invertiertes Kommando

Sharp:

1. Frame: Adresse + Kommando
2. Frame: Adresse + invertiertes Kommando
3. Frame: Adresse + Kommando

Deshalb bitte beim Einscannen drauf achten, die Tasten möglichst kurz zu 
drücken.

Gruß,

Frank

von Stefan P. (form)


Lesenswert?

Ich habe mein auf IRMP & IRSND basierendes Projekt nun auch mal im 
IRMP-Wikiartikel eingefügt:
http://forum.mikrokopter.de/topic-21060.html

Vielen Dank nochmal an Frank für Deine großartigen Routinen.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Stefan P. schrieb:
> Ich habe mein auf IRMP & IRSND basierendes Projekt nun auch mal im
> IRMP-Wikiartikel eingefügt:
> http://forum.mikrokopter.de/topic-21060.html

Schön! Am witzigsten fand ich es übrigens, mit der Servo-Fernbedienung 
den Fernseher lauter/leiser zu drehen...
Das Youtube-Video dazu wäre doch ein prima Link ;-)

von Stefan G. (dreamer83)


Angehängte Dateien:

Lesenswert?

Hallo,

bin derzeit dabei einen Umsetzer von ner Opel Lenkradfernbedienung auf 
mein Sony Autoradio (Infrarot) mit nem AVR-Mega8 zu machen.
Ich habe vorerst nen kleines Prog geschrieben, was die IR-Codes leicht 
zeitverzögert wieder sendet. Getestet wurde dass ganze zuerst mit meinem 
TV der das NEC-Protokoll verwendet, was problemlos funktioniert.
Jedoch jeder Versuch ein erfolgreiches SIRCS Protokoll zu versenden ist 
bisher gescheitert. Das Protokoll wird anscheinend jedoch richtig 
erkannt. So wird mir über den UART bei jedm Tastendruck 1-2 Codes 
ausgegeben die als Command im Bereich von 0x4200 bis 0x4247 liegen.

Leider habe ich kein Speicheroszi um mir die Angelegenheit da mal 
anzusehen.

Wo könnte mein Problem sein?

Gruß Stefan

von Michael H. (michael_h45)


Lesenswert?

Stefan Grimm schrieb:
> Leider habe ich kein Speicheroszi um mir die Angelegenheit da mal
> anzusehen.
Beitrag "Re: IR Signal - Welches Protokoll?"
Soundkarte reicht.

von Stefan G. (dreamer83)


Angehängte Dateien:

Lesenswert?

Danke für den Tip, auch wenn ich mit den Spannungen an der Soundkarte 
vorsichtig sein würde.

Habe mal einen "Scan" der Taste "Hoch +" gemacht. Das vom IR-Empfänger 
registrierte Signal ist in der Datei "RX.wav" gespeichert das vom 
Controler gesendete in "TX.wav". Im Log ist der Pegel vom Senden 
aufgrund meiner Beschaltung noch invertiert.
Der nach Irmp ausgewertete Code soll SIRCS mit Adresse 0 und den 
Commands 0x4233  gefolgt von 0x4245 sein.

Gruß Stefan

von Stefan G. (dreamer83)


Angehängte Dateien:

Lesenswert?

Hier nochmal ne grobe Übersicht über die beiden Logs.

Die Signale stehen zueinander in keinem zeitlichen Verältniss.

Gruß Stefan

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Stefan,

Stefan Grimm schrieb:

> Habe mal einen "Scan" der Taste "Hoch +" gemacht. Das vom IR-Empfänger
> registrierte Signal ist in der Datei "RX.wav" gespeichert das vom
> Controler gesendete in "TX.wav".

Besser wäre es, wenn Du mal einen Scan per IRMP machst - einmal mit kurz 
und einmal mit lang gedrückten Tasten - mindestens zwei.

Wenn die mit IRSND gesandten Daten vom Radio nicht dekodiert werden 
können, kann das folgende Gründe haben:

1. Schlechtes Timing:

   Quarz am µC verwenden! Die Dekodierer in den industriellen Geräten
   sind nicht so timing-tolerant wie IRMP.

2. Falsche Modulationsfrquenz:

   Eventuell benutzt die Original-FB zum Radio eine abweichende
   Modulationsfrequenz

3. Leichte Abweichungen vom SIRCs-Protokoll

   Zum Beispiel kann dies der Fall sein bei der Anzahl der
   Wiederholungsframes, die gesandt werden müssen, bevor das Gerät
   einen Befehl als gültig erkennt.

4. Bug in IRSND

   Wovon ich aber nicht ausgehe ;-)

Kann denn IRMP das per IRSND gesandte Signal wieder dekodieren?
Welche Interruptfrequenz benutzt Du (sowohl beim IRMP als beim IRSND)?

Wie gesagt: eine per IRMP erstellte Scan-Datei (analog zu IR-Data/*.txt) 
würde hier weiterhelfen.

Gruß,

Frank

von Stefan G. (dreamer83)


Lesenswert?

Ok Danke schon mal für die Tipps.

Ich werde heute Abend mal einen Scan machen.

Ich verwende momentan die Standartvorgaben der aktuellen IRSND & IRMP.

Werde mal ne 2.Version meiner Schaltung zum "Rescan" aufbauen.

Gruß Stefan

von Stefan G. (dreamer83)


Angehängte Dateien:

Lesenswert?

Abend,

hab hier mal den Log aller Tasten der Fernbedienung.

In der IRMP verwende ich 10000 Interrupts, genauso wie in der IRSND.

habe irgendwie das Gefühl, das beim senden durch die recht großen 
Commandos irgendwas schief geht, denn es ist nicht wirklich möglich 
Zahlen wie 0x4247 in 3 Nibble beim senden unterzubringen.
1
case IRMP_SIRCS_PROTOCOL:
2
  { command = bitsrevervse (irmp_data_p->command, SIRCS_MINIMUM_DATA_LEN);
3
    irsnd_buffer[0] = (command & 0x0FF0) >>  4;   // CCCCCCCC
4
    irsnd_buffer[1] = (command & 0x000F) << 4;    // CCCC0000
5
6
    irsnd_busy      = TRUE;
7
    break;
8
  }

wenn in der oberen Zeile die Daten gespielgelt werden müsste die 
Nachricht dann ja 0xEC42 lauten. nur wie sollen die nun in den 
Sendbuffer geschrieben werden?, müsste dann 0xEC in den Buffer[0] und 
der Rest in Buffer[1] ?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Stefan Grimm schrieb:

> habe irgendwie das Gefühl, das beim senden durch die recht großen
> Commandos irgendwas schief geht, denn es ist nicht wirklich möglich
> Zahlen wie 0x4247 in 3 Nibble beim senden unterzubringen.

Ja, das ist der Knackpunkt. Das SIRCS-Telegramm besteht laut

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

aus mindestens 12 Bits (3 Nibbles), maximal jedoch aus 20 Bits. Die 
Bitlänge ist also variabel. IRSND unterstützt momentan nur die 
12-Bit-Variante.

Ich werde mir Deine Scans mal näher ansehen und muss dann überlegen, wie 
man dem IRSND die Bitlänge beibringt.

Gruß,

Frank

von Stefan G. (dreamer83)


Lesenswert?

Hab hier nen kleinen Erfolg zu verbuchen. Habe es hinbekommen, dass die 
jeweiligen Kommandos zumindest korrekt gesendet werden, auch wenn die 
Anpassung nicht unbedingt schön ist.

In der "irsnd_ISR (void)" habe ich die Mindestanzah an Bits per #define 
variabel erhöht.
1
  complete_data_len = SIRCS_MINIMUM_DATA_LEN+SIRCS_ADDITIONAL_NUM_OF_BITS;

sowie in der "irsnd_send_data"
1
case IRMP_SIRCS_PROTOCOL:
2
{
3
//command = bitsrevervse (irmp_data_p->command, SIRCS_MINIMUM_DATA_LEN);
4
  command = bitsrevervse (irmp_data_p->command, SIRCS_MINIMUM_DATA_LEN+SIRCS_ADDITIONAL_NUM_OF_BITS);
5
6
//  irsnd_buffer[0] = (command & 0x0FF0) >> 4;     // CCCCCCCC
7
//  irsnd_buffer[1] = (command & 0x000F) << 4;     // CCCC0000
8
    irsnd_buffer[0] = (command & 0x7F10) >> 7;     
9
    irsnd_buffer[1] = (command & 0x007f) << 1;     // Anpassung auf 15 Bit
10
    irsnd_busy      = TRUE;
11
    break;
12
}
Somit funktioniert in meinem Fall das Senden von Befehlen. Es sind Codes 
von 0x4200 bis 0x4247 in Verwendung.

Hoffe dennoch das euch die Codes etwas bringen.

Gruß Stefan

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Stefan Grimm schrieb:
> Hab hier nen kleinen Erfolg zu verbuchen.

Freut mich!

> Habe es hinbekommen, dass die
> jeweiligen Kommandos zumindest korrekt gesendet werden, auch wenn die
> Anpassung nicht unbedingt schön ist.

Ich werde es in eine allgemeine Form bringen, Vorschlag dazu siehe 
unten.

> In der "irsnd_ISR (void)" habe ich die Mindestanzah an Bits per #define
> variabel erhöht.
>
1
  complete_data_len =
2
> SIRCS_MINIMUM_DATA_LEN+SIRCS_ADDITIONAL_NUM_OF_BITS;

Ich nehme an, dass bei Dir SIRCS_ADDITIONAL_NUM_OF_BITS den Wert 3 hat?

> sowie in der "irsnd_send_data"
>
1
>     irsnd_buffer[0] = (command & 0x7F10) >> 7;
2
>     irsnd_buffer[1] = (command & 0x007f) << 1;     // Anpassung auf 15
3
>

Okay, das muss ich dann variabel gestalten für 
SIRCS_ADDITIONAL_NUM_OF_BITS von 0 bis 8.

Ich habe mir eine allgemeine Erweiterung folgendermaßen vorgestellt:

1. Erweiterung von IRMP_DATA um: uint8_t additional_bitlen

2. IRMP füllt beim Empfang eines Frames diese Variable mit der Anzahl
   der zusätzlich empfangenen Bits. In der Regel ist der Wert also 0,
   in Stefans Fall dann aber 3.

3. IRSND wertet im Falle von SIRCS diese neue Variable aus, um damit
   die Länge des Frames zu erhöhen.

Meinungen dazu?

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Mir ist noch eine Alternative dazu eingefallen:

Ich baue die Information der zusätzlichen Bitlänge in irmp_data.address 
mit ein. Dann kann man auf die neue Variable irmp_data.additional_bitlen 
verzichten.

Gruß,

Frank

von Stefan G. (dreamer83)


Lesenswert?

Genau SIRCS_ADDITIONAL_NUM_OF_BITS ist bei mir 3.

Keine schlechte Idee mit dem Adressfeld.

Das mit dem ganzen Schieben variabel zu machen ist nicht unbedingt ganz 
so angenehm, aber lässt sich sichrlich machen.

Gruß Stefan

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Stefan Grimm schrieb:

> Keine schlechte Idee mit dem Adressfeld.

Ja, dieser Weg scheint mir auch vernünftiger zu sein. Ein paar Anwender 
werden dann aber bei SIRCs u.U. plötzlich andere Adresswerte bekommen 
als bisher. Ich habe dazu mal die gesammelten Scans unter 
IR-Data/Sony*.txt angeschaut: Die meisten haben 12, einige 15 und einer 
sogar 20 Bits.

Bei den 12er-Frames wird die Adresse gleich bleiben, bei den anderen 
zukünftig abweichen. Aber das ist hinnehmbar.

> Das mit dem ganzen Schieben variabel zu machen ist nicht unbedingt ganz
> so angenehm, aber lässt sich sichrlich machen.

Ist nicht so schwer.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Im SVN ist eine neue Version von IRMP und IRSND.

Die Änderungen betreffen nur das SIRCs-Protokoll:

IRMP speichert nun die Anzahl der zusätzlichen Bits gegenüber einem 
Standard-SIRCs-Frame der Länge 12 im oberen Byte des Adressfeldes. Bei 
Frames mit Standard-Länge bleibt die Adresse 0x0000.

@Stefan Grimm: Damit sollte bei Dir nun die Adresse 0x0300 sein, da bei 
Deiner Fernbedienung 3 zusätzliche Bits gesandt werden.

IRSND wertet nun die Längeninformation im Adressfeld aus und passt 
dadurch Länge und Frame-Daten dynamisch an.

@Stefan Grimm: Kannst Du das mal testen? Bei mir habe ich es lediglich 
unter Linux per Pipe von IRSND-Daten in den IRMP testen können. IRMP 
konnte alle von IRSND generierten Frames mit SIRCs-Frame-Längen (12, 15 
und 20) einwandfrei dekodieren.

Gruß,

Frank

von Sebastian .. (zahlenfreak)


Lesenswert?

Hallo Frank,

erstmal vielen dank für das super Projekt. Hat mir sehr geholfen.

Kannst du (zumindest ungefähre) Angaben zum RAM/Stack-Verbrauch von IRMP 
machen? Bei mir ist der RAM grad sehr knapp und ich hab auch Probleme, 
die auf den Stack hinweisen, aber ich kann in meinem Teil der Software 
nicht wirklich was finden. Und wenns geht wollte ichs vermeiden, IRMP 
selbst analysieren zu müssen ;-)

Gruß, Sebastian

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Sebastian ... schrieb:

> Kannst du (zumindest ungefähre) Angaben zum RAM/Stack-Verbrauch von IRMP
> machen?

An RAM werden ungefähr 60 Bytes verbraten, das sind allesamt static 
Variablen. Der Stack dürfte ähnlich ausfallen, da nur wenige lokale 
Variablen innerhalb der Funktion benötigt werden. Es hängt aber auch 
davon ab, wieviele/welche Protokolle Du freischaltest.

> Bei mir ist der RAM grad sehr knapp und ich hab auch Probleme,
> die auf den Stack hinweisen, aber ich kann in meinem Teil der Software
> nicht wirklich was finden.

Dann poste Deinen Source doch mal. Und gib mal die Größe der 
Data-Section an, die beim Übersetzen ausgegeben werden. Welchen µC 
verwendest Du?

Typische RAM-Probleme bereiten zum Beispiel Arrays oder Strukturen, die 
bereits im Source mit Konstanten gefüllt werden. Diese werden beim Boot 
des µC vom Flash ins RAM kopiert, wenn Du diese Daten nicht über PROGMEM 
deklarierst.

Gruß,

Frank

von Sebastian .. (zahlenfreak)


Lesenswert?

Vielen Dank. 60Byte static plus ca. 60 Byte stack dürfte das ganze schon 
erklären.
Danke für das Hilfsangebot, aber denke damit sollte ichs auch allein 
hinkriegen (ist dann auch ein stück weit Programmiererstolz ;) ). Hab 
ein paar größere Arrays im RAM. Mal schaun, ob ich irgendwo noch bischen 
was einsparen kann. Sonst gibts halt den nächstgrößeren Controller (hab 
grad nen Mega8).

Sebastian

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Sebastian ... schrieb:
> Vielen Dank. 60Byte static plus ca. 60 Byte stack dürfte das ganze schon
> erklären.

Naja, Stack sollte weniger sein.

> Danke für das Hilfsangebot, aber denke damit sollte ichs auch allein
> hinkriegen (ist dann auch ein stück weit Programmiererstolz ;) ). Hab
> ein paar größere Arrays im RAM.

Ändern sich die Werte in den Arrays? Wenn nicht, packe sie ins Flash. 
Wenn doch, aber nur selten, packe sie ins EEPROM.

> Mal schaun, ob ich irgendwo noch bischen
> was einsparen kann. Sonst gibts halt den nächstgrößeren Controller (hab
> grad nen Mega8).

Mega8 ist obsolet, wechsle besser auf den pinkompatiblen Mega88 oder auf 
den Mega168 mit doppelt soviel Speicher. Dann sollten Deine Probleme der 
Vergangenheit angehören.

Gruß,

Frank

von Sebastian .. (zahlenfreak)


Lesenswert?

Der Mega8 lag halt noch rum. Irgendwann müssen die ja auch mal wegkommen 
^^

Ein Teil der Arrays sind nur Kopien ihrer EEPROM-Version und werden fast 
nur gelesen und sehr selten geschrieben. Ich habs auch schon probiert, 
einfach live aus dem EEPROM zu lesen. Wie erwatet waren die Probleme 
weg. Nur hab ich das ganze in der Bedienung unangenehm gemerkt...

Wie gesagt: Wenn mir nichts vernünftiges für die Software einfällt gibts 
den nächst größeren Controller. Ich wollte halt gerne wissen, ob das 
wirklich ein RAM-problem sein könnte, oder ob ich irgendwas anderes auch 
noch falsch gemacht habe.

Gruß, Sebastian

von eku (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Frank,

anbei die versprochenen Aufzeichnungen von Denon und Sharp bei 10kHz 
Abtastrate. Ich hoffe, die unterscheiden sich soweit, dass IRMP die 
Protokolle auseinanderhalten kann.

Gruß, eku

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo eku,

eku schrieb:

> anbei die versprochenen Aufzeichnungen von Denon und Sharp bei 10kHz
> Abtastrate. Ich hoffe, die unterscheiden sich soweit, dass IRMP die
> Protokolle auseinanderhalten kann.

Erstmal danke für die Erstellung der Scans.

denon2_kurz_10khz.txt kann ich leider nicht verwenden, irmp erkennt das 
Zeugs nicht. Da scheint jeder Frame aus nur 3 Bits zu bestehen.

Auswerten konnte ich also nur denon1, denon3 und sharp.

Leider unterscheiden sie sich nur minimal. Damit kann man definitiv 
keine Unterscheidung hinbekommen. Beide senden 3 Frames, wo die Pausen 
dazwischen fast identisch sind. Die Abweichungen liegen im einstelligen 
Prozentbereich. Da könnte man lediglich über statistische Auswertungen 
eine Unterscheidung hinbekommen.

Du hattest ja gesagt, dass das Sharp-Gerät nicht auf die 
Original-Denon-Timings reagiert. Wie sieht es denn umgekehrt aus? Kommt 
das Denon-Gerät mit den Sharp-Timings zurecht?

Es gäbe ja noch die Möglichkeit, im IRSND mit einem Kompromiss im Timing 
zu arbeiten, so dass sowohl Denon als auch Sharp die von IRSND 
ausgesandten Frames verstehen. Idee ist also, die etwas verschiedenen 
Timingwerte durch entsprechende Versuche soweit anzunähern, dass beide 
Geräte damit zurechtkommen.

Könntest Du mal so eine Versuchsreihe starten? Ich kann es leider nicht, 
denn ich habe weder ein Gerät von Denon noch eins von Sharp.

irmp mit der Option -a verrät über die Timings Deiner Scans:

           Sharp       Denon1     Denon3
Puls       320 µs      300 µs     300 µs
Pause0     735 µs      745 µs     745 µs
Pause1    1781 µs     1783 µs    1783 µs

Ich kenne eigentlich nur zwei Quellen über das Denon-Protokoll, nämlich

   http://www.mikrocontroller.com/de/IR-Protokolle.php#DENON
   http://www.mikrocontroller.net/attachment/4246/IR-Protokolle_Diplomarbeit.pdf

Vielleicht sind die dort angegebenen Werte

           Denon
Puls       275 µs
Pause0     775 µs
Pause1    1900 µs

einfach schlichtweg falsch (abgeschrieben) bzw. liegen viel zu weit 
neben der Realität?

Deine Denon-Fernbedienungen liegen jedenfalls viel näher an den 
Sharp-Timings als an den Timings aus der obigen Dokumentation!

Fazit:
======

Wie wäre es, wenn Du in irmp.h einstellst:
1
#define DENON_PULSE_TIME         310.0e-6  //  310 usec pulse
2
#define DENON_1_PAUSE_TIME      1780.0e-6  // 1780 usec pause
3
#define DENON_0_PAUSE_TIME       745.0e-6  //  745 usec pause

und dann nochmal zunächst IRMP testest mit beiden FBs und anschließend 
diese Timings auch für IRSND testest mit Deinem Denon- und Sharp-Gerät?

Ich glaube fest daran, dass beide Geräte die obigen Timings schlucken 
;-)

Wenn ja, werde ich die obigen Werte ab sofort im Source verwenden.

Gruß,

Frank

von eku (Gast)


Lesenswert?

Frank M. schrieb:
> Ich kenne eigentlich nur zwei Quellen über das Denon-Protokoll, nämlich
[...]
> Vielleicht sind die dort angegebenen Werte
>
>            Denon
> Puls       275 µs
> Pause0     775 µs
> Pause1    1900 µs
>
> einfach schlichtweg falsch (abgeschrieben) bzw. liegen viel zu weit
> neben der Realität?

http://lirc.sourceforge.net/remotes/denon/
http://www.hifi-remote.com/johnsfine/DecodeIR.html

> Wie wäre es, wenn Du in irmp.h einstellst:

Probiere ich aus.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:

> http://lirc.sourceforge.net/remotes/denon/

Zumindest die Werte der ersten 5 FBs in diesem Verzeichnis bekräftigen 
meinen Eindruck, dass in der Realität die Denon-Timings eher denen der 
Sharp-FB entsprechen und nicht den Werten in meinen herangezogenen 
Dokumenten.

> Probiere ich aus.

Bin gespannt.

Gruß,

Franak

von Colt F. (Firma: TUC) (coltfish)


Lesenswert?

Hallo,

möchte nur kurz allen, die Ihre Energie in dieses Projekt gesteckt haben 
(besonders natürlich Frank M.) einen herzlichen Dank aussprechen.
Tolle Arbeit, ich ziehe meine Hut!

Habe mir eben in kürzester Zeit den IR-Decoder für ein Projekt mit 
16Bit-PIC portieren können, die Performance ist super.

Gruß
Daniel

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Colt Fish schrieb:

> möchte nur kurz allen, die Ihre Energie in dieses Projekt gesteckt haben
> (besonders natürlich Frank M.) einen herzlichen Dank aussprechen.
> Tolle Arbeit, ich ziehe meine Hut!

Danke fürs Danke :-)

> Habe mir eben in kürzester Zeit den IR-Decoder für ein Projekt mit
> 16Bit-PIC portieren können, die Performance ist super.

Waren dafür Anpassungen im IRMP-Source nötig, die sich lohnen, in den 
Standard-Source mit einfließen zu lassen?

Gruß,

Frank

von Colt F. (Firma: TUC) (coltfish)


Lesenswert?

Frank M. schrieb:
> Waren dafür Anpassungen im IRMP-Source nötig, die sich lohnen, in den
> Standard-Source mit einfließen zu lassen?

Nicht wirklich. Ich habe nur die Datentypen umbenennen müssen. Der C30 
Compiler von Microchip ist ja ebenfalls ein gcc.
Und natürlich das Setup von Timer und Interrupts muss angepasst werden, 
welches allerdings stark vom verwendeten Chip abhängt.

Gruß
Daniel

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi eku,

eku schrieb:

> Probiere ich aus.

Ich habe gerade einen systematischen Bug im IRSND entdeckt: sämtliche 
gesendete Pausen waren bisher 1 Interrupt-Tick zu lang. Ich habe das 
gerade korrigiert und den Source im SVN eingecheckt.

Daher bitte vorher den Source aus dem SVN neu laden. Dort stehen jetzt 
auch die ermittelten Praxiswerte für das Denon-Timing drin.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Die letzten Änderungen im SVN seit September 2010 sind nun eingeflossen 
in eine neue IRMP- und IRSND-Version 1.9.0.

Änderungen IRMP seit 1.8.1:

  - Korrekturen für Siemens-Protokoll
  - Neues Protokoll: NIKON
  - Speichern der zusätzlichen Bits (>12) im SIRCS-Protokoll in der
    Adresse
  - Timing-Korrekturen für Denon-Protokoll

Download IRMP:

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

Änderungen IRSND seit 1.8.0:

  - Neues Protokoll: RC6A
  - Neues Protokoll: RC6
  - Neues Protokoll: NIKON
  - Beachten der zusätzlichen Bits (>12) im SIRCS-Protokoll
  - Korrektur der Pausenlängen
  - Timing-Korrekturen für Denon-Protokoll

Download IRSND:

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

Viel Spaß,

Frank

von eku (Gast)


Lesenswert?

Hallo Frank,

> Daher bitte vorher den Source aus dem SVN neu laden. Dort stehen jetzt
> auch die ermittelten Praxiswerte für das Denon-Timing drin.

wir sind auf dem richtigen Weg! Sharp und Denon-Geräte kann ich nun 
beide mit dem Denon-Protokoll steuern. Allerdings liegt die 
Erkennungsrate bei ca. 80%. Einige Codes muss ich mehrfach senden bevor 
sie erkannt werden.

In welche Richtung kann ich das Timing noch verändern? Mehr hin zum 
Sharp oder wieder zu den alten Denon Werten?

Gruß, eku

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo eku,

eku schrieb:
> Hallo Frank,
>
> wir sind auf dem richtigen Weg! Sharp und Denon-Geräte kann ich nun
> beide mit dem Denon-Protokoll steuern. Allerdings liegt die
> Erkennungsrate bei ca. 80%. Einige Codes muss ich mehrfach senden bevor
> sie erkannt werden.

Ist es bei beiden 80%?

> In welche Richtung kann ich das Timing noch verändern? Mehr hin zum
> Sharp oder wieder zu den alten Denon Werten?

Als erstes würde ich mal mit der Modulationsfrequenz spielen. In der 
Denon-Doku las ich immer was von 32kHz. Aber das glaube ich nicht so 
recht. Probiere mal 32kHz, 36kHz und 38kHz.

Wenn das nichts bringt, verschiebe die Timings mal zu den alten 
Denon-Werten.

Gruß,

Frank

von eku (Gast)


Lesenswert?

Hallo Frank,

mit den Timings der Revision 51 und 36kHz Modulationsfrequenz kann ich 
sowohl das Denon als ach das Sharp-Gerät fehlerfrei bedienen. Die 
Reaktion des Denons ist bei 32kHz und 38kHz schlechter. Der Sharp 
reagiert auf 32kHz garnicht und auf 38kHz unzuverlässig.

Ein kleinerSchönheitsfehler ist mir noch aufgefallen:

irmp/irsnd.c: In function 'ir_tx_put':
irmp/irsnd.c:337: warning: unused variable 'toggle_bit_rc6'

Diese Variable sollte nur für RC6 einkompiliert werden.


Nochmals vielen Dank für Deine Unterstützung. Ich werde den aktuellen 
Stand dann noch zu Ethersex portieren.

Gruß, eku

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo eku,

eku schrieb:

> mit den Timings der Revision 51 und 36kHz Modulationsfrequenz kann ich
> sowohl das Denon als ach das Sharp-Gerät fehlerfrei bedienen. Die
> Reaktion des Denons ist bei 32kHz und 38kHz schlechter. Der Sharp
> reagiert auf 32kHz garnicht und auf 38kHz unzuverlässig.

Vielen Dank für die wichtige Info. Ich werde also 36 kHz in irsnd.c 
eintragen und die Timings so lassen, wie sie aktuell sind. Sie 
entsprechen ja auch im Wesentlichen den von Dir gescannten Werten und 
passen auch zur lirc-DB.

> Ein kleinerSchönheitsfehler ist mir noch aufgefallen:
>
> irmp/irsnd.c: In function 'ir_tx_put':
> irmp/irsnd.c:337: warning: unused variable 'toggle_bit_rc6'
>
> Diese Variable sollte nur für RC6 einkompiliert werden.

Danke, das war ein Copy-And-Paste-Fehler, die RC5-Bedingung ist hier an 
dieser Stelle falsch.

Alt:
1
#if IRSND_SUPPORT_RC5_PROTOCOL == 1
2
    static uint8_t  toggle_bit_rc6;
3
#endif

Neu:
1
#if IRSND_SUPPORT_RC6_PROTOCOL == 1 || IRSND_SUPPORT_RC6A_PROTOCOL == 1
2
    static uint8_t  toggle_bit_rc6;
3
#endif

Werde ich ebenfalls korrigieren.

> Nochmals vielen Dank für Deine Unterstützung. Ich werde den aktuellen
> Stand dann noch zu Ethersex portieren.

Auch von mir vielen Dank für Deine wirklich hilfreichen Experimente.

Gruß,

Frank

von eku (Gast)


Lesenswert?

Pollin hat eine neue IR-Tastatur:  711 057

von eku (Gast)


Lesenswert?

eku schrieb:
> Ich werde den aktuellen Stand dann noch zu Ethersex portieren.

Ethersex' IRMP ist nun auch auf dem aktuellen Stand. Viel Spaß damit!

http://www.ethersex.de

von iffi (Gast)


Lesenswert?

Hallo Frank,

genau so etwas wie IRMP habe ich gesucht! :)  Für ein Uni-Projekt will 
ich Infrarot-Signale an einem MSP430 empfangen. Da es so viele 
unterschiedliche Protokolle gibt, stellte sich mir die Frage, welche 
Protokolle ich implementieren soll. Jetzt sehe ich, dass in IRMP schon 
die meisten implementiert und ausgiebig getestet sind.

Jetzt wird es eine Kleinigkeit sein, den Infrarot-Sensor in Gang zu 
bringen. Danke, dass du allen dein Projekt zur Verfügung stellst.

Viele Grüße

von Fred (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

ist ja ein tolles Projekt. Ich habe mir das Ganze mal auf einen ATMEGA8
16MHz angepasst und noch eine Ausgabe für die Serielle eingefügt.

So, dann gleich ein paar FB ausprobiert und es klappt recht gut. Nur 
eine FB mag so gar nicht. Mit der hatte ich aber auch schon früher 
Probleme.
Eine Universal FB konnte sie jedenfalls nicht nachbilden.

Es handelt sich um eine FB für den T-Home X301T Mediareceiver.
Hersteller ist ruwido und es ist bereits die zweite Generation.

Im Anhang ist eine Datei, da hab ich mal mit der Logfunktion alle Tasten 
der Reihenfolge nach betätigt.

Kann man da was erkennen?

Gruß Fred

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Fred schrieb:

> Es handelt sich um eine FB für den T-Home X301T Mediareceiver.
> Hersteller ist ruwido und es ist bereits die zweite Generation.
>
> Im Anhang ist eine Datei, da hab ich mal mit der Logfunktion alle Tasten
> der Reihenfolge nach betätigt.

Das scheint ein Manchester-Code mit RC5-Timings zu sein, aber die Anzahl 
der Bits ist von 13 (Original-RC5) auf 17 Bit aufgebohrt. Leider sind da 
noch ein paar Ungenauigkeiten drin, wo ich nicht weiß, ob das 
Aufzeichnungsfehler sind oder etwas anderes.

Ändere in irmp.h mal testweise:

Alt:
1
#define RC5_ADDRESS_OFFSET                      2                               // skip 2 bits (2nd start + 1 toggle)
2
#define RC5_ADDRESS_LEN                         5                               // read 5 address bits
3
#define RC5_COMMAND_OFFSET                      7                               // skip 5 bits (2nd start + 1 toggle + 5 address)
4
#define RC5_COMMAND_LEN                         6                               // read 6 command bits
5
#define RC5_COMPLETE_DATA_LEN                   13                              // complete length

Neu:
1
#define RC5_ADDRESS_OFFSET                      1                               // skip 1 bit
2
#define RC5_ADDRESS_LEN                         3                               // read 3 address bits
3
#define RC5_COMMAND_OFFSET                      4                               // skip 4 bits
4
#define RC5_COMMAND_LEN                         13                              // read 13 command bits
5
#define RC5_COMPLETE_DATA_LEN                   17                              // complete length

Dann ist die Erkennungsrate bei über 70 Prozent.

Aber wie gesagt: das ist nur ein Test, keine endgültige Lösung. Denn das 
RC5-Protokoll hat tatsächlich nur 13 Bits.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

iffi schrieb:

> genau so etwas wie IRMP habe ich gesucht! :)  Für ein Uni-Projekt will
> ich Infrarot-Signale an einem MSP430 empfangen.

Wenn Du IRMP auf MSP430 portiert hast, kannst Du mir gerne die 
Änderungen nennen (z.B. über #ifdef MSP430), damit ich die Anpassungen 
einpflegen kann.

> Jetzt wird es eine Kleinigkeit sein, den Infrarot-Sensor in Gang zu
> bringen. Danke, dass du allen dein Projekt zur Verfügung stellst.

Danke fürs Danke :-)

Gruß,

Frank

von ich (Gast)


Lesenswert?

Frank M. schrieb:
> Das scheint ein Manchester-Code mit RC5-Timings zu sein, aber die Anzahl
> der Bits ist von 13 (Original-RC5) auf 17 Bit aufgebohrt.

Ich habe mal versucht über die FB was rauszufinden. Das Protokoll nennt 
sich r-step und soll 23 bit und Manchestercodierung haben. Im Gegensatz 
zu RC5 jedoch invertiert. Die unter 
http://www.mikrocontroller.net/articles/MOTOROLA_VIP1710#Fernbedienung 
ist recht ähnlich.

Fred

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

ich schrieb:

> Ich habe mal versucht über die FB was rauszufinden. Das Protokoll nennt
> sich r-step und soll 23 bit und Manchestercodierung haben. Im Gegensatz
> zu RC5 jedoch invertiert.

Die Bitlänge ist definitiv 17 und nicht 23.

Wenn ich in irmp.c die Toleranz für RC5 von 10% auf 20% hochsetze:
1
#define RC5_START_BIT_LEN_MIN                   ((uint8_t)(F_INTERRUPTS * RC5_BIT_TIME * MIN_TOLERANCE_20 + 0.5) - 1)
2
#define RC5_START_BIT_LEN_MAX                   ((uint8_t)(F_INTERRUPTS * RC5_BIT_TIME * MAX_TOLERANCE_20 + 0.5) + 1)
3
#define RC5_BIT_LEN_MIN                         ((uint8_t)(F_INTERRUPTS * RC5_BIT_TIME * MIN_TOLERANCE_20 + 0.5) - 1)
4
#define RC5_BIT_LEN_MAX                         ((uint8_t)(F_INTERRUPTS * RC5_BIT_TIME * MAX_TOLERANCE_20 + 0.5) + 1)

habe ich sogar eine Erkennungsrate von 100%. Verwendest Du einen Quarz 
am µC?

Leider hast Du in der Scan-Datei keine Kommentare eingepflegt. Ich habe 
nämlich gesehen, dass von den 44 Tastendrücken, die Du aufgezeichnet 
hast, 14 identisch sind, es tatsächlich also nur 30 verschiedene Tasten 
waren.

Um nun herauszufinden, ob der Code tatsächlich invertiert ist oder 
nicht, bitte ich Dich, zumindest die Tasten 0-9 nochmal aufzuzeichnen 
und mit einer Kommentarzeile vor jeder Scan-Zeile zu versehen, siehe 
dazu auch die anderen Scan-Dateien im Unterverzeichnis IR-Data.

Gruß,

Frank

von Fred (Gast)


Lesenswert?

Frank M. schrieb:
> habe ich sogar eine Erkennungsrate von 100%. Verwendest Du einen Quarz
> am µC?

ja, einen 16MHz.

Die Info mit den 23 Bit stammt nicht von mir. Da bin ich mir aber auch 
nicht sicher, was da mit dazugerechnet wurde.

Den Scan werde ich noch mal durchführen. Es sollten eigentlich 45 
verschiedene Codes in der alten Scandatei sein.

Bewirkt die Invertierung der Manchestercodierung irgendwas?

Mach mich gleich an die Arbeit, wenn ich wieder daheim bin.


Fred

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Fred schrieb:

> ja, einen 16MHz.

Dann ist die Fernbedienung so "wackelig" ;-)

> Den Scan werde ich noch mal durchführen. Es sollten eigentlich 45
> verschiedene Codes in der alten Scandatei sein.

Leider nicht. Die Datei hat 44 Zeilen, aber 14 Codes sind doppelt.

> Bewirkt die Invertierung der Manchestercodierung irgendwas?

Nein, nur dass die Codes invertiert sind und dann "riesengroße" Zahlen 
ergeben. Ich glaube nicht, dass die tatsächlich zu invertieren sind. Das 
wird man aber besser sehen, wenn die Zeilen kommentiert sind, denn meist 
geben die Tasten 0 bis 9 einen fortlaufenden Code ab.

> Mach mich gleich an die Arbeit, wenn ich wieder daheim bin.

Prima.

Gruß,

Frank

von Martin (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

erstmal vielen Dank dafür das es Leute gibt die Ihre Projekte anderen 
zugänglich machen :)

Hab gerade das erste Mal mit IRMP rumgespielt und bin begeistert. Hab 
aber auch eine Fernbedienung gefunden die nicht funktionieren will.

Die Fernbedienung gehört zu einem IMON-Display (für den PC).

Hab mal n Paar tasten gedrückt und das File angehängt :)
Ist das Normal das die einzelnen Befehle sich so stark in der Länge 
unterscheiden?
Kann jemand erkennen was das für n Protokoll is?

Danke :)

von Bastian F. (bastian_f)


Lesenswert?

@Fred: Kannst du mir bitte mal deine portierte Version für den Atmega8 
zukommen lassen?
Danke,
Basti

bastian.felten[ät]gmail[dot]com

von Bastian F. (bastian_f)


Lesenswert?

Schon wieder ich...
Ich habe einen TSOP1838 an PB6 eines mit 8 MHz getakteten Atmega88 
angeschlossen, der in einem STK500 steckt.
RX/TX hängen an PD0/PD1 und in der irmpconfig.h wurde das logging 
aktiviert.
HTerm zeigt mir jedoch bei keiner einzigen Fernbedienung irgendeinen 
Ausgabe.

Muss man sonst noch etwas einstellen, oder was könnte das Problem sein?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Bastian F. schrieb:
> HTerm zeigt mir jedoch bei keiner einzigen Fernbedienung irgendeinen
> Ausgabe.

Zeig mal Deine irmpconfig.h und deine main-Funktion.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Martin schrieb:

> Die Fernbedienung gehört zu einem IMON-Display (für den PC).
>
> Hab mal n Paar tasten gedrückt und das File angehängt :)

Habe das mal durch "irmp -a" gejagt. Scheint tatsächlich ein neues 
Protokoll zu sein, was aber relativ einfach zu decodieren ist.

> Ist das Normal das die einzelnen Befehle sich so stark in der Länge
> unterscheiden?

Sieht so aus, als ob das einfach Schrott ist. Kann es sein, dass da eine 
Neonröhre oder ähnliches in der Nähe leuchtete?

> Kann jemand erkennen was das für n Protokoll is?

Eines, welches IRMP noch nicht beherrscht. Ich baue es ein und melde 
mich danach nochmal mit einer Lösung.

Gruß,

Frank

von Bastian F. (bastian_f)


Lesenswert?

Frank M. schrieb:
> Zeig mal Deine irmpconfig.h und deine main-Funktion.

Ich befürchte, dass ich das ganze noch nicht wirklich verstanden habe.
Die main Funktion habe ich nämlich nicht verändert und wenn ich mir die 
anschaue, wird dort nirgends das Logging bzw die entsprechende Ausgabe 
aufgerufen wird.
Bin davon ausgegangen, dass das einfach durch das Setzen der "1" 
passiert.
Was muss ich denn eintragen, dass ich eine Ausgabe bekomme?

von Stefan G. (dreamer83)


Lesenswert?

Hi,

seh dir einfach mal das Projekt hier ganz oben auf der Seite an. In der 
main.c ist ein funktionierendes Beispiel zur Ausgabe des "normalen" 
Codes.

Gruß Stefan

von Fred (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

hat ne Weile gedauert aber ich kam nicht früher heim :-(

So, im Anhang nun die Scans der Tasten 1-0. Ich habe die Tasten
jeweils mehrmals betätigt und dazu auch immer eine ganze Zeile
erhalten. Ich hoffe, das ist so brauchbar.

Für die Atmega8 Version brauchte ich nicht viel anpassen. Im Projekt
den entsprechenden Controller und Takt einstellen und in der 
irmpconfig.h
noch den entsprechenden Port wählen.

Fred

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Fred schrieb:
> So, im Anhang nun die Scans der Tasten 1-0. Ich habe die Tasten
> jeweils mehrmals betätigt und dazu auch immer eine ganze Zeile
> erhalten. Ich hoffe, das ist so brauchbar.

Ja, der Scan ist sehr gut brauchbar. Was mir auffällt, dass der "Jitter" 
wesentlich geringer ist. Die Puls-/Pause-Zeiten in r-step.txt sind 
wesentlich exakter als die in t-home.txt.

Hast Du da eine andere Fernbedienung oder eine andere Empfängerschaltung 
(z.B. mit/ohne Quartz) verwendet?

Was mir noch auffiel: Kommen hier beim Manchester-Protokoll zwei Pulse 
oder Pausen direkt hintereinander, weichen sie etwas von der doppelten 
Dauer, die man erwarten müsste, ab. Ich musste dafür den 
Manchester-Decoder im IRMP etwas "aufbohren", um so ein asymmetrisches 
Verhalten besser abbilden zu können.

Ausserdem sind die Bits hier tatsächlich "negiert", d.h. bei einer 1 
kommt erst der Puls, dann die Pause. Damit erhöht sich die Anzahl der 
Bits im Frame von 17 auf 18. Das letzte Bit ist ein Parity-Bit, was von 
IRMP nicht ausgewertet wird.

Hier das Ergebnis, gekürzt um die Wiederholungen:

#1 000110010100000010 p = 23, a = 0x0065, c = 0x0001, f = 0x00
#2 000110010100000101 p = 23, a = 0x0065, c = 0x0002, f = 0x00
#3 000110010100000110 p = 23, a = 0x0065, c = 0x0003, f = 0x00
#4 000110010100001001 p = 23, a = 0x0065, c = 0x0004, f = 0x00
#5 000110010100001010 p = 23, a = 0x0065, c = 0x0005, f = 0x00
#6 000110010100001101 p = 23, a = 0x0065, c = 0x0006, f = 0x00
#7 000110010100001110 p = 23, a = 0x0065, c = 0x0007, f = 0x00
#8 000110010100010001 p = 23, a = 0x0065, c = 0x0008, f = 0x00
#9 000110010100010010 p = 23, a = 0x0065, c = 0x0009, f = 0x00
#0 000110010100010101 p = 23, a = 0x0065, c = 0x000a, f = 0x00

Die Adresse ist also 0x65, der Code geht von 0x01 bis 0x0a. Das passt 
sehr gut.

Bevor ich den Code veröffentliche, möchte ich obige erste Frage 
beantwortet haben. Denn der Ruwiodo-Decoder versteht zwar jetzt 
r-step.txt ganz gut, jedoch nicht mehr t-home.txt, welches zu nahe an 
den RC5-Timings ist.

Gruß,

Frank

von Martin (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Frank,

ich hab eben nochmal auf der Fernbedienung rumgedrückt - und siehe da: 
alle Befehle gleich lang.
Keine Ahnung was da gestört hatte. Neonröhre hab ich hier nicht. Alles 
was zu dem Zeitpunkt geleuchtet hatte war mein Display :)

Hab dir die neue Datei nochmal angehängt. Vielleicht erleichtert dir das 
ja dann die Arbeit (kenn mich damit ja nich so aus ;)).

Ach... Nochmals danke für deine Arbeit! :)


Martin

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Martin,

Martin schrieb:
> Hab dir die neue Datei nochmal angehängt. Vielleicht erleichtert dir das
> ja dann die Arbeit (kenn mich damit ja nich so aus ;)).

Danke. Mittlerweile bin ich mit der imon.txt durch. Es handelt sich um 
kein Fernbedienungsprotokoll im klassischen Sinne. Es ist weder 
Manchester-codiert noch ist ein Pulse-Distance Protokoll. Es ist viel 
einfacher, nämlich einfach bitseriell mit 38 Bits, wenn ich mich nicht 
verzählt habe.

Das kann IRMP nicht. Einfacher wäre es, einen Software-Uart (i.d.R. 8 
Bit) auf 38 Bit umzuschreiben. ;-)

Naja, ich schaue mir nochmal imon2.txt an. Dann entscheide ich, ob ich 
das in IRMP einbaue oder nicht.

Gruß,

Frank

von herby (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Frank M.,

erstmal vielen Dank für Deine tolle Arbeit.
Ich habe hier auch eine imon-Fernbedienung mit dem Namen "Veris RM200".
Sie gehört zu einem PC-Gehäuse von Antec.
Allerding werden hier im Gegensatz zu Martin´s Protokoll je Tastendruck
zwei Pakete gesendet.
Es wäre schön wenn das Protokoll in deine Software integriert werden 
könnte.

Schonmal vielen Dank

von Fred (Gast)


Lesenswert?

Frank M. schrieb:
> Hast Du da eine andere Fernbedienung oder eine andere Empfängerschaltung
> (z.B. mit/ohne Quartz) verwendet?

Hallo,

ich vermute, beim ersten Scan war der Quarz noch nicht aktiv,
Da ich die Fuses erst danach geändert habe.

Zusätzlich liegt die Samplerate jetzt bei 24000.

Soll ich das mal mit weniger oder eben einer anderen Rate noch mal 
scannen?

Vielleicht hat ja noch jemand die FB zum MOTOROLA VIP1710, die sollte ja 
so ähnlich sein.

Fred

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Fred schrieb:

> ich vermute, beim ersten Scan war der Quarz noch nicht aktiv,
> Da ich die Fuses erst danach geändert habe.

Ahja, das erklärt das Verhalten. Da die Timings sehr nahe bei RC5 
liegen, kann ich hier auch nur die Verwendung eines Quarzes empfehlen.

> Zusätzlich liegt die Samplerate jetzt bei 24000.
>
> Soll ich das mal mit weniger oder eben einer anderen Rate noch mal
> scannen?

24000 ist zuviel, da läuft der Log-Buffer im IRMP über. Wenn Du nochmal 
Lust hast, kannst Du das gern mit 15000 wiederholen. Dann bekomme ich 
auf jeden Fall genauere Werte.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

@Fred:

Ich habe die Unterstützung der T-Home Mediareceiver-FB (neues Protokoll 
"RUWIDO") ins SVN eingecheckt. Du kannst ja mal testen, ob damit die FB 
sauber erkannt wird. Du musst aber in irmpconfig.h das RUWIDO-Protokoll 
noch freischalten. Standardmäßig ist es abgeschaltet.

Gruß,

Frank

von Klaus L. (kllei)


Lesenswert?

Hallo, melde mich auch mal wieder im IRMP Projekt zurück ;-)

Gibt es schon praktische Erfahrung mit RC6(a) in irsnd? Ich habe das 
gerade in Ethersex probiert, da wackelt der Pin garnicht. Hat es jemand 
schon mal "nativ" probiert? (RC5, NEC, SIRCS und andere funktionieren 
da)

Hab leider meine IRMP Testumgebung vollkommen zerlegt...

Danke für einen Input.

Grüße,
Klaus

von Klaus L. (kllei)


Lesenswert?

So, die Frage hätte ich mir sparen können ;-)
Test war einfacher aufzubauen als gedacht, irsnd schickt alles und irmp 
erkennt den Code. Wie zu erwarten.

Hat jemand Ethersex am laufen mit irsnd und könnte RC6 mal testen?

Grüße,
Klaus

von Klaus L. (kllei)


Lesenswert?

So, in Ethersex fehlt der Teil der RC6 sendet in der Datei irsnd_lib.c
Werde ich dann mal einbauen.
Sorry für das kleine Selbstgespräch ;-)

Klaus

von Bastian F. (bastian_f)


Lesenswert?

Wie genau kann man denn nun loggen?
Wie gesagt, habe ich nur das Logging aktiviert und sonst nichts am 
Programm geändert. Und das scheint ja schonmal falsch zu sein.
Wird wohl nur der Aufruf einer Funktion oä sein, aber ich verstehe es 
leider nicht, bzw kann diese Funktion nicht finden.
Wäre nett, wenn sich jemand erbarmen würde und mir dies erklären könnte.
Im ersten Entwurf "hier ganz oben auf der Seite" habe ich dahingehend 
auch nichts finden können.
Danke!

von Fred (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

ich habe nun die Version aus dem SVN neu gezogen und die beiden 
Logdateien
erzeugt. Ein mal mit Abtastrate 10000 und 15000.

Es ist mit dieser Version nicht mehr möglich auf 20000 zu gehen.
Dies wäre aber mit RC80 usw. nötig.

Leider funktioniert die Erkennung von ruwido noch nicht richtig.

Fred

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Fred schrieb:

> ich habe nun die Version aus dem SVN neu gezogen und die beiden
> Logdateien
> erzeugt. Ein mal mit Abtastrate 10000 und 15000.

Danke, schaue ich mir an.

> Es ist mit dieser Version nicht mehr möglich auf 20000 zu gehen.

Wieso nicht? Compiler-Fehlermeldung oder was anderes, was nicht mehr 
geht?

> Dies wäre aber mit RC80 usw. nötig.

Du meinst RECS80? Hat das mal bei Dir funktioniert? Ich habe bisher von 
niemandem eine Rückmeldung zu RECS80 erhalten, der IRMP-Code dazu war 
bisher absolut ungetestet.

> Leider funktioniert die Erkennung von ruwido noch nicht richtig.

Wie äußert sich das?

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Fred schrieb:

> ich habe nun die Version aus dem SVN neu gezogen und die beiden
> Logdateien
> erzeugt. Ein mal mit Abtastrate 10000 und 15000.

Ich habe die mal verglichen mit Deiner vorhergehenden r-step.txt. Dort 
sind die Pulse und Pausen ziemlich genau doppelt so lang wie in 
home10k.txt. Kann es sein, dass Du r-step.txt mit 20kHz aufgenommen 
hast? Das hättest Du mir sagen müssen! Jetzt sind die Timingwerte für 
das RUWIDO-Protokoll alle viel zu kurz :-(

Bitte um Aufklärung.

Gruß,

Frank

von Fred (Gast)


Lesenswert?

Hallo,

sorry für die unvollständigen Angaben. Ich hatte wie oben beschrieben
eine Abtastrate von 25000 eingestellt und das r-step.txt erzeugt.
Die beiden anderen mit 15000 und 10000. Ich hätte da noch ein 20000 und
25000 erzeugt, aber das ging ja nicht mehr.

Bei 20000 kommt jetzt "integer overflow in expression" mit 10 warnings.
Das eigendlich nicht mehr wie 20000 gehen sollte, hab ich auch erst 
später gelesen.

Fred

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Fred schrieb:

> sorry für die unvollständigen Angaben. Ich hatte wie oben beschrieben
> eine Abtastrate von 25000 eingestellt und das r-step.txt erzeugt.

Upps, sogar 25000. Ich habe mich schon gewundert, warum ich die 3 
Dateien nicht "übereínander" bekommen habe. Die Angabe der Abtastrate 
ist absolut wichtig.

> Bei 20000 kommt jetzt "integer overflow in expression" mit 10 warnings.
> Das eigendlich nicht mehr wie 20000 gehen sollte, hab ich auch erst
> später gelesen.

Das ist logisch, durch die falschen Timingwerte, die um den Faktor 2,5 
zu groß sind, laufen bei so hohen Abtastraten die Variablen über.

Ich werde sie um den Faktor 2,5 stauchen, dann nochmal alle 3 Dateien 
damit durchchecken und dann, wenn es läuft, ein Update im SVN machen.

Gruß,

Frank

von Fred (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

ich hab mal weiter Scans durchgeführt. Dazu hab ich jetzt erstmal wieder 
die alte Version geflasht und hierbei 20000 als Abtastrate eingestellt, 
da dies für ein paar Protokolle anscheinend nötig ist.

die Datei irc.txt sollte eigentlich das RECS80 Protokoll sein. Es wird 
aber nicht erkannt, könnte auch was anderes sein. Die sagem.txt stammt 
von einer d-box und wird auch nicht erkannt. Bei der kathrein.txt würde 
mich nur interessieren, ob das ein bekanntes Verfahren ist. Zusätzlich 
noch die r-step.txt mit der gleichen Rate.

Ich hoffe da ist was brauchbares für dich dabei.
Wegen den Verwirrungen der Abtastrate, sollte man beim logging eine 
feste Abtastrate vorgeben?

Fred

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Fred schrieb:
> ich hab mal weiter Scans durchgeführt. Dazu hab ich jetzt erstmal wieder
> die alte Version geflasht und hierbei 20000 als Abtastrate eingestellt,
> da dies für ein paar Protokolle anscheinend nötig ist.

15kHz wären optimal. Bei 20kHz reicht der Buffer nicht aus, um 
Framewiederholungen zu speichern.

> die Datei irc.txt sollte eigentlich das RECS80 Protokoll sein. Es wird
> aber nicht erkannt, könnte auch was anderes sein.

Das ist ein Manchester-Protokoll, und zwar ein Mischmasch aus Grundig (9 
Datenbits) und Nokia (16 Datenbits). IRC (was ist das?) hat aber nur 13 
Datenbits. Das kann ich leicht einbauen.

> Die sagem.txt stammt
> von einer d-box und wird auch nicht erkannt.

Ein Pulse-Distance-Protokoll, was leider vom Start-Bit mit dem 
Siemens-Protokoll her kollidiert. Deine T-Home-Scans funktionieren bei 
mir nun alle wunderbar, kollidieren aber nun vom Timing her mit Denon 
und auch dem Siemens-Protokoll. Da bin ich noch etwas am tüfteln, wie 
ich dieses auseinanderhalten könnte.

> Bei der kathrein.txt würde mich nur interessieren, ob das ein bekanntes
> Verfahren ist.

Nein, das ist was komplett neues, Zwischen den Pulsen sind irre lange 
Pausen, die schon nicht mehr als Pausen zwischen Bits, sondern als 
Pausen zwischen Frames verstanden werden.

> Zusätzlich noch die r-step.txt mit der gleichen Rate.

Funktioniert wunderbar, leider habe ich da noch diese Konflikte zu 
SIEMENS und DENON. Deaktiviere ich diese beide Protokolle, läuft alles 
gut.

> Ich hoffe da ist was brauchbares für dich dabei.

Danke, ich werde da das beste draus machen.

> Wegen den Verwirrungen der Abtastrate, sollte man beim logging eine
> feste Abtastrate vorgeben?

Nein, das geht nicht. Bei einigen Protokollen sind die Pulse sehr kurz, 
dann ist 10kHz ungeeignet. 10kHz haben aber den Vorteil, dass man auch 
Frame-Wiederholungen noch sieht. 15kHz ist da ein guter Kompromiss, 
siehe oben. Optimal ist es, die Frquenzrate im Dateinamen zu 
hinterlegen, wie ich es mit den Beispieldateien unter IR-Data gemacht 
habe.

Gruß,

Frank

von Fred (Gast)


Lesenswert?

Hallo,

soll ich die Scans mit 15000 noch mal wiederholen?

das irc ist die FB von Pollin, die bei dem IR-Fernsteuerbausatz 
mitgeliefert wird. Im Artikel [[Quellcode für den Pollin Fernsteuer 
Bausatz]] wurde eben dieses Verfahren erwähnt. So wie es aber aussieht 
ist das aber nicht mehr das was es sein sollte.

Die kathrein scheint wohl so langsam zu sein, da das Gerät dazu nur 
einen 8051 mit 1MHz hat und die FB dazu angepasst ist.

Fred

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Fred schrieb:

> soll ich die Scans mit 15000 noch mal wiederholen?

Wenn Du Spaß daran hast, sehr gern :-)

> das irc ist die FB von Pollin, die bei dem IR-Fernsteuerbausatz
> mitgeliefert wird. Im Artikel [[Quellcode für den Pollin Fernsteuer
> Bausatz]] wurde eben dieses Verfahren erwähnt. So wie es aber aussieht
> ist das aber nicht mehr das was es sein sollte.

Pollin hat da schon 3x die Fernbedienung gewechselt. Das war mal RECS80 
mit dem 3004er Controller in der FB.

> Die kathrein scheint wohl so langsam zu sein, da das Gerät dazu nur
> einen 8051 mit 1MHz hat und die FB dazu angepasst ist.

Normalerweise verwendet Kathrein das Protokoll RC6A, welches von IRMP 
auch unterstützt wird. Aber die scheinen das auch zu wechseln....

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Bastian F. schrieb:
> Wie genau kann man denn nun loggen?

Ich verstehe leider überhaupt nicht, was Du möchtest. Möchtest Du 
loggen, um eine unbekannte Fernbedienung zu scannen oder willst Du nicht 
erstmal schauen, ob IRMP Deine Fernbedienung vielleicht doch erkennt? In 
mehr als 80% der Fälle sollte die FB erkannt werden. Du musst dann nur 
noch

- Protokoll
- Adresse
- Kommando

auch irgendwo ausgeben, entweder auf dem UART oder auf einem LC-Display.

> Wie gesagt, habe ich nur das Logging aktiviert und sonst nichts am
> Programm geändert. Und das scheint ja schonmal falsch zu sein.

Ja, das Logging ist nur für unbekannte FBs. Erstmal solltest Du schauen, 
ob IRMP die FB nicht doch erkennt.

> Wird wohl nur der Aufruf einer Funktion oä sein, aber ich verstehe es
> leider nicht, bzw kann diese Funktion nicht finden.

Schau Dir die main-Funktion von irmp.c ganz am Ende von main.c an:
1
// This is the main routine if you use GCC Compiler
2
int
3
main (void)
4
{
5
  IRMP_DATA irmp_data;
6
7
  irmp_init();         // initialize rc5
8
  timer_init();        // initialize timer
9
  sei ();              // enable interrupts
10
11
  for (;;)
12
  {
13
    if (irmp_get_data (&irmp_data))
14
    {
15
        // ir signal decoded, do something here...
16
        // irmp_data.protocol is the protocol, see irmp.h
17
        // irmp_data.address is the address/manufacturer code of ir sender
18
        // irmp_data.command is the command code
19
    }
20
  }
21
}

> Wäre nett, wenn sich jemand erbarmen würde und mir dies erklären könnte.

Du musst den Teil nach dem if-Statement schon mit Leben füllen, sonst 
bekommst Du kein Ergebnis. Hier kann sich jeder selbst austoben. Ich 
verstehe IRMP eher als anzuwendendes Tool und nicht als fertiges 
Programm.

Gruß,

Frank

von eku (Gast)


Lesenswert?

Hallo Frank,

versuch doch bitte nur RUWIDO einzukompilieren :-)

error: 'last_value' undeclared

von Fred (Gast)


Lesenswert?

da muss RC5 noch mit rein, dann klappts.


Fred

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:
> versuch doch bitte nur RUWIDO einzukompilieren :-)
> error: 'last_value' undeclared

Danke für den Hinweis. Hier der Fix in irmp.c (ziemlich am Anfang):

Alt:
1
#if IRMP_SUPPORT_RC5_PROTOCOL == 1 || IRMP_SUPPORT_RC6_PROTOCOL == 1 ....
2
#define IRMP_SUPPORT_MANCHESTER                 1

Neu:
1
#if IRMP_SUPPORT_RC5_PROTOCOL == 1 || IRMP_SUPPORT_RC6_PROTOCOL == 1 || \
2
    IRMP_SUPPORT_GRUNDIG_OR_NOKIA_PROTOCOL == 1 || IRMP_SUPPORT_SIEMENS_PROTOCOL == 1 || \
3
    IRMP_SUPPORT_RUWIDO_PROTOCOL == 1
4
#define IRMP_SUPPORT_MANCHESTER                 1

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Fred schrieb:
> da muss RC5 noch mit rein, dann klappts.

Es klappt dann zwar, aber RC5 ist kein Muss. Der Fehler lag woanders, 
siehe letzten Beitrag.

Gruß,

Frank

von Fred (Gast)


Lesenswert?

Hallo,

so, nun hab ich mal wieder etwas Zeit gehabt und konnte mal noch ein 
paar Sachen machen.

Ich hab die Kathrein mal mit 10k und 15k protokolliert. Irgendwie, kann 
ich da nicht viel erkennen. Darum hab ich einfach mal die FB aufgemacht 
und mir den Chip angesehen. Auf der Platine steht übrigens auch RUWIDO, 
dürfte aber trotzdem ein anderes Protokoll sein. Der Chip ist mit M709 
bezeichnet.
Datenblatt hab ich mal rausgesucht und angehängt. Nach der Schaltung 
müsste der Carriermode eingestellt sein.

Mist, ich glaub ich kann hier keine Logs mehr anhängen.

Fred

von Fred (Gast)


Lesenswert?

Sorry, ich kann gar keine Dateien mehr anhängen.

Gebe ich einen Dateianhang ein, lässt sich der Beitrag nicht mehr 
senden.

Wie kann ich denn nun dir die Logs etc. zur Verfügung stellen?

Die IRC hat übrigens eine SAB2008 und sollte IR60 sein.

Die Sagem hat einen M34280MK-331FP, dazu konnte ich nichts genaues 
finden.

Fred

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Fred schrieb:

> Wie kann ich denn nun dir die Logs etc. zur Verfügung stellen?

Im IRMP-Source findest Du oben im Kommentar meine E-Mail-Adresse.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Im SVN ist eine neue IRMP-Version 1.9.2

Die bisherigen Decoderteile für RUWIDO (T-Home-Mediareceiver) und für 
SIEMENS (Siemens-Gigaset) konnte ich vereinigen, denn tatsächlich konnte 
ich nach den Wirren der unterschiedlichen Scan-Frequenzen nun erkennen, 
dass die Timings innerhalb der Toleranzgrenzen gleich sind. Der 
Unterschied liegt lediglich in der Länge des Frames:

RUWIDO:   9 Adress-Bits + 7  Kommando-Bits + 1 Check-Bit = 17 Bits
SIEMENS: 11 Adress-Bits + 10 Kommando-Bits + 1 Check-Bit = 22 Bits

Der Decoder nimmt nun beim Empfang zunächst das kürzere RUWIDO-Protokoll 
an, wenn das Timing passt, und schaltet dann während des Empfangs auf 
das SIEMENS-Protokoll um, wenn der Frame doch länger ist als 17 Bits.

Beide Protokolle sind erst aktivierbar ab einer Sample-Frequenz von 15 
kHz.

Viel Spaß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Update: Im SVN ist nun die neue IRMP-Version 1.9.4:

Neues Protokoll: IR60

@Fred: Bitte mal mit Deiner IRC-FB testen, danke!

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Und noch ein Update: Im SVN ist nun die neue IRMP-Version 1.9.5:

Neues Protokoll: KATHREIN

@Fred: Bitte mal mit Deiner IRC-FB testen, danke!

Gruß,

Frank

von eku (Gast)


Lesenswert?

Leider geht SIEMENS nun nicht mehr zu übersetzen:

irmp/irsnd.c:1088: error: 'SIEMENS_BIT_TIME' undeclared (first use in 
this function)
irmp/irsnd.c:1088: error: (Each undeclared identifier is reported only 
once
irmp/irsnd.c:1088: error: for each function it appears in.)
irmp/irsnd.c:1092: error: 'SIEMENS_STOP_BIT' undeclared (first use in 
this function)
irmp/irsnd.c:1096: error: 'SIEMENS_FRAME_REPEAT_PAUSE_TIME' undeclared 
(first use in this function)
irmp/irmp.h:41: error: expected '=', ',', ';', 'asm' or '__attribute__' 
before 'PAUSE_LEN'
irmp/irmp.h:427: error: expected specifier-qualifier-list before 
'uint8_t'
irmp/irmp.h:447: error: expected '=', ',', ';', 'asm' or '__attribute__' 
before 'irmp_get_data'
irmp/irmp.h:456: error: expected '=', ',', ';', 'asm' or '__attribute__' 
before 'irmp_ISR'
irmp/irsnd.h:31: error: expected '=', ',', ';', 'asm' or '__attribute__' 
before 'irsnd_is_busy'
irmp/irsnd.h:39: error: expected '=', ',', ';', 'asm' or '__attribute__' 
before 'irsnd_send_data'
irmp/irsnd.h:45: error: expected '=', ',', ';', 'asm' or '__attribute__' 
before 'irsnd_ISR'

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:
> Leider geht SIEMENS nun nicht mehr zu übersetzen:

Sorry, hatte vergessen, die neuen SIEMENS-/RUWIDO-Konstanten an IRSND 
anzupassen.

Ist korrigiert.

Gruß,

Frank

von jar (Gast)


Lesenswert?

Frank M. schrieb:
> Und noch ein Update: Im SVN ist nun die neue IRMP-Version 1.9.5:

$Id: irmp.c,v 1.94 2011/02/22 14:24:00 fm Exp $

??? gerade geladen

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

jar schrieb:

> $Id: irmp.c,v 1.94 2011/02/22 14:24:00 fm Exp $

Das ist meine interne CVS-Version, die hat nichts mit der "offiziellen" 
Version des Gesamtpakets zu tun. Dass meine interne Versionsverwaltung 
gerade bei 1.94 angekommen ist, ist reiner Zufall. Das bedeutet 
lediglich, dass ich mittlerweile 94 historische Versionen von irmp.c 
habe. In den anderen Source-Dateien stehen ganz andere Zahlen, je 
nachdem, wie oft ich diese in meine interne Versionsverwaltung (CVS) 
eingecheckt habe.

Die "offizielle" Version des IRMP-Pakets steht in README.txt - und sonst 
nirgendwo ;-)

Gruß,

Frank

von jar (Gast)


Lesenswert?

danke

kennt oder hat jemand Scans oder Codes einer Canon RC1 RC5 RC6 
Fernbedienung für Canon Cams ?

von Fred (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

hatte nun mal wiede Zeit zum Testen. (Manchmal hat ein Steik auch was 
Gutes)

Also die Kathrein und die Ruwido Auswertung funktioniert schon mal 
perfekt.
Die IRC (IR60) funktioniert auch schon fast perfekt, nur bei zwei Tasten 
wird nichts erkannt. Ich habe eine Log für diese beiden Tasten 
angehängt. Vielleicht kann man daran was erkennen.

Die beiden anderen Dateien sind ein Scan mit einer Universal FB. Die 
haut im Scanmodus den Power-Off mit allen möglichen Kodierungen raus.
Die zweite Datei zeigt, was erkannt worden ist. Da kann ich für alle 
Variationen, die die FB kennt auch noch andere Logs liefern.

Ein kleines Problem hab ich noch entdeckt. Mit der Abtastrate 15k kann 
ich z.B. das RECS80 nicht aktivieren. Setze ich 20k, mag der RC5 und 
noch ein paar andere nicht.

Das dürfte wohl kein Problem sein, wenn man nur ein Protokoll braucht.

Mir schwebt aber noch ein Universalprüfgerät vor, das einfach alle Codes 
erkennt und dies auf dem LCD anzeigt. Mit dem IRMP brauchts dazu nur 
noch ein paar Routinen für das LCD.

Momentan haue ich die Daten nur über die Serielle raus. Mal sehen, ob 
das mit den LCD Routinen noch in den ATMEGA 8 reinpasst.

Fileupload geht anscheinend auch wieder.

Fred

von Klaus L. (Gast)


Lesenswert?

Fred schrieb:
> Mir schwebt aber noch ein Universalprüfgerät vor, das einfach alle Codes
> erkennt und dies auf dem LCD anzeigt. Mit dem IRMP brauchts dazu nur
> noch ein paar Routinen für das LCD.

Hallo Fred,

http://www.mikrocontroller-projekte.de/Mikrocontroller/IR-LCD/IR-LCD.html

braucht aber einen M168, dafür wenn gewünscht mit Bootloader.

Einfach die aktuellen irmp Files einbauen, habs bei mir mit Version 1.90 
laufen und werde die Seite demnächst mal mit der aktuellen Version 
updaten.

Grüße,
Klaus

von Klaus L. (Gast)


Lesenswert?

Ach ja, wegen dem Layout und der kompatibilität mit der alten Codevision 
Version geht hier leider kein Quarz. Kann mit einem anderen Layout 
natürlich angepasst werden.
Klaus

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Fred,

Fred schrieb:

> Also die Kathrein und die Ruwido Auswertung funktioniert schon mal
> perfekt.

Das freut mich, Danke für Deine Tests :-)

> Die IRC (IR60) funktioniert auch schon fast perfekt, nur bei zwei Tasten
> wird nichts erkannt. Ich habe eine Log für diese beiden Tasten
> angehängt. Vielleicht kann man daran was erkennen.

Ja, diese 2 Tasten senden einen kürzeren IR60-Frame (5 statt 7 bit) aus. 
Kannst Du damit leben, auf diese beiden Tasten zu verzichten? Sonst 
müsste ich da noch eine etwas kompliziertere Sonderbehandlung 
einbauen...

> Die zweite Datei zeigt, was erkannt worden ist. Da kann ich für alle
> Variationen, die die FB kennt auch noch andere Logs liefern.

Wow, nicht schlecht. 211 der 335 erkannten Scans sind NEC-Frames. Womit 
ich ja ganz gut mit meiner Meinung liege, dass NEC mittlerweile das am 
häufigsten eingesetzte Protokoll ist.

> Ein kleines Problem hab ich noch entdeckt. Mit der Abtastrate 15k kann
> ich z.B. das RECS80 nicht aktivieren. Setze ich 20k, mag der RC5 und
> noch ein paar andere nicht.

Die einzelnen Protokolle arbeiten mit derart verschiedenen Timings, dass 
es schwierig ist, sie alle unter einen Hut zu bekommen. Aus 
Speicherplatzgründen verwende ich für die Timing-Messvariablen uint8_t. 
Diese können bei 20kHz durchaus überlaufen. Daher ist 15kHz ein guter 
Kompromiss. RECS80 bzw. RECS80EXT könnte mit 15kHz vielleicht auch 
gerade noch laufen. Ich habe es selbst noch nicht getestet und habe bis 
heute von niemandem(!) ein positives Feedback zu RECS80 erhalten.

Nimm am Ende von irmpconfig.h die entsprechenden Passagen, welche RECS80 
und RECS80EXT bei unter 20kHz abschalten, einfach raus und teste das mit 
15kHz. Wenns geht, werde ich die untere Schranke für RECS80 auf 15kHz 
herabsetzen.

> Mir schwebt aber noch ein Universalprüfgerät vor, das einfach alle Codes
> erkennt und dies auf dem LCD anzeigt. Mit dem IRMP brauchts dazu nur
> noch ein paar Routinen für das LCD.

Wie Klaus Leidinger schon schrieb: so etwas gibt es bereits. Klaus hat 
seinen IR-Tester auch im IRMP-Artikel unter "IRMP-Projekte" eingetragen. 
Vielleicht tut Ihr Euch zusammen?

> Momentan haue ich die Daten nur über die Serielle raus. Mal sehen, ob
> das mit den LCD Routinen noch in den ATMEGA 8 reinpasst.

ATMega8 ist obsolet, nimm den Nachfolger ATMega88 oder - noch besser - 
den kompatiblen ATMega168. Damit kannst Du IRMP und IRSND zusammen in 
einem µC unterbringen und musst Dir keine Sorge um den Speicher machen.

Gruß,

Frank

von Fred (Gast)


Lesenswert?

Frank M. schrieb:
> Ja, diese 2 Tasten senden einen kürzeren IR60-Frame (5 statt 7 bit) aus.
> Kannst Du damit leben, auf diese beiden Tasten zu verzichten? Sonst
> müsste ich da noch eine etwas kompliziertere Sonderbehandlung
> einbauen...

Hallo,

wer macht denn sowas? Steht da auch im Datenblatt was von dieser 
komischen Art und Weise einfach kürzere Frames zu senden? Wegen mir wäre 
eine Sonderbehandlung nicht nötig. Ich hab halt nur die eine FB die IR60 
verwendet, deshalb kann ich nicht sagen, wie das bei anderen FB mit IR60 
aussieht. Vielleicht hat ja noch jemand eine (Universal)FB mit IR60 und 
könnte das mal testen.

Auch mit 20k und aktivierten RECS80 konnte ich meiner Universal FB da 
nichts entlocken. Das ist das billige Teil vom Aldi MD6461.

Beim Scan mit der Universal FB sind aber noch ein paar Codes nicht 
erkannt worden. Hast du da schon mal einen Blick darauf geworfen? Wenn 
du da noch was brauchst, kann ich da noch ein paar Scans machen und ggf. 
den Hersteller der den Code verwendet rausfinden.

Ich nehme eine ATMEGA8 her, weil ich da noch welche habe. :-)
Alternativ hätte ich noch ATMEGA48 (Speicher zu klein) oder dann die
16/32/644 noch.

Für ein einzelnes Protokoll müsste es doch auf einen ATTiny2313 zu 
kriegen sein. Da wären aber einigen Anpassungen nötig, ob das dann sich 
rentiert.

Fred

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Fred schrieb:

> wer macht denn sowas? Steht da auch im Datenblatt was von dieser
> komischen Art und Weise einfach kürzere Frames zu senden?

Keine Ahnung, kann man aber schön sehen, wenn man sich eine Zeile aus 
Deiner missing-Datei in den Editor lädt und dann noch irgendeine aus 
Deiner irc15k.txt reinholt. Die missing-Zeilen sind kürzer als alle aus 
der irc15k.txt.

> Auch mit 20k und aktivierten RECS80 konnte ich meiner Universal FB da
> nichts entlocken. Das ist das billige Teil vom Aldi MD6461.

Ich habe mir die Scans aus der universal-Datei angeschaut. Insgesamt 
9mal erkennt IRMP zunächst RECS80 am Startbit, scheitert dann aber an 
der Framelänge. Diese sind 6, 7 oder meist 9 Bit lang. IRMP erwartet 
aber immer eine Länge von 11 Bits.

Entweder ist die Doku unter

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

(nach der ich vorgegangen bin) falsch oder es gibt weitere 
RECS80-Abarten. Jedenfalls passen die Timings der Startbits und auch der 
Datenbits perfekt - es scheitert aber immer an der Framelänge.

> Beim Scan mit der Universal FB sind aber noch ein paar Codes nicht
> erkannt worden. Hast du da schon mal einen Blick darauf geworfen?

Ja, siehe oben. Ich werde sie mir auch noch detaillierter anschauen. 
IRMP nimmt auch oft RUWIDO an, weil die Startbits passen, scheitert dann 
aber später an den Längen der Datenbits, die zu RUWIDO überhaupt nicht 
passen. Was das genau ist, kann ich jetzt noch nicht sagen.

> Wenn
> du da noch was brauchst, kann ich da noch ein paar Scans machen und ggf.
> den Hersteller der den Code verwendet rausfinden.

Ja, darauf komme ich gern nochmal zurück.

> Ich nehme eine ATMEGA8 her, weil ich da noch welche habe. :-)

Okay.

> Für ein einzelnes Protokoll müsste es doch auf einen ATTiny2313 zu
> kriegen sein.

Das wird zu knapp - jedenfalls in Verbindung mit einem LCD. Und nur ein 
IR-Protokoll ist langweilig ;-)

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Frank M. schrieb:

> Ich habe mir die Scans aus der universal-Datei angeschaut. Insgesamt
> 9mal erkennt IRMP zunächst RECS80 am Startbit, scheitert dann aber an
> der Framelänge. Diese sind 6, 7 oder meist 9 Bit lang. IRMP erwartet
> aber immer eine Länge von 11 Bits.

Das Problem habe ich klären können. Ich habe mich damals, als ich das 
RECS80-Protokoll in den IRMP eingebaut habe, verzählt. RECS80 hat nur 1 
Start-Bit, nicht 2. Das gibt es nur beim RECS80EXT-Protokoll.

Ich habe das im IRMP korrigiert und schon konnte IRMP die RECS80-Frames 
von der Universal-Fernbedienung auch lesen. Dass es im Scan von Fred 
auch kürzere RECS80-Frames gab, lag einfach daran, dass nach 3 Frames 
innerhalb einer Textzeile der Log-Buffer voll war.

Damit sollte das immerwährende Rätsel, ob IRMP überhaupt RECS80 
versteht, endlich gelöst sein:

Es geht erst ab Version 1.9.6, habe ich ins SVN eingecheckt :-)

Ausserdem klappt es bestens bei 15kHz, ich habe daher die untere 
Scanfrequenz für RECS80 auf 15kHz (statt 20kHz) korrigiert.

Damit sollten nun alle von IRMP unterstützten IR-Protokolle bei 15kHz 
prima gelesen werden.

Gruß,

Frank

von Bastian F. (bastian_f)


Lesenswert?

Sorry, dass ich schon wieder nerven muss.
Ich habe jetzt, hier aus dem Thread übernommen, folgendes in main:
1
   if (irmp_get_data (&irmp_data))
2
    {
3
        itoa(irmp_data.protocol, protocol, 10);
4
        itoa(irmp_data.address, address, 16);
5
        itoa(irmp_data.command, command, 16);
6
7
        lcd_string(protocol);
8
        lcd_string(address);
9
        lcd_string(command);
10
     }

Nur leider kommt auf dem LCD nichts an (die Ansteuerung des LCD 
funktioniert, daran liegt es nicht).
Am "Outpin" des IR Receivers kann ich mit meinem Multimeter 
unterschiedliche Frequenzen messen, wenn ich Knöpfe einer FB drücke, 
aber wie gesagt, es kommt nichts an oder wird nichts ausgegeben.
Atmega88, Fuses (direct hex values) low: E2, high: DC, ext.: 01
Int. RC Osc. 8MHz; Start-up time PWRDWN/RESET : 6 CK/14 CK + 65 ms
PB6 ist der "Eingangspin".

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Bastian F. schrieb:

> Ich habe jetzt, hier aus dem Thread übernommen, folgendes in main:
1
>     if (irmp_get_data (&irmp_data))
2
>     {
3
>         itoa(irmp_data.protocol, protocol, 10);
4
>         itoa(irmp_data.address, address, 16);
5
>         itoa(irmp_data.command, command, 16);
6
> 
7
>         lcd_string(protocol);
8
>         lcd_string(address);
9
>         lcd_string(command);
10
>      }

Wie ist bei Dir protocol, address und command definiert? Bitte zeige die 
ganze main-Funktion.

> Nur leider kommt auf dem LCD nichts an (die Ansteuerung des LCD
> funktioniert, daran liegt es nicht).

Wenn Du in den if-Block ein

  lcd_string("Hallo");

einbaust, erscheint das dann auf dem LCD, wenn Du eine FB-Taste drückst?

Welche FBs hast Du ausprobiert?

> Atmega88, Fuses (direct hex values) low: E2, high: DC, ext.: 01
> Int. RC Osc. 8MHz; Start-up time PWRDWN/RESET : 6 CK/14 CK + 65 ms

Sieht okay aus.

> PB6 ist der "Eingangspin".

Zeige bitte die entsprechende Stelle in irmpconfig.h. Am besten hängst 
Du diese hier mal an, damit man sieht, was Du alles so eingestellt hast.

Gruß,

Frank

von Bastian F. (bastian_f)


Angehängte Dateien:

Lesenswert?

Frank M. schrieb:
> Wie ist bei Dir protocol, address und command definiert? Bitte zeige die
> ganze main-Funktion.
1
main (void)
2
{
3
  char protocol[10];
4
  char address[10];
5
  char command[10];
6
7
  IRMP_DATA irmp_data;
8
  lcd_init();
9
  irmp_init();                                                              // initialize rc5
10
  timer_init();                                                             // initialize timer
11
  sei ();                                                                   // enable interrupts
12
13
  for (;;)
14
  {
15
16
    if (irmp_get_data (&irmp_data))
17
    {
18
      itoa(irmp_data.protocol, protocol, 10);
19
        itoa(irmp_data.address, address, 16);
20
        itoa(irmp_data.command, command, 16);
21
22
        lcd_string(protocol);
23
        lcd_string(address);
24
        lcd_string(command);
25
    }
26
  }
27
}
>
>> Nur leider kommt auf dem LCD nichts an (die Ansteuerung des LCD
>> funktioniert, daran liegt es nicht).
>
> Wenn Du in den if-Block ein
>
>   lcd_string("Hallo");
>
> einbaust, erscheint das dann auf dem LCD, wenn Du eine FB-Taste drückst?

Nein, hatte ich auch schon getestet, nur vergessen zu erwähnen.
Sieht nach falscher Verkabelung aus, oder?

> Welche FBs hast Du ausprobiert?

Kathrein, Samsung, Grundig, Pioneer, Philips

>> Atmega88, Fuses (direct hex values) low: E2, high: DC, ext.: 01
>> Int. RC Osc. 8MHz; Start-up time PWRDWN/RESET : 6 CK/14 CK + 65 ms
>
> Sieht okay aus.

Wenigstens etwas ;)

>> PB6 ist der "Eingangspin".
>
> Zeige bitte die entsprechende Stelle in irmpconfig.h. Am besten hängst
> Du diese hier mal an, damit man sieht, was Du alles so eingestellt hast.

s.o.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Bastian F. schrieb:
> Nein, hatte ich auch schon getestet, nur vergessen zu erwähnen.
> Sieht nach falscher Verkabelung aus, oder?

Kann man so nicht sagen, wenn IRMP nichts erkennt, wird auch das "Hallo" 
nicht ausgegeben. Du könntest natürlich, um sicher zu gehen, ein 
lcd_print ("Start"); mal vor die while-Schleife setzen. Wenn das 
kommt, ist das LCD schon mal kein Problem.

Bleibt dann IRMP...

>> Welche FBs hast Du ausprobiert?
> Kathrein, Samsung, Grundig, Pioneer, Philips

Komisch... Zumindest die Samsung sollte mit den Standard-Einstellungen 
gehen. Hast Du sonst nix japanisches dabei? ;-)

Aktiviere bitte zusätzlich in irmpconfig.h:

IRMP_SUPPORT_RC6_PROTOCOL             (wegen deiner Kathrein FB)
IRMP_SUPPORT_RUWIDO_PROTOCOL          (nur mal so)
IRMP_SUPPORT_GRUNDIG_PROTOCOL         (wegen Grundig)
IRMP_SUPPORT_NOKIA_PROTOCOL           (auch wegen Grundig)

Keine Ahnung, was Pioneer so benutzt.

Sonst sieht die irmpconfig.h ganz gut aus.

EDIT: Welche IRMP-Version benutzt Du?

Gruß,

Frank

von Bastian F. (bastian_f)



Lesenswert?

Wie gesagt, das LCD bzw dessen Ansteuerung funktioniert.
Ich meinte auch eher den IR Receiver, obwohl man da ja eigentlich nicht 
vie falsch machen kann. Zumal ich ich ja auch was am Ausgang messen 
kann.
(Aber sicherheitshalber mal die Belegung (TSOP1838, Datenblatt im 
Anhang. Vcc/Gnd ist wie vorgeschrieben mit Widerstand und Kondensator 
beschaltet):
Von vorne gesehen:
Links: Out
Mitte: Gnd
Rechts: Vcc)
Ne, komischerweise nichts japanisches im Haushalt vorhanden.

Habe die von dir erwähnten Protokolle aktiviert, aber keine Änderung.

Ich weiß nicht welche ich vorher hatte, jedenfalls funktioniert es mit 
der aktuellsten auch nicht - grade getestet.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Bastian F. schrieb:

> Habe die von dir erwähnten Protokolle aktiviert, aber keine Änderung.

Ich habe keine Idee mehr, Du benutzt das AVR-Studio und F_CPU steht auf 
8 MHz?

Gruß,

Frank

von Bastian F. (bastian_f)


Lesenswert?

Sehr seltsam.
Habe mal auf PB4 gewechselt und siehe da, es funktioniert...
Was aber zudem sehr komisch ist, dass wenn ich DDRC mit dem LED Port 
verbinde leuchten die LED je nach Tastendruck unterschiedlich aus, 
obwohl nichts davon im Code steht.
Wie kann man dies erklären?
Wie irgendwann oben erwähnt, läuft das ganze auf/mit einem STK500.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Bastian F. schrieb:

> Habe mal auf PB4 gewechselt und siehe da, es funktioniert...

Gratuliere! :-)

Ich kenne das STK500 nicht, aber kannn es sein, dass an PB6 ein Quarz 
hängt?

> Was aber zudem sehr komisch ist, dass wenn ich DDRC mit dem LED Port
> verbinde leuchten die LED je nach Tastendruck unterschiedlich aus,
> obwohl nichts davon im Code steht.

Was ist DDRC?

> Wie kann man dies erklären?

Keine Ahnung, was da auf dem STK500 verdrahtet ist.

Werden nun alle FBs erkannt?

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Version 1.9.8 ist nun im SVN, zwei neue Protokolle zum Testen sind 
hinzugekommen:

1. NETBOX: Infrarot-Tastatur für die Netbox, erhältlich bei Pollin unter
   der Bestellnr. 711 009 für 1 EUR :-)
   Die Netbox-Tastatur wird momentan aber nur erkannt, wenn man das
   RC6-Protokoll in IRMP abschaltet. Da muss ich noch was dran tun...

2. NEC16: Eine Abart des Standard-NEC-Protokolls (32 bit), welches nur
   16 Bit sendet. Dieses habe ich aus den Universal-FB-Scans von Fred
   extrahiert und in den IRMP eingebaut.

Sobald die Netbox-Tastatur rundläuft, werde ich auch ein neues Release 
im Download-Bereich des IRMP-Artikels zur Verfügung stellen.

Gruß,

Frank

von Fred (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

ich hab nun gleich die neuen Version geholt. Die LCD Routinen sind nun 
auch
eingebunden und die Ausgabe funktioniert. Der Flash in nun zu 90% 
gefüllt, mal sehen, was da noch für Protokolle reingehen :-)

Im Anhang der Scan wieder mit meiner Universal FB. Es werden schon 
einige
mehr erkannt.

Fred

von Bastian F. (bastian_f)


Lesenswert?

Frank M. schrieb:
> Bastian F. schrieb:
>
>> Habe mal auf PB4 gewechselt und siehe da, es funktioniert...
>
> Gratuliere! :-)

Danke, nur verstehen tue ich es nicht.
Egal, läuft ja erstmal ;-)

> Ich kenne das STK500 nicht, aber kannn es sein, dass an PB6 ein Quarz
> hängt?
>
>> Was aber zudem sehr komisch ist, dass wenn ich DDRC mit dem LED Port
>> verbinde leuchten die LED je nach Tastendruck unterschiedlich aus,
>> obwohl nichts davon im Code steht.
>
> Was ist DDRC?

Die "PCx Reihe".

>> Wie kann man dies erklären?
>
> Keine Ahnung, was da auf dem STK500 verdrahtet ist.

Erst nachdenken, dann doofe Fragen stellen...
An PORTC hängt auch das Display :-|

> Werden nun alle FBs erkannt?

Alle bis auf die Pioneer.
Da reagiert alles sehr "träge" und es werden nicht alles Tastendrücke 
erkannt.

von eku (Gast)


Lesenswert?

Hallo Uwe,

neue Probleme mit den letzten Änderungen im SVN:

irmp.c: In function 'irmp_rx_process':
hardware/ir/irmp/irmp_lib.c:2712: warning: conversion to 'uint8_t' from 
'int' may alter its value
irmp.c:2727: warning: conversion to 'PAUSE_LEN' from 'int' may alter its 
value
irmp.c:2911: error: 'irmp_tmp_id' undeclared (first use in this 
function)
irmp.c:2911: error: (Each undeclared identifier is reported only once
irmp.c:2911: error: for each function it appears in.)

Die Zeilennummer können abweichen, da ich für ethersex noch ein paar 
Anpassungen einfügen musste.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi eku,

eku schrieb:
> Hallo Uwe,

Wer ist Uwe? ;-)

> irmp.c: In function 'irmp_rx_process':
> hardware/ir/irmp/irmp_lib.c:2712: warning: conversion to 'uint8_t' from
> 'int' may alter its value

irmp_rx_process() kenne ich nicht - nicht von mir ;-)

> irmp.c:2727: warning: conversion to 'PAUSE_LEN' from 'int' may alter its
> value
> irmp.c:2911: error: 'irmp_tmp_id' undeclared (first use in this
> function)
> irmp.c:2911: error: (Each undeclared identifier is reported only once
> irmp.c:2911: error: for each function it appears in.)
>
> Die Zeilennummer können abweichen, da ich für ethersex noch ein paar
> Anpassungen einfügen musste.

Da müsstest Du mir dann schon die Stellen im Source zeigen... und auch 
die dazugehörige irmpconfig.h. Bei mir compiliert das einwandfrei durch.

Gruß,

Frank

von eku (Gast)


Lesenswert?

Hallo Frank,

die Variable irmp_tmp_id ist nur für Samsung deklariert, wird aber auch 
von Kathrein benutzt.

von eku (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Frank,

ich habe Probleme mit dem RC5-Code von IRSND. Eine DVD-Player-FB sendet 
nachweislich RC5, die von IRMP auch erkannt wird (rc5_org). Ich habe 
eine Universal-FB damit angelernt (rc5_uni). Mit beiden kann ich den 
DVD-Player steuern. Nutze ich allerdings IRSND gibt es sowohl beim 
Anlernen durch die Universal-FB (statt zu lernen wird ein Fehler 
gemeldet) als auch bei der Bedienung des DVD-Players Probleme nicht 
erkannter Codes.

Kann es an Toleranzen des Timings liegen oder ist der RC5-Code in IRSND 
fehlerhaft? Was kann ich tun um Dir die nötigen Diagnosedaten zu 
liefern?

Gruß, eku

von eku (Gast)


Lesenswert?

Hallo Frank,

Variable irmp_bit in irmp.c wird zweimal deklariert.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:

> die Variable irmp_tmp_id ist nur für Samsung deklariert, wird aber auch
> von Kathrein benutzt.

Schmeiss sie einfach im Kathrein-Code raus. Sie wird dort gesetzt, aber 
nicht weiter genutzt. Korrektur werde ich demnächst einchecken.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:
> Variable irmp_bit in irmp.c wird zweimal deklariert.

Danke, habe ich auch korrigiert.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:
> Kann es an Toleranzen des Timings liegen oder ist der RC5-Code in IRSND
> fehlerhaft? Was kann ich tun um Dir die nötigen Diagnosedaten zu
> liefern?

IRSND erzeugt unter Linux auf stdout IRMP-Scans. Ich habe mal dieselben 
Codes vom IRSND erzeugen lassen. Dann habe ich die Zeichenfolgen von 
rc5_org und die von IRSND erzeugten im Editor zeilenweise untereinander 
betrachtet. Die Puls-/Pausenfolgen sind identisch - wenn man mal von dem 
Toggle-Bit absieht, was man bei IRSND unter Linux nicht testen kann, 
weil man da nur einen Frame pro Kommando-Aufruf "senden" kann.

Die von IRSND erzeugten Pulse sind etwas kürzer als die von rs5_org. Die 
Puls-/Pausenzeiten sind bei rc5_org ca. 950 µs, die vom IRSND erzeugten 
liegen bei 866µs, was etwas näher am dokumentieren Ideal von 889µs 
liegt.

Gruß,

Frank

von Fred (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

ich hab mal den Scan mit der Universal FB mit den Ausgaben zu verbinden.

Leider klappt das nicht ganz so gut. Wäre das nicht mal noch ne Idee, 
das in die Logfunktion zu integrieren? Es würde ja der erkannte 
Hersteller genügen.
Also in der Richtung:

#0x11   (wenn z.B. der Siemens Code erkannt wurde)
111100000111110011110000111

#       (wenn nicht)
000011111111100000000111111

So wirds vielleicht lesbarer und die anderen Tools dürften damit kein 
Problem haben.


Fred

von Chan (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

Ich benutze irmp unter CodeVision aber ich bekomme gleich am Anfang 
einige Fehlermeldungen vom Compiler...

was muss ich machen ?

lg

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Fred schrieb:

> Leider klappt das nicht ganz so gut. Wäre das nicht mal noch ne Idee,
> das in die Logfunktion zu integrieren? Es würde ja der erkannte
> Hersteller genügen.

Das wird schwierig. Die Log-Funktion arbeitet aus dem Interrupt heraus. 
Wann diese ihren Buffer flusht, ist nicht vorhersagbar, läuft daher 
asynchron zur Frame-Erkennung. Die Erkennung vor(!) der Ausgabe der 
Einsen/Nullen rauszublasen, ist dann fast unmöglich.

Ich schau mal, was ich machen kann.

Gruß,

Frank

von Telekom (Gast)


Lesenswert?

Hallo,

war nur mal so eine Idee.

Ich hab mal meine main.c so umgebaut, das "Zeitmarken" in die Log
geschrieben werden. Wenn ich nun den Scan der Universal-FB laufen lasse,
sehe ich anhand der Marken, welche Codes erkannt wurden und welche 
nicht. Hast du noch ein paar Codes entdeckt, die sich lohnen würden 
näher zu betrachten?

Mal noch so eine nette Idee: Da ich die beiden Pollinboards verwende und 
sich darauf ein NF-Verstärker befindet, hab ich mal einen Lautsprecher 
angeschlossen und den Eingang mit dem TSOP verbunden. Ich kann jetzt 
schon ein paar Codes am Klang erkennen :-)

Fred

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi Fred,

Telekom schrieb:

> Ich hab mal meine main.c so umgebaut, das "Zeitmarken" in die Log
> geschrieben werden. Wenn ich nun den Scan der Universal-FB laufen lasse,
> sehe ich anhand der Marken, welche Codes erkannt wurden und welche
> nicht.

Interessant, die Änderungen kannst Du mir ja mal zeigen.

> Hast du noch ein paar Codes entdeckt, die sich lohnen würden
> näher zu betrachten?

Ja, soviel "anderes" als das, was IRMP nicht schon kennt, ist da gar 
nicht mehr drin. Ich hab das mal statistisch analysiert. IRMP erkennt 
über 80 Prozent. Neben dem NEC16-Protokoll, was ich ja noch eingebaut 
habe, kommen da sehr oft Frames vor, die dem NEC-Timing entsprechen, 
aber 40 statt 32 Bit haben. Wenn ich das auch einbauen würde, wären wir 
bei über 90 Prozent. Aber bisher hat mir noch keiner sowas mal gezeigt, 
daher weiß ich nicht, ob der Aufwand sich lohnt, ein NEC40-Protokoll in 
den IRMP zu integrieren... Ausserdem müsste ich da überlegen, wie ich 
die 40 Bit in eine 16-Bit-Adresse und ein 16-Bit-Kommando zerlege. 
Vermutlich wird Redundanz drin sein, die man rausoptimieren kann, um das 
in 16+16 Bit reinzuquetschen. Aber ob die paar NEC40-Frames ausreichen? 
Da bräuchte ich schon systematische Scans der Tasten 0-9, besser noch 
mehr. Alternativ wäre natürlich ein Link auf eine passende Doku 
hilfreich.

> Mal noch so eine nette Idee: Da ich die beiden Pollinboards verwende und
> sich darauf ein NF-Verstärker befindet, hab ich mal einen Lautsprecher
> angeschlossen und den Eingang mit dem TSOP verbunden. Ich kann jetzt
> schon ein paar Codes am Klang erkennen :-)

lach Sehr nette Idee! :-)

Gruß,

Frank

von Jan B. (berge)


Angehängte Dateien:

Lesenswert?

Hallöchen zusammen,

da ich ARM MCUs einsetze, musste ich ein wenig am IRMP drehen, damit er 
anwendbar wird. Meine Änderungen sind nicht gravierend und sicher nicht 
optimal, aber funktionieren. Da sie auch für andere interessant sein 
könnten, poste ich sie hier.

Im Wesentlichen habe ich das define IRMP_FLEXIBLE_VERSION hinzugefuegt 
und die Funktion für die ISR so angepasst, dass sie nun einen 
übergebenen Wert verarbeitet. Somit ist man von der Zielarchitektur 
relativ unabhängig und übergibt lediglich den Pinstatus.

Vielen Dank an alle Entwickler des IRMP!

Liebe Grüße,

Jan

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Jan Berg schrieb:

> da ich ARM MCUs einsetze, musste ich ein wenig am IRMP drehen, damit er
> anwendbar wird. Meine Änderungen sind nicht gravierend und sicher nicht
> optimal, aber funktionieren. Da sie auch für andere interessant sein
> könnten, poste ich sie hier.

Erstmal danke für die Änderungsvorschläge. Ich werde sie in ähnlicher 
Form übernehmen. Die Namensgebung IRMP_FLEXIBLE_VERSION finde ich etwas 
unglücklich gewählt. Eine Alternative wäre IRMP_GENERIC_INTERFACE oder 
etwas ähnliches in der Art. Ich muss mal drüber nachdenken.

Gruß,

Frank

von jar (Gast)


Lesenswert?

ich würde gerne den Timer1 zu Timer 0 tauschen, sehe ich das richtig das 
im Prinzip nur um die 15000 Interrupts nötig sind ? deswegen einen 16 
Bit Timer nehmen müsste nicht sein ?

wenn ich das soweit überblicke könnte ich auch meine HW mit dani code 
ersetzen, Timer0 -> 8 MHz CPU Vorteiler 256 -> Timer compare auf -2 gibt 
overflow nach 512 Takte = 64 µs das sind genau 15625 Interrupts pro 
Sekunde und damit in die IRMP-ISR, dann müsste der Timer 1 wieder völlig 
frei sein, oder hab ich was übersehen ?

danke

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

jar schrieb:
> ich würde gerne den Timer1 zu Timer 0 tauschen, sehe ich das richtig das
> im Prinzip nur um die 15000 Interrupts nötig sind ?

Richtig. Es müssen auch nicht exakt 15000 Interrupts/sec sein. Aber Du 
solltest den exakten Wert für F_INTERRUPTS angeben.

> deswegen einen 16 Bit Timer nehmen müsste nicht sein ?

Nein, muss nicht sein.

> wenn ich das soweit überblicke könnte ich auch meine HW mit dani code
> ersetzen, Timer0 -> 8 MHz CPU Vorteiler 256 -> Timer compare auf -2 gibt
> overflow nach 512 Takte = 64 µs das sind genau 15625 Interrupts pro
> Sekunde und damit in die IRMP-ISR, dann müsste der Timer 1 wieder völlig
> frei sein, oder hab ich was übersehen ?

Sollte gehen. Wenns läuft, schick mir bitte Deine Code-Änderungen. Dann 
baue ich das als Alternative zum 16-Bit-Timer ein.

Gruß,

Frank

von jar (Gast)


Lesenswert?

Frank M. schrieb:
> Sollte gehen. Wenns läuft, schick mir bitte Deine Code-Änderungen. Dann
>
> baue ich das als Alternative zum 16-Bit-Timer ein.

OK ich versuchs mal, danke spart mir ne Menge reverse engeniering
mit Dani Code meinte ich:
Beitrag "Fernbedien RC5 Empfänger"

von eku (Gast)


Lesenswert?

Hallo Frank,

Frank M. schrieb:
> Die Namensgebung IRMP_FLEXIBLE_VERSION finde ich etwas
> unglücklich gewählt. Eine Alternative wäre IRMP_GENERIC_INTERFACE oder
> etwas ähnliches in der Art. Ich muss mal drüber nachdenken.

Da gibt doch schon was im Code: IRMP_USE_AS_LIB

Im IRMP-Port nach ethersex habe ich die Port- und Timerprogrammierung 
herausgezogen: 
https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi eku,

eku schrieb:

>> Die Namensgebung IRMP_FLEXIBLE_VERSION finde ich etwas
>> unglücklich gewählt. Eine Alternative wäre IRMP_GENERIC_INTERFACE oder
>> etwas ähnliches in der Art. Ich muss mal drüber nachdenken.
>
> Da gibt doch schon was im Code: IRMP_USE_AS_LIB

Das ist was ganz anderes! Hier geht es darum, den Source per Include zu 
laden, um ihn in ein eigenes Projekt einzubinden. Aber nicht zum Linken, 
sondern At-Compile-Time. Vielleicht werde ich das Vorgehen dazu mal im 
IRMP-Artikel dokumentieren. Bis dato nutze nur ich selbst dieses 
Feature.

> Im IRMP-Port nach ethersex habe ich die Port- und Timerprogrammierung
> herausgezogen:
> https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp

Danke, schaue ich mir an.

Sicherlich kann man den IRMP-Source allgemeiner halten und das 
µC-spezifische komplett raushalten. Für Linux und Windows wird das ja 
schon gemacht. Den Zustand des IR-Empfängers als Argument an das 
IRMP-Working-Horse zu übergeben ist ja keine schlechte Idee von Jan 
Berg. Nur kostet so eine Argumentübergabe etwas Zeit (Parameterübergabe 
über Stack) und die wollte ich vermeiden. Das hört sich zwar wegen der 
ziemlich großen Codelänge der ISR jetzt paradox an, ist aber angesichts 
der sehr geringen Durchlaufzeit der Interrupt-Routine als State-Machine 
trotzdem sinnvoll. Die ISR verbrät eigentlich nur in dem (kurzen) Moment 
Zeit, wenn sie das zugehörige Protokoll zum erkannten Startbit sucht.

Ich muss mal drüber nachdenken.

Gruß,

Frank

von jar (Gast)


Lesenswert?

Frank M. schrieb:
> Sollte gehen. Wenns läuft, schick mir bitte Deine Code-Änderungen. Dann
> baue ich das als Alternative zum 16-Bit-Timer ein.

so nun läufts endlich,
1
// wo auch immer
2
void timer0_init(void)
3
{
4
  TCCR0B = 1<<CS02;      //divide by 256
5
  TCNT0 = -2;          // 2 * 256 = 512 cycle bei 8 MHz
6
  TIMSK0 = 1<<TOIE0;    //enable timer interrupt
7
}
8
9
// in IRMP.C 
10
SIGNAL (SIG_OVERFLOW0)
11
{
12
  TCNT0 = -2;
13
  irmp_ISR ();
14
}
15
16
//---------------- ab hier nur kalk-hilfe
17
18
19
20
21
/* kleine kalk-Hilfe in qbasic, wer mag kanns auch in C umschreiben
22
CLS
23
OPEN "timer0.h" FOR OUTPUT AS #1
24
j = 1
25
26
PRINT #1, "//", "TCCR0B"
27
PRINT #1, "//", "CS02  CS01  CS00  Description"
28
PRINT #1, "//", "0     0     0     No clock source (Timer/Counter stopped)"
29
PRINT #1, "//", "0     0     1     clkI/O/(No prescaling)"
30
PRINT #1, "//", "0     1     0     clkI/O/8 (From prescaler)"
31
PRINT #1, "//", "0     1     1     clkI/O/64 (From prescaler)"
32
PRINT #1, "//", "1     0     0     clkI/O/256 (From prescaler)"
33
PRINT #1, "//", "1     0     1     clkI/O/1024 (From prescaler)"
34
35
36
PRINT #1, "//", "F_CPU / MHz", "Interrupts", "TCCR0B", "TCNT0"
37
38
FOR f1 = 1 TO 20 STEP 1
39
f = f1
40
nochmal:
41
FOR d = 1 TO 30
42
FOR e = 0 TO 6 STEP 3
43
REM 2^0 2^3 2^6 2^8 2^10
44
IF (f * 1000000 / (2 ^ e)) / d >= 10000 AND (f * 1000000 / (2 ^ e)) / d <= 21000 THEN
45
   PRINT #1, "//", f, INT((f * 1000000 / (2 ^ e)) / d), 2 ^ e, -d;
46
   IF (2 ^ e) = 8 THEN PRINT #1, "-> "; CHR$(9); "TCCR0B=(CS01);"; CHR$(9); "TCNT0 = "; -d; ";"
47
   IF (2 ^ e) = 64 THEN PRINT #1, "-> "; CHR$(9); "TCCR0B=(CS01 | CS00);"; CHR$(9); "TCNT0 = "; -d; ";"
48
   IF (2 ^ e) = 256 THEN PRINT #1, "-> "; CHR$(9); "TCCR0B = (CS02); "; CHR$(9); "TCNT0 = "; -d; ";"
49
   IF (2 ^ e) = 1024 THEN PRINT #1, "-> "; CHR$(9); "TCCR0B=(CS02| CS00);"; CHR$(9); "TCNT0 = "; -d; ";"
50
51
   j = j + 1
52
END IF
53
NEXT e
54
NEXT d
55
FOR d = 1 TO 30
56
FOR e = 8 TO 10 STEP 2
57
IF (f * 1000000 / (2 ^ e)) / d >= 10000 AND (f * 1000000 / (2 ^ e)) / d <= 21000 THEN
58
   PRINT #1, "//", f, INT((f * 1000000 / (2 ^ e)) / d), 2 ^ e, -d;
59
   IF (2 ^ e) = 8 THEN PRINT #1, "-> "; CHR$(9); "TCCR0B=(CS01);"; CHR$(9); "TCNT0 = "; -d; ";"
60
   IF (2 ^ e) = 64 THEN PRINT #1, "-> "; CHR$(9); "TCCR0B=(CS01 | CS00);"; CHR$(9); "TCNT0 = "; -d; ";"
61
   IF (2 ^ e) = 256 THEN PRINT #1, "-> "; CHR$(9); "TCCR0B = (CS02); "; CHR$(9); "TCNT0 = "; -d; ";"
62
   IF (2 ^ e) = 1024 THEN PRINT #1, "-> "; CHR$(9); "TCCR0B=(CS02| CS00);"; CHR$(9); "TCNT0 = "; -d; ";"
63
  
64
   j = j + 1
65
END IF
66
NEXT e
67
NEXT d
68
IF f = 7 THEN
69
   f = 7.373
70
   GOTO nochmal
71
END IF
72
IF f = 14 THEN
73
   f = 14.318
74
   GOTO nochmal
75
END IF
76
NEXT f1
77
78
*/
79
80
81
82
83
84
//            TCCR0B
85
//            CS02  CS01  CS00  Description
86
//            0     0     0     No clock source (Timer/Counter stopped)
87
//            0     0     1     clkI/O/(No prescaling)
88
//            0     1     0     clkI/O/8 (From prescaler)
89
//            0     1     1     clkI/O/64 (From prescaler)
90
//            1     0     0     clkI/O/256 (From prescaler)
91
//            1     0     1     clkI/O/1024 (From prescaler)
92
//            F_CPU / MHz   Interrupts    TCCR0B        TCNT0
93
//             1             15625         64           -1 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -1 ;
94
//             1             20833         8            -6 ->   TCCR0B=(CS01);  TCNT0 = -6 ;
95
//             1             17857         8            -7 ->   TCCR0B=(CS01);  TCNT0 = -7 ;
96
//             1             15625         8            -8 ->   TCCR0B=(CS01);  TCNT0 = -8 ;
97
//             1             13888         8            -9 ->   TCCR0B=(CS01);  TCNT0 = -9 ;
98
//             1             12500         8            -10 ->   TCCR0B=(CS01);  TCNT0 = -10 ;
99
//             1             11363         8            -11 ->   TCCR0B=(CS01);  TCNT0 = -11 ;
100
//             1             10416         8            -12 ->   TCCR0B=(CS01);  TCNT0 = -12 ;
101
//             2             15625         64           -2 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -2 ;
102
//             2             10416         64           -3 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -3 ;
103
//             2             20833         8            -12 ->   TCCR0B=(CS01);  TCNT0 = -12 ;
104
//             2             19230         8            -13 ->   TCCR0B=(CS01);  TCNT0 = -13 ;
105
//             2             17857         8            -14 ->   TCCR0B=(CS01);  TCNT0 = -14 ;
106
//             2             16666         8            -15 ->   TCCR0B=(CS01);  TCNT0 = -15 ;
107
//             2             15625         8            -16 ->   TCCR0B=(CS01);  TCNT0 = -16 ;
108
//             2             14705         8            -17 ->   TCCR0B=(CS01);  TCNT0 = -17 ;
109
//             2             13888         8            -18 ->   TCCR0B=(CS01);  TCNT0 = -18 ;
110
//             2             13157         8            -19 ->   TCCR0B=(CS01);  TCNT0 = -19 ;
111
//             2             12500         8            -20 ->   TCCR0B=(CS01);  TCNT0 = -20 ;
112
//             2             11904         8            -21 ->   TCCR0B=(CS01);  TCNT0 = -21 ;
113
//             2             11363         8            -22 ->   TCCR0B=(CS01);  TCNT0 = -22 ;
114
//             2             10869         8            -23 ->   TCCR0B=(CS01);  TCNT0 = -23 ;
115
//             2             10416         8            -24 ->   TCCR0B=(CS01);  TCNT0 = -24 ;
116
//             2             10000         8            -25 ->   TCCR0B=(CS01);  TCNT0 = -25 ;
117
//             3             15625         64           -3 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -3 ;
118
//             3             11718         64           -4 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -4 ;
119
//             3             20833         8            -18 ->   TCCR0B=(CS01);  TCNT0 = -18 ;
120
//             3             19736         8            -19 ->   TCCR0B=(CS01);  TCNT0 = -19 ;
121
//             3             18750         8            -20 ->   TCCR0B=(CS01);  TCNT0 = -20 ;
122
//             3             17857         8            -21 ->   TCCR0B=(CS01);  TCNT0 = -21 ;
123
//             3             17045         8            -22 ->   TCCR0B=(CS01);  TCNT0 = -22 ;
124
//             3             16304         8            -23 ->   TCCR0B=(CS01);  TCNT0 = -23 ;
125
//             3             15625         8            -24 ->   TCCR0B=(CS01);  TCNT0 = -24 ;
126
//             3             15000         8            -25 ->   TCCR0B=(CS01);  TCNT0 = -25 ;
127
//             3             14423         8            -26 ->   TCCR0B=(CS01);  TCNT0 = -26 ;
128
//             3             13888         8            -27 ->   TCCR0B=(CS01);  TCNT0 = -27 ;
129
//             3             13392         8            -28 ->   TCCR0B=(CS01);  TCNT0 = -28 ;
130
//             3             12931         8            -29 ->   TCCR0B=(CS01);  TCNT0 = -29 ;
131
//             3             12500         8            -30 ->   TCCR0B=(CS01);  TCNT0 = -30 ;
132
//             3             11718         256          -1 ->   TCCR0B = (CS02);   TCNT0 = -1 ;
133
//             4             20833         64           -3 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -3 ;
134
//             4             15625         64           -4 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -4 ;
135
//             4             12500         64           -5 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -5 ;
136
//             4             10416         64           -6 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -6 ;
137
//             4             20833         8            -24 ->   TCCR0B=(CS01);  TCNT0 = -24 ;
138
//             4             20000         8            -25 ->   TCCR0B=(CS01);  TCNT0 = -25 ;
139
//             4             19230         8            -26 ->   TCCR0B=(CS01);  TCNT0 = -26 ;
140
//             4             18518         8            -27 ->   TCCR0B=(CS01);  TCNT0 = -27 ;
141
//             4             17857         8            -28 ->   TCCR0B=(CS01);  TCNT0 = -28 ;
142
//             4             17241         8            -29 ->   TCCR0B=(CS01);  TCNT0 = -29 ;
143
//             4             16666         8            -30 ->   TCCR0B=(CS01);  TCNT0 = -30 ;
144
//             4             15625         256          -1 ->   TCCR0B = (CS02);   TCNT0 = -1 ;
145
//             5             19531         64           -4 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -4 ;
146
//             5             15625         64           -5 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -5 ;
147
//             5             13020         64           -6 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -6 ;
148
//             5             11160         64           -7 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -7 ;
149
//             5             20833         8            -30 ->   TCCR0B=(CS01);  TCNT0 = -30 ;
150
//             5             19531         256          -1 ->   TCCR0B = (CS02);   TCNT0 = -1 ;
151
//             6             18750         64           -5 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -5 ;
152
//             6             15625         64           -6 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -6 ;
153
//             6             13392         64           -7 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -7 ;
154
//             6             11718         64           -8 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -8 ;
155
//             6             10416         64           -9 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -9 ;
156
//             6             11718         256          -2 ->   TCCR0B = (CS02);   TCNT0 = -2 ;
157
//             7             18229         64           -6 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -6 ;
158
//             7             15625         64           -7 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -7 ;
159
//             7             13671         64           -8 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -8 ;
160
//             7             12152         64           -9 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -9 ;
161
//             7             10937         64           -10 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -10 ;
162
//             7             13671         256          -2 ->   TCCR0B = (CS02);   TCNT0 = -2 ;
163
//             7.373         19200         64           -6 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -6 ;
164
//             7.373         16457         64           -7 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -7 ;
165
//             7.373         14400         64           -8 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -8 ;
166
//             7.373         12800         64           -9 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -9 ;
167
//             7.373         11520         64           -10 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -10 ;
168
//             7.373         10473         64           -11 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -11 ;
169
//             7.373         14400         256          -2 ->   TCCR0B = (CS02);   TCNT0 = -2 ;
170
//             8             20833         64           -6 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -6 ;
171
//             8             17857         64           -7 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -7 ;
172
//             8             15625         64           -8 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -8 ;
173
//             8             13888         64           -9 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -9 ;
174
//             8             12500         64           -10 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -10 ;
175
//             8             11363         64           -11 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -11 ;
176
//             8             10416         64           -12 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -12 ;
177
//             8             15625         256          -2 ->   TCCR0B = (CS02);   TCNT0 = -2 ;
178
//             8             10416         256          -3 ->   TCCR0B = (CS02);   TCNT0 = -3 ;
179
//             9             20089         64           -7 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -7 ;
180
//             9             17578         64           -8 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -8 ;
181
//             9             15625         64           -9 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -9 ;
182
//             9             14062         64           -10 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -10 ;
183
//             9             12784         64           -11 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -11 ;
184
//             9             11718         64           -12 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -12 ;
185
//             9             10817         64           -13 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -13 ;
186
//             9             10044         64           -14 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -14 ;
187
//             9             17578         256          -2 ->   TCCR0B = (CS02);   TCNT0 = -2 ;
188
//             9             11718         256          -3 ->   TCCR0B = (CS02);   TCNT0 = -3 ;
189
//             10            19531         64           -8 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -8 ;
190
//             10            17361         64           -9 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -9 ;
191
//             10            15625         64           -10 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -10 ;
192
//             10            14204         64           -11 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -11 ;
193
//             10            13020         64           -12 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -12 ;
194
//             10            12019         64           -13 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -13 ;
195
//             10            11160         64           -14 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -14 ;
196
//             10            10416         64           -15 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -15 ;
197
//             10            19531         256          -2 ->   TCCR0B = (CS02);   TCNT0 = -2 ;
198
//             10            13020         256          -3 ->   TCCR0B = (CS02);   TCNT0 = -3 ;
199
//             11            19097         64           -9 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -9 ;
200
//             11            17187         64           -10 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -10 ;
201
//             11            15625         64           -11 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -11 ;
202
//             11            14322         64           -12 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -12 ;
203
//             11            13221         64           -13 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -13 ;
204
//             11            12276         64           -14 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -14 ;
205
//             11            11458         64           -15 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -15 ;
206
//             11            10742         64           -16 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -16 ;
207
//             11            10110         64           -17 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -17 ;
208
//             11            10742         1024         -1 ->   TCCR0B=(CS02| CS00);  TCNT0 = -1 ;
209
//             11            14322         256          -3 ->   TCCR0B = (CS02);   TCNT0 = -3 ;
210
//             11            10742         256          -4 ->   TCCR0B = (CS02);   TCNT0 = -4 ;
211
//             12            20833         64           -9 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -9 ;
212
//             12            18750         64           -10 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -10 ;
213
//             12            17045         64           -11 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -11 ;
214
//             12            15625         64           -12 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -12 ;
215
//             12            14423         64           -13 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -13 ;
216
//             12            13392         64           -14 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -14 ;
217
//             12            12500         64           -15 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -15 ;
218
//             12            11718         64           -16 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -16 ;
219
//             12            11029         64           -17 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -17 ;
220
//             12            10416         64           -18 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -18 ;
221
//             12            11718         1024         -1 ->   TCCR0B=(CS02| CS00);  TCNT0 = -1 ;
222
//             12            15625         256          -3 ->   TCCR0B = (CS02);   TCNT0 = -3 ;
223
//             12            11718         256          -4 ->   TCCR0B = (CS02);   TCNT0 = -4 ;
224
//             13            20312         64           -10 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -10 ;
225
//             13            18465         64           -11 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -11 ;
226
//             13            16927         64           -12 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -12 ;
227
//             13            15625         64           -13 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -13 ;
228
//             13            14508         64           -14 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -14 ;
229
//             13            13541         64           -15 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -15 ;
230
//             13            12695         64           -16 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -16 ;
231
//             13            11948         64           -17 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -17 ;
232
//             13            11284         64           -18 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -18 ;
233
//             13            10690         64           -19 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -19 ;
234
//             13            10156         64           -20 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -20 ;
235
//             13            12695         1024         -1 ->   TCCR0B=(CS02| CS00);  TCNT0 = -1 ;
236
//             13            16927         256          -3 ->   TCCR0B = (CS02);   TCNT0 = -3 ;
237
//             13            12695         256          -4 ->   TCCR0B = (CS02);   TCNT0 = -4 ;
238
//             13            10156         256          -5 ->   TCCR0B = (CS02);   TCNT0 = -5 ;
239
//             14            19886         64           -11 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -11 ;
240
//             14            18229         64           -12 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -12 ;
241
//             14            16826         64           -13 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -13 ;
242
//             14            15625         64           -14 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -14 ;
243
//             14            14583         64           -15 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -15 ;
244
//             14            13671         64           -16 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -16 ;
245
//             14            12867         64           -17 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -17 ;
246
//             14            12152         64           -18 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -18 ;
247
//             14            11513         64           -19 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -19 ;
248
//             14            10937         64           -20 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -20 ;
249
//             14            10416         64           -21 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -21 ;
250
//             14            13671         1024         -1 ->   TCCR0B=(CS02| CS00);  TCNT0 = -1 ;
251
//             14            18229         256          -3 ->   TCCR0B = (CS02);   TCNT0 = -3 ;
252
//             14            13671         256          -4 ->   TCCR0B = (CS02);   TCNT0 = -4 ;
253
//             14            10937         256          -5 ->   TCCR0B = (CS02);   TCNT0 = -5 ;
254
//             14.318        20338         64           -11 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -11 ;
255
//             14.318        18643         64           -12 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -12 ;
256
//             14.318        17209         64           -13 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -13 ;
257
//             14.318        15979         64           -14 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -14 ;
258
//             14.318        14914         64           -15 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -15 ;
259
//             14.318        13982         64           -16 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -16 ;
260
//             14.318        13159         64           -17 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -17 ;
261
//             14.318        12428         64           -18 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -18 ;
262
//             14.318        11774         64           -19 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -19 ;
263
//             14.318        11185         64           -20 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -20 ;
264
//             14.318        10653         64           -21 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -21 ;
265
//             14.318        10169         64           -22 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -22 ;
266
//             14.318        13982         1024         -1 ->   TCCR0B=(CS02| CS00);  TCNT0 = -1 ;
267
//             14.318        18643         256          -3 ->   TCCR0B = (CS02);   TCNT0 = -3 ;
268
//             14.318        13982         256          -4 ->   TCCR0B = (CS02);   TCNT0 = -4 ;
269
//             14.318        11185         256          -5 ->   TCCR0B = (CS02);   TCNT0 = -5 ;
270
//             15            19531         64           -12 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -12 ;
271
//             15            18028         64           -13 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -13 ;
272
//             15            16741         64           -14 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -14 ;
273
//             15            15625         64           -15 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -15 ;
274
//             15            14648         64           -16 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -16 ;
275
//             15            13786         64           -17 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -17 ;
276
//             15            13020         64           -18 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -18 ;
277
//             15            12335         64           -19 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -19 ;
278
//             15            11718         64           -20 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -20 ;
279
//             15            11160         64           -21 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -21 ;
280
//             15            10653         64           -22 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -22 ;
281
//             15            10190         64           -23 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -23 ;
282
//             15            14648         1024         -1 ->   TCCR0B=(CS02| CS00);  TCNT0 = -1 ;
283
//             15            19531         256          -3 ->   TCCR0B = (CS02);   TCNT0 = -3 ;
284
//             15            14648         256          -4 ->   TCCR0B = (CS02);   TCNT0 = -4 ;
285
//             15            11718         256          -5 ->   TCCR0B = (CS02);   TCNT0 = -5 ;
286
//             16            20833         64           -12 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -12 ;
287
//             16            19230         64           -13 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -13 ;
288
//             16            17857         64           -14 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -14 ;
289
//             16            16666         64           -15 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -15 ;
290
//             16            15625         64           -16 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -16 ;
291
//             16            14705         64           -17 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -17 ;
292
//             16            13888         64           -18 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -18 ;
293
//             16            13157         64           -19 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -19 ;
294
//             16            12500         64           -20 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -20 ;
295
//             16            11904         64           -21 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -21 ;
296
//             16            11363         64           -22 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -22 ;
297
//             16            10869         64           -23 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -23 ;
298
//             16            10416         64           -24 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -24 ;
299
//             16            10000         64           -25 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -25 ;
300
//             16            15625         1024         -1 ->   TCCR0B=(CS02| CS00);  TCNT0 = -1 ;
301
//             16            20833         256          -3 ->   TCCR0B = (CS02);   TCNT0 = -3 ;
302
//             16            15625         256          -4 ->   TCCR0B = (CS02);   TCNT0 = -4 ;
303
//             16            12500         256          -5 ->   TCCR0B = (CS02);   TCNT0 = -5 ;
304
//             16            10416         256          -6 ->   TCCR0B = (CS02);   TCNT0 = -6 ;
305
//             17            20432         64           -13 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -13 ;
306
//             17            18973         64           -14 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -14 ;
307
//             17            17708         64           -15 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -15 ;
308
//             17            16601         64           -16 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -16 ;
309
//             17            15625         64           -17 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -17 ;
310
//             17            14756         64           -18 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -18 ;
311
//             17            13980         64           -19 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -19 ;
312
//             17            13281         64           -20 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -20 ;
313
//             17            12648         64           -21 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -21 ;
314
//             17            12073         64           -22 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -22 ;
315
//             17            11548         64           -23 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -23 ;
316
//             17            11067         64           -24 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -24 ;
317
//             17            10625         64           -25 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -25 ;
318
//             17            10216         64           -26 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -26 ;
319
//             17            16601         1024         -1 ->   TCCR0B=(CS02| CS00);  TCNT0 = -1 ;
320
//             17            16601         256          -4 ->   TCCR0B = (CS02);   TCNT0 = -4 ;
321
//             17            13281         256          -5 ->   TCCR0B = (CS02);   TCNT0 = -5 ;
322
//             17            11067         256          -6 ->   TCCR0B = (CS02);   TCNT0 = -6 ;
323
//             18            20089         64           -14 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -14 ;
324
//             18            18750         64           -15 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -15 ;
325
//             18            17578         64           -16 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -16 ;
326
//             18            16544         64           -17 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -17 ;
327
//             18            15625         64           -18 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -18 ;
328
//             18            14802         64           -19 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -19 ;
329
//             18            14062         64           -20 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -20 ;
330
//             18            13392         64           -21 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -21 ;
331
//             18            12784         64           -22 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -22 ;
332
//             18            12228         64           -23 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -23 ;
333
//             18            11718         64           -24 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -24 ;
334
//             18            11250         64           -25 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -25 ;
335
//             18            10817         64           -26 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -26 ;
336
//             18            10416         64           -27 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -27 ;
337
//             18            10044         64           -28 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -28 ;
338
//             18            17578         1024         -1 ->   TCCR0B=(CS02| CS00);  TCNT0 = -1 ;
339
//             18            17578         256          -4 ->   TCCR0B = (CS02);   TCNT0 = -4 ;
340
//             18            14062         256          -5 ->   TCCR0B = (CS02);   TCNT0 = -5 ;
341
//             18            11718         256          -6 ->   TCCR0B = (CS02);   TCNT0 = -6 ;
342
//             18            10044         256          -7 ->   TCCR0B = (CS02);   TCNT0 = -7 ;
343
//             19            19791         64           -15 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -15 ;
344
//             19            18554         64           -16 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -16 ;
345
//             19            17463         64           -17 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -17 ;
346
//             19            16493         64           -18 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -18 ;
347
//             19            15625         64           -19 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -19 ;
348
//             19            14843         64           -20 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -20 ;
349
//             19            14136         64           -21 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -21 ;
350
//             19            13494         64           -22 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -22 ;
351
//             19            12907         64           -23 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -23 ;
352
//             19            12369         64           -24 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -24 ;
353
//             19            11875         64           -25 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -25 ;
354
//             19            11418         64           -26 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -26 ;
355
//             19            10995         64           -27 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -27 ;
356
//             19            10602         64           -28 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -28 ;
357
//             19            10237         64           -29 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -29 ;
358
//             19            18554         1024         -1 ->   TCCR0B=(CS02| CS00);  TCNT0 = -1 ;
359
//             19            18554         256          -4 ->   TCCR0B = (CS02);   TCNT0 = -4 ;
360
//             19            14843         256          -5 ->   TCCR0B = (CS02);   TCNT0 = -5 ;
361
//             19            12369         256          -6 ->   TCCR0B = (CS02);   TCNT0 = -6 ;
362
//             19            10602         256          -7 ->   TCCR0B = (CS02);   TCNT0 = -7 ;
363
//             20            20833         64           -15 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -15 ;
364
//             20            19531         64           -16 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -16 ;
365
//             20            18382         64           -17 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -17 ;
366
//             20            17361         64           -18 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -18 ;
367
//             20            16447         64           -19 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -19 ;
368
//             20            15625         64           -20 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -20 ;
369
//             20            14880         64           -21 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -21 ;
370
//             20            14204         64           -22 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -22 ;
371
//             20            13586         64           -23 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -23 ;
372
//             20            13020         64           -24 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -24 ;
373
//             20            12500         64           -25 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -25 ;
374
//             20            12019         64           -26 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -26 ;
375
//             20            11574         64           -27 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -27 ;
376
//             20            11160         64           -28 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -28 ;
377
//             20            10775         64           -29 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -29 ;
378
//             20            10416         64           -30 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -30 ;
379
//             20            19531         1024         -1 ->   TCCR0B=(CS02| CS00);  TCNT0 = -1 ;
380
//             20            19531         256          -4 ->   TCCR0B = (CS02);   TCNT0 = -4 ;
381
//             20            15625         256          -5 ->   TCCR0B = (CS02);   TCNT0 = -5 ;
382
//             20            13020         256          -6 ->   TCCR0B = (CS02);   TCNT0 = -6 ;
383
//             20            11160         256          -7 ->   TCCR0B = (CS02);   TCNT0 = -7 ;

von jar (Gast)


Lesenswert?

jar schrieb:
> so nun läufts endlich,

das sollte nicht fehlen

#define F_INTERRUPTS                            15625 // passend 
einsetzen

von jar (Gast)


Lesenswert?

kleines Problem, soweit klappt alles
1
//TCCR0B=(1<<CS01 | 1<<CS00);  TCNT0 = -7 ;  
2
//divide by 64; TCNT0 = -7; // 7 * 64 = 448 cycle
3
gibt F_INTERRUPTS  17857
4
oder
5
TCCR0B=(1<<CS02); TCNT0 = -2 ;  //TCCR0B = 1<<CS02;  //divide by 256; TCNT0 = -2;  // 2 * 256 = 512 cycle
6
gibt F_INTERRUPTS  15625
7
TIMSK0 = 1<<TOIE0;    //enable timer interrupt
8
9
SIGNAL (SIG_OVERFLOW0)
10
{
11
  TCNT0 = -2 ;  // 2*256=512 cycle mit F_CPU 8000000 alle 64µs->F_INT.15625
12
13
oder auch 
14
15
  TCNT0 = -7 ;  // 7*64=448 cycle mit F_CPU 8000000 alle 64µs->F_INT. 17857
16
  irmp_ISR ();
17
}

soweit so gut, wenn ich aber auf 71428 Interrupts möchte um auf F_SND 
36kHz zu kommen, mit
1
init_teil 
2
TCCR0B=(1<<CS01);  TCNT0 = -14 ; // divide 8 -> 8x14 = 112 cycle
3
TIMSK0 = 1<<TOIE0;    //enable timer interrupt
4
isr_cnt =4;
5
6
ISR
7
SIGNAL (SIG_OVERFLOW0)
8
{
9
  TCNT0 = -14 ;  // 14*8=112 cycle mit F_CPU 8000000 alle 4x->F_INT. 17857
10
  IR_ERKANNT_PORT ^= (1<<IR_ERKANNT); // sollte 36kHz haben (Messtoggel)
11
12
  if (!isr_cnt--)
13
  {  
14
    irmp_ISR (); // die IRMP_ISR wird nur jeden 4ten Interrupt aufgerufen
15
    isr_cnt =4;
16
  }
17
}

klappts nicht, kommt maximal 26 kHz raus
die IR Erkennung geht auch nicht

von Torsten K. (nobby)


Lesenswert?

Hallo,

hat schonmal jemand die Pollin Infrarot-Tastatur RUWIDO MERLIN mit 
Nummer  711 057 zum Laufen bekommen ?
Bislang habe ich hier nur die BestNr. gesehen, sonst aber noch nichts.
Das ist eine sehr schöne kleine Tastatur !!

Mit der Version 1.9.0 aus der SVN wird jedenfalls nichts erkannt. Ich 
könnte mal die Tasten Scannen, wenn das bisher noch keiner versucht hat 
?!

Gruß
Torsten

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Torsten Kalbe schrieb:

> hat schonmal jemand die Pollin Infrarot-Tastatur RUWIDO MERLIN mit
> Nummer  711 057 zum Laufen bekommen ?

Witzig, die habe ich mir vor 2 Wochen bestellt. Habe ich mittlerweile 
auch hier, bisher hatte ich aber noch keine Zeit gehabt, IRMP daran 
anzupassen.

Werde ich in den nächsten Tagen mal testen, denn das ist wirklich eine 
schöne kleine Tastatur.

Wenn IRMP damit funktioniert, melde ich mich wieder.

von Dominique G. (dgoersch)


Angehängte Dateien:

Lesenswert?

Hallo zusammen,

bin gerade erst auf diese IR-Lib gestossen, echt tolle arbeit! Werde sie 
sicher in dem ein oder anderen Projekt verwenden.

Hab auch gleich einen Wunsch: Das Protokoll der LEGO Powerfunctions. 
Lego hat sogar ein Dokument dazu veröffentlicht (hängt an).

Wäre es möglich dieses Protokoll hinzuzufügen?

Danke und Gruß
Dominique Görsch

von Dominique G. (dgoersch)


Lesenswert?

Nachtrag:

Hab gerade gesehen, dass es eine neuere Version des Dokuments gibt: 
http://storage.technicbricks.com/Media/2010/TBs_20100304_1/LEGO%20Power%20Functions%20RC%20v120.pdf

Dort sind zB auch die increment/decrement-Kommandos drin, die der 
LEGO-Zug meines Sohnes nutzt.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Dominique Görsch schrieb:

> Hab auch gleich einen Wunsch: Das Protokoll der LEGO Powerfunctions.
> Lego hat sogar ein Dokument dazu veröffentlicht (hängt an).
>
> Wäre es möglich dieses Protokoll hinzuzufügen?

Das Protokoll ist offenbar ein Pulse-Distance-Protokoll mit 16 Bit, 
wobei nur 12 Bit Nutzdaten vorhanden sind.

Es sieht ganz einfach aus. Willst Du das nur decodieren oder auch 
senden?
Die eigentlichen Inhalte wird IRMP nicht weiter interpretieren, sondern 
Dir einfach die 12 Bit liefern.

Ich bau das mal in den nächsten Tagen ein.

Gruß,

Frank

von Dominique G. (dgoersch)


Lesenswert?

Sowohl als auch wäre genial. Ich plane zum einen eigene Receiver die 
dann mit der LEGO Fernbedienung steuerbar sind, zum anderen aber auch 
das automatische Steuern zB von Zügen.

Super, dass du es gleich implementieren willst. Reichen dir die Infos 
aus dem Paper oder kann ich dir noch anderweitig (zB mit Scans) helfen?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Dominique Görsch schrieb:
> Super, dass du es gleich implementieren willst. Reichen dir die Infos
> aus dem Paper oder kann ich dir noch anderweitig (zB mit Scans) helfen?

Es wäre natürlich nett, wenn Du auch ein paar Scans machen könntest. 
Graue Theorie ist die eine Geschichte, Praxis oft eine andere :-)

Gruß,

Frank

von Dominique G. (dgoersch)


Lesenswert?

Kein Problem, werde ich machen. Muss deinen Code dafür nur etwas 
umstricken weil ich in meiner Firmware sowieso UART mit 250kBaud (USB) 
drin hab. Wird heute aber wohl eher nixmehr...

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Dominique Görsch schrieb:
> Sowohl als auch wäre genial. Ich plane zum einen eigene Receiver die
> dann mit der LEGO Fernbedienung steuerbar sind, zum anderen aber auch
> das automatische Steuern zB von Zügen.

Im SVN ist nun ein IRMP/IRSND mit dem LEGO-Protokoll zu finden. 
Maßgeblich sind in irmp_data.command die unteren 12 Bits, die je nach 
Inhalt von der Anwendung zu prüfen sind - anlehnend an die 
LEGO-Dokumentation. irmp_data.address ist immer 0.

IRMP liest die 16 Bits des LEGO-Telegramm ein und checkt das letzte 
Nibble im XOR-Verfahren gegen die anderen 3 Nibbles. Kommt der richtige 
Wert raus, gibt IRMP die 12 Bit an Nutzdaten zurück.

Umgekehrt kann man die 12 Bits an IRSND in irmp_data.command übergeben. 
IRSND "konstruiert" daraus das fehlende letzte Nibble und schickt 
anschließend den kompletten Frame mit 16 Bit raus.

Als letzte Info: Man braucht eine Interrupt-Frequenz von 20kHz, da die 
Pulse ziemlich kurz sind. Wenn Du noch Scans machen möchtest, dann bitte 
mit 20kHz.

Ich hoffe, ich habe keinen Fehler gemacht, bitte testen.

Gruß,

Frank

von Torsten K. (nobby)


Lesenswert?

Hy Frank,

wie ist es denn mit der Unterstützung für die kleine Pollin Tasttatur 
"Merlin" ?
Hast Du da schon was erreichen können ?

Gruß
Torsten

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Torsten K. schrieb:
> wie ist es denn mit der Unterstützung für die kleine Pollin Tasttatur
> "Merlin" ?
> Hast Du da schon was erreichen können ?

Nein, noch nicht. Da werde ich wohl vor dem nächsten Wochenende nicht zu 
kommen. Wenn Du mir helfen willst, kannst Du gern vorabe schon mal ein 
paar Scans mit IRMP machen. Das würde mir eine Menge Arbeit abnehmen.

Gruß,

Frank

von Torsten K. (nobby)


Lesenswert?

Hi,

ja, werde mal sehen, wie ich die Tage dazu komme, sollte aber möglich 
sein.

Bis dann
Torsten

von Joachim B. (Gast)


Lesenswert?

Frank M. schrieb:
> Sollte gehen. Wenns läuft, schick mir bitte Deine Code-Änderungen. Dann
> baue ich das als Alternative zum 16-Bit-Timer ein.
>
> Gruß,
>
> Frank

läuft prima, erstzt nun den dani code und mein Timer kann immer mehr, 
nicht nur timen, sondern auch FB testen :-)
1
/* ======================================================================
2
3
C Source File -- Created with SAPIEN Technologies Primalscript(TM)
4
5
NAME: <filename>
6
7
AUTHOR: jar , test
8
DATE  : 12.04.2011
9
10
COMMENT: <comment>
11
12
====================================================================== */
13
#define F_INTERRUPTS F_CPU/512   // Timer0 RC5 dannegger 64µs bei 8 MHz oder anders gesprochen F_CPU/512 = 15625
14
//#define F_INTERRUPTS F_CPU/448   // Timer0 F_CPU/448 = 17857
15
16
void timer0_init(void)
17
{  TCCR0B = 1<<CS02;      //divide by 256
18
  //TCCR0B = (CS01 | CS00);    //divide by 64 
19
  TIMSK0 |= (1<<TOIE0);    //enable timer interrupt
20
}
21
22
SIGNAL (SIG_OVERFLOW0)
23
{  
24
  uint tmp = rc5_tmp;      // for faster access
25
26
  TCNT0 = -2;          // gibt mit divide by 256 genau 512 Takte zum Interrrupt
27
  //TCNT0 = -7;          // gibt mit divide by 64 genau 448 Takte zum Interrrupt
28
  irmp_ISR();
29
}
30
31
// die würden sich auch bei 8 MHz anbieten
32
//            TCCR0B
33
//            CS02  CS01  CS00  Description
34
//            0     0     0     No clock source (Timer/Counter stopped)
35
//            0     0     1     clkI/O/(No prescaling)
36
//            0     1     0     clkI/O/8 (From prescaler)
37
//            0     1     1     clkI/O/64 (From prescaler)
38
//            1     0     0     clkI/O/256 (From prescaler)
39
//            1     0     1     clkI/O/1024 (From prescaler)
40
//            F_CPU / MHz   Interrupts    TCCR0B        TCNT0
41
//             8             20833         64           -6 ->   #define F_INTERRUPTS  20833   ;TCCR0B = (CS01 | CS00);  TCNT0 = -6 ;
42
//             8             17857         64           -7 ->   #define F_INTERRUPTS  17857   ;TCCR0B = (CS01 | CS00);  TCNT0 = -7 ;
43
//             8             13888         64           -9 ->   #define F_INTERRUPTS  13888   ;TCCR0B = (CS01 | CS00);  TCNT0 = -9 ;
44
//             8             12500         64           -10 ->   #define F_INTERRUPTS  12500   ;TCCR0B = (CS01 | CS00);  TCNT0 = -10 ;
45
//             8             15625         256          -2 ->   #define F_INTERRUPTS  15625   ;TCCR0B = (CS02);      TCNT0 = -2 ;
46
//             8             11363         64           -11 ->   #define F_INTERRUPTS  11363   ;TCCR0B = (CS01 | CS00);  TCNT0 = -11 ;
47
//             8             10416         256          -3 ->   #define F_INTERRUPTS  10416   ;TCCR0B = (CS02);      TCNT0 = -3 ;

von Dominique G. (dgoersch)


Lesenswert?

Sorry, ich komme im Moment leider nicht zum Testen, trotzdem schonmal 
ein Danke für die schnelle Implementation.

von Joachim B. (Gast)


Angehängte Dateien:

Lesenswert?

an Frank (ukw)

habe eine FB die IRMP nicht erkennt

daewoo Videorecorder V-737

die FB ist defekt, nur noch 3/4 ? Tasten funktionieren IR Led leuchtet
output_2011-04-15_09-02-22.log

Tasten PROG, <- , -INDEX

habe eine Nachbau FB bestellt
1 90 11 54 22 daewoo 97p1r2taa0 DAEWOO 97P1RA1AA0

die sendet auf den Tasten (PROG Taste nicht gefunden)
Tasten <- , -INDEX
output_2011-04-15_09-05-56.log

kannst du den Code erkennen ?

kannst du die "gleichen" Codes ? vergleichen ?

und evt. sagen um was für einen Code es sich handelt ?

#define F_INTERRUPTS                            17857
#define F_CPU                            8000000


wenn nötig, mehr Codes aus der Ersatz FB

von Joachim B. (Gast)


Lesenswert?

Joachim B. schrieb:
> an Frank (ukw)
>
> habe eine FB die IRMP nicht erkennt

kann die Nachbau FB nicht vorher testen weil der VCR im Ausland steht

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi Joachim,

Joachim B. schrieb:
> an Frank (ukw)
>
> habe eine FB die IRMP nicht erkennt

Doch, wird erkannt. Das ist das NEC16-Protokoll (eine verkürzte Variante 
des 32-Bit-NEC-Protokolls, dafür aber mit Sync-Bit nach den 8 
Adressbits).

Protokoll: 27
Adresse: 0x0015

Habe ich erst vor ein paar Wochen eingebaut, findest Du im Download des 
SVN.

Gruß,

Frank

von Joachim B. (Gast)


Lesenswert?

Frank M. schrieb:
> Habe ich erst vor ein paar Wochen eingebaut, findest Du im Download des
> SVN.
>
> Gruß,
>
> Frank

hast du ne Idee warum ich bei F_INTERRUPTS 17857 -> 25 warnings bekomme 
?

manche Codes brauchen doch sogar 20000 ! OK mit 15500 gehts aber wenn 
20000 geht sollte 17857 nicht meckern

../irmp.c:1106: warning: integer overflow in expression
../irmp.c:1107: warning: integer overflow in expression
../irmp.c:1108: warning: integer overflow in expression
../irmp.c:1109: warning: integer overflow in expression
../irmp.c:1157: warning: integer overflow in expression
../irmp.c:1158: warning: integer overflow in expression
../irmp.c:1159: warning: integer overflow in expression
../irmp.c:1160: warning: integer overflow in expression
../irmp.c:1260: warning: integer overflow in expression
../irmp.c:1261: warning: integer overflow in expression
../irmp.c:1262: warning: integer overflow in expression
../irmp.c:1263: warning: integer overflow in expression
../irmp.c: In function 'irmp_ISR':
../irmp.c:2033: warning: integer overflow in expression
../irmp.c:2033: warning: integer overflow in expression
../irmp.c:2035: warning: integer overflow in expression
../irmp.c:2035: warning: integer overflow in expression
../irmp.c:2079: warning: integer overflow in expression
../irmp.c:2080: warning: integer overflow in expression
../irmp.c:2184: warning: integer overflow in expression
../irmp.c:2184: warning: integer overflow in expression
../irmp.c:2186: warning: integer overflow in expression
../irmp.c:2186: warning: integer overflow in expression

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:

> hast du ne Idee warum ich bei F_INTERRUPTS 17857 -> 25 warnings bekomme
> ?

Habs mir gerade angeschaut, das hat was mit einer kürzlich von mir 
geänderten Behandlung der 2-fachen Längen von Pulsen/Pausen im 
Manchester-Decoder zu tun. Ich wollte da Code einsparen, hab aber nicht 
bedacht, dass da Variablen "platzen" könnten. Ich repariere das am 
Wochenende. Entweder Du gehst auf 15kHz runter oder Du verzichtest 
erstmal auf RC5 und Co.

Gruß,

Frank

von Joachim B. (Gast)


Lesenswert?

Frank M. schrieb:
> Ich repariere das am
> Wochenende.

fein, gib dann mal Bescheid, dann lade ich die reparierte

hast du schon die 8-bit Timer0 Variante eingebaut ?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:
> hast du schon die 8-bit Timer0 Variante eingebaut ?

Nein, habe ich noch nicht. Bei der 16-Bit-Timer-Variante werden die 
Werte für die Timer-Register über eine Formel, die lediglich von F_CPU 
und F_INTERRUPTS abhängig sind, automatisch initialisiert. Da muss man 
nichts anpassen.

Bei Deiner Timer0-Variante muss man eine Tabelle heranziehen und dann 
die Werte abtippen und damit den eigentlichen Code ändern. Das ist nicht 
so schön, geht aber wohl nicht anders. Deshalb überlege ich noch hin und 
her, wie ich das am besten allgemeingültig in den Code einbaue.

von Joachim B. (Gast)


Lesenswert?

Frank M. schrieb:
> Bei Deiner Timer0-Variante muss man eine Tabelle heranziehen und dann
> die Werte abtippen und damit den eigentlichen Code ändern. Das ist nicht
> so schön, geht aber wohl nicht anders. Deshalb überlege ich noch hin und
> her, wie ich das am besten allgemeingültig in den Code einbaue.

ich weiss

lauter #if F_CPU == && F_INTRRUPTS ==

ist auch keine Lösung

schade das der Precompiler nicht rechnen kann

die Teilerstufen sind auch nicht linear 2^n

wegen 0 8 64 256 1024 gibt 2^0 2^3 2^6 2^8 2^10

kleiner 6 step 3
else step 2

eine Tabelle einfügen ?

von eku (Gast)


Lesenswert?

Hallo,

in ethersex verwendet IRMP wahlweise Timer 0 oder 2. Der Vorteiler wird
in abhängigkeit von F_CPU und Abtastrate zur Compilezeit berechnet, ganz 
ohne Tabelle.

https://github.com/ethersex/ethersex/blob/12710c72d560ec0e60382bd1778912702a63c3d7/hardware/ir/irmp/irmp.c

von Cajus H. (cajush)


Angehängte Dateien:

Lesenswert?

Hallo Frank,

erst mal ein großes Lob, Dein IRMP ist große Klasse!

Ich spiele mit dem Gedanken mir eine programmierbare Fernbedienung zu 
basteln, die mit einem 5" Touch etwa so viel kann wie die Philips 
Pronto.
Leider hat Philips die Herstellung dieser genialen Fernbedienungen 
eingestellt und es gibt keinen Hersteller, der etwas vergleichbares 
anbieten kann, zumindest nicht unter 1400€.

Ich habe also alle 20 Originalfernbedienungen aus dem Keller geholt und 
IRMP mit allen Protokollen (ausser Lego) auf meinem ATmega32 zum Laufen 
gebracht.

Dabei bin ich auf eine Fernbedienung gestossen, die scheinbar von IRMP 
nicht erkannt wird. Es handelt sich um eine Fernbedienung für einen 
älteren Thomson TV, die Fernbedienung nennt sich "mb100". Die 
Modulationsfrequenz ist ca. 33kHz (mit dem Oszi nachgemessen), der 
Empfänger ist ein TSOP1738 (38kHz), also passt nicht ganz zur 
Modulationsfrequenz, sollte aber trotzdem noch gehen.

Könntest Du mal schauen, ob Du mit den Scans etwas anfangen kannst?
Es wäre schön, wenn man das Protokoll noch implementieren könnte.

Gruß
Cajus

Hoppla, irgendwie ist mein Dateianhang doppelt vorhanden!?
Weis jemand wie man Dateianhänge wieder löschen kann?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Cajus H. schrieb:

> erst mal ein großes Lob, Dein IRMP ist große Klasse!

Danke :-)

> Ich spiele mit dem Gedanken mir eine programmierbare Fernbedienung zu
> basteln, die mit einem 5" Touch etwa so viel kann wie die Philips
> Pronto.

Das sagt mir jetzt nichts, aber ich vermute, dass es sich um eine 
programmierbare FB handelt, bei dem das Tastenlayout auf dem Display 
frei wählbar ist?

Vielleicht schaust Du Dir dazu mal

  http://www.mikrocontroller.net/articles/DIY_Lernf%C3%A4hige_Fernbedienung_mit_IRMP

an. Diese kann die Codes lernen und im EEPROM abespeichern. Ich weiß, 
hier gibt es zwar nur 5 Tasten, aber vielleicht kannst Du da was von 
übernehmen oder zumindest die eine oder andere Anregung erhalten :-)

> Ich habe also alle 20 Originalfernbedienungen aus dem Keller geholt und
> IRMP mit allen Protokollen (ausser Lego) auf meinem ATmega32 zum Laufen
> gebracht.

Super!

> Dabei bin ich auf eine Fernbedienung gestossen, die scheinbar von IRMP
> nicht erkannt wird. Es handelt sich um eine Fernbedienung für einen
> älteren Thomson TV, die Fernbedienung nennt sich "mb100". Die
> Modulationsfrequenz ist ca. 33kHz (mit dem Oszi nachgemessen), der
> Empfänger ist ein TSOP1738 (38kHz), also passt nicht ganz zur
> Modulationsfrequenz, sollte aber trotzdem noch gehen.
>
> Könntest Du mal schauen, ob Du mit den Scans etwas anfangen kannst?
> Es wäre schön, wenn man das Protokoll noch implementieren könnte.

Habs mir gerade mal kurz mit "irmp-15kHz -a" unter Linux angeschaut. Das 
Protokoll ist sehr einfach gehalten:

- Jeder Frame wird 2 mal wiederholt (also insgesamt 3 Frames)
- Kein Startbit
- Framelänge 12 Bit
- Pulslänge: 550 µs
- Pausen: 1990 µs oder 4523µs

Ich schaue mal, ob ich das morgen früh mal einbaue, sollte nicht 
schwierig sein. Dank der Fülle Deiner Scans sollte ich auch noch 
herausbekommen, wieviele Bits zur Adresse und wieviele zum Kommando 
gehören.

Eine Frage hätte ich noch: Hast Du die Tasten kurz gedrückt oder länger? 
Die 2 Wiederholungen eines jeden Frames sind etwas untypisch. Eventuell 
müsstest Du das nochmal testen, sobald IRMP das Thomson-Protokoll 
"versteht". Nicht dass zumindest der 3. Frame eine Wiederholung ist, die 
durch langes Drücken einer Taste zustandekam...

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Lesenswert?

Mich hat es doch in den Fingern gejuckt und ich habe gerade mal das 
Thomson-Protokoll in den IRMP eingebaut. Da es so einfach ist, hat es 
gerade mal 20 Minuten gebraucht :-)

Neue Erkenntnisse:

- Der Frame setzt sich aus einer 4-Bit-Adresse und 8-Bit Daten zusammen
- MSB oder LSB first ist noch unbekannt, lässt sich leider nicht aus den
  Tasten 0 bis 9 erkennen
- Frame-Wiederholungen werden im Moment noch als Tasten-Wiederholungen
  (flag = 0x01) erkannt. Das muss noch angepasst werden, sobald klar
  ist, wieviele Frames bei kurzem! Tastendruck erzeugt werden

@Cajus H. (cajush):

Teste das bitte mal. Gemeinsam sollten wir das dann hinbekommen.

Im Anhang findest Du die gegenüber dem SVN geänderten Sources.

Achja: Da kommt im Moment noch eine Compiler-Warnung, die Du ignorieren 
kannst... ist halt noch ein Prototyp.

Gruß,

Frank

von Cajus H. (cajush)


Angehängte Dateien:

Lesenswert?

Hallo Frank,

>> Philips Pronto...
> Das sagt mir jetzt nichts, aber ich vermute, dass es sich um eine
> programmierbare FB handelt, bei dem das Tastenlayout auf dem Display
> frei wählbar ist?

Ja genau und zwar WIRKLICH frei wählbar mit Tastenform, Tastengröße, 
Anordnung der Tasten, beliebige Macros und vielem mehr. Es gab eine 
Variante mit Graustufen-Touch und eine Variante mit Farb-Touch, ich habe 
eine ältere Graustufen-Variante mit relativ kleinem Touch. Im Anhang 
sind ein paar Seiten meiner Pronto.
Als Basis für eine Touch-FB habe ich dieses Modul im Auge 
http://shop.embedded-projects.net/index.php?module=artikel&action=artikel&id=459 
, erweitert um einen ATmega mit IRSND.

> Thomson Protokoll...
Ich habe eine Scan-Datei in den Anhang gepackt, bei der ich kurze und 
lange Tastendrücke dokumentiert habe. Der kurze Tastendruck ist SEHR 
kurz, normalerweise kommen zwei Ausgaben mit Code,Address und Command.
Man kann ausserdem erkennen, dass das letzte Bit ein Toggle-Bit (analog 
zum RC5 von Philips) ist. Das Bit togglet bei jedem Tastendruck, egal ob 
kurz oder lang. Es togglet auch beim Drücken von unterschiedlichen 
Tasten.

Ich habe Dir außerdem mal meine Source-Dateien angehängt.
Darin sind ein paar kleine Änderungen:
- Versionsnummer aktualisiert (sollte man eigentlich besser in einer 
Header-Datei festlegen als in der printf-Ausgabe, ich war aber zu faul 
;-)
- printf-Unterstützung auch für gcc (war nur für CODEVISION drin)
- Namen der Protokolle erweitert

Gibt es eigentlich irgendwo eine Sammlung mit Scancodes?
Ich habe mal angefangen die Codes meiner FBs in eine Tabelle zu packen, 
aber vielleicht gibt es schon eine vergleichbare Sammlung. Ich habe den 
aktuellen Stand der Liste auch mal angehängt, es fehlen noch einige FBs. 
Eigentlich eine Anwendung für eine Datenbank...

Gruß
Cajus

von Cajus H. (cajush)


Angehängte Dateien:

Lesenswert?

Hallo Frank,

hier noch einmal meine modifizierten IRMP Sourcen, bei den obigen hatte 
sich ein Fehler eingeschlichen, der das Übersetzen mit IRMP_LOGGING = 0 
verhinderte. Das resultierte daher, weil ich Deine Uart-Initialisierung 
nach main() kopiert hatte, die Definition der Register aber nur bei 
IRMP_LOGGING = 1 gemacht wird. Daher habe ich diese Definitionen nach 
irmp.h verlegt.

Ich habe die Version nach irmp.h verschoben und gebe bei printf nur noch 
%s aus.


In Deinem Code war auch noch ein kleiner Fehler, den ich allerdings auch 
schon in der letzten Version meiner Sourcen behoben hatte: irmp.c

vor
static PROGMEM IRMP_PARAMETER thomson_param =
steht
#if IRMP_SUPPORT_DENON_PROTOCOL == 1
das sollte vermutlich
#if IRMP_SUPPORT_THOMSON_PROTOCOL == 1
heissen, oder?

Gruß
Cajus

von Torsten K. (nobby)


Angehängte Dateien:

Lesenswert?

Hallo Frank,

hier sind ein paar Scans der Pollin Merlin Tastatur, hat etwas länger 
gedauert.
Gemacht mit  F_INTERRUPTS 20000.
Wenn Du noch mehr brauchst, oder bei Fragen, sag bescheid.

Gruß
Torsten

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Cajus H. schrieb:
>> Thomson Protokoll...
> Ich habe eine Scan-Datei in den Anhang gepackt, bei der ich kurze und
> lange Tastendrücke dokumentiert habe. Der kurze Tastendruck ist SEHR
> kurz, normalerweise kommen zwei Ausgaben mit Code,Address und Command.
> Man kann ausserdem erkennen, dass das letzte Bit ein Toggle-Bit (analog
> zum RC5 von Philips) ist. Das Bit togglet bei jedem Tastendruck, egal ob
> kurz oder lang. Es togglet auch beim Drücken von unterschiedlichen
> Tasten.

Sehr gut. Bei kurzen Tastendrücken gibt es nur einen einzigen Frame. Das 
macht die Sache leichter. Danke für den Tipp mit dem Toggle-Bit. IRMP 
blendet das nun aus. Damit konnte ich dann sehen, dass die 
Bit-Reihenfolge MSB-First ist, denn die untereinander liegenden Tasten 
0,4,7 / 2,5,8 / 3,6,9 haben damit eine aufsteigende Reihenfolge. Das 
ergibt folgende Codeänderungen:
1
#define THOMSON_COMMAND_OFFSET                  5                               // skip 4 address bits + 1 toggle bit
2
#define THOMSON_COMMAND_LEN                     7                               // read 7 command bits
3
#define THOMSON_LSB                             0                               // MSB...LSB

> Ich habe Dir außerdem mal meine Source-Dateien angehängt.
> Darin sind ein paar kleine Änderungen:
> - Versionsnummer aktualisiert (sollte man eigentlich besser in einer
> Header-Datei festlegen als in der printf-Ausgabe, ich war aber zu faul
> ;-)

Die Versionsnummer, die im Codevision-Teil steht, habe ich nie gepflegt. 
Ich überlege mittlerweile auch, die Codevision-Unterstützung komplett 
rauszuwerfen, da ich diese mangels Codevision-Compiler sowieso nicht 
unterstützen kann. Das würde den Code etwas übersichtlicher machen - 
zumindest in main.c.

> - printf-Unterstützung auch für gcc (war nur für CODEVISION drin)

Schaue ich mir mal an. Eigentlich hat das aber nichts im IRMP zu suchen. 
Die main.c ist eigentlich nur ein Beispiel-Code und nicht wirklich 
Bestandteil des IRMP.

> - Namen der Protokolle erweitert

Ja, eben, das wurde nicht gepflegt. Eigentlich will ich das auch gar 
nicht ;-)

> Gibt es eigentlich irgendwo eine Sammlung mit Scancodes?

Es gibt das LIRC-Projekt. Ob es sinnvoll ist, für IRMP auch so etwas zu 
machen, weiß ich nicht.

Cajus H. schrieb:

> In Deinem Code war auch noch ein kleiner Fehler, den ich allerdings auch
> schon in der letzten Version meiner Sourcen behoben hatte: irmp.c
>
> vor
> static PROGMEM IRMP_PARAMETER thomson_param =
> steht
> #if IRMP_SUPPORT_DENON_PROTOCOL == 1
> das sollte vermutlich
> #if IRMP_SUPPORT_THOMSON_PROTOCOL == 1
> heissen, oder?

Ja, danke, das war ein Copy&Paste-Fehler.

Ich werde meine Änderungen bzgl. Thomson-Protkoll morgen mal ins SVN 
einchecken.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Torsten K. schrieb:
> hier sind ein paar Scans der Pollin Merlin Tastatur, hat etwas länger
> gedauert.

Vielen Dank. Auf den ersten Blick ist das ein Bitserielles Protokoll - 
analog zur Netbox. Also weder Manchester noch Pulse-Distance, wie es bei 
Fernbedienungen üblich ist. Ich schaue mal, dass ich da einen ersten 
Prototyp im Laufe der kommenden Woche baue.

> Wenn Du noch mehr brauchst, oder bei Fragen, sag bescheid.

Danke, ich melde mich dann :-)

Gruß,

Frank

von Joachim B. (Gast)


Lesenswert?

Frank M. schrieb:
>> Gibt es eigentlich irgendwo eine Sammlung mit Scancodes?
>
> Es gibt das LIRC-Projekt. Ob es sinnvoll ist, für IRMP auch so etwas zu
> machen, weiß ich nicht.

fände ich sinnvoll, wenn z.B. eine FB kaputt geht kann man nix machen, 
würde man die Codes finden könnte man eine FB nachprogrammieren und sei 
es wenn man IRSND nur dazu benutzt eine lernfähige anzulernen, ich 
musste für Vaters VCR FB die teure Nachbau FB bestellen, hätte ich die 
Codes gefunden, genügte IRSND + eine billige Lern FB

von Joachim B. (Gast)


Lesenswert?

@frank (ukw)

gibt es die Möglichkeit das RC5 toogle Bit wieder einzufügen ?

ich hatte ja vorher den dani RC5 Code drin und nun auf IRMP umgestellt, 
Address und Data konnte ich kompatibel erstellen, aber mir fehlt zu 
einfachen Auswertung das toogle Bit für gleiche Taste oder neue Taste

irgendwie schaffe ich es nicht nur 1 Tastendruck auszuwerten, egal wie 
ich drücke entweder wird nix erkannt, zu kurz, oder zu lang und ich 
bekomme 2 steps zum einstellen, mit toogle bit wärs leichter

danke

gruss
jar

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:

> gibt es die Möglichkeit das RC5 toogle Bit wieder einzufügen ?

Ich sehe dafür eigentlich keine Notwendigkeit. IRMP ignoriert das 
Toggle-Bit, weil es meines Erachtens überflüssig ist. Zum "Entprellen" 
der Tastatur stellt IRMP andere (kompatible) Methoden zur Verfügung, 
s.u.

> ich hatte ja vorher den dani RC5 Code drin und nun auf IRMP umgestellt,
> Address und Data konnte ich kompatibel erstellen, aber mir fehlt zu
> einfachen Auswertung das toogle Bit für gleiche Taste oder neue Taste

Das ist einfach: IRMP setzt in flags das BIT IRMP_FLAG_REPETITION, wenn 
eine Wiederholung durch langen Tastendruck entsteht, siehe auch 
IRMP-Artikel.

Einfache Abfrage:
1
    if (irmp_data.flags & IRMP_FLAG_REPETITION)
2
    {
3
      // Benutzer hält die Taste länger runter
4
      // entweder:
5
      //   ich ignoriere die (Wiederholungs-)Taste
6
      // oder:
7
      //   ich benutze diese Info, um einen Repeat-Effekt zu nutzen
8
    }
9
    else
10
    {
11
      // Es handelt sich um eine neue Taste
12
    }

So ist das für alle von IRMP unterstützten Protokolle kompatibel gelöst 
- egal, ob das Protokoll ein Toggle-Bit bereitstellt oder nicht.

> irgendwie schaffe ich es nicht nur 1 Tastendruck auszuwerten, egal wie
> ich drücke entweder wird nix erkannt, zu kurz, oder zu lang und ich
> bekomme 2 steps zum einstellen, mit toogle bit wärs leichter

Ignoriere einfach alle Frames, wo das Bit IRMP_FLAG_REPETITION gesetzt 
ist.

Also in Deinem Fall:
1
    if (! (irmp_data.flags & IRMP_FLAG_REPETITION))
2
    {
3
      // Es handelt sich um eine neue Taste
4
      // ACTION!
5
    }

Und schon hast Du Deine FB-Tasten "entprellt" ;-)

Gruß,

Frank

von Joachim B. (Gast)


Lesenswert?

Frank M. schrieb:
> Also in Deinem Fall:
>     if (! (irmp_data.flags & IRMP_FLAG_REPETITION))
>     {
>       // Es handelt sich um eine neue Taste
>       // ACTION!
>     }
>
> Und schon hast Du Deine FB-Tasten "entprellt" ;-)
>
> Gruß,
>
> Frank

funzt, nur natürlich kein repeat mehr.....

ich muss mal sehen evt. muss ich aus diesen Infos das toogle Bit 
nachbauen

oder ich blicke noch nicht durch wie ich kurz und lang auswerten kann 
ohne delay !

ich weiss die Lösung hast du schon beschrieben, nur muss ich das in 
meinen Code pressen, oder meinen code neu schreiben, mal sehen

danke
jar

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:

> funzt, nur natürlich kein repeat mehr.....

Wie hast Du denn mit dem Toggle-Bit das Repeat gemacht? Wenn das 
Toggle-Bit sich nicht(!) ändert, dann Repeat wegen langem Tastendruck? 
Das entspricht doch dem Fall, dass das IRMP-Flag gesetzt ist.

Brauchst Du für jede Taste ein Repeat? Oder nur für bestimmte?

> ich weiss die Lösung hast du schon beschrieben, nur muss ich das in
> meinen Code pressen, oder meinen code neu schreiben, mal sehen

Vielleicht zeigst Du mal einen Auszug aus Deinem Code?

Gruß,

Frank

von Joachim B. (Gast)


Lesenswert?

so ungefähr, muss mich nach 3 Jahren selber wieder einfummeln, bin halt 
kein begnadeter progger, nur für den Hausgebrauch :-)

// Auszug
1
L_Com=(irmp_data.address*100)+irmp_data.command;
2
3
switch( L_Com&0x7fff )
4
// kein repeat
5
case PINN_PLAY:  // programm ausführen pinnacle taste "||>"
6
case 3053:  // programm ausführen hauppauge taste ">"
7
 if(Old_L_Com != L_Com)
8
  res_key=(1<<KEY6);
9
break;
10
11
// repeat möglich
12
case PINN_PLUS:  // kon up pinnacle taste "VOL up"
13
case 3016:  // kon up hauppauge taste "VOL up"
14
k_plus();
15
break;
16
17
aus dani code
18
void fb(void)
19
{  if( i_ )
20
  {  //_toggelbit = ( i_ >> 11 & 1);
21
    L_Com  =  (i_ >> 6 & 0x1F)*100;
22
      L_Com  +=  (i_ & 0x3F) | (~i_ >> 7 & 0x40);

von Cajus H. (cajush)


Lesenswert?

Hallo Frank,

>> Thomson Protokoll...
> Ich werde meine Änderungen bzgl. Thomson-Protkoll morgen mal ins SVN
> einchecken.
Kann es sein, dass Du noch nicht dazu gekommen bist? ;-)

Nachdem ich die Fernbedienungen aller z.Zt. in Gebrauch befindlichen 
Geräte mit IRMP einlesen konnte stehe ich nun vor der Aufgabe IRSND in 
Betrieb zu nehmen. Der aktuelle Code aus dem SVN funktionierte auf 
Anhieb, zumindest kam ein IR-Signal im 1 sec. Rythmus. Wie ich oben 
schon erwähnt habe, möchte ich eine Programmierbare FB mit Touch-Screen 
bauen. Die Touch-Software erkennt einen Tastendruck und sendet einen 
"Taste Gedrückt" Event an IRSND, zusammen mit dem Wert für Protokoll, 
Adresse und Komando. Wird der Finger vom Touch genommen kommt der "Taste 
Losgelassen" Event. In der Zwischenzeit sollte IRSND das entsprechende 
Kommando senden.

Frage: Wie lässt sich das mit IRSND realisieren?

Ein einfaches Wiederholen des Komandos bis zum Taste Losgelassen Event 
dürfte nicht funktionieren. Ich habe Funktionen, die unterschiedlich auf 
lange und kurze Tastendrücke reagieren. Beispiel Licht Schalten/Dimmen: 
Ein kurzer Tastendruck schaltet das Licht ein/aus, ein langer 
Tastendruck dimmt heller/dunkler. Hier wird RC5 Code verwendet, d.h. 
neben der "gedrückt-Zeit" das Togglebit wird mit ausgewertet. Wird der 
gleiche Code mit anderem Toggle-Bit empfangen, so wertet das der Dimmer 
als neuen Tastendruck. Würde ich also den Befehl "Licht ein/heller" so 
lange wiederholen, bis der Taste Losgelassen Event eintrifft, dann würde 
jede Wiederholung mit invertiertem Toggle Bit ausgesendet. Dies würde 
vom Dimmer aber als neuer Tastendruck gewertet, wodurch bei einem langem 
Tastendruck nicht die Funktion Dimmen, sondern nur 
ein-aus-ein-aus-ein-aus erkannt wird.

Berücksichtigt IRSND eigentlich das Toggle-Bit bei Codes, die das 
unterstützen?

Ich habe gesehen, IRSND hat den Parameter flags, mit dem man die Anzahl 
der Wiederholungen vorgeben kann. Das Problem dabei ist, in dem Moment, 
in dem die Taste gedrückt wird, weis ich noch nicht wie lange sie unten 
bleibt! Man bräuchte daher ein flag "sende bis auf Widerruf".

Und noch eine Bitte: Könntest Du das neue Thomson Protokoll in IRSND 
einbauen?

Gruß
Cajus

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Cajus,

Cajus H. schrieb:

>> Ich werde meine Änderungen bzgl. Thomson-Protkoll morgen mal ins SVN
>> einchecken.
> Kann es sein, dass Du noch nicht dazu gekommen bist? ;-)

Upps, habe ich das tatäschlich vergessen? Naja, bis auf die 3 defines 
habe ich da nichts großartiges geändert. Okay, werde ich nachholen.

> [...] Wird der Finger vom Touch genommen kommt der "Taste
> Losgelassen" Event. In der Zwischenzeit sollte IRSND das entsprechende
> Kommando senden.
>
> Frage: Wie lässt sich das mit IRSND realisieren?

Gute Frage. Ich würde auf den ersten Blick sagen, dass Du, bis das 
Loslassen-Event kommt, immer wieder irsnd_send_data() aufrufst.

> Ein einfaches Wiederholen des Komandos bis zum Taste Losgelassen Event
> dürfte nicht funktionieren.

Warum nicht? Wenn das Problem lediglich das Toggle-Bit ist, werden wir 
das auch lösen können. Ich habe da auch schon eine Idee, siehe weiter 
unten.

> Ich habe Funktionen, die unterschiedlich auf
> lange und kurze Tastendrücke reagieren. Beispiel Licht Schalten/Dimmen:
> Ein kurzer Tastendruck schaltet das Licht ein/aus, ein langer
> Tastendruck dimmt heller/dunkler. Hier wird RC5 Code verwendet, d.h.
> neben der "gedrückt-Zeit" das Togglebit wird mit ausgewertet. Wird der
> gleiche Code mit anderem Toggle-Bit empfangen, so wertet das der Dimmer
> als neuen Tastendruck.

Wenn ich es recht in Erinnerung habe, toggelt IRSND das Toggle-Bit nicht 
in Wiederholungen, die durch den flags-Wert angegeben ist, sondern nur 
bei erneutem Aufruf von irsnd_send_data(). So sollte es jedenfalls 
sein... und so brauchst Du das ja prinzipiell auch.

> Würde ich also den Befehl "Licht ein/heller" so
> lange wiederholen, bis der Taste Losgelassen Event eintrifft, dann würde
> jede Wiederholung mit invertiertem Toggle Bit ausgesendet.

Korrekt.

> Dies würde
> vom Dimmer aber als neuer Tastendruck gewertet, wodurch bei einem langem
> Tastendruck nicht die Funktion Dimmen, sondern nur
> ein-aus-ein-aus-ein-aus erkannt wird.

Okay, habe ich verstanden. Ist das Dein eigens entwickelter Dimmer? 
Sowas am Toggle-Bit festzumachen, ist eine höchst inkompatible 
Geschichte, wenn man an andere IR-Protokolle denkt ;-)

> Berücksichtigt IRSND eigentlich das Toggle-Bit bei Codes, die das
> unterstützen?

Ja, sollte IRSND berücksichtigen. Bei jedem erneuten Aufruf von 
irsnd_send_data() wird getogglet, innerhalb der flags-Wiederholungen 
nicht.

> Ich habe gesehen, IRSND hat den Parameter flags, mit dem man die Anzahl
> der Wiederholungen vorgeben kann. Das Problem dabei ist, in dem Moment,
> in dem die Taste gedrückt wird, weis ich noch nicht wie lange sie unten
> bleibt! Man bräuchte daher ein flag "sende bis auf Widerruf".

Ja, genau DAS ist das Problem, was ich bei meiner lernfähigen FB, die 
mein Sohn und ich im gesonderten Artikel vorgestellt hatten, auch hatte.

Deshalb rufe ich irsnd_send_data() in einer Schleife mit flags = 0 auf, 
wenn ich Wiederholungen senden möchte (Code dazu s. ganz unten). Da wird 
aber das Toggle-Bit immer wieder geändert... nicht schön.

Ich hätte folgenden Vorschlag zur Änderung der Software:

1. Die Anzahl der Wiederholungen werden im unteren Nibble von
   flags abgelegt, es sind dann nur noch Werte von 0 bis 15 möglich.
   Mehr als 15 Wiederholungen (in einem Satz) braucht keiner, außer...
   siehe Punkt 2.

   Damit gewinne ich 4 Bit, die ich zukünftig als flags gebrauchen kann.

2. Der Wert flags = 15 führt dazu, dass IRSND die Frames endlos
   wiederholt, also bis in alle Ewigkeit sendet. Hier würde dann
   natürlich ein Toggle-Bit nicht geändert werden - wie jetzt auch.

3. Es gibt eine neue Funktion irsnd_stop(), welche das weitere Senden
   von Wiederholungen nach Abschluss des aktuell gesendeten Frames
   unterbindet. Damit kann man dann das endlose Senden dann wieder
   stoppen.

Fürs API würde ich folgende 4 Konstanten vorsehen:

#define IRSND_NO_REPETITIONS       0    // no repetitions
#define IRSND_MAX_REPETITIONS     14    // max # of repetitions
#define IRSND_ENDLESS_REPETITION  15    // endless repetions
#define IRSND_REPETITION_MASK     0x0F  // lower nibble of flags

Du könntest dann beim "Taste Gedrückt" Event die Funktion 
irsnd_send_data() mit flags = IRSND_ENDLESS_REPETITION aufrufen. Sobald 
Deine Software das "Taste Losgelassen" Event schickt, rufst Du 
irsnd_stop() auf.

Wäre Dir damit geholfen?

> Und noch eine Bitte: Könntest Du das neue Thomson Protokoll in IRSND
> einbauen?

Ja, kann ich machen. Ich komme zu all diesen Änderungen aber frühestens 
am Sontagabend (spät!).

Gruß,

Frank

P.S.
IRSND hat im Moment auch noch einen unschönen Bug, den ich dabei auch 
noch loswerden möchte: Nach Aussenden des gewünschten Frames wird die 
Pause-Zeit zum nächsten Frame nicht eingehalten, wenn man 
irsnd_send_data() direkt wieder aufruft. Innerhalb von flags > 0 wird 
das korrekt eingehalten, aber nach dem letzten gesendeten Frame kann man 
direkt wieder mittels irsnd_send_data() "feuern". Das ist unschön.

Ich habe das in der DIY-FB erstmal als Hack folgendermaßen gelöst:
1
        while (cnt > 0)                                             // send cnt frames
2
        {
3
            irsnd_send_data (&(irmp_data[k]), TRUE);                // send IR code now
4
5
            while (irsnd_is_busy ())                                // HACK: wait until IRSND is ready
6
            {
7
                ;
8
            }
9
10
            _delay_ms (50);                                         // wait 50 msec to force a pause between frames
11
            cnt--;
12
        };

Ich weiß, das ist unschön. Deshalb werde ich den Bug in IRSND 
schnellstmöglich fixen.

von Cajus H. (cajush)


Lesenswert?

Hallo Frank,

> Ist das Dein eigens entwickelter Dimmer?
Ja
> Sowas am Toggle-Bit festzumachen, ist eine höchst inkompatible
> Geschichte, wenn man an andere IR-Protokolle denkt ;-)
Dem will ich nicht widersprechen, aber die Abhängigkeit vom Toggle-Bit 
ist nicht auf meinem Mist gewachsen. Ich habe bei diversen alten Philips 
TV Geräten und anderen mit RC5 arbeitenden FBs eine ähnliches Verhalten 
festgestellt: Lautstärke + gedrückt halten hat nur funktioniert, wenn 
sich das Toggle Bit NICHT geändert hat.

> 1. Die Anzahl der Wiederholungen werden im unteren Nibble von
>   flags abgelegt, es sind dann nur noch Werte von 0 bis 15 möglich.
>   Mehr als 15 Wiederholungen (in einem Satz) braucht keiner, außer...
>   siehe Punkt 2.
>
>   Damit gewinne ich 4 Bit, die ich zukünftig als flags gebrauchen kann.

OK. Ich hoffe es schreit dann keiner "Ich brauche aber 20 
Wiederholungen!"

> 2. Der Wert flags = 15 führt dazu, dass IRSND die Frames endlos
>   wiederholt, also bis in alle Ewigkeit sendet. Hier würde dann
>   natürlich ein Toggle-Bit nicht geändert werden - wie jetzt auch.

Gut. Vielleicht sollte man eine "Notabschaltung" nach einigen Sekunden 
vorsehen (per #define sollte reichen), sonst ist bei batteriebetriebenen 
Geräten und einem verloren gegangenen Loslass-Event jedes mal die 
Batterie alle ;-). So etwas kann man auch in main() realisieren, dann 
bläht das nicht die Interrupt Routine auf.

> 3. Es gibt eine neue Funktion irsnd_stop(), welche das weitere Senden
>   von Wiederholungen nach Abschluss des aktuell gesendeten Frames
>   unterbindet. Damit kann man dann das endlose Senden dann wieder
>   stoppen.

Perfekt!

> Wäre Dir damit geholfen?

Sehr!

>> Und noch eine Bitte: Könntest Du das neue Thomson Protokoll in IRSND
>> einbauen?
> Ja, kann ich machen.

Danke!
Bitte im Thomson Protokoll auch das Toggle-Bit berücksichtigen!

> IRSND hat im Moment auch noch einen unschönen Bug...
> Nach Aussenden des gewünschten Frames wird die Pause-Zeit zum
> nächsten Frame nicht eingehalten...

Danke für den Hinweis. Ich sehe das aber nicht als so schlimm an, das 
kann ruhig in main() erledigt werden. Schreib doch einfach den Hinweis 
und den Code in irsndmain.c. Ich halte das für völlig ausreichend.

Gruß
Cajus

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Frank M. schrieb:

> Ich hätte folgenden Vorschlag zur Änderung der Software:
>
> 1. Die Anzahl der Wiederholungen werden im unteren Nibble von
>    flags abgelegt, es sind dann nur noch Werte von 0 bis 15 möglich.
>    Mehr als 15 Wiederholungen (in einem Satz) braucht keiner, außer...
>    siehe Punkt 2.
>
>    Damit gewinne ich 4 Bit, die ich zukünftig als flags gebrauchen kann.

Die Änderung ist nun im SVN.

> 2. Der Wert flags = 15 führt dazu, dass IRSND die Frames endlos
>    wiederholt, also bis in alle Ewigkeit sendet. Hier würde dann
>    natürlich ein Toggle-Bit nicht geändert werden - wie jetzt auch.

Bei flags == IRSND_ENDLESS_REPETITION wird der erzeugte Frame endlos 
geschickt. Nein, stimmt nicht ganz: Nach max. 256 Frames wird aufgehört, 
um die Batterie nicht komplett leerzulutschen :-)

Auch diese Änderung ist im SVN.

> 3. Es gibt eine neue Funktion irsnd_stop(), welche das weitere Senden
>    von Wiederholungen nach Abschluss des aktuell gesendeten Frames
>    unterbindet. Damit kann man dann das endlose Senden dann wieder
>    stoppen.

Ist nun auch im SVN.

> Fürs API würde ich folgende 4 Konstanten vorsehen:
>
> #define IRSND_NO_REPETITIONS       0    // no repetitions
> #define IRSND_MAX_REPETITIONS     14    // max # of repetitions
> #define IRSND_ENDLESS_REPETITION  15    // endless repetions
> #define IRSND_REPETITION_MASK     0x0F  // lower nibble of flags

Ist ebenso umgesetzt.

> IRSND hat im Moment auch noch einen unschönen Bug, den ich dabei auch
> noch loswerden möchte: Nach Aussenden des gewünschten Frames wird die
> Pause-Zeit zum nächsten Frame nicht eingehalten, wenn man
> irsnd_send_data() direkt wieder aufruft. Innerhalb von flags > 0 wird
> das korrekt eingehalten, aber nach dem letzten gesendeten Frame kann man
> direkt wieder mittels irsnd_send_data() "feuern". Das ist unschön.

Diesen Bug habe ich nun auch gefixt. Ist zwar noch nicht optimal, aber 
ich bin erstmal damit zufrieden. Die Pause wird nämlich erst dann 
eingefügt, wenn auch tatsächlich ein 2. Frame auf die Reise geschickt 
wird.

Desweiteren habe ich das THOMSON-Protokoll in den IRSND eingebaut.

Cajus H. (cajush):

Kannst Du das bitte testen und berichten?

Gruß,

Frank

von Torsten K. (nobby)


Lesenswert?

Hy Frank,

gibts schon was neues zur Pollin Merlin Tastatur, oder hab ich das hier 
überlesen ??

Gruß
Torsten

von Cajus H. (cajush)


Lesenswert?

Hallo Frank,

Frank M. schrieb:
> Cajus H. (cajush):
>
> Kannst Du das bitte testen und berichten?

Da ist ein Copy&Paste Fehler in irmp.c
nach
#if IRMP_SUPPORT_MERLIN_PROTOCOL == 1

static PROGMEM IRMP_PARAMETER netbox_param =
sollte vermutlich
static PROGMEM IRMP_PARAMETER merlin_param =
heissen...

Danach arbeitet IRMP gut und liefert sinnvolle Werte für das Thomson 
Protokoll.

IRSND - mein main() sieht so aus:

int main (void)
{
  IRMP_DATA irmp_data;

  irsnd_init(); // initialize irsnd
  timer_init(); // initialize timer
  sei();        // enable interrupts

  for (;;)
  {
    irmp_data.protocol = IRMP_THOMSON_PROTOCOL;
    irmp_data.address  = 0x03;
    irmp_data.command  = 0x1d;
    irmp_data.flags    = 15;

    irsnd_send_data (&irmp_data, TRUE);
    _delay_ms (10000);
    irsnd_stop ();
    _delay_ms (3000);

  }
}
Es sollte also 10 Sekunden das Kommando 0x1d senden, dann 3 Sekunde 
Pause und wieder von vorne. Es passiert aber folgendes:
- 10 Sekunden Senden
- 3 Sekunden Pause
- Senden bis die Batterie alle ist.
Scheinbar funktioniert das irsnd_stop(); nur einmal ?!
Wenn ich
irmp_data.flags = 14;
setze, dann funktioniert es. (auch mit dem irsnd_stop(), vermutlich weil 
das Senden von 14 Wiederholungen keine 10 Sekunden dauert...)
Das Beenden des Sendens nach 256 Wiederholungen funktioniert, außer im 
Fall oben, da hört IRSND mit dem Senden nicht mehr auf,

Gruß
Cajus

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Cajus,

Cajus H. schrieb:

> Da ist ein Copy&Paste Fehler in irmp.c

Danke, ist korrigiert.

> Es sollte also 10 Sekunden das Kommando 0x1d senden, dann 3 Sekunde
> Pause und wieder von vorne. Es passiert aber folgendes:
> - 10 Sekunden Senden
> - 3 Sekunden Pause
> - Senden bis die Batterie alle ist.

Danke für den Test, ich habe den Fehler gefunden und korrigiert. 
irsnd_stop() sollte nun tun, was es soll.

Klappt das denn nun auch mit dem Toggle-Bit, so wie Du es mir 
beschrieben hat? Kann Dein Dimmer nun lange Tastendrücke von mehrfachen 
Tastendrücken per Toggle-Bit unterscheiden?

> Scheinbar funktioniert das irsnd_stop(); nur einmal ?!

Nein, es funktionierte keinmal. irsnd_stop() hatte die falsche Variable 
zurückgesetzt. Das hatte schlicht und ergreifend "Null Effekt".

Korrektur ist im SVN eingecheckt.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Torsten,

Torsten K. schrieb:

> gibts schon was neues zur Pollin Merlin Tastatur, oder hab ich das hier
> überlesen ??

Sorry, habs noch nicht geschafft, die Merlin-Tastatur komplett auf alle 
Tastendrücke durchzuchecken. Ich hoffe, ich schaffe es im Laufe der 
Woche.

Gruß,

Frank

von Joachim B. (Gast)


Lesenswert?

Frank M. schrieb:
> och, wird erkannt. Das ist das NEC16-Protokoll

hmm, guten abend

habe gerade mal das aktuelle aus dem SVN installiert

NEC16 flattert nun über alle möglichen Erkennungen NEC16 MERLIN RUWIDO 
kommt alles mögliche bei repeat (also wenn ich den Finger auf der Taste 
lasse)

SAMSUNG32 ist stabil

KASEIKYO flattert wenig aber ich sehe dabei auch gel. MERLIN und SIEMENS

IRMP - Infrared Multi Protocol Decoder
--------------------------------------
Version IRMP:  2.0.0-pre4 20.05.2010
Version IRSND: 1.9.4      22.05.2010

??? wunder einige Sourcen waren vom 22.5. also aktuell

irgendwas ist instabil

evt. schaust mal ?

gruss
jar

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:

> NEC16 flattert nun über alle möglichen Erkennungen NEC16 MERLIN RUWIDO
> kommt alles mögliche bei repeat (also wenn ich den Finger auf der Taste
> lasse)

Was meinst Du damit? Dass bei einer NEC16-FB zwischendurch auch mal 
MERLIN oder RUWIDO erkannt wird? Welche Protokolle hast Du alle 
eingeschaltet?

> KASEIKYO flattert wenig aber ich sehe dabei auch gel. MERLIN und SIEMENS

Hier also KASEIKYO-FB, wo ab und zu MERLIN bzw. SIEMENS ausgegeben wird?

> irgendwas ist instabil

Ich bräuchte Deine irmpconfig.h, um das nachzustellen. Quarz ist 
angeschlossen und aktiv?

Gruß,

Frank

von Joachim B. (Gast)


Angehängte Dateien:

Lesenswert?

Frank M. schrieb:
> as meinst Du damit? Dass bei einer NEC16-FB zwischendurch auch mal
> MERLIN oder RUWIDO erkannt wird? Welche Protokolle hast Du alle
> eingeschaltet?

genau bleibe ich auf der Taste werden reium alle mal erkannt

alle ausser on >15000 Hz und Prototyp Protokoll 99

> Hier also KASEIKYO-FB, wo ab und zu MERLIN bzw. SIEMENS ausgegeben wird?
> Ich bräuchte Deine irmpconfig.h, um das nachzustellen. Quarz ist
> angeschlossen und aktiv?

ohne Quarz, war aber vorher stabiler

von Joachim B. (Gast)


Lesenswert?

PS könnte man proto String nicht integrieren ?

muss den immer nachfummeln bei jedem Update
1
static char *Proto[]={ \
2
"SIRCS","NEC","SAMSUNG","MATSUSH","KASEIKYO","RECS80","RC5(x)","DENON","RC6","SAMSG32",\
3
"APPLE","RECS80x","NUBERT","BANG_OLUF","GRUNDIG","NOKIA","SIEMENS","FDC","RCCAR","JVC",\
4
"RC6A","NIKON", "RUWIDO","IR60","KATHREIN","NETBOX","NEC16","NEC42","LEGO","THOMSON", \
5
"MERLIN"};

von Joachim B. (Gast)


Lesenswert?

noch ein kleines Problem:

wird nach
irmp_get_data(&irmp_data)

das irmp_get_data FLAG nicht gelöscht ?

ich kann nur zwischen den Drücken unterscheiden wenn ich zwischendurch 
eine andere Taste drücke

drücke ich die Taste 1x und halte fest, lasse los und drück die selbe 
toogelt das Repeat Bit nicht, erst wenn ci zwischendurch ne andere 
drücke, dabei sollte z.B. TASTE 1 toggeln, wenn losgelassen und wieder 
gedrückt wird ..
1
    if (irmp_get_data(&irmp_data))
2
     {  
3
      merke_fb=(irmp_data.address*100)+irmp_data.command;
4
      L_Com=merke_fb;
5
      merke_rc5=merke_fb;
6
7
      if (irmp_data.flags & IRMP_FLAG_REPETITION)
8
       {   // Benutzer hält die Taste länger runter
9
          // entweder:
10
          //   ich ignoriere die (Wiederholungs-)Taste
11
          // oder:
12
          //   ich benutze diese Info, um einen Repeat-Effekt zu nutzen
13
        merke_fb  |= (1<<15);
14
        merke_rc5       |= (1<<15);
15
        L_Com    |= (1<<15);
16
                                // simmuliere TOGGELbit
17
        }
18
       else // if (irmp_data.flags & IRMP_FLAG_REPETITION)
19
       {   // Es handelt sich um eine neue Taste
20
        show_irmp=5;
21
        merke_fb    &= ~(1<<15);
22
        merke_rc5  &= ~(1<<15);
23
        L_Com      &= ~(1<<15);
24
                                // simmuliere TOGGELbit

von Joachim B. (Gast)


Lesenswert?

keine Antwort ? liegts an mir (weil ich mich unwissend anstelle?)

ich versuchs mal anders zu erklären

DU kennst doch typische Puls- Pausenlängen

ergo müsste es doch in IRMP auffallen wenn zwischen 2 Tastendrücken der 
selbe Code kommt oder innerhalb der Repeatframezeit der selbe Code 
einläuft und das Repeatflag entsprechend gesetzt wird.

Ich blick immer noch nicht durch wielange IRMP das Flag "Code erkannt" 
vorrätig hält, für mein Geschmack wäre es richtig bis man es ausgelesen 
hat, man guckt ja als Controller nicht ständig :-)

bei meiner KEY Abfrage mache ich es so, lese KEY, werte Key aus, lösche 
den gelesen KEY und wenn nix zu tun ist und KEY leer ist, dann hole dir 
wieder einen KEY wenn vorhanden

und da ich KEY und IR benutze wäre es schön wenn man das zusammen 
bekommt

nur muss ich ja die IR Flags befragen und wenn da ewig welche abzuholen 
sind kann ich nicht erkennen ob ich den schon mal geholt habe, bzw. kann 
ja ein neuer KEY , ähhh, IR Code sein der durchaus identisch mit dem 
Vorcode ist, trotzem ist er neu und es sollte toggeln....

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:
> keine Antwort ? liegts an mir (weil ich mich unwissend anstelle?)

Ich habe Dir bisher nicht antworten können, weil ich noch ein 
Privatleben ohne µC und Elektronik habe ;-)

> ich versuchs mal anders zu erklären
> [...]

Da ich an den Timingparametern nichts geändert habe, kann ich mir im 
Moment gar nicht vorstellen, wo Deine Probleme herrühren. Im Moment kann 
ich mir da nur den fehlenden Quarz vorstellen. Sonst helfen mir da nur 
intensive Tests weiter.

Am Donnerstagabend habe ich vielleicht Zeit, Dein Szenario 
durchzuspielen. Dann kann ich Dir auch antworten. Vorher schaffe ich es 
leider nicht, sorry.

> nur muss ich ja die IR Flags befragen und wenn da ewig welche abzuholen
> sind kann ich nicht erkennen ob ich den schon mal geholt habe, bzw. kann
> ja ein neuer KEY , ähhh, IR Code sein der durchaus identisch mit dem
> Vorcode ist, trotzem ist er neu und es sollte toggeln....

Wenn der nächste IR-Frame innerhalb IRMP_KEY_REPETITION_LEN (150 msec) 
reinkommt, dann geht IRMP davon aus, dass die FB automatisch repetiert. 
Dann wird das Repetition-Flag gesetzt. Das funktioniert sehr gut. Wenn 
Du selber mit dem Finger repetierst, wirst Du das nicht so schnell 
schaffen und IRMP setzt dann auch nicht(!) das Repetition-Flag. Also 
vergiss das mit dem Toggle, das geht nur bei RC5, RC6 und Thomson. Bei 
den 27 anderen FB-Protokollen, die IRMP unterstützt, gibt es gar kein 
Toggle-Bit. Daher kann ich das auch gar nicht auswerten.

EDIT: Wenn Du das Toggle-Bit simulieren musst, weil Du anderen Code 
verwendest, der nicht auf das RC5-Toggle-Bit verzichten kann, dann mach 
einfach folgendes:

 - Repetition-Flag gesetzt: dann nicht togglen
 - Repetition-Flag nicht gesetzt: dann togglen

Dann sollte auch RC5-Legacy-Code zusammen mit IRMP funktionieren ;-)

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:

> bei meiner KEY Abfrage mache ich es so, lese KEY, werte Key aus, lösche
> den gelesen KEY und wenn nix zu tun ist und KEY leer ist, dann hole dir
> wieder einen KEY wenn vorhanden

Wenn was zu tun ist: Wie lange brauchst Du, um den Key abzuarbeiten?

Bitte möglichst in msec angeben :-)

Sobald IRMP einen Frame eingelesen hat, sperrt er den Empfang weiterer 
IR-Signale solange, bis Du den Code auch abholst.

Ich kann mir ein Szenario vorstellen, wo das in die Hose geht.

1. Du hältst den Finger auf eine FB-Taste
2. IRMP empfängt 1. Frame
3. Du holtst ihn ab und verarbeitest den Key...
4. Währenddessen empfängt IRMP den 2. Frame und speichert die Daten
5. Du verarbeitest aber immer noch den 1. Key -> IRMP sperrt den Empfang
6. Es kommt der 3. Frame, aber IRMP empfängt nicht
7. Du bist mit der Verarbeitung fertig - mitten im Frame 3
8. Du holst den 2. Frame ab, IRMP gibt den Empfang wieder frei
9. Ein Restfragment vom 3. Frame wird von IRMP aufgezeichnet und
   fälschlicherweise als irgendein Protokoll erkannt, vorzugsweise eines
   ohne ausgezeichnetes Start-Bit.

Wenn dem so ist, kann ich das nur lösen, indem IRMP den Empfang nicht 
sperrt, aber das Ergebnis anschließend verwirft, solange Du den Frame 
davor nicht abgeholt hast.

Gruß,

Frank

von Joachim B. (Gast)


Lesenswert?

natürlich darfst du ein Privatleben haben, ich hab momentan keines und 
bin deswegen so ungeduldig ?

Frank M. schrieb:
> Ich kann mir ein Szenario vorstellen, wo das in die Hose geht.
>
> 1. Du hältst den Finger auf eine FB-Taste

logisch, ich weiss ja nicht wann der Code vollständig empfangen wurde 
bis das gewünschte passiert, vermutlich auch das Problem das der Buffer 
meiner lernfähigen FB nie reicht für 4-8 Fernbedienungen (wie der 
Aufdruck und die Werbung behaupten), immer sagt die lern FB : Buffer 
voll obwohl nur 2 halbe FBs (Kaseikyo) gelernt wurden.

Kann aber auch sein die Befehle wurden immer länger und der Speicher der 
FB (alte >5 Jahre  und NEUE !!! grad gekauft ) ist zu knapp

> 2. IRMP empfängt 1. Frame
> 3. Du holtst ihn ab und verarbeitest den Key...
> 4. Währenddessen empfängt IRMP den 2. Frame und speichert die Daten
> 5. Du verarbeitest aber immer noch den 1. Key -> IRMP sperrt den Empfang
> 6. Es kommt der 3. Frame, aber IRMP empfängt nicht

das könnte genau so laufen

> 7. Du bist mit der Verarbeitung fertig - mitten im Frame 3
> 8. Du holst den 2. Frame ab, IRMP gibt den Empfang wieder frei
> 9. Ein Restfragment vom 3. Frame wird von IRMP aufgezeichnet und
>    fälschlicherweise als irgendein Protokoll erkannt, vorzugsweise eines
>    ohne ausgezeichnetes Start-Bit.
>
> Wenn dem so ist, kann ich das nur lösen, indem IRMP den Empfang nicht
> sperrt, aber das Ergebnis anschließend verwirft, solange Du den Frame
> davor nicht abgeholt hast.

wielange KEY dauert ? oder die Abarbeitung nach KEY ? das letztere werde 
ich nie rausfinden, es gibt nur 6 Tasten die in jedem Menue und 
Untermenue je nach Bedingung verschiedenes tun, also die 
Verarbeitungsdauer nach KEY lesen ist unbestimmt

ein Riesendanke für deine Bemühungen

von Joachim B. (Gast)


Lesenswert?

ich hatte mir was überlegt, aber das scheint auch nicht zu klappen

ich dachte wenn ich ein Bit selber toggeln lasse, in der Art,

...

klappt aber auch nicht, evt. kannst du ein Flag einbauen welches immer 
toggelt wenn eine neue Taste kommt oder wenn eine FramePause erkannt 
wurde also die FB Taste mal nicht gedrückt war
1
void fb(void)
2
{  
3
  if (irmp_get_data(&irmp_data) && !strcmp((char *)Proto[irmp_data.protocol-1], "RC5(x)") )
4
  {  
5
    L_Com&=0x8000; // loesche L_Com aber behalte das alte toggleBIT
6
    L_Com|=(((irmp_data.address*100)+irmp_data.command)&0x7fff); // addiere neues L_Com aber behalte das alte toggleBIT
7
    merke_rc5=L_Com;
8
9
    if (irmp_data.flags & IRMP_FLAG_REPETITION)
10
     {   // Benutzer hält die Taste länger runter
11
        // entweder:
12
        //   ich ignoriere die (Wiederholungs-)Taste
13
        // oder:
14
        //   ich benutze diese Info, um einen Repeat-Effekt zu nutzen
15
      // toggleBIT aendert nicht
16
      }
17
     else // if (irmp_data.flags & IRMP_FLAG_REPETITION)
18
     {   // Es handelt sich um eine neue Taste
19
      show_irmp=5;
20
      //_merke_toggleBIT^=(1<<15);
21
      L_Com  ^= (1<<15);       // toggleBIT aendert sich
22
      merke_rc5=L_Com;
23
    }
24
        // ....
25
        // ab hier mache ich weiter wie frueher
26
        // ....
27
        // ....
28
        // ....
29
        // ....
30
        // ....
31
        // ....
32
        
33
        
34
   } // if(irmp_get_data(&irmp_data) && !strcmp((char *)Proto[irmp_data.protocol-1], "RC5(x)") )
35
  else
36
  {
37
      L_Com  ^= (1<<15);
38
    // toggleBIT aendert sich
39
  }
40
}

von Joachim B. (Gast)


Lesenswert?

warum ist das toggleBIT eigendlich nicht im IRMP erkannten RC5 Code 
vorhanden ?

dann könnte man sich diese Quälerei sparen, im RC5 wird es ja 
mitgeliefert und ich brauche nicht zu tricksen

wenn der Umbau aber klappt mit toggle selber erzeugen -

(nach meinem Vorschlag: evt. kannst du ein Flag einbauen welches immer
toggelt wenn eine neue Taste kommt oder wenn eine FramePause erkannt
wurde also die FB Taste mal nicht gedrückt war )

- für alle Codes waere das auch fein

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:
> warum ist das toggleBIT eigendlich nicht im IRMP erkannten RC5 Code
> vorhanden ?

Weil Du dann für ein- und dieselbe Taste zwei unterschiedliche Codes 
bekommen würdest.

> dann könnte man sich diese Quälerei sparen, im RC5 wird es ja
> mitgeliefert und ich brauche nicht zu tricksen

Die "Quälerei" hast Du nur deshalb, weil Du Code benutzt, der Original 
RC5 sehen will. IRMP wandelt die Daten aber in ein portables Format, was 
für alle Protokolle einheitlich ist.

> wenn der Umbau aber klappt mit toggle selber erzeugen -
>
> (nach meinem Vorschlag: evt. kannst du ein Flag einbauen welches immer
> toggelt wenn eine neue Taste kommt oder wenn eine FramePause erkannt
> wurde also die FB Taste mal nicht gedrückt war )

Ich habe doch schon geschrieben: Wenn Repetition-Flag nicht gesetzt, 
dann togglen, wenn Flag gesetzt, dann nicht togglen. Hast Du das 
überlesen?

> - für alle Codes waere das auch fein

Warum sollte ich ein Toggle-Bit künstlich einbauen? Die anderen 
Protokolle kennen doch gar kein Toggle-Bit. Dafür gibt es doch das 
Repetition-Flag in IRMP. Das ist doch viel einfacher zu handhaben als so 
ein Toggle-Bit.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:
> ich hatte mir was überlegt, aber das scheint auch nicht zu klappen
1
> void fb(void)
2
> {
3
>   if (irmp_get_data(&irmp_data) && !strcmp((char
4
> *)Proto[irmp_data.protocol-1], "RC5(x)") )
5
>   {
6
>     L_Com&=0x8000; // loesche L_Com aber behalte das alte toggleBIT

Wie kommst Du auf die Idee, dass das Toggle-Bit an der 16. Stelle sitzt?
1
>       L_Com  ^= (1<<15);

Auch hier:

Wie kommst Du auf die Idee, dass das Toggle-Bit an der 16. Stelle sitzt?

Schau Dir bitte http://www.sbprojects.com/knowledge/ir/rc5.htm an.

merke_rc5 wird bei Dir gesetzt aber nie benutzt?

Machs doch einfach so:
1
void fb(void)
2
{
3
    static uint16_t toggle_bit;
4
    ...
5
6
    toggle_bit ^= (1<<11);    // Togglen
7
    L_Com|= toggle_bit;
8
    ...
9
}

Und noch etwas:

Dein

   if (... !strcmp((char *)Proto[irmp_data.protocol-1], "RC5(x)"))

ist suboptimal und kostet viel CPU-ZEIT. Warum nicht einfach:

   if (... irmp_data.protocol == IRMP_RC5_PROTOCOL)

Das ist nur ein int16-Vergleich und geht wesentlich schneller als Dein 
Zeichenkettenvergleich. Warum machst Du so etwas?

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Deine fb-Funktion ist absoluter Murks, der else-Block ganz am Ende 
gehört da auch nicht hin.

Ich schreibe das mal neu:
1
void fb(void)
2
{  
3
  static uint16_t toggle_bit;
4
5
  if (irmp_get_data(&irmp_data) && irmp_data.protocol == IRMP_RC5_PROTOCOL)
6
  {  
7
    L_Com = (((irmp_data.address*100) + irmp_data.command) & 0x7fff); // L_Com aus Adresse und Kommando zusammenbauen
8
9
    if (! (irmp_data.flags & IRMP_FLAG_REPETITION))
10
    {
11
      toggle_bit ^= (1<<11);    // Togglen
12
      L_Com |= toggle_bit;
13
    }
14
15
16
    // ....
17
    // ab hier mache ich weiter wie frueher
18
    // ....
19
20
  }
21
22
  // KEIN ELSE!!!!
23
}

So einfach ist das. :-)

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Zusatz:

Was soll der Ausdruck ((irmp_data.address*100) + irmp_data.command) & 
0x7fff)

Adresse mal hundert + Kommando? Verstehe ich nicht. Damit baust Du 
jedenfalls nicht den Original-Frame zusammen, sondern irgendeine 
Zufallszahl.

von Joachim B. (Gast)


Lesenswert?

Frank M. schrieb:
> Warum sollte ich ein Toggle-Bit künstlich einbauen? Die anderen
> Protokolle kennen doch gar kein Toggle-Bit. Dafür gibt es doch das
> Repetition-Flag in IRMP. Das ist doch viel einfacher zu handhaben als so
> ein Toggle-Bit.
> Gruß,
> Frank

also im RC5 Code wäre es nicht künstlich eingebaut, da wird das 
mitgeliefert und damit lief mein altes Programm genau wie geplant, ich 
verstehe halt nicht warum IRMP das nicht durchreichen kann ?

Frank M. schrieb:
> Dein
>
>    if (... !strcmp((char *)Proto[irmp_data.protocol-1], "RC5(x)"))
>
> ist suboptimal und kostet viel CPU-ZEIT. Warum nicht einfach:
>
>    if (... irmp_data.protocol == IRMP_RC5_PROTOCOL)
>
> Das ist nur ein int16-Vergleich und geht wesentlich schneller als Dein
> Zeichenkettenvergleich.

ja klar

> Warum machst Du so etwas?

weil das für mich der schnellste Weg war ohne IRMP vollständig zu 
erkunden ?
ich wusste RC5 wird per String ausgegeben wenn erkannt, also war das 
mein Unterscheidungsmerkmal, natürlich suboptimal und kann man ja 
korrigieren, zur Codeoptimierung kann ich ja später vordringen wenns 
erst mal läuft, wenn natürlich schon vorher gute Ideen einfliessen warum 
nicht zur Laufzeit der Prog.Entwicklung einfliessen lassen, mach ich nun

Frank M. schrieb:
> Deine fb-Funktion ist absoluter Murks, der else-Block ganz am Ende
> gehört da auch nicht hin.
>
> Ich schreibe das mal neu:
> ...
> So einfach ist das. :-)


ich probiere es ;-)))

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:
> also im RC5 Code wäre es nicht künstlich eingebaut, da wird das
> mitgeliefert und damit lief mein altes Programm genau wie geplant, ich
> verstehe halt nicht warum IRMP das nicht durchreichen kann ?

Habe ich doch geschrieben: Dann würdest Du im IRMP für ein- und dieselbe 
Taste 2 verschiedene Codes bekommen.

> weil das für mich der schnellste Weg war ohne IRMP vollständig zu
> erkunden ?

Die Konstante steht in irmp.h und im IRMP-Artikel steht ein 
Anwendungsbeispiel:

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

Zitat:
1
      if (irmp_data.protocol == IRMP_NEC_PROTOCOL &&     // NEC-Protokoll
2
          irmp_data.address == 0x1234)                   // Adresse 0x1234

> ich wusste RC5 wird per String ausgegeben wenn erkannt, also war das
> mein Unterscheidungsmerkmal, natürlich suboptimal und kann man ja
> korrigieren, zur Codeoptimierung kann ich ja später vordringen wenns
> erst mal läuft, wenn natürlich schon vorher gute Ideen einfliessen warum
> nicht zur Laufzeit der Prog.Entwicklung einfliessen lassen, mach ich nun

Jetzt verstehe ich auch, warum Du wolltest, dass ich die Texte in main.c 
vervollständige... :-)

> ich probiere es ;-)))

Viel Glück! :-)

von Joachim B. (Gast)


Lesenswert?

funktioniert nicht :-(

Codes werden mehrfach erkannt und sofort ohne Zwischenstop falsch 
abgearbeitet

also Menue -> ENTER -> Untermenue und da warten bis andere Taste oder 
ENTER wieder neu ! gedrückt wird

wird in einem Rutsch abgearbeitet, keine Chance im Untermenue noch 
Optionen zu wählen

wenn ich also auf der FB Taste gedrückt bleibe ! werden die Aktionen im 
ca. 10s ? Takt durchgeführt, z.B. Licht an/aus
obwohl ich ja die Taste nie losgelassen hatte

wenn ich kurz drücke, passiert entweder nix ! oder Licht geht an und 
gleich wieder aus, einen statischen ON/OFF Zustand kann ich so nicht 
erreichen

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:
> funktioniert nicht :-(

Du hattest auch meine Frage bzgl. der Position des Toggle-Bits nicht 
beantwortet. Wo muss das stecken? An der 16. Stelle? Oder wie im 
Original an der 12. Stelle?

Zeig doch mal den Rest Deines RC5-Programms, damit man sieht, wo das 
Toggle-Bit stecken muss.

von Joachim B. (Gast)


Lesenswert?

Frank M. schrieb:
> Habe ich doch geschrieben: Dann würdest Du im IRMP für ein- und dieselbe
> Taste 2 verschiedene Codes bekommen.

ja und ? das war schon immer so, der einzige Unterschied wäre das 
originale RC5 ToogleBIT welches ausmaskiert werden kann wenn das 
jemanden stört !

ich hab das ToggleBIT von (1<<11) nur nach (1<<15) verschoben um unten 
Platz zu behalten

ich habe Adresse mit 100 multipliziert weil mir Adresse 30 als 3000 und 
7 als 700 sympatisch war und ich bei RC5 nie mehr als 100 Commands sah 
und weil ich hauptberuflich kein Infomatiker bin

deswegen kämpfe ich ja an allen Fronten gleichzeitig

eagle nervt fast mit wöchenlichen Updates und jedesmal muss ich an allen 
Stellen die LIBs importieren die wires beim Start neu intialisieren, das 
nervt und wehe man vergisst an einem Rechner irgendeine Einstellung....

eine zeitlang waren meine avr_gcc und ASTUDIO nicht auf allen Rechnern 
auf den gleichen Stand aber alles lief, dann hatte ich auf einem Rechner 
ein update gemacht und nix lief mehr, dann habe ich alles gelöscht die 
REG geputzt und noch mal von vorne und nix ging (irgendwas in der REG 
übersehen?), also noch mal von vorne und damit das nicht wieder passiert 
habe ich den win_avr PATH geändert um sicherzugehen, seit dem nervt mich 
MAKE wenn ich an dem einen oder anderen Rechner arbeite das er die LIBs 
nicht findet, gleichwohl ich weiss nicht wie das passiert, werden die 
FILENAMEN nun manchmal in UPPER Case importiert, was den Linker wieder 
ärgert C++ ist nicht in gnu99c enthalten, dabei benutze ich kein C++

wenn ich dann manuell im DIR die Filenamen wieder zu lower Case mache 
ist es wieder OK, jedenfalls temporär

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Frank M. schrieb:
> Zeig doch mal den Rest Deines RC5-Programms, damit man sieht, wo das
> Toggle-Bit stecken muss.

Habs gerade selber gefunden in

   Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"

Da steht:
1
aus dani code
2
void fb(void)
3
{  if( i_ )
4
  {  //_toggelbit = ( i_ >> 11 & 1);
5
    L_Com  =  (i_ >> 6 & 0x1F)*100;
6
      L_Com  +=  (i_ & 0x3F) | (~i_ >> 7 & 0x40);

Ein RC5x-Frame sieht folgendermaßen aus:

C6 T A4 A3 A2 A1 A0 C5 C4 C3 C2 C1 C0

Die Zeile
1
    L_Com  =  (i_ >> 6 & 0x1F)*100;

Speichert in L_Com das Hundertfache von der Adresse: A4 A3 A2 A1 A0.
Dabei werden die Kommando-Bits und auch das Toggle-Bit weggeschnitten.

Die Zeile
1
      L_Com  +=  (i_ & 0x3F) | (~i_ >> 7 & 0x40);

sollte wohl C6 C5 C4 C3 C2 C1 C0 speichern, wobei C6 invertiert ist nach 
dem RC5x-Protokoll.

Aber das scheint ein Programmierfehler zu sein: Wenn ich richtig zähle, 
stimmt aber die Bitposition für das C6 nicht.

@Joachim B.

Das Toggle-Bit an 12. Stelle wird hier jedenfalls komplett ignoriert. 
Ich brauche den alten RC5-Code, sonst kann ich Dir nicht helfen.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:
> ja und ? das war schon immer so, der einzige Unterschied wäre das
> originale RC5 ToogleBIT welches ausmaskiert werden kann wenn das
> jemanden stört !

Sorry, Du hast den Sinn und Zweck von IRMP nicht verstanden. IRMP 
speichert den Frame in einem kompatiblen Format ab und nicht im 
RC5-Format. Ein IRMP-Anwender braucht gar nicht zu wissen, was RC5 ist 
und dass da ein Toggle-Bit ist, was ausmaskiert werden muss!

Der Vorteil von IRMP ist doch gerade die Protokoll-Unabhängigkeit. Soll 
der jetzt da reinschreiben: "Wenn protokoll gleich RC5, schmeiß dass 
Toggle-Bit weg"?

Nein, die Einführung eines eines allgemeinen Toggle-Bits in IRMP für den 
Spezialfall, dass Dein alter Code wieder läuft, ist für mich nicht 
akzeptabel. Ich helfe Dir gern. Aber ich brauch dafür den alten Source 
von Dir, sonst wird das nix.

von Joachim B. (Gast)


Angehängte Dateien:

Lesenswert?

Frank M. schrieb:
> Zeig doch mal den Rest Deines RC5-Programms, damit man sieht, wo das
> Toggle-Bit stecken muss.

etwas mehr Code als IRMP noch nicht integriert war

von Joachim B. (Gast)


Lesenswert?

Frank M. schrieb:
> Nein, die Einführung eines eines allgemeinen Toggle-Bits in IRMP für den
> Spezialfall, dass Dein alter Code wieder läuft, ist für mich nicht
> akzeptabel. Ich helfe Dir gern. Aber ich brauch dafür den alten Source
> von Dir, sonst wird das nix.

ich verstehe das ja, nur wie soll man das lösen das das so gewünschte 
programmtechnisch läuft ?

alle Lösungsversuche liefen bis jetzt schief, es scheint als wenn das 
nicht funktioniert

warum geht mein Licht an und aus wenn ich auf der Taste power bleibe ? 
der State hat ja nie gewechselt, ergo dürfte
1
  if( !(irmp_data.flags & IRMP_FLAG_REPETITION) )
2
      {
3
     toggle_bit ^= (1<<15);    // Togglen
4
           L_Com |= toggle_bit;
5
      }

nie das toggleBIT ändern, mit L_Com ist gleicher Befehl und das 
togglebit unverändert und __p == HAUPTMENU
1
        case PINN_GROSSER_KULLER:  // light 
2
        case PINN_6:  // p6 pinnacle taste "6"
3
        case 3006:  // light hauppauge taste "6"
4
        case 3015:  // light hauppauge taste "mute" MUTE
5
          if(__p==_STATUS || __p==_IRMP)
6
          {  if(count> 10)  {  p_old=86; __p=_LICHT; count=0;  }  }
7
          else
8
            if(Old_L_Com != L_Com)
9
              speedLED(TOGGLE);
10
          break;

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:
> warum geht mein Licht an und aus wenn ich auf der Taste power bleibe ?
> der State hat ja nie gewechselt, ergo dürfte

Jetzt zeige bitte den neuen Source, welcher IRMP nutzt, damit ich das 
vergleichen kann.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:

> warum geht mein Licht an und aus wenn ich auf der Taste power bleibe ?
> der State hat ja nie gewechselt, ergo dürfte
>
>
1
>   if( !(irmp_data.flags & IRMP_FLAG_REPETITION) )
2
>       {
3
>      toggle_bit ^= (1<<15);    // Togglen
4
>            L_Com |= toggle_bit;
5
>       }
6
>
>
> nie das toggleBIT ändern, mit L_Com ist gleicher Befehl und das
> togglebit unverändert und __p == HAUPTMENU

Wenn Du diesen Block weglässt, passiert dann das gewünschte bei langem 
Tastendruck?

von Joachim B. (Gast)


Angehängte Dateien:

Lesenswert?

Frank M. schrieb:
> Wenn Du diesen Block weglässt, passiert dann das gewünschte bei langem
> Tastendruck?

wie schon mal

langer Tastendruck z.B. Licht an/aus lässt eine NEUE Taste genau einmal 
reagieren, ob ich draufbleibe oder loslasse und nochmal drücke ändert 
nix, nie wieder reagiert die Routine auf die gewünschte Taste bis ich 
eine andere drücke erst dann wird wieder z.B. Licht geschaltet

evt. geht das Licht auch so schnell an und aus das ich es nicht merke

denn up und downscrollen funktioniert ja

aber wenn ich im Untermenue mehrfach die TAB-Taste drücke, springt die 
nur 1x wie beim Licht, ich muss zwischendurch eine andere Taste drücken 
damit TAB wieder einmal reagiert

neuer Code anbei

von Joachim B. (Gast)


Lesenswert?

die Idee warum ich dafür IRMP nutzen möchte

wie du schon sagtes RC5 stirbt aus und mein Timer sollte (lernfähig) mit 
allen FB arbeiten, gleichwohl ist die "Funktion" alle FB erkennen toll 
und hilfreich als Tester in ein Gehäuse gepresst und kann quasi nebenbei 
von meinem Timer erledigt werden, alle Codes erkenne ich ja, nur kann 
ich so die IR Fähigkeit der Bedienung vergessen, es sei denn wir finden 
ne Lösung

die Möglichkeit nur zur Bedienung auf RC5 Decoder auszuweichen und zum 
Test IRMP zu nutzen gäbs ja auch noch, aber damit verbaue ich mir die 
Lernfähigkeit der Timerbedienung für alle FB
1
#include "cpu.h"
2
#include <avr/io.h>
3
4
#ifndef TYPES_H
5
  #include "types_.h"
6
#endif
7
8
/************************************************************************/
9
/*                                                                      */
10
/*                      RC5 Remote Receiver                             */
11
/*                                                                      */
12
/*              Author: Peter Dannegger                                 */
13
/*                      danni@specs.de                                  */
14
/*                                                                      */
15
/************************************************************************/
16
#include <avr/interrupt.h>
17
//#include <avr/signal.h>
18
#include <stdlib.h>

von Joachim B. (Gast)


Angehängte Dateien:

Lesenswert?

hi frank,

ich hab nun den RC5 Aufruf in die ISR hinter dem IRMP Aufruf gesetzt und 
bei RC5 erkannt werte ich dieses nur aus, ergo mein Hauptcode 
funktioniert wieder wie gewünscht,

kein repeat da wo er nicht sein darf,
aber repeat da wo gewünscht

ich kann repeaten bei scroll up/down und nie repeaten bei Licht an/aus 
oder ENTER

ich leg das mal in den Zip

vielleicht fällt dir noch was ein (ich würde sehr gerne für alle FB IRMP 
nutzen)

eines ist mir aufgefallen

ich hole pro main loop genau 1x den RC5 Code ab und der wird von mir 
gleich danach gelöscht
1
 for (;;)
2
{
3
  cli(); //Global Interrupt Disable
4
     i_ = rc5_data;      // read two bytes from interrupt !
5
     rc5_data = 0;
6
     sei(); //Global Interrupt Enable
7
8
// der ganze Rest vom main loop 
9
10
}

evt. muss ich das auch bei IRMP ?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:
> vielleicht fällt dir noch was ein (ich würde sehr gerne für alle FB IRMP
> nutzen)

Ich weiß nicht, ob ich es schaffe, mir das in den nächsten Tagen 
anzuschauen.

Wenn Du gern alle FBs mit IRMP für Dein Programm nutzen möchtest, dann 
musst Du Dich gedanklich vom Toggle-Bit lösen. Du vergleichst immer den 
letzten mit dem vorletzten Befehl, um herauszufinden, obs togglet oder 
nicht. Das ist alles viel zu umständlich. Dein Source würde sich 
vereinfachen, wenn Du einfach das Flag konsequent abfragst. Es bringt 
nichts, die IRMP-Werte an Dein Programm anzupassen. Besser wäre die 
Anpassung Deines Sources an IRMP.

Leider ist Dein Source nicht soooo übersichtlich, dass ich mir das in 5 
Minuten zu Gemüte führen kann, da ist schon etwas Detektivarbeit 
gefragt, um da durchzusteigen. Ich machs irgendwann in den nächsten 
Tagen, bin aber viel unterwegs. Kann also etwas dauern.

Gruß,

Frank

von Joachim B. (Gast)


Lesenswert?

Frank M. schrieb:
> Ich weiß nicht, ob ich es schaffe, mir das in den nächsten Tagen
> anzuschauen.
>
> Wenn Du gern alle FBs mit IRMP für Dein Programm nutzen möchtest, dann
> musst Du Dich gedanklich vom Toggle-Bit lösen. Du vergleichst immer den
> letzten mit dem vorletzten Befehl, um herauszufinden, obs togglet oder
> nicht. Das ist alles viel zu umständlich. Dein Source würde sich
> vereinfachen, wenn Du einfach das Flag konsequent abfragst.

das hatten wir doch versucht ? ohne Erfolg :-(

> Es bringt
> nichts, die IRMP-Werte an Dein Programm anzupassen. Besser wäre die
> Anpassung Deines Sources an IRMP.

klar ich bin sehr dafür !

> Leider ist Dein Source nicht soooo übersichtlich, dass ich mir das in 5
> Minuten zu Gemüte führen kann, da ist schon etwas Detektivarbeit
> gefragt, um da durchzusteigen.

genau deswegen wird er ja so pö a pö neugeschrieben, war eben ne top 
down Entwicklung (erwähnte ich das ich kein Softi bin :D)
PS. brauchst du noch den umfangreichen Rest ?

> Ich machs irgendwann in den nächsten
> Tagen, bin aber viel unterwegs. Kann also etwas dauern.

alles klar, danke, ich werde mich nun mal um die Straffung und 
Bereinigung kümmern, einiges gefällt mir selber nicht mehr, z.B. mein 
"Multitask" viel zu umständlich (ich hasse delays, jede Menge Timercode 
den man so im Netz findet lässt die CPU ewig in delay-Schleifen unnütz 
warten, dabei kann man in der Zeit auch was anderes tun, die ADC 
befragen, das LCD updaten, die Uhr weiterlaufen lassen, die DCF77 Bits 
befragen die Tastatur abholen und natürlich auf Events reagieren wie LED 
zurücksetzen

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:

> das hatten wir doch versucht ? ohne Erfolg :-(

Wir? Nein! Bis heute kannte ich Deinen Source doch überhaupt nicht. Und 
mich beschleicht das Gefühl, dass Du Deinen Source auch nicht (mehr) so 
gut kennst :-)

Folgende Maßnahmen sind notwendig, um vom RC5-Protokoll wegzukommen:

 - Das toggle-Bit muss komplett raus.
 - Der Vergleich alter <--> neuer Frame muss raus, ist überflüssig
 - Das Multiplizieren/Addieren der Adresse mit dem Kommando muss raus
   (das funktioniert nur mit RC5 so, bei NEC geht das schon voll in die
    Hose)

> klar ich bin sehr dafür !

Ich schlage vor, dass ich dafür ein Grundgerüst schreibe, dass Du dann 
mit Leben füllst (reinschreiben konkreter numerischer Werte + Test). 
Dann sollte das machbar sein.

> genau deswegen wird er ja so pö a pö neugeschrieben, war eben ne top
> down Entwicklung (erwähnte ich das ich kein Softi bin :D)
> PS. brauchst du noch den umfangreichen Rest ?

Dieses "pö a pö" ist der falsche Weg, das macht alles nur 
unübersichtlicher. Besser ist es, die Funktion fb() komplett neu zu 
schreiben. Schreib doch mal auf, was die Funktion bei welcher Taste 
machen soll, z.B.

TAB kurz:    nächster Menüpunkt Funktion: menu_down()
TAB lang:    Untermenüaufruf, Funktion: sub_menu()

So in der Richtung...

Aber ich bin in der nächsten Woche komplett ausgelastet, ich komme da 
erst übernächste Woche zu.

von Joachim B. (Gast)


Lesenswert?

Frank M. schrieb:
> Wir? Nein! Bis heute kannte ich Deinen Source doch überhaupt nicht. Und
> mich beschleicht das Gefühl, dass Du Deinen Source auch nicht (mehr) so
> gut kennst :-)

hmm du hattest gesagt wie und ich habs eingetippt, mit der Folge,

Versuch 1
das bei "ewigem" Tastendruck die LED trotzdem an und aus ging, also die 
Einmalabfrage nicht klappte
Versuch 2
die einmal Abfrage zwar klappte, aber nur einmal, Taste loslassen hatte 
danach keinerlei Wirkung mehr, erst der Tastenwechsel und zurück lies 
die Taste wieder erkennen

> Folgende Maßnahmen sind notwendig, um vom RC5-Protokoll wegzukommen:
>  - Das toggle-Bit muss komplett raus.
>  - Der Vergleich alter <--> neuer Frame muss raus, ist überflüssig
>  - Das Multiplizieren/Addieren der Adresse mit dem Kommando muss raus
>    (das funktioniert nur mit RC5 so, bei NEC geht das schon voll in die
>     Hose)

OK

> Ich schlage vor, dass ich dafür ein Grundgerüst schreibe, dass Du dann
> mit Leben füllst (reinschreiben konkreter numerischer Werte + Test).
> Dann sollte das machbar sein.

noch mehr OK

> Dieses "pö a pö" ist der falsche Weg, das macht alles nur
> unübersichtlicher. Besser ist es, die Funktion fb() komplett neu zu
> schreiben. Schreib doch mal auf, was die Funktion bei welcher Taste
> machen soll, z.B.
>
> TAB kurz:    nächster Menüpunkt Funktion: menu_down()
> TAB lang:    Untermenüaufruf, Funktion: sub_menu()
>
> So in der Richtung...

da grübel ich ja gerade, IR und Tastatur sind gleichberechtigt
entweder ich lese die Taste und weise dem einen IR Code zu und erledige 
die Aufgaben da, oder ich lese den IR Code und setze KEY und erledige 
die Aufgaben da ????

natürlich muss ich dann KEY Test und IR Test irgendwie sonderbehandeln

> Aber ich bin in der nächsten Woche komplett ausgelastet, ich komme da
> erst übernächste Woche zu.

no Problem, mache ich erst mal den Rumpf weiter (Display ist größer 
geworden, von 20 x 4 alphanumerisch auf 21 x 8 Z -aber grafisch- )

Ich muss eh die Screens neu definieren, den RAM Verbrauch eindämmen, 
Grafik ohne Lesemöglichkeit kostet, und Strings gleich aus dem flash zu 
lesen, oder ins EEPROM schieben um da ändern zu können

also ich bin beschäftigt solange du noch nicht kannst

Danke und viel Erfolg

von Michael K. (Gast)


Lesenswert?

Weiter oben wurde mal wegen Stromsparmechanismen diskutiert. Hat sich 
mal jemand weiter damit auseinandergesetzt und/oder Erfahrungen damit 
gesammelt, zwecks Realisierbarkeit? Die neueren TSOPs (z.B. TSOP34838) 
kommen ja mit weniger als 1mA aus - da würde sich das IMO schon lohnen.

von Joachim B. (jar)


Lesenswert?

Michael K. schrieb:
> Weiter oben wurde mal wegen Stromsparmechanismen diskutiert. Hat sich
> mal jemand weiter damit auseinandergesetzt und/oder Erfahrungen damit
> gesammelt, zwecks Realisierbarkeit? Die neueren TSOPs (z.B. TSOP34838)
> kommen ja mit weniger als 1mA aus - da würde sich das IMO schon lohnen.

hmm, bedingt, was meinst du damit ? als Sender oder Empfänger ?

im Prinzip einfach, an einer TastenMatrix für IRSND den pin-change 
wakeup und senden, als Empfänger dito pinchange belauscht den TSOP

ich habe es in meinem Timer1 gemacht, luca in einem Cam Trigger, da 
werden sogar die Puls/Pausenzeiten per sleep realisiert, also jedes 
delay schickt die CPU schlafen bis die Zeit um ist

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Michael K. schrieb:
> Weiter oben wurde mal wegen Stromsparmechanismen diskutiert. Hat sich
> mal jemand weiter damit auseinandergesetzt und/oder Erfahrungen damit
> gesammelt, zwecks Realisierbarkeit?

Das ist eigentlich nicht Sache des IRMP - als Bibliothek betrachtet.

> Die neueren TSOPs (z.B. TSOP34838) kommen ja mit weniger als 1mA
> aus - da würde sich das IMO schon lohnen.

Es geht auch mit den älteren TSOPs, wenn man die Stromversorgung des 
TSOPs über einen ATMega-Pin steuert. Ich habe das so in der Lernfähigen 
Fernbedienung so umgesetzt, die auch IRMP nutzt:

http://www.mikrocontroller.net/articles/DIY_Lernf%C3%A4hige_Fernbedienung_mit_IRMP

Dafür muss dann aber das Programm "wissen", wann es den TSOP einschalten 
muss, damit etwas empfangen werden kann. Der Stromverbrauch bei diesem 
Mini-Projekt liegt bei weit unter 1µA.

Gruß,

Frank

von Michael K. (Gast)


Lesenswert?

Ich meinte als Empfänger, der allzeit bereit sein soll.

von jar (Gast)


Lesenswert?

Frank M. schrieb:
> Es geht auch mit den älteren TSOPs, wenn man die Stromversorgung des
> TSOPs über einen ATMega-Pin steuert.

dann geht das folgende aber nicht, der TSOP muss ja Vcc haben damit er 
ein output an pin change AVR senden kann

Michael K. schrieb:
> Ich meinte als Empfänger, der allzeit bereit sein soll.

klaro, schick die CPU schlafen der TSOP bleibt auch on an Vcc und weckt 
mit Signal out an einen PIN Change den AVR, das AVR delay dürfte 
vernachlässigbar sein ? irgendwas um 65 CLK also bei 20 MHz AVR 3µs,
Frank wird das eher wissen ob das delay die Auswertung stört

@frank, mal zu meinem "Problem" geschaut ?

von Dirk W. (glotzi)


Lesenswert?

Hallo zusammen,

ich verwende IRMP zusammen mit dem IR-Receiver in Hugo Portisch. Da der 
IR-Receiver einen älteren Stand aus dem letzen Jahr enthält, habe ich 
ein Upgrade auf IRMP-SVN-Head gemacht. Das funktioniert soweit auch gut, 
bis auf folgendes:

1. ich kann keine Frequenzen > 10000 benutzen, dann wird nichts mehr 
erkannt. Das könnte auch ein IR-Receiver spezifisches Problem sein. Im 
Thread dort habe ich schon nachgefragt aber keine Antwort bekommen. BTW 
der ältere Stand aus dem letzen Jahr hat das gleiche Problem.

2. Die Ruwido Merlin funktioniert bei mir nicht, es wird nur Müll 
erkannt. Wie ist denn der genaue Status der Merlin Implementierung? 
Sollte das funktionieren?

Folgende Protokolle funktionieren bei mir: RC6A, Samsung32, FDC 
Keyboard.

von Michael K. (Gast)


Lesenswert?

Dirk W. schrieb:
> Im Thread dort habe ich schon nachgefragt aber keine Antwort bekommen.
Ich habe dir doch dort geantwortet 
(Beitrag "Re: USB IR Remote Receiver (V-USB + IRMP)").

Mit IRMP hat das Problem nichts zu tun. Derzeit gibt es keine Lösung, 
daher sollte der Regler IMO in ruhe gelassen werden. Anders sieht es mit 
dem Makro F_INTERRUPTS aus: das kann geändert werden und die Firmware 
sollte nach der Neukompilierung laufen (ich habe es nicht getestet).

Um das zu beheben müsste für jedes Makro in irmp.c, Zeile 385 bis 599, 
eine Variable her, deren Inhalt bei einer Änderung neu berechnet werden 
müsste. Das hätte einen Speicherverbrauch zur Folge der den Rahmen eines 
AVR sprengt.

von Dirk W. (glotzi)


Lesenswert?

Michael K. schrieb:
> Mit IRMP hat das Problem nichts zu tun. Derzeit gibt es keine Lösung,
> daher sollte der Regler IMO in ruhe gelassen werden. Anders sieht es mit
> dem Makro F_INTERRUPTS aus: das kann geändert werden und die Firmware
> sollte nach der Neukompilierung laufen (ich habe es nicht getestet).

Ich habe natürlich F_INTERRUPTS in der IRMP Source geändert und nicht 
über die Windows-DLL. Es funktionert (bei mir) nicht.

von KLez (Gast)


Lesenswert?

Hallo,

Mal eine frage: Wäre es möglich, dass IRMP auch das Ausgangssignal des 
Funkempfängers von z.B. der Logitech Harmony 900 dekodieren kann? Dessen 
Ausgang ist eigentlich dazu da einen extra IR Sender anzuschließen. Da 
dieser Sender aber nur IR-Dioden enthält, gehe ich davon aus, dass das 
Signal bereits mit der Trägerfrequenz versehen ist, usw.

IRMP müsste also zuerst noch die Trägerfrequenz rausrechnen um an das 
Nutzsignal zu kommen... Ist es möglich das einzubauen oder funktioniert 
das ohne extra Hardware allgemein nicht?

P.S.: Die Frage habe ich auch schon im USB IR Empfänger Thread gestellt, 
aber eventuell bin ich hier "richtiger".

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

KLez schrieb:
> IRMP müsste also zuerst noch die Trägerfrequenz rausrechnen um an das
> Nutzsignal zu kommen... Ist es möglich das einzubauen oder funktioniert
> das ohne extra Hardware allgemein nicht?

Ja, das sollte möglich sein.

Gruß,

Frank

von Dirk W. (glotzi)


Lesenswert?

@Frank M.

Darf ich deine Aufmerksamkeit auf diesen Beitrag 
Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"

lenken. Vorallem Punkt 2 würde mich interessieren.
Danke.

von KLez (Gast)


Lesenswert?

Frank M. schrieb:
> Ja, das sollte möglich sein.

Hallo Frank,

Ich habe gerade nochmal geschaut und glaube ehrlichgesagt nicht, dass es 
so einfach möglich ist. Wie ich lesen konnte pollst Du den Eingang mit 
10KHz... Das ist nach meinem Verständnis also um das 3,8 fache zu wenig 
um eine 38Khz Trägerfreuqenz raus zu rechnen, oder habe ich gerade einen 
Denkfehler?

Wie würdest Du das ganze implementieren?

Viele Grüße

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

KLez schrieb:
> Ich habe gerade nochmal geschaut und glaube ehrlichgesagt nicht, dass es
> so einfach möglich ist. Wie ich lesen konnte pollst Du den Eingang mit
> 10KHz... Das ist nach meinem Verständnis also um das 3,8 fache zu wenig
> um eine 38Khz Trägerfreuqenz raus zu rechnen, oder habe ich gerade einen
> Denkfehler?

Eine 38kHz Trägerfrequenz hat eine Periodenlänge von ca. 26 µsec. Du 
musst die Pulse von ca. 13 µsec softwaremäßig auf mehr als 26 µsec 
verlängern, damit IRMP ein durchgängiges Signal "sieht".

> Wie würdest Du das ganze implementieren?

Ich würde mir einen PCINT-Interrupt auf das Eingangssignal setzen. Dort 
setze ich ein globales Flag namens ir_signal, z.B. so:
1
#define IR_OFF    1             // no IR signal
2
#define IR_ACTIVE 0             // IR signal active
3
4
volatile uint8_t ir_signal = IR_OFF;
5
6
ISR(PCINT1_vect)
7
{
8
    ir_signal = IR_ACTIVE;      // IR is active
9
}

In der normalen Timer_ISR, die Du ja sowieso für den Aufruf der IRMP-ISR 
brauchst, würde ich nach(!) dem Aufruf von irmp_ISR() dieses Flag wieder 
zurücksetzen, also:
1
ISR(TIMER1_COMPA_vect)
2
{
3
  (void) irmp_ISR();
4
  ir_signal = IR_OFF;
5
}

In irmpconfig.h setzt Du:
1
#define input(x)        ir_signal


Der Trick ist, dass Du damit jeden Puls des Trägersignals solange 
softwaremäßig verlängerst, dass die IRMP-ISR ihn mindestens einmal 
"sieht". Da der PCINT bei aktivem IR-Signal viel öfter kommt als die 
IRMP-ISR ausgelöst wird, sollte das so klappen.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Dirk W. schrieb:
> Darf ich deine Aufmerksamkeit auf diesen Beitrag
> Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"
> lenken. Vorallem Punkt 2 würde mich interessieren.

Sorry, zum Punkt 1 kann ich nichts beitragen, ich habe mich bisher nicht 
so tief in Hugos V-USB Port reingehängt.

Zum Punkt 2: Muss ich zu Hause nachschauen, wie weit ich da bin, habe 
zwischwendurch viele andere interessante Sachen gemacht. ;-)

Ich melde mich dazu nochmal.

Gruß,

Frank

von Dirk W. (glotzi)


Lesenswert?

Frank M. schrieb:
> Zum Punkt 2: Muss ich zu Hause nachschauen, wie weit ich da bin, habe
> zwischwendurch viele andere interessante Sachen gemacht. ;-)
>
> Ich melde mich dazu nochmal.

Danke fürs Feedback. Ich habe inzwischen noch eine Netbox Tastatur hier 
und die funktioniert auch nicht. Es wird nur gelegentlich RC6A erkannt. 
Evtl. hängt das mit den Merlin Problem zusammen.

Bei der FDC Tastatur ist mir aufgefallen, dass wenn ich längere Zeit 
eine Taste festhalte nicht auschliesslich Events mit Protokoll FDC 
geschickt werden, sondern auch welche mit Protokoll Merlin. Das kann 
aber auch Zufall sein, dass irgendwas überläuft und ausgerechnet Merlin 
Codes geschickt werden. Die Codes sehen auch ziemlich seltsam aus.

von KLez (Gast)


Lesenswert?

Hallo Frank M,

Vielen Dank für Deine Ausführung! Ich werde mal damit ein wenig 
experimentieren. Trotzdem noch eine Frage: Wäre es nicht einfacher einen 
seperaten Eingang dafür zu nehmen und das Signal direkt auf den 
Interrupt des AVR zu legen? Dann müsste dieser doch nur noch die Flanken 
zählen und das Ergebnis an irmp übergeben.

von Fred (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

ich hatte mal wieder Zeit etwas zu basteln. Dazu hab ich natürlich die 
aktuelle Version vom svn gezogen und mal mit allen FB durchprobiert.
Funktioniert fast perfekt, nur mit dieser Sagem FB für die d-box klappt 
es nicht so richtig. Es wird als Merlin erkannt und zeigt aber 
verschiedene Adressen und Codes an. Scheint nicht ganz das gleiche zu 
sein.

Da ich das Ganze mal sauber aufgebaut haben wollte und nicht nur auf dem 
Experimentierboard, hsb ich die Pollin RS232-Bas Platine verwendet.
Mit minimalen Änderungen kann man die dazu verwenden und muß sich keine 
eigen Platine ätzen.

Angefügt hab ich mal meine main.c die momentan nur zum Testen der FB 
dient.

Wenn ich mal wieder dazukommen werden ich noch eine Anpassung der FDC 
Tastatur schreiben, damit sie an einen PC angebunden werden kann.

Fred

von eku (Gast)


Lesenswert?

Hallo Frank,

um IRMP mit dem aktuellen GCC 4.6.1 zu übersetzen sind alle PROGMEM
Variablen als const zu markieren, was auch nur logisch ist. Könntest Du 
den SVN Quellcode diesbezüglich bitte aktualisieren.

Danke.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:
> um IRMP mit dem aktuellen GCC 4.6.1 zu übersetzen sind alle PROGMEM
> Variablen als const zu markieren, was auch nur logisch ist. Könntest Du
> den SVN Quellcode diesbezüglich bitte aktualisieren.

Ist erledigt.

Gruß,

Frank

von Daniel S. (daniel_s38)


Lesenswert?

Hallo!

Nachdem ich die Frage hier

Beitrag "USB IR Remote Receiver (V-USB + IRMP)"

schonmal gestellt habe und dabei auf dieses Forum verwiesen wurde 
versuch ichs nun hier:

Ich habe diesen Empfänger:

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

laut Anleitung aufgebaut, funktioniert tadellos.
Allerdings habe ich ein kleines Problem:

Die (Noname) Fernbedienung, welche ich mit dem Empfänger verwenden
möchte, hat einige Tasten, die nicht erkannt werden ("8", "Mute" und
einige weitere).
Diese Tasten funktionieren jedoch über den IgorPlug problemlos.
Alle anderen werden einwandfrei erkannt.

Hat jemand eine Idee, woran das liegen könnte?
Der einzige Unterschied in meinem Aufbau ist, daß ich einen TSOP 1136
verwende.....kann es daran liegen?

Muß dazu sagen daß ich ein absoluter Laie bin was das Thema 
programmieren o.ä. angeht....

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Daniel S. schrieb:
> Nachdem ich die Frage hier
>
> Beitrag "USB IR Remote Receiver (V-USB + IRMP)"
>
> schonmal gestellt habe [...]

... habe ich dir dort geantwortet:

  Beitrag "Re: USB IR Remote Receiver (V-USB + IRMP)"

Die Antwort gilt natürlich hier auch :-)

Gruß,

Frank

von eku (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Frank,

würdest Du bitte den Mitschnitt im Anhang analysieren. Mir ist es nicht 
gelungen, die Fernbedienung eines SAT-Receivers von Medion mit 
irgendeinem Protokoll zu dekodieren. Manchmal sprang der RC5-Algorithmus 
an, lieferte aber unabhängig von der gedrückten Taste den selben Code.

Danke.

von Dirk W. (glotzi)


Lesenswert?

Frank M. schrieb:
> Zum Punkt 2: Muss ich zu Hause nachschauen, wie weit ich da bin, habe
> zwischwendurch viele andere interessante Sachen gemacht. ;-)
>
> Ich melde mich dazu nochmal.

Hmm, darf ich nach 4 Wochen mal vorsichtig fragen wie denn der Status zu 
meiner Anfrage bzgl. Merlin Tastatur ist?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo eku,

eku schrieb:

> würdest Du bitte den Mitschnitt im Anhang analysieren.

Habs mir gerade mal im Editor und mit "irmp -a" angeschaut. Das 
Protokoll ist einfach, aber ziemlich blöde für irmp.

Eigenschaften:

1. Bitserielles Protokoll mit Datenrate von 600Bd
2. 1 Startbit ohne Pause, 8 Datenbits, 1 Stopbit
3. Jeder Frame wird 2x gesendet.

Blöd für IRMP ist der Punkt 2: Ohne Pause nach dem Startbit kann das 
Protokoll nicht eindeutig erkannt werden, weil schon der erste Puls 
1-fache bis 9-fache Länge haben kann.

Ich kann das Protokoll zwar einbauen in IRMP, aber man müsste sämtliche 
anderen Protokolle deaktivieren, damit dieses eindeutig erkannt wird. 
Die Geschichte ist also für einen Multiprotoll-Decoder ziemlich 
unsinnig.

Einfacher wäre es, den TSOP direkt an den UART zu hängen und den UART 
auf 600 Bd einzustellen. Dann kann man die Bytes direkt mit jeder 
üblichen UART-Lib auslesen. Im IRMP wäre es sowieso nichts anderes als 
ein Software-Uart.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Dirk W. schrieb:
> Hmm, darf ich nach 4 Wochen mal vorsichtig fragen wie denn der Status zu
> meiner Anfrage bzgl. Merlin Tastatur ist?

Sorry, Dirk. Ich hatte dazu wenig Lust in der letzten Zeit, muss ich 
zugeben. Ich versuche, mich in der kommenden Woche mal dazu aufzuraffen.

Gruß,

Frank

von Dirk W. (glotzi)


Lesenswert?

Frank M. schrieb:
> Sorry, Dirk. Ich hatte dazu wenig Lust in der letzten Zeit, muss ich
> zugeben.
Dafür habe ich vollstes Verständnis, daher frage ich auch jetzt erst 
nach, ist ja alles deine Freizeit.

> Ich versuche, mich in der kommenden Woche mal dazu aufzuraffen.
Wäre schön. Wie gesagt, mir geht es nur darum: funzt die Merlin mit dem 
Head-Stand oder nicht. Also ein reiner Funktionstest.

von narkus (Gast)


Lesenswert?

Toll das!! :))
Großes Lob, Frank!

Ich habe das in einen AT90USB "eingebaut", der zugleich sich als HID 
Keyboard ausgibt. So kann ich die empfangenen RC5-Signale als 
Tastendruck ans Media Center übergeben! :)

Als HID USB nutze ich LUFA. Bei mir funktioniert alles soweit. Mein Code 
für die FB-Auswertung sieht im Groben wie folgt aus:
1
if (irmp_get_data (&irmp_data))
2
{    
3
  if (irmp_data.address == 19)
4
  {      
5
    if (!(irmp_data.flags & IRMP_FLAG_REPETITION))
6
    {  switch(irmp_data.command)
7
      {  case ir_hoch:  Taste = t_hoch;    break;
8
        case ir_runter:  Taste = t_runter;  break;
9
        case ir_links:  Taste = t_links;  break;
10
        case ir_rechts:  Taste = t_rechts;  break;
11
        case ir_enter:  Taste = t_enter;  break;
12
        default:  break;
13
      }
14
    }
15
  }
16
}
17
else
18
{  
19
  Taste = 0;
20
}

Wenn ich nun die Abfrage nach dem IRMP_FLAG_REPETITION weglasse, 
reagiert alles rattenschnell. Allerdings läuft LUFA öfter durch als IRMP 
mir Werte liefern kann. Was zur Folge hat, dass meine Variable "Taste" 
zwischendurch Null gesetzt wird, obwohl ich die FB-Taste gedrückt halte, 
und LUFA das als schnelle hintereinanderfolgende Tastendrücke 
interpretiert. Sprich, ich drücke nur kurz für ein Zeichen, aber bekomme 
mein Zeichen auf dem Bildschirm mehrmals ausgegeben.

Dafür ist ja IRMP_FLAG_REPETITION da (siehe Codeschnipsel). Allerdings 
habe ich so umgekehrt das Problem, wenn ich gerade mal eine Taste 
mehrmals schnell hintereinander drücken will (für track skippen oder 
Ähnliches), scheinen Telegramme verloren zu gehen, nicht jeder 
Tastendruck wird erkannt. Woran kann das liegen?

Ich habe versucht, das mit einem Zähler aufzufangen, der abschätzt, ob 
das nächste Telegramm länger als 117ms gebraucht hat, was ich dann als 
neuen Tastendruck interpretiere. Erst nach Ablauf des Zählers setze ich 
meine Variable "Taste" zu Null. Das hat aber zur Folge, dass LUFA nach 
losgelassener Taste merklich länger das Zeichen ausgibt, bevor es die 
Ausgabe stoppt. Das spricht einerseits dafür, dass mein Zähler deutlich 
länger als 117ms braucht - sonst würde ich es nicht merken können -, 
aber wenn ich den Zählerwert nur leicht heruntersetze, habe ich das 
Problem mit ohne IRMP_FLAG_REPETITION-Abfrage wieder. (?)

Ich denke idealer Weise an folgende Lösung: Kannst Du denn deinem 
Programm nicht ähnlich der Pollin IR-Tastatur beibringen, nach 
losgelassener Taste dem Kommando das 8. Bit hinzuzufügen (oder 
beliebiger fester Wert >0x80, mich interessiert nicht unbedingt welche 
Taste losgelassen wurde, sondern dass eine losgelassen wurde)? Das 
wäre nämlich schneller und sicherer als mein Zähler! Ich hatte versucht, 
selber Hand anzulegen, aber ich habe Deinen Code leider doch nicht voll 
und ganz verstanden.

Danke und Gruß

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

narkus schrieb:
> Toll das!! :))
> Großes Lob, Frank!

Danke :-)

>   if (irmp_data.address == 19)

Besser:

>   if (irmp.protocol == IRMP_RC5_PROTOCOL && irmp_data.address == 19)

So kann Dir keine andere FB, die auch die Adresse 19 (aber ein anderes 
Protokoll) hat, dazwischenfunken.

> Dafür ist ja IRMP_FLAG_REPETITION da (siehe Codeschnipsel). Allerdings
> habe ich so umgekehrt das Problem, wenn ich gerade mal eine Taste
> mehrmals schnell hintereinander drücken will (für track skippen oder
> Ähnliches), scheinen Telegramme verloren zu gehen, nicht jeder
> Tastendruck wird erkannt. Woran kann das liegen?

IRMP unterscheidet über die Konstante

  IRMP_KEY_REPETITION_LEN

in irmp.c, ob es sich um eine schnell gedrückte Wiederholungstaste 
handelt oder ob die FB selbst "repetiert" - durch langen Tastendruck. 
Offenbar schaffst Du es, innerhalb von 150msec die Taste mehr als einmal 
zu drücken... Du bist da ganz schön schnell :-)

Verkleinere den Wert einfach mal - z.B. von 150.0 auf 120.0 oder 100.0.

> Ich denke idealer Weise an folgende Lösung: Kannst Du denn deinem
> Programm nicht ähnlich der Pollin IR-Tastatur beibringen, nach
> losgelassener Taste dem Kommando das 8. Bit hinzuzufügen (oder
> beliebiger fester Wert >0x80, mich interessiert nicht unbedingt *welche*
> Taste losgelassen wurde, sondern dass eine losgelassen wurde)?

Das würde ich ungern machen wollen. Es gibt nämlich durchaus FBs, die 
16-Bit-Kommandos rausschicken, da bräuchte ich dann ein 17. Bit.

Was ich besser fände: Bei RC5 und RC6 gibt es das sog. Toggle-Bit im 
IR-Frame. Dieses könnte ich im IRMP auswerten, ob eine Taste lang 
gedrückt wurde oder ob der Anwender diese kurz gedrückt hatte und 
entsprechend das Repetition-Flag setzen. Ändert sich das Toggle-Bit 
nicht und bleibt der Code derselbe, würde ich dann das Repetition-Flag 
setzen - unabhängig von IRMP_KEY_REPETITION_LEN (was ich für die anderen 
Protokolle aber weiterhin benötige!). Im Moment ignoriert IRMP das 
Toggle-Bit.

Ich schaue mal, dass ich das am Wochenende so einbaue. Du könntest 
parallel dazu aber mal den Wert der Konstanten IRMP_KEY_REPETITION_LEN 
testweise herabsetzen und hier berichten.

Gruß,

Frank

P.S.
Hast Du ein Schaltbild zu Deiner Lösung? Ich habe mit den 
AT90USB-Dingern noch nie was gemacht. Vielleicht wäre das ja eine 
Erwähnung im IRMP-Artikel wert....

von jar (Gast)


Lesenswert?

Frank M. schrieb:
> Was ich besser fände: Bei RC5 und RC6 gibt es das sog. Toggle-Bit im
> IR-Frame. Dieses könnte ich im IRMP auswerten, ob eine Taste lang
> gedrückt wurde oder ob der Anwender diese kurz gedrückt hatte und
> entsprechend das Repetition-Flag setzen. Ändert sich das Toggle-Bit
> nicht und bleibt der Code derselbe, würde ich dann das Repetition-Flag
> setzen - unabhängig von IRMP_KEY_REPETITION_LEN (was ich für die anderen
> Protokolle aber weiterhin benötige!). Im Moment ignoriert IRMP das
> Toggle-Bit.

das sieht nach meinem "alten" Problem aus, hatte ich ja auch schon mal 
gewünscht, evt. kommts doch noch in IRMP, dann kann ich endlich die RC5 
ISR rauswerfen :-)

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

jar schrieb:

> das sieht nach meinem "alten" Problem aus,

Nicht ganz: Du hast dir immer gewünscht, dass Dir IRMP das Toggle-Bit 
liefert, damit Du den Code nicht umschreiben musst. ;-)

Sorry, das werde ich nicht machen. Ich brauche eine Lösung für alle 
von IRMP unterstützten Protokolle. Ich kann für RC5/RC6 das Toggle-Bit 
auswerten, um das Repetition-Flag korrekt zu setzen... aber mehr nicht.

von jar (Gast)


Lesenswert?

Frank M. schrieb:
> Ich kann für RC5/RC6 das Toggle-Bit
> auswerten, um das Repetition-Flag korrekt zu setzen... aber mehr nicht.

das würde ja reichen :-)

aber wie der letzte User das beschreibt erinnert mich genau ! an mein 
Problem mit der Auswertung, hab ich ja deutlich genug beschrieben, wir 
dokterten ja auch gemeinsam mit allen möglichen Ideen rum, nur nix half

es ist doch so das entweder noch Repeatcodes im Buffer liegen und 
nachgeliefert werden auch wenn die eigendliche Aktion schon gelaufen ist 
oder wie auch immer, mit 1x drücken bekomme ich entweder kein Licht an 
oder gleich wieder aus weil mir das toogle Bit fehlt, nur deswegen 
bedine ich meinen Timer ja mit RC5 und werte die Bedienung mit RC5 aus, 
an dieser Stelle ist IRMP nur gut um Codes zu liefern (hört sich jetzt 
härter an als es gemeint ist !

ne wirklich, finde IRMP gut nutze es auch gerne, nur du wolltest vor 
Monaten mal meine Code durchgucken warum ich mit IRMP nicht bedienen 
kann, der mit RC5 prima läuft.....

von master control (Gast)


Lesenswert?

Eine Frage: welche Pegel gibt IRSND auf der Konsole aus? Ist es 
invertiert?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

master control schrieb:
> Eine Frage: welche Pegel gibt IRSND auf der Konsole aus? Ist es
> invertiert?

Da das Signal mit 32, 36, 38 oder 40kHz moduliert ist, ist der Pegel 
vollkommen unerheblich ;-)

Wenn Du Dir den Minischaltplan unter

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

ansiehst, erkennst Du, dass die Pausen Low-Pegel haben.

Gruß,

Frank

von narkus (Gast)


Angehängte Dateien:

Lesenswert?

>Besser:
>
>>   if (irmp.protocol == IRMP_RC5_PROTOCOL && irmp_data.address == 19)

Stimmt!! :))

Ich bin tatsächlich ein schneller Drücker! Ich habe 
IRMP_KEY_REPETITION_LEN auf 100.0 gesetzt, und habe mit schnellen 
Tastendrücken kaum noch ein Problem. Interessanter Weise wird das 
IRMP_FLAG_REPETITION noch richtig gesetzt, obwohl dieser Werte unterhalb 
der 117,zerquetschte ms liegt. Vielleicht hält aber auch mein Sender den 
RC5 nicht zu 100% ein, müsste ich mal mitm Oszi kontrollieren. Ich nehme 
das jetzt mal so hin.

Toggle Bit ist zwar nett, aber einerseits brauche ich es nicht, wenn das 
repetition flag funktioniert. Andererseits hilft es mir nicht bei der 
Aussage, wie lange eine Taste gedrückt gehalten wurde repektive wann sie 
losgelassen wurde.

Das Problem liegt darin, dass die Funktion irmp_get_data() Nullwerte 
ausgibt, owohl sie eigentlich gerade dabei ist, einen möglichen langen 
Tastendruck auszuwerten. Wenn ich jedoch Null erhalte, setze ich auch 
meine Variable "Taste" auf Null. Mein Programm kann somit nicht ohne 
selbst mitlaufendem Timer erkennen, ob eine Taste nicht mehr gedrückt 
wird. Und dieser Timer erzeugt ei mir die eingangs schon erwähnte 
merkliche Latenz beim Loslassen.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

narkus schrieb:
> Ich bin tatsächlich ein schneller Drücker! Ich habe
> IRMP_KEY_REPETITION_LEN auf 100.0 gesetzt, und habe mit schnellen
> Tastendrücken kaum noch ein Problem.

Ich habe nun ins SVN eine neuere Version von IRMP eingecheckt, die das 
RC5-Toggle-Bit als zusätzliches Kriterium heranzieht, ob eine Taste lang 
oder kurz gedrückt wurde.

Bitte teste das nochmal mit dem alten Wert von IRMP_KEY_REPETITION_LEN = 
150. Es sollte nun für RC5 auch mit dem 150er Wert zuverlässig 
funktionieren. Die 150msec brauche ich nämlich für diverse andere 
Protokolle, ich kann es also nicht pauschal auf 100 setzen.

> Interessanter Weise wird das
> IRMP_FLAG_REPETITION noch richtig gesetzt, obwohl dieser Werte unterhalb
> der 117,zerquetschte ms liegt.

Die 150msec beschreiben den Abstand zwischen 2 Frames - exkl. dem 1. 
Frame. Bei der RC5-Repetition-Time von ca. 115msec, die man in diversen 
Quellen findet, ist mir nicht ganz klar, ob der 1. Frame mitgestoppt 
wird, z.B. hier:

   http://users.telenet.be/davshomepage/rc5.htm

> Vielleicht hält aber auch mein Sender den RC5 nicht zu 100% ein,
> müsste ich mal mitm Oszi kontrollieren.

Könnte auch sein. Wäre prima, wenn Du das mal nachmessen würdest.

> Toggle Bit ist zwar nett, aber einerseits brauche ich es nicht, wenn das
> repetition flag funktioniert.

Das Toggle-Bit bekommst Du auch nicht zu sehen. IRMP zieht es nun aber 
als zusätzliches Kriterium hinzu, um zu entscheiden, ob eine Taste lang 
oder mehrfach kurz gedrückt wurde.

> Das Problem liegt darin, dass die Funktion irmp_get_data() Nullwerte
> ausgibt, owohl sie eigentlich gerade dabei ist, einen möglichen langen
> Tastendruck auszuwerten.

Was sollte sie dann machen? Hängen und warten, bis der Frame komplett 
angekommen ist?

Ich könnte eine Funktion

     irmp_busy ()

bereitstellen, die TRUE zurückliefert, wenn gerade ein neuer Frame 
eingelesen wird.

Ein irmp_get_data(), welches blockiert, bis der Frame komplett ist, 
halte ich für nicht notwendig. Dies kann man einfach mit:
1
   while (! irmp_get_data (..))
2
   {
3
       ;  // wait, do nothing
4
   }
5
   ....   // action!

erledigen.

von jar (Gast)


Lesenswert?

Frank M. schrieb:
> Ich könnte eine Funktion
>
>      irmp_busy ()
>
> bereitstellen, die TRUE zurückliefert, wenn gerade ein neuer Frame
> eingelesen wird.

wäre auch toll

oder gibt es eine Möglichkeit den Buffer zu leeren wenn eine Taste 
erkannt wurde ? damit wenn ich die Taste auswerte und interagiere nicht 
ein neuer Tastendruck im Buffer lauert ?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

jar schrieb:
> oder gibt es eine Möglichkeit den Buffer zu leeren wenn eine Taste
> erkannt wurde ? damit wenn ich die Taste auswerte und interagiere nicht
> ein neuer Tastendruck im Buffer lauert ?

Könnte man natürlich auch einbauen. Die meisten Frames dauern ca. 30 - 
40 msec. Das ist doch eine halbe Ewigkeit, ich frage mich da, was Du da 
alles in der Zwischenzeit machen willst? ;-)

von jar (Gast)


Lesenswert?

Frank M. schrieb:
> Das ist doch eine halbe Ewigkeit, ich frage mich da, was Du da
> alles in der Zwischenzeit machen willst? ;-)

nun ja ich will nur das mein Programm funktioniert, mit jeder FB nicht 
nur mit RC5

eigendlich ganz einfach, man drückt doch solange die Taste bis das 
gewünschte eintritt, z.B. Licht an dann lässt man los, will aber nicht 
das dann das Licht wieder ausgeht weil noch was nachkommt, kürzer 
drücken geht nur wenn man weiss das der Code ankommt, aber die 
Rückmeldung ist doch Licht an, ich hoffe du verstehst warum das toogle 
Bit recht nützlich ist im RC5, das macht es einem leichter, alternativ, 
nach Erkennung Buffer leeren bis zur nächsten Abfrage.....

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

jar schrieb:
> eigendlich ganz einfach, man drückt doch solange die Taste bis das
> gewünschte eintritt, z.B. Licht an dann lässt man los, will aber nicht
> das dann das Licht wieder ausgeht weil noch was nachkommt,

Das ist doch einfach: Du ignorierst einfach alle Frames mit gesetztem 
Repetition-Flag - fertig.

> ich hoffe du verstehst warum das toogle
> Bit recht nützlich ist im RC5, das macht es einem leichter, alternativ,
> nach Erkennung Buffer leeren bis zur nächsten Abfrage.....

Naja, um das Toggle-Bit auszuwerten, brauchst Du immer den letzten und 
den aktuellen Zustand des Toggle-Bits, um diese dann beide zu 
vergleichen. Mit dem Repetition-Flag von IRMP ist es noch einfacher: 
Wenn gesetzt, handelt es sich um einen langen Tastendruck -> wegwerfen, 
fertig. Dass IRMP intern(!) genau das Toggle-Bit (bei RC5) dafür 
auswertet, um das Repetition-Flag zu setzen, muss Dich als IRMP-Anwender 
nicht kümmern.

von jar (Gast)


Lesenswert?

Frank M. schrieb:
> Das ist doch einfach: Du ignorierst einfach alle Frames mit gesetztem
> Repetition-Flag - fertig.

sagst du, aber das hatten wir doch alles schon durch und es lief nicht 
(wie gewünscht)

ich weiss ehrlich nicht warum du das immer wieder widerholst, entweder

IRMP liefert das richtige Tooglebit was im RC5 ja vorhanden ist 
transparent durch oder man muss dafür eben wie ich es nun mache in der 
ISR RC5 und IRMP laufen lassen......

klar verstehe ich deinen Wunsch IRMP für alle gleich zu behandeln, aber 
nur deswegen ein geliefertes Toogle Bit  zu repaet frames zu übersetzen 
und das toogle Bit zu unterschlagen kann auch nicht so richtig sein, du 
hast da einen ganz schönen Dickkopf

ich möchte doch nix exotisches, im RC5 steckt das toogle Bit, reiche es 
doch einfach durch und/oder gib uns ne leere_buffer Routine die auf 
Wunsch alles cleart

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

jar schrieb:

> sagst du, aber das hatten wir doch alles schon durch und es lief nicht
> (wie gewünscht)

Das läuft bei Dir nur deshalb nicht, weil Du Deinen Source nicht 
umschreibst und stattdessen versuchst, aus den IRMP-Daten (die nicht 
mehr protokollspezifisch sind) wieder RC5-Daten zu konstruieren - und 
das auch noch unzureichend.

> ich weiss ehrlich nicht warum du das immer wieder widerholst, [...]

Ich wiederhole mich immer wieder, weil Du Dich immer wiederholst. IRMP 
arbeitet korrekt, Du wendest aber IRMP nicht korrekt an! Solange Du 
immer wieder und wieder auf dem Toggle-Bit rumreitest, werde ich wieder 
und wieder das Repetition-Flag hervorkramen - ganz einfach :-)

Denk einfach daran: die Mehrheit aller anderen IR-Protokolle hat 
überhaupt kein Toggle-Bit. Und trotzdem funktioniert es.

> klar verstehe ich deinen Wunsch IRMP für alle gleich zu behandeln, aber
> nur deswegen ein geliefertes Toogle Bit  zu repaet frames zu übersetzen
> und das toogle Bit zu unterschlagen kann auch nicht so richtig sein, du
> hast da einen ganz schönen Dickkopf

Das Toggle-Bit gehört nicht in die IRMP-Daten. Soll ich mir das dann für 
die anderen 30 IR-Protokolle aus den Rippen schneiden?!?

Du hast den Dickkopf: Du reitest auf dem Toggle-Bit herum, weil Du zu 
faul bist, Deinen Code, der RC5-Spezifika nutzt, portabel umzuschreiben. 
Was willst Du denn in 5 Jahren machen, wenn es keine RC5-FB mehr gibt?

> ich möchte doch nix exotisches, im RC5 steckt das toogle Bit, reiche es
> doch einfach durch [...]

Nein, wenn ich es durchreiche, würde ja jeder zweite identische 
Tastendruck unterschiedliche IRMP-Daten liefern.

> und/oder gib uns ne leere_buffer Routine die auf Wunsch alles cleart

Hier hast Du sie:
1
void
2
irmp_clear (void)
3
{
4
   IRMP_DATA dummy;
5
6
   while (irmp_get_data (&dummy))
7
   {
8
        ;
9
   }
10
}

War das jetzt so schwierig?

Gruß,

Frank

von jar (Gast)


Lesenswert?

Frank M. schrieb:
> Hier hast Du sie:
> void
> irmp_clear (void)

> War das jetzt so schwierig?
> Frank

danke probiere ich ;-)

von PimmingerA (Gast)


Lesenswert?

abc

von PimmingerA (Gast)


Lesenswert?

Sieht wer eine Möglichkeit genau die Funktion des Senders & Empfängers 
auf einen PC zu Implementieren und die Bitmuster über USB-IR 
Sender/Empfänger zu senden/empfangen
Würde gerne verschiedene Fernseher über einen zentralen Server steuern 
und hierzu einen USB-IR Sender verwenden welche ich direkt bei der 
IR-Empfangsfenster beim Fernseher anbringe.

von jar (Gast)


Lesenswert?

PimmingerA schrieb:
> Sieht wer eine Möglichkeit genau die Funktion des Senders & Empfängers
> auf einen PC zu Implementieren und die Bitmuster über USB-IR

will ich auch hier gibt es irgenwo einen Thread IRMP mit USB

wenn ich mich richtig erinnere so als USB RS232 Umsetzer

Atmel mit USB Clientfunktion zu RS232 Umsetzer gibts ja schon, die 
Treiber für win gibts auch, braucht man nur RS232 Codes an die virtuelle 
COM zu schicken, bzw gleich IRMP im Atmel zu integrieren und zu senden

vom PC schickt man nur das Byte Protkoll, Adress, Command

nur mir fehlte bis jetzt noch die Zeit mich da einzulesen unbd das zu 
bauen

evt. schaust du mal und meldest rück ?

von jar (Gast)


Lesenswert?


von jar (Gast)


Lesenswert?

ist leider nur Receiver ?

wir brauchen ja IRSND

IRMP + IRSND in einem Atmel zu bringen geht ja
USB zu RS232 Umsetzer auch
beides zusammen sollte auch gehen, vom PC angesprochen als virtuelle COM 
nur das wir im Atmel nix mehr an die serrielle Schnitte RX + TX ausgeben 
und empfangen, stattdessen IRMP und IRSND nutzen

Idee im Kopf fertig, nur noch nicht in echt

ggffs könnte man Fertigmodule umbauen RS232 Pegelwandler auslöten, IR 
Sende Diode und TSOP einbauen, müsste halt nur Atmel basierend sein und 
genügend Codeplatz und ISP Schnitte haben

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Robert (mein Sohn) und ich hatten mal für die DIY-Fernbedienung 
(basierend auf IRMP/IRSND)

  http://www.mikrocontroller.net/articles/DIY_Lernf%C3%A4hige_Fernbedienung_mit_IRMP

testweise ein Kommando-Interface geschrieben, was über die UART lief - 
aber nicht veröffentlicht.

Das Schaltbild könnte man dann vereinfachen auf:

1. TSOP an ATMEGA zum Empfang der Codes über IRMP
2. Transistor + IR-Sendediode an ATmega für IRSND

Eine kleine EXE, die dann das Protokoll, Adresse und Kommando über UART 
an den ATmega schickte, hatten wir damals auch schon programmiert.

Wir hatten das nur noch nicht veröffentlicht, weil wir eigentlich für 
den PC noch eine GUI schreiben wollten, damit man sich selbst eine 
persönliche Fernbedienung unter Windows "zusammenklicken" kann. Dazu war 
aber noch keine Zeit bisher.

Ich kann das heute abend mal raussuchen und hier einstellen. Die 
aktuelle EXE will einfach Protokoll-Nummer, Adresse, Kommando und 
Wiederholungsfaktor als Argument.

Gruß,

Frank

von PimmingerA (Gast)


Lesenswert?

Wenn ich Euch richtig verstanden habe, dann wollt ihr über die 
USB-Schnittstelle des PCs nur die Daten runterschicken auf einen MC und 
dort dann das Timing im MC erzeugen und über einen Pin auf die 
IR-Endstufe ausgeben?

Ich wollte mir die Elektronik ersparen und einen USB-IR-Converter den es 
um 10-20 Euro gibt an den PC anschließen und das Timing im PC-Programm 
machen und runterschicken - funktioniert dies auch oder hat da wer eine 
Ahnung?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

PimmingerA schrieb:
> Wenn ich Euch richtig verstanden habe, dann wollt ihr über die
> USB-Schnittstelle des PCs nur die Daten runterschicken auf einen MC und
> dort dann das Timing im MC erzeugen und über einen Pin auf die
> IR-Endstufe ausgeben?

Jepp.

> Ich wollte mir die Elektronik ersparen und einen USB-IR-Converter den es
> um 10-20 Euro gibt an den PC anschließen und das Timing im PC-Programm
> machen und runterschicken - funktioniert dies auch oder hat da wer eine
> Ahnung?

Hast Du mal einen Link oder Schaltplan von diesem "USB-IR-Converter", 
dass man das mal nachlesen kann? Kann funktionieren, kann auch nicht. Ob 
Du unter Windows hinreichend genaue Timings hinbekommst, kann ich nicht 
sagen.

Für die PC -> µC Lösung braucht man:

1. ATmega88 oder ATmega168
2. Transistor + IR-Diode
3. TSOP
4. Ein paar Kondensatoren + Widerstände

Alles in allem macht das ungefähr einen Preis von ca. 5 Euro - ohne das 
Stückchen Lochrasterplatine ;-)

Achja, man braucht noch einen USB->UART-Wandler, z.B. diesen hier:

  http://shop.myavr.de/Bauelemente%20und%20Controller/myUSBtoUART.htm?sp=article.sp.php&artID=200024

von PimmingerA (Gast)


Lesenswert?

Ich wollte einen Standsender oder Empfänger von HAMA hernehmen ... da 
gibt es vom Hersteller natürlich keine Schaltpläne ;O)
Aber ich werde es nun eh über ein kleines MC-Interface lösen, da mein 
Gefühl mir sagt, dass ich da das Timing besser im Griff habe.
Ich werde einen ATMEGA8 PDIP verwenden - hier ist die USB-Schnittstelle 
mit ein paar BauteilenWorkAround schon dabei - dann brauche ich den 
USB/UART Umsetzer nicht oder?
Dann werde ich 2 Pins brauchen für Sender und Empfänger - so wie von Dir 
beschrieben.
Den Source Deines Exe-files wäre toll - bzw. die Tabellen der ganzen 
Codec-Daten ;O)

von jar (Gast)


Lesenswert?

IRMP braucht für alle Protokolle ca 4k IRSND dito wenn ich das richtig 
überschlagen habe

auf Platine bauen hab ich keinen Lust, deswegen denke ich an Pollin 
RS232 BAS Wandler 10 €

anstelle der RS232 Buchse und Wandlerchip USB mit Schutzdioden und R

anstelle das BAS Ausgang TSOP Trasi und IR Sendediode

nur wird das Modul nur mit mega8 geliefert, kein Platz mehr für den 
V-USB, evt. Chip größer wählen, oder AVR Net I/O 20 € dann könnte man 
die Codes auch über Router schicken ohne PC oder eben USB Stecker und 
Beschaltung nachfrickeln, da ist ein mega32 drauf Platz genug

was benötigt v-usb an SW Platz ?

von narkus (Gast)


Lesenswert?

Hey Frank!

So, war länger nicht dabei. Also, ich habe jetzt den aktuellen Code 
getestet und das mitm RC5 läuft jetzt mitm 150er Wert so wie es soll! 
Super!! :)

So ein busy wäre sehr sinnvoll. Sonst kann ich keinen lang anhaltenden 
Tastendruck erkennen, ohne dass ich parallel einen Timer des letzten 
erkannten Empfangs mitlaufen lasse. Gerne auch als Flag.

Solange IRMP was tut, sollte irmp_get_data() weiterhin TRUE zurückgeben, 
so kann ich dann gesichert meine variablen zurücksetzen, wenn 
tatsächlich kein Empfang mehr stattfindet, sprich keine Taste egal ob 
kurz oder lang gedrückt wurde. Mein Code könnte dann so aussehen:
1
  if (irmp_get_data (&irmp_data))
2
  {    
3
    if (!irmp_data.busy && (irmp_data.protocol == IRMP_RC5_PROTOCOL) && (irmp_data.address == 19))      // << Hier mitprüfen, ob busy
4
    {  if (!(irmp_data.flags & IRMP_FLAG_REPETITION))
5
      {  rc5_pressed = 1;
6
        rc5_do = 1;
7
      }
8
      else
9
      {  if (rc5_pressed < 5000) rc5_pressed++;       // Wiederholverzögerung
10
        else rc5_do = 1;
11
      }
12
      
13
      irmp_data.flags = 0;                    // reset flags!
14
    }
15
  }
16
  else
17
  {  rc5_pressed = 0;
18
    Taste = 0;
19
  }

von jar (Gast)


Lesenswert?

Frank M. schrieb:
> Ich habe nun ins SVN eine neuere Version von IRMP eingecheckt

ich hab auch mal wieder geschaut, komme am IRMP grad nicht weiter, macht 
aber nix

doofe Frage,
wäre es nicht möglich den proto_str in die IRMP.C einzubinden, dann muss 
man im quelltext nie ändern

eine weitere Funktion im IRMP.C
char *get_irmp_prot_str(protokoll)

könnte das dann immer liefern

warum diese Version ? c erlaubt doch
sei();

???

#asm("sei");

was bringt der ASM als Vorteil ?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

jar schrieb:

> wäre es nicht möglich den proto_str in die IRMP.C einzubinden, dann muss
> man im quelltext nie ändern

Nein, ganz im Gegenteil: Da er nur im Codevision-Teil des 
IRMP-Demo(!)programms main.c steht, fliegt er demnächst komplett raus. 
Der Protokoll-Name als String ist nicht Bestandteil der IRMP-LIB.

Vergleiche macht man mittels:
1
  if (irmp_data.protocol == IRMP_NEC_PROTOCOL)
2
  {
3
     ...
4
  }

und nicht mittels strcmp() auf einen Protokollnamen! Aber das habe ich 
Dir vor Monaten schon mal gesteckt ;-)

Frage: Benutzt Du den Codevision-Compiler?

> eine weitere Funktion im IRMP.C
> char *get_irmp_prot_str(protokoll)

Nein, kostet nur jede Menge Flash, die unsinnig verbraten werden. Die 
Protokoll-Strings sind nur sinnvoll für die Ausgabe auf einem LCD. Da 
aber die LCD-Routinen auch nicht Bestandteil der IRMP-Lib sind, sehe ich 
auch nicht ein, die Strings zum Bestandteil der Lib zu machen.

> warum diese Version ? c erlaubt doch
> sei();

Ja, klar, wird auch so genutzt, siehe AVR-GCC-Teil von main.c.

> #asm("sei");

Du bist im Codevision-Teil von main.c. Der stammt nicht von mir, sondern 
von Klaus Leidinger, der damals mal das main.c auf Codevision-C portiert 
hat. Offenbar kennt der Codevision-Compiler kein sei().

> was bringt der ASM als Vorteil ?

Dass er auch für Codevision funktioniert.

Aber warum machst Du da dauernd im Codevision-Teil rum? Die 
Codevision-Unterstützung werfe ich sowieso demnächst raus, da ich keinen 
Codevision-Compiler habe.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

narkus schrieb:

> So, war länger nicht dabei. Also, ich habe jetzt den aktuellen Code
> getestet und das mitm RC5 läuft jetzt mitm 150er Wert so wie es soll!
> Super!! :)

Freut mich.

> So ein busy wäre sehr sinnvoll. Sonst kann ich keinen lang anhaltenden
> Tastendruck erkennen, ohne dass ich parallel einen Timer des letzten
> erkannten Empfangs mitlaufen lasse. Gerne auch als Flag.

Was soll IRMP zwischen 2 Frames zurückliefern? Jede FB macht auch bei 
lang anhaltender Taste Pausen zwischen den Frames.

Stell Dir folgende Situation vor:

A1. FB sendet ersten Frame
A2. IRMP liest ersten Frame ein
A3. Applikation holt ersten Frame ab
A4. FB macht eine Pause von ca. 40 msec
A5. FB sendet zweiten Frame
A6. IRMP liest ersten Frame ein
A7. Applikation holt zweiten Frame ab, Repetition-Flag ist gesetzt.

Wenn ich nun ein busy-Flag einbaue, passiert folgendes:

B1. FB sendet ersten Frame
B2. IRMP setzt Busy-Flag
B3. IRMP liest ersten Frame ein
B4. IRMP setzt Busy-Flag zurück
B5. Applikation holt ersten Frame ab
B6. FB macht eine Pause von ca. 40 msec
B7. FB sendet zweiten Frame
B8. IRMP setzt Busy-Flag
B9. IRMP liest ersten Frame ein
B10. IRMP setzt Busy-Flag zurück
B11. Applikation holt zweiten Frame ab, Repetition-Flag ist gesetzt.

Problem ist die Zeit zwischen B5 und B7, da ist das Busy-Flag nicht 
gesetzt! Hilft Dir das weiter?

> Solange IRMP was tut, sollte irmp_get_data() weiterhin TRUE zurückgeben,

Sorry, das geht nicht, denn damit würde irmp_get_data() 
aufruf-inkompatibel zu bisherigen Versionen werden. Bisherige Programme, 
die IRMP verwenden, müssten alle in ihrer Logik umgeschrieben werden.

Ich kann Dir höchstens eine Funktion irmp_is_busy() anbieten, die TRUE 
oder FALSE zurückliefert. Aber erst müssten wir klären, in welchem State 
diese Funktion was zurückliefert.

Gruß,

Frank

von jar (Gast)


Lesenswert?

Frank M. schrieb:
> und nicht mittels strcmp() auf einen Protokollnamen! Aber das habe ich
> Dir vor Monaten schon mal gesteckt ;-)

das mache ich doch nicht (mehr) aber als IR Tester gebe ich natürlich 
den Protokollnamen aufs LCDaus !

> Frage: Benutzt Du den Codevision-Compiler?
nö !

>> eine weitere Funktion im IRMP.C
>> char *get_irmp_prot_str(protokoll)
> Nein, kostet nur jede Menge Flash, die unsinnig verbraten werden.

OK muss ! ich akzeptieren

> Protokoll-Strings sind nur sinnvoll für die Ausgabe auf einem LCD. Da
> aber die LCD-Routinen auch nicht Bestandteil der IRMP-Lib sind, sehe ich
> auch nicht ein, die Strings zum Bestandteil der Lib zu machen.

na ja, kann man auch anders sehen, als IR Tester ist für mich der 
Protokollname Bestandteil der IRMP, könnte man mit #if define LCD_H 
einbinden

> Du bist im Codevision-Teil von main.c. Der stammt nicht von mir, sondern
> von Klaus Leidinger, der damals mal das main.c auf Codevision-C portiert

da bin ich grad wieder irrtümlich reingerutscht zwischen 2 Tätigkeiten, 
ich finde es gut wenn die coderversion endlich rausfliegt, dann 
entfallen derlei Irrtümer

danke jar

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Neue Version IRMP und IRSND im SVN:

1. Unterstützung von ATtiny85 (bisher nur ATmegas)
2. Codevision-Unterstützung gelöscht
3. Array von IRMP-Protokollnamen zur Verfügung gestellt
4. Kleinere Bugfixes

@jar:

Um auf die Protokollnamen zugreifen zu können, muss
1
/*---------------------------------------------------------------------------------------------------------------------------------------------------
2
 * Set IRMP_PROTOCOL_NAMES to 1 if want to access protocol names (for logging etc), costs ~300 bytes RAM!
3
 *---------------------------------------------------------------------------------------------------------------------------------------------------
4
 */
5
#define IRMP_PROTOCOL_NAMES                     0       // 1: access protocol names, 0: do not (default),

auf 1 gesetzt werden. Dies verbraucht im Moment noch ca. 300 Bytes RAM, 
da die Strings noch nicht als PROGMEM gespeichert werden.

Man kann dann mit irmp_protocol_names[irmp_data.protocol] auf den 
Protokollnamen zugreifen. Die Protokollnamen wurden so gekürzt, dass sie 
die Länge von 8 nicht überschreiten.

Gruß,

Frank

von Sebastian W. (dl3yc)


Lesenswert?

Frank M. schrieb:
> Neue Version IRMP und IRSND im SVN:
>
> 1. Unterstützung von ATtiny85 (bisher nur ATmegas)

Hallo Frank, hast du auch ein funktionierendes Projekt für einen 
ATtiny85?
Ich habe momentan mit dem aktuellen Projekt aus dem SVN und einen Tiny45 
nur den Pin von PB6 auf PB4 geändert und eine LED an PB0, die an gehen 
soll, wenn etwas erkannt wird. Am Oszi kann ich sehen, dass der TSOP 
funktioniert, aber die LED geht nie an :(
Fuses habe ich auf interne 8MHz (Divider/8 aus).

meine main:
1
int
2
main (void)
3
{
4
    IRMP_DATA irmp_data;
5
6
    irmp_init();                                                            // initialize irmp
7
    DDRB |= (1<<PB0);
8
  timer1_init();                                                          // initialize timer 1
9
    sei ();                                                                 // enable interrupts
10
11
    for (;;)
12
    {
13
        if (irmp_get_data (&irmp_data))
14
        {
15
      PORTB |= (1<<PB0);
16
            // ir signal decoded, do something here...
17
            // irmp_data.protocol is the protocol, see irmp.h
18
            // irmp_data.address is the address/manufacturer code of ir sender
19
            // irmp_data.command is the command code
20
            // irmp_protocol_names[irmp_data.protocol] is the protocol name (if enabled, see irmpconfig.h)
21
        }
22
    }
23
}

Hast du eine Idee an was es liegen kann? Habe alle Protokolle und mit 3 
verschd. FB ausprobiert.

Danke im Vorraus!

73 DL3YC

von Sebastian W. (dl3yc)


Lesenswert?

Fehler gefunden: es fehlt die ISR in der main!

Einfach
ISR(TIMER1_COMPA_vect)
{
  irmp_ISR();
}
hinzufügen und es funktioniert :)

73 DL3YC

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Sebastian,

Sebastian Weiß schrieb:
> Fehler gefunden: es fehlt die ISR in der main!

Sorry, die ISR hatte ich beim Rauswerfen der Codevision-Unterstützung 
tatsächlich "wegoptimiert" - sprich versehentlich gelöscht. Ist nun 
wieder drin.

Trotzdem wundert es mich, dass es bei Dir nun auf dem ATtiny 
funktioniert, denn meines Erachtens war da noch ein 
Copy-and-Paste-Fehler meinerseits beim Setzen von TCCR1. Man benötigt 
hier einen Prescaler von 4 und nicht von 2.

Kannst Du mal Deine timer1_init()-Funktion zeigen? Ich habe jetzt 
folgende im SVN eingecheckt:
1
void
2
timer1_init (void)
3
{
4
#if defined (__AVR_ATtiny85__)                                              // ATtiny85:
5
    OCR1A   =  (F_CPU / F_INTERRUPTS / 4) - 1;                              // compare value: 1/15000 of CPU frequency, presc = 4
6
    TCCR1   = (1 << CTC1) | (1 << CS11) | (1 << CS10);                      // switch CTC Mode on, set prescaler to 4
7
#else                                                                       // ATmegaXX:
8
    OCR1A   =  (F_CPU / F_INTERRUPTS) - 1;                                  // compare value: 1/15000 of CPU frequency
9
    TCCR1B  = (1 << WGM12) | (1 << CS10);                                   // switch CTC Mode on, set prescaler to 1
10
#endif
11
12
#ifdef TIMSK1
13
    TIMSK1  = 1 << OCIE1A;                                                  // OCIE1A: Interrupt by timer compare
14
#else
15
    TIMSK   = 1 << OCIE1A;                                                  // OCIE1A: Interrupt by timer compare
16
#endif
17
}

Wichtig sind hier die beiden Zeilen für den ATTiny85: Neben dem Bit CS11 
wird auch noch CS10 im TCCR1-Register gesetzt, um den Prescaler auf 4 zu 
bekommen. Eigentlich müsstest Du das auch so korrigiert haben, um das 
zum Laufen zu bekommen. Kannst Du das so bestätigen?

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Neue Versionen von IRMP und IRSND im SVN:

IRMP:

1. Unterstützung für ATtiny84 (zusätzlich zu ATTiny85) hinzugefügt.
2. Fehlende ISR in main.c wieder eingefügt
3. Div. Fehler in timer1_init korrigiert (für ATmega & ATTtiny)

IRSND:

1. Unterstützung für ATTiny84 und ATTiny85 hinzugefügt
2. Unterstützung der IR-Protokolle NEC16 und NEC24

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Dirk W. schrieb:
> Hmm, darf ich nach 4 Wochen mal vorsichtig fragen wie denn der Status zu
> meiner Anfrage bzgl. Merlin Tastatur ist?

Ich habe am Wochenende einige Tests mit der Merlin gemacht. Wie ich über 
IR_LOGGING per IRMP fesstellen konnte, gibt es einige Tasten, die exakt 
den gleichen IR-Frame senden. Das war bei mir zum Beispiel bei den 
Tasten "t" und "n" der Fall. Entweder habe ich da ein defektes Exemplar 
erwischt oder es handelt sich um einen Serienfehler. Letzteres würde 
erklären, warum Pollin diese Tastaturen zum Schleuderpreis anbietet.

Ich kann da also nichts weiter machen. Da das Merlin-Protokoll vom 
Startbit-Timing ähnlich zu anderen IR-Protokollen ist und daher immer 
mal bei der Erkennung "dazwischenfunkt", wenn es aktiviert ist, habe ich 
mich entschlossen, die Unterstützung für die Merlin-Tastatur komplett 
aus dem IRMP herauszuwerfen. Vom Timing her arbeitet die Tastatur auch 
nicht gerade sehr exakt, so dass ab und zu auch verschiedene Codes für 
ein- und dieselbe Taste decodiert werden.

Fazit: Merlin fliegt raus.

Sorry,

Frank

von Dirk W. (glotzi)


Lesenswert?

Frank M. schrieb:
> Ich habe am Wochenende einige Tests mit der Merlin gemacht.
Danke fürs Feedback, hatte schon gar nicht mehr damit gerechnet.

> ... Entweder habe ich da ein defektes Exemplar
> erwischt oder es handelt sich um einen Serienfehler. Letzteres würde
> erklären, warum Pollin diese Tastaturen zum Schleuderpreis anbietet.

Hmm, seltsam. Ich und andere User auch, können die Merlin via lirc im 
Rawmode ohne Probleme benutzen. Ich werde nochmal nachfragen.

> Fazit: Merlin fliegt raus.
Sehr schade.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Dirk W. schrieb:
> Hmm, seltsam. Ich und andere User auch, können die Merlin via lirc im
> Rawmode ohne Probleme benutzen. Ich werde nochmal nachfragen.

Vielleicht ist wirklich nur meine Tastatur defekt. Ich meine, ich habe 
irgendwo im Keller noch ein zweites Exemplar davon vergraben. Ich werde 
das heute abend mal rauswühlen und damit nochmal testen.

> Sehr schade.

Okay, wenn es mit der Tastatur im Keller doch geht, dann baue ich es 
wieder ein. Hast mich überredet, denn eigentlich ist das wirklich eine 
niedliche Tastatur ;-)

von Dirk W. (glotzi)


Lesenswert?

Frank M. schrieb:
> Ich habe am Wochenende einige Tests mit der Merlin gemacht. Wie ich über
> IR_LOGGING per IRMP fesstellen konnte, gibt es einige Tasten, die exakt
> den gleichen IR-Frame senden. Das war bei mir zum Beispiel bei den
> Tasten "t" und "n" der Fall. Entweder habe ich da ein defektes Exemplar
> erwischt oder es handelt sich um einen Serienfehler. Letzteres würde
> erklären, warum Pollin diese Tastaturen zum Schleuderpreis anbietet.

Ich muss nochmal nachfragen: wurde keine Taste erkannt oder nur manche 
nicht? Bei mir ist es so, dass noch nicht mal das Merlin Protokoll 
erkannt wurde.

von Sebastian W. (dl3yc)


Lesenswert?

Hallo Frank,

Frank M. schrieb:
> Trotzdem wundert es mich, dass es bei Dir nun auf dem ATtiny
> funktioniert, denn meines Erachtens war da noch ein
> Copy-and-Paste-Fehler meinerseits beim Setzen von TCCR1. Man benötigt
> hier einen Prescaler von 4 und nicht von 2.
> [...]
> Wichtig sind hier die beiden Zeilen für den ATTiny85: Neben dem Bit CS11
> wird auch noch CS10 im TCCR1-Register gesetzt, um den Prescaler auf 4 zu
> bekommen. Eigentlich müsstest Du das auch so korrigiert haben, um das
> zum Laufen zu bekommen. Kannst Du das so bestätigen?
Nein, ich habe sie unverändert übernommen, auch die F_INTERRUPTS sind 
noch bei 15k.

Der Grund warum hier eine Veränderung benötigt wird ist doch, dass beim 
Tiny Timer1 ein 8bit-Timer statt eines 16bit-Timers wie bei den Megas 
ist.
Mein Wert mit Prescaler 2 ist mit OCR1A   =  (F_CPU / (2 * F_INTERRUPTS) 
/ 2) - 1 rund 132 und passt somit in die 8bit Variable - warum sollte 
das anders sein?

Gruß Sebastian

Nachtrag:

meine Timer1_init():
1
void
2
timer1_init (void)
3
{
4
#if defined (__AVR_ATtiny45__)                                      // ATtiny85:
5
    OCR1A   =  (F_CPU / (2 * F_INTERRUPTS) / 2) - 1;                // compare value: 1/28800 of CPU frequency, presc = 2
6
    TCCR1   = (1 << CTC1) | (1 << CS11);                            // switch CTC Mode on, set prescaler to 2
7
#else                                                               // ATmegaXX:
8
    OCR1A   =  (F_CPU / (2 * F_INTERRUPTS)) - 1;                    // compare value: 1/28800 of CPU frequency
9
    TCCR1B  = (1 << WGM12) | (1 << CS10);                           // switch CTC Mode on, set prescaler to 1
10
#endif
11
12
#ifdef TIMSK1
13
    TIMSK1  = 1 << OCIE1A;                                          // OCIE1A: Interrupt by timer compare
14
#else
15
    TIMSK   = 1 << OCIE1A;                                          // OCIE1A: Interrupt by timer compare
16
#endif
17
}

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Sebastian,

Sebastian Weiß schrieb:

> Der Grund warum hier eine Veränderung benötigt wird ist doch, dass beim
> Tiny Timer1 ein 8bit-Timer statt eines 16bit-Timers wie bei den Megas
> ist.

Richtig.

> Mein Wert mit Prescaler 2 ist mit OCR1A   =  (F_CPU / (2 * F_INTERRUPTS)
> / 2) - 1 rund 132 und passt somit in die 8bit Variable - warum sollte
> das anders sein?

Ja. Aber wenn Du Dir die Zuweisung einmal genauer anschaust, steckt der 
Faktor 2 zweimal drin. Also hat man faktisch einen Divisor mit dem Wert 
4. Die obige Zuweisung ist also identisch mit:
1
 OCR1A   =  (F_CPU / F_INTERRUPTS / 4) - 1;

Und damit müsste der Prescaler auch auf 4 gestellt werden, also:
1
 TCCR1   = (1 << CTC1) | (1 << CS11) | (1 << CS10);

statt
1
 TCCR1   = (1 << CTC1) | (1 << CS11);

damit auch der Prescaler von 4 rauskommt.

Oder habe ich da jetzt einen Denkfehler?

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Dirk W. schrieb:
> Ich muss nochmal nachfragen: wurde keine Taste erkannt oder nur manche
> nicht?

Es werden bei mir eigentlich alle Tasten erkannt, auf jeden Fall immer 
das Merlin-Protokoll.

Aber was auffiel:

1. Bei längerem Herunterdrücken einer Taste kippte ab und zu ein bit,
   d.h. man erhielt dann bei den Wiederholungen einen anderen Code.

2. Manche Tasten sendeten denselben IR-Frame. Das führe ich mal auf
   einen Defekt meiner Tastatur zurück, z.B. Kurzschluss in der
   Tastatur-Matrix oder ähnliches.

> Bei mir ist es so, dass noch nicht mal das Merlin Protokoll erkannt wurde.

Doch, bei mir schon. Allerdings habe ich alle anderen exotischen 
Protokolle abgeschaltet, also nur die Standard-Protokolle von SIRCS bis 
DENON eingeschaltet und zusätzlich nur noch Merlin. Du kannst das ja 
auch mal mit dieser Konstruktion testen. Ich kann mir durchaus 
vorstellen, dass die anderen Exoten wie Ruwido und andere mit ähnlichem 
Startbit-Timing stören könnten.

von Dirk W. (glotzi)


Lesenswert?

Frank M. schrieb:
> Dirk W. schrieb:
>> Ich muss nochmal nachfragen: wurde keine Taste erkannt oder nur manche
>> nicht?
>
> Es werden bei mir eigentlich alle Tasten erkannt, auf jeden Fall immer
> das Merlin-Protokoll.

Ok, danke für die Info.

Dann habe ich mit meinem V-USB Receiver wohl noch ein ganz anderes 
Problem. Bei mir funktionieren auch keine Frequenzen > 10000, egal 
welche Remote ich benutze. Ich frage mich jetzt doch, ob das ein 
prinzipielles Problem des Portisch-Receivers ist.

von Sebastian W. (dl3yc)


Lesenswert?

Hallo Frank,

was du beschreibst ist logisch, aber trotzdem falsch.
Ich habe die neueste SVN-Version gezogen und probiert - es funktioniert 
nicht.

Meine main():
1
int
2
main (void)
3
{
4
    IRMP_DATA irmp_data;
5
6
    irmp_init();                                                            // initialize irmp
7
  DDRB |= (1<<PB0);                            // initialize LED
8
    timer1_init();                                                          // initialize timer 1
9
    sei ();                                                                 // enable interrupts
10
11
    for (;;)
12
    {
13
        if (irmp_get_data (&irmp_data))
14
        {
15
      // toggle LED
16
      if (PORTB & (1<<PB0))
17
      PORTB &= ~(1<<PB0);
18
      else
19
      PORTB |= (1<<PB0);
20
            // ir signal decoded, do something here...
21
            // irmp_data.protocol is the protocol, see irmp.h
22
            // irmp_data.address is the address/manufacturer code of ir sender
23
            // irmp_data.command is the command code
24
            // irmp_protocol_names[irmp_data.protocol] is the protocol name (if enabled, see irmpconfig.h)
25
        }
26
    }
27
}

Ändere ich aber den Prescaler wieder zurück zu 2, also lösche CS10, dann 
funktioniert alles soweit.
Kannst du dir das erklären?

Nun möchte ich dazu auch IRSND benutzen, aber das hat dann wohl 
Probleme, weil es auf der falschen Zeitbasis aufsetzt?

Nebenbei:
Ich habe NEC, SAMSUNG und RC5 aktiviert, also ich teste mit 3 verschd. 
FB.
NEC und RC5 funktioniert(meine LED togglet). Aber SAMSUNG wird nicht 
erkannt. Auf einem 2. Board mit einem ATMega8 und Anzeige von Protokoll, 
Addresse und Befehl per UART funktioniert die Erkennung dort.

Mit F_INTERRUPTS = 20000 geht dann auch RC5 nicht und mit F_INTERRUPTS = 
10000 geht SAMSUNG, aber NEC nicht mehr.

Ich probiere es weiter.

Gruß DL3YC

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Sebastian,

Sebastian Weiß schrieb:
> Ändere ich aber den Prescaler wieder zurück zu 2, also lösche CS10, dann
> funktioniert alles soweit.
> Kannst du dir das erklären?

Nein, das kann ich mir momentan überhaupt nicht erklären. Da mir aber 
die ATTtiny85 ausgegangen sind, habe ich mir gestern neue bestellt, um 
das selbst zu testen. Es muss ja eine Erklärung dafür geben. 
Wahrscheinlich habe ich nur an der falschen Stelle im Datenblatt 
geschaut.

> Nun möchte ich dazu auch IRSND benutzen, aber das hat dann wohl
> Probleme, weil es auf der falschen Zeitbasis aufsetzt?

Nein, das sollte gehen. Du willst IRMP & IRSND verwenden? Dann muss die 
ISR dafür so aussehen (s.a. IRMP-Artikel):
1
ISR(TIMER1_COMPA_vect)
2
{
3
  if (! irsnd_ISR())          // call irsnd ISR
4
  {                           // if not busy...
5
      irmp_ISR();             // call irmp ISR
6
  }
7
  // call other timer interrupt routines...
8
}

Wenn dann noch die Konstanten F_INTERRUPTS in irmpconfig.h und 
irsndconfig.h denselben Wert haben, ist alles perfekt.

> Ich habe NEC, SAMSUNG und RC5 aktiviert, also ich teste mit 3 verschd.
> FB.
> NEC und RC5 funktioniert(meine LED togglet). Aber SAMSUNG wird nicht
> erkannt.

Hast Du mal SAMSUNG32 als alternatives Protokoll ausgewählt? Sonst 
schalte soviele Protokolle an, wie mit Deinem ATmega8 möglich sind. Wenn 
es dann auch nicht geht, schalte IRMP_LOGGING an und schicke mir ein 
paar Scans.

> Mit F_INTERRUPTS = 20000 geht dann auch RC5 nicht und mit F_INTERRUPTS =
> 10000 geht SAMSUNG, aber NEC nicht mehr.

In der Regel sind F_INTERRUPTS = 15000 die richtige Wahl.

Gruß,

Frank

von jar (Gast)


Lesenswert?

Frank M. schrieb:
> Sonst
> schalte soviele Protokolle an, wie mit Deinem ATmega8 möglich sind.

PS ich hatte mal überschlagen, alle <= 15000 F_Interrupt Protokolle 
brauchen ca 4k und für IRSND auch, reicht der ATmega8 oder braucht man 
schon den 16 ?

hat einer einen Link für einen Adapter von ISP 6 auf ISP 10, meine Kabel 
sind alle auf 10pol aber der letzte gekaufte hat 6pol mag keine neuen 
Kabel bauen lieber einen Adapter Stecker ISP6 auf Kupplung ISP10

von Sebastian W. (dl3yc)


Lesenswert?

Nocheinmal Rückmeldung von mir:
Bei mir funktioniert jetzt alles wie gewollt (IRMP + IRSND) auf dem 
ATtiny45. Einzige Änderung der Prescaler s.o. und meine IR-Sendediode 
habe ich gegen eine 950nm-IR-LED getauscht.

Vielen Dank für das tolle Projekt und den guten Support!

73! DL3YC

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Sebastian Weiß schrieb:
> Bei mir funktioniert jetzt alles wie gewollt (IRMP + IRSND) auf dem
> ATtiny45. Einzige Änderung der Prescaler s.o. und meine IR-Sendediode
> habe ich gegen eine 950nm-IR-LED getauscht.

Freut mich, dass es funktioniert. Aber ich muss da nochmal nachhaken:

Mit welcher Frequenz läuft Dein ATtiny? Was ist bei Dir als F_CPU im 
Projekt eingetragen?

Gruß,

Frank

von Sebastian W. (dl3yc)


Lesenswert?

Frank M. schrieb:
> Mit welcher Frequenz läuft Dein ATtiny? Was ist bei Dir als F_CPU im
> Projekt eingetragen?

Beides 8 MHz. Ich kann es mir auch noch nicht erklären. Deswegen habe 
ich gerade einen Test gemacht mit:

Per Fuse den Takt ausgegeben und gemessen - 8,74MHz.
In der Timer-ISR Pin togglen lassen und gemessen - 8,275kHz.
Pintogglen halbiert die Frequenz also sind es ~16,5kHz
Reale CPU-Frequenz / Timerwert(OCR1A) / Prescaler müsste 16,5kHz 
ergeben.
8740000/133/2=32857 -> da stimmt was nicht!
Somit gibt es trotz einem Prescaler von 2 einen 15kHz Interrupt.

Gruß Sebastian

von gera (Gast)


Lesenswert?

Hallo,

Gibt es auch ein Code für den C18 Compiler.
Den CCS Code habe ich gefunden, habe leider keine
Ahnung wie man von CSS nach C18 portiert.

Gruß

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Sebastian Weiß schrieb:
> Beides 8 MHz. Ich kann es mir auch noch nicht erklären.

Ich habe den Fehler gefunden. Fälschlicherweise habe ich das 
OCR1A-Register auch beim ATtiny85 genommen, obwohl es hier das 
OCR1C-Register sein muss. Bei Dir hat es nur deshalb funktioniert, weil 
der errechnete Wert mit dem Prescaler 2 statt 4 ungefähr einen Wert von 
256 (in Wirklichkeit 266) ergibt. Da das OCR1C-Register mit 0 vorbelegt 
ist, hat der Timer immer bis 256 durchgezählt. Dadurch hattest Du dann 
mit einer Abweichung von ca. 5 Prozent die "richtige" Abtastrate. Da 
IRMP mit Toleranzen von bis zu 40% klarkommt, funktionierte das dann bei 
Dir.

Hier der korrekte Code von timer1_init() für ATtiny85:
1
#if defined (__AVR_ATtiny45__) || defined (__AVR_ATtiny85__)                // ATtiny45 / ATtiny85:
2
    OCR1C   =  (F_CPU / F_INTERRUPTS / 4) - 1;                              // compare value: 1/15000 of CPU frequency, presc = 4
3
    TCCR1   = (1 << CTC1) | (1 << CS11) | (1 << CS10);                      // switch CTC Mode on, set prescaler to 4
4
    ....

Und jetzt passt das auch wieder zusammen mit dem Prescaler von 4.

Den Code im SVN habe ich korrigiert.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

gera schrieb:

> Gibt es auch ein Code für den C18 Compiler.

Bisher nicht. Der hardware-abhängige Teil beschränkt sich auf die Angabe 
des input-Makros (s. irmpconfig.h) und der Definition des Timers.

Bekommst Du das hin? Wäre nett, wennn Du mir dann die Änderungen für den 
PIC-C18-Compiler zur Verfügung stellen könntest.

Gruß,

Frank

von gera (Gast)


Lesenswert?

Hallo,

Habe mal versucht den Code zu übersetzen.
Zwei Probleme:
1. Wie übersetze ich diese Zeile (input gibt es bei C18 nicht)
    irmp_input = input(IRMP_PIN);

  Mein Versuch ?
    irmp_input = IRMP_PIN;

2. Die Input Pin
   #define IRMP_PIN   PIN_B4  // use PB4 as IR input on PIC

 Mein Versuch:

   #define IRMP_PIN   LATBbits.LATB4  // use PB4 as IR input on PIC

 oder evtl das hier ?

   #define IRMP_PIN   PORTBbits.RB4   // use PB4 as IR input on PIC

Was ist die richtige Übersetzung ?

So läuft schon mal bis jetzt der Compiler durch.
Zum Testen bin ich noch nicht gekommen.

Den Timer0 habe ich auf 10000 Hz gestellt und eine INT Routine 
eingebaut.
Passt das so ?
Benutze einen 18F2550 mit 20MHz Quarz.

Gruß

von gera (Gast)


Lesenswert?

Hallo,

Compilieren kann ich es jetzt ohne Probleme.
Leider wird nichts erkannt.

Den Timer0 hab ich auf 10000Hz eingestellt, Timer0 Int funktioniert 
soweit.
Muss ich irgendwo noch was eintragen ? CPU-Frequenz, ... ?
Oder kann man es einfach so benutzen.
Benutze Version 1.90
HW: 18F2550, Quarz 20Mhz, Takt 40Mhz

Gruß
gera

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

gera schrieb:

> Den Timer0 habe ich auf 10000 Hz gestellt und eine INT Routine
> eingebaut.
> Passt das so ?

Hast Du auch F_INTERRUPTS in irmpconfig.h angepasst? Dort ist in der 
SVN-Version standardmäßig 15000 als Wert eingetragen.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Im IRMP-Artikel

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

steht nun die Version 2.0.1 sowohl für IRMP als auch für IRSND zum 
Download bereit. Diese Version entspricht der letzten SVN-Version. Somit 
sind nun die Download-Dateien wieder zum SVN synchron.

Hier die Änderungen gegenüber der letzten Download-Version vom Januar:

IRMP:

    - Neues Protokoll: KATHREIN
    - Neues Protokoll: RUWIDO
    - Neues Protokoll: THOMSON
    - Neues Protokoll: IR60
    - Neues Protokoll: LEGO
    - Neues Protokoll: NEC16
    - Neues Protokoll: NEC42
    - Neues Protokoll: NETBOX (Prototyp)
    - Portierung auf ATtiny84 und ATtiny85
    - Verbesserung von Tastenwiederholungen bei RC5
    - Verbessertes Decodieren von Bi-Phase-Protokollen
    - Korrekturen am RECS80-Decoder
    - Korrekturen beim Erkennen von zusätzlichen Bits im SIRCS-Protocol

IRSND:

    - Neues Protokoll: THOMSON
    - Neues Protokoll: LEGO
    - Neues Protokoll: NEC16
    - Neues Protokoll: NEC42
    - Portierung auf ATtiny84 und ATtiny85
    - Korrektur von Pausenlängen
    - Korrekturen von irsnd_stop()
    - Korrektur des SIEMENS-Timings
    - Umstellung auf 36kHz Modulationsfrequenz für DENON-Protokoll
    - Korrektur Behandlung zusätzlicher Bits im SIRCS Protokoll

Viel Spaß,

Frank

von gera (Gast)


Lesenswert?

Hallo,

Nach langer Suche habe den Fehler gefunden.
War ein blöder Schreibfehler in einer define-Anweisung.

Funktioniert soweit mit Microchip C18 !

Vielen Dank für die Library !

Ich hab mir mal die 2.01 runtergeladen und werde die Änderungen in diese 
Version einarbeiten.
Wo soll ich es dann schicken ?

Gruß

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

gera schrieb:
> Nach langer Suche habe den Fehler gefunden.

Prima!

> Funktioniert soweit mit Microchip C18 !

Ich werde Deine Änderungen in den IRMP-Source übernehmen, vielen Dank.

> Wo soll ich es dann schicken ?

Da mich Deine Mail schon erreicht hat, hast Du meine Adresse offenbar 
gefunden. Ich antworte Dir dort zu Deinem RC6-Problem.

von Tom S. (year2525)


Lesenswert?

vielen Dank erstmal für dieses Projekt, eine super Arbeit. Es hat auf 
Anhieb funktioniert, eine Creative Fernbed. RM-1500 geht einwandfrei.

2 Fragen habe ich jedoch:

1. Ich habe eine JVC RM-SV511UE remote, von der ich gern das Steuerkreuz 
nutzen möchte. Nur geht die right-Taste irgendwie überhaupt nicht, die 
up/down/left/enter Tasten gehen einwandfrei:

down
irmp_data.protocol: 20
irmp_data.address : 15
irmp_data.command : 3358
irmp_data.flags   : 0

up
irmp_data.protocol: 20
irmp_data.address : 15
irmp_data.command : 3342
irmp_data.flags   : 0

left
irmp_data.protocol: 20
irmp_data.address : 15
irmp_data.command : 3374
irmp_data.flags   : 0

enter
irmp_data.protocol: 20
irmp_data.address : 15
irmp_data.command : 3406
irmp_data.flags   : 0

right
nichts

Die Taste selbst sendet def. ein IR-Signal. Ist das ein bekannter bug? 
Ansonsten kann ich gerne das Logging aktivieren falls das weiterhilft.

2. Ich möchte das ganze in ein RTOS integrieren und dazu den IRMP 
interrupt erst einschalten wenn was am pin passiert, z.B. über einen pin 
change interrupt, und nach ein paar Sek. Pause den IRMP interrupt wieder 
ausschalten. Ist das prinzipiell mit dem vorliegenden code machbar, oder 
wird es Probleme geben weil z.B. counter hochgezählt werden müssen, die 
state machine damit nicht klarkommt etc.

Vielen Dank für das tolle Projekt.

Gruß

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Tom S. schrieb:
> vielen Dank erstmal für dieses Projekt, eine super Arbeit.

Danke fürs Danke :-)
> Die Taste selbst sendet def. ein IR-Signal. Ist das ein bekannter bug?
> Ansonsten kann ich gerne das Logging aktivieren falls das weiterhilft.

Ja, da bräuchte ich Logging-Daten. Am besten von allen 4 Richtungen des 
Steuerkreuzes.

> 2. Ich möchte das ganze in ein RTOS integrieren und dazu den IRMP
> interrupt erst einschalten wenn was am pin passiert, z.B. über einen pin
> change interrupt, und nach ein paar Sek. Pause den IRMP interrupt wieder
> ausschalten. Ist das prinzipiell mit dem vorliegenden code machbar, oder
> wird es Probleme geben weil z.B. counter hochgezählt werden müssen, die
> state machine damit nicht klarkommt etc.

Das müsste machbar sein. Schalte den Timer-Interrupt einfach beim ersten 
Toggle ein und nach einer bestimmten Zeit wieder ab.

Gruß,

Frank

von Tom S. (year2525)


Angehängte Dateien:

Lesenswert?

Hallo,

anbei der log für die JVC für alle 5 Tasten des Steuerkreuzes. Wie 
gesagt, nur die Taste right liefert bei irmp_get_data() null zurück. 
IRMP timer irq ist 14400 Hz.

Das Enablen des IRMP Interrupts nur bei Infrarot-Aktivität werde ich 
dann also demnächst mal probieren.

Danke und Grüße

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Tom,

Tom S. schrieb:
> anbei der log für die JVC für alle 5 Tasten des Steuerkreuzes. Wie
> gesagt, nur die Taste right liefert bei irmp_get_data() null zurück.

Ich habe mir den Log eben angeschaut: Die Taste right sendet 17 statt 16 
Bits. Da das JVC-Timing exakt dem NEC-Timing entspricht, startet IRMP 
erstmal mit dem Protokoll NEC bei der Startbit-Erkennung. Kommt nach dem 
16. Bit dann eine Pause (weil es eben JVC und nicht NEC ist), schaltet 
IRMP auf JVC um. Das passiert aber leider nicht, wenn da statt der Pause 
noch ein 17. Bit hinterhergeschickt wird.

Da muss ich mir etwas einfallen lassen, habe da auch schon eine Idee...

> IRMP timer irq ist 14400 Hz.

Wie kommt diese "komische" Zahl zustande? Benutzt Du vielleicht einen 
Soft-UART mit einer Abtastrate von 28800, was einer Baudrate von 9600 
entspricht? ;-)

> Das Enablen des IRMP Interrupts nur bei Infrarot-Aktivität werde ich
> dann also demnächst mal probieren.

Ja, finde ich spannend. Sollte meiner Meinung auch problemlos 
funktionieren. Du könntest den Timer-Interrupt eigentlich auch sofort 
abstellen, sobald IRMP den Frame erkannt hat und nicht erst nach einer 
"gewissen" Zeit. Dazu müsstest Du aber in den IRMP-Source eingreifen.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Tom S. schrieb:
> anbei der log für die JVC für alle 5 Tasten des Steuerkreuzes. Wie
> gesagt, nur die Taste right liefert bei irmp_get_data() null zurück.

Im SVN ist nun eine neue Version, mit der jetzt auch die Taste "right" 
erkannt wird. War doch etwas mehr Arbeit als ich dachte. Läuft aber 
jetzt :-)

P.S.
Wenn Du Adresse und Code in Hex schreibst, wird die Systematik der 
Tastencodes besser ersichtlich:

# up    p=20 addr=0x000F cmd=0x0d0e
# down  p=20 addr=0x000F cmd=0x0d1e
# left  p=20 addr=0x000F cmd=0x0d2e
# right p=20 addr=0x000F cmd=0x0d3e
# enter p=20 addr=0x000F cmd=0x0d4e

von narkus (Gast)


Lesenswert?

Frank M. schrieb:
> B1. FB sendet ersten Frame
> B2. IRMP setzt Busy-Flag
> B3. IRMP liest ersten Frame ein
> B4. IRMP setzt Busy-Flag zurück
> B5. Applikation holt ersten Frame ab
> B6. FB macht eine Pause von ca. 40 msec
> B7. FB sendet zweiten Frame
> B8. IRMP setzt Busy-Flag
> B9. IRMP liest ersten Frame ein
> B10. IRMP setzt Busy-Flag zurück
> B11. Applikation holt zweiten Frame ab, Repetition-Flag ist gesetzt.

Hmm, B4 (Busy-Flag zurücksetzen) ist eigentlich falsch. IRMP sollte busy 
sein, solange ein wiederholter Tastendruck erkannt werden kann. Und das 
ist frühestens nach 114 ms der Fall!

Wird auf der FB eine Taste gedrückt gehalten, so sollte eine RC5 FB alle 
114 ms das Paket erneut senden. D.h. innerhalb dieser Zeit muss ich 
davon ausgehen, dass die Taste noch gedrückt ist!

Somit darf das Busy-Flag frühestens nach 114 ms (geben wir paar Sekunden 
Puffer drauf, für FBs, die sich nicht ganz daran halten) zurückgesetzt 
werden!

Zur Sicherheit kann man das Toggle-Bit vergleichen, falls es jemand doch 
schaffen sollte, innerhalb dieser Zeit diese Taste oder eine neue 
gedrückt zu haben. ;)

Was meinst Du dazu?
Grüße

von Tom S. (year2525)


Lesenswert?

Hallo Frank,

danke für prompte Änderungen. Ich kann bestätigen das jetzt auch die 
right Taste geht (und mit hex siehst besser aus). Ich hoffe das Deine 
Änderung der IRMP_TIMEOUT_TIME nicht andere remotes, die bis jetzt 
gingen, negativ beeinflussen werden :)
Da es eine Original JVC remote ist und der bisherige JVC Teil in IRMP 
wahrscheinlich gut getestet ist, gibt es wohl zumindest 2 Varianten des 
Protokolls im Hause JVC.

>Wie kommt diese "komische" Zahl zustande? Benutzt Du vielleicht einen
>Soft-UART mit einer Abtastrate von 28800, was einer Baudrate von 9600
>entspricht? ;-)

Nein, hat nichts mit einer UART zu tun. Ich habe einen 14.7456 MHz Quarz 
und wollte eine "glatte" interrupt Frequenz haben, also habe ich clk/8 
verwendet und OCR0A auf 127 gesetzt :)

Enablen des IRMP Interrupts nur bei Infrarot-Aktivität werde ich am WE 
probieren.

Danke und Grüße

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Tom S. schrieb:
> danke für prompte Änderungen. Ich kann bestätigen das jetzt auch die
> right Taste geht (und mit hex siehst besser aus). Ich hoffe das Deine
> Änderung der IRMP_TIMEOUT_TIME nicht andere remotes, die bis jetzt
> gingen, negativ beeinflussen werden :)

Ich checke nach Source-Änderungen einen Großteil der Scans im Ordner 
IR-Data unter Linux komplett durch, siehe IR-Data/test-suite.sh. Erst, 
wenn alle Scans ohne Fehler erkannt werden, gebe ich die Software raus.

> Da es eine Original JVC remote ist und der bisherige JVC Teil in IRMP
> wahrscheinlich gut getestet ist, gibt es wohl zumindest 2 Varianten des
> Protokolls im Hause JVC.

JVC ist relativ spät dazugekommen, gibt es erst seit ein paar Monaten. 
Also soooo gut getestet war es bisher nicht. Aber es sind tatsächlich 
Differenzen im Protokoll-Verhalten zwischen den beiden 
JVC-Fernbedienungen, deren Scans ich bisher erhalten habe. Das konnte 
ich aber erst anhand Deiner Right-Taste erkennen.

Gruß,

Frank

von jar (Gast)


Lesenswert?

Frank M. schrieb:
> irmp_protocol_names[irmp_data.protocol]

Frank M. schrieb:
> @jar:
>
> Um auf die Protokollnamen zugreifen zu können, muss

hallo, bin grad wieder bei

muss nun mein code anpassen

kannst du evt. in irmp.h ein

#ifndef TRUE vor line 486 setzen ?

#ifndef FALSE
  #define FALSE 0
#endif
#ifndef TRUE
  #define TRUE !FALSE
#endif


oder liegt der Fehler bei mir
../irmp.h:486:1: warning: "TRUE" redefined

von Cajus H. (cajush)


Lesenswert?

Hallo Frank,

meine programmierbare Fernbedienung mit 5" Touch-Screen ist fast fertig 
und ich feile an den letzten Kleinigkeiten.
Das aktuelle Problemkind sind zwei verschieden-alte Samsung LCD-TV, die 
beide das SAMSUNG32 Protokoll verwenden.
Problem 1: Das von IRSND generierte Signal wird vom TV nur erkannt, wenn 
meine FB in geringem Abstand vor dem TV mit Zielfernrohr auf das TV 
Gerät gerichtet wird. Außerdem muss man jede Taste ziemlich lange 
drücken, bis diese vom TV aktzeptiert wird.
Problem 2: Beim hintereinander-senden von mehreren Befehlen (z.B. "2", 
"4", "Enter" für die Anwahl des Programmes 24) wird nur der erste Befehl 
vom TV aktzeptiert.

zu Problem 1: Ich habe die Signale von IRSND und den Original-FB's am 
Ozszilloskop verglichen.
Mir sind folgende Unterschiede aufgefallen:
a) IRSND sendet immer zwei Frames, die Fernbedienungen senden auch 
einzelne Frames, wenn man die Taste kurz genug drückt.
b) die Pause-Zeit für den Bitwert "1" von IRSND ist zu kurz. 
IRSND=1450us, die Original-FB's haben 1680us und 1710us
c) die Pause-Zeit für den Bitwert "0" von IRSND ist zu kurz. 
IRSND=450us, die Original-FB's haben 550us und 580us
Die übrigen Zeiten aus den Definitionen in irmp.h (_START_BIT_xx und 
_PULSE_TIME) stimmen aber exakt!
Ich habe also folgende Änderungen in irmp.h vorgenommen:
#define SAMSUNG_1_PAUSE_TIME  1700.0e-6    // 1700 usec pause
#define SAMSUNG_0_PAUSE_TIME   550.0e-6    //  550 usec pause
#define SAMSUNG32_FRAMES      1            // SAMSUNG32 sends each frame 
1 time
Danach funktionierte meine FB wesentlich besser!

zu Problem 2: Ich konnte das Problem beheben, indem ich zwischen die 
Sendebefehle eine 50ms Pause eingefügt habe.
In Deinem Beitrag vom 20.05.2011 11:43 hattest Du dieses Problem als 
fixed gepostet:

>> IRSND hat im Moment auch noch einen unschönen Bug, den ich dabei auch
>> noch loswerden möchte: Nach Aussenden des gewünschten Frames wird die
>> Pause-Zeit zum nächsten Frame nicht eingehalten, wenn man
>> irsnd_send_data() direkt wieder aufruft. Innerhalb von flags > 0 wird
>> das korrekt eingehalten, aber nach dem letzten gesendeten Frame kann man
>> direkt wieder mittels irsnd_send_data() "feuern". Das ist unschön.

> Diesen Bug habe ich nun auch gefixt. Ist zwar noch nicht optimal, aber
> ich bin erstmal damit zufrieden. Die Pause wird nämlich erst dann
> eingefügt, wenn auch tatsächlich ein 2. Frame auf die Reise geschickt
> wird.

Kann es sein, dass noch nicht ganz funktioniert?

Viele Grüße
Cajus

von Joachim B. (jar)


Lesenswert?

frage zu IRSND

wo muss ich die CPU definieren ?
../irsnd.c:197:2: error: #error mikrocontroller not defined, please fill 
in definitions here.

holt IRSND sich das nicht aus astudio win-gcc den projekt options ? da 
hab ich doch die CPU gewählt

und wenn ich schon definieren muss, wie bitte ? für atmega1284p

   || defined (_AVR_ATmega1284P_)                      // 
ATmega164|324|644|644P|1284 uses OC2A = PD7 or OC2B = PD6 or OC0A = PB3 
or OC0B = PB4

es fehlte der Prozessor 1284p

noch eine kleine Anmerkung, sollte mit der Nennung OC2A und der CPU 
Definition der Port PD7 bekannt sein ? warum muss man den noch extra 
eingeben ?

noch ne doofe Frage, in astudio und im Arbeitsdir, wechseln manchmal die 
Dateinamen zu Uppercase Letter, das provoziert den c++ Fehler, ich weiss 
nicht wieso alle meine Dateinamen manchmal groß werden, auch wenn sie 
noch klein sind öffnet AStudio diese in Großbuchstaben und manchmal wird 
es auch so im Dir angezeigt

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:

> und wenn ich schon definieren muss, wie bitte ? für atmega1284p
>
>    || defined (_AVR_ATmega1284P_)                      //
> ATmega164|324|644|644P|1284 uses OC2A = PD7 or OC2B = PD6 or OC0A = PB3
> or OC0B = PB4
>
> es fehlte der Prozessor 1284p

Ja, den habe ich einfach vergessen. Eintragen und fertig:
1
#elif defined (__AVR_ATmega164__)   \
2
   || defined (__AVR_ATmega324__)   \
3
   || defined (__AVR_ATmega644__)   \
4
   || defined (__AVR_ATmega644P__)  \
5
   || defined (__AVR_ATmega1284__)  \
6
   || defined (__AVR_ATmega1284P__)                     // ATmega164|324|644|644P|1284 uses OC2A = PD7 or OC2B = PD6 or OC0A = PB3 or OC0B = PB4


> noch eine kleine Anmerkung, sollte mit der Nennung OC2A und der CPU
> Definition der Port PD7 bekannt sein ? warum muss man den noch extra
> eingeben ?

Musst Du ja eben nicht. In irsndconfig einfach OC2A auswählen und 
fertig. Über das obige #if in irsnd.c "weiß" dann der Compiler, welcher 
Portpin verwendet wird.

> noch ne doofe Frage, in astudio und im Arbeitsdir, wechseln manchmal die
> Dateinamen zu Uppercase Letter, das provoziert den c++ Fehler, ich weiss
> nicht wieso alle meine Dateinamen manchmal groß werden, auch wenn sie
> noch klein sind öffnet AStudio diese in Großbuchstaben und manchmal wird
> es auch so im Dir angezeigt

Ich habe alle IRMP-/IRSND-Sources mit Kleinbuchstaben angelegt, gerade 
um solche Probleme zu vermeiden.

Gruß,

Frank

von Joachim B. (jar)


Lesenswert?

Frank M. schrieb:
> Ich habe alle IRMP-/IRSND-Sources mit Kleinbuchstaben angelegt, gerade
> um solche Probleme zu vermeiden.

das habe ich auch, nur mein Problem ist ja das die urplötzlich groß 
werden

ich vermute aber das passiert durch primalscript wenn ich ausserhalb vom 
astudio mal eine *.c öffne

also wenns nicht astudio macht, dann wer anderes, ich wollte nur mal 
hören ob den Fehler jemand kennt

von Klaus K. (klkl)


Angehängte Dateien:

Lesenswert?

Hallo zusammen

Ich habe das irmp Projekt erfolgreich auf einem ARM SAM7x unter ethernut 
ans laufen bekommen. Die minimalen Änderungen schicke Ich hier mit.
Ein wirklich schönes Projekt....

Mein Vorschlag wäre es die Hardwareabhängigkeiten weitgehend aus irmp.c 
zu entfernen und insbesondere die input-Funktion ohne Parameter als 
extern zu deklarieren. Dann muss auf jeder Platform nur noch eine 
entsprechende Funktion generiert werden, und man muss weniger an irmp 
ändern.

Dann ist mir noch aufgefallen, das die IRQ-Routine für mein Gefühl recht 
viel Zeit beansprucht. 5-7us, damit verbraucht die IR-Erkennung bei 
15000 IRQs/s etwa 10% der Rechenleistung des SAM7. Bei einem AVR sieht 
das bestimmt noch schlechter aus(?)

Die Ethernut-Anbindung kann Ich auch an Interessiert weitergeben. Unter 
www.klkl.de werde Ich in den nächsten Tagen eine Seite dazu schreiben.

Vielen Dank, irmp hat mich schnell an mein Ziel gebracht
Gruß Klaus

von Joachim B. (jar)


Lesenswert?

hallo Frank,

so langsam komme ich voran, kann offensichtlich genau einmal IRSND 
aufrufen, danach hängt der Atmel, muss ich noch suchen (grrrr)

in deiner Projektseite hier :
http://www.mikrocontroller.net/articles/IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder
ist der Aufruf noch beschrieben als :
1
irsnd_send_data (&irmp_data);

ergibt aber:
Build error weil :
1
(void) irsnd_send_data (&irmp_data, TRUE);

eine Idee warum der genau nach einmal Aufruf abstürzt ? hab ich was beim 
Einbinden übersehen ?
1
      if(res_key & ( 1<<KEY_ENTER ))
2
      {  res_key=0;
3
        if(__p==_IRSND)
4
        {  
5
           irmp_data.protocol = IRMP_SAMSUNG32_PROTOCOL;   // sende im NEC-Protokoll
6
           irmp_data.address  = 0x0707;              // verwende Adresse 0x00FF
7
           irmp_data.command  = 0xed12;              // sende Kommando 0001
8
           irmp_data.flags    = 5;                   // keine Wiederholung!
9
10
          lcd_gotoxy(0,1); lcd_puts("R: Code: "); lcd_puts(trimm_string(' ', irmp_protocol_names[irmp_data.protocol], 8));
11
          lcd_gotoxy(0,2); lcd_puts("A: "); 
12
          strcpy(s2, "0x"); strcat(s2, utoa(irmp_data.address,s,16)); lcd_puts(trimm_string(' ', s2, 6)); 
13
          strcpy(s2, "("); strcat(s2, utoa(irmp_data.address,s,10)); strcat(s2, "d)");
14
          lcd_gotoxy(11,2); lcd_puts(trimm_string(' ', s2, 8));
15
          
16
          lcd_gotoxy(0,3); lcd_puts("C: ");
17
          strcpy(s2, "0x"); strcat(s2, utoa(irmp_data.command,s,16));  lcd_puts(trimm_string(' ', s2, 6)); 
18
          strcpy(s2, "("); strcat(s2, utoa(irmp_data.command,s,10)); strcat(s2, "d)");
19
          lcd_gotoxy(11,3); lcd_puts(trimm_string(' ', s2, 8));
20
            irsnd_send_data (&irmp_data, TRUE);
21
        }
22
}

danke jar

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Joachim,

Joachim B. schrieb:
> Build error weil :
> (void) irsnd_send_data (&irmp_data, TRUE);

Stimmt, da habe ich vergessen, den Artikel anzupassen. Werde ich 
nachholen.

> eine Idee warum der genau nach einmal Aufruf abstürzt ? hab ich was beim
> Einbinden übersehen ?

Kann ich erstmal nicht sehen. Schickt er denn tatsächlich 1+5 Frames 
raus, so wie du mit

> irmp_data.flags = 5;   // keine Wiederholung!

eingestellt hast?

Am leichtesten siehst Du das, wenn Du Dir die IR-LED mit einer 
Digitalkamera anschaust. Bei 6 Frames müsste es schon mehr als eine 
halbe Sekunde flackern.

Da ich nicht weiß, was das Programm nach Ausführen von irsnd_send_data() 
macht, kann ich Dir auch nicht sagen, wo es danach abstürzt ;-)

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Klaus,

Klaus Kloos schrieb:

> Ich habe das irmp Projekt erfolgreich auf einem ARM SAM7x unter ethernut
> ans laufen bekommen. Die minimalen Änderungen schicke Ich hier mit.

Vielen Dank für die Änderungen, werde ich in den IRMP-Source einbauen. 
Leider hast Du Deine eigene Input-Funktion weggelassen, hätte mich schon 
interessiert.

> Mein Vorschlag wäre es die Hardwareabhängigkeiten weitgehend aus irmp.c
> zu entfernen und insbesondere die input-Funktion ohne Parameter als
> extern zu deklarieren. Dann muss auf jeder Platform nur noch eine
> entsprechende Funktion generiert werden, und man muss weniger an irmp
> ändern.

Ich wollte eigentlich aus "Zeitgründen" vermeiden, eine externe Funktion 
in der ISR dafür aufzufrufen. Ließe sich Deine input-Funktion nicht auch 
als Makro in irmpconfig.h realisieren?

Gruß,

Frank

von Joachim B. (jar)


Lesenswert?

Frank M. schrieb:
> Da ich nicht weiß, was das Programm nach Ausführen von irsnd_send_data()
> macht, kann ich Dir auch nicht sagen, wo es danach abstürzt ;-)
> Gruß,
> Frank

bin einen Schritt weiter, kann mehrfach das Kommando mit KEY_ENTER 
auslösen

mir fehlt im Moment noch ein 2ter IRMP Empfänger, deine Idee mit der LED 
hatte ich schon umgesetzt, parallel zur IR ist eine UH rt LED zum 
gucken, einmal hab ich die IR mit der Cam im Handy gecheckt, öfter tut 
erst mal nicht Not

habe die Pollin RS232 zu FBAS bekommen, werde den ATmega 8 zu 168 
tauschen und den TSOP und IR Dioden bestücken, RS232 zu USB nehme ich 
die billigen 9,95 Teile, die aber nur 0 und +V liefern, doof mal sehen 
ob RTS und DTR genug Strom liefern zum betreiben vons ganze, deswegen 
wollte ich ja v-usb, da wäre der Strom gleich mitgekommen, aber den USB 
Adapter aufbohren mag ich nicht

muss man eigendlich den Buffer leeren ? mit
1
while(irmp_get_data(&irmp_data));

kannst du für IRSND noch die Codes für Sony Panasonic Canon Nikon DSLR 
Cams nachrüsten ?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Cajus,

Cajus H. schrieb:

> Das aktuelle Problemkind sind zwei verschieden-alte Samsung LCD-TV, die
> beide das SAMSUNG32 Protokoll verwenden.
> Problem 1: Das von IRSND generierte Signal wird vom TV nur erkannt, wenn
> meine FB in geringem Abstand vor dem TV mit Zielfernrohr auf das TV
> Gerät gerichtet wird. Außerdem muss man jede Taste ziemlich lange
> drücken, bis diese vom TV aktzeptiert wird.

Könnte das eine falsche Modulationsfrequenz sein? Die schlechte 
Reichweite spricht jedenfalls dafür. Kannst Du Modulationsfrequenz bei 
den Original-Fernbedienungen mit einem Scope (o.ä.) messen? Die 38kHz 
sind beim Samsung32-Protokoll nur "geraten", da ich darüber keine Daten 
im Internet finden konnte.

> zu Problem 1: Ich habe die Signale von IRSND und den Original-FB's am
> Ozszilloskop verglichen.
> Mir sind folgende Unterschiede aufgefallen:
> a) IRSND sendet immer zwei Frames, die Fernbedienungen senden auch
> einzelne Frames, wenn man die Taste kurz genug drückt.

Upps! Danke für die Info! Ich hatte bisher nur Samsung32-Scans bekommen, 
wo immer 2 Frames hintereinander kamen. Die Leute drücken leider beim 
Scannen meist länger die Taste, damit es auch "garantiert" ankommt. Hat 
den Nachteil, dass ich dann falsche Schlussfolgerungen ziehe. ;-)

Also ist für SAMSUNG32 in

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

der Eintrag

  Wiederholung     einmalig nach 45ms

falsch und es muss heißen:

  Wiederholung     keine.

> b) die Pause-Zeit für den Bitwert "1" von IRSND ist zu kurz.
> IRSND=1450us, die Original-FB's haben 1680us und 1710us
> c) die Pause-Zeit für den Bitwert "0" von IRSND ist zu kurz.
> IRSND=450us, die Original-FB's haben 550us und 580us

Danke auch dafür, ich werde das mit den mir vorliegenden Scans 
gegenprüfen. Ich habe da dieselben Werte wie für das SAMSUNG-Protokoll 
angenommen, da es im Rahmen der Messungenauigkeiten war und sich 
ansonsten das SAMSUNG- und das SAMSUNG32-Protokoll doch sehr ähneln.

> Die übrigen Zeiten aus den Definitionen in irmp.h (_START_BIT_xx und
> _PULSE_TIME) stimmen aber exakt!

Und das ohne Dokumentation :-) Ich habe mir das Samsung32-Protokoll 
nämlich lediglich anhand von Scans zusammengereimt.

> Ich habe also folgende Änderungen in irmp.h vorgenommen:
> #define SAMSUNG_1_PAUSE_TIME  1700.0e-6    // 1700 usec pause
> #define SAMSUNG_0_PAUSE_TIME   550.0e-6    //  550 usec pause
> #define SAMSUNG32_FRAMES      1            // SAMSUNG32 sends each frame
> 1 time
> Danach funktionierte meine FB wesentlich besser!

Danke, ist aber die falsche Stelle, da sich damit auch die Timings für 
das SAMSUNG-Protokoll (ohne 32) ändern. Tatsächlich muss ich da wohl 
SAMSUNG und SAMSUNG32 vom Timing her trennen.

> In Deinem Beitrag vom 20.05.2011 11:43 hattest Du dieses Problem als
> fixed gepostet:

Ja, das stimmt, hatte ich eigentlich gefixed... dachte ich jedenfalls 
:-)
Werde ich aber nochmal überprüfen.

Viele Grüße,

Frank

von Klaus K. (klkl)


Lesenswert?

Hallo Frank

Hier die wichtigsten Teile zu input-Funktion.
Für den Zeitbedarf ist es eigentlich unerheblich, ob eine externe oder 
eine Funktion aus der gleichen Code-Datei aufgerufen wird. Der Linker 
packt diese ja später zusammen, egal woher die Funktionen kommen. Der 
Optimierer hat nur etwas schlechtere Chancen überflüssiges zu entsorgen.

Wenn man die input-Funktion als 'wie ist denn der Stand auf dem 
IR-Eingang' versteht, dann kann dort der übergebene Parameter weg.

Ich betrachte irmp als autarkes Modul. Die Hardware-Abhaengigkeiten sind 
bei mir im aufrufenden Thread. Um die Funktion in irmpconfig() mit 
meiner input-Funktion ans compilieren zu bekommen müsste Ich dort wieder 
Dateien für den SAM7 einbinden.
Vielleicht kann man ein define vorsehen, womit dann die input-Funktion 
extern erwartet wird?

/*!
 * \def IO_PIO_PDS_REG
 * \brief Pin data status register of the button interface.
*/
#define IO_PIO_PDS_REG PIOB_PDSR

/*!
 * \def IO_IR_BIT
 * \brief used PIO bit. */
#define IO_IR_BIT      29

bei der Thread-Initialisierung
    /* Initialize GPIO lines for IR-Read. */
    outr(IO_PIO_PE_REG, IO_IR);
    outr(IO_PIO_OD_REG, IO_IR);
    outr(IO_PIO_PUE_REG, IO_IR);

/*!
 * \brief hier die Funktion fuer irmp um den Status des IO-Pins zu 
ermitteln
 */
uint8_t input(uint8_t test)
{
  return ( (~inr(IO_PIO_PDS_REG) & IO_IR) == 0);
}

Gruß Klaus

von Joachim B. (jar)


Lesenswert?

@frank, hattest du das gelesen ?

Joachim B. schrieb:
> muss man eigendlich den Buffer leeren ? mit
>
1
> while(irmp_get_data(&irmp_data));
2
>
>
> kannst du für IRSND noch die Codes für Sony Panasonic Canon Nikon DSLR
> Cams nachrüsten ?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:
> @frank, hattest du das gelesen ?

Ja, habe ich eben gelesen.

> muss man eigendlich den Buffer leeren ? mit
>
1
> while(irmp_get_data(&irmp_data));
2
>

Sollte man machen, wenn man dem User (z.B. fürs Anlernen) sagen will:

           "Drücke JETZT Taste auf FB".

Dann sollte man irgendwelche Frames, die man sich DAVOR "eingefangen" 
hat (z.B. weil die Freundin vorher ferngesehen hat) wegwerfen. Wenn Du 
aber sowieso permanent in einer Endlosschleife irmp_get_data() aufrufst, 
wäre oben genannte Zeile sinnfrei.

>> kannst du für IRSND noch die Codes für Sony Panasonic Canon Nikon DSLR
>> Cams nachrüsten ?

Steht natürlich auf meiner TODO-Liste. Jedes Protokoll, welches ich in 
den IRMP einbaue, will ich später dann auch in den IRSND einbauen. Aber 
nicht immer sind dafür Zeit und Lust vorhanden ;-)

Gruß,

Frank

von Joachim B. (jar)


Lesenswert?

Frank M. schrieb:
>>> kannst du für IRSND noch die Codes für Sony Panasonic Canon Nikon DSLR
>>> Cams nachrüsten ?
>
> Steht natürlich auf meiner TODO-Liste. Jedes Protokoll, welches ich in
> den IRMP einbaue, will ich später dann auch in den IRSND einbauen. Aber
> nicht immer sind dafür Zeit und Lust vorhanden ;-)
>
> Gruß,
>
> Frank

ja ist klar, meine todo ist auch länger als meine Zeit, brauchst du die 
Parameter für die Cams ? ich hab im Moment nur Q&D Code erzeugt der 
funktioniert, würde den gerne rauswerfen wenn IRSND eh schon drin 
ist....

mangels aller IR Sender kann ich die logisch nicht in IRMP scannen

von Joachim B. (jar)


Lesenswert?

@ Frank

Frage zu IRSND irmp_data.flags steht ja für Wiederholungen, 
offensichtlich bedeutet 0 eine Aussendung, also müsste 5 Wiederholungen 
6 Aussendungen bedeuten, mein TV Samsung32 hat aber jeweils nur 5 Prg 
weitergeschaltet,
(immerhin wenn man 99 wiederholungen proggt kann man so schnell als 
möglich zappen)
deswegen war ich in dem Glauben 5 bedeutet 5x aussenden und 0 eben 
keinmal, aber eben getestet, 0 bedeutet 1 Sendung aber 5 hat nur 5 PRG+ 
geschaltet und nicht 6

bin leicht verwirrt davon

der Absturz in meiner HW kann nur an der Dauer gelegen haben, bei 5 
repeat wird mein(e) Interrupt(s) zu lange unterbrochen, da kommt alles 
durcheinander

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:

> Frage zu IRSND irmp_data.flags steht ja für Wiederholungen,
> offensichtlich bedeutet 0 eine Aussendung, also müsste 5 Wiederholungen
> 6 Aussendungen bedeuten, [...]

Ja.

> mein TV Samsung32 hat aber jeweils nur 5 Prg weitergeschaltet,
> (immerhin wenn man 99 wiederholungen proggt kann man so schnell als
> möglich zappen)
> deswegen war ich in dem Glauben 5 bedeutet 5x aussenden und 0 eben
> keinmal, aber eben getestet, 0 bedeutet 1 Sendung aber 5 hat nur 5 PRG+
> geschaltet und nicht 6

Wie schon Cajus in

Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"

andeutete, muss da wohl jeweils eine Zwangspause gemacht werden. Diese 
wird zwar gemacht, wenn man irsnd_send_data() mit flags = 5 aufruft, 
aber nicht, wenn man 6x hintereinander irsnd_send_data() mit flags = 0 
aufruft. Die von Cajus gemachten Verbesserungsvorschläge für SAMSUNG32 
werde ich in den Source einarbeiten, Du kannst dies ja auch schonmal 
parallel bei Dir machen.

Gruß,

Frank

von Joachim B. (jar)


Lesenswert?

Frank M. schrieb:
> muss da wohl jeweils eine Zwangspause gemacht werden. Diese
> wird zwar gemacht, wenn man irsnd_send_data() mit flags = 5 aufruft,
> aber nicht, wenn man 6x hintereinander irsnd_send_data() mit flags = 0
> aufruft.

da muss ein Verständnisproblem vorliegen

du schreibst die Zwangspause wird benötigt und gemacht für
"irsnd_send_data() mit flags = 5"

wenns so wäre warum dann nur 5 Weiterschaltungen und nicht 6 ?

also 1 +5 Wiederholungen

"6x hintereinander irsnd_send_data() mit flags = 0"
hab ich nicht versucht, also kann deine Erklärung nicht passen ???

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:

> wenns so wäre warum dann nur 5 Weiterschaltungen und nicht 6 ?

Das weiß ich nicht. Vielleicht akzeptiert das Gerät nicht mehr als 5 
Wiederholungen in so kurzer Zeit?

Gruß,

Frank

von Joachim B. (jar)


Lesenswert?

Frank M. schrieb:
> Vielleicht akzeptiert das Gerät nicht mehr als 5
> Wiederholungen in so kurzer Zeit?

das wäre ja leicht zu testen :-) mach ich am WE

mit FLAGS 1, FLAGS 2, FLAGS 3, FLAGS 4, FLAGS 5, FLAGS 6,

müsste ja 2, 3, 4, 5, 6, 7 Weiterschaltungen geben :-)

von Cajus H. (cajush)


Lesenswert?

Hallo Frank,

>> ...Samsung LCD-TV, die beide das SAMSUNG32 Protokoll verwenden.
>> Das von IRSND generierte Signal wird vom TV nur erkannt, wenn
>> meine FB in geringem Abstand vor dem TV mit Zielfernrohr auf das TV
>> Gerät gerichtet wird. Außerdem muss man jede Taste ziemlich lange
>> drücken, bis diese vom TV aktzeptiert wird.

> Könnte das eine falsche Modulationsfrequenz sein? Die schlechte
> Reichweite spricht jedenfalls dafür. Kannst Du Modulationsfrequenz bei
> den Original-Fernbedienungen mit einem Scope (o.ä.) messen? Die 38kHz
> sind beim Samsung32-Protokoll nur "geraten", da ich darüber keine Daten
> im Internet finden konnte.

nein, ich habe die Frequenzen überprüft. 37.3 und 37.5 kHz. Das scheint 
mir innerhalb der Toleranz zu sein. Außerdem ist das Problem nach der 
Timing-Änderung wesentlich besser was ebenfalls gegen eine falsche 
Modulationsfrequenz spricht.
Ich habe übrigens auch die Wellenlängen der IR-LEDs der original-FBs mit 
der von mir verwendeten LED verglichen. Diese sind ebenfalls identisch.

Die vorgeschlagenen Änderungen werde ich vermutlich in Kürze im 
SVN-Repository wiederfinden, dann werden sie auch den Weg in meine 
Sourcen finden.

Hast Du noch vor die Zwangspause bei Befehlen gleichen Typs einzubauen? 
(bei flags=0). Wäre ganz schick, insbesondere bei Macros für 
Sendernummern ("2","3","Enter")

Viele Grüße
Cajus

von DK3SB (Gast)


Lesenswert?

Hallo zusammen,

ich versuche hier gerade ein kleines Heimproblem zu beheben: Bisher 
musste ich TV und Reciever hier immer mit 2 Fernbedienungen einschalten, 
die Fernbedienung für den Reciever brauchte ich danach aber nie wieder, 
also ging es mir auf den Geist immer 2 FBs rumliegen zu haben. Also 
dachte ich mir: Wäre es nicht prima, das durch eine unauffällige Kiste 
zu ersetzen, die auf das Power-On via Infrarot von der TV-Remote wartet 
und daraufhin das Power-On für den Reciever sendet.

Also genau das mit IRMP und IRSND realisiert, auf einen Formfaktor 
verkleinert, in dem es bequem in ein kleines Digitalthermometer passt, 
was nun in der Linie Sofa -> TV steht. Geht prima. Nach jetzt ca. 6 
Wochen kam mir das Problem der zu geringen Batterielaufzeit in den Sinn 
- ich musste jetzt das zweite mal die 2 x AAA-Zellen wechseln.
Der AtTiny45 den ich benutze ist bereits auf einen SleepMode 
eingestellt, den er immer betritt, wenn nix zu tun ist (was etwa 90% der 
Zeit der Fall ist schätze ich), aufwachen tut er durch die ISR vom 
Timer, in dem dann IRSND und IRMP aufgerufen werden. Das ging auch 
super, es verbleibt aber die Dauerhafte Stromaufnahme des TSOP, der an 
Vcc hängt. Also wollte ich diesen nun über einen Portpin schaltbar 
machen. Also vor der IRMP-ISR das Ding anschalten, danach wieder aus, 
keine Magie.

Nun wird allerdings nichts mehr deokdiert, das Umschalten des Portpins 
kann ich mit dem Oszi nachvollziehen, geht, ist etwa 10% der Zeit an, 
den Rest aus. Ich habe den Vcc-Pin des TSOP einfach an den µC gelötet 
und schalte so, wenn er an sein soll, den Pin Hi.

Am Data-Ausgang ist nun aber nix zu messen - könnt ihr mir das erklären? 
Brauch der TSOP eine Art "Einschwingzeit", ist mein Vorgehen komplett 
unangebracht? Was gibts für ne bessere Idee, das Ding auf Stromsparen zu 
optimieren?

mfg,
Stefan

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

DK3SB schrieb:
> Am Data-Ausgang ist nun aber nix zu messen - könnt ihr mir das erklären?
> Brauch der TSOP eine Art "Einschwingzeit", [...]

Ja, so wird es wohl sein. Der TSOP empfängt dann ja auch keine 
vollständigen Bits mehr, wenn er nur für einen Bruchteil der Zeit, die 
ein Bit braucht, eingeschaltet ist.

> Was gibts für ne bessere Idee, das Ding auf Stromsparen zu optimieren?

Welchen TSOP benutzt Du? Die neueren TSOP312xx (3mA?) sollen etwas 
sparsamer sein als die TSOP17xx (5mA).

Alternative wäre eine Selbstbau-FB, die mit IRMP/IRSND arbeitet, siehe 
z.B.

http://www.mikrocontroller.net/articles/DIY_Lernf%C3%A4hige_Fernbedienung_mit_IRMP

Das Ding kommt mit einigen µA aus. Wahrscheinlich reichen Dir die aber 
die 5 Tasten nicht, hier könnte man evtl. eine Tastatur-Matrix 
verwenden.

Gruß,

Frank

von Joachim B. (jar)


Lesenswert?

DK3SB schrieb:
> Der AtTiny45 den ich benutze ist bereits auf einen SleepMode
> eingestellt, den er immer betritt, wenn nix zu tun ist (was etwa 90% der
> Zeit der Fall ist schätze ich), aufwachen tut er durch die ISR vom
> Timer, in dem dann IRSND und IRMP aufgerufen werden. Das ging auch
> super, es verbleibt aber die Dauerhafte Stromaufnahme des TSOP

ich persönlich würde den TINY nicht per Timer aufwachen lassen sondern 
vom Pegelwechsel des TSOP, die Zeit für das Tinyaufwachen dürfte noch 
reichen um den Befehl auszuwerten, das senkt schon mal den 
Stromverbrauch, aber jeder IR Befehl weckt natürlich ! den Tiny ! also 
um dickere Akkus und Wechsel wirst du nicht rumkommen ! ich staune nur 
das der neue mit 3mA weniger verbrauchen soll, meine alten TSOP 17 haben 
nur um 1mA gebraucht

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:ich staune nur
> das der neue mit 3mA weniger verbrauchen soll, meine alten TSOP 17 haben
> nur um 1mA gebraucht

Meine TSOP auch, aber im Datenblatt stehen halt die 5mA bzw. 3mA - warum 
auch immer.

von Joachim B. (jar)


Lesenswert?

Frank M. schrieb:
> Das Ding kommt mit einigen µA aus. Wahrscheinlich reichen Dir die aber
> die 5 Tasten nicht, hier könnte man evtl. eine Tastatur-Matrix
> verwenden.

genau ! ich grübel gerade, irgendwo hatte ich eine Tastenmatrix gesehen 
die mit einem ! Pinchange Interrupt geweckt wird, da darf dann auch der 
TSOP abgeschaltet sein ! und trotzdem ist eine Tastenmatrix mit viel 
mehr ! Tasten möglich, zum Anlernen weckt man den auf kann bei IR 
Empfang in anlernen gehen, sonst nach aufwecken nur senden ! da braucht 
der TSOP dann keinen Strom saugen, trotzdem scheint mir dazu auch der 
168 von den Port unterdimensioniert wenn ich mal durchzähle 48-60 Tasten 
keine Seltenheit, heisst 8x8 Matrix und so viele Ports + LEDs sind 
selten frei, sieht eher nach mega32 bis 1284(p)aus, dafür auch im DIL40 
zu bekommen

PS. Senden 18mA ? (für Reichweite sollte man die 100mA mindestens 
ausnutzen, für schwache Batterien eher etwas drüber, damit das auch noch 
geht wenn der Batteriepegel sinkt) ich hab den Rv für die IR Sende Diode 
auf 22 Ohm verkleinert und für bessere Winkel lieber 2 IR Dioden in 
Reihe gelegt, meine 3mm Dioden finde ich recht schmal im Abstrahlwinkel, 
kann aber am Steckbrettaufbau liegen, nach unten ist das Brett der 
Begrenzer, optimal sitzen ja Dioden so das sie vorne über die Kante 
stehen und in keine Richtug eingeschränkt werden, aber mehr als 50° 
Dioden fand ich nicht in 3mm, als 5mm geht mehr, will aber optisch zu 
den LED (3mm) kompatibel bleiben

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:

> genau ! ich grübel gerade, irgendwo hatte ich eine Tastenmatrix gesehen
> die mit einem ! Pinchange Interrupt geweckt wird, da darf dann auch der
> TSOP abgeschaltet sein !

Klar.

> PS. Senden 18mA ?

Ja, aber es sind 18mA im Mittel. Der max. Strom durch die Sendediode ist 
natürlich höher, nämlich fast 100mA. Dies liegt zum einen an der 
Modulation mit einem Puls-Pausen-Verhältnis 50:50, andererseits an den 
Pausen des jeweiligen IR-Protokolls. Der mittlere Strom von 18mA ist 
genau das, was die IR-Sendediode (im Mittel) verkraftet - bei max. 
Sendeleistung. Das passt also ganz gut so.

von Stefan Biereigel (Gast)


Lesenswert?

Danke für eure Anregungen, ein paar kleine Kommentare dazu:

1. Die 5mA Verbrauch für TSOP 1738 sind quatsch, im Datenblatt steht 
dieser Wert in der Tabelle der "Absolute Maxmium Ratings", bei den 
"Normal Conditions" stehen da ~1mA, und das ist auch der reelle 
Verbrauch.

2. Eine Neue lernfähige Fernbedienung zu bauen wäre für meine Anwendung 
quatsch. Ich möchte meine Samsung-Remote benutzen, sie hat alle 
Funktionen und sieht dazu noch gut aus. Das war der Grund, eine solche 
"Verlängerung" für die zweite Fernbedienung zu bauen, und was anderes 
möchte ich auch garnicht. Das Thermometer sieht dekorativ aus, nur war 
halt das Batteriewechseln aller 2-3 Wochen mir nun aufgefallen.
Darum suche ich auch nach Stromsparmaßnahmen für den TSOP - gibt es 
eventuell einen speziell auf Stromverbrauchsminimierung ausgelegten 
Ersatz?

Abschalten kann man ihn wohl nicht, ich sehe in der kurzen On-Zeit kein 
Logisch-Hi am DATA-Out, wo es ja eigentlich sein müsste, das kommt erst 
später.

Aber nunja:

3. Ein Aufwachen auf die Pegelwechsel funktioniert hier nicht, da IRMP 
in festen Zeitintervallen aufgerufen werden will. Was man machen könnte, 
nach einer Art "Timeout" den Interrupt zu deaktivieren und auf externe 
Pegelwechsel zu triggern, wodurch er wieder aktiviert wird. Aber wie 
schon gesagt ist der AtTiny nicht mein Hauptstromverbrauch im Moment, er 
schläft etwa 90% der Zeit. Der TSOP der aber nicht abgeschalten wird 
braucht seine 1-2mA Dauerstrom und zieht die Batterie leer, dagegen kann 
ich nix machen, denke ich mittlerweile.

Danke trotzdem euch allen für eure Vorschläge, falls noch jemand was 
hat: Bin ich immer offen für!

von Joachim B. (jar)


Lesenswert?

Stefan Biereigel schrieb:
> 2. Eine Neue lernfähige Fernbedienung zu bauen wäre für meine Anwendung
> quatsch. Ich möchte meine Samsung-Remote benutzen

also Quatsch finde ich zu hart, why not ?
für mich wäre Selbstbau einer neuen in dem Grund begründet da alle meine 
lerndenden zu wenig Bittiefe haben und ich eine mit 433 Mhz will, habe 
eina alte die nach 1/4 Funktionen programiert voll meldet ! kaufe eine 
Neue (10 Jahre später) in der Hoffnung das die mehr Speicher hat und ich 
hab noch nicht mal alle Tasten 2er ! FB drin meldet die neue auch voll !
ich glaub da muss man selber bauen (*grummel grummel, gibt nix 
vernüftiges zu kaufen mit anlernen Bittiefe und Funk und Reichweite !)

> Der TSOP der aber nicht abgeschalten wird
> braucht seine 1-2mA Dauerstrom und zieht die Batterie leer, dagegen kann
> ich nix machen, denke ich mittlerweile.

sag ich doch, also doch richtige FB selber bauen

von Stefan Biereigel (Gast)


Lesenswert?

Gut, da gehen wohl unsere Vorstellungen etwas auseinander, schätze ich. 
Ich möchte gern die bestehende FB weiternutzen, sie hat ja echt nur EINE 
Taste nicht, auch schon dran gedacht habe ich, meinen µC einfach in die 
FB einzubauen, so könnte ich auf Taste reagieren (Ext. Int) und müsste 
keinen Strom verbrauchen wenn ich nix machen will ... Aber das ist alles 
eher unpraktikabel. Zur großen Not muss ich halt mit dem Batteriewechsel 
leben, aber zuerstmal versuche ich noch den Attiny45-20 gegen den 
AtTiny45-10 zu tauschen, der soll in der Spannung variabler sein (und 
weiter runter gehen) - mal sehen wie es damit aussieht.

Zum Thema Universal-FBs, auch wenn hier etwas OT:

Wenn man da Geld reinsteckt und nicht das 5€-Modell von [hier Discounter 
einsetzen] kauft, kann man für etwas mehr schon nen gutes Teil haben. 
Meine Chamäleon(s) die ich in der Vergangenheit nutzte konnten alle mehr 
lernen als ich lernen wollte, damals gabs noch: VCR, DVD, SAT, TV, 
Radio, PC

Jetzt hat sich das gesamte Geraffel auf TV + Reciever gekürzt, da wollt 
ich eigentlich dass eine FB reicht.

von Joachim B. (jar)


Lesenswert?

Stefan Biereigel schrieb:
> auch schon dran gedacht habe ich, meinen µC einfach in die
> FB einzubauen, so könnte ich auf Taste reagieren (Ext. Int) und müsste
> keinen Strom verbrauchen wenn ich nix machen will

das würde ich in deinem Fall für am sinnvollsten halten, weil ein immer 
an TSOP einfach unsinnig ist und  immer wieder den Tiny per Timer 
aufwachen lassen genauso, also kleiner Tiny mit Int an Taste und eigener 
IR Sendediode

> Zur großen Not muss ich halt mit dem Batteriewechsel
> leben, aber zuerstmal versuche ich noch den Attiny45-20 gegen den
> AtTiny45-10 zu tauschen, der soll in der Spannung variabler sein (und
> weiter runter gehen) - mal sehen wie es damit aussieht.

oder so !

> Zum Thema Universal-FBs, auch wenn hier etwas OT:
> Wenn man da Geld reinsteckt und nicht das 5€-Modell von [hier Discounter
> einsetzen] kauft, kann man für etwas mehr schon nen gutes Teil haben.

nein und immer wieder nein, ich hab alle universell von 100-400 € 
ausprobiert, die letzte Logitech Harmony ? 350€ so ein Sche*ss

anlernen ? ist nicht -> Codes nur über Logi Server download und wenn der 
mal abgeschaltet wird hat man 350 € Elektronikschrott !
Reichweite, kaum das ich das Wohnzimmer verlassen hatte war Ende mit 
Funk, das konnte und kann die 10 Jahre alte viel besser, Anlernen und 
Reichweite !
am grausamsten war die Programmierung, man muss erst mal alle Geräte und 
FBs vorstellen, dann darf man, muss man Macros programmieren, wer nur 
mal testeise eine programmiert kann später nicht mehr nachrüsten, alles 
auf Reset und dann alle Geräte und Macros neu anlernen, ja so eine 
Schrottprogrammierung und Menüs gibt es wirklich für 350 €

kein Wunder das mein Modell auch schon eine Rückgabe war, ich habs auch 
wieder zurückgegeben, für das Geld erwarte ich mehr, mehr Reichweite, 
mehr Funktionalität und mehr Komfort

von jar (Gast)


Lesenswert?

Frank M. schrieb:
> Klar

Frage an den Autor,

bin grad dabei die IR SND einer größeren Funktionalität zuzuführen

würde also gerne irmp_data erweitern mit Tasten-Name und Geräte-Name

2 Möglichkeiten

1 die schlechtere, ich erweitere das Feld, inkompatibel !
2 die bessere ? und da bin ich als nicht gelernter Progger unsicher

ich baue ein neues Array wo irmp_data drin steckt + G-Name und T-Name

hast du dazu ne Idee ?

oder noch besser einen Vorschlag ?

von jar (Gast)


Lesenswert?

und das möglichst platzsparend ?

also Idee
1.
STRUCT {
   g-name char[8];
   t-name char[8];
   IRMP_DATA;
}uni;


ist schon mal doof, verschwendet Platz

Idee
2.
STRUCT {
   t-name char[8];
   IRMP_DATA;
}g-name;

spart Platz, nur wie greife ich von aussen auf G-Name zu ?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

jar schrieb:

> 1.
> STRUCT {
>    g-name char[8];
>    t-name char[8];
>    IRMP_DATA;
> }uni;

Das ist die einzig vernünftige Möglichkeit, jedoch sind in den obigen 
Zeilen einige syntaktische Fehler drin :-)

Wenn schon, dann so:
1
#define MAXDEVICENAMELEN    8
2
#define MAXKEYNAMELEN       8
3
4
typedef struct
5
{
6
   char      devicename[MAXDEVICENAMELEN + 1];
7
   char      keyname[MAXKEYNAMELEN + 1];
8
   IRMP_DATA irmp_data;
9
} EXT_IRMP_DATA;

Dann kann man zum Beispiel folgendermaßen drauf zugreifen:
1
  EXT_IRMP_DATA  ext;
2
  ...
3
  strcpy (ext.devicename, "TV");
4
  strcpy (ext.keyname, "Volume+");
5
  ext.irmp_data.protcol = IRMP_SAMSUNG_PROTOCOL;
6
  ext.irmp_data.address = 0x0012;
7
  ext.irmp_data.command = 0x0034;
8
  ext.irmp_data.flags   = 0;


Das Erweitern auf ein Array (Du willst bestimmt mehr als eine Taste) 
überlasse ich Dir :-)

Gruß,

Frank

von jar (Gast)


Lesenswert?

danke, aber da muss ich noch mal drüber schlafen

ich weigere mich für jedes Gerät mehrfach den Namensplatz zu 
verschwenden, so üppig ist EEPROM Platz nicht im Atmel, da hat man ja 
mehr Platz im flash :-)

evt. nehme ich statt NAME 8+1 x-mal f. jede Taste und jedes Gerät (sieht 
irgendwie nach linearen 2-dimensionalen Array aus)

n-Tasten * m-Geräte egal ob Gerät x die Menge an Tasten von Gerät y hat

ein u_int8 für 256 Geräte und weise den Namen in einer table zu

von Fluto (Gast)


Lesenswert?

Hallo,

auch auf die Gefahr hin, dass ich gleich gerügt werde, weil ich nicht 
den kompletten thread gelesen habe und die Antwort bereits geschrieben 
wurde:
habe eine dreambox dm800se und würde nur gern wissen, welches Protokoll 
die haben / freigeschaltetes werden muss b.z.w. ob die überhaupt 
steuerbar sind. Habe irgendwo etwas von einem TWIRP- Protokol gelesen...
Gruß und danke
Fluto.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Fluto schrieb:

> habe eine dreambox dm800se und würde nur gern wissen, welches Protokoll
> die haben / freigeschaltetes werden muss b.z.w. ob die überhaupt
> steuerbar sind. Habe irgendwo etwas von einem TWIRP- Protokol gelesen...

Habe auch eine Dreambox und kann Dir schon mal sagen, dass die 
Dreambox-FB momentan nicht von IRMP/IRSND unterstützt wird. Mach ich 
vielleicht irgendwann mal...

Gruß,

Frank

von jar (Gast)


Lesenswert?

BTW. Kaseikyo

@frank

ich weiss du machst Kaseikyo immer im Blindflug mangels Geräte, soweit 
funktioniert das auch, nur hab ich das Problem das ich mit Tastendruck 
varieren alles von NEC, Siemens, Ruwido simmulieren kann, wohlgemerkt 
mit einer Kaseikyo ! entweder IRMP kommt durcheinander bei halben 
Repeatframes oder bei halben Frames ? oder deine Pausenerkennung ist 
unzuverlässig bezüglich Kaseikyo

was kann ich für dich tun damit du die besser erkennen kannst, bzw. die 
bessere Erkennung in IRMP einpflegen kannst ?

von Joachim B. (jar)


Lesenswert?

evt. kanns auch am int. RC Oszi liegen, bin da aber unsicher weil der ab 
Werk ja schon kal. Byte gesetzt hat und die Toleranzen nicht so riesig 
sind

meine Abweichung

//OCR2A = 76;  // Reloadwert Timer 2 rechnerisch richtig wär 78,125,

76/78,125

~2,7% mit Oszi ermittelt für einen anderen Timer, nicht für IRMP, also 
ohne Korrektur muss IRMP mit diesem 2,7% Fehler leben, das kann aber 
nicht die Ursache sein, FBs haben ja deutlich größere Toleranzen

von Martin R. (m-joy)


Lesenswert?

Hallo zusammen,
ich möchte das IRSND protokoll bei meinem ATTINY88 benutzen. Leider hat 
der ATTINY88 kein OC0A oder OC0B, sondern nur OC1A und OC1B. Was muss 
ich jetzt hier eintragen, damit es klappt?:
#define IRSND_OCx

grüße

von Joachim B. (jar)


Lesenswert?

nimmst halt den OC1A oder 1B statt 0

#define IRSND_OC1A oder
#define IRSND_OC1B

du brauchst aber das passende OC Bein für die Sendediode

oc für output compare, dein TINY88 muss ja sowas auch haben

wäre am PDIP 28,3 Pin15 f. OC1A

von Joachim B. (jar)


Lesenswert?

hier müsstest du erweitern:
1
#elif defined (__AVR_ATtiny45__) || defined (__AVR_ATtiny85__)  // ATtiny45/85 uses OC0A = PB0 or OC0B = PB1
2
#if IRSND_OCx == IRSND_OC0A                             // OC0A
3
#define IRSND_PORT                              PORTB   // port B
4
#define IRSND_DDR                               DDRB    // ddr B
5
#define IRSND_BIT                               0       // OC0A
6
#elif IRSND_OCx == IRSND_OC0B                           // OC0B
7
#define IRSND_PORT                              PORTB   // port B
8
#define IRSND_DDR                               DDRB    // ddr B
9
#define IRSND_BIT                               1       // OC0B

mit || defined (_AVR_ATtiny88_)
1
#elif defined (__AVR_ATtiny45__) || defined (__AVR_ATtiny85__) || defined (__AVR_ATtiny88__)

und
1
#elif IRSND_OCx == IRSND_OC1A                           // OC1A
2
#define IRSND_PORT                              PORTB   // port B
3
#define IRSND_DDR                               DDRB    // ddr B
4
#define IRSND_BIT                               1       // OC0B


wenn ich das Datenblatt richtig gelesen hatte

von Martin R. (m-joy)


Lesenswert?

ah cool danke :) werde ich testen sobald die schaltung aufgebaut ist. 
super =)

von Cajus H. (cajush)


Angehängte Dateien:

Lesenswert?

Hallo Frank,

da wäre mal wieder ein Problem:
IRSND und KASEIKYO Codes einer Panasonic DVD-RW Fernbedienung.
Ich habe zwei Tasten, deren Codes vom Gerät einfach nicht aktzeptiert 
werden.
Es handelt sich dabei um die Tasten "rot" und "grün". Wenn ich das 
Signal mit IRMP logge, dann wird bei beiden Sendern (original FB und 
IRSND-FB) der gleiche Befehl erkannt. Das Gerät reagiert jedoch nur auf 
die original-FB. Die anderen Tasten scheinen alle zu funktionieren, 
zumindest ist mir noch keine weitere Taste aufgefallen. Ich habe die 
Logs in den Anhang gepackt. Die Tasten "gelb" und "blau" funtionieren 
und sind nur als Referenz in der Logdatei. Irgendwie ist das Signal der 
Original-FB deutlich länger. Bei "rot" und "blau" habe ich außerdem den 
Finger zu lange auf dem Knopf gehabt, weswegen eine Wiederholung 
vorhanden ist.
Ich verwende die letzten Sourcen aus dem SVN, F_INTERRUPTS 15000 auf 
einem ATmega644A (Sender und Empfänger auf getrennter Hardware). Ich 
habe fast alle Protokolle in IRSND und IRMP aktiviert.
Hast Du da einen Tip für mich?
...
Da war doch noch was mit dem SAMSUNG32 Protokoll und der 
Wiederholpause...

Viele Grüße
Cajus

von Cajus H. (cajush)


Lesenswert?

Hallo Frank,

ich habe meine Scans mal durch IRMP unter Linux geschickt und ich denke,
ich habe das Problem gefunden. Eines der 4 System-Bits (Genre2) ist 
unterschiedlich.
Das Parity-Byte am Ende dann natürlich auch. hier für Taste "grün", bei 
"rot" das gleiche Bit.

010000000000010000001101000000000100001001001111  original
010000000000010000001101100000000100001011001111  IRSND
123456789012345678901234567890123456789012345678
MMMMMMMMMMMMMMMMppppGGGGggggCCCCCCCCCCiipppppppp
                        ^               ^
In Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"
stand etwas von

 - Kaseikyo: es werden nun die 4 System-Bits (Genre2) im Frame
   ausgewertet

Wo landen denn die Bits und wie bekomme ich die Bits wieder nach IRSND?
Welche 4 bits gehen denn dann verloren?

Könnte man die 4 Bits nicht in den oberen 4 Bits von "flags" 
unterbringen?
Die unteren 4 Bits werden bei IRSND schon für die Anzahl von 
Wiederholungen verwendet.
Die oberen Bits sind, soweit ich weis, noch frei.
Oder sollte man die IRMP_DATA-Struktur aufzuboren,
z.B. uint8_t flags in uint16_t wandeln?
Dann hätte man noch etwas mehr Luft.

Viele Grüße
Cajus

von Cajus H. (cajush)


Lesenswert?

Hallo Frank,

da Du offensichtlich im Moment nur wenig Zeit hast, habe ich mich mal 
daran gesetzt nach den Genre2-Bits im KASEIKYO Protokoll zu schauen.
Ich habe IRMP erweitert, die Genre2 Bits werden jetzt im MSB von flags 
zurückgegeben.
Danach habe ich die DVD-RW-Fernbedienung mal überprüft: Es sind 
tatsächlich nur die zwei Tasten "rot" und "grün", die ein Genre2 <> 0 
haben.
Ich habe allerdings noch einen neueren Blu-ray Player von Panasonic, der 
die gleichen Codes verwendet, dort sind schon 8 Tasten mit Genre2 <> 0.
Ich habe mich schon gewundert, warum meine IRSND-Fernbedienung bei 
diesem Gerät so schlecht funktioniert ...

Vielleicht komme ich am Wochenende dazu die Funktion in IRSND 
einzubauen. Dann werde ich den Diff zu den aktuellen SVN-Sourcen hier 
einstellen.

Falls Du Lust (und Zeit) hast, kannst Du ja vielleicht mal nach dem 
SAMSUNG32 Protokoll und der Wiederholpause sehen und die Änderungen ins 
SVN einchecken.

Viele Grüße
Cajus

von Cajus H. (cajush)


Angehängte Dateien:

Lesenswert?

Hallo Frank,

hier wäre dann die Änderung an irmp.c und irsnd.c, mit der die Genre2 
Bits der KASEIKYO Codes berücksichtigt werden. Wie schon erwähnt werden 
die 4 Bits in den oberen 4 Bits der flags eingeblendet. Diese Bits sind 
sowohl in irmp als auch in irsnd noch unbenutzt.
Die Quelle für den angehängten Patch sind die SVN-Sourcen von heute.
Es wäre schön, wenn die Änderung in Deinen offiziellen Sourcen eingebaut 
würden.

Viele Grüße
Cajus

von Joachim B. (jar)


Lesenswert?

Cajus H. schrieb:
> Hallo Frank,
> hier wäre dann die Änderung an irmp.c und irsnd.c, mit der die Genre2
> Bits der KASEIKYO Codes berücksichtigt werden. .......
> Viele Grüße
> Cajus

irgendwie blicke ich noch nicht durch wo genau ich das einfügen muss

kannst du die kompletten Texte mit deiner Änderung einstellen ?

die vielen + u. - verwirren mich

ich kenne - als entfernen und + als einfügen, heisst das aber lt. deimem 
Text nur zusätzlich einfügen an der Stelle oder wegen --- entfernen der 
orignal Texte ?


die Zeillennummern stimmen auch nicht mit meinen Versionen überein, 
weiss nicht ob ich da optimiert habe oder andere Quellen hatte.

Kaseikyo liegt mir ja auch sehr am Herzen, komme vermutlich erst heute 
dazu die IRSND in meinem RS232 zu BAS Konverter (Pollin) umgebaut zu 
RS232 zu IRMP implementieren

wenn das fertig ist werde ich Umbauplan und Source hier einstellen

das Teil versorgt sich selber über RS232 (RTS, DTR und TxD angezapft auf 
LM317CZ vom stromfressenden MAX232 befreit, mit sparsamer Trasischaltung 
ausgeführt) und kann von RS232 bedient werden

von Cajus H. (cajush)


Angehängte Dateien:

Lesenswert?

Hallo Joachim,

sorry, meine Patch-Datei war leider fehlerhaft. Ich habe am IRMP und 
IRSND Source noch einige andere Änderungen vorgenommen, die ich dann von 
Hand aus der Patch-Datei entfernt habe. Dadurch stimmten die 
Zeilennummern aber nicht mehr. Im Anhang sind jetzt die kompletten 
Dateien, Basis sind immer noch die SVN-Sourcen vom 2.12.2011.

Gruß
Cajus

von Martin R. (m-joy)


Lesenswert?

huhu, ich möchte nochmal auf den ATTINY88 zurück kommen.
ganz so leicht war es wohl doch nicht... in der irsnd.c
gibt es probleme. Anschinend fehlten definitionen und zwar...

Hier:

irsnd_on (void)
{
    if (! irsnd_is_on)
    {
#ifndef DEBUG
#if   IRSND_OCx == IRSND_OC1A             // use OC2
      TCCR1A |= (1<<COM1A0)|(1<<WGM12);   // toggle OC1A on compare 
match,  clear Timer 1 at compare match OCR1A

.....


hier:

irsnd_off (void)
{
    if (irsnd_is_on)
    {
#ifndef DEBUG
#if   IRSND_OCx == IRSND_OC1A    // use OC2
       TCCR1A &= ~(1<<COM1A0);   // normal port operation, OC1A 
disconnected.
..........


hier:
irsnd_set_freq (uint8_t freq)
{
#ifndef DEBUG
#if IRSND_OCx == IRSND_OC1A
OCR1A = freq;                       // use register OCR2 for OC2
#elif IRSND_OCx == IRSND_OC2A       // use OC2A

uner hier:
irsnd_init (void)
{
#ifndef DEBUG
    IRSND_PORT &= ~(1<<IRSND_BIT);    // set IRSND_BIT to low
    IRSND_DDR |= (1<<IRSND_BIT);      // set IRSND_BIT to output
#if IRSND_OCx == IRSND_OC1A         // use OC2
    TCCR1A = (1<<WGM12);          // CTC mode
    TCCR1A |= (1<<CS10);           // 0x01, start Timer 2, no prescaling




die werte für die timer habe ich jetzt eingesetzt, da diese nicht für 
IRSND_OC1A definiert waren. ich glaube aber da ist ziemlich viel falsch, 
leider weiß ich die richtigen werte nicht da ich total der überblick 
verloren habe :(

kann mir jemand helfen?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Cajus,

vorab erstmal eine Entschuldigung, dass ich mich jetzt erst melde. Deine 
Vermutung wg. knapper Zeit war schon ganz richtig.

Cajus H. schrieb:

> 123456789012345678901234567890123456789012345678
> MMMMMMMMMMMMMMMMppppGGGGggggCCCCCCCCCCiipppppppp
>                         ^               ^
> In Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"
> stand etwas von
>
>  - Kaseikyo: es werden nun die 4 System-Bits (Genre2) im Frame
>    ausgewertet

Da ging es mir um die 4 Bits, die Du oben mit GGGG gekennzeichnet hast. 
Die 4 Bits "gggg" habe ich bisher im IRMP einfach ignoriert, da sie 
nicht mehr in die IRMP_DATA-Struktur passten. Kaseikyo ist da mit 48 
Bits einfach zu fett. Bei den mir bekannten FBs war das auch kein 
Beinbruch, da die gggg-Bits immer 0000 waren.

> Könnte man die 4 Bits nicht in den oberen 4 Bits von "flags"
> unterbringen?

Ja, könnte man. Ich bin zwar mit der Lösung nicht ganz so glücklich, 
weil das eher ein Workaround als eine Lösung ist. Eher müsste man die 
IRMP-Datenstruktur aufblasen, z.B. Adresse und Kommando auf 32 Bits 
erweitern. Das würde aber zu Inkompatibilitäten zu bereits bestehenden 
Projekten führen, z.B. zum V-USB-IRMP-Projekt von Hugo Portisch, welcher 
momentan 6 Bytes über V-USB überträgt.

> Die unteren 4 Bits werden bei IRSND schon für die Anzahl von
> Wiederholungen verwendet.

So ist es, gut erkannt. Die oberen 4 Bits verwende ich teilweise in 
privaten IRMP-Projekten, z.B. bei meiner lernfähigen Fernbedienung.

> Die oberen Bits sind, soweit ich weis, noch frei.
> Oder sollte man die IRMP_DATA-Struktur aufzuboren,
> z.B. uint8_t flags in uint16_t wandeln?

Die Flags sind eigentlich nicht dafür gedacht, für Datenbits herzuhalten 
;-)

> Dann hätte man noch etwas mehr Luft.

Eher sollte man address & command aufbohren. Ich schwanke da hin und 
her... wegen einem einzigen Protokoll die Datengröße verdoppeln... 
kostet Zeit (im IRMP) und Speicher (z.B. in der makro-/lernfähigen FB).

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Cajus,

Cajus H. schrieb:

> hier wäre dann die Änderung an irmp.c und irsnd.c, mit der die Genre2
> Bits der KASEIKYO Codes berücksichtigt werden.

Vielen Dank, ich werde Deine Änderungen in den IRMP-Source einbauen. 
Aber die letzte Entscheidung, ob das so bleiben wird, ist darüber noch 
nicht gefallen. Ich finde die Verlagerung von Datenbits in die Flag-Bits 
eigentlich nicht so schön, habe (wie oben beschrieben) aber momentan 
auch keine bessere Lösung.

Gruß,

Frank

von Cajus H. (cajush)


Lesenswert?

Hallo Frank,

schön, dass Du wieder da bist!
Ich habe genau wie Du lange hin- und her-überlegt, ob man nicht lieber 
die Datenbits erweitert, aber wegen einem Protokoll?
Wenn Du meine Erweiterungen in IRMP und IRSND einbaust, dann kannst Du 
das Ganze ja in ein #ifdef stecken. Wer kein Kaseikyo verwendet, oder 
die Genre2 Bits nicht braucht, kann den Code ja rauslassen und die Bits 
für andere Zwecke verwenden. Allerdings ist Kaseikyo ziemlich 
gebräuchlich und ich vermute, es werden in Zukunft auch noch andere 
Geräte Gebrauch von den Genre2 Bits machen werden.

Auf die Gefahr, dass ich Dich mit der Frage inzwischen langweile...
Wolltest Du nicht auch noch meine Timing-Änderungen für SAMSUNG32 prüfen 
und in den Code einbauen?
Der Punkt mit der Zwangspause zwischen zwei Befehlen gleicher Kodierung 
ist auch noch offen...
( Beitrag "Re: IRMP - Infrared Multi Protocol Decoder" )

Schöne Feiertage!

Cajus

von Sebastian .. (zahlenfreak)


Lesenswert?

Wieso fügst du nicht noch einen weiteren Structmember für IRMP_DATA ein? 
Dann werden keine Flags missbraucht, man spart sichs, daten aus den 
flags zu operieren und die kompatibilität bleibt gewahrt. Alter Code mit 
neuem IRMP ignoriert die gggg-Bits einfach weiterhin. Und das problem 
mit dem unnötigen Speicher wäre auch weniger schlimm - man müsste ja nur 
ein Byte reservieren.


Viele Grüße,

Sebastian

von irmp (Gast)


Lesenswert?

hallo,

ich bekomme bei jeder Fernbedienung immer das heraus:

Code:
Address: 0x2X
Command: 0x2X

Hatte schon jemand diesen Fehler??



DANKE

von Michael H. (michael_h45)


Lesenswert?

Du gehst wohl auch im Keuschheitsgürtel zum Urologen...
Zeig deinen Code her. Vermutlich ist die Taktfrequenz falsch.

von Dieter (Gast)


Lesenswert?

Guten Abend,

ich habe fast das gleich Problem, nur bei mir erkennt er aber den Code.

Code: NEC
Address: 0x2X
Command: 0x2X

von Dieter (Gast)


Lesenswert?

du bekommst nur den Code, Address und Command sind leer.
1
printf("Code: %s\n",Proto[irmp_data.protocol-1]);
2
printf("Address: 0x%.2X\n",irmp_data.address);
3
printf("Command: 0x%.2X\n\n",irmp_data.command);

von Martin R. (m-joy)


Lesenswert?

huhu, kann mir denn niemand mit dem
IRSND protokoll bei meinem ATTINY88 helfen :(
ich bekomme die timer im protokoll net hin :(
das wär echt voll suuuuuuper !

grüße

von Michael H. (michael_h45)


Lesenswert?

du hast die antwort doch schon bekommen. sogar fertig ausgemalt...
Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"

von Martin R. (m-joy)


Lesenswert?

Michael H. schrieb:
> du hast die antwort doch schon bekommen. sogar fertig ausgemalt...
> Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"

huhu, das funktioniert leider nicht.... ganz so leicht wars wohl net, 
weil die timerbefehle in den funktionen
irsnd_on (void)
irsnd_off (void)
irsnd_set_freq (uint8_t freq)
irsnd_init (void)

für OCR1A nicht vorhanden sind....

von Mario G. (mario)


Angehängte Dateien:

Lesenswert?

Hallo zusammen,
tolles Projekt. Meine Fernbedienungen hab schon ich geloggt aber
hat jemand schon mal probiert die Protokolle von so kleinen 
Modellhubschraubern mit Infrarot zu entschlüsseln.
Ich habe einen kleinen Nincoair 180 ALU G 
(http://www.thalia.de/shop/home/rubrikartikel/ID24972473.html?zUserID=733&zanpid=1596265215589458944)

Anbei ein Log der Fernbedieung. Kann jemand etwas damit anfangen. 
Interruptfrequenz habe ich auf 20000 ISR/s gestellt.

Mario

von Mario G. (mario)


Angehängte Dateien:

Lesenswert?

Hier nochmal ein Scan desselben Hubschraubers mit 10khz. Ich habe es 
schon versucht mit irmp zu analysieren (unter Windows). Er erkennt ein 
irgendwie fehlerhaftes unvollständiges RC5... ich werd nicht schlau 
draus.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Martin K. schrieb:
> huhu, kann mir denn niemand mit dem
> IRSND protokoll bei meinem ATTINY88 helfen :(
> ich bekomme die timer im protokoll net hin :(
> das wär echt voll suuuuuuper !

IRSND braucht 2 Timer:

  - 8-Bit-Timer  0 für die Modulation des Signals durch PWM, z.B. 36kHz,
    38kHz, 40kHz - je nach Protokoll.

  - 16-Bit-Timer 1 für das Senden des IR-Frames, läuft i.d.R. mit 10
    oder 15 kHz.

Leider kann man auf dem ATTiny88 keine PWM mit dem Timer0 benutzen. 
Genau dieses Feature hat man dem kastrierten ATTiny88 geklaut.

Um das Ganze auf dem ATTiny88 zum Laufen zu bekommen, müsste man das 
Ganze umdrehen:

  - 16-Bit-Timer 1 für die Modulation des Signals durch PWM

  - 8-Bit-Timer  0 für das Senden des IR-Frames

Das Umschreiben ist ein wenig Arbeit, wofür ich gerade wenig Zeit habe.

Aber mal eine Frage: Warum benutzt Du einen 28-Pinner, der so abgespeckt 
ist? Nimm doch einfach einen ATMega88 statt dem ATTiny88. Der scheint 
auf den ersten Blick pinkompatibel zu sein und bietet wesentlich mehr 
Möglichkeiten.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Mario Grafe schrieb:
> Hier nochmal ein Scan desselben Hubschraubers mit 10khz.

10kHz reicht dafür aus, die Pulse (und Pausen) sind lang genug.

> Ich habe es schon versucht mit irmp zu analysieren (unter Windows).

"Analysieren" macht man in IRMP mit der "Analyze-Option" (-a). Du 
hättest einfach mal

   irmp.exe -a < hubi.txt

eingeben sollen ;-)

Das habe ich gerade mal unter Linux mittels

   ./irmp -a < hubi.txt

gemacht. Dabei kommt raus:

1. Protokoll ist Bi-Phase (Manchester). Das erkennt man daran, dass
   es sowohl 2 verschiedene Puls- auch auch 2 verschiedene Pausenzeiten
   gibt.

2. Startbit ist: ca. 970 µs Puls, dann ca. 275 µs Pause

3. Pulse: 490 µs und 890 µs

4. Pausen: 280 µs und 670 µs

Eigentlich sollten bei Bi-Phase-Protokollen die kurzen Pulslängen 
genauso lang sein wie die kurzen Pausen. Das gleiche gilt für die langen 
Puls-/Pause-Zeiten. Das Timing ist hier stark asymmetrisch und 
dementsprechend schlecht... ist das so ein Billig-Hubschrauber?

Wenn ich das richtig in Erinnerung habe, habe ich mal vor einigen 
Monaten die Unterstützung von stark asymmetrischen Bi-Phase-Protokollen 
eingebaut. Muss ich mir bei Gelegenheit nochmal ansehen.

Gruß,

Frank

von Martin R. (m-joy)


Lesenswert?

huhuu vielen dank, sorry ich wusste nicht dass es so viel arbeit ist...
das doofe ist ich hab die schaltung schon gemacht weil ichd achte das 
klappt :D naja dann werd ich die schaltung wohl mal mit dem mega88 
aufbauen wenn ich dafür wieder zeit finde hehe =)

danke trotzdem, jetzt weiß ich immerhin woran es liegt ;)

grüüüße

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Martin K. schrieb:
> huhuu vielen dank, sorry ich wusste nicht dass es so viel arbeit ist...
> das doofe ist ich hab die schaltung schon gemacht weil ichd achte das
> klappt

Wie gesagt: der ATMega88 scheint weitestgehend pinkompatibel mit dem 
ATTiny88 zu sein. Wenn Du Deinen ATTIny88 nicht fest eingelötet hast, 
kannst Du ihn direkt gegen einen ATMega88 ersetzen.

von Mario G. (mario)


Lesenswert?

Hallo Frank,

vielen Dank für die schnelle Antwort.

Frank M. schrieb:
> .. ist das so ein Billig-Hubschrauber?

Ja ist so ein Billigteil (vor allem die Steuerung), fliegt aber 
erstaunlich gut. Wäre lustig wenn man den mit deiner Lib auch steuern 
könnte :)

Frank M. schrieb:
> Wenn ich das richtig in Erinnerung habe, habe ich mal vor einigen
> Monaten die Unterstützung von stark asymmetrischen Bi-Phase-Protokollen
> eingebaut. Muss ich mir bei Gelegenheit nochmal ansehen.

Wie hast du denn das Protokoll bezeichnet? Welches muß ich aktivieren?

Noch eine Frage: Ich habe zur Analyse die "irmp.exe" unter Windows 
benutzt. Ist das die Version für 10kHz? Für Windows hast du keine 15 
bzw. 20kHz-Version kompiliert, oder?

Gruß
Mario

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Mario Grafe schrieb:

> Wie hast du denn das Protokoll bezeichnet? Welches muß ich aktivieren?

Es geht nicht um ein bestimmtes Protokoll, sondern nur darum, dass IRMP 
bei Manchester-Codes (Bi-Phase) wie RC5, RC6, Grundig usw. nicht ins 
Schleudern gerät, wenn die Zeiten stark asymmetrisch sind. Dein 
Hubschschrauber-Protokoll wird momentan nicht unterstützt. Kann ich mir 
bei nächster Gelegenheit mal vornehmen...

> Noch eine Frage: Ich habe zur Analyse die "irmp.exe" unter Windows
> benutzt. Ist das die Version für 10kHz? Für Windows hast du keine 15
> bzw. 20kHz-Version kompiliert, oder?

Die ist mit 10kHz kompiliert.

Gruß,

Frank

von Mario G. (mario)


Lesenswert?

Frank M. schrieb:
> Kann ich mir
> bei nächster Gelegenheit mal vornehmen...

Da freu ich mich schon drauf :)
Hast du denn einen Ansatz wie man die Adress- bzw. Kommando-
Bitlängen rausbekommt? Letztenendes muß man schauen wann ein neues 
Startbit kommt, oder? Aber wieder erkennt man die Adressbitlänge?

Falls du noch mehr Logs brauchst, sag Bescheid.
Sobald man den Schubhebel bewegt sendet die Steuerung ohne Pause wild 
drauflos, d.h. es werden permanent Datenpakete geschickt. Evtl. gehen 
einige Bits bei Logging verloren. Vielleicht werde ich mal die Baudrate 
erhöhen...

Gruß
Mario

von P...s (Gast)


Lesenswert?

Hallo,

wenn ich eine Fernbedinung dekodieren will, dann wird nur das Protokoll 
erkannt, die Adresse und das Commando steht leer. Ich benutzt die letzte 
Version die noch CodeVision unterstützt, das ist glaub ich die 2.0.0 vom 
16.08.2011.

Hatte jemand auch schon mal so ein Problem? Würde mich über Eurer Hilfe 
freuen.

von Wolfgang B. (wolfgang6444)


Lesenswert?

Hallo zusammen,

ich benutze irmp, irsnd und V_USB zusammen mit einer
Funkstrecke auf der Basis der RFM01/02-Module von hope - alles zusammen 
auf atmega8. Das ganze kommuniziert mit vdr per irmplircd. Ich bin
begeistert!

Jetzt wuerde ich gerne meine 'historische" Fernbedienung Grundig TP 400
VT empfangen und insbesondere mit irsnd codes aussenden.

Es handelt sich um einen biphase-code mit 29.5khz-Traeger. Das Startbit
hat ca 500us Puls gefolgt von 2.75ms Pause. Danach kommen 7 Daten-Bits
im biphase-code. Das erste Datenbit ist immer eine '0' (d.h. ca 500us
Puls gefolgt von 500us Pause). Wiederholungen sind durch 96ms Pausen
getrennt. Offenbar wird einfach der gleiche Code weitergesendet (kein
Toggeln erkennbar). Wie man da sinnvoll in Adresse und Daten unterteilt
ist mir unklar.

Ich habe mir den code in irmp.c angesehen. Eine Ergaenzung ist nicht 
direkt
trivial.
Es waere super, wenn mir da jemand helfen koennte oder ein paar Tipps 
haette?

Ich habe auch ein paar scope-traces - aber leider keine gesacannten 
files, da ich z.Z. kein UART in Betrieb habe.
Gruss und vielen Dank

Wolfgang

von Peter K. (peko)


Lesenswert?

Hallo Frank,
befasse mich nach endlos langer Zeit mal wieder mit IRMP/IRSND. Das 
Projekt ist ja richtig erwachsen geworden. Mich interessiert hier 
hauptsächlich der RC6A Code. Gibt es Erfahrungen bezüglich IRSND und 
RC6A an "realen" Geräten? Ich habe mal mit einem zweiten IRMP den von 
IRSND ausgesandten Code mit Logging empfangen. Was IRSND da sendet, hat 
rein gar nichts mit dem zu tun, was die originale FB sendet. Bin im 
Moment etwas ratlos, wo hier zu suchen wäre.
PS
SIRCS funktioniert z.B. sowohl in IRMP als auch in IRSND prima.

-peko

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Peter,

Peter K. schrieb:
> Gibt es Erfahrungen bezüglich IRSND und RC6A an "realen" Geräten?

Nein, ich habe bzgl. RC6A und IRSND kein Feedback.

> Was IRSND da sendet, hat rein gar nichts mit dem zu tun, was die
> originale FB sendet. Bin im Moment etwas ratlos, wo hier zu suchen wäre.

Scans Deiner FB würden mir helfen.

Gruß,

Frank

von Peter K. (peko)


Angehängte Dateien:

Lesenswert?

Hallo Frank,

bei so prompter Antwort schicke ich doch gleich mal einen Scan. 
Erklärungen sind im file enthalten.
-peko

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Peter K. schrieb:
> bei so prompter Antwort schicke ich doch gleich mal einen Scan.

Habs mir angeschaut, kann mir nicht erklären, warum der IRSND bei Dir so 
einen Schrott produziert.

Ich habe gerade mal unter Linux ausprobiert:

       ./irsnd-15kHz 21 0046 0081
1
Ausgabe:
2
00000000000000000000000000000000000000001111111111110000000111111100000001111111000000011111111111111000000011111111111111000000000000000000000111111111111110000000111111100000001111111000000011111110000000111111100000001111111000000011111110000000111111100000000000000111111111111110000000111111100000001111111000000000000001111111000000011111111111111000000000000001111111111111100000001111111000000011111110000000111111100000001111111000000011111110000000111111100000000000000111111111111110000000111111100000001111111000000011111110000000111111100000001111111000000000000001111111111111111111111111111
3
4
Wenn man das mit Deinem Scan der Original-FB vergleicht, passt es perfekt:
5
000000000000000000000000000000000000000001111111111110000000011111100000001111110000000111111111111100000001111111111111000000000000000000001111111111111000000011111100000001111110000000011111100000001111110000000011111100000001111110000000111111000000000000001111111111111000000011111100000000111111000000000000001111110000000111111111111100000001111110000000111111000000001111110000000111111000000011111110000000111111000000011111100000000111111000000000000001111111111110000000011111100000001111110000000111111000000001111110000000111111000000000000001111111111111111

Also prinzipiell funktioniert IRSND, denn beide Frames sehen (bis auf 
kleinere vernachlässigbare Timing-Unterschiede und damit eine 
schleichende Verschiebung) deckungsgleich aus und werden auch beide von 
IRMP einwandfrei wiedererkannt.

Es muss also ein Problem beim µC sein. Entweder ist da eine 
Inkompatibilität des IRSND-Sources betreffend Zielsystem Linux / ATmega 
oder die Speicherverwaltung auf dem µC ist durcheinander. Ob das am 
IRSND liegt oder an dem, was Du "drumherum" programmiert hast, kann ich 
aber erst sagen, wenn ich das selbst mit 2 µCs getestet habe. Der 
Schrott, den Dein µC ausgibt, sieht nach zerwürfelter Speicherverwaltung 
(Überschreiber auf Stack oder sonst irgendwo im SRAM) aus.

Sag mal bitte was über verwendeten µC, Speicherbedarf Deiner Anwendung 
etc.
Oder wenn Deine IRSND-Anwendung klein ist, poste doch mal den Quellcode.

Gruß,

Frank

von Peter K. (peko)


Angehängte Dateien:

Lesenswert?

Hallo Frank,

jetzt habe ich nochmal alles komprimiert, das Ganze besteht fast nur 
noch aus IRMP / IRSND. Ich nutze main() aus irmp. IRMP dient jetzt nur 
als Trigger zum Senden des RC6A codes: Wenn ein IR-Code empfangen wird, 
geht RC6A raus. Gerade mal eine Blink-LED ist noch mit dabei, damit ich 
sehen kann, daß der µC arbeitet. Ich verwende einen 664P mit 20MHz 
getaktet. Anbei mal die gezippten sources. Ich bin mir nicht sicher, ob 
ich nicht irgendwo ein define vergessen / oder falsch eingestellt habe.

Gruß, peko

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Es steht eine neue Version 2.0.3 von IRMP + IRSND zum Download bereit.

Download über Artikel:

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

und auch übers SVN möglich:

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

Änderungen IRMP:

  - Bugfix: oberstes Bit in Adresse falsch bei NEC-Protokoll, wenn auch
    NEC42-Protokoll eingeschaltet ist.
  - Timing von SAMSUNG- und SAMSUNG32-Protokoll korrigiert
  - Genre2-Bits werden nun im oberen Nibble von flags gespeichert.

Änderungen IRSND:

  - Timing von SAMSUNG- und SAMSUNG32-Protokoll korrigiert
  - Genre2-Bits werden nun im oberen Nibble von flags gespeichert.
  - Zusätzliche Pause nach dem Senden des letzten Frames

Vielen Dank an Cajus.

Wünsche viel Spaß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

IRSND hatte in der Version 2.0.3 den Fehler, dass es nur einen einzigen 
Frame rausschickte.

Deshalb gibt es nun eine Version 2.0.4 - zum Download und im SVN.

Gruß,

Frank

von Mathias O. (m-obi)


Lesenswert?

Ähm was ist das genre2 Bit? Wozu ist das da?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Mathias O. schrieb:
> Ähm was ist das genre2 Bit? Wozu ist das da?

Stimmt, dazu hätte ich mehr schreiben sollen. Es steht dazu aber einiges 
hier im Thread. Die Genre2-Bits sind 4 Bits aus dem Kaseikyo-Protokoll.

Leider ist das Kaseikyo-Protokoll mit 48 Bit so fett, dass die 4 
Genre2-Bits nicht mehr in die IRMP_DATA-Struct passen. Deshalb werden 
sie nun im oberen Nibble von flags gespeichert bzw. von IRSND 
ausgewertet. Ich bin zwar mit dieser Lösung nicht sehr glücklich, weiß 
aber im Moment auch keine bessere Lösung... außer IRMP_DATA zu 
vergößern. Ob das so bleibt, weiß ich noch nicht.

Das Ganze ist nur relevant, wenn man Kaseikyo nutzt. Die 4 Genre2-Bits 
sind bei Kaseikyo zudem meist 0, so dass diese Änderung nur in ganz 
speziellen Fällen zum Tragen kommt.

Ich werde dies noch im IRMP-Artikel erwähnen.

Gruß,

Frank

von jar (Gast)


Lesenswert?

Frank M. schrieb:
> Leider ist das Kaseikyo-Protokoll mit 48 Bit so fett, dass die 4
> Genre2-Bits nicht mehr in die IRMP_DATA-Struct passen

genau das verstehe ich immer noch nicht, du schreibst immer von 48 Bit 
bei Kaseikyo, aber in IRMP gibt es nur 16 Bit Address und 16 Bit Data, 
mit den 4 zusätzlichen (Genre2) landen wir bei 36 Bit, warum schreibst 
du bei Kaseikyo immer von 48 Bit, ich gehe davon aus das Protocolbyte 
eine IRMP spezifische ist, die nur festlegt welches Protokoll erkannt 
wurde und keine Nutzdaten aus der IR Übertragung trägt, genau wie Flags

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

jar schrieb:
> genau das verstehe ich immer noch nicht, du schreibst immer von 48 Bit
> bei Kaseikyo, aber in IRMP gibt es nur 16 Bit Address und 16 Bit Data,
> mit den 4 zusätzlichen (Genre2) landen wir bei 36 Bit, warum schreibst
> du bei Kaseikyo immer von 48 Bit, ich gehe davon aus das Protocolbyte
> eine IRMP spezifische ist, die nur festlegt welches Protokoll erkannt
> wurde und keine Nutzdaten aus der IR Übertragung trägt, genau wie Flags

Wenn Du Dir

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

unter "Kaseikyo" anschaust, dann weißt Du warum. Im Frame stecken 4 + 8 
= 12 Parity-Bits. Die brauche ich nicht, die kann IRSND mühelos wieder 
aus den 36 Daten-Bits wieder reproduzieren. Aber auch 36 Bits sind 4 
Bits zuviel.

Gruß,

Frank

P.S.
Die Parity-Bits werden selbstverständlich von IRMP berücksichtigt, um 
die Korrektheit der Daten zu prüfen. Gespeichert werden brauchen sie 
aber nicht.

von jar (Gast)


Lesenswert?

Frank M. schrieb:
> ie kann IRSND mühelos wieder
> aus den 36 Daten-Bits wieder reproduzieren. Aber auch 36 Bits sind 4
> Bits zuviel.

danke, so wie ich das nun rauslese haben wir alle 36 relevanten Bits vom 
Kaseikyo, aufgeteilt in IRMP auf 16 Address Bits und 16 Command Bits + 4 
Genre2 Bits in Flags, du schreibst 4 sind zuviel, aber es gab ja User 
die die brauchten, ich konnte zwar alle Kaseikyo Codes auslesen, habe 
aber bis jetzt nur einen schwach senden können, kann aber an den Dioden 
oder der Frequenz liegen, das genau muss ich noch testen, ich bekomme ja 
die Bits aus einem TSOP (3)1736 der spuckt natürlich zwischen 32 und 38 
kHz locker Daten aus, meine Sendediode hat 940nm mit wenig sr, es gibt 
aber auch 950 und 880er nm Dioden mit viel mehr power, aber das ist 
wieder ne andere Baustelle

von KLaus (Gast)


Lesenswert?

Hallo

Ich verfolge nun dieses Thread schon seit Wochen .
Derzeit programmiere ich noch alles in Bascom, das wird sich aber 
ändern.
Da ich eh noch nicht so lange mit MC’s bastel is das auch nicht so 
weltbewegend, bin ja nicht festgewachsen 
Aber wird schon a bissal Hirnschmalz nötig sein!

Aber nichts desto trotz , ich hab ein Problem mit der integration von 
IRMP und IRSND in ein fertiges
Gerät, dass ich von der Arbeit gespendet bekomme. Es sind keine Layout 
Änderungen möglich.

Das is so ein Gaswarner für die Chemieindustrie mit einem Atmel an 
Board.
Den oder diese würde ich gerne für zukünftige Projekte verwenden.
Dazu sollte es möglich sein per IR Einstelungen von einem Laptop oder 
2.tem Gaswarner zu übertragen, dies will ich mit rc5 oder anderem z.B. 
Grundig Code übertragen.

Auf einer extra aufgebauten Schaltung (Polin Board) funktioniert IRMP 
tadel los mit 16Mhz Atmega 32! Die Grundig IR Variante hat bei mir die 
stabilste Erkennung.

Ausstattung :
-  Atmel Atmega169PV-8MU  /hab ich fürs compilieren in der IRMP 
atmega168 Sektion hinzugefügt)
-  1Mhz interner Takt (ckdiv8 gesetzt)  - dies ist die 
Standardeinstellung vor und nach dem Löschen des orginal beschriebenen 
microcontrollers und sollte auch so bleiben
-  SIR TFBS4711 (irda Transceiver)
Irgend ein Quarz(FSR 12.5) ohne Kondensatoren ist verlötet (evtl ein 
Uhrenquarz ?)

Mein Problem nun :
Der RX pin des IRDA ist auf PG4 (T0/SEG23)
Der TX Pin des IRDA ist auf PB4 (OC0A/PCINT12)

Ich kann Daten empfangen mit der Log Funktion(in der neuesten IRMP 
allerding lässt  sichs nicht mehr compilieren mit Log Flag) von IRMP, 
aber es wird nie etwas komplett erkannt so das ich keine Adresse , 
Command und sonstige Daten zum Auswerten bekomme.
Beim Senden wird’s wohl  auch nix werden .

Ich hab schon mehrfachi n einigen Foren gelesen , dass es möglich sein 
muss ohne externen quarz IR empfangen und senden zu können.
Aber Wie ?
Hab schon mit den Fuses (ckdiv8) und den FPU einstellungen gespielt aber 
leider nichts.

Beim Atmega32 gehst auch mit 8Mhz internem Takt (nur das Thomson wird 
dann nicht mehr erkannt), bei 1Mht internem Takt rührt sich allerdings 
auch beim Atmega32 nichts mehr.

Ich denke ich hab fürs empfangen hier ein eindeutiges Timing Problem 
aber wie mach ich das es funktioniert???
Kann mir bitte jemand auf die Sprünge helfen, oder zumindest erstmal 
noch fragen was er zu meiner Problemlösung noch wissen muss ?
Hab schon etliche Nächte weiss werdende Haare gezählt.


Gruß Klaus

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo zusammen,

eine neue Version von IRMP und IRSND steht zum Download bereit. Diese 
ist nun auch für den C18-Compiler (PIC) verfügbar. Ebenso kann man nun 
auch unbekannte Formate auf dem PIC scannen (über USB).

Vielen Dank dafür an gera!

IRMP Version 2.0.4:

 - Bug in IR60-Decoder behoben
 - Bug in CRC-Berechnung von Kaseikyo-Frames behoben
 - Portierung auf C18 Compiler für PIC-Mikroprozessoren
 - Scannen von IR-Frames auf dem PIC (über USB)

IRSND Version 2.0.4:

 - Neues Protokoll: IR60
 - Bug beim Senden von Bi-Phase-Frames (Manchester) behoben
 - Portierung auf C18 Compiler für PIC-Mikroprozessoren

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

KLaus schrieb:
> Mein Problem nun :
> Der RX pin des IRDA ist auf PG4 (T0/SEG23)
> Der TX Pin des IRDA ist auf PB4 (OC0A/PCINT12)

IRMP funktioniert nicht mit IRDA. Diese IRDA-Controller benutzen ein 
eigenes Protokoll, dass Du überhaupt nicht beeinflussen kannst. Du 
kannst versuchen, den IRDA-Controller direkt über RX/TX als UART 
auszulesen bzw. Daten darüber zu senden. Das hat dann aber gar nichts 
mehr mit IRMP zu tun.

Gruß,

Frank

von jar (Gast)


Lesenswert?

KLaus schrieb:
> Ausstattung :
> -  Atmel Atmega169PV-8MU  /hab ich fürs compilieren in der IRMP
> atmega168 Sektion hinzugefügt)
> -  1Mhz interner Takt (ckdiv8 gesetzt)  - dies ist die
> Standardeinstellung vor und nach dem Löschen des orginal beschriebenen
> microcontrollers und sollte auch so bleiben
> Beim Atmega32 gehst auch mit 8Mhz internem Takt (nur das Thomson wird
> dann nicht mehr erkannt), bei 1Mht internem Takt rührt sich allerdings
> auch beim Atmega32 nichts mehr.

ich denke mit 1 MHz geht eh nix mehr, egal welcher Atmel, das wäre dann 
auch das was du schon beobachtet hast

von Klaus (Gast)


Lesenswert?

jar schrieb:
> KLaus schrieb:
>> Ausstattung :
>> -  Atmel Atmega169PV-8MU  /hab ich fürs compilieren in der IRMP
>> atmega168 Sektion hinzugefügt)
>> -  1Mhz interner Takt (ckdiv8 gesetzt)  - dies ist die
>> Standardeinstellung vor und nach dem Löschen des orginal beschriebenen
>> microcontrollers und sollte auch so bleiben
>> Beim Atmega32 gehst auch mit 8Mhz internem Takt (nur das Thomson wird
>> dann nicht mehr erkannt), bei 1Mht internem Takt rührt sich allerdings
>> auch beim Atmega32 nichts mehr.
>
> ich denke mit 1 MHz geht eh nix mehr, egal welcher Atmel, das wäre dann
> auch das was du schon beobachtet hast

Frank M. schrieb:
> KLaus schrieb:
>> Mein Problem nun :
>> Der RX pin des IRDA ist auf PG4 (T0/SEG23)
>> Der TX Pin des IRDA ist auf PB4 (OC0A/PCINT12)
>
> IRMP funktioniert nicht mit IRDA. Diese IRDA-Controller benutzen ein
> eigenes Protokoll, dass Du überhaupt nicht beeinflussen kannst. Du
> kannst versuchen, den IRDA-Controller direkt über RX/TX als UART
> auszulesen bzw. Daten darüber zu senden. Das hat dann aber gar nichts
> mehr mit IRMP zu tun.
>
> Gruß,
>
> Frank

Hallo Frank


Danke für deine Antworten
Aber jetzt werd ich wohl mal kalt duschen gehen müssen, ich dachte 
dieser irda controller lässt sich auch dazu bewegen die Daten korrekt zu 
empfangen und zu senden  da ich ja schon Daten empfing aber eben nur im 
log modus .
Da hab i jetzt echt 2 oder 3 wochen rumgedoktert , oh MAMA MIA , wo werd 
ich noch enden :-(. hätt wohl eher fragen sollen.

Zu aller Anfang versuchte ich alllerdings eine Kommunikation direkt über 
Software Uart mit 2 Gasmeldern.
Ich dachte ich könnte das einfach bei 1Mhz Controllertakt und 2400Baud 
übertragen incl verdunklung der Irda Transceiver.
Schien mir das einfachste . Aber irgendwas mache ich falsch .
Was genau da nicht funktioiert  kann ich erst sagen wann ich wieder an 
diesem Punkt anfange und weitermache. Denke aber es wurden einfach keine 
Daten am empfänger ausgegeben.

Kann mir evtl jemand ein Example zeigen das ohne encoder/decoder chip 
zwischen uart(controller) und irda transceiver auskommt und trotzdem 
Daten übertragen werden können?

gruß klaus

von jar (Gast)


Lesenswert?

es gab mal Irdeo welche über UART ging
mit etwas umlöten geht auch die Kombi WinLirc und IR Assistent

aber das hat nix mit hier zu tun, aber mit einem Tiny85 IR zu seriell 
und an der Seriellen geht das im Prinzip

von jar (Gast)


Lesenswert?

Klaus schrieb:
> Kann mir evtl jemand ein Example zeigen das ohne encoder/decoder chip
> zwischen uart(controller) und irda transceiver auskommt und trotzdem
> Daten übertragen werden können?

willst du wirklich echtes IRDA ?
http://www.infrarotport.de/

von Didi S. (kokisan2000)


Lesenswert?

Hallo Frank,

eigentlich ist es garnicht so dramatisch mit dem IrDA Transceiver. Doch 
eines Vorweg. Das IrDA Software Protokoll ist ausgelegt, um 
unterschiedlichste Geräte miteinander zu verbinden. Nach dem OSI Modell 
laufen zwischen zwei Geräten viele Kommunikationen ab, in denen sich die 
Geräte über Protokoll, maximale Geschwindigkeit, Errorkodierung und CRC 
Prüfsumme austauschen. Doch das sind alles sachen, die Du für eine 
eigene Punkt zu Punkt Verbindung NICHT benötigst. Wenn Du den gesamten 
Overhead weglässt, dann bleibt beim TFBS4711 Transceiver ein IR Bauteil 
das im Halbduplex Verfahren Daten senden und empfangen kann - und das 
sehr gut und fehlerfrei innerhalb gewisser Grenzen.

Der TFBS4711 ist ein SIR Bauteil, kann also Daten senden und empfangen 
von 2400 Baud bis 115200 Baud. Das SIR Protokoll ist zum UART Signal 
nicht kompatibel, weil High und Low als RZI (Return to Zero Inverted) 
gesendet werden. Um den Unterschied zum UART zu verstehen, schaue Dir 
doch bitte einmal das Bild 13 im Physical Layer von IrDA an: 
http://www.vishay.com/docs/82513/physical.pdf.
Statt einem "High" auf dem UART muß ein "Low" bereitgestellt werden. Für 
jedes "Low" auf dem UART muß ein "3/16 High" am TFBS4711 angelegt 
werden. Wenn Du den TFBS4711 so ansteuerst, dann funktioniert die 
Übetragung per IR genau so, als ob Du zwei Controller per UART 
kommunizieren lässt.

Du hast jetzt zwei Möglichkeiten:

1) Wenn Du das IrDa Bauteil an einem normalen UART eines Controllers 
anschliessen willst, benötigst Du ein Encoder-Decoder Baustein zwischen 
UART und TFBS4711. Ich habe vor vielen Jahren diese beiden 
mitentwickelt:
http://www.vishay.com/docs/81749/toim5232.pdf
http://www.vishay.com/docs/82546/toim4232.pdf

2) Wenn Du die Möglichkeit hast den TFBS4711 an zwei freien Pins des 
Controllers anzuschliessen, kannst Du das Timing des SIR Protokolles 
einfach selber programmieren.

Im Internet findest Du Softwarerealisierung des SIR Protokolls wie 
z.B.hier: http://www.gaw.ru/pdf/TI/app/msp430/slaa044.pdf

Wenn Du den Weg weiter verfolgen möchtest, dann müsste ich mal in meinem 
Fundus graben. Ich habe da eventuell noch Sourcecode Relikte für 
Prozessoren ...

Gruß
kokisan

von Didi S. (kokisan2000)


Lesenswert?

Hallo Frank,

sorry, meine ausführlichen Hinweise in meinem letzten Beitrag waren 
nicht für Dich, sondern für Klaus gedacht ;-)

Frank, klasse Arbeit mit IRMP !!!

Gruß
kokisan

von Klaus (Gast)


Lesenswert?

Hallo erstmaltschuldigung für das späte schreiben , bin gerade beruflich 
unterwegs
Danke für die vielen Anworten
@jar
willst du wirklich echtes IRDA ?


Nein das ist das was ich will .
Mein Bestreben ist es , den IRDA Transceiver mit einem irda transceiver 
kommunizieren zu lassen ohne zusätzliche beschaltung (wie vorgegeben) 
und sowie es didi in seinem ersten block beschrieben hat .
und evtl. auch über eine normale sende und empfangsdiode daten hin und 
herschieben und das ganze mit einem atmega169 bei 3,6 Volt.
Es  muss keine hoche Reichweite haben , 20cm reichen.

@Didi S. (kokisan2000)

Du bist meine Rettung , du hast mich verstanden :-))
Da ich nicht flexibel bin mit meiner Hardware , is ja ein fertig 
verbauter Gasmelder mit Atmega169 und Irda Transceiver
daher kommt für mich nur zweiteres in Frage .
Und ich hab mich grad riesig gefreut da du was zu dem 3/16 Dings 
geschrieben hast und das auch noch auf einfache weise
Ich werde mich mit diesem Thema beschäftigen,dazu kann ich sehr gerne 
deine SourceCode Schnippseln brauchen .
Evtl. hast du noch mehr solcher Erklärungsstützen auf Lager :-)
 wautschis AT gmx dot net
Versuche dann auch mir das gabnze zu erklären was aber am Anfang immer 
ein Riesenberg ist da einzusteigen:-(

Wanns mal klar ist dürfte das ganze gar nicht mehr so schwer werden

von Klaus (Gast)


Lesenswert?

@didi
eins hab i  ja noch vergessen
die original firmware die drauf
war konnte alles mit dem chkdiv8 teiler und 1 Mhz Prozessor takt

die programmierer haben das eben auch per programmierung gelöst und das 
mit 1mhz takt
bzw. es ist nooch ein quarz verbaut aber warsch. ein uhrenquarz.
dder gasmelder soll ja 18 monate rückwärts zählen und ausgehen oder wann 
Batterie leer ist.
Die Übertragung der sensor daten fand auch in unmittelbarerer nähe zum 
controllgerät statt.

von Klaus (Gast)


Lesenswert?

@jar
willst du wirklich echtes IRDA ?

fix verschrieben

natürlich will ich das nicht! :-)

von Hans W. (stampede)


Lesenswert?

Darf das IRMP auch kommerziell genutzt werden?

von Michael S (Gast)


Lesenswert?

Hat jemand die Lib schon auf einem atXmega eingesetzt ? Gibts evtl. nen 
Patch ?

Danke
Michael

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hans W. schrieb:
> Darf das IRMP auch kommerziell genutzt werden?

Da IRMP unter der GPL-Lizenz läuft, kann es auch kommerziell genutzt 
werden.

Sobald Du die erste Million verdient hast, kannst Du mich gern mit 10% 
beteiligen ;-)

von Martin R. (m-joy)


Lesenswert?

Huhu, ich habe meine schaltung jetzt vom attiny88 auf den atmega88 
umgebaut. und siehe da es funktioniert ... super :)

aber eine sache funktioniert nicht, und zwar wenn ich am sender folgende 
routine benutze:
1
    for (VCount=0; VCount<=7; VCount++)
2
        {
3
    if( POSITION == VCount )
4
    {
5
    V=VCount;
6
    irmp_data.command  = VCount;    
7
    send=1;
8
    }
9
       }

dann funktioniert es mit diesem am empfänger:
1
  for (Vcommand=0; Vcommand<=7; Vcommand++)
2
       {
3
  if( irmp_data.command == Vcommand )
4
    {
5
    V=Vcommand;
6
    }
7
      
8
        }

ich möchte aber sehr viele IR codes benutzen und diese teilen,also 
dachte ich mir ich benutze 0x0A** für eine reihe, und 0x0B** (mit * von 
0-f) für die zweite reihe.
Jetzt habe ich beim sender eingegeben:

    for (VCount=0; VCount<=7; VCount++)
        {
    if( POSITION == VCount )
    {
    V=VCount;
    irmp_data.command  = (VCount + 0x0A00);
    send=1;
    }
       }

und dasselbe eben auch beim empfänger. wenn ich da einen wert aufaddiere 
dann geht es nicht mehr :( weiß jemand woran das liegen könnte...?

grüüße

von Martin R. (m-joy)


Lesenswert?

nach etwas rumprobieren bin ich auf die idee gekommen, dass es wohl 
probleme gibt bei den größeren werten....
wenn ich das command
0x0011 schicke, kann ich es emfpangen
bei 0x0101 klappts dann nicht mehr.... vielleicht liegts ja daran? wie 
kann das sein.... what is wrooong?
Ich benutze das NEC Protocol, der rest ist deaktiviert.


grüße

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Martin K. schrieb:
> wenn ich das command
> 0x0011 schicke, kann ich es emfpangen
> bei 0x0101 klappts dann nicht mehr.... vielleicht liegts ja daran? wie
> kann das sein.... what is wrooong?

Wenn Du unter

  http://www.mikrocontroller.net/articles/IRMP#Pulse-Distance_Protokolle

nachschaust, siehst Du, dass das NEC-Protokoll aus

  16 Bit Adresse + 8 Bit Kommando + 8 Bit invertiertes Kommando

besteht. Das NEC-Protokoll unterscheidet also nur 256 Kommandos. Damit 
geht Dein Wertebereich für irmp_data.command von 0x00 bis 0xff. Das 
Senden von 0x0101 ist also dasselbe wie das Senden von 0x0001, da IRSND 
die zusätzlichen Bits außerhalb des Wertebereichs einfach wegblendet.

> Ich benutze das NEC Protocol, der rest ist deaktiviert.

Versuche, mit 8 Bit hinzukommen oder wähle ein anderes Protokoll, wenn 
Du Daten übertragen willst.

Gruß,

Frank

P.S.

Ich verstehe Deine for-Schleifen nicht:

>  for (Vcommand=0; Vcommand<=7; Vcommand++)
>  {
>     if( irmp_data.command == Vcommand )
>     {
>         V=Vcommand;
>     }
>  }

Das kannst Du doch einfach als

     if( irmp_data.command <= 7 )
     {
         V=irmp_data.command;
     }

schreiben. Eine Schleife ist überhaupt nicht notwendig.

von Ephraim H. (ephi)


Lesenswert?

Hallo zusammen,

erstmal: ein grandioses Projekt!
Im wesentlichen funktioniert das bei mir auch grandios. Ich empfange die 
Volume +/- Befehle einer Apple Remote (die alte), um damit einen 
Motorpoti zu steuern. Das ganze werte ich wie folgt aus:
1
while(1)
2
    {
3
        irmp_get_data(&irmp_data);
4
        
5
        if(irmp_data.protocol == IRMP_APPLE_PROTOCOL)
6
        {
7
            // Volume up
8
            if((irmp_data.command&0x00FF) == 0x0B)
9
            {
10
                // Motor rechts
11
                PORTD |= (1<<PD5);
12
                PORTD &= ~(1<<PD6);
13
            }
14
            // Volume down
15
            else if((irmp_data.command&0x00FF) == 0x0D)
16
            {
17
                // Motor links
18
                PORTD |= (1<<PD6);
19
                PORTD &= ~(1<<PD5);
20
            }
21
            else
22
            {
23
            // Motor stop
24
            PORTD &= ~(1<<PD5);
25
            PORTD &= ~(1<<PD6);
26
            }
27
        }
28
    }
Funktioniert soweit prima, bis auf eine Kleinigkeit: Wenn ich einmal 
kurz Volume up oder down drücke, steht in irmp_data.command so lange 
dieser Befehl, bis ich einen anderen sende. D.h. ich muss irgendeine 
Taste drücken, um den Motor zu stoppen. Ist das ein Fehler? Oder muss 
ich irmp_data nach dem auslesen irgendwie bereinigen?

Gruß,
Ephraim

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Ephraim Hahn schrieb:
> Im wesentlichen funktioniert das bei mir auch grandios. Ich empfange die
> Volume +/- Befehle einer Apple Remote (die alte), um damit einen
> Motorpoti zu steuern. Das ganze werte ich wie folgt aus:
>
1
>     while(1)
2
>     {
3
>         irmp_get_data(&irmp_data);
4
>

Das ist falsch, Du musst den Rückgabewert prüfen. Wenn 0 zurückkommt, 
wurde nichts empfangen.

Also:
1
    while(1)
2
    {
3
        if (irmp_get_data(&irmp_data))
4
        {
5
            ... // hier Deinen restlichen Code einfügen
6
        }
7
    }

> Funktioniert soweit prima, bis auf eine Kleinigkeit: Wenn ich einmal
> kurz Volume up oder down drücke, steht in irmp_data.command so lange
> dieser Befehl, bis ich einen anderen sende. D.h. ich muss irgendeine
> Taste drücken, um den Motor zu stoppen. Ist das ein Fehler? Oder muss
> ich irmp_data nach dem auslesen irgendwie bereinigen?

Wie gesagt: Du musst den Rückgabewert prüfen. irmp_data wartet nicht, 
bis etwas empfangen wird, sondern kommt sofort zurück, wenn keine Daten 
anstehen. In diesem Fall steht natürlich noch das alte Zeugs in der 
Datenstruktur. Ein Zurücksetzen der Datenstruktur ist nicht notwendig, 
da die Daten valide sind, wenn irmp_get_data() TRUE zurückliefert.

Gruß,

Frank

von Ephraim H. (ephi)


Lesenswert?

ah okay, das macht Sinn. Probier ich nacher gleich aus, vielen Dank!

von Martin R. (m-joy)


Lesenswert?

ohhhjee ich idiot vielen dank.... naatürlich es gibt nur 8 command 
bit... :( ich habe das problem gelöst indem ich einfach zwei 
verschiedene adress bits genutzt habe ;)
vielen dank

p.s. die schleife muss man net verstehen G

von Ephraim H. (ephi)


Lesenswert?

Verzeihung, aber ich muss mich noch mal melden.
Konnte die Geschichte erst jetzt testen, da ich noch andere Hardware 
Probleme zu lösen hatte.

Dieser Code hier (wie oben) funktioniert, aber mit besagtem Problem, 
dass er nicht mehr aufhört, wenn ich einmal gedrückt habe, da ich den 
Rückgabewert von /irmp_get_data()/ nicht prüfe.
1
while(1)
2
    {
3
        irmp_get_data(&irmp_data);
4
 
5
            if(irmp_data.protocol == IRMP_APPLE_PROTOCOL)
6
            {
7
                // Volume up
8
                if((irmp_data.command&0x00FF) == 0x0B)
9
                {
10
                    // Motor rechts
11
                    PORTD |= (1<<PD5);
12
                    PORTD &= ~(1<<PD6);
13
                }
14
                // Volume down
15
                else if((irmp_data.command&0x00FF) == 0x0D)
16
                {
17
                    // Motor links
18
                    PORTD |= (1<<PD6);
19
                    PORTD &= ~(1<<PD5);
20
                }
21
                else
22
                {
23
                    // Motor stop
24
                    PORTD &= ~(1<<PD5);
25
                    PORTD &= ~(1<<PD6);
26
                }
27
            }
28
    }

Jetzt nehme ich die Überprüfung mit rein:
1
while(1)
2
    {
3
        if(irmp_get_data(&irmp_data))
4
        {
5
            if(irmp_data.protocol == IRMP_APPLE_PROTOCOL)
6
            {
7
                // Volume up
8
                if((irmp_data.command&0x00FF) == 0x0B)
9
                {
10
                    // Motor rechts
11
                    PORTD |= (1<<PD5);
12
                    PORTD &= ~(1<<PD6);
13
                }
14
                // Volume down
15
                else if((irmp_data.command&0x00FF) == 0x0D)
16
                {
17
                    // Motor links
18
                    PORTD |= (1<<PD6);
19
                    PORTD &= ~(1<<PD5);
20
                }
21
                else
22
                {
23
                    // Motor stop
24
                    PORTD &= ~(1<<PD5);
25
                    PORTD &= ~(1<<PD6);
26
                }
27
            }
28
        }
29
        else
30
        {
31
            // Motor stop
32
            PORTD &= ~(1<<PD5);
33
            PORTD &= ~(1<<PD6);
34
        }
35
    }

Und nun tut sich garnichts mehr. Habe ich irgendetwas übersehen?

von etMax (Gast)


Angehängte Dateien:

Lesenswert?

Hallo!

Ich stehe grade auf dem Schlauch: Ich versuche, die IRMP mit einem 
Atmega8 zum laufen zu bekommen.

Dazu habe ich einfach das aktuelle release genommen und 2 Zeilen 
eingefügt: der aktuell empfangene Command soll auf PortD ausgegeben 
werden.

Ich habe auf meinem STK600 den PORTD des Atmega8 mit den LEDs verbunden 
und den IR-Decoder an PB6 angeschlossen. Leider bleibt PORTD immer auf 
LOW.

Wenn ich PORTD = PINB; hinzufüge, sehe ich die LED an PD6 blinken, also 
das Signal kommt an.

Vielleicht kann sich das mal jemand anschauen, was das Problem ist? Ich 
hab den Quellcode beigelegt.

Vielen Dank und liebe Grüße,
etMax

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Ephraim Hahn schrieb:
>
1
while(1)
2
>     {
3
>         if(irmp_get_data(&irmp_data))
4
>         {
5
>             ....
6
>         }
7
>         else
8
>         {
9
>             // Motor stop
10
>             PORTD &= ~(1<<PD5);
11
>             PORTD &= ~(1<<PD6);
12
>         }
13
>     }
>
> Und nun tut sich garnichts mehr. Habe ich irgendetwas übersehen?

Ja, hast Du. Schau Dir mal obigen Code genauer an. Wenn irm_get_data() 
NICHTS empfängt, wird der else-Zweig durchlaufen und damit Dein Motor 
gestoppt. Denke daran: irmp_get_data() wartet NICHT. In 99,9995% der 
Zeit wird der else-Zweig durchlaufen und Dein Motor gestoppt.

Wenn Du mal was sendest, springt der Motor kurz an und wird danach 
direkt wieder gestoppt. Das ist so kurz, dass Du das gar nicht siehst.

Daher: Werfe den unteren else-Zweig komplett raus, also lass folgendes 
stehen:
1
   while(1)
2
   {
3
       if(irmp_get_data(&irmp_data))
4
       {
5
           if (...)
6
           {
7
               ...
8
           }
9
           else if (...)
10
           {
11
               ...
12
           }
13
           else // NUR HIER MOTORSTOPP!
14
           {
15
               ...
16
           }
17
       }
18
       // KEIN else!
19
   }

Die Volume-Tasten regeln dann den Links-/Rechtslauf, jede andere 
gedrückte Taste stoppt den Motor. Das ist vermutlich auch das, was Du 
haben möchtest.

Fazit: Wenn NICHTS empfangen wurde, dann auch NICHTS tun.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

etMax schrieb:

> Ich stehe grade auf dem Schlauch: Ich versuche, die IRMP mit einem
> Atmega8 zum laufen zu bekommen.

Hast Du die Fuses vom ATmega8 auch so angepasst, dass er mit 8 MHz läuft 
und nicht mit den werksseitig eingestellten 1 MHz?

Schau mal hier:

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

Gruß,

Frank

von Ephraim H. (ephi)


Lesenswert?

>
> Die Volume-Tasten regeln dann den Links-/Rechtslauf, jede andere
> gedrückte Taste stoppt den Motor. Das ist vermutlich auch das, was Du
> haben möchtest.
>
> Fazit: Wenn NICHTS empfangen wurde, dann auch NICHTS tun.
>
> Gruß,
>
> Frank

genau dieses Verhalten ergab sich ja bereits aus meiner allerersten 
Version. Was ich aber will, ist, den Motor nur zu bewegen solange die 
entsprechende Volume Taste gedrückt wird. Nun dachte ich, solange ich 
drücke, ist /irmp_get_data()/ positiv und liefert mir in der struct den 
Befehl. Kann es sein, da aber irmp_get_data() wesentlich öfter empfängt, 
als meine apple remote senden kann, und sich dadurch praktisch nichts 
bewegt, da der Motor stoppt, bevor er überhaupt angelaufen ist? In dem 
Fall müsste ich eine Art delay bzw. timeout für einen empfangenen befehl 
integrieren.

von etMax (Gast)


Lesenswert?

Frank M. schrieb:
> etMax schrieb:
>
>> Ich stehe grade auf dem Schlauch: Ich versuche, die IRMP mit einem
>> Atmega8 zum laufen zu bekommen.
>
> Hast Du die Fuses vom ATmega8 auch so angepasst, dass er mit 8 MHz läuft
> und nicht mit den werksseitig eingestellten 1 MHz?
>

Hallo,

ja, meine Fuses stehen auf e4 d9 . F_CPU ist auf 8000000 definiert und 
eine Lampe blinkt auch im Sekundentakt, wenn ich 10 mal 100ms delay 
zwischen den Blinkern mache.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Ephraim Hahn schrieb:
> Kann es sein, da aber irmp_get_data() wesentlich öfter empfängt,
> als meine apple remote senden kann, [...]

Ja, natürlich. Eine FB sendet ca. 10 Frames pro Sekunde. irmp_get_data 
wird aber wesentlich öfter mit FALSE zurückkommen.

Vorschlag der Lösung:

In der timer-ISR einen globalen Zähler hochzählen (static volatile 
uint16_t), diesen in den beiden if-Blöcken, wo Du tatsächlich 
Volume-UP/DOWN empfängst, auf 0 zurücksetzen. Im else-Block prüfen, ob 
ein bestimmer Wert des Zählers überschritten wurde. Dann hast Du Deinen 
Timeout und Du kannst den Motor stoppen.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

etMax schrieb:
> ja, meine Fuses stehen auf e4 d9 . F_CPU ist auf 8000000 definiert und
> eine Lampe blinkt auch im Sekundentakt, wenn ich 10 mal 100ms delay
> zwischen den Blinkern mache.

Welche Fernbedienungen hast Du ausprobiert?

Ich sehe, dass Du in irmpconfig.h lediglich die Standsrd-Protokolle 
aktiviert hast, die ich als wichtig empfinde. Aktiviere bitte auch mal 
RC5, RC6, NEC16, NEC42, GRUNDIG, SIEMENS, NOKIA - also alles, was unter 
"more protocols" steht. Die "exotic protocols" lasse erstmal weg.

Gruß,

Frank

von M. K. (kichi)


Lesenswert?

Ich habe mir nicht den ganzen Thread durchgelesen: hat schon jemand das 
Projekt inkl. IRSND auf einen ARM (STM32) portiert?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Michael K. schrieb:
> Ich habe mir nicht den ganzen Thread durchgelesen: hat schon jemand das
> Projekt inkl. IRSND auf einen ARM (STM32) portiert?

Schau Dir mal Beitrag "Re: IRMP - Infrared Multi Protocol Decoder" an.

von M. K. (kichi)


Lesenswert?

Hast du das implementiert oder muss speziell diese Version genommen 
werden? Und wie steht es mit IRSND?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Michael K. schrieb:
> Hast du das implementiert oder muss speziell diese Version genommen
> werden? Und wie steht es mit IRSND?

Nein, habe ich nicht implementiert. Aber wenn Du Dir die Unterschiede 
durch Suchen nach IRMP_FLEXIBLE_VERSION anschaust, siehst Du, dass Jan 
neben einigen kosmetischen Sachen (die so für den ARM nicht existieren) 
lediglich das Interface der Funktion irmp_ISR() geändert hat, um den 
IRMP-Source komplett hardwareunabhängig zu machen.

Über den hardware-abhängigen Teil

  1) wie lese ich einen PIN?

  2) wie rufe ich irmp_ISR() 10000 mal (oder 15000 mal) pro Sekunde auf?

schweigen sich seine Source-Änderungen leider aus. Da ich selber mit ARM 
noch nichts gemacht habe, kann ich Dir da auch nicht weiterhelfen. Aber 
eigentlich musst Du nur die beiden obigen Punkte klären, das ist alles. 
Dann kann man das auch in den aktuellen IRMP integrieren.

Punkt 1) ist simpel: Schreibe in irmpconfig.h ein Macro namens input().
Punkt 2) ist auch nicht viel schwieriger: Schreibe eine Funktion 
timer_init() und sorge damit dafür, dass irmp_ISR() 15000 mal pro 
Sekunde aufgerufen wird.

Wie Du siehst, ist das nicht schwierig. Wenn Du Dich einigermaßen mit 
ARM-Programmierung auskennst, solltest Du das hinbekommen. Deine 
Source-Anpasssungen baue ich gern in den IRMP ein.

Gruß,

Frank

von M. K. (kichi)


Lesenswert?

Frank M. schrieb:
> Punkt 1) ist simpel: Schreibe in irmpconfig.h ein Macro namens input().
> Punkt 2) ist auch nicht viel schwieriger: Schreibe eine Funktion
> timer_init() und sorge damit dafür, dass irmp_ISR() 15000 mal pro
> Sekunde aufgerufen wird.
Werde ich tun. Ich komme dann nochmal auf dich zu.

Wie sieht ist es mit der Hardwareunabhängigkeit von IRSND aus? Du nutzt 
doch den Timer 2 dafür, oder?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Michael K. schrieb:
> Werde ich tun. Ich komme dann nochmal auf dich zu.

Prima, bin gespannt.

> Wie sieht ist es mit der Hardwareunabhängigkeit von IRSND aus? Du nutzt
> doch den Timer 2 dafür, oder?

IRSND benutzt (genauso wie IRMP) einmal den Timer 1 (irsnd_ISR()) und 
zusätzlich den Timer 2 für die Erzeugung der Modulationsfrequenz. Bei 
den ATtinys ist es stattdessen der Timer 0, siehe irsndconfig.h.

Gruß,

Frank

von etMax2 (Gast)


Lesenswert?

Frank M. schrieb:
> Welche Fernbedienungen hast Du ausprobiert?
>
> Ich sehe, dass Du in irmpconfig.h lediglich die Standsrd-Protokolle
> aktiviert hast, die ich als wichtig empfinde. Aktiviere bitte auch mal
> RC5, RC6, NEC16, NEC42, GRUNDIG, SIEMENS, NOKIA - also alles, was unter
> "more protocols" steht. Die "exotic protocols" lasse erstmal weg.

Oh je, ich bin ja ein Idiot...
Ich habe eine RC5-Fernbedienung und war mir sicher, dass RC5 zu den 
Standard-Protokollen gehört...
Danke fürs Drüberschauen, Frank! Jetzt klappt es einwandfrei!

etMax

von Martin (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

ich versuche gerade eine 44-Tasten-RGB-Fernbedienung eines 5m
LED-Streifens am Atmega88 zum laufen zu kriegen, bis jetzt ohne Erfolg. 
Der RGB Streifen wurde
in der Bucht gekauft und beinhaltet bereits einen Controller und eine
Fernbedienung.

Das IR-Protokoll ist das NEC-Protokoll. Im Anhang habe ich das Timing
für die "Rot"-Taste.
In der IRMPconfig.h wurde nur das NEC-Protokoll aktiviert und der Pin 
für den Empfänger auf PB.5 gesetzt.

Der Atmega88 wurde, wie in der main.c beschrieben, für interne 8MHz
gefused. Für die Übertragung der "Rot"-Taste habe ich folgende Werte
erhalten:

Startbit > 0x00 (Adressbyte) > 0xFF (inv. Adressbyte) > 0x1A
(Commandbyte) > 0xE5 (inv. Commandbyte) > Stopbit

Könnt ihr bitte mal über meine Switch-Case-Anweisung drüber schauen, ob
die Abfrage des irmp_data.command richtig ist?
1
int
2
main (void)
3
{
4
    IRMP_DATA irmp_data;
5
6
    irmp_init();                                                            // initialize irmp
7
    timer1_init();                                                          // initialize timer 1
8
    sei ();                                                                 // enable interrupts
9
10
  DDRC |= (1 << DDC1) | (1 << DDC2) | (1<<DDC3);
11
12
    for (;;)
13
    {
14
        if (irmp_get_data (&irmp_data))
15
        {
16
            //if (irmp_data.protocol == IRMP_NEC_PROTOCOL)// &&     // NEC-Protokoll
17
        //irmp_data.address == 0x00FF)                   // Adresse 0x1234
18
        //{
19
          switch (irmp_data.command)
20
          {
21
            case 0x9A65: PORTC|=(1<<PC1); break;          // Taste grün
22
            case 0x18E7: PORTC|=(1<<PC2); break;          // Taste gelb
23
            case 0x1AE5: PORTC|=(1<<PC3); break;          // Taste rot
24
          }
25
  }
26
    }
27
}

Gruß Martin

von Martin (Gast)


Lesenswert?

Jetzt hab ichs. Ich darf nur das 8-Bit-Commandbyte verwenden. Jetzt 
gehts:-) Das IRMP ist ein Spitzenprojekt!!:-) Danke Frank für dieses 
Projekt.

Frohe Ostern

von Ulli -. (ulli2k)


Lesenswert?

Hallo zusammen,

Ich habe die Library IRMP und IRSND schon mit Erfolg auf einem Atmega8
anwenden können. Dafür erstmal ein dickes Lob für die tolle Lib.

Jetzt habe ich nur das Problem, dass ich an dem Atmega8 die SPI
Schnittstelle dringend benötige. Leider liegt der PWM Pin für die IRSND
Funktion auf dem MOSI Pin PB3. Ist es möglich diesen auf den PB1 (OC1A)
zu verschieben um die SPI Schnittstelle zu nutzen?

Seht ihr da eine Möglichkeit?

von Graf-von-Socke (Gast)


Lesenswert?

hallo zusammen
ich möchte gernen meine digicam über infarot ansteuern und habe da 
folgendes gefunden

begin remote

  name  Olympus_RM-1
  bits           16
  flags SPACE_ENC|CONST_LENGTH
  eps            30
  aeps          100

  header       8853  4489
  one           559  1670
  zero          559   555
  ptrail        559
  repeat       8853  2259
  pre_data_bits   16
  pre_data       0x61DC
  gap          107013
  toggle_bit      0


      begin codes
          capture                  0x000000000000807F
          w                        0x00000000000040BF
          t                        0x000000000000C03F
          -                        0x00000000000020DF
          +                        0x000000000000A05F
      end codes

end remote

wie muss ich das nun verstehen und wie muss ich das auf irsend anwenden

mfg

Graf-von-Socke

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Graf-von-Socke schrieb:

> begin remote

Ich vermute mal, dass das eine lirc-Berschreibungsdatei ist? Ich kenne 
mich damit nicht so aus, aber ich versuche mal zu deuten:

>   bits           16

16 Datenbits.

>   header       8853  4489

Das ist ein offenbar vom Timing ein NEC-Startbit, siehe auch:

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

>   one           559  1670
>   zero          559   555

Das sieht ebenso nach NEC-Timing aus.

>   ptrail        559

Könnte das Stoppbit sein.

>   pre_data_bits   16

16 bits vor den Datenbits, scheint die NEC-Adresse zu sein.

>   pre_data       0x61DC

0x61DC ist offenbar die Adresse.

>           capture                  0x000000000000807F
>           w                        0x00000000000040BF
>           t                        0x000000000000C03F
>           -                        0x00000000000020DF
>           +                        0x000000000000A05F

Das scheinen die Kommando-Codes zu sein.

> wie muss ich das nun verstehen und wie muss ich das auf irsend anwenden

Also probiere es mal mit
1
  IRMP_DATA irmp_data;
2
  ...
3
4
  irmp_data.protocol = IRMP_NEC_PROTOCOL;
5
  irmp_data.address  = 0x61DC;       // address of camera
6
  irmp_data.protocol = 0x40BF;       // command "w"
7
  irmp_data.flags    = 0x00;         // reset flags
8
  irsnd_send_data (&irmp_data);      // send data

Gruß,

Frank

von Ulli -. (ulli2k)


Lesenswert?

hat keiner eine Vorstellung, ob man den IRSEND Pin bei einem Atmega8 von 
PB3 auf PB1 ändern kann und wenn ja wie?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Ulli -- schrieb:
> hat keiner eine Vorstellung, ob man den IRSEND Pin bei einem Atmega8 von
> PB3 auf PB1 ändern kann und wenn ja wie?

IRSND benötigt den Timer1 bereits für das periodische Aufrufen der 
15kHz-ISR. Wenn Du die ISR über einen anderen Timer laufen lässt, kannst 
Du natürlich IRMP anpassen an OC1A (PB1). Dazu musst Du allerdings den 
Code erweitern.

IRMP benutzt den Timer0 bzw. Timer2 zur Erzeugung der 
Modulationsfrequenz per PWM. Der veraltete ATmega8 ist da ziemlich 
beschränkt. Wenn Du ihn gegen den moderneren ATmega88 tauschst, hast Du 
die Wahl zwischen OC2A (PB3) und OC2B (PD3), ohne den IRSND-Code 
erweitern zu müssen.

Gruß,

Frank

von Ulli -. (ulli2k)


Lesenswert?

Frank: D.h. ja, mit einem Atmega8 kann ich IRMP und IRSND nicht 
gleichzeitig mit der SPI Schnittstelle benutzen, da die Timer nicht 
ausreichen? Auch nicht mit Code Erweiterung?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Ulli -- schrieb:
> Frank: D.h. ja, mit einem Atmega8 kann ich IRMP und IRSND nicht
> gleichzeitig mit der SPI Schnittstelle benutzen, da die Timer nicht
> ausreichen? Auch nicht mit Code Erweiterung?

Mit Code-Erweiterung gehts auch mit einem ATmega8.

Dann benutzt Du halt Timer 0 oder Timer 2 zum Aufruf der ISR mit 15kHz 
und verwendest Timer1 (und damit OC1A = PB1) als Sender-Ausgang. Aber 
die PWM-Routinen für die Modulation des Timer 1 musst Du dann neu 
schreiben, die habe ich nur für Timer 0 oder Timer 2 implementiert.

von eku (Gast)


Lesenswert?

Hallo Frank,

mein IRMP hat NEC, RC5, DENON, NUBERT, GRUNDIG, NOKIA, SIEMENS und FDC 
einkompiliert und tastet mit 15kHz ab. Kürzlich habe ich von Revision 71 
auf 95 aktualisiert und nun funktioniert die Erkennung nicht:

* DENON wird nur noch sporadisch erkannt
* RUWIDO wird erkannt obwohl nicht einkompiliert, z.B. bei DENON 
Signalen
* SIEMENS werden nicht mehr alle Tasten erkannt
* die FB meines SHARP (siehe Beiträge Januar 2011) wird nicht mehr 
erkannt

Meine zugelieferten Scans liegen in IR-Data und ich nehme an, dass Du 
alle
nach Änderungen am Quellcode testest. Anscheinend macht es aber die 
Kombination der aktivierten Protokolle. Welche Deiner Änderungen könnte 
für meine Probleme verantwortlich sein?

Gruß, eku

von Christian R. (idl0r)


Lesenswert?

hm, passt vielleicht nicht ganz zum thema aber trotzdem.. ich habe 
einige schaltungen mit 2 TSOPs gesehen, bringt das tatsaechlich was? 
wenn beide versetzt voneinander angeordnet sind ok.. aber 
ueber/nebeneinander?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Christian Ruppert schrieb:
> hm, passt vielleicht nicht ganz zum thema aber trotzdem.. ich habe
> einige schaltungen mit 2 TSOPs gesehen, bringt das tatsaechlich was?
> wenn beide versetzt voneinander angeordnet sind ok.. aber
> ueber/nebeneinander?

Vielleicht arbeiten beide mit unterschiedlichen Modulationsfrequenzen?

von jar (Gast)


Lesenswert?

eku schrieb:
> Kürzlich habe ich von Revision 71
> auf 95 aktualisiert und nun funktioniert die Erkennung nicht:
>
> * DENON wird nur noch sporadisch erkannt

so was ähnliches ist mir auch ab und an mal aufgefallen,
habe alles aktiviert was <=15kHz ist und bekam für eine Kaseikyo alles 
von Siemens bis RUWIDO je nach Tastendrück

habe nun wieder die aktuelle in meine SW eingepflegt

 * $Id: irmp.h,v 1.73 2012/02/24 15:00:18 fm Exp $

und prompt kommt wieder der Fehler:
../irmp.h:489:1: warning: "TRUE" redefined

ich mag nun nicht jedesmal suchen wo das herkommt
wäre folgendes nicht sinnvoll ?

#ifndef FALSE
  #define FALSE 0
#endif
#ifndef TRUE
  #define TRUE !FALSE
#endif

hatte ich auch in der letzten eingebauten Version nachgerüstet, aber 
jedesmal nachfummeln ist irgendwie unnötig zeitraubend

von jar (Gast)


Lesenswert?

Korrektur zur Erkennung

umstellen mit rc5_ISR(); nach (void) irmp_ISR();

half für bessere Erkennung

ändert aber nix am redefine TRUE FALSE Problem





  if (! irsnd_ISR())         // call irsnd ISR
  {                          // if not busy...
    (void) irmp_ISR();      // call irmp 3-16µs
    (void) rc5_ISR();      // call rc5 8-10µs
    }

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:
> mein IRMP hat NEC, RC5, DENON, NUBERT, GRUNDIG, NOKIA, SIEMENS und FDC
> einkompiliert und tastet mit 15kHz ab. Kürzlich habe ich von Revision 71
> auf 95 aktualisiert und nun funktioniert die Erkennung nicht:
>
> * DENON wird nur noch sporadisch erkannt
> * RUWIDO wird erkannt obwohl nicht einkompiliert, z.B. bei DENON
> Signalen
> [...]

Ich habe probeweise IRMP mit obigen Protokollen übersetzt und dann gegen 
IR-Data/denon-15kHz.txt laufen lassen... keine Probleme bei der 
Erkennung.

> Meine zugelieferten Scans liegen in IR-Data und ich nehme an, dass Du
> alle
> nach Änderungen am Quellcode testest.

Ja, ich checke sie immer mit test-suite.sh. Das Script schaltet alle 
Protokolle frei und lässt den generierten IRMP gegen die im Shell-Script 
aufgeführten Scan-Dateien laufen. Nur wenn diese fehlerfrei durchgehen, 
gebe ich eine Version frei. Natürlich ist mit diesem Check lediglich 
eine notwendige Bedingung für Fehlerfreiheit gegeben, aber nicht 
unbedingt eine hinreichende.

> Anscheinend macht es aber die
> Kombination der aktivierten Protokolle. Welche Deiner Änderungen könnte
> für meine Probleme verantwortlich sein?

Keine Ahnung. Nenne mir bitte die Scan-Dateien unter IR-Data, die von 
Dir sind. Dann kann ich diese nochmal gezielt in Deiner Kombination 
testen.

Gruß,

Frank

von finnjet (Gast)


Lesenswert?

Ich stehe zur Zeit vor einem ähnlichen Problem, indem ich für einen 
Kenwood Receiver eine Ansteuerung implementieren möchte.  Es existiert 
eine LIRC Konfiguration, die auch funktioniert:
http://lirc.sourceforge.net/remotes/kenwood/RC-R0813

begin remote

  name  Kenwood_RC-R0813
  bits           24
  flags SPACE_ENC|CONST_LENGTH
  eps            30
  aeps          100

  header       9065  4480
  one           580  1660
  zero          580   550
  ptrail        580
  repeat       9060  2230
  pre_data_bits   8
  pre_data       0x1D
  gap          108434
  toggle_bit      0


      begin codes
        power       0x00B946
        thx         0x8043BC
        listenmodeup 0x00fb04
        listenmodedown 0xe0f807
        activeeq    0x60e21d
        speakereq   0x60926d
        inputmode   0x20f906
        dspmode     0x8030cf
        mute        0x0039c6
        stereo      0x00eb14
        vol+        0x00d926
        vol-        0x0059a6
        setup       0xc09867
        sound       0x80ea15
        up          0x80aa55
        down        0x802ad5
        left        0x4000ff
        right       0x40807f
        tunerev     0x4040bf
        tunefwd     0x40c03f
        flip        0xc0906f
        band        0xc0609f
        inputsel    0xc06a95
        a/b         0x0010ef
        auto        0x4020df
        dimmer      0x40b847
        dvd6ch      0xc001fe
        cd/dvd      0x0049b6
        phono       0x0009f6
        tuner       0x008976
        video1      0x006996
        video2      0x0040bf
        video3      0xc0b847
        md/tape     0x00a956
        avaux       0x00c936
        loudness    0x00fa05
        tone        0x80AB54
        bass        0x40EA15


        1       0x00817E
        2       0x0041be
        3       0x00c13e
        4       0x0021de
        5       0x00a15e
        6       0x00619e
        7       0x00e11e
        8       0x0011ee
        9       0x00916e
        0       0x0001fe
        +10     0x00b04f
        +100    0x40f20d


      end codes

end remote

von finnjet (Gast)


Lesenswert?

...Sorry! ich wollte nicht die ganze Datei posten!

Die Lirc Remote files sind ja sehr hilfreich, leider habe ich bislang 
keine ausführliche Beschreibung des Formats gefunden.

Meine Frage dazu ist folgende: 24 Daten Bits + 8 Pre-data (address?) 
Bits scheint mir ja weder das normale NEC noch NEC48 Protokoll zu sein. 
Die Timings sehen dagegen recht passend aus.

Sehe ich es richtig, dass ich mir hier gewissermaßen ein NEC36 
implementieren muss?

Gruß

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

finnjet schrieb:

> Meine Frage dazu ist folgende: 24 Daten Bits + 8 Pre-data (address?)
> Bits scheint mir ja weder das normale NEC noch NEC48 Protokoll zu sein.
> Die Timings sehen dagegen recht passend aus.

Stimmt, diese sehen tatsächlich passend aus. Schalte einfach 
IRMP_LOGGING in irmpconfig.h ein, scanne die Tasten 0...9 ein und poste 
hier die Text-Datei. Ich baue das Protokoll dann ein. Den Aufbau der 
Scan-Datei siehst Du auch als Beispiele unter IR-Data/*.txt. Kommentare 
mit # eingeleitet wären hilfreich.

Hast Du denn schon mal Deine FB mit IRMP getestet?

Gruß,

Frank

von Hans W. (stampede)


Lesenswert?

Hallo Frank,

ich möchte einfach mal "DANKE" sagen für dieses hervorragende Projekt. 
Gut dokumentiert, innerhalb von 30min in meinen Code eingebunden und für 
den verwendeten PIC32 portiert. Lief auf Anhieb, so soll es sein.

Grüße
Stampede

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Hans,

Hans W. schrieb:

> ich möchte einfach mal "DANKE" sagen für dieses hervorragende Projekt.
> Gut dokumentiert, innerhalb von 30min in meinen Code eingebunden und für
> den verwendeten PIC32 portiert. Lief auf Anhieb, so soll es sein.

Erstmal Danke fürs "Danke" ;-)

Ist bei Deiner Portierung vielleicht irgendetwas wichtiges, das in den 
allgemeinen Source zurückfließen sollte?

Gruß,

Frank

von jar (Gast)


Lesenswert?

Frank M. schrieb:
> vielleicht irgendetwas wichtiges, das in den
> allgemeinen Source zurückfließen sollte?

möglicherweise in:

irmp.h:489:1: warning: "TRUE" redefined

ich mag nun nicht jedesmal suchen wo das herkommt
wäre folgendes nicht sinnvoll ?

#ifndef FALSE
  #define FALSE 0
#endif
#ifndef TRUE
  #define TRUE !FALSE
#endif

oder lag der Fehler bei mir ?

ansonsten, auch von mir noch mal ein Riesen DANKE

auch wenn ich momentan nicht weiterkomme in der ausschliesslichen 
Nutzung von IRMP allone, in der Verbindung mit "meinen" alten RC5 
Auswertecode tuts ganz hervorragend :-)

alle Versuche das change key bit vom RC5 in IRMP zu generieren sind bis 
jetzt fehlgeschlagen, aber macht nix, irgendwann finde(t) ich (sich) ne 
Lösung
jar

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

jar schrieb:
> möglicherweise in:
>
> irmp.h:489:1: warning: "TRUE" redefined

Es gibt im IRMP-Source ausschließlich diese Stelle. Das redefine ist 
eine Folge einer TRUE-Definition, die aus Deinem Source kommt.

Sagt der Compiler nicht, wo die ursprüngliche Definition steht?

> ich mag nun nicht jedesmal suchen wo das herkommt
> wäre folgendes nicht sinnvoll ?
>
> #ifndef FALSE
>   #define FALSE 0
> #endif
> #ifndef TRUE
>   #define TRUE !FALSE
> #endif

Könnte ich machen, aber theoretisch gibt es ja tausend Möglichkeiten 
solcher Konflikte.

Gruß,

Frank

von jar (Gast)


Lesenswert?

Frank M. schrieb:
> Es gibt im IRMP-Source ausschließlich diese Stelle. Das redefine ist
> eine Folge einer TRUE-Definition, die aus Deinem Source kommt.

die ich bestimmt auch brauche an der Stelle ;-)

klaro um das abzukürzen suche ich alle meine TRUE def und bau das bei 
mir ein

dann muss das in IRMP.H nicht geändert werden, sollte auch klappen 
(hoffe ich)

danke
jar

PS. da IRMP aber immer in andere Projekte integriert wird ist es nicht 
auszuschliessen das man immer wieder drüber stolpert, also so dumm ist 
mein Gedanke nicht das auch in irmp.h einzubauen

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

jar schrieb:
> PS. da IRMP aber immer in andere Projekte integriert wird ist es nicht
> auszuschliessen das man immer wieder drüber stolpert, also so dumm ist
> mein Gedanke nicht das auch in irmp.h einzubauen

Ich habe es jetzt so geändert:
1
#ifndef TRUE
2
#define TRUE                                    1
3
#define FALSE                                   0
4
#endif

Kommt mit dem nächsten Release.

von jar (Gast)


Lesenswert?

Frank M. schrieb:
> #ifndef TRUE
> #define TRUE                                    1
> #define FALSE                                   0
> #endif
>
> Kommt mit dem nächsten Release

Klasse, braucht man nicht mehr zusätzlich Hand anzulegen beim Einbau !

danke
jar

von Sebastian (Gast)


Lesenswert?

Hallo zusammen,

ich hab ja mittlerweile IRMP auf einem PIC16F917 (mit CCS Compiler (auch 
so'n Kandidat für dreckstool.de)) zum laufen bekommen. Der PIC läuft mit 
20Mhz und die ISR mit 9,766kHz. Ich kann also die IR Signale decodieren, 
und die sehen auch plausibel aus. Nun dachte ich, dass das Senden 
deutlich einfacher ist, aber das will einfach nicht laufen. Die 
Schaltung und die Bauteile des Sendezweigs sind nach dem Artikel 
aufgebaut. Ich hab schon folgende Dinge überprüft:
 - 36/38kHz Trägerfrequenz --> gemessen mit Multimeter 35.95/38.15kHz 
duty cycle jeweils 49.6%. Sieht auf'm Scope eigentlich auch gut aus.
 - ein/ausschalten der PWM passt auch
 - ich hab mir das binär Signal zu einem empfangen Kommando mit irsnd 
erzeugt und sende das direkt aus einem Puffer. Der IR-Receiver am PIC 
empfängt auch genau dieselbe Bitfolge.

Bin gerade etwas ratlos. Hat vielleicht noch jemand nen heißen Tipp für 
mich?

Viele Grüße
Sebastian

von Sebastian .. (zahlenfreak)


Lesenswert?

Hallo Frank,

ich hab da ein etwas seltsames Problem mit IRMP:

Die meiste Zeit läuft alles einwandfrei. Nur manchmal kommt es vor, dass 
eine Taste reproduzierbar andere Daten liefert als normalerweise. Das 
hält dann so lange an, bis ich wieder eine andere Taste gedrückt habe, 
danach gehen wieder alle wie gewohnt.

Von dem Fehler sind mehrere (alle?) Tasten meiner FB betroffen.
Der (falsche) Code, den IRMP ausgibt, wenn der Fehler auftritt, scheint 
dann erstmal immer der gleiche zu sein, konnte das aber noch nicht 
verifizieren. Es ist aber auf jeden Fall nicht bei jeder Taste der 
gleiche.

Meine Ferbedienung ist eine DENON RC-176, definitiv aufgetreten ist der 
Bug bei
Protocol 8
Address 4
Command 1E8 und 0E8

Bei anderen Tasten auch, aber da müsste ich die richtigen Codes erst 
wieder raussuchen.

Hatte auch schon überlegt, ob vielleicht die Fernbedienung einen Bug 
hat, aber eine andere mit NEC-protocol zeigt das gleiche Verhalten, wenn 
auch deutlich schwerer zu provozieren.

Ich weiß momentan nicht so recht weiter. In meiner Software hab ich 
nichts gefunden, zumal ich den Bug auch schon in zwei Projekten hatte.

Vielleicht hat hier ja jemand eine Idee, was das sein könnte. Bei Bedarf 
mach ich natürlich gerne noch weitere Versuche.

Viele Grüße,
Sebastian

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Sebastian schrieb:
> ich hab ja mittlerweile IRMP auf einem PIC16F917 (mit CCS Compiler (auch
> so'n Kandidat für dreckstool.de)) zum laufen bekommen. Der PIC läuft mit
> 20Mhz und die ISR mit 9,766kHz. Ich kann also die IR Signale decodieren,
> und die sehen auch plausibel aus.

Welches IR-Protokoll?

> Nun dachte ich, dass das Senden
> deutlich einfacher ist, aber das will einfach nicht laufen. Die
> Schaltung und die Bauteile des Sendezweigs sind nach dem Artikel
> aufgebaut. Ich hab schon folgende Dinge überprüft:
>  - 36/38kHz Trägerfrequenz --> gemessen mit Multimeter 35.95/38.15kHz
> duty cycle jeweils 49.6%. Sieht auf'm Scope eigentlich auch gut aus.
>  - ein/ausschalten der PWM passt auch
>  - ich hab mir das binär Signal zu einem empfangen Kommando mit irsnd
> erzeugt und sende das direkt aus einem Puffer. Der IR-Receiver am PIC
> empfängt auch genau dieselbe Bitfolge.

Es lässt sich mit IRMP auch wieder dekodieren?

Es kann sein, dass der Original-Empfänger vom Timing her empfindlicher 
ist als IRMP, welcher auch noch bei größeren zeitlichen Abweichungen das 
Signal noch erkennt.

Ein IRMP-Scan (siehe auch IR-Data/*.txt) von der Original-FB wäre nicht 
schlecht.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Sebastian ... schrieb:
> ich hab da ein etwas seltsames Problem mit IRMP:
>
> Die meiste Zeit läuft alles einwandfrei. Nur manchmal kommt es vor, dass
> eine Taste reproduzierbar andere Daten liefert als normalerweise.

Wie sehen die Daten bzgl. Protokollnr, Adresse und Kommando-Code vorher 
und nachher aus?

> Das
> hält dann so lange an, bis ich wieder eine andere Taste gedrückt habe,
> danach gehen wieder alle wie gewohnt.

Das hört sich so an, als ob irgendetwas in der Statemachine nicht 
korrekt zurückgesetzt wird.

Hilfreich wäre ein IRMP-Scan mit einer Tastenfolge, wo der Fehler 
auftritt. Dann müsste ich das unter Linux reproduzieren können.

> Meine Ferbedienung ist eine DENON RC-176, definitiv aufgetreten ist der
> Bug bei
> Protocol 8
> Address 4
> Command 1E8 und 0E8

Das oben ist der korrekte? Wie sieht der fehlerhafte Code aus?

> Ich weiß momentan nicht so recht weiter. In meiner Software hab ich
> nichts gefunden, zumal ich den Bug auch schon in zwei Projekten hatte.

Gibt es außer IRMP noch weitere Software-Module, die in beiden Projekten 
stecken?

Ich bräuchte da Scans... sonst kann ich Dir wahrscheinlich nicht helfen.

von Sebastian (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Frank,

anbei die Scans von den beiden Fernbedienungen (Denon RC-1016, Toshiba 
CT-90327). Ich habe mir allerdings selbst eine ISR geschrieben, die die 
Pulslänge misst. Vielleicht fällt dir ja noch was auf.

Viele Grüße
Sebastian

von jar (Gast)


Lesenswert?

Sebastian schrieb:
> Der PIC läuft mit
> 20Mhz und die ISR mit 9,766kHz.

ist unter 10 kHz nicht etwas knapp ?
ich denke IRMP will als minimum 10kHz ?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Sebastian,

Sebastian schrieb:

> anbei die Scans von den beiden Fernbedienungen (Denon RC-1016, Toshiba
> CT-90327). Ich habe mir allerdings selbst eine ISR geschrieben, die die
> Pulslänge misst. Vielleicht fällt dir ja noch was auf.

Beide Scans lassen sich einwandfrei decodieren, auch wenn ich sagen 
muss, dass die 9766Hz beim Denon-Protokoll schon arg knapp sind.
1
# ./irmp  <rx_denon_9766Hz.txt
2
-------------------------------------------------------------------
3
#1
4
010001000111100
5
010000111000011 p =  8, a = 0x0008, c = 0x023c, f = 0x00
6
-------------------------------------------------------------------
7
#2
8
010001000111100
9
010000111000011 p =  8, a = 0x0008, c = 0x023c, f = 0x00
10
-------------------------------------------------------------------
11
#3
12
010001000111100
13
010000111000011 p =  8, a = 0x0008, c = 0x023c, f = 0x00
14
-------------------------------------------------------------------
15
#4
16
010001000111100
17
010000111000011 p =  8, a = 0x0008, c = 0x023c, f = 0x00
18
-------------------------------------------------------------------
19
#5
20
010001000111100
21
010000111000011 p =  8, a = 0x0008, c = 0x023c, f = 0x00
22
23
24
# ./irmp-20kHz < rx_test_19990Hz.txt
25
-------------------------------------------------------------------
26
#1 denon vol+
27
010001000111100
28
010000111000011 p =  8, a = 0x0008, c = 0x023c, f = 0x00
29
-------------------------------------------------------------------
30
#2 denon vol+
31
010001000111100
32
010000111000011 p =  8, a = 0x0008, c = 0x023c, f = 0x00
33
-------------------------------------------------------------------
34
#3 denon vol+
35
010001000111100
36
010000111000011 p =  8, a = 0x0008, c = 0x023c, f = 0x00
37
-------------------------------------------------------------------
38
#4 nec vol+
39
00000010111111010101100010100111 p =  2, a = 0xbf40, c = 0x001a, f = 0x00
40
-------------------------------------------------------------------
41
#5 nec vol+
42
00000010111111010101100010100111 p =  2, a = 0xbf40, c = 0x001a, f = 0x00
43
-------------------------------------------------------------------
44
#6 nec vol+
45
00000010111111010101100010100111 p =  2, a = 0xbf40, c = 0x001a, f = 0x00

Zu rx_denon_9766Hz.txt:

Du hast bei #1 bis #5 immer dieselbe Taste gedrückt, oder?

Zu rx_test_19990Hz.txt: auch kein Problem.

Wenn ich Dein vorhergendes Posting richtig verstanden habe, hast Du 
lediglich ein Problem beim Senden dieser Codes mittels IRSND.

Wenn ich den Output von IRSND in den IRMP mittels Unix-Pipe schicke, 
klappt alles sauber:
1
# ./irsnd 8 0008 023c 0 | ./irmp
2
010001000111100
3
010000111000011 p =  8, a = 0x0008, c = 0x023c, f = 0x00
4
5
# ./irsnd-20kHz 8 0008 023c 0 | ./irmp-20kHz
6
010001000111100
7
010000111000011 p =  8, a = 0x0008, c = 0x023c, f = 0x00
8
9
# ./irsnd-20kHz 2 bf40 001a 0 | ./irmp-20kHz
10
00000010111111010101100010100111 p =  2, a = 0xbf40, c = 0x001a, f = 0x00

Vergleich des IRSND-Outputs mit Deiner Text-Datei:
1
# ./irsnd-20kHz 2 bf40 001a 0 
2
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111000000000001111111111100000000000111111111110000000000011111111111000000000001111111111100000000000111111111110000000000011111111111000000000001111111111111111111111111111111111000000000001111111111100000000000111111111111111111111111111111111100000000000111111111111111111111111111111111100000000000111111111111111111111111111111111100000000000111111111111111111111111111111111100000000000111111111111111111111111111111111100000000000111111111111111111111111111111111100000000000111111111110000000000011111111111111111111111111111111110000000000011111111111000000000001111111111111111111111111111111111000000000001111111111100000000000111111111111111111111111111111111100000000000111111111111111111111111111111111100000000000111111111110000000000011111111111000000000001111111111100000000000111111111111111111111111111111111100000000000111111111110000000000011111111111111111111111111111111110000000000011111111111000000000001111111111100000000000111111111111111111111111111111111100000000000111111111111111111111111111111111100000000000111111111111111111111111111111111100000000000111111111...
3
# tail -1 rx_test_19990Hz.txt
4
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000011111111111111111111111111111111111111111111111111111111111111111111111111111111111111110000000000000111111111100000000000011111111110000000000000111111111100000000000001111111110000000000000111111111100000000000001111111110000000000000111111111111111111111111111111110000000000000111111111100000000000011111111111111111111111111111111100000000000011111111111111111111111111111111000000000000011111111111111111111111111111111000000000000011111111111111111111111111111111000000000000011111111111111111111111111111111000000000000011111111111111111111111111111111000000000000111111111100000000000001111111111111111111111111111111100000000000001111111110000000000000111111111111111111111111111111110000000000000111111111100000000000011111111111111111111111111111111100000000000011111111111111111111111111111111000000000000011111111110000000000000111111111000000000000011111111110000000000000111111111111111111111111111111110000000000001111111111000000000000011111111111111111111111111111111000000000000011111111110000000000001111111111000000000000011111111111111111111111111111111000000000000011111111111111111111111111111111000000000000111111111111111111111111111111111000000000000111111111...

Bis auf minimale, zu vernachlässigende Abweichungen ist der Output 
derselbe.

Kannst Du den IRSND mittels zweitem µC auch scannen?

Gruß,

Frank

von Sebastian (Gast)


Lesenswert?

Hallo Frank,

ja, #1-#5 in rx_denon_9766Hz.txt ist immer dieselbe Taste.

OK, du meinst also, dass das von IRMP decodierte Signal OK ist. Davon 
gehe ich auch aus. Ich verstehe nur nicht, warum das Senden im IRSND 
nicht klappt. Welchen Wert für F_INTERRUPT empfiehlst du für's Senden 
des Denon/Nec Protokoll?

Das Scannen des IRSND Signals über einen 2. µC werde ich die mal 
testen...

Gruß
Sebastian

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Sebastian schrieb:
> OK, du meinst also, dass das von IRMP decodierte Signal OK ist.

Ja.

> Ich verstehe nur nicht, warum das Senden im IRSND
> nicht klappt. Welchen Wert für F_INTERRUPT empfiehlst du für's Senden
> des Denon/Nec Protokoll?

Für das NEC-Protokoll sind 10kHz (oder Deine 9,7kHz) ausreichend. Daher 
sollte Dein Toshiba-Fernseher problemlos klarkommen. Ich habe auch einen 
Toshiba, den ich mit IRSND und 10kHz problemlos bedienen kann.

Bei Denon ist das jedoch kritisch, siehe auch:

  http://www.mikrocontroller.net/articles/IRMP#Pulse-Distance_Protokolle

Auszug für Denon:

In der Praxis (diverse Scans von verschiedenen IRMP-Anwendern) sind es:

0-Bit   310µs Puls, 745µs Pause
1-Bit   310µs Puls, 1780µs Pause

Laut diverser Dokus im Netz sind es jedoch:

0-Bit   275µs Puls, 775µs Pause)
1-Bit   275µs Puls, 1900µs Pause)

Das sind gerade mal 3 Timer-Takte zum Generieren der Pulse. Da könnte 
die Abweichung schon so groß sein, dass der Denon-Empfänger das nicht 
mehr akzeptiert. Bei 15kHz und mehr sollten die Abweichungen wesentlich 
geringer sein.

Ich habe gerade mal Deine 1990er Scans durch den IRMP-Analyzer 
geschickt:
1
pulse avg:  5.7= 284.9 us, min:  5= 250.0 us, max:  7= 350.0 us, tol: 22.8%
2
pause avg: 15.2= 759.8 us, min: 14= 700.0 us, max: 16= 800.0 us, tol:  7.9%
3
pause avg: 35.9=1794.4 us, min: 34=1700.0 us, max: 37=1850.0 us, tol:  5.3%

Die Pulse entsprechen eher den Werten aus der Doku, der Rest eher den 
Erfahrungen, die bisher mit Denon-FBs gemacht wurden.

Du könntest also mal
1
#define DENON_PULSE_TIME                         310.0e-6                       //  310 usec pulse in practice,  275 in theory

in
1
#define DENON_PULSE_TIME                         275.0e-6                       //  310 usec pulse in practice,  275 in theory

ändern. Ich bezweifle aber, dass das was bringt. Irgendetwas anderes ist 
da faul, denn zumindest Dein Toshiba sollte problemlos mit dem 
IRSND-Output klarkommen.

> Das Scannen des IRSND Signals über einen 2. µC werde ich die mal
> testen...

Ja, ich glaube, das bringt uns eher weiter.

Gruß,

Frank

von Sebastian .. (zahlenfreak)


Angehängte Dateien:

Lesenswert?

Hallo Frank,

Vielen Dank schonmal für deine Antwort und sorry, dass ich so lange 
brauche. Ist zur Zeit leider etwas stressig hier.


Hier jetzt also die Ergebnisse:
Drücke ich die unten genannten Tasten oft genug im Wechsel (reichen auch 
zwei davon), wird irgendwann mal eine konsequent falsch erkannt. Auch 
bei mehrmaligem drücken kommt immer der gleiche falsche code bis ich 
wieder eine beliebige andere Taste drücke. Der Falsch erkannte Code ist 
"characteristisch" für die Taste und jedes mal der gleiche, wenn der 
Fehler auftritt.
Der Fehler dürfte ziemlich sicher in IRMP liegen. Habe testweise einen 
Controller nur mit IRMP geflasht. Den Code habe ich nur um eine simple 
UART-routine erweitert, die die erkannten codes ausgibt.
Außerdem ist aufgefallen, dass, wenn der extra eingerichtete Controller 
die codes falsch erkannt hat, ein anderes Projekt gleichzeitig die 
Commandos richtig decodiert. Bei dem anderen Projekt tritt der Fehler 
prinzipiell aber auch auf. Die Fernbedienung kanns also nicht sein. 
Vielleicht noch der Empfänger. Das sind zwei unterschiedliche in den 
beiden Projekten. Wäre aber komisch...

Der fehler tritt auch mit anderen Tasten auf, aber mit diesen habe ichs 
jetzt mal nachvollzogen. Auch mit einer anderen Fernbedienung 
(NEC-protocol) habe ich den Bug schon gehabt, aber wie gesagt kaum 
reproduzierbar.

Anbei sind Scans der vier Tasten mit 20kHz. Sobald ich zeit finde, 
scanne ich auch die ganze Fernbedienung ein, aber jetzt muss ich erstmal 
ins Bett.

Viele Grüße,

Sebastian



Die (vermutlich) Richtigen Codes sind:

Stop-Taste
Protocol 0x08
Address 0x0004
Command 0x01E8


Play >-Taste
Protocol 0x08
Address 0x0004
Command 0x00E8

Pause -Taste
Protocol 0x08
Address 0x0004
Command 0x02E8

Play < -Taste
Protocol 0x08
Address 0x0004
Command 0x03A8




Stop -Taste Falscher Code
Protocol 0x08
Address 0x0004
Command 0x0217

Play > -Taste Falscher Code
Protocol 0x08
Address 0x0004
Command 0x317

Pause -Taste Falscher Code
Protocol 0x08
Address 0x0004
Command 0x0117

Play < -Taste Falscher Code
Protocol 0x08
Address 0x0004
Command 0x0057

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Sebastian,

Sebastian ... schrieb:
> Drücke ich die unten genannten Tasten oft genug im Wechsel (reichen auch
> zwei davon), wird irgendwann mal eine konsequent falsch erkannt. Auch
> bei mehrmaligem drücken kommt immer der gleiche falsche code bis ich
> wieder eine beliebige andere Taste drücke.
>

Ich glaube zu verstehen, was da falsch läuft. Das Denon-Protokoll 
schickt jeden Frame zweimal raus, wobei beim zweiten mal die 
Command-Bits invertiert sind. Zwischen diesen beiden Frames ist eine 
Pause von 65ms.

IRMP wartet immer den 2. Frame ab und vergleicht die Command-Bits, ob 
sie invertiert sind. Soweit okay, aber: Bekommt IRMP mal den ersten 
Frame nicht richtig mit, klinkt er sich beim 2. Frame ein und wartet 
dann auf den vermeintlichen 2. Frame mit invertierten Bits. Drückst Du 
die Taste dann nochmal, nimmt er den 1. Original-Frame als invertierten 
Frame auf und bestätigt diesen als vermeintlich richtigen Code. Aus 
diesem "falschen Takt" kommt IRMP nur wieder raus, wenn irgendwann 
wieder eine Übertragunsstörung auftritt.

Diesen Fehler kann man hier auch gut erkennen:

> Die (vermutlich) Richtigen Codes sind: [...]
> Command 0x01E8
> Stop -Taste Falscher Code [...]
> Command 0x0217

0x01E8 = 01 1110 1000
0x0217 = 10 0001 0111

Man sieht, dass hier alle 10 Bits gekippt sind. Das gleiche gilt auch 
für die anderen Kommando-Codes, die Du genannt hast.

Um diesen Fehler zu beheben, muss ich eine Abbruchbedingung in IRMP 
einbauen, wie lange er auf den 2. Frame warten soll. Ist die Zeit 
wesentlich größer als 65ms, sollte IRMP den empfangenen Frame einfach 
verwerfen und wieder "von vorn" anfangen.

> Anbei sind Scans der vier Tasten mit 20kHz.

Danke. Aus irgendeinem Grunde kommt der IRMP mit den Scans nicht ganz 
klar. Er erkennt zwar Denon, bricht aber dann irgendwann die Decodierung 
ab. Das schaue ich mir nochmal genauer an, kann sein, dass bei 20kHz der 
Log-Buffer überläuft und die Scans nicht lang genug sind für 2 Frames.

Warum verwendest Du 20kHz und nicht 15kHz?

Gruß,

Frank

von Sebastian .. (zahlenfreak)


Angehängte Dateien:

Lesenswert?

Hallo Frank,

das klingt ja schonmal sehr gut!


Das mit den Scans scheint meine Schuld bzw die der Fernbedienung zu 
sein. Das dürften unvollständige Kommandos sein. Sorry dafür.
Kam so, dass ich wiederholungen vermeiden wollte, also möglichst kurz 
gedrückt hab. Aber die FB scheint die Übertragung wieder abzubrechen, 
wenn man zu kurz drückt. Jedenfalls Reagieren ein IRMP-Projekt und der 
original-Verstärker nur, wenn ich die Taste etwas länger drücke. Dann 
sind auch die scans des gleichzeitig laufenden Scan-IRMPs länger.

Anbei jetzt also ein Komplettscan der FB mit ein wenig längerem 
Tastendruck. Und mit 15kHz.
Die 20kHz kamen übrigens aus der überlegung "viel hilft viel" ;) Das 
Verhalten mit kurzen und langen scans hab ich aber bei 15 und 20 kHz 
gleichermaßen.


Viele Grüße,

Sebastian

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Sebastian,

Sebastian ... schrieb:

> Anbei jetzt also ein Komplettscan der FB mit ein wenig längerem
> Tastendruck. Und mit 15kHz.

Nachdem ich alle Kommentarzeilen mit "#" auch als solche gekennzeichnet 
und in irmp.c die Zeile
1
#define DENON_PULSE_LEN_MAX                     ((uint8_t)(F_INTERRUPTS * DENON_PULSE_TIME * MAX_TOLERANCE_10 + 0.5) + 1)

in
1
#define DENON_PULSE_LEN_MAX                     ((uint8_t)(F_INTERRUPTS * DENON_PULSE_TIME * MAX_TOLERANCE_20 + 0.5) + 1)

geändert habe, ging der Scan einwandfrei durch.

Deine FB scheint außergewöhnlich lange Pulse zu machen. Ich empfehle Dir 
daher, die Toleranz in irmp.c auf 20% zu erhöhen - so wie oben 
geschrieben. Ich werde das ebenso ins nächste Release einbauen.

Mittlerweile habe ich eine Abbruchbedingung in der IRMP-Statemachine 
eingebaut, damit die invertierten Frames beim Denon-Protokoll nicht als 
Initial-Frames erkannt werden. Funktioniert soweit mit künstlich 
generierten "fehlerhaften" Scan-Dateien tadellos. Desweiteren habe ich 
das Denon-Timing im IRSND auch verbessern können, so dass das Verhalten 
(nach 65ms kommt der invertierte Frame) nun exakt nachgebildet wird.

Damit sollten Deine Probleme erledigt sein. Das neue Release kommt in 
Kürze.

Viele Grüße,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Es steht eine neue Version 2.2.0 von IRMP + IRSND zum Download bereit.

Download über Artikel:

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

und auch übers SVN möglich:

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

Die wichtigsten Änderungen IRMP:

    - Portierung auf ARM STM32
    - Bugfix Frame-Erkennung beim Denon-Protokoll

Die wichtigsten Änderungen IRSND:

    - Portierung auf ARM STM32 (ungetestet!)
    - Bugfix Timing für 2. Frame beim Denon-Protokoll

Da IRMP/IRSND nun auf den Zielsystemen AVR/PIC/STM32 läuft, war eine 
größere Umstrukturierung des Sources notwendig, um weiterhin die 
Konfigurationsdateien irmpconfig.h und irsndconfig.h möglichst einfach 
und übersichtlich zu belassen.

Die IR-Protokoll-spezifischen Definitionen haben dafür eine neue 
Include-Datei irmpprotocols erhalten. Ebenso sind die für die 
verschiedenen Zielsysteme notwendigen Konstanten in die neue Datei 
irmpsystem.h gewandert.

Anzupassen ist weiterhin lediglich eine Datei, nämlich irmpconfig.h bzw. 
irsndconfig.h.

Achja, noch eine Kleinigkeit: Der Applikationssource darf nun nur noch 
irmp.h bzw. irsnd.h per Include einfügen. Alle anderen notwendigen 
H-Dateien werden automatisch von irmp.h bzw. irsnd.h per Include 
eingefügt.

Also:
1
#include "irmp.h"
2
3
main ()
4
{
5
  ....
6
}

Siehe auch die dazugehörigen Beispiel-Dateien main.c bzw. irsndmain.c.

Sämtliche Änderungen und neue Dateien wurden auch im Artikel IRMP 
dokumentiert bzw. aktualisiert.

Vielen Dank an kichi (Michael K.) für seine unermüdliche Arbeit an der 
STM32-Portierung.

Wünsche viel Spaß,

Frank

P.S.
@Sebastian: Mit diesem Release sollten Deine Probleme mit dem 
Denon-Protokoll behoben sein.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo zusammen,

ein paar Bugs wurden in der STM32-Portierung gefunden und behoben. Im 
SVN unter

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

ist daher jetzt die Version 2.2.1 eingecheckt.

Die Änderungen betreffen nur die STM32-Variante. Für AVRs und PICs hat 
sich gegenüber 2.2.0 nichts geändert. Sobald die Tests von IRSND unter 
STM32 abgeschlossen sind, wird es auch neue Zip-Dateien direkt zum 
Download aus dem IRMP-Artikel geben.

Viele Grüße,

Frank

von Hugo P. (portisch)


Lesenswert?

Hallo!

Ich habe mal eine kleine Zwischenfrage:
Ich wollte nun den USB IR Remote Receiver updaten.

Nun darf ja nurmehr die "irmp.h" ins Projekt eingebunden werden.
Leider kann aber der Compiler (AVR Studio 5) die Defines von der 
"irmpconfig.h" nicht mehr lesen.

Ich habe z.B. in der "configUSBIRRemoteReceiver.h" ein:
#if IRMP_LOGGING == 1
drinnen.

Das ist aber nun immer 0 weil die irmpconfig.h nicht mehr eingebunden 
ist.
Was gibt es da für einen Trick um das wieder hinzubekommen?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Hugo,

Hugo Portisch schrieb:

> Nun darf ja nurmehr die "irmp.h" ins Projekt eingebunden werden.
> Leider kann aber der Compiler (AVR Studio 5) die Defines von der
> "irmpconfig.h" nicht mehr lesen.

Kann ich mir überhaupt nicht erklären, denn in irmp.h steht nun
das

  #include irmpconfig.h

drin.

Das heisst, irmpconfig.h wird eingebunden und dadurch auch z.B. 
IRMP_LOGGING definiert.

> Ich habe z.B. in der "configUSBIRRemoteReceiver.h" ein:
> #if IRMP_LOGGING == 1
> drinnen.

Sollte ganz normal (also wie immer) gehen.

Ich habe gerade mal testweise in das Beispiel-main.c von IRMP eingefügt:
1
#if IRMP_LOGGING == 1
2
xxxxxx
3
#endif

und IRMP_LOGGING auf 1 in irmpconfig.h gestellt.

Beim Neucompilieren bekomme ich sofort den (gewünschten) Syntax-Error 
als Indikator, dass IRMP_LOGGING den korrekten Wert hat.

> Das ist aber nun immer 0 weil die irmpconfig.h nicht mehr eingebunden
> ist.

Doch, wird sie - über irmp.h

> Was gibt es da für einen Trick um das wieder hinzubekommen?

Es ist eigentlich kein Trick notwendig, siehe oben.

Kann es sein, dass Dein Compiler nicht bemerkt, dass Du irmpconfig.h 
geändert hast und er deshalb Dein main-Modul nicht neu übersetzt? Du 
solltest auf jeden Fall irmpconfig.h mit in Dein Projekt einfügen. Sonst 
fehlt die Abhängigkeit und die entsprechenden C-Sources werden nicht neu 
übersetzt, wenn Du irmpconfig.h änderst.

Im Notfall hilft auch eine Neuübersetzung des kompletten Codes.

Gruß,

Frank