Hallo, ich bin in meinem Projekt zum Stillstand gekommen. Ich muss ein Weg finden, eine Lernfunktion der Infrarot Signale für mein AVR zu programmieren. Es muss so funktionieren, wie inzwichen viele universale Fernbediehnungen können: man drückt eine Taste auf irgendeiner IR Fernbediehnung von irgendeinem Unterhaltungsgerät, µC merkt dies und speichert den Signal im eeprom ab. Beim wiederholtem denselben Signal werden entsprächende Funkrionen durchgeführt. Das Programmieren an sich ist für mich kein Problemm. Was mir fählt, ist der Logaritmus, wie man den Signal so abspeichern kann, dass man ihn später wiedererkennen kann. Ich brauche also nur den Prinzip, wie die Uni Fernbediehnungen das realisieren. Mir fehlt die Idee, wie man es machen könnte. Und wie gesagt, es geht hier nur um die Lernfunktion. Das alles Andere habe ich bereits schon, oder ich werde es noch machen. Es stehen 2 Timer (8Bit 16Bit), ein Externer Interrupt zur Verfügung. Taktfrequenz 4 Mhz. Trägefr. der Signale: 38 kHz(ein entsprächender empfänger habe ich bereits.) Bin gespannt auf eure Vorschläge.
Also geht es beispielsweise um einen Standard RC5 Code? Das zeugs ist ja im prinzip nichts anderes als eine Bitfolge, die du dann als einzelne Bytes im eeprom ablegen kannst... die Bitzahl ist immer gleich und besteht (neben den Start/Stop/Statusbits) aus einem Hersteller- und einem Gerätecode... also im Prinzip kann dein Programm ziemlich dumm sein und die Bitfolge die es empfängt original abspeichern und bei Bedarf vergleichen (erneuter Empfang) und auch senden.
@Adrian: Also theoretisch geht das garnicht, weil sich die Codes ja nicht wiederholen müssen. Wenn Du z.B. auf der FB die "5" drückst und dann das Signal aufzeichnest, dann ist ja nicht sicher, ob beim nächstenmal wieder der gleiche Code für die "5" gesendet wird. Bei Infrarot-Türöffnern für Autos wird das absichtlich gemacht (eben damit man die Schlüssel nicht einfach kopieren kann), aber auch bei manchen Fernbedienungen wird das so gemacht, damit der Empfänger unterscheiden kann, ob eine Taste noch oder schon wieder gedrückt wird. Da ändert sich zwar nur ein Bit, aber für Dich bedeutet das, daß der Empfänger nur auf jeden 2. Tastendruck reagiert. Ein weiteres Problem ist, daß manche Fernbedienungen die Signale ständig wiederholen solange die Taste gedrückt ist. Dadurch bekommst Du zum einen ziemlich lange Signalfolgen, die dann auch viel Speicher kosten, zum anderen darf die Taste an der FB während der Lernphase nur ganz kurz gedrückt werden, weil das ja die Mindestzeit vorgibt, die man die Taste in Zukunft drücken muß. Deshalb sage ich: Es gibt gar keine lernfähigen universellen Fernbedienungen. Und meine Erfahrung bestätigt das: Die lernfähigen Fernbedienungen kommen nicht mit allen Fernbedienungen klar, auch z.B. Girder mit IgorPlug-USB nicht. Obwohl die definitiv Signale der passenden Frequenz (also nicht z.B. 450kHz oder so) empfangen, haben sie bei manchen Modellen schlicht Probleme. Die Lösung des Problems besteht meiner Meinung nach darin, daß man eben die gängigen Protokolle erkennen kann und dann nur deren Inhalt und das Protokoll abspeichert. Markus
Hi, man kann prinzipiell schon das "Rohformat" speichern. Entweder die High- bzw. Low-Pegel messen (per Timer) und die Werte speichern oder eben halt die ganz harte Tour und quasi bei jedem MC-Takt den anliegenden Zustand speichern. Ich habe mit eine RC5-Erkenn-Routine geschrieben, die zum speichern 2 Byte braucht. Auf die harte Tour müsste ich 16000 Byte speichern... ABER: Das Problem, das Markus angeschsprochen hat, bleibt. Sobald Toggle-Bit'S o.ä. auftauchen ist's ohne Protokoll-Beachtung vorbei. Der Anhang ist auch ganz nützlich, eine Diplomarbeit von jemandem! Sebastian
Von mir mal wieder ein theoretischer, möglicherweise total unrealistischer Einwurf: Stichwort Neuroinformatik Habe mich damit nicht auseinandergesetzt, aber meine Freundin hat da in der Uni mal was gemacht. Da wurden (in Matlab, und das gar nicht mal soooo umfangreich) Neuronen modelliert, die bestimmte Muster lernten. Nach vielen Lernwiederholungen konnten sie auch etwas verrauschte Muster erkennen, wahrscheinlich würde auch ein Toggle-Bit wie bei RC5 durchgehen. Ob das in einem AVR programmierbar ist, weiss ich leider selbst nicht.
Neuronale Netze müssen trainiert werden, damit sie wissen worauf es ankommt. Und zwar nicht nur einmal, damit das Netz auch lernt, worin die Unterschiede liegen. Wenn Du z.B. die Taste "5" 1,2 Sekunden gedrückt hälst und die Taste "6" 1,5 Sekunden, dann muß das Netz lernen, daß die Dauer eben kein Unterscheidungskriterium ist. Ein weiteres Problem ist das lernen von zusätzlichen Codes. Angenommen, Du hast am Anfang nur eine Fernbedienung. Dann lernt das Netz, daß der Gerätecode keine Bedeutung hat, weil der ja immer gleich ist. Kommt dann eine zweite Fernbedienung dazu, dann muß das Netz umtrainiert werden, damit es die Unterschiede lernt. Dazu braucht man wohl auch wieder Codes von der ersten Fernbedienung. Markus
Hallo zusammen, ich bin auch gerade an so einem ähnlichem Thema. Habe mir dabei auch überlegt alle Protokolle zu speichern und soweiter und sofort habe mir dazu den IRMP-Artikel hier durchgelesen (find ich recht gut gelungen, so nebenbei). Dennoch verstehe ich nicht wieso das ganze so schwer sein soll. Kann man nicht einfach mit einem Phototransistor das Signal aufzeichnen. Anhand eines Timers dann feststellen welche Frequenz das Signal dann hat (hier ist es ja bereits bekannt 38kHz) und dann das einfach abspeichern? Das Problem mit den Togglebits müsste man halt dann einfach manuell lösen, also nachschauen welches ist das Togglebit und dann beides akzeptieren. Zum Thema mit den 16kbytes (is ja blöd auf so nem AVR :) ), ich würde einfach die bereits erlernten Signale übschreiben, wenn für die selbe Taste (soferns mit Tasten sein soll) ein anderen Signal kommt. Oder nicht?!? Habe bisher nur die Theorie von meiner Schaltung und noch keine Erfahrungen beim Aufzeichnen der Signale. wäre auch dankbar über Infos über die Problematik hier :) danke
Franz Wallner schrieb: > Habe mir dabei auch überlegt alle Protokolle zu speichern und soweiter > und sofort habe mir dazu den IRMP-Artikel hier durchgelesen (find ich > recht gut gelungen, so nebenbei). Danke für das Kompliment :-) > Dennoch verstehe ich nicht wieso das ganze so schwer sein soll. > Kann man nicht einfach mit einem Phototransistor das Signal aufzeichnen. Du siehst dann aber auch den ganzen Dreck aus dem Umgebungslicht. Die IR-Empfänger (TSOPxxxx) nehmen Dir das ab. Sie sind auf eine Modulationsfrequenz getrimmt und filtern alles andere raus. Am Ausgang siehst Du dann aber nicht mehr sie Modulationsfrequenz, sondern nur noch die Information "Signal da" oder "Signal nicht da". Bei einem einfachen Phototransistor musst Du eine optische (oder programmtechnische) Isolation gegenüber dem Umgebungslicht schaffen. > Anhand eines Timers dann feststellen welche Frequenz das Signal dann hat > (hier ist es ja bereits bekannt 38kHz) und dann das einfach abspeichern? Prinzipiell ja. Dafür brauchst Du aber jede Menge Speicher, denn Du musst für jedes Bit die Puls-/Pausenlängen aufzeichnen. Aber manchmal reicht es einfach nicht, die Signale "dumm" und ohne Hintergrundwissen aufzuzeichnen, manchmal muss man einfach "wissen", was sich hinter bestimmten Informationen verbirgt. Dazu gehören: - Toggle-Bits bei RC5, RC6 und anderen(!) IR-Protokollen - Automatisch generierte Wiederholungsframes (mit teilweise invertieren Bits) zwecks Datenredundanz zur Erkennung von Fehlern - Wiederholungsframes durch längere Tastendrücke - Unterscheidung von langen und kurzen Tastendrücken - Repetition-Frames, z.B. im NEC-Protokoll für "wiederhole das letzte Kommando" Das waren nur einige Punkte, es gibt aber noch einige weitere semantische Informationen, die Du nicht einfach aufzeichnen und dann abspielen kannst. > Das Problem mit den Togglebits müsste man halt dann einfach manuell > lösen, > also nachschauen welches ist das Togglebit und dann beides akzeptieren. Du musst also "Wissen" über die einzelnen Protokolle einbauen, d.h. sie auch erkennen und "verstehen". Wo Du dann am Schluss landest, ist vorherzusehen: IRMP :-) > Zum Thema mit den 16kbytes (is ja blöd auf so nem AVR :) ), ich würde > einfach die bereits erlernten Signale übschreiben, wenn für die selbe > Taste (soferns mit Tasten sein soll) ein anderen Signal kommt. Oder > nicht?!? Rechnen wir mal aus, wieviele IR-Kommandos Du in einem EEPROM von 512 Bytes abspeichern kannst, wenn Du sie nicht decodierst, sondern einfach als Scan (analog zu einer Tonbandaufnahme) speicherst. Als Beispiel nehmen wir das NEC-Protokoll mit einer Länge von 32 Bits. Das NEC-Protokoll ist heutzutage das Protokoll, was mit über 70 Prozent "Marktanteil" in unseren Haushalten vorzufinden ist. Und vergiss mal RC5. Das ist ausgestorben. Man findet das in keinem modernen Gerät mehr. Ich rechne es mal kurz durch für NEC: 1 Start-Bit 32 Daten-Bits 1 Stop-Bit Das macht 34 Bits. Du musst also 34 Puls- und 34 Pausenlängen speichern. Bei einer Auflösung von 8-Bit brauchst Du dafür 68 Bytes Speicher. Bei einem 512er EEPROM kannst Du so maximal 7 Tasten abspeichern. Nur: die Signal-Längen unterscheiden sich bei bestimmten IR-Protokollen um mehrere Größenordnungen, so dass Du mit einem 8-Bit-Zähler auch bei geschickter Wahl der Scan-Frequenz nicht auskommen wirst. Du brauchst also 16-Bit-Zähler und damit auch 16-Bit-Werte im EEPROM. Damit halbiert sich die Zahl der abspeicherbaren Kommandos auf lächerliche 3 Tasten. Dabei habe ich die dazugehörige Modulationsfrequenz mal ganz weggelassen. Bei anderen Protokollen siehts noch schlimmer aus, da können bei einem einzelnen kurzen(!) Tastendruck bis zu 3 Frames rausgeschickt werden (z.B. SIRCS). Nach einem Tastendruck wäre dann schon Dein EEPROM voll! Andere Protokolle haben bis zu 48 Bits (z.B. Kaseikyo) mit bis zu 3 Startbits. Da sind es auch nur noch 2 Tasten, die Du abspeichern könntest. Bei IRMP wird ein kompletter IR-Frame in einer Datenstruktur von 6 Bytes gespeichert. Damit kannst Du 85 verschiedene Kommandos in einem 512 Byte-EEPROM abspeichern. Das kann man sogar noch auf über 100 erhöhen, wenn man die Datenstruktur etwas kompakter ablegt (z.b. Protokollnummer und Flag in ein Byte schiebt). Aber selbst, wenn Du jede Menge Speicher hast, wirst Du Dir wegen der fehlenden Semantikfunktion Deines Aufzeichnungsgedankens jede Menge unlösbare Probleme einhandeln. Es wird nie "richtig" funktionieren. Gruß, Frank
Interessant, ich habe den Gedanken weitergeführt und eine gut 90%ige Lösung (also 9 von 10 FBs) funktionieren gefunden, dabei analysiere ich nach Zeitklassen (kurz=0, lang=1, darüber=Ende einer Sequenz) und speichere bis zu 120 Bit/IR-Befehl im EEPROM, für 16 Befehle benötige ich daher 16x15=300 Bytes + 16 Verwaltungsbytes=316 Bytes im EEPROM, bei Bedarf können aber durch einfaches Ändern der Konstante mehr oder weniger Befehle gelernt werden. Hier gibts mehr: Beitrag "Atmega - Jede beliebige IR-Fernbedienung erkennen"
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.