Axas E4HD Ultra FB Codes

[Gorcon]

meinst du das ..

Nein. Beitrag 1 (Punkt 1,2,3)

[seife]

Hi,
genau, ich habe per Telnet über den rcsim-Befehl diesen Code "quasi" gesendet, also vermutlich dem Kernel vorgemacht, dass dieser grad ankam.

Nein, damit hast du neutrino vorgemacht, daß dieser code aus dem rcinput-code fertig dekodiert raus kam.

Alternativ gibt es im rcsim auch die Möglichkeit (wird bei der Kompilation ausgewählt), den code in den Kernel zu injizieren, so daß er dann wieder aus dem input device rauskommt und dann wieder vom neutrino rcinput-code dekodiert wird, aber soweit ich sehe wird da im NI nicht so kompiliert.

Wenn du bei eingabe von "rcsim" ohne parameter sowas bekommst:

Code: Alles auswählen

rcsim v1.2
Usage: rcsim <keyname>

     Keys:
 [...liste der keys...]
 

dann hast du die version, die das nicht in den Kernel injiziert.

Aber egal welche version du hast: rcsim kann Keycodes senden, die die Fernbedienung selber (oder der Treiber dazu) gar nicht kennt. Hat also überhaupt nichts damit zu tun, was auf deiner Hardware mittels infrarot (oder Funk) geht.
Der Kernel ist ja vermutlich die Schnittstelle zu allem, die Codeversteher sagen ja nix dazu und lassen uns dumm sterben... LOL

Also die Box kann schon mit den diskreten Codes umgehen, bloss fehlt "nur"? noch die Strecke IR-(das was ich benenne als) Frontprozessor-(Treiber-) und Kernel. Aber da gibts ja Dank Open-Source evtl Möglichkeiten.

Alles logischerweise nur, wenn die Box an ist, im Deep-Standby hat der Frontprozessor das sagen, den kann man wohl nicht umprogrammieren. Aber den ganzen Rest, das sollte gehen können...

Ciao,
DdD.
[/quote]

[seife]

Und nochwas ist mir letztens aufgefallen, im GIT scheint es für einige Boxen eine lirc.conf zu geben -> https://github.com/Duckbox-Developers/b ... ase.mk#L67 Kann man da die möglichen Tasten einfach erweitern?

Ja. Aber nur bei Boxen die einen LIRC treiber haben. Da wird dann die eigentliche Dekodierung des IR Codes im userspace vom lircd gemacht und dem kann man fast beliebige Protokolle und codetabellen beibringen. Ich kenne das aber nur von den SPARK (wahrscheinlich auch andere SH4-) boxen (Und der dbox2, wobei die zwar einen LIRC Treiber hatte, aber tatsächlich die IR-Dekodierung des Frontprozessors genutzt hat wenn ich mich recht erinnere).
Aber die ganzen Mülltreiber heute (und auch früher, z.B. coolstream oder Tripledragon), dekodieren das Infrarotsignal selber und erzeugen dann ein input-device wo ein keycode rauskommt (bei der Tripledragon war es sogar ein proprietäres RC interface). Da ist man dann auf die Fernbedienungstypen und codebelegungen angewiesen, die der "freundliche" Treiberautor da mit reingepackt hat.

Wenn ich das problem hätte, würde ich mir wahrscheinlich einen externen USB-IR-Dekoder mit einem ATMega32u4 oder so (arduino leonardo) bauen, der sich als USB-Tastatur meldet und den internen einfach ignorieren. Im Prinzip sowas wie https://flirc.tv/. Problematisch wäre halt das einschalten vom deep standby, aber das würde ich auch irgendwie hin bekommen, z.B. in dem halt dann vom usb-ir-dekoder der originale "power" code gesendet würde oder so.
Man könnte sowas sogar mit eigener USB-ID so machen, daß es im neutrino automatisch erkannt würde und konfiguriert werden könnte. Es müsste halt nur jemand machen .

