Hallo, ich überlege ein Projekt (Beitrag "RGB Moodlight mit STM8") mit der Unterstützung für verschiedene Fernbedienungen auszustatten. Nun könnte ich zwar einfach alle Protokolle in IRMP aktivieren, aber dann sprenge ich vermutlich das Flash-Limit. Deswegen meine Umfrage: Wenn ihr schon Projekte mit IRMP gebaut habt, was waren die IR-Proto- kolle die ihr genutzt habt? Bitte nennt jedes Protokoll und wie oft (Schätzung reicht) ihr es verwendet habt. Bitte jeder nur seine eigenen Angaben. Ich werde nach ca. einer Woche mal alle Posts zusammenfassen. Ich fange mal an: ----- NEC 3x
:
Verschoben durch User
Fast ausschließlich NEC (Protokol 2) weil ich dutzende kleine Fernbedienungen habe die alle NEC sprechen.
Keins. Mein NEC-Protokoll Bedarf ist schneller und kleiner in Asm codiert als mit diesem Monstrum.
Axel S. schrieb: > Wenn ihr schon Projekte mit IRMP gebaut habt Nein habe ich nicht und werde ich auch nicht. IRMP ist definitiv ein Irrweg. Es setzt darauf, IR-Protokolle erkennen und tatsächlich sinnvoll decodieren/codieren zu können. Das ist aber in aller Regel für die Anwendung überhaupt nicht nötig. Dazu kommt noch, dass sich die Zahl der realexistierenden IR-Protokolle in den letzen 10..15 Jahren exponentiell vervielfacht hat und die meisten davon nirgendwo mehr dokumentiert sind. Es ist halt mit der Verfügbarkeit billiger und leistungsfähiger µC extrem leicht geworden, einfach seine eigenen Brötchen zu backen. Und jeder Arsch in der Industrie nutzt scheinbar auch diese Möglichkeiten. Der korrekte Ansatz ist also: Man nutzt aus, dass all diese Ärsche gewissen Restriktionen beim Design ihres Protokolls unterliegen, primär wohl meist: die IR-Strecke darf praktisch nicht viel mehr kosten als eine IR-LED und einen handelsüblichen IR-Receiver. Die ultimative Lösung kann also nur sein: Man baut dann einfach eine Software, die ihm gegebenen Rahmen einfach mal jedes denkbare Scheiß-Protokoll aufzeichnen und widergeben kann und zwar ohne zu wissen, um welches Protokoll es sich dabei konkret handelt oder gar den logischen Gehalt erkennen zu können. Weil das eben praktisch niemals wichtig ist...
Nein, das wäre ein Irrweg. Was machst du denn, wenn du die FB nicht auftreiben kannst und diese nun nachbauen sollst? Dann suchst du nach Strukturmöglichkeiten. Es gibt genug Codeadressen, daß sich jeder blind irgendeinen wählen kann, und dennoch höchstwahrscheinlich nicht denselben Code vom Gerät daneben zu treffen. Dafür gibts dann irgendwann Standard-Scourcecodes, die dann recht einfach implementierbar und untereinander kompatibel sind. Und so kann auch irgendwann eine kritische Masse entstehen, die die häufigsten Codes als Quasistandard etablieren und sozusagen als Gravitationsschwerpunkt allen Wildwuchs auf den Standard reduzieren. (wenn es genug fertige Codebeispiele mit genug Erfahrung gibt, ist ein Eigenbrutzeln mühseliger als "einfach von der Stange" zu coden.) Klar gibts immer ein paar faule Programmierer, die die paar Zeilen Code für ein ordentliches Protokoll nicht schreiben wollen (Okay, manchmal bin ich auch so). Ich nutze Kaseiko, NEC, NEC32 und RC5.
c-hater schrieb: > Nein habe ich nicht und werde ich auch nicht. IRMP ist definitiv ein > Irrweg. > > Es setzt darauf, IR-Protokolle erkennen und tatsächlich sinnvoll > decodieren/codieren zu können. Das ist aber in aller Regel für die > Anwendung überhaupt nicht nötig. selten so einen Quark gelesen, ich kaufe eine brauchbare FB, kenne deren Protokoll und Tastencode nicht, sehe das mit IRMP und kann es tastengenau so in meine Hardware stricken, wie soll das sonst funktionieren? c-hater schrieb: > Die ultimative Lösung kann also nur sein: Man baut dann einfach eine > Software, die ihm gegebenen Rahmen einfach mal jedes denkbare > Scheiß-Protokoll aufzeichnen und widergeben kann wie soll das denn klappen? mit klassischen Variablen kann ich im Proggi umgehen, mit Bitmustern? so genial bin ich nicht.
Bitte hier keine Diskussion über Sinn oder Unsinn von IRMP. Wenn ihr das diskutieren wollt - gerne - aber bitte in einem eigenen Thread.
Axel S. schrieb: > Bitte hier keine Diskussion über Sinn oder Unsinn von IRMP. Wenn > ihr > das diskutieren wollt - gerne - aber bitte in einem eigenen Thread. hast ja recht, habe mich hinreissen lassen, aktuell nutze ich NEC in der wordclock, hatte aber auch schon mal RC5, Kaseikyo und Samsung genutzt.
In der Grabbelkiste liegen hier Fernbedienungen folgenden Typs: 4 * RC5 3 * NEC 2 * Sony 1 * RECS80 Eine weitere Fernbedienung von Hama benutzt Ortek, das ich aber i.d.R. wegen des Konflikts mit RC5 abgeklemmt lasse. Alle anderen, die in Gebrauch sind, verwenden meiner Erinnerung zufolge NEC.
Andy P. schrieb: > Nein, das wäre ein Irrweg. Was machst du denn, wenn du die FB nicht > auftreiben kannst und diese nun nachbauen sollst? Das genau ist die EINZIGE Gegenindikation. Das ist dir doch hoffentlich klar, oder?
c-hater schrieb: > Das genau ist die EINZIGE Gegenindikation. Das ist dir doch > hoffentlich klar, oder? Verdammt, ich rechne immer nur mit Fachleuten. Also um das noch etwas breiter auszuwalzen, so dass es jeder verstehen kann: Abgesehen von dem Szenario mit der nicht mehr verfügbaren Original-FB kann man mit "meinem" Ansatz all das machen, was auch mit IRMP möglich ist. Scripting usw. ist absolut kein Problem. Und selbst das (mangels Reduktion auf den semantischen Gehalt der Nachrichten) etwas fülligere Speicherformat relativiert sich sehr schnell, sobald man mehrere verschiedene FBs bedienen muss, denn der eine Code macht alles, es ist nicht nötig, immer mehr Codemodule hinzuzulinken, die den Speicher schneller vollscheissen als die paar IR-Codes, die unterstützt werden sollen. Und, last but not least: Es gibt bei "meinem" Ansatz keine Protokolle, die sich gegenseitig ausschließen! Selbst dem letzten Vollidioten sollte klar sein, was für einen Vorteil allein das darstellt...
c-hater schrieb: >> Das genau ist die EINZIGE Gegenindikation. Das ist dir doch >> hoffentlich klar, oder? Verdammt, noch was vergessen: Natürlich steht es jedem frei, im Falle der einzigen Gegenindikation einfach tatsächlich IRMP zu benutzen, um das Protokoll und den Payload der zu unterstützenden Nachrichten herauszufinden und das Ergebnis letztlich wieder in "meine" Lösung einzuspeisen... Mit "vergessen" meine ich hier tatsächlich vergessen. Denn diese naheliegende Anwendung habe ich tatsächlich in meinem seit Jahren real benutzten TeachIn-Stick noch nicht vorgesehen, der kann bisher nur von realexistierenden FBs lernen (IR und 433MHz AM Funk). Blöd nur, dass ich dafür eine Lösung finden muss, um die IRMP-Restriktionen von der Designzeit auf die Laufzeit zu verlagern. Aber das kriege ich schon hin. Aber sicher nicht bis morgen. C ist ja so nervig...
c-hater schrieb: > Und, last but not least: Es gibt bei "meinem" Ansatz keine Protokolle, > die sich gegenseitig ausschließen! Und wo war diese traumhafte Software als Quellcode doch gleich nochmal downzuloaden?
Axel S. schrieb: > @Konrad: bitte nicht den Troll füttern. So wenig C-Haters Kommentare jetzt hierher passen so sehr hat er aber recht damit. Diese am besten in den IRMP Projekt-Thread verschieben!
Axel S. schrieb: > @Konrad: bitte nicht den Troll füttern. Wollt' nur mal auf den Busch klopfen, ob er - wie so oft - nur das Arschloch gibt oder ob da doch was dahinter ist. ;-) Zur Frage des TO: Ich zieh bei Bedarf eine verwaiste IR-Fernbedienung mit geeignetem Layout aus der Kiste, lass mir von IRMP die Werte aller Tasten ausgeben und bau das dann in die Anwendung ein. Meist ist es NEC-Protokoll, Platz zwei geht an RC5.
Moby A. schrieb: > So wenig C-Haters Kommentare jetzt hierher passen so sehr hat er aber > recht damit. Nein, hat er nicht. Seine ganze Argumentation basiert auf der falschen Annahme (um nicht zu sagen: dem Strohmann) der primäre Zweck von IRMP wäre das Aktivieren möglichst vieler Protokolle und dann das Erkennen möglichst vieler verschiedener Fernbedienungen. Und natürlich kann man IRMP so benutzen um z.B. einen Protokoll- Analyzer zu bauen. Aber genauso gut kann man IRMP als Decoder für nur eine spezifische Fernbedienung benutzen. Wie ich in dem verlinkten Moodlight. Dann aktiviert man genau ein IR-Protokoll und schreibt Protokoll und Systemcode in die Anwendung. Und fertig. Und wenn man sich dann mal anschaut was von dem (zugegeben riesigen) Haufen Code effektiv noch übrig bleibt, dann ist das kaum ineffizienter als ein handoptimierter Decoder für genau ein einziges Protokoll. Als Bonus funktioniert das für fast jede Fernbedienung die mir vielleicht in die Hände fällt. Ich muß nur ein einziges Headerfile ändern und schon decodiert mir der gleiche Code (mit der gleichen API) meine neue Fernbedienung. Das ist auf jeden Fall sehr praktisch. Aber es wird noch besser. Wieder mein Moodlight. Ich bediene das mit einer alten Fernbedienung aus einem 10-er Sortiment von Pollin. Ich weiß nicht mal für welches Gerät die ursprünglich mal war. Auch egal. Jetzt habe ich auf der Fernbedienung meines Fernsehers ein paar Tasten ohne Funktion und denke mir "warum soll das Moodlight nicht auch auf diese Tasten reagieren?". Mit IRMP kein Problem, auch wenn diese Fernbedienung ein anderes Protokoll spricht. Ich habe nach wie vor nur eine Funktion die ich aus dem Timer-Interrupt aufrufen muß und das API zur Abfrage ist auch immer noch das gleiche. Und wieder ist das superpraktisch. Und IMHO viel besser als jetzt zwei handoptimierte Protokolldecoder einzeln zu programmieren, einzeln in den Timer-Interrupt zu hängen und einzeln abzufragen. Und ich finde auch daß es ein echter Mehrwert ist, wenn man ein Gerät mit mehreren verschiedenen Fernbedienungen gleichberechtigt bedienen kann.
Hier bitteschön, anbei eine Konfiguration, wo möglichst viele IR-Codes aktiviert sind. Auch wenn das Gegenteil gefragt ist, der Vollständigkeit halber. ;)
So. Nachdem ich mir Luft gemacht habe, hier die versprochene Zusammenfassung (leider gab es nur wenig Reaktionen)
1 | Platz Protokoll Anzahl Nennungen |
2 | ----------------------------------- |
3 | 1 NEC 11 ½ |
4 | 2 RC5 5 |
5 | 3 Sony 2 |
6 | 3 Kaseikyo 2 |
7 | 4 NEC32 1 |
8 | 4 Samsung 1 |
9 | 4 RECS80 1 |
Am weitesten verbreitet scheint das NEC Protokoll zu sein, gefolgt von RC5. Das hätte ich auch so vermutet :) Sony und Kaseikyo teilen sich Platz 3. Die anderen Kandidaten wurden nur je einmal genannt. Zumindest RECS80 würde ich als "Exot" einstufen :) Ach ja, das ½ bei NEC kommt von dem einen Poster der zwar angibt NEC zu decodieren, aber dafür nicht IRMP verwendet. Ich denke der Thread kann jetzt geschlossen werden. Ich bedanke mich bei allen, die im Sinne der Fragestellung geantwortet haben!
:
Bearbeitet durch User
Axel S. schrieb: > Seine ganze Argumentation basiert auf der falschen Annahme (um nicht zu > sagen: dem Strohmann) der primäre Zweck von IRMP wäre das Aktivieren > möglichst vieler Protokolle und dann das Erkennen möglichst vieler > verschiedener Fernbedienungen. Nein, das hast du völlig falsch verstanden, möglicherweise sogar bewusst falsch verstehen wollen. Aus meiner Sicht gibt es drei denkbare Instanzen der Anwendung von IRMP (bzw. alternativer funktionskongruenter Lösungen): 1) Die Reproduktion eines gewünschten Kommandos. Hier ist der Knackpunkt, dass die zu generierenden Kommandos in irgendeinem Speicher in einem möglichst kompakten Speicherformat vorliegen UND der Code, der aus diesem Speicherformat letztlich das auszusendende Kommando erzeugt. Erst die Betrachtung der Summe beider Komponenten des Speicherverbrauchs ergibt sich eine realistische Einschätzung der Gesamteffizienz der Lösung. Mein Ansatz ist hier bezüglich des Speicherplatzes für die Codes gegenüber IRMP deutlich im Nachteil, da es auf Grund des geringeren Grads der Abstraktion der Analyse der Codes zwangsläufig diverse Redundanzen mitspeichern muss. Er ist aber im Vorteil bezüglich des Codes, denn er benötigt nur genau einen universellen, um jedes Protokoll aus diesem Speicherformat reproduzieren zu können. 2) Die Ermittlung/Erfassung des gewünschten Kommandos aus einem vorhanden Sender. Hier ist ganz klar der Knackpunkt, dass möglichst alles gehen soll und zwar ohne jegliche Konfiguration. Denn die müsste der Anwender leisten und zwar bereits zur Designzeit der Analyse-Firmware, der DAU hat aber in aller Regel wenig bis keine Ahnung und ist deshalb garnicht in der Lage, das zu leisten. Hier ist ganz eindeutig mein Ansatz massiv im Vorteil, denn er braucht keine diesbezüglich Konfiguration und kann trotzdem "alles" erfassen und obendrein sehr ordentlich von unnötiger Redundanz befreien. (Genau das ist eigentlich meine Eigenleistung, der ganze Rest ist ja sowieso ziemlich trivial...) 3) Die Generierung von bekannten, aber mangels vorhandenem Sender nicht nach Punkt 2) erfassbaren Codes. Hier stinkt meine Lösung vollkommen ab, das kann sie derzeit schlicht garnicht. Aber ich denke gerade darüber nach, wie ich die Fähigkeiten von IRMP dafür nutzbar machen kann. Das hat für mich dieser Thread gebracht, einen Anstoß, ein altes Projekt erneut aufzunehmen und mit zusätzlichen Fähigkeiten auszustatten. > Aber genauso gut kann man IRMP als Decoder für nur > eine spezifische Fernbedienung benutzen. Wie ich in dem verlinkten > Moodlight. Dann aktiviert man genau ein IR-Protokoll und schreibt > Protokoll und Systemcode in die Anwendung. Und fertig. Das ist ja auch trivialst. Ein Lösung die nichtmal das leisten könnte, wäre ja wohl von vornherein völlig indiskutabel. > Und wenn man sich dann mal anschaut was von dem (zugegeben riesigen) > Haufen Code effektiv noch übrig bleibt, dann ist das kaum ineffizienter > als ein handoptimierter Decoder für genau ein einziges Protokoll. Das ist der Punkt: bei meiner Lösung ist du es immer nur mit genau einen handoptimierten Decoder/Encoder zu tun. Und der ist sogar sehr primitiv. Insbesondere ist er primitiv genug, dass selbst die relativ zeitkritische unterste Stufe der Lernroutine sozusagen "nebenläufig" in VUSB zu integrieren war (zumindest ab 18MHz Systemtakt). Genau so ist vor 5 Jahren mein TeachIn-Stick entstanden... Mach das mal mit IRMP...
c-hater schrieb: > Axel S. schrieb: > >> Seine ganze Argumentation basiert auf der falschen Annahme ... > > Nein, das hast du völlig falsch verstanden Gut möglich. Und mit diesem Post wird es kein bischen besser. > Aus meiner Sicht gibt es drei denkbare Instanzen der Anwendung von IRMP > (bzw. alternativer funktionskongruenter Lösungen): > > 1) Die Reproduktion eines gewünschten Kommandos. Es wäre hilfreich, wenn du dich weniger geschwollen ausdrücken würdest. Meinst du damit, daß der µC Kommandos in einem bestimmten IR-Protokoll senden soll? Dann ist das am Thema vorbei. Ich spreche von IRMP. Das ist ein IR-Protokoll Decoder, mithin nur die Empfängerseite. Die Sender- Seite heißt IRSND. Um die geht es hier aber nicht. > 2) Die Ermittlung/Erfassung des gewünschten Kommandos aus einem > vorhanden Sender. Ich dechiffriere mal dein Geschwurbel: ein Empfänger für IR-Fern- bediensignale. Also das was IRMP macht und worum es mir geht. > Hier ist ganz klar der Knackpunkt, dass möglichst alles gehen soll und > zwar ohne jegliche Konfiguration. Wie soll das gehen? Und warum? Warum sollte man alle denkbaren Proto- kolle decodieren können müssen? In 99% der Fälle muß man die Signale genau einer Fernbedienung erkennen können. Also ein Protokoll. Ein Systemcode. Und N Tastencodes. Und zumindest die Tastencodes muß man irgendwo konfigurieren. Wie sonst soll man Aktionen an empfangene Tastencodes koppeln? > Denn die müsste der Anwender leisten und zwar bereits zur Designzeit > der Analyse-Firmware der DAU hat aber in aller Regel wenig bis keine > Ahnung und ist deshalb garnicht in der Lage, das zu leisten. Wieder habe ich keinen Schimmer wovon du redest. Analyse-Firmware? Wenn ich ein IR-fernbedienbares Gerät baue, dann weiß ich doch vorher, welche Fernbedienung ich verwende. Welches Protokoll, welchen Systemcode, wieviele Tasten und welchen Tastencode ich für welche Aktion verwenden will. All das weiß ich spätestens bevor ich die finale Version der Firmware compiliere. > Hier ist ganz eindeutig mein Ansatz massiv im Vorteil Keiner hier kennt "deinen Ansatz". Mach einen Thread auf, erkläre deinen Ansatz da. Poste einen Pointer hier. Oder schweige. Und nein, poste nicht hier. Du hast dich sicher sehr bemüht, diesen Thread zu kapern. Aber wenn du das hier postest, werde ich es schlicht ignorieren. > 3) Die Generierung von bekannten, aber mangels vorhandenem Sender nicht > nach Punkt 2) erfassbaren Codes. Hier scheint es schon wieder um das Senden zu gehen. Überdies wohl auch um das Senden von etwas, das man selber nicht kennt. Das ist einfach nur albern. "Try And Error" oder was?
c-hater schrieb: > Hier ist ganz eindeutig mein Ansatz massiv im Vorteil, Konrad S. schrieb: > Und wo war diese traumhafte Software als Quellcode doch gleich nochmal > downzuloaden?
c-hater schrieb: > Hier ist ganz klar der Knackpunkt, dass möglichst alles gehen soll und > zwar ohne jegliche Konfiguration. Du scheinst Dir IRMP und dessen Konfigurationsmöglichkeiten nie wirklich angesehen zu haben. > Hier ist ganz eindeutig mein Ansatz massiv im Vorteil, denn er braucht > keine diesbezüglich Konfiguration und kann trotzdem "alles" erfassen und > obendrein sehr ordentlich von unnötiger Redundanz befreien. Dann nutz die doch und gut. Warum dieser Alleinherschungsanspruch einer Lösung die Du hier nichtmal anbietest? Hier wurde nicht nach Alternativen gefragt, Du liegst etwas neben den Thema. Du hast nur mit vielen Worten ausgedrückt, daß Du die Ausgangsfrage garnicht beantworten kannst wei Du IRMP nicht nutzt (und nicht kennst), Du solltest Politiker werden.
c-hater schrieb: > Und selbst das (mangels Reduktion auf den semantischen Gehalt der > Nachrichten) etwas fülligere Speicherformat relativiert sich sehr > schnell, sobald man mehrere verschiedene FBs bedienen muss, denn der > eine Code macht alles, es ist nicht nötig, immer mehr Codemodule > hinzuzulinken, die den Speicher schneller vollscheissen als die paar > IR-Codes, die unterstützt werden sollen. Du unterliegst da mehreren Irrtümern. Offenbar gehst Du davon aus, dass man mit einem einmalig aufgezeichneten IR-Frame das Gerät reproduzierbar bedienen kann. Da hast Du aber leider die Rechnung ohne den Wirt gemacht, denn das scheitert aus folgenden Gründen: 1. Toggle-Bits, z.B. bei RC5, RC6 und verwandten Protokollen. Das Toggle-Bit ist ein Indikator dafür, ob eine Taste lang oder mehrmals kurz gedrückt wurde. Ohne diese semantische Information (Du musst(!) bei jedem neuen Tastendruck das Toggle- Bit ändern - auch bei identischem Kommando!) reagiert das Gerät nicht so, wie Du es Dir vorstellst. Denn es wird in der Regel dann jeden folgenden Befehl ignorieren oder nur noch jeden zweiten Befehl ausführen - wenn Du Glück hast. Bei längeren Tastendrücken darf übrigens das Toggle-Bit nicht geändert werden, der Frame aber dann solange unverändert wiederholt werden, bis Du die Taste loslässt. 2. Repetition Frames, z.B. beim NEC-Protokoll Bei einem langen Tastendruck wird zunächst der NEC-Frame ausgesandt. Bei längerem Tastendruck wird anschließend ein viel kürzerer Frame solnge wiederholt, bis Du die Taste loslässt. Dieser kurze "Repetition-Frame" sieht immer gleich aus - und zwar für alle Geräte, die das NEC-Protokoll verwenden! Denn es ist weder eine Geräte-Adresse noch ein konkretes Kommando im Frame vorhanden. Der Repetition-Frame bedeutet aber semantisch: "Wiederhole das zuletzt empfangene Kommando!". Das kommt zum Beispiel zum Tragen, wenn Du die Lautstärke am Fernseher durch längeres Festhalten der Volume-Taste aufdrehen willst. Ein und derselbe Frame - für alle erdenklichen Befehle! Dabei gilt es auch, gewisse Timeouts einzuhalten. Empfängt ein Gerät zum Beispiel zufällig den NEC-Repetition-Frame erst nach einer halben Stunde (weil zwischenzeitlich ein anderes Gerät, welches auch NEC nutzt, angesprochen wurde), ist es überhaupt nicht sinnvoll, diesen Befehl noch umzusetzen. Das führt auf schlecht programmierten Geräten dann zu "Geisterbefehlen". Ich habe zuhause eine Multi-Media-Festplatte, die genau das macht: Wenn ich die Lautstärke per langem Tastendruck für den Fernseher hochdrehe, fängt die Media-Festplatte plötzlich an, den irgendwann davor empfangenen Befehl nochmals auszuführen. Sie schaltet dann zum Beispiel auf den nächsten Film. Sehr ärgerlich. IRMP ist da schlauer und ignoriert Repetition-Frames nach einem bestimmten Timeout, in der Regel nach ca. 100ms. Und schon sind die Geisterbefehle weg. Das Lautstärke- oder Helligkeitsregeln für LEDs funktioniert aber weiterhin auch bei längerem Tastendruck perfekt. 3. Wiederholungs-Frames Manche IR-Protokolle senden nach ein paar Dutzend Millisekunden denselben Frame aus Redundanzgründen neu. Dieser Wiederholungs- Frame ist manchmal identisch, manchmal sind dort bewusst ein paar Bits gekippt. Hier ist es sinnvoll, a) Diese Bits auf Übereinstimmung zu prüfen b) Richtig zu "rechnen", was davon redundante und was davon Wiederholungsframes sind, welche durch lange Tastendrücke zustandekommen. Beispiele: SAMSUNG32-Protokoll: N zu wiederholende Befehle = 2 * N Frames SIRCS (Sony): N zu wiederholende Befehle = 3 + N Frames (ja: plus!) Es gibt noch mehrere davon, dabei sind die Regeln, wann gewisse Bits zu kippen sind (ob in Redundanz- oder in Tastenwiederholungsframes), verschieden! 4. CRCs: Viele IR-Frames enthalten redundante Informationen, weil sie entweder Wiederholungen (invertiert/nicht invertiert) oder Checksums enthalten. Diese auf Plausibilität zu prüfen, ist sinnvoll, um fehlerhafte Frames (wegen schlechtem/unvollständigem Empfang) auszufiltern. 5. Datenmenge IRMP stampft die redundanten Informationen grundsätzlich komplett ein auf 5 Bytes - auch wenn die Datenmenge weitaus größer ist. IRSND dagegen baut beim Encodieren aus dieser minimalen Datenmenge alle Redundanzen, CRCs, Toggle-Bits und Wiederholungsframes kontextbezogen wieder ein, dekomprimiert die Daten also wieder. Dieses geschieht On-The-Fly, d.h. der/die Frames müssen niemals komplett im Speicher vorliegen. Ein Beispiel: Beim Kaseikyo-Protokoll (das ist KEIN exotisches Protokoll, sondern ein Standard!) werden im Original-Frame 48 Bits verwendet. Wenn diese Daten ohne Prüfung der enthaltenen CRCs roh aufgezeichnet werden durch Speicherung der Timings, sind das mindestens 96 Bytes, die Du für eine einzige Taste vorhalten müsstest. Da kann ein ATTINY-EEPROM, in welchem aufgezeichnete Tasten sinnvollerweise abgelegt werden, schon nach einer Taste voll sein. IRMP jedoch speichert auch in einem 128-Byte-EEPROM immerhin noch 25 Tastencodes - bei geschickter Protokoll-/Adress-Gruppierung sogar 42 Tastencodes. EDIT: Ich vergaß Grund 6. 6. Klimaanlagen IR-Frames für Klimaanlagen verwenden in einem einzelnen Frame mehrere unabhängige Daten-Informationen wie Temperatur, Lüfter ein-/aus, Entfeuchter ein/aus. Diese sind unabhängig voneinander. Wenn Du da einen Frame für 21° aufzeichnest und den später reproduzierst, wirst Du Dich später wundern, warum der Lüfter plötzlich auch abschaltet oder warum es plötzlich so feucht wird. Alles in allem ist Dein Gedankengang, die Daten einfach roh zu speichern und zu reproduzieren, zum Scheitern verurteilt. Du kommst um semantische Behandlung der Protokolle einfach nicht herum. Und wenn man dann noch den geringen Speicherbedarf von IRMP berücksichtigt: IRMP bzw. IRSND laufen auch noch auf ATTINYs. EDIT2: Dass die Anzahl der Protokolle "explodieren", stimmt so nicht. Viele Hersteller benutzen oft bereits eingeführte Standards. Wenn Du im IRMP die ersten 5 aufgeführten Protokolle aktivierst, unterstüzt IRMP bereits mehr als 99% aller im normalen Haushalt befindlichen Fernbedienungen.
:
Bearbeitet durch Moderator
Frage: Wofür ist die Auswertung von langen Tastendrücken zwingend? Damit ist die Argumentationskette in den wohl allermeisten Fällen schon mal höchstens auf exotische Protokolle eingedampft, denn Frank M. schrieb: > die ersten 5 aufgeführten Protokolle ... (in) > bereits mehr als 99% aller im normalen Haushalt befindlichen > Fernbedienungen also Sony,NEC,Samsung,Kaseiko,JVC ließen sich dann ohne weiteres "roh" speichern. > Diese auf Plausibilität zu prüfen, ist > sinnvoll, um fehlerhafte Frames (wegen schlechtem/unvollständigem > Empfang) auszufiltern. Für die Filterfunktion sind entsprechende Empfänger (z.B. TSOP48 Serie) und reproduzierbare Codes am Ausgang doch absolut ausreichend. > 5. Datenmenge Entscheidend ist, was die Wiedergabe insgesamt benötigt- und da bin ich mir nicht so sicher, wie gut IRSND beim Speicherverbrauch da abschneidet. Für den NEC Powercode (wie für jeden anderen IR-Code) meiner Soundbar brauch ich zum Beispiel zwar 16 "Roh-" statt derer 5 effizente IRMP-Bytes, dafür für die eigentliche NEC-Ausgabefunktion aber nur ca. 25 Asm Instruktionen- wobei man ja meist längst nicht alle Tastenfunktionen der Original-Fernbedienung benötigt, sondern oft nur ein paar. Da dürfte IRSND im Speicherverbrauch so schnell kein Land sehen, oder? Wenige benötigte Codes in wenigen IR-Apps lassen sich genausogut mit dem Oszi ermitteln. Bei diesem meinem Bedarf ist man mit ein bischen Pegel-Abzählen so viel schneller fertig als sich dafür erst eine IRMP-Gerätschaft zu bauen und erst recht sich ins fette IRMP einzuarbeiten. Bei den Fernbedienungen für Heimelektronik, die ich so besitze, kommt eh nur das einfache NEC-Protokoll zur Anwendung. Frank M. schrieb: > 6. Klimaanlagen Na schön. Für den der eine hat.
MOBY schrieb: > sich ins fette IRMP > einzuarbeiten IRMP ist eine der wenigen 3rd-party-libs die bei mir Out-of-the-box liefen. Wie immer wenn ich erstmals eine neue Hardware in Betrieb nehme hab ich mich auf Debuggen und Fehlersuchen eingestellt. Aber nein, Sourcen ins makefile eingetragen, API kurz angeschaut (es sind 2 Funktionen wichtig), kompilieren, testen, LÄUFT. 5min.
MOBY schrieb: > Frage: Wofür ist die Auswertung von langen Tastendrücken zwingend? Gegenfrage: Du hämmerst also 64 mal auf eine FB-Taste, um die Helligkeit einer Beleuchtung von 0 auf 100% zu dimmen? Oder 64 mal auf die Volume-Taste Deines Fernsehers, um den Ton hochzudrehen? Nein, Du hältst die Taste einfach länger runter und lässt den Empfänger runterdimmen. Und genau da muss man die langen Tastendrücke auswerten. > Damit ist die Argumentationskette in den wohl allermeisten Fällen schon > mal höchstens auf exotische Protokolle eingedampft, denn Damit ist Deine Argumentationskette komplett hinfällig. > also Sony,NEC,Samsung,Kaseiko,JVC ließen sich dann ohne weiteres "roh" > speichern. Hinfällig. > Für die Filterfunktion sind entsprechende Empfänger (z.B. TSOP48 Serie) > und reproduzierbare Codes am Ausgang doch absolut ausreichend. Dann schreib Dir doch Dein eigenes IR-Empfänger und Sende-Programm. Wenn Du dann mit dem Ergebnis zufrieden bist, kannst Du Dich ja freuen. > Für den NEC Powercode (wie für jeden anderen IR-Code) meiner Soundbar > brauch ich zum Beispiel zwar 16 "Roh-" statt derer 5 effizente > IRMP-Bytes, dafür für die eigentliche NEC-Ausgabefunktion aber nur ca. > 25 Asm Instruktionen- wobei man ja meist längst nicht alle > Tastenfunktionen der Original-Fernbedienung benötigt, sondern oft nur > ein paar. Solange Du Deinen Code nicht zeigst, behaupte ich einfach, Du brauchst 2.500.000 Assembler-Instruktionen. Zeigen, nicht lamentieren. > Da dürfte IRSND im Speicherverbrauch so schnell kein Land > sehen, oder? Zeigen und ich sage Dir, was Du alles vergessen hast. > Wenige benötigte Codes in wenigen IR-Apps lassen sich > genausogut mit dem Oszi ermitteln. Bei diesem meinem Bedarf ist man mit > ein bischen Pegel-Abzählen so viel schneller fertig als sich dafür erst > eine IRMP-Gerätschaft zu bauen und erst recht sich ins fette IRMP > einzuarbeiten. Was willst Du Dich da einarbeiten? Den Code zum Projekt hinzufügen, einen Send-Befehl eintippen und fertig. Dauert 10 Minuten. Eine Eigenentwicklung dauert länger als 10 Minuten, solange Du Deinen Code nicht veröffentlicht hast und der arme Programmierer auf sich allein gestellt ist ;-) > Bei den Fernbedienungen für Heimelektronik, die ich so > besitze, kommt eh nur das einfache NEC-Protokoll zur Anwendung. Ja, ich fahre auch noch Bobbycar. Ich kann auch ein kleines spezielles C-Programm schreiben, was NEC-Code empfangen und senden kann. Das kann jeder, sogar Du. Aber das ist NICHT Sinn und Zweck von IRMP.
Ein in meinen Augen nicht unwesentlicher Vorteil von IRMP/IRSND ist, dass der auf mehreren Mikrocontrollerfamilien laufende Code hier auf µC.net zum Download bereitsteht. Dagegen stehen MOBYs und c-haters "Lösungen" in den Sternen - wer lange Arme hat, mag danach greifen.
Konrad S. schrieb: > Ein in meinen Augen nicht unwesentlicher Vorteil von IRMP/IRSND ist, > dass der auf mehreren Mikrocontrollerfamilien laufende Code hier auf > µC.net zum Download bereitsteht. vergiss nicht den persönlichen Support, wann immer ein User neue Protokolle meldet, Frank baut es umgehend ein!
Joachim B. schrieb: > vergiss nicht den persönlichen Support, wann immer ein User neue > Protokolle meldet, Frank baut es umgehend ein! Ist mir schon klar. Bei den beiden anderen Kandidaten ist mir dieser Service bisher nur noch nicht so deutlich in Auge gesprungen. Hab ich bestimmt nur übersehen! ;-)
Konrad S. schrieb: > Bei den beiden anderen Kandidaten ist mir dieser Service bisher nur noch > nicht so deutlich in Auge gesprungen. Hab ich bestimmt nur übersehen! > ;-) ich auch.....
Frank M. schrieb: > Du hämmerst also 64 mal auf eine FB-Taste, um die Helligkeit > einer Beleuchtung von 0 auf 100% zu dimmen? Nö. Sowas macht man dann mit einem simplen Schalter ;-) > also Sony,NEC,Samsung,Kaseiko,JVC ließen sich dann ohne weiteres "roh" > speichern. > > Hinfällig. Wieso? Natürlich geht das wenn die Wiederholfunktion nicht gebraucht wird! > Dann schreib Dir doch Dein eigenes IR-Empfänger und Sende-Programm. Wenn > Du dann mit dem Ergebnis zufrieden bist, kannst Du Dich ja freuen. Das bin ich. > IRMP bzw. IRSND laufen auch noch auf ATTINYs Das zaubert jetzt höchstens ein breites Grinsen auf das Gesicht jedes halbwegs fähigen Asm-Programmierers ;-) > Solange Du Deinen Code nicht zeigst, behaupte ich einfach, Du brauchst > 2.500.000 Assembler-Instruktionen. Zeigen, nicht lamentieren Lässt sich machen. > Zeigen und ich sage Dir, was Du alles vergessen hast. Da hab ich garantiert nix vergessen, denn die Soundbar reagiert wie gewünscht ;-) > Was willst Du Dich da einarbeiten? Den Code zum Projekt hinzufügen, > einen Send-Befehl eintippen und fertig. Dauert 10 Minuten. Eine > Eigenentwicklung dauert länger als 10 Minuten, solange Du Deinen Code > nicht veröffentlicht hast und der arme Programmierer auf sich allein > gestellt ist ;-) Der Autor hat meist die geringste Ahnung vom Einarbeitungs-Aufwand. Wobei ich dazu sagen sollte daß für mich ressourcenhungriges C ja ohnehin nicht in Frage kommt. Für alle die die es verwenden mag IRMP/IRSND aber eine zeitsparende Lösung sein, wenn auch aus Mangel an Alternativen...
Konrad S. schrieb: > Ein in meinen Augen nicht unwesentlicher Vorteil von IRMP/IRSND > ist, dass der auf mehreren Mikrocontrollerfamilien laufende Code hier > auf µC.net zum Download bereitsteht. Wenn man sich den Luxus gönnen kann bei einer Familie bleiben zu können nutzt der Portabilitätsvorteil gar nichts. Und glaub mir, eine IR-Ausgabe zu programmieren ist jetzt kein Hexenwerk- jedenfalls was mindestens mal das von mir eingesetzte NEC-Protokoll angeht.
:
Bearbeitet durch User
Moby A. schrieb: > jedenfalls was > mindestens mal das von mir eingesetzte NEC-Protokoll angeht. Ich suche mir die Protokolle nicht aus. Ich nehme das, was eine 'rumliegende, anderweitig nicht mehr benötigte Fernbedienung an Protokoll eben grade hat und konfiguriere IRMP dafür. Oder für die Gegenrichtung muss man rausfinden, welches Protokoll das Gerät sehen mag. Wenn es da die Original-Fernbedienung noch gibt, dann nehm ich einfach den "IR-Spion" (TSOP, Controller, LCD, IRMP mit vielen aktivierten Protokollen) und erfasse die Codes aller relevanten Tasten. Moby A. schrieb: > Der Autor hat meist die geringste Ahnung vom Einarbeitungs-Aufwand. Ja, da liegt Frank mit "10 Minuten" deutlich zu tief. Allein das Lesen das Artikels IRMP dauert schon länger. Wenn man den aber einmal durch hat, dann geht das Konfigurieren wirklich flott von der Hand. Apropos "Hand". Hand aufs Herz: Wem ist es nicht lieber, eine ausführliche Dokumentation zum Sourcecode dazuzubekommen, als das, was manch anderer hier zeigt - oder vielmehr nicht zeigt!
@Konrad Mich interessiert da im Wesentlichen nur, IR-bedienbare Geräte statt mit der Original-Fernbedienung von einem Selbstbau-Controller aus mit minimalstem Ressourcenverbrauch anzusteuern. Zur Bedienung braucht man meistens nur ganz wenige Grund-Funktionen, die sind auch schnell am Oszi ermittelt. Die Original-FB kann dann zum Relaxen in den Schrank ;-) Für gewünscht vollwertigen FB-Ersatz gibts doch genug (lernfähige) Lösungen zum kaufen, das muß man nicht selber basteln. Aber so ein IR-Spion ist bestimmt eine prima Sache wenn man täglich mit dem Thema zu tun hat.
Moby A. schrieb: > Mich interessiert da im Wesentlichen nur, IR-bedienbare Geräte statt mit > der Original-Fernbedienung von einem Selbstbau-Controller aus mit > minimalstem Ressourcenverbrauch anzusteuern. <seufz> Noch so ein Fehlgeleiteter. Wenn du den Eröffnungspost dieses Threads auch nur überflogen hättest, dann wäre dir aufgefallen daß es hier nicht um die Sender-Seite einer IR-Fernbedienung geht, sondern um die Empfänger-Seite. Mit anderen Worten: du hast nichts, aber auch gar nichts beizutragen. Wenn du gerne deinen IR-Sender mit minimalstem [1] Ressourcenverbrauch diskutieren möchtest, dann mach das - in einem eigenen Thread. [1] ist dir bewußt, daß man "minimal" nicht steigern kann? Und wie albern es wirkt, wenn du es trotzdem tust?
Axel S. schrieb: > [1] ist dir bewußt, daß man "minimal" nicht steigern kann? Und wie > albern es wirkt, wenn du es trotzdem tust? Eine Steigerung wär "minimaler" oder "maximaler"... Minimalstem ist in diesem Zusammenhang nur eine besondere Betonung von minimal. Die ist bei nur 25 Asm-Instruktionen für die Ausgabe auch durchaus gerechtfertigt ;-) Ich reagiere auf den zitierten Autor. Du hattest hier ja längst abgeschlossen. Allzuviele IRMP Anwender haben sich ja auch nicht zu Wort gemeldet...
:
Bearbeitet durch User
Moby A. schrieb: > Für > gewünscht vollwertigen FB-Ersatz gibts doch genug (lernfähige) > Lösungen zum kaufen, das muß man nicht selber basteln. sorry ich habe genug IR lernfähige für meine Oma gekauft, das ist meist rausgeworfenes Geld, entweder sie vergessen den Code, oder können durch ungeschickte Bedienung ihre Codes vergessen, was du sagst scheint nur für deinen kleinen Horizont zuzutreffen. Moby A. schrieb: > Allzuviele IRMP Anwender haben sich ja auch nicht zu Wort gemeldet Das kann man ja nun werten wie man mag, ist aber ein Totschlagargument. Ab wieviele Anwender hättest du es akzeptiert? Ich sehe immer noch keinen Link auf deine SW, also wo wäre der Vorteil für alle mit deiner SW?
Moby A. schrieb: > Allzuviele IRMP Anwender haben sich ja auch nicht zu Wort gemeldet... Mehr als einer. Das reicht. Du auf der "anderen Seite" bist nämlich ganz allein. Was soll jemand hier mit einem speziellen Programm, mit dem man eine "Soundbar" ansteuern kann? Sehr spezielles Gerät, sehr spezielles Protokoll, sehr spezieller µC. Vielleicht findest Du ja noch einen anderen Interessenten auf der Welt, der genau das braucht. Du vergleichst gerade ein Matchbox-Auto mit einem verkehrstüchtigen Fahrzeug. Für Kleinkinder ist wohl das Matchbox-Auto ausreichend, für den Rest nicht. IRMP hat vollkommen andere Ansprüche. Es ist eine Bibliothek zum Einbinden in die eigene Applikation. Dabei kann die Größe des Codes durch Ein-/Ausschalten von jedem der knapp 50 Protokoll-Decodern sehr fein eingestellt werden. Man schnappt sich irgendeine Fernbedienung, die man im Haushalt rumliegen hat und legt los. Die IRMP-API sorgt dafür, dass für den Programmierer jede FB gleich behandelt werden kann. Schau Dir mal das Word Clock Projekt an. Jeder der Anwender kann eine beliebige FB anlernen und kann damit seine Uhr steuern. Das ist eine ganz andere Geschichte als Deine spezielle Soundbar-Anwendung. Und damit EOD für mich.
:
Bearbeitet durch Moderator
Ich nutze bisher IRMP nur mit NEC. Vier meiner sechs FBs die ich hier habe sprechen das. Daneben gibts noch Grundig und RC6. Witzig fand ich, dass ein Thomson Gerät nicht Thomson, sondern NEC benutzt :) EDIT: Eigentlich wollte ich nix dazu schreiben... Aber ;) Klar, den IRMP-Thread zu lesen dauert. Macht aber auch Spaß :) Und den Artikel zu lesen reicht für die Anwendung auch. IRMP compiliert out of the box auch im XC8. Und die Anwendung und Parametrierung ist wirklich einfach. Die Erkennung Erstdruck/Folgedruck finde ich unerlässlich für Anwendungen wie Dimmen und Ein-/Ausschalten. So kann eine Taste mehrere Funktionen haben.
:
Bearbeitet durch User
Joachim B. schrieb: > sorry ich habe genug IR lernfähige für meine Oma gekauft, das ist meist > rausgeworfenes Geld Was willst Du für diesen "Einsatzfall" auch mit vollständigem FB-Ersatz? Das ist doch geradezu prädestiniert für eine einfachere Selbstbau-Lösung! > was du sagst scheint nur > für deinen kleinen Horizont zuzutreffen. Da mach Dir mal keine unnützen Sorgen drum, für IR-Fernbedienung langts gerade noch ;-) > Ab wieviele Anwender hättest du es akzeptiert? Mir doch wurscht... > also wo wäre der Vorteil > für alle mit deiner SW? Hier gings um die unbestreitbare Möglichkeit, IR-Kommandos auch "roh" aufzeichnen zu können. Die Ausgabe (NEC) schließlich gelingt auch mit wenig Speicherbedarf, dazu bedarf es keiner aufgeblähten C-Lösung.
Frank M. schrieb: > Was soll jemand hier mit einem speziellen Programm, mit dem man eine > "Soundbar" ansteuern kann? Sehr spezielles Gerät, sehr spezielles > Protokoll, sehr spezieller µC... Weder ist ein Programm zur Ausgabe von IR-Codes sonderlich speziell noch ist eine Soundbar ein "sehr" spezielles Gerät mit "sehr" speziellem (gewöhnlichem NEC-) Protokoll. Auch der µC (AVR) ist alles andere als speziell... > Vielleicht findest Du ja noch einen > anderen Interessenten auf der Welt, der genau das braucht. Ich muß auch nichts "finden" sondern weise nur darauf hin daß sich IR-Codes auch "roh" aufzeichnen und äußerst ressourcensparend wiedergeben lassen > vergleichst gerade ein Matchbox-Auto mit einem verkehrstüchtigen > Fahrzeug. Du theoretisierst eindeutig zu viel. In der Praxis langt eben das kleine, angepasste Matchbox-Auto, da bedarf es keinem fettenTaschenmesser für alle denkbaren Einsatzfälle. Es mag interessant sein für ein Diagnose-Werkzeug. Oder für Systeme mit viel viel Speicherplatz und raumgreifenden Programmiersprachen, so als gäb's kein Morgen ;-)
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.