Liste und Beschreibung verschiedener 38kHz IR-Protokolle

Ja, ganz sicher. Das wäre für meine Lösung nix anderes als eine neue, bisher unbekannte Taste mit einem sehr länglichen Hauptcode und einem Repeatcode, der genauso aussieht wie der der anderen, ihm möglicherweise schon bekannten Tasten.

Replay des Codes wird genau dasselbe bewirken wie deine Manipulation an der Originalbedienung. Der einzige Nachteil würde ein unnötig hoher Verbrauch an Speicherplatz für die Abspeicherung dieses Tastencodes sein.

Würdest du nämlich einfach ganz normal die Tasten Play und Stop einlernen und dann der Replay-Routine befehlen "Play down", einige Zeit später dann "Stop down" und wieder einige Zeit später "Stop up", könntest du ebenfalls genau das Signal der Originalbedienung nachempfinden, ohne diesen hohen Speicherverbrauch in Kauf nehmen zu müssen.

Mal ganz davon abgesehen, daß es also sogar auf zwei Wegen möglich möglich wäre, den Code einzulernen und wiederzugeben: Wozu ist der eigentlich sinnvoll? Ich meine: Was macht der VCR daraus? Wird darüber irgendeine Sonderfunktion erreichbar oder ist es nur eine sehr umständliche Art, die "Pause"-Taste zu betätigen?

Nicht wirklich. wie ich schon schrieb, machen die Signaleigenschaften praktisch immer eine sehr effizente Kompression möglich. Typisch kommt (nach "Entrauschen") nur eine einstellige Zahl _verschiedener_ Puls- und Pauselängen vor.

Wieder völlig abstrakte Herangehensweise: Was viel Redundanz enthält, läßt sich gut packen.

Als ersten Schritt machst du eine kleine Tabelle, in der die Werte der z.B. sechs oder acht vorkommenden verschiedenen Längen gespeichert sind. Die zeitliche Abfolge der Längen selber speicherst dann in Form von Indizes in diese Tabelle. Das allein spart typisch schon knapp drei Viertel des Speicherbedarfs. (Weil die Längentabelle für alle Tastencodes der FB gemeinsam verwendet werden kann)

Als zweiten Schritt kann man dann noch ausnutzen, daß es recht oft extreme Häufigkeitsunterschiede der vorkommenden Längen (hier also Tabellenindizes) gibt. Das liegt daran, daß oft Syncs (ultralange Trägerbursts) und diverse Pausen unterschiedlicher Länge verwendet werden, die im Verhältnis zu den zur Codierung der Nutzbits verwendeten Längen nur recht selten vorkommen. Zur Codierung der eigentlichen Nutzbits werden meist nur zwei oder drei verschiedene Längen verwendet. Ein Szenario, was wie geschaffen für Entropie-Encoder á la Huffman ist. Spart typisch nochmal knapp die Hälfte des Speichers, den Stufe 1 noch verbraucht hat.

Klar: nach dem ganzen Aufwand wird das Ergebnis immer noch deutlich mehr Platz verbrauchen, als wenn man nur die Rohbits und die Kodierungsvorschrift speichern müßte. Aber dafür ist es halt ziemlich universell.

Keine Ahnung. Ich hab den Video nie besessen. Ich hab die FB nur mal auf dem Flohmarkt gekauft weil ich damit anderes vorhatte.

Ich bin aber davon abgekommen weil der Nachteil dieser Methode darin besteht das ein Tastendruck nicht erkannt wird wenn die erste Codefolge fehlerhaft uebertragen wird.

Olaf

Also lesen musst du schon selber :-)

| The first number indicates the duration of the first pulse in microseconds. | The second number indicates the duration of the space which follows it.