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. Symptom: - Logging geht - er spukt Nullen und Einsen aus (recht viele). - irmp_get_data löst aus mit verschiedenen Fernbedienungen - das sollte doch eigentlich eine erfolgreiche Erkennung signalisieren, oder? - Aber irmp_data.protocol, irmp_data.address usw. immer = null ! Einzige Änderungen im Code: - Eingangspin auf PORTD - Pin 3 - Logging dann mal rausgenommen (=0 in irmp_config.h), aber so umgeändert, dass ich UART nach wie vor benutzen kann. - Primitive Ausgabe der Ergebnisse in der irmp_get_data Nutze Atmega32 mit 16MHz und AVRStudio. Das Pollin add on nutzt den TSOP 1136. Schade, das ist so eine praktische Software - fuchst mich, dass ich das nicht zum Laufen bekomme. Hat jemand eine Idee oder ähnliche Erfahrungen mit der Pollin-Hardware? Grüsse Axel
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
Angehängte Dateien:
-
IMG_5384.JPG
270 KB
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
>Und hier das Oszi-Foto. Wie gesagt, ist ein Analog-Oszi. Nun ja, das >sieht nicht nach einem kompletten Signal aus, oder? Doch, das sieht wie ein Signal aus. Der Pegel kommt nur nicht hoch genug. Hängt da irgendwo ein Kondensator mit am Pin? Oder vieleicht doch nicht auf Eingang geschaltet? > Vielleicht messe ich >auch falsch oder das geht nicht mit Analog-Oszi. Geht. Nimm mal einen 10:1 Tastkopf. Dann sieht es evtl. besser aus;)
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.