yaUsbIR V3 LIRC USB IR Empfänger/Sender/Einschalter

  • wie laeuft eigentlich die Synchronisation zwischen child_process() und dem tatsaechlichen Ende des IR-Sendevorganges?
    Ist also sichergestellt, dass wenn er im Code an Stelle

    Code
    1. + read(pipe_tx2main[0], ya_usbir_txbuf, 1);// wait for child process to be ready with it


    ankommt, alle Daten gesendet sind?


    Ich frage deswegen, weil bei irsends mit Mehrfachtasten, z.B.

    Code
    1. irsend --count 7 SEND_ONCE SONY_RM_U304 BTN_DOWN


    der Gap der sich rechnerisch aus obigem Sync-Punkt und der Wartezeit im lircd/send_core (wegen repeat_timer.it_value.tv_usec = remote->min_remaining_gap; ) ergibt schon rein gar nicht mit der Realitaet uebereinstimmt. Es sieht so aus als wenn der child_process() dem ya_usbir_send() schon vor Ende der Sendung die Kontrolle zurueckgibt.


    Oder sind Mehrfachtasten sowieso verboten?


    Ein

    Code
    1. irsend SEND_START SONY_RM_U304 BTN_DOWN


    scheint gar nicht unterstuetzt zu sein. Im Daemon kommt dann:

    Code
    1. Mon Apr 28 18:23:08.845367 buffer too small
    2. Mon Apr 28 18:23:08.846511 yaUsbIr: init_send() failed


    Wieviel Puffer existiert eigentlich auf dem Board? Ein

    Code
    1. irsend --count 7 SEND_ONCE SONY_RM_U304 BTN_DOWN


    wie oben scheint gerade noch zu gehen.


    Bei count==8:

    Code
    1. irsend --count 8 SEND_ONCE SONY_RM_U304 BTN_DOWN


    ist das Sendesignal komplett verstuemmelt. ABer diesmal ohne Fehlermeldung vom Daemon.
    Bei Bedarf kann ich jederzeit Bilder vom Speicheroszi nachliefern.
    Falls Obiges eigentlich haette funktionieren sollen:-)


    - sparkie

  • Bei Bedarf kann ich jederzeit Bilder vom Speicheroszi nachliefern.

    Nur zu - wenn möglich mit dem IR-Signal der Original-FB für wiederholte Tastendrücke zum Vergleich - dann könnte man schon mal sehen was da genau "verstümmelt" wird und wie lang die IR-Codes sind.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • also ich sollte vielleicht noch hinzufuegen es geht hier nicht um Einfach-Tastendruck per irsend. Mit dem Workaround 'LIRCD_EXACT_GAP_THRESHOLD 200000' wird ja jetzt der 'gap xxx' fuer 'min_repeat' richtig ausgewertet. Auch ansonsten ist das SIgnal verglichen mit der Originalfernbedienung praktisch identisch.


    Es geht hier ausschliesslich um die Mehrfachtasten per 'irsend --count xxx' was ab bestimmtem count nicht mehr funktioniert.
    Der 'irsend SEND_START xxx' geht generell nicht (siehe Daemon Fehlermeldung oben). Da brauche ich auch keine Bilder beilegen:-)


    Darum wollte ich, bevor ich hier weiter Zeit investiere, erst man checken ob Mehrfachtasten mit yausbir ueberhaupt unterstuetzt werden. Bilder werde ich morgen nachliefern.


    - sparkie

  • Darum wollte ich, bevor ich hier weiter Zeit investiere, erst man checken ob Mehrfachtasten mit yausbir ueberhaupt unterstuetzt werden.

    Mit RC-5 und RC-6 hatte ich das vor ein paar Monaten (war noch nicht der aktuelle Patch-Stand) ausprobiert und beim endlosen Senden mit SEND_START keine "buffer too small" Meldungen. IIRC hat auch das wiederholte Senden von Tastencodes geklappt - aber diese IR-Protokolle haben eine andere (vermutlich kleinere) Bitlänge als deine Sony-Fernbedienung und ich bin bei der Anzahl der Wiederholungen bei irsend --count n SEND_ONCE IIRC nicht so hoch gegangen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • wie versprochen ein paar Bildchen.


    API: libusb-1.0
    lirc-basis: lirc-0.9.0~pre1 (debian V7.4)
    patch: lirc-0.9.0_ya_usbir_v3.5.diff.tar.gz
    hardware: yaUsbIR V3
    conf:



    Original-FB kurzer Tastendruck:


    das Gleiche mit yausbir sieht ok aus (insbes. wenn man den Signalverlauf hochaufgeloest vergleicht). Erzeugt mit

    Code
    1. irsend SEND_ONCE SONY_RM_U304 BTN_DOWN


    liefert:


    Soweit so gut. Die Fehler passieren bei Mehrfach-Tastendruck:


    wenn ich auf der Original-FB die BTN_DOWN so kurz als moeglich druecke, so dass aber genau 1 zusaetzlicher Tastendruck generiert wird bekomme ich:


    wenn ich das mit yausbir nachbilden will, geht das nicht:

    Code
    1. irsend --count 2 SEND_ONCE SONY_RM_U304 BTN_DOWN


    liefert:


    hier wird irgendwas vermanscht. Zudem versucht er nicht 1 Signalfolge fuer BTN_DOIWN dranzuhaengen sondern 2 oder vielleicht 3?


    die vermanschte Stelle sieht hoeher aufgeloest dann so aus:

    Hier kann man sehen, dass evtl. der naechste Tastendruck ohne jedes Gap einfach drangehaengt wird. ABer warum gleich 2 statt 1?


    Wenn ich versuche einen count > 9 zu setzen, um z.B. das Volume ganz runterzudrehen wird das mit Fehler abgebrochen:

    Code
    1. irsend --count 10 SEND_ONCE SONY_RM_U304 BTN_DOWN


    gibt Fehlermeldung:


    ein Befehl wie

    Code
    1. irsend SEND_START SONY_RM_U304 BTN_DOWN


    geht leider auch nicht. Auch hier wieder die Fehlermeldung "buffer too small" wie vor.
    Ausserdem wird dann genau nur 1 einziger Tastendruck generiert statt eine endlose Folge (bis zum STOP). IR-Sendepattern dann aehnlich dem allerersten Bild.


    - sparkie

  • Hallo zusammen,


    es gibt seit langem wieder eine neue lirc Version: 0.9.1
    Leider läuft der Patch aus dem ersten Post nun nicht mehr, oder ist er etwa in 0.9.1 enthalten?
    Auf jeden Fall gibt es einen neuen Maintainer und es könnte somit der Patch (falls noch nicht in 0.9.1) endlich in die offizielle Version einfließen :-).


    Viele Grüße
    Fux

    Hardware: Asus M3N78-EM µATX GF 8300 | AMD Sempron 140 | Display VFD USB MDM166A | DVB-S2 TT-3600 USB | RAM 1 GB | WD20EARS 2 TB
    Software: yaVDR 0.5

  • Ich hab nen Problem mit meinem yausbir V3 Empfänger (Anfang Februar gekauft). Es kommt immer wieder zu kurzen Aussetzern, was da drin mündet, dass der repeat Zähler neu zu zählen anfängt und somit der VDR ein loslassen und erneutes Drücken der Taste erkennt. Das sorgt dann für ein recht unschönes Ruckeln beim bewegen des Cursers durch's VDR Menü.
    Das Problem tritt mit meiner RC5 Fernbedienung als auch mit ner RC6 Fernbedienung gleichermaßen auf. Mein alter igorplugusb Empfänger zeigt bei der RC5 Fernbedinung nicht dieses Verhalten. Hier mal die irw Ausgabe bei durchgängig gedrückter Taste:


    EDIT:
    Ich musste gerade Feststellen, dass das Problem scheinbar nur im Zusammenspiel mit lircd2uinput auftritt. Beim igotplugusb Reciver Tritt es aber dennoch nicht auf.


    Claus



    PS.: Gibt es nun eigentlich die Möglichkeit eines Firmware upgrades? Und ist dafür besondere Hardware erforderlich?

    MLD 5.4 mit vdr 2.4.1 - lirc yaUSBir - Octopus NET S2 - SCR - XFX GeForce 9300 mit Intel E3200 - 2GB RAM - WD Green 12TB HDD - SanDisk 64GB SSD - Lian Li PC-C37B - Samsung LE40A559
    MLD 5.4 mit vdr 2.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.4 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT

    The post was edited 1 time, last by clausmuus ().

  • Hi Fux,


    wenn ich mich richtig erinnere scheinen nahezu alle Kernel basierten Treiber aus dem aktuellem Lirc Sourcen raus geflogen zu sein. Vermutlich weil die inzwischen im Kernel enthalten sind.
    Dadurch passt der ya_usbir Patch aber nicht mehr zu den Sourcen.
    Ich verwende deshalb die Sourcen vom 9.5.2014, da das der letzte Stand ist, zu dem der Patch noch passt.


    Claus

    MLD 5.4 mit vdr 2.4.1 - lirc yaUSBir - Octopus NET S2 - SCR - XFX GeForce 9300 mit Intel E3200 - 2GB RAM - WD Green 12TB HDD - SanDisk 64GB SSD - Lian Li PC-C37B - Samsung LE40A559
    MLD 5.4 mit vdr 2.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.4 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT

  • Moment mal. An Lirc wird wieder weiterentwickelt?


    Ja, es gibt eine recht junge Version 0.9.1 und im nächsten Release werden wohl lirc_serial und ein paar andere alte Treiber rausfliegen: http://sourceforge.net/p/lirc/git/commit_browser

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Das Paket wurde bei Arch Linux noch nicht aktualisiert...


    Aber am 03.07.2014 als outdated geflaggt.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ich hab noch ein wenig weiter mit dem Problem, mit den Aussetzern bei gedrückter Taste, herum experimentiert.
    Der ya_usbir sendet anders als zuvor angenommen einen durchgängigen Repeat Zähler. Erst das lircd2uinput baut da das zurücksetzen des Zählers ein. Allerdings macht der ya_usbir Reciver an genau diesen Stellen eine kurze Pause. Also selbst wenn ich das lircd2uinput weg lasse und den VDR direkt mit der Ausgabe von ya_usbir verbinde läuft der Cursor nicht gleichmäßig im VDR Menü.
    Der Fehler tritt auch dann auf, wen ich neben lircd nur noch irw laufen lasse und ansonsten keine Weiteren Dienste oder Programme. Getestet habe ich sowohl am PC als auch am RPI. Immer mit dem Selben Ergebnis.
    Auch ein Ändern der Priorität des lircd Prozesses ändert nichts an dem Verhalten.


    Claus

    MLD 5.4 mit vdr 2.4.1 - lirc yaUSBir - Octopus NET S2 - SCR - XFX GeForce 9300 mit Intel E3200 - 2GB RAM - WD Green 12TB HDD - SanDisk 64GB SSD - Lian Li PC-C37B - Samsung LE40A559
    MLD 5.4 mit vdr 2.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.4 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT

  • Der ya_usbir sendet anders als zuvor angenommen einen durchgängigen Repeat Zähler.

    Der yaUsbIR reicht eigentlich nur die Puls-/Pausensequenzen weiter, decodieren muss Lircd - der generiert auch den Repeat-Zähler

    Erst das lircd2uinput baut da das zurücksetzen des Zählers ein

    Jein, das macht dann eventlircd, weil lircd2uinput signalisiert, dass die Taste zwischendrin losgelassen wurde (wenn innerhalb von 200 ms nichts mehr kommt). Der Timeout ist notwendig, weil man sich bei uinput entscheiden muss, ob man die Taste loslassen oder noch einmal wiederholt drücken will (das ist mit eventlircd nicht so kritisch, aber wenn man z.B. direkt die Ausgaben an einen X-Server machen lässt, bekommt man durch dessen eingebaute Tastenwiederholung sonst eine Flut unerwünschter Tastendrücke). Der Timeout dafür ist übrigens konfigurierbar - versuch es mal mit 250 bis 400 ms, dann sollte er weiterhin Wiederholungssignale generieren, auch wenn mal zwischendrin ein Tastendruck ausfällt:

    Code
    1. -t TIMEOUT, --timeout=TIMEOUT
    2. release key after x ms no following key is received
    3. (default = 200 ms)

    Der Effekt scheint auch von der verwendeten Fernbedienung abzuhängen - mit einer meiner Hauppauge A415 kann ich das mit lircd auch beobachten, mit dem gleichen IR-Protkoll an einer Harmony 300 sind die Pausen zumindest nicht offensichtlich. Interessanterweise tritt dieser Effekt mit einem selbst geschriebenen Python-Programm, das die Daten vom yaUsbIR direkt von der USB-Schnittstelle auslesen und decodieren kann nicht auf - damit bekomme ich einwandfreie Tastendruckwiederholungen über hunderte Events hinweg.


    In der Ausgabe von mode2 unter Ubuntu 14.04 sieht es bei mir dann so aus, dass er da mitunter Pulse und Pausen verschluckt (vermutlich jeweils am Ende der 62 Bytes Nutzdaten), die bei meinem Python-Programm aber alle sauber ankommen - dann dürfte der Wurm am ehesten im Lirc-(Treiber) stecken.


    Ich habe jetzt jetzt mal in Zeile 269 der daemon/hw_ya_usbir.c den Timeout für die Leseoperation von 25 auf 10 ms verringert - im Patch sieht das so aus:


    Damit scheinen mode2 und lircd bei mir am Laptop keine Pulse bzw. Pausen mehr zu verschlucken. Warum der Timeout so kritisch ist und es schlechter wird, wenn man ihn hochsetzt, ist mir allerdings noch nicht ganz klar...

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hi,


    danke für die Tipps. Ich werde das nachher mal ausprobieren.


    Claus

    MLD 5.4 mit vdr 2.4.1 - lirc yaUSBir - Octopus NET S2 - SCR - XFX GeForce 9300 mit Intel E3200 - 2GB RAM - WD Green 12TB HDD - SanDisk 64GB SSD - Lian Li PC-C37B - Samsung LE40A559
    MLD 5.4 mit vdr 2.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.4 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT

  • So, ich hab das nun getestet. Erst einmal aber nur auf dem RPI.
    Das setzen der --timeout Option hilft gegen den Reset des counters. Der Patch hat aber leider keine Auswirkung.
    Ich werde das also Morgen auch noch am PC testen.


    Claus

    MLD 5.4 mit vdr 2.4.1 - lirc yaUSBir - Octopus NET S2 - SCR - XFX GeForce 9300 mit Intel E3200 - 2GB RAM - WD Green 12TB HDD - SanDisk 64GB SSD - Lian Li PC-C37B - Samsung LE40A559
    MLD 5.4 mit vdr 2.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.4 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT

  • Auch beim PC hilft der Patch leider nicht.
    Hast Du noch ne Idee, wo ich ansetzen kann, um das Problem zu beheben. Das setzten des größeren timeouts hilft ja nur marginal. Stottern tut's weiterhin (wenn auch ein bischen weniger), weil ja immer wieder tasten Events verschluckt werden.


    Claus



    PS.: Lässt sich Dein pyYaUsbIR Script als lircd Ersatz verwenden? Und würde das mit eventlircd zusammenarbeiten? Wie muss das gestartet werden?

    MLD 5.4 mit vdr 2.4.1 - lirc yaUSBir - Octopus NET S2 - SCR - XFX GeForce 9300 mit Intel E3200 - 2GB RAM - WD Green 12TB HDD - SanDisk 64GB SSD - Lian Li PC-C37B - Samsung LE40A559
    MLD 5.4 mit vdr 2.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.4 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT

  • Auch beim PC hilft der Patch leider nicht.

    Ich konnte es gestern nur auf einem einzigen Rechner ausprobieren, leider weiß ich zu wenig über USB und C um da auf Fehlersuche zu gehen - vielleicht hat uwe67 ja eine Idee dazu.

    PS.: Lässt sich Dein pyYaUsbIR Script als lircd Ersatz verwenden? Und würde das mit eventlircd zusammenarbeiten? Wie muss das gestartet werden?

    Ja, man kann es schon dafür nutzen - lircd2uinput lässt man dann einfach von dem vom Programm erzeugten Lirc-Sockel lesen, dann bekommt eventlircd die Tastendrücke (eine direkte Ausgabe über uinput wäre prinzipiell auch möglich, mal sehen wann ich dazu komme) - ich habe mal einen Branch mit den nötigen Änderungen erstellt: https://github.com/seahawk1986/pyYaUsbIR/tree/receiver
    Benötigt werden unter Ubuntu 14.04 noch python3, python3-gi sowie die Module https://github.com/walac/pyusb (benötigt libusb-1.0-0-dev) und https://pypi.python.org/pypi/bitarray/0.8.1

    Code
    1. $ python3 yaUsbir.py -h
    2. Usage: yaUsbir.py [options]
    3. Options:
    4. -h, --help show this help message and exit
    5. -s SOCKET, --socket=SOCKET
    6. -k KEYMAP, --keymap=KEYMAP
    7. -p "RC-5 RC-6 NEC SAMSUNG", --protocol="RC-5 RC-6 NEC SAMSUNG"

    In der Keymap (ein Beispiel ist mit im Git: https://github.com/seahawk1986…/blob/receiver/keymap.txt) legt man die Tastencodes nach folgendem Schema ab:

    Code
    1. [<protocol>_<address>]
    2. <command> KEY_NAME

    Wenn dir irw also z.B. das bei einer noch unbekannten Taste liefert:

    Code
    1. 40d 00 None RC-6_15

    dann kommt der Tastencode "40d" in den Abschnitt [RC-6_15]:

    An Protokollen habe ich bislang RC-5, RC6A-32 (was meine Harmony FB als MCE-1039 Profil bezeichnen), NEC und ein SAMSUNG-Protokoll umgesetzt, wer mehr will, muss es sich selber schreiben, mir fehlt da aktuell die Zeit dazu...


    Der Daemon funktioniert hier auch auf meinem Raspberry Pi (ich habe es jetzt nur kurz unter Arch Linux ARM ohne eventlircd ausprobiert).

    Code
    1. git clone https://github.com/seahawk1986/pyYaUsbIR.git
    2. cd pyYaUsbIR
    3. git checkout receiver
    4. sudo python3 -s /var/run/lircd/lircd.ya -k keymap.txt -p RC-5

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hi,


    ich hab Dein Tool nun endlich ausprobiert. Leider bekomme ich beim Tastendruck diese Fehlermeldung:


    Hast Du nen Vorschlag um das zu fixen?


    Claus

    MLD 5.4 mit vdr 2.4.1 - lirc yaUSBir - Octopus NET S2 - SCR - XFX GeForce 9300 mit Intel E3200 - 2GB RAM - WD Green 12TB HDD - SanDisk 64GB SSD - Lian Li PC-C37B - Samsung LE40A559
    MLD 5.4 mit vdr 2.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.4 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT