Forum: Projekte & Code IRMP - Infrared Multi Protocol Decoder

Fabi S schrieb:
> soll ich nochmal kucken?

Nö, brauchst Du nicht.

kleines Problem (oder eher großes)

dein Code ist doch ähnlich meinem gefundenen für IRSND start stop

meiner funktioniert, getestet mit Oszi 500µs 36kHz on off
meiner:

1

void timer0_init(void)

2

{

3

    OCR0A  = (F_CPU / ( 2 * IR_FREQUENZ )) - 1;               // compare value: 

4

#if !FB_LCD_STECKBRETT

5

  IR_SND_DDR |= (1<<IR_SND);                                  // set DDR to output

6

    IR_SND_PORT &= ~(1<<IR_SND);                                // set pin to low

7

#endif

8

}

9

10

void timer0_start(void)

11

{

12

    TCCR0A  |= (1 << WGM01) | (1 << WGM00) | (1 << COM0A0);   // switch CTC Mode on, set prescaler to 1

13

  TCCR0B   |= (1 << WGM02) | (1<<CS00);

14

    TIMSK0  |= (1 << OCIE0A);                                   // OCIE0A: Interrupt by timer compare

15

}

16

17

void timer0_stop(void)

18

{

19

  TIMSK0  &= ~(1 << OCIE0A);                                   // OCIE0A: Interrupt by timer compare

20

  TCCR0B   &= ~(1 << WGM02) | (1<<CS00);

21

    TCCR0A  &= ~(1 << WGM01) | (1 << WGM00) | (1 << COM0A0);

deiner:

1

static void

2

irsnd_on (void)

3

{

4

    if (! irsnd_is_on)

5

    {

6

#ifndef DEBUG

7

#if defined (__AVR_ATmega32__)

8

        TCCR2 |= (1<<COM20)|(1<<WGM21);                 // = 0x42: toggle OC2A on compare match, clear Timer 2 at compare match OCR2A

9

#else

10

        TCCR2A |= (1<<COM2A0)|(1<<WGM21);               // = 0x42: toggle OC2A on compare match, clear Timer 2 at compare match OCR2A

11

#endif  // __AVR...

12

#endif // DEBUG

13

        irsnd_is_on = TRUE;

14

    }

15

}

16

17

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

18

 *  Switch PWM off

19

 *  @details  Switches PWM off

20

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

21

 */

22

static void

23

irsnd_off (void)

24

{

25

    if (irsnd_is_on)

26

    {

27

#ifndef DEBUG

28

#if defined (__AVR_ATmega32__)

29

        TCCR2 &= ~(1<<COM20);                                                           // normal port operation, OC2A disconnected.

30

#else

31

        TCCR2A &= ~(1<<COM2A0);                                                         // normal port operation, OC2A disconnected.

32

#endif  // __AVR...

33

        IRSND_PORT  &= ~(1<<IRSND_BIT);                                                 // set IRSND_BIT to low

34

#endif // DEBUG

35

        irsnd_is_on = FALSE;

36

    }

37

}

ergo dachte ich ich ersetzte dein ON/OFF durch meines

aber klappt nicht, irgendwo ist noch der Wurm drin,

nach play +5 sekunden hängt die routine

wenn einer mal schauen mag ?

danke
gruss
jar

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

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.

Hier noch die Platine

BPW82: http://www.datasheetcatalog.org/datasheet/vishay/81529.pdf

Man, das ging ja fix. Da war ich wohl schlampig.

Hallo Frank,

ich teste IRMP gerade auf einem ATmega324P.
Dieser sollte in der irsndconfig noch eingetragen werden, da auch hier 
die Pins nicht stimmen:

1

#if defined (__AVR_ATmega32__) || defined (__AVR_ATmega644P__) || defined (__AVR_ATmega324P__)

2

// usw.

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

Grüße,

Peter

Hi eku,

eku schrieb:
> hast Du Pläne, IRMP_USE_AS_LIB bis zu ende zu implementieren. Im Moment
> ist das nur ein Feigenblatt :-) Ich habe zwar eine Einbindung in
> ethersex laufen, einen Bibliothek würde aber das ganze vereinfachen.

Dieses define ist eher gedacht, irmp als sog. "Include-Lib" zu nutzen. 
Das heisst, man hat irgendwo in seinem Projekt sämtliche Defines, die 
normalerweise in irmpconfig.h stehen, in seinem project-irmp.c und macht 
anschließend einfach ein

1

#include "../irmp/irmp.c"

