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

+       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.

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

irsend SEND_START SONY_RM_U304 BTN_DOWN

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

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

Wieviel Puffer existiert eigentlich auf dem Board? Ein

irsend --count 7 SEND_ONCE SONY_RM_U304 BTN_DOWN

wie oben scheint gerade noch zu gehen.

Bei count==8:

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

Zitat von 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.

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

Zitat von 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.

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:

/etc/lirc/lircd.conf:
begin remote
  name  SONY_RM_U304
  bits               12
  flags SPACE_ENC|CONST_LENGTH
  eps                30
  aeps              100


  header           2403   520
  one              1250   518
  zero              640   518
  gap             44000
  min_repeat          2
  toggle_bit_mask   0x0
  frequency       38000
      begin codes
          BTN_AUX                  0xB81
          BTN_DVD                  0xBE1
          BTN_CD                   0xA41
          BTN_UP                   0x481
          BTN_DOWN                 0xC81
          VIDEO3                   0x421
          TV/SAT                   0x561
          MD/TAPE                  0x961
          DAT/TAPE                 0xC41
          TUNER                    0x841
          PHONO                    0x041
          MULTI_CH                 0x4E1
          MPX/DUAL                 0xE81
          ANALOG_DIRECT            0x921
          MUTING                   0x281
          ON_SCREEN                0xCA1
          SYSTEM_STANDBY           0xA81
      end codes
end remote

Original-FB kurzer Tastendruck:

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

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:

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:

irsend --count 10 SEND_ONCE SONY_RM_U304 BTN_DOWN

gibt Fehlermeldung:

lircd: accepted new client on /var/run/lirc/lircd
lircd: yaUsbIr: Initializing yaUsbIr (libusb-1.0 API)
lircd: yaUsbIr: idVendor=10C4, idProduct=876C
                Manufacturer: UG Development Lab
                Product: yaUsbIR V3:IR transceiver with power switch
                hid interface (generic)
                SerialNumber: 0003
lircd: yaUsbIr: entering send()
lircd: yaUsbIr: set carrier frequency = 38000 Hz
lircd: yaUsbIr: entering send()
lircd: buffer too small
lircd: yaUsbIr: init_send() failed
lircd: removed client
lircd: yaUsbIr: close device

ein Befehl wie

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 :-).

/usr/src/Lirc/yaUsbIr3/lirc-0.9.1$ patch -p1 < lirc-0.9.0_ya_usbir_v3.5.diff 
patching file configure.ac
Hunk #1 FAILED at 312.
Hunk #2 succeeded at 458 (offset 12 lines).
Hunk #3 succeeded at 479 (offset 12 lines).
Hunk #4 FAILED at 684.
Hunk #5 succeeded at 1421 (offset 12 lines).
Hunk #6 succeeded at 1462 with fuzz 2 (offset 12 lines).
Hunk #7 FAILED at 1510.
Hunk #8 succeeded at 1694 with fuzz 1 (offset 14 lines).
3 out of 8 hunks FAILED -- saving rejects to file configure.ac.rej
patching file daemons/hw-types.c
patching file daemons/hw_ya_usbir.c
patching file daemons/Makefile.am
patching file daemons/Makefile.in
Hunk #1 succeeded at 436 (offset 117 lines).
Hunk #2 succeeded at 732 (offset 153 lines).
patching file daemons/transmit.c
Hunk #1 succeeded at 15 (offset -1 lines).
patching file setup.data
Hunk #1 FAILED at 146.
Hunk #2 FAILED at 260.
Hunk #3 FAILED at 331.
3 out of 3 hunks FAILED -- saving rejects to file setup.data.rej
patching file setup-driver.sh
Hunk #1 FAILED at 286.
Hunk #2 FAILED at 327.
2 out of 2 hunks FAILED -- saving rejects to file setup-driver.sh.rej

Viele Grüße
Fux

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:

