LIRC on Dockstar

Connecting an actual IR transceiver recognized by the kernel...

usb 1-1.1: New USB device found, idVendor=0471, idProduct=060c
usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1.1: Product: BB+ Dongle(e.d)

...I was hoping to get it to work with LIRC:

apt-get update
apt-get install lirc
wget http://lirc.sourceforge.net/remotes/i24/I24 -O /etc/lirc/lircd.conf
/etc/init.d/lirc start
Loading LIRC modules:.
Starting remote control daemon(s) : LIRC :Driver `mceusb' not supported.
Supported drivers:
accent
[...]
usbx
failed!

Regrettably "apt-cache search mceusb" comes up empty.

How could the required driver and lirc_mceusb or lirc_mceusb2 kernel module be added?

You have to build any lirc modules yourself. I built mceusb2 and atiusb on my dockstar using the following commands. The module sources provided by debian are a bit stale, so I also grabbed some updated code from the LIRC source tree.

These notes are several months old. Some of the package names may have changed, however, it should be enough to get you started.

apt-get install \
  lirc-modules-source \
  linux-headers-$(uname -r) \
  linux-source-2.6.32 \
  linux-kbuild-2.6.32 \
  kernel-package \
  module-assistant

m-a update,prepare

cd /usr/src

tar -xjvf lirc-modules.tar.bz2
rm lirc-modules.tar.bz2

cd modules/lirc-modules

rm lirc_dev.c lirc_dev.h kcompat.h lirc.h lirc_mceusb.c lirc_atiusb.c

wget http://lirc.cvs.sourceforge.net/viewvc/lirc/lirc/drivers/lirc_mceusb/lirc_mceusb.c
wget http://lirc.cvs.sourceforge.net/viewvc/lirc/lirc/drivers/lirc_atiusb/lirc_atiusb.c

wget http://lirc.cvs.sourceforge.net/viewvc/lirc/lirc/drivers/lirc_dev/lirc_dev.c
wget http://lirc.cvs.sourceforge.net/viewvc/lirc/lirc/drivers/lirc_dev/lirc_dev.h

wget http://lirc.cvs.sourceforge.net/viewvc/lirc/lirc/drivers/kcompat.h
wget http://lirc.cvs.sourceforge.net/viewvc/lirc/lirc/drivers/lirc.h


mkdir -p drivers/lirc_dev

cd drivers
wget http://lirc.cvs.sourceforge.net/viewvc/lirc/lirc/drivers/kcompat.h
wget http://lirc.cvs.sourceforge.net/viewvc/lirc/lirc/drivers/lirc.h

cd lirc_dev
wget http://lirc.cvs.sourceforge.net/viewvc/lirc/lirc/drivers/lirc_dev/lirc_dev.c
wget http://lirc.cvs.sourceforge.net/viewvc/lirc/lirc/drivers/lirc_dev/lirc_dev.h

dpkg-reconfigure lirc-modules-source

Select atiusb and mceusb

m-a a-i lirc

dpkg -i lirc-modules-2.6.32-5-kirkwood_0.8.3-5+2.6.32-18_armel.deb

(This thread started in http://forum.doozan.com/read.php?2,2471)

Thanks a ton, Jeff, your above installation steps still work like a charm (albeit weighing in at a whopping 227 megabytes).

Only the final package path and file name have to be changed to

dpkg -i /usr/src/lirc-modules-2.6.32-5-kirkwood_0.8.3-5+2.6.32-28_armel.deb

Following that, after setting LOAD_MODULES=true and DRIVER="mceusb" in /etc/lirc/hardware.conf, all is well on as per dmesg:
lirc_dev: IR Remote Control driver registered, major 61
lirc_mceusb: Windows Media Center Edition USB IR Transceiver driver for LIRC 1.90
lirc_mceusb: Daniel Melander <lirc@rajidae.se>, Martin Blatter <martin_a_blatter@yahoo.com>, Dan Conti <dconti@acm.wwu.edu>
lirc_dev: lirc_register_driver: sample_rate: 0
lirc_mceusb[5]: BB+ Dongle(e.d) on usb1:5
usbcore: registered new interface driver lirc_mceusb

However, "/etc/init.d/lirc start" with LOAD_MODULES=true set in /etc/lirc/hardware.conf complains (apparently not knowing a DRIVER="mceusb"):

/etc/init.d/lirc start
Loading LIRC modules:.
Starting remote control daemon(s) : LIRC :Driver `mceusb' not supported.
Supported drivers:
accent
alsa_usb
asusdh
atilibusb
audio_alsa
bte
bw6130
creative
creative_infracd
default
devinput
dsp
dvico
ea65
i2cuser
irlink
irman
livedrive_midi
livedrive_seq
logitech
macmini
mp3anywhere
mplay
mouseremote
mouseremote_ps2
null
pcmak
pinsys
pixelview
samsung
sb0540
silitek
tira
udp
uirt2
uirt2_raw
usb_uirt_raw
usbx
failed!

