DecodeIR.DLL version 2.13
-------------------------------------------------------------------------

INSTALLATION:

Copy DecodeIR.DLL to the directory where you have the programs which use
it (such as IR.EXE, CCF2EFC.EXE, CML2EFC.EXE or IRTOOL.EXE)
or copy DecodeIR.DLL to a directory from which programs in multiple
directories can access a DLL (on my Windows XP system, \Windows\System
and \Windows\System32 are such directories).

-------------------------------------------------------------------------

USE:

Use the main program (IR or CCF2EFC, etc.) normally.  When that program
needs to decode an IR signal and is able to find DecodeIR.DLL, it will
use DecodeIR.DLL instead of its built in decoder.

Some protocol names will be followed by extra information in {}.  That
extra information should usually be ignored.  If you don't understand the
part in {} then definitely ignore it (unlike other parts of the system in
which ignoring the things you don't understand can mess up your results).

Several of the included decoders for individual protocols will
occasionally decode signals which are not really in that protocol.  The
ones with the biggest problems are "Gap", "Async" and "AirB".  If you
see these decodes in situations that don't make sense, and especially if
you see them when there is also a decode for another protocol that does
make sense, just ignore them.

Even after you ignore the garbage decodes described above, there are
often multiple correct decodes in one learned signal for one of three
reasons:

1) Multiple identical decodes normally means that the learning logic in
the device that captured the signal didn't fully understand the repeat
pattern of the signal and included more than one copy.  You should
ignore those extra decodes.

2) Multiple related decodes (which are common in Pioneer and some other
protocols) normally mean the device uses a compound signal which requires
more than one instance of that protocol's basic signal.  To reproduce
such signals (with a JP1 remote or MakeHex, etc.) requires including
the extra information in a protocol specific manner which is beyond the
scope of this ReadMe.  Look in the protocol specific part of the
documentation of the software you are using to reproduce the signals.

3) Multiple related or unrelated decodes might mean that the original
remote was sending a macro of some sort (for example an "all off" macro
to a group of devices).  If the decodes are related then it is often
impossible to distinguish this case from (2) simply by looking at the
decodes.  Then you should reproduce and test the individual signals to
see what each does alone.  That should tell you whether the whole
sequence was a macro of individual commands or a compound signal only
meaningful together.  If the decodes are unrelated then you need to
apply some common sense and context from other decodes of the same
OEM remote in order to determine whether it's a macro or whether the
extra decodes are garbage that should be ignored.

-------------------------------------------------------------------------

Individual protocols:

48-Nec1:  This is a 48 bit version of the Nec1 protocol.  The first two
parts of device information are reported as Device and Subdevice.  The
third part is reported as "E=" in the "Misc" column.  You need all three
parts to create an upgrade.  The EFC and Hex are consistent with the
protocol upgrade Jon and I created for the NEC-XG Projector.
This decoder may also report 48-Nec, 48-Nec2, or 48-Nec12 depending on
the repeat characteristics it sees.  The protocol I posted is only for
48-Nec1.  If you see 48-Nec, it is PROBABLY a learn of a very short
press of 48-Nec1.  If you see 48-Nec2, or 48-Nec12 ask Jon or me for
more help.

AirB:
Signals from an infrared keyboard.

Aiwa: {564}<1,-1|1,-3>(16,-8,D:8,S:5,~D:8,~S:5,F:8,~F:8,1,-42,(16,-8,1,-165)*)
This corresponds to KM's Aiwa protocol (UEI protocol 005E) and KM's Aiwa Combo
protocol (UEI protocol 009E).
The OBC value should be correct for both, but the EFC is lsb which is valid
only for 005E.  009E uses an lsb-comp hex command, so it is best to use OBC
mode in KM.
The "device code" used by KM V7.21 for Aiwa must be computed from the values
reported by this decoder using "device code" = SubDevice*256+Device
KM V7.21 for Aiwa-Combo uses "Parameter" on the setup sheet, which is the
SubDevice from this decoder, and uses "byte2" on the functions sheet, which is
Device from this decoder (allowing a different device for each function).
KM's Aiwa support may change in future release.

Archer:  {0k,12}<1,-3.3m|1,-4.7m>(F:5,1,-9.7m)+
Untested.

Async:
IR data stream structured to match an async serial data stream.