Ich benutze diese Methode selbst öfters, um bestimmte Sources, welche 
projektunabhängig sind, in mein konkretes Projekt einzubinden. Das hat 
zwar nichts mit "echten" Libs im C-Sinne zu tun, hat aber den Vorteil, 
dass nur das vom Code übernommmen/compiliert wird, was man gerade 
braucht - bei IRMP zum Beispiel nur den NEC-Decoder. Mein Projekt bleibt 
dann unabhängig von den Standard-Werten in irmpconfig.h. Das ist 
sinnvoll bei µCs, wo es auf jedes gesparte Byte ankommt. Hier wird also 
kein Object-File dazugelinkt, sondern der Source selbst mit ins Projekt 
eingebunden. Meinetwegen kannst Du das Includen von C-Files (xxx.c) als 
No-Go ansehen, für mich ist das aber eine durchaus anwendbare Methode.

Eine "klassische" Lib aus IRMP zu machen, die man dazubindet, halte ich 
für einen µC unpraktikabel, da ja dann schon bei Erstellung der Lib klar 
sein muss, welche IR-Decoder ich brauche. Es ist aber bei der 
universellen Konfigurierbarkeit von IRMP gar nicht möglich, dies vorab 
zu entscheiden.

Um auf Deine Frage zurückzukommen: das IRMP_USE_AS_LIB ist für mich kein 
Feigenblatt, sondern für mich soweit bereits anwendbar ;-)

Gruß,

Frank

Hallo Peter,

Peter Diener schrieb:
> ich teste IRMP gerade auf einem ATmega324P.
> Dieser sollte in der irsndconfig noch eingetragen werden, da auch hier
> die Pins nicht stimmen:
>

1

> #if defined (__AVR_ATmega32__) || defined (__AVR_ATmega644P__) ||

2

> defined (__AVR_ATmega324P__)

3

> // usw.

4

>

Danke, habe ich so übernommen, kommt ins nächste Release.

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

Danke fürs Danke :-)

Gruß,

Frank

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

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

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?

Simon K. schrieb:
> Also nehme ich mal an, dass da auf jeden Fall mindestens irgendein
> Protokoll unterstützt wird, richtig?

Davon gehe ich aus.

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

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

eku schrieb:

> 13 Adress-Bits + 1 Repeat-Bit + 7 Daten-Bits + 1 unbekanntes Bit
>
> zusammen. Könnte es sein, dass es sich bei dem "unbekannten Bit" um die
> Parität handelt?

Das kann durchaus sein. Ich habe mir gerade nochmal die Scans von der 
M740AV angeschaut. Dabei haben ca. 50% der Frames als letztes Bit den 
Wert 0, die anderen haben als letztes Bit den Wert 1.

> Das würde zumindest erklären, warum nur die von IRSND
> gesendeten Zeichen vom M740AV erkannt werden, bei denen zufällig die
> Parität stimmt.

Ja, sehr gut erkannt!

> Wie müsste man IRSND ändern, um diese These zu verifizieren?

Füge die mit +++ gekennzeichneten Zeilen in irsnd.c ein:

1

#if IRSND_SUPPORT_SIEMENS_PROTOCOL == 1

2

        case IRMP_SIEMENS_PROTOCOL:

3

        {

4

            irsnd_buffer[0] = ((irmp_data_p->address & 0x0FFF) >> 5);                                           // SAAAAAAA

5

            irsnd_buffer[1] = ((irmp_data_p->address & 0x1F) << 3) | ((irmp_data_p->command & 0x7F) >> 5);      // AAAAA0CC

6

            irsnd_buffer[2] = (irmp_data_p->command << 3);                                                      // CCCCC0

7

8

            if ((irmp_data_p->command % 2) == 0)         // +++

9

            {                                            // +++

10

                irsnd_buffer[2] |= 0x04;                 // +++

11

            }                                            // +++

12

            irsnd_busy      = TRUE;

13

            break;

14

        }

15

#endif

Hier wird nun zusätzlich geprüft, ob das Kommando gerade oder ungerade 
ist. Zumindest für die M740AV scheint das zu stimmen, wenn ich das 
letzte Bit betrachte. Aber es könnte auch sein, dass beim 
Siemens-Protokoll im letzten Bit tatsächlich die Parität von Adresse + 
Kommando herangezogen wird. Um das zu beurteilen, bräuchte ich den Scan 
von einer anderen Siemens-FB, welche eine andere Adresse verwendet.

Kannst Du mal testen, ob es nun stimmt?

[/c]

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

Frank M. schrieb:
> Hier wird nun zusätzlich geprüft, ob das Kommando gerade oder ungerade
> ist. Zumindest für die M740AV scheint das zu stimmen, wenn ich das
> letzte Bit betrachte.

Das letzte Bit ist eigentlich kein Paritätsbit, sondern einfach die 
Invertierung des davor zuletzt gesandten Bits, welches das 
niederwertigste Bit des Kommandocodes ist.

Daher ist die folgende Schreibweise als Codekorrektur von IRSND 
plausibler (führt aber zu demselben Ergebnis):

1

#if IRSND_SUPPORT_SIEMENS_PROTOCOL == 1

2

        case IRMP_SIEMENS_PROTOCOL:

