|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
3FG Expert
Joined: 19 May 2009 Posts: 3367
|
Posted: Wed Aug 29, 2012 1:08 am Post subject: DecodeIR 2.44 |
|
|
I've posted the compiled version 2.44 DecodeIR.dll for Windows and the source code. I hope the usual suspects will compile Linux and Mac versions and post those so that I can incorporate all versions into a single distribution. Please include any needed revisions to the make files.
Additions/Revisons for 2.44:
* Added NEC-rnc (reverse nibble complement, which is primarily used by SlingCatcher)
* Revised decode of Nokia32 from X:8 to T:1, X:7 http://www.hifi-remote.com/forums/viewtopic.php?t=13487
* fixed most of the crashes mentioned here: http://www.hifi-remote.com/forums/viewtopic.php?p=99369#99369
* Fixed incorrect decodes of SharpDVD (thanks to Barf and shimura--see above link)
* Revised GI 4DTV to handle device (unit numbers 4-7) http://www.hifi-remote.com/forums/viewtopic.php?t=13631
* Revised Thomson 7 and Lumagen decoding algorithms to distinguish these very similar protocols
* Added GI RG protocol which is used in some Motorola cable boxes
* Renamed pid 002A to Barco
* Added Revox IR protocol and corrected mis-identification of it as pid002A
* Added Elan
* Added F32 (similar to F12 but 32 bits)
* Added Logitech and corrected mis-identification of it as Kathrein
* Added CanalSatLD, which is a variant of CanalSat
Last edited by 3FG on Thu Jan 22, 2015 1:19 am; edited 1 time in total |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1414 Location: Munich, Germany |
Posted: Wed Aug 29, 2012 3:46 pm Post subject: |
|
|
Wow. Looks promising.
I am not sure if I should feel myself addressed by "the usual suspects", but here is a 64 bit Linux version (compiled with gcc 4.6.2), here is a 32 bit version. Here is the makefile I used to create a 32 bit so on a 64 bit machine:
Code: | # This makefile unconditinally generates a 32 bit so, even if invoked on a 64 bit machine
NAME=DecodeIR
JAVA_INCLUDE=/usr/lib/jvm/java-6-sun/include
INCLUDES=-I$(JAVA_INCLUDE) -I$(JAVA_INCLUDE)/linux -Icom/hifiremote/decodeir
all: lib$(NAME).so
clean:
rm lib$(NAME).so
lib$(NAME).so: $(NAME).cpp
g++ -m32 -shared -fPIC -o $@ $(INCLUDES) $?
|
|
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1414 Location: Munich, Germany |
Posted: Wed Aug 29, 2012 4:07 pm Post subject: |
|
|
One more thing:
Is there any reason for not keeping this stuff (the sources that is) in SVN? |
|
Back to top |
|
|
vickyg2003 Site Admin
Joined: 20 Mar 2004 Posts: 7073 Location: Florida |
Posted: Sat Sep 29, 2012 4:50 am Post subject: |
|
|
It took me forever to find this version. Jetskier was using it, and I couldn't find it.
Now that I have, is there a protocols.ini file that goes with it?
I can't seem to find a protocols.ini file that has velleman.
I also am confused
I downloaded the RemoteMaster Beta 2.02 jar and there is a 10/3/2011 protocols.ini file.
In the file section there is
RM protocols.ini
Quote: | This is a link to the development version of protocols.ini, which may contain more protocols than the version packaged with RM. |
But that version is dated 11/14/2010.
I'm more than a little confused, since the development version appears to be a year older than the beta. |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Sat Sep 29, 2012 1:49 pm Post subject: |
|
|
Unfortunately protocols.ini has never had version numbers and various versions seem to be scattered in different places. I believe the latest version is that packaged with RMIR v2.02 Beta 1.5v. This consists of a version supplied to me by 3FG that had some additions of his and which he believed to be the latest, with my addition of MAXQ610 code for protocols where it is known. This is now the one posted in the SVN. Its predecessor in the SVN was the one included in the original RMIR v2.02 Beta. The SVN needs to have the latest one, as that is the one that will get packaged with the next official release of RMIR.
If there is a version with protocols not included in this one then I should like to know, as this is the only one with MAXQ code and we need it to be up to date. _________________ Graham |
|
Back to top |
|
|
vickyg2003 Site Admin
Joined: 20 Mar 2004 Posts: 7073 Location: Florida |
Posted: Sat Sep 29, 2012 3:56 pm Post subject: |
|
|
mathdon wrote: | Unfortunately protocols.ini has never had version numbers and various versions seem to be scattered in different places. I believe the latest version is that packaged with RMIR v2.02 Beta 1.5v. This consists of a version supplied to me by 3FG that had some additions of his and which he believed to be the latest, with my addition of MAXQ610 code for protocols where it is known.
|
Thanks Graham.
Quote: |
If there is a version with protocols not included in this one then I should like to know, as this is the only one with MAXQ code and we need it to be up to date. |
There are some slingbox versions of various protocols, particularly the non-repeating Nec, that are not in any of the protocol.ini's. That particular code causes me all sorts of problems, because lots of times AlanRichies Slingbox RDMUs are the ONLY source for devices. When you try to open them in RM, you get an unknown protocol version. These don't open, (but at least the latest and greatest RMIR no longer hangs when you try to open one of these- Thank-you Graham) Of course there is a way around this, you just hunt down one of Alan's Bins and import it to get the data, and then because you know that 005a is a NEC, you simply open the Nec. I don't think you even need to fiddle around with the LSB-Comp settings because I think it identifies it as a Custom Code with the tranlsatiors in place. Its no biggy, but if that protocol was included in protocols.ini it would save me a lot of time and make things smoother for a novice since Nec seems to be one of the most common protocols. |
|
Back to top |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3367
|
Posted: Sat Sep 29, 2012 4:05 pm Post subject: |
|
|
Adding to Graham's comments--
The version of protocols.ini included with Beta 1.5v refers to two new Java classes, and consequently it won't load correctly into older versions of RMIR.
Velleman is a maker of electronic kits and modules, many of which can be controlled by IR, using a protocol that Velleman refer to as "modified RECS80 / 38KHz carrier". I've included it in DecodeIR because seemingly a lot of electronic hobbyists use it, although there has only been a couple of threads about it on this forum. I did not make an entry into protocols.ini because I'm not aware of a UEI executor for it, and thus there is the question of what PID to assign to it.
Note that in the current situation with jetskier and his IR rpeater, the signals he has learned are not really either RECS80 or Velleman. |
|
Back to top |
|
|
vickyg2003 Site Admin
Joined: 20 Mar 2004 Posts: 7073 Location: Florida |
Posted: Sat Sep 29, 2012 7:12 pm Post subject: |
|
|
Thanks 3FG
3FG wrote: | Note that in the current situation with jetskier and his IR rpeater, the signals he has learned are not really either RECS80 or Velleman. |
I see now where there is a link to the thread.
I just wanted to see what he was trying to send. I was under the impression that he tried a Velleman upgrade that didn't work, and I always like to see WHY it didn't. For example mdavej's recent problem with Orteck MCE, being an RDF problem.
Speeking of the RECS80, though I was wondering about the T=2 meant in the decode, with T:1 in the IRP. Following jetskiers earlier thread, it looked like the (1:1, T:1 ) in the IRP really was supposed to be T:2, but it isn't shown that way in the DecodeIR.HTML. Now that I can read simple IRP, I rely on the HTML and was kind of confused. |
|
Back to top |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3367
|
Posted: Sat Sep 29, 2012 8:23 pm Post subject: |
|
|
I don't know why, but DecodeIR reports the first two bits as the toggle. I speculate that the RECS80 decoding algorithm was done before we knew for sure that the first bit is always 1, and John Fine wanted to check if it might sometimes be zero. Anyway, T=2 really means T=0.
BTW, I kept that same algorithm for Velleman, but I plan to change it to just report the single toggle bit. |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21234 Location: Chicago, IL |
Posted: Thu Oct 04, 2012 10:22 am Post subject: |
|
|
This thread refers to the "Humax 4Phase" protocol, which was added new in version 2.44 of DecodeIR but I don't find it mentioned in any of the release notes or change log. I also did a search in the forum and couldn't find any references to it, so, what can you tell me about this protocol? _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3367
|
Posted: Thu Oct 04, 2012 10:57 am Post subject: |
|
|
Looks like I forgot to mention it in the release notes. It is supported for S3F80 in the latest protocols.in in RMIR 2.02 Beta 1.5v. You do need that version of RMIR, because protocols.ini refers to a new class called BitExpander. |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21234 Location: Chicago, IL |
Posted: Thu Oct 04, 2012 11:24 am Post subject: |
|
|
I have all those versions and I can see the protocol there, however it doesn't appear that any attempt was made to allow the user to enter the device codes and OBCs in their natural format.
I'm not good at writing code for protocols.ini so I'll decribe here how you convert an OBC into UEI hex.
1. Convert the OBC to 7-bit binary
2. Add a checksum bit which is the complement of the LSB of the OBC
3. To convert the resulting binary into the binary required for the executor, you need to look at the binary 2-bits at a time. Here's the conversion chart:
00 = 0011
01 = 0001
10 = 1000
11 = 1100
So, let's walk thru an example. The POWER button has an OBC of 11.
1. The 7-bit binary for 11 is 0001011
2. The LSB is 1, so the checksum is 0, giving 00010110
3. Split into 2-bit chunks: 00-01-01-10
00=0011
01=0001
01=0001
10=1000
So the new binary is 00110001 00011000, which is "31 18" in hex.
It doesn't appear that there's a checksum in the 2 device codes, so the fixed data "C3 1C 83 33" should resolve to device code 199 and sub-device 128.
I just found an original file of learns and see that the device codes decode as 15.0 but I'm confused how we got those values. When I convert "C3 1C" to binary, using the chart shown above, I get 11000111 which is decimal 199. Likewise for "83 33", I get 10000000 which is 128. _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Last edited by The Robman on Sat Oct 06, 2012 7:45 pm; edited 1 time in total |
|
Back to top |
|
|
gfb107 Expert
Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC |
Posted: Sat Oct 06, 2012 2:46 pm Post subject: |
|
|
Graham has asked me to make an official, complete release of RMIR v2.02, and we'd like to include DecodeIR 2.44. However, as far as I can tell no one has built the libraries for Mac. Is there someone that can do that?
If not, I don't know which of the following would be better:
- Release with DecodeIR 2.44 for Windows and Linux only, no DecodeIR support for Mac
- Release with DecodeIR 2.44 for Windows and Linux and Decode IR 2.43 for Mac
- Release with Decode IR 2.43 for all platforms
_________________ -- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST) |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21234 Location: Chicago, IL |
Posted: Sat Oct 06, 2012 5:23 pm Post subject: |
|
|
In the event that it's not immediately possible to create a Mac version of DecodeIR 2.44, I would vote for option #2. _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3367
|
Posted: Sat Oct 06, 2012 6:21 pm Post subject: |
|
|
Rob,
I've messed this up in just about every possible way.
1) The entry that I've put into protocols.ini is an old version intended to work with a previous version of BitExpander.
2) I've lost the correct protocols.ini fragment for Humax 4Phase to correspond to the distributed new version of BitExpander. Of course I can reconstruct this, but--
3) I also used an IRP form in DecodeIR which isn't compatible with RMIR. D:7,S:5 (each is an odd number of base 2 bits) can't be converted to base 4 descriptions of the device and subdevice, prior to expanding the bits.
So I think I need to revise DecodeIR to D:6, S:6 (with apologies to Barf, who has already compiled 2.44 for Linux), and I also need to revise the protocols.ini entry to match. It will take me a day or two.
I would appreciate any comments on this plan to issue DecodeIR 2.44b.
BTW, as you figured out some months ago, and I think you still know, the natural OBC for Power Toggle is 11, not 22. 22 includes the check bit, and your description of converting to bits does take that into account. |
|
Back to top |
|
|
|
|
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
|