Beta of DecodeIR.dll 2.42

3FG · Post by **3FG** » Tue Dec 21, 2010 11:11 pm

Here's a Beta of DecodeIR.dll version 2.42. It is intended to address the following:

Decodes NEC signals for which the 4th byte of the data is not the complement of the 3rd. Yamaha "Gap" signals are variously decoded as the -y1, -y2, or -y3 style, while the suffix -f16 indicates a NEC-like signal with no relationship between values of the 3rd and 4th bytes. The Y styles can be used with the NEC 4DEV Yamaha Combo executor. I don't believe that we currently have an executor which will send f16 style signals.

Decodes NEC1-like signals which have a longer than usual duration of the on pulse in the leadout as NEC1.

Decodes NEC-like signals with truncated leadout as NEC.

The names RC5-7F and RC5-7F-57 replace StreamZap, StreamZap-57, and EchoStar. This new decoding assigns 6 bits to device numbers and 7 bits to OBCs, so device numbers can range from 0 to 63, and OBCs can be up to 127. RC5-7F and the 57KHz style can be entered into RM using the RC5-7F executor (PID 01 82). An IRP file is included in the distribution.

Kaseikyo IR signals with OEM 170.90 are decoded as SharpDVD.

Thomson IR signals are decoded as Thomson7. Devices can be 0-15 and OBCs from 0 to 127. An IRP file is included in the distribution. I've added a Thomson7 entry in protocols.ini.

Zaptor/Amino. Zaptor has been distinguished from Amino by checking if the frequency is 46Khz or less. I've followed Rob's suggestion and decode as Amino if freq > 46Khz or the high nibble in the checksum byte is 0xF. This feature is untested on a low frequency signal.

Some comments:
See DecodeIR update requests for the motivation behind some of the changes.

In the distribution, I have included a version of protocols.ini with a variety of changes, most of which are intended to facilitate use of the RC5-7F, SharpDVD, and Thomson7 decodes. The entries are also split into separate files.

The SharpDVD entry in protocols.ini needed significant enhancements--the entry for variant 2 was wrong, and there was no entry for Variant 3 at all. The majority of UEI remotes carry Variant 3, and upgrades for those remotes have required a redundant protocol executor upgrade. Ironic, since part of the reason Capn Trips has wanted this signal decoded as SharpDVD was to avoid wasting space with a needless protocol executor upgrade.

Thomson is a mess. We've been using a decoding assignment that purports to give 6 bits of device and 6 bits of OBC. Actually only device numbers 0-15 and 32-47 had meaning-- the other bit gets toggled in the executor. UEI has apparently used a similar 6-6 illusory split (example fixed data: 0xF4) , also a 5-6 split (0x58), and mostly a 4-6 split (0xF0). The 4-6 split however retains 5 bit device numbers, according to the Lookup Tool. The whole situation either calls for a new name (like Thomson7) or some way of distinguishing amongst the various schemes.

DecodeIR 2.42 Beta

Capn Trips · Post by **Capn Trips** » Wed Dec 22, 2010 6:09 am

Thanks for the monumental effort, 3, but the zip file includes everything you describe EXCEPT for DecodeIR.dll!

Post by **mathdon** » Wed Dec 22, 2010 9:33 am

3FG wrote:Zaptor/Amino. Zaptor has been distinguished from Amino by checking if the frequency is 46Khz or less. I've followed Rob's suggestion and decode as Amino if freq > 46Khz or the high nibble in the checksum byte is 0xF. This feature is untested on a low frequency signal.

Zaptor was already in v2.41, see this announcement, and distinguished in this way. Did you miss that?

3FG · Post by **3FG** » Wed Dec 22, 2010 10:33 am

Well, that's embarrasing.... leaving out the DLL itself. Perhaps it is just as well, since mathdon's post suggests that (in spite of his earlier entreaty to make sure) that I have started from the incorrect code base. So I'll compare the various codes tonight and then try to make a useful upload!

Post by **mathdon** » Wed Dec 22, 2010 12:12 pm

Dave, I think you have started from the correct base. If it says

Code: Select all

#include "JNI.h"

then it is the latest one from me. Before that, it said

Code: Select all

#include "JNIUtil.h"

which was how I inherited it from John Fine. Finding JNIUtil.h was a real pain, but it turned out that it was entirely irrelevant, the standard JNI.h has all that is required. I never got round to changing it till the latest posting of the source code. You have probably just missed it. Amino and Zaptor are decoded by tryCanalSat().

3FG · Post by **3FG** » Wed Dec 22, 2010 1:15 pm

