1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

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

Discussion in 'Embedded' started by Lewin A.R.W. Edwards, Feb 2, 2004.

  1. Hi all,

    I'm having a strange problem using LIRC with simple 3-pin IR decoder
    modules (Vishay TSOP13xx, Sharp GP1Uxxxxx) on certain SBCs, even
    though the boards are nominally all the same. Both of them use the
    same Super I/O (Winbond W83977AF). Both vendors implement IR on a
    5x1-pin 2mm header that's "almost" the same as the "standard" for PC
    motherboards:

    Board vendor A has "CIR_IN" on pin 2.
    Board vendor B shows pin 2 as NC, and although it's hard to trace
    (6-layer board), I verified that wherever that pin goes, it doesn't go
    to an input on the super I/O.
    Both vendors have pin 1=5V, 3=IR_RxD, 4=GND, 5=IR_TxD.

    If I connect my decoder to pin 2 on board A, everything works OK.
    However, if I connect the decoder to pin 3 on board B, it doesn't work
    properly, and Board B is the one I really want to use. Board B's CMOS
    setup has the options IrDA, CIR and ASK as the modes for the IR port;
    I've tried all three modes with basically the same results.

    I may be missing something very obvious; for example I may be
    selecting the wrong LIRC driver (I'm using lirc_sir). If anyone can
    offer an insight, it would be greatly appreciated. Is there something
    special about the IrDA transceivers (vs. a standard CIR rxvr) that
    would be the culprit?

    Below is the result of training LIRC on my remote on board A
    (working). I get the same results when I train the remote on my
    ThinkPad. However, on board B the training process APPEARS to work but
    gives totally different results. Sometimes it thinks it's seeing an
    RC-6 remote. Sometimes it just says raw mode. Even when training is
    successful, LIRC will never recognize button presses.


    begin remote
    name /etc/lircd.conf
    bits 16
    flags SPACE_ENC|CONST_LENGTH
    eps 30
    aeps 100
    header 39 13508
    one 39 2222
    zero 39 1085
    ptrail 39
    repeat 39 11259
    pre_data_bits 16
    pre_data 0x41C8
    gap 108332
    toggle_bit 0
    begin codes
    p 0x00000000000000FF
    w 0x000000000000807F
    u 0x00000000000040BF
    l 0x000000000000C03F
    d 0x00000000000020DF
    r 0x000000000000A05F
    n 0x000000000000609F
    end codes
    end remote
     
    Lewin A.R.W. Edwards, Feb 2, 2004
    #1
    1. Advertisements

  2. 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:
     
    Lewin A.R.W. Edwards, Feb 3, 2004
    #2
    1. Advertisements

  3. 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:
    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 ---
     
    Damion de Soto, Feb 3, 2004
    #3
  4. 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.
     
    Lewin A.R.W. Edwards, Feb 3, 2004
    #4
  5. Lewin A.R.W. Edwards

    Reiner Rosin Guest

    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
     
    Reiner Rosin, Feb 4, 2004
    #5
  6. 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.
    3. 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.
    4. 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).
     
    Lewin A.R.W. Edwards, Feb 4, 2004
    #6
  7. Lewin A.R.W. Edwards

    Reiner Rosin Guest

    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
     
    Reiner Rosin, Feb 5, 2004
    #7
  8. 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!
     
    Lewin A.R.W. Edwards, Feb 5, 2004
    #8
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.