Menu ▾ ▴

#389 Inverted RC-6 decoding

Future
open
nobody
None
na
2026-03-12
2026-03-11
Gernot Walzl
No

Affected version: LIRC 0.10.2

I used mode2 to record the volume up signal sent from a remote control for a Philips TV (55 PUS 6704/12):

No VolUp 1 VolUp 2 VolUp 3
1 pulse 2766 pulse 2740 pulse 2738
2 space 771 space 797 space 797
3 pulse 509 pulse 535 pulse 535
4 space 832 space 807 space 807
5 pulse 535 pulse 535 pulse 535
6 space 359 space 359 space 359
7 pulse 535 pulse 535 pulse 535
8 space 359 space 359 space 359
9 pulse 540 pulse 1417 pulse 535
10 space 785 space 1254 space 789
11 pulse 952 pulse 509 pulse 974
12 space 394 space 385 space 367
13 pulse 562 pulse 509 pulse 535
14 space 333 space 385 space 359
15 pulse 535 pulse 509 pulse 540
16 space 359 space 385 space 359
17 pulse 535 pulse 536 pulse 535
18 space 359 space 359 space 359
19 pulse 535 pulse 535 pulse 536
20 space 359 space 359 space 358
21 pulse 535 pulse 535 pulse 509
22 space 359 space 359 space 385
23 pulse 513 pulse 535 pulse 535
24 space 385 space 359 space 359
25 pulse 535 pulse 535 pulse 535
26 space 359 space 368 space 359
27 pulse 509 pulse 535 pulse 509
28 space 389 space 359 space 394
29 pulse 509 pulse 536 pulse 536
30 space 385 space 359 space 359
31 pulse 535 pulse 952 pulse 509
32 space 359 space 837 space 386
33 pulse 978 pulse 537 pulse 1004
34 space 817 space 361 space 784
35 pulse 534 pulse 531 pulse 535
36 space 358 space 363 space 363
37 pulse 509 pulse 505 pulse 505
38 space 385 space 390 space 389
39 pulse 535 pulse 536 pulse 535
40 space 359 space 359
41 pulse 535 pulse 535

The recorded signal discretized in 444 microseconds (as defined in the RC-6 protocol):

No VolUp 1 in 444µs
1 1
1 1
1 1
1 1
1 1
1 1
2 0
2 0
3 1
4 0
4 0
5 1
6 0
7 1
8 0
9 1
10 0
10 0
11 1
11 1
12 0
13 1
14 0
15 1
16 0
17 1
18 0
19 1
20 0
21 1
22 0
23 1
24 0
25 1
26 0
27 1
28 0
29 1
30 0
31 1
32 0
33 1
33 1
34 0
34 0
35 1
36 0
37 1
38 0
39 1
40 0
41 1

I decoded the RC-6 protocol by hand using the description provided in [1]:

No VolUp 1 RC6
1-2 Leader
3-4 1
5-6 0
7-8 0
8-9 0
10-11 TR 0
12-13 0
14-15 0
16-17 0
18-19 0
20-21 0
22-23 0
24-25 0
26-27 0
28-29 0
30-31 0
32-33 0
33-34 1
34-35 0
36-37 0
38-39 0
40-41 0

The payload in hex is 0x0010.

When I use irrecord, the output is always:

begin remote

  name  PHILIPS_BRC0884402
  bits           21
  flags RC6|CONST_LENGTH
  eps            30
  aeps          100

  header       2755   794
  one           515   379
  zero          515   379
  gap          106729
  min_repeat      1
  toggle_bit_mask 0x10000
  rc6_mask    0x10000
  frequency    38000

      begin codes
          # ...
          KEY_VOLUMEUP             0x0EFFEF
          # ...
      end codes

end remote

I compared the output to other remote controls by Philips that use the RC-6 protocol [2].
Seems like KEY_VOLUMEUP is always 0xFFEF, which is somehow the inverted payload.

I reviewed the source code and found that expectzero(...) first expectpulse(...) and then set_pending_space(...). [3]
This is somehow contradicting to "If the symbol is a 0 the first half of the bit time is a space and the second half is a mark. Please note that this is the opposite of the RC-5 protocol! " [1]

So ... which variant is correct?

[1] https://www.sbprojects.net/knowledge/ir/rc6.php
[2] https://lirc.sourceforge.net/remotes/philips/
[3] https://sourceforge.net/p/lirc/git/ci/master/tree/lib/receive.c#l457

Discussion

  • Bengt Martensson

    Bengt Martensson - 2026-03-12

    This is not a ticket in the formal sense -- it does not describe a bug/misbehavior nor a suggested improvement -- so it can be just closed. Rather it is an attempt to understand. I will try to give some (hopefully) helpful suggestions next.

    Trying to use Lirc to understand IR protocols is not a good idea. May I suggest that you try IrScrutinizer instead? You probably already have a /dev/lirc* device, so in IrScrutinizer select that device as "hardware". Thus you can capture and decode IR signal from the /dev/lirc device.

    The RC-5 has the IRP notation 

    {36k,msb,889}<1,-1|-1,1>((1,~F:1:6,T:1,D:5,F:6,^114m)*,T=1-T)[D:0..31,F:0..127,T@:0..1=0]

    while RC-6 goes

    {36k,444,msb}<-1,1|1,-1>((6,-2,1:1,0:3,<-2,2|2,-2>(T:1),D:8,F:8,^107m)*,T=1-T) [D:0..255,F:0..255,T@:0..1=0]

    so, yes, their 0 and 1 encodings differ.

     

    • Gernot Walzl

      Gernot Walzl - 2026-03-12

      Thanks for the fast reply :-)
      Sorry for the detailed explanation. Let me rephrase it to a bug:

      I have a remote for a Philips TV. When I press the volume up key on this remote,
      mode2 shows an RC-6 signal (pulses and spaces) with a payload of 0x0010.
      Unfortunately, irrecord always creates a config file with flags RC6 and 0x...FFEF for the volume up key.

      Suspected issue: Receiving RC-6 signals in LIRC does not correctly decode Manchester encoded signals. Receiving in LIRC does not distinguish between RC-5 and RC-6 encoding.
      Therefore, the recorded logical meaning of RC6 signals does not match the expected logical meaning. (expected as specified in [1])

       

  • Bengt Martensson

    Bengt Martensson - 2026-03-12

    The man page lircd.conf(5) says:

            LIRC was designed to collect IR data and save it in a private,  compact,
       yet  human readable format with the purpose of being able to re-transmit
       (or re-recognize) these signals. It was not designed with  the  goal  of
       providing  a  well  documented and tested configuration file format that
       could be used e.g., to generate arbitrary IR signals or to convert  them
       to other formats. The configuration file should thus not be considered a
       public interface to LIRC.

    So if you are looking for a tool to decode IR signal to their official versions, Lirc is not the right tool, nor does it claim to be. If you want to record and reproduce certain IR signals, it may do the job though.

     

    • Gernot Walzl

      Gernot Walzl - 2026-03-12

      Then, my bug description becomes a feature request :-)

       

Log in to post a comment.

MongoDB Logo MongoDB