Graham,
No, I saw the Zaptor/Amino routines in tryCanalSat. However, Rob thinks that signals which have a frequency <46KHz but which also have a high nibble in the checksum byte equal to 0xF should be decoded as Amino. I think 2.41 will decode signals < 46KHz as Zaptor even if the high nibble is 0xF, and I have tried to change that behavior.

3FG · Post by **3FG** » Wed Dec 22, 2010 10:11 pm

OK, now it is complete with the DLL......

Post by **mathdon** » Thu Dec 23, 2010 3:13 am

3FG wrote:Graham,
No, I saw the Zaptor/Amino routines in tryCanalSat. However, Rob thinks that signals which have a frequency <46KHz but which also have a high nibble in the checksum byte equal to 0xF should be decoded as Amino. I think 2.41 will decode signals < 46KHz as Zaptor even if the high nibble is 0xF, and I have tried to change that behavior.

Sorry, Dave. Many apologies.

I misunderstood the issue. I read it as if you had added Zaptor as a new decode, rather than modifying the existing one. I did to you what I hate when others do it to me - read it hurriedly and miss the most significant part.

alanrichey · Post by **alanrichey** » Sun Dec 26, 2010 8:11 am

Just to let you know that we have had our first success with a Thomson box over at the Slingbox forum, using 2.42 and the 'Thomson7' protocol in PROTOCOLS.INI.

So well done, you appear to have cracked that one at long last !!

Cheers

Al

PS, hope everyone here had a good Xmas day !!

Post by **vickyg2003** » Fri Jul 22, 2011 7:04 pm

Dave, what are all those txt files for?

3FG · Post by **3FG** » Fri Jul 22, 2011 8:55 pm

You mean in the protocol_ini folder? There is a version of protocol.ini which handles the new or revised protocols. The text files are just the individual pieces that go into making up the changes in protocols.ini.

olli_h · Post by **olli_h** » Fri Aug 05, 2011 4:13 pm

Decoding a NEC1-f16 style pronto hex code in IRTool using 2.42BETA the output is missing the OBC and returning device 3 instead.

Example:

0000 006c 0022 0002 0156 00ac 0015 0016 0015 0041 0015 0016 0015 0016 0015 0041 0015 0016 0015 0041 0015 0041 0015 0016 0015 0041 0015 0041 0015 0041 0015 0041 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0041 0015 0016 0015 0041 0015 0016 0015 0016 0015 0016 0015 0041 0015 0016 0015 0041 0015 0016 0015 0016 0015 0041 0020 066F 0156 0056 0020 0E54

results in

Protocol: NEC1-f16
Device: 210.30
OBC: 80
EFC: 75

but correct would be something like

Protocol: NEC1-f16
Device: 210.30.80
OBC: 148
EFC: ...

3FG · Post by **3FG** » Fri Aug 05, 2011 7:42 pm

There's a couple of things to consider here. Just as background, DecodeIR was designed quite a long time ago, and the interface to other programs is pretty much set in stone. It allows the description of device, subdevice, and OBC. Over time, some additional output--strings rather than integers--has been added. IRTool is really old, and does not know about the enhancements to DecodeIR.

So at the present time, I recommend that you use either IRScope (the Import button in the upper right corner) or IR.exe (Learned Signals tab, Add button) to decode Pronto Hex signals. IRScope provides the most information in cases where the IR signal has more than one frame type, and is IMO easier to use for Pronto imports. It needs less effort to install, also.

You mention "device 3". For the particular Pronto hex example above, which controls the Main zone of newer Onkyo receivers, it is tempting to regard the 3rd byte of the 4 byte signal as a device. The division between device, subdevice, and function numbers (OBCs) is somewhat arbitrary, but within the context of our tools, I think it is better to regard the 3rd byte as the first byte of the OBC information. For Onkyo receivers, for example, the 3rd byte can take on values (decimal) 5, 13, 21, 29, 80, 83, 84, and 85. I probably missed some.

Regardless, DecodeIR isn't capable of providing device, subdevice, and device3 as integer outputs. It handles this and many other situations by outputting a text string labeled "Misc". In IR and IRScope the above signal is shown as D2.1E.50.94. Perhaps it should instead show 80.148, since 208.30 is already shown in device.subdevice.

olli_h · Post by **olli_h** » Sat Aug 06, 2011 8:35 am

Thanks for explaining this.

The naming "device 3" is from the custom protocol Vicky created for NEC1-f16, see details here.

As a reference, the byte "grouping" used in the original spreadsheet for the onkyo ir commands:

NEC1: D26C D2 (HDMI SELECT)
NEC1-f16: D21E 50 94 (HDMI BOTH)

From this I think you are correct considering the 3rd byte part of the OBC, but as all 4 byte commands start with D21E 50 I can see why Vicky named it "device 3"...