(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]]]> Like DecodeIR, we call a 48-NEC* signal without repeat "48-NEC". true (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]]]> true (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]]]> true (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. (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]]]> 005E:2 009E[S;D,F] (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]]]> Source: Dave Reed's program Teaser. 005E:2 (D:3,F:7,1,^25.3m)*[D:0..7,F:0..127]]]> 000D[D:2;D:1:2,F] (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. (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]]]> This protocol was discovered/invented and discussed in this thread. Amazon Fan (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]]]> 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 100 0.2 Freq=37kHz Freq=37kHz (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]]]> 100 0.2 Amino Freq=56kHz Amino Freq=56kHz ((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]]]> 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. 0123(Anthem)[D,S,Unit;F:6] 0123(Anthem Combo)[D,S;F,Unit] Anthem_relaxed NEC2-f16 (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]]]> Relaxed version of the Anthem protocol. true Anthem Non-standard repeats Anthem Combo Non-standard repeats (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]]]> 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. 01E0{S=135,E=PairID}[D?0,E|||D?1,S,D?2,D?3;F,??,0] NEC1-f16 NEC2-f16 NEC1 NEC-Shirriff-32 (F:5,1,-9.7m)* [F:0..31]]]> This is not a robust protocol, so spurious decodes are likely. 0.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".

 (<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. (16,-8,D:8,1,-8,F:8,1,-40)*[D:0..255,F:0..255]]]> 005D[D;F] (200u,-1,200u,-1,200u,-5,D:9,F:8,200u,-4,200u,-100m) {zeroGap=1, oneGap=3} [D:0..511,F:0..255]]]> 455kHz protocol used by some Bang & Olufsen equipment. Forum thread. 00EB[D:1:8,D:8,1;F,F] 00EB:4[D:1:8,D:8,1;F] -1 (200u,-1,200u,-1,200u,-5,D:9,F:8,200u,-4) {zeroGap=1, oneGap=3} [D:0..511,F:0..255]]]> From David Reed's program Teaser. 00EB:4[D:1:8,D:8,1;F] -1 (1,-25, D:5,F:6, 1,-25,1,-120m)*[D:0..31,F:0..63]]]> This protocol uses no modulation of the signal. This is a moderately robust protocol, but spurious decodes are still possible. 60 002A 00F3 (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]]]> Motorola 00A5[D,0;F] (2,-3,F:8,~F:8,1,-50m)* [F:0..255]]]> 010C (D:10,F:8,-18m)* [D:0..1023,F:0..255]]]> 15000 (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]]]> 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". 018C ruwido r-step (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]]]> The official name for CanalSatLD is "ruwido r-step" 018C:JP1 (F:1)2[F:0..1]]]> IR protocol for many Canon cameras. With F=0 it triggers immediately, F=1 it triggers after a delay of approximately two seconds. 0.1 50 (D:5,F:8,0:2,1,-165,D:5,~F:8,3:2,1,-165)* [D:0..31,F:0..255]]]> 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{1} Denon{2} 001C[D;F] 009C(Denon Combo (Official))[;D,1,F] 009C:JP1[;D,F] 01C8[;0,D,F,(F:1:7)*4,D:5|(F:7)*32] 01AC[;0,D,F,D:5|(F:7)*32] (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]]]> 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. 00CD:2[D;S,F] 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] 01AC[D,S;2,,,F] Kaseikyo (D:5,F:8,0:2,1,-165)* [D:0..31,F:0..255]]]> See Denon. true 001C[D;F] 009C(Denon Combo (Official))[;D,,F] 009C:JP1[;D,F] 01C8[;0,D,F,(F:1:7)*4,D:5|(F:7)*32] 01AC[;0,D,F,D:5|(F:7)*32] (D:5,~F:8,3:2,1,-165)* [D:0..31,F:0..255]]]> See Denon. true 001C[D;F] 009C(Denon Combo (Official))[;D,,F] 009C:JP1[;D,F] 01C8[;0,D,F,(F:1:7)*4,D:5|(F:7)*32] 01AC[;0,D,F,D:5|(F:7)*32] (16,-8,D:8,F:8,~F:8,1,^108m,(16,-4,1,^108m)*) [D:0..255,F:0..255]]]> 016A:2 016A (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. (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]]]> 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
 0162[D;F] ([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]]]> 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
 7000 1000 DirecTV_3FG DirecTV ([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]]]> 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
 1000 DirecTV_P0 DirecTV_3FG DirecTV ([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]]]> 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
 7000 1000 DirecTV_3FG DirecTV ([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]]]> 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
 1000 DirecTV_P2 DirecTV_3FG DirecTV DirecTV ([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]]]> 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
 7000 1000 DirecTV_3FG DirecTV ([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]]]> 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
 1000 DirecTV_P4 DirecTV_3FG DirecTV (1,-15,(F:-6,S:5,D:5,1,-15)+) [F:0..63,S:0..31,D:0..31]]]> This is not a robust protocol, so spurious decodes are likely. See this thread for a discussion. 0002[S+1,D;F] 0002:2[S+1,D;F] 0002:3[S+1,D;F] 0002:5(Dish Network)[D?0,D?1,D?2,D?3,S+1;??,F] 0002:5(Dish Network Combo)[D?0,D?1,D?2,D?3,S+1;??,F] 0002:6(Dish Network Combo)[D?0,D?1,D?2,D?3,S+1;??,F] (1,-11,(F:6,S:5,D:2,1,-11)+) [F:0..63,S:0..31,D:0..3]]]> This is not a robust protocol, so spurious decodes are likely. 010F[D,S;F] (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]]]> 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. Dyson_relaxed 01FF:JP1Dyson(;F!=0) (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]]]> 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 01FF:JP1Dyson(;F==0) (3,-1,D:7,F:6,T:-2,1,-100m)*[D:0..127,F:0..63,T:0..3=0]]]> 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. true (3,-2,D:8,~D:8,2,-2,F:8,~F:8,1,^50m)* [D:0..255,F:0..255]]]> See the JP1-forum thread. 01F8[D;F] (10,-3,D:24,F:8,-7)*{D=0xf48080} [F:0..255]]]> Elunevision Luna motorized projector screen remote. Posting on Lirc mailing list. (4,-4,D:6,F:6,~D:6,~F:6,1,-39)* [D:0..63,F:0..63]]]> 0065[D?0,D?1,D?2;??,F] 0065:2[D?0,D?1,D?2,D?3;??,F] 0065:old Sampo ScAtl-6 (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]]]> A special case of the RC6-M-56 protocol, used in the Entone Amulet. See this forum thread. RC6-M-56 ((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 (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]]]> This is the protocol used by the Eufy 11s robot vacuum cleaner. See this thread. D2 F2 CO -1 -1 -1 ((D:3,S:1,F:8,-80)2)* [D:0..7,S:0..1,F:0..255]]]> Old version of the F12 specification. F12_relaxed F12x 001A[D;F] (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. (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. (D:3,S:1,F:8,-80)* [D:0..7,S:0..1,F:0..255]]]> Relaxed version of the F12 specification. 6000 F12 Non-standard repeats ((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]]]> 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. F12_relaxed 016D[D,S,E;F] (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. (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]]]> 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. Kaseikyo 00F8[D;F,S] 00F8:2[D;F,S] 00F8:3[D;F,S] (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]]]> (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]]]> (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]]]> Protocol for Fujitsu inverter air conditioning. RemoteCentral thread. This version is a re-parametrization of 3FG's version, allowing for decoding. Fujitsu-128 (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]]]> Protocol for Fujitsu inverter air conditioning. RemoteCentral thread. false (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]]]> 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 00A4[D;F] (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. (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]]]> GI Cable 00C4(;D==0) (5,-3,F:6,S:2,D:8,1,-60)*[D:0..255, S:0..3, F:0..63]]]> This is a moderately robust protocol, but spurious decodes are still possible. Typical usage is the GI/Next Level/Motorola RC2x00 series. 0177 (806u,-2960u,1346u,T:1,F:8,D:7,-100)*[D:0..127,F:0..255,T@:0..1=0]]]> 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. 0112[D:6,F:1:7;D:1:6,F:8] (806u,-2960u,1346u,T:1,F:8,D:7,-100)* [D:0..127,F:0..255,T:0..1]]]> See Grundig16 (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. (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
