JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

Beta of DecodeIR.dll 2.42

 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Software
View previous topic :: View next topic  
Author Message
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Wed Dec 22, 2010 12:11 am    Post subject: Beta of DecodeIR.dll 2.42 Reply with quote

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
View user's profile Send private message
Capn Trips
Expert


Joined: 03 Oct 2003
Posts: 3990

                    
PostPosted: Wed Dec 22, 2010 7:09 am    Post subject: Reply with quote

Thanks for the monumental effort, 3, but the zip file includes everything you describe EXCEPT for DecodeIR.dll! Surprised
_________________
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
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Wed Dec 22, 2010 10:33 am    Post subject: Reply with quote

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
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Wed Dec 22, 2010 11:33 am    Post subject: Reply with quote

Embarassed Embarassed Embarassed
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
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Wed Dec 22, 2010 1:12 pm    Post subject: Reply with quote

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

Code:
#include "JNI.h"

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
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Wed Dec 22, 2010 2:15 pm    Post subject: Reply with quote

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
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Wed Dec 22, 2010 11:11 pm    Post subject: Reply with quote

OK, now it is complete with the DLL......
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Thu Dec 23, 2010 4:13 am    Post subject: Reply with quote

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. Embarassed 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
View user's profile Send private message
alanrichey
Expert


Joined: 24 Mar 2008
Posts: 3529
Location: UK/USA

                    
PostPosted: Sun Dec 26, 2010 9:11 am    Post subject: Reply with quote

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
View user's profile Send private message
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7073
Location: Florida

                    
PostPosted: Fri Jul 22, 2011 8:04 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Fri Jul 22, 2011 9:55 pm    Post subject: Reply with quote

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
View user's profile Send private message
olli_h



Joined: 17 May 2005
Posts: 4

                    
PostPosted: Fri Aug 05, 2011 5:13 pm    Post subject: Reply with quote

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
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Fri Aug 05, 2011 8:42 pm    Post subject: Reply with quote

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
View user's profile Send private message
olli_h



Joined: 17 May 2005
Posts: 4

                    
PostPosted: Sat Aug 06, 2011 9:35 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Software All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control