-
Notifications
You must be signed in to change notification settings - Fork 0
/
DecodeIR.html
1182 lines (1033 loc) · 67.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>Applicable to Version 2.45 of DecodeIR.dll</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="#Audiovox">Audiovox</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="#GI Cable">GI Cable</A><BR>
<A href="#GI Cable">GI Cable{1}</A><BR>
<A href="#GI 4DTV">GI 4DTV</A><BR>
<A href="#GI RG">GI 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">Pace</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="#Zaptor">Zaptor</A><BR>
<A href="#Zenith">Zenith</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="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="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>This protocol signals repeats by the use of <A href="#repeat">dittos</A>.
<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)+
<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>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 executor: 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>
<H2><A name="AK">AK</A></H2>
Documentation not written yet.
<H2><A name="Akai">Akai</A></H2>
UEI executor: 000D
<br>
IRP notation: {38k,289}<1,-2.6|1,-6.3>(D:3,F:7,1,^25.3m)+ <br>
This is not a robust protocol, so <A href="#spurious">spurious decodes</A> are likely.<br>
<H2><A name="Amino">Amino</A></H2>
UEI executor: 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 checks T and reports 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 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.
<H2><A name="Anthem">Anthem</A></H2>
UEI executor: 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 executor: 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.
<br>Apple uses the same framing as NEC1, with D=238 in normal use, 224 while pairing. S=135
<H2><A name="Archer">Archer</A></H2>
IRP notation: {0k,12}<1,-3.3m|1,-4.7m>(F:5,1,-9.7m)+ <br>
This is not a robust protocol, so <A href="#spurious">spurious decodes</A> are likely.
<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.45 does not report Async decodes.
</p>
<H2><A name="Audiovox">Audiovox</A></H2>
UEI executor: 005D
<br>
IRP notation: {40k,500}<1,-1|1,-3>(16,-8,D:8,1,-8,F:8,1,-40)+
<H2><A name="Barco">Barco</A></H2>
UEI executor: 002A
<br>IRP notation: {0k,10}<1,-5|1,-15>(1,-25, D:5,F:6, 1,-25,1,120m)+
This is a moderately robust protocol, but <A href="#spurious">spurious decodes</A> are still possible.
<H2><A name="Blaupunkt">Blaupunkt</A></H2>
UEI executor: 00A5
<br>
IRP notation: {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)
<H2><A name="Bose">Bose</A></H2>
UEI executor: 010C<br>
IRP notation: {38.0k,500,msb}<1,-1|1,-3>(2,-3,F:8,~F:8,1,-50m)+ <br>
<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 executor: 018C
<br>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>UEI executor: 0171
<br>IRP notation: {38k,250,msb}<-1,1|1,-1>(T=0,(1,-1,D:7,S:6,T:1,0:1,F:7,-89m,T=1)+)
<br>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".
<H2><A name="CanalSatLD">CanalSatLD</A></H2>
UEI executor: 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)+)
<br>The official name for CanalSatLD is "ruwido r-step"
<H2><A name="Denon">Denon, Denon{1} and Denon{2}</A></H2>
UEI executor: 001C <br>
IRP notation: {38k,264}<1,-3|1,-7>((D:5,F:8,0:2,1,-165,D:5,~F:8,3:2,1,-165)+,(D:5,F:8,0:2,1,-165))
<br>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>.
<H2><A name="Denon-K">Denon-K</A></H2>
UEI executor: 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>
Denon-K is the member of the Kaseikyo family with OEM_code1=84 and OEM_code2=50.
<H2><A name="Dgtec">Dgtec</A></H2>
UEI executor: 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>
This protocol signals repeats by the use of <A href="#repeat">dittos</A>.
<H2><A name="DirecTV">DirecTV</A></H2>
UEI executor: 0162<br>
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)}
<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>
This protocol was called Russound in versions of DecodeIR earlier than 2.40.
<H2><A name="Dishplayer">Dishplayer</A></H2>
UEI executor: 010F
<br>
IRP notation: {38.4k,535,msb}<1,-5|1,-3>(1,-11,(F:6,S:5,D:2,1,-11)+) <br>
This is not a robust protocol, so <A href="#spurious">spurious decodes</A> are likely.
<H2><A name="Dish_Network">Dish_Network</A></H2>
UEI executor: 0002 <br>
IRP notation: {57.6k,400}<1,-7|1,-4>(1,-15,(F:-6,S:5,D:5,1,-15)+)
<br>This is not a robust protocol, so <A href="#spurious">spurious decodes</A> are likely.
<H2><A name="EchoStar">EchoStar</A></H2>
UEI executor: 0182
<br> As of 2.42 DecodeIR shows this as RC5-7F
<H2><A name="Elan">Elan</A></H2>
UEI executor: 01F8<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>
<H2><A name="Emerson">Emerson</A></H2>
UEI executor: 0065
<br>
IRP notation: {36.7k,872}<1,-1|1,-3>(4,-4,D:6,F:6,~D:6,~F:6,1,-39)+ <br>
<H2><A name="F12">F12</A></H2>
UEI executor: 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> 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.
<br>UEI executor 016D transmits a similar signal but with a leadout time of 6.7mS. One frame of OBC1 and repeating frame of OBC2.
<H2><A name="F32">F32</A></H2>
UEI executor: Unknown
<br>
IRP notation: {37.9k,422,msb}<1,-3|3,-1>(D:8,S:8,F:8,E:8,-100m)+ <br>
The meaning of the 32 bits of data is unknown, and the assignment to D, S, F, and E is arbitrary
<H2><A name="Fujitsu">Fujitsu</A></H2>
UEI executor: 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>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.
<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="GI Cable">GI Cable and GI Cable{1}</A></H2>
UEI executor: 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>
This protocol signals repeats by the use of <A href="#repeat">dittos</A>.
<H2><A name="GI 4DTV">GI 4DTV</A></H2>
UEI executor: 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>
This is a moderately robust protocol, but <A href="#spurious">spurious decodes</A> are still possible
<br>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>
<H2><A name="GI RG">GI RG</A></H2>
UEI executor: 0177
<br>
IRP notation: {37.3k,1000, msb}<1,-1|1,-3>(5,-3,F:6,S:2,D:8,1,-60)+ <br>
This is a moderately robust protocol, but <A href="#spurious">spurious decodes</A> are still possible,
especially SIM2 which has nearly identical timing.
<br>Typical usage is the GI/Next Level/Motorola RG2x00 series
<H2><A name="Grundig16">Grundig16 and Grundig16-30</A></H2>
UEI executor: 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>These are two variants of the same protocol, differing only in frequency.
<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,^???)+
<br>Decoder for a nonstandard Xbox remote.
<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)+)
<br>The allocation of bits to device and subdevice (D:6, S:6) is a guess.
<H2><A name="IODATAn">IODATA</A><i>n</i> and IODATA<i>n</i>-<i>x</i>-<i>y</i></H2>
UEI executor: 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>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.
<H2><A name="Jerrold">Jerrold</A></H2>
UEI executor: 0006
<br>
IRP notation: {0k,44}<1,-7.5m|1,-11.5m>(F:5,1,-23.5m)+
<br>This is not a robust protocol, so <A href="#spurious">spurious decodes</A> are likely.
<H2><A name="JVC">JVC and JVC{2}</A></H2>
UEI executor: 0034
<br>
IRP notation: {38k,525}<1,-1|1,-3>(16,-8,(D:8,F:8,1,-45)+) <br>
<br>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.
<H2><A name="JVC-48">JVC-48</A></H2>
UEI executor: 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>
JVC-48 is the member of the Kaseikyo family with M=3 and N=1.
<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)+
<br>JVC-56 is the member of the Kaseikyo56 family with M=3 and N=1.
<H2><A name="Kaseikyo">Kaseikyo</A></H2>
UEI executor: 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>
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.
<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}
<br>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.
<H2><A name="Kathrein">Kathrein</A></H2>
UEI executor: 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>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.
<H2><A name="Konka">Konka</A></H2>
UEI executor: 019B
<br>
IRP notation: {38k,500,msb}<1,-3|1,-5>(6,-6,D:8,F:8,1,-8,1,-46)+
<H2><A name="Logitech">Logitech</A></H2>
UEI executor: 020B <br>
IRP notation: {38k,127}<3,-4|3,-8>(31,-36,D:4,~D:4,F:8,~F:8,3,-50m)+ <br>
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.
<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>
This is a moderately robust protocol, but <A href="#spurious">spurious decodes</A> are still possible.
<H2><A name="Lutron">Lutron</A></H2>
UEI executor: 00E7 <br>
IRP notation: {40k,2300,msb}<-1|1>(255:8,X:24,0:4)+
<br>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. See
<A href="http://www.hifi-remote.com/forums/viewtopic.php?p=84021#84021">this post</A> and
<A href="http://www.hifi-remote.com/forums/viewtopic.php?p=113963#113963">this one</A> for more description.
<H2><A name="Matsui">Matsui</A></H2>
IRP notation: {38K,525}<1,-1|1,-3>(D:3,F:7,1,^30.5m)+ <br>
This is not a robust protocol, so <A href="#spurious">spurious decodes</A> are likely.
<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)+
<br>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.
<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 executor: 0014
<br>
IRP notation: {32.6k,300}<1,-3|1,-7>(D:8,F:8,1,-80)+ <br>
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.
<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>
Mitsubishi-K is the member of the Kaseikyo family with OEM_code1=35 and OEM_code2=203.
<H2><A name="NEC">NEC</A></H2>
UEI executor: 005A, 011A, 00B6, 017E, 01AD, 000F, 0246 <br>
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) UEI executor: 0206<br>
-f16: D:8,S:8,F:8,E:8 (no relationship between the 3rd and 4th bytes) UEI executor: 01AD<br>
-f16 may be returned as the decode for a signal in which F and ~F precede D:S<br>
{38.0k,564}<1,-1|1,-3>(16,-8,F:8,~F:8,D:8,S:8,1,^108m,(16,-4,1,^108m)*) UEI executor: 01EA<br>
{38.0k,564}<1,-1|1,-3>(16,-8,F:8,~F:8,D:8,S:8,1,^108m)+ UEI executor: 01EA
<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>
<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,~D:8,F:8,~F:8,1,^108m)+ <br>
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.
<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>
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>
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)+
<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)+
<H2><A name="Nokia32">Nokia32</A></H2>
UEI executor: 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>
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"
<H2><A name="NRC16">NRC16</A></H2>
UEI executor: 0075 for 32KHz, 00B0 for 38KHz <br>
{32k,500}<-1,1|1,-1>(1,-5,1:1,254:8,127:7,-15m,(1,-5,1:1,F:8,D:7,-110m)+,1,-5,1:1,254:8,127:7,-15m)<br>
{38k,500}<-1,1|1,-1>(1,-5,1:1,254:8,127:7,-15m,(1,-5,1:1,F:8,D:7,-110m)+,1,-5,1:1,254:8,127:7,-15m)
<H2><A name="NRC17">NRC17</A></H2>
UEI executor: 00BD <br>
IRP notation: {38k,500}<-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 executor: 01ED
<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>
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 checks P and reports in the Misc field if either the start or end frame, or both, is/are missing.
<H2><A name="Pace">Pace</A></H2>
UEI executor: 0095 <br>
IRP notation: {38k,630,msb}<1,-7|1,-11>(1,-5,1,-5,T:1,D:1,F:8,1,^120m)+
<br>
This is a moderately robust protocol, but <A href="#spurious">spurious decodes</A> are still possible.
<H2><A name="Panasonic">Panasonic</A></H2>
UEI executor: 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>
Panasonic protocol is the most commonly seen member of the Kaseikyo family
OEM_code1 is 2 and OEM_code2 is 32 (or DecodeIr won't display the name as "Panasonic").
<H2><A name="Panasonic2">Panasonic2</A></H2>
UEI executor: 0109 <br>
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 executor: 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)+
<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 executor: 0001
<br>IRP notation: {0k,msb}<24,-9314|24,-13486>(24,-21148,(F:5,1,-28m)+)
<H2><A name="pid-0003">pid-0003</A></H2>
UEI executor: 0003
<br>IRP notation: {40.2k,389}<2,-2|3,-1>(F:8,~F:8,^102k)+
<H2><A name="pid-0004">pid-0004</A></H2>
UEI executor: 0004
<br>IRP notation: {0k,msb}<12,-130|12,-372>(F:6,12,-27k)+
<H2><A name="pid-0083">pid-0083</A></H2>
UEI executor: 0083
<br>IRP notation: {42.3K, 3000}<1,-3,1,-7|1,-7,1,-3>(F:5,1,-27)+
<br>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.
<H2><A name="Pioneer">Pioneer</A></H2>
UEI executor: 00E2 <br>
IRP notation: {40k,564}<1,-1|1,-3>(16,-8,D:8,~D:8,F:8,~F:8,1, -25m)+ <br>
Pioneer is distinguished from NEC2 only by frequency and lead out duration. So if your learning system does not
learn frequency accurately, it probably 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.
<br>Many Pioneer commands are sent as combinations of two different Pioneer signals.
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.
<H2><A name="Proton">Proton</A></H2>
UEI executor: 005C or 011B
<br>
IRP notation: {38.5k,500}<1,-1|1,-3>(16,-8,D:8,1,-8,F:8,1,^63m)+ <br>
IRP notation: {40.5k,500}<1,-1|1,-3>(16,-8,D:8,1,-8,F:8,1,^63m)+ <br>
There seems to be two frequencies in use with Proton. Executor 011B can send either. <br>
This is not a robust protocol, so <A href="#spurious">spurious decodes</A> are likely.
<H2><A name="RC5">RC5</A></H2>
UEI executor: 00E8
<br>
IRP notation: {36k,msb,889}<1,-1|-1,1>(1,~F:1:6,T:1,D:5,F:6,^114m)+ <br>
The D and F (Device and OBC) values in a decode are referred to by Philips and some other manufacturers as
"System" and "Command", respectively.
<H2><A name="RC5-7F">RC5-7F</A></H2>
UEI executor: 0182
<br>
IRP notation: {36k,msb,889}<1,-1|-1,1>(1, ~D:1:5,T:1,D:5,F:7,^114m)+
<H2><A name="RC5-7F-57">RC5-7F-57</A></H2>
UEI executor: 0182 <br>
IRP notation: {57k,msb,889}<1,-1|-1,1>(1, ~D:1:5,T:1,D:5,F:7,^114m)+
<H2><A name="RC5x">RC5x</A></H2>
UEI executor: 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>
The D, S and F (Device, Subdevice, and OBC) values in a decode are referred to by Philips and some other manufacturers as
"System", "Command", and "Data", respectively.
<H2><A name="RC5-?-??">RC5-?-??</A></H2>
This decode is almost certainly <A href="#spurious">spurious</A>.
<H2><A name="RC6">RC6</A></H2>
UEI executor: 0058
<br>IRP notation: {36k,444,msb}<-1,1|1,-1>(6,-2,1:1,0:3,<-2,2|2,-2>(T:1),D:8,F:8,^107m)+
<br>RC6 is the name used for the first member of the RC6 family of protocols. Technically this is
RC6-0-16, but DecodeIr will always display that as simply "RC6"
<H2><A name="RC6-6-20">RC6-6-20</A></H2>
UEI executor: 0020 <br>
IRP notation: {36k,444,msb}<-1,1|1,-1>(6,-2,1:1,6:3,<-2,2|2,-2>(T:1),D:8,S:4,F:8,-???)+
<br>This protocol is commonly used in Sky and Sky+ remotes.
<H2><A name="RC6-?-??">RC6-?-??</A></H2>
IRP notation: {36k,444,msb}<-1,1|1,-1>(6,-2,1:1,M:3,<-2,2|2,-2>(T:1),???:??)+
<br>This is the generic form for a decode of protocols in the RC6 family. DecodeIr
uses this form for all RC6 decodes, except RC6-0-16 which is displayed as
simply "RC6", RC6-6-24 which is displayed as "Replay"
and some RC6-6-32 which display as MCE.
<br>The first ? in the protocol name is the M value in the RC6 spec. The ending ?? represents the number of data bits
in the signal.
<H2><A name="RCA">RCA and RCA(Old)</A></H2>
UEI protocols: 00AF (RCA), 002D(RCA(Old)) and 0114 (RCA Combo)
<br>IRP notation for RCA: {58k,460,msb}<1,-2|1,-4>(8,-8,D:4,F:8,~D:4,~F:8,1,-16)+
<br>IRP notation for RCA(Old): {58k,460,msb}<1,-2|1,-4>(32,(8,-8,D:4,F:8,~D:4,~F:8,2,-16)+)
<br>These are two very similar forms of RCA protocol which differ only in that RCA(Old) has an extended lead-in
and a double-length ON pulse before the lead-out. They are so similar that most RCA devices will accept either.
But some RCA devices only accept the one that really matches their own remote.
<H2><A name="RCA-38">RCA-38 and RCA-38(Old)</A></H2>
UEI executor: 00AF:2
<br>IRP notation for RCA-38: {38.7k,460,msb}<1,-2|1,-4>(8,-8,D:4,F:8,~D:4,~F:8,1,-16)+
<br>IRP notation for RCA-38(Old): {38.7k,460,msb}<1,-2|1,-4>(32,(8,-8,D:4,F:8,~D:4,~F:8,2,-16)+)
<br>These signals differ from RCA and RCA(Old) only in the
frequency, which is 38.7kHz instead of the standard 58kHz.
<H2><A name="RECS80">RECS80</A></H2>
UEI executor: 0045, 0068, 0090
<br>IRP notation for 0045: {38k,158,msb}<1,-31|1,-47>(1:1,T:1,D:3,F:6,1,-45m)+
<br>IRP notation for 0068: {33.3k,180,msb}<1,-31|1,-47>(1:1,T:1,D:3,F:6,1,^138m)+
<br>RECS80 is a family of related protocols with the same structure, but different timing. See also
Velleman.
<br>These are moderately non robust protocols, so <A href="#spurious">spurious decodes</A> are possible.
<p>The timing differences are not definitive enough for DecodeIr to identify which RECS80
version is which. Instead it displays the timing information in the "Misc" field of the
output. That will be three numbers formatted as in this example: (157/5048/7572).</p>
<p>Using those three numbers and the frequency, you should be able to determine whether
the signals fit the 0045 version, the 0068 version, the 0090 version or none of them. You should look at all
the learned signals for your device together when doing that. A single device won't mix
versions of RECS80, so any differences in frequency or timing between learns is
due to the IR learning process, not due to any differences among the correct signals. You
should find one RECS80 version that is a good enough fit for all signals of the device.</p>
<p>For 0045,</p>
<ul>
<li>frequency should be between 37000 and 39000</li>
<li>first timing number between 100 and 200</li>
<li>second timing number between 4500 and 5500</li>
<li>third timing number between 6800 and 8300</li>
</ul>
<p>For 0068,</p>
<ul>
<li>frequency should be between 32300 and 34300</li>
<li>first timing number between 130 and 250</li>
<li>second timing number between 5100 and 6300</li>
<li>third timing number between 7700 and 9500</li>
</ul>
<p>For 0090,</p>
<ul>
<li>frequency should be 0</li>
<li>first timing number between 0 and 40</li>
<li>second timing number between 4500 and 5500</li>
<li>third timing number between 6800 and 8300</li>
</ul>
<H2><A name="Replay">Replay</A></H2>
UEI executor: 0092
<br>IRP notation: {36k,444,msb}<-1,1|1,-1>(6,-2,1:1,6:3,<-2,2|2,-2>(T:1),D:8,S:8,F:8,-100m)+
<br>Replay is a member of the RC6 family. Technically it is RC6-6-24, but DecodeIr will always
display the name as "Replay". ProntoEdit calls this protocol "RC6 mode 6A" RM has it under the alternate name "RC6-M-24n" as
well as its primary name "Replay".
<br>In ProntoEdit, DecodeIr's "Device" is called "Customer Code"; DecodeIr's "Subdevice" is called "System";
and DecodeIr's "OBC" is called "Command".
<H2><A name="Revox">Revox</A></H2>
UEI executor: 00A0
<br>IRP notation: {0k,15u}<1,-9|1,-19>(1:1,-10,0:1,D:4,F:6,1:1,-10,1:1,-100m)+
<br>Note that Revox uses no modulation. Programs which require a modulation frequency might work with f= 66.7KHz
<H2><A name="Samsung20">Samsung20</A></H2>
UEI executor: 002F <br>
IRP notation: {38.4k,564}<1,-1|1,-3>(8,-8,D:6,S:6,F:8,1,^???)+
<br>This is a moderately robust protocol, but <A href="#spurious">spurious decodes</A> are still possible.
<H2><A name="Samsung36">Samsung36</A></H2>
UEI executor: 01B5
<br>IRP notation: {38k,500}<1,-1|1,-3>(9,-9,D:8,S:8,1,-9,E:4,F:8,~F:8,1,-118)+
<H2><A name="Sampo">Sampo</A></H2>
IRP notation: {38.4k, 833}<1,-1|1,-3>(4,-4,D:6,F:6,S:6,~F:6,1,-39)+
<br>This is a moderately robust protocol, but <A href="#spurious">spurious decodes</A> are still possible.
<H2><A name="ScAtl-6">ScAtl-6</A></H2>
UEI executor: 0078
<br>IRP notation: {57.6k,846}<1,-1|1,-3>(4,-4,D:6,F:6,~D:6,~F:6,1,-40)+
<br>ScAtl-6 is distinguished from Emerson only by frequency. So if you are using
a learning system that doesn't record the frequency accurately, then DecodeIr
can't accurately select between Emerson and ScAtl-6.
<br>Most Scientific Atlanta cable tuners use Panasonic_Old
protocol, not this protocol.
<H2><A name="Sejin-M-38">Sejin-<i>M</i>-38 and Sejin-<i>M</i>-56</A></H2>
UEI executor: 0161
<br>
IRP notation for Sejin-<i>M</i>-38: {38.8k,310,msb}<-1|1>(<8:4|4:4|2:4|1:4>(3,3:2,Dx:8,Fx:8,Fy:8,E:4,C:4,-L))+
<br>
IRP notation for Sejin-<i>M</i>-56: {56.3k,310,msb}<-1|1>(<8:4|4:4|2:4|1:4>(3,3:2,Dx:8,Fx:8,Fy:8,E:4,C:4,-L))+
<br>
In both cases E is a checksum seed (0 in all known examples) and C is a checksum given by
<br>C = Dx:4 + Dx:4:4 + Fx:4 + Fx:4:4 + Fy:4 + Fy:4:4 + E.
<p>The parameter <i>M</i> is either 1 or 2. It distinguishes two styles of this protocol that have different purposes and very different lead-out times L. The 8-bit parameter Dx is a signed integer. If Dx > 0 then the style is Sejin-1, used for normal buttons of a remote control. If Dx < 0 then the style is Sejin-2, used for signals of an associated 2- or 3-button pointing device. E is a checksum seed, E=0 in the only known examples. The checksum formula reflects that in the UEI executor, so is
presumed correct.</p>
<p>The protocol parameters Dx, Fx, Fy translate into device parameters in different ways corresponding to the different uses of the protocol. In Sejin-1 the device parameters are a Device Code, a SubDevice code and an OBC as is common for many protocols. Sejin-2 has two sub-styles. One corresponds to the displacement of a cursor or other pointer with device parameters (X, Y) that
give the horizontal and vertical components of the displacement (and which can be positive or negative). The other signals Button Up or Button Down for any of the three buttons of the pointing device. The Misc field of the DecodeIR output displays these device parameters for the Sejin-2 signals. The relationship between these and the protocol parameters is beyond the
scope of this document. The Misc field also displays an RMOBC value for Sejin-2 signals, which is an artificial OBC value that can be used as input to RemoteMaster to create the signal concerned.</p>
<p>The protocol parameters for Sejin-1 include a bit that marks the end frame of a <A href="#repeat">repeat
sequence</A>. DecodeIR v2.37 and later check this and will report in the Misc field if the end frame is
missing. This will normally be due to the key still being held when the learning process ends, so that
the end frame gets omitted from the learned signal. For Sejin-2 signals that represent button operations
the signal does not repeat. A single frame is sent on button down, a different frame is sent once on
button up. Both frames can be detected and distinguished by DecodeIR v2.37 and later but the button up
frame will not normally be present in a learned signal.</p>
<H2><A name="Sharp">Sharp, Sharp{1} and Sharp{2}</A></H2>
IRP notation: {38k,264}<1,-3|1,-7>((D:5,F:8,1:2,1,-165,D:5,~F:8,2:2,1,-165)+,(D:5,F:8,1:2,1,-165))
<p>A Sharp signal, which is identical to Denon, has two halves, either one of which is
enough to fully decode the information. A significant fraction of Sharp 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 Sharp{1} or Sharp{2} depending on which half is decoded. Sharp,
Sharp{1} and Sharp{2} all represent the same protocol when they are correct.
But only Sharp is robust. A Sharp{1} or Sharp{2} decode might be <A href="#spurious">spurious</A>.</p>
<H2><A name="SharpDVD">SharpDVD</A></H2>
UEI executor: 00F8
<br>
IRP notation: {38k,400}<1,-1|1,-3>(8,-4,170:8,90:8,15:4,D:4,S:8,F:8,E:4,C:4,1,-48)+ {E=1,C=D^S:4:0^S:4:4^F:4:0^F:4:4^E:4}
<br>SharpDVD is the member of the Kaseikyo family with OEM_code1=170 and OEM_code2=90.
<H2><A name="SIM2">SIM2</A></H2>
IRP notation: {38.8k,400}<3,-3|3,-7>(6,-7,D:8,F:8,3,-60m) <br>
Nearly identical timing to G.I. RG, so either decode is likely.
<H2><A name="Solidtek16">Solidtek16</A></H2>
IRP notation: {38k}<-624,468|468,-624>(S=0,(1820,-590,0:1,D:4,F:7,S:1,C:4,1:1,-143m,S=1)3) {C= F:4:0 + F:3:4 + 8*S }
<br>
This is a KeyBoard protocol. The make/break bit is decoded into the subdevice field. Checksum is only known to be correct for D = 0