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 Fabi S (Gast)


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


Bewertung
0 lesenswert
nicht lesenswert
Fabi S schrieb:
> soll ich nochmal kucken?

Nö, brauchst Du nicht.

von Joachim B. (jar)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht 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:
void timer0_init(void)
{
    OCR0A  = (F_CPU / ( 2 * IR_FREQUENZ )) - 1;               // compare value: 
#if !FB_LCD_STECKBRETT
  IR_SND_DDR |= (1<<IR_SND);                                  // set DDR to output
    IR_SND_PORT &= ~(1<<IR_SND);                                // set pin to low
#endif
}

void timer0_start(void)
{
    TCCR0A  |= (1 << WGM01) | (1 << WGM00) | (1 << COM0A0);   // switch CTC Mode on, set prescaler to 1
  TCCR0B   |= (1 << WGM02) | (1<<CS00);
    TIMSK0  |= (1 << OCIE0A);                                   // OCIE0A: Interrupt by timer compare
}

void timer0_stop(void)
{
  TIMSK0  &= ~(1 << OCIE0A);                                   // OCIE0A: Interrupt by timer compare
  TCCR0B   &= ~(1 << WGM02) | (1<<CS00);
    TCCR0A  &= ~(1 << WGM01) | (1 << WGM00) | (1 << COM0A0);

deiner:
static void
irsnd_on (void)
{
    if (! irsnd_is_on)
    {
#ifndef DEBUG
#if defined (__AVR_ATmega32__)
        TCCR2 |= (1<<COM20)|(1<<WGM21);                 // = 0x42: toggle OC2A on compare match, clear Timer 2 at compare match OCR2A
#else
        TCCR2A |= (1<<COM2A0)|(1<<WGM21);               // = 0x42: toggle OC2A on compare match, clear Timer 2 at compare match OCR2A
#endif  // __AVR...
#endif // DEBUG
        irsnd_is_on = TRUE;
    }
}

/*---------------------------------------------------------------------------------------------------------------------------------------------------
 *  Switch PWM off
 *  @details  Switches PWM off
 *---------------------------------------------------------------------------------------------------------------------------------------------------
 */
static void
irsnd_off (void)
{
    if (irsnd_is_on)
    {
#ifndef DEBUG
#if defined (__AVR_ATmega32__)
        TCCR2 &= ~(1<<COM20);                                                           // normal port operation, OC2A disconnected.
#else
        TCCR2A &= ~(1<<COM2A0);                                                         // normal port operation, OC2A disconnected.
#endif  // __AVR...
        IRSND_PORT  &= ~(1<<IRSND_BIT);                                                 // set IRSND_BIT to low
#endif // DEBUG
        irsnd_is_on = FALSE;
    }
}


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)


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


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

Bewertung
0 lesenswert
nicht lesenswert
Hier noch die Platine

von Michael H. (michael_h45)


Bewertung
0 lesenswert
nicht lesenswert

von Bruno I. (bjnas)


Bewertung
0 lesenswert
nicht lesenswert
Man, das ging ja fix. Da war ich wohl schlampig.

von eku (Gast)


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


Bewertung
0 lesenswert
nicht 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:
#if defined (__AVR_ATmega32__) || defined (__AVR_ATmega644P__) || defined (__AVR_ATmega324P__)
// usw.

Vielen Dank für dieses schöne Projekt!!!

Grüße,

Peter

von eku (Gast)


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


Bewertung
0 lesenswert
nicht lesenswert
Pollin-IR-Tastatur FDC-3402: Mausknubbel enträtselt

IR-Daten:
8 Adress-Bits
8 Mouse-Bits (Bit0=lButtonDown, Bit1=rButtonDown, Bit3=IsMouse, Bit4=IsLeftMove, Bit5=IsDownMove)
4 RightMove-Bits
4 LeftMove-Bits (wenn IsMouse in Mouse-Bits gesetzt, sonst Press/Release)
4 UpMove-Bits   (wenn IsMouse in Mouse-Bits gesetzt, sonst Low-Nibble von Command
4 DownMove-Bits (wenn IsMouse in Mouse-Bits gesetzt, sonst High-Nibble von Command
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)


Bewertung
0 lesenswert
nicht 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.
hardware/ir/irmp/irmp.c:114: Warnung: #pragma push_macro  wird ignoriert
hardware/ir/irmp/irmp.c:118: Warnung: #pragma push_macro  wird ignoriert
hardware/ir/irmp/irmp.c:133: Warnung: #pragma pop_macro  wird ignoriert
hardware/ir/irmp/irmp.c:134: Warnung: #pragma pop_macro  wird ignoriert
hardware/ir/irmp/irmp.c:328: Warnung: »TIMER0_COMP_vect« scheint ein falsch geschriebener Signal-Handler zu sein
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)


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


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


Bewertung
0 lesenswert
nicht 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:
>
> #if defined (__AVR_ATmega32__) || defined (__AVR_ATmega644P__) ||
> defined (__AVR_ATmega324P__)
> // usw.
> 

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


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


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


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


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


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


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


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


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


Bewertung
0 lesenswert
nicht 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:
#if IRSND_SUPPORT_SIEMENS_PROTOCOL == 1
        case IRMP_SIEMENS_PROTOCOL:
        {
            irsnd_buffer[0] = ((irmp_data_p->address & 0x0FFF) >> 5);                                           // SAAAAAAA
            irsnd_buffer[1] = ((irmp_data_p->address & 0x1F) << 3) | ((irmp_data_p->command & 0x7F) >> 5);      // AAAAA0CC
            irsnd_buffer[2] = (irmp_data_p->command << 3);                                                      // CCCCC0

            if ((irmp_data_p->command % 2) == 0)         // +++
            {                                            // +++
                irsnd_buffer[2] |= 0x04;                 // +++
            }                                            // +++
            irsnd_busy      = TRUE;
            break;
        }
#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


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