3

        {

4

            irsnd_buffer[0] = ((irmp_data_p->address & 0x0FFF) >> 5);                                           // SAAAAAAA

5

            irsnd_buffer[1] = ((irmp_data_p->address & 0x1F) << 3) | ((irmp_data_p->command & 0x7F) >> 5);      // AAAAA0CC

6

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

7

8

            if (!(irmp_data_p->command & 0x01))   // +++

9

            {                                     // +++

10

                irsnd_buffer[2] |= 0x04;          // +++  // 00000c

11

            }                                     // +++

12

            irsnd_busy      = TRUE;

13

            break;

14

        }

15

#endif

Im IRMP-Artikel habe ich nun folgendes zum SIEMENS-Prtokoll angemerkt:

13 Adress-Bits + 1 Repeat-Bit + 7 Daten-Bits + 1 invertiertes Bit 
(letztes Bit davor nochmal invertiert)

Gruß,

Frank

Noch kürzer:

Alt:

1

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

Neu:

1

  irsnd_buffer[2] = (irmp_data_p->command << 3) | ((~irmp_data_p->command & 0x01) << 2);              // CCCCCc

Dann kann der ganze nachfolgende if-Block entfallen. Ich habe das so nun 
im IRSND übernommen. Kommt ins nächste Release.

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

