List of Irp Protocols, version 2024-01-07

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.
Amazon_Fan
{38.5k,520,msb}<1,-3|1,-5>(9,-9,D:8,F:8,0:1,9,-9,D:8,F:8,1,-13.7m,(9074u,-5,1,-52m)*)[D:0..255,F:0..255]
uei-executor:
This protocol was discovered/invented and discussed in this 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]
prefer-over: Amino-56
absolute-tolerance: 100
relative-tolerance: 0.2
uei-executor:
uei-executor:
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]
absolute-tolerance: 100
relative-tolerance: 0.2
uei-executor:
uei-executor:
Anthem
{38.0k,605}<1,-1|1,-3>((8000u,-4000u,D:8,S:8,Unit:2,F:6,C:8,1,-25m)2, 8000u,-4000u,D:8,S:8,Unit:2,F:6,C:8,1,-100)* { C=~(D+S+(Unit<<6)+F+255):8} [D:0..255,S:0..255,Unit:0..3,F:0..63]
uei-executor: 0123(Anthem)[D,S,Unit;F:6]
uei-executor: 0123(Anthem Combo)[D,S;F,Unit]
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_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]
decode-only: true
uei-executor:
uei-executor:
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-(#D+#S+#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
This protocol uses the same framing as NEC1. D is normally 238, with 224 while pairing, but also other values have been observed. C is a checksum, making the whole payload having even parity.
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]
alt_name: Motorola
uei-executor: 00A5[D,0;F]
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,(F:1:7)*4,D:5|(F:7)*32]
uei-executor: 01AC[;0,D,F,D:5|(F:7)*32]
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:2[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;1,,,??,F]
uei-executor: 01AC[D,S;2,,,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,(F:1:7)*4,D:5|(F:7)*32]
uei-executor: 01AC[;0,D,F,D:5|(F:7)*32]
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,(F:1:7)*4,D:5|(F:7)*32]
uei-executor: 01AC[;0,D,F,D:5|(F:7)*32]
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:
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]
minimum-leadout: 7000
frequency-tolerance: 1000
prefer-over: DirecTV_3FG
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:
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]
frequency-tolerance: 1000
prefer-over: DirecTV_P0
prefer-over: DirecTV_3FG
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:
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]
minimum-leadout: 7000
frequency-tolerance: 1000
prefer-over: DirecTV_3FG
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:
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
prefer-over: DirecTV_3FG
alt_name: DirecTV
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:
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]
minimum-leadout: 7000
frequency-tolerance: 1000
prefer-over: DirecTV_3FG
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:
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]
frequency-tolerance: 1000
prefer-over: DirecTV_P4
prefer-over: DirecTV_3FG
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:
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.
Dyson
{780,38k}<1,-1|1,-2>(3,-1,D:7,F:6,T:-2,1,-100m,3,-1,D:7,F:6,T:-2,1,-60m,(3,-1,1:1,1,-60m)*,T=(T+1)%3)[D:0..127,F:0..63,T@:0..3=0]
prefer-over: Dyson_relaxed
uei-executor: 01FF:JP1Dyson(;F!=0)
This protocol is used by Dyson fan heaters. T is a toggle but its range of values may depend on the Dyson model. For example, the AM05 cycles T through 0,1,2 leaving the value 3 unused. The Dyson2 protocol differs in having a longer lead-out between the two full frames. It is used in the AM05 for the Power button. For signals with no ditto repeat frames to be decoded by IrpTransmogrifier, Repeat Finder must be turned off.
Dyson2
{780,38k}<1,-1|1,-2>(3,-1,D:7,F:6,T:-2,1,-400m,3,-1,D:7,F:6,T:-2,1,-60m,(3,-1,1:1,1,-60m)*,T=(T+1)%3)[D:0..127,F:0..63,T@:0..3=0]
prefer-over: Dyson_relaxed
uei-executor: 01FF:JP1Dyson(;F==0)
The Dyson protocol is used by Dyson fan heaters. T is a toggle but its range of values may depend on the Dyson model. For example, the AM05 cycles T through 0,1,2 leaving the value 3 unused. The Dyson2 protocol differs in having a longer lead-out between the two full frames. It is used in the AM05 for the Power button. For signals with no ditto repeat frames to be decoded by IrpTransmogrifier, Repeat Finder must be turned off.
Dyson_relaxed
{780,38k}<1,-1|1,-2>(3,-1,D:7,F:6,T:-2,1,-100m)*[D:0..127,F:0..63,T:0..3=0]
decode-only: true
Relaxed version of the Dyson and Dyson2 protocols, which tests only the first frame. A signal may decode as Dyson_relaxed because (a) the signal is incomplete, or (b) the capture hardware cannot report large lead-out values, or (c) the signal has no ditto repeat frames and Repeat Finder has squashed it.
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
Eufy
{38.0k,500}<1,-3|1,-1>(6,-6,D:8,F:8,D2:8,F2:8,S:8,C:8,1,-40)*{C=CO:8+D:8+D2:8+S:8}[D:0..255,D2:0..255,S:0..255,CO:0..255,F:0..255,F2:0..255]
uei-executor:
This is the protocol used by the Eufy 11s robot vacuum cleaner. See this 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
prefer-over: F12x
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]
minimum-leadout: 6000
uei-executor:
Relaxed version of the F12 specification.
F12x
{37.9k,422}<1,-3|3,-1>((D:3,S:1,F:8,-16)*,(D:3,S:1,E:8,-16))[D:0..7,S:0..1,F:0..255,E:0..255]
prefer-over: F12_relaxed
uei-executor: 016D[D,S,E;F]
This is an extended and slightly modified version of the F12 protocol. The modifications are that the lead-out gap between frames is only one-fifth of that of the F12 protocol and that the number of repeats does not have to be an even number. The extension is that there is a final frame sent on key release with a different command value. This protocol has been seen in the Delta Air Cleaner #50-875.
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]
prefer-over: Kaseikyo
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
{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=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(;D==0)
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:1:7;D:1:6,F:8]
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_squashed
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]
prefer-over: Kaseikyo
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_squashed
{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
decode-only: true
This is a version of the JVC protocol for signals that has been too much reduced ("squashed") 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:4,G=(C<<4)|E:4}[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.
Keeprite
{38.1k,570}<1,-1|1,-3>(16,-8,A:8,B:4,C:8,E:3,0xA0:9,2:3,1,-20m,G:4,0:4,H:2,16:6,0:12,chksum:4,1,-20m){chksum=(14+A+B+C:4:4)&15}[A:0..255,B:0..15,C:0..255,E:0..7,G:0..15,H:0..3]
uei-executor:
An air conditioning protocol, see this thread.
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]
uei-executor: 012A:2(RC6-M-32;T==0){OEM1=128,X=T,TS=T<0?-T-1:T,T=0}[OEM1,((2*S+TS)<<7)+D:7,6, T,X<0?1:0;F]
uei-executor: 012A(RC6-6-32){OEM1=128,X=T,TS=T<0?-T-1:T,T=0}[OEM1,((2*S+TS)<<7)+D:7,X<0?1:0;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]
prefer-over: Kaseikyo
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
decode-only: true
uei-executor: 005A(NEC1)
uei-executor: 005A(NEC2)
uei-executor: 01AD[;D,S,F:8,~F:8]
uei-executor: 011A:JP1[D?0,S?0,D?1,S?1,D?2,S?2,D?3,S?3;F,??,,0]
uei-executor: 01BA[D,S;F:8,~F:8]
uei-executor: 01EA(;S==~D:8)[F,~F:8;D]
uei-executor: 011A[D?0,S?0,D?1,S?1;F,??]
uei-executor: 011A:2[D?0,S?0,D?1,S?1,D?2,S?2,D?3,S?3;F,??]
uei-executor: 017E[D,S?0,S?1,S?2,S?3;??,,F]
uei-executor: 0246[D,S?0,S?1,S?2,S?3,S?4,S?5;??,,F]
uei-executor: 00B6[D;S,F]
uei-executor: 00B6:JP1[D;S,F]
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
uei-executor: 01BA[D,S;F,E]
uei-executor: 01FF:JP1f16[D,S,F;E]
uei-executor: 01EA(;S==~D:8)[F,E;D]
uei-executor:
uei-executor:
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,-50m)
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 the NEC protocols was referred to in the original Arduino IRremote project, originated by Ken Shirriff. (The current version of that project has a different description.)
NEC-Shirriff-32
{38.4k,msb,564}<1,-1|1,-3>(16,-8,data:32,1,^108m) [data:0..UINT32_MAX]
uei-executor:
The NEC-Shirriff protocol with payload length set to 32, making it viable for decoding.
NEC-Yamaha
{38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,E0:1,~F:6:1,E7:1,1,^108m) {E0=(~Y:1:1)^(F:1),E7=(~Y:1)^(F:1:7)}[D:0..255,S:0..255=255-D,F:0..255,Y:1..3]
prefer-over: NEC-f16
prefer-over: NEC1-f16
prefer-over: NEC2-f16
prefer-over: NECx1-f16
prefer-over: NECx2-f16
prefer-over: NEC-Shirriff-32
uei-executor: 011A:JP1[D?0,S?0,D?1,S?1,D?2,S?2,D?3,S?3;F,??,,Y]
uei-executor: 01AD[;D,S,F:8,(~F:8)^(128*Y:1|Y:1:1)]
uei-executor: 01BA[D,S;F:8,(~F:8)^(128*Y:1|Y:1:1)]
A relaxed variant of the NEC1-Yamaha protocol. As with that protocol, the relationship between bytes 3 and 4 of the signal differs from that of the NEC1 protocol. Instead of byte 4 being the complement of byte 3, the relationship is determined by the value of the Y parameter, as follows:
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
prefer-over: NEC-f16
prefer-over: NEC1-f16
prefer-over: NEC
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]
uei-executor: 011A:JP1[D?0,S?0,D?1,S?1,D?2,S?2,D?3,S?3;F,??,0,0]
uei-executor: 01BA[D,S;F:8,~F:8]
uei-executor: 01EA(;S==~D:8)[F,~F:8;D,0]
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: 01BA[D,S;F,E]
uei-executor: 01FF:JP1f16[D,S,F;E]
uei-executor: 01EA(;S==~D:8)[F,E;D,0]
uei-executor:
uei-executor:
A relaxed form (but used in some real devices) of the NEC1 protocol. Byte 3 and byte 4 are independent. NEC1-Yamaha is a special case of this, in which bytes 3 and 4 are related but in a different manner than in a standard NEC1 signal. The NEC1 standard is that byte 4 is the complement of byte 3. The relationship in an NEC1-Yamaha signal is determined by a style parameter with values Y1, Y2 and Y3 as follows:
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
uei-executor: 01AD[;D,S,F,~(((F:4)<<4)|F:4:4):8]
Variant of the NEC1 protocol with the checksum in byte 4 different (complement F and reverse the nibbles).
NEC1-Yamaha
{38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,E0:1,~F:6:1,E7:1,1,^108m,(16,-4,1,^108m)*) {E0=(~Y:1:1)^(F:1),E7=(~Y:1)^(F:1:7)}[D:0..255,S:0..255=255-D,F:0..255,Y:1..3]
prefer-over: NEC-f16
prefer-over: NEC1-f16
prefer-over: NEC2-f16
prefer-over: NECx1-f16
prefer-over: NECx2-f16
prefer-over: NEC-Yamaha
prefer-over: NEC-Shirriff-32
uei-executor: 011A:JP1[D?0,S?0,D?1,S?1,D?2,S?2,D?3,S?3;F,??,,Y]
uei-executor: 01AD[;D,S,F:8,(~F:8)^(128*Y:1|Y:1:1)]
uei-executor: 01BA[D,S;F:8,(~F:8)^(128*Y:1|Y:1:1)]
A variant of the NEC1 protocol which differs in the relationship between bytes 3 and 4. Instead of byte 4 being the complement of byte 3, the relationship is determined by the value of the Y parameter, as follows:
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
prefer-over: NEC-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]
uei-executor: 01EA(;S==~D:8)[F,~F:8;D,1]
uei-executor: 011A:JP1[D?0,S?0,D?1,S?1,D?2,S?2,D?3,S?3;F,??,1,0]
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
prefer-over: NEC-f16
reject-repeatless: true
uei-executor: 01EA(;S==~D:8)[F,E;D,1]
uei-executor:
uei-executor:
A relaxed form (but used in some real devices) of the NEC2 protocol. Byte 3 and byte 4 are independent. NEC2-Yamaha is a special case of this, in which bytes 3 and 4 are related but in a different manner than in a standard NEC2 signal. The NEC2 standard is that byte 4 is the complement of byte 3. The relationship in an NEC2-Yamaha signal is determined by a style parameter with values Y1, Y2 and Y3 as follows:
NECx-f16
{38.4k,564}<1,-1|1,-3>(8,-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]
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]
reject-repeatless: true
prefer-over: NECx1-f16
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]
uei-executor: 011A:JP1[D?0,S?0,D?1,S?1,D?2,S?2,D?3,S?3;F,??,2,0]
See this thread for a recent discussion.
NECx1-f16
{38.4k,564}<1,-1|1,-3>(8,-8,D:8,S:8,F:8,E:8,1,^108m,(8,-8,~D:1,1,^108m)*) [D:0..255,S:0..255=255-D,F:0..255,E:0..255=255-F]
prefer-over: NECx-f16
reject-repeatless: true
alt_name: Samsung32
uei-executor:
A relaxed form (but used in some real devices) of the NECx1 protocol. Byte 3 and byte 4 are independent. NECx1-Yamaha is a special case of this, in which bytes 3 and 4 are related but in a different manner than in a standard NECx1 signal. The NECx1 standard is that byte 4 is the complement of byte 3. The relationship in an NECx1-Yamaha signal is determined by a style parameter with values Y1, Y2 and Y3 as follows:
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]
reject-repeatless: true
prefer-over: NECx2-f16
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]
uei-executor: 011A:JP1[D?0,S?0,D?1,S?1,D?2,S?2,D?3,S?3;F,??,3,0]
NECx2-f16
{38.4k,564}<1,-1|1,-3>(8,-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: NECx-f16
reject-repeatless: true
uei-executor:
A relaxed form (but used in some real devices) of the NECx2 protocol. Byte 3 and byte 4 are independent. NECx2-Yamaha is a special case of this, in which bytes 3 and 4 are related but in a different manner than in a standard NECx2 signal. The NECx2 standard is that byte 4 is the complement of byte 3. The relationship in an NECx2-Yamaha signal is determined by a style parameter with values Y1, Y2 and Y3 as follows:
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]
alt_name: RCMM32
absolute-tolerance: 50
relative-tolerance: 0.04
prefer-over: Nokia32_endframe
uei-executor: 0173:1{Y=1,Z=T<0?1:2,T=2*Z:1:1-1}(;Y*Z>0)[D,S,X:7+(Y<<7),Z;F]
uei-executor: 0173:3{Y=T<0?0:T,Z=T<0?1:0,T=Y-2*Z:1}(;Y*Z==0)[D,S,X:7+(Y<<7),Z;F]
uei-executor: 0173:3{Y=1,Z=T<0?1:2,T=2*Z:1:1-1}(;Y*Z>0)[D,S,X:7+(Y<<7),Z;F]
uei-executor: 01E1:2{Y=T<0?-T-1:T,Z=T<0?1:0,T=Z?-Y-1:Y}[D,S,Z;F,X:7+(Y<<7)]
uei-executor:
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.
Nokia32_endframe
{36k,1p,msb}<6,-10|6,-16|6,-22|6,-28>([][T=0][T=1],15,-10,D:8,S:8,T:1,X:7,F:8,6,^100m)+[D:0..255,S:0..255,F:0..255,X:0..127]
absolute-tolerance: 50
relative-tolerance: 0.04
uei-executor: 0173:3(;X<128)[D,S,X,2;F]
uei-executor:
A version of the Nokia32 protocol that sets T=0 except for the last frame, which has T=1.
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:1:7;F:8]
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:1:7;F:8]
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:1:7;F:8]
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(Panasonic Combo)[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]
uei-executor: 0117[;D,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(;D==~S:8&&F:1:5==0)[D;0,0,0,F]
uei-executor: 007E:2(Pioneer DVD2;D==~S:8&&F:1:5==0)[D;F]
uei-executor: 007E:2(Pioneer MIX;D==~S:8)[D;0,0,0,F]
uei-executor: 007E:3(;D==~S:8)[D;0,0,0,F]
uei-executor: 007E:4(;D==~S:8)[D?0,D?1,D?2,D?3;0,0,??,F]
uei-executor: 007E:5(;D==~S:8)[D?0,D?1,D?2,D?3;0,0,??,F]
uei-executor: 005F(;D==~S:8)[D;F,F]
uei-executor: 006A(;D==~S:8)[D?0,D?1,D?2;??,F,F]
uei-executor: 006A:JP1(;D==~S:8)[D?0,D?1,D?2,D?3;??,F,F]
uei-executor: 006A:4(;D==~S:8)[D?0,D?1,D?2,D?3;??,F,F]
uei-executor: 017C:JP1[;D,F,D,F]
prefer-over: (160<=D && D<=165) || D==168 || D==170 || D==171 || D==173 || D==175 ; NEC2
frequency-lower: 39700
frequency-upper: 42000
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-2Part
{40k,564}<1,-1|1,-3>(16,-8,D0:8,~D0:8,F0:8,~F0:8,1,^90m,(16,-8,D:8,~D:8,F:8,~F:8,1,^90m)+) [D0:0..255,F0:0..255,D:0..255=D0,F:0..255=F0]
alt_name: Pioneer-Mix
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,??,5,F]
uei-executor: 007E:5(;;D.F=3.3,..)[D0,D?1D|||F0?1F,D?2D|||F0?2F,D?3D|||F0?3F,D?4D|||F0?4F,D?5D;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:JP1(;D0==D)[D?0,D?1,D?2,D?3;??,F0,F]
uei-executor: 006A:4(;D0==D)[D?0,D?1,D?2,D?3;??,F0,F]
uei-executor: 017C:JP1[;D0,F0,D,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 (Device) and F (OBC).
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:1:6?0,D?1,F:1:6?1,D?2,F:1:6?2;??,F:7]
uei-executor: 01C3[0,D?0,F:1:6?0,D?1,F:1:6?1,D?2,F:1:6?2,D?3,F:1:6?3;??,F:7]
uei-executor: 0073[;0,F,D]
uei-executor: 0184:2{D6=2*(~F):1,F6=(~D):5|32*D:1:5|64*F:1:6|128*D:1:6}[;0,D,F,D6,F6]
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:1:6;S:7,F:6]
uei-executor: 0073[D?0,S:1:6?0,D?1,S:1:6?1,D?2,S:1:6?2,D?3,S:1:6?3;1,F:6,,??,S:7]
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]
prefer-over: RC6-6-20-notoggle
uei-executor: 0020(;T==0)[6,D,S;F]
uei-executor: 0020:2[6,D,S,T;F]
absolute-tolerance: 300
The executors for this protocol do not toggle T. This no-toggle version 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-24
{36k,444,msb}<-1,1|1,-1>((6,-2,1:1,M:3,<-2,2|2,-2>(T:1),D:8,S:8,F:8,^105m)*,T=1-T)[D:0..255,S:0..255,F:0..255,M:0..7,T@:0..1=0]
uei-executor: 0092:3(ReplayTV (Official);M==6&&T==0)[D,S;F]
uei-executor:
This is a generic version of Replay that supports M values other than 6. The RC6-M-24 executor for this protocol supports both toggle and non-toggle behaviours for T.
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(;T==0)[D,S,M,0;F]
absolute-tolerance: 300
The executor for this protocol does not toggle T.
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]
absolute-tolerance: 300
uei-executor: 012A(RC6-6-32;M==6&&X<2){X=T==0?0:1,TS=T,T=-X,T=TS}[OEM1,(OEM2<<8)+D:8,X;F]>
uei-executor: 012A:2(MCE;M==6&&OEM1==128&&T==0)[D:7,OEM2;F]
uei-executor:
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. The executor for this protocol supports both toggle and non-toggle behaviours for T.
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
{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
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]
uei-executor: 0092:3(RC6-M-24)[D,S,6,0;F]
prefer-over: RC6-M-24
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]
reject-repeatless: true
prefer-over: Roku-8bit
prefer-over: NEC
prefer-over: NEC2
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.
Roku-8bit
{38.0k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,^108m, (16,-8,D:8,S:8,F:7,~F:1:7,~F:7,F:1:7,1,^108m)*)[D:0..255,S:0..255=255-D,F:0..255]
reject-repeatless: true
prefer-over: NEC
prefer-over: NEC2
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. This version has been modified to allow for 8-bit Fs.
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,D,F,D|(F:7)*32]
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,D,F,D|(F:7)*32]
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,D,F,D|(F:7)*32]
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..127,T@:0..1=0]
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..127,T@:0..1=0]
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]
TCL_AC
{38.2k,394}<1,-1|1,-3>(8,-4,M:40,modesw:-3,timesw:1,2:4,mode:8,~temp:5,0:3,fan:3,swing:3,timesw:1,0:1,time:8,0:24,chksum:8,1,-50m) {M=0x000126cb23,chksum=85 + modesw:-3 + (timesw<<3) + mode + ~temp + fan + (swing<<3) + (timesw<<6) + time} [modesw:0..1=0,timesw:0..1=0,mode:0..8=3,temp:0..31,fan:0..5=2,swing:0..7=0,time:0..144=0]
uei-executor:
Protocol used by air conditioning devices by TCL and others. See this thread, this thread, and this thread.

