forked from probonopd/decodeir
-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathDecodeIR.html
1423 lines (1270 loc) · 81.1 KB
/
DecodeIR.html
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
<HTML>
<HEAD>
<TITLE>Interpreting Decoded IR Signals (v2.45)</TITLE>
</HEAD>
<BODY text="#000000" vlink="#666666" alink="#996600" link="#3366cc" bgcolor="#ffffff">
<H2>Version 2.45</H2>
<blockquote>
<A href="#Introduction">Introduction</A><BR><BR>
<table>
<tr><td valign="top" width="140">
<A href="#48-NEC">48-NEC</A><BR>
<A href="#48-NEC1">48-NEC1</A><BR>
<A href="#48-NEC2">48-NEC2</A><BR>
<A href="#AdNotam">AdNotam</A><BR>
<A href="#AirAsync">AirAsync</A><BR>
<A href="#AirB?-????">AirB?-????</A><BR>
<A href="#Aiwa">Aiwa</A><BR>
<A href="#AK">AK</A><BR>
<A href="#Akai">Akai</A><BR>
<A href="#Amino">Amino</A><BR>
<A href="#Anthem">Anthem</A><BR>
<A href="#Apple">Apple</A><BR>
<A href="#Archer">Archer</A><BR>
<A href="#Async">Async</A><BR>
<A href="#Barco">Barco</A><BR>
<A href="#Blaupunkt">Blaupunkt</A><BR>
<A href="#Bryston">Bryston</A><BR>
<A href="#Bose">Bose</A><BR>
<A href="#CanalSat">CanalSat</A><BR>
<A href="#CanalSatLD">CanalSatLD</A><BR>
<A href="#Denon">Denon</A><BR>
<A href="#Denon">Denon{1}</A><BR>
<A href="#Denon">Denon{2}</A><BR>
<A href="#Denon-K">Denon-K</A><BR>
<A href="#Dgtec">Dgtec</A><BR>
<A href="#DirecTV">DirecTV</A><BR>
<A href="#Dishplayer">Dishplayer</A><BR>
<A href="#Dish_Network">Dish_Network</A><BR>
</td>
<td valign="top" width="144">
<A href="#Elan">Elan</A><BR>
<A href="#Emerson">Emerson</A><BR>
<A href="#F12">F12</A><BR>
<A href="#F32">F32</A><BR>
<A href="#Fujitsu">Fujitsu</A><BR>
<A href="#Fujitsu-56">Fujitsu-56</A><BR>
<A href="#G.I. Cable">G.I. Cable</A><BR>
<A href="#G.I. Cable">G.I. Cable{1}</A><BR>
<A href="#G.I. 4DTV">G.I. 4DTV</A><BR>
<A href="#G.I. RG">G.I. RG</A><BR>
<A href="#Grundig16">Grundig16</A><BR>
<A href="#Grundig16">Grundig16-30</A><BR>
<A href="#GXB">GXB</A><BR>
<A href="#GXB">Humax 4Phase</A><BR>
<A href="#IODATAn">IODATA<i>n</i></A><BR>
<A href="#IODATAn">IODATA<i>n</i>-<i>x</i>-<i>y</i></A><BR>
<A href="#Jerrold">Jerrold</A><BR>
<A href="#JVC">JVC</A><BR>
<A href="#JVC">JVC{2}</A><BR>
<A href="#JVC-48">JVC-48</A><BR>
<A href="#JVC-56">JVC-56</A><BR>
<A href="#Kaseikyo">Kaseikyo</A><BR>
<A href="#Kaseikyo56">Kaseikyo56</A><BR>
<A href="#Kathrein">Kathrein</A><BR>
<A href="#Konka">Konka</A><BR>
<A href="#Logitech">Logitech</A><BR>
</td>
<td valign="top" width="142">
<A href="#Lumagen">Lumagen</A><BR>
<A href="#Lutron">Lutron</A><BR>
<A href="#Matsui">Matsui</A><BR>
<A href="#MCE">MCE</A><BR>
<A href="#Metz19">Metz19</A><BR>
<A href="#Mitsubishi">Mitsubishi</A><BR>
<A href="#Mitsubishi-K">Mitsubishi-K</A><BR>
<A href="#NEC">NEC</A><BR>
<A href="#NEC1">NEC1</A><BR>
<A href="#NEC2">NEC2</A><BR>
<A href="#NECx">NECx</A><BR>
<A href="#NECx1">NECx1</A><BR>
<A href="#NECx2">NECx2</A><BR>
<A href="#Nokia">Nokia</A><BR>
<A href="#Nokia12">Nokia12</A><BR>
<A href="#Nokia32">Nokia32</A><BR>
<A href="#NRC16">NRC16</A><BR>
<A href="#NRC17">NRC17</A><BR>
<A href="#OrtekMCE">OrtekMCE</A><BR>
<A href="#Pace MSS">Pace MSS</A><BR>
<A href="#Panasonic">Panasonic</A><BR>
<A href="#Panasonic2">Panasonic2</A><BR>
<A href="#Panasonic_Old">Panasonic_Old</A><BR>
<A href="#PCTV">PCTV</A><BR>
<A href="#pid-0001">pid-0001</A><BR>
<A href="#pid-0003">pid-0003</A><BR>
<A href="#pid-0004">pid-0004</A><BR>
<A href="#pid-0083">pid-0083</A><BR>
</td>
<td valign="top" width="131">
<A href="#Pioneer">Pioneer</A><BR>
<A href="#Proton">Proton</A><BR>
<A href="#RC5">RC5</A><BR>
<A href="#RC5-7F">RC5-7F</A><BR>
<A href="#RC5-7F-57">RC5-7F-57</A><BR>
<A href="#RC5x">RC5x</A><BR>
<A href="#RC5-?-??">RC5-?-??</A><BR>
<A href="#RC6">RC6</A><BR>
<A href="#RC6-6-20">RC6-6-20</A><BR>
<A href="#RC6-?-??">RC6-?-??</A><BR>
<A href="#RCA">RCA</A><BR>
<A href="#RCA">RCA(Old)</A><BR>
<A href="#RCA-38">RCA-38</A><BR>
<A href="#RCA-38">RCA-38(Old)</A><BR>
<A href="#RECS80">RECS80</A><BR>
<A href="#Replay">Replay</A><BR>
<A href="#Revox">Revox</A><BR>
<A href="#Samsung20">Samsung20</A><BR>
<A href="#Samsung36">Samsung36</A><BR>
<A href="#Sampo">Sampo</A><BR>
<A href="#ScAtl-6">ScAtl-6</A><BR>
<A href="#Sejin-M-38">Sejin-<i>M</i>-38</A><BR>
<A href="#Sejin-M-38">Sejin-<i>M</i>-56</A><BR>
<A href="#Sharp">Sharp</A><BR>
<A href="#Sharp">Sharp{1}</A><BR>
<A href="#Sharp">Sharp{2}</A><BR>
<A href="#SharpDVD">SharpDVD</A><BR>
<A href="#SIM2">SIM2</A><BR>
</td>
<td valign="top" width="130">
<A href="#Solidtek16">Solidtek16</A><BR>
<A href="#Solidtek20">Solidtek20</A><BR>
<A href="#Somfy">Somfy</A><BR>
<A href="#Sony8">Sony8</A><BR>
<A href="#Sony12">Sony12</A><BR>
<A href="#Sony15">Sony15</A><BR>
<A href="#Sony20">Sony20</A><BR>
<A href="#StreamZap">StreamZap</A><BR>
<A href="#Sunfire">Sunfire</A><BR>
<A href="#TDC-38">TDC-38</A><BR>
<A href="#TDC-38">TDC-56</A><BR>
<A href="#Teac-K">Teac-K</A><BR>
<A href="#Thomson">Thomson</A><BR>
<A href="#Thomson7">Thomson7</A><BR>
<A href="#Tivo">Tivo</A><BR>
<A href="#Velleman">Velleman</A><BR>
<A href="#Velodyne">Velodyne</A><BR>
<A href="#Viewstar">Viewstar</A><BR>
<A href="#X10">X10</A><BR>
<A href="#X10">X10.<i>n</i></A><BR>
<A href="#XMP">XMP</A><BR>
<A href="#XMP">XMP-1</A><BR>
<A href="#XMP">XMP-2</A><BR>
<A href="#XX">XX</A><BR>
<A href="#Zaptor">Zaptor</A><BR>
<A href="#Zenith">Zenith</A><BR>
<A href="#?1-??-??-??">?1-??-??-??</A><BR>
</td></tr></table>
<H2><A name="Introduction">Introduction</A></H2>
The primary purpose of this document is to explain any peculiarities of the decoding of each protocol.
Click in the list above on each protocol name to get any information specific to decodes with that name.
<p>If you don't understand the advanced information (IRP notation, etc.) at the start of each of those
entries, don't worry about that and please don't let it stop you from reading the text below that. In many
cases there is important protocol-specific information you will need in order to use the data from
the decode.</p>
<H3>Decode problems</H3>
The decoder only looks at one IR signal at a time. Sometimes it gives contradictory
results for a signal. The best way to determine which result is correct is to
compare with the decodes of other signals for the same device.
<H3><A name="spurious">Spurious decodes and non-robust protocols</A></H3>
Most IR protocols have enough internal consistency checks that the decoder can reliably
tell whether that protocol is present in a learned signal and can reliably decode the
device, subdevice and OBC numbers. If the signal is learned badly enough, the decoder
may fail to find that protocol in the signal. But it is very unlikely to decode it
with the wrong numbers or to imagine that protocol is a bad learn of something else.
<p>Some protocols are not robust. A totally unrelated IR signal can accidentally
fit the pattern of such a protocol resulting in a spurious decode. When you
get a decode for a non-robust protocol you need to exercise some judgment
about whether to believe or ignore that decode. Usually you can decide based
on decodes of other signals of the same device.</p>
<H3><A name="jp1">EFC, JP1, KeyMoves, Upgrades, etc.</A></H3>
Much of this document assumes DecodeIr is being used with JP1 or at least with a JP1
capable remote. But some people will be using DecodeIr with other types of remote.
<p>If your remote is not OneForAll brand and is not one of the models of Radio Shack (or a few
other brands) that uses the same design as OneForAll, then everything this document says
about JP1, KeyMoves, Upgrades, KM, RM (RemoteMaster), and EFC numbers has no meaning for
your use. Just ignore those references and the rest of this doc should apply to your use.
Also ignore the EFC numbers in the actual output from DecodeIr.</p>
<p>If you are using a OneForAll type remote but have neither a JP1 cable nor a remote model
that can be upgraded by .wav file, then nothing about Upgrades, KM, RM, and OBC numbers
applies to your use. If the decodes you get include EFC numbers and you know (or can
ask in a forum) which setup code is right (corresponds to the protocol, device and
subdevice of the decode) then you can use those EFC numbers in KeyMoves. Note that
the decoding process cannot directly tell you which setup code is needed to
generate the signal. If you post a question in an appropriate forum with the protocol name,
device number, subdevice number, and which model OneForAll type remote you have, someone
will probably identify the setup code for you.</p>
<H3><A name="toggle">Toggle bits</A></H3>
Several different protocols include something called a toggle bit. This means that each command
has two or more different forms. Some protocols (e.g. RC5) alternate the toggle on each key press, while
others change the toggle to indicate a start or end frame.
<p>An alternating toggle lets the device receiving the commands distinguish between a long press
of a button and two short presses. For example, if you press and hold the '1' button
the remote continuously sends repeats of a single form of the '1' command. But if you
press '1', release it and press it again the remote will switch to the other form of the
command for the second press.</p>
<p>When you learn such a command you are capturing just one form of the command and
every use will send that same form. If you use that learned signal and press the same button twice
in a row, the device receiving the signal will see that as one long press rather than two
short ones. For keys, such as digits, where one long press has a different meaning than
two short presses, that gets quite inconvenient.</p>
<p>With OneForAll type remotes, using an upgrade or KeyMove will solve that problem.</p>
<p>For some of these protocols, for some models of Pronto remote, there is a condensed
encoding of the Pronto Hex that will solve the problem.</p>
<H3><A name="repeat">Repeat frames and dittos</A></H3>
<p>DecodeIR v2.37 and later versions have a look-ahead facility that is not present in earlier ones.
This distinguishes between two styles of data passed to them by the calling application. The
remote control programming applications IR.exe and RMIR pass signals learned by a UEI remote
that has itself performed a partial analysis of the signal. The data is passed in a structured
form, divided into Once, Repeat and Extra sections. The data in each of these sections can be
viewed in IR.exe if the "Force Learned Timings" option on the Advanced menu is selected. Because
of this analysis, DecodeIR does not see the original signal in full and cannot determine such
things as the number of repeats of the signal that were sent. Other applications such as the
IRScope software for the IR Widget send the entire signal as unstructured data, which enables
IR.exe to identify the number of repeats.</p>
<p>The look-ahead facility checks successive frames within a single signal to see if they are
repeats – either identical repeats or, in certain protocols, frames of a repeat sequence
that have a distinctive marker in either the start or end frame, or both, of the sequence. If a
protocol has distinctive start or end frame markers and either or both of the start and end frames
are missing, this is reported in the Misc field of the decode (but at present this may not be
implemented for all protocols with such markers). If the data has been passed in an unstructured
form then the number of repeats in the signal will also be reported in the Misc field in a form
like "4 frames", or in version 2.39 and later, "+ 3 copies".</p>
<p>In the case of unstructured data, DecodeIR v2.38 extends the look-ahead to protocols in which repeat
action is signalled not by a full repeat of the frame but by a much shorter frame that does not carry
the signal data (or occasionally carries just part of this data). These frames serve
as "ditto marks". If present then the number of such frames is reported in the Misc field
in a form like "3 dittos", or in version 2.39 and later, "+ 3 dittos". If there
are no repeat frames or ditto marks, then to avoid ambiguity this is reported as "no repeat".</p>
<H3><A name="MiniComboExecutors">Mini Combos</A></H3>
Some UEI protocol executors are "mini-combos". This means they support more than one
device number within one setup code using single-byte hex commands. There will be more
than one possible EFC number for each OBC number. DecodeIr can't determine the correct
EFC number by looking at the IR signal, because it isn't a characteristic of the signal.
It is a characteristic of the fixed data used in creation of the setup code.
<p>DecodeIr will list two or three different EFC numbers for each OBC number.
The sequence of those two or three EFC numbers is consistent across all the decodes.
So once you find out which position in that list is correct for one OBC of a given device
number and setup code, that position will be correct for the EFC list of any other OBC of
the same device and setup code (except that for RC-5 the decision of whether or not the OBC
number is above 63 is treated as being part of the device number).</p>
<H3><A name="ReadingIRP">Brief and incomplete guide to reading IRP</A></H3>
<b>General</b>: {carrier frequency, time unit, sequencing rule}
Mitsubishi:<b>{32.6k,300}</b><1,-3|1,-7>(D:8,F:8,1,-80)+ <br>
<i>Carrier Frequency</i>: Hz; e.g. 38.3k; default is 0k--no modulation<br>
<i>Time Unit</i>: Integer that can represent durations. Suffix u (default) is microseconds, p denotes number of pulses of the carrier.<br>
<i>Sequencing Rule</i>: lsb|msb; lsb (default) means the least significant bit of a binary form is sent first. <br>
<b>BitSpec</b>: Rule for the translating bit sequences to duration sequences. <ZeroPulseSeq|OnePulseSeq|TwoPulseSeq....>. Most IR protocols use only <ZeroPulseSeq|OnePulseSeq>, and the sequence is simply OnDuration,OffDuration. Example: NEC uses <1,-1|1,-3><br>
<b>Bitfield</b>: D:NumberOfBits:StartingBit. E.g. if D=47= 01000111, D:2:5 means x<b>10</b>xxxxx. D:2:5 = 10b = 2. ~ is the bitwise complement operator. ~D =10111000. Specifying the StartingBit is optional. D:6 is equivalent to D:6:0.<br>
<b>IRStream</b>: The sequence of data. Enclosed in parentheses, items separated by commas.
A trailing + means send one or more times. A trailing 3 means send 3 times; 3+ means at least 3 times.
A trailing * means send zero or more times. NEC2: {38.4k,564}<1,-1|1,-3><b>(16,-8,D:8,S:8,F:8,~F:8,1,-78)+</b> <br>
<b>Durations</b>: no suffix means duration is expressed in Time Units, as defined above.
m is milliseconds, u microsec, p pulses. No prefix means a flash, a preceeding - (minus) means a gap.<br>
<b>Extent</b>: A gap which trails a signal. The trailing gap is adjusted to make the total length of signal
plus trailing gap equal to the extent. Notation is like a gap duration, except ^ replaces the minus sign.
RC-5:(1:1,~F:1:6,T:1,D:5,F:6,<b>^114m</b>)+ <br>
<b>Expressions</b>: names, numbers and bitfields connected by standard symbols for arithmetic and logical
operations. Enclosed in parentheses. Panasonic: {37k,432}<1,-1|1,-3>(8,-4,2:8,32:8,D:8,S:8,F:8,<b>(D^S^F)</b>:8,1,-173)+
<br>
<b>Permitted operators in decreasing order of precedence:</b><br>
<code>
unary (negation)<br>
** (exponentiation)<br>
* /, % (multiplication, integer division, modulo) (* is also used in IRStreams)<br>
+, (addition, subtraction (+ is also used in IRStreams)<br>
# number of 1 bits in argument<br>
& (bitwise AND)<br>
^ (exclusive OR) (also used in extents)<br>
| (OR)<br>
~ (complement) is permitted in Bitfields</code><br>
<b>Definitions</b>: expressions separated by commas, enclosed in curly brackets.
GI Cable: {38.7k,490}<1,-4.5|1,-9>(18,-9,F:8,D:4,C:4,1,-84,(18,-4.5,1,-178)*)
<b>{C = -(D + F:4 + F:4:4)}</b> <br>
<b>Assignments</b>: For example T=T+1, which can be used to describe the RC-5 toggle bit.<br>
<b>Variations</b>: Up to 3 expressions enclosed in square brackets. The first variation is
sent on the first transmission, second for middle transmissons, and the third for the final transmission.
E.g. the Zaptor toggle bit is zero until the last frame: [T=0] [T=0] [T=1]<br>
<a href="http://www.hifi-remote.com/wiki/index.php?title=IRP_Notation"> The IRP specification by Graham Dixon</a><br>
<a href="http://www.hifi-remote.com/forums/dload.php?action=file&file_id=6996"> Practical explanation of IR signals and IRP by Vicky Getz</a>
<H2><A name="48-NEC">48-NEC</A></H2>
If you get a decode whose protocol name is
simply "48-NEC" that indicates the learned signal is not complete (usually caused by
not holding the original remote's button long enough during learning). Enough of
the signal is present to accurately determining the device, subdevice and OBC numbers.
But not enough is present to determine whether the protocol is 48-NEC1 or 48-NEC2.
<H2><A name="48-NEC1">48-NEC1</A></H2>
IRP notation: {38.0k,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)*)
<br>
EFC translation: LSB comp
<p>This protocol signals repeats by the use of <A href="#repeat">dittos</A>.</p>
<H2><A name="48-NEC2">48-NEC2</A></H2>
IRP notation: {38.0k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,E:8,~E:8,1,^108m)+
<br>
EFC translation: LSB comp
<H2><A name="AdNotam">AdNotam</A></H2>
IRP notation: {35.7Khz,895,msb}<1,-1|-1,1>(1,-2,1,D:6,F:6,^114m)+
<br>
<p>Very similar to RC5, except AdNotam uses two start bits, and no toggle bit.
<H2><A name="AirAsync">AirAsync</A></H2>
IRP notation: {37.7Khz,840}<1|-1>(N=0,(1,B:8:N,-2,N=N+8)+)
<p>This protocol uses asynchronous data transmission that sends an 8-bit byte with 1 start bit,
8 data bits and 2 stop bits. The minimum signal is one byte. The protocol is reported as
AirAsync<i>n</i>-xx.yy. ...
where <i>n</i> is the number of bytes and xx, yy, ... are the byte values in hexadecimal notation.
</p>
<H2><A name="AirB?-????">AirB?-????</A></H2>
<p>This is not a robust protocol, so <A href="#spurious">spurious decodes</A> are likely.
If you see this decode from something other than an IR keyboard, you should probably ignore it.</p>
<H2><A name="Aiwa">Aiwa</A></H2>
UEI protocol: 005E or 009E
<br>
IRP notation: {38k,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)*)
<br>
EFC translation: LSB
<p>This protocol signals repeats by the use of <A href="#repeat">dittos</A>.</p>
<p>The EFC numbering varies among the KM and RM versions of Aiwa. Using OBC numbers is less confusing.</p>
<p>When using a non-combo version of Aiwa in KM, you must combine the device and subdevice numbers as
device+256*subdevice to get the number KM calls "Device Code". (Since subdevice is usually zero, that
combination is trivial). In Aiwa combo in KM you use the subdevice as "parameter" (on the setup sheet)
and put the device in the byte2 column on the functions sheet. RM follows DecodeIr's naming of Device
and Subdevice.</p>
<H2><A name="AK">AK</A></H2>
Documentation not written yet.
<H2><A name="Akai">Akai</A></H2>
UEI protocol: 000D
<br>
IRP notation: {38k,289}<1,-2.6|1,-6.3>(D:3,F:7,1,^25.3m)+ <br>
EFC translation: LSB comp prefixed with last device bit
<p>This is not a robust protocol, so <A href="#spurious">spurious decodes</A> are likely.</p>
<p>As of version 8.31, KM does not translate device to fixed data, nor OBC to EFC according to
the same rules used by DecodeIr. RM does translate consistently with DecodeIr, so you may find
it easier to use RM. If you use KM, you must change the device number as follows:</p>
<ul>
<li>Decoded device 0 or 4 --> KM device 3</li>
<li>Decoded device 1 or 5 --> KM device 2</li>
<li>Decoded device 2 or 6 --> KM device 1</li>
<li>Decoded device 3 or 7 --> KM device 0</li>
</ul>
<p>Also (in KM) you should use the EFC number from the decode not the OBC number. Akai protocol
uses the same EFC numbering across all JP1 remotes, so use of EFC is safe. KM uses different
OBC numbering than RM and DecodeIr, so use of OBCs isn't safe.</p>
<H2><A name="Amino">Amino</A></H2>
UEI protocol: 019C
<br>
IRP notation: {56.0k,268,msb}<-1,1|1,-1>[T=1] [T=0] (7,-6,3,D:4,1:1,T:1,1:2,0:8,F:8,15:4,C:4,-79m)+<br>
-----Variant: {36.0k,268,msb}<-1,1|1,-1>[T=1] [T=0] (7,-6,3,D:4,1:1,T:1,1:2,0:8,F:8,15:4,C:4,-79m)+
<br>{C =(D:4+4*T+9+F:4+F:4:4+15)&15} [the arithmetic sum of the first 7 nibbles mod 15]
<br>T=1 for the first frame and T=0 for all repeat frames.
<br>DecodeIR v2.43 checks T and will report in the Misc field if the start or end frame is missing.
Amino equipment use both 36 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.
IRDecode v2.43 distinguishes between Amino and Zaptor in order of priority by 1)the position of the toggle bit,
2)the value of the next to last nibble, and 3)the measured duration of a half-bit.
<br>
EFC translation: MSB
<H2><A name="Anthem">Anthem</A></H2>
UEI protocol: 0123 <br>
IRP notation: {38.0k,605}<1,-1|1,-3>((8000u,-4000u,D:8,S:8,F:8,C:8,1,-25m)3, -75m)+ {C=~(D+S+F+255):8}
<br>Anthem framing is very similar to NEC, and also uses 32 bits of data. However, the leadout is much shorter.
The signal is sent at least 3 times. Anthem usually splits F into a 2 bit unit number, and a 6 bit function number.
<H2><A name="Apple">Apple</A></H2>
UEI protocol: 01E0
<br>
IRP notation: {38.0k,564}<1,-1|1,-3>(16,-8,D:8,S:8,C:1,F:7,I:8,1,^108m,(16,-4,1,^108m)*) {C=~(#F+#PairID)&1)}<br>
C=1 if the number of 1 bits in the fields F and I is even. I is the remote ID.
<p> Apple uses the same framing as NEC1, with D=238 in normal use, 224 while pairing. S=135 </p>
<H2><A name="Archer">Archer</A></H2>
IRP notation: {0k,12}<1,-3.3m|1,-4.7m>(F:5,1,-9.7m)+ <br>
EFC translation: 5-bit LSB
<p>This is not a robust protocol, so <A href="#spurious">spurious decodes</A> are likely.</p>
<H2><A name="Async">Async</A></H2>
<p>This protocol uses asynchronous data transmission that sends an 8-bit byte with 1 start bit,
8 data bits and 1 stop bit. The minimum signal is four bytes. The protocol is reported as
Async<i>n</i>:min-max:aa.bb...yy.zz
where <i>n</i> is the number of bytes, min-max is the range of durations in microseconds that was taken as a single bit and aa.bb...yy.zz are the first two and last two byte values in hexadecimal notation. DecodeIR v 2.44 does not report Async decodes.
</p>
<H2><A name="Barco">Barco</A></H2>
UEI protocol: 002A
<br>IRP notation: {0k,10}<1,-5|1,-15>(1,-25, D:5,F:6, 1,-25,1,120m)+
<br>EFC translation: 6-bit LSB comp
<p>This is a moderately robust protocol, but <A href="#spurious">spurious decodes</A> are still possible.</p>
<H2><A name="Blaupunkt">Blaupunkt</A></H2>
IRP notation: {30.3k,528}<-1,1|1,-1>(1,-5,1023:10,-39,1,-5,1:1,F:6,D:3,-230)
<H2><A name="Bose">Bose</A></H2>
UEI protocol: 010C<br>
IRP notation: {38.0k,500,msb}<1,-1|1,-3>(2,-3,F:8,~F:8,1,-50m)+ <br>
EFC translation: MSB
<H2><A name="Bryston">Bryston</A></H2>
IRP notation: {38.0k,315} <1,-6|6,-1>(D:10,F:8, -18m)+ <br>
<H2><A name="CanalSat">CanalSat</A></H2>
UEI protocol: 018C
IRP notation: {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)+)
<br>
EFC translation: 7-bit MSB.
<p>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. DecodeIR v2.37 and later check T and will report in the Misc
field if the start frame is missing. The official name for CanalSat is "ruwido r-step".</p>
<H2><A name="CanalSatLD">CanalSatLD</A></H2>
UEI protocol: unknown <br>
IRP notation: {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)+)
<p>The official name for CanalSatLD is "ruwido r-step"</p>
<H2><A name="Denon">Denon, Denon{1} and Denon{2}</A></H2>
IRP notation: {38k,264}<1,-3|1,-7>(D:5,F:8,0:2,1,-165,D:5,~F:8,3:2,1,-165)+
<br>
EFC translation: LSB
<p>A Denon signal is identical to Sharp, and has two halves, either one of which is enough
to fully decode
the information. A significant fraction of Denon learned signals contain just
one half or have the halves separated so that DecodeIr can't process them
together. When one half is seen separate from the other, DecodeIr will name
the protocol Denon{1} or Denon{2} depending on which half is decoded. Denon,
Denon{1} and Denon{2} all represent the same protocol when they are correct.
But only Denon is robust. A Denon{1} or Denon{2} decode might be <A href="#spurious">spurious</A>.</p>
<H2><A name="Denon-K">Denon-K</A></H2>
UEI protocol: 00CD, 01C8
<br>
IRP notation: {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)+
<br>
EFC translation: LSB comp
<p>Denon-K is the member of the Kaseikyo family with OEM_code1=84 and OEM_code2=50.</p>
<p>Denon-K uses the same check byte rules as Panasonic protocol, but uses the data bits differently.
The Panasonic Combo protocol in KM can be used with some difficulty to produce Denon-K signals.
The Denon-K choice in RM uses the same protocol executor as Panasonic combo, but computes the hex commands
based on Denon's use of the Kaseikyo data bits.</p>
<H2><A name="Dgtec">Dgtec</A></H2>
UEI protocol: 016A
<br>
IRP notation: {38k,560}<1,-1|1,-3>(16,-8,D:8,F:8,~F:8,1,^108m,(16,-4,1,^108m)+)
<br>
EFC translation: LSB comp
<p>This protocol signals repeats by the use of <A href="#repeat">dittos</A>.</p>
<H2><A name="DirecTV">DirecTV</A></H2>
IRP notation: {38k,600,msb}<1,-1|1,-2|2,-1|2,-2>(5,(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)} <br>
EFC translation: MSB
<p>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:</p>
<ul>
<li>Parm=0 : 40k, -15
<li>Parm=1 : 40k, -50
<li>Parm=2 : 38k, -15
<li>Parm=3 : 38k, -50
<li>Parm=4 : 57k, -15
<li>Parm=5 : 57k, -50
</ul>
<p>Portions of a dirty learn of a Sony signal may look like a DirecTV signal. So, if you get a DirecTV
decode together with a plausible Sony decode, believe the Sony decode and ignore the DirecTV. If you get
a DirecTV decode without a Sony decode for some functions of a Sony device, try relearning them; a DirecTV
decode for a signal meant for a Sony device is not likely to be correct.</p>
<p>This protocol was called Russound in versions of DecodeIR earlier than 2.40.</p>
<H2><A name="Dishplayer">Dishplayer</A></H2>
UEI protocol: 010F
<br>
IRP notation: {38.4k,535,msb}<1,-5|1,-3>(1,-11,(F:6,S:5,D:2,1,-11)+) <br>
EFC translation: Not available in this version of DecodeIr
<p>This is not a robust protocol, so <A href="#spurious">spurious decodes</A> are likely.</p>
<H2><A name="Dish_Network">Dish_Network</A></H2>
UEI protocol: 0002 <br>IRP notation: {57.6k,400}<1,-7|1,-4>(1,-15,(F:-6,S:5,D:5,1,-15)+)
<br>
EFC translation: MSB comp 6 function bits followed by LSB comp low 2 unit bits.
<p>This is not a robust protocol, so <A href="#spurious">spurious decodes</A> are likely.</p>
<p>The unit number shows up in the Subdevice field of DecodeIr's output. In KM, the "unit code" is
one greater than the unit number. So you must take the Subdevice from the decode and add one to
it and use that as the "unit code" in KM.</p>
<p>There are two variants of the protocol executor for DishNetwork with different
but compatible EFC numbering. The decoded EFC should work for both. But the
results may be less confusing if you use OBC numbers in KM or RM.</p>
<H2><A name="EchoStar">EchoStar</A></H2>
UEI protocol: 0182
<br> As of 2.42 DecodeIR shows this as RC5-7F
<H2><A name="Elan">Elan</A></H2>
UEI protocol: Unknown<br>
IRP notation: {40.2k,398,msb}<1,-1|1,-2>(3,-2,D:8,~D:8,2,-2,F:8,~F:8,1,^50m)+ <br>
<p>See the <A href="http://www.hifi-remote.com/forums/viewtopic.php?p=87473">JP1-forum</A> for the executor.</p>
<H2><A name="Emerson">Emerson</A></H2>
UEI protocol: 0065
<br>
IRP notation: {36.7k,872}<1,-1|1,-3>(4,-4,D:6,F:6,~D:6,~F:6,1,-39)+ <br>
EFC translation: 6-bit LSB comp with 2-bit mini-combo
<p>Lists three different EFCs because this protocol is a <A href="#mini combo">mini combo</A>.</p>
<H2><A name="F12">F12</A></H2>
UEI protocol: 001A
<br>
IRP notation: (Toshiba specification)
{37.9k,422}<1,-3|3,-1>(D:3,H:1,A:1,B:1,F:6),-80)2 for A=1 or B=1 <br>
{37.9k,422}<1,-3|3,-1>((D:3,H:1,A:1,B:1,F:6),-80)2,-128)+ for H=1.<br>
Exactly one of H, A, or B can have a value of 1. If H=1 the signal can be sent repeatedly, and F can take any 6 bit value.
If A or B=1, the signal is sent once only per button press, and only a single bit of F can be non-zero. <A href="http://www.hifi-remote.com/forums/dload.php?action=file&file_id=9832">Toshiba spec sheet</A> <p>
IRP notation: (JP1)
{37.9k,422}<1,-3|3,-1>((D:3,S:1,F:8,-80)2,-128)+ <br>
A and B are subsumed into F, and the value of H is computed by the executor. H=A^B.
<br>EFC translation: lsb, but not computed in DecodeIR.
<br> DecodeIR reports H as the subdevice. This is useful when making a Pronto Hex file,
or other description based on durations. Remotes with executors (e.g. UEI remotes) normally compute the value of
H in the executor, and the "subdevice" is not needed as a parameter.
<H2><A name="F32">F32</A></H2>
UEI protocol: Unknown
<br>
IRP notation: {37.9k,422,msb}<1,-3|3,-1>(D:8,S:8,F:8,E:8,-100m)+ <br>
<p>The meaning of the 32 bits of data is unknown, and the assignment to D, S, F, and E is arbitrary </p>
<H2><A name="Fujitsu">Fujitsu</A></H2>
UEI protocol: 00F8
<br>
IRP notation: {37k,432}<1,-1|1,-3>(8,-4,20:8,99:8,0:4,E:4,D:8,S:8,F:8,1,-110)+
<br>
EFC translation: LSB comp
<p>Fujitsu is the member of the Kaseikyo family with OEM_code1=20 and OEM_code2=99.
There is no check byte, so the risk of an incorrectly decoded OBC is much higher than in
other Kaseikyo protocols.</p>
<p>00F8 requires 2-byte hex commands, so the decoded EFC number is generally not
useful. Use OBC number in upgrades or to compute Hex commands.</p>
<H2><A name="Fujitsu-56">Fujitsu-56</A></H2>
IRP notation: {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)+
<H2><A name="G.I. Cable">G.I. Cable and G.I. Cable{1}</A></H2>
UEI protocol: 00C4
<br>
IRP notation: {38.7k,490}<1,-4.5|1,-9>(18,-9,F:8,D:4,C:4,1,-84,(18,-4.5,1,-178)*)
{C = -(D + F:4 + F:4:4)} <br>
EFC translation: LSB
<p>This protocol signals repeats by the use of <A href="#repeat">dittos</A>.
When the {1} is shown as part of the protocol name for G.I. Cable, it just means that the repeat
part of the signal is not present. That doesn't indicate any difference in the actual protocol nor
even any unreliability in the decode. It may indicate that use of the learned signal will be less
reliable, so you have more than usual reason to replace it with a <A HREF="#jp1">KeyMove, Upgrade</A> or cleaned
up version.</p>
<H2><A name="G.I.4DTV">G.I.4DTV</A></H2>
UEI protocol: 00A4
<br>
IRP notation: {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)} <br>
EFC translation: NONE
<p>This is a moderately robust protocol, but <A href="#spurious">spurious decodes</A> are still possible</p>
<p>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 check sum. <A href="http://www.hifi-remote.com/forums/viewtopic.php?p=103934#103934">D encoding scheme</A>
The official (UEI) protocol executor for G.I.4DTV does not support EFC numbers. If you are creating an
upgrade in KM or RM you should use OBC numbers, not EFC numbers. If you need the Hex Cmd for a KeyMove,
you should use the functions sheet of KM or RM to compute it for you from the OBC and device number.</p>
<H2><A name="G.I.RG">G.I.RG</A></H2>
UEI protocol: unknown
<br>
IRP notation: {37.3k,1000, msb}<1,-1|1,-3>(5,-3,F:6,S:2,D:8,1,-60)+ <br>
EFC translation:
<p>This is a moderately robust protocol, but <A href="#spurious">spurious decodes</A> are still possible,
especially SIM2 which has nearly identical timing.</p>
<p>Typical usage is the GI/Next Level/Motorola RG2x00 series</p>
<H2><A name="Grundig16">Grundig16 and Grundig16-30</A></H2>
UEI protocol: Grundig16 0112, Grundig16-30 00AB
<br>IRP notation for Grundig16: {35.7k,578,msb}<-4,2|-3,1,-1,1|-2,1,-2,1|-1,1,-3,1>
(806u,-2960u,1346u,T:1,F:8,D:7,-100)+
<br>IRP notation for Grundig16-30: {30.3k,578,msb}<-4,2|-3,1,-1,1|-2,1,-2,1|-1,1,-3,1>
(806u,-2960u,1346u,T:1,F:8,D:7,-100)+
<br>
EFC translation: MSB but with bit pairs translated data->hex by 00->00, 01->11, 10->01, 11->
10 and off by one position.
<p>These are two variants of the same protocol, differing only in frequency. The IRP notation is corrected
from previous versions of this document, to bring it into line with what DecodeIR actually does.</p>
<H2><A name="GXB">GXB</A></H2>
IRP notation: {38.3k,520,msb}<1,-3|3,-1>(1,-1,D:4,F:8,P:1,1,^???)+
<p>Decoder for a nonstandard Xbox remote.</p>
<H2><A name="Humax 4Phase">Humax 4Phase</A></H2>
IRP notation: {56k,105, msb}<-2,2|-3,1|1,-3|2,-2>(T=0,(2,-2,D:6,S:6,T:2,F:7,~F:1,^95m,T=1)+)
<p>The allocation of bits to device and subdevice (D:6, S:6) is a guess.</p>
<H2><A name="IODATAn">IODATA</A><i>n</i> and IODATA<i>n</i>-<i>x</i>-<i>y</i></H2>
UEI protocol: not known.
<br>
IRP notation: {38k,550}<1,-1|1,-3>(16,-8,x:7,D:7,S:7,y:7,F:8,C:4,1,^108m)+
{n = F:4 ^ F:4:4 ^ C:4} <br>
EFC translation: LSB
<p>This is potentially a class of protocols distinguished by values of <i>n</i>, <i>x</i> and <i>y</i> with
<i>n</i> = 0..15 and <i>x</i>, <i>y</i> = 0..127. If <i>x</i> and <i>y</i> are both zero, they are omitted. The only known example is IODATA1.</p>
<H2><A name="Jerrold">Jerrold</A></H2>
UEI protocol: 0006
<br>
IRP notation: {0k,44}<1,-7.5m|1,-11.5m>(F:5,1,-23.5m)+
<p>This is not a robust protocol, so <A href="#spurious">spurious decodes</A> are likely.</p>
<H2><A name="JVC">JVC and JVC{2}</A></H2>
UEI protocol: 0034
<br>
IRP notation: {38k,525}<1,-1|1,-3>(16,-8,(D:8,F:8,1,-45)+) <br>
EFC translation: LSB comp
<p>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. But JVC{2} is not robust,
so <A href="#spurious">spurious decodes</A> are likely. It
is also very similar in structure and timing to <A href="#Mitsubishi">Mitsubishi</A> protocol, so that
DecodeIr has difficulty distinguishing one from the other. The device number, OBC and EFC
are all encoded the same way between the two. So if you have JVC{2}
decodes that you have reason to suspect should actually be Mitsubishi, you can try using
them as Mitsubishi without changing the numbers. However, true Mitsubishi signals will not
mis-decode as JVC, just as JVC{2}. So if some of the signals for your device decode as JVC
and others as JVC{2}, you should trust all those decodes and not try Mitsubishi.</p>
<H2><A name="JVC-48">JVC-48</A></H2>
UEI protocol: 001F or 00C9 or 00CD
<br>
IRP notation: {37k,432}<1,-1|1,-3>(8,-4,3:8,1:8,D:8,S:8,F:8,(D^S^F):8,1,-173)+
<br>
EFC translation: LSB comp
<p>JVC-48 is the member of the Kaseikyo family with M=3 and N=1.</p>
<p>Panasonic protocol uses the same check byte rules as JVC-48, so you might want use the (more flexible)
Panasonic entries in KM or RM to produce a JVC-48 upgrade (by changing the OEM_code1(M) and OEM_code2(N) values). For simple
JVC-48 upgrades you get exactly the same results by directly selecting the "JVC-48" protocol.</p>
<H2><A name="JVC-56">JVC-56</A></H2>
IRP notation: {37k,432}<1,-1|1,-3>(8,-4,3:8,1:8,D:8,S:8,X:8,F:8,(D^S^X^F):8,1,-173)+
<p>JVC-56 is the member of the Kaseikyo56 family with M=3 and N=1.</p>
<H2><A name="Kaseikyo">Kaseikyo</A></H2>
UEI protocol: 00F8 <br>
IRP notation: {37k,432}<1,-1|1,-3>(8,-4,M:8,N:8,X:4,D:4,S:8,F:8,G:8,1,-173)+ {X=M:4:0^M:4:4^N:4:0^N:4:4}
<br>
EFC translation: LSB comp
<p>Kaseikyo is a family of protocols that includes Panasonic, Mitsubishi-K, Fujitsu, JVC-48, Denon-K, Sharp-DVD and Teac-K.
Each manufacturer is assigned a pair of identifiers, here identified as M and N. If an IR signal matches a known pair of OEM
identifiers and has the correct checksum behavior, it will be decoded with appropriate protocol name. Otherwise it will
be decoded as Kaseikyo.</p>
<p>
<H2><A name="Kaseikyo56">Kaseikyo56</A></H2>
IRP notation: {37k,432}<1,-1|1,-3>(8,-4,M:8,N:8,X:4,D:4,S:8,E:8,F:8,G:8,1,-173)+ {X=M:4:0^M:4:4^N:4:0^N:4:4}
Like Kaseikyo, each manufacturer is assigned a pair of identifiers identified as M and N. If an IR signal matches a known pair of OEM
identifiers and has the correct checksum behavior, it will be decoded with appropriate protocol name. Otherwise it will
be decoded as Kaseikyo56.</p>
<H2><A name="Kathrein">Kathrein</A></H2>
UEI protocol: 0066
<br>IRP notation: {38k,540}<1,-1|1,-3>(16,-8,D:4,~D:4,F:8,~F:8,1,^105m,(16,-8,F:8,1,^105m)+)
<br>EFC translation: LSB comp
<p>This protocol signals repeats by the use of <A href="#repeat">dittos</A>. It is unusual in that the ditto
frame carries part of the signal data, specifically the function code (OBC) but not the device code.
Similar to Logitech, but both decodes give the same device number and OBC.</p>
<H2><A name="Konka">Konka</A></H2>
UEI protocol: 019B
<br>
IRP notation: {38k,500,msb}<1,-3|1,-5>(6,-6,D:8,F:8,1,-8,1,-46)+ <br>
EFC translation: MSB
<H2><A name="Lumagen">Lumagen</A></H2>
IRP notation: {38.4k,416,msb}<1,-6|1,-12>(D:4,C:1,F:7,1,-26)+ {C = (#F+1)&1}
<br>
EFC translation: MSB prepended with C bit.
<p>This is a moderately robust protocol, but <A href="#spurious">spurious decodes</A> are still possible.</p>
<H2><A name="Lutron">Lutron</A></H2>
IRP notation: {40k,2300,msb}<-1|1>(255:8,X:24,0:4)+ <br>
EFC translation: MSB of decoded signal.
<p>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.</p>
<H2><A name="Logitech">Logitech</A></H2>
UEI protocol: 020B <br>
IRP notation: {38k,127}<3,-4|3,-8>(31,-36,D:4,~D:4,F:8,~F:8,3,-50m)+ <br>
<p>Logitech is used with their PS3 adapter. The IR signal is similar to Kathrein. If a Logitech signal is decoded
as Kathrein, the device number and OBC are still correct.</p>
<H2><A name="Matsui">Matsui</A></H2>
IRP notation: {38K,525}<1,-1|1,-3>(D:3,F:7,1,^30.5m)+ <br>
EFC translation: Not available in this version of DecodeIr
<p>This is not a robust protocol, so <A href="#spurious">spurious decodes</A> are likely.</p>
<H2><A name="MCE">MCE (RC6-6-32)</A></H2>
IRP notation: {36k,444,msb}<-1,1|1,-1>(6,-2,1:1,6:3,-2,2,OEM1:8,OEM2:8,T:1,D:7,F:8,^107m)+
<p>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. If all those
rules are met, DecodeIr will display the name as "MCE" and with the OEM2 field moved to the
subdevice position. Otherwise it will display RC6-6-32.</p>
<p>As of version 8.31, KM does not have built-in support for this protocol, but there are KM format upgrade
files available for Media Center (built by an expert who isn't limited to KM's built-in protocols). Those
upgrades should be adaptable to any RC6-6-32 code set (by changing the fixed data), if the one you have
doesn't already match the upgrade.</p>
<p>RM version 1.16 has support for RC6-6-32, which can be used for MCE upgrades. Version 1.17 will also have
direct support for MCE</p>
<H2><A name="Metz19">Metz19</A></H2>
IRP notation: (37.9K,106,msb)<4,-9|4,-16>(8,-22,T:1,D:3,~D:3,F:6,~F:6,4,-125m)+ <br>
The toggle bit T is inverted each time a new button press occurs.
<H2><A name="Mitsubishi">Mitsubishi</A></H2>
UEI protocol: 0014
<br>
IRP notation: {32.6k,300}<1,-3|1,-7>(D:8,F:8,1,-80)+ <br>
EFC translation: LSB comp
<p>This is not a robust protocol, so <A href="#spurious">spurious decodes</A> are likely. It
is also very similar in structure and timing to <A href="#JVC">JVC{2}</A> protocol, so that
DecodeIr has difficulty distinguishing one from the other. The device number, OBC and EFC
are all encoded the same way between the two. So if you have Mitsubishi
decodes that you have reason to suspect should actually be JVC, you can try using
them as JVC without changing the numbers.</p>
<H2><A name="Mitsubishi-K">Mitsubishi-K</A></H2>
IRP notation: {37k,432}<1,-1|1,-3>(8,-4,35:8,203:8,X:4,D:8,S:8,F:8,T:4,1,-100)+
<br>
EFC translation: not available yet
<p>Mitsubishi-K is the member of the Kaseikyo family with OEM_code1=35 and OEM_code2=203.</p>
<H2><A name="NEC">NEC</A></H2>
NEC is a family of similar protocols including NEC1, NEC2, Tivo, Pioneer, Apple, NECx1 and NECx2.
If you get a decode whose protocol name is
simply "NEC" that indicates the learned signal is not complete (usually caused by
not holding the original remote's button long enough during learning). Enough of
the signal is present to accurately determine the device, subdevice and OBC numbers.
But not enough is present to determine whether the protocol is NEC1 or NEC2.
<H3><A name="NEC12difference">Difference between NEC1 and NEC2</A></H3>
The difference between NEC1 and NEC2 only affects the signal sent by a long
keypress. A short press sends the same signal in NEC1 and NEC2.
<H3><A name="Variant IRstreams in NEC protocols">Variant IRstreams in NEC protocols</A></H3>
For NEC1, NEC2, NECx1, and NECx2 protocols, the IRstream contains D:8,S:8,F:8,~F:8 <br>
However, some manufacturers (especially Yamaha and Onkyo) are breaking the "rule" that the 4th byte should be ~F:8<br>
Version 2.42 decodes these variants by adding suffixes to the protocol name depending on the IRstream:<br>
-y1: D:8,S:8,F:8,~F:7,F:1:7 (complement all of F except the MSB)<br>
-y2: D:8,S:8,F:8,F:1,~F:7:1 (complement all of F except the LSB)<br>
-y3: D:8,S:8,F:8,F:1,~F:6:1,F:1:7 (complement all of F except MSB and LSB)<br>
-rnc: D:8,S:8,F:8;~F:4:4,~F:4 (complement F and reverse the nibbles)<br>
-f16: D:8,S:8,F:8,E:8 (no relationship between the 3rd and 4th bytes)<br>
<H2><A name="NEC1">NEC1</A></H2>
IRP notation: {38.0k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,^108m,(16,-4,1,^108m)*)
<br>
EFC translation: LSB comp
<p>A few devices use NEC1 protocol at 40Khz, rather than the typical frequency.
When getting a decode of NEC1, if you notice that the frequency is closer to 40Khz than to 38Khz,
examine multiple learns from the same device to estimate whether the 40Khz frequency is a
learning error or a true characteristic of the device. If the 40Khz is correct, there are
methods in JP1, or MakeHex (whichever you are using) to reproduce NEC1 at 40Khz rather than the
usual frequency.</p>
<H2><A name="NEC2">NEC2</A></H2>
IRP notation: {38.0k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,^108m)+ <br>
EFC translation: LSB comp
<p>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.</p>
<H2><A name="NECx">NECx</A></H2>
If you get a decode whose protocol name is
simply "NECx" that indicates the learned signal is not complete (usually caused by
not holding the original remote's button long enough during learning). Enough of
the signal is present to accurately determining the device, subdevice and OBC numbers.
But not enough is present to determine the exact protocol, which is probably NECx1 or NECx2. This
incomplete learn also makes it harder to distinguish NEC from NECx, so a decode of "NECx"
might be NEC1 or NEC2 or even Tivo or Pioneer.
<H2><A name="NECx1">NECx1</A></H2>
IRP notation: {38.0k,564}<1,-1|1,-3>(8,-8,D:8,S:8,F:8,~F8,1,^108m,(8,-8,D:1,1,^108m)*) <br>
EFC translation: LSB comp
<br> Most, but not all NECx1 signals have S=D
<H2><A name="NECx2">NECx2</A></H2>
IRP notation: {38.0k,564}<1,-1|1,-3>(8,-8,D:8,S:8,F:8,~F8,1,^108m)+ <br>
EFC translation: LSB comp
<br> Most, but not all NECx2 signals have S=D
<H2><A name="Nokia">Nokia</A></H2>
IRP notation: {36k,msb}<164,-276|164,-445|164,-614|164,-783>(412,-276,D:8,S:8,F:8,164,^100m)+
<br>
EFC translation: MSB
<H2><A name="Nokia12">Nokia12</A></H2>
IRP notation: {36k,msb}<164,-276|164,-445|164,-614|164,-783>(412,-276,D:4,F:8,164,^100m)+
<br>
EFC translation: MSB
<H2><A name="Nokia32">Nokia32</A></H2>
UEI protocol: 0173
<br>
IRP notation: {36k,msb}<164,-276|164,-445|164,-614|164,-783>(412,-276,D:8,S:8,T:1,X:7,F:8,164,^100m)+
<br>
EFC translation: MSB
<p>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"</p>
<H2><A name="NRC16">NRC16</A></H2>
Documentation not written yet.
<H2><A name="NRC17">NRC17</A></H2>
UEI protocol: 00BD <br>
irp={500,38k,25%}<-1,1|1,-1>(1,-5,1:1,254:8,255:8,-28, (1,-5,1:1,F:8,D:8,-220)+, 1,-5,1:1,254:8,255:8,-200)<br>
<a href="http://www.sbprojects.com/knowledge/ir/nrc17.php"> Details of NRC17</a><br>
<H2><A name="OrtekMCE">OrtekMCE</A></H2>
UEI protocol: not known.
<br>
IRP notation: {38.6k,480}<1,-1|-1,1>([P=0][P=1][P=2],4,-1,D:5,P:2,F:6,C:4,-48m)+{C=3+#D+#P+#F}<br>
EFC translation: 6-bit LSB
<p>The <A href="#repeat">repeat frames</A> 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. DecodeIR v2.37
and later check P and will report in the Misc field if either the start or end frame, or both, is/are missing.</p>
<H2><A name="Pace MSS">Pace MSS</A></H2>
IRP notation: {38k,630,msb}<1,-7|1,-11>(1,-5,1,-5,T:1,D:1,F:8,1,^120m)+
<br>
EFC translation: Not available in this version of DecodeIr
<p>This is a moderately robust protocol, but <A href="#spurious">spurious decodes</A> are still possible.</p>
<H2><A name="Panasonic">Panasonic</A></H2>
UEI protocol: 001F or 00C9 or 00CD
<br>
IRP notation: {37k,432}<1,-1|1,-3>(8,-4,2:8,32:8,D:8,S:8,F:8,(D^S^F):8,1,-173)+
<br>
EFC translation: LSB comp
<p>Panasonic protocol is the most commonly seen member of the Kaseikyo family</p>
<p>OEM_code1 is 2 and OEM_code2 is 32 (or DecodeIr won't display the name as "Panasonic").
So those values in KM or RM can be changed from the default 2 and 32 only
when using the Panasonic entry in KM or RM to produce some Kaseikyo variant
OTHER THAN Panasonic. When creating a Panasonic upgrade, don't change those
from the default values.</p>
<H2><A name="Panasonic2">Panasonic2</A></H2>
IRP notation: {37k,432}<1,-1|1,-3>(8,-4,2:8,32:8,D:8,S:8,X:8,F:8,(D^S^X^F):8,1,-173)+
<H2><A name="Panasonic_Old">Panasonic_Old</A></H2>
UEI protocol: 0000 or 0087
<br>
IRP notation: {57.6k,833}<1,-1|1,-3>(4,-4,D:5,F:6,~D:5,~F:6,1,-44m)+ <br>
EFC translation: 6-bit LSB comp with 2-bit mini-combo
<p>Lists three different EFCs because this protocol is a <A href="#mini combo">mini combo</A>.</p>
<H2><A name="PCTV">PCTV</A></H2>
IRP notation: {38.4k,832}<0,-1|1,-0>(2,-8,1,D:8,F:8,2,-???)
<H2><A name="pid-0001">pid-0001</A></H2>
UEI protocol: 0001
<br>IRP notation: {0k,msb}<24,-9314|24,-13486>(24,-21148,(F:5,1,-28m)+)
<br>EFC translation: 5-bit MSB comp
<p>As of version 8.31 KM has seriously wrong OBC translation for pid-0001, so use only EFC's with KM.</p>
<H2><A name="pid-0003">pid-0003</A></H2>
UEI protocol: 0003
<br>IRP notation: {40.2k,389}<2,-2|3,-1>(F:8,~F:8,^102k)+
<br>EFC translation: LSB
<H2><A name="pid-0004">pid-0004</A></H2>
UEI protocol: 0004
<br>IRP notation: {0k,msb}<12,-130|12,-372>(F:6,12,-27k)+
<br>EFC translation: 6-bit MSB comp
<H2><A name="pid-0083">pid-0083</A></H2>
UEI protocol: 0083
<br>EFC translation: 5-bit MSB comp
<br>IRP notation: {42.3K, 3000}<1,-3,1,-7|1,-7,1,-3>(F:5,1,-27)+
<p>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.</p>
<p>As of version 8.31, KM does not translate OBC to EFC according to
the same rules used by DecodeIr. RM does translate consistently with DecodeIr, so you may find
it easier to use RM. If you use KM, you should use the EFC number from the decode not the OBC number.
Pid-0083 protocol
uses the same EFC numbering across all JP1 remotes, so use of EFC is safe. KM uses different
OBC numbering than RM and DecodeIr, so use of OBCs isn't safe.</p>
<H2><A name="Pioneer">Pioneer</A></H2>
IRP notation: {40k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,^108m)+ <br>
EFC translation: LSB comp
<p>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.</p>
<p>Many Pioneer commands are sent as combinations of two different Pioneer signals.
This version of DecodeIr does not associate the two signals together into
one command. It decodes them separately. If you get more than one of the same
OBC from decoding a learned signal, that just means the learning system failed
to understand the repeat pattern. It does not mean a two part signal. But
if there are two different OBCs (with the same or different device numbers)
you have a two part Pioneer signal.</p>
<p>Including a two part Pioneer signal in a KeyMove or upgrade is a complex process that requires a good
understanding of Pioneer signals and of the Pioneer support in KM. The signals don't vary much among related Pioneer models.
So the best way to get an upgrade or hex cmd including such signals is to look through existing Pioneer upgrades in
the JP1 group and find one that already includes the same (or nearly same) signal.</p>
<H2><A name="Proton">Proton</A></H2>
UEI protocol: 005C
<br>
IRP notation: {38k,500}<1,-1|1,-3>(16,-8,D:8,1,-8,F:8,1,^63m)+ <br>
EFC translation: LSB comp
<p>This is not a robust protocol, so <A href="#spurious">spurious decodes</A> are likely.</p>
<H2><A name="RC5">RC5</A></H2>
UEI protocol: 00E8
<br>
IRP notation: {36k,msb,889}<1,-1|-1,1>(1,~F:1:6,T:1,D:5,F:6,^114m)+ <br>
EFC translation: 6-bit MSB comp with 2-bit mini-combo
<p>Lists three different EFCs because this protocol is a <A href="#mini combo">mini combo</A>.</p>
<p>What we call "device" is really the "System" and what we
call "OBC" is really the "Command". If you are using ProntoEdit
to create the RC5 signals directly, that GUI uses that correct (System and
Command) Philips terminology.</p>
<H2><A name="RC5-7F">RC5-7F</A></H2>
UEI protocol: 0182
<br>
IRP notation: {36k,msb,889}<1,-1|-1,1>(1, ~D:1:5,T:1,D:5,F:7,^114m)+ <br>
EFC translation: 7-bit MSB comp
<H2><A name="RC5-7F-57">RC5-7F-57</A></H2>
UEI protocol: 0182
<br>
IRP notation: {57k,msb,889}<1,-1|-1,1>(1, ~D:1:5,T:1,D:5,F:7,^114m)+ <br>
EFC translation: 7-bit MSB comp
<H2><A name="RC5x">RC5x</A></H2>
UEI protocol: 00F2
<br>
IRP notation: {36k,msb,889}<1,-1|-1,1>(1,~S:1:6,T:1,D:5,-4,S:6,F:6,^114m)+
<br>
EFC translation: NONE
<p>The official (UEI) protocol executor for RC5x does not support EFC numbers. If you are creating an
upgrade in KM or RM you should use OBC numbers, not EFC numbers. If you need the Hex Cmd for a KeyMove,
you should use the functions sheet of KM or RM to compute it for you from the OBC and subdevice number.</p>
<p>In the functions sheet in KM you must put the subdevice number in the byte2 column, which KM calls
"unit code".</p>
<p>What we call "Device" is really the "System". What we call
Subdevice is really the "Command". What we call "OBC"
is really the "Data". If you are using ProntoEdit to create the
RC5 signals directly, that GUI uses the correct (System, Command and Data)
Philips terminology.</p>
<H2><A name="RC5-?-??">RC5-?-??</A></H2>
Just ignore this decode. It is almost certainly <A href="#spurious">spurious</A>. In case there is a new
protocol I don't know about yet in the family with RC5 and StreamZap, it will decode in this form producing
data to help me understand that protocol.