eku schrieb:
>> Das letzte Bit ist eigentlich kein Paritätsbit, sondern einfach die
>> Invertierung des davor zuletzt gesandten Bits, welches das
>> niederwertigste Bit des Kommandocodes ist.
>
> das war es nicht. Versuche es nun mit der Parität, d.h. die Einsen
> zählen ( (parity_even_bit aus der avrlibc). Allerdings muss ich noch
> testen, ob die Parität auch über die Adresse gebildet wird.

Komisch, schau Dir mal diesen Output an:

1

 ./irmp-15kHz <IR-Data/Siemens-Gigaset-M740AV-15kHz.txt

2

-------------------------------------------------------------------

3

# Power

4

00011011000100000010110 p = 17, a = 0x06c4, c = 0x000b, f = 0x00

5

-------------------------------------------------------------------

6

# 1

7

00011011000100000000010 p = 17, a = 0x06c4, c = 0x0001, f = 0x00

8

-------------------------------------------------------------------

9

#2

10

00011011000100000000101 p = 17, a = 0x06c4, c = 0x0002, f = 0x00

11

-------------------------------------------------------------------

12

# 3

13

00011011000100000000110 p = 17, a = 0x06c4, c = 0x0003, f = 0x00

14

-------------------------------------------------------------------

15

# 4

16

00011011000100000001001 p = 17, a = 0x06c4, c = 0x0004, f = 0x00

17

-------------------------------------------------------------------

18

# 5

19

00011011000100000001010 p = 17, a = 0x06c4, c = 0x0005, f = 0x00

20

-------------------------------------------------------------------

21

# 6

22

00011011000100000001101 p = 17, a = 0x06c4, c = 0x0006, f = 0x00

23

-------------------------------------------------------------------

24

# 7

25

00011011000100000001110 p = 17, a = 0x06c4, c = 0x0007, f = 0x00

26

-------------------------------------------------------------------

27

# 8

28

00011011000100000010001 p = 17, a = 0x06c4, c = 0x0008, f = 0x00

29

-------------------------------------------------------------------

30

# 9

31

00011011000100000010010 p = 17, a = 0x06c4, c = 0x0009, f = 0x00

32

-------------------------------------------------------------------

33

# 0

34

00011011000100000010101 p = 17, a = 0x06c4, c = 0x000a, f = 0x00

35

-------------------------------------------------------------------

36

# HELP

37

00011011000100000100110 p = 17, a = 0x06c4, c = 0x0013, f = 0x00

38

-------------------------------------------------------------------

39

# Hoch

40

00011011000100000101101 p = 17, a = 0x06c4, c = 0x0016, f = 0x00

41

-------------------------------------------------------------------

42

# Links

43

00011011000100000011001 p = 17, a = 0x06c4, c = 0x000c, f = 0x00

44

-------------------------------------------------------------------

45

# OK

46

00011011000100000011101 p = 17, a = 0x06c4, c = 0x000e, f = 0x00

47

-------------------------------------------------------------------

48

# Rechts

49

00011011000100000011110 p = 17, a = 0x06c4, c = 0x000f, f = 0x00

50

-------------------------------------------------------------------

51

# Runter

52

00011011000100000100001 p = 17, a = 0x06c4, c = 0x0010, f = 0x00

53

-------------------------------------------------------------------

54

# EXIT

55

00011011000100000011010 p = 17, a = 0x06c4, c = 0x000d, f = 0x00

56

-------------------------------------------------------------------

57

# Mute

58

00011011000100000101110 p = 17, a = 0x06c4, c = 0x0017, f = 0x00

59

-------------------------------------------------------------------

60

# Menu

61

00011011000100000110010 p = 17, a = 0x06c4, c = 0x0019, f = 0x00

62

-------------------------------------------------------------------

63

# EPG

64

00011011000100000110110 p = 17, a = 0x06c4, c = 0x001b, f = 0x00

65

-------------------------------------------------------------------

66

# INFO

67

00011011000100000111001 p = 17, a = 0x06c4, c = 0x001c, f = 0x00

68

-------------------------------------------------------------------

69

# REW

70

00011011000100000111010 p = 17, a = 0x06c4, c = 0x001d, f = 0x00

71

-------------------------------------------------------------------

72

# STOP

73

00011011000100000111101 p = 17, a = 0x06c4, c = 0x001e, f = 0x00

74

-------------------------------------------------------------------

75

# FF

76

00011011000100000111110 p = 17, a = 0x06c4, c = 0x001f, f = 0x00

77

-------------------------------------------------------------------

78

# Rot

79

00011011000100001000001 p = 17, a = 0x06c4, c = 0x0020, f = 0x00

80

-------------------------------------------------------------------

81

# Gruen

82

00011011000100001000010 p = 17, a = 0x06c4, c = 0x0021, f = 0x00

83

-------------------------------------------------------------------

84

# Gelb

85

00011011000100001000101 p = 17, a = 0x06c4, c = 0x0022, f = 0x00

86

-------------------------------------------------------------------

87

# Blau

88

00011011000100001000110 p = 17, a = 0x06c4, c = 0x0023, f = 0x00

Hier ist das letzte Bit immer das invertierte des vorletzten. Oder ist 
da noch ein Bug in der Manchester-Codierung des IRMP? Glaube ich 
eigentlich nicht, denn RS5 und RC6 funktionieren ja....

Kannst Du mal sagen, welche Kommando-Codes gerade nicht akzeptiert 
werden?

Gruß,

Frank

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.

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

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

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

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

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

Müller schrieb:
> Habe deine neune Datein bei mir ins Projeckt übernommen
> nun habe ich ein Problem mein IR-Empfanger geht nicht mehr hast du was
> am eingang geändert ?

Nein, aber Du scheinst den neuen Code nicht an Deine Hardware angepasst 
zu haben:

irmpconfig.h:

1

< #define IRMP_PORT                               PORTC

2

< #define IRMP_DDR                                DDRC

3

< #define IRMP_PIN                                PINC

4

< #define IRMP_BIT                                0       // use PB6 as IR input on AVR

5

---

6

> #define IRMP_PORT                               PORTB

7

> #define IRMP_DDR                                DDRB

8

> #define IRMP_PIN                                PINB

9

> #define IRMP_BIT                                6       // use PB6 as IR input on AVR

irsndconfig.h

1

< #define IRSND_PORT                              PORTB   // port D

2

< #define IRSND_DDR                               DDRB    // ddr D

3

< #define IRSND_BIT                               3       // OC2A

4

---

5

> #define IRSND_PORT                              PORTD   // port D

6

> #define IRSND_DDR                               DDRD    // ddr D

7

> #define IRSND_BIT                               7       // OC2A

Damals hattest Du es wohl angepasst (siehe obige Unterschiede), dieses 
Mal hast Du das offenbar versäumt.

Gruß,

Frank

eku schrieb:

>> 2. Modulationsfrequenz der FB passt schlecht zum TSOP.
> Schon möglich.

Welchen IR-Empfänger benutzt Du denn?

Wenn man sich die Scans mit einem Text-Editor anschaut (einer, der auch 
mit langen Zeilen bestens zurechtkommt, also nicht Notepad o.ä.), sieht 
man sehr schön, dass es immer wieder "Aussetzer" gibt, d.h. dass 
IR-Impulse dort, wo sie eigentlich sein sollten, komplett fehlen. Das 
Timing von der FB ist ungeheuer exakt, selbst nach über 2300 Scanpunkten 
passen die empfangenen Impulse noch ziemlich genau übereinander.

Eigentlich werden nur die ersten beiden Tasten (power + radio) Deines 
Scans von IRMP "verstanden", alles andere wird als fehlerhaft verworfen 
- was man auch nachvollziehen kann, wenn man mit dem Editor reinschaut.

Hast Du denn beim IRMP auch derart schlechte Ergebnisse bei der 
Sharp-FB? Oder war das einfach nur ein "Montags-Scan"? Kannst Du den 
Scan wiederholen, damit man eine Aussage über die Qualität der 
Reproduzierung machen kann?

> Mit der selben Hardware kann ich eine originale Denon-FB problemlos
> einlesen und auch die Geräte mit IRSND bedienen. Null Probleme.

Sehr schön :)

> Auf keines der ausgesandten Kommandos reagiert der TV.