Bewertung
0 lesenswert
nicht 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):
#if IRSND_SUPPORT_SIEMENS_PROTOCOL == 1
        case IRMP_SIEMENS_PROTOCOL:
        {
            irsnd_buffer[0] = ((irmp_data_p->address & 0x0FFF) >> 5);                                           // SAAAAAAA
            irsnd_buffer[1] = ((irmp_data_p->address & 0x1F) << 3) | ((irmp_data_p->command & 0x7F) >> 5);      // AAAAA0CC
            irsnd_buffer[2] = (irmp_data_p->command << 3);                                                      // CCCCC?

            if (!(irmp_data_p->command & 0x01))   // +++
            {                                     // +++
                irsnd_buffer[2] |= 0x04;          // +++  // 00000c
            }                                     // +++
            irsnd_busy      = TRUE;
            break;
        }
#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


Bewertung
0 lesenswert
nicht lesenswert
Noch kürzer:

Alt:
  irsnd_buffer[2] = (irmp_data_p->command << 3);                                                      // CCCCC?

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


Bewertung
0 lesenswert
nicht lesenswert
Hast du mal ausprobiert, was weniger Code verbraucht? Ich vermute fast, 
dass die if-Anweisung effizienter ist.

von eku (Gast)


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


Bewertung
0 lesenswert
nicht 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:
 ./irmp-15kHz <IR-Data/Siemens-Gigaset-M740AV-15kHz.txt
-------------------------------------------------------------------
# Power
00011011000100000010110 p = 17, a = 0x06c4, c = 0x000b, f = 0x00
-------------------------------------------------------------------
# 1
00011011000100000000010 p = 17, a = 0x06c4, c = 0x0001, f = 0x00
-------------------------------------------------------------------
#2
00011011000100000000101 p = 17, a = 0x06c4, c = 0x0002, f = 0x00
-------------------------------------------------------------------
# 3
00011011000100000000110 p = 17, a = 0x06c4, c = 0x0003, f = 0x00
-------------------------------------------------------------------
# 4
00011011000100000001001 p = 17, a = 0x06c4, c = 0x0004, f = 0x00
-------------------------------------------------------------------
# 5
00011011000100000001010 p = 17, a = 0x06c4, c = 0x0005, f = 0x00
-------------------------------------------------------------------
# 6
00011011000100000001101 p = 17, a = 0x06c4, c = 0x0006, f = 0x00
-------------------------------------------------------------------
# 7
00011011000100000001110 p = 17, a = 0x06c4, c = 0x0007, f = 0x00
-------------------------------------------------------------------
# 8
00011011000100000010001 p = 17, a = 0x06c4, c = 0x0008, f = 0x00
-------------------------------------------------------------------
# 9
00011011000100000010010 p = 17, a = 0x06c4, c = 0x0009, f = 0x00
-------------------------------------------------------------------
# 0
00011011000100000010101 p = 17, a = 0x06c4, c = 0x000a, f = 0x00
-------------------------------------------------------------------
# HELP
00011011000100000100110 p = 17, a = 0x06c4, c = 0x0013, f = 0x00
-------------------------------------------------------------------
# Hoch
00011011000100000101101 p = 17, a = 0x06c4, c = 0x0016, f = 0x00
-------------------------------------------------------------------
# Links
00011011000100000011001 p = 17, a = 0x06c4, c = 0x000c, f = 0x00
-------------------------------------------------------------------
# OK
00011011000100000011101 p = 17, a = 0x06c4, c = 0x000e, f = 0x00
-------------------------------------------------------------------
# Rechts
00011011000100000011110 p = 17, a = 0x06c4, c = 0x000f, f = 0x00
-------------------------------------------------------------------
# Runter
00011011000100000100001 p = 17, a = 0x06c4, c = 0x0010, f = 0x00
-------------------------------------------------------------------
# EXIT
00011011000100000011010 p = 17, a = 0x06c4, c = 0x000d, f = 0x00
-------------------------------------------------------------------
# Mute
00011011000100000101110 p = 17, a = 0x06c4, c = 0x0017, f = 0x00
-------------------------------------------------------------------
# Menu
00011011000100000110010 p = 17, a = 0x06c4, c = 0x0019, f = 0x00
-------------------------------------------------------------------
# EPG
00011011000100000110110 p = 17, a = 0x06c4, c = 0x001b, f = 0x00
-------------------------------------------------------------------
# INFO
00011011000100000111001 p = 17, a = 0x06c4, c = 0x001c, f = 0x00
-------------------------------------------------------------------
# REW
00011011000100000111010 p = 17, a = 0x06c4, c = 0x001d, f = 0x00
-------------------------------------------------------------------
# STOP
00011011000100000111101 p = 17, a = 0x06c4, c = 0x001e, f = 0x00
-------------------------------------------------------------------
# FF
00011011000100000111110 p = 17, a = 0x06c4, c = 0x001f, f = 0x00
-------------------------------------------------------------------
# Rot
00011011000100001000001 p = 17, a = 0x06c4, c = 0x0020, f = 0x00
-------------------------------------------------------------------
# Gruen
00011011000100001000010 p = 17, a = 0x06c4, c = 0x0021, f = 0x00
-------------------------------------------------------------------
# Gelb
00011011000100001000101 p = 17, a = 0x06c4, c = 0x0022, f = 0x00
-------------------------------------------------------------------
# Blau
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


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


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


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


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


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

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


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


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


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

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

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

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


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


Bewertung
0 lesenswert
nicht 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:
< #define IRMP_PORT                               PORTC
< #define IRMP_DDR                                DDRC
< #define IRMP_PIN                                PINC
< #define IRMP_BIT                                0       // use PB6 as IR input on AVR
---
> #define IRMP_PORT                               PORTB
> #define IRMP_DDR                                DDRB
> #define IRMP_PIN                                PINB
> #define IRMP_BIT                                6       // use PB6 as IR input on AVR


irsndconfig.h
< #define IRSND_PORT                              PORTB   // port D
< #define IRSND_DDR                               DDRB    // ddr D
< #define IRSND_BIT                               3       // OC2A
---
> #define IRSND_PORT                              PORTD   // port D
> #define IRSND_DDR                               DDRD    // ddr D
> #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)


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


Bewertung
0 lesenswert
nicht 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
#define DENON_PULSE_TIME                        275.0e-6                        //  275 usec pulse
#define DENON_1_PAUSE_TIME                      1900.0e-6                       // 1900 usec pause

durch
#define DENON_PULSE_TIME                        300.0e-6                        //  300 usec pulse
#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


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

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


Bewertung
0 lesenswert
nicht 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.
# ./irmp < sharp.log
-------------------------------------------------------------------
# power
100000110100010
100001001011101 p =  8, a = 0x0010, c = 0x01a2, f = 0x00
100000110100010
-------------------------------------------------------------------
...

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)


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


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

noch eine Quelle: S.15 in 
http://tinkerish.com/docs/ir%20remote%20control%20details.pdf

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht 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:
   case IRMP_DENON_PROTOCOL:
   {
       ...
       irsnd_set_freq (IRSND_FREQ_32_KHZ);

Neu:
   case IRMP_DENON_PROTOCOL:
   {
       ...
       irsnd_set_freq (IRSND_FREQ_38_KHZ);

2. Timings in irmp.h:
#define DENON_PULSE_TIME                        320.0e-6                        //  320 usec pulse
#define DENON_1_PAUSE_TIME                      1680.0e-6                       // 1680 usec pause
#define DENON_0_PAUSE_TIME                       680.0e-6                       //   680 usec pause
#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)


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


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


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


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


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


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


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


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


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

hast Du schon Zeit und Muse gehabt, das SHARP Protokoll zu 
implemetieren?

von Frank M. (ukw) (Moderator) Benutzerseite


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


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


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


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


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

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


Bewertung
0 lesenswert
nicht 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:
  • TX.wav (49,3 KB, 128 Downloads)
  • RX.wav (67,3 KB, 122 Downloads)

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

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


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


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

Bewertung
0 lesenswert
nicht 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.
case IRMP_SIRCS_PROTOCOL:
  { command = bitsrevervse (irmp_data_p->command, SIRCS_MINIMUM_DATA_LEN);
    irsnd_buffer[0] = (command & 0x0FF0) >>  4;   // CCCCCCCC
    irsnd_buffer[1] = (command & 0x000F) << 4;    // CCCC0000

    irsnd_busy      = TRUE;
    break;
  }

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


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


Bewertung
0 lesenswert
nicht 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.
  complete_data_len = SIRCS_MINIMUM_DATA_LEN+SIRCS_ADDITIONAL_NUM_OF_BITS; 

sowie in der "irsnd_send_data"
case IRMP_SIRCS_PROTOCOL:
{
//command = bitsrevervse (irmp_data_p->command, SIRCS_MINIMUM_DATA_LEN);
  command = bitsrevervse (irmp_data_p->command, SIRCS_MINIMUM_DATA_LEN+SIRCS_ADDITIONAL_NUM_OF_BITS);

//  irsnd_buffer[0] = (command & 0x0FF0) >> 4;     // CCCCCCCC
//  irsnd_buffer[1] = (command & 0x000F) << 4;     // CCCC0000
    irsnd_buffer[0] = (command & 0x7F10) >> 7;     
    irsnd_buffer[1] = (command & 0x007f) << 1;     // Anpassung auf 15 Bit
    irsnd_busy      = TRUE;
    break;
}
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


Bewertung
0 lesenswert
nicht 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.
>
  complete_data_len =
> 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"
>
>     irsnd_buffer[0] = (command & 0x7F10) >> 7;
>     irsnd_buffer[1] = (command & 0x007f) << 1;     // Anpassung auf 15
> 

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


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


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


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


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


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


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


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


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


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

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


Bewertung
0 lesenswert
nicht 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:
#define DENON_PULSE_TIME         310.0e-6  //  310 usec pulse
#define DENON_1_PAUSE_TIME      1780.0e-6  // 1780 usec pause
#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)


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


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


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


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


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


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


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


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


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


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


Bewertung
0 lesenswert
nicht 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:
#if IRSND_SUPPORT_RC5_PROTOCOL == 1
    static uint8_t  toggle_bit_rc6;
#endif

Neu:
#if IRSND_SUPPORT_RC6_PROTOCOL == 1 || IRSND_SUPPORT_RC6A_PROTOCOL == 1
    static uint8_t  toggle_bit_rc6;
#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)


Bewertung
0 lesenswert
nicht lesenswert
Pollin hat eine neue IR-Tastatur:  711 057

von eku (Gast)


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


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

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


Bewertung
0 lesenswert
nicht 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:
#define RC5_ADDRESS_OFFSET                      2                               // skip 2 bits (2nd start + 1 toggle)
#define RC5_ADDRESS_LEN                         5                               // read 5 address bits
#define RC5_COMMAND_OFFSET                      7                               // skip 5 bits (2nd start + 1 toggle + 5 address)
#define RC5_COMMAND_LEN                         6                               // read 6 command bits
#define RC5_COMPLETE_DATA_LEN                   13                              // complete length

Neu:
#define RC5_ADDRESS_OFFSET                      1                               // skip 1 bit
#define RC5_ADDRESS_LEN                         3                               // read 3 address bits
#define RC5_COMMAND_OFFSET                      4                               // skip 4 bits
#define RC5_COMMAND_LEN                         13                              // read 13 command bits
#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


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


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


Bewertung
0 lesenswert
nicht 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:
#define RC5_START_BIT_LEN_MIN                   ((uint8_t)(F_INTERRUPTS * RC5_BIT_TIME * MIN_TOLERANCE_20 + 0.5) - 1)
#define RC5_START_BIT_LEN_MAX                   ((uint8_t)(F_INTERRUPTS * RC5_BIT_TIME * MAX_TOLERANCE_20 + 0.5) + 1)
#define RC5_BIT_LEN_MIN                         ((uint8_t)(F_INTERRUPTS * RC5_BIT_TIME * MIN_TOLERANCE_20 + 0.5) - 1)
#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)


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


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

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


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


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


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


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


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


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

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


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

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


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

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


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


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


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


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


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


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


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

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


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


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


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


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

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


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


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


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


Bewertung
0 lesenswert
nicht 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:
// This is the main routine if you use GCC Compiler
int
main (void)
{
  IRMP_DATA irmp_data;

  irmp_init();         // initialize rc5
  timer_init();        // initialize timer
  sei ();              // enable interrupts

  for (;;)
  {
    if (irmp_get_data (&irmp_data))
    {
        // ir signal decoded, do something here...
        // irmp_data.protocol is the protocol, see irmp.h
        // irmp_data.address is the address/manufacturer code of ir sender
        // irmp_data.command is the command code
    }
  }
}


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


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

versuch doch bitte nur RUWIDO einzukompilieren :-)

error: 'last_value' undeclared

von Fred (Gast)


Bewertung
0 lesenswert
nicht lesenswert
da muss RC5 noch mit rein, dann klappts.


Fred

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht 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:
#if IRMP_SUPPORT_RC5_PROTOCOL == 1 || IRMP_SUPPORT_RC6_PROTOCOL == 1 ....
#define IRMP_SUPPORT_MANCHESTER                 1

Neu:
#if IRMP_SUPPORT_RC5_PROTOCOL == 1 || IRMP_SUPPORT_RC6_PROTOCOL == 1 || \
    IRMP_SUPPORT_GRUNDIG_OR_NOKIA_PROTOCOL == 1 || IRMP_SUPPORT_SIEMENS_PROTOCOL == 1 || \
    IRMP_SUPPORT_RUWIDO_PROTOCOL == 1
#define IRMP_SUPPORT_MANCHESTER                 1

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


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


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


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


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


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


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


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


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


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


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


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


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

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


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


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


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


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


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


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


Bewertung
0 lesenswert
nicht lesenswert
Sorry, dass ich schon wieder nerven muss.
Ich habe jetzt, hier aus dem Thread übernommen, folgendes in main:
   if (irmp_get_data (&irmp_data))
    {
        itoa(irmp_data.protocol, protocol, 10);
        itoa(irmp_data.address, address, 16);
        itoa(irmp_data.command, command, 16);

        lcd_string(protocol);
        lcd_string(address);
        lcd_string(command);
     }

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


Bewertung
0 lesenswert
nicht lesenswert
Bastian F. schrieb:

> Ich habe jetzt, hier aus dem Thread übernommen, folgendes in main:
>     if (irmp_get_data (&irmp_data))
>     {
>         itoa(irmp_data.protocol, protocol, 10);
>         itoa(irmp_data.address, address, 16);
>         itoa(irmp_data.command, command, 16);
> 
>         lcd_string(protocol);
>         lcd_string(address);
>         lcd_string(command);
>      }

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:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Wie ist bei Dir protocol, address und command definiert? Bitte zeige die
> ganze main-Funktion.
main (void)
{
  char protocol[10];
  char address[10];
  char command[10];

  IRMP_DATA irmp_data;
  lcd_init();
  irmp_init();                                                              // initialize rc5
  timer_init();                                                             // initialize timer
  sei ();                                                                   // enable interrupts

  for (;;)
  {

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

        lcd_string(protocol);
        lcd_string(address);
        lcd_string(command);
    }
  }
}
>
>> 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


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


