I envy you a little, hardware tinkering could certainly be fun. However, a clean sw solution has the advantage that it eventually could be merged into the lirc codebase and be useful for all lirc users.

Also, I don't really think you need to disable interrupts to get a reasonable real-time behaviour. However, what you definitely need to do is to avoid kernel dispatching another process between the two calls. If you could avoid this (and in theory real-time priorities would give you exactly that) there should be a predictable maximum delay which is short enough.

I think, that is. Don't forget the kernel† list(s), I'm pretty sure you would get a good answer there. My certainly isn't.

BTW, I think it's time to file a bug against lirc with these findings. The random delay between the two write() certainly looks like a bug to me, whatever the the cause might be.


On Tue, Jan 21, 2014 at 11:37 AM, Paul D Smith <paul_d_smith@hotmail.com> wrote:
Thanks for those suggestions.† Getting the keys to send reliably once will do me for now as that might be possible by running the bit of code that sends the key code within some ďdisable all interruptsĒ code or similar (Iím guessing as I donít know the R-Pi architecture, yet, or whether this might cause the Linux watchdog timer to trip).
As someone who likes tinkering with hardware, the idea of having some dedicated hardware doesnít bother me if that results in much more reliable behavior Ė but Iíll see what I can figure out about the software idea first.
Paul DS.
Sent: Tuesday, January 21, 2014 10:11 AM
Subject: Re: IR send timing issue
Well, looking at this it indeed seems like a kernel scheduling issue - occasionally the kernel switches to another process between the two write(2) calls causing a random delay.† Some thoughts out of the top of my head:
- A hardware-based solution should probably work. However, it looks a bit "brutal" to me to fix these kind of not that hard real-time requirements and is of course a maintenance problem, only working on specific hardware.
- We don't know whether irsend is using the lircd drivers or the kernel ones to do the sending in your setup. This might possibly affect things, I guess.
- The pulseaudio daemon seems to have a similar problem space, keeping ms-accurate timing. They seem to be able to fix this using real-time priorities. Running the complete lircd daemon using this is probably too risky, but might be worth a try to gather information.'
- Being a kernel scheduling problem, this might be the wrong list to get help. Perhaps you should try one of the kernel lists instead (sorry, I have no specifics). Here is also the people who knows about the kernel part of lirc in general, and I guess† this is what's it all about.



On Tue, Jan 21, 2014 at 9:17 AM, Paul D Smith <paul_d_smith@hotmail.com> wrote:
Thanks for the info.† Iíve got a second SDCard with a dev environment and I have enabled debugging in lircd, but perhaps not enough yet.† This enabled me to realise at least one mistake on my part.† I originally thought I was seeing this...
KEY-1, gap,KEY-2,gap,..., KEY-X,gap, KEY-X-Duplicate,gap, KEY-Y
(the ďgapsĒ are added by me because the Samsung TV Iím blasting at takes time to action any command).
..with the duplicate being the bug.† In fact I was seeing
KEY-1,KEY-1,gap,KEY-2,KEY-2,gap,...,KEY-X,random gap, KEY-X,gap,KEY-Y,gap,KEY_Y...
It seems that the TV normally expects a pair of keys (and thatís what the remote sends) but the random and unexpected gap between the KEY-Xs causes the TV to interpret these as two key presses instead of one.
But stopping the repeat has introduced a new problem which Iíve got to look at namely I now see keys periodically miss-sent so in a 12 key macro, #9 _always_ fails Ė bizarre but reproducibly true yesterday.
So more debugging to do.† In the meantime Iíve come across this...


Looks quite interesting in that it uses a PIC to offload the transmission.† using this with the Raspberry-Pi, a suitable prototype board and a new LIRC daemon (which could run in user space of course since itís not doing direct hardware IO, just writing to the serial port) might offer a far more reliable solution.

Paul DS.

Sent: Monday, January 20, 2014 7:26 PM
Subject: Re: IR send timing issue
On Sun, Jan 19, 2014 at 5:16 PM, Paul Smith <paul_d_smith@hotmail.com> wrote:
I believe I debugged a problem which I've narrowed down to an IRsend timing issue.† I wonder if someone with more knowledge of Linux internals can consider my conclusions and comment on whether I'm correct or not?

I'm using "irsend" to send commands to a Samsung TV.† Both a real and "fake" Samsung remotes send the same key twice in rapid succession and it seems that the TV allows a period of time during which a second occurence of the same code is ignored.† I understand this is done for reliability reasons as if one of the pair is corrupted, the other probably arrives OK.

Unfortunately sometimes this fails, for example, if try to send (pairs of) the keys "1", "2", "3", the TV might react as if I've sent "1", "2, "2", "3".† When this "duplicate" detection occurs is very random and, for example, when sending a "macro" of 11 keys, any one of them might be detected as a duplicate but it could be any of the 11 with no reproducibility.

What I believe is happening is that LIRC (probably the lircd daemon) sends the first of a pair of codes but then the time period until the second of the pair (remember each code is sent twice) is occasionally longer than expected.† The Samsung TV has given up ignoring duplicates and treats the second of the pair as a NEW code.

I've seen similar to this on DOS/Windows where timers get delayed because of interupts etc and I suspect something similar is happening here.† Do you, the reader, agree?

If so, is there a way to send the pair of keys with a more reliable interval between them so that this doesn't happen?† For now I've had to stop the "send twice" and this seems to work but obviously it would be better, and presumably more reliable, if I could follow the example of teh Samsung remote and send a pair of each code.

Paul D Smith
[Well, I'm certainly not the person knowing LInux internals. That said, the general answer to your question is "Yes, you can do anything. It's just to patch the sources". Admittedly, this isn't that helpful for us mere mortals. But still.

Have you tried the debugging options? They might give some more info (?)† Depending on your platform you might need to rebuild the sources. For Fedora, there are scratch packages with debug enabled at [1]

Perhaps some help,


[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=6430847