IR erkennen mit AtMega16

  • Thread starter Uwe 'hammernocker' Roßber
  • Start date
U

Uwe 'hammernocker' Roßber

Guest
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. ;-)"
 
Hallo!

Am 18.01.2006, 00:33 Uhr, schrieb Uwe 'hammernocker' Roßberg
<2005@hammernocker.de>:
Wie wird das in Programierbaren Fernbedienungen gelöst?
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:
http://home.arcor.de/avrwakeup/
http://www.jepsennet.de/vdr/
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.
 
Lars Frings schrieb:

Hallo!

Am 18.01.2006, 00:33 Uhr, schrieb Uwe 'hammernocker' Roßberg
2005@hammernocker.de>:

Wie wird das in Programierbaren Fernbedienungen gelöst?


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).
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))

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.
Habe eine Universale, deswegen sehe ich ja das die so vollkommen
unterschiedliche zeiten erzeugen.

Deine Herangehensweise an das Problem ist falsch. Lies dich beim
Protokoll ein. Und dann kannst du dir das vdrwakeup-Projekt anschauen.
Hmm, na da werde ich wohl doch das protokoll auswerten, zumal das in
bascom bereits vorgefertigt ist.

Findest du hier:
http://home.arcor.de/avrwakeup/
http://www.jepsennet.de/vdr/
Das benutzt auch einen Atmel - ist also nah an deiner Lösung. Mindest
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. ;-)"
 
"Uwe 'hammernocker' Roßberg" <2005@hammernocker.de> schrieb im Newsbeitrag
news:dqjv3m$u99$03$1@news.t-online.com...
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?
Warum gibt es wohl nicht so viele selbstlernende Fernbedienungen,
und warum funktionieren die nicht so gut ?

Weil es zu viele verschiedene Sendeprotokolle gibt.

Du musst dich wenigstens auf eine Traegerfrequenz festlegen,
dann bekommst du einen empfindlichen Empfaenger.

Der Rest ist Software.

http://www.web-ee.com/Schematics/Universal%20Remote/upr.htm

und die anderen aus der
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.
 
"Lars Frings" <pseudotetrade007@web.de> wrote:
Hallo!

Am 18.01.2006, 00:33 Uhr, schrieb Uwe 'hammernocker' Roßberg
2005@hammernocker.de>:
Wie wird das in Programierbaren Fernbedienungen gelöst?

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).
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
 
Uwe 'hammernocker' Roßberg schrieb:

Fernbedienungen gespeichert werden, also 40 Felder, zumindest ungefär,
was der speicher dann hergibt.
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.

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.
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).

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?
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 (www.irtrans.de) 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
 
Uwe 'hammernocker' Roßberg schrieb:

RC5, RC5!

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))
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
 
Uwe 'hammernocker' Roßberg wrote:

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.
Schau Dir mal http://mikro.e-technik.uni-ulm.de/research/urcr.html 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
 
Dschen Reinecke schrieb:


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.
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. ;-)"
 
Axel Schwenke schrieb:

Aber Uwes Problem ist ein anderes: er möchte exakt *ein* Protokoll
einer bestimmten Fernbedienung decodieren. Praktisch legt man dazu
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. ;-)"
 
Hallo!

Axel Schwenke schrieb:
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.
Vielleicht ist ja der code zu diesem Projekt hier interessant:
http://www.lirc.org/

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
 
Jürgen Appel schrieb:

Hallo!

Axel Schwenke schrieb:

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.


Vielleicht ist ja der code zu diesem Projekt hier interessant:
http://www.lirc.org/

Die Dokumentation ist zwar nicht allzu ausführlich, aber dafür gibt's den
kompletten Sourcecode und ein paar einfache Schaltungen.
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. ;-)"
 

Welcome to EDABoard.com

Sponsor

Back
Top