IRMP mag nicht - Hardware?

Axel Ro. schrieb:
> Hallo Forum,
> versuche IRMP auf meinem Pollin Eval Board mit Add-on Board zum laufen
> zu bewegen, es klappt aber einfach nicht. Vielleicht mag einmal jemand
> schauen.

Besser wäre es vielleicht gewesen, Dein Problem im dazugehörenden Thread

  Beitrag "IRMP - Infrared Multi Protocol Decoder"

darzustellen. Ich bin jetzt nur zufällig über Dein Posting gestolpert.

> Symptom:
> - Logging geht - er spukt Nullen und Einsen aus (recht viele).

Wo ist das Logging? Das wäre am interessantesten gewesen.

> - irmp_get_data löst aus mit verschiedenen Fernbedienungen - das sollte
> doch eigentlich eine erfolgreiche Erkennung signalisieren, oder?

Ja.

> - Aber irmp_data.protocol, irmp_data.address usw. immer = null !

Kann ich mir eigentlich nicht vorstellen. Wenn IRMP ein Protokoll 
erkennt, ist irmp_data.protocol immer größer als 0. Wie gibst Du denn 
das Protokoll, die Adresse und das Kommando aus? Vielleicht liegt ja 
dort der Hase im Pfeffer.

> Einzige Änderungen im Code:
> - Eingangspin auf PORTD - Pin 3

Diese Änderung + Deine Ausgaberoutine anzugeben hätte gereicht - warum 
Du jetzt das komplette IRMP-Software-Paket, welches über den Artikel

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

herunterladbar ist, angehängt hast, verstehe ich nicht.

> - Primitive Ausgabe der Ergebnisse in der irmp_get_data

Du meinst hinter dem Aufruf von irmp_get_data() - in main.c

Hier Deine Passage zur Ausgabe des Protokolls:

1

    itoa((int)irmp_data.protocol,s,10);

2

    for (i=0;i<4;i++)

3

      {

4

      irmp_uart_putc(s[i]);

5

      }

Du gibst hier 4 Zeichen aus, auch wenn in s nur eine einzige Ziffer 
steht. Damit produzierst Du Müll. Der String s wird von itoa() 
automatisch 0-terminiert.

Deshalb müsste das eigentlich so aussehen:

1

     itoa((int)irmp_data.protocol,s,10);

2

     for (i=0; s[i]; i++)

3

     {

4

        irmp_uart_putc(s[i]);

5

     }

Dito für die Ausgabe der anderen Werte.

Sollte der Tipp allein nicht ausreichen, poste hier bitte einen Scan 
Deiner Fernbedienung - in der Form, wie die Scans im Unterverzeichnis 
IR-Data des IRMP-Pakets abgelegt sind.

Gruß,

Frank

Hallo Frank,
danke erstmal für die Mühe und die Antwort.

Habe es eigentlich gut gemeint, mit meinem Problem nicht den 
Original-Thread zu belasten - auch wird hier im Forum immer mal wieder 
jemand geschimpft, wenn man nicht den kompletten Code zufügt. Im 
gegebenen Fall aber wohl richtig - wäre nicht nötig gewesen.

Die zugegebenermassen primitive Ausgaberoutine funktioniert eigentlich 
schon - es werden ja einfach nur die ersten 4 Characters in s[] 
ausgegeben. Ich hatte das auch schon im Verdacht und hab das dann 
ausprobiert mit einem Const Zahlenwert - geht. Klar - an Stelle 3-4 
steht Müll (genaugenommen "da" des vorher geladenen Strings "data") - 
das ignoriere ich dann einfach.

Ich fange jetzt einfach nochmal ganz von vorne an und füge dann den Scan 
an - wäre nett, wenn Du nochmal vorbei schautest. Dauert ein paar 
Minuten.

Danke und Gruss
Axel

Noch ein Zusatz - habe bei dem erneuten Auspacken gesehen, dass da 
Beispiele anderer Fernbedienungen dabei sind - hier wird schon klar, 
dass da etwas schon nicht stimmen kann. Meine Scans (aus der Erinnerung) 
sind viel trivialer - schon auch Nullen und Einsen, aber bei weitem 
nicht so differenziert.

OK, egal, ich übersetze das jetzt noch mal neu und häng dann Scan an ...

Hallo Frank,
habe mal von vorne begonnnen - nur diesmal mit dem Tarball, welcher im 
Artikel verlinkt ist. Dieser Code scheint deutich weiter als das 
irmp.zip file, zumindest musste ich hier keine Anpassungen für UART und 
Timer-Interupt für den Atmega32 mehr machen.

OK, siehe bitte im Anhang die Scans meiner Samsung TV Fernbedienung - 
ganz klar stimmt da schon was nicht, verglichen mit den Beispielscans 
anbei. Diesmal triggert irmp_data_get nicht, erkennt also 
offensichtlich, dass dies nicht valide ist.

Die Anpassungen beschränkten sich diesmal nur auf diese Zeilen:

