Hallo, habe zur Anwendung des Programms Fragen. Zunächst habe ich die AVR-Version (irmp-main-avr.c) ausgesucht und Änderungen zur Anpassung an den ATMEGA168P (Hardware Pin an PORTD2) in irmpconfig.h gemacht. Nirgendwo konnte ich allerdings die F_CPU Anpassung finden, doch das Programm wurde fehlerlos compiliert. Da ich annahm, dass irgendwo F_CPU auf 8MHz definiert ist, habe ich in irmp-main-avr.c statt #error ... in #define F_CPU 16000000UL; geändert. Damit ich überhaupt was sehe, habe ich weiter im Demo-Programm die Endlos-Schleife mit einer blinkenden LED an PORTB5 angepasst for (;;) { if (irmp_get_data (&irmp_data)) { // got an IR message, do something if(PINB & (1<<5)) {PORTB &= !(1<<5);} // LED an else {PORTB |= (1<<5);} // LED aus } } Danach im Studio7 compiliert und per usbasp in den ATMEGA geladen. Mit der MEDION Fernbedienung für MD84627 ging nichts. Dann habe ich meine PANASONIC FB genommen aber auch damit blinkt die LED nicht. Dann PANASONIC =1 und Kaseikyo =0 auch kein Erfolg. Welchen Fehler mache ich? mfG Frewer
:
Verschoben durch Admin
Nur weil Du F_CPU auf einen bestimmten Wert setzt, tickt die CPU noch lange nicht mit dieser Frequenz - das kannst Du einzig über das korrekte Setzen der AVR Fuses bewirken. Also, schreibe Dir mal ein Minimalprogramm mit LED an - 500 ms warten - LED aus - 500 ms warten, und schaue, ob die LED tatsächlich im 1s-Rhythmus blinkt. Erst dann weitermachen mit IRMP, wenn das erfolgreich war!
Ja Thilo, das ist mir bekannt. In meinen Programmen wird zuerst mal F_CPU definiert, da zBsp sonst die util/delay.h einen Fehler meldet. Mich machte nur stutzig, dass bei meiner F_CPU Definition der Compiler ein "redefine..." als Warnung meldet. Habe nunmehr festgestellt, dass in der Toolchain F_CPU auf 8MHz voreingestellt ist. Das habe ich m.E. jetzt mit der Neudefinition auf 16MHz geändert. Die LED sollte im irmp-Hauptprogramm nur melden, dass die irq-Routine mit einer Erkenntnis zurück ins Hauptprogramm gekommen ist (in der for-Schleife unter "// got a message" etwas angezeigt wird). Das aber tut es nicht. mfG Frewer
Werner F. schrieb: > Welchen Fehler mache ich? - das Signal kommt nicht an - dein Empfänger ist kaputt - ... - das Signal kommt an, wird aber nicht dekodiert - IRMP kann es nicht - ... - das Signal kommt an, wird dekodiert, aber dein Programm hat einen Fehler - ...
Werner F. schrieb: > if(PINB & (1<<5)) {PORTB &= !(1<<5);} // LED an > else {PORTB |= (1<<5);} // LED aus warum nicht einfach ein PORTB &= ~(1<<PB5) // toggle LED
hui schrieb: > falsches Forum übrigens Und wie komme ich ins richtige? Habe im wiki die Anweisung ausgfüllt, that's it. 2. habe mit dem Oszillographen verifiziert, dass das Signal einwandfrei an PIND2 ansteht (TSOP gemäß Bild im Artikel). Mein Test war mit der PANASONIC FStg ebenfalls nicht erfolgreich. Es sollte daher am Programm liegen. Doch fehlt mir irgendwie eine Beschreibung, wie man mit dem Programm umgeht. Die Analyse des Programms ist für mich schwierig, da die C-Programmierung aus meiner Sicht ganz schön den Compiler ausreizt. 3. Das MEDION-Protokoll: (nach dem TSOP Impulse L) Sync: 9,2ms L + 4,5ms H Daten: 0,76ms L + 0,45ms H bzw 0,76ms L + 1,6ms H insgesamt Sync + 32 Daten + Endbit(0,76ms L) 4. Horst: na klar geht einfacher, macht aber den "Bock nicht fett" und löst mein Problem nicht! mfG Frewer
Werner F. schrieb: > macht aber den "Bock nicht fett" doch, du benutzt das falsche NOT, das logische und nicht das bitweise. wobei ein &= auch nicht umschaltet, dafür bräuchte man ein EXOR, also ^=.
Johannes S. schrieb: > wobei ein &= auch nicht umschaltet, dafür bräuchte man ein EXOR, also > ^=. Ich hab ja auch Unsinn geschrieben, das währe LED aus. Ich wollte schreiben: PORTB ^= (1<<PB5) // toggle LED
Werner F. schrieb: > Und wie komme ich ins richtige? Habe im wiki die Anweisung ausgfüllt, > that's it. Entweder im entsprechenden Thread (Beitrag "IRMP - Infrared Multi Protocol Decoder"), oder allgemein: https://www.mikrocontroller.net/forum/mikrocontroller-elektronik
1. hui: Das Original steht im Forum "Projekte&Code" und meine Frage dito. Demnach bin ich vollkommen richtig hier. 2. irmp scheint zu laufen. Jedenfalls leuchtet meine LED, wenn ich die FStg gedrückt habe. Es war ein Anfängerfehler, hatte vergessen den LED-PORT auf Ausgang zu setzen. 3. mein nächster Schritt ist jetzt die Anzeige des Codes über eine LCD-Anzeige oder über den UART auf den PC. Mal sehen. mfG Frewer
Angehängte Dateien:
-
PuC.jpg
31 KB
Frewer schrieb: > Es war ein Anfängerfehler, hatte vergessen den > LED-PORT auf Ausgang zu setzen. was den Fehler mit dem falschen Operator immer noch einen Fehler sein lässt. > Welchen Fehler mache ich? keine Fragen, Projektvorstellung mit HW und SW. Mich stört es nicht weil ich sowieso immer über https://www.mikrocontroller.net/forum/all hier einsteige.
Angehängte Dateien:
-
irmp-fcpu.png
9,8 KB
Werner F. schrieb: > Da ich annahm, dass irgendwo F_CPU auf 8MHz definiert ist, habe ich in > irmp-main-avr.c statt #error ... in #define F_CPU 16000000UL; geändert. Das ist schlecht, mache das bitte rückgängig! Der #error ist bewusst gewählt! F_CPU sollte genau einmal definiert sein, und zwar nicht in den C-Sources oder Headers, sondern in den IDE-Einstellungen. Sonst gibt es Kuddelmuddel bei der Übersetzung jedes C-Files, welches F_CPU benötigt. Wie willst Du einen einheitlichen Wert garantieren, wenn nicht in den Projekteinstellungen oder im Makefile? Du bekommst beim Compilieren eine Fehlermeldung, wenn F_CPU nicht in den Projekteinstellungen definiert ist. Wenn Du keine bekommst, dann scheint F_CPU im Projekt bereits definiert zu sein. Suche danach und stelle den Wert korrekt ein! Wenn Du im IRMP Artikel unter https://www.mikrocontroller.net/articles/IRMP#Source-Code nachschaust, wirst Du auch ein dickes rotes Kästchen sehen, welches die richtige Anwendung von F_CPU erläutert, siehe auch Bild. Offenbar hast Du das rote Kästchen übersehen.
Danke Frank für die Info. Ich habe das rote Kästchen sehr wohl gelesen, den unteren Teil aber nicht wirklich verstanden. Bin halt weit entfernt vom Programmier-Profi. Da ich Studio7 benutze, habe ich mit dem Makefile nichts zu tun und wohl auch keinen Einfluss darauf. Ein sog. Projektfile ist mir bisher unbekannt, obwohl ich schon viele Projekte mit AVR's in Ass und C hinter mir habe. Bei der Suche nach einer ersten Definition von F_CPU meldet Studio7 eine Datei "irmp". Die sieht nach einem Projektfile aus. Wie ich den allerdings erzeuge, ist mir unklar. Ich habe nach Recherche im Internet (Wolles Elektronikkiste) gelernt, dass ich mit dem "Hammer" Symbol einen File öffne, in dem der µC unter "Device" und unter "toolchain-Symbol" die Frequenz eingegeben werden kann. Allerdings ist mir diese Datei immer nur dann aufgefallen, wenn ich in einem Projekt den Simulator benutzen will und dieser in dieser Datei unter "tools" noch nicht angewählt ist. Mein Schluss aus diesem Vorgehen war, dass diese Angaben nur für die Simulatornutzung relevant sind. Neue Erkenntnis: Ist wohl nicht so! Habe jetzt in dieser Datei die Frequenz auf 16MHz geändert und damit erscheint auch kein Fehler mehr. mfG Frewer
Frewer schrieb: > Da ich Studio7 benutze, habe ich mit dem Makefile > nichts zu tun und wohl auch keinen Einfluss darauf. Doch. In den Project Settings findest du auch optionale Ergänzungen des make Files und da schreibst du rein
1 | -D F_CPU 16000000 |
Es ist auch egal dabei, ob du Atmel Studio 7 oder Microchip Studio 7 benutzt, das ist die gleiche IDE, nur, das Microchip den Namen geändert hat und ein paar Links auf Microchip umgebogen hat. IRMP ist recht gutmütig, du solltest aber nach erfolgreichem Empfang auch aufs Protokoll und die richtige Subadresse prüfen, bevor du mit den Daten was anfängst:
1 | #define FB_VIDEOUP 0x000a
|
2 | // Empfangsschleife
|
3 | for (;;) |
4 | {
|
5 | if (irmp_get_data (&irmp_data)) |
6 | {
|
7 | if ((irmp_data.protocol == 0x1C) && (irmp_data.address == 0x0113)) |
8 | {
|
9 | switch (irmp_data.command) { |
10 | case FB_VIDEOUP : if (DAC[0] < 63) DAC[0]++; |
11 | // und so weiter
|
:
Bearbeitet durch User
Vielen Dank für die Info. Ich habe mittlerweile das Thema Projektfile-Makefile kapiert und angepasst. Und in Zukunft werde ich darauf achten, da ich immer mal wieder Probleme mit der Frequenzeinstellung im Simulator hatte. Das ist jetzt klar soweit. Bin gerade dabei, meinem "alten" PC mit WIN10 ein Terminalprogramm zu verpassen, damit ich mit dem UART den Code meiner FStg mal sehen kann. Bin gespannt. mfG Frewer
Frewer schrieb: > Bin > gerade dabei, meinem "alten" PC mit WIN10 ein Terminalprogramm zu > verpassen, damit ich mit dem UART den Code meiner FStg mal sehen kann. Das klingt doch gut. Ich habe dazu einen Mega328 mit LC-Display und so gut wie allen Protokollen programmiert, der mir auf dem Display Protokoll, Subadresse und Kommandocode anzeigt. Damit schnüffele ich nach Bedarf unbekannte Fernbedienungen aus.
kannst Du Deine Lösung mit dem LCD nicht hier mal vorstellen? Würde mich sehr interessieren, bevor ich loslege und meinen PC aktiviere. Die Idee gefällt mir sehr gut.
habe mit der RS232 Schnittstelle und irmp-main-avr-uart.c die MEDION FStg getestet mit folgendem Ergebnis: protocol: 0x02 -> NEC address : 0xFF00 command : 0x0045 -> Ein/Aus flag : 0x00 manchmal 0x01 oder 0x02 Das scheint mit dem Oszillogramm übereinzustimmen (Sync + 33Bit). Der Test mit der Panasonic FStg bringt das Ergebnis: protocol: 0x05 -> Panasonic address : 0x2002 command : 0x8100 -> Taste "1" flag : 0x00 immer Auch das scheint mir logisch. Die Überprüfung mit dem Oszi folgt. Ansonsten vielen Dank für die positiven Kommentare, die mich ein Stück weiter brachten. Mein nächster Schritt ist das Ganze auf einem LCD Display anzuzeigen und dann einen entsprechenden IR-Sender zu bauen. mfG Frewer
Werner F. schrieb: > Ansonsten vielen Dank für die positiven Kommentare, die mich ein Stück > weiter brachten. Mein nächster Schritt ist das Ganze auf einem LCD > Display anzuzeigen und dann einen entsprechenden IR-Sender zu bauen. > mfG Frewer Hallo, das Projekt hier kannst Du ja mal als Anregung nehmen: https://www.mikrocontroller.net/articles/IR-LCD#Software ...und Deines dann in Projekte vorstellen... Grüße!
Frewer schrieb: > kannst Du Deine Lösung mit dem LCD nicht hier mal vorstellen? Ich hänge dir mal die main.c aus dem Projekt an. Das ist aber die gleiche wie die IRMP demo, nur das ich per define auf LCD_OUTPUT umschalten kann. Als LCD Treiber wird die Bibliothek von Peter Fleury benutzt, die mit den HD44780 kompatiblen Modellen gut spielt. Die Bibliothek findest hier: http://www.peterfleury.ep?zy.com/?i=1 Weil hier irgendein Spamschutz des Forums zuschlägt, bitte ep?zy durch epizy ersetzen.
merci Matthias für die "main.c". Die Fleury Lib benutze ich auch, allerdings an meine Bedürfnisse angepasst. Eine offene Frage habe ich doch noch: Beim Testen von FStgen wird neben Adresse und Command stets noch der Begriff flag angezeigt. Abhängig von der Dauer der Übertragung beinhaltet flag unterschiedliche Werte (mal 00,01,02,etc). Was bedeutet flag?? mfG Frewer
Werner F. schrieb: > Die Fleury Lib benutze ich auch, > allerdings an meine Bedürfnisse angepasst. Das muss man ja immer machen, deswegen habe ich das weggelassen. > Was bedeutet > flag?? Das sind Repeatcodes. M.W. gibt IRMP diese aus, wenn es von der FB diese Codes als 'wiederholter Code' bekommt - z.B. für Tasten wie Lautstärke oder Programmzappen. Wenn Frank hier mal vorbeikommt, kann er da sicher was zu sagen. Jedenfalls kann das sinnvoll sein, wenn du ein Kommando nur dann akzeptieren willst, wenn es wiederholt wird, oder es nur beim ersten Mal auswerten möchtest.
Werner F. schrieb: > Abhängig von der Dauer der Übertragung beinhaltet flag unterschiedliche > Werte (mal 00,01,02,etc). Was bedeutet flag?? Ist im IRMP-Artikel hier beschrieben: https://www.mikrocontroller.net/articles/IRMP#%22Entprellen%22_von_Tasten Das Flag IRMP_FLAG_REPETITION wird dann gesetzt, wenn der Frame aufgrund eines langen Tastendrucks wiederholt wurde. Willst Du nur den ersten Frame berücksichtigen und alle folgenden identischen Frames ignorieren, dann unterscheide dies anhand des Flags, siehe auch den Beispielcode im oben angegebenen Link - Kapitel "Entprellen von Tasten". Dieser ist ausführlich kommentiert. Das kann sinnvoll sein, damit eine mit der Taste verbundene Aktion nicht versehentlich mehrfach ausgeführt wird. Willst Du aber eine Lautstärke-Regelung bauen, wo ein langes Drücken durchaus sinnvoll ist, dann ignoriere das Flag - zumindest für diese Taste.
Entschuldige Frank! Mit dem Lesen das ist so eine Sache. Habe viel früher abgebrochen, da das Entprellen für meine ersten Tests gar keine Rolle spielt und ich eigentlich ja nur mal den Code einer anderen Fstg MEDION sehen wollte. Beim Testen mit meinen Panasonic Fstgen (TV und DVD Recorder) fiel mir ein auf, dass das Ergebnis mit der Beschreibung des Panasonic Codenicht übereinstimmt. Der Code wird wie folgt beschrieben und sieht auf dem Oszi auch so aus
1 | Frequenz 32 (33) kHz. |
2 | Kodierung Pulse Distance |
3 | Frame 1Sync + 48 Bits (6 Byte) |
4 | Sync-Signal + 3 Standard-Bytes + 1 Byte GeräteKennung + 1 Byte Adresse + 1 Byte Kommando. |
5 | Sync-Signal : H = 3,5 ms, L = 1,7 msec |
6 | Log 0: 0,6ms H + 0,6 ms L |
7 | Log 1: 0,6ms H + 1,2 ms L |
Ergebnisse, die ich mit dem Oszi ermittelt habe:
1 | Player : SyncSignal + 40 04 0D 00 88 85 = StandBy-Taste |
2 | Recorder: SyncSignal + 40 04 0D 08 88 8D = StandBy-Taste |
Der gleiche Versuch mit IRMP ergibt aber
1 | TV : Sync + 20 02 83 D0 = StandBy-Taste |
2 | Recorder: Sync + 20 02 B3 D0 = StandBy-Taste |
Meines Erachtens fehlt da was bei der IRMP Auswertung. Auch vom Kaseikyo Code habe ich eine Beschreibung, die aber nur teilweise zum Panasonic passt.
1 | KASEIKYO |
2 | Frequenz 56 kHz |
3 | Kodierung Pulse Distance |
4 | Frame 1 Start-Bit + 48 Daten-Bits + 1 Stop-Bit |
5 | Daten 16 Bit Hersteller + 4 Parity-Bit + 4 Genre1-Bit + 4 Genre2-Bit + 10 Kommando-Bit + 2 ID-Bit + 8 Parity-Bit |
6 | Start-Bit 3,38ms H + 1,69ms L |
7 | Log-0 423µs H + 423µs L |
8 | Log-1 423µs H + 1269µs L |
9 | Stop-Bit 423µs H |
10 | Wiederholung keine |
11 | Tasten-Wiederholung N-fache Wiederholung des Original-Frames innerhalb von 100msec |
12 | Bit-Order LSB first |
Wie gehe ich damit um? guten Rutsch ins neue Jahr und hoffentlich kriegen wir mal Corona in den Griff Frewer [Mod: Formatierung eingefügt]
:
Bearbeitet durch Moderator
Werner F. schrieb: > dass das Ergebnis mit der Beschreibung des Panasonic Codenicht > übereinstimmt. Panasonic benutzt diverse Protokolle, nicht nur sein hauseigenes. > Ergebnisse, die ich mit dem Oszi ermittelt habe: > Player : SyncSignal + 40 04 0D 00 88 85 = StandBy-Taste > Recorder: SyncSignal + 40 04 0D 08 88 8D = StandBy-Taste > Der gleiche Versuch mit IRMP ergibt aber > TV : Sync + 20 02 83 D0 = StandBy-Taste > Recorder: Sync + 20 02 B3 D0 = StandBy-Taste Was heisst das? IRMP gibt keine RAW-Codes aus, sondern berechnet eine Adresse und ein Kommando. Wie kommst Du auf die Zahlenfolge "20 02 83 D0"? Hast Du dabei beachtet, dass IRMP sowohl PANASONIC als auch KASEIKYO als LSB-codiert betrachtet? also wortweise von rechts nach links? Wenn ich mir die Beschreibung von PANASONIC unter https://www.mikrocontroller.net/articles/IRMP#PANASONIC anschaue, dann steht da:
1 | Frame 1 Start-Bit + 56 Daten-Bits + 1 Stop-Bit |
2 | Daten 24 Bits (010000000000010000000001) + 16 Adress-Bits + 16 Kommando-Bits |
Das heisst: Die Panasonic schickt 56 Datenbits, wobei die ersten 24 Bits fix sind. Diese werden von IRMP zwar geprüft, aber nicht in der Adresse und im Kommando hinterlegt. Dann bleiben 16 + 16 Bits im LSB-Format übrig, die IRMP dann noch "von rechts nach links umdreht", damit sie den korrekten Code ergeben. Wenn das keine Erklärung für Dich ist, dann aktivierst Du am besten mal in irmpconfig.h die Konstante IRMP_LOGGING und erstellst ein paar Scans über UART mit einem Terminal-Programm, z.B. Putty. Nachdem Du sie hier eingestellt hast (als Anhang - unter Angabe von F_INTERRUPTS), kann ich mir diese dann anschauen und auch mit dem IRMP-Analyzer (irmp-xxx -a unter Linux) prüfen. Dann bekomme ich ziemlich schnell raus, welches Protokoll das ist. (P.S. Ich habe Dein Posting mit [ code ] ... [ /code ] (ohne Leerzeichen) neu formatiert, damit das auch auf Mobilgeräten mit Proportionalschrift lesbar ist.)
:
Bearbeitet durch Moderator
Werner F. schrieb: > Frequenz 32 (33) kHz. > Frequenz 56 kHz Beide Fernbedienungen, vor allem die KASEIKYO, sind mit einem normalen IR Empfänger wie dem TSOP 31238 nur grenzwertig zu empfangen. für die KASEIKYO wird auf jeden Fall ein Receiver für 56kHz nötig, wie der TSOP31256.
Hallo Frank, hallo Matthias, zuerst mal vielen Dank für die Erklärungen, die ich beim Lesen verstanden habe und bei genauerer Bewertung werde zuordnen können. Denn klar, ich habe die fest codierten Bits auch ausgelesen, da sie in meiner Beschreibung einen Herstellercode sind. Wenn ich die weglasse, dann komme ich der Sache ja schon näher. 1. Meine Panasonic Fernsteuerung für den DVD-Recorder ist schon einige Jahre alt (>10) und so alt ist auch meine Code-Beschreibung. Deshalb vielleicht die Unterschiede. 2. Ich lese den Code mit Deinem Programm IRMP-MAIN-AVR-UART.C aus, das mir das Protokoll, die Adresse, den Command und das Flag ausgibt. Das ganze Protokoll heißt original mit dem Terminal "hterm" empfangen: protocol: 0x05, address: 0x2002, command: 0x83D0, flags: 0x00. Ich habe das nur umgeschrieben zum Vergleich mit meinen alten Werten, die ich früher mal (2009) neben dem Oszi mit einem Programm auf einem AT89S51 ermittelt hatte. 3. meine Beschreibung des KASEIKYO Code (auch >10Jahre) diente nur der Aussage im IRMP Artikel, dass dieser und Panasonic so gleich seien, dass das Protokoll 5 für beide angegeben wird. Ich habe weder eine solche FStg noch einen solchen 56kHz Empfänger. Soweit so gut, ich muss jetzt erst einmal die restlichen Erklärungen verdauen, mal den Oszi "anschmeissen", um die ganzen Details zu verstehen und Deine Änderung (irmpconfig.h) mit Ausdruck machen. Ich melde mich wieder im neuen Jahr. mfG Frewer
Hallo Frank, habe die Änderung mal ausprobiert und hänge die Ergebnisse für die alte PA Recorder FStg und die neue PA TV FStg an. Bin gespannt über die Ergebnisse. mfG Frewer
Matthias S. schrieb: > für die > KASEIKYO wird auf jeden Fall ein Receiver für 56kHz nötig, ich hatte gestern noch eine Panasonic mit TSOP31238 ausgelesen, zumindest auf kurze Entfernung hat es geklappt. Haben die Kaseiykos alles 56 kHz? Und einige Tasten haben andere Flags, die zumindest in meiner alten IRMP von 2016 nicht dokumentiert sind:
1 | proto 5 addr 8194 cmd 34928 flags 90 name KASEIKYO : guide 8870 |
2 | proto 5 addr 8194 cmd 33536 flags 20 name KASEIKYO : input TV 8300 |
3 | proto 5 addr 8194 cmd 32848 flags 0 name KASEIKYO : input AV 8050 |
ist das in neueren IRMP Versionen anders?
Hallo Johannes, also ich kenne KASEIKYO erst seit ich IRMP durchgearbeitet habe. Ich kann es auch nicht ausprobieren, keine FStg. Dagegen besitze ich wie gesagt PANASONIC alt und neu, sowie eine Medion FStg für einen KüRadio. Mit Panasonic habe ich kein Entfernungsproblem außer man geht aus der Reichweite heraus. Mit dem TSOP, den ich nutze, gibt es da keine Schwierigkeiten. Es ist interessant, dass bei Dir die Codes ähnlich sind wie bei mir (address: 0x2002, cmd: 0x8870). Warum die flags so große Zahlen haben ist mir unklar (es sei denn, Du hast lange die Taste gedrückt). Ich bin sehr gespannt, was Frank zu den Ausdrucken sagt. mfG Frewer
die Adresse ist gleich, 0x2002 = 8194 dezimal. Das Flag für lange Tastendrücke ist 1, ich hänge mal die ganze Liste an, da sieht man das die Flägs wohl Gruppen wie AV oder andere Sonderfunktionen bedeuten. Die 56 kHz stehen auch in einer im IRMP Artikel verlinkten Diplomarbeit, wird also so sein. Habe die FB auch nicht mehr hier und kann es jetzt nicht nachmessen. Die Filter in den TSOP sind aber sehr breitbandig und es wird dann nur die Reichweite beeinflussen. War aber ein guter Hinweis von Matthias.
Johannes S. schrieb: > ich hatte gestern noch eine Panasonic mit TSOP31238 ausgelesen, > zumindest auf kurze Entfernung hat es geklappt. Jaja, das sollte auch meistens klappen, vor allem auf kurze Entfernung. Mein IRMP Tester hat jedenfalls keine Probleme, solange es nicht um Exoten geht, liest also auch Panasonic. Ich nutze dazu die 38kHz Billig-Sharps von Pollin, die es interessanterweise in 56kHz auch gibt: https://www.pollin.de/p/infrarot-empfaenger-sharp-gp1u287y-56-8-khz-10-stueck-121085 https://www.pollin.de/p/infrarot-empfaenger-sharp-gp1uv701qs-38-khz-10-stueck-121082 https://www.pollin.de/p/infrarot-empfaenger-sharp-gp1ud262rk-36-7-khz-10-stueck-121087 Und es gibt moch mehr, auch mit 36,7kHz (Einfach mal nach Sharp suchen). Bei den Preisen kann man wirklich nicht meckern, da sind immer 10 Stück im Tütchen. Wünsche wohl zu rutschen! Johannes S. schrieb: > Haben die Kaseiykos > alles 56 kHz? Ich habe nicht die geringste Ahnung. Bin über 'Kaseiyko' erst im Zusammenhang mit IRMP gestolpert. Frank hat auf Sonderwünsche super reagiert und hat immer wieder neue Protokolle addiert.
:
Bearbeitet durch User
Werner F. schrieb: > Warum die flags so große Zahlen haben ist mir unklar (es sei denn, Du > hast lange die Taste gedrückt). > Ich bin sehr gespannt, was Frank zu den Ausdrucken sagt. Um die Flags mit den "großen Zahlen" speziell bei Kaseikyo zu erklären, muss ich etwas weiter ausholen. Ich hatte das zwar schon mal vor einigen Jahren im IRMP-Thread erklärt, versuche es aber jetzt nochmal. IRMP hat den Anspruch, das verwendete IR-Protokoll zu "verstehen". Das heisst, es extrahiert aus den Daten lediglich die tatsächlichen Nutzinformationen. Ein IR-Frame besteht aber aus noch viel mehr, nämlich auch aus Redundanzen durch (optional invertierte) Wiederholungen oder Parity-Bits oder CRCs. Diese redundanten Infos gehören aber nicht zu den Nutzdaten, sondern dienen lediglich als Hilfe, um die Gültigkeit eines IR-Frames zu überprüfen. IRMP extrahiert also aus den Rohdaten ("raw") die Nutzinformationen ("cooked") und prüft diese gegen die redundanten Daten. Ist die Prüfung erfolgreich, liefert irmp_get_data() TRUE zurück - sonst nicht. In diesem Fall liegen in irmp_data.address die Geräteadresse und in data.command das Kommando vor. So schafft es IRMP, auch Frames, die wesentlich länger als 16+16=32 Bits sind, redundanzfrei in lediglich 32 Bit zu speichern. Aus diesen beiden Angaben kann IRSND (das Gegenstück zu IRMP) den IR-Frame verlustfrei wieder reproduzieren - also aus den Cooked-Daten den Raw-Frame generieren und auf einer IR-Diode wieder ausgeben. Das einzige Protokoll, wo es IRMP nicht schafft, die Nutzdaten auf 16+16=32 Bits einzustampfen, ist KASEIKYO. Ein Kaseikyo-Frame besteht aus 48 Bits Daten, von denen 36 Bits tatsächlich Nutzdaten und zusätzlich 12 Bits Parity-Bits sind, siehe auch https://www.mikrocontroller.net/articles/IRMP#KASEIKYO . Von daher gibt es das Problem, dass 36 Bits in die 32 Bit-Datenstruktur von IRMP "gepresst" werden müssen. Ich habe das so gelöst, dass ich die Bedeutung von irmp_data.flags erweitert habe, nämlich so:
1 | Das Kommando setzt sich zusammen aus: |
2 | 1. irmp_data.command |
3 | 2. irmp_data.flags im oberen Nibble (obere 4 Bits) |
So bleibt die Kompatibilität zu Non-Kaseikyo-Protokollen bestehen, da nämlich bei allen anderen Protokollen die 4 oberen Bits von flags immer 0 sind. Und auch nur in Ausnahmefällen ist das obere Nibble beim Kaseikyo-Protokoll ungleich 0, denn hier speichert IRMP die 4 Genre2-Bits von Kaseikyo, die oft unspezifiert und damit 0 sind. Das heißt: Um einen mit IRMP empfangenen Frame mittels IRSND wieder auszusenden, muss man folgendes tun:
1 | 1. irmp_data.address mit der empfangenen Adresse füllen |
2 | 2. irmp_data.command mit dem empfangenen Kommando füllen |
3 | 3. Im oberen Nibble von irmp_data.flags das empfangene obere Nibble füllen. |
4 | 4. Im unteren Nibble von irmp_data.flags die Anzahl der Wiederholungen setzen (Wert von 0..15) |
Das "Schöne" an dieser Erweiterung ist: Der Schritt 3 kann kann bei allen Protokollen außer Kaseikyo entfallen, bietet also höchstmögliche Rückwärtskompatibilität. Und selbst bei Kaseikyo ist das obere Nibble von flags oft 0. Als Alternative könnte ich auch IRMP auf 32 Bit Adresse und 32 Bit Kommando aufbohren. Auf 32-Bittern wie STM32 wäre das auch kein Problem, auf AVRs könnte das bei einigen Anwendungen jedoch zu Problemen führen, da hier die ISR ziemlich zeitintensiv 32-Bit-Variablen bearbeiten (im wesentlichen shiften) müsste - was nicht gerade zur Stärke eines AVR-µCs gehört. Von daher wurden mir von einigen Usern Probleme gemeldet, die eine spezielle IRMP-Version mit der Möglichkeit, IRMP auf 32 Bit umzustellen, getestet hatten. Ich hoffe, dass ich damit alle Klarheiten beseitigt habe. Ja, ich müsste das spezielle KASEIKYO-Verhalten mal im Artikel dokumentieren. Bisher bin ich aber aus Faulheit nicht dazu gekommen ;-) P.S. In IRMP testet man das Wiederholungs-Bit natürlich immer mit:
1 | if (irmp_data.flags & IRMP_FLAG_REPETITION) |
bzw. das Loslassen einer Taste (optional) mit:
1 | if (irmp_data.flags & IRMP_FLAG_RELEASE) |
so dass ein etwaiger Wert im oberen Nibble in irmp_data.flags überhaupt nicht stört. Keinesfalls sollte man Frame-Wiederholungen mit
1 | if (irmp_data.flags > 0) |
testen, denn das hat mit irgendwie gesetzten Bits in Flags überhaupt nichts zu tun!
:
Bearbeitet durch Moderator
sehr schön, gut zu wissen. Die Lösung mit den Flags reicht mir, Kompatibilität ist da sicher wichtiger.
Johannes S. schrieb: > Haben die Kaseiykos alles 56 kHz? Das weiß ich auch nicht, aber ich hatte damals im IRMP-Artikel zu Kaseikyo (hier auch "Japan-Code" genannt) zwei Literatur-Hinweise hinterlegt: https://www.mikrocontroller.net/articles/IRMP#KASEIKYO-Protokoll_(auch_%22Japan-Protokoll%22) Der erste Link dokumentiert Kaseikyo mit 56 kHz, der zweite mit 38 kHz. Den usprünglichen Link auf die offizielle Kaseikyo-Dokumentation, nach der ich damals das Protokoll implementiert hatte, finde ich nicht mehr.
die FB habe ich ja mit einem 38 kHz Empfänger ausgelesen bekommen, die Sendeseite kann ich ja umschaltbar machen um sicher zu gehen, da ist die Trägerfrequenz ja eine SW Sache.
Werner F. schrieb: > Hallo Frank, > habe die Änderung mal ausprobiert und hänge die Ergebnisse für die alte > PA Recorder FStg und die neue PA TV FStg an. Bin gespannt über die > Ergebnisse. Danke für die Scans. Dein Recorder bzw. Dein TV benutzt ein etwas abgeändertes Protokoll zu dem, was ich unter PANASONIC implementiert habe. Damals lagen mir nur Daten für einen speziellen Panasonic-Beamer vor. Deine FBs senden lediglich 48 statt 56 Bits, sind aber vom Timing her sehr ähnlich und innerhalb der Toleranzen. Um diese FBs zu unterstützen, müsste ich ein weiteres Protokoll PANASONIC2 einführen. Wenn dies für Dich wichtig ist, kann ich das implementieren. Dauert aber ein paar Tage, da ich momentan wenig Zeit dafür habe.
vielen Dank Frank für das Angebot, Dich um die Ergänzung zu bemühen. Mir ging es um meine Medion FStg. Die Panasonic habe ich nur benutzt, um IRMP bedienen zu lernen (MEDION wird im Artikel nicht angesprochen) und meinen TSOP-> UART Adapter auszutesten. Und dafür hat es ja prima gereicht. Mein Ziel ist es für den Medion FStg Sender eine Alternative zu bauen, mit dem ich Tastenfunktionen kreieren kann. Ich habe nämlich mehrere Geräte, die auf Tasten der MEDION FStg ansprechen, aber wohl andere Tastencodes zusätzlich benötigen (was mir beim Auslesen der FStg auch deutlich geworden ist). Dazu will ich Deine Software IRSND benutzen. Mal sehen, ob ich das hinkriege im neuen Jahr. Gruß Frewer
Werner F. schrieb: > Mein Ziel ist es für den Medion FStg Sender eine Alternative zu bauen Offenbar hast Du ja schon herausgefunden, welches Protokoll die Medion benutzt, nämlich NEC. Das wird auch mit IRSND out-of-the box gehen, ich selber habe schon mehrere FBs mit IRSND und NEC-Protokoll realisiert.
Frank M. schrieb: > Das wird auch mit IRSND out-of-the box gehen Überhaupt keine Frage. Falls der TE Interesse hat, poste ich gerne den Code meiner Spitzenfernbedienung :-P: Beitrag "Re: Quick&dirty - schnelle Problemlösungen selbst gebaut" Allerdings gabs dazu nie einen Schaltplan. Sollte aber aus dem Code hervorgehen. Werner F. schrieb: > MEDION wird im Artikel nicht angesprochen Aus gutem Grund, Medion benutzt jedes Protokoll, was nicht bei 3 aufm Baum ist :-) Ich hatte hier auch schon einen Medion TV mit RC5.
:
Bearbeitet durch User
Hallo Matthias, bin sehr interessiert an Deinem Code. Habe mir Deine Lösung angesehen und finde die super einfach für die Anwendung, die ich mir vorstelle. Schaltplan ist kein Problem. Thanks im Voraus. mfG Frewer
Du findest auch noch weitere Anregungen zu IRMP-Anwendungen hier im Artikel: https://www.mikrocontroller.net/articles/IRMP#Weitere_Artikel_zu_IRMP Hier zum Beispiel eine lernfähige FB mit nur 5 Tasten (max. 3-fach belegt): https://www.mikrocontroller.net/articles/DIY_Lernf%C3%A4hige_Fernbedienung_mit_IRMP Makrofähig ist diese auch noch, d.h. Du kannst bestimmte Sequenzen von IR-Frames automatisch "abspielen".
:
Bearbeitet durch Moderator
Werner F. schrieb: > Thanks im Voraus. Da nich' für :-) Frank ist der Held - anbei das Archiv, sollte ohne Probleme auf Atmel Studio 7 aka Microchip Studio 7 kompilieren. Die Matrix sind 2 Zeilen an PortD und 2*8 Tasten, die an Port A abgefragt werden. Beim Tastendruck wacht der MC auf und scannt die Tasten. Die beiden anderen PORTD sind auch verwendbar, im Moment aber für Debug Zwecke missbraucht. Mittlerweile habe ich die Rundzelle durch einen flachen Telefonakku ersetzt, dann ist das Ding etwas handlicher. Hält nach wie vor seit Monaten ohne Nachladen. Am IR Ausgang hängt ein BC547 mit 1k Vorwiderstand an der Basis. Der Kollektor treibt die IR-LED (oder auch 2 parallel) über jeweils einen 27 Ohm Widerstand.
:
Bearbeitet durch User
Vielen Dank Matthias, werde das Ganze jetzt mal verdauen (bin schon etwas älter und langsamer) und die Elektronik konkret aufbauen. ZZt bin ich noch auf einem Brettboard. Da sieht alles etwas unübersichtlich aus. Der Empfänger läuft aber einwandfrei mit einem TSOP ?? und ATmega168p (Nano Arduino Verschnitt von Pollin auf 5V getrimmt). Melde mich hier wieder, wenn es soweit ist. Habe doch noch einige gedankliche Probleme mit Franks Programmen, die ich noch gerne abklären möchte. Muss aber meine Verständnisfragen zuerst mal noch konkretisieren. ZBsp ist mir noch unklar, wie ich die beiden selbstständigen Programme IRMP.c und IRSND.c zusammenpacke. In den config.h Dateien sind ja viele gleiche Pakete. Vielleicht habe ich aber beim mehrfachen durchlesen der vielen Artikel zum Thema wieder etwas übersehen, nicht kapiert oder.. mfG Frewer
Einfach gesagt, für einen IR Sender brauchst du nur IRSND und für einen Empfänger nur IRMP. Der kleine ATTiny2313 könnte gar nicht beides schlucken, da er nur 2kByte Flash besitzt. Man bekommt zwar sicher 2-3 Protokolle da rein, aber nicht Sender und Empfängersoftware gleichzeitig. Das Problem gibts beim Mega328 natürlich nicht. Für mich war wichtig, das die Fernbedienung mit einer LiIon Zelle (3,5 - 4,2 Volt) läuft. Deswegen auch nur 8MHz Takt. Willst du einen MC schneller takten, musst du ihm nämlich auch die vollen 5V geben. Der o.a. IRMP Schnüffler mit LCD läuft auch mit einem Mega328, damit die ganzen Protokolle reinpassen. Werner F. schrieb: > (bin schon > etwas älter und langsamer) Lass dir Zeit, man wird ja nie zu alt, um etwas zu lernen, das hält frisch. Bin auch nicht mehr der Jüngste, habe aber Spass am Basteln und Werkeln. Und solange es Winter bleibt, ist es im Haus gemütlicher als draussen, also wird gelötet und programmiert :-)
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.