Blaupunkt: There is a {prefix} signal with no device or OBC and a {body} signal.
A perfect learn ought to show one of each.  Most learns seem to have one prefix
and two (identical) body frames.  The OBC values are intended to be consistent
with the published Grundig information and the EFC values with the Blaupunkt
protocol in KM.

Bose: {500,msb}<1,-1|1,-3>(2,-3,F:8,~F:8,1,-???)+
The decode is intended to be consistent with the posted KM and PB files:
<http://groups.yahoo.com/group/jp1/files/3. Device Codes/Audio/Bose-Wave-Radio-KM.txt>
<http://groups.yahoo.com/group/jp1/files/Protocol Builder Files/Bose_Wave_Radio-PB.txt>
There is no device number.  The OBC and EFC values should be consistent
with the above KM file.

Denon {38k,264}<1,-3|1,-7>(D:5,F:8,0:2,1,-165,D:5,~F:8,3:2,1,-165)+
UEI protocol 001C (and 009C)

DishPlayer_Network: {57.6k,400}<1,-7|1,-4>(1,-15,(F:-6,U:5,D:5,1,-15)+)
Unfortunately, this protocol varies from one model remote
to another.
The EFC in the decode is only for the oldest variant (the one in the urc7800 and 15-1994).
The bit sequence in the device field is changed in the decoder as of 8-Apr-04, and may
not yet have been changed in RM and KM.  But that only matters in the unlikely case that
the device number isn't zero.
The unit and OBC numbering is compatible across models here and in RM.  I'm not sure
whether KM is in sync with that.

Dishplayer: {38.4k,535,msb}<1,-5|1,-3>(1,-11,(F:6,U:5,D:2,1,-11)+)
UEI protocol 010F

Emerson {36.7k,872}<1,-1|1,-3>(4,-4,D:6,F:6,~D:6,~F:6,1,-39)+
UEI protocol 0065
Lists three different EFCs because the protocol is a mini combiner

F12: {410}<1,-3|3,-1>(D:3,C:1,F:8,^129)+

Fujitsu: {38k,400}<1,-1|1,-3>(8,-4,20:8,99:8,X:4,E:4,D:8,S:8,F:8,1,-110)+
Has the basic structure of a Kaseikyo signal (such as Panasonic or JVC-48) but
uses different check byte rules.

Gap-###-###-##: This is a decode from an incomplete decoder.  You should
ignore it.

G.I.4DTV: {37.3k,992}<1,-1|1,-3>(5,-2,F:6,D:2,C:4,1,-60)+
UEI protocol 00A4

G.I. Cable: {38.7k,490}<1,-4.5|1,-9>(18,-9,F:8,D:4,C:4,1,-84,(18,-4.5,1,-178)*){C=-(D+F:4+F:4:4)}
UEI protocol 00C4
 The OBC and EFC should be consistent with KM.  UEI protocol 00C4
only supports device 0, so if you get a decode with a
device other than zero, you can't reproduce it with a G.I. Cable upgrade
from KM.  If the special repeat portion is missing, it would be decoded
as "G.I. Cable{1}".  I haven't seen this happen and don't know whether
it would indicate a correct learn of a very short press, or a key that
sends only one frame, or a mislearn.


ID-000D: {38k,289}<1,-2.6|1,-6.3>(D:3,F:7,1,^25.3m)+
UEI protocol 000D
"Akai" in devices4.xls
Used in all the Harman/Kardon devices I've seen that aren't NEC.  Also in some
JVC, Makita and maybe Mitsubishi.

Jerrold: {0k,44}<1,-7.5m|1,-11.5m>(F:5,1,-23.5m)+
UEI protocol 0006