Angehängte Dateien:

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


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


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


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


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

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


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


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


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


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

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


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

Variable irmp_bit in irmp.c wird zweimal deklariert.

von Frank M. (ukw) (Moderator) Benutzerseite


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


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


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

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

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


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


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


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

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


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


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


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


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


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


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


Bewertung
0 lesenswert
nicht 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,
// wo auch immer
void timer0_init(void)
{
  TCCR0B = 1<<CS02;      //divide by 256
  TCNT0 = -2;          // 2 * 256 = 512 cycle bei 8 MHz
  TIMSK0 = 1<<TOIE0;    //enable timer interrupt
}

// in IRMP.C 
SIGNAL (SIG_OVERFLOW0)
{
  TCNT0 = -2;
  irmp_ISR ();
}

//---------------- ab hier nur kalk-hilfe




/* kleine kalk-Hilfe in qbasic, wer mag kanns auch in C umschreiben
CLS
OPEN "timer0.h" FOR OUTPUT AS #1
j = 1

PRINT #1, "//", "TCCR0B"
PRINT #1, "//", "CS02  CS01  CS00  Description"
PRINT #1, "//", "0     0     0     No clock source (Timer/Counter stopped)"
PRINT #1, "//", "0     0     1     clkI/O/(No prescaling)"
PRINT #1, "//", "0     1     0     clkI/O/8 (From prescaler)"
PRINT #1, "//", "0     1     1     clkI/O/64 (From prescaler)"
PRINT #1, "//", "1     0     0     clkI/O/256 (From prescaler)"
PRINT #1, "//", "1     0     1     clkI/O/1024 (From prescaler)"


PRINT #1, "//", "F_CPU / MHz", "Interrupts", "TCCR0B", "TCNT0"

FOR f1 = 1 TO 20 STEP 1
f = f1
nochmal:
FOR d = 1 TO 30
FOR e = 0 TO 6 STEP 3
REM 2^0 2^3 2^6 2^8 2^10
IF (f * 1000000 / (2 ^ e)) / d >= 10000 AND (f * 1000000 / (2 ^ e)) / d <= 21000 THEN
   PRINT #1, "//", f, INT((f * 1000000 / (2 ^ e)) / d), 2 ^ e, -d;
   IF (2 ^ e) = 8 THEN PRINT #1, "-> "; CHR$(9); "TCCR0B=(CS01);"; CHR$(9); "TCNT0 = "; -d; ";"
   IF (2 ^ e) = 64 THEN PRINT #1, "-> "; CHR$(9); "TCCR0B=(CS01 | CS00);"; CHR$(9); "TCNT0 = "; -d; ";"
   IF (2 ^ e) = 256 THEN PRINT #1, "-> "; CHR$(9); "TCCR0B = (CS02); "; CHR$(9); "TCNT0 = "; -d; ";"
   IF (2 ^ e) = 1024 THEN PRINT #1, "-> "; CHR$(9); "TCCR0B=(CS02| CS00);"; CHR$(9); "TCNT0 = "; -d; ";"

   j = j + 1
END IF
NEXT e
NEXT d
FOR d = 1 TO 30
FOR e = 8 TO 10 STEP 2
IF (f * 1000000 / (2 ^ e)) / d >= 10000 AND (f * 1000000 / (2 ^ e)) / d <= 21000 THEN
   PRINT #1, "//", f, INT((f * 1000000 / (2 ^ e)) / d), 2 ^ e, -d;
   IF (2 ^ e) = 8 THEN PRINT #1, "-> "; CHR$(9); "TCCR0B=(CS01);"; CHR$(9); "TCNT0 = "; -d; ";"
   IF (2 ^ e) = 64 THEN PRINT #1, "-> "; CHR$(9); "TCCR0B=(CS01 | CS00);"; CHR$(9); "TCNT0 = "; -d; ";"
   IF (2 ^ e) = 256 THEN PRINT #1, "-> "; CHR$(9); "TCCR0B = (CS02); "; CHR$(9); "TCNT0 = "; -d; ";"
   IF (2 ^ e) = 1024 THEN PRINT #1, "-> "; CHR$(9); "TCCR0B=(CS02| CS00);"; CHR$(9); "TCNT0 = "; -d; ";"
  
   j = j + 1
END IF
NEXT e
NEXT d
IF f = 7 THEN
   f = 7.373
   GOTO nochmal
END IF
IF f = 14 THEN
   f = 14.318
   GOTO nochmal
END IF
NEXT f1

*/





