Page 1 of 2
DecodeIR 2.43 is Released
Posted: Thu Sep 29, 2011 10:21 pm
by 3FG
Here is the
release version of DecodeIR version 2.43, with support for Windows, Linux, and newer Macs.
The previous released version was 2.41, and it can be found
here. Version 2.42 was released as a beta only.
Version 2.43 includes these changes from 2.41:
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 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.
Added Velodyne, Metz19, Velleman, Apple, and SIM2 protocols.
Added additional prioritized criteria to distinguish Amino from Zaptor, and corrected the Amino checksum calculation.
My thanks to Greg Bush for compiling under Linux, and alex750 and MikeT for compiling under Mac OSX
Posted: Fri Sep 30, 2011 12:42 am
by vickyg2003
Dave that's a pretty frightening looking zip file. What are all those files for? Decode 2.41v2 only had about 14 files in it, this one has 50 something.
For example what is jar.exe?
Posted: Fri Sep 30, 2011 8:33 am
by gfb107
I'll add NibbleSumChk to RMIR, so you won't have to include any of that in your zip file.
I'll also update RMIR's protocols.ini
I'd like to request that your zip be consistent in where the binaries are placed for all platforms.
Currently you have:
- Linux-amd64
- Linux-i386
- Mac
- Mac OS X-i386
- Mac OS X-X86_64
- Windows
I'd like to see the
Mac folder removed, like this:
- Linux-amd64
- Linux-i386
- Mac OS X-i386
- Mac OS X-X86_64
- Windows
This is consistent with the runtime folder structure RMIR uses, and works well with my process for building my zip file, which takes binaries directly out of the distribution zip files of the libraries RMIR needs (DecodeIR and the various interface drivers).
The other files in the Mac folder also exist in other folders, except Makefile.Lion, which should probably be moved into the Source folder along with the other makefiles.
Thanks.
Posted: Fri Sep 30, 2011 9:06 am
by vickyg2003
Shouldn't the IRP files be bundled in with makehex, the way the other irp files are? It makes it real confusing to have the .irp files in with decodeir.
I woundn't think most people have any use for makehex/and irp files.
Posted: Fri Sep 30, 2011 10:17 pm
by 3FG
OK,
I've made the modifications to the directory structure for the Mac files. Also stripped out the source code, and two (huge) RM.jar files that I included by mistake.
I'm glad to hear that NibbleSumChk and protocols.ini will be included in the next release of RMIR. It doesn't change the immediate need to include them in the present release of DecodeIR (since RMIR isn't released yet), and once RMIR is released, an RMIR user won't need to download the DecodeIR2.43 distribution-- the necessary files will be included in RMIR.
Vicky,
DecodeIR is used outside the JP1 community with IRTool and IRScope, and one or two other programs that we JP1ers don't think about. I can't modify the MakeHex distribution, and we're already in the situation that a Pronto Hex user should download both MakeHex and mdavej's very nice GUI for it besides DecodeIR.dll. I don't want to require a MakeHex user to download a third package containing new irp files, yet for most people a decoded IR signal is really only useful if they have a way to reproduce or distribute it..
Posted: Sat Oct 01, 2011 1:53 pm
by vickyg2003
3FG wrote:
Vicky,
DecodeIR is used outside the JP1 community with IRTool and IRScope, and one or two other programs that we JP1ers don't think about. I can't modify the MakeHex distribution, and we're already in the situation that a Pronto Hex user should download both MakeHex and mdavej's very nice GUI for it besides DecodeIR.dll. I don't want to require a MakeHex user to download a third package containing new irp files, yet for most people a decoded IR signal is really only useful if they have a way to reproduce or distribute it..
Yes, I know that there are all sorts of places DecodeIR.DLL are used. Did you ask John if he'd update makehex with your IRP? I could update the zip file and move the current one to the archive tools, but I'd rather have John update his file. It makes sense to have the IRP's all together.
Posted: Sun Oct 02, 2011 10:31 am
by mathdon
Could I suggest that this thread be turned into an announcement and that a link to the announcement of v2.41 be added in its first post. The annoucement status of the thread for v2.41 can then be removed. That thread in turn has a link to v2.40 in its first post and this adds another link to the chain, making the latest version be the most prominent one.
Posted: Sun Oct 02, 2011 2:03 pm
by 3FG
Yes, I also think it should be an announcement. I did include a link to the announcement of 2.41; do you think it should be more pronounced? Personally, I think the link to the previous version should be less obvious than the link ot the new version.
Posted: Sun Oct 02, 2011 2:07 pm
by Barf
First of all, thanx to 3FG for doing this hard job.
Secondly, I would strongly suggest migrating from the old IRP-Notation (irp-files) and Makehex to the current IRP-notation and
IrpMaster. Having different language for communicating with humans (new IRP) and machines (old IRP) is clearly suboptimal. IrpMaster is also a much better program than Makehex!
Posted: Tue Oct 04, 2011 5:17 am
by mathdon
3FG wrote:Yes, I also think it should be an announcement. I did include a link to the announcement of 2.41; do you think it should be more pronounced? Personally, I think the link to the previous version should be less obvious than the link ot the new version.
Thanks for making the announcement changes. Without checking, I took the link to v2.41 to be to the zip file, not to the announcement. Sorry, I should have checked. No need to make it more prominent.
Crash
Posted: Tue Oct 04, 2011 12:19 pm
by Barf
DecodeIR 2.43 crashes with a zero pointer dereference on the signal rc5x D=31 S=0 F=0 T=1
Code: Select all
0000 0073 0000 0014 0020 0020 0020 0020 0020 0020 0020 0020 0020 0020 0020 0020 0020 0020 0020 0080 0020 0020 0020 0020 0020 0020 0020 0020 0020 0020 0020 0020 0020 0020 0020 0020 0020 0020 0020 0020 0020 0020 0020 0AC8
(actually anything for S and F. Tested on Linux/IrpMaster as well as Windows7/IRScope.
Also zenith 6 1 0 leads to crash.
Code: Select all
0000 0068 0000 0014 0015 0015 0015 00A6 0015 00D0 0015 0015 0015 00A6 0015 00D0 0015 0015 0015 00A6 0015 00D0 0015 0015 0015 00A6 0015 00D0 0015 0015 0015 00A6 0015 00D0 0015 0015 0015 00A6 0015 00D0 0015 0015 0015 0EB6
Posted: Wed Oct 05, 2011 9:57 pm
by 3FG
I'll try to fix this in the next release.
Posted: Sun Oct 30, 2011 4:03 am
by Barf
As far as I am aware of, DecodeIR presently comes without any license or copyright messages in any way. In most countries (again, as far as I know) this legally means that the recipient is not granted any rights at all, neither to use or anything else... This is clearly not the intent of its authors and maintainers, who effectively makes the library including source free for everyone to use, study, and improve.
I have published software that uses DecodeIR. What if, if someone sues me for copyright infringement? There are enough examples of weird court cases...
I do not want to start a discussion in these issues, just suggest that a suitable license, e.g.
GPL3 or 2, be used, like most other software in this project. Of course, also other alternatives are possible.
SharpDVD
Posted: Mon Aug 20, 2012 8:07 am
by shimura
DecodeIR 2.43 decode wrong code with SharpDVD (misc E).
E value is lower 4 bits of cBits[5] isn't it?
So I correct the source,
line 2549 "int x5 = cBits[5]>>4;" to "int x5 = cBits[5] & 15;"
Is it right?
Posted: Mon Aug 20, 2012 11:17 am
by Barf
Using IrpMaster, I tried all the E's from 0 to 15, for device=12, subdevice=34, obc=56 (randomly selected)
Code: Select all
$ irpmaster --decodeir sharpdvd E='*' 12 34 56
libraryFolder=/home/bengt/harc/IrpMaster/Linux-amd64
Loading /home/bengt/harc/IrpMaster/Linux-amd64/libDecodeIR.so
Loaded /home/bengt/harc/IrpMaster/Linux-amd64/libDecodeIR.so
DecodeIR result: success
DecodeIR result: protocol = SharpDVD, device = 12, subdevice = 34, obc = 56, misc = E=6
DecodeIR result: protocol = SharpDVD, device = 12, subdevice = 34, obc = 56, misc = E=5
DecodeIR result: protocol = SharpDVD, device = 12, subdevice = 34, obc = 56, misc = E=4
DecodeIR result: protocol = SharpDVD, device = 12, subdevice = 34, obc = 56, misc = E=3
DecodeIR result: protocol = SharpDVD, device = 12, subdevice = 34, obc = 56, misc = E=2
DecodeIR result: protocol = SharpDVD, device = 12, subdevice = 34, obc = 56, misc = E=1
DecodeIR result: protocol = SharpDVD, device = 12, subdevice = 34, obc = 56
DecodeIR result: protocol = SharpDVD, device = 12, subdevice = 34, obc = 56, misc = E=15
DecodeIR result: protocol = SharpDVD, device = 12, subdevice = 34, obc = 56, misc = E=14
DecodeIR result: protocol = SharpDVD, device = 12, subdevice = 34, obc = 56, misc = E=13
DecodeIR result: protocol = SharpDVD, device = 12, subdevice = 34, obc = 56, misc = E=12
DecodeIR result: protocol = SharpDVD, device = 12, subdevice = 34, obc = 56, misc = E=11
DecodeIR result: protocol = SharpDVD, device = 12, subdevice = 34, obc = 56, misc = E=10
DecodeIR result: protocol = SharpDVD, device = 12, subdevice = 34, obc = 56, misc = E=9
DecodeIR result: protocol = SharpDVD, device = 12, subdevice = 34, obc = 56, misc = E=8
so the decodes are definitely wrong for E != 0. I also verified the suggested solution, and it works.
Thanx shimura.