Help! x86 SBCs, LIRC, infra-red and CIR remote controls

Oops. I forgot to post the BAD lircd.conf: Remember, this is with the same remote control...

begin remote

name /etc/lircd.conf flags CONST_LENGTH|RAW_CODES eps 30 aeps 100

ptrail 0 repeat 0 0 gap 107872

begin raw_codes

name 1 39 12799 39 710 39 1965 39 209 39 2529 39 301 39 460 39 613 39 754 39 2075 39 1368 39 4801 39 857 39 981 39 1367 39 473 39 608 39 753 39 4057 39 1100 39 218 39 366 39 511 39 652 39 798 39 946 39 5145 39 1573 39 1874 39 2174 39 1505 39 3393 39 2142 39 1449 39

name 3 39 12738 39 1111 39 3053 39 582 39 711 39 352 146 910 39 237 39 1449 39 5378 39 2076 39 259 39 407 39 1685 39 854 39 1002 39 3536 39 1467 39 621 39 1066 39 918 39 1096 39 232 39 381 141 3739 39 680 39 1979 39 1346 39 1587 39 4192 39 2209 39 1534 39 1828 39

name w 39 13038 39 217 39 1498 39 673 39 808 39 961 39 3680 39 283 39 1557 39 1867 39 2199 39 363 39 3868 39 1794 39 961 39 207 39 283 39 420 39 1703 39 4723 39 1022 39 236 39 345 39 486 39 629 39 1915 39 200 39 5465 39 1700 39 2006 39 1380 39 3947 39 1954 39

name a 39 12631 39 900 39 2170 39 368 39 517 39 3198 39 814 39 949 39 1326 39 1566 39 2151 39 2955 39 272 39 1487 39 663 39 803 39 951 39 1320 39 5714 39 738 39 872 39 1020 39 245 39 339 39 488 39 628 39 3933 39 2068 39 1390 39 1756 39 2013 39 3774 39 1644 39

name s 39 13699 39 1097 39 1389 39 556 39 3003 39 364 144 902 39 238 39 1448 39 1751 39 5025 39 261 39 399 39 1682 39 855 39 995 39 229 39 311 39 4896 39 1748 39 911 39 1060 39 223 39 371 39 881 39 4533 39 2122 39 304 39 1583 39 1893 39 4076 39 1537 39 1827 39

name d 39 13748 39 1106 39 1457 39 523 39 663 39 807 39 960 39 202 39 1402 39 5546 39 2067 39 220 39 363 39 1644 39 818 39 3979 39 212 39 1413 39 673 39 1858 39 1030 39 249 39 4554 39 505 39 647 39 785 39 2093 39 269 39 1540 39 4468 39 2190 39 1512 39 1793 39

name x 39

end raw_codes

end remote

The good one again:

Hi Lewin,

I've only ever played with IrDA and don't really know anything about CIR, but what i can say, is that you shouldn't go by the LIRC training results.

I have trained one of my remotes a few times, and even though i've trained it in exactly the same way, the result codes have been different (and both still work). The header numbers have all been different, and subsequently the button/code numbers have all been different too.

also, does the IR decode module have more than one mode ? IIRC, the vishay unit i played around with a few years ago had mode pins to put it into different IrDA/ASK etc modes.

Good luck anyway.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Damion de Soto - Software Engineer  email:     damion@snapgear.com
SnapGear - A CyberGuard Company ---    ph:         +61 7 3435 2809
  | Custom Embedded Solutions          fax:         +61 7 3891 3630
  | and Security Appliances            web: http://www.snapgear.com~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  ---  Free Embedded Linux Distro at   http://www.snapgear.org  ---

Hi Damion,

Hmm. This happens in raw mode due to timing variances, but in "intelligent" mode, the codes at least should be the same, even though the burst lengths will vary a bit.

The thing is, on my ThinkPad, and on other machines, a single lircd.conf will work fine (can be switched amongst them). It's just on this one SBC that I have problems.

No, it's not an IrDA transceiver, it's just a simple CIR receiver as you might find in a TV set or VCR. One data pin, no options :) The Super I/O has several modes, but I've tried them all.

I'm now almost 100% sure I'm being screwed by Geode's damn SMM-induced non-realtimeness again. And the board vendor is being totally unresponsive - which is rather unusual, I usually get at least an acknowledgement of receipt of a problem report.