//            TCCR0B
//            CS02  CS01  CS00  Description
//            0     0     0     No clock source (Timer/Counter stopped)
//            0     0     1     clkI/O/(No prescaling)
//            0     1     0     clkI/O/8 (From prescaler)
//            0     1     1     clkI/O/64 (From prescaler)
//            1     0     0     clkI/O/256 (From prescaler)
//            1     0     1     clkI/O/1024 (From prescaler)
//            F_CPU / MHz   Interrupts    TCCR0B        TCNT0
//             1             15625         64           -1 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -1 ;
//             1             20833         8            -6 ->   TCCR0B=(CS01);  TCNT0 = -6 ;
//             1             17857         8            -7 ->   TCCR0B=(CS01);  TCNT0 = -7 ;
//             1             15625         8            -8 ->   TCCR0B=(CS01);  TCNT0 = -8 ;
//             1             13888         8            -9 ->   TCCR0B=(CS01);  TCNT0 = -9 ;
//             1             12500         8            -10 ->   TCCR0B=(CS01);  TCNT0 = -10 ;
//             1             11363         8            -11 ->   TCCR0B=(CS01);  TCNT0 = -11 ;
//             1             10416         8            -12 ->   TCCR0B=(CS01);  TCNT0 = -12 ;
//             2             15625         64           -2 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -2 ;
//             2             10416         64           -3 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -3 ;
//             2             20833         8            -12 ->   TCCR0B=(CS01);  TCNT0 = -12 ;
//             2             19230         8            -13 ->   TCCR0B=(CS01);  TCNT0 = -13 ;
//             2             17857         8            -14 ->   TCCR0B=(CS01);  TCNT0 = -14 ;
//             2             16666         8            -15 ->   TCCR0B=(CS01);  TCNT0 = -15 ;
//             2             15625         8            -16 ->   TCCR0B=(CS01);  TCNT0 = -16 ;
//             2             14705         8            -17 ->   TCCR0B=(CS01);  TCNT0 = -17 ;
//             2             13888         8            -18 ->   TCCR0B=(CS01);  TCNT0 = -18 ;
//             2             13157         8            -19 ->   TCCR0B=(CS01);  TCNT0 = -19 ;
//             2             12500         8            -20 ->   TCCR0B=(CS01);  TCNT0 = -20 ;
//             2             11904         8            -21 ->   TCCR0B=(CS01);  TCNT0 = -21 ;
//             2             11363         8            -22 ->   TCCR0B=(CS01);  TCNT0 = -22 ;
//             2             10869         8            -23 ->   TCCR0B=(CS01);  TCNT0 = -23 ;
//             2             10416         8            -24 ->   TCCR0B=(CS01);  TCNT0 = -24 ;
//             2             10000         8            -25 ->   TCCR0B=(CS01);  TCNT0 = -25 ;
//             3             15625         64           -3 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -3 ;
//             3             11718         64           -4 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -4 ;
//             3             20833         8            -18 ->   TCCR0B=(CS01);  TCNT0 = -18 ;
//             3             19736         8            -19 ->   TCCR0B=(CS01);  TCNT0 = -19 ;
//             3             18750         8            -20 ->   TCCR0B=(CS01);  TCNT0 = -20 ;
//             3             17857         8            -21 ->   TCCR0B=(CS01);  TCNT0 = -21 ;
//             3             17045         8            -22 ->   TCCR0B=(CS01);  TCNT0 = -22 ;
//             3             16304         8            -23 ->   TCCR0B=(CS01);  TCNT0 = -23 ;
//             3             15625         8            -24 ->   TCCR0B=(CS01);  TCNT0 = -24 ;
//             3             15000         8            -25 ->   TCCR0B=(CS01);  TCNT0 = -25 ;
//             3             14423         8            -26 ->   TCCR0B=(CS01);  TCNT0 = -26 ;
//             3             13888         8            -27 ->   TCCR0B=(CS01);  TCNT0 = -27 ;
//             3             13392         8            -28 ->   TCCR0B=(CS01);  TCNT0 = -28 ;
//             3             12931         8            -29 ->   TCCR0B=(CS01);  TCNT0 = -29 ;
//             3             12500         8            -30 ->   TCCR0B=(CS01);  TCNT0 = -30 ;
//             3             11718         256          -1 ->   TCCR0B = (CS02);   TCNT0 = -1 ;
//             4             20833         64           -3 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -3 ;
//             4             15625         64           -4 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -4 ;
//             4             12500         64           -5 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -5 ;
//             4             10416         64           -6 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -6 ;
//             4             20833         8            -24 ->   TCCR0B=(CS01);  TCNT0 = -24 ;
//             4             20000         8            -25 ->   TCCR0B=(CS01);  TCNT0 = -25 ;
//             4             19230         8            -26 ->   TCCR0B=(CS01);  TCNT0 = -26 ;
//             4             18518         8            -27 ->   TCCR0B=(CS01);  TCNT0 = -27 ;
//             4             17857         8            -28 ->   TCCR0B=(CS01);  TCNT0 = -28 ;
//             4             17241         8            -29 ->   TCCR0B=(CS01);  TCNT0 = -29 ;
//             4             16666         8            -30 ->   TCCR0B=(CS01);  TCNT0 = -30 ;
//             4             15625         256          -1 ->   TCCR0B = (CS02);   TCNT0 = -1 ;
//             5             19531         64           -4 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -4 ;
//             5             15625         64           -5 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -5 ;
//             5             13020         64           -6 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -6 ;
//             5             11160         64           -7 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -7 ;
//             5             20833         8            -30 ->   TCCR0B=(CS01);  TCNT0 = -30 ;
//             5             19531         256          -1 ->   TCCR0B = (CS02);   TCNT0 = -1 ;
//             6             18750         64           -5 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -5 ;
//             6             15625         64           -6 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -6 ;
//             6             13392         64           -7 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -7 ;
//             6             11718         64           -8 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -8 ;
//             6             10416         64           -9 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -9 ;
//             6             11718         256          -2 ->   TCCR0B = (CS02);   TCNT0 = -2 ;
//             7             18229         64           -6 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -6 ;
//             7             15625         64           -7 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -7 ;
//             7             13671         64           -8 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -8 ;
//             7             12152         64           -9 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -9 ;
//             7             10937         64           -10 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -10 ;
//             7             13671         256          -2 ->   TCCR0B = (CS02);   TCNT0 = -2 ;
//             7.373         19200         64           -6 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -6 ;
//             7.373         16457         64           -7 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -7 ;
//             7.373         14400         64           -8 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -8 ;
//             7.373         12800         64           -9 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -9 ;
//             7.373         11520         64           -10 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -10 ;
//             7.373         10473         64           -11 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -11 ;
//             7.373         14400         256          -2 ->   TCCR0B = (CS02);   TCNT0 = -2 ;
//             8             20833         64           -6 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -6 ;
//             8             17857         64           -7 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -7 ;
//             8             15625         64           -8 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -8 ;
//             8             13888         64           -9 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -9 ;
//             8             12500         64           -10 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -10 ;
//             8             11363         64           -11 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -11 ;
//             8             10416         64           -12 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -12 ;
//             8             15625         256          -2 ->   TCCR0B = (CS02);   TCNT0 = -2 ;
//             8             10416         256          -3 ->   TCCR0B = (CS02);   TCNT0 = -3 ;
//             9             20089         64           -7 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -7 ;
//             9             17578         64           -8 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -8 ;
//             9             15625         64           -9 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -9 ;
//             9             14062         64           -10 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -10 ;
//             9             12784         64           -11 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -11 ;
//             9             11718         64           -12 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -12 ;
//             9             10817         64           -13 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -13 ;
//             9             10044         64           -14 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -14 ;
//             9             17578         256          -2 ->   TCCR0B = (CS02);   TCNT0 = -2 ;
//             9             11718         256          -3 ->   TCCR0B = (CS02);   TCNT0 = -3 ;
//             10            19531         64           -8 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -8 ;
//             10            17361         64           -9 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -9 ;
//             10            15625         64           -10 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -10 ;
//             10            14204         64           -11 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -11 ;
//             10            13020         64           -12 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -12 ;
//             10            12019         64           -13 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -13 ;
//             10            11160         64           -14 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -14 ;
//             10            10416         64           -15 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -15 ;
//             10            19531         256          -2 ->   TCCR0B = (CS02);   TCNT0 = -2 ;
//             10            13020         256          -3 ->   TCCR0B = (CS02);   TCNT0 = -3 ;
//             11            19097         64           -9 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -9 ;
//             11            17187         64           -10 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -10 ;
//             11            15625         64           -11 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -11 ;
//             11            14322         64           -12 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -12 ;
//             11            13221         64           -13 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -13 ;
//             11            12276         64           -14 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -14 ;
//             11            11458         64           -15 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -15 ;
//             11            10742         64           -16 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -16 ;
//             11            10110         64           -17 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -17 ;
//             11            10742         1024         -1 ->   TCCR0B=(CS02| CS00);  TCNT0 = -1 ;
//             11            14322         256          -3 ->   TCCR0B = (CS02);   TCNT0 = -3 ;
//             11            10742         256          -4 ->   TCCR0B = (CS02);   TCNT0 = -4 ;
//             12            20833         64           -9 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -9 ;
//             12            18750         64           -10 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -10 ;
//             12            17045         64           -11 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -11 ;
//             12            15625         64           -12 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -12 ;
//             12            14423         64           -13 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -13 ;
//             12            13392         64           -14 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -14 ;
//             12            12500         64           -15 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -15 ;
//             12            11718         64           -16 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -16 ;
//             12            11029         64           -17 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -17 ;
//             12            10416         64           -18 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -18 ;
//             12            11718         1024         -1 ->   TCCR0B=(CS02| CS00);  TCNT0 = -1 ;
//             12            15625         256          -3 ->   TCCR0B = (CS02);   TCNT0 = -3 ;
//             12            11718         256          -4 ->   TCCR0B = (CS02);   TCNT0 = -4 ;
//             13            20312         64           -10 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -10 ;
//             13            18465         64           -11 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -11 ;
//             13            16927         64           -12 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -12 ;
//             13            15625         64           -13 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -13 ;
//             13            14508         64           -14 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -14 ;
//             13            13541         64           -15 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -15 ;
//             13            12695         64           -16 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -16 ;
//             13            11948         64           -17 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -17 ;
//             13            11284         64           -18 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -18 ;
//             13            10690         64           -19 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -19 ;
//             13            10156         64           -20 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -20 ;
//             13            12695         1024         -1 ->   TCCR0B=(CS02| CS00);  TCNT0 = -1 ;
//             13            16927         256          -3 ->   TCCR0B = (CS02);   TCNT0 = -3 ;
//             13            12695         256          -4 ->   TCCR0B = (CS02);   TCNT0 = -4 ;
//             13            10156         256          -5 ->   TCCR0B = (CS02);   TCNT0 = -5 ;
//             14            19886         64           -11 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -11 ;
//             14            18229         64           -12 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -12 ;
//             14            16826         64           -13 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -13 ;
//             14            15625         64           -14 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -14 ;
//             14            14583         64           -15 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -15 ;
//             14            13671         64           -16 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -16 ;
//             14            12867         64           -17 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -17 ;
//             14            12152         64           -18 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -18 ;
//             14            11513         64           -19 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -19 ;
//             14            10937         64           -20 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -20 ;
//             14            10416         64           -21 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -21 ;
//             14            13671         1024         -1 ->   TCCR0B=(CS02| CS00);  TCNT0 = -1 ;
//             14            18229         256          -3 ->   TCCR0B = (CS02);   TCNT0 = -3 ;
//             14            13671         256          -4 ->   TCCR0B = (CS02);   TCNT0 = -4 ;
//             14            10937         256          -5 ->   TCCR0B = (CS02);   TCNT0 = -5 ;
//             14.318        20338         64           -11 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -11 ;
//             14.318        18643         64           -12 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -12 ;
//             14.318        17209         64           -13 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -13 ;
//             14.318        15979         64           -14 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -14 ;
//             14.318        14914         64           -15 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -15 ;
//             14.318        13982         64           -16 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -16 ;
//             14.318        13159         64           -17 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -17 ;
//             14.318        12428         64           -18 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -18 ;
//             14.318        11774         64           -19 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -19 ;
//             14.318        11185         64           -20 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -20 ;
//             14.318        10653         64           -21 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -21 ;
//             14.318        10169         64           -22 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -22 ;
//             14.318        13982         1024         -1 ->   TCCR0B=(CS02| CS00);  TCNT0 = -1 ;
//             14.318        18643         256          -3 ->   TCCR0B = (CS02);   TCNT0 = -3 ;
//             14.318        13982         256          -4 ->   TCCR0B = (CS02);   TCNT0 = -4 ;
//             14.318        11185         256          -5 ->   TCCR0B = (CS02);   TCNT0 = -5 ;
//             15            19531         64           -12 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -12 ;
//             15            18028         64           -13 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -13 ;
//             15            16741         64           -14 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -14 ;
//             15            15625         64           -15 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -15 ;
//             15            14648         64           -16 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -16 ;
//             15            13786         64           -17 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -17 ;
//             15            13020         64           -18 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -18 ;
//             15            12335         64           -19 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -19 ;
//             15            11718         64           -20 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -20 ;
//             15            11160         64           -21 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -21 ;
//             15            10653         64           -22 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -22 ;
//             15            10190         64           -23 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -23 ;
//             15            14648         1024         -1 ->   TCCR0B=(CS02| CS00);  TCNT0 = -1 ;
//             15            19531         256          -3 ->   TCCR0B = (CS02);   TCNT0 = -3 ;
//             15            14648         256          -4 ->   TCCR0B = (CS02);   TCNT0 = -4 ;
//             15            11718         256          -5 ->   TCCR0B = (CS02);   TCNT0 = -5 ;
//             16            20833         64           -12 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -12 ;
//             16            19230         64           -13 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -13 ;
//             16            17857         64           -14 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -14 ;
//             16            16666         64           -15 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -15 ;
//             16            15625         64           -16 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -16 ;
//             16            14705         64           -17 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -17 ;
//             16            13888         64           -18 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -18 ;
//             16            13157         64           -19 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -19 ;
//             16            12500         64           -20 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -20 ;
//             16            11904         64           -21 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -21 ;
//             16            11363         64           -22 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -22 ;
//             16            10869         64           -23 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -23 ;
//             16            10416         64           -24 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -24 ;
//             16            10000         64           -25 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -25 ;
//             16            15625         1024         -1 ->   TCCR0B=(CS02| CS00);  TCNT0 = -1 ;
//             16            20833         256          -3 ->   TCCR0B = (CS02);   TCNT0 = -3 ;
//             16            15625         256          -4 ->   TCCR0B = (CS02);   TCNT0 = -4 ;
//             16            12500         256          -5 ->   TCCR0B = (CS02);   TCNT0 = -5 ;
//             16            10416         256          -6 ->   TCCR0B = (CS02);   TCNT0 = -6 ;
//             17            20432         64           -13 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -13 ;
//             17            18973         64           -14 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -14 ;
//             17            17708         64           -15 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -15 ;
//             17            16601         64           -16 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -16 ;
//             17            15625         64           -17 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -17 ;
//             17            14756         64           -18 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -18 ;
//             17            13980         64           -19 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -19 ;
//             17            13281         64           -20 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -20 ;
//             17            12648         64           -21 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -21 ;
//             17            12073         64           -22 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -22 ;
//             17            11548         64           -23 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -23 ;
//             17            11067         64           -24 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -24 ;
//             17            10625         64           -25 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -25 ;
//             17            10216         64           -26 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -26 ;
//             17            16601         1024         -1 ->   TCCR0B=(CS02| CS00);  TCNT0 = -1 ;
//             17            16601         256          -4 ->   TCCR0B = (CS02);   TCNT0 = -4 ;
//             17            13281         256          -5 ->   TCCR0B = (CS02);   TCNT0 = -5 ;
//             17            11067         256          -6 ->   TCCR0B = (CS02);   TCNT0 = -6 ;
//             18            20089         64           -14 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -14 ;
//             18            18750         64           -15 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -15 ;
//             18            17578         64           -16 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -16 ;
//             18            16544         64           -17 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -17 ;
//             18            15625         64           -18 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -18 ;
//             18            14802         64           -19 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -19 ;
//             18            14062         64           -20 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -20 ;
//             18            13392         64           -21 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -21 ;
//             18            12784         64           -22 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -22 ;
//             18            12228         64           -23 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -23 ;
//             18            11718         64           -24 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -24 ;
//             18            11250         64           -25 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -25 ;
//             18            10817         64           -26 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -26 ;
//             18            10416         64           -27 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -27 ;
//             18            10044         64           -28 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -28 ;
//             18            17578         1024         -1 ->   TCCR0B=(CS02| CS00);  TCNT0 = -1 ;
//             18            17578         256          -4 ->   TCCR0B = (CS02);   TCNT0 = -4 ;
//             18            14062         256          -5 ->   TCCR0B = (CS02);   TCNT0 = -5 ;
//             18            11718         256          -6 ->   TCCR0B = (CS02);   TCNT0 = -6 ;
//             18            10044         256          -7 ->   TCCR0B = (CS02);   TCNT0 = -7 ;
//             19            19791         64           -15 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -15 ;
//             19            18554         64           -16 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -16 ;
//             19            17463         64           -17 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -17 ;
//             19            16493         64           -18 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -18 ;
//             19            15625         64           -19 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -19 ;
//             19            14843         64           -20 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -20 ;
//             19            14136         64           -21 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -21 ;
//             19            13494         64           -22 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -22 ;
//             19            12907         64           -23 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -23 ;
//             19            12369         64           -24 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -24 ;
//             19            11875         64           -25 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -25 ;
//             19            11418         64           -26 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -26 ;
//             19            10995         64           -27 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -27 ;
//             19            10602         64           -28 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -28 ;
//             19            10237         64           -29 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -29 ;
//             19            18554         1024         -1 ->   TCCR0B=(CS02| CS00);  TCNT0 = -1 ;
//             19            18554         256          -4 ->   TCCR0B = (CS02);   TCNT0 = -4 ;
//             19            14843         256          -5 ->   TCCR0B = (CS02);   TCNT0 = -5 ;
//             19            12369         256          -6 ->   TCCR0B = (CS02);   TCNT0 = -6 ;
//             19            10602         256          -7 ->   TCCR0B = (CS02);   TCNT0 = -7 ;
//             20            20833         64           -15 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -15 ;
//             20            19531         64           -16 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -16 ;
//             20            18382         64           -17 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -17 ;
//             20            17361         64           -18 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -18 ;
//             20            16447         64           -19 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -19 ;
//             20            15625         64           -20 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -20 ;
//             20            14880         64           -21 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -21 ;
//             20            14204         64           -22 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -22 ;
//             20            13586         64           -23 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -23 ;
//             20            13020         64           -24 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -24 ;
//             20            12500         64           -25 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -25 ;
//             20            12019         64           -26 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -26 ;
//             20            11574         64           -27 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -27 ;
//             20            11160         64           -28 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -28 ;
//             20            10775         64           -29 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -29 ;
//             20            10416         64           -30 ->   TCCR0B=(CS01 | CS00);  TCNT0 = -30 ;
//             20            19531         1024         -1 ->   TCCR0B=(CS02| CS00);  TCNT0 = -1 ;
//             20            19531         256          -4 ->   TCCR0B = (CS02);   TCNT0 = -4 ;
//             20            15625         256          -5 ->   TCCR0B = (CS02);   TCNT0 = -5 ;
//             20            13020         256          -6 ->   TCCR0B = (CS02);   TCNT0 = -6 ;
//             20            11160         256          -7 ->   TCCR0B = (CS02);   TCNT0 = -7 ;