Parameters:

modesw
0 Off
1 On
timesw
0 Off
1 On
mode
1 heat
2 dry
3 unit
8 fan
9 feel
temp
Desired temperature in degrees Celsius
fan
0 auto
1 sleep
2 low
3 med
5 high
swing
0 Off
1 On
time
Timer value, in multiples of 10 minutes
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:4,S;F]
prefer-over: Kaseikyo
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-command
{38.4k,570}<2,-12|7,-7>(7,-7,C:4,1:1,~C:4,0:1,21,-7)*[C:0..15]
prefer-over: X10.n
uei-executor:
uei-executor:
This protocol is used to send X10 command codes to an IR543 receiver or compatible device.
X10-device
{38.4k,570}<2,-12|7,-7>(7,-7,D:4,0:1,~D:4,1:1,21,-7)*[D:0..15]
prefer-over: X10.n
uei-executor:
uei-executor:
This protocol is used to send X10 device (unit) selection codes to an IR543 receiver or compatible device. Devices are numbered from 1 to 16.
X10-house
{38.4k,570}<2,-12|7,-7>(7,-7,H:4,~H:4,21,-7)*[H:0..15]
uei-executor:
This protocol is used to send a house code to an IR543AH receiver or compatible device. More basic X10 receivers such as the IR543 do not accept the house code as an IR signal. The house code is a letter in the range A-P.
X10.n
{40.8k,565}<2,-12|7,-7>(F:5,N:-4,21,-7,(7,-7,F:5,~F:5,21,-7)+,N=(N+1)%16)[F:0..31,N@:0..15=0]
reject-repeatless: true
uei-executor:
This protocol is a UEI version of the protocol used to send X10 device (unit) and command codes to an IR543 receiver or compatible device. This protocol sends a non-functional first frame that is ignored by the receiver before sending the true X10 signal. The true X10 signal is that of the X10-device and X10-command protocols. For receivers that accept the house code as an IR signal, the X10-house protocol is used to send that value.
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]
prefer-over: XMP
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
prefer-over: XMP-1
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
prefer-over: XMP-2
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
{40k,520,msb}<1,-10|1,-1,1,-8>(S:1,<1:2|2:2>(F:D),-90m)*{D=5}[S:0..1,F:0..255]
uei-executor: 0022[5,,S;F]
Special case of the Zenith protocol, with D = 5.
Zenith6
{40k,520,msb}<1,-10|1,-1,1,-8>(S:1,<1:2|2:2>(F:D),-90m)*{D=6}[S:0..1,F:0..255]
uei-executor: 0022[6,,S;F]
Special case of the Zenith protocol, with D = 6.
Zenith7
{40k,520,msb}<1,-10|1,-1,1,-8>(S:1,<1:2|2:2>(F:D),-90m)*{D=7}[S:0..1,F:0..255]
uei-executor: 0022[7,,S;F]
Special case of the Zenith protocol, with D = 7.
Zenith8
{40k,520,msb}<1,-10|1,-1,1,-8>(S:1,<1:2|2:2>(F:D),-90m)*{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)

Motorola
Alternative name for Blaupunkt.
ruwido r-step
Alternative name for CanalSat.
DirecTV
Alternative name for DirecTV_P3.
GI Cable
Alternative name for G.I.Cable.
IODATAn-x-y
Alternative name for IODATAn.
RC6-6-32
Alternative name for MCE.
Samsung32
Alternative name for NECx1-f16.
RCMM32
Alternative name for Nokia32.
Pace
Alternative name for PaceMSS.
Pioneer-Mix
Alternative name for Pioneer-2Part.
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).