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/IRMPOldie 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.PDFOldie 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?
"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
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
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.
