ich habe mir mit einem TSOP1738 einen kleinen IR-Empfänger gebaut und spiele damit im Moment ein bischen rum. Eigentlich hätte ich erwartet, das so zimelich alle Fernbedienungen RC-5 einsetzen.
Weit gefehlt.
Zwei Fernbedienungen senden jeweils 34 Bits raus, für Wiederholung der Taste dann alle ~100ms 2 weitere Bits.
Eine Fernbedienung sendet alle ~100ms 22 Bits.
Eine (ältere) Fernbedienung sendet (je nach Taste!) manchmal 9, 10 oder
11 Bits.
Das ist ja schrecklich! Gibts irgendwo eine halbwegs umfassende Liste mit Protokollbeschreibung? Das Format der LIRC-Dateien (zu welchem ich gerne kompatibel wäre) scheint auch nirgendwo beschrieben zu sein.
Jede Hilfe willkommen!
Viele Grüße, Johannes
--
"PS: Ein Realname wäre nett. Ich selbst nutze nur keinen, weil mich die
meisten hier bereits mit Namen kennen." -- Markus Gronotte aka Makus /
Kosst Amojan / maqqusz / Mr. G / Ferdinand Simpson / Quartillia
Rosenberg in dse
Das hat nicht mal Philips geschafft. Hatte eine Universal-FB gekauft, in der Hoffnung, einen DVD Player vom Yard Sale damit zu betreiben. Nach etlichem Probieren mit den Codes tut es nun FW, FFW und STOP. Sonst nix :-(
Am besten mit einem Scope oder Logik-Analysator alle Tasten aufdroeseln, in eine Database und emulieren.
Wozu? Es ist doch eigentlich scheißegal, wie die Tasten codiert sind (außer für den Fall, daß man einem Gerät Codes senden will, die die zugehörige FB nicht senden kann).
Will man bloß das senden oder empfangen, was die FB auch hergibt, ist die Sache relativ einfach, man interessiert sich erstmal überhaupt nicht für die Details der Codierung, sondern sieht die Sache ganz abstrakt. Praktisch alle FBs funktionieren nämlich nach demselben Grundprinzip: entweder sie senden einen Träger aus oder sie tuen es nicht. Die Information steckt in der zeitlichen Abfolge dieser beiden Zustände.
Man ermittelt also den Träger und filtert mit einer Grenze knapp unterhalb der Trägerfrequenz. Was dann noch wackelt, ist die Nutzinformation. Die zeichnet man einfach auf. Man kann sie dann auch noch "rauschfiltern" und "komprimieren", denn die originalen Impulse haben meist nur relativ wenige verschiedene Breiten, die obendrein praktisch immer Vielfache einer gemeinsamen Basis sind (Bitclock).
Und wenn man ganz viel Langeweile hat, kann man noch per Autokorrelation die Codewiederholungen ermitteln und überflüssige Wiederholungen entfernen.
Erst bei diesem Schritt trifft man das erste Mal auf nennenswerte Unterschiede zwischen den verschiedenen FB. Es gibt nämlich Codes, die aus einer Art Hauptcode und einem meist vergleichsweise kurzen Repeatcode bestehen und es gibt Codes, bei denen es diese Trennung nicht gibt und derselbe Code immer komplett wiederholt wird.
Mit dem bisher beschriebenen Ansatz kann man wohl nahezu alle in Consumergeräten übliche Codes analysieren und platzsparend speichern ohne ihre innere Bedeutung oder Struktur kennen zu müssen. Mit einer großen Ausnahme: RC5. Da haben die Säcke sich die Schweinerei eines bei jedem aufeinanderfolgenden Tastendruck derselben Taste alternierenden Codes ausgedacht.
Die Konseqeunz ist, daß man die Analyse zwar beibehalten kann, aber zweimal hintereinander dieselbe Taste drücken muß, um auch den alternierenden Code mitzubekommen.
So funktioniert in groben Zügen meine Lösung und bis jetzt ist mir nur eine einzige FB untergekommen, die sich damit zuerst nicht analysieren ließ, ein gutes Stück aus der DDR-Produktion. Am Oszi hat aber auch sie ihr Geheimnis preisgegeben: Sie sendet immer nur eine einzige Periode der Trägerfrequenz. Gut für ihre Batterie, aber schlecht für Störabstand und damit Reichweite. Und ganz schlecht für meine ursprüngliche Filterroutine für den Träger... Wie auch immer, nach Erkennen des Problems war auch die Lösung einfach. Jetzt kann ich auch diesen "Dialekt" senden und empfangen.
|> Mit dem bisher beschriebenen Ansatz kann man wohl nahezu alle in |> Consumergeräten übliche Codes analysieren und platzsparend speichern |> ohne ihre innere Bedeutung oder Struktur kennen zu müssen. |> Mit einer großen Ausnahme: RC5. Da haben die Säcke sich die Schweinerei |> eines bei jedem aufeinanderfolgenden Tastendruck derselben Taste |> alternierenden Codes ausgedacht.
Dann hast du zB. noch nicht die Fernbedienungen von UEI getroffen (zB. bei der Dreambox eingesetzt). Mal davon abgesehen, dass die zwei 32Bit Pakete abwechselnd senden, kodieren sie auch gleich noch 4Bit über 16 Impulsabstände. Da braucht man eine ziemliche Genauigkeit und einiges an Aufwand, weil die AGC im IR-Empfänger die Pulse verschieden breit werden lässt.
|> So funktioniert in groben Zügen meine Lösung und bis jetzt ist mir nur |> eine einzige FB untergekommen, die sich damit zuerst nicht analysieren |> ließ, ein gutes Stück aus der DDR-Produktion. Am Oszi hat aber auch sie |> ihr Geheimnis preisgegeben: Sie sendet immer nur eine einzige Periode |> der Trägerfrequenz. Gut für ihre Batterie, aber schlecht für Störabstand |> und damit Reichweite. Und ganz schlecht für meine ursprüngliche |> Filterroutine für den Träger...
Ich kenne sowas von einer FB mit einem SAB-irgendwas, Interfunk-Chassis oder sowas. Die Reichweite von der FB war aber erstaunlich.
--
Georg Acher, acher@in.tum.de
http://www.lrr.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
Von deiner Beschreibung ausgehend würde ich sagen: Doch, ist erfaßt. Garantieren kann ich es aber natürlich erst nach einem praktischen Test.
Der Pool der getesteten FBs umfaßt zwar fast 300 verschiedene, aber von der Dreambox ist noch keine dabei. Ich kenne niemanden, der so'n Ding hat.
man
Meine Zeitbasis ist ein 14.7MHz Quarz. Der ist deutlich genauer, als alles, was in FBs normalerweise als Zeitbasis dient (typisch sind da irgendwelche Keramikresonatoren deutlich unterhalb 1MHz).
Was ich nicht genau genug trennen kann, könnte auch der Originalempfänger nicht genau genug trennen, denn auch der muß mit den Ungenauigkeiten des Senders klarkommen.
Mein Empfänger für das Einlesen unbekannter Codes zur Analyse ist natürlich eine simple Photodiode, kein richtiger IR-Empfänger. Sonst würde ich ja schon an den unterschiedlichen Trägerfrequenzen scheitern und könnte die Trägerfrequenz auch nicht messen.
"St. Schulte" schrieb im Newsbeitrag news:fon80q$oj7$ snipped-for-privacy@news01.versatel.de...
Die reale Welt bewirkt aber, das einige der codes bei Lirc falsch sind. User supported software: Schnell hingehackt aus irgendwelchen Quellen, nie mehr korrigiert.
--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.
Ich hab hier noch irgendwo eine FB von einem aelteren Aiwa Videorecorder rumliegen. Die sendet beim druecken einer Taste erstmalig einen bestimmten Tastencode der von der Taste abhaengt, und haelt man sie gedrueckt dann wird bei jeder Taste derselbe Code dauerhaft gesendet. Der gibt dann also an das die zuerst gesendete Taste noch nicht losgelassen wurde. Also zum Beispiel so: [Play] [repeat] [repeat] ... [Stop] [repeat] [repeat] ...
"Falk Willberg" schrieb im Newsbeitrag news: snipped-for-privacy@mid.individual.net...
Ich muss LiRC nicht fehlerfrei machen als Beweis dass es fehlerhaft ist, sondern mir reicht meine Anlage, deren Fernbedienung in LiRC aufgefuehrt ist, die aber nicht funktioniert, weil, nach nachgucken, die Leute nicht beachtet haben, dass zwei unterschiedliche Datenpakete nacheinander kommen und sie nur bei einigen Kommandos das erste, bei anderen das zweite Datenpaket abgebildet haben.
Geschenkt ist noch zu teuer. Der Maintainer hat nicht mal die von mir zugeschickte Korrektur eingearbeitet, das Config-File ist seit 1999 unveraendert.
--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.
"Falk Willberg" schrieb im Newsbeitrag news: snipped-for-privacy@mid.individual.net...
Wieviele davon stimmen ?
Je mehr OpenSource/Linux-Programme/UserSupportedSoftware mir begegnet und sich als krass herausstellt (obwohls das Beste ist was es egebn soll), um so weniger ueberzeugt bin ich von dem Konzept, das ich mal selbst versorgt habe. Denn auch die Gegenrichtung, man macht was oeffentlich damit es jemand aufgreift und mehr draus macht, ist Utopie, maximal wird der Copyright-Text ausgetauscht um das Ding ihm selbst zu widmen, damit sind einige aber auch schon ueberfordert.
Falk, es ist Erfahrung, jahrzehnte Erfahrung.
--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.
Na gut, meine Erfahrung mit Computern beschränkt sich auf die Zeit seit dem PET-2001, also etwa 1980.
Und das Ergebnis ist ganz einfach: Kaufsoftware benutze ich, wenn ich das _muß_, weil es nix für Linux gibt. Sonst reicht mir Open-Source/GPL/GNU.
Ob Windows/Mac-OS/Solaris/AIX besser/stabiler/bunter ist, als Linux, kann ich mangels Erfahrung nicht beurteilen. Mit GNU-Linux komme ich bestens zurecht. Das reicht mir.
Ich habe auch schon "contributed". Der Autor der AVR-LCD-Lib hat es ignoriert. Was solls, _ich_ kann mein 27x4-LCD benutzen.
Der Autor der ersten SCSI-Treiber hat sich dafür entschuldigt, daß MOs mit 1000 Byte Sector-size nicht funktioniert haben.
Mit dem Support für kommerzielle Betriebssysteme habe ich auch Erfahrungen gemacht.
Oh, ah, danke! Habe ich nicht gefunden, finde die lirc-Seite recht unübersichtlich. Kannst du mir zufällig sagen, was die Einheit für die Werte (z.B. " one 642 470") ist? Es scheinen keine us zu sein... wären dann nämlich 1112 us, viel zu lang (899 Hz). 1112 ns sind dagegen viel zu kurz.
Pseudoeinheit?
Werde ich mir mal zu Gemüte führen, vielen Dank!
Viele Grüße, auch an die anderen Poster, Johannes
--
"PS: Ein Realname wäre nett. Ich selbst nutze nur keinen, weil mich die
meisten hier bereits mit Namen kennen." -- Markus Gronotte aka Makus /
Kosst Amojan / maqqusz / Mr. G / Ferdinand Simpson / Quartillia
Rosenberg in dse
Richtig, das machen zwei meiner vier Fernbedienungen. Ich wollte halt so flexibel wie möglich bleiben. Naja.
Ansonsten werde ich es wohl so machen, wie du vorgeschlagen hast - nur wenn der uC möglichst viel "versteht" von dem, was da kommt, kann er die Information auch schön kompakt speichern. Wenn eine Fernbedienungen Codes mit 64 Flanken haben (also, demoduliert natürlich) dann wirds schon knapp mit "ich speicher einfach die Zeiten zwischen jeder Flanke"
- zumindest auf dem Tiny2313, auf dem ich mich gerade bewege.
Viele Grüße, Danke nochmals, Johannes
--
"PS: Ein Realname wäre nett. Ich selbst nutze nur keinen, weil mich die
meisten hier bereits mit Namen kennen." -- Markus Gronotte aka Makus /
Kosst Amojan / maqqusz / Mr. G / Ferdinand Simpson / Quartillia
Rosenberg in dse
Also das Verfahren 128 Byte für einen Sample eines um die Modulationsfrequenz bereinigten Signals zu verwenden, funktioniert (ich meine sogar gut 100 Byte reichen). Jedes Byte darf nicht einfach die Zeiten zwischen den Pegelwechseln speichern, sondern muß diese per Tabelle abbilden. Bei der Wahl der Tabelle habe ich darauf geachtet, daß möglichst die Längen der gängigen Codes darin eine gute Abbildung finden.
Beim Samplen ist es notwendig eine zu langen Abstand zwischen zwei Pegellängen als Abbruchbedingung zu sehen, ich hatte 1Sekunde als maximale Dauer.
Der µC braucht den Code nicht zu verstehen, in der realen Umwelt sind die verschiedenen Codes so unterschiedlich, und teils leichte Abwandlungen gängiger Codes, daß ein Verstehen dieser eine extrem anspruchsvolles, wenn nicht aussichtsloses Unterfangen ist.
Während des Samplens sollte der µC notfalls genug Zeit haben, wenn das RAM nicht ausreicht die Daten schon in ein EEPROM wegzuspeichern.
Ciao Dschen
Die Tabelle, die ich verwendet habe (Einheiten sind mir unbekannt, es kann sein, daß es µS sind, oder irgendeine Zeitbasis des µCs). Diese ist so aufgebaut, daß sie auch mit einer verschachtelten Modulo-Abfrage funktioniert und somit RAM spart (3er-Steigung, 5er-Steigung,
"Falk Willberg" schrieb im Newsbeitrag news: snipped-for-privacy@mid.individual.net...
Na guge mal, dieselbe Erfahrung. ICH frag jetzt nicht, in welchem Stil du es ihm mitgeteilt hast.
Welchen Support ?
--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.
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.