[mythtv-users] Need IR advice

[Michael Tiller]

After getting my Myth box set up, I have been on a quest to improve the WAF 
for my system. There have been many tweaks, but my "holy grail" has been to 
get all the functions (both media center + TV + ...) on to a single 
universal remote. I thought my objective was within my grasp, but I've been 
thwarted once again and I'm hoping somebody can provide me with a solution 
to my latest problem.

First, a bit of background. I have a PVR-150 card. I got the LIRC stuff 
going with the IR pickup that came with the card. But, it only works with 
the Hauppauge supplied remote. I know in theory I could probably get it to 
work with other RC-5 remotes, but none of the codes I tried on my universal 
remote seemed to work.

I tried making my own, but the voltages weren't right and I just didn't have 
the time to iterate on that thing.

So I bought an IRA-3 from www.home-electro.com
<http://www.home-electro.com>thinking my days of screwing around were
over. Sadly, I was wrong. The IRA-3
uses the IRMAN protocol, BTW.

I hooked the thing up and tried to get it to work with the version of LIRC 
already installed on my machine (0.7.1). No dice. I couldn't seem to get 
anything. It kept giving me an error in irman_init(). Crap. So I got the 
source to LIRC and tried building it. No dice, same error. Because I could 
initialize the device on my Windows machine, I didn't understand what the 
problem was. I got the latest versions of LIRC and libirman and tried to 
sort things out.

After a considerable amount of digging and learning far more about IRMAN, 
IR, LIRC and serial ports than I ever wanted to learn, I eventually managed 
to narrow down the problem. While the IRMAN protocol specifies 9600 baud, 8 
data bits, no partity, no flow control and 1 stop bit, the port 
initialization fails to actually specify one stop bit (although it doesn 
explicitly handle all the other parameters). I added one line to the 
initialization routine in libirman (to set the stop bit to 1, something it 
should have already been doing even according to the comments in the code) 
and low and behold...it worked!!! My IRA-3 initialized and I started getting 
data from it in the expected 6 byte chunks. Hooray!!!

At this point, I thought I had finally conquered this stupid issue. I 
rebuilt libirman and LIRC using the new initialization code and I was well 
on my after running irrecord and building up a .conf file for my remote.

Then...disaster struck. After trying to use Myth with the new remote it 
seemed like it was ignoring some of the key presses. I went back into raw 
mode (using test_io in libirman to output the codes) and it turns out that 
the stupid thing is spitting out multiple codes for the same key. I don't 
mean it repeats itself (which it does, but that is a different issue). I 
mean it gives a different code sequence! God Damn IT!!!!

The problem seems to be related to the history of key presses. As I said, a 
single keypress send a duplicated code but that doesn't seem to cause any 
problem. The real problem is when the codes change. For example, running 
'test_io', these sequences are for the same key:

[29][14][7d][f7][5f][ff]
[29][14][7d][f7][5f][ff]
[2a][e8][4e][f7][5f][3f]
[2a][e8][4e][f7][5f][3f]
[29][14][7d][f7][5f][ff]
[29][14][7d][f7][5f][ff]

WTF? I find that if I hit the same key repeatedly I pretty much get 
consistent codes. But, if I jump around (e.g. LEFT, RIGHT, Channel-UP, LEFT) 
that the same key (e.g. LEFT) will have different codes.

My hope is that somebody has some simple remedy (e.g. something simple like 
turning on flow or changing the parity or something). By the way, the 
Hauppauge remote works fine. But it only send 2 bytes?!?

Any suggestions?!? I was so close. After having hacked may way through all 
this to have it fail to read remote key signals reliably is so 
aggravating!!!!!

Any help would be greatly, greatly appreciated.

--
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-users/attachments/20050828/fb2acdaa/attachment-0001.htm