(1,-1,D:4,F:8,P:1,1,^100m)*{P=1-#F%2}[D:0..15,F:0..255]]]> Decoder for a nonstandard Xbox remote. 01FF:JP1GXB[;D,F] (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]]]> Forum thread. 50 0.1 01DD (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. (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]]]> 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. IODATAn-x-y 01FF:JP1IOD[D,S,F:4^F:4:4^C:4,x,y;F] (F:5,1,-23.5m)* [F:0..31]]]> This is not a robust protocol, so spurious decodes are likely. 0006 (16,-8,D:8,F:8,1,^59.08m,(D:8,F:8,1,^46.42m)*) [D:0..255,F:0..255]]]> 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. 0034 JVC_squashed (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]]]> JVC-48 is the member of the Kaseikyo family with OEM_code1=3 and OEM_code2=31. Kaseikyo 00C9 001F[D&239,S&254,3,1;D:1:4,S:1,F] 001F:8(Panasonic VCR Combo)[D&239,S&254,3,1;D:1:4,S:1,F] 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] 01C9[;D,S,F] (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]]]> (16,-8,(D:8,F:8,1,^46.42m)*) [D:0..255,F:0..255]]]> This is a version of the JVC protocol for signals that has been too much reduced ("squashed") by the repeat finder. 0034 true true (D:8,F:8,1,^46.42m)* [D:0..255,F:0..255]]]> See JVC. 0034 (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]]]> This is the nominal form of the Kaseikyo protocol. 0.035 00F8:3{Z=D^S^F^(E*16),C=Z::4^Z:4,G=(C<<4)|E:4}[M,N,D,S;F,G] (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]]]> 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. 0.04 (16,-8,D:4,~D:4,F:8,~F:8,1,^105m,(16,-8,F:8,1,^105m)+)[D:0..15,F:0..255]]]> 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. 0066 (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]]]> A:3 A:1:3 A:2:4 A:1:6 A:1:7 B E:1 E:1:1 E:1:2 G H C/26 -1 -1 -1 -1 -1 -1 mode|Auto|Cool|Dry|Fan|Heat power1|Off|On fan|Auto|Low|Med|High unknown|Off|On sleep|Off|On temp|16C|17C|18C|19C|20C|21C|22C|23C|24C|25C|26C|27C|28C|29C|30C turbo|Off|On light|Off|On power2|Off|On swing|Off|Full|Pos1|Pos2|Pos3|Pos4|Pos5|Bottom|-|Middle|-|Top display|Off|Indoor Set|Indoor Ambient|Outdoor Ambient mainpower|On|Off An air conditioning protocol, see this thread. (6,-6,D:8,F:8,1,-8,1,-46)* [D:0..255,F:0..255]]]> 019B (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. (D:4,C:1,F:7,1,-26)* {C = (#F+1)&1} [D:0..15,F:0..127]]]> 01FF:JP1Luma (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.
 (D:3,F:7,1,^30.5m)* [D:0..7,F:0..127]]]> This is not a robust protocol, so spurious decodes are likely. ((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]]]> 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. RC6-M-32 RC6-6-32 012A:2[D,S;F] 012A[D,S;F] 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] 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] (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. (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. ((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]]]> The toggle bit T is inverted each time a new button press occurs. 01FF:JP1Metz (D:8,F:8,1,-80)* [D:0..127,F:0..255]]]> This is not a robust protocol, so spurious decodes are likely. It is also very similar in structure and timing to JVC{2} protocol. 0014[D;F] 01A4[D;F] (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. Kaseikyo (16,-8,D:8,S:8,F:8,~F:8,1,^108m) [D:0..255,S:0..255=255-D,F:0..255]]]> Inspired by DecodeIR, we call a NEC signal without repeat "NEC". This decode normally indicates an incomplete learn. NEC-Shirriff-32 NEC-f16 NEC1-f16 NEC2-f16 NEC1-rnc true 005A(NEC1) 005A(NEC2) 01AD[;D,S,F:8,~F:8] 011A:JP1[D?0,S?0,D?1,S?1,D?2,S?2,D?3,S?3;F,??,,0] 01BA[D,S;F:8,~F:8] 01EA(;S==~D:8)[F,~F:8;D] 011A[D?0,S?0,D?1,S?1;F,??] 011A:2[D?0,S?0,D?1,S?1,D?2,S?2,D?3,S?3;F,??] 017E[D,S?0,S?1,S?2,S?3;??,,F] 0246[D,S?0,S?1,S?2,S?3,S?4,S?5;??,,F] 00B6[D;S,F] 00B6:JP1[D;S,F] (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]]]> A relaxed form (but used in some real devices) of the NEC protocol. Byte 3 and byte 4 are independent. NEC-Shirriff-32 01BA[D,S;F,E] 01FF:JP1f16[D,S,F;E] 01EA(;S==~D:8)[F,E;D] NEC-Yamaha YStyle=NEC|Y1|Y2|Y3 -1 E -1 (16,-8,data:length,-50m) ]]> 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.) false 0x (16,-8,data:32,1,^108m) [data:0..UINT32_MAX]]]> The NEC-Shirriff protocol with payload length set to 32, making it viable for decoding. (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]]]> 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:
  • Y=1: Only bits 0-6 are complemented.
  • Y=2: Only bits 1-7 are complemented.
  • Y=3: Only bits 1-6 are complemented.
 NEC-f16 NEC1-f16 NEC2-f16 NECx1-f16 NECx2-f16 NEC-Shirriff-32 011A:JP1[D?0,S?0,D?1,S?1,D?2,S?2,D?3,S?3;F,??,,Y] 01AD[;D,S,F:8,(~F:8)^(128*Y:1|Y:1:1)] 01BA[D,S;F:8,(~F:8)^(128*Y:1|Y:1:1)] (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]]]> The most commonly used version of the NEC protocol, repeating with dittos. Tutorial. NEC1-rnc Pioneer NEC-f16 NEC1-f16 NEC true 005A 011A[D?0,S?0,D?1,S?1;F,??,0] 011A:2[D?0,S?0,D?1,S?1,D?2,S?2,D?3,S?3;F,??,0] 017E[D,S?0,S?1,S?2,S?3;??,,F,0] 0246[D,S?0,S?1,S?2,S?3,S?4,S?5;??,,F,0] 00B6[D;S,F] 00B6:JP1[D,0;S,F] 01AD[;D,S,F:8,~F:8] 011A:JP1[D?0,S?0,D?1,S?1,D?2,S?2,D?3,S?3;F,??,0,0] 01BA[D,S;F:8,~F:8] 01EA(;S==~D:8)[F,~F:8;D,0] (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]]]> 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:
  • Y1: Only bits 0-6 are complemented.
  • Y2: Only bits 1-7 are complemented.
  • Y3: Only bits 1-6 are complemented.
 NEC-Shirriff-32 NEC-f16 true 01BA[D,S;F,E] 01FF:JP1f16[D,S,F;E] 01EA(;S==~D:8)[F,E;D,0] NEC1-Yamaha YStyle=NEC|Y1|Y2|Y3 -1 E -1 (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]]]> Variant of the NEC1 protocol with the checksum in byte 4 different (complement F and reverse the nibbles). NEC1-f16 NEC-Shirriff-32 0206 01AD[;D,S,F,~(((F:4)<<4)|F:4:4):8] (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]]]> 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:
  • Y=1: Only bits 0-6 are complemented.
  • Y=2: Only bits 1-7 are complemented.
  • Y=3: Only bits 1-6 are complemented.
 NEC-f16 NEC1-f16 NEC2-f16 NECx1-f16 NECx2-f16 NEC-Yamaha NEC-Shirriff-32 011A:JP1[D?0,S?0,D?1,S?1,D?2,S?2,D?3,S?3;F,??,,Y] 01AD[;D,S,F:8,(~F:8)^(128*Y:1|Y:1:1)] 01BA[D,S;F:8,(~F:8)^(128*Y:1|Y:1:1)] (16,-8,D:8,S:8,F:8,~F:8,1,^108m)* [D:0..255,S:0..255=255-D,F:0..255]]]> A variant of the NEC protocol, that repeats by repeating the whole intro sequence. Pioneer is distinguished from NEC2 only by frequency. NEC NEC-Shirriff-32 NEC2-f16 NEC-f16 true 005A 011A[D?0,S?0,D?1,S?1;F,??,1] 011A:2[D?0,S?0,D?1,S?1,D?2,S?2,D?3,S?3;F,??,1] 017E[D,S?0,S?1,S?2,S?3;??,,F,1] 0246[D,S?0,S?1,S?2,S?3,S?4,S?5;??,,F,1] 00B6:JP1[D,1;S,F] 01EA(;S==~D:8)[F,~F:8;D,1] 011A:JP1[D?0,S?0,D?1,S?1,D?2,S?2,D?3,S?3;F,??,1,0] (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]]]> 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:
  • Y1: Only bits 0-6 are complemented.
  • Y2: Only bits 1-7 are complemented.
  • Y3: Only bits 1-6 are complemented.
 NEC-Shirriff-32 NEC-f16 true 01EA(;S==~D:8)[F,E;D,1] NEC2-Yamaha YStyle=NEC|Y1|Y2|Y3 -1 E -1 (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]]]> (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]]]> See this thread for a recent discussion. true NECx1-f16 005A 011A[D?0,S?0,D?1,S?1;F,??,2] 011A:2[D?0,S?0,D?1,S?1,D?2,S?2,D?3,S?3;F,??,2] 011A:JP1[D?0,S?0,D?1,S?1,D?2,S?2,D?3,S?3;F,??,2,0] (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]]]> 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:
  • Y1: Only bits 0-6 are complemented.
  • Y2: Only bits 1-7 are complemented.
  • Y3: Only bits 1-6 are complemented.
 NECx-f16 true Samsung32 NECx1-Yamaha YStyle=NEC|Y1|Y2|Y3 -1 true (8,-8,D:8,S:8,F:8,~F:8,1,^108m)* [D:0..255,S:0..255=255-D,F:0..255]]]> NECx2-f16 005A 011A[D?0,S?0,D?1,S?1;F,??,3] 011A:2[D?0,S?0,D?1,S?1,D?2,S?2,D?3,S?3;F,??,3] 011A:JP1[D?0,S?0,D?1,S?1,D?2,S?2,D?3,S?3;F,??,3,0] (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]]]> 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:
  • Y1: Only bits 0-6 are complemented.
  • Y2: Only bits 1-7 are complemented.
  • Y3: Only bits 1-6 are complemented.
 NECx-f16 true NECx2-Yamaha YStyle=NEC|Y1|Y2|Y3 -1 (15,-10,D:8,S:8,F:8,6,^100m)* [D:0..255,S:0..255,F:0..255]]]> 0.04 00ED[D,S;F] (15,-10,D:4,F:8,6,^100m)*[D:0..15,F:0..255]]]> 0.04 ((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]]]> 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. RCMM32 50 0.04 Nokia32_endframe 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] 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] 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] 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)] X:7+(Y<<7) -1 -1 -1 ([][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]]]> A version of the Nokia32 protocol that sets T=0 except for the last frame, which has T=1. 50 0.04 0173:3(;X<128)[D,S,X,2;F] Nokia32 adds 128 in final frame ((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. (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]]]> 00B0[D,F:1:7;F:8] (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]]]> 0075[D,F:1:7;F:8] (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]]]> Taken from John Fine's contribution (fixed), modified for the setup here. 00BD:2[D;F] 00BD[D,F:1:7;F:8] (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. ([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]]]> 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. 021B:JP1 ([][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]]]> This is a relaxed version of the OrtekMCE protocol, in that it lacks the intro sequence. OrtekMCE Incomplete signal (1,-5,1,-5,T:1,D:1,F:8,1,^120m)* [D:0..1,F:0..255,T:0..1]]]> This is a moderately robust protocol, but spurious decodes are still possible. Pace 0095[D;F] (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]]]> Panasonic protocol is the most commonly seen member of the Kaseikyo family. 00C9 001F[D&239,S&254,2,32;~D:1:4,S:1,F] 001F:8(Panasonic VCR Combo)[D&239,S&254,2,32;~D:1:4,S:1,F] 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] 00CD:2(Panasonic Combo)[D;S,F] 00CD:JP1[D;S,F] Kaseikyo (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]]]> 0109[D,S,X;F] Kaseikyo56 (4,-4,D:5,F:6,~D:5,~F:6,1,-44m)* [D:0..31,F:0..63]]]> 0000[D?0,D?1,D?2;??,F] 0117[;D,F] (2,-8,1,D:8,F:8,2,-100m) [D:0..255,F:0..255]]]> (24,-21148,(F:5,1,-28m)+)[F:0..31]]]> 0001 (F:8,~F:8,^102m)*[F:0..255]]]> (F:6,12,-27m)*[F:0..63]]]> (F:5,1,-27)*[F:0..31]]]> 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. 0083 (16,-8,D:8,S:8,F:8,~F:8,1,^108m)* [D:0..255,S:0..255=255-D,F:0..255]]]> 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. 00E2(;D==~S:8)[D;F] 007E(;D==~S:8&&F:1:5==0)[D;0,0,0,F] 007E:2(Pioneer DVD2;D==~S:8&&F:1:5==0)[D;F] 007E:2(Pioneer MIX;D==~S:8)[D;0,0,0,F] 007E:3(;D==~S:8)[D;0,0,0,F] 007E:4(;D==~S:8)[D?0,D?1,D?2,D?3;0,0,??,F] 007E:5(;D==~S:8)[D?0,D?1,D?2,D?3;0,0,??,F] 005F(;D==~S:8)[D;F,F] 006A(;D==~S:8)[D?0,D?1,D?2;??,F,F] 006A:JP1(;D==~S:8)[D?0,D?1,D?2,D?3;??,F,F] 006A:4(;D==~S:8)[D?0,D?1,D?2,D?3;??,F,F] 017C:JP1[;D,F,D,F] (160<=D && D<=165) || D==168 || D==170 || D==171 || D==173 || D==175 ; NEC2 39700 42000 (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]]]> Pioneer-Mix 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). 007E(;F:1:5==1)[D0,D,F0;1,1,1,F] 007E:2(Pioneer DVD2;F:1:5==1)[D0,D,F0;F] 007E:2(Pioneer MIX)[D0,D,F0?1,F0?2;1,??,1,F] 007E:3[D0,D,F0?1,F0?2,F0?3,F0?4;1,??,1,F] 007E:4[D0,F0?1,F0?2,F0?3,F0?4,D;1,??,5,F] 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] 005F(;D0==D)[D;F0,F] 006A(;D0==D)[D?0,D?1,D?2;??,F0,F] 006A:JP1(;D0==D)[D?0,D?1,D?2,D?3;??,F0,F] 006A:4(;D0==D)[D?0,D?1,D?2,D?3;??,F0,F] 017C:JP1[;D0,F0,D,F] (162<=D && D<=165) || D==168 || D==170 || D==173 || D==175 ; NEC2 (D0 != D) || (F0 != F) ; Pioneer 39700 41000 (16,-8,D:8,1,-8,F:8,1,^63m)*[D:0..255,F:0..255]]]> This is not a robust protocol, so spurious decodes are likely. 005C[D;F] 011B[0;D,F] (16,-8,D:8,1,-8,F:8,1,^63m)*[D:0..255,F:0..255]]]> This is not a robust protocol, so spurious decodes are likely. 011B[1;D,F] ((1,~F:1:6,T:1,D:5,F:6,^114m)*,T=1-T)[D:0..31,F:0..127,T@:0..1=0]]]> In Philips' (the creator of the protocol) terminology, "D" is called "System" and "F" is called "Command". Tutorial. 00E8[D?0,F:1:6?0,D?1,F:1:6?1,D?2,F:1:6?2;??,F:7] 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] 0073[;0,F,D] 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] ((1, ~D:1:5,T:1,D:5,F:7,^114m)*,T=1-T) [D:0..63,F:0..127,T@:0..1=0]]]> StreamZap 0182:2[D?0,D?1,0;??,F] (1, ~D:1:5,T:1,D:5,F:7,^114m)*[D:0..63,F:0..127,T@:0..1=0]]]> StreamZap-57 0182:2[D?0,D?1,1;??,F] 0182[D?0,D?1;??,F] ((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]]]> In Philips' (the creator of the protocol) terminology, "D" is called "System", "S" is called "Command", and F is called "Data". 00F2[D,S:1:6;S:7,F:6] 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] 0.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]]]> RC6 is the name used for the first member of the RC6 family of protocols. Technically this is RC6-0-16. Tutorial. 0058[D;F] 0058:2(RC-6)[D;F] 0184:2[D?0,D?1,D?2;1,,,??,F] RC6-M-16 300 ((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]]]> The executors for this protocol do not toggle T. This no-toggle version is commonly used in Sky and Sky+ remotes. RC6-6-20-notoggle 0020(;T==0)[6,D,S;F] 0020:2[6,D,S,T;F] 300 ((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]]]> 300 0058:2(RC6-M-16)[D,M;F] ((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]]]> 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. 0092:3(ReplayTV (Official);M==6&&T==0)[D,S;F] -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]]]> The executor for this protocol does not toggle T. 0240(;T==0)[D,S,M,0;F] 300 ((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]]]> 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. 300 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]> 012A:2(MCE;M==6&&OEM1==128&&T==0)[D:7,OEM2;F] X -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]]]> This is the "RC6-M-N protocol" made usable for the case of N=56. 300 (8,-8,D:4,F:8,~D:4,~F:8,1,-16)*[D:0..15,F:0..255]]]> 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. 00AF[D;F] 00AF:2[D,0;F] 0114[;D,0,F] ([40][8],-8,D:4,F:8,~D:4,~F:8,2,-16)+[D:0..15,F:0..255]]]> See RCA. 002D[D;F] (8,-8,D:4,F:8,~D:4,~F:8,1,-16)*[D:0..15,F:0..255]]]> 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. 0091 ([40][8],-8,D:4,F:8,~D:4,~F:8,2,-16)+[D:0..15,F:0..255]]]> See RCA-38. (1:1,T:1,D:3,F:6,1,-45m)* {}[D:0..7,F:0..63, T@:0..1=0]]]> 0045 RECS80-0045 (1:1,T:1,D:3,F:6,1,-45m)* [D:0..7,F:0..63, T@:0..1=0]]]> 0045 (1:1,T:1,D:3,F:6,1,^138m)* [D:0..7,F:0..63, T@:0..1=0]]]> 0068 (1:1,T:1,D:3,F:6,1,^138m)* [D:0..7,F:0..63, T@:0..1=0]]]> 0090 (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]]]> Replay is a member of the RC6 family; technically it is RC6-6-24. RC6-6-24 RC6A 0092[D,S;F] 0092:3(ReplayTV (Official))[D,S;F] 0092:3(RC6-M-24)[D,S,6,0;F] RC6-M-24 (1,-29,0:1,D:4,F:6,1,-29,1,-100285u)*[D:0..15,F:0..63]]]> Revox uses no modulation. (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]]]> 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. true Roku-8bit NEC NEC2 021A[D,S;F] (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]]]> 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. true NEC NEC2 021A[D,S;F] (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. (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. (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]]]> Different parameterization of RTI_Relay. false (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. (4497u,-4497u,D:16,1,-4497u,S:4,F:16,1,^120m)*[D:0..65335,S:0..15,F:0..65535]]]> Forum thread. (8,-8,D:6,S:6,F:8,1,^100m)*[D:0..63,S:0..63,F:0..255]]]> This is a moderately robust protocol, but spurious decodes are still possible. 002F (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]]]> Reference. 01B5[D,S,E;F] 0.2 Samsung-SMT-G (4,-4,D:6,F:6,~D:6,~F:6,1,-40)*[D:0..63,F:0..63]]]> ScAtl-6 is distinguished from Emerson only by frequency. Most Scientific Atlanta cable tuners instead use the Panasonic_Old protocol. 0078[D;F] (<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]]]> 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.) 0161:3[0,D,S,E;F] 0161:5[0,D,S?0,,S?1,E;0,??,F] Sejin-1-56 (<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]]]> 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.) 0161:3[1,D,S,E;F] 0161:5[1,D,S?0,,S?1,E;0,??,F] (D:5,F:8,1:2,1,-165,D:5,~F:8,2:2,1,-165)*[D:0..31,F:0..255]]]> 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. Sharp{1} 001C[D;F] 009C(Sharp Combo (Official))[;D,0,F] 01AC[;1,D,F,D|(F:7)*32] (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]]]> SharpDVD is the member of the Kaseikyo family with OEM_code1=170 and OEM_code2=90. E=1 in all instances seen so far. 00F8[D,S;F] 00F8:2[D,S;F] 00F8:3[D,S;F] Kaseikyo (D:5,F:8,1:2,1,-165)*[D:0..31,F:0..255]]]> See Sharp. 001C[D;F] 009C(Sharp Combo (Official))[;D,0,F] 01AC[;1,D,F,D|(F:7)*32] (D:5,~F:8,2:2,1,-165)*[D:0..31,F:0..255]]]> See Sharp. 001C[D;F] 009C(Sharp Combo (Official))[;D,0,F] 01AC[;1,D,F,D|(F:7)*32] (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. (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. (2072,-484,F:2,D:3,C:4,-2300)*{C = F*4 + D + 3}[F:0..3,D:0..7]]]> 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. 01FF:Somfy2[;D,F*4+D+3,F] (4,-1,F:7,D:5,^45m)*[D:0..31,F:0..127]]]> 00CA[D?0,0?0,D?1,0?1;??,F] 00DE[,,D;1,F] 0027:old[;F,D] 0027:2[;0,D,0,F] (4,-1,F:7,D:8,^45m)*[D:0..255,F:0..127]]]> 00CA{X=D<32}[D?0,X?0,D?1,X?1;??,F] 0027:2[;1,D,0,F] (4,-1,F:7,D:5,S:8,^45m)*[D:0..31,S:0..255,F:0..127]]]> 00DE[D,S;0,F] 0027:old[D,S;F] 0027:2[S?1,S?2,S?3,S?4;2,D,??,F] (4,-1,F:8,^45m)[F:0..255]]]> ((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]]]> SonyDSP_relaxed Sony15 01FF:JP1DSP[;F] ((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]]]> Sony15 true SonyDSP Final data bit missing (1,~F:1:6,T:1,D:6,F:6,^114m)*[D:0..63,F:0..127,T@:0..1=0]]]> 01FF:JP1SZ[D;F] (1,~F:1:6,T:1,D:6,F:6,^114m)*[D:0..63,F:0..127,T@:0..1=0]]]> 01FF:JP1S57[D;F] (16,-8, D:4,F:8,~D:4,~F:8, -32)*[D:0..15,F:0..255]]]> mode time/6 (time%6)*10 swing/7 modesw|Off|On timesw|Off|On mode2|-|heat|dry|cool|-|-|-|fan|feel %s/%s|modesw|mode2 fan|auto|sleep|low|med|-|high swing|Off|On %s/%02d:%02d|timesw|hrs|mins (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]]]> 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
 (1,-1,D:5,S:5,F:7,-89m)*[D:0..31,S:0..31,F:0..127]]]> 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. 01BB (1,-1,D:5,S:5,F:7,-89m)*[D:0..31,S:0..31,F:0..127]]]> 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. 01BD (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]]]> 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. 00BB[(D<<4)+X:4,S;F] Kaseikyo ((D:4,T:1,D:1:4,F:6,1,^80m)*,T=1-T)[D:0..31,F:0..63,T@:0..1=0]]]> This is not a robust protocol, so spurious decodes are likely. 004B ((D:4,T:1,F:7,1,^80m)*,T=1-T) [D:0..15,F:0..127,T@:0..1=0]]]> Thomson 004B:7 (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]]]> NEC1-f16 0111[D,S,U;F] 0111:2byte[D,S,U;F] (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. ([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]]]> Velodyne is a close relative of XMP. 0.04 100 01FF:JP1VD (~F:5,1,-17)*[F:0..31]]]> This is not a robust protocol, so spurious decodes are likely. 0021 (0:1,4,-4,F:32,1,-50m)[F:0..0xFFFFFFFF]]]> From IRremote, see also this issue. "Tested with Whynter ARC-110WD." (7,-7,C:4,1:1,~C:4,0:1,21,-7)*[C:0..15]]]> This protocol is used to send X10 command codes to an IR543 receiver or compatible device. X10.n X10 Cmd=all off|all lights on|turn on|turn off|dim|brighten|all lights off|(reserved)| hail req|hail ack|preset dim|cmd11|cmd12|status is on|status is off|status req X10.n (7,-7,D:4,0:1,~D:4,1:1,21,-7)*[D:0..15]]]> 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.n X10 DevNbr=1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16 X10.n (7,-7,H:4,~H:4,21,-7)*[H:0..15]]]> 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. X10H HouseCode=A|B|C|D|E|F|G|H|I|J|K|L|M|N|O|P (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]]]> 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. true Has non-functional first frame (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]]]> Protocol found in the Xiaomi Mi Box Streaming Android TV Device. Defined and described in this thread. 0.1 023B[;D,F] ([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]]]> DecodeIR documentation. 0.04 100 016C:2[D,S,OEM;F:8:8,F:8] ([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]]]> XMP 0.04 100 016C:2[D,S,OEM;F:8] ([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]]]> XMP 0.04 100 016C:2[D,S,OEM;,F] ([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]]]> XMP 0.04 100 ([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]]]> XMPff XMP-1 0.04 100 ([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]]]> XMPff XMP-2 0.04 100 ([][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]]]> 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. 01CD[D,S,E,0;F] ([][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]]]> 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. 01CD[D,S,E,1;F] (S:1,<1:2|2:2>(F:D),-90m)*[S:0..1,F:0..255,D:5..8]]]> 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". false (S:1,<1:2|2:2>(F:D),-90m)*{D=5}[S:0..1,F:0..255]]]> Special case of the Zenith protocol, with D = 5. 0022[5,,S;F] (S:1,<1:2|2:2>(F:D),-90m)*{D=6}[S:0..1,F:0..255]]]> Special case of the Zenith protocol, with D = 6. 0022[6,,S;F] (S:1,<1:2|2:2>(F:D),-90m)*{D=7}[S:0..1,F:0..255]]]> Special case of the Zenith protocol, with D = 7. 0022[7,,S;F] (S:1,<1:2|2:2>(F:D),-90m)*{D=8}[S:0..1,F:0..255]]]> Special case of the Zenith protocol, with D = 8. 0022[8,,S;F]