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

Hallo,

VERKAUFT

Grüße,

Martin

Bei mir wird die libusb nicht gefunden, um das gleiche Problem ging es bereits in einem früheren Post:
yaUsbIR V3 LIRC USB IR Empfänger/Sender/Einschalter

Zitat von uwe67

hm ja scheinbar fehlt noch was, habe aber libusb-1.0-0-dev installiert, was fehlt?:
Ich benutze zur Zeit die libusbx-1.0.x von http://libusbx.org/ , libusb-1.0-0 muss aber auch funktionieren.

Dein Linker linkt es warscheinlich noch mit einer alten libusb-0.1, dort gibt es zum Beispiel nicht die API "libusb_release_interface".
Zitat von »grooverider«
/home/jarvis/Documents/own.projects/lirc-0.9.0/daemons/hw_ya_usbir.c:84: undefined reference to `libusb_release_interface'

Wie mache ich denn den Verweis, dass richtig verlinkt wird?

Grüße
Fux

Wenn das ganze für einen yaVDR bzw. ein Ubuntu 12.04 oder 14.04 ist, kannst du einfach mein lircd-Paket nutzen (siehe erstes Post dieses Threads bzw. https://launchpad.net/~yavdr/+archive/unstable-main/+packages?field.name_filter=lirc&field.status_filter=published&field.series_filter=). Wenn nicht schau in die Datei debian/rules des Quellpakets bzw. hier: yaUsbIR V3 LIRC USB IR Empfänger/Sender/Einschalter

Danke, der Tipp mit (rauswerfen?) der Lib hat funktioniert und lirc kompiliert jetzt ohne Beschwerden.

Dann habe ich noch eine weitere Frage: Kann ich an die Ausgänge, mit Vorwiderstand natürlich, direkt Standard-LEDs mit 20mA Strom anschließen?

Hallo Uwe,
weil ich eben in Deiner Signatur "yaUsbIR V3.5" gelesen habe: kommt da demnächst hardwaretechnisch was neues oder bezieht sich die Revision auf die Software?

Grüße
Fux

Zitat von uwe67

- USB Remote WakeUp (PC über USB aufwachen lassen wenn der PC USB Anschluss dies unterstützt)

Geht das nur in S3 (Suspend to RAM), oder auch in S5 (PowerOff)?

LG
Jasmin

Hi

kann man auch so einen stecker direkt drauf löten? Dann könnte man den direkt in einen usb port stecken .. habe ein m350 gehäuse und da sind an der front usb ports versteckt

USB-Stecker
http://www.reichelt.de/USB-AGF/3/index.html?&ACTION=3&LA=446&ARTICLE=52008&artnr=USB+AGF&SEARCH=usb+stecker

Gehäuse
http://www.amazon.de/mini-ITX-…hwarz-black/dp/B004LUJ31C

vg mentox

Mit einer gehörigen Portion Glück könnte das klappen. Die Pins dürfen nämlich nicht spiegelverkehrt liegen, denn dann passt dein SMD-Stecker nicht auf das Layout. Die Laschen, die durch die Platine gehören, müsstest du nach die Seite wegbiegen und dann (ggf. nach Entfernen des Lötstopplacks) mit auflöten. Die Belastung für die Leiterbahnen wäre dennoch enorm weil die Fläche, über die Kräfte aufgenommen werden, sehr klein ist.

Einfacher und besser wäre wohl du lässt dir die "externe Variante" kommen und steckst sowas dazwischen:

http://www.amazon.de/dp/B0027BUYYW/

Die Mini-USB-Buchse ist an 4 Stellen über eine relativ große Fläche gehalten. Wäre also eine solidere Lösung.

Ist es denn möglich ohne "Spezialhardware" die Firmware selber zu aktualisieren?

Ich kenne jetzt zwar die Hardware nicht genau, aber wenn dort ein Bootloader vorhanden ist, kannst du per USB-TTL Wander (3€ aus Ebay oder altes Nokia Datenkabel), die Firmware aktualisieren

Jetzt muss ich doch mal nachfragen, weil ich es auch nach mehreren Versuchen nicht hinbekomme. Kann yaUsbIR auch RC-6?

Ich habe sowohl mit dem UDP-Daemon als auch mit dem Patch gegen LIRC (alte Version. Die neue kompiliert bei mir nicht) getestet und er lernt RC-6 immer "RAW" an und findet dann keine Toogle-Bitmaske.

So langsam gebe ich das auf. RC-5 dagegen scheint bestens zu funktionieren.

Falls relevant wegen Firmware-Version: Ich habe die Platine am 11. August 2013 gekauft.

Ich habe keinerlei Probleme mit einem RC6 MCE Protokoll an meinen yaUsbIR V1 und V3.

Welche Fernbedienung bzw. was für ein RC6-Protokoll ist das genau?
Kannst du mal eine mode2-Ausgabe für ein paar Tasten posten?

Hier zwei "mode2"-Ausgaben. Ich hoffe auf meiner OneForAll den Code für die XBOX360 gefunden zu haben und die sollte ja RC-6 sein. Ich habe aber auch die Fernbedienung vom Samsung-TV getestet und damit wird auch Murks erkannt.

[root@vdr ~]# mode2 -H ya_usbir
mode2: yaUsbIr: Initializing yaUsbIr
mode2: yaUsbIr: device: vid=10C4, pic=876C, with 1 interface
mode2:          Manufacturer: UG Development Lab
                Product: yaUsbIR V3:IR transceiver with power switch
                hid interface (generic)
space 425971
pulse 8983
space 4420
pulse 585
space 533
pulse 585
space 533
pulse 546
space 559
pulse 585
space 533
pulse 585
space 533
pulse 585
space 533
pulse 572
space 533
pulse 572
space 546
pulse 598
space 1638
pulse 585
space 1638
pulse 572
space 1664
pulse 585
space 1638
pulse 559
space 1677
pulse 585
space 1651
pulse 585
space 1638
pulse 598
space 1638
pulse 585
space 520
pulse 585
space 1638
pulse 598
space 1625
pulse 585
space 1638
pulse 598
space 520
pulse 598
space 520
pulse 559
space 1664
pulse 585
space 520
pulse 585
space 1651
pulse 585
space 520
pulse 598
space 520
pulse 559
space 559
pulse 585
space 1651
pulse 585
space 1638
pulse 585
space 533
pulse 585
space 1638
pulse 585

[root@vdr ~]# mode2 -H ya_usbir
mode2: yaUsbIr: Initializing yaUsbIr
mode2: yaUsbIr: device: vid=10C4, pic=876C, with 1 interface
mode2:          Manufacturer: UG Development Lab
                Product: yaUsbIR V3:IR transceiver with power switch
                hid interface (generic)
space 425971
pulse 8970
space 4407
pulse 585
space 533
pulse 585
space 520
pulse 585
space 533
pulse 585
space 520
pulse 585
space 533
pulse 585
space 533
pulse 585
space 520
pulse 598
space 520
pulse 585
space 1638
pulse 598
space 1638
pulse 585
space 1638
pulse 598
space 1638
pulse 598
space 1638
pulse 598
space 1638
pulse 598
space 1638
pulse 585
space 1651
pulse 585
space 520
pulse 598
space 1638
pulse 585
space 520
pulse 598
space 1638
pulse 585
space 533
pulse 585
space 520
pulse 598
space 1638
pulse 585
space 520
pulse 598
space 1638
pulse 585
space 533
pulse 585
space 1638
pulse 598
space 520
pulse 585
space 1651
pulse 585
space 1651
pulse 585
space 533
pulse 585
space 1651
pulse 585

[root@vdr ~]# mode2 -H ya_usbir
mode2: yaUsbIr: Initializing yaUsbIr
mode2: yaUsbIr: device: vid=10C4, pic=876C, with 1 interface
mode2:          Manufacturer: UG Development Lab
                Product: yaUsbIR V3:IR transceiver with power switch
                hid interface (generic)
space 425971
pulse 4511
space 4485
pulse 598
space 1664
pulse 585
space 1664
pulse 572
space 1690
pulse 559
space 559
pulse 598
space 533
pulse 598
space 533
pulse 598
space 533
pulse 637
space 494
pulse 585
space 1664
pulse 598
space 1651
pulse 572
space 1690
pulse 559
space 572
pulse 572
space 559
pulse 559
space 559
pulse 598
space 533
pulse 598
space 533
pulse 598
space 533
pulse 598
space 533
pulse 585
space 1664
pulse 572
space 559
pulse 598
space 533
pulse 598
space 533
pulse 585
space 533
pulse 572
space 559
pulse 598
space 1664
pulse 585
space 1664
pulse 598
space 533
pulse 598
space 1651
pulse 598
space 1664
pulse 585
space 1664
pulse 585
space 1664
pulse 598
space 1664
pulse 559

Fernbedienung ist eine OneForAll URC 7140 R01

Zitat von Mreimer

Ich habe aber auch die Fernbedienung vom Samsung-TV getestet und damit wird auch Murks erkannt.

Inwiefern? Das SAMSUNG-Protokoll hat kein Toggle-Bit: https://www.mikrocontroller.net/articles/IRMP#SAMSUNG
Für mich sieht das vollständig aus, alle 32-Bit vom Start-Bit bis zu Stop-Bit sind vorhanden: (Start)11100000111000000010000011011111(Stop)

Die Tasten 1 und 2 sehen auch nicht nach RC6 aus ( https://www.mikrocontroller.net/articles/IRMP#RC6_.2B_RC6A ) - schon das Start-Bit passt nicht zu der lircd.conf die ich dafür erwarten würde: http://lircconfig.commandir.com/lircd.conf/?viewremote=337 - ich würde da eher auf NEC42 tippen, das passt von den Zeiten und dem Aufbau. NEC42 hat ebenfalls kein Toggle-Bit sondern eine Wiederholungssequenz bei gedrückt gehaltener Taste: nach 110ms (ab Start-Bit), 9000µs Puls, 2250µs Pause, 560µs Puls
Decodiert bekomme ich für die Puls-Pausensequenzen das:

Taste 1: 
(Start)00000000111111110111001010001101(Stop)
Taste 2: 
(Start)00000000111111110101001010101101(Stop)

Für Arch Linux habe ich das aktuellste PKGBUILD für Lirc so angepasst:

--- /var/abs/extra/lirc/PKGBUILD	2014-04-11 00:06:04.986450060 +0200
+++ PKGBUILD	2014-04-11 16:36:02.559004267 +0200
@@ -11,20 +11,22 @@ arch=('i686' 'x86_64')
 url="http://www.lirc.org/"
 license=('GPL')
 ### NOTICE don't forget to bump version in depends in package_lirc
-makedepends=('help2man' 'linux>=3.14' 'linux<3.15' 'linux-headers>=3.14' 'linux-headers<3.15' 'alsa-lib' 'libx11' 'libftdi-compat' 'libirman' 'python2')
+makedepends=('help2man' 'linux>=3.14' 'linux<3.15' 'linux-headers>=3.14' 'linux-headers<3.15' 'alsa-lib' 'libx11' 'libftdi-compat' 'libirman' 'python2' 'libusb')
 options=('!makeflags' '!strip')
 source=(http://prdownloads.sourceforge.net/${pkgbase}/${pkgbase}-${pkgver}.tar.bz2
+        lirc-0.9.0_ya_usbir_v3.5.diff.tar.gz::"http://www.vdr-portal.de/index.php?page=Attachment&attachmentID=35309"
         lirc_wpc8769l.patch
         lircd-handle-large-config.patch
         lirc_atiusb-kfifo.patch
         kernel-2.6.39.patch
         linux-3.8.patch
         lirc.logrotate
-        lirc.service 
-        lircm.service 
+        lirc.service
+        lircm.service
         irexec.service
         lirc.tmpfiles)
 md5sums=('b232aef26f23fe33ea8305d276637086'
+         '356e29c57cfa7729c023ab0b29aa9503'
          '1cce37e18e3f6f46044abab29016d18f'
          'b70cc9640505205446ec47b7d4779f38'
          '1f8b104a2365d9f93404b143f499059b'
@@ -43,6 +45,7 @@ prepare() {
   patch -Np1 -i "${srcdir}/lirc_atiusb-kfifo.patch"
   patch -Np1 -i "${srcdir}/kernel-2.6.39.patch"
   patch -Np1 -i "${srcdir}/linux-3.8.patch"
+  patch -Np1 -i "${srcdir}/lirc-0.9.0_ya_usbir_v3.5.diff"
 
   # use fixed instead of Courier w/xmode2, should be more prevalent on linux boxen
   sed -i -e 's|char.*font1_name.*Courier.*$|char		font1_name[]="-misc-fixed-*-r-*-*-12-*-*-*-*-*-iso8859-1";|g' tools/xmode2.c
@@ -66,6 +69,9 @@ build() {
   _kernver="$(cat /usr/lib/modules/${_extramodules}/version)"
   cd "${srcdir}/lirc-${pkgver}"
 
+  # Add libusb(x)-1.0 linking
+  export LIBS=-lusb-1.0
+
   PYTHON=python2 ./configure --enable-sandboxed --prefix=/usr \
       --with-driver=all --with-kerneldir=/usr/src/linux-${_kernver}/ \
       --with-moduledir=/usr/lib/modules/${_kernver}/kernel/drivers/misc \

Wenn das für Arch Linux bzw. VDR4Arch ein Problem ist, würde ich mich auch "breitschlagen" lassen, ein verpatchten lirc auszuliefern.
Da lirc sowieso nicht mehr weiterentwickelt wird, ist das kein großer Aufwand.

Ich würde da am ehesten ein dediziertes Lirc-Userspace Paket erstellen (das dann das Paket lirc-utils aus den Arch Linux Repos ersetzt), dann fällt auch die Abhängigkeit zum Kernel weg. Beim ./configure könnte man dann einfach angeben, dass man nur die userspace-Treiber braucht:

--with-driver=userspace

Das lirc-Paket selbst enthält sowieso nur noch ein einziges Kernel-Modul:

$  tree pkg/lirc/
pkg/lirc/
└── usr
    └── lib
        └── modules
            └── extramodules-3.14-ARCH
                └── lirc_wpc8769l.ko.gz

Für alle, die aus welchem Grund auch immer gerne einen unverpatchten LIRC verwenden möchten, habe ich mich mal am Daemon versucht:

https://github.com/M-Reimer/yausbir_lirc/

Diese Version enthält neben den letzten Fixes auch ein einfaches Makefile und für systemd auch ein Service-File.

Alles, was im Patch im Laufe der Zeit gefixt wurde, habe ich in den Daemon rückportiert. Während der "Original-Daemon" zumindest mit RC-6 Probleme hatte habe ich mit der angepassten Version erfolgreich eine RC-6 Fernbedienung anlernen können.

Getestet habe ich mit RC-5 und RC-6. Beide scheinen gut erkannt zu werden.