[Gorcon]

An einen extrenen IR Empfänger hatte ich auch schon gedacht. Für die Raspberry Pis gibt es ja auch eine Platine mit der man selbst angelernte FB Codes nutzen kann um diesen ein und ab zuschalten (vorher wird er richtig heruntergefahren).

Aber eigentlich müsste, denke ich, es ja ausreichen das shutdownplugin zu erweitern. So wie das im Image selbst von satbaby auch gemacht wurde.

[seife]

Nein schon mal deswegen nicht weil die VU+ Boxen ein tooglebit haben und daher auf zwei Codes hören. Die Zee² zumindest hatte den Code

Code: Alles auswählen

power                    0xAF50
power_off                0x738c
power_on                 0xf30c

Die VU+ haben wohl anscheinend das RC6 IR-Protokoll was ich so ergooglen konnte. Die hören also nicht "auf zwei codes" sondern auf einen RC6-Code, und das RC6-Protokoll spezifiziert halt, daß das togglebit bei jedem erneuten Senden eines Codes eben gewecheslt wird. Damit kann der Empfänger unterscheiden ob die Taste lange gedrückt wurde (code 0x1234 mit gleichbleibendem Togglebit) oder ob 2x gedrückt wurde (code 0x1234 mit wechselndem Togglebit).
Das ältere, früher sehr verbreitete RC5 Protokoll hat z.B. auch ein togglebit, das ist also nichts seltsames oder ungewöhnliches (Fun fact: in den späten 80ern / 90ern hatten die Fernbedienungen von Telefunken Fernsehern (Thomson) sogar 2 togglebits, also kam erst nach 4x knopf drücken wieder derselbe code an).

Das NEC IR Protokoll, welches meiner Stichprobe nach die meisten aktuellen Geräte, zumindest der "nicht-premium-Klasse" verwenden (ich kann mir gut vorstellen, daß SONY z.B. etwas eigenes verwendet, nur weil sie es können ), hat kein togglebit weil es einfach einmal das Kommando schickt und danach nur noch in kurzen Abständen "Wiederholung, Wiederholung, Wiederholung" signalisiert. Das hat den Vorteil, daß sogar Logitech es wahrscheinlich schafft das Protokoll zu implementieren, aber halt den Nachteil daß wenn das initiale Telegramm verloren geht, der Tastendruck nicht mehr dekodiert werden kann.
Die einzige Fernbedienung die mir in den letzten Jahren untergekommen ist die nicht NEC sondern RC6 als protokoll hatte ist die des (> 10 Jahre alten...) Philips-Fernsehers, der beim Hauskauf im Haus war. (Ok, die einzige bei der ich aktiv nachgeschaut habe was sie für ein Protokoll hat...).
Aber die ganzen schrottboxen die mir von irgendjemand in den letzten 5-10 Jahren geschickt wurden um da vielleicht neutrino draufzuportieren hatten alle NEC.

Daß die coolstreams discrete power on / off haben war auch nicht von Anfang an so, das wurde irgendwann mal "nachgerüstet". Meine neo macht keinen mucks mehr, sonst würde ich das mal testen ob deren Frontprozessor das schon konnte.

Ich vermute mal, daß die Kisten bei denen man mit diesem Fernbedienungs-Umschalt-Plugin die FB umschalten kann, alle vom selben OEM sind oder zumindest alle mehr oder weniger dasselbe Referenzdesign haben, so wie es bei den SPARK boxen auch war. Da gibt es auch gefühlt 20 verschiedenen Fernbedienungen, alle mit ungefähr gleichen Tasten, aber halt verschiedenen NEC codes für denselben knopf. Bei den SPARK Boxen kann man auch dem frontprozessor per kommado sagen, welche tasten er als Powerbutton interpretieren soll. Ich benutze das, um eine meiner boxen (in der Küche) mit der Coolstream Fernbedienung zu bedienen (die hat auch NEC Protokoll) und auch aus dem deep-standby zu holen.
Wenn das bei den 4k kisten so ähnlich ist, könnte ich mir gut vorstellen daß das Umstellen des Fernbedienungstyps halt auch dem Frontprozessor mitgeteilt wird. Der kann trotzdem dumm wie ein Stück Brot sein, alles was er sich merken muss ist ein 32bit-wort mit dem Fernbedienungscode für's Aufwachen.