MLD> irw
6c 0 KEY_DOWN devinput
6c 1 KEY_DOWN devinput
6c 2 KEY_DOWN devinput
6c 3 KEY_DOWN devinput
6c 4 KEY_DOWN devinput
6c 5 KEY_DOWN devinput
6c 6 KEY_DOWN devinput
6c 7 KEY_DOWN devinput
6c 8 KEY_DOWN devinput
6c 0 KEY_DOWN devinput
6c 1 KEY_DOWN devinput
6c 2 KEY_DOWN devinput
6c 3 KEY_DOWN devinput
6c 4 KEY_DOWN devinput
6c 5 KEY_DOWN devinput
6c 6 KEY_DOWN devinput
6c 7 KEY_DOWN devinput
6c 0 KEY_DOWN devinput
6c 1 KEY_DOWN devinput
6c 2 KEY_DOWN devinput
6c 3 KEY_DOWN devinput
6c 4 KEY_DOWN devinput
6c 5 KEY_DOWN devinput
6c 6 KEY_DOWN devinput
6c 0 KEY_DOWN devinput
6c 1 KEY_DOWN devinput
6c 2 KEY_DOWN devinput
6c 3 KEY_DOWN devinput
6c 4 KEY_DOWN devinput
6c 5 KEY_DOWN devinput
6c 6 KEY_DOWN devinput
6c 7 KEY_DOWN devinput
6c 8 KEY_DOWN devinput
6c 0 KEY_DOWN devinput
6c 1 KEY_DOWN devinput
6c 2 KEY_DOWN devinput
6c 3 KEY_DOWN devinput
6c 4 KEY_DOWN devinput
6c 5 KEY_DOWN devinput
6c 6 KEY_DOWN devinput
6c 7 KEY_DOWN devinput
6c 8 KEY_DOWN devinput
6c 9 KEY_DOWN devinput
6c a KEY_DOWN devinput
6c b KEY_DOWN devinput
6c c KEY_DOWN devinput
6c d KEY_DOWN devinput
6c e KEY_DOWN devinput

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?

Der billigste Programmer dürfte der owSilProg sein.

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

Moment mal. An Lirc wird wieder weiterentwickelt?

Zitat von Copperhead

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

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

Ich kümmere mich mal darum...

Zitat von Copperhead

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

Aber am 03.07.2014 als outdated geflaggt.

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

Zitat von clausmuus

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

Zitat von clausmuus

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:

-t TIMEOUT, --timeout=TIMEOUT
                        release key after x ms no following key is received
                        (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:

diff --git a/lirc-0.9.0_ya_usbir_v3.5.diff b/lirc-0.9.0_ya_usbir_v3.5.diff
index 31126af..368dea2 100644
--- a/lirc-0.9.0_ya_usbir_v3.5.diff
+++ b/lirc-0.9.0_ya_usbir_v3.5.diff
@@ -377,7 +377,7 @@ diff -ruN lirc-0.9.0/daemons/hw_ya_usbir.c lirc-0.9.0_ya_usbir_v3.5/daemons/hw_y
 +      uint8_t ya_usbir_rxbuf[64];
 +
 +      if (ya_usbir_dev.handle == NULL) return 0;
-+      num = rawhidrecv(&ya_usbir_dev, ya_usbir_rxbuf, sizeof(ya_usbir_rxbuf), 25);
++      num = rawhidrecv(&ya_usbir_dev, ya_usbir_rxbuf, sizeof(ya_usbir_rxbuf), 10);
 +      if (num < 0) {
 +              logprintf(LOG_ERR,"yaUsbIr: error reading, device went offline");
 +              return 0;

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...

Hi,

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

Claus

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

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?

Zitat von clausmuus

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.

Zitat von clausmuus

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

$ python3 yaUsbir.py -h
Usage: yaUsbir.py [options]


Options:
  -h, --help            show this help message and exit
  -s SOCKET, --socket=SOCKET
  -k KEYMAP, --keymap=KEYMAP
  -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:

[<protocol>_<address>]
<command> KEY_NAME

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

40d 00 None RC-6_15

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

[RC-6_15]
# MCE Profile Harmony
0x400	KEY_0
0x401	KEY_1
0x402	KEY_2
0x403	KEY_3
0x404	KEY_4
0x405	KEY_5
0x406	KEY_6
0x407	KEY_7
0x408	KEY_8
0x409	KEY_9
0x422	KEY_OK
0x40d	KEY_MENU

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).

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

Hi,

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

MLD> python /usr/lib/yausbir/yaUsbir.py -s /var/run/lirc/lircd-yausbir -k /etc/yausbir.keymap -p RC-6
('enabled protocols:', ['RC-6'])
reading keymap /etc/yausbir.keymap
created Lirc-Socket /var/run/lirc/lircd-yausbir
Traceback (most recent call last):
  File "/usr/lib/yausbir/yaUsbir.py", line 38, in read_data
    decoder.addEvent(t, duration)
  File "/usr/lib/yausbir/rc6decoder.py", line 39, in addEvent
    self.state(t, duration)
  File "/usr/lib/yausbir/rc6decoder.py", line 129, in midZero
    self.state = self.midToggle
AttributeError: RC6Decoder instance has no attribute 'midToggle'

Hast Du nen Vorschlag um das zu fixen?

Claus