1. Home
  2. Electronics (German)
  3. IR erkennen mit AtMega16

IR erkennen mit AtMega16

Liebe Gemeinde,

ich möchte gerne mit dem µC Signale einer Fernbedienung erkennen und speichern, um sie dann für Schaltaufgaben zu verwenden (die Fernbedienung). Es sollen 10 Symbole (tasten 0-9 bspw.) von 4 Fernbedienungen gespeichert werden, also 40 Felder, zumindest ungefär, was der speicher dann hergibt.

Mein Ansatz ist das ich, nachdem ich ausgeschlossen habe das ich in der Lage bin die ganzen möglichen Protokolle als solche zu implementieren, dachte ich mir ich menutze den Timer und lese einfach die Zeiten zwischen den Flanken. Dabei erhalte ich Datenfolgen von Z.B.

16-17-35-16-16-17-36-36-37-16-85 nun dachte ich mir ich kann das so teilen (durch 20) das ich zumindest im ganzzahligen bereich einstellige zahlen erhalte. Dummerweise sind aber selbst diese Zahlen alles andere als konstant, so als würde das protokoll ständig rotiert werden. selbst (habe zunächst immer 50-ger reihen ausgelesen) wenn ich versuche die Bereiche zwischen besonders langen abständen (die ich dabei als Reset interpretiere) zu betrachten. Beim druck auf die Taste müsste ich doch zumindest immer den gleichen Anfang der übertragung bekommen, abgesehen von fluktuierenden Bits, wegen des Tastendruckzählers, aber ich bekomme derart unterschiedliche reihen, das ich vermute mein ansatz zum simplen capturen der Signale geht gegen den Baum.

Ich benötige Grundsatzhilfe. Kann man das ganze überhaupt einfach als Eimerkette ablegen, um die wirkliche Protokollauswertung zu umgehen? Oder sollte ich mich auf eine Fernbedienung eines Herstellers einigen, und dieses Protokoll verwenden? Wie wird das in Programierbaren Fernbedienungen gelöst?

THX und bye uwe

--
AIM: hammernocker2000 ## ICQ: 115118874 ## www.pssgzudresden.de
Jürgen Gerkens in d.r.f. : "... gerade ein Polfilter ist als
Schutzfilter auch nicht viel schlauer, als die Frontlinse zum Schutz
vor Streulicht zu lackieren. ;-)"
Reply to
Uwe 'hammernocker' Roßberg
Loading thread data ...

Hallo!

Am 18.01.2006, 00:33 Uhr, schrieb Uwe 'hammernocker' Roßberg :

RC5, RC5! Das Protokoll hat quasi eine Art MAC-Adresse für HiFi-Geräte um möglichst viele bedienen zu können. Universalferbedienungen verstehen also RC5 und können diese Adresse einfach ändern (das sind die Codes, die man eingeben muss).

Leider gibt es außer RC5 noch ein paar andere Protkolle, über die man nur spärlich an Informationen kommt. Vielleicht auch viel properitär!? Jedenfalls würde ich dir von den anderen abraten. Kauf dir lieber eine Universalfernbedienung, statt eine mühselig zu unterstützen, die keine RC5 ist.

Deine Herangehensweise an das Problem ist falsch. Lies dich beim Protokoll ein. Und dann kannst du dir das vdrwakeup-Projekt anschauen. Findest du hier:

formatting link
formatting link
Das benutzt auch einen Atmel - ist also nah an deiner Lösung. Mindest ein RC5-Code muss die Schaltung direkt verarbeiten (Power-Taste ;-) ). Guck doch einfach mal in den Quelltext, dann solltest du Anregungen bekommen.

Grüße, Lars

P.S.: Um Fehler im Testlauf zu vermeiden kann es hilfreich sein alle Lichtquellen abzuschalten, gerade Leuchtstofflampen.

Reply to
Lars Frings

Lars Frings schrieb:

Habe darüber gelesen aber nicht gewusst das es so häufig ist das man sich darauf beinahe gut verlassen kann. ich wollte für die eigentlich mokrige aufgabe keine festlegung des protokolls sondern eben ganz flaxibel sein ;o))

Habe eine Universale, deswegen sehe ich ja das die so vollkommen unterschiedliche zeiten erzeugen.

Hmm, na da werde ich wohl doch das protokoll auswerten, zumal das in bascom bereits vorgefertigt ist.

THX und gute nacht, uwe

--
AIM: hammernocker2000 ## ICQ: 115118874 ## www.pssgzudresden.de
Jürgen Gerkens in d.r.f. : "... gerade ein Polfilter ist als
Schutzfilter auch nicht viel schlauer, als die Frontlinse zum Schutz
vor Streulicht zu lackieren. ;-)"
Reply to
Uwe 'hammernocker' Roßberg

Das ist natürlich Blödsinn.

Eine Universalfernbedienung, die lediglich RC5 versteht, würde in Europa vielleicht 50% der Geräte bedienen können; in Asien nur 10%. Außerdem hat RC5 nur 5 Bit Gerätekennung.

Eine wirklich universell programmierbare (also: ein fremdes IR-Signal lernende) Fernbedienung ist verdammt schwer zu bauen. Deswegen gibts auch nur 90-95% Lösungen zu kaufen.

Aber Uwes Problem ist ein anderes: er möchte exakt *ein* Protokoll einer bestimmten Fernbedienung decodieren. Praktisch legt man dazu Grenzen für die Puls/Pausen-Länge fest und verwirft alles, was außerhalb liegt. Vor längerer Zeit wurde hier mal die URL zu einem Fragment C-Code gepostet, das RC5 decodiert. Daraus kann man sich ein paar Tricks abschauen.

XL

Reply to
Axel Schwenke

Uwe 'hammernocker' Roßberg schrieb:

Das habe ich auch schon probiert. Mit einer Tabelle mit den bei verschiedenen Protokollen möglichen Puls(Pause)-Längen brauchte ich etwa

100 Byte (je 7 Bit genutzt) je Befehl.

So ähnlich läuft es bei mir auch, ist aber nicht wirklich zufriedenstellend.

Die großen Abstände als Pause vor einem Befehl zu interpretieren ist je nach Protokoll nicht sinnvoll.

Ich lese einen Referenzbefehl nach einem Tastendruck ein und zwar beginne ich mit dem ersten Flankenwechsel (durch einen TSOP37xx um die Modulationsfrequenz bereinigt) nach dem Tastendruck und lese maximal 100 Flankenwechsel ein, bzw. beende das Samplen nach nach 1 Sekunde ohne Flankenwechsel. Bei allen mir bekannten Fernbedienungscodes habe ich nicht mehr als 100 Flankenwechsel pro Befehl.

Beim Vergleich auf Übereinstimmung wird bei jedem empfangenen Flankenwechsel mit allen Referenzbefehlen verglichen, ob der erste Zeitabstand hinkommt. Wenn ja wird weiterverglichen sonnst abgebrochen.

In meinem halbwegs funktionierenden Prototyp habe ich pro Befehl eine maximale Summe an Abweichungen zugelassen, pro Zeitabstand allerdings ebenfalls begrenzt (denn Tasten wie Lautstärke + und - unterscheiden sich üblicherweise nur durch eine oder zwei unterschiedlich lange Zeitabstände pro Befehl).

Wenn Du nicht zwangsweise auf ein Universalität für *jede* Fernbedienung (na ja mit den Grundsätzen Infrarot und Modulationsfrequenz in der Nahe von 36kHz) angewiesen bist, dekodiere die Protokolle, dann kannst Du auch integrierte Prüfsummen benutzen und musst Referenzbefehle nicht zweifach abspreichen, da diese ein bei jedem Tastendruck wechselndes Toggle-Bit haben (um zu unterscheiden, ob eine Taste länger oder erneut gedrückt wird).

Das Produkt irtrans

formatting link
könnte für Dich ganz interessant sein, vielleicht macht es ja schon einen Teil Deiner Wunschliste. Hier wird eine Mischform benutzt: Einige Protokolle werden dokodiert, bei anderen wird ein Vergleich mit einem gesampleten Referenzbefehl durchgeführt. Das schien mir jedenfalls so, als ich mir das Teil genauer angesehen habe.

Ciao Dschen

--
Dschen Reinecke

=== der mit dem Namen aus China ===

http://WWW.DSCHEN.DE mailto:usenet@dschen.de
Reply to
Dschen Reinecke