[Gorcon]

Die VU+ haben wohl anscheinend das RC6 IR-Protokoll was ich so ergooglen konnte. Die hören also nicht "auf zwei codes" sondern auf einen RC6-Code, und das RC6-Protokoll spezifiziert halt, daß das togglebit bei jedem erneuten Senden eines Codes eben gewecheslt wird. Damit kann der Empfänger unterscheiden ob die Taste lange gedrückt wurde (code 0x1234 mit gleichbleibendem Togglebit) oder ob 2x gedrückt wurde (code 0x1234 mit wechselndem Togglebit).
Das ältere, früher sehr verbreitete RC5 Protokoll hat z.B. auch ein togglebit, das ist also nichts seltsames oder ungewöhnliches (Fun fact: in den späten 80ern / 90ern hatten die Fernbedienungen von Telefunken Fernsehern (Thomson) sogar 2 togglebits, also kam erst nach 4x knopf drücken wieder derselbe code an).

Das NEC IR Protokoll, welches meiner Stichprobe nach die meisten aktuellen Geräte, zumindest der "nicht-premium-Klasse" verwenden (ich kann mir gut vorstellen, daß SONY z.B. etwas eigenes verwendet, nur weil sie es können ), hat kein togglebit weil es einfach einmal das Kommando schickt und danach nur noch in kurzen Abständen "Wiederholung, Wiederholung, Wiederholung" signalisiert. Das hat den Vorteil, daß sogar Logitech es wahrscheinlich schafft das Protokoll zu implementieren, aber halt den Nachteil daß wenn das initiale Telegramm verloren geht, der Tastendruck nicht mehr dekodiert werden kann.

Wenn das bei den 4k kisten so ähnlich ist, könnte ich mir gut vorstellen daß das Umstellen des Fernbedienungstyps halt auch dem Frontprozessor mitgeteilt wird. Der kann trotzdem dumm wie ein Stück Brot sein, alles was er sich merken muss ist ein 32bit-wort mit dem Fernbedienungscode für's Aufwachen.

Bei der VU+ konnte ich meine ausgelesenen IR Codes nicht mit der Logitech FB aufzeichnen da das Tooglebit irgendwie nicht erkannt wurde.


Aber die LIRC Befehle auszulesen ist auch sehr sehr tricki und funktioniert nicht immer (meist gar nicht).

Aber die VU+ Boxen interessieren mich eh nicht mehr da da vieles nicht funktioniert, die werde ich verkaufen.

Ich habe allerdings das Gefühl das ich mit der Axsas genauso angeschissen bin. (Keine Audioausgabe bei HDMI per AC-3)

[seife]

Bei der VU+ konnte ich meine ausgelesenen IR Codes nicht mit der Logitech FB aufzeichnen da das Tooglebit irgendwie nicht erkannt wurde.

Aber die LIRC Befehle auszulesen ist auch sehr sehr tricki und funktioniert nicht immer (meist gar nicht).

Daß die Logitech ein wahrscheinlich über 20 Jahre altes Standard-Protokoll nicht kann sagt mehr über die Logitech aus als über die VU+ Fernbedienung

Irrecord ist tatsächlich regelmäßig etwas tricky, es hängt aber auch von der benutzten Hardware ab. Mit dem IR-Treiber im SPARK-Kernel funktioniert es ziemlich gut, aber meistens benutze ich einen arduino oder ähnliches mit IRMP (oder meinen alten IRMP-port in der libstb-hal für das SPARK-lirc device), weil meiner Erfahrung nach die Protokollerkennung im IRMP wesentlich besser ist als im LIRC. Die Codes die dabei rauskommen kann ich dann entweder in meinen OneForAll Fernbedienungen nutzen, oder per LIRC oder Tasmota versenden oder auswerten.