What do I further have to specify?

BTW, "which irw" responds with /usr/bin/irw but there is no such file.

The error on irw actually refers to the device - it still seems to look for /dev/lirc by default, to which the actual /dev/lirc0 has no reference - but even if I do specify the latter, irw still complains (even with no LIRC running):
irw /dev/lirc0
connect: Connection refused

Figured out that one (as http://www.mythtv.org/wiki/ubuntu_lirc_install mentioned the auto-selection of modules and device won't work):

/etc/lirc/hardware.conf has to have these lines:

# Run "lircd --driver=help" for a list of supported drivers.
DRIVER=""
# If DEVICE is set to /dev/lirc and udev is in use /dev/lirc0 will be
# automatically used instead
DEVICE="/dev/lirc0"
MODULES="lirc_mceusb lirc_dev"

This way it receiving/irw do receive after /etc/init.d/lirc start, albeit while complaining in dmesg:
lirc_dev (lirc_mceusb [0]): userspace uses outdated ioctl please update your lirc installation

I have yet to get to work something like: irsend SEND_ONCE I24 ON
- either all of the Chinese transmitters for the HP MCE USB transceiver dongles (apparently without a built-in transmitter behind their front plates either) actually have nothing but ordinary (visible) red (rather than infrared) LEDs built into them, or there is a timing/modulation problem when sending out IR signals.

While I couldn't get irrecord to recognise more than 1-3 (of the required 160) dots with the above setup, I had been able to transmit using an "LD 271" IR LED soldered to a 3.5mm mono plug (center anode), while no such thing seems to be in the spacious casing of the USB transceiver - and unlike my DIY one, the Chinese IR blaster dongles (including the one that came with the HP device!) do only seem to send visible red instead of IR, holding just one 3mm LED that is unlikely to emit both wavelengths (but I don't have prisms or filters at hand to make sure).

Having rebuilt using "m-a -f a-i lirc", modprobe lirc_dev shows the latter in lsmod used by lirc_mceusb, but apparently doesn't provide a /dev/lirc0 anymore, without anything unusual shown in dmesg.
(lirc_mceusb2 also recognizes the HP "MODEL OVU422000/06" IR transceiver but then causes an Oops).

BTW, shouldn't the DockStar offer a few GPIO pins (maybe even on a header) that could be repurposed nicely for IR (modulated) and RF (base band only, not requiring a softcarrier) remote control I/O ?

I realize I should probably leave both approaches to someone better equipped for and more experienced in building these kinds of things, but the results could easily accomplish the tasks of a http://mediola.com and more, at a much lower price tag.

For the record, the reason for irw not showing any output is that the transceiver specified above goes into saturation by as little ambient visible (non-infrared) light as from one monitor's CCFL backlight in the same room.
It does work in a dark place, otherwise the red LED goes on as soon as the driver is loaded, and stays that way. Not sure whether it has any software-configurable thresholds that lirc-mceusb(2) ought to initialize.

In conjunction with the phenomenon of the blaster LEDs emitting red rather than infrared light (as described in previous posts), the vendor has been informed about apparent problems with manufacturing and/or circuit design, without getting back to me since.

Reliability of irsend transmissions on this hardware has been improved over configurations from http://lirc.org/remotes by re-sampling the respective controls in raw mode as follows (for lirc-0.8.7), but the results (3 retries approx. required for proper reception by the controlled appliances) still suggest there might be a problem with the timing/accuracy on replay (to be confirmed by someone with a scope).
irrecord --disable-namespace --force -d /dev/lirc0 raw_light.conf

The "silver bullet" might be getting the DockStar's spare GPIO pins, if any, to directly drive homebrew transceivers (preferably also one without softcarrier).

