View previous topic :: View next topic |
Author |
Message |
3FG Expert
Joined: 19 May 2009 Posts: 3368
|
Posted: Wed Dec 22, 2010 12:11 am Post subject: Beta of DecodeIR.dll 2.42 |
|
|
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
Last edited by 3FG on Wed Aug 29, 2012 1:12 am; edited 1 time in total |
|
Back to top |
|
|
Capn Trips Expert
Joined: 03 Oct 2003 Posts: 3990
|
Posted: Wed Dec 22, 2010 7:09 am Post subject: |
|
|
Thanks for the monumental effort, 3, but the zip file includes everything you describe EXCEPT for DecodeIR.dll! _________________ Beginners - Read this thread first
READ BEFORE POSTING or your post will be DELETED!
Remotes: OFA XSight Touch, AR XSight Touch
TVs: LG 65" Smart LED TV; Samsung QN850BF Series - 8K UHD Neo QLED LCD TV
RCVR: Onkyo TX-SR875; Integra DTR 40.3
DVD/VCR: Pioneer DV-400VK (multi-region DVD), Sony BDP-S350 (Blu-ray), Toshiba HD-A3 (HD-DVD), Panasonic AG-W1 (Multi-system VCR);
Laserdisc: Pioneer CLD-D704.
Amazon Firestick
tape deck: Pioneer CT 1380WR (double cassette deck)
(But I still have to get up for my beer) |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Wed Dec 22, 2010 10:33 am Post subject: |
|
|
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? _________________ Graham |
|
Back to top |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3368
|
Posted: Wed Dec 22, 2010 11:33 am Post subject: |
|
|
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! |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Wed Dec 22, 2010 1:12 pm Post subject: |
|
|
Dave, I think you have started from the correct base. If it says
then it is the latest one from me. Before that, it said
Code: | #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(). _________________ Graham |
|
Back to top |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3368
|
Posted: Wed Dec 22, 2010 2:15 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3368
|
Posted: Wed Dec 22, 2010 11:11 pm Post subject: |
|
|
OK, now it is complete with the DLL...... |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Thu Dec 23, 2010 4:13 am Post subject: |
|
|
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. _________________ Graham |
|
Back to top |
|
|
alanrichey Expert
Joined: 24 Mar 2008 Posts: 3529 Location: UK/USA |
Posted: Sun Dec 26, 2010 9:11 am Post subject: |
|
|
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 !! |
|
Back to top |
|
|
vickyg2003 Site Admin
Joined: 20 Mar 2004 Posts: 7073 Location: Florida |
Posted: Fri Jul 22, 2011 8:04 pm Post subject: |
|
|
Dave, what are all those txt files for? _________________ Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
|
|
Back to top |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3368
|
Posted: Fri Jul 22, 2011 9:55 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
olli_h
Joined: 17 May 2005 Posts: 4
|
Posted: Fri Aug 05, 2011 5:13 pm Post subject: |
|
|
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: ... |
|
Back to top |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3368
|
Posted: Fri Aug 05, 2011 8:42 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
olli_h
Joined: 17 May 2005 Posts: 4
|
Posted: Sat Aug 06, 2011 9:35 am Post subject: |
|
|
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"... |
|
Back to top |
|
|
|