List of Irp Protocols, version 2019-12-22

Contents:

Protocols

48-NEC
{38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,E:8,~E:8,1,^108m)[D:0..255,S:0..255=255-D,F:0..255,E:0..255]
decode-only: true
Like DecodeIR, we call a 48-NEC* signal without repeat "48-NEC".
48-NEC1
{38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,E:8,~E:8,1,^108m,(16,-4,1,^108m)*)[D:0..255,S:0..255=255-D,F:0..255,E:0..255]
reject-repeatless: true
48-NEC2
{38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,E:8,~E:8,1,^108m)*[D:0..255,S:0..255=255-D,F:0..255,E:0..255]
reject-repeatless: true
AdNotam
{35.7k,895,msb}<1,-1|-1,1>(1,-2,1,D:6,F:6,^114m)*[D:0..63,F:0..63]
Very similar to RC5, except AdNotam uses two start bits, and no toggle bit.
Aiwa
{38.123k,550}<1,-1|1,-3>(16,-8,D:8,S:5,~D:8,~S:5,F:8,~F:8,1,-42,(16,-8,1,-165)*)[D:0..255,S:0..31,F:0..255]
uei-executor: 005E:2
uei-executor: 009E[S;D,F]
Aiwa2
{38k,550}<1,-1|1,-3>(16,-8,D:8,S:5,~D:8,~S:5,F:8,~F:8,1,-42)* [D:0..255,S:0..31,F:0..255]
uei-executor: 005E:2
Source: Dave Reed's program Teaser.
Akai
{38k,289}<1,-2.6|1,-6.3>(D:3,F:7,1,^25.3m)*[D:0..7,F:0..127]
uei-executor: 000D[D:2;D:1:2,F]
Akord
{37.0k,477,msb}<1,-1|1,-2>(18,-8,D:8,S:8,F:8,~F:8,1,-40m,(18,-5,1,-78m)*)[D:0..255,S:0..255,F:0..255]
Protocol found in Akord HDMI switches. Similar to NEC1, but with different timing. See forum thread.
Amino
{37.3k,268,msb}<-1,1|1,-1>(T=1,(7,-6,3,D:4,1:1,T:1,1:2,0:8,F:8,15:4,C:4,-79m,T=0)+){C =(D:4+4*T+9+F:4+F:4:4+15)&15} [D:0..15,F:0..255]
uei-executor:
uei-executor:
prefer-over: Amino-56
absolute-tolerance: 100
relative-tolerance: 0.2
Amino equipment use both 37 and 56KHz, but the duration of the half-bit is always 268. Zaptor is a closely related protocol which for which the half-bit duration is 330.
Amino-56
{56.0k,268,msb}<-1,1|1,-1>(T=1,(7,-6,3,D:4,1:1,T:1,1:2,0:8,F:8,15:4,C:4,-79m,T=0)+){C =(D:4+4*T+9+F:4+F:4:4+15)&15} [D:0..15,F:0..255]
uei-executor:
uei-executor:
absolute-tolerance: 100
relative-tolerance: 0.2
Anthem
{38.0k,605}<1,-1|1,-3>((8000u,-4000u,D:8,S:8,F:8,C:8,1,-25m)2, 8000u,-4000u,D:8,S:8,F:8,C:8,1,-100)* { C=~(D+S+F+255):8} [D:0..255,S:0..255,F:0..255]
uei-executor: 0123[D,S,F:-2:6;F:6]
prefer-over: Anthem_relaxed
prefer-over: NEC2-f16
Anthem framing is very similar to NEC, and also uses 32 bits of data. However, the leadout is much shorter. The signal is sent at least 3 times. Anthem usually splits F into a 2 bit unit number, and a 6 bit function number.
Anthem_relaxed
{38.0k,605}<1,-1|1,-3>(8000u,-4000u,D:8,S:8,F:8,C:8,1,-25m)* { C=~(D+S+F+255):8} [D:0..255,S:0..255,F:0..255]
uei-executor:
decode-only: true
Relaxed version of the Anthem protocol.
Apple
{38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,C:1,F:7,PairID:8,1,^108m,(16,-4,1,^108m)*){C=1-(#F+#PairID)%2,S=135}[D:0..255=238,F:0..127,PairID:0..255]
uei-executor: 01E0{S=135,E=PairID}[D?0,E|||D?1,S,D?2,D?3;F,??,0]
prefer-over: NEC1-f16
prefer-over: NEC2-f16
prefer-over: NEC1
prefer-over: NEC-Shirriff-32
C=1 if the number of 1 bits in the fields F and I is even. I is the remote ID. Apple uses the same framing as NEC1, with D=238 in normal use, 224 while pairing.
Archer
{0k,12}<1,-3.3m|1,-4.7m>(F:5,1,-9.7m)* [F:0..31]
relative-tolerance: 0.1
This is not a robust protocol, so spurious decodes are likely.
arctech
{0k,388}<1,-3|3,-1>(<0:2|2:2>((D-1):4,(S-1):4),40:7,F:1,0:1,-10.2m)*[D:1..16,S:1..16,F:0..1]

Protocol used by several manufacturers of 433MHz RF controlled switches, like Intertechno, Duewi, ELRO, KlikAanKlikUit, and the URC light control kit, and many other. Appears to be introduced by the Taiwanese firm ARC Technology. These codes correspond to switches with code wheels, having an "House number" ranging from "A" to "P", in the IRP above corresponding to D=1 up to 16 for "P". They also have an "Address", ranging from 1 to 16, corresponding to the parameter "S" in the IRP. Note that e.g. Intertechno makes switches "with code wheel" and "without code wheel", the latter having a much larger addressing space, and unfortunately cannot be controlled by the present protocol. F=0 is the power off command, F=1 the power on command. The power on command is also used for dimming, both up and down.

In some One for All remotes, for example the URC-7781, the setup codes 2200,2201,...,2215 correspond to this protocol, 2200 for house "A", up to 2215 for house "P".

arctech-38
{38k,388}<1,-3|3,-1>(<0:2|2:2>((D-1):4,(S-1):4),40:7,F:1,0:1,-10.2m)*[D:1..16,S:1..16,F:0..1]
Same as arctech, but with an IR-typical modulation.
Audiovox
{40k,500}<1,-1|1,-3>(16,-8,D:8,1,-8,F:8,1,-40)*[D:0..255,F:0..255]
uei-executor: 005D[D;F]
B&O
{455k,3125,msb}<200u,-zeroGap,zeroGap=2,oneGap=3 | 200u,-oneGap,zeroGap=1,oneGap=2> (200u,-1,200u,-1,200u,-5,D:9,F:8,200u,-4,200u,-100m) {zeroGap=1, oneGap=3} [D:0..511,F:0..255]
uei-executor: 00EB[D:1:8,D:8,1;F,F]
uei-executor: 00EB:4[D:1:8,D:8,1;F]
frequency-tolerance: -1
455kHz protocol used by some Bang & Olufsen equipment. Forum thread.
B&O repeat
{455k,3125,msb}<200u,-zeroGap,zeroGap=2,oneGap=3 | 200u,-oneGap,zeroGap=1,oneGap=2> (200u,-1,200u,-1,200u,-5,D:9,F:8,200u,-4) {zeroGap=1, oneGap=3} [D:0..511,F:0..255]
uei-executor: 00EB:4[D:1:8,D:8,1;F]
frequency-tolerance: -1
From David Reed's program Teaser.
Barco
{0k,10}<1,-5|1,-15>(1,-25, D:5,F:6, 1,-25,1,-120m)*[D:0..31,F:0..63]
absolute-tolerance: 60
uei-executor: 002A
uei-executor: 00F3
This protocol uses no modulation of the signal. This is a moderately robust protocol, but spurious decodes are still possible.
Blaupunkt
{30.3k,512}<-1,1|1,-1>(1,-5,1023:10, -44, (1,-5,1:1,F:6,D:3,-236)+ ,1,-5,1023:10,-44)[F:0..63,D:0..7]
uei-executor: 00A5[D,0;F]
prefer-over: Blaupunkt_relaxed
Blaupunkt_relaxed
{30.3k,512}<-1,1|1,-1>(1,-5,1023:10, -44, (1,-5,1:1,F:6,D:3,-236)* ,1,-5,1023:10,-44)[F:0..63,D:0..7]
uei-executor:
decode-only: true
Bose
{38.0k,500,msb}<1,-1|1,-3>(2,-3,F:8,~F:8,1,-50m)* [F:0..255]
uei-executor: 010C
Bryston
{38.0k,315}<1,-6|6,-1>(D:10,F:8,-18m)* [D:0..1023,F:0..255]
minimum-leadout: 15000
CanalSat
{55.5k,250,msb}<-1,1|1,-1>(T=0,(1,-1,D:7,S:6,T:1,0:1,F:7,-89m,T=1)+)[D:0..127,S:0..63,F:0..127]
uei-executor: 018C
alt_name: ruwido r-step
The repeat frames are not all identical. T toggles within a single signal, with T=0 for the start frame and T=1 for all repeats. The official name for CanalSat is "ruwido r-step".
CanalSatLD
{56k,320,msb}<-1,1|1,-1>(T=0,(1,-1,D:7,S:6,T:1,0:1,F:6,~F:1,-85m,T=1)+)[D:0..127,S:0..63,F:0..63]
uei-executor: 018C:JP1
The official name for CanalSatLD is "ruwido r-step"
Canon
{33k,1}<16p,-240p|16p,-175p>(F:1)2[F:0..1]
relative-tolerance: 0.1
absolute-tolerance: 50
IR protocol for many Canon cameras. With F=0 it triggers immediately, F=1 it triggers after a delay of approximately two seconds.
Denon
{38k,264}<1,-3|1,-7>(D:5,F:8,0:2,1,-165,D:5,~F:8,3:2,1,-165)* [D:0..31,F:0..255]
prefer-over: Denon{1}
prefer-over: Denon{2}
uei-executor: 001C[D;F]
uei-executor: 009C(Denon Combo (Official))[;D,1,F]
uei-executor: 009C:JP1[;D,F]
uei-executor: 01C8[;0,D,F]
uei-executor: 01AC[0;0,D,F]
A Denon signal has two halves, either one of which is enough to fully decode the information. When one half is seen it will be decoded as Denon{1} or Denon{2}. Denon, Denon{1} and Denon{2} all represent the same protocol when correct, but only Denon is robust.
Denon-K
{37k,432}<1,-1|1,-3>(8,-4,84:8,50:8,0:4,D:4,S:4,F:12,((D*16)^S^(F*16)^(F:8:4)):8,1,-173)* [D:0..15,S:0..15,F:0..4095]
uei-executor: 00CD[D;S,F]
uei-executor: 01C8[D?0,S?0,D?1,S?1,D?2,S?2,D?3,S?3,D?4,S?4,D?5,S?5;0,,,??,F]
uei-executor: 01AC[D,S;0,,,F]
prefer-over: Kaseikyo
Denon-K is the member of the Kaseikyo family with OEM_code1=84 and OEM_code2=50. It uses the same check byte rules as Panasonic protocol, but uses the data bits differently.
Denon{1}
{38k,264}<1,-3|1,-7>(D:5,F:8,0:2,1,-165)* [D:0..31,F:0..255]
decode-only: true
uei-executor: 001C[D;F]
uei-executor: 009C(Denon Combo (Official))[;D,,F]
uei-executor: 009C:JP1[;D,F]
uei-executor: 01C8[;0,D,F]
uei-executor: 01AC[;0,D,F]
See Denon.
Denon{2}
{38k,264}<1,-3|1,-7>(D:5,~F:8,3:2,1,-165)* [D:0..31,F:0..255]
decode-only: true
uei-executor: 001C[D;F]
uei-executor: 009C(Denon Combo (Official))[;D,,F]
uei-executor: 009C:JP1[;D,F]
uei-executor: 01C8[;0,D,F]
uei-executor: 01AC[;0,D,F]
See Denon.
Dgtec
{38k,560}<1,-1|1,-3>(16,-8,D:8,F:8,~F:8,1,^108m,(16,-4,1,^108m)*) [D:0..255,F:0..255]
uei-executor: 016A:2
uei-executor: 016A
Digivision
{38.0k,182}<3,-3|3,-6>(20,-10,D:8,Dev2:8,Dev3:8,20,-10,F:8,~F:8,3,^108m,(20,-20,3,^108m)*) [D:0..255,Dev2:0..255,Dev3:0..255,F:0..255]
See GuangZhou, which has identical framing but with different bit definitions.
DirecTV_3FG
{38k,600,msb}<1,-1|1,-2|2,-1|2,-2>(10,-2,(D:4,F:8,C:4,1,-30m,5,-2)*){C=7*(F:2:6)+5*(F:2:4)+3*(F:2:2)+(F:2)}[D:0..15,F:0..255]
uei-executor: 0162[D;F]
There are six variants of the DirecTV protocol, distinguished in RemoteMaster by the parameter "Parm" on the Setup page. The Parm value is shown in the Misc field of DecodeIR. The IRP notation above corresponds to the default Parm=3. The various Parm values correspond to three different frequencies (the 38k in the above) and two different lead-out times (the -50 in the above). The corresponding values are:
  • Parm=0 : 40k, -15
  • Parm=1 : 40k, -50
  • Parm=2 : 38k, -15
  • Parm=3 : 38k, -50
  • Parm=4 : 57k, -15
  • Parm=5 : 57k, -50
DirecTV_P0
{40k,600,msb}<1,-1|1,-2|2,-1|2,-2>([10][5],-2,D:4,F:8,C:4,1,-15){C=7*(F:2:6)+5*(F:2:4)+3*(F:2:2)+(F:2)}[D:0..15,F:0..255]
uei-executor:
min-leadout: 7000
frequency-tolerance: 1000
There are six variants of the DirecTV protocol, distinguished in RemoteMaster by the parameter "Parm" on the Setup page. The Parm value is shown in the Misc field of DecodeIR. The IRP notation above corresponds to the default Parm=3. The various Parm values correspond to three different frequencies (the 38k in the above) and two different lead-out times (the -50 in the above). The corresponding values are:
  • Parm=0 : 40k, -15
  • Parm=1 : 40k, -50
  • Parm=2 : 38k, -15
  • Parm=3 : 38k, -50
  • Parm=4 : 57k, -15
  • Parm=5 : 57k, -50
DirecTV_P1
{40k,600,msb}<1,-1|1,-2|2,-1|2,-2>([10][5],-2,D:4,F:8,C:4,1,-50){C=7*(F:2:6)+5*(F:2:4)+3*(F:2:2)+(F:2)}[D:0..15,F:0..255]
uei-executor:
frequency-tolerance: 1000
prefer-over: DirecTV_P0
There are six variants of the DirecTV protocol, distinguished in RemoteMaster by the parameter "Parm" on the Setup page. The Parm value is shown in the Misc field of DecodeIR. The IRP notation above corresponds to the default Parm=3. The various Parm values correspond to three different frequencies (the 38k in the above) and two different lead-out times (the -50 in the above). The corresponding values are:
  • Parm=0 : 40k, -15
  • Parm=1 : 40k, -50
  • Parm=2 : 38k, -15
  • Parm=3 : 38k, -50
  • Parm=4 : 57k, -15
  • Parm=5 : 57k, -50
DirecTV_P2
{38k,600,msb}<1,-1|1,-2|2,-1|2,-2>([10][5],-2,D:4,F:8,C:4,1,-15){C=7*(F:2:6)+5*(F:2:4)+3*(F:2:2)+(F:2)}[D:0..15,F:0..255]
uei-executor:
min-leadout: 7000
frequency-tolerance: 1000
There are six variants of the DirecTV protocol, distinguished in RemoteMaster by the parameter "Parm" on the Setup page. The Parm value is shown in the Misc field of DecodeIR. The IRP notation above corresponds to the default Parm=3. The various Parm values correspond to three different frequencies (the 38k in the above) and two different lead-out times (the -50 in the above). The corresponding values are:
  • Parm=0 : 40k, -15
  • Parm=1 : 40k, -50
  • Parm=2 : 38k, -15
  • Parm=3 : 38k, -50
  • Parm=4 : 57k, -15
  • Parm=5 : 57k, -50
DirecTV_P3
{38k,600,msb}<1,-1|1,-2|2,-1|2,-2>([10][5],-2,D:4,F:8,C:4,1,-50){C=7*(F:2:6)+5*(F:2:4)+3*(F:2:2)+(F:2)}[D:0..15,F:0..255]
frequency-tolerance: 1000
prefer-over: DirecTV_P2
uei-executor:
There are six variants of the DirecTV protocol, distinguished in RemoteMaster by the parameter "Parm" on the Setup page. The Parm value is shown in the Misc field of DecodeIR. The IRP notation above corresponds to the default Parm=3. The various Parm values correspond to three different frequencies (the 38k in the above) and two different lead-out times (the -50 in the above). The corresponding values are:
  • Parm=0 : 40k, -15
  • Parm=1 : 40k, -50
  • Parm=2 : 38k, -15
  • Parm=3 : 38k, -50
  • Parm=4 : 57k, -15
  • Parm=5 : 57k, -50
DirecTV_P4
{57k,600,msb}<1,-1|1,-2|2,-1|2,-2>([10][5],-2,D:4,F:8,C:4,1,-15){C=7*(F:2:6)+5*(F:2:4)+3*(F:2:2)+(F:2)}[D:0..15,F:0..255]
uei-executor:
min-leadout: 7000
frequency-tolerance: 1000
There are six variants of the DirecTV protocol, distinguished in RemoteMaster by the parameter "Parm" on the Setup page. The Parm value is shown in the Misc field of DecodeIR. The IRP notation above corresponds to the default Parm=3. The various Parm values correspond to three different frequencies (the 38k in the above) and two different lead-out times (the -50 in the above). The corresponding values are:
  • Parm=0 : 40k, -15
  • Parm=1 : 40k, -50
  • Parm=2 : 38k, -15
  • Parm=3 : 38k, -50
  • Parm=4 : 57k, -15
  • Parm=5 : 57k, -50
DirecTV_P5
{57k,600,msb}<1,-1|1,-2|2,-1|2,-2>([10][5],-2,D:4,F:8,C:4,1,-50){C=7*(F:2:6)+5*(F:2:4)+3*(F:2:2)+(F:2)}[D:0..15,F:0..255]
uei-executor:
frequency-tolerance: 1000
prefer-over: DirecTV_P4
There are six variants of the DirecTV protocol, distinguished in RemoteMaster by the parameter "Parm" on the Setup page. The Parm value is shown in the Misc field of DecodeIR. The IRP notation above corresponds to the default Parm=3. The various Parm values correspond to three different frequencies (the 38k in the above) and two different lead-out times (the -50 in the above). The corresponding values are:
  • Parm=0 : 40k, -15
  • Parm=1 : 40k, -50
  • Parm=2 : 38k, -15
  • Parm=3 : 38k, -50
  • Parm=4 : 57k, -15
  • Parm=5 : 57k, -50
Dish_Network
{57.6k,406}<1,-7|1,-4>(1,-15,(F:-6,S:5,D:5,1,-15)+) [F:0..63,S:0..31,D:0..31]
uei-executor: 0002[S+1,D;F]
uei-executor: 0002:2[S+1,D;F]
uei-executor: 0002:3[S+1,D;F]
uei-executor: 0002:5(Dish Network)[D?0,D?1,D?2,D?3,S+1;??,F]
uei-executor: 0002:5(Dish Network Combo)[D?0,D?1,D?2,D?3,S+1;??,F]
uei-executor: 0002:6(Dish Network Combo)[D?0,D?1,D?2,D?3,S+1;??,F]
This is not a robust protocol, so spurious decodes are likely. See this thread for a discussion.
Dishplayer
{38.4k,535,msb}<1,-5|1,-3>(1,-11,(F:6,S:5,D:2,1,-11)+) [F:0..63,S:0..31,D:0..3]
uei-executor: 010F[D,S;F]
This is not a robust protocol, so spurious decodes are likely.
Dysan
{780,38k}<1,-1|1,-2>(3,-1,D:7,F:8,1,-104m)* [D:0..127,F:0..255]
Elan
{0k,398,msb}<1,-1|1,-2>(3,-2,D:8,~D:8,2,-2,F:8,~F:8,1,^50m)* [D:0..255,F:0..255]
uei-executor: 01F8[D;F]
See the JP1-forum thread.
Elunevision
{0k,358,msb}<1,-3|3,-1>(10,-3,D:24,F:8,-7)*{D=0xf48080} [F:0..255]
Elunevision Luna motorized projector screen remote. Posting on Lirc mailing list.
Emerson
{36.7k,872}<1,-1|1,-3>(4,-4,D:6,F:6,~D:6,~F:6,1,-39)* [D:0..63,F:0..63]
uei-executor: 0065[D?0,D?1,D?2;??,F]
uei-executor: 0065:2[D?0,D?1,D?2,D?3;??,F]
uei-executor: 0065:old
prefer-over: Sampo
prefer-over: ScAtl-6
entone
{36k,444,msb}<-1,1|1,-1>(6,-2,1:1,M:3,<-2,2|2,-2>(T:1),0xE60396FFFFF:44,F:8,0:4,-131.0m)*{M=6,T=0}[F:0..255]
prefer-over: RC6-M-56
A special case of the RC6-M-56 protocol, used in the Entone Amulet. See this forum thread.
Epson
{38.4k,577}<2,-1|1,-2|1,-1|2,-2>((4,-1,D:8,T1:2,OBC:6,T2:2,S:8,1,-75m)*,(4,-1,D:8,~F1:2,OBC:6,~F2:2,S:8,1,-250m)) [D:0..255,S:0..255,OBC:0..63,T1:0..3,T2:0..3,F1:0..3,F2:0..3]
Forum thread
F12
{37.9k,422}<1,-3|3,-1>((D:3,S:1,F:8,-80)2)* [D:0..7,S:0..1,F:0..255]
prefer-over: F12_relaxed
uei-executor: 001A[D;F]
Old version of the F12 specification.
F12-0
{37.9k,422}<1,-3|3,-1>(D:3,H:1,F:8,-34,D:3,H:1,F:8) {H=0} [D:0..7,F:0..0xFF]
Taken from DecodeIR, case H=0.
F12-1
{37.9k,422}<1,-3|3,-1>(D:3,H:1,F:8,-34,D:3,H:1,F:8,-88,D:3,H:1,F:8,-34,D:3,H:1,F:8)* {H=1} [D:0..7,F:0..0xFF]
Taken from DecodeIR, case H=1.
F12_relaxed
{37.9k,422}<1,-3|3,-1>(D:3,S:1,F:8,-80)* [D:0..7,S:0..1,F:0..255]
uei-executor:
minimum-leadout: 6000
Relaxed version of the F12 specification.
F32
{37.9k,422,msb}<1,-3|3,-1>(D:8,S:8,F:8,E:8,-100m)* [D:0..255,S:0..255,F:0..255,E:0..255]
The meaning of the 32 bits of data is unknown, and the assignment to D, S, F, and E is arbitrary.
Fujitsu
{37k,432}<1,-1|1,-3>(8,-4,20:8,99:8,0:4,E:4,D:8,S:8,F:8,1,-110)* [D:0..255,S:0..255=D,F:0..255,E:0..15=0]
uei-executor: 00F8[D;F,S]
uei-executor: 00F8:2[D;F,S]
uei-executor: 00F8:3[D;F,S]
Fujitsu is the member of the Kaseikyo family with OEM_code1=20 and OEM_code2=99. There is no checksum, so the risk of an incorrect decode is much higher than in other Kaseikyo protocols.
Fujitsu-128
{38.4k,413}<1,-1|1,-3>(8, -4, A0:8, A1:8, A2:8, A3:8, A4:8, A5:8, A6:8, A7:8, A8:8, A9:8, A10:8, A11:8, A12:8, A13:8, A14:8, A15:8, 1, -104.3m)* [A0:0..255, A1:0..255, A2:0..255, A3:0..255, A4:0..255, A5:0..255, A6:0..255, A7:0..255, A8:0..255, A9:0..255, A10:0..255, A11:0..255, A12:0..255, A13:0..255, A14:0..255, A15:0..255]
Fujitsu-56
{37k,432}<1,-1|1,-3>(8,-4,20:8,99:8,0:4,E:4,D:8,S:8,X:8,F:8,1,-110)* [D:0..255,S:0..255=D,F:0..255,E:0..15=0,X:0..255=0]
Fujitsu_Aircon
{38.4k,413}<1,-1|1,-3> (8, -4, A0:8, A1:8, A2:8, A3:8, A4:8, A5:8, A6:8, A7:8, wOn:4, A:4, B:4, C:4, D:4, E:4, tOff:11, fOff:1, tOn:11, fOn:1, A14:8, A15:8, 1, -104.3m)* {A0=20, A1=99, A2=0, A3=16, A4=16, A5=254, A6=9, A7=48, A14=32, A15=256 -(16*A+wOn+(16*C+B)+(16*E+D)+tOff:8+(tOff:3:8+fOff*8+16*tOn:4)+(tOn:7:4+128*fOn)+80)%256} [A:0..15, B:0..15, C:0..15, D:0..15, E:0..15, fOff:0..1, fOn:0..1, tOff:0..1024, tOn:0..1024, wOn:0..1]
prefer-over: Fujitsu-128
Protocol for Fujitsu inverter air conditioning. RemoteCentral thread. This version is a re-parametrization of 3FG's version, allowing for decoding.
Fujitsu_Aircon_old
Fujitsu-128 {A0=20, A1=99, A2=0, A3=16, A4=16, A5=254, A6=9, A7=48, A8=16*A + wOn, A9=16*C + B, A10=16*E:4 + D:4, A11=tOff:8, A12=tOff:3:8+fOff*8+16*tOn:4, A13=tOn:7:8+128*fOn, A14=32, A15=256 -(A8+A9+A10+A11+A12+A13+80)%256} [A:0..15, wOn:0..1, B:0..15, C:0..15, D:0..15, E:0..15, tOff:0..1024, tOn:0..1024, fOff:0..1, fOn:0..1]
decodable: false
Protocol for Fujitsu inverter air conditioning. RemoteCentral thread.
G.I.4DTV
{37.3k,992}<1,-1|1,-3>(5,-2,F:6,D:2,C0:1,C1:1,C2:1,C3:1,1,-60)* { C0=D:1:2 + #(F&25) + #(D&1), C1=D:1:2 + #(F&43) + #(D&3), C2=D:1:2 + #(F&22) + #(D&3), C3=D:1:2 + #(F&44) + #(D&2) }[D:0..7, F:0..63]
prefer-over: G.I.4DTV_relaxed
uei-executor: 00A4[D;F]
This is a moderately robust protocol, but spurious decodes are still possible. Unit (device) numbers from 0 to 7 are supported. The check sum C is a Hamming Code, which can correct single bit errors. D:1:2 is encoded in the checksum. See forum thread.
G.I.4DTV_relaxed
{37.3k,992}<1,-1|1,-3>(5,-2,F:6,D:2,C:4,1,-60)*[D:0..3, F:0..63, C:0..15]
Relaxed version of G.I.4DTV — the checksum is not checked but considered a parameter.
G.I.Cable
{38.7k,490}<1,-4.5|1,-9>(18,-9,F:8,D:4,C:4,1,-84,(18,-4.5,1,-178)*){C = -(D + F:4 + F:4:4)} [D:0..15,F:0..255]
alt_name: GI Cable
uei-executor: 00C4
GI RG
{37.3k,1000, msb}<1,-1|1,-3>(5,-3,F:6,S:2,D:8,1,-60)*[D:0..255, S:0..3, F:0..63]
uei-executor: 0177
This is a moderately robust protocol, but spurious decodes are still possible. Typical usage is the GI/Next Level/Motorola RC2x00 series.
Grundig16
{35.7k,578,msb}<-4,2|-3,1,-1,1|-2,1,-2,1|-1,1,-3,1>(806u,-2960u,1346u,T:1,F:8,D:7,-100)*[D:0..127,F:0..255,T@:0..1=0]
uei-executor: 0112[D:6,F>127;D:1:6,F]
These are two variants of the same protocol, differing only in frequency. The IRP notation is corrected from previous versions of this document, to make it consistent with DecodeIR.
Grundig16-30
{30.3k,578,msb}<-4,2|-3,1,-1,1|-2,1,-2,1|-1,1,-3,1>(806u,-2960u,1346u,T:1,F:8,D:7,-100)* [D:0..127,F:0..255,T:0..1]
See Grundig16
GuangZhou
{38.0k,182}<3,-3|3,-6>(20,-10,T:2,D:6,F:8,S:8,20,-10,~T:2,D:6,~F:8,3,^108m,(20,-20,3,^108m)*){T=3} [D:0..63,F:0..255,S:0..255]
Forum thread.
GwtS
{38.005k,417,lsb}<1|-1>(0:1,D:8,1:2,F:8,1:2,CRC:8,1:1)[D:0..255=144,F:0..255,CRC:0..255]

Protocol for Disney's Glow with the Show Hat/Ears, see forum thread. Unfortunately, the IRP engine cannot compute the CRC, but the user has to enter it as a parameter.

The known commands are, together with their F and CRC values, as follows:

Name F CRC
off 0x60 166
blue 0x61 248
green 0x62 26
cyan 0x63 68
red 0x64 199
magenta 0x65 153
yellow 0x66 123
white 0x67 37
off_r 0x68 100
blue_r 0x69 58
green_r 0x6A 216
cyan_r 0x6B 134
red_r 0x6C 5
magenta_r 0x6D 91
yellow_r 0x6E 185
white_r 0x6F 231
GXB
{38.3k,520,msb}<1,-3|3,-1>(1,-1,D:4,F:8,P:1,1,^100m)*{P=1-#F%2}[D:0..15,F:0..255]
uei-executor: 01FF:JP1GXB[;D,F]
Decoder for a nonstandard Xbox remote.
Humax 4Phase
{56k,105, msb}<-2,2|-3,1|1,-3|2,-2>(T=0,(2,-2,D:6,S:6,T:2,F:7,~F:1,^95m,T=1)+) [D:0..63, S:0..63, F:0..127]
absolute-tolerance: 50
relative-tolerance: 0.1
uei-executor: 01DD
Forum thread.
InterVideo RC-201
{38k,300}<1,-1|1,-3>(10,-5,0:1,F:6,768:10,1,-10m)* [F:0..63]
Used by a remote marked as InterVideo RC-201 that is paired with a USB HID receiver simply marked as RC-201. Exact carrier frequency not known.
IODATAn
{38k,550}<1,-1|1,-3>(16,-8,x:7,D:7,S:7,y:7,F:8,C:4,1,^108m)* {n = F:4 ^ F:4:4 ^ C:4} [D:0..127,S:0..127,F:0..255,C:0..15=0,x:0..127=0,y:0..127=0]
alt_name: IODATAn-x-y
uei-executor: 01FF:JP1IOD[D,S,F:4^F:4:4^C:4,x,y;F]
This is potentially a class of protocols distinguished by values of n, x and y with n = 0..15 and x, y = 0..127. If x and y are both zero, they are omitted. The only known example is IODATA1.
Jerrold
{0k,44}<1,-7.5m|1,-11.5m>(F:5,1,-23.5m)* [F:0..31]
uei-executor: 0006
This is not a robust protocol, so spurious decodes are likely.
JVC
{37.9k,527,33%}<1,-1|1,-3>(16,-8,D:8,F:8,1,^59.08m,(D:8,F:8,1,^46.42m)*) [D:0..255,F:0..255]
uei-executor: 0034
prefer-over: JVC_alt
JVC{2} indicates a JVC signal from which the lead-in is missing. The JVC protocol has lead-in on only the first frame, so it is quite easy to have it missing from a learned signal. So when JVC{2} is correct, it means the same as JVC. It is very similar in structure and timing to Mitsubishi protocol. JVC documentation.
JVC-48
{37k,432}<1,-1|1,-3>(8,-4,3:8,1:8,D:8,S:8,F:8,(D^S^F):8,1,-173)* [D:0..255,S:0..255,F:0..255]
uei-executor: 00C9
uei-executor: 001F[D&239,S&254,3,1;D:1:4,S:1,F]
uei-executor: 001F:8(Panasonic VCR Combo)[D&239,S&254,3,1;D:1:4,S:1,F]
uei-executor: 001F:8(Panasonic Mixed Combo;; D.S=0.0,0.1,0.2,0.3.0.4,1.0,1.1,1.2,1.3,1.4,2.0,2.2,2.3,2.4,3.0,3.3,3.4,4.0,4.4,5.0) [D?0D,D?1D|||S?0S,D?2D|||S?1S,D?3D|||S?2S,D?4D|||S?3S,D?5D|||S?4S,3,1;??D,??S,F]
uei-executor: 01C9[;D,S,F]
JVC-48 is the member of the Kaseikyo family with OEM_code1=3 and OEM_code2=31.
JVC-56
{37k,432}<1,-1|1,-3>(8,-4,3:8,1:8,D:8,S:8,X:8,F:8,(D^S^X^F):8,1,-173)*[D:0..255,S:0..255,F:0..255,X:0..255]
JVC_alt
{37.9k,527,33%}<1,-1|1,-3>(16,-8,(D:8,F:8,1,^46.42m)*) [D:0..255,F:0..255]
uei-executor: 0034
reject-repeatless: true
This is a version of the JVC protocol for signals that has been (too much) reduced by the repeat finder.
JVC{2}
{37.9k,527,33%}<1,-1|1,-3>(D:8,F:8,1,^46.42m)* [D:0..255,F:0..255]
uei-executor: 0034
See JVC.
Kaseikyo
{37k,432}<1,-1|1,-3>(8,-4,M:8,N:8,X:4,D:4,S:8,F:8,E:4,C:4,1,-173)* {X=((M^N)::4)^(M^N), chksum=D^S^F^(E*16), C=chksum::4 ^ chksum}[D:0..15,S:0..255,F:0..255,E:0..15,M:0..255,N:0..255]
relative-tolerance: 0.035
uei-executor: 00F8:3{Z=D^S^F^(E*16),C=Z::4^Z,G=(C<<4)|E}[M,N,D,S;F,G]
This is the nominal form of the Kaseikyo protocol.
Kaseikyo56
{37k,432}<1,-1|1,-3>(8,-4,M:8,N:8,H:4,D:4,S:8,E:8,F:8,G:8,1,-173)* {H=((M^N)::4)^(M^N), chksum=S^G^F^(E*16)^D, C=chksum::4 ^ chksum}[D:0..15,S:0..255,F:0..255,G:0..255,M:0..255,N:0..255,E:0..255]
relative-tolerance: 0.04
Kaseikyo56 is a lengthened version of the Kaseikyo family of protocols. It has the same OEM codes indicating the same manufacturers as Kaseikyo, and it has the same variation (by manufacturer) in check byte and other details as Kaseikyo.
Kathrein
{38k,540}<1,-1|1,-3>(16,-8,D:4,~D:4,F:8,~F:8,1,^105m,(16,-8,F:8,1,^105m)+)[D:0..15,F:0..255]
uei-executor: 0066
This protocol signals repeats by the use of dittos. It is unusual in that the ditto frame carries part of the signal data, specifically F. Similar to Logitech, but both decodes give the same device number and OBC.
Konka
{38k,500,msb}<1,-3|1,-5>(6,-6,D:8,F:8,1,-8,1,-46)* [D:0..255,F:0..255]
uei-executor: 019B
Logitech
{38k,127}<3,-4|3,-8>(31,-36,D:4,~D:4,F:8,~F:8,3,-50m)*[D:0..15,F:0..255]
This protocol is used with Logitech's PS3 adapter. Similar to Kathrein.
Lumagen
{38.4k,416,msb}<1,-6|1,-12>(D:4,C:1,F:7,1,-26)* {C = (#F+1)&1} [D:0..15,F:0..127]
uei-executor: 01FF:JP1Luma
Lutron
{40k,2300,msb}<-1|1>(255:8,X:24,0:4)*[X:0..0xFFFFFF]
From the DecodeIR documentation:
This is an unusual protocol in that an 8-bit device code and 8-bit OBC are encoded in a 24-bit error-correcting code as the X of the IRP notation. This is constructed as follows. First two parity bits are appended to the 16 data bits to give even parity for the two sets of 9 bits taken alternately. The resulting 18-bit sequence is then treated as 6 octal digits (0-7) expressed in 3-bit binary code. These are then re-coded in the 3-bit Gray code (also called, more descriptively, the reflected-binary code) with a parity bit to give odd parity, so giving 6 4-bit groups treated as a single 24-bit sequence. The whole thing allows any single-bit error in transmission to be identified and corrected.
Matsui
{38k,525}<1,-1|1,-3>(D:3,F:7,1,^30.5m)* [D:0..7,F:0..127]
This is not a robust protocol, so spurious decodes are likely.
MCE
{36k,444,msb}<-1,1|1,-1>((6,-2,1:1,6:3,-2,2,OEM1:8,S:8,T:1,D:7,F:8,^107m)*,T=1-T) {OEM1=128}[D:0..127,S:0..255,F:0..255,T@:0..1=0]
prefer-over: RC6-M-32
alt_name: RC6-6-32
uei-executor: 012A:2[D,S;F]
uei-executor: 012A[D,S;F]
MCE is a member of the RC6 family. Technically it is RC6-6-32 with the standard toggle bit zero, with the OEM1 field equal to 128, and with a nonstandard (for the RC6 family) toggle bit added.
MCIR-2-kbd
{300,msb}<-1,1|1,-1>(9,32:8,C:5,0:8,F:8,M:8,-74m)* {c1 = #(F & 0b11111000) % 2, c2 = (#(F & 0b00000111) + #(M & 0b00110000)) % 2, c3 = (#(F & 0b11000111) + #(M & 0b10001110)) % 2, c4 = (#(F & 0b00110110) + #(M & 0b10101101)) % 2, c5 = (#(F & 0b10101101) + #(M & 0b10011011)) % 2, C = (c1 << 4) | (c2 << 3) | (c3 << 2) | (c4 << 1) | c5 } [F:0..255,M:0..255]
A RC6-ish keyboard IR protocol used by the Microsoft Remote Keyboard for Windows Media Center Edition, referred to by Microsoft's Windows Media Center remote specification docs as "an internal protocol called MCIR-2". See HiFi-Remote thread and Linux media driver.
MCIR-2-mouse
{300,msb}<-1,1|1,-1>(9,8:8,C:5,y:7,x:7,R:1,L:1,F:5,-10.7m)* [C:0..31,L:0..1,R:0..1,x:0..127,y:0..127,F:0..31]
A RC6-ish mouse IR protocol used by the Microsoft Remote Keyboard for Windows Media Center Edition, referred to by Microsoft's Windows Media Center remote specification docs as "an internal protocol called MCIR-2". See HiFi-Remote thread and Linux media driver.
Metz19
{37.9k,106,msb}<4,-9|4,-16>((8,-22,T:1,D:3,~D:3,F:6,~F:6,4,-125m)*,T=1-T)[D:0..7,F:0..63,T@:0..1=0]
uei-executor: 01FF:JP1Metz
The toggle bit T is inverted each time a new button press occurs.
Mitsubishi
{32.6k,300}<1,-3|1,-7>(D:8,F:8,1,-80)* [D:0..127,F:0..255]
uei-executor: 0014[D;F]
uei-executor: 01A4[D;F]
This is not a robust protocol, so spurious decodes are likely. It is also very similar in structure and timing to JVC{2} protocol.
Mitsubishi-K
{37k,432}<1,-1|1,-3>(8,-4,35:8,203:8,X:4,D:8,S:8,F:8,T:4,1,-100)* {X=6,T=-S:4:0-S:4:4-F:4:0-F:4:4+15}[D:0..255,F:0..255, S:0..255]
Mitsubishi-K is the member of the Kaseikyo family with OEM_code1=35 and OEM_code2=203.
NEC
{38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,^108m) [D:0..255,S:0..255=255-D,F:0..255]
prefer-over: NEC-Shirriff-32
prefer-over: NEC-f16
prefer-over: NEC1-f16
prefer-over: NEC2-f16
prefer-over: NEC1-rnc
prefer-over: Roku
decode-only: true
uei-executor: 005A(NEC1)
uei-executor: 005A(NEC2)
uei-executor: 01AD[;D,S,F:8,~F:8]
Inspired by DecodeIR, we call a NEC signal without repeat "NEC". This decode normally indicates an incomplete learn.
NEC-f16
{38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,E:8,1,^108m) [D:0..255,S:0..255=255-D,F:0..255,E:0..255=255-F]
prefer-over: NEC-Shirriff-32
A relaxed form (but used in some real devices) of the NEC protocol. Byte 3 and byte 4 are independent.
NEC-Shirriff
{38.4k,msb,564}<1,-1|1,-3>(16,-8,data:length,1,-1) [data:0..UINT32_MAX,length:1..64]
decodable: false
Like NEC1 but without repeat, just one large parameter, and msb bit order, no ending silence, and undetermined payload length. This is how NEC protocols are referred to in the Arduino IRremote project, originated by Ken Shirriff.
NEC-Shirriff-32
{38.4k,msb,564}<1,-1|1,-3>(16,-8,data:32,1,-1) [data:0..UINT32_MAX]
The NEC-Shirriff protocol with payload length set to 32, making it viable for decoding.
NEC1
{38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,^108m,(16,-4,1,^108m)*) [D:0..255,S:0..255=255-D,F:0..255]
prefer-over: NEC1-rnc
prefer-over: Pioneer
reject-repeatless: true
uei-executor: 005A
uei-executor: 011A[D?0,S?0,D?1,S?1;F,??,0]
uei-executor: 011A:2[D?0,S?0,D?1,S?1,D?2,S?2,D?3,S?3;F,??,0]
uei-executor: 017E[D,S?0,S?1,S?2,S?3;??,,F,0]
uei-executor: 0246[D,S?0,S?1,S?2,S?3,S?4,S?5;??,,F,0]
uei-executor: 00B6[D;S,F]
uei-executor: 00B6:JP1[D,0;S,F]
uei-executor: 01AD[;D,S,F:8,~F:8]
The most commonly used version of the NEC protocol, repeating with dittos. Tutorial.
NEC1-f16
{38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,E:8,1,^108m,(16,-4,1,^108m)*) [D:0..255,S:0..255=255-D,F:0..255,E:0..255=255-F]
prefer-over: NEC-Shirriff-32
prefer-over: NEC-f16
reject-repeatless: true
uei-executor: 01AD[;D,S,F:8,E:8]
uei-executor: 01BA[D,S;F:8,E:8]
uei-executor: 01AD[;D,S,F:8,E:8]
A relaxed form (but used in some real devices) of the NEC1 protocol. Byte 3 and byte 4 are independent.
NEC1-rnc
{38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:4:4,~F:4,1,^108m,(16,-4,1,^108m)*) [D:0..255,S:0..255=255-D,F:0..255]
prefer-over: NEC1-f16
prefer-over: NEC-Shirriff-32
uei-executor: 0206
Variant of the NEC1 protocol with the checksum in byte 4 different.
NEC2
{38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,^108m)* [D:0..255,S:0..255=255-D,F:0..255]
prefer-over: NEC
prefer-over: NEC-Shirriff-32
prefer-over: NEC2-f16
reject-repeatless: true
uei-executor: 005A
uei-executor: 011A[D?0,S?0,D?1,S?1;F,??,1]
uei-executor: 011A:2[D?0,S?0,D?1,S?1,D?2,S?2,D?3,S?3;F,??,1]
uei-executor: 017E[D,S?0,S?1,S?2,S?3;??,,F,1]
uei-executor: 0246[D,S?0,S?1,S?2,S?3,S?4,S?5;??,,F,1]
uei-executor: 00B6:JP1[D,1;S,F]
A variant of the NEC protocol, that repeats by repeating the whole intro sequence. Pioneer is distinguished from NEC2 only by frequency.
NEC2-f16
{38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,E:8,1,^108m)* [D:0..255,S:0..255=255-D,F:0..255,E:0..255=255-F]
prefer-over: NEC-Shirriff-32
reject-repeatless: true
A relaxed form (but used in some real devices) of the NEC2 protocol. Byte 3 and byte 4 are independent.
NECx1
{38.4k,564}<1,-1|1,-3>(8,-8,D:8,S:8,F:8,~F:8,1,^108m,(8,-8,D:1,1,^108m)*) [D:0..255,S:0..255=255-D,F:0..255]
uei-executor: 005A
uei-executor: 011A[D?0,S?0,D?1,S?1;F,??,2]
uei-executor: 011A:2[D?0,S?0,D?1,S?1,D?2,S?2,D?3,S?3;F,??,2]
NECx2
{38.4k,564}<1,-1|1,-3>(8,-8,D:8,S:8,F:8,~F:8,1,^108m)* [D:0..255,S:0..255=255-D,F:0..255]
uei-executor: 005A
uei-executor: 011A[D?0,S?0,D?1,S?1;F,??,3]
uei-executor: 011A:2[D?0,S?0,D?1,S?1,D?2,S?2,D?3,S?3;F,??,3]
Nokia
{36k,1p,msb}<6,-10|6,-16|6,-22|6,-28>(15,-10,D:8,S:8,F:8,6,^100m)* [D:0..255,S:0..255,F:0..255]
relative-tolerance: 0.04
uei-executor: 00ED[D,S;F]
Nokia12
{36k,1p,msb}<6,-10|6,-16|6,-22|6,-28>(15,-10,D:4,F:8,6,^100m)*[D:0..15,F:0..255]
relative-tolerance: 0.04
Nokia32
{36k,1p,msb}<6,-10|6,-16|6,-22|6,-28>((15,-10,D:8,S:8,T:1,X:7,F:8,6,^100m)*,T=1-T) [D:0..255,S:0..255,F:0..255,T@:0..1=0,X:0..127]
absolute-tolerance: 50
relative-tolerance: 0.04
uei-executor: 0173:1[D,S,X;F]
uei-executor: 0173:3[D,S,X;F]
uei-executor: 01E1:2[D,S;F,X]
The Nokia32 protocol is one variation of the RCMM 1.5 protocol developed by Philips. RCMM refers to X as "System" and to D:2,S:4:4 as "Customer". The parameters have been taken from SB-projects.
Nova Pace
{38k, 300, msb}<-1,1|1,-1>((1,-1,D:10, S:8, F:8, T:1, -1, 1,-82m)*,T=1-T) [D:0..1023,S:0..255,F:0..255,T@:0..1=0]
Forum thread.
NRC16
{38k,500}<-1,1|1,-1>(1,-5,1:1,254:8,127:7,-15m,(1,-5,1:1,F:8,D:7,-110m)+,1,-5,1:1,254:8,127:7,-15m) [D:0..127,F:0..255]
uei-executor: 00B0[D,F>127;F]
NRC16-32
{32k,500}<-1,1|1,-1>(1,-5,1:1,254:8,127:7,-15m,(1,-5,1:1,F:8,D:7,-110m)+,1,-5,1:1,254:8,127:7,-15m) [D:0..127,F:0..255]
uei-executor: 0075[D,F>127;F]
NRC17
{500,38k,25%}<-1,1|1,-1>(1,-5,1:1,254:8,255:8,-28, (1,-5,1:1,F:8,D:8,-220)*, 1,-5,1:1,254:8,255:8,-200)[D:0..255,F:0..255]
uei-executor: 00BD:2[D;F]
uei-executor: 00BD[D,F>127;F]
Taken from John Fine's contribution (fixed), modified for the setup here.
Ortek_NEClike
{40.0k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,F:4:4,~F:4,1,^108m,(16,-4,1,-3,1,^108m)*)[D:0..255,S:0..255,F:0..255]
See this thread.
OrtekMCE
{38.6k,480}<1,-1|-1,1>([P=0][P=1][P=2],4,-1,D:5,P:2,F:6,C:4,-48m)+{C=3+#D+#P+#F}[D:0..31,F:0..63]
uei-executor: 021B:JP1
The repeat sequences are not all identical. P is a position code: 0 for the start frame of a repeat sequence, 2 for the end frame and 1 for all frames in between. C is a checksum, 3 more than the number of 1 bits in D, P, F together.
OrtekMCE_relaxed
{38.6k,480}<1,-1|-1,1>([][P=1][P=2],4,-1,D:5,P:2,F:6,C:4,-48m)+{C=3+#D+#P+#F}[D:0..31,F:0..63]
uei-executor:
This is a relaxed version of the OrtekMCE protocol, in that it lacks the intro sequence.
PaceMSS
{38k,630,msb}<1,-7|1,-11>(1,-5,1,-5,T:1,D:1,F:8,1,^120m)* [D:0..1,F:0..255,T:0..1]
alt_name: Pace
uei-executor: 0095[D;F]
This is a moderately robust protocol, but spurious decodes are still possible.
Panasonic
{37k,432}<1,-1|1,-3>(8,-4,2:8,32:8,D:8,S:8,F:8,(D^S^F):8,1,-173)* [D:0..255,S:0..255,F:0..255]
uei-executor: 00C9
uei-executor: 001F[D&239,S&254,2,32;~D:1:4,S:1,F]
uei-executor: 001F:8(Panasonic VCR Combo)[D&239,S&254,2,32;~D:1:4,S:1,F]
uei-executor: 001F:8(Panasonic Mixed Combo;; D.S=0.0,0.1,0.2,0.3.0.4,1.0,1.1,1.2,1.3,1.4,2.0,2.2,2.3,2.4,3.0,3.3,3.4,4.0,4.4,5.0) [D?0D,D?1D|||S?0S,D?2D|||S?1S,D?3D|||S?2S,D?4D|||S?3S,D?5D|||S?4S,2,32;??D,??S,F]
uei-executor: 00CD:2[D;S,F]
uei-executor: 00CD:JP1[D;S,F]
prefer-over: Kaseikyo
Panasonic protocol is the most commonly seen member of the Kaseikyo family.
Panasonic2
{37k,432}<1,-1|1,-3>(8,-4,2:8,32:8,D:8,S:8,X:8,F:8,(D^S^X^F):8,1,-173)* [D:0..255,S:0..255,F:0..255,X:0..255]
uei-executor: 0109[D,S,X;F]
prefer-over: Kaseikyo56
Panasonic_Old
{57.6k,833}<1,-1|1,-3>(4,-4,D:5,F:6,~D:5,~F:6,1,-44m)* [D:0..31,F:0..63]
uei-executor: 0000[D?0,D?1,D?2;??,F]
PCTV
{38.4k,832}<-1|1>(2,-8,1,D:8,F:8,2,-100m) [D:0..255,F:0..255]
pid-0001
{0k,msb}<24,-9314|24,-13486>(24,-21148,(F:5,1,-28m)+)[F:0..31]
uei-executor: 0001
pid-0003
{40.2k,389}<2,-2|3,-1>(F:8,~F:8,^102m)*[F:0..255]
pid-0004
{0k,msb}<12,-130|12,-372>(F:6,12,-27m)*[F:0..63]
pid-0083
{42.3k, 3000}<1,-3,1,-7|1,-7,1,-3>(F:5,1,-27)*[F:0..31]
uei-executor: 0083
This protocol is a very limited design. We have seen it used only in the UEI setup code TV/0159, which is for some TVs brand named Fisher, Sanyo and Sears. It is not likely that any other code set uses this protocol. So if you get a correct decode of pid-0083 you probably have a TV that can be controlled by the TV/0159 setup code.
Pioneer
{40k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,^108m)* [D:0..255,S:0..255=255-D,F:0..255]
uei-executor: 00E2(;D==~S:8)[D;F]
uei-executor: 007E(;F:1:5==0)[D;0,0,0,F]
uei-executor: 007E:2(Pioneer DVD2;F:1:5==0)[D;F]
uei-executor: 007E:2(Pioneer MIX)[D;0,0,0,F]
uei-executor: 007E:3[D;0,0,0,F]
uei-executor: 007E:4[D?0,D?1,D?2,D?3;0,0,??,F]
uei-executor: 007E:5[D?0,D?1,D?2,D?3;0,0,??,F]
uei-executor: 005F[D;F,F]
uei-executor: 006A[D?0,D?1,D?2;??,F,F]
uei-executor: 006A:JP1[D?0,D?1,D?2,D?3;??,F,F]
prefer-over: (162<=D && D<=165) || D==168 || D==170 || D==173 || D==175 ; NEC2
frequency-lower: 39700
frequency-upper: 41000
Pioneer is distinguished from NEC2 only by frequency. So if your learning system does not learn frequency accurately, it won't accurately distinguish Pioneer from NEC2. All Pioneer signals should have a device number in the range 160 to 175 and no subdevice. No NEC2 signal should fit those rules. So you usually can determine whether the decision (by frequency) was wrong by checking the device numbers. Many Pioneer commands are sent as combinations of two different Pioneer signals, see Pioneer-Mix.
Pioneer-Mix
{40k,564}<1,-1|1,-3>(16,-8,D0:8,~D0:8,F0:8,~F0:8,1,^108m,(16,-8,D:8,~D:8,F:8,~F:8,1,^108m)+) [D0:0..255,F0:0..255,D:0..255=D0,F:0..255=F0]
uei-executor: 007E(;F:1:5==1)[D0,D,F0;1,1,1,F]
uei-executor: 007E:2(Pioneer DVD2;F:1:5==1)[D0,D,F0;F]
uei-executor: 007E:2(Pioneer MIX)[D0,D,F0?1,F0?2;1,??,1,F]
uei-executor: 007E:3[D0,D,F0?1,F0?2,F0?3,F0?4;1,??,1,F]
uei-executor: 007E:4[D0,F0?1,F0?2,F0?3,F0?4,D;1,??,4,F]
uei-executor: 007E:5(;;D.F=3.3,..)[D0,D?1D|||F0?1F,D?2D|||F0?2F,D?3D|||F0?3F,F0?4F,D?4D;1,??F,??D,F]
uei-executor: 005F(;D0==D)[D;F0,F]
uei-executor: 006A(;D0==D)[D?0,D?1,D?2;??,F0,F]
uei-executor: 006A(;D0==D)[D?0,D?1,D?2,D?3;??,F0,F]
prefer-over: (162<=D && D<=165) || D==168 || D==170 || D==173 || D==175 ; NEC2
prefer-over: (D0 != D) || (F0 != F) ; Pioneer
frequency-lower: 39700
frequency-upper: 41000
Two-signal version of the Pioneer protocol. First sends the "normal" signal (parameters D0 and F0) as intro, then, as repeat, the one determined by D and F.
Proton
{38.5k,500}<1,-1|1,-3>(16,-8,D:8,1,-8,F:8,1,^63m)*[D:0..255,F:0..255]
uei-executor: 005C[D;F]
uei-executor: 011B[0;D,F]
This is not a robust protocol, so spurious decodes are likely.
Proton-40
{40.5k,500}<1,-1|1,-3>(16,-8,D:8,1,-8,F:8,1,^63m)*[D:0..255,F:0..255]
uei-executor: 011B[1;D,F]
This is not a robust protocol, so spurious decodes are likely.
RC5
{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]
uei-executor: 00E8[D?0,F>63?0,D?1,F>63?1,D?2,F>63?2;??,F]
uei-executor: 01C3[0,D?0,F>63?0,D?1,F>63?1,D?2,F>63?2,D?3,F>63?3;??,F]
uei-executor: 0073[;0,F,D]
uei-executor: 0184:2[;0,D,F]
In Philips' (the creator of the protocol) terminology, "D" is called "System" and "F" is called "Command". Tutorial.
RC5-7F
{36k,msb,889}<1,-1|-1,1>((1, ~D:1:5,T:1,D:5,F:7,^114m)*,T=1-T) [D:0..63,F:0..127,T@:0..1=0]
prefer-over: StreamZap
uei-executor: 0182:2[D?0,D?1,0;??,F]
RC5-7F-57
{57k,msb,889}<1,-1|-1,1>(1, ~D:1:5,T:1,D:5,F:7,^114m)*[D:0..63,F:0..127,T@:0..1=0]
prefer-over: StreamZap-57
uei-executor: 0182:2[D?0,D?1,1;??,F]
uei-executor: 0182[D?0,D?1;??,F]
RC5x
{36k,msb,889}<1,-1|-1,1>((1,~S:1:6,T:1,D:5,-4,S:6,F:6,^114m)*,T=1-T) [D:0..31,S:0..127,F:0..63,T@:0..1=0]
uei-executor: 00F2[D,S>63;S,F]
uei-executor: 0073[D?0,F>63?0,D?1,F>63?1,D?2,F>63?2,D?3,F>63?3;1,F,,S]
relative-tolerance: 0.1
In Philips' (the creator of the protocol) terminology, "D" is called "System", "S" is called "Command", and F is called "Data".
RC6
{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]
uei-executor: 0058[D;F]
uei-executor: 0058:2(RC-6)[D;F]
uei-executor: 0184:2[D?0,D?1,D?2;1,,,??,F]
prefer-over: RC6-M-16
absolute-tolerance: 300
RC6 is the name used for the first member of the RC6 family of protocols. Technically this is RC6-0-16. Tutorial.
RC6-6-20
{36k,444,msb}<-1,1|1,-1>((6,-2,1:1,6:3,<-2,2|2,-2>(T:1),D:8,S:4,F:8,-100m)*,T=1-T)[D:0..255,S:0..15,F:0..255,T@:0..1=0]
uei-executor: 0020[6,D,S;F]
uei-executor: 0020:2[6,D,S,T;F]
absolute-tolerance: 300
This protocol is commonly used in Sky and Sky+ remotes.
RC6-M-16
{36k,444,msb}<-1,1|1,-1>((6,-2,1:1,M:3,<-2,2|2,-2>(T:1),D:8,F:8,^107m)*,T=1-T) [D:0..255,F:0..255,M:0..7,T@:0..1=0]
absolute-tolerance: 300
uei-executor: 0058:2(RC6-M-16)[D,M;F]
RC6-M-28
{36k,444,msb}<-1,1|1,-1>((6,-2,1:1,M:3,<-2,2|2,-2>(T:1),D:8,S:12,F:8,-100m)*,T=1-T)[D:0..255,S:0..4095,F:0..255,M:0..7,T@:0..1=0]
uei-executor: 0240[D,S,M,0;F]
absolute-tolerance: 300
RC6-M-32
{36k,444,msb}<-1,1|1,-1>((6,-2,1:1,M:3,<-2,2|2,-2>(T:1),OEM1:8,OEM2:8,D:8,F:8,^107m)*,T=1-T)[OEM1:0..255,OEM2:0..255,D:0..255,F:0..255,M:0..7,T@:0..1=0]
uei-executor: 012A:2[D,(OEM1<<8)+OEM2,M;F]
absolute-tolerance: 300
This is the generic form for a decode of protocols in the RC6 family, restricted to 32 bits. Exceptions: RC6-0-16 is displayed as simply RC6, RC6-6-24 is displayed as Replay, and some RC6-6-32 which is displayed as MCE.
RC6-M-56
{36k,444,msb}<-1,1|1,-1>(6,-2,1:1,M:3,<-2,2|2,-2>(T:1),C:56,-131.0m)*[M:0..7,T@:0..1=0,C:0..72057594037927935]
absolute-tolerance: 300
This is the "RC6-M-N protocol" made usable for the case of N=56.
RCA
{58k,460,msb}<1,-2|1,-4>(8,-8,D:4,F:8,~D:4,~F:8,1,-16)*[D:0..15,F:0..255]
uei-executor: 00AF[D;F]
uei-executor: 00AF:2[D,0;F]
uei-executor: 0114[;D,0,F]
RCA and RCA(Old) are two very similar forms of RCA protocol which differ only in that RCA(Old) has an extended lead-in and a double-length ON pulse before the lead-out. They are so similar that most RCA devices will accept either. But some RCA devices only accept the one that really matches.
RCA(Old)
{58k,460,msb}<1,-2|1,-4>([40][8],-8,D:4,F:8,~D:4,~F:8,2,-16)[D:0..15,F:0..255]
uei-executor: 002D[D;F]
See RCA.
RCA-38
{38.7k,460,msb}<1,-2|1,-4>(8,-8,D:4,F:8,~D:4,~F:8,1,-16)*[D:0..15,F:0..255]
uei-executor: 0091
These are recently discovered variants of the RCA protocol. They differ from RCA and RCA(Old) only in the frequency, which is 38.7kHz instead of the standard 58kHz.
RCA-38(Old)
{38.7k,460,msb}<1,-2|1,-4>([40][8],-8,D:4,F:8,~D:4,~F:8,2,-16)[D:0..15,F:0..255]
See RCA-38.
RECS80
RECS80-0045{}[D:0..7,F:0..63, T@:0..1=0]
uei-executor: 0045
prefer-over: RECS80-0045
RECS80-0045
{38k,158,msb}<1,-31|1,-47>(1:1,T:1,D:3,F:6,1,-45m)* [D:0..7,F:0..63, T@:0..1=0]
uei-executor: 0045
RECS80-0068
{33.3k,180,msb}<1,-31|1,-47>(1:1,T:1,D:3,F:6,1,^138m)* [D:0..7,F:0..63, T@:0..1=0]
uei-executor: 0068
RECS80-0090
{0k,158,msb}<1,-31|1,-47>(1:1,T:1,D:3,F:6,1,^138m)* [D:0..7,F:0..63, T@:0..1=0]
uei-executor: 0090
Replay
{36k,444,msb}<-1,1|1,-1>(6,-2,1:1,6:3,<-2,2|2,-2>(T:1),D:8,S:8,F:8,-100m/*???*/)*[D:0..255,S:0..255,F:0..255,T@:0..1=0]
alt_name: RC6-6-24
alt_name: RC6A
uei-executor: 0092[D,S;F]
uei-executor: 0092:3(ReplayTV (Official))[D,S;F]
Replay is a member of the RC6 family; technically it is RC6-6-24.
Revox
{0k,15u}<1,-9|1,-19>(1,-29,0:1,D:4,F:6,1,-29,1,-100285u)*[D:0..15,F:0..63]
Revox uses no modulation.
Roku
{38.0k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:7,0:1,~F:7,1:1,1,^108m, (16,-8,D:8,S:8,F:7,1:1,~F:7,0:1,1,^108m)*)[D:0..255,S:0..255=255-D,F:0..127]
uei-executor: 021A[D,S;F]
This IR protocol is very similar to NEC2, except the repeat behavior is different. The second and additional frames of a repeating signal send the OBC + 128. Reference.
Rs200
{35.7k,msb}<50p,-120p|21p,-120p>(25:6,(H4-1):2,(H3-1):2,(H2-1):2,(H1-1):2,P:1,(D-1):3,F:2,0:2,sum:4,-1160p)*{ P=~(#(D-1)+#F):1,sum=9+((H4-1)*4+(H3-1)) + ((H2-1)*4+(H1-1)) + (P*8+(D-1)) + F*4}[H1:1..4, H2:1..4, H3:1..4, H4:1..4, D:1..6, F:0..2]
This protocol is/was used by the so-called RS-200 RF (433MHz) controlled switches, that were sold by Conrad Electronics. There is a "house numbers" consisting of four digits, each in the range 1 to 4. These are called H1, H2, H3, and H4 in the IRP. There is also a "device address". Officially, it ranges from 1 to 4, however, at least on the hardware I (BM) tried, 5 can also be used and assigned to a receiver. Also, 6 was working, and in fact controlled the "group" consisting of all devices with address 1,...,5. For 7 and 8, no function has been verified. F=0 is the power on command, F=1 the power off command, and F=2 the power toggle command.
RTI_Relay
{40.244k,398,msb}<1,-1|-1,1>(1,A:31,F:1,F:8,D:23,D:8,0:4,-19.5m)*{A=0x7fe08080}[F:0..1,D:0..255]
Protocol used by RTI RCM-4 Relay module, see this forum thread.
RTI_Relay_alt
{40.244k,398,msb}<1,-1|-1,1>(1,A:31,F:1,F:8,D:23,D:8,0:4,-19.5m)*{A=0x7fe08080,D=2**(4-N)}[F:0..1,N:1..4]
decodable: false
Different parameterization of RTI_Relay.
Sampo
{38.4k, 833}<1,-1|1,-3>(4,-4,D:6,F:6,S:6,~F:6,1,-39)*[D:0..63,S:0..63,F:0..63]
This is a moderately robust protocol, but spurious decodes are still possible.
Samsung-SMT-G
{38.5k,497,msb}<1,-1|1,-3>(4497u,-4497u,D:16,1,-4497u,S:4,F:16,1,^120m)*[D:0..65335,S:0..15,F:0..65535]
Forum thread.
Samsung20
{38.4k,564}<1,-1|1,-3>(8,-8,D:6,S:6,F:8,1,^100m)*[D:0..63,S:0..63,F:0..255]
uei-executor: 002F
This is a moderately robust protocol, but spurious decodes are still possible.
Samsung36
{37.9k,560,33%}<1,-1|1,-3>(4500u,-4500u,D:8,S:8,1,-9,E:4,F:8,~F:8,1,^108m)*[D:0..255,S:0..255,F:0..255,E:0..15]
uei-executor: 01B5[D,S,E;F]
relative-tolerance: 0.2
prefer-over: Samsung-SMT-G
Reference.
ScAtl-6
{57.6k,846}<1,-1|1,-3>(4,-4,D:6,F:6,~D:6,~F:6,1,-40)*[D:0..63,F:0..63]
uei-executor: 0078[D;F]
ScAtl-6 is distinguished from Emerson only by frequency. Most Scientific Atlanta cable tuners instead use the Panasonic_Old protocol.
Sejin-1-38
{38.8k,310,msb}<-1|1>(<8:4|4:4|2:4|1:4>(3,3:2,D:8,F:8,S:8,E:4,C:4,-77))* {C = D:4 + D:4:4 + F:4 + F:4:4 + S:4 + S:4:4 + E} [D:0..255, S:0..255, F:0..255, E:0..15=0]
uei-executor: 0161:3[0,D,S,E;F]
uei-executor: 0161:5[0,D,S?0,,S?1,E;0,??,F]
prefer-over: Sejin-1-56
This is the Sejin-1 version from DecodeIR, with the following substitutions: Dx -> D, Fx -> F, Fy -> S, L = 77. (Teaser uses a slightly different parameterization.)
Sejin-1-56
{56.3k,310,msb}<-1|1>(<8:4|4:4|2:4|1:4>(3,3:2,D:8,F:8,S:8,E:4,C:4,-77))* {C = D:4 + D:4:4 + F:4 + F:4:4 + S:4 + S:4:4 + E} [D:0..255, S:0..255, F:0..255, E:0..15=0]
uei-executor: 0161:3[1,D,S,E;F]
uei-executor: 0161:5[1,D,S?0,,S?1,E;0,??,F]
This is the Sejin-1 version from DecodeIR, with the following substitutions: Dx -> D, Fx -> F, Fy -> S, L = 77. (Teaser uses a slightly different parameterization.)
Sharp
{38k,264}<1,-3|1,-7>(D:5,F:8,1:2,1,-165,D:5,~F:8,2:2,1,-165)*[D:0..31,F:0..255]
prefer-over: Sharp{1}
uei-executor: 001C[D;F]
uei-executor: 009C(Sharp Combo (Official))[;D,0,F]
uei-executor: 01AC[1;0,D,F]
A Sharp signal, which is almost identical to Denon, has two halves, either one of which is enough to fully decode the information. When one half is seen separate from the other, it will be decoded as Sharp{1} or Sharp{2} depending on which half is decoded. Sharp, Sharp{1} and Sharp{2} all represent the same protocol when they are correct, but only Sharp is robust.
SharpDVD
{38k,400}<1,-1|1,-3>(8,-4,170:8,90:8,15:4,D:4,S:8,F:8,E:4,C:4,1,-48)*{C = D ^ S:4:0 ^ S:4:4 ^ F:4:0 ^ F:4:4 ^ E:4}[D:0..15,S:0..255,F:0..255,E:0..15=1]
uei-executor: 00F8[D,S;F]
uei-executor: 00F8:2[D,S;F]
uei-executor: 00F8:3[D,S;F]
prefer-over: Kaseikyo
SharpDVD is the member of the Kaseikyo family with OEM_code1=170 and OEM_code2=90. E=1 in all instances seen so far.
Sharp{1}
{38k,264}<1,-3|1,-7>(D:5,F:8,1:2,1,-165)*[D:0..31,F:0..255]
uei-executor: 001C[D;F]
uei-executor: 009C(Sharp Combo (Official))[;D,0,F]
uei-executor: 01AC[1;0,D,F]
See Sharp.
Sharp{2}
{38k,264}<1,-3|1,-7>(D:5,~F:8,2:2,1,-165)*[D:0..31,F:0..255]
uei-executor: 001C[D;F]
uei-executor: 009C(Sharp Combo (Official))[;D,0,F]
uei-executor: 01AC[1;0,D,F]
See Sharp.
SIM2
{38.8k,400}<3,-3|3,-7>(6,-7,D:8,F:8,3,^115m)[D:0..255=236,F:0..255]
Reference. In that document, there is a contradiction between the verbal description and the Pronto Hex code given. Here we follow the Pronto form, which is also consistent with DecodeIR.
Solidtek16
{38k}<-624,468|468,-624>(S=0,(1820,-590,0:1,D:4,F:7,S:1,C:4,1:1,-143m,S=1)3) {C= F:4:0 + F:3:4 + 8*S } [D:0..15, F:0..127]
This is a keyboard protocol. The make/break bit is decoded into the subdevice field.
Somfy
{35.7k}<308,-881|669,-520>(2072,-484,F:2,D:3,C:4,-2300)*{C = F*4 + D + 3}[F:0..3,D:0..7]
uei-executor: 01FF:Somfy2[;D,F*4+D+3,F]
F = 1 for UP or 2 for DOWN. D = 1, 2 or 3 for the three observed devices, or D = 0 to control all devices together.
Sony12
{40k,600}<1,-1|2,-1>(4,-1,F:7,D:5,^45m)*[D:0..31,F:0..127]
uei-executor: 00CA[D?0,0?0,D?1,0?1;??,F]
uei-executor: 00DE[,,D;1,F]
uei-executor: 0027:old[;F,D]
uei-executor: 0027:2[;0,D,0,F]
Sony15
{40k,600}<1,-1|2,-1>(4,-1,F:7,D:8,^45m)*[D:0..255,F:0..127]
uei-executor: 00CA{X=D<32}[D?0,X?0,D?1,X?1;??,F]
uei-executor: 0027:2[;1,D,0,F]
Sony20
{40k,600}<1,-1|2,-1>(4,-1,F:7,D:5,S:8,^45m)*[D:0..31,S:0..255,F:0..127]
uei-executor: 00DE[D,S;0,F]
uei-executor: 0027:old[D,S;F]
uei-executor: 0027:2[S?1,S?2,S?3,S?4;2,D,??,F]
Sony8
{40k,600}<1,-1|2,-1>(4,-1,F:8,^45m)[F:0..255]
SonyDSP
{40k,600}<1,-1|2,-1>((4,-1,96:8,18:7,^45m)3,(4,-1,195:8,^45m),(4,-1,81:8,^45m),(4,-1,F:8,^45m), (4,-1,(F^145):8,11:7,^45m))[F:0..255]
prefer-over: SonyDSP_relaxed
prefer-over: Sony15
uei-executor: 01FF:JP1DSP[;F]
SonyDSP_relaxed
{40k,600}<1,-1|2,-1>((4,-1,96:8,18:7,^45m)3,(4,-1,195:8,^45m),(4,-1,81:8,^45m),(4,-1,F:8,^45m), (4,-1,(F^145):8,11:6))[F:0..255]
prefer-over: Sony15
decode-only: true
uei-executor:
StreamZap
{36k,msb,889}<1,-1|-1,1>(1,~F:1:6,T:1,D:6,F:6,^114m)*[D:0..63,F:0..63,T:0..1]
uei-executor: 01FF:JP1SZ[D;F]
StreamZap-57
{57k,msb,889}<1,-1|-1,1>(1,~F:1:6,T:1,D:6,F:6,^114m)*[D:0..63,F:0..63,T:0..1]
uei-executor: 01FF:JP1S57[D;F]
Sunfire
{38k,560,msb}<1,-1|3,-1>(16,-8, D:4,F:8,~D:4,~F:8, -32)*[D:0..15,F:0..255]
TDC-38
{38k,315,msb}<-1,1|1,-1>(1,-1,D:5,S:5,F:7,-89m)*[D:0..31,S:0..31,F:0..127]
uei-executor: 01BB
There are two variants of this protocol, with different frequencies but with the same number of carrier cycles in each burst, which makes the duration of a burst also differ. TDC-38 has a 38kHz carrier and is used by Danish TDC IPTV. TDC-56 has a 56.3kHz carrier and is used by Italian ALICE Home TV box. These implementations effectively use a 6-bit OBC as bit 0 of F is always the complement of bit 1, but there are other implementations which do not follow that pattern.
TDC-56
{56.3k,213,msb}<-1,1|1,-1>(1,-1,D:5,S:5,F:7,-89m)*[D:0..31,S:0..31,F:0..127]
uei-executor: 01BD
There are two variants of this protocol, with different frequencies but with the same number of carrier cycles in each burst, which makes the duration of a burst also differ. TDC-38 has a 38kHz carrier and is used by Danish TDC IPTV. TDC-56 has a 56.3kHz carrier and is used by Italian ALICE Home TV box. These implementations effectively use a 6-bit OBC as bit 0 of F is always the complement of bit 1, but there are other implementations which do not follow that pattern.
Teac-K
{37k,432}<1,-1|1,-3>(8,-4,67:8,83:8,X:4,D:4,S:8,F:8,T:8,1,-100,(8,-8,1,-100)*) {T=D+S:4:0+S:4:4+F:4:0+F:4:4} [D:0..15,S:0..255,F:0..255,X:0..15=1]
uei-executor: 00BB[(D<<4)+X,S;F]
Teac-K is the member of the Kaseikyo family with OEM_code1=67 and OEM_code2=83. Teac-K uses different repeat rules and a different check byte than other Kaseikyo protocols.
Thomson
{33k,500}<1,-4|1,-9>((D:4,T:1,D:1:4,F:6,1,^80m)*,T=1-T)[D:0..31,F:0..63,T@:0..1=0]
uei-executor: 004B
This is not a robust protocol, so spurious decodes are likely.
Thomson7
{33k,500}<1,-4|1,-9>((D:4,T:1,F:7,1,^80m)*,T=1-T) [D:0..15,F:0..127,T@:0..1=0]
prefer-over: Thomson
uei-executor: 004B:7
Tivo
{38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,U:4,~F:4:4,1,-78,(16,-4,1,-173)*) [D:133..133=133,S:48..48=48,F:0..255,U:0..15]
prefer-over: NEC1-f16
uei-executor: 0111[D,S,U;F]
uei-executor: 0111:2byte[D,S,U;F]
Velleman
{38k,msb}<700,-5060|700,-7590>(1:1,T:1,D:3,F:6,700,-55m)* [D:0..7,F:0..63,T@:0..1=0]
Very similar to RECS80-0045, except on duration is longer.
Velodyne
{38k,136,msb}<210u,-760u|210u,-896u|210u,-1032u|210u,-1168u|210u,-1304u|210u,-1449u|210u,-1576u|210u,-1712u|210u,-1848u|210u,-1984u|210u,-2120u|210u,-2256u|210u,-2392u|210u,-2528u|210u,-2664u|210u,-2800u>([T=0][T=8],S:4:4,~C:4,S:4,15:4,D:4,T:4,F:8,210u,-79m){C=(8+S:4+S:4:4+15+D+T+F:4+F:4:4)&15}[D:0..15,S:0..255,F:0..255]
relative-tolerance: 0.04
absolute-tolerance: 100
uei-executor: 01FF:JP1VD
Velodyne is a close relative of XMP.
Viewstar
{50.5k,337}<1,-8|1,-5>(~F:5,1,-17)*[F:0..31]
uei-executor: 0021
This is not a robust protocol, so spurious decodes are likely.
Whynter
{38k,750,msb}<1,-1|1,-3>(0:1,4,-4,F:32,1,-50m)[F:0..0xFFFFFFFF]
From IRremote, see also this issue. "Tested with Whynter ARC-110WD."
X10
{40.8k,565}<2,-12|7,-7>(7,-7,F:5,~F:5,21,-7)*[F:0..31]
uei-executor: 01DF
X10 and X10.n are two variants of the same home automation protocol. They differ in that X10.n has a distinctive start frame that carries a sequence number, the n of the protocol name, in addition to F. The repeat frames, and all frames of the X10 version, only carry the F. The value of n runs from 0 to 15 (or some lower value) and then restarts again at 0. It is incremented on each successive keypress. A valid X10.n signal must have at least one repeat frame.
X10.n
{40.8k,565}<2,-12|7,-7>(F:5,N:-4,21,-7,(7,-7,F:5,~F:5,21,-7)+)[F:0..31,N:0..15]
uei-executor: 003F
reject-repeatless: true
See X10.
X10_18
{40.8k,565}<2,-12|7,-7>(7,-7,F:9,~F:9,21,-7)*[F:0..511]
X10_8
{40.8k,565}<2,-12|7,-7>(7,-7,F:4,~F:4,21,-7)*[F:0..15]
Xiaomi
{36k,290,msb}<2,-2|2,-3|2,-4|2,-5>(1000u,-2,D:8,F:8,C:4,2,^30m)* {C=(D:4:4^D:4^F:4:4^F:4)} [D:0..255,F:0..255]
relative-tolerance: 0.1
uei-executor: 023B[;D,F]
Protocol found in the Xiaomi Mi Box Streaming Android TV Device. Defined and described in this thread.
XMP
{38k,136,msb}<210u,-760u|210u,-896u|210u,-1032u|210u,-1168u|210u,-1304u|210u,-1449u|210u,-1576u|210u,-1712u|210u,-1848u|210u,-1984u|210u,-2120u|210u,-2256u|210u,-2392u|210u,-2528u|210u,-2664u|210u,-2800u>([T=0][T=8],S:4:4,C1:4,S:4,15:4,OEM:8,D:8,210u,-13.8m,S:4:4,C2:4,T:4,S:4,F:16,210u,-80.4m){ C1=-(S+S::4+15+OEM+OEM::4+D+D::4), C2=-(S+S::4+T+F+F::4+F::8+F::12) }[F:0..65535,D:0..255,S:0..255,OEM:0..255=68]
relative-tolerance: 0.04
absolute-tolerance: 100
uei-executor: 016C:2[D,S,OEM;F:8:8,F:8]
DecodeIR documentation.
XMP-1
{38k,136,msb}<210u,-760u|210u,-896u|210u,-1032u|210u,-1168u|210u,-1304u|210u,-1449u|210u,-1576u|210u,-1712u|210u,-1848u|210u,-1984u|210u,-2120u|210u,-2256u|210u,-2392u|210u,-2528u|210u,-2664u|210u,-2800u>([T=0][T=8],S:4:4,C1:4,S:4,15:4,OEM:8,D:8,210u,-13.8m,S:4:4,C2:4,T:4,S:4,(F*256):16,210u,-80.4m){ C1=-(S+S::4+15+OEM+OEM::4+D+D::4),C2=-(S + S::4 + T + 256*F + 16*F + F + F::4) }[D:0..255, S:0..255, F:0..255, OEM:0..255=68]
prefer-over: XMP
relative-tolerance: 0.04
absolute-tolerance: 100
uei-executor: 016C:2[D,S,OEM;F:8]
XMP-2
{38k,136,msb}<210u,-760u|210u,-896u|210u,-1032u|210u,-1168u|210u,-1304u|210u,-1449u|210u,-1576u|210u,-1712u|210u,-1848u|210u,-1984u|210u,-2120u|210u,-2256u|210u,-2392u|210u,-2528u|210u,-2664u|210u,-2800u>([T=0][T=8],S:4:4,C1:4,S:4,15:4,OEM:8,D:8,210u,-13.8m,S:4:4,C2:4,T:4,S:4,F:16,210u,-80.4m){ C1=-(S+S::4+15+OEM+OEM::4+D+D::4),C2=-(S+S::4+T+F+F::4+F::8+F::12) }[D:0..255, S:0..255, F:0..255, OEM:0..255=68]
prefer-over: XMP
relative-tolerance: 0.04
absolute-tolerance: 100
uei-executor: 016C:2[D,S,OEM;,F]
XMPff
{38k,136,msb}<210u,-760u|210u,-896u|210u,-1032u|210u,-1168u|210u,-1304u|210u,-1449u|210u,-1576u|210u,-1712u|210u,-1848u|210u,-1984u|210u,-2120u|210u,-2256u|210u,-2392u|210u,-2528u|210u,-2664u|210u,-2800u>([T=0][T=8][T=9],S:4:4,C1:4,S:4,15:4,OEM:8,D:8,210u,-13.8m,S:4:4,C2:4,T:4,S:4,F:16,210u,[-80.4m][-80.4m][-13.8m]){ C1=-(S+S::4+15+OEM+OEM::4+D+D::4),C2=-(S+S::4+T+F+F::4+F::8+F::12) }[F:0..65535,D:0..255,S:0..255,OEM:0..255=68]
relative-tolerance: 0.04
absolute-tolerance: 100
XMPff-1
{38k,136,msb}<210u,-760u|210u,-896u|210u,-1032u|210u,-1168u|210u,-1304u|210u,-1449u|210u,-1576u|210u,-1712u|210u,-1848u|210u,-1984u|210u,-2120u|210u,-2256u|210u,-2392u|210u,-2528u|210u,-2664u|210u,-2800u>([T=0][T=8][T=9],S:4:4,C1:4,S:4,15:4,OEM:8,D:8,210u,-13.8m,S:4:4,C2:4,T:4,S:4,(F*256):16,210u,[-80.4m][-80.4m][-13.8m]){ C1=-(S+S::4+15+OEM+OEM::4+D+D::4),C2=-(S + S::4 + T + 256*F + 16*F + F + F::4) }[D:0..255, S:0..255, F:0..255, OEM:0..255=68]
prefer-over: XMPff
relative-tolerance: 0.04
absolute-tolerance: 100
XMPff-2
{38k,136,msb}<210u,-760u|210u,-896u|210u,-1032u|210u,-1168u|210u,-1304u|210u,-1449u|210u,-1576u|210u,-1712u|210u,-1848u|210u,-1984u|210u,-2120u|210u,-2256u|210u,-2392u|210u,-2528u|210u,-2664u|210u,-2800u>([T=0][T=8][T=9],S:4:4,C1:4,S:4,15:4,OEM:8,D:8,210u,-13.8m,S:4:4,C2:4,T:4,S:4,F:16,210u,[-80.4m][-80.4m][-13.8m]){ C1=-(S+S::4+15+OEM+OEM::4+D+D::4),C2=-(S+S::4+T+F+F::4+F::8+F::12) }[D:0..255, S:0..255, F:0..255, OEM:0..255=68]
prefer-over: XMPff
relative-tolerance: 0.04
absolute-tolerance: 100
Zaptor-36
{36k,330,msb}<-1,1|1,-1>([][T=0][T=1],8,-6,2,D:8,T:1,S:7,F:8,E:4,C:4,-74m){C = (D:4+D:4:4+S:4+S:3:4+8*T+F:4+F:4:4+E)&15}[D:0..255,S:0..127,F:0..127,E:0..15]
uei-executor: 01CD[D,S,E,0;F]
T=0 for all frames except the last, T=1 for last frame, E is a checksum seed. A protocol so far seen only in the Motorola Zaptor.
Zaptor-56
{56k,330,msb}<-1,1|1,-1>([][T=0][T=1],8,-6,2,D:8,T:1,S:7,F:8,E:4,C:4,-74m){C = (D:4+D:4:4+S:4+S:3:4+8*T+F:4+F:4:4+E)&15}[D:0..255,S:0..127,F:0..127,E:0..15]
uei-executor: 01CD[D,S,E,1;F]
T=0 for all frames except the last, T=1 for last frame, E is a checksum seed. A protocol so far seen only in the Motorola Zaptor.
Zenith
{40k,520,msb}<1,-10|1,-1,1,-8>(S:1,<1:2|2:2>(F:D),-90m)*[S:0..1,F:0..255,D:5..8]
decodable: false
An unusual protocol, in that the number of bits in the function code is variable. There are also two lead-in styles, decoded as subdevice values 0 and 1. Style 1 aka "double-start" is usually used in TV's, other appliances use 0 aka "single start".
Zenith5
Zenith{D=5}[S:0..1,F:0..255]
uei-executor: 0022[5,,S;F]
Special case of the Zenith protocol, with D = 5.
Zenith6
Zenith{D=6}[S:0..1,F:0..255]
uei-executor: 0022[6,,S;F]
Special case of the Zenith protocol, with D = 6.
Zenith7
Zenith{D=7}[S:0..1,F:0..255]
uei-executor: 0022[7,,S;F]
Special case of the Zenith protocol, with D = 7.
Zenith8
Zenith{D=8}[S:0..1,F:0..255]
uei-executor: 0022[8,,S;F]
Special case of the Zenith protocol, with D = 8.

Aliases (alternative names)

ruwido r-step
Alternative name for CanalSat.
GI Cable
Alternative name for G.I.Cable.
IODATAn-x-y
Alternative name for IODATAn.
RC6-6-32
Alternative name for MCE.
Pace
Alternative name for PaceMSS.
RC6-6-24
Alternative name for Replay.
RC6A
Alternative name for Replay.

Glossary

Cyclic Redundancy Check (CRC)
An elaborate form of checksum, see Wikipedia.
DecodeIR
Library for the decoding of IrSequences. Originally written by John Fine, extended by others; used by many widely spread programs as a shared library (IrScrutinizer version 1, IrpMaster, IrScope, RemoteMaster). Written in C++ with Java Native Interface. The current (and most likely final) version is 2.45, released in January 2015. Current official documentation. License: public domain. Binaries for Windows, Linux, and Mac, source code. Arduino port.
ditto
Simple sequence, without payload information, that is repeated as a repeat sequence's. For an example, see NEC1.
ending sequence
IR sequence that is sent exactly once when a button is released, after the repeats have ended. Only present if a few protocols, like NRC17 and OrtekMCE.
executor
An embedded "program" for the rendering and transmission of one or several protocols on an embedded processor. One executor can manage several protocols; also, for one protocol there may be several alternative executors. An executer has its own parameterization, more-or-less similar to the parameterization of the protocol. Used in UEI Remotes and RemoteMaster.
intro sequence
IR sequence that is sent exactly once when a button is held pressed. (If more is sent if the button is held, then it is the repeat- and ending sequence.)
relaxed protocol
A relaxed protocol (in general recognized by the suffix _relaxed in the name) is a protocol, derived from another protocol, where the recognition is in some way "relaxed", for example by some checks being left out. For example, a checksum may be just reported by its value, instead of being checked (possibly leading to the decode being considered as invalid). This can be useful for identifying imperfectly learned, or otherwise flawed IR signals. It should normally be marked decode-only, since rendering is normally meaningless.
repeat sequence
IR sequence that is sent repeatedly when a button is held down, after the intro sequence has been sent.
spurious decodes
An imperfectly measured signal that incorrectly matches a protocol (false positive).