CaptureIR progress

[johnsfine]

In the past few days I've made some small progress toward the changes I've wanted for a long time in CaptureIR.

But I haven't changed version number or copyright notice or various debug things (that are designed only for my own use).

If I'm the only one using CaptureIR, I'll keep going this way and only post updated binary and source after I've made much more progress.

If others are using it, I should clean up some things more often and post updated binaries. If others are interested in helping with the Java UI code (never my strong point) I should post updated source code.

So who else is using CaptureIR?

The change today displays the body of the frame (in the raw signal panel) in red, while displaying the lead_out_off and anything not part of the frame in black. When the capture is anything other than a single clean frame, that makes the raw data display much more informative. (I'm finding it a big improvement for my own use of CaptureIR).

For most protocols, it also displays the lead-in in black. That isn't intentional. It is a side effect of a feature of the DecodeIR interface that I'd like to change, but haven't had time. For anyone who know the protocol structure, displaying the lead-in that way doesn't make the display confusing or hard to use. It's just strange.

If someone wants to help with Java coding, I'd especially like a properties file similar to the one RM has and an options UI to turn on and off various optional features of the processing.

For those considering starting to use CaptureIR, it is still easy, reliable and very useful on dual processor, dual core and/or hyperthreaded CPUs and still slow and glitchy (but I think useful anyway) on single processor thread systems. I'm trying to improve that.

[classicsat]

If you can, I'd like to be able to connect the IR receiver module to the SDA line on the JP1 cable. My Qbasic IR reader software works fine with it, so there is no reason yours cannot.

[johnsfine]

I assume you've dealt with the issue of powering the IR receiver module.

Are you using an IR receiver module with similar characteristics (polarity etc.) to the one used with CaptureIR

If I ever get a properties dialog and file into CaptureIR, I'll certainly let the user change which pin the signal comes in on, probably the polarity of the signal as well. For now, those things are easy to edit into the c code but aren't under user control.

I forget the printer port pin number of SDA, and I don't know the polarity of your receiver module. But if you want me to slap together a test copy of CaptureIR based on that, I can do so and email it.

Until recently I always ran CaptureIR from a .bat file that invokes Allowio, telling it to invoke java.exe, and telling that to invoke CaptureIR.jar. That works, but I don't like it. After reading a little more about porttalk, I added the C code to have the CaptureIR.dll directly ask porttalk to unprotect the printer port, so I could run CaptureIR by just double clicking the .jar file. Sometimes that works and sometimes it doesn't and I haven't figured out what determines that. So for the moment, the ugly .bat file method is required.

[classicsat]

I don't know the specified one's characteristics.

I am using a standard module pulled from an old VCR (38-40 Khz detect, active low open collector), powering it with a few AA or AAA batteries (depending on what holder I pull form my battery kit).

It cannot discern frequency of the carrier (I can learn and analyse for that)for that.

However I think I do have a detector here that passes the carrier through.

[johnsfine]

I think CaptureIR would work OK with a detector that doesn't pass the carrier through, but I haven't tested that.

Of course in the few cases where the carrier is needed for DecodeIR to identify the protocol, you wouldn't get the right decode.

CaptureIR is currently set for active high, so it is grounding the printer port's internal pull up on the signal line the whole time it is connected. I want to add a polarity option and try the opposite polarity IR sensor, so it draws that current only when it detects IR.

[gfb107]

If someone wants to help with Java coding, I'd especially like a properties file similar to the one RM has and an options UI to turn on and off various optional features of the processing.

I'll trade you a Java options UI for a Java API to DecodeIR

[johnsfine]

I assume you mean actually in DecodeIR.

Right now the CaptureIR java code calls C code in CaptureIR.dll via a Java API. That C code then calls DecodeIR.dll via a C interface.

You probably already know that. Maybe you even did something similar for RM IR (I haven't had time to look).

While that method is easy to copy, it's ugly that it needs an extra dll.

I know I ought to put something compatible with that into DecodeIr.dll itself. I guess that's what you want. I'll try harder to find that time when I'm on a computer where I have all the tools.

I've changed the CaptureIR UI in a few ways since the official version. The source code to my current copy is at:
http://home.comcast.net/~john.fine/ir/s ... IR-src.jar
in case you want to get a look at it.

BTW, I want to change the calling interface of DecodeIR.dll. Some things are kludged in CaptureIR that could be a lot cleaner with a slightly improved interface. I'll keep the existing C interface. I was planning to add a direct Java interface only for the improved one, and add a C improved interface under a new name (I don't think I can ever retire the original C interface). But if it would simplify RM IR, I should add direct Java interfaces for both the old and new (under different names).

[gfb107]

It doesn't really matter to me where the Java interface to DecodeIR is, whether it is actually in DecodeIR.dll or in a different DLL that calls into DecodeIR.dll. As the owner of DecodeIR, and knowing you, I expect you do care.

I just want a (not too complicated) way to add support for decoding learned signals to RMIR.

If you are adding Java support directly into DecodeIR, I don't think including the old interface is a requirement, since that interface never had a builtin Java equivalent. But if you want to include it, I certainly don't have any reason to object.

If you'll write up a brief description of what you need in CaptureIR's options UI, I'll take a stab at it.

[johnsfine]

I just want a (not too complicated) way to add support for decoding learned signals to RMIR.

So I should clean up the DecodeIRCaller.java file in CaptureIR and finalize the interface between that and the outside (Java) world. Then the interface between that file and the C code can evolve as I like.

I'm not sure what release controls we might want to invent, vs. just including that same DecodeIRCaller.java file in both RM and CaptureIR source code collections.

Also if you have any reason the DecodeIRCaller class should be renamed, tell me soon.

If you'll write up a brief description of what you need in CaptureIR's options UI, I'll take a stab at it.

I don't know exactly what I need, but I can tweak Java code will enough to fix the details. I'm worst at researching which standard package is appropriate to a specific UI task.

We need some way to get to the options dialog. I don't like the current collection of buttons on the top of the CaptureIR dialog (vs. an organised set of pull down menus) but havn't had time to fix.

In the options section, I think tabs are required (but I don't have a good feel yet for where it's going).

On a hardware tab of the options, I'd like to be able to select which of the (twelve, I think) readable printer port pins will be used for the single input, and whether its polarity is active high or active low. A more advanced version would also select things about the non input pins to specify their state in case one of them is used for power, and/or to keep CaptureIR from messing with them if other things are connected at the same time. Maybe I will add an option about which unprotect method is used to let the program direct access the port.

Options on a timing tab would evolve as a fix other things. Right now I really need a main timeout value (how many milliseconds to wait after a signal seems to end before decoding and displaying the result). Too long and CaptureIR is annoying to use. Too short and you can only see the first step in any macro. Normally you know you aren't looking at macros so you want it short. But now I need to edit and recompile to switch to capturing macros. I'd also like a minimum modulation frequency (that is used to decide whether a signal is modulated. Set it higher to correctly capture a very fast unmodulated signal. Set it lower if you think you have a modulated signal with very low frequency. If CaptureIR makes the wrong choice about modulated/unmodulated the results are worthless, but usually the fastest unmodulated is enough slower than the slowest modulation that a default is OK.)

Options on a diagnostics tab would turn on/off a number of debugging features that slow things down when not needed, but explain what is going wrong when something is going wrong.

The properties file should also hold the main screen metrics. I improved the code for letting the user resize the main dialog, but you still need to resize/reposition each time you start.

I hope that isn't too much.

[johnsfine]

With more experimentation and mistakes than I thought it should take, I managed to move one of the routines from DecodeIRCallerImp.c into DecodeIR.cpp and deal with all the GNU vs. Microsoft build issues and C vs. C++ coding issues and actually get it to work.

Moving the rest and eliminating DecodeIRCallerImp.c should be easier. CaptureIR.jar will still need an extra DLL (for printer port access) but will get to DecodeIR.dll directly. RM IR will then also be able to get to DecodeIR.dll directly.

There still is a fair amount of clean up that I'm too tired to do tonight. Should be done tomorrow.

[johnsfine]

I cleaned up the code from CaptureIR that calls DecodeIR. It is now isolated to a single .java file and no longer makes assumptions specific to CapureIR.

You can get it from
http://john.fine.home.comcast.net/ir/CaptureIR.jar

Inside that .jar file is
CaptureIR-src.jar

and inside THAT .jar file is
DecodeIRCaller.java

That should be all you need to call the new DecodeIR.dll from a different Java program.

The new DecodeIR.dll that can be called that way is available at:
http://john.fine.home.comcast.net/ir/Decode_IR_DLL.zip

[gfb107]

I cleaned up the code from CaptureIR that calls DecodeIR. It is now isolated to a single .java file and no longer makes assumptions specific to CapureIR.

You can get it from
http://john.fine.home.comcast.net/ir/CaptureIR.jar

Inside that .jar file is
CaptureIR-src.jar

and inside THAT .jar file is
DecodeIRCaller.java

That should be all you need to call the new DecodeIR.dll from a different Java program.

The new DecodeIR.dll that can be called that way is available at:
http://john.fine.home.comcast.net/ir/Decode_IR_DLL.zip

I'm finally getting around to looking at all this. I'm just getting started with this, but I'd like to suggest that you ship DecodeIRCaller.class as part of DecodeIR, rather than as part of both RM and CaptureIR.

[johnsfine]

I assume you still have the last UnpackLearned.java that I emailed. That turned out to be a bigger part of using DecodeIr from RM_IR than DecodeIRCaller was.

Of course UnpackLearned is entirely specific to UEI remotes so it should be packaged just with RM_IR, not with DecodeIR nor with CaptureIR.

Did you really mean ".class" for shipping DecodeIRcaller with DecoderIR.zip?

I think it would be a pain for anyone setting up RM_IR or CaptureIR to figure out how to give it access to a .class file that isn't in the .jar (or is that easier than I think?). You may have forgotten how unclear Java path issues are to the uninitiated (such as myself).

DecodeIRCaller won't change many times and I could put changes directly to Sourceforge for RM if appropriate once the official RM uses it. I plan to keep the interface between RM and DecodeIRCaller unchanged, while changing both the interface between CaptureIR and DecodeIRCaller (with new function names) and between DecodeIRCaller and DecodeIR.dll

I certainly will put both DecodeIRCaller.class and DecodeIRCaller.java in the CaptureIR distribution to minimize issues for any non Java experienced users installing that, and I'll manage the multiple updates when I change that code.

I was planning to put just the .java file in DecodeIR.zip to benefit anyone writing a third Java program that uses it.

Of course you can distribute it or not as you like for RM. But I guess if you don't put the .class file in RM, I need to include it in DecodeIR.zip and you need to include instructions and or code in RM's setup process to make sure the .class file is accessable.

[gfb107]

John,

I've run into a snag using the DecodeIRCaller class.

As you know, RemoteMaster is coded in the com.hifiremote.jp1 package. It turns out that classes in a package do not have access to classes that have no package (or more correctly, are in the default unnamed package). DecodeIRCaller is such a class

As a temporary workaround, so I can try it out, I have placed DecodeIRCaller in com.hifiremote.decodeir

If you like that package, we can continue using it, or you can come up with another.

[gfb107]

That was silly. I can't just change the package of DecodeIRCaller. Changing the package changes the class name, which in turn changes the names of the entry points into the DLL. I guess I'll need you to provide an updated DecodeIR.dll