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

DecodeIR 2.44
Goto page 1, 2, 3, 4  Next
 
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: 3246

PostPosted: Wed Aug 29, 2012 1:08 am    Post subject: DecodeIR 2.44 Reply with quote

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


Joined: 24 Oct 2008
Posts: 945

PostPosted: Wed Aug 29, 2012 3:46 pm    Post subject: Reply with quote

Wow. Looks promising. Cool

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


Joined: 24 Oct 2008
Posts: 945

PostPosted: Wed Aug 29, 2012 4:07 pm    Post subject: Reply with quote

One more thing:

Is there any reason for not keeping this stuff (the sources that is) in SVN?
Back to top
View user's profile Send private message Send e-mail Visit poster's website
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7053
Location: Florida

PostPosted: Sat Sep 29, 2012 4:50 am    Post subject: Reply with quote

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


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

PostPosted: Sat Sep 29, 2012 1:49 pm    Post subject: Reply with quote

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


Joined: 20 Mar 2004
Posts: 7053
Location: Florida

PostPosted: Sat Sep 29, 2012 3:56 pm    Post subject: Reply with quote

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


Joined: 19 May 2009
Posts: 3246

PostPosted: Sat Sep 29, 2012 4:05 pm    Post subject: Reply with quote

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


Joined: 20 Mar 2004
Posts: 7053
Location: Florida

PostPosted: Sat Sep 29, 2012 7:12 pm    Post subject: Reply with quote

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


Joined: 19 May 2009
Posts: 3246

PostPosted: Sat Sep 29, 2012 8:23 pm    Post subject: Reply with quote

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
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 18929
Location: Chicago, IL

PostPosted: Thu Oct 04, 2012 10:22 am    Post subject: Reply with quote

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


Joined: 19 May 2009
Posts: 3246

PostPosted: Thu Oct 04, 2012 10:57 am    Post subject: Reply with quote

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
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 18929
Location: Chicago, IL

PostPosted: Thu Oct 04, 2012 11:24 am    Post subject: Reply with quote

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


Joined: 03 Aug 2003
Posts: 3402
Location: Cary, NC

PostPosted: Sat Oct 06, 2012 2:46 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 18929
Location: Chicago, IL

PostPosted: Sat Oct 06, 2012 5:23 pm    Post subject: Reply with quote

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


Joined: 19 May 2009
Posts: 3246

PostPosted: Sat Oct 06, 2012 6:21 pm    Post subject: Reply with quote

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
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
Goto page 1, 2, 3, 4  Next
Page 1 of 4

 
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
Get Smart! the band's official homepage Rockabilly Central