Die Protokollerkennung der OneForAll ist auch ganz OK, aber es ist halt umständlicher eine ganze Fernbedienung mit der OFA "anzulernen", dann auszulesen und dann die paar Befehle die doch fehlerkannt wurden (und deswegen nur als "Samples" in der Fernbedienung und nicht als Protokoll/Adresse/Code-Kombi gespeichert) nochmal neu zu machen. Darum das einlesen entweder mit Mikrocontroller oder sparkbox mit IRMP.

Edit: hab grad mal in dein axas lirc file geschaut -- das ist ja NEC protokoll (Genauer: NEC-Enhanced weil es eine 16-bit statt einer 8-Bit Adresse hat ) Das einzige was mir an deinem File seltsam vorkommt ist das fehlende

Code: Alles auswählen

  repeat       9000  2250

Aber das kann vom einlesen kommen. Ansonsten ist das eine stinknormale NEC-Protokoll Fernbedienung mit der Adresse 0x40B3

[Gorcon]

Edit: hab grad mal in dein axas lirc file geschaut -- das ist ja NEC protokoll (Genauer: NEC-Enhanced weil es eine 16-bit statt einer 8-Bit Adresse hat ) Das einzige was mir an deinem File seltsam vorkommt ist das fehlende

Code: Alles auswählen

  repeat       9000  2250

Aber das kann vom einlesen kommen. Ansonsten ist das eine stinknormale NEC-Protokoll Fernbedienung mit der Adresse 0x40B3

Ich muss das nochmal hervor kramen:
einen Eintrag für repeat habe ich im LIRC so noch nicht gefunden.
Was mir aber heute aufgefallen ist das der Code der Original FB nur einmal kurz gesendet wird und dann wohl ein leerer Code gesendet wird. Mit IRGraph sieht man den Code also nur ganz kurz und dann bleibt nur noch ein kurzer Impuls stehen.

Bei den von mir generierten LIRC bleibt der Code stehen. (er ist aber sonst vollkommen identisch).
Bei der Ausgabe über mein USB Infrared Toy V2 gabs da kein Problem, jedoch scheint da der SMD Treiber defekt zu sein und ich muss die IR Befehle per App ausgeben. Die werden jedoch nicht vom Receiver erkannt.

[Don de Deckelwech]

Hi,
hmm, so wie ich übers WE gelesen habe, sendet das NEC-Protokoll als Hinweis, dass die Taste dauerhaft gedrückt gehalten wird, ein kurzes Signal, also gerade nicht immer wieder das eigentliche Signal. Vllt meinst du das ja.

Ciao,
DdD.

[Gorcon]

Das ist mir schon klar, nur habe ich den Repeat Ausdruck noch in keiner Lirc conf gesehen.
Ich weiß jetzt nicht ob der da überhaupt vorgesehen ist. Beim einlesen wird er auch nicht erzeugt.

[seife]

Beispiel für eine NEC Fernbedienung in der lirc.conf:

Code: Alles auswählen

begin remote

  name  rc13(PinguluxPlus)
  bits           16
  flags SPACE_ENC|CONST_LENGTH
  eps            30
  aeps          100

  header       9000  4500
  one           560  1690
  zero          560   560
  ptrail        560
  repeat       9000  2250
  pre_data_bits   16
  pre_data       0xAA55
  gap          107500
  toggle_bit_mask 0x0

      begin codes
          KEY_POWER                 0x7887
          KEY_MODE                  0xF00F    # V.FORMAT

[Gorcon]

Ja exakt wie meine auch.
Nur das repeat nicht drin ist da das beim Einlesen nicht abgefragt wird. (Warum auch immer)
Und wenn ich die Daten in den Lircconverter für RCoid eingebe gibts den Wert auch nicht.