Das Timing der Sharp-FB ist zwar exakt, jedoch ermittelt IRMP leicht vom 
DENON-Protokoll abweichende Timingwerte, die aber alle noch in der 
IRMP-Toleranz liegen, für das Sharp-TV aber vielleicht schon zu stark 
abweichen.

Ersetze mal in irmp.h folgende Zeilen

1

#define DENON_PULSE_TIME                        275.0e-6                        //  275 usec pulse

2

#define DENON_1_PAUSE_TIME                      1900.0e-6                       // 1900 usec pause

durch

1

#define DENON_PULSE_TIME                        300.0e-6                        //  300 usec pulse

2

#define DENON_1_PAUSE_TIME                      1800.0e-6                       // 1800 usec pause

und teste IRSND erneut.

> Zugriff auf einen Oszi habe ich nicht.

Das ist schade.

Gruß,

Frank

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

Hi eku,

eku schrieb:

> danke für deine Analyse. Der TV lässt sich weder von den geänderten
> Timings noch von der Framewiederholung beindrucken :-(

Hm, erstmal habe ich jetzt keine Idee mehr, muss ich nochmal drüber 
nachdenken.

> Anbei ein erneuter Scan, diesmal beo 10KkHz.

Dieses Mal ist der Scan perfekt und läuft ohne Fehler durch den IRMP 
durch.

Hier eine Beispiel-Ausgabe, wo man sehr gut sieht, dass es 3 Frames 
sind.

1

# ./irmp < sharp.log

2

-------------------------------------------------------------------

3

# power

4

100000110100010

5

100001001011101 p =  8, a = 0x0010, c = 0x01a2, f = 0x00

6

100000110100010

7

-------------------------------------------------------------------

8

...

IRMP detektiert also nach dem 2. Frame (in welchem die Kommando-Bits 
negiert sind) bereits die Daten. Es folgt aber nochmal der 
Original-Frame. So geht das bei allen Tasten im Scan.

In meinen Augen kann das eigentlich nur daran liegen. Vielleicht baue 
ich dieses 3-Frame-Telegramm mal als Besonderheit in den IRMP ein - 
vielleicht hilft das weiter. Dabei würde ich dann auch die Pausen 
zwischen dem 2. und dem 3. Frame mal genau umsetzen - nicht mit dem 
Trick der Wiederholung.

Gruß,

Frank

eku schrieb:
> passt die Beschreibung von
> http://www.sbprojects.com/knowledge/ir/sharp.htm auf meinen Scan? Ist es
> am Ende doch ein eigenständiges Protokoll und nur ähnlich dem Denon?

Diese Beschreibung ist tatsächlich sehr ähnlich zum Denon-Protokoll. Im 
obigen Link wird von

  0 Start-Bits
  5 Adress-Bits
  8 Daten-Bits
  1 Expansion-Bit - immer 1
  0 Check-Bit - immer 0

gesprochen. Das macht zusammen 15 Bits.

Das Denon-Protokoll setzt sich zusammen aus:

  0 Start-Bits
  5 Adress-Bits
 10 Daten-Bits

macht also zusammen auch 15 Bits.

Tatsächlich sind die beiden letzten Bits auch "10" in deinen Scans, das 
passt also auf die Beschreibung des Expansion- und Check-Bits.

Die Timings sind auch sehr ähnlich:

          Denon       Sharp
Pulse     275µs       320µs
Pause 0   775µs       680µs
Pause 1  1900µs       1680µs

Tatsächlich sind diese Timings innerhalb der IRMP-Toleranzen identisch, 
IRMP kann diese also gar nicht auseinanderhalten. Es passt alles: Anzahl 
der Bits und die Timings.

Wenn ich mir die Timings innerhalb Deines Scans anschaue, so liegen sie 
ziemlich zwischen den obigen Werten, ich kann also auch nicht genau 
sagen, ob es eher Denon- oder Sharp-Timings sind.

Aber was gar nicht passt, ist die Modulationsfrequenz, bei Denon ist sie 
32 kHz, bei Sharp ist sie 38 kHz.

Ändere also bitte folgendes zum Testen des IRSND:

1. Modulationsfrequenz von 32 kHz auf 38 kHz:

Alt:

1

   case IRMP_DENON_PROTOCOL:

2

   {

3

       ...

4

       irsnd_set_freq (IRSND_FREQ_32_KHZ);

Neu:

1

   case IRMP_DENON_PROTOCOL:

2

   {

3

       ...

4

       irsnd_set_freq (IRSND_FREQ_38_KHZ);

2. Timings in irmp.h:

1

#define DENON_PULSE_TIME                        320.0e-6                        //  320 usec pulse

2

#define DENON_1_PAUSE_TIME                      1680.0e-6                       // 1680 usec pause

3

#define DENON_0_PAUSE_TIME                       680.0e-6                       //   680 usec pause

4

#define DENON_FRAMES                            2                               // DENON sends each frame 2 times

Probiere das einmal mit irmp_data.flags = 0 und dann, wenn das nichts 
hilft, mit irmp_data.flags = 1.

Gruß,

Frank

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

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

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

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

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

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.

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

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

Stefan Grimm schrieb:
> Leider habe ich kein Speicheroszi um mir die Angelegenheit da mal
> anzusehen.
Beitrag "Re: IR Signal - Welches Protokoll?"
Soundkarte reicht.

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

Hier nochmal ne grobe Übersicht über die beiden Logs.

Die Signale stehen zueinander in keinem zeitlichen Verältniss.

Gruß Stefan

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

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

Abend,

hab hier mal den Log aller Tasten der Fernbedienung.

In der IRMP verwende ich 10000 Interrupts, genauso wie in der IRSND.

habe irgendwie das Gefühl, das beim senden durch die recht großen 
Commandos irgendwas schief geht, denn es ist nicht wirklich möglich 
Zahlen wie 0x4247 in 3 Nibble beim senden unterzubringen.

1

case IRMP_SIRCS_PROTOCOL:

2

  { command = bitsrevervse (irmp_data_p->command, SIRCS_MINIMUM_DATA_LEN);

3

    irsnd_buffer[0] = (command & 0x0FF0) >>  4;   // CCCCCCCC

4

    irsnd_buffer[1] = (command & 0x000F) << 4;    // CCCC0000

5

6

    irsnd_busy      = TRUE;

7

    break;

8

  }

wenn in der oberen Zeile die Daten gespielgelt werden müsste die 
Nachricht dann ja 0xEC42 lauten. nur wie sollen die nun in den 
Sendbuffer geschrieben werden?, müsste dann 0xEC in den Buffer[0] und 
der Rest in Buffer[1] ?

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

Hab hier nen kleinen Erfolg zu verbuchen. Habe es hinbekommen, dass die 
jeweiligen Kommandos zumindest korrekt gesendet werden, auch wenn die 
Anpassung nicht unbedingt schön ist.

In der "irsnd_ISR (void)" habe ich die Mindestanzah an Bits per #define 
variabel erhöht.

1

  complete_data_len = SIRCS_MINIMUM_DATA_LEN+SIRCS_ADDITIONAL_NUM_OF_BITS;

sowie in der "irsnd_send_data"

1

case IRMP_SIRCS_PROTOCOL:

2

{

3

//command = bitsrevervse (irmp_data_p->command, SIRCS_MINIMUM_DATA_LEN);

4

  command = bitsrevervse (irmp_data_p->command, SIRCS_MINIMUM_DATA_LEN+SIRCS_ADDITIONAL_NUM_OF_BITS);

5

6

//  irsnd_buffer[0] = (command & 0x0FF0) >> 4;     // CCCCCCCC

7

//  irsnd_buffer[1] = (command & 0x000F) << 4;     // CCCC0000

8

    irsnd_buffer[0] = (command & 0x7F10) >> 7;     

9

    irsnd_buffer[1] = (command & 0x007f) << 1;     // Anpassung auf 15 Bit

10

    irsnd_busy      = TRUE;

11

    break;

12

}

Somit funktioniert in meinem Fall das Senden von Befehlen. Es sind Codes 
von 0x4200 bis 0x4247 in Verwendung.

Hoffe dennoch das euch die Codes etwas bringen.

Gruß Stefan

Stefan Grimm schrieb:
> Hab hier nen kleinen Erfolg zu verbuchen.

Freut mich!

> Habe es hinbekommen, dass die
> jeweiligen Kommandos zumindest korrekt gesendet werden, auch wenn die
> Anpassung nicht unbedingt schön ist.

Ich werde es in eine allgemeine Form bringen, Vorschlag dazu siehe 
unten.

> In der "irsnd_ISR (void)" habe ich die Mindestanzah an Bits per #define
> variabel erhöht.
>

1

  complete_data_len =

2

> SIRCS_MINIMUM_DATA_LEN+SIRCS_ADDITIONAL_NUM_OF_BITS;

Ich nehme an, dass bei Dir SIRCS_ADDITIONAL_NUM_OF_BITS den Wert 3 hat?

> sowie in der "irsnd_send_data"
>

1

>     irsnd_buffer[0] = (command & 0x7F10) >> 7;

2

>     irsnd_buffer[1] = (command & 0x007f) << 1;     // Anpassung auf 15

3

>

Okay, das muss ich dann variabel gestalten für 
SIRCS_ADDITIONAL_NUM_OF_BITS von 0 bis 8.

Ich habe mir eine allgemeine Erweiterung folgendermaßen vorgestellt:

1. Erweiterung von IRMP_DATA um: uint8_t additional_bitlen

2. IRMP füllt beim Empfang eines Frames diese Variable mit der Anzahl
   der zusätzlich empfangenen Bits. In der Regel ist der Wert also 0,
   in Stefans Fall dann aber 3.

3. IRSND wertet im Falle von SIRCS diese neue Variable aus, um damit
   die Länge des Frames zu erhöhen.

Meinungen dazu?

Gruß,

Frank

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

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

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

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

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

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

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

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

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

Hallo eku,

eku schrieb:

> anbei die versprochenen Aufzeichnungen von Denon und Sharp bei 10kHz
> Abtastrate. Ich hoffe, die unterscheiden sich soweit, dass IRMP die
> Protokolle auseinanderhalten kann.

Erstmal danke für die Erstellung der Scans.

denon2_kurz_10khz.txt kann ich leider nicht verwenden, irmp erkennt das 
Zeugs nicht. Da scheint jeder Frame aus nur 3 Bits zu bestehen.

Auswerten konnte ich also nur denon1, denon3 und sharp.

Leider unterscheiden sie sich nur minimal. Damit kann man definitiv 
keine Unterscheidung hinbekommen. Beide senden 3 Frames, wo die Pausen 
dazwischen fast identisch sind. Die Abweichungen liegen im einstelligen 
Prozentbereich. Da könnte man lediglich über statistische Auswertungen 
eine Unterscheidung hinbekommen.

Du hattest ja gesagt, dass das Sharp-Gerät nicht auf die 
Original-Denon-Timings reagiert. Wie sieht es denn umgekehrt aus? Kommt 
das Denon-Gerät mit den Sharp-Timings zurecht?

Es gäbe ja noch die Möglichkeit, im IRSND mit einem Kompromiss im Timing 
zu arbeiten, so dass sowohl Denon als auch Sharp die von IRSND 
ausgesandten Frames verstehen. Idee ist also, die etwas verschiedenen 
Timingwerte durch entsprechende Versuche soweit anzunähern, dass beide 
Geräte damit zurechtkommen.

Könntest Du mal so eine Versuchsreihe starten? Ich kann es leider nicht, 
denn ich habe weder ein Gerät von Denon noch eins von Sharp.

irmp mit der Option -a verrät über die Timings Deiner Scans:

           Sharp       Denon1     Denon3
Puls       320 µs      300 µs     300 µs
Pause0     735 µs      745 µs     745 µs
Pause1    1781 µs     1783 µs    1783 µs

Ich kenne eigentlich nur zwei Quellen über das Denon-Protokoll, nämlich

   http://www.mikrocontroller.com/de/IR-Protokolle.php#DENON
   http://www.mikrocontroller.net/attachment/4246/IR-Protokolle_Diplomarbeit.pdf

Vielleicht sind die dort angegebenen Werte

           Denon
Puls       275 µs
Pause0     775 µs
Pause1    1900 µs

einfach schlichtweg falsch (abgeschrieben) bzw. liegen viel zu weit 
neben der Realität?

Deine Denon-Fernbedienungen liegen jedenfalls viel näher an den 
Sharp-Timings als an den Timings aus der obigen Dokumentation!

Fazit:
======

Wie wäre es, wenn Du in irmp.h einstellst:

1

#define DENON_PULSE_TIME         310.0e-6  //  310 usec pulse

2

#define DENON_1_PAUSE_TIME      1780.0e-6  // 1780 usec pause

3

#define DENON_0_PAUSE_TIME       745.0e-6  //  745 usec pause

und dann nochmal zunächst IRMP testest mit beiden FBs und anschließend 
diese Timings auch für IRSND testest mit Deinem Denon- und Sharp-Gerät?

Ich glaube fest daran, dass beide Geräte die obigen Timings schlucken 
;-)

Wenn ja, werde ich die obigen Werte ab sofort im Source verwenden.

Gruß,

Frank

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

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

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

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

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

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

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

Hallo eku,

eku schrieb:

> mit den Timings der Revision 51 und 36kHz Modulationsfrequenz kann ich
> sowohl das Denon als ach das Sharp-Gerät fehlerfrei bedienen. Die
> Reaktion des Denons ist bei 32kHz und 38kHz schlechter. Der Sharp
> reagiert auf 32kHz garnicht und auf 38kHz unzuverlässig.

Vielen Dank für die wichtige Info. Ich werde also 36 kHz in irsnd.c 
eintragen und die Timings so lassen, wie sie aktuell sind. Sie 
entsprechen ja auch im Wesentlichen den von Dir gescannten Werten und 
passen auch zur lirc-DB.

> Ein kleinerSchönheitsfehler ist mir noch aufgefallen:
>
> irmp/irsnd.c: In function 'ir_tx_put':
> irmp/irsnd.c:337: warning: unused variable 'toggle_bit_rc6'
>
> Diese Variable sollte nur für RC6 einkompiliert werden.

Danke, das war ein Copy-And-Paste-Fehler, die RC5-Bedingung ist hier an 
dieser Stelle falsch.

Alt:

1

#if IRSND_SUPPORT_RC5_PROTOCOL == 1

2

    static uint8_t  toggle_bit_rc6;

3

#endif

Neu:

1

#if IRSND_SUPPORT_RC6_PROTOCOL == 1 || IRSND_SUPPORT_RC6A_PROTOCOL == 1

2

    static uint8_t  toggle_bit_rc6;

3

#endif

Werde ich ebenfalls korrigieren.

> Nochmals vielen Dank für Deine Unterstützung. Ich werde den aktuellen
> Stand dann noch zu Ethersex portieren.

Auch von mir vielen Dank für Deine wirklich hilfreichen Experimente.

Gruß,

Frank

Fred schrieb:

> Es handelt sich um eine FB für den T-Home X301T Mediareceiver.
> Hersteller ist ruwido und es ist bereits die zweite Generation.
>
> Im Anhang ist eine Datei, da hab ich mal mit der Logfunktion alle Tasten
> der Reihenfolge nach betätigt.

Das scheint ein Manchester-Code mit RC5-Timings zu sein, aber die Anzahl 
der Bits ist von 13 (Original-RC5) auf 17 Bit aufgebohrt. Leider sind da 
noch ein paar Ungenauigkeiten drin, wo ich nicht weiß, ob das 
Aufzeichnungsfehler sind oder etwas anderes.

Ändere in irmp.h mal testweise:

Alt:

1

#define RC5_ADDRESS_OFFSET                      2                               // skip 2 bits (2nd start + 1 toggle)

2

#define RC5_ADDRESS_LEN                         5                               // read 5 address bits

3

#define RC5_COMMAND_OFFSET                      7                               // skip 5 bits (2nd start + 1 toggle + 5 address)

4

#define RC5_COMMAND_LEN                         6                               // read 6 command bits

5

#define RC5_COMPLETE_DATA_LEN                   13                              // complete length

Neu:

1

#define RC5_ADDRESS_OFFSET                      1                               // skip 1 bit

2

#define RC5_ADDRESS_LEN                         3                               // read 3 address bits

3

#define RC5_COMMAND_OFFSET                      4                               // skip 4 bits

4

#define RC5_COMMAND_LEN                         13                              // read 13 command bits

5

#define RC5_COMPLETE_DATA_LEN                   17                              // complete length

Dann ist die Erkennungsrate bei über 70 Prozent.

Aber wie gesagt: das ist nur ein Test, keine endgültige Lösung. Denn das 
RC5-Protokoll hat tatsächlich nur 13 Bits.

Gruß,

Frank

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

ich schrieb:

> Ich habe mal versucht über die FB was rauszufinden. Das Protokoll nennt
> sich r-step und soll 23 bit und Manchestercodierung haben. Im Gegensatz
> zu RC5 jedoch invertiert.

Die Bitlänge ist definitiv 17 und nicht 23.

Wenn ich in irmp.c die Toleranz für RC5 von 10% auf 20% hochsetze:

1

#define RC5_START_BIT_LEN_MIN                   ((uint8_t)(F_INTERRUPTS * RC5_BIT_TIME * MIN_TOLERANCE_20 + 0.5) - 1)

2

#define RC5_START_BIT_LEN_MAX                   ((uint8_t)(F_INTERRUPTS * RC5_BIT_TIME * MAX_TOLERANCE_20 + 0.5) + 1)

3

#define RC5_BIT_LEN_MIN                         ((uint8_t)(F_INTERRUPTS * RC5_BIT_TIME * MIN_TOLERANCE_20 + 0.5) - 1)

4

#define RC5_BIT_LEN_MAX                         ((uint8_t)(F_INTERRUPTS * RC5_BIT_TIME * MAX_TOLERANCE_20 + 0.5) + 1)

habe ich sogar eine Erkennungsrate von 100%. Verwendest Du einen Quarz 
am µC?

Leider hast Du in der Scan-Datei keine Kommentare eingepflegt. Ich habe 
nämlich gesehen, dass von den 44 Tastendrücken, die Du aufgezeichnet 
hast, 14 identisch sind, es tatsächlich also nur 30 verschiedene Tasten 
waren.

Um nun herauszufinden, ob der Code tatsächlich invertiert ist oder 
nicht, bitte ich Dich, zumindest die Tasten 0-9 nochmal aufzuzeichnen 
und mit einer Kommentarzeile vor jeder Scan-Zeile zu versehen, siehe 
dazu auch die anderen Scan-Dateien im Unterverzeichnis IR-Data.

Gruß,

Frank

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

@Fred: Kannst du mir bitte mal deine portierte Version für den Atmega8 
zukommen lassen?
Danke,
Basti

bastian.felten[ät]gmail[dot]com

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?

Bastian F. schrieb:
> HTerm zeigt mir jedoch bei keiner einzigen Fernbedienung irgendeinen
> Ausgabe.

Zeig mal Deine irmpconfig.h und deine main-Funktion.

Gruß,

Frank