Hallo, ich möchte einen IR-Sender für einen Lautsprecher bauen ohne die Fernbedienung auseinander nehmen zu müssen. Hab dazu nen TSOP31238 genommen; IRMP liefert mir immer als Protokoll "23" (obwohl es aufgrund eines Konflikts deaktiviert worden ist!?); die Addresse und der Befehl ist zufällig. Also wird wohl die Modulationsfrequenz nicht stimmen (=> nicht 38kHz). Wollte mir dazu ein kleines Programm schreiben, das diese Frequenz ermittelt, aber irgendwie funktioniert das nicht. Als IR-Empfänger habe ich den Detektor aus den IR-Lichtschranken-Paaren von Pollin genommen. Die meisten Werte liegen bei ca. 10000 => 16MHz/10000 = 1600Hz. Das liegt aber weit von 30 bis 70kHz entfernt ... Ist irgendwas in meinem Programm falsch oder ist die Fernbedienung einfach nur komisch!? Danke schon mal burgerohnealles
Was denn nun? Der TSOP31238 ist ein Empfänger, der aber nur die Hüllkurve ausgibt. Der funktioniert auch mit 30..45 und bestimmt auch 56 kHz, wenn der Sender nicht zu weit weg ist. Um den Code zu ermitteln, sollte das gehen. - Wenn das Code-Ermittlungsprogramm was taugt. - Wer deaktiviert denn da "aufgrund eines Konflikts"??? Was die Pollin IR-Lichtschranken-Paare liefern, such ich jetzt nicht raus. Das Mindeste wäre ja wohl die Bestellnummer als Suchhilfe gewesen.
Oldie schrieb: > Wer deaktiviert denn da "aufgrund eines Konflikts"??? IRMP. Man kann in der Datei "irmpconfig.h" einstellen, welche Protokolle mitkompiliert werden sollen. Einige sind zusammen nicht kompatibel und werden daher beim Kompilieren automatisch deaktivert. EDIT2: Hier IRMP: http://www.mikrocontroller.net/articles/IRMP Oldie schrieb: > Was die Pollin IR-Lichtschranken-Paare liefern, such ich jetzt > nicht raus. Das Mindeste wäre ja wohl die Bestellnummer > als Suchhilfe gewesen. Hab gedacht es sei nicht nötig, da es der erste Link ist, wenn man bei Google nach "ir lichtschranken paare" sucht, sorry; aber hier wäre gleich das Datenblatt: http://www.pollin.de/shop/downloads/D120592D.PDF Oldie schrieb: > Wenn das Code-Ermittlungsprogramm was taugt. Das wollt ich ja von euch wissen .. EDIT: Ich mein, ich möchte wissen, ob mein "Frequenz-Ermittlungsprogramm" was taugt. Falls du IRMP meinst, das taugt was, hat bis jetzt bei allen anderen IR-Fernbedienungen problemlos funktioniert. Oldie schrieb: > Der funktioniert auch mit 30..45 Hab gedacht er geht nur mit 38kHz, aber ok. Aber warum bekomm ich dann 1.) ein Protokoll, das deaktiviert ist und 2.) als "address" und "command" zufällige Werte?
Jonathan K. schrieb: > Hab gedacht es sei nicht nötig, da es der erste Link ist, wenn man bei > Google nach "ir lichtschranken paare" sucht, sorry; aber hier wäre > gleich das Datenblatt: http://www.pollin.de/shop/downloads/D120592D.PDF Na bitte, geht doch. Und nun noch die Schaltung, mit der du den Detektor an den µC getüdert hast. Dann hättest du es doch schon im dritten Anlauf tatsächlich geschafft, alle Informationen bereitzustellen, die man zur Beurteilung der Funktionsfähigkeit deines Programms benötigt... > Aber warum bekomm ich dann > 1.) ein Protokoll, das deaktiviert ist und > 2.) als "address" und "command" zufällige Werte? Weil offensichtlich Müll empfangen wird, an dem die Analyseroutine von IRMP scheitert.
Jonathan K. schrieb: > Bekomm ich vielleicht auch ernsthafte Antworten? Ersetzt "Oskar" durch "Oszilloskop". Besser?
Jonathan K. schrieb: > Bekomm ich vielleicht auch ernsthafte Antworten? "Oskar" ist der Slangausdruck für Oszilloskop. Hast Du ein solches oder kannst Du eins ausleihen? Damit kannst Du die Frequenz am besten ausmessen. Gruss Harald
Jonathan K. schrieb: > Aber warum bekomm ich dann > 1.) ein Protokoll, das deaktiviert ist und > 2.) als "address" und "command" zufällige Werte? Schick mir ein paar IRMP-Scans von der FB. Dann check ich mit dem IRMP-Analyzer. Wie Du Scans erstellen kannst, steht im Artikel: http://www.mikrocontroller.net/articles/IRMP#Scannen_von_unbekannten_IR-Protokollen Welchen Wert für INTERRUPTS hast Du denn verwendet? Am besten schickst Du mir auch die irmpconfig.h. Gruß, Frank
Jonathan K. schrieb: > Also wird wohl die Modulationsfrequenz nicht stimmen (=> > nicht 38kHz). Wollte mir dazu ein kleines Programm schreiben, das diese > Frequenz ermittelt, aber irgendwie funktioniert das nicht Sieh dir mal das Projekt unter http://www.mikrocontroller.net/articles/High-Speed_capture_mit_ATmega_Timer an, das ermittelt unter anderem die Modulationsfrequenz. Mit einem demodulierenden IR-Empfänger geht dies aber prinzipbedingt nicht. Michael
Angehängte Dateien:
-
ir.png
100 KB
Eln schrieb: > Ersetzt "Oskar" durch "Oszilloskop". > > Besser? Harald Wilhelms schrieb: > "Oskar" ist der Slangausdruck für Oszilloskop. > Hast Du ein solches oder kannst Du eins ausleihen? Achso, hab ich nicht gewusst, aber man kann ja immer dazulernen ;) c-hater schrieb: > Und nun noch die Schaltung, mit der du den Detektor > an den µC getüdert hast. Frank M. schrieb: > Am besten schickst > Du mir auch die irmpconfig.h. Ist im Anhang (für Linux- und Windoof-User). EDIT: Sorry, dass es kein Eagle-Schaltplan ist, hatte vor paar Tagen ein neues System installiert, und hab bisher Eagle noch nicht installiert. Frank M. schrieb: > Welchen Wert für INTERRUPTS hast Du denn verwendet? Hab 15000 und 20000 probiert, beides führt zum Protokoll "23" und zufälliger Adresse/Befehl. Michael Dreher schrieb: > Sieh dir mal das Projekt unter > http://www.mikrocontroller.net/articles/High-Speed_capture_mit_ATmega_Timer > an, das ermittelt unter anderem die Modulationsfrequenz. Probier ich gleich mal. Michael Dreher schrieb: > Mit einem > demodulierenden IR-Empfänger geht dies aber prinzipbedingt nicht. Das ist mir klar :D
Jonathan K. schrieb: >> Und nun noch die Schaltung, mit der du den Detektor >> an den µC getüdert hast. [handgemalter Scan] Ohje... Versuch's mal so: Vcc o--- | | \C \| |--B /| /E | - o-----oPC0 | |/ | | \| | Poti 10k - | o--- GND Poti so einstellen, daß der AVR an PC0 gerade so sicher Low sieht, wenn keine FB sendet. Am besten zur optischen Rückmeldung eine LED ansteuern, die leuchtet, wenn an PC0 High gesehen wird. Dann sieht man sehr schön bei langsamer Annäherung der aktiven FB an den Sensor, wie die (je nach Code) entweder sichtbar rythmisch flackert oder einfach nur konstant heller wird. Wenn der Punkt erreicht ist, an der sie nicht mehr sichtbar heller leuchtet/flackert, ist der der optimale Abstand zum Einlernen des Codes und zur Messung der Trägerfrequenz gefunden. Das dürfte so bei einigen cm Abstand der Fall sein.
Jonathan K. schrieb: > Hab 15000 und 20000 probiert, beides führt zum Protokoll "23" und > zufälliger Adresse/Befehl. Danke für die Scans. Das Protokoll 23 ist das RUWIDO-Protokoll. Obwohl es vom Compiler wegen Timing-Konflikten mit dem DENON-Protokoll abgeschaltet wird, schleicht es sich wegen Deiner Aktivierung des SIEMENS-Protokolls doch wieder rein. Das liegt daran, dass sich RUWIDO- und SIEMENS-Protokoll nur von der Anzahl der Bits unterscheiden. Daher wird hier derselbe Decoder verwendet. Es ist eigentlich ein Bug in irmp.h, denn das SIEMENS-Protokoll hätte ebenso abgeschaltet werden müssen. Wie kommt es zum Timing-Konflikt mit dem DENON-Protokoll? Die Pulse/Pausen des Start-Bits sind sich sehr ähnlich, so dass IRMP sich da "verfransen" kann. Ich hatte aber keine Lust, wegen des sehr selten vorkommenden RUWIDO-Protokolls extra ein zweigleisiges Scannen von DENON und RUWIDO in die IRMP-Statemachine einzubauen. Daher wird hier hart verfahren: RUWIDO wird zugunsten DENON abgeschaltet. Das einzig Richtige, was Du hättest machen können: DENON abschalten zugunsten RUWIDO. Damit wäre der Konflikt weg. Aber es hätte sowieso nichts genutzt: Das Protokoll, was da Deine FB benutzt, wird von IRMP (noch) nicht unterstützt. Es wäre jedoch ein leichtes, das Protokoll einzubauen. Es handelt sich hier um ein stinknormales Pulse Distance Width Protokoll, also um eine Mischung von Pulse Distance und Pulse Width Coding. Codiert sind 1 Start-Bit + 10 Daten-Bits + 1 Stop-Bit. 0-Bit: 420 µs Puls, 1250 µs Pause 1-Bit: 1250 µs Puls, 420 µs Pause Ich brauche ca. 1 Stunde, um das neue Protokoll in IRMP einzubauen. Wenn Du das möchtest, dann brauche ich folgende Angaben von Dir: 1. Bezeichnung/Name der FB, um den Namen des Protokolls festzulegen 2. Angabe, ob in den Einzel-Log-Dateien immer dieselbe Taste gedrückt wurde. Da scheint sich nämlich ein Toggle-Bit zu verstecken, das ich isolieren muss. 3. Angabe, ob Du das Protokoll auch in IRSND brauchst. Wenn ja, könnte ich das bei der Gelegenheit auch einbauen. 4. Wenn Du ein Oszilloskop hast, wäre noch die Angabe der Modulationsfrequenz gut. Das geht aber nicht mit einem TSOP. Wenn das nicht möglich ist, werde ich einfach 38 kHz annehmen. Gruß, Frank
@c-hater: Werde ich gleich mal so aufaufbauen .. Frank M. schrieb: > 1. Bezeichnung/Name der FB, um den Namen des Protokolls festzulegen Da steht nur X-TENSIONS drauf. Genaueres weiß ich nicht. Frank M. schrieb: > 2. Angabe, ob in den Einzel-Log-Dateien immer dieselbe Taste gedrückt > wurde. Da scheint sich nämlich ein Toggle-Bit zu verstecken, das > ich isolieren muss. Alle Log-Dateien haben die selben Tasten in der selben Reihefolge: POWER, MUTE, BASS_UP, BASS_DOWN, VOLUME_UP, VOLUME_DOWN. Frank M. schrieb: > 3. Angabe, ob Du das Protokoll auch in IRSND brauchst. Wenn ja, könnte > ich das bei der Gelegenheit auch einbauen. Das ist ja mein eigentliches Ziel. Frank M. schrieb: > 4. Wenn Du ein Oszilloskop hast, wäre noch die Angabe der > Modulationsfrequenz gut. Das geht aber nicht mit einem TSOP. Wenn > das nicht möglich ist, werde ich einfach 38 kHz annehmen. Oszi hab ich leider nicht, bin aber grad dabei das ganze mit nem AVR zu messen. EDIT: Die Scans hab ich mit INTERRUPTS=15000 gemacht.
Jonathan K. schrieb: > Da steht nur X-TENSIONS drauf. Genaueres weiß ich nicht. Okay, ich nenne es jetzt einfach SPEAKER :-) Das Protokoll ist übrigens sehr ähnlich zum Nubert-Protokoll - bis auf die Timings. Daher ist es für IRMP eigentlich nichts wirklich neues. Reicht es Dir, wenn ich den geänderten Source im SVN einchecke? Bin gleich schon fertig... letzte Tests laufen. > Alle Log-Dateien haben die selben Tasten in der selben Reihefolge: > POWER, MUTE, BASS_UP, BASS_DOWN, VOLUME_UP, VOLUME_DOWN. Danke, das erklärt einiges. Also doch kein Toggle-Bit. >> 3. Angabe, ob Du das Protokoll auch in IRSND brauchst. Wenn ja, könnte >> ich das bei der Gelegenheit auch einbauen. > > Das ist ja mein eigentliches Ziel. Okay, das mache ich dann, sobald Du den neuen IRMP getestet hast. > EDIT: Die Scans hab ich mit INTERRUPTS=15000 gemacht. Danke, hatte ich schon aus Deiner irmpconfig.h gesehen ;-)
Ist im SVN als IRMP-Version 2.5.0. Protokoll heisst SPEAKER, Protokollnummer ist die 39. Du solltest bis auf die 6 typischen Standard-Protolle und SPEAKER nichts weiteres aktivieren, was Du nicht brauchst. Ich habe den Konflikt-Test noch nicht gemacht. Sobald Du mir schreibst, dass IRMP alles zuverlässig erkennt, mache ich mich an IRSND. Gruß, Frank
:
Bearbeitet durch Moderator
Hatte gerade Langeweile und hab auch schon mal das neue SPEAKER-Protokoll in IRSND eingebaut. Damit kannst Du die Codes nun auch senden. Ist eingecheckt im SVN unter der Versionsnummer 2.5.1. Viel Spaß, Frank
Erstmal ein fettes DANKE, dass du dir die Arbeit machst, dieses Protokoll einzubauen :) Funktioniert so halb. Protokoll wird immer richtig erkannt, aber "command" nicht immer. Ich erhalte für die TASTE meist XXX, aber auch YYY und ZZZ. TASTE XXX YYY ZZZ ------------------------ POWER 322 320 256 MUTE 328 320 256 BASS_UP 385 384 256 BASS_DOWN 386 384 256 VOL_UP 400 384 256 VOL_DOWN 392 384 256 Wenn ich die Taste gedrückt halte (geht nur bei BASS_UP/DOWN und VOL_UP/DOWN), bekomme ich fast immer den ersten Wert (XXX). Wenn ich diese Taste dann schnell hintereinander drücke kommen relativ häufig auch die anderen Werte (YYY/ZZZ). Habe es mit INTERRUPTS=10000/15000/20000 getestet. Bei allen das selbe Ergebnis. Frank M. schrieb: > hab auch schon mal das neue > SPEAKER-Protokoll in IRSND eingebaut Werd ich gleich mal testen.
Jonathan K. schrieb: > Funktioniert so halb. Protokoll wird immer richtig erkannt, aber > "command" nicht immer. > > Ich erhalte für die TASTE meist XXX, aber auch YYY und ZZZ. > TASTE XXX YYY ZZZ > ------------------------ > POWER 322 320 256 > MUTE 328 320 256 > BASS_UP 385 384 256 > BASS_DOWN 386 384 256 > VOL_UP 400 384 256 > VOL_DOWN 392 384 256 Ja, die 256 (ZZZ) sehe ich auch öfters in Deinen Scans - und zwar ausschließlich als Wiederholframe. Deine FB wiederholt jeden Frame einmal. Normalerweise ist der Scan komplett identisch zum 1. Frame. Aber in Deinen Scans kommt es ab und zu vor, dass die 256 statt dem ursprünglichen Kommando geschickt wird. Ich nehme mal an, dass die 256 ( = 0x0100) als Kommando bedeutet: "Wiederhole den zuletzt gesandten Befehl". Das ist so ähnlich wie bei den NEC-Repetition Frames. Bitte teste folgendes: Jede Taste so kurz wie möglich drücken. Wenn die 256 so nicht reproduzierbar ist, ist es ein Wiederholungsframe durch langen Tastendruck. In dem Fall baue ich in IRMP dann ein, dass Du das letzte Kommando davor erhältst und in Flag das REPETITION-Flag gesetzt ist. Ähnlich dürfte es sich bei YYY verhalten: Es heisst wohl: Wiederholung des letzten Kommandos AUS. Die brauchen wir bei IRMP nicht. Ich werde die Frames dann in IRMP einfach ignorieren. Bei den repetierenden Tasten BASS und VOLUME ist es wohl ein anderer Wert als bei den nicht-repetierenden wie Power und Mute. Wenn Du das so bestätigen kannst, werde ich das in IRMP so einbauen. Gruß, Frank
Hmm, das ist ein bisschen komisch: Wenn ich die Taste gedrückt halte, kommt immer der erste Wert (XXX), wenn ich sie oft einzeln drücke kommt XXX, YYY und ZZZ zufällig. Aber IRSND scheint zu funktionieren. Habe bis jetzt nur MUTE getestet, aber der Rest geht denk ich dann auch.
Jonathan K. schrieb: > Hmm, das ist ein bisschen komisch: Wenn ich die Taste gedrückt halte, > kommt immer der erste Wert (XXX), wenn ich sie oft einzeln drücke kommt > XXX, YYY und ZZZ zufällig. Hm, blöd. Es handelt sich aber nicht um fehlerhafte Übertragungen. Die Werte sind klar aus den Scans zu erkennen. Fehlinterpretationen sind da nicht möglich. Irgendein herstellerspezifisches "Geheimnnis" verbirgt sich hinter YYY und ZZZ. Man könnte sie ja in IRMP komplett ignorieren, denn ihr Sinn und Zweck erschließt sich mir (noch) nicht. > Aber IRSND scheint zu funktionieren. Habe bis jetzt nur MUTE getestet, > aber der Rest geht denk ich dann auch. Ja, wird wohl. Du könntest ja mal testen, wie sich Deine Lautsprecher verhalten, wenn Du nach Volume Up einige male ZZZ (bzw. YYY) schickst ;-)
Kenne das angesprochene Projekt nicht. Eine meiner Fernbedienungen ging kaputt und beim reingucken zwecks Reparaturversuch bemerkte ich ein IC das einen Resonator um die 800 KHZ besitzt und im Empfänger ein IR Diode mit eingebauter Logik ist, der das hochfrequent gesendete Signal intern decodiert. Ob solcherlei Technik vom IRMP Protokol bzw dem drum herum erkannt werden kann, weiß ich nicht. Da die Fernbedienung nicht funktionierte, gab es nichts zu oszillographieren. Somit wäre für mich nebenher interessant ob das IRMP Protokol für solcherlei teils unübliche Technik dienlich sein könnte.
Kenne das angesprochene Projekt nicht. Eine meiner Fernbedienungen ging kaputt und beim reingucken zwecks Reparaturversuch bemerkte ich ein IC das einen Resonator um die 800 KHZ besitzt und im Empfänger eine IR Diode mit eingebauter Logik ist, die das hochfrequent gesendete Signal intern decodiert. Ob solcherlei Technik vom IRMP Protokol bzw dem drum herum erkannt werden kann, weiß ich nicht. Da die Fernbedienung nicht funktionierte, gab es nichts zu oszillographieren. Somit wäre für mich nebenher interessant ob das IRMP Protokol für solcherlei teils unübliche Technik dienlich sein könnte.
Bastler schrieb: > Kenne das angesprochene Projekt nicht. Macht nichts, lies Dir den Artikel IRMP durch und schau Dir die verlinkten Projekte mit IRMP an. IRMP versteht mittlerweile 40 Protokolle und deckt damit mehr als 95% aller im Haushalt üblichen Fernbedienungen ab. > Eine meiner Fernbedienungen ging kaputt und beim reingucken zwecks > Reparaturversuch bemerkte ich ein IC das einen Resonator um die 800 KHZ > besitzt und im Empfänger ein IR Diode mit eingebauter Logik ist, der das > hochfrequent gesendete Signal intern decodiert. Das ist üblich. Allerdings wird meist nicht mit so hohen Modulationsfrequenzen gearbeitet. Die üblichen Protokolle arbeiten mit 32 bis 40 kHz (Bang & Olufsen ist eine Ausnahme: hier sind es 455kHz). Wahrscheinlich werden die 800 kHz in Deiner defekten Fernbedienung nochmal runtergeteilt. Sicher, dass im Empfänger eine IR Diode und nicht ein TSOP-Empfänger, der die Modulationsfrequenz herausfiltert, steckte? > Ob solcherlei Technik vom IRMP Protokol bzw dem drum herum erkannt > werden kann, weiß ich nicht. Der TSOP-Empfänger muss nur zur Modulationsfrequenz einigermaßen passen (ein 38kHz-TSOP empfängt aber alles von 32 bis 40 kHz mühelos). > Da die Fernbedienung nicht funktionierte, gab es nichts zu > oszillographieren. Ohne funktionsfähige Fernbedienung bist Du aufgeschmissen. Da kann man das Protokoll und die dazugehörenden Kommandos nur noch "erraten". > Somit wäre für mich nebenher interessant ob das IRMP Protokol für > solcherlei teils unübliche Technik dienlich sein könnte. Siehe oben: Solange es einen TSOP gibt, dann geht es mit IRMP. Ja, es gibt auch TSOPs für das 455-kHz-Protokoll von B&O ;-)
Frank M. schrieb: > Du könntest ja mal testen, wie sich Deine Lautsprecher > verhalten, wenn Du nach Volume Up einige male ZZZ (bzw. YYY) schickst > ;-) Hab mal die anderen Tasten getestet, funktioniert perfekt! Wenn ich YYY/ZZZ sende passiert nichts. Egal, bei welcher Taste und egal, ob ich gerade ein-/ausgeschaltet hab.
Frank M. schrieb: > Das Protokoll ist übrigens sehr ähnlich zum Nubert-Protokoll - bis auf > die Timings. Daher ist es für IRMP eigentlich nichts wirklich neues. Sehe ich das richtig, dass Du damit die Nubert Systeme bedienen kannst? Das wäre interessant für mich.
Rolf Sassinger schrieb: > Sehe ich das richtig, dass Du damit die Nubert Systeme bedienen kannst? Jepp, siehe Artikel IRMP.
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.