common problem with LIRC

[KidE]

HI Guys,

I have LIRC issue with a "Command IR mini III" transceiver connected to a Guruplug server plus running Debian 6 squeeze and i wanted to know if this issue sounds familiar.

When compile the 0.8.7 version of LIRC all seems fine and mode2 give a normal pulsetrain output but when i use irrecord it almost always fails and starts recording RAW config files.
Also if i use pre-recorded (working) lircd.conf files and use IRW to reflect my buttons nothing happens.
If i hookup the command IR to my Intell Ubuntu 10.04 box and use irrecord with the same remote all seems to be working fine and i can record my remote buttons. Also IRW is working fine and reclection of command work flawlessly
We tried almost everything you can imagine and the Manufacturer even send me a new one because they thought it was defective. Even with their extensive knowledge i'm hitting rock bottem.

Does this issue sounds familiar to anyone? does anyone have LIRC working (good) with irrecord with Arch Linux ARM?

Cheers,

E

[MojoMax]

I am having exactly the same problem - did you find a workaround for this?

M

[KidE]

@M

I used all debian versions with stock and self compiled lirc from squeeze to sid and unstable, i used Arch Linux ARM 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. I'm trying to compile LIRC now on a MIPS CPU from my popcornhour to see if that works