LIRC issues with Guruplug server PLUS

[KidE]

All,

I've been struggling with LIRC and a USB IR tranceiver from CommandIR for a few weeks now and i finally found the issue why it will not work on the Guruplug.

The issue:

LIRC works flawlessly on my desktop PC with Ubuntu 10.04. I can record my remotes witout a glitch.
Doing the same with the same remotes and the same IR device on the guruplug ends in total disaster. Irrecord will simply not decode the ir commands or hangs totally.

I used all debian versions with stock and self compiled lirc from squeeze to sid and unstable, i used plugapps linux to see if it  makes a difference but without any luck.

It seems that lirc de/encodes a incomming/outgoing ir stream synchronously. If it cant get the correct interrupt scheduling it needs it fails to decode the stream and it will not send or receive a command correctly.

i found an interesting page regarding this topic and i was suprised to see that LIRC dev team has marked this as a "known bug"

http://www.lirc.org/html/technical.html

it states:

    The lirc_serial and lirc_parallel drivers measure the time between interrupts on the serial resp. parallel port to get a pulse and space representation of the incoming infra-red signal. If interrupts are disabled by the CPU for a rather long time (>100 µs, which happens often e.g. during heavy IDE disk activity) some interrupts might get lost and the incoming data stream becomes disturbed. In this case decoding of the infra-red signal will fail. This is the downside of the really simple receiver circuits and can't be addressed in software except keeping the time where interrupts are disabled to a minimum.

    If you are using an IDE system you might want to try calling hdparm -u1 -d1 for all of your drives. This enables DMA for the drive and allows the driver to unmask other interrupts during handling of a disk interrupt. But be aware that this can be dangerous for some (buggy) IDE chipsets. Consult the hdparm man page for further information.

So i investigated and i found that in all these plug computers (Marvell CPU ones) all disk (sd-card) and USB traffic goes through one controller on on the chip.
Running "hdparm" on the plug reports that DMA is not supported for disk devices and this relates perfecly with the known bug from LIRC dev team.

So..... i think this will be the end?

Or has somebody a working LIRC? (or do i need to get back to school)

[sfzhi]

This is the downside of the really simple receiver circuits and can't be addressed in software except keeping the time where interrupts are disabled to a minimum.

So..... i think this will be the end?

Why the end? You could just stop trying to use those "really simple receiver circuits" that require interrupts enabled and use a "decent" receiver hardware instead...

[KidE]

This is the downside of the really simple receiver circuits and can't be addressed in software except keeping the time where interrupts are disabled to a minimum.

So..... i think this will be the end?

Why the end? You could just stop trying to use those "really simple receiver circuits" that require interrupts enabled and use a "decent" receiver hardware instead...

Do you mean that the CommandIR mini III is not a decent piece of hardware? http://www.commandir.com/

[sfzhi]

Do you mean that the CommandIR mini III is not a decent piece of hardware? http://www.commandir.com/

Sorry, somehow I missed the part of your message referring to the device type you were using. Looks quite decent to me, although I haven't used it myself.
I would expect this kind of hardware not to need those not-so-nice tricks in the driver. And since it is a USB device, I strongly doubt that the "known bug" behavior described on the LIRC page would be possible at all. You just can't have that precise timing over USB bus, so the decoding has to be done by the receiver itself.
Also considering what they say on the home page:
"Announcing the brand new CommandIR Utilities (beta), a set of command line utilities to record and send IR codes with CommandIR without LIRC."
your problem is most likely unrelated to the "known bug" of LIRC.