Uwe 'hammernocker' Roßberg schrieb:

Beim Feldtest mit verschiedenen Fernbedienung in meinem Haushalt habe ich folgendes rausgefunden. Das Zeigt, daß schon verschiedenen Codes Verwendung finden. In einem alten Elektor (3/2001, S.38ff und 4/2001 S.38ff) gab es einen Überblick über die gängigen Codes. An die Bezeichnungen habe ich mich bei meinem Test gehalten:

=== TV (Orion), RC5 TV-Karte Haupauge, RC5 Verstärker Kenwood, NEC CD Technics, Japan Sat Grundig, Motorola Sat Skymaster, Daewoo TV Condor, Daewoo Video GT - General Technic, NEC ganzer Befehl wird wiederholt Sat Galaxis, NEC DVD Cyberhome, NEC Telefunken (Video-TV), unklar, 100uS Puls, 100uS Pause oder 8000uS Pause Grundig (System), RC5 ===

Ist Deine Email-Adresse korrekt? Ich könnte Dir die Tabelle mit den für alle Fernbedinungen passenden Pulsabständen zumailen (hat 208 Einträge), die ich in meinem anderen Posting erwähnt hatte.

Ciao Dschen

--
Dschen Reinecke

=== der mit dem Namen aus China ===

http://WWW.DSCHEN.DE mailto:usenet@dschen.de
Reply to
Dschen Reinecke

Schau Dir mal

formatting link
an. Ich denke das ist in etwa der Empfänger, den ich vor einigen Jahren mal als "UIR - Universal Infrared Receiver" gebaut habe, die Originalseite gibt´s leider nicht mehr.

Der Empfänger gibt für jede Taste eine bestimmte, immer gleiche Bytefolge per serieller Schnittstelle aus. Der Source ist zwar für PIC, aber gut dokumentiert. Und im Zweifel kannst Du ja einfach einen PIC an den Atmel hängen ;-)

Grüße, Sebastian

Reply to
Sebastian Voitzsch

Dschen Reinecke schrieb:

Das wäre klasse, hatte einige Seiten gefunden, aber alles andere als ausführlich. Adresse stimmt, geht auch, ich muss sie nur mal in 2006 umbenennen ;o))

THX und ybe uwe

--
AIM: hammernocker2000 ## ICQ: 115118874 ## www.pssgzudresden.de
Jürgen Gerkens in d.r.f. : "... gerade ein Polfilter ist als
Schutzfilter auch nicht viel schlauer, als die Frontlinse zum Schutz
vor Streulicht zu lackieren. ;-)"
Reply to
Uwe 'hammernocker' Roßberg

Axel Schwenke schrieb:

nicht ganz, ich will eigentlich garnicht decodieren, sondern ein beliebiges Signal speichersparend und wiedererkennbar als 'stream' ablegen.

bye uwe

--
AIM: hammernocker2000 ## ICQ: 115118874 ## www.pssgzudresden.de
Jürgen Gerkens in d.r.f. : "... gerade ein Polfilter ist als
Schutzfilter auch nicht viel schlauer, als die Frontlinse zum Schutz
vor Streulicht zu lackieren. ;-)"
Reply to
Uwe 'hammernocker' Roßberg

Hallo!

Axel Schwenke schrieb:

Vielleicht ist ja der code zu diesem Projekt hier interessant:

formatting link

Die Dokumentation ist zwar nicht allzu ausführlich, aber dafür gibt's den kompletten Sourcecode und ein paar einfache Schaltungen.

Gruß Jürgen

--
GPG key: 
http://pgp.mit.edu:11371/pks/lookup?search=J%FCrgen+Appel&op=get
Reply to
Jürgen Appel

Jürgen Appel schrieb:

Ich danke dir, aber ich werde mich der einfachheit halber doch auf rc5 beschränken ;o))

thx und bye uwe

--
AIM: hammernocker2000 ## ICQ: 115118874 ## www.pssgzudresden.de
Jürgen Gerkens in d.r.f. : "... gerade ein Polfilter ist als
Schutzfilter auch nicht viel schlauer, als die Frontlinse zum Schutz
vor Streulicht zu lackieren. ;-)"
Reply to
Uwe 'hammernocker' Roßberg

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.