von jar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
jar schrieb:
> so nun läufts endlich,

das sollte nicht fehlen

#define F_INTERRUPTS                            15625 // passend 
einsetzen

von jar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
kleines Problem, soweit klappt alles
//TCCR0B=(1<<CS01 | 1<<CS00);  TCNT0 = -7 ;  
//divide by 64; TCNT0 = -7; // 7 * 64 = 448 cycle
gibt F_INTERRUPTS  17857
oder
TCCR0B=(1<<CS02); TCNT0 = -2 ;  //TCCR0B = 1<<CS02;  //divide by 256; TCNT0 = -2;  // 2 * 256 = 512 cycle
gibt F_INTERRUPTS  15625
TIMSK0 = 1<<TOIE0;    //enable timer interrupt

SIGNAL (SIG_OVERFLOW0)
{
  TCNT0 = -2 ;  // 2*256=512 cycle mit F_CPU 8000000 alle 64µs->F_INT.15625

oder auch 

  TCNT0 = -7 ;  // 7*64=448 cycle mit F_CPU 8000000 alle 64µs->F_INT. 17857
  irmp_ISR ();
}

soweit so gut, wenn ich aber auf 71428 Interrupts möchte um auf F_SND 
36kHz zu kommen, mit
init_teil 
TCCR0B=(1<<CS01);  TCNT0 = -14 ; // divide 8 -> 8x14 = 112 cycle
TIMSK0 = 1<<TOIE0;    //enable timer interrupt
isr_cnt =4;

ISR
SIGNAL (SIG_OVERFLOW0)
{
  TCNT0 = -14 ;  // 14*8=112 cycle mit F_CPU 8000000 alle 4x->F_INT. 17857
  IR_ERKANNT_PORT ^= (1<<IR_ERKANNT); // sollte 36kHz haben (Messtoggel)

  if (!isr_cnt--)
  {  
    irmp_ISR (); // die IRMP_ISR wird nur jeden 4ten Interrupt aufgerufen
    isr_cnt =4;
  }
}

klappts nicht, kommt maximal 26 kHz raus
die IR Erkennung geht auch nicht

von Torsten K. (nobby)


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


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

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


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


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


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

Antwort schreiben

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

Wichtige Regeln - erst lesen, dann posten!

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

Formatierung (mehr Informationen...)

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




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

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