I'm getting a little further, though. If I force raw mode with irrecord -f and analyze the configuration file, I see that some of the recorded bits are abnormally short (e.g. burst lengths of 600 when I expect to see 2200). By manually tweaking lirc's fuzziness threshholds and by manually editing the config file's bit descriptions to fix up the recorded glitches, I'm at a point where I can successfully read six out of the seven buttons on my remote. Close, very close, still no cigar :)) But I don't understand why I can ONLY get the raw controlfile to work. I should be able to get the normal controlfile to work simply by adjusting the fuzziness params.

I also don't understand at all why I can't get this last button to work. The codes are 1-2-3-4-5-6-7 and it's code 5 that won't work. VERY BIZARRE.

Hi,

Try to figure out, which pin of the ir header of board B is connected to the Winbonds CIR_IN (CMOS mode should be CIR). Connecting a "normal" IR receiver like the TSOP13XX to the IRDA pins of Board B (pin 3,5) should not work, as you have seen. If you cannot get the CIR_IN pin, you might want to check, if you can run the IRDA port as a "standard" serial port and then use the TSOP on this.

If lirc_sir is working on board A, it should be ok. I don't know how the CIR port of the Winbond chip is handled by linux (serial driver or something special), but if it is handled as a normal serial port lirc_serial should work too.

Best regards, Reiner

Hi Reiner,

Well, I have gotten further.. I now have a workaround that functions acceptably. But manual tweaking is necessary.

That pin isn't connected on board B. Also, the latest BIOS for the board has no more CIR mode, only IrDA and ASKIR.

As it transpires, I find that the root cause of this problem is either an analog design issue or (more likely IMHO) BIOS bug on board vendor B (which is Advantech, by the way). It seems that the port is either very sensitive to glitches or is periodically missing pulses [could be SMM mode on the Geode screwing things up], and the burst times measured are quite different from times measured on other SBCs. I can get the standard CIR receiver (TSOP/GP1U - I have tested both now) to work acceptably when connected to IrDA IR_RX as long as I do the following:

1. Record the remote's characteristics on a laptop or other board so I can know the codes generated by each button.
2. Train the remote on the bad board, using irrecord -f to force raw.

2a. If any buttons report an unusually short signal length, retrain those immediately.

1. Manually edit lircd.conf file and look for bursts that are way outside limits. Example: My remote uses ~1085 for 0 and ~2220 for 1. Training on the bad board will show occasional glitches of 500 or 3000 bursts where bits have been joined together or split in half. Manually editing the burst sequences for each button fixes this up, but it is extremely tedious. I am glad my remote has only 7 buttons, it would be horrible to edit all the entries for, say, a keyboard.
2. Manually adjust fuzziness threshhold :)

I am sure, that a high percentage of button presses are being missed, but it empirically seems to respond adequately. I am also sure that this same glitch would cause high BER in IrDA comms, but the user probably never notices because it is retried automatically. Basically it is a submarine bug.

(BTW - As far as I understand it from all the datasheets I have now read, the Rx half of an IrDA transceiver is the same circuit as an active-low CIR receiver, although some transceivers have less or more carrier filtering. So I /expected/ to be able to get the CIR rxvr to work. I was just desperate for answers and wondering if maybe there was extra magic in the IrDA rxvr).

Hi,

Good to hear, that you have got it working, although I thought that it's not possible to get an ir-receiver working on an IRDA port ;)

BTW: Can you give some numbers how much processing power is used on your board in this configuration. I once used a "raw" TSOP connected to the serial port of a Celeron 400 and lirc used up to

20% - that's why I use an uc-based solution now.

Best regards, Reiner

Hi Reiner,

I don't see why... at least, with most protocols it should be OK? ASK would be a problem, I guess.

I am moving the other way - I am trying to eliminate as much external circuitry as I can and move functions into software. We were using an external PIC to decode the IR. Changing this circuit has saved $11 in external components already, not counting some minor savings on little things like wire and lowered soldering expenses. Plus it allows us to support different remotes - and even an IR keyboard, later - just with a software change.

The reason I want to use the IR mode of the board's UART is precisely because I don't want lirc chewing up time manually measuring pulse lengths :) I just ran top on my development system, and I can't see lircd when it's idle. If I hold down a button, I can briefly get it to show 1% (intermittently). I take this all to mean it's not consuming any significant amount of processing time. Empirically, it does not disturb foreground playback of MPEG-video files, and that is the important thing!