JVC: {38k,525}<1,-1|1,-3>(16,-8,(D:8,F:8,1,-45)+)
UEI protocol 0034
The device, OBC and EFC should be consistent with KM.  A JVC signal
has two parts.  The whole signal could be learned as one frame which would be
reported as JVC, but that almost never happens.  A good JVC learn typically
is two frames where the first is JVC and the second is JVC{2} and the device
and OBC are the same between the two.
If you get a decode of just JVC{2} without the matching JVC, it could be
a partial learn of a JVC signal (which might even work) or it could be a
misdecode of something else (though this new decoder will do that much
less than the old one does and I haven't seen that kind of misdecode yet).

JVC-48:  {37k,432}<1,-1,1,-3>(8,-4,3:8,1:8,D:8,S:8,F:8,(D^S^F):8,1,-173)+
This is the JVC protocol that uses the same structure as Panasonic protocol.  KM
calls it "Panasonic-JVC", but they're really both variants of the Kaseikyo
protocol, so calling the JVC one "Panasonic" was confusing.

Kaseikyo: {37k,432}<1,-1,1,-3>(8,-4,M:8,N:8,X:4,D:4,S:8,F:8,E:4,C:4,1,-173)+
Two numbers are reported with the protocol name.  Those, along with device and
subdevice, would be needed as fixed data for any JP1 protocol for Kaseikyo.
I'm not aware of whether such a protocol already exists.
This is my best guess at the "standard" form of the Kaseikyo protocol.  However,
we've so far found signals from only one manufacturer that follow this standard,
vs. Fujitsu, Panasonic and JVC-48 which have the same basic structure but
different check byte rules.  The reporting of "Kaseikyo" and "JVC-48" may be changed
in a later version if we discover more samples and figure out which form really is
the standard.

Mitsubishi:  {32.6k,300}<1,-3|1,-7>(D:8,F:8,1,-80)+
UEI protocol 0014
Device, OBC and EFC should all be consistent with KM.

NEC1 {38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,^108m,(16,-4,1,^108m)*)
NEC2 {38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,^108m)+
NECx1 {38.4k,564}<1,-1|1,-3>(8,-8,D:8,D:8,F:8,~F:8,1,^108m,(8,-8,D:1,1,^108m)*)
NECx2 {38.4k,564}<1,-1|1,-3>(8,-8,D:8,D:8,F:8,~F:8,1,^108m)+
UEI protocol 005A

Nokia: The device, subdevice, OBC and EFC should all be consistent with
the Nokia Quad protocol in KM.

Pace MSS: {38k,630,msb}<1,-7|1,-11>(1,-5,1,-5,T:1,D:1,F:8,1,^120m)+

Panasonic_Old {57.6k,833}<1,-1|1,-3>(4,-4,D:5,F:6,~D:5,~F:6,1,-???)+
UEI protocol 0000
Lists three different EFCs because this protocol is a mini combiner.

Panasonic: {37k,432}<1,-1,1,-3>(8,-4,2:8,32:8,D:8,S:8,F:8,(D^S^F):8,1,-173)+

PCTV: Untested.

pid_002A: {0k,20}<1,-4|1,-9>(1,-14, D:5, F:6, 1,-14,1, 129m)+
Used in some Barco devices and Oritron and Lenco Satellite Decoders.
For Oritron, the device number is XORed with 30 (decimal) after the first frame.
That behavior is indicated by the hex command odd in pid_002A.

Pioneer {40k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,-78)+
Be careful to look in each command for a second frame with a different command
and sometimes different device.  Many Pioneer commands consist of two different
frames.

Proton: {38k,500}<1,-1|1,-3>(16,-8,D:8,1,-8,F:8,1,^63m)+
UEI protocol 005C
I think UEI protocol 005D is the same thing, except 40khz.  If so, it would decode
as Proton.  So check the frequency when you get this decode.

RC5: Three different EFCs are listed for each OBC, assuming the usual
mini combiner for RC5 (UEI protocol 00E8).  I'm not sure how the EFCs work
for UEI protocol 0073, which also can produce RC5.  The misc column shows
the state of the toggle bit, which you normally can ignore.

RC5x: EFCs are not listed because I haven't yet checked how EFCs work in
UEI protocols 00F2 and 0073, which can produce RC5x.  The misc column shows
the state of the toggle bit, which you normally can ignore.

RC6: The device, OBC and EFC should be consistent with KM.  The misc column
shows the state of the toggle bit, which you normally can ignore.

RC6-6-20:  SAT_0847 and SAT_1175 are two setup codes using this variant
of RC6 protocol.  The device, subdevice and OBC reported are based on my
bad guess at the internal structure.  It needs to be improved.  A toggle
bit is present and is correctly reported in the misc column, but the UEI
protocol 0020 for these devices doesn't ever toggle the toggle bit, so
probably the actual device doesn't need it to toggle.

RCA: {58k,460,msb}<1,-2|1,-4>(40,-8,D:4,F:8,~D:4,~F:8,1,-15,(8,-8,D:4,F:8,~D:4,~F:8,1,-15)+)
UEI protocols 002D, 00AF and 0114
There are two very similar forms of RCA protocol.  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.
The one that KM calls RCA(Old) (UEI protocol 002D) will usually be decoded as
a frame of RCA{1} followed by a frame of RCA where the two frames have
identical device and OBC.
The one that KM calls RCA (UEI protocol 00AF) will usually be decoded as a
single frame of RCA.

RECS80:
UEI protocol 0045  {38k,158,msb}<1,-31|1,-47>(1:1,T:1,D:3,F:6,1,^122m)+
UEI protocol 0068  {33.3k,180,msb)<180,-5500|180,-8400>(1:1,T:1,D:3,F:6,1,^138m)+
Different devices seem to use RECS80 structure with different enough timing
that different protocols are required.  Two of those protocols are described
here, but that isn't enough to cover all examples of RECS80.
The "misc" column of decode data for RECS80 has three timing numbers that,
together with the frequency (reported elsewhere), should help you decide
which RECS80 protocol to use.
For 0045,
  frequency should be between 37000 and 39000
  first timing number between 100 and 200
  second timing number between 4500 and 5500
  third timing number between 6800 and 8300
For 0068,
  frequency should be between 32300 and 34300
  first timing number between 130 and 250
  second timing number between 5100 and 6300
  third timing number between 7700 and 9500
You may find decodes that don't quite fit either.  If it almost fits, it may
be worth testing to see if it works, but it's most unlikely to work if the
second timing number is above the suggested max or the third timing number
is below the suggested min.  For example, I found a decode with frequency
41879 and timing numbers (132,5092,7652).  The three timing numbers are
perfect for protocol 0045, but the frequency is quite wrong.  I have no
device to test with, but my guess is that it would work anyway.  For
protocol 0068, the third number 7652 is below the minimum of 7700 making
it quite unlikely to work.  I found a different device with frequency
33333 and timing (450,5770,8656).  For 0068 all but the first number are
perfect and I wouldn't be surprised if it worked.  For 0045 the second
number 5770 is too high for the max of 5500, so it's unlikely to work.
The decodes for RECS80 all report EFCs for protocol 0045.  These are not
correct EFCs if you select a protocol other than 0045.

Replay:  The device, subdevice (unit), OBC and EFC are intended to be
consistent with KM for OBC's up to 63.  A decoded OBC over 63 would represent
an actual value over 63 in the signal.  Rob told me that there is never a
value over 63 in the signal, and an OBC over 63 in KM means something else.
The misc column shows the state of the toggle bit, but none of the replay
remotes ever send a signal with the toggle bit non zero.

Samsung20: {38.4k,564}<1,-1|1,-3>(8,-8,D:6,S:6,F:8,1,^???)+
20-bit version of NECx2 seen in two Samsung devices

ScAtl-6: {57.6k,846}<1,-1|1,-3>(4,-4,D:6,F:6,~D:6,~F:6,1,-40)+
UEI protocol 0078

Sharp: {38k,264}<1,-3|1,-7>(D:5,F:8,1:2,1,-165,D:5,~F:8,2:2,1,-165)+
UEI protocol 001C

Sony8:  {40k,600}<1,-1|2,-1>(4,-1,F:8,^22200)
Sony12: {40k,600}<1,-1|2,-1>(4,-1,F:7,D:5,^45m)+
Sony15: {40k,600}<1,-1|2,-1>(4,-1,F:7,D:8,^45m)+
Sony20: {40k,600}<1,-1|2,-1>(4,-1,F:7,D:5,S:8,^45m)+

StreamZap:  I forget what the EFC is supposed to be compatible with and what
source I had for the decision of the boundary of device and OBC.  The misc
column shows the state of the toggle bit, which you normally can ignore.

Sunfire: (38k,560,msb)<1,-1|3,-1>(16,-8, D:4,F:8,~D:4,~F:8 -32)+

Thomson: {33k,500}<1,-4|1,-9>(D:4,T:1,D:1:5,F:6,1,^80m)+
UEI protocol 004B

Tivo-NEC:
Has the same timing as an NEC signal but has a unit number replacing part
of the check byte.

Viewstar: {50.5k,337}<1,-8|1,-5>(F:5,1,-17)+
UEI protocol 0021

Zenith:  I set "Device" to the number of bits, since there is no real Device
and that's how KM handles it.  I set "Subdevice" to the initial half bit, which
KM calls "Style".  The thing KM calls "Long Record" can't be deduced from the
learned signal.  The EFC matches the way KM does Zenith upgrades, but KM does
not do correct translations to and from OBC unless the number of bits is 7.