Jeff Wrote:
-------------------------------------------------------
> You have to build any lirc modules yourself. I
> built mceusb2 and atiusb on my dockstar using the
> following commands. The module sources provided
> by debian are a bit stale, so I also grabbed some
> updated code from the LIRC source tree.
>
> These notes are several months old. Some of the
> package names may have changed, however, it should
> be enough to get you started.
>
>
> apt-get install \
> lirc-modules-source \
> linux-headers-$(uname -r) \
> linux-source-2.6.32 \
> linux-kbuild-2.6.32 \
> kernel-package \
> module-assistant
>
> m-a update,prepare
>
> cd /usr/src
>
> tar -xjvf lirc-modules.tar.bz2
> rm lirc-modules.tar.bz2
>
> cd modules/lirc-modules
>
> rm lirc_dev.c lirc_dev.h kcompat.h lirc.h
> lirc_mceusb.c lirc_atiusb.c
>
> wget
> http://lirc.cvs.sourceforge.net/viewvc/lirc/lirc/d
> rivers/lirc_mceusb/lirc_mceusb.c
> wget
> http://lirc.cvs.sourceforge.net/viewvc/lirc/lirc/d
> rivers/lirc_atiusb/lirc_atiusb.c
>
> wget
> http://lirc.cvs.sourceforge.net/viewvc/lirc/lirc/d
> rivers/lirc_dev/lirc_dev.c
> wget
> http://lirc.cvs.sourceforge.net/viewvc/lirc/lirc/d
> rivers/lirc_dev/lirc_dev.h
>
> wget
> http://lirc.cvs.sourceforge.net/viewvc/lirc/lirc/d
> rivers/kcompat.h
> wget
> http://lirc.cvs.sourceforge.net/viewvc/lirc/lirc/d
> rivers/lirc.h
>
>
> mkdir -p drivers/lirc_dev
>
> cd drivers
> wget
> http://lirc.cvs.sourceforge.net/viewvc/lirc/lirc/d
> rivers/kcompat.h
> wget
> http://lirc.cvs.sourceforge.net/viewvc/lirc/lirc/d
> rivers/lirc.h
>
> cd lirc_dev
> wget
> http://lirc.cvs.sourceforge.net/viewvc/lirc/lirc/d
> rivers/lirc_dev/lirc_dev.c
> wget
> http://lirc.cvs.sourceforge.net/viewvc/lirc/lirc/d
> rivers/lirc_dev/lirc_dev.h
>
>
>
> dpkg-reconfigure lirc-modules-source
>
> Select atiusb and mceusb
>
>
> m-a a-i lirc
>
> dpkg -i
> lirc-modules-2.6.32-5-kirkwood_0.8.3-5+2.6.32-18_a
> rmel.deb
>


When I try to run this procedure the problem occurs at line:

apt-get ... linux-headers-$(uname -r) ...

because I'm using this special dockstar kernel with LED support and .deb containing header can't be find in official repository.
What is the workaround ?
This same problem occurs when running:

m-a a-i lirc

I've tried to install original header but it didn't helped.

Help ! :)

Since this thread is working on a solution to one of the issue's I currently haven't solved on my Dockstar project, I figure I'll post here too.

I purchased one of the FTDI based USB to IR blaster/receivers for my Dockstar. It has some level of at least "support" in Lirc and the sample rc5 transmit program does flash the LED (can see it from camera on phone). But it won't record and I can't actually tell if it sends properly since I don't have a proper config to use on the cable box I want it for.

If I can't get this working properly, what IR transmitter "for sure" works on the Dockstar? I still have other test's to run to find out if I can create the config on my PC and port it, but the FTDI isn't supported by Winlirc and the version of Mint I'm currently using has the driver improperly rolled into the kernel which also prevents me from following the instructions I have to use the thing. At some point when I have more time, I'll upgrade Mint so that I can do some testing from there.

Thanks,
Dave

Hi,

I suppose that the one of the most popular is:
http://wiki.xbmc.org/index.php?title=Remote_Control_Reviews#Microsoft_Media_Center_Remote_Control

Here is instruction how to install it in Debian:
http://www.mythtv.org/wiki/MCE_Remote#Debian_GNU.2FLinux_4.0

But because I have special kernel I could not fully complete this procedure (it work on Ubuntu fine).

Regards,
Adam.

I've followed all these steps but still get kernel error:

[ 36.840417] lirc_dev: IR Remote Control driver registered, major 61
[ 37.006154]
[ 37.007654] lirc_mceusb2: Philips eHome USB IR Transceiver and Microsoft MCE 2005 Remote Control driver for LIRC $Revision: 1.44 $
[ 37.019510] lirc_mceusb2: Daniel Melander <lirc@rajidae.se>, Martin Blatter <martin_a_blatter@yahoo.com>
[ 37.110775] usb 1-1.3: reset full speed USB device using orion-ehci and address 4
[ 37.221647] lirc_dev: lirc_register_plugin: sample_rate: 0
[ 37.229507] lirc_mceusb2[4]: Philips eHome Infrared Transceiver on usb1:4
[ 37.237015] kernel BUG at /build/buildd-linux-2.6_2.6.32-31-armel-ReZWr3/linux-2.6-2.6.32/debian/build/source_armel_none/arch/arm/mm/dma-mapping.c:547!
[ 37.251219] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[ 37.259398] pgd = c6fb4000
[ 37.262133] [00000000] *pgd=07b8f031, *pte=00000000, *ppte=00000000
[ 37.268454] Internal error: Oops: 817 [#1]
[ 37.272568] last sysfs file: /sys/devices/platform/orion-ehci.0/usb1/1-1/1-1.3/lirc/lirc0/uevent
[ 37.281391] Modules linked in: lirc_mceusb2(+) rfkill lirc_dev sha1_generic mv_cesa(+) aes_generic ext2 mbcache sd_mod crc_t10dif usb_storage scsi_mod ehci_hcd usbcore mvsdio nls_base mv643xx_eth mmc_core libphy inet_lro

Hi,

This issue is solved !
I was compiling lirc_mceusb2 module which might be bit more up to date although is still broken.
The solution was to build ONLY lirc_mceusb and DO NOT build lirc_mceusb2.
From that point on everything worked fine :)
Thnx for all tips above - they helped me a lot !

