Hallo zusammen, wir haben auf Basis von IRMP/IRSND eine lernfähige Fernbedienung entwickelt und das Projekt im Artikel unter http://www.mikrocontroller.net/articles/DIY_Lernf%C3%A4hige_Fernbedienung_mit_IRMP zusammengefasst. Sicher gibt es noch Anregungen und Tipps, wie man das Programm erweitern und verbessern kann. Die Fernbedienung kann mittels IRMP Fernbedienungs-Codes speichern und auch wiedergeben. Insgesamt gibt es fünf Tasten zum Senden von Codes: - Power - Rauf - Runter - Rechts - Links Diese Tasten können 3-fach belegt werden. Dafür gibt es eine zusätzliche Select-Taste für das gewünschte Gerät. Es können aber auch für eine der drei Speicherplätze unterschiedliche Geräte angesteuert werden. Das ist zum Beispiel sinnvoll, wenn man die TV-Kanalwahl über den Satellitenempfänger einstellen muss, aber die Lautstärkewahl über das Fernsehgerät erfolgt. Angezeigt wird das anzusteuernde Gerät über 3 LEDs. Mit der Select-Taste wird das gewünschte Gerät ausgewählt. Drückt man die Taste länger, schaltet die Fernbedienung in den Lernmodus. Dies wird durch Leuchten aller 3 LEDs angezeigt. Sendet man nun mit der Original-Fernbedienung eine Taste (zum Beispiel POWER), blinken die 3 LEDs kurzzeitig auf. Nun muss man die Taste an seiner DIY-Fernbedienung drücken, auf welcher das Signal gespeichert werden soll. Anschließend blinken die LEDs nochmal zur Bestätigung auf. Das Signal ist nun gespeichert und kann durch Drücken der jeweiligen Taste gesendet werden. Viel Spaß, Robert und Frank
Die Version 1.1.0 ist nun verfügbar: http://www.mikrocontroller.net/articles/DIY_Lernf%C3%A4hige_Fernbedienung_mit_IRMP - Stromsparmodus hinzugefügt (Verbrauch: unter 1 µA) - Schaltung erweitert: An-/Abschalten des IR-Empfängers - Kleinere Verbesserungen bei der Anzeige Viel Spaß, Robert und Frank
Schönes Projekt. Müsste noch jemand ein taugliches Layout zusammenzimmern und Gehäuse besorgen :-D Was mir noch auffällt: 100nF an RESET Eingang würde ich nicht machen. Manche Programmiergeräte haben damit Probleme und es wird auch AFAIK von Atmel davon abgeraten (gibt da eine AppNote). Als Delay ist das sowieso unnötig, da der Prozessor intern einen konfigurierbaren Startup Delay hat. Gegen EMV würden vermutlich auch schon 1nF reichen. Die Transistoren mit dem 4,7k Widerstand brauchen für Batteriebetrieb natürlich gut Strom. hier würde ich eventuell auf MOSFETs zurückgreifen.
Simon K. schrieb: > Schönes Projekt. Müsste noch jemand ein taugliches Layout > zusammenzimmern und Gehäuse besorgen :-D An einem Layout bin ich schon dran. Allerdings müsste man erst das Gehäuse finden. Andersherum hat das wohl wenig Sinn ;-) > Was mir noch auffällt: > 100nF an RESET Eingang würde ich nicht machen. Manche Programmiergeräte > haben damit Probleme und es wird auch AFAIK von Atmel davon abgeraten > (gibt da eine AppNote). Als Delay ist das sowieso unnötig, da der > Prozessor intern einen konfigurierbaren Startup Delay hat. Gegen EMV > würden vermutlich auch schon 1nF reichen. Okay, können wir ändern. > Die Transistoren mit dem 4,7k Widerstand brauchen für Batteriebetrieb > natürlich gut Strom. hier würde ich eventuell auf MOSFETs zurückgreifen. Der Strom über den Basiswiderstand ist aber nur im aktiven Zustand maßgeblich, oder? Hier verbraucht die IR-Sendediode sowieso ein Vielfaches, so daß der Basisstrom eher vernachlässigbar ist. Ebenso fließt nur ein Strom über T2, wenn die Schaltung im Lernmodus ist. Das ist sie aber nur für kurze Zeit, außerdem programmiert man die Tasten ja nicht alle paar Minuten um ;-) Oder habe ich das jetzt falsch verstanden? Solange die Pins an den Basis-Vorwiderständen Low sind (und das sind sie eigentlich die meiste Zeit), fließt doch auch kein Strom? Oder meinst Du vielleicht Leckströme über die Transistoren? Gruß, Frank
Frank M. schrieb: >> Die Transistoren mit dem 4,7k Widerstand brauchen für Batteriebetrieb >> natürlich gut Strom. hier würde ich eventuell auf MOSFETs zurückgreifen. > Oder habe ich das jetzt falsch verstanden? Solange die Pins an den > Basis-Vorwiderständen Low sind (und das sind sie eigentlich die meiste > Zeit), fließt doch auch kein Strom? Oder meinst Du vielleicht Leckströme > über die Transistoren? Stimmt schon, wenn ich da noch mal drüber nachdenke hast du natürlich Recht.
Warum einen so riesiegen µC? Ein Tiny84 würde es doch auch tun, oder? Ich komme auf 10pins wenn ich die 5 Taster an eine Widerstandsmatrix schalte, die drei Leds an 2 Pins und TX + RX weglasse. Dazu kommt noch Reset. Also ist noch 1pin am Ende frei.
Samuel K. schrieb: > Warum einen so riesiegen µC? IRMP/IRSND unterstützen mittlerweile bis zu 28 verschiedene Fernbedienungsprotokolle. Damit sind wohl 98% aller im normalen Haushalt vorkommenden FB-Protokolle abgedeckt. Dafür braucht man aber in der Kombination IRMP + IRSND mehr als 8K Flash, wenn man alle FB-Protokolle aktivieren/unterstützen will. Deshalb haben wir uns für den ATmega168 entschieden. > Ein Tiny84 würde es doch auch tun, oder? Ja, er würde es auch tun. Allerdings könnte man damit nur die gebräuchlichsten FB-Protokolle unterstützen, dann ist man ungefähr bei 7K Code. Okay, man käme damit zwar auch auf eine Trefferrate von ca. 80%, aber genau die eine FB, die man unbedingt braucht, wird dann gerade nicht unterstützt, das ist dann ärgerlich ;-) Ein Tiny164 wäre daher ideal... gibbet aber nicht... oder doch? > Ich komme auf 10pins wenn ich die 5 Taster an eine Widerstandsmatrix > schalte, die drei Leds an 2 Pins und TX + RX weglasse. Dazu kommt noch > Reset. Also ist noch 1pin am Ende frei. Ich habe das Projekt mit meinem Sohn Robert angepackt, damit er dabei das Programmieren von µCs lernt und auch ein wenig Gefühl für Elektronik bekommt und sie versteht. Praxis ist doch viel spannender als graue Theorie :-) Da ist ein ATmega168 (als großer Bruder des veralteten ATmega8) doch eigentlich das geeignete Studienobjekt. Sicher kann man in der Schaltung noch eine Menge tricksen, ich wollte aber erstmal beim "klassischen Standard" bleiben, damit auch ein Anfänger sowohl mit der Schaltung als auch mit dem Programm gut zurechtkommt und auch versteht, was da passiert. Sicher kann man nachher, wenn das Thema mit dem ATmega168 ausgefeilt ist, eine Phase 2 einschieben und darüber nachdenken, wie man es noch besser/geschickter machen kann. Ich würde daher sagen, dass wir unsere noch übriggebliebenen Aufgabenstellungen (Ansteuern mehrerer Geräte über eine Taste, z.B. alle auf einmal "AUS" und den Bootloader über UART und/oder IR) weiterhin mit der aktuellen Schaltung durchziehen. Da kann man noch eine Menge dran lernen. Erst dann, wenn man sich zufrieden zurücklehnen kann und sagt "Alles fertig, ich weiß nichts mehr dran zu verbessern", kann man sich ins nächste Level schießen ;-) Davon abgesehen: Eine handliche Fernbedienung hat immer eine gewisse räumliche Ausdehnung. Da passt ein ATmega168 im DIP-Gehäuise allemal rein. Gruß, Frank
man könnte versuchen den Empfänger wegzurationalisieren und die Sende-LED zu benutzen. wenn das nicht funktioniert eine normale Fotodiode oder Transistor. Wenn das funktionieren würde hätte das den positiven Seiteneffekt, dass man nicht an die feste Abtastrate des Empfängers gebunden ist und sich optimal auf das angelernte Protokoll einstellen kann. Edit: der Empfänger braucht ja auch schließlich keine große Reichweite.
@Vlad: Hmmm, gar nicht mal so übel die Idee! Immerhin hält man beim anlernen ja sowieso die zu lernende Fernbedienung ziemlich nah an die lernende Fernbedienung. Da bräuchte man gar keinen AGC. Eventuell nicht mal generell einen großartigen Verstärker. Allerdings müsste man trotzdem irgendwas Bandpassmäßiges verwenden. Eventuell die Fotodiode an einen ADC hängen? Die internen dürften aber zu langsam sein zum samplen und zur digitalen Weiterverarbeitung. Wäre auch etwas mit Kanonen auf Fernbedienungen geschossen.
Vlad Tepesch schrieb: > man könnte versuchen den Empfänger wegzurationalisieren und die > Sende-LED zu benutzen. Eine sehr interessante Idee, da man beim Empfang keine große Reichweite braucht, sondern die Original-FB durchaus direkt davorhalten könnte. Allerdings ist dann das Erkennen der Modulation und das Ausfiltern von Störsignalen in Software umzusetzen, da nimmt so ein TSOP einem schon eine Menge Arbeit ab ;-) Wie empfängt man mit einer Diode? Ich dachte bisher, man "misst" Ladungen und Entladungen. Funktioniert das bei den Datenraten heutiger FBs schnell genug? Wenn das tatsächlich geht, finde ich die Idee ganz gut, das könnte man sich dann durchaus auf den Aufgabenplan setzen - in einer späteren Stufe. > Wenn das funktionieren würde hätte das den positiven Seiteneffekt, dass > man nicht an die feste Abtastrate des Empfängers gebunden ist und sich > optimal auf das angelernte Protokoll einstellen kann. Das stimmt allerdings. Mit einem TSOP-1738 oder einem verwandten Empfänger, der genügend "breitbandig" ist, kann man bei der geringen Entfernung aber auch noch Signale einfangen, die in einem Modulationsfrequenzbereich von 32kHz bis 44kHz liegen. Das sollte für die meisten FBs reichen. Wenn es aber lediglich darum geht, einen weiteren µC-Pin einzusparen, könnte man auch versuchen, den TSOP-Ausgang über eine Diode zu einem Open-Collector-Ausgang umzufunktionieren und diesen dann z.B. an den Output für die Sendediode anzuflanschen. Dann könnte man diesen µC-Pin als Ausgang zum Senden und als Eingang zum Empfangen verwenden. Wie man sieht, gibt es da viele Möglichkeiten. Vielleicht sollten wir das weiter diskutieren :-) Gruß, Frank
Simon K. schrieb: > @Vlad: Hmmm, gar nicht mal so übel die Idee! Frank M. schrieb: > Vlad Tepesch schrieb: >> man könnte versuchen den Empfänger wegzurationalisieren und die >> Sende-LED zu benutzen. > naja, die idee stammt ja nicht von mir. einige der Universalfernbedienungen haben ja nur eine LED. aber keine hat so einen IR-Empfänger, die haben alle maximal eine Fotodiode drauf. Simon K. schrieb: > Eventuell die Fotodiode an einen ADC hängen? ADC wird nicht gehen. 77kSamples/s sind zu wenig man müsste das Signal soweit verstärken, dass es digital auswertbar wird. Analogtechnik ist nicht so mein Ding. Vielleicht reicht ein Transistor. Wenn man dazu allerdings einen Opamp braucht, ist es schon wieder nicht mehr so toll. Der Softwareanpassungsaufwand wäre ja auch noch. Man müsste den Pin ja wenigstens mit 200kHz abtasten, wenn man bis 50kHz Signale zuverlässig erkennen will. Eventuell könnte man mit dem AnalogComperator arbeiten, aber ich habe im Datenblatt keine Angaben gesehen, bis zu welchen Frequenzen der benutzbar ist. Frank M. schrieb: > Wenn es aber lediglich darum geht, einen weiteren µC-Pin einzusparen eher braucht man zusätzliche um die Verstärkerschaltung zu deaktivieren.
Betrifft: Wegrationalisieren Eigenlich kann man den TSOP direkt vom AVR (Pin B1/RECON an R3) versorgen lassen. Das spart den Transistor und Basiswiderstand ein (und 5 kalte Lötstellen weniger ;).
Werner B. schrieb: > Eigenlich kann man den TSOP direkt vom AVR (Pin B1/RECON an R3) > versorgen lassen. Das ist eine super Idee! Danke, wird umgesetzt! Gruß, Frank
Irgendwie stimmt das Layout des M168 im Schaltplan nicht. Schau dir mal Port B und D an! Vorallem die Quarzpins.
M. W. schrieb: > Irgendwie stimmt das Layout des M168 im Schaltplan nicht. > Schau dir mal Port B und D an! Vorallem die Quarzpins. Whoops, Du hast vollkommen Recht! Der Quarz muss natürlich an PB6/PB7. Damit muss dann IR an PD5. Bisher haben wir zwar den Quarz schon auf der Lochrasterplatine festgelötet, aber bisher noch nicht durch die Fuse aktiviert. Deshalb ist der Fehler gar nicht aufgefallen. Ich bringe das Layout in Ordnung und passe die Software bzgl. des IR-Signals an. Danke für den Hinweis, da hätte ich lange gesucht, warum denn der Quarz nicht läuft ;-) Gruß, Frank
Frank M. schrieb: > Ich bringe das Layout in Ordnung und passe die Software bzgl. des > IR-Signals an. Das Layout und die Software habe ich nun korrigiert. Änderungen in der Version 1.2.0: - Anschlussfehler XTAL geändert - IR-Empfänger nun an PD5 angeschlossen - Aktivierung des IR-Empfängers direkt über PB1 - ohne Transistor Siehe auch Artikel: http://www.mikrocontroller.net/articles/DIY_Lernf%C3%A4hige_Fernbedienung_mit_IRMP Viel Spaß, Frank
Die neue Version (1.3.0) ist nun verfügbar: Änderungen: - Speicherung der Tastendrucklängen - Makros möglich: Bis zu 5 Befehle und Pausen pro Taste Download über Artikel: http://www.mikrocontroller.net/articles/DIY_Lernf%C3%A4hige_Fernbedienung_mit_IRMP Viel Spaß, Robert und Frank
Die neue Version (1.4.0) ist nun verfügbar: Änderungen: - Ansteuerlogik RECON geändert: Active Low, siehe Schaltplanänderung - 8 MHz Quartz aktiviert - Bootloader-Support (UART) Download über Artikel: http://www.mikrocontroller.net/articles/DIY_Lernf%C3%A4hige_Fernbedienung_mit_IRMP Viel Spaß, Robert und Frank
Was fängt man bitte mit einer Fernbedienung an, die nur fünf Tasten hat?
Klaus schrieb: > Was fängt man bitte mit einer Fernbedienung an, die nur fünf Tasten hat? Ich verstehe die Codesammlung eher als Sammlung von sinnvollen Ideen/Implementationen/Design-Studien und weniger zur Vorstellung von Komplett-Projekten eierlegender Wollmilchsäue. Hier in der Codesammlung kann jeder bereits erdachte Lösungen bzw. Lösungsansätze für eigene Projekte übernehmen. Die Lernfähige Fernbedienung mit 5 Tasten ist daher für mich nicht unbedingt als fertige Lösung zu sehen, sondern eher als Ideensammlung. Dabei wird eine sinnvolle Anwendung von IRMP und IRSND aufgezeigt. Ebenso kann man sich Anregungen holen, wie man eine Schaltung hard- und softwaretechnisch möglichst batterieschonend umsetzt oder wie man Datenstrukturen möglichst gepackt im EEPROM des µCs ablegt. Das Projekt ist also für Dich nicht unbedingt zum 1:1-Nachbau gedacht. Wenn Du mehr Tasten brauchst, werfe einfach die Tastatur-Routinen raus und ersetze diese durch eigene :-) Zurück zu Deiner Frage: Ich sehe auch eine 5-Tasten-FB als durchaus sinnvoll an: Meist braucht man nämlich sowieso nur 5 Tasten: Ein-/Aus, Kanal +/-, Laut +/-. Dadurch, dass die Lernfähige Fernbedienung auch noch 3 Ebenen bietet, hast Du also schon mal 5 x 3 = 15 freiprogrammierbare Tasten. Desweiteren sind die Tasten makrofähig, so dass Du ganze Kommando-Abfolgen auf einer Taste speichern kannst. Ein praktisches Beispiel: Ebene 1: ========= Power: TV an, SAT an, 4 Sek. warten, TV umschalten auf SCART-1 Kanal +/-: Kanal +/- am Satellitenempfänger Laut +/-: Lautstärkeregelung am TV Ebene 2: ========= Power: TV an, DVD-Player an, 4 Sek. warten, TV umschalten auf HDMI Kanal +/-: Play-/Pause am DVD-Player Laut +/-: Lautstärkeregelung am TV Ebene 3: ========= Power: Radio-Tuner an/aus, Verstärker der Steroanlage an/aus Kanal +/-: Kanal +/- am Radio-Tuner Laut +/-: Lautstärkeregelung am Verstärker Somit kann man die Selbstbau-FB durchaus sinnvoll einsetzen - nämlich für die meistbenutzten Funktionen seiner elektronischen Geräte, ohne immer wieder die Fernbedienung wechseln zu müssen. Aber wie gesagt: Es hindert Dich niemand, eine Tastatur-Matrix anzuschließen oder die noch unbenutzten Pins des ATMega zu nutzen, um weitere Tasten anzuschließen. Gruß, Frank
Bin heute auf dieses Projekt gestoßen und muss leider feststellen, dass hier schon längere Zeit nichts passiert ist. Die Idee ist sicherlich interessant - vor allem für mich als Einsteiger in die µC Programmierung. Insofern zunächst vielen Dank dafür! Zunächst frage ich mich gerade warum in der tabellarischen Auflistung der benötigen Bauteile Q1 mit 16 MHz angegeben ist, während im Schaltplan von 8 MHz die Rede ist. Wenn ich den Artikel über die von dir erstellte IRMP "Bibliothek" richtig verstehe, dann braucht es "nur" 8 MHz. Das ist in Bezug auf die Sparsamkeit bestimmt auch besser so. Was mich außerdem brennend interessieren würde wäre der batteriebetriebene Einsatz. Mit 3 Mignon-Zellen scheint es ja bereits zu klappen. Was wäre zu beachten bzw. zu ändern um das Ganze dahingehend anzupassen, dass es mit 2 Mignonzellen (~3 V) funktioniert? Laut Datenblatt sollte sich zumindest der ATmega168 mit 2.7V - 5.5V betreiben lassen (zumindest im Bereich 0-10 MHz).
Karol Babioch schrieb: > Zunächst frage ich mich gerade warum in der tabellarischen Auflistung > der benötigen Bauteile Q1 mit 16 MHz angegeben ist, während im > Schaltplan von 8 MHz die Rede ist. Wenn ich den Artikel über die von dir > erstellte IRMP "Bibliothek" richtig verstehe, dann braucht es "nur" 8 > MHz. Das ist in Bezug auf die Sparsamkeit bestimmt auch besser so. 8 MHz reichen natürlich aus, die 16 MHz sind wahrscheinlich durch Copy&Paste aus eine anderen Schaltung dort hineingekommen. > Was mich außerdem brennend interessieren würde wäre der > batteriebetriebene Einsatz. Mit 3 Mignon-Zellen scheint es ja bereits zu > klappen. Was wäre zu beachten bzw. zu ändern um das Ganze dahingehend > anzupassen, dass es mit 2 Mignonzellen (~3 V) funktioniert? Laut > Datenblatt sollte sich zumindest der ATmega168 mit 2.7V - 5.5V betreiben > lassen (zumindest im Bereich 0-10 MHz). Das ist eine gute Frage. Zum Empfänger: mittlerweile gibt es die TSOP312xx-Familie (z.B. TSOP31236), die auch mit einer Betriebsspannung von nur ~3V auskommen. Zum Sender: Die Transistorschaltung muss wahrscheinlich angepasst werden. Das betrifft wohl sowohl den Basisvorwiderstand R1 als auch den Vorwiderstand R2. Die Vorwiderständ für die 3 Leuchtdioden müssten wohl ebenso angepasst werden. Alternativ könnte man auch einen Step-Up-Regler nutzen, welchen den nötigen Saft aus einer oder zwei Mignonzellen bereitstellt. Siehe auch: http://www.mikrocontroller.net/articles/Versorgung_aus_einer_Zelle#Step-Up-Schaltregler Gruß, Frank
Hallo Frank, ich bin auch gerade erst über dein Projekt gestolpert. Super gemacht :) Wenn du immer noch auf der Suche nach Erweiterungsmöglichkeiten bist hätte ich einen Vorschlag. Die Empfangenen IR Codes auf dem UART ausgeben und die möglichkeit über UART IR Befehle zu senden. Damit könnte man es als BlackBox auch an andere Projekte und PCs anschliessen. Mangels C kenntnisse kann ich es leider nicht selbst realisieren aber mein Dank würde dir ewig nachschleichen ;)
Wobei das eher ein Fall für die IRMP Bibliothek an sich wäre ;).
Chr. Messener schrieb: > Die Empfangenen IR Codes auf dem UART ausgeben und die möglichkeit über > UART IR Befehle zu senden. Habe ich bereits vor Monaten realisiert :-) Allerdings habe ich es nie veröffentlicht, weil ich mit meinem Sohn zusammen noch eine GUI dafür programmieren wollten, wo man sich per Mausklick eine lernfähige Fernbedienung auf dem PC zusammenklicken kann. Das Projekt ist aber nie fertig geworden. Was funktioniert, ist ein kommandozeilenbasiertes Programm zum Empfangen und Senden von IR-Frames. Vielleicht schreibe ich das mal in den IRMP-Artikel... Viele Grüße, Frank
Hallo Frank, ich habe deine FB nachgebaut, funktioniert prima mit dem Samsung code und Loewe RC5/TV; Loewe RC5/VCR tut es aber nicht. Woran könnte das liegen? Ansonsten sehr schönes und durchdachtes Projekt von dir und deinem Sohn Gruß Melanie
Hallo Melanie, Melanie Krüger schrieb: > ich habe deine FB nachgebaut, funktioniert prima mit dem Samsung code > und Loewe RC5/TV; Loewe RC5/VCR tut es aber nicht. Woran könnte das > liegen? Gute Frage, keine Ahnung. RC5 ist eigentlich sehr simpel und schon lange im IRMP implementiert. Kannst Du im IRMP mal IRMP_LOGGING aktivieren und hier die Scans zur Loewe RC5/VCR einstellen - vielleicht auch zum Vergleich die Scans der RC5/TV? Nähere Beschreibung zum Logging siehe hier: http://www.mikrocontroller.net/articles/IRMP#Scannen_von_unbekannten_Protokollen Viele Grüße, Frank
Hallo Frank, wird schwierig, ich habe als Decoder eine Uraltbastelei mit SAA3049 die problemlos mit der Loewe control 150 Fernbediehnung im VCR-mode funktioniert ich müßte deinen Empfänger aufbauen und das Protokoll scannen wenn ich dich richtig verstanden habe Gruß Melanie
Melanie Krüger schrieb: > wird schwierig, ich habe als Decoder eine Uraltbastelei mit SAA3049 die > problemlos mit der Loewe control 150 Fernbediehnung im VCR-mode > funktioniert > ich müßte deinen Empfänger aufbauen und das Protokoll scannen wenn ich > dich richtig verstanden habe Komisch, ich las heute morgen von Dir: > ich habe deine FB nachgebaut, funktioniert prima mit dem Samsung code > und Loewe RC5/TV; Loewe RC5/VCR tut es aber nicht. Woran könnte das > liegen? Hast Du denn keinen TSOPxxxx als Empfänger an die DIY-FB gehängt, um die Codes auszulesen und dann per Tastendruck zu speichern? Gruß, Frank
Hallo Frank, dann habe ich dich mißverstanden, ja klar habe ich da einen TSOP dran, ich kann also die Daten aus der FB aulesen- ich lasse von mir hören Gruß Melanie
Hallo, ich hab die Fernbedienung mal nachgebastelt, vielleicht kann jemand was damit anfangen. Ich hab mir erlaubt die Schaltung ein wenig zu modifizieren Der Resonator ist von Reichelt und echt winzig Die 3 LEDs hab ich durch eine PLCC6 RGB ersetzt und die IR LEDs werden durch einen MOSFET getrieben Die 4 Patches haben sich leider nicht vermeiden lassen und der ISP Stecker kommt wieder weg. Leider habe ich , als ich fertig war, festgestellt dass ich nicht allzuviel damit anfangen kann weil das Dreambox Protokoll nicht unterstützt wird.. Und mir gelingt es nicht nur einen Tastendruck abzuspeichern. Nochmal danke an Frenk für die Vorlage :)
Chr. Messener schrieb: > ich hab die Fernbedienung mal nachgebastelt, vielleicht kann jemand was > damit anfangen. Sehr schön, gefällt mir. > Leider habe ich , als ich fertig war, festgestellt dass ich nicht > allzuviel damit anfangen kann weil das Dreambox Protokoll nicht > unterstützt wird.. Ich habe selbst eine Dreambox zu Hause. Ich schaue mal, dass ich das Dreambox-Protokoll einbaue. Das ist ein bitserielles Protokoll. Ich mag es nicht sonderlich, da es bei vielen gleichen Bits Gefahr läuft, aus der Synchronisation zu laufen. > Und mir gelingt es nicht nur einen Tastendruck abzuspeichern. Du meinst, Du kannst gar nicht so kurz drücken? Welche FB? Welches Protokoll? Vielleicht ist es eine FB, die prinzipiell aus Datensicherheitsgründen jeden Frame 1x wiederholt... Gruß, Frank
Frank M. schrieb: > Du meinst, Du kannst gar nicht so kurz drücken? Welche FB? Welches > Protokoll? Ich habe es noch nicht sonderlich intensiv ausprobiert. ist ne LG Glotze, Protokoll kann ich im mom nicht sagen da ich keinen UART Anschluss vorgesehen habe. Ausprobiert hab ich es mit der Lautstärketaste, die die DB FB auf der TV einstellung ausgibt. mit der gelingen einzelschritte und bei langem Tastendruck wird wiederholt mit der DIY FB sind mir bis jetzt nur 3er Schritte gelungen. Deshalb brauchst Du aber nicht extra aktiv werden. :) Falls doch, die DB Powertaste würde eigentlich reichen
Hey, ich habe gerade den Artikel über die Lernfähigefernbedienung hier gefunden: http://www.mikrocontroller.net/articles/DIY_Lernf%C3%A4hige_Fernbedienung_mit_IRMP ich habe mir die Source Datei geladen und dann auch den WINAVR aber leider kann ich die Datei dort nicht öffnen. Folgende Fehlermeldung bekomme ich dort: C:/Users/MrIch/Downloads/Remotecontrol/remotecontrol.aps:1: Error in sourced command file: Undefined command: "<AVRStudio><MANAGEMENT><ProjectName>remotecontrol<". Try "help". Vlt kann mir da geholfen werden mit einem Tipp? Viele Grüße
Habe auch kleinere Probleme, ich kann das Projekt fehlerfrei in meine Studio 4.19.730 einladen. Beim kompilieren kommt allerdings folgender Fehler: ../irmp.c:903:31: error: variable '***' must be const in order to be put into read-only section by means of '__attribute__((progmem))' Was es mir sagen will glaube ich zu verstehen. Da ich mich in C nicht auskenne wäre es schön, wenn mir da jemand helfen könnte. Der Fehler taucht insgesamt 11 mal auf mit unterschiedlichen Angaben für '***' Was ist zu tun??? mfg, hw-schrauber
Herby Schrauber schrieb: > ich kann das Projekt fehlerfrei in meine Studio 4.19.730 einladen. Beim > kompilieren kommt allerdings folgender Fehler: > > ../irmp.c:903:31: error: variable '***' must be const in order to be put > into read-only section by means of '__attribute__((progmem))' Das liegt daran, dass eine ältere IRMP-Version genutzt wird, Du aber einen neueren Compiler verwendest. Du kannst das folgendermaßen ändern: Ersetze alle Vorkommnisse von static PROGMEM IRMP_PARAMETER .... durch static const PROGMEM IRMP_PARAMETER .... in irmp.c. Dann sollte es laufen. Ich werde im Laufe der Tage die Zip-Datei aktualisieren. Dann ist das Problem beseitigt. Viele Grüße, Frank
Super, Dankeschön. Habe ich schonmal sofort umgesetzt. Lediglich, beim ersten Versuch kamen 11 Fehler. Mit der Funktion "Ersetzen" wurden insgesamt 23 Ersetzungen gefunden. Danach habe ich das Projekt kompiliert und es kam noch eine "Warnung": ../irsnd.c:471:22: warning: variable 'sircs_additional_command_len' set but not used [-Wunused-but-set-variable] Ich nehme an, dass ich das erst mal ignorieren kann; eine gesetzte Variable die nicht genutzt wird. Oder fehlt ein Modul, welches die Variable benutzt? VG, hw-schrauber
Herby Schrauber schrieb: > ../irsnd.c:471:22: warning: variable 'sircs_additional_command_len' set > but not used [-Wunused-but-set-variable] Die Meldung kannst Du getrost ignorieren. Vermutlich hast Du SIRCS deaktiviert und ich vergaß damals, in diesem Fall die dazugehörende Variable auch per Preprocessor auszublenden. Gruß, Frank
Hallo Frank, habe nun mal eine kleine Handverdratung der LFB erstellt, eine CPU geflasht und muss sagen, läuft erst mal genau so wie versprochen. -Klasse und Danke!- Ich hätte allerdings nich ein paar kleinere Anregungen. Da ich das Projekt nicht als Ersatz für mehrere Fernbedienungen benötige, sondern als eine Art seriellen Zugang zu einem Medienplayer, würde ich die Schaltung genre modifizieren. Ich bräuchte zum einen einen Taste mehr und fänd gut, wenn die Makrofunktionen dann in Punkto Kapazität dem einen Gerät zugute kämen. Sprich nicht 3 Geräte mit je 5 Tasten und 5 Pausen sondern ein Gerät mit 15 Tasten und 15 Pausen. Müsste ja vom EEProm her eigentlich auch passen, oder? Zudem wären noch drei Sachen hilfreich. Zum einen, wenn ich z.B. die Stromversorgung der FB bei Selektion von Gerät 3(rot) unterbreche und wieder anlege, ist automatisch Gerät 1 (grün) wieder selektiert. Hier wäre schön, wenn die letzte Einstellung nach Power on wieder aktiv ist. Ich weiß, die Schreibzyklen für das EEProm, aber ich denke das könnte man verkraften. Zweitens wäre es schön, wenn man die Tasten von Schließer auf Öffner umstellen könnte. Möglicherweise durch einen Jumper an einem freien Portpin. Drittens wäre der Aufbau bzw. die Struktur der gespeicherten Daten im EEProm interessant. Dann könnte man nach Aufnahme des Signals durch die LFB den Tastencode säubern. Und bei falschen Pausenzeiten diese z.B. einfach in einem Hex-Editor ändern ohne dass man die ganze Sequenz noch mal neu aufnehmen muss. Ist dann interessant, wenn ich eine LFB fertig konfiguriere um dann weitere mit der gleichen Funktion herzustellen. Könntest du/ihr das mal noch online stellen? Noch mal danke für das gelungene Projekt. Grüße hw-schrauber
Ich habe gerade noch mal den ganzen Blog studiert. Da scheint es immer wieder mal Schwierigkeiten mit den Protokollen zu geben. Eine super einfache Lösung zum Ermitteln eines IR-FB-Codes ist die Freeware "IR_protocol_analyzer (http://ostan.cz/IR_protocol_analyzer/IR_protocol_analyzer_v1.1.zip)" von Ondřej Staněk. Hierfür braucht man lediglich einen 3,5mm Klinkenstecker und einen Fototransistor. Man bekommt sogar einen Überblick über das Timing der Signale. Schneller und einfacher kann man an die Codes seiner FB nicht rankommen. Dieses Tool verwende ich um zu testen, ob eine FB überhaupt funktioniert und man kann gut beurteilen, welche Codes gesendet werden und weiß dadurch meist auch ob es sich um NEC, RC5 oder anderes handelt. VG, hw-schrauber
Hallo Herby, Herby Schrauber schrieb: > habe nun mal eine kleine Handverdratung der LFB erstellt, eine CPU > geflasht und muss sagen, läuft erst mal genau so wie versprochen. Freut mich :-) > Ich hätte allerdings nich ein paar kleinere Anregungen. Da ich das > Projekt nicht als Ersatz für mehrere Fernbedienungen benötige, sondern > als eine Art seriellen Zugang zu einem Medienplayer, würde ich die > Schaltung genre modifizieren. Ich bräuchte zum einen einen Taste mehr > und fänd gut, wenn die Makrofunktionen dann in Punkto Kapazität dem > einen Gerät zugute kämen. Sprich nicht 3 Geräte mit je 5 Tasten und 5 > Pausen sondern ein Gerät mit 15 Tasten und 15 Pausen. Müsste ja vom > EEProm her eigentlich auch passen, oder? Es ist hier falsch, in "Geräten" zu denken. Es sind eher 3 Tasten-Ebenen mit je 5 Tasten. Denn Du kannst für jede Taste (insg. 5) in jeder Ebene (insg. 3) eine bliebige Geräte-Adresse nebst Kommando-Code speichern. So kannst Du entweder 15 verschiedene Geräte mit je einer Taste oder auch nur ein Gerät mit 15 Tasten steuern. Und alles, was Du Dir dazwischen ausdenken kannst. Durch die Makro-Fähigkeit sind sogar noch viel mehr Geräte als nur 15 möglich. Denn jeder Befehl eines Makros enthält wieder eine eigene Geräte-Adresse und das dazugehörende Kommando. > Zudem wären noch drei Sachen hilfreich. Zum einen, wenn ich z.B. die > Stromversorgung der FB bei Selektion von Gerät 3(rot) unterbreche und > wieder anlege, ist automatisch Gerät 1 (grün) wieder selektiert. Warum willst Du die Stromversorgung abklemmen? Normalerweise befindet sich der µC im Sleep-Modus und verbraucht nur wenige Mikroampere. Klar kann man auch die gerade aktive Ebene auch im EEPROM ablegen. > Zweitens wäre es schön, wenn man die Tasten von Schließer auf Öffner > umstellen könnte. Möglicherweise durch einen Jumper an einem freien > Portpin. Ja, wäre eine Idee. Aber wo werden Öffner bei FBs benutzt? > Drittens wäre der Aufbau bzw. die Struktur der gespeicherten Daten im > EEProm interessant. Dann könnte man nach Aufnahme des Signals durch die > LFB den Tastencode säubern. Und bei falschen Pausenzeiten diese z.B. > einfach in einem Hex-Editor ändern ohne dass man die ganze Sequenz noch > mal neu aufnehmen muss. Ist dann interessant, wenn ich eine LFB fertig > konfiguriere um dann weitere mit der gleichen Funktion herzustellen. > Könntest du/ihr das mal noch online stellen? Robert und ich dachten damals daran, dass man die LFB per UART vom PC aus auch auslesen bzw. programmieren könnte. Die Programmiererei dafür ist aber Aufwand und die Zeit war immer knapp... Was hast Du denn vor? Eine Herstellung dieser LFB in Serie? Eigentlich ist der Artikel eher eine "Design-Studie", welche einem Interessenten zeigt, wie man IRMP und IRSND in Kombination sinnvoll nutzen kann. Die Motivation des Artikels war keineswegs, ein fertiges (gar serienreifes) Produkt vorzustellen. Eher war der Artikel als Anschubhilfe für eigene LFB-Projekte des Lesers gedacht. Daher auch die ziemlich realitätsferne Beschränkung auf nur 5 Taster. Bei mehr Tastern (wie auf jeder "echten" FB auch) würde ich eine Matrix verwenden. > Noch mal danke für das gelungene Projekt. Danke fürs Danke. Gruß, Frank
Herby Schrauber schrieb: > Ich habe gerade noch mal den ganzen Blog studiert. Da scheint es immer > wieder mal Schwierigkeiten mit den Protokollen zu geben. Diese sind historisch zu sehen, schließlich dauert die Entwicklung von IRMP schon seit Ende 2009 an. Mittlerweile werden die in IRMP eingebauten Protokolle alle sauber erkannt. > Eine super > einfache Lösung zum Ermitteln eines IR-FB-Codes ist die Freeware > "IR_protocol_analyzer > (http://ostan.cz/IR_protocol_analyzer/IR_protocol_analyzer_v1.1.zip)" Soviel ich weiß, kann dieser Analyzer nur eine Handvoll von Protokollen verstehen (gerade mal 4?). IRMP beherrscht mittlerweile über 30 Protokolle ohne Probleme. > von Ondřej Staněk. Hierfür braucht man lediglich einen 3,5mm > Klinkenstecker und einen Fototransistor. Man bekommt sogar einen > Überblick über das Timing der Signale. Schneller und einfacher kann man > an die Codes seiner FB nicht rankommen. Die meisten von IRMP beherrschten Protokolle wurden von mir implementiert, indem die User mir sog. IRMP-Scans zugeschickt haben. IRMP beherrscht nämlich auch die Aufzeichnung von IR-Befehlen im Raw-Mode. Diese werden dann bei Einschalten von IRMP_LOGGING auf dem UART ausgegeben und können dann direkt mit der Linux- oder Windows-Variante von IRMP analysiert werden. Für die Implementierung eines 08/15-Protokolls brauche ich für IRMP dann ca. 15 Minuten. Aber nicht alle Protokolle sind so einfach, wie man sich das denkt. Da kann der von Dir zitierte IR-Analyzer überhaupt nicht mithalten. Siehe dazu auch http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail > Dieses Tool verwende ich um zu > testen, ob eine FB überhaupt funktioniert [...] Zeigt Dir jede Handy-CAM oder andere digitale Kamera an, weil sie IR sichtbar macht. Du siehst dann direkt das Blinken der LED im Display. Einfacher gehts nicht. > und man kann gut beurteilen, > welche Codes gesendet werden und weiß dadurch meist auch ob es sich um > NEC, RC5 oder anderes handelt. Ja, für diese simplen Protokolle reicht das aus. Die Welt ist aber nicht immer so einfach ;-) Gruß, Frank
Hallo Frank, sehe gerade, du hast schon auf meinen vorletzten Eintrag geantwortet. Also, was ich machen will ist, für eine Installation zwischen 5 und 10 gleiche Geräte verwenden. Deshalb mehrer der LFBs. Aus betriebssicherheits Gründen will ich die Geräte nicht öffnen. Nun muss ich aber die Geräte zum einen mit 2 Fußschaltern (Öffner) bedienen und brauche über ein separates Panel Zugriff auf weitere Funktionen. Da die lediglich 6 Tasten am Gerät nicht alles an Funktionen im Direktzugriff zur Verfügung stellen, die original FB aber schon, dachte ich mir, ich baue eine kleine Elektronik, an der ich 4 Tasten und 2 Fußpedale anschließe und sende dann IR-Codes zum Gerät um dieses zu Steuern. Beide Elektroniken (Gerät und LFB) werden aus einem 5V Netzteil versorgt. Somit könnte man die LFB als ein kleines Bedinfeld betrachten welches IR-Seriell an ein Gerät gedockt ist. Spannend ist, durch die Lernfähigkeit würde es eben auch keine Rolle spielen, wenn in Zukunft mal ein Geräte ausfällt und durch ein anderes ersetzt wird dessen Funktionen und Tastenzuordnungen anders aussehen. Durch die Verwendung mit dem Netzteil ergibt sich natürlich, das abends alles ausgeschaltet wird und morgens alles wieder an. Wenn ich die LFB mit Batterien versorge, dann gibts imemr den Stress, dass der Anweder irgendwann vor dem Problem steht, das etwas nicht funktioniert und er nicht wirklich weiß warum. Das mit der Abspeicherung des letzten Zustandes ist für dieses Projekt nicht zwingend von Nöten. Das mit den drei Eben habe ich verstanden. Und ich sehe auch den allgemeinen Vorteil. In meinem Projekt kommt es jedoch vor, dass ich auf eine Taste ein Makro legen muss, das nach heutigem Stand 8 Codes und 7 Pausen braucht. Ich brauche aber keine weiteren Ebenen. Wenn ich noch irgendwie ne Ebebumschaltung mit einbauen muss, dann ist das dem Bediener nicht intuitiv logisch was er tun muss. VG, hw-schrauber
Bei dem "IR_protocol_analyzer" geht es ja nicht in erster Linie darum, das da irgende ein Protokoll im Detail erkannt wird. Spannend ist, er zeigt mir das echte Timing an. Egal ob High oder Low. Was man dann damit macht ist ja ne zweite Sache. Nur wenn man gar keinen Anfang hat und der Empfänger nur auf bekannte Codes reagiert, dann kann dieses Tool vielleicht helfen, ein unbekanntes Protokoll zu analysieren. Mehr sollte der Tipp nicht bedeuten. In Punkto des implementierten Protokolls gebe ich dir Recht. Aber ich habe nicht den Eindruck, dass das tatsächlich protokollecht sein kann. Beispiel: Ich betätige kürzest möglich auf einer NEC FB eine Taste. Dann wird der Code ausgegeben und, soweit ich das habe nachvollziehen können, mindestens ein Repeat-Befehl. Drücke ich nun länger, folgen mehrere Repeats. Wenn ich also eine halbe Sekunde die Taste drücke, ergibt sich ein Code und z.B. 5 Repeats. Wenn ich das mit der LFB aufnehme, dann habe ich ja den Code und 5 Repeats auf der Taste liegen? oder? Wenn ich dann allerdings auf der LFB die Taste dann für 1 Sekunde betätige, was sendet die dann? 1 Code, 5 Repeats, 1 Code und noch 5 Repaets? Oder erkennt die LFB das und baut sich den Code mit den Repeats selbst protokollgetreu zusammen? Das war das was ich meinte mit säubern. Ich weiß ja nicht genau, wieviele Repeats z.B. mit aufgenommen wurden. Diese könnte ich ja bei allen Tasten so kürzen, dass immer nur ein Code und ein Repeat ausgegeben wird. Auch das Editieren der Pausenzeiten wäre klasse, dann könnte man die Steuerung halt recht "smothy" gestalten so das dem Bediener die Bedienung nicht ggf. ruckelig vorkommt. MfG
Bitte 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.