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 Previous  1, 2, 3, 4
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Software
View previous topic :: View next topic  
Author Message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Thu Nov 01, 2012 5:46 am    Post subject: Reply with quote

3FG wrote:
The newly posted DecodeIR 2.44 v5 decodes all combinations of Humax 4Phase signals with no false decodes. It tightens up the decoding requirements for Nokia12 and Sony8 in order to avoid these false decodes.


I have tested, thus verified this statement. Even the need to call decode() an extra time has been fixed. Congratulations! Very Happy

Quote:
... I've decided to disable the Async decoder. We have dozens of posts describing false Async decodes, and none (I even checked learns in the Yahoo file section) that are legitimate decodes.


This is probably a wise, pragmatic, decision.

I have uploaded current versions of the Linux libraries. Really hoping someone will upload a windows 64-bit version.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Thu Nov 01, 2012 10:53 am    Post subject: Reply with quote

Thanks for testing. I haven't done anything which was intended to deal with needing to call decode() twice. DecodeIR uses somewhat complicated logic to handle protocols with start and/or end frames, and the need to call twice may result if a two part IR signal is recognized for the first part but not for the second.

Don't shoot the messenger, but regarding 64 bit Windows, the current recommendation from Oracle is: "we recommend using the default 32-bit browser and downloading 32-bit Java". Apparently the 64 bit version of Internet Explorer and some other browsers work poorly with 64 bit Java.

