Hallo, mir schwebt folgendes vor: damit ich zukünftig keine Tasten mehr verbauen muss, soll ein IR-Empfänger diese Funktion bei den AVR-Projekten übernehmen. Folgende Idee: ich nehme eine beliebige IR-Fernbedienung, drücke lange die Power ON-Taste und damit weiß mein Atmega, dass eine neue FB angelernt werden soll. Dann drücke ich hintereinander die Tasten 1,2,3 bis 0 und der Atmega quittiert jede gelernte Taste mit 1-n kurzen Beeptönen. Dann ist die Programmierung abgeschlossen, sollte zukünftig eine andere FB verwendet werden, wiederholt man das.. bei Bedarf können natürlich neben 1,2,3 -0 auch andere Tasten angelernt werden. Das Ganze soll aber nicht wie beim Projekt IRMP mit Herstellervorgaben gehen, sondern wirklich unabhängig von der Marke und dem Protokoll. Bei den ersten Versuchen habe ich jetzt einen Timer mit 20 kHz laufen lassen und ein Sample von 255 Bits mit Häufigkeitsanalyse eingelesen. Das sieht recht vielversprechend aus. Hab jetzt Sony, Samsung probiert, alle Sequenzen konnte ich einlesen. Ich verwende einen 36kHz IR-Empfänger und dazu meine Frage: wie universell ist der IR-Empfänger - was passiert wenn eine IR-FB mit 40 khZ sendet, kommt da auch noch ein Signal?
Naja, IRMP war nicht das, was ich wirklich gesucht habe. Meine Idee ist: - ich brauche eine Zehnertastatur, * und # sowie 4 Zusatztaste und möchte das mit einer (beliebigen) IR-FB steuern. - Der Atmega soll das einmal lernen, in seinem EEPROM speichern und wenn ich die FB nicht mehr finde oder sie defekt ist, soll eine neue angelernt werden. Beim Neustart des Programms (z.B. Reset-Taster oder Strom ein) besteht für einige Sekunden die Möglichkeit, eine andere FB anzulernen (also ebenfalls keine Taste erforderlich). Das Programm analysiert den Datenstrom der FB und lernt quasi von selbst (im Gegensatz zu IRMP). Herausgekommen ist folgender Bascom-Code, auf ein myAVR mk2 System optimiert mit Atmega 8, vielleicht mag jemand das Testen, bis auf 1 von 7 FBs hats überall funktioniert (z.B. Sony, Samsung..) Über Kommentare und Verbesserungsvorschläge freue ich mich.
> kommt da auch noch ein Signal?
Na ja, man darf erst mal natürlich beliebig naiv an die Sache rangehen.
Es gibt Fernbedienungen mit 28.5 - 48kHz, 78kHz und 4MHz Träger,
zumindest sind mir solche schon untergekommen.
Während ein 36kHz Empfänger noch die beiden danbeneiliegenden leidlich
empfängt (dichter dran halten) ist bei weiter danebenliegenden Essig.
Schlimmer ist die reduzierte Reichweite aber bei Sendern, wenn man
danebenliegt was der Empfänger erwartet hat man keine Freude beim
"Fern"bedienen.
Dann gibt es Fernbedienungen die ein Impulspaket senden und es bei
Tasten-Repeat wiederholen. Es gibt Sender, die zwei oder drei
verschiedenen Impulspakete pro Taste senden, weil sie unterschiedliche
Geräte bedienen können "Systemfernbedienungen".
Und es gibt Empfänger, die 2 verschiedene Impulspakete empfangen wollen,
bevor sie reagieren, weil sie eben solche Systemfernbedienungen
voraussetzen.
Wer meint, das wäre alles ganz einfach, und es gibt ja schon so tolle
open source Projekte, man soll doch einfach LiRC nehmen, den muß ich
enttäuschen: Wie bei den meisten open soure Projekten funktioniert das
genau bei einem, nämlich dem Programmierer, und bei der ersten
Fernbedienung die du ausprobierst obwohl sie in der Liste der
unterstützen Geräte steht, funktioniert es natürlich nicht.
Auch die waren gnadenlos naiv.
Wie man leicht daran erkennt, daß kommerzielle Universalfernbedienungen
eben NICHT nach diesem Selbstlernprinzip gehen.
MaWin schrieb: >> kommt da auch noch ein Signal? > > Na ja, man darf erst mal natürlich beliebig naiv an die Sache rangehen. > > Es gibt Fernbedienungen mit 28.5 - 48kHz, 78kHz und 4MHz Träger, > zumindest sind mir solche schon untergekommen. > > Während ein 36kHz Empfänger noch die beiden danbeneiliegenden leidlich > empfängt (dichter dran halten) ist bei weiter danebenliegenden Essig. Danke für die Info - dann dürfte ich also mit 36kHz recht gut liegen > Dann gibt es Fernbedienungen die ein Impulspaket senden und es bei > Tasten-Repeat wiederholen. Es gibt Sender, die zwei oder drei > verschiedenen Impulspakete pro Taste senden, weil sie unterschiedliche > Geräte bedienen können "Systemfernbedienungen". Kein Problem, ich nehme immer nur das erste Pulspaket und checke es gegen das 2. Paket, bis jetzt war das 2. Paket - soferne es überhaupt gesendet wurde - immer ident. > Wie man leicht daran erkennt, daß kommerzielle Universalfernbedienungen > eben NICHT nach diesem Selbstlernprinzip gehen. Bis auf 1 von 10 getesten FBs, sind alle problemlos gegangen. Also fast jede beliebige IR-Fernbedienung kann verwendet werden! Mein Ergebnis: Sony RM-ED011W geht problemlos (TV) Sony RM-ADP060 geht problemlos (bei allen Einstellungen BD, TV, STB) Samsung AA59-00446A (z.B. TV 32D6500) problemlos JVC RM-SDRD017E DVD Recorder problemlos 3 Universal-FBs von Pollin gehen problemlos: Remote Control 160 more-TV FB1 more-TV FB2 Remote Control RC130 Dual Remote Control RC520 gehen alle lediglich Galaxy Digital TV-Receiver geht nicht Leider war im vorigen Code noch ein kleiner Fehler, sodass das wiederholte Starten der Programmierung nicht geklappt hatte es sollte heißen: LED=IRSensor statt Portc.6, hier der geänderte Code
MaWin schrieb: > Es gibt Fernbedienungen mit 28.5 - 48kHz, 78kHz und 4MHz Träger, > zumindest sind mir solche schon untergekommen. Dem könnte man mit etwas zusätzlicher Hardware beikommen...
MWS schrieb: > Dem könnte man mit etwas zusätzlicher Hardware beikommen... Dieser MWS war nicht meinereiner, aber es mag ja vielleicht noch mehr davon geben... Würde MaWin zustimmen, was er schreibt hat Hand und Fuß. Und mit "etwas" HW kommt man dem auch nicht bei, evtl. durch verschiedene Empfänger, nur welcher soll dann ansprechen ? Das erscheint doch recht sinnlos und so'nen Quark würd' ich auch nicht schreiben. MaWin schrieb: > Während ein 36kHz Empfänger noch die beiden danbeneiliegenden leidlich > empfängt (dichter dran halten) ist bei weiter danebenliegenden Essig. Was auch daraus resultiert, dass nicht auf die richtige Frequenz abgestimmte TSOP's o.ä. die Puls-/Pausezeiten ungenau wiedergeben. Das hier aus dem Code des TO's stimmt nicht so recht: > '20khz bei 8Mhz, geht auch mit 3,6 Mhz Quartz Da hat der TE wohl übersehen, dass die Registersicherung auch ein paar Takte braucht und der Timer an dieser Stelle schon weiter als 0 ist. Die daraus ergebende Aufrufrate der ISR beträgt also um die 17,5kHz.
MWS schrieb: > MWS schrieb: >> Dem könnte man mit etwas zusätzlicher Hardware beikommen... > > Dieser MWS war nicht meinereiner, aber es mag ja vielleicht noch mehr > davon geben... > > Würde MaWin zustimmen, was er schreibt hat Hand und Fuß. > > Und mit "etwas" HW kommt man dem auch nicht bei, evtl. durch > verschiedene Empfänger, nur welcher soll dann ansprechen ? Das erscheint > doch recht sinnlos und so'nen Quark würd' ich auch nicht schreiben. > > MaWin schrieb: >> Während ein 36kHz Empfänger noch die beiden danbeneiliegenden leidlich >> empfängt (dichter dran halten) ist bei weiter danebenliegenden Essig. > > Was auch daraus resultiert, dass nicht auf die richtige Frequenz > abgestimmte TSOP's o.ä. die Puls-/Pausezeiten ungenau wiedergeben. Das macht auch nichts, wird durch den Algorithmus korrigiert, idR ist das Timing zwischen 0 und 1 auch meist doppelt so lang > > Das hier aus dem Code des TO's stimmt nicht so recht: >> '20khz bei 8Mhz, geht auch mit 3,6 Mhz Quartz > > Da hat der TE wohl übersehen, dass die Registersicherung auch ein paar > Takte braucht und der Timer an dieser Stelle schon weiter als 0 ist. Die > daraus ergebende Aufrufrate der ISR beträgt also um die 17,5kHz. Auch das ist egal, das Programm läuft ohne Änderung auch mit 3,6 Mhz Quarz, was dann einer Frequenz von 8 kHz entspricht, dann wird bei den handelsüblichen IR-Fernbedienungen halt bei 0 idR nur bis 5 und bei 1 bis 10 gezählt, auch egal
Manfred S. schrieb: > Auch das ist egal, > bis 10 gezählt, auch egal Das freut mich doch, dass Du Dir gegenüber so tolerant bist. Und so aufgeschlossen, wenn man Dir 'nen Fehler sagt. LOL > Das macht auch nichts, wird durch den Algorithmus korrigiert, idR ist > das Timing zwischen 0 und 1 auch meist doppelt so lang Ich denk' Du hast das nicht selbst ausprobiert. Bei einem Signal, das von der Frequenz daneben liegt, werden vom TSOP die Puls-/Pausenverhältnisse von der Signalstärke abhängig, d.h. Entfernung, unterschiedlich ausgegeben. Das kann nicht korrigiert werden. Aber solange es reicht Dein Gebastel zu bedienen wenn Du davor sitzt, soll's ja recht sein, dann hatt's ja den Eingangs erklärten Zweck erfüllt.
MWS schrieb: > wenn Du davor sitzt, > soll's ja recht sein, dann hatt's ja den Eingangs erklärten Zweck > erfüllt. Wieso davor? Ich kann auch 10m dahinter sitzen und es geht immer noch ;-)
Manfred S. schrieb: > Wieso davor? Ich kann auch 10m dahinter sitzen und es geht immer noch Ja, nee. Is klar. Mit 'ner FB die Deinem Empfangslogik entspricht und den richtigen Träger hat kann das gehen. Die Rede hier war jedoch von nicht genau passender Trägerfrequenz, denn Du wolltest ja was "Universelles" basteln. Und das wird dann halt nichts, das hat Dir ja auch MaWin schon gesagt. Also träum' weiter.
Bzgl. der IR Protokolle kann ich zum Start diese Seite empfehlen: http://www.sbprojects.com/knowledge/ir/index.php So kann man z.B. beim NRC17 und RC-5 Protokoll nicht davon ausgehen das 0/1 durch die Pulspausen definiert werden. Bei dem SIRC Protokoll ist das dann nur annähernd so. RC6 hat Puls-Längen sowie -Pausen jeweils "normal" oder "doppelt" solange. RC-MM ist wieder komplett anders. RECS ist Trickreich weil es nur einen sehr kurzen Puls hat, gefolgt von einer langen (0) oder längeren (1) Pause. Auch die Protokolle haben starke Variationen um die entsprechenden Daten zu Übermitteln. Viele wiederholen das gleiche Datenpaket. Andere haben "Toggle-Bits" die bei jedem Paket umschalten. Einige wiederholen garnicht bei den meisten Tasten. Manche Protokolle haben nur einen langen Start"block", andere nur Pulse mit definierter Pausezeit danach. Wieder andere haben das für Start und Ende. RC-5 hat dann normale Startbits, die genauso wie die normalen Datenbits sind. FB's erkennen ist recht trickreich, es ist sehr schwierig ein "Catch-All" zu bauen ohne die Protokolleigenheiten zu kennen. Man sollte zumindest eine rudimentäre Erkennung haben bzgl. der verschiedenen Start/Stop-Konditionen um dann ggf. verschiedene Auswertungs-Routinen nutzen zu können. Ist zwar mehr Aufwand, aber dafür auch ein wenig genauer. Aber auch so wird man nicht alles Fehlerfrei erkennen können. Achja, und dann gibt es noch viele exotische Protokolle die jeder so aufbaut wie er es für Richtig hält. Das Problem ist ja das es immer mehr Geräte mit IR Fernbedienungen gibt, von vielen Herstellern. Irgendwie wollen die halt soweit wie es geht "Eigenständig" sein, damit nicht die FB vom Fernseher dann den Sat-Receiver stört, etc. So kommt es zu einem ständig wachsenden Wust an Protokollen, leider. Grüße, Chris
Danke für eure Rückmeldungen Christian Klippel schrieb: > Bzgl. der IR Protokolle kann ich zum Start diese Seite empfehlen: > > http://www.sbprojects.com/knowledge/ir/index.php > > So kann man z.B. beim NRC17 und RC-5 Protokoll nicht davon ausgehen das > 0/1 durch die Pulspausen definiert werden. Bei dem SIRC Protokoll ist > das dann nur annähernd so. RC6 hat Puls-Längen sowie -Pausen jeweils > "normal" oder "doppelt" solange. RC-MM ist wieder komplett anders. RECS > ist Trickreich weil es nur einen sehr kurzen Puls hat, gefolgt von einer > langen (0) oder längeren (1) Pause. Ja, das ist richtig, gibt auch Manchester-Codierung usw., ist aber für meine Zwecke egal - denn ich möchte ja nicht die richtige Folge von 0 und 1 detektieren, sondern nur eine möglichst eindeutig wiedererkennbare Folge. Zweck des Projektes ist es bis dato nur, die Hardwareschaltung für Zehnertastur, * und # sowie 4 Sondertasten einzusparen. Daher mein Ansatz: nimm eine beliebige herumliegende IR-FB, schau, ob sie der Atmega lernen kann - wenn er die 16 Tasten eindeutig zuordnen kann, ist es ok, ansonst nimm einfach eine andere IR-FB. Wenn die passende IR-FB kaputt ist oder - wie eigentlich öfter der Fall - nicht mehr auffindbar ist - wird wieder eine neue angelernt. Ich war dann selbst überrascht, dass 9 von 10 herumliegenden FBs auf Anhieb gepasst haben. Hab dann an Stelle des TSOP einen Fototransistor genommen und es wurden dann immer noch 0/1-Folgen erkannt, aber die waren nicht mehr exakt zuordenbar. > > Auch die Protokolle haben starke Variationen um die entsprechenden Daten > zu Übermitteln. Viele wiederholen das gleiche Datenpaket. Andere haben > "Toggle-Bits" die bei jedem Paket umschalten. Einige wiederholen > garnicht bei den meisten Tasten. Manche Protokolle haben nur einen > langen Start"block", andere nur Pulse mit definierter Pausezeit danach. > Wieder andere haben das für Start und Ende. RC-5 hat dann normale > Startbits, die genauso wie die normalen Datenbits sind. > Ich lese das erste Paket, sollte die FB ein Zweites senden, wird beim Programmieren dieses mit dem Ersten verglichen - wenn nicht ok, wird der Code verworfen, wenn ok ist die Sequenz gespeichert. Toggle-Bits könnte ich also definitiv nicht erkennen. Bleibt bei manchen FBs die Taste gedrückt, wird der eingegebene Code so ca. im 0,5 sek. Takt wiederholt, die Tasten sind übrigens automatisch entprellt. > FB's erkennen ist recht trickreich, es ist sehr schwierig ein > "Catch-All" zu bauen ohne die Protokolleigenheiten zu kennen. Man sollte > zumindest eine rudimentäre Erkennung haben bzgl. der verschiedenen > Start/Stop-Konditionen um dann ggf. verschiedene Auswertungs-Routinen > nutzen zu können. Ist zwar mehr Aufwand, aber dafür auch ein wenig > genauer. Aber auch so wird man nicht alles Fehlerfrei erkennen können. Das wären interessante Erweiterungen und sind vor allem dann notwendig, wenn die FB auch Codes senden soll. Da ist dann doch IRMP besser. Für meinen Tastaturersatz aber nicht nowendig. Der Algorithmus ist eigentlich ganz einfach: Analysiere die Zustandsänderungen (Wechsel des Levels) 1) analysiere mit ca. 18 kHZ 2) Zähle mit, wie lange ein Level bei seinem Zustand bleibt, speichere Wert in Array X Abbruchbedingung: speichere max. 255 Zustandsänderungen, sollte sich nach 1000 Zeiteinheiten nichts ändern, brich ab und beginn den Code ebenfalls zu analysieren - während dessen empfange keine neuen Daten. Analysiere Code: Analysiere die Häufigkeiten, bilde Klassen: 1) Klasse 0: niedrigste Zählergebnisse - intern als 0 2) Klasse 1: höhere Zähleregebnisse - intern als 1 3) Klasse 2: noch höhere Zählergebnisse usw. 4) Klasse x: längste Zählergebnisse.. Meine vereinfachende Annahme: die kürzesten und "zweitkürzesten" sind die relevanten Codedaten, in denen sich die Befehle unterscheiden. Danach suche - mit Ausnahme der Startsequenz - nach dem ersten Vorkommen einer Klasse >=2 = nimm an: Codeende einer Sequenz=Codelaenge Speichere max. 120 Bits der Codesequenz (meine FBs hatten Codelängen von 26 bis 68 Bits) im EEPROM, sieh nach, ob die FB schon beim ersten Tastendruck eine 2. Sequenz gesendet hat - wenn die ident ist mit der ersten Sequenz, gilt der Code als gesichert, ansonst warte auf einen 2. Tastendruck, um den Code zu bestätigen. Speichere Codelänge und gesicherten Code (Bit 7) ebenfalls im EEPROM. Der Programmcode selbst ist sicher noch nicht optimal, aber immerhin schon funktionsfähig. Was aber noch interessant wäre - gibt es wo eine Übersicht, welcher Hersteller (Samsung, Sony, JVC) auf 36k Hz, 40 kHz usw. senden? Was ist heute üblich?
Manfred S. schrieb: > Ja, das ist richtig, gibt auch Manchester-Codierung usw., ist aber für > meine Zwecke egal - denn ich möchte ja nicht die richtige Folge von 0 > und 1 detektieren, sondern nur eine möglichst eindeutig wiedererkennbare > Folge. Wie willst Du mit dieser Vorgehensweise die Toggle-Bit-Problematik bei RC5, RC6 und RECS80 in den Griff bekommen? Drücke ich da ein- und dieselbe Taste ein zweites Mal, sieht Dein empfangenes Bitmuster plötzlich anders aus und wird dann nicht erkannt. Ich muss also im Zweifelsfall eine Taste 2x drücken, damit sie dann erkannt wird. Dann gibt es noch die Repetition-Frames beim NEC-Protokoll. Drücke ich da eine Taste länger, werden nach dem eigentlichen Kommando-Frame nur noch Repetition-Frames gesendet, die Du bei Deiner Vorgehensweise nicht "verstehen" kannst. Um also mit einer NEC-kompatiblen FB (ca. 70% aller im Haushalt befindlichen Tastaturen benutzen NEC-Protokolle und Verwandte) eine Lautstärke oder Helligkeit zu bedienen, muss man bei Deiner Methode die Lautstärke-Taste dauernd neu betätigen statt sie einfach lang herunterzudrücken. Das ist nicht gerade komfortabel ;-) Gruß, Frank
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.