1

#define IRMP_PORT                               PORTD

2

#define IRMP_DDR                                DDRD

3

#define IRMP_PIN                                PIND

4

#define IRMP_BIT                                3       // use PD3 as IR input on AVR

und in main

1

    if (irmp_get_data (&irmp_data))

2

    {

3

    itoa(irmp_data.protocol, s, 10);

4

    irmp_uart_putc('\r');

5

    irmp_uart_putc('\n');

6

    for (i=0;s[i];i++)

7

      {

8

      irmp_uart_putc(s[i]);

9

      }

10

    irmp_uart_putc('\r');

11

    irmp_uart_putc('\n');

.

Ist Dir so etwas schon mal untergekommen? Mir fehlt im Moment jeglicher 
Ansatz, wo zu suchen. Bin für jeden Hinweis dankbar.

Grüsse
Axel

Axel Ro. schrieb:
> OK, siehe bitte im Anhang die Scans meiner Samsung TV Fernbedienung -
> ganz klar stimmt da schon was nicht, verglichen mit den Beispielscans
> anbei.

Habe mir den Scan angeschaut, da sind lediglich 2 Pulslängen drin, 
nämlich

6,2msec Puls
2,7msec Pause

und davon auch nur eine Handvoll. Das ist nie und nimmer ein 
vollständiger IR-Frame, höchstens sind das ein paar Start-Bits, die 
meist mit längerer Pulslänge als die einzelnen Daten gesendet werden. 
Ich kenne den TSOP1136 nicht, vielleicht moduliert die SAMSUNG-FB das 
Signal mit 40kHz und der TSOP1136 packt die Abweichung nicht? Mit einem 
TSOP1736 konnte ich aber problemlos das Signal einiger 
SAMSUNG-Fernbedienungen über IRMP empfangen.

> Diesmal triggert irmp_data_get nicht, erkennt also
> offensichtlich, dass dies nicht valide ist.

Hm, das ist merkwürdig.

Leider habe ich keine Idee, woran das liegen könnte. Wie ist der TSOP 
denn angeschlossen? Ist der Tiefpassfilter mit 100R und 4,7µF auch an 
der Spannungsversorgung des TSOP?

Gruß,

Frank

Hallo Frank,
danke für die Antwort.

Ich habe dies mit einer ganzen Latte von verschiedenen Fernbedienungen 
ausprobiert - alle sehen ähnlich simplistisch vom Scan her aus. 
Inzwischen habe ich auch mal einen 8Mhz Quartz genommen, ändert aber 
nichts am Symtom.

Ich tippe mehr und mehr auch auf ein Hardware-Problem mit dem TSOP1136. 
Der Tiefpass beim Pollin Add-on ist mit 100R und 47uF (also nicht 4,7uF) 
bestückt. Das ist ungewöhnlich, allerdings dachte ich, dass es sich hier 
nur um eine Entkopplung von irgendwelchen Störungen auf der 
Versorgungsleitung handelt. Oder könnten die 47uF das Problem sein??

Ich hänge jetzt mal mein Analog-Oszi dran, bezweifle allerdings, dass 
ich da viel erkennen kann.

Sehr seltsam. Die Software scheint ja inzwischen recht ausgereift - und 
viel falsch kann man ja auch nicht mehr machen.

Grüsse
Axel

Und hier das Oszi-Foto. Wie gesagt, ist ein Analog-Oszi. Nun ja, das 
sieht nicht nach einem kompletten Signal aus, oder? Vielleicht messe ich 
auch falsch oder das geht nicht mit Analog-Oszi.

Gruss
Axel

Mensch, ist das peinlich. Sowas von peinlich. Ich mags gar nicht 
zugeben. Menschliches Versagen hoch 3. Setzen, 6. Reif für die Bild.

Holger, Du hast 100% recht mit dem Kondensator. Am Eval-Board war noch 
ein Jumper auf eine Taste gesetzt für den Eingangspin. Die ist zwar 
offen, aber daran hängt so eine R-C Kombination zum Entprellen.

So was doofes - meine mich. Sorry für Euren Zeitaufwand.

Nun ja, nun gehts - fast. Protokoll ist schon mal richtig. Bei einer 
Denon kommt immer (egal welche Taste) 5 12884 0. Bei Toshiba
2 -17851 49. Command ändert sich allerdings nicht, egal welche Taste. 
Jetzt mache ich das erstmal zurück auf 16Mhz und prüfe alles nochmal 
sorgfältig durch.

Danke!
Axel

So, jetzt gehts - endlich. Muss wirklich übermüded gewesen sein.

Danke Holger und natürlich Dir, Frank, für die schöne Software!

Grüsse
Axel

Axel Ro. schrieb:
> So, jetzt gehts - endlich.

Freut mich :-)

Solltest Du noch ein Problem mit einer bestimmten FB haben, dann mache 
einen Scan davon und hänge ihn hier an.

Gruß,

Frank