Regards,
Adam.

Adam Wrote:
-------------------------------------------------------
> I've followed all these steps but still get kernel
> error:
>
> [ 36.840417] lirc_dev: IR Remote Control driver
> registered, major 61
> [ 37.006154]
> [ 37.007654] lirc_mceusb2: Philips eHome USB IR
> Transceiver and Microsoft MCE 2005 Remote Control
> driver for LIRC $Revision: 1.44 $
> [ 37.019510] lirc_mceusb2: Daniel Melander ,
> Martin Blatter
> [ 37.110775] usb 1-1.3: reset full speed USB
> device using orion-ehci and address 4
> [ 37.221647] lirc_dev: lirc_register_plugin:
> sample_rate: 0
> [ 37.229507] lirc_mceusb2[4]: Philips eHome
> Infrared Transceiver on usb1:4
> [ 37.237015] kernel BUG at
> /build/buildd-linux-2.6_2.6.32-31-armel-ReZWr3/lin
> ux-2.6-2.6.32/debian/build/source_armel_none/arch/
> arm/mm/dma-mapping.c:547!
> [ 37.251219] Unable to handle kernel NULL
> pointer dereference at virtual address 00000000
> [ 37.259398] pgd = c6fb4000
> [ 37.262133] [00000000] *pgd=07b8f031,
> *pte=00000000, *ppte=00000000
> [ 37.268454] Internal error: Oops: 817 [#1]
> [ 37.272568] last sysfs file:
> /sys/devices/platform/orion-ehci.0/usb1/1-1/1-1.3/
> lirc/lirc0/uevent
> [ 37.281391] Modules linked in: lirc_mceusb2(+)
> rfkill lirc_dev sha1_generic mv_cesa(+)
> aes_generic ext2 mbcache sd_mod crc_t10dif
> usb_storage scsi_mod ehci_hcd usbcore mvsdio
> nls_base mv643xx_eth mmc_core libphy inet_lro

Quote
TEN
(This thread started in http://forum.doozan.com/read.php?2,2471)
Thanks a ton, Jeff, your above installation steps still work like a charm (albeit weighing in at a whopping 227 megabytes).

Quote
bedek
This issue is solved !
I was compiling lirc_mceusb2 module which might be bit more up to date although is still broken.
The solution was to build ONLY lirc_mceusb and DO NOT build lirc_mceusb2.
From that point on everything worked fine :)
Thnx for all tips above - they helped me a lot !

5 years on, much of LIRC has moved to the kernel and thrown the documentation into disarray all over the Internet as traditional approaches and kernel ir-keytable events collide while they have to live side by side on the same circuitry.

Time for an update, and the good news is that under Debian again, everything can be set up to make our ARM boxes great networked IR transceivers with built-in crontab etc., at a fraction of the price for a Mediola or even an IRTrans:

irsend with mceusb in kernel: not "rather than" LIRC, but using it, even over the network @ ubuntuforums.org

TEN Wrote:
> Reliability of irsend transmissions on this [mceusb]
> hardware has been improved over configurations
> from http://lirc.org/remotes by re-sampling the
> respective controls in raw mode as follows (for
> lirc-0.8.7), but the results (3 retries approx.
> required for proper reception by the controlled
> appliances) still suggest there might be a problem
> with the timing/accuracy on replay (to be
> confirmed by someone with a scope).
> irrecord --disable-namespace --force -d /dev/lirc0
> raw_light.conf

As I've since found out, there's a hard-coded constant limitation in http://lxr.free-electrons.com/source/drivers/media/rc/mceusb.c:
#define MCE_TIME_UNIT 50 /* Approx 50us resolution */
cf. http://sourceforge.net/p/lirc/mailman/message/24253837/

> The "silver bullet" might be getting the
> DockStar's spare GPIO pins, if any, to directly
> drive homebrew transceivers (preferably also one
> without softcarrier).

Investigations resumed ;) at http://forum.doozan.com/read.php?8,20700,21108#msg-21108