Liebe Auskenner, ich bastel gerade mit Fernbedienungen herum, RC5 senden und empfangen geht ganz gut. Allerdings habe ich gelesen, daß viele Fernbedienungen gar kein RC5 senden (meine senden es alle..) - ist das so? Ich möchte im Weiteren so eine Art universelle Fernbedienung bauen (lernfähig). Bei den IR-Empfänger-Bausteinen fällt schonmal auf, daß die mit verschiedenen Frequenzen arbeiten. Verschiedene Protokolle gibt es auch. Man brauchte also zum "Lernen und wieder ausgeben" entweder verschiedene Empfänger (für jede Frequenz einen) und verschiedene Protokollimplementationen ODER man liest "Rohdaten" ein und sendet die mitgeschnittenen Rohdaten wieder 'raus. Die erste Variante ist nicht so toll, weil man alle Protokolle implementieren muß und testen, welcher Empfänger klappt. Die zweite Variante ist nicht so toll, weil man das Toggle-Bit nicht mitbekommt und somit nicht unterscheiden kann, ob bei langem Signal die Taste denn nun lange gehalten wurde oder mehrfach gedrückt wurde. Gibt es ein "Ei des Columbus" auf diesem Gebiet, sprich eine elegante Lösung oder Lösungsansätze, um die Sache möglichst universell zu gestalten?
Mein 15 Jahre alter Grundig Fernseher spricht kein RC5 und meine neueren Geräte (alle aus Fernost) tun es auch nicht. Wie Du schon richtig erkannt hast, kann es keine Universalfernbedienung geben. Wenn Du Dir die typischen Protokolle anschaust, dann wirst Du aber feststellen, dass es viele ähnliche Protokolle gibt, die sich nur etwas im Timing unterscheiden. Ich würde halt diese Protokolle unterstützen. Markus
>kann es keine Universalfernbedienung >geben. Wie zum Teufel macht die OneForAll Chamäleon das?
guck mal nach: lirc win-lirc da kannste von x herstellern sehen, was die so senden. oder mit lirc selbst messen...
> Wie zum Teufel macht die OneForAll Chamäleon das?
Die samplet im Lernmodus das IR Signal auf einem Vielfachen der
IR-Trägerfrequenz, speichert diese Werte im Flashspeicher und spielt sie
auf Abruf wieder ab.
Dann würde diese "OneForAll Chamäleon" meiner oben genannten Variante 2 entsprechen und sollte auch dei daraus resultierenden Probleme haben (Unterscheidung: Taste lang oder kurz gedrückt) Beispiel: am CD-Player dient die vorwärts-Taste oft dazu, bei kurzer Betätigung auf den nächsten Titel, bei langer Betätigung innerhalb des titels weiterzugehen - funktioniert das mit dem Teil? Wäre mal interessant.. Wobei man dafür noch kein Toggle-Bit bräuchte, aber z.B. wenn man eine an/aus-Funktion (umschalter) auf einer Taste hat. Außerdem: woher weiß das Chamäleon, wie lang das Datenpaket ist?
Ahhh okay, macht Sinn. Dann könnte man das Prinzip ja eigentlich nachbauen. @alfsch: Nettes Programm, danke für den Hinweis.
> Die samplet im Lernmodus das IR Signal auf einem Vielfachen
Für RC5 braucht es imho mehr als nur samplen des Signals. Bei RC5
toggled das 3. bit bei jedem Tastendruck. Somit erkennt der Empfänger ob
die Taste länger gehalten oder mehrfach gedrückt wurde.
Und das geht durch simples aufzeichnen nicht...
Stimmt auch wieder, die kann sicher noch mehr, als nur samplen, was dann auch den Preis rechtfertigt ;-) Aber gut aussehen tut sie trotzdem (Zahn tropf...)!
Lieber Nicht-Auskenner, wenn du nicht in der Lage bist, auf deiner Fernbedienung eine Taste einmal kurz und einmal etwas länger zu halten, wirst du keine "universelle Fernbedienung" trainieren können. Ich kann dir zu jedem Algorithmus, der nicht das hochfrequente IR-Signal samplet und wieder abspielt, ein Protokoll nennen, das dein vermeintlich intelligenter Algorithmus nicht korrekt wiedergibt. Die Unterschiede mit getoggeltem Wiederholungsbit, Shift-Taste etc. filtert Chamäleon mittels grundlegendem DSP aus dem Signal. Wenn du weitergehende Tricks in dein IR-Protokoll einbaust, wird Chamäleon damit nicht klarkommen.
über die trägerfrequenzen wurde hier noch garnicht diskutiert... zu allem überfluss sprechen die bedienungen ja auch noch auf unterschiedlichen trägern.... on/off modulation auf 36Khz bis 48khz.... lirc lässt grüßen, wenn das auch noch mit integriert wäre, dann könnte man dies als auswertetool gelten lassen.... dennis
> zu allem überfluss sprechen die bedienungen ja auch noch auf > unterschiedlichen trägern.... > > on/off modulation auf 36Khz bis 48khz.... .. und Chamäleon kann auch noch Funk bei 455kHz oder so. Allerdings wird dabei nicht mehr der Träger abgetastet, sondern HF gemessen und als ein einziger Zahlenwert (z.B. 455000) gespeichert, NF gesamplet und später wieder auf den neu generierten HF-Träger aufmoduliert. Viel Spass!
Ich weis nicht ob das bei den Lernfähigen so gemacht wird, aber man könnte ja beim Einlesen zweimal auf die Taste drücken müssen. Der Empfänger erkennt dann ja ob das Datenpaket identisch ist. Wenn nicht musst du hallt zwei Datenpakete speichern und bei jedem Tastendruck abwechselnt das eine oder andere Protokoll senden. Die Länge des Protokolls ist eigentlich relativ egal. Entweder der Prozessor erkennt eine Regelmässigkeit im Paket, oder oft werden auch längere Pausen als zwischen normalen Bits als Trennzeichen verwendet. Du kannst aber eigentlich auch eine gewisse Anzahl an Samples aufnehmen und die dann wieder senden. Wenn es dann 1,5 Protokolle sind ist es auch egal, sobalt ein Protokoll richtig übermittelt wird reicht das.
@Matthias: Das mit dem Toggle-Bit kann man schon so erkennen, aber es hilft halt genau gegen dieses Problem. Wenn die nächste FB z.B. einen Zähler im Protokoll hätte, dann hast Du wieder verloren. Deswegen sage ich ja: Man kann keine universellen Fernbedienungen bauen. In der Praxis mag Samplen und RC5-Erkennung gut genug sein, aber das ist dann halt trotzdem nicht universell. Markus
Gibt es Protokolle die einen Zähler als Toggle haben? Habe ich noch nicht gehört und macht eigentlich ja auch keinen Sinn.Der Empfänger soll ja nur erkennen od ich immernoch drücke oder schon wieder. P.S. Die Trägerfrequenz braucht man eigentlich nur einmal erkennen und abspeichern. Danach braucht man nur noch die Zeiten für High und Low Speichern. Da sollte man eigentlich mit 50Bytes Pro Taste und Gerät hinkommen. Also müsste ein Eeprom mit 64K für 10Geräte und 100Tasten reichen. Sicher, die Fernbedienung ist dann nicht universell, aber eigentlich müsste jede einlesbar sein.
> Sicher, die Fernbedienung ist dann nicht universell, aber eigentlich
müsste jede einlesbar sein.
Sicher. Und eigentlich sind alle Fernbedienungen RC5-Fernbedienungen.
RC5 ist sogar ziemlich selten. Zumindest in meinem Haushalt. Ich habe nur eine gefunden die RC5 sendet(Phillips). Aber warum sollte damit nicht jede Fernbedienung einlesbar sein? Wenn man die Trägerfrequenz kennt und die Zeiten für die Highs und Lows. Mehr Informationen hat das Sendesignal doch nicht.
>Und eigentlich sind alle Fernbedienungen RC5-Fernbedienungen.
Nein ! Sehr viele Fernbedienungen senden RECS80 Code.
Sony, Denon, JVC, Panasonic haben je ein eigenes Format. Üblich sind auch noch das RECS80 und viele jap. DVD Player und Sat Receiver benutzen NEC oder NECncr17. Da sie meisten Geräte inzwischen aus Japan kommen, ist RC5 nicht mehr so gebräuchlich (früher Grundig, Philips). Ich hatte mal angefangen, ein Programm zu schreiben, das die genannten Protokolle erkannt hat (ausser RC5). Man kann sie gut auseinanderhalten anhand der Bitzahl/Befehl und Zeitdauer Startimpuls und Bits/Pausen. Bsp: Denon: .db $0F, $07, $13, $07,$13, $07,$2F, 4,$06, 8,$4C, 2,$00, 1, 0,0 Sony15: .db $0C, $3C, $0F, $0F,$0F, $1E,$0F, 7,$1A, 5,$07,0 ; Länge Start Pause 0- Bit 1- Bit Bitzahl,Command,Bitzahl,Adr NEC: .db $21, $E0, $71, $0D,$0D, $0D,$2A, 8,$00,8,~$00, 8,$19,8,~$19, 1,0 ,0 Plasma: .db $0b, $06, $B6, $04,$79, $03,$B7, $FF ,3,$07, 6,$32, 1,0 Panasonic: .db $31, $56, $2C, $0A,$0A, $0A,$21, 8,$02, 8,$20, 8,$A0, 8,$00, 8,$21, 8,$81, 1,0 ,0 JVC: .db $11, $D2, $69, $0D,$0D, $0D,$27, 8,$9F, 8,$7b ,0 Ausser Länge alle Werte in 40uS Hat gut funktioniert. Ich werde es irgendwann mal weitermachen. Das Sendeprogramm brauchte nur die jeweilige Datenzeile für das jeweilige Protokoll. gruss christian
Ich hab' ein Programm für meinen PDA, das zeichnet wie ein Recorder den Code jedes IR-Senders (auch Auto-Fernbedienungen) auf und kann abgespeichert werden. Nur den Rolling-Code kann's nicht.
So, jetzt hatte ich wieder ein bischen Zeit zum Probieren. Ich verwende einen TSOP1736 als Empfänger und ich habe jetzt auch 2 "nicht-RC5-Fernbedienungen" gefunden. Die Signale kann ich messen, Impulslänge bestimmen geht auch so langsam. Was ich nicht probieren kann: Wie ist das mit den unterschiedlichen Trägerfrequenzen? Ich habe gesehen, daß der TSOP1736 auf 36kHz "horcht", wie der Name schon sagt. Wie oben angegeben, will ich erreichen, daß möglichst viele Fernbedingungen erkannt werden ("alle" ist wohl etwas hochgesteckt, und erfahrungsgemäß erreicht man mit 20% Aufwand 80% des Ergebnisses, hat mal ein schlauer Mensch (Pareto?) 'rausgefunden..? naja..) Also wenn ich jetzt einen Sender mit 38kHz hätte - würde der 1736 1) gar nichts empfangen, weil die Trägerfrequenz nicht paßt 2) Fragmente / ein paar Bits empfangen, weil das Zeitfenster von 36kHz bei 38kHz auch manchmal paßt? 3) alles trotzdem empfangen, weil er ohnehin von 30 bis 40 kHz tolerant ist? Fall 1 oder 3 wäre mir am liebsten, da könnte ich entweder mehrere Empfänger verbauen oder einen für alles nehmen - aber ich habe eben noch keine 38kHz Fernbedienung dabei..
Irgendwas zwischen 1) und 3). Die TSOPs haben eine gewisse Bandbreite, so daß du von einem 38kHz-Signal auch noch einen Teil (der Amplitude) erhältst. Sind Sender und Empfänger sehr dicht beieinander, kannst du problemlos dekodieren. Bei größerem Abstand ist halt die Fehlerrate deutlich höher als bei der richtigen Frequenz.
'nen 1736er würde auch das 38 KHz signal empfangen, äußern tut sich der Unterschied dann aber evtl in unterschiedlicher reichweite bzw unterschiedlicher toleranz bei falscher ausrichtung der FB. gibt es auch einen nicht demodulierenden IR empfänger? um sich mal raw daten anzuschauen ist sowas ja schon interessant.
lach diese Präzision habe ich befürchtet. Also werde ich mit kleinen Abständen arbeiten (beim Einlesen), das Senden ist ja dann nicht kritisch, wenn ich richtig decodiert habe.. Viel mehr Zeit zum Basteln und probieren müßte man haben! :-)
> lach diese Präzision habe ich befürchtet Hattest du Aussagen über die Fehlerraten erwartet? Sieh dir das Datenblatt des TSOPs an und such die Bandbreite heraus. Unter der Annahme einer Gaussfunktion kannst du die Amplitudenreduktion berechnen. Bleibt z.B. 25% erhalten, entspricht dies einer Entfernungsbegranzung um den Faktor 4, da die Amplitude mit der Entfernung (die Energiedichte mit dem Entfernungsquadrat) abnimmt. >gibt es auch einen nicht demodulierenden IR empfänger? Nennt sich dann 'nen Fotodiode. Ist es so schwer, 'nen richtigen Artikel zu benutzen. "Ein" wäre kürzer und lesbarer als dein 'nen. Sorry, vergaß dabei natürlich wie cool du bist.
Hehe, habe genau das, was du vorhast letzt gebaut. Ein anlernbares RC5 modul, mit 16 verschiedenen Schaltfunktionen (toggle, on, zeitverzögert etc). Und von meinen ca 7 HiFi FBs ist es nur eine die mit RC5 arbeitet.
Ich finde das Thema auch interessant. @Djshadowman: Gesucht ist doch eine universelle Lösung, Du hast dagegen ein RC5-Modul, das nur eine Deiner Fernbedienungen bedienen kann? Was hast Du als Empfänger, auch TSOP1736 oder Fotodiode/Transistor? Braucht man überhaupt einen TSOP, wenn man ohnehin (relativ hochauflösend) die Impulslängen messen und speichern will und dann "zu Fuß" filtert und decodiert?
Hallo, ich war zwischendurch mit meinem Audiorecorder beschäftigt und komme mit Bastelerfahrungen auf dieses Thema zurück, evtl. interessiert das jemanden, der auch mit IR, TSOP & Co. 'rumbastelt. 1) Wie oben schon erwähnt - Die Situation, daß viele Fernbedienungen RC5 können war bei mir eine Ausnahme, die senden alles mögliche. 2) Die TSOP* sind meiner Ansicht nach so breitbandig, daß bei normalen (Zimmer-)Entfernungen die Frequenz nur eine untergeordnete Rolle spielt. Sogar den IRDA von meinem Laptop mußte ich zuhalten, der wurde auch empfangen.. :-) 3) Ich hatte keine "Exoten" unter meinen Fernbedienungen, die sehr kurze Signale senden (solche kurzen Signale empfängt man manchmal als Störung). Alle haben mindestens 200uS breite Pulse gesendet. Im Anhang findet Ihr ein kleines, simples Programm, welches mir (mangels SpeicherOszi) beim Analysieren der FBs sehr geholfen hat. Es benötigt nur einen TSOP* in Standard-Beschaltung und einen AtMega* (Ich hab Mega8 genommen mit internem Oszillator 8Mhz). Ein Terminal reicht als Ausgabe. Es wartet einfach auf das erste "L" vom TSOP und schneided dann die nächsten 200ms in 50uS Auflösung mit. Ausgabe siehe unten. Ich bin nicht sicher, ob es würdig für die Codesammlung ist - ist ja nun nicht so kompliziert und im oft geschmähten BasCom geschrieben.. :-) Was meint Ihr? (Ok, wer das nicht mag kann es ja umschreiben, ist ja einfach zu lesen) Beispielausgabe: FB vom CD-Spieler, Taste FF Start IRWatcher. 1 Stelle = 50 uSekunden 0 ms 0000000000000000000000000000000000000000 2 ms 0000000000000000000000000000000000000000 4 ms 0000000000000000000000000000000000000000 6 ms 0000000000000000000000000000000000000000 8 ms 0000000000000111111111111111111111111111 10 ms 1111111111111111111111111111111111111111 12 ms 1111111111111111110000000000011111111110 14 ms 0000000000001111111100000000000011111111 16 ms 1100000000000011111111100000000000011111 18 ms 1111100000000000111111111100000000000111 20 ms 1111111100000000000111111111100000000000 22 ms 1111111111111111111111111111111100000000 24 ms 0001111111111111111111111111111111000000 26 ms 0000001111111111111111111111111111111000 28 ms 0000000001111111111111111111111111111111 30 ms 0000000000011111111111111111111111111111 32 ms 1100000000000011111111111111111111111111 34 ms 1111110000000000011111111111111111111111 36 ms 1111111100000000000011111111111111111111 38 ms 1111111111100000000000011111111100000000 40 ms 0000111111111100000000000111111111111111 42 ms 1111111111111111100000000000111111111100 44 ms 0000000000111111111111111111111111111111 46 ms 1000000000000111111111000000000000111111 48 ms 1111111111111111111111111000000000000111 50 ms 1111111000000000000111111111111111111111 52 ms 1111111110000000000001111111111111111111 54 ms 1111111111110000000000001111111110000000 56 ms 0000011111111111111111111111111111110000 58 ms 0000000011111111110000000000011111111111 60 ms 1111111111111111111110000000000011111111 62 ms 1100000000000111111111111111111111111111 64 ms 1111000000000000011111111111111111111111 66 ms 1111111111111111111111111111111111111111 68 ms 1111111111111111111111111111111111111111 70 ms 1111111111111111111111111111111111111111 72 ms 1111111111111111111111111111111111111111 74 ms 1111111111111111111111111111111111111111 76 ms 1111111111111111111111111111111111111111 78 ms 1111111111111111111111111111111111111111 80 ms 1111111111111111111111111111111111111111 82 ms 1111111111111111111111111111111111111111 84 ms 1111111111111111111111111111111111111111 86 ms 1111111111111111111111111111111111111111 88 ms 1111111111111111111111111111111111111111 90 ms 1111111111111111111111111111111111111111 92 ms 1111111111111111111111111111111111111111 94 ms 1111111111111111111111111111111111111111 96 ms 1111111111111111111111111111111111111111 98 ms 1111111111111111111111111111111111111111 100 ms 1111111111111111111111111111111111111111 102 ms 1111111111111110000000000000000000000000 104 ms 0000000000000000000000000000000000000000 106 ms 0000000000000000000000000000000000000000 108 ms 0000000000000000000000000000000000000000 110 ms 0000000000000000000000000000111111111111 112 ms 1111111111111111111111111111100000000000 114 ms 1111111111111111111111111111111111111111 116 ms 1111111111111111111111111111111111111111 118 ms 1111111111111111111111111111111111111111 120 ms 1111111111111111111111111111111111111111 122 ms 1111111111111111111111111111111111111111 124 ms 1111111111111111111111111111111111111111 126 ms 1111111111111111111111111111111111111111 128 ms 1111111111111111111111111111111111111111 130 ms 1111111111111111111111111111111111111111 132 ms 1111111111111111111111111111111111111111 134 ms 1111111111111111111111111111111111111111 136 ms 1111111111111111111111111111111111111111 138 ms 1111111111111111111111111111111111111111 140 ms 1111111111111111111111111111111111111111 142 ms 1111111111111111111111111111111111111111 144 ms 1111111111111111111111111111111111111111 146 ms 1111111111111111111111111111111111111111 148 ms 1111111111111111111111111111111111111111 150 ms 1111111111111111111111111111111111111111 152 ms 1111111111111111111111111111111111111111 154 ms 1111111111111111111111111111111111111111 156 ms 1111111111111111111111111111111111111111 158 ms 1111111111111111111111111111111111111111 160 ms 1111111111111111111111111111111111111111 162 ms 1111111111111111111111111111111111111111 164 ms 1111111111111111111111111111111111111111 166 ms 1111111111111111111111111111111111111111 168 ms 1111111111111111111111111111111111111111 170 ms 1111111111111111111111111111111111111111 172 ms 1111111111111111111111111111111111111111 174 ms 1111111111111111111111111111111111111111 176 ms 1111111111111111111111111111111111111111 178 ms 1111111111111111111111111111111111111111 180 ms 1111111111111111111111111111111111111111 182 ms 1111111111111111111111111111111111111111 184 ms 1111111111111111111111111111111111111111 186 ms 1111111111111111111111111111111111111111 188 ms 1111111111111111111111111111111111111111 190 ms 1111111111111111111111111111111111111111 192 ms 1111111111111111111111111111111111111111 194 ms 1111111111111111111111111111111111111111 196 ms 1111111111111111111111111111111111111111 198 ms 1111111111111111111111111111111111111111 200 ms
Hallo! Hat jemand funktionierende AVR-GCC Code, der mittels einer TSOP1738 den oben erwähnten Japan Code von Panasonic empfangen und dekodieren kann?
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.