I ran across this because I checked DecodeIR at work on a 64 bit OS and processor, and it worked fine because the computer was set up to use 32 bit Java. So I asked why 32 bit Java and got an earful! 64 bit Java (I'm told) doesn't handle updates to new versions correctly either. I was also told that it increases the memory needed by the process and runs more slowly.

Of course it will be nice if someone (I don't have the capability) can compile a 64 bit version of the dll, but maybe using 32 bit Java is something of a universal workaround at the present time.
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Sat Nov 03, 2012 3:43 am    Post subject: Reply with quote

3FG wrote:
Thanks for testing. I haven't done anything which was intended to deal with needing to call decode() twice. DecodeIR uses somewhat complicated logic to handle protocols with start and/or end frames, and the need to call twice may result if a two part IR signal is recognized for the first part but not for the second.


Some of the try*-functions set an internal flag (function local, "static") and expect to reset it in a subsequent call, if successful. So, what happens in the subsequent call does not happen, or is not successful? The internal flag remains in a non-virgin state. This holds even if the decoder starts working on a new signal. There is no way to reset the internal memory, except for the successful subsequent call. The function initDecoder() (from Java) does not do what the name suggests, because of this local memory. Also calling the "constructor" leaves that state alone, and the "newly constructed object" has the same state as the "old".

This is not dangers I make up: in the course of the latest development, as reported in this thread, erroneous behavior came and went again, without being explicitly addressed. (Please take what I am saying as constructive criticism, not bashing.)

Quote:

Don't shoot the messenger, but regarding 64 bit Windows, the current recommendation from Oracle is: "we recommend using the default 32-bit browser and downloading 32-bit Java". Apparently the 64 bit version of Internet Explorer and some other browsers work poorly with 64 bit Java.

They say that they recommend 32 bit browsing, and in that context 32-bit Java. At least in that note, I cannot find any recommendation against 64 bit Java for applications. I installed IrMaster on 64 bit XP/64 bit Java, and everything seemed to run fine, except DecodeIR.

Moreover, DecodeIR is not a Java issue (only).

Has someone succeed compiling DecodeIR for Windows with mingw (32 or 64 bit?)

Quote:
but maybe using 32 bit Java is something of a universal workaround at the present time.

yesss..... but for the upcoming new release of IrMaster/IrpMaster I would hate to write "if using 64 bit JVM, everything will work fine except DecodeIR". Wink
Back to top
View user's profile Send private message Send e-mail Visit poster's website
MikeT



Joined: 28 Oct 2010
Posts: 115

                    
PostPosted: Mon Nov 12, 2012 6:30 am    Post subject: Reply with quote

Barf wrote:
Has someone succeed compiling DecodeIR for Windows with mingw (32 or 64 bit?)

I've compiled DecodeIR for MacOS 32 and 64 bit. Today 95% of the Intel Mac software are 64 bit applications. There is no current 32 bit version of Java for MacOS, so DecodeIR is always used as 64 bit lib on MacOS.

Are there any unit test cases for DecodeIR that I can run? I just used some learned keys to see if it is working at all, but I don't know if the result of all of them is correct.

Michael
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Mon Nov 12, 2012 3:18 pm    Post subject: Reply with quote

What a coincidence! I was fooling around with my Mac Mini (just upgraded from Snow Leopard to Mountain Lion), succeeded to get everything compiled and running, preparing to upload the shared libs, and you just did it an hour or so earlier!! Using the XCode I downloaded from Apple (containing a really ancient gcc from 2007 if I recall it correctly), I had different compilation issues than you: your 1. and 2. no problem; however, the abs function for float and double argument did not resolve uniquely, so I replace the calls by the (standard C functions) fabs and fabsf.

Furthermore, I noticed that with Snow Leopard the Java system property "os.arch" (System.getProperty("os.arch")) delivers "X64_64" (first X capitalized) while Mountain Lion returns "x86_64" (small "x"). I noted that the previous decodeIR-distribution contains the "X86_64" while yours say "x84_64". I smell potential for trouble.


MikeT wrote:

Are there any unit test cases for DecodeIR that I can run? I just used some learned keys to see if it is working at all, but I don't know if the result of all of them is correct.l

You can use IrpMaster to test DEcodeIR against whole ranges of input parameters, generated by IrpMaster. Try, e.g.
Code:

$ irpmaster --decodeir  rc5x   \* 0 0

(Unix-like shell assumed). You can also use IrMaster interactively to interface to DecodeIR interactively with GUI (cut-n-paste).
Back to top
View user's profile Send private message Send e-mail Visit poster's website
MikeT



Joined: 28 Oct 2010
Posts: 115

                    
PostPosted: Tue Nov 13, 2012 3:25 pm    Post subject: Reply with quote

Barf wrote:
Furthermore, I noticed that with Snow Leopard the Java system property "os.arch" (System.getProperty("os.arch")) delivers "X64_64" (first X capitalized) while Mountain Lion returns "x86_64" (small "x"). I noted that the previous decodeIR-distribution contains the "X86_64" while yours say "x84_64". I smell potential for trouble.

When you look at the distributions of RemoteMaster V2.01, V2.02Beta, jp12serial 0.18 and DecodeIRV2.41v2, all use the same directory name "Mac OS X-x86_64".
The file "decodeir-2.41-source\Mac OS X notes.txt" refers to the platform "x86_64".
The gcc -arch switch uses the parameter "x86_64".
The environment variable HOSTTYPE is set to "x86_64" on my machine.

I really don't know where "X64_64" or "X86_64" with an uppercase X should come from. Also google has only very few hits with the uppercase X.

Which java distribution (Apple or Oracle) and which version are you using?
"java -version" says on my machine:
java version "1.6.0_37"
Java(TM) SE Runtime Environment (build 1.6.0_37-b06-434-11M3909)
Java HotSpot(TM) 64-Bit Server VM (build 20.12-b01-434, mixed mode)

This is the current version Java 7, update 9 from Oracle.

I would stay with the directory name "Mac OS X-x86_64" like it has been in the previous RemoteMaster version.

Michael
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Tue Nov 13, 2012 4:10 pm    Post subject: Reply with quote

I wrote down my observations, because sooner or later it may bite, possibly with an obsolete version and an inexperienced user.

DecodeIR 2.43 comes with "Mac OS X-X86_64", as does IrMaster 0.3.0. This worked for me with Snow Leopard, but after upgrading to Mountain Lion, it did not any longer, which I with some effort identified to the above mentioned problem. I do not think I made a mistake.

Unfortunately, I do not have access to the old system any longer; the update overwrote it.

Quote:

I would stay with the directory name "Mac OS X-x86_64" like it has been in the previous RemoteMaster version.

Agreed. I have changed my loading code (in IrpMaster.DecodeIr.java) to read
Code:
 + System.getProperty("os.arch").toLowerCase(Locale.US);

and would suggest the RM maintainers to do likewise.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


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

                    
PostPosted: Wed Nov 14, 2012 8:21 am    Post subject: Reply with quote

Barf wrote:
I have changed my loading code (in IrpMaster.DecodeIr.java) to read
Code:
 + System.getProperty("os.arch").toLowerCase(Locale.US);

and would suggest the RM maintainers to do likewise.

I have made this change to my development code, so that it will be in the next v2.03 Alpha version.
_________________
Graham
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Wed Feb 13, 2013 4:34 pm    Post subject: Reply with quote

Just uploaded a version compiled for the Raspberry Pi. I am using Raspian, with Hardware FP support. (Using Raspian 2013-02-09.)
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mdavej
Expert


Joined: 08 Oct 2003
Posts: 4500

                    
PostPosted: Thu Apr 10, 2014 10:14 am    Post subject: Reply with quote

I have a huge spreadsheet full of pronto hex codes from Denon and would like to use DecodeIR to find all the OBCs. Is it possible to use the dll from Excel in VBA? If so, could anyone provide some example code?

If not, what's the easiest way to bulk decode a lot of pronto hex? Barf, if Scrutinizer can do it, could you point me in the right direction?

If there is an easier way to achieve my goal, please let me know.

Thanks
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Thu Apr 10, 2014 12:08 pm    Post subject: Reply with quote

For sure, IrScrutinizer can do it, although not quite in one step (at least not presently). It can import one worksheet at a time. To do so, just copy the the worksheet to the clipboard (no fumbling necessary, just Ctrl-A Ctrl-C suffices). In IrScrutinizer, go to Import->Text->Raw, leave Name column to 1, and raw signal column at 2, and (important!) select TAB as Field separator. Then just press "Load from clipboard" and you have it in the tree. Press Import all, and press OK in the popup. which takes you to the parametrized remote panel. You can now either import another worksheet (they will all be added up in the parametrized remote pane), or you can re-export in one of may formats. RM is not one of them, however, here i published an improvement to RM enabling it to import Girr-files, which is the native format of IrScrutinizer.

Let me know if you need more detailed instructions.

Having IrScrutinizer import Excel files directly, even multi-worksheet like the current file, would be do-able (Apache POI), but I have presently no plans. But who knows?
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mdavej
Expert


Joined: 08 Oct 2003
Posts: 4500

                    
PostPosted: Thu Apr 10, 2014 2:15 pm    Post subject: Reply with quote

Sounds good. I'll give it a shot. Thanks

Unless you gets lots more requests, I wouldn't bother with excel import. This is the first time in over ten years or JP1-ing I've had a need for such a thing.

One thing I could do quite easily, I think, is have excel output the codes in Girr format. I may try that first.
Back to top
View user's profile Send private message
mdavej
Expert


Joined: 08 Oct 2003
Posts: 4500

                    
PostPosted: Fri Apr 11, 2014 9:23 am    Post subject: Reply with quote

Worked great. Got a couple hundred codes converted in just a few minutes using copy/paste method. Didn't try Girr method.

Thanks
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 Previous  1, 2, 3, 4
Page 4 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
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control