-
Notifications
You must be signed in to change notification settings - Fork 4
/
IrpProtocols.xml
3052 lines (2794 loc) · 168 KB
/
IrpProtocols.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<?xml-stylesheet type="text/xsl" href="IrpProtocols2html.xsl"?>
<!-- Copying and distribution of this file, with or without modification,
are permitted in any medium without royalty provided the copyright
notice and this notice are preserved. This file is offered as-is,
without any warranty.
-->
<!--
Notes for those modifying this file:
Syntax of the XML file is defined in the W3C Schema http://www.harctoolbox.org/schemas/irp-protocols.xsd
(although possibly easier to digest for machines than for humans).
This defines the XML name space irp=http://www.harctoolbox.org/irp-protocols,
using the prefix irp.
Semantics is/should be documented in the main IrpTransmogrifier documentation.
These notes are therefore to be seen as informal help to people modifying, not
as a defining document.
This document is read by IrpTransmogrifier with XInclude processing enabled, so
it is possible to use include documents according to the XInclude standard.
Semantics of some of the elements:
irp:parameter: The irp:parameter can be used to define all sort of information associated with
a particular protocol. IrpTransmogrifier ignores the ones with names it does not
use, except that it can be inquired about the values from the API. Of course, using
another program to read the file and extract the value as an XPath expression is also possible.
(For example: /irp:protocols/irp:protocol[@name="Denon"]/irp:parameter[@name="uei-executor"]/text()
extracts the text of the uei-executor for the Denon protocol).
Such a parameter contains of an arbitrary string content, or, by setting the attribute type to "xml",
an arbitrary well-formed XML fragment. For a certain name (value of the name attribute), the
element can occur multiple times. It will be available to a reading program as a List
in Java, one list element per occurrence on the parameter with the particular name.
irp:documentation: Arbitrary documentation of the present protocol. Can contain (X)HTML markup.
More formally: it is considered as an XML document fragment. A reading user or program
can request it either as XHTML (an XML document fragment), or as text (which is
nothing but a dumb rendering of the HTML content).
irp:irp: A text string, possibly spanning several lines, containing the IRP representation
of the present protocol. Use of CDATA sections is recommended, however not required.
List of parameters recognized by IrpTransmogrifier:
prefer-over
If a signal has multiple decodes, the present protocol is preferred over the one mentioned as prefer-over.
May be given several times.
Alternatively, the content of the element may have two parts: a predicate and a protocol name,
separated by a semi colon (";").
The predicate is evaluated for the current, to be preferred, protocol and its parameters.
Only if the predicate (which is an <code>expression</code> in the sense of IRP) evaluates to non-zero,
the preferance takes effect.
(See the protocol Pioneer for an example.)
(Normally, a specialized protocol should be preferred over a more general one.)
alt_name
Alternative name, ("alias", "synonym") for the present protocol.
reject-repeatless
When decoding, normally the repeat sequence may match 0 times, i.e. not at all.
If this parameter is true at least one repeat must be present for a match to be recognized.
(Strictly speaking, this would have been possible to achieve by using "+" instead of "*"
for the repeat indicator, but this would have other disadvantages.)
decodable
Setting this to false prohibits the program from trying to use this protocol for decoding.
Normally, this is only used when the IRP form makes protocol decoding impossible or not feasible.
decode-only
Setting this to true makes the program refuse to render the protocol.
Should be used only for "protocols" that denote incomplete or otherwise flawed decodes,
for example with missing parts or non-matching checksums.
The following define protocol-private values of otherwise global parameters:
absolute-tolerance
See Numerical equality between durations. Current default: 100.0.
relative-tolerance
See Numerical equality between durations. Current default: 0.3.
frequency-tolerance
Tolerance in Hz for frequency comparisons. Set to -1 to disable frequency check. Current default: 2000.0.
frequency-low
frequency-high
If present, replaces the frequency-tolerance parameter.
In this case, frequencies between frequency-low and frequency-high (inclusive) will be accepted.
minimum-leadout
Minimal duration in micro seconds that is accepted as final duration. Current default: 20000.0.
Other parameters, both with type="xml" and type="text", are allowed,
but ignored by IrpTransmogrifier. They may be used by another program.
Additional notes on usage in RMIR:
Within an irp:protocol element, an irp:parameter with name uei-executor is read by RMIR in the decoding
of learned signals, the conversion of a set of signals to a device upgrade and import and export between
a Girr file or an IRScope ict file and a device upgrade. There may be multiple irp:parameter entries
within the same irp:protocol element. The content of an irp:parameter entry is either an executor
descriptor or, with its attribute type set to "xml", an XML fragment that usually includes an executor
descriptor. XML fragments that do not include an executor descriptor affect only the display of learned
signal decodes in RMIR. Conversion, import and export cannot be performed in these cases.
An executor descriptor is a string that identifies, for the protocol concerned, a unique executor in the
protocols.ini file of RMIR. It also specifies how the parameter values contained in a signal decode may be
mapped to the device and command parameters of the executor for the executor to reproduce that signal. The
syntax and semantics of an executor descriptor are specified in the document Executor Descriptor Notation:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=25672
The uei-executor entry that applies to a decode shown in the Learned Signals tab of RMIR is selected as
follows. The entries that contain an executor descriptor are considered first, with those of type XML
taking precedence over any others. The entry that applies is the first that is valid for the decode concerned.
An executor is valid for a decode if its executor descriptor has no qualifier or if the qualifier evaluates
true for that decode. If there are no valid entries with an executor descriptor then one without such a
descriptor applies, if such an entry is present.
If the uei-executor has type "xml" then its content uses the XML name space
rm=https://sourceforge.net/projects/controlremote/files/RemoteMaster.
This content is a single rm:deployment element with an attribute "executor" whose value is the executor
descriptor. An empty string is used to signify the absence of an executor descriptor. This element may
also contain the following additional elements and will normally contain at least one of them:
rm:assignment: This may occur multiple times. It has a single attribute "target" whose value is the name
of a parameter of the protocol, or an additional name that is defined by the assignment. The content of
the element is an IRP bare expression that evaluates, in the context of the parameter values from the decode
and any earlier rm:assignment elements, to the value to be assigned to that name. A definitionSpec in an
executor descriptor has this same functionality but the two methods of assignment differ in their scope.
Assignments made in a definitionSpec apply to all evaluations, which are those of the qualifier (if any)
and parameterSpec of the executor descriptor and those of the device parameters displayed in the Learned
Signals tab of RMIR. Assignments made in an rm:assignment are evaluated after those of a definitionSpec
and apply only to the evaluation of those device parameter values displayed in RMIR. Assigning the value
-1 to a name, either in the definitionSpec of an executor descriptor or with an rm:assignment, suppresses
the display of that name in RMIR. An illustration of these features is given below.
rm:translator: Like rm:assignment, this may occur multiple times with a single attribute "target". Its
allowed values are the names assigned after the evaluation of all rm:assignments. It has three uses,
(a) when a name evaluates to a choice index, it allows RMIR to display the choice value rather than the
numerical choice index, (b) it allows two or more values to be combined for display, such as time=xx:yy
rather than hrs=xx, mins=yy, and (c) for names whose values are displayed as numbers, it allows an alternate
radix to be used instead of the default base 10. For (a) the content of the element has the form
<choice name> = <choice list>, where the choice list is a list of choice values separated by vertical bars.
For (b) it again is a list separated by vertical bars, but here the first item is a format string as in
Java String.format(..) and the following items are the names whose values are the arguments of the format
string. For (c) the content is the radix prefix, selected from the list 0b, 0q, 0 and 0x for base 2, 4,
8, 16 respectively and the value is displayed with the corresponding prefix.
rm:protocolName: This may occur at most once. It has no attributes and its content is a display name for
the protocol that RMIR will use in place of the value of the name attribute of the protocol.
rm:commentItem: This may occur at most once. It has no attributes and its content is text that RMIR
will display as a comment accompanying the decode of the signal. Its typical use is where more than one
protocol is given the same rm:protocolName and this comment distinguishes between them. Examples would
be two protocols differing only in frequency where the comment gives the frequency, or a relaxed version
of a protocol given an rm:protocolName that is the name of the original protocol with a comment such
as "Incomplete signal".
The NEC1-f16 protocol provides an illustration of several of these features. It contains the entry
<irp:parameter name="uei-executor" type="xml">
<rm:deployment executor="011A:JP1{X=F^E^129,Y=2*X:1+X:1:7,E=-1}(;X:6:1==63)[D?0,S?0,D?1,S?1,D?2,S?2,D?3,S?3;F,??,0,Y]">
<rm:protocolName>NEC1-Yamaha</rm:protocolName>
<rm:translator target="Y">YStyle=NEC|Y1|Y2|Y3</rm:translator>
<rm:assignment target="X">-1</rm:assignment>
</rm:deployment>
</irp:parameter>
Here F and E are command bytes resulting from the protocol decode. The definitionSpec of the executor
descriptor defines additional names X and Y. E is used only as an auxiliary variable in the definition of
X and does not need to be displayed, so after its use in determining X, it is assigned the value -1.
X is used only in the qualifier X:6:1==63. If this evaluates true then RMIR displays the protocol as
NEC1-Yamaha, otherwise it passes to the next entry and displays it as NEC1-f16. When true, the command
parameters of the 011A:JP1 executor are determined by F and Y. For display in RMIR, Y is converted by
an rm:translator to a choice named YStyle with one of the values NEC, Y1, Y2, Y3. X is set to -1 by
an rm:assignment to suppress its display. This cannot be done in the definitionSpec as X is used in the
qualifier. Note that when the qualifier evaluates true, the original value of E is completely determined
by F and Y. When the qualifier evaluates false and the protocol is displayed as NEC1-f16, the complete
entry for the NEC1-f16 protocol shows that E is renamed for display as OBC2, by first setting OBC2 to E
and then setting E to -1 to suppress its display.
RMIR v2.10 build 2 and later support a minor enhancement to the second draft of the Executor Descriptor
Notation. As described above, additional names defined in a definitionSpec may be used in a qualifier
as well as in a parameterSpec. Also, the three bracketted parts of an an executor descriptor, namely
the infoSpec, definitionSpec and parameterSpec may be given in any order. This enables a definitionSpec
to precede an infoSpec containing a qualifier if that qualifier uses the additional defined names. This
ordering is not required but it improves the readability of the entry.
-->
<irp:protocols xmlns="http://www.w3.org/1999/xhtml"
xmlns:rm="https://sourceforge.net/projects/controlremote/files/RemoteMaster"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
version="2024-03-14"
xsi:schemaLocation="http://www.harctoolbox.org/irp-protocols http://www.harctoolbox.org/schemas/irp-protocols.xsd"
xmlns:irp="http://www.harctoolbox.org/irp-protocols">
<irp:protocol name="48-NEC">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">Like <a href="#DecodeIR">DecodeIR</a>, we call a 48-NEC* signal without repeat "48-NEC".</irp:documentation>
<irp:parameter name="decode-only">true</irp:parameter>
</irp:protocol>
<irp:protocol name="48-NEC1">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:parameter name="reject-repeatless">true</irp:parameter>
</irp:protocol>
<irp:protocol name="48-NEC2">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:parameter name="reject-repeatless">true</irp:parameter>
</irp:protocol>
<irp:protocol name="AdNotam">
<irp:irp>
<![CDATA[{35.7k,895,msb}<1,-1|-1,1>(1,-2,1,D:6,F:6,^114m)*[D:0..63,F:0..63]]]>
</irp:irp>
<irp:documentation xml:space="preserve">Very similar to <a href="#RC5">RC5</a>, except AdNotam uses two start bits, and no toggle bit.</irp:documentation>
</irp:protocol>
<irp:protocol name="Aiwa">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:parameter name="uei-executor">005E:2</irp:parameter>
<irp:parameter name="uei-executor">009E[S;D,F]</irp:parameter>
</irp:protocol>
<irp:protocol name="Aiwa2">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">Source: Dave Reed's program <a href="http://www.hifi-remote.com/forums/viewtopic.php?t=100614">Teaser</a>.</irp:documentation>
<irp:parameter name="uei-executor">005E:2</irp:parameter>
</irp:protocol>
<irp:protocol name="Akai">
<irp:irp>
<![CDATA[{38k,289}<1,-2.6|1,-6.3>(D:3,F:7,1,^25.3m)*[D:0..7,F:0..127]]]>
</irp:irp>
<irp:parameter name="uei-executor">000D[D:2;D:1:2,F]</irp:parameter>
</irp:protocol>
<irp:protocol name="Akord">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">Protocol found in Akord HDMI switches. Similar to <a href="#NEC1">NEC1</a>, but with different timing.
See <a href="http://www.hifi-remote.com/forums/viewtopic.php?p=137873">forum thread</a>.</irp:documentation>
</irp:protocol>
<irp:protocol name="Amazon_Fan">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation>This protocol was discovered/invented and discussed in <a href="http://www.hifi-remote.com/forums/viewtopic.php?t=103390">this thread</a>.</irp:documentation>
<irp:parameter name="uei-executor" type="xml">
<rm:deployment executor="01FF:JP1Amazon[D;F]">
<rm:protocolName>Amazon Fan</rm:protocolName>
</rm:deployment>
</irp:parameter>
</irp:protocol>
<irp:protocol name="Amino">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">Amino equipment use both 37 and 56KHz, but the duration of the half-bit is always 268.
<a href="#Zaptor-36">Zaptor</a> is a closely related protocol which for which the half-bit duration is 330.</irp:documentation>
<irp:parameter name="prefer-over">Amino-56</irp:parameter>
<irp:parameter name="absolute-tolerance">100</irp:parameter>
<irp:parameter name="relative-tolerance">0.2</irp:parameter>
<irp:parameter name="uei-executor" type="xml">
<rm:deployment executor="019C[D,0,0]">
<rm:commentItem>Freq=37kHz</rm:commentItem>
</rm:deployment>
</irp:parameter>
<irp:parameter name="uei-executor" type="xml">
<rm:deployment executor="019C:JP1[D,0]">
<rm:commentItem>Freq=37kHz</rm:commentItem>
</rm:deployment>
</irp:parameter>
</irp:protocol>
<irp:protocol name="Amino-56">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:parameter name="absolute-tolerance">100</irp:parameter>
<irp:parameter name="relative-tolerance">0.2</irp:parameter>
<irp:parameter name="uei-executor" type="xml">
<rm:deployment executor="019C[D,0,1]">
<rm:protocolName>Amino</rm:protocolName>
<rm:commentItem>Freq=56kHz</rm:commentItem>
</rm:deployment>
</irp:parameter>
<irp:parameter name="uei-executor" type="xml">
<rm:deployment executor="019C:JP1[D,1]">
<rm:protocolName>Amino</rm:protocolName>
<rm:commentItem>Freq=56kHz</rm:commentItem>
</rm:deployment>
</irp:parameter>
</irp:protocol>
<irp:protocol name="Anthem">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">Anthem framing is very similar to <a href="#NEC1">NEC</a>, and also uses 32 bits of data. However, the leadout is much shorter. The signal is sent at least 3 times.</irp:documentation>
<irp:parameter name="uei-executor">0123(Anthem)[D,S,Unit;F:6]</irp:parameter>
<irp:parameter name="uei-executor">0123(Anthem Combo)[D,S;F,Unit]</irp:parameter>
<irp:parameter name="prefer-over">Anthem_relaxed</irp:parameter>
<irp:parameter name="prefer-over">NEC2-f16</irp:parameter>
</irp:protocol>
<irp:protocol name="Anthem_relaxed">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve"><a href="#relaxed">Relaxed version</a> of the Anthem protocol.</irp:documentation>
<irp:parameter name="decode-only">true</irp:parameter>
<irp:parameter name="uei-executor" type="xml">
<rm:deployment executor="0123(Anthem)[D,S,Unit;F:6]">
<rm:protocolName>Anthem</rm:protocolName>
<rm:commentItem>Non-standard repeats</rm:commentItem>
</rm:deployment>
</irp:parameter>
<irp:parameter name="uei-executor" type="xml">
<rm:deployment executor="0123(Anthem Combo)[D,S;F,Unit]">
<rm:protocolName>Anthem Combo</rm:protocolName>
<rm:commentItem>Non-standard repeats</rm:commentItem>
</rm:deployment>
</irp:parameter>
</irp:protocol>
<irp:protocol name="Apple">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">This protocol uses the same framing as <a href="#NEC1">NEC1</a>. 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.</irp:documentation>
<irp:parameter name="uei-executor">01E0{S=135,E=PairID}[D?0,E|||D?1,S,D?2,D?3;F,??,0]</irp:parameter>
<irp:parameter name="prefer-over">NEC1-f16</irp:parameter>
<irp:parameter name="prefer-over">NEC2-f16</irp:parameter>
<irp:parameter name="prefer-over">NEC1</irp:parameter>
<irp:parameter name="prefer-over">NEC-Shirriff-32</irp:parameter>
</irp:protocol>
<irp:protocol name="Archer">
<irp:irp>
<![CDATA[{0k,12}<1,-3.3m|1,-4.7m>(F:5,1,-9.7m)* [F:0..31]]]>
</irp:irp>
<irp:documentation xml:space="preserve">This is not a robust protocol, so <A href="#spurious">spurious decodes</A> are likely.</irp:documentation>
<irp:parameter name="relative-tolerance">0.1</irp:parameter>
</irp:protocol>
<irp:protocol name="arctech">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve"><p>Protocol used by several manufacturers of 433MHz RF controlled switches, like
<a href="http://www.intertechno.at">Intertechno</a>, Duewi, ELRO, KlikAanKlikUit, and the URC light control kit, and many other.
Appears to be introduced by the Taiwanese firm <a href="http://www.arctech.com.tw">ARC Technology</a>.
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.</p>
<p>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".</p>
</irp:documentation>
</irp:protocol>
<irp:protocol name="arctech-38">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">Same as <a href="#arctech">arctech</a>, but with an IR-typical modulation.</irp:documentation>
</irp:protocol>
<irp:protocol name="Audiovox">
<irp:irp>
<![CDATA[{40k,500}<1,-1|1,-3>(16,-8,D:8,1,-8,F:8,1,-40)*[D:0..255,F:0..255]]]>
</irp:irp>
<irp:parameter name="uei-executor">005D[D;F]</irp:parameter>
</irp:protocol>
<irp:protocol name="B&O">
<!-- Very seldom 455kHz measurements are correct -->
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">455kHz protocol used by some Bang & Olufsen equipment.
<a href="http://www.hifi-remote.com/forums/viewtopic.php?t=12486">Forum thread.</a>
</irp:documentation>
<irp:parameter name="uei-executor">00EB[D:1:8,D:8,1;F,F]</irp:parameter>
<irp:parameter name="uei-executor">00EB:4[D:1:8,D:8,1;F]</irp:parameter>
<irp:parameter name="frequency-tolerance">-1</irp:parameter>
</irp:protocol>
<irp:protocol name="B&O repeat">
<!-- Very seldom 455kHz measurements are correct -->
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">From David Reed's program <a href="http://www.hifi-remote.com/forums/viewtopic.php?t=100614">Teaser</a>.</irp:documentation>
<irp:parameter name="uei-executor">00EB:4[D:1:8,D:8,1;F]</irp:parameter>
<irp:parameter name="frequency-tolerance">-1</irp:parameter>
</irp:protocol>
<irp:protocol name="Barco">
<irp:irp>
<![CDATA[{0k,10}<1,-5|1,-15>(1,-25, D:5,F:6, 1,-25,1,-120m)*[D:0..31,F:0..63]]]>
</irp:irp>
<irp:documentation xml:space="preserve">This protocol uses no modulation of the signal.
This is a moderately robust protocol, but <A href="#spurious">spurious decodes</A> are still possible.</irp:documentation>
<irp:parameter name="absolute-tolerance">60</irp:parameter>
<irp:parameter name="uei-executor">002A</irp:parameter>
<irp:parameter name="uei-executor">00F3</irp:parameter>
</irp:protocol>
<irp:protocol name="Blaupunkt">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:parameter name="alt_name">Motorola</irp:parameter>
<irp:parameter name="uei-executor">00A5[D,0;F]</irp:parameter>
</irp:protocol>
<irp:protocol name="Bose">
<irp:irp>
<![CDATA[{38.0k,500,msb}<1,-1|1,-3>(2,-3,F:8,~F:8,1,-50m)* [F:0..255]]]>
</irp:irp>
<irp:parameter name="uei-executor">010C</irp:parameter>
</irp:protocol>
<irp:protocol name="Bryston">
<irp:irp>
<![CDATA[{38.0k,315}<1,-6|6,-1>(D:10,F:8,-18m)* [D:0..1023,F:0..255]]]>
</irp:irp>
<irp:parameter name="minimum-leadout">15000</irp:parameter>
</irp:protocol>
<irp:protocol name="CanalSat">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">The <A href="#repeat">repeat frames</A> 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".
</irp:documentation>
<irp:parameter name="uei-executor">018C</irp:parameter>
<irp:parameter name="alt_name">ruwido r-step</irp:parameter>
</irp:protocol>
<irp:protocol name="CanalSatLD">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">The official name for CanalSatLD is "ruwido r-step"</irp:documentation>
<irp:parameter name="uei-executor">018C:JP1</irp:parameter>
</irp:protocol>
<irp:protocol name="Canon">
<irp:irp>
<![CDATA[{33k,1}<16p,-240p|16p,-175p>(F:1)2[F:0..1]]]>
</irp:irp>
<irp:documentation xml:space="preserve">IR protocol for many Canon cameras. With F=0 it triggers immediately, F=1 it triggers after a delay of approximately two seconds.</irp:documentation>
<irp:parameter name="relative-tolerance">0.1</irp:parameter>
<irp:parameter name="absolute-tolerance">50</irp:parameter>
</irp:protocol>
<irp:protocol name="Denon">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">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 <a href="#Denon{1}">Denon{1}</a> or <a href="#Denon{2}">Denon{2}</a>.
Denon, Denon{1} and Denon{2} all represent the same protocol when correct,
but only Denon is robust.
</irp:documentation>
<irp:parameter name="prefer-over">Denon{1}</irp:parameter>
<irp:parameter name="prefer-over">Denon{2}</irp:parameter>
<irp:parameter name="uei-executor">001C[D;F]</irp:parameter>
<irp:parameter name="uei-executor">009C(Denon Combo (Official))[;D,1,F]</irp:parameter>
<irp:parameter name="uei-executor">009C:JP1[;D,F]</irp:parameter>
<irp:parameter name="uei-executor">01C8[;0,D,F,(F:1:7)*4,D:5|(F:7)*32]</irp:parameter>
<irp:parameter name="uei-executor">01AC[;0,D,F,D:5|(F:7)*32]</irp:parameter>
</irp:protocol>
<irp:protocol name="Denon-K">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">Denon-K is the member of the <a href="#Kaseikyo">Kaseikyo</a> family with OEM_code1=84 and OEM_code2=50.
It uses the same check byte rules as <a href="#Panasonic">Panasonic</a> protocol, but uses the data bits differently.
</irp:documentation>
<irp:parameter name="uei-executor">00CD:2[D;S,F]</irp:parameter>
<irp:parameter name="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]</irp:parameter>
<irp:parameter name="uei-executor">01AC[D,S;2,,,F]</irp:parameter>
<irp:parameter name="prefer-over">Kaseikyo</irp:parameter>
</irp:protocol>
<irp:protocol name="Denon{1}">
<irp:irp>
<![CDATA[{38k,264}<1,-3|1,-7>(D:5,F:8,0:2,1,-165)* [D:0..31,F:0..255]]]>
</irp:irp>
<irp:documentation xml:space="preserve">See <a href="#Denon">Denon</a>.</irp:documentation>
<irp:parameter name="decode-only">true</irp:parameter>
<irp:parameter name="uei-executor">001C[D;F]</irp:parameter>
<irp:parameter name="uei-executor">009C(Denon Combo (Official))[;D,,F]</irp:parameter>
<irp:parameter name="uei-executor">009C:JP1[;D,F]</irp:parameter>
<irp:parameter name="uei-executor">01C8[;0,D,F,(F:1:7)*4,D:5|(F:7)*32]</irp:parameter>
<irp:parameter name="uei-executor">01AC[;0,D,F,D:5|(F:7)*32]</irp:parameter>
</irp:protocol>
<irp:protocol name="Denon{2}">
<irp:irp>
<![CDATA[{38k,264}<1,-3|1,-7>(D:5,~F:8,3:2,1,-165)* [D:0..31,F:0..255]]]>
</irp:irp>
<irp:documentation xml:space="preserve">See <a href="#Denon">Denon</a>.</irp:documentation>
<irp:parameter name="decode-only">true</irp:parameter>
<irp:parameter name="uei-executor">001C[D;F]</irp:parameter>
<irp:parameter name="uei-executor">009C(Denon Combo (Official))[;D,,F]</irp:parameter>
<irp:parameter name="uei-executor">009C:JP1[;D,F]</irp:parameter>
<irp:parameter name="uei-executor">01C8[;0,D,F,(F:1:7)*4,D:5|(F:7)*32]</irp:parameter>
<irp:parameter name="uei-executor">01AC[;0,D,F,D:5|(F:7)*32]</irp:parameter>
</irp:protocol>
<irp:protocol name="Dgtec">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:parameter name="uei-executor">016A:2</irp:parameter>
<irp:parameter name="uei-executor">016A</irp:parameter>
</irp:protocol>
<irp:protocol name="Digivision">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">See <a href="#GuangZhou">GuangZhou</a>, which has identical framing but with different bit definitions.</irp:documentation>
</irp:protocol>
<irp:protocol name="DirecTV_3FG">
<!-- FIXME -->
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">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:
<ul> <li>Parm=0 : 40k, -15</li> <li>Parm=1 : 40k, -50</li> <li>Parm=2 : 38k, -15</li> <li>Parm=3 : 38k, -50</li> <li>Parm=4 : 57k, -15</li> <li>Parm=5 : 57k, -50</li> </ul>
</irp:documentation>
<irp:parameter name="uei-executor">0162[D;F]</irp:parameter>
</irp:protocol>
<irp:protocol name="DirecTV_P0">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">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:
<ul>
<li>Parm=0 : 40k, -15</li>
<li>Parm=1 : 40k, -50</li>
<li>Parm=2 : 38k, -15</li>
<li>Parm=3 : 38k, -50</li>
<li>Parm=4 : 57k, -15</li>
<li>Parm=5 : 57k, -50</li>
</ul>
</irp:documentation>
<irp:parameter name="minimum-leadout">7000</irp:parameter>
<irp:parameter name="frequency-tolerance">1000</irp:parameter>
<irp:parameter name="prefer-over">DirecTV_3FG</irp:parameter>
<irp:parameter name="uei-executor" type="xml">
<rm:deployment executor="0162{Parm=0}[D,Parm;F]">
<rm:protocolName>DirecTV</rm:protocolName>
</rm:deployment>
</irp:parameter>
</irp:protocol>
<irp:protocol name="DirecTV_P1">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">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:
<ul>
<li>Parm=0 : 40k, -15</li>
<li>Parm=1 : 40k, -50</li>
<li>Parm=2 : 38k, -15</li>
<li>Parm=3 : 38k, -50</li>
<li>Parm=4 : 57k, -15</li>
<li>Parm=5 : 57k, -50</li>
</ul>
</irp:documentation>
<irp:parameter name="frequency-tolerance">1000</irp:parameter>
<irp:parameter name="prefer-over">DirecTV_P0</irp:parameter>
<irp:parameter name="prefer-over">DirecTV_3FG</irp:parameter>
<irp:parameter name="uei-executor" type="xml">
<rm:deployment executor="0162{Parm=1}[D,Parm;F]">
<rm:protocolName>DirecTV</rm:protocolName>
</rm:deployment>
</irp:parameter>
</irp:protocol>
<irp:protocol name="DirecTV_P2">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">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:
<ul>
<li>Parm=0 : 40k, -15</li>
<li>Parm=1 : 40k, -50</li>
<li>Parm=2 : 38k, -15</li>
<li>Parm=3 : 38k, -50</li>
<li>Parm=4 : 57k, -15</li>
<li>Parm=5 : 57k, -50</li>
</ul>
</irp:documentation>
<irp:parameter name="minimum-leadout">7000</irp:parameter>
<irp:parameter name="frequency-tolerance">1000</irp:parameter>
<irp:parameter name="prefer-over">DirecTV_3FG</irp:parameter>
<irp:parameter name="uei-executor" type="xml">
<rm:deployment executor="0162{Parm=2}[D,Parm;F]">
<rm:protocolName>DirecTV</rm:protocolName>
</rm:deployment>
</irp:parameter>
</irp:protocol>
<irp:protocol name="DirecTV_P3">
<!--irp:parameter name="uei-executor">0162[D;F]</irp:parameter-->
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">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:
<ul>
<li>Parm=0 : 40k, -15</li>
<li>Parm=1 : 40k, -50</li>
<li>Parm=2 : 38k, -15</li>
<li>Parm=3 : 38k, -50</li>
<li>Parm=4 : 57k, -15</li>
<li>Parm=5 : 57k, -50</li>
</ul>
</irp:documentation>
<irp:parameter name="frequency-tolerance">1000</irp:parameter>
<irp:parameter name="prefer-over">DirecTV_P2</irp:parameter>
<irp:parameter name="prefer-over">DirecTV_3FG</irp:parameter>
<irp:parameter name="alt_name">DirecTV</irp:parameter>
<irp:parameter name="uei-executor" type="xml">
<rm:deployment executor="0162{Parm=3}[D,Parm;F]">
<rm:protocolName>DirecTV</rm:protocolName>
</rm:deployment>
</irp:parameter>
</irp:protocol>
<irp:protocol name="DirecTV_P4">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">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:
<ul>
<li>Parm=0 : 40k, -15</li>
<li>Parm=1 : 40k, -50</li>
<li>Parm=2 : 38k, -15</li>
<li>Parm=3 : 38k, -50</li>
<li>Parm=4 : 57k, -15</li>
<li>Parm=5 : 57k, -50</li>
</ul>
</irp:documentation>
<irp:parameter name="minimum-leadout">7000</irp:parameter>
<irp:parameter name="frequency-tolerance">1000</irp:parameter>
<irp:parameter name="prefer-over">DirecTV_3FG</irp:parameter>
<irp:parameter name="uei-executor" type="xml">
<rm:deployment executor="0162{Parm=4}[D,Parm;F]">
<rm:protocolName>DirecTV</rm:protocolName>
</rm:deployment>
</irp:parameter>
</irp:protocol>
<irp:protocol name="DirecTV_P5">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">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:
<ul>
<li>Parm=0 : 40k, -15</li>
<li>Parm=1 : 40k, -50</li>
<li>Parm=2 : 38k, -15</li>
<li>Parm=3 : 38k, -50</li>
<li>Parm=4 : 57k, -15</li>
<li>Parm=5 : 57k, -50</li>
</ul>
</irp:documentation>
<irp:parameter name="frequency-tolerance">1000</irp:parameter>
<irp:parameter name="prefer-over">DirecTV_P4</irp:parameter>
<irp:parameter name="prefer-over">DirecTV_3FG</irp:parameter>
<irp:parameter name="uei-executor" type="xml">
<rm:deployment executor="0162{Parm=5}[D,Parm;F]">
<rm:protocolName>DirecTV</rm:protocolName>
</rm:deployment>
</irp:parameter>
</irp:protocol>
<irp:protocol name="Dish_Network">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">This is not a robust protocol, so <A href="#spurious">spurious decodes</A> are likely.
See <a href="http://www.hifi-remote.com/forums/viewtopic.php?t=13923">this thread</a> for a discussion.
</irp:documentation>
<irp:parameter name="uei-executor">0002[S+1,D;F]</irp:parameter>
<irp:parameter name="uei-executor">0002:2[S+1,D;F]</irp:parameter>
<irp:parameter name="uei-executor">0002:3[S+1,D;F]</irp:parameter>
<irp:parameter name="uei-executor">0002:5(Dish Network)[D?0,D?1,D?2,D?3,S+1;??,F]</irp:parameter>
<irp:parameter name="uei-executor">0002:5(Dish Network Combo)[D?0,D?1,D?2,D?3,S+1;??,F]</irp:parameter>
<irp:parameter name="uei-executor">0002:6(Dish Network Combo)[D?0,D?1,D?2,D?3,S+1;??,F]</irp:parameter>
</irp:protocol>
<irp:protocol name="Dishplayer">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">This is not a robust protocol, so <A href="#spurious">spurious decodes</A> are likely.</irp:documentation>
<irp:parameter name="uei-executor">010F[D,S;F]</irp:parameter>
</irp:protocol>
<irp:protocol name="Dyson">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">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.</irp:documentation>
<irp:parameter name="prefer-over">Dyson_relaxed</irp:parameter>
<irp:parameter name="uei-executor">01FF:JP1Dyson(;F!=0)</irp:parameter>
</irp:protocol>
<irp:protocol name="Dyson2">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">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.</irp:documentation>
<irp:parameter name="prefer-over">Dyson_relaxed</irp:parameter>
<irp:parameter name="uei-executor">01FF:JP1Dyson(;F==0)</irp:parameter>
</irp:protocol>
<irp:protocol name="Dyson_relaxed">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">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.</irp:documentation>
<irp:parameter name="decode-only">true</irp:parameter>
</irp:protocol>
<irp:protocol name="Elan">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">See the <A href="http://www.hifi-remote.com/forums/viewtopic.php?p=87473">JP1-forum thread</A>.</irp:documentation>
<irp:parameter name="uei-executor">01F8[D;F]</irp:parameter>
</irp:protocol>
<irp:protocol name="Elunevision">
<irp:irp>
<![CDATA[{0k,358,msb}<1,-3|3,-1>(10,-3,D:24,F:8,-7)*{D=0xf48080} [F:0..255]]]>
</irp:irp>
<irp:documentation xml:space="preserve">Elunevision Luna motorized projector screen remote.
<a href="https://sourceforge.net/p/lirc/mailman/message/36646738/">Posting on Lirc mailing list.</a>
</irp:documentation>
</irp:protocol>
<irp:protocol name="Emerson">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:parameter name="uei-executor">0065[D?0,D?1,D?2;??,F]</irp:parameter>
<irp:parameter name="uei-executor">0065:2[D?0,D?1,D?2,D?3;??,F]</irp:parameter>
<irp:parameter name="uei-executor">0065:old</irp:parameter>
<irp:parameter name="prefer-over">Sampo</irp:parameter>
<irp:parameter name="prefer-over">ScAtl-6</irp:parameter>
</irp:protocol>
<irp:protocol name="entone">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">A special case of the <a href="#RC6-M-56">RC6-M-56</a> protocol, used in the Entone Amulet.
See <a href="http://www.hifi-remote.com/forums/viewtopic.php?t=12561">this forum thread</a>.</irp:documentation>
<irp:parameter name="prefer-over">RC6-M-56</irp:parameter>
</irp:protocol>
<irp:protocol name="Epson">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve"><a href="http://www.hifi-remote.com/forums/viewtopic.php?t=17051">Forum thread</a>
</irp:documentation>
</irp:protocol>
<irp:protocol name="Eufy">
<irp:irp><![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">This is the protocol used by the Eufy 11s robot vacuum cleaner. See <a href="http://www.hifi-remote.com/forums/viewtopic.php?p=142817">this thread</a>.</irp:documentation>
<irp:parameter name="uei-executor" type="xml">
<rm:deployment executor="01FF:JP1Eufy[D,D2,S,CO;F,F2]">
<rm:assignment target="Dev2">D2</rm:assignment>
<rm:assignment target="OBC2">F2</rm:assignment>
<rm:assignment target="ChkSumOffset">CO</rm:assignment>
<rm:assignment target="D2">-1</rm:assignment>
<rm:assignment target="F2">-1</rm:assignment>
<rm:assignment target="CO">-1</rm:assignment>
</rm:deployment>
</irp:parameter>
</irp:protocol>
<irp:protocol name="F12">
<irp:irp>
<![CDATA[{37.9k,422}<1,-3|3,-1>((D:3,S:1,F:8,-80)2)* [D:0..7,S:0..1,F:0..255]]]>
</irp:irp>
<irp:documentation xml:space="preserve">Old version of the F12 specification.
</irp:documentation>
<irp:parameter name="prefer-over">F12_relaxed</irp:parameter>
<irp:parameter name="prefer-over">F12x</irp:parameter>
<irp:parameter name="uei-executor">001A[D;F]</irp:parameter>
</irp:protocol>
<irp:protocol name="F12-0">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">Taken from <a href="http://www.hifi-remote.com/wiki/index.php?title=DecodeIR#F12">DecodeIR</a>, case H=0.
</irp:documentation>
</irp:protocol>
<irp:protocol name="F12-1">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">Taken from <a href="http://www.hifi-remote.com/wiki/index.php?title=DecodeIR#F12">DecodeIR</a>, case H=1.
</irp:documentation>
</irp:protocol>
<irp:protocol name="F12_relaxed">
<irp:irp>
<![CDATA[{37.9k,422}<1,-3|3,-1>(D:3,S:1,F:8,-80)* [D:0..7,S:0..1,F:0..255]]]>
</irp:irp>
<irp:documentation xml:space="preserve">Relaxed version of the F12 specification.
</irp:documentation>
<irp:parameter name="minimum-leadout">6000</irp:parameter>
<irp:parameter name="uei-executor" type="xml">
<rm:deployment executor="001A[D;F]">
<rm:protocolName>F12</rm:protocolName>
<rm:commentItem>Non-standard repeats</rm:commentItem>
</rm:deployment>
</irp:parameter>
</irp:protocol>
<irp:protocol name="F12x">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">This is an extended and slightly modified version of the <a href="#F12">F12 protocol.</a>
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.
</irp:documentation>
<irp:parameter name="prefer-over">F12_relaxed</irp:parameter>
<irp:parameter name="uei-executor">016D[D,S,E;F]</irp:parameter>
</irp:protocol>
<irp:protocol name="F32">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">The meaning of the 32 bits of data is unknown, and the assignment to D, S, F, and E is arbitrary.</irp:documentation>
</irp:protocol>
<irp:protocol name="Fujitsu">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">Fujitsu is the member of the <a href="#Kaseikyo">Kaseikyo</a> 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.</irp:documentation>
<irp:parameter name="prefer-over">Kaseikyo</irp:parameter>
<irp:parameter name="uei-executor">00F8[D;F,S]</irp:parameter>
<irp:parameter name="uei-executor">00F8:2[D;F,S]</irp:parameter>
<irp:parameter name="uei-executor">00F8:3[D;F,S]</irp:parameter>
</irp:protocol>
<irp:protocol name="Fujitsu-128">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
</irp:protocol>
<irp:protocol name="Fujitsu-56">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
</irp:protocol>
<irp:protocol name="Fujitsu_Aircon">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">Protocol for Fujitsu inverter air conditioning.
<a href="http://www.remotecentral.com/cgi-bin/mboard/rc-discrete/thread.cgi?4894">RemoteCentral thread</a>.
This version is a re-parametrization of 3FG's version, allowing for decoding.
</irp:documentation>
<irp:parameter name="prefer-over">Fujitsu-128</irp:parameter>
</irp:protocol>
<irp:protocol name="Fujitsu_Aircon_old">
<!-- To be removed -->
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">Protocol for Fujitsu inverter air conditioning. <a href="http://www.remotecentral.com/cgi-bin/mboard/rc-discrete/thread.cgi?4894">RemoteCentral thread</a>.</irp:documentation>
<irp:parameter name="decodable">false</irp:parameter>
</irp:protocol>
<irp:protocol name="G.I.4DTV">
<!--irp:irp><![CDATA[{37.3k,992}<1,-1|1,-3>(5,-2,F:6,D:2,C:4,1,-60)*{C= ((#(F&25) + #(D&5))&1) + 2*((#(F&43) + #(D&7))&1) + 4*((#(F&22) + #(D&7))&1) + 8*((#(F&44) + #(D&6))&1)}[D:0..3, F:0..63]]]></irp:irp-->
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>
<irp:documentation xml:space="preserve">This is a moderately robust protocol, but <A href="#spurious">spurious decodes</A> 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 <a href="http://www.hifi-remote.com/forums/viewtopic.php?p=103934#103934">forum thread</a>.
</irp:documentation>
<irp:parameter name="prefer-over">G.I.4DTV_relaxed</irp:parameter>
<irp:parameter name="uei-executor">00A4[D;F]</irp:parameter>
</irp:protocol>
<irp:protocol name="G.I.4DTV_relaxed">
<irp:irp>
<![CDATA[{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]]]>
</irp:irp>