JP1 Remotes

I've been lurking for a while, and (thanks to Rob) now have my account activated and running, and so the time has now come to start asking questions. This just happens to be the first

So, what is the purpose of the DecodeIR.dll? Is it a static data structure or does it go beyond that and actually perform calculations based on data passed to it?

Regards,
Craig

The C++ source code is posted in the Yahoo JP1-KM group (a few rev's obsolete at the moment, but I'll update it again soon).

It performs massive calculations based on the data passed to it.

It looks at almost every contiguous subsegment of the passed data as a possible frame (including "contiguous" subsegments that only exist when you circularly wrap the end of the repeat part around to the beginning. This finds IR signals even when there is noise or signal framents before and/or after the real signal.

For every possible frame it considers every known way of encoding data in IR. It assumes that the transmitter and or receiver may have distorted the signal in all the different ways that IR signals are typically distorted and decodes in strange ways that attempt to be as imune as possible from such distortions.

The 'high level' answer is that it examines learned signals to see if they match the patterns of any known infrared protocols.

It's done in a DLL module so that this same module can be used from all the programs that need this functionality (ie, IR.exe, CCF2EFC, DecodeCCF, and IRTool)

johnsfine wrote:The C++ source code is posted in the Yahoo JP1-KM group (a few rev's obsolete at the moment, but I'll update it again soon).

It performs massive calculations based on the data passed to it.

Thankyou for pointing me to the JP1-KM group - I would never have known it existed. Taking a look at the (earlier) DecodeIT.DLL source helps a lot in understanding what is going on. Gotta love pattern recognition at the bit level

Again, thanks for the link.

CSE

Token User wrote:Taking a look at the (earlier) DecodeIT.DLL source helps a lot in understanding what is going on.

If you had any clue at all what is going on in that messy C++ code, that soon after first looking at it, you must be quite an experienced C++ programmer and we should be working on convincing you to contribute to some of the group's half finished (or half baked) programming projects.

Craig has been communicating with me via email and that's exactly what he has in mind to do.

FWIW - Despite the fact I can read C++, I hate it, and prefer to use plain vanilla K&R C in preference. I have been a software developer for PalmOS devices in the past using straight C - none of this fancy shmancy object oriented stuff. Like Rob, my background was IBM 370/XA assembler in a CICS environment. It amazing the appreciation for tight code you get when you are constrained in memory/MHz.

I do enjoy Java as a language though - and my last programming gig was writing multitiered web based apps in Java, so I am not a copletely lost cause when it comes to OO vs Procedural languages

Before I throw my hat in the ring as a contributor, I'll poke around the code some more. A first pass might be to translate the DecodeIR code from C++ to Java.

The RM project up on SourceForge sounds like a worthy project (and kudos to all involved) that is building a great framework that should (touch wood) run across platforms. Once I am up to speed, it is a project I would like to contribute to - no sense reinventing the wheel.

CSE

Token User wrote:FWIW - Despite the fact I can read C++, I hate it, and prefer to use plain vanilla K&R C in preference.

I took a long time to get used to C++. I'm still upset by flaws in the design of the langauge every day that I work with it (something I didn't feel when I was a professional C programmer). But software engineering has changed and C is no longer enough. My opinion of C++ is that it is a horrid misdesigned piece of garbage that unfortunately is better than any other available language for writing serious projects.

Token User wrote:It amazing the appreciation for tight code you get when you are constrained in memory/MHz.

Try writing an extender or an RC6 protocol in S3C80 assembler and "tight code" can take on meanings you never imagined. But actually please don't. We need Java programming a lot more at the moment.

Token User wrote: I do enjoy Java as a language though

There are a lot of applications in which the C or C++ implimentation drowns in the problem of remembering which dynamically allocated objects still have owners. Java just eliminates the problem. I also find the use of "super" a vast improvement over C++ when you are evolving your inheretance structure as you evolve the project. Java also avoids all sorts of declaration sequencing nightmares you hit when objects need to know about each other non hierarchically.

But Java really doesn't have the power of C++, especially for big projects and often overwhelming all other factors, Java doesn't have the speed of C++

Token User wrote: Before I throw my hat in the ring as a contributor, I'll poke around the code some more. A first pass might be to translate the DecodeIR code from C++ to Java.

I'd advise against it. decodeIR would be pretty slow in anything but C++. The code that I haven't posted in source yet is even slower. I have plans for more changes that will make it slower still. Later, I MIGHT do some things I've been planning that involve very complicated templating combined with some very non_object_oriented tricks with pointers, all of which should greatly improve the speed and make it REALLY hard to port to anything but C++.

Most platforms have C++ compilers. DecodeIR has no GUI and has a very simple interface to its caller, so it should be easier to port (to another platform) staying in C++ and easier to call from non C++ programs than typical C++ programs would be.

*I* don't know how to call C++ DLL's from Java, but I know it can be done because at my last job someone else wrote Java code that called my C++ code across a DLL boundary (as well as C++ code that called Java across a DLL boundary).

I suggest you look into some aspect of manipulating the files saved by IR.EXE from Java code. In ExtInstall there is crude C++ code for reading an RDF file and then using knowledge from the RDF file to read, understand and write IR's files. In RM there is (presumably better) code in Java to read an RDF but there is no code to use that information to read IR's files.

1) If you know (or can figure out) how to call C++ from Java, I'd really appreciate a stand alone command line utility to read a saved IR file and decode all the contained signals (there was an experimental IR.EXE with that command line interface, but it got dropped). There is limited usefulness by anyone other than me for that tool, but the Java code you would need to write for that tool is all Java code we need for more important projects.

2) A logical next major step in RM would be the ability to read an IR file, install the upgrades and KeyMoves and rewrite it. By itself, that isn't a big improvement over the copy/paste to IR.EXE method, but it is necessary Java code before more valuable features are possible (again the ExtInstall source code has all the concepts needed).

3) The IrToWav Java software particularly suffers from lack of integration with the rest of the tools (meaning it needs more expertise to run than its typical user would have). If RM had the ability described in item (2) then it would be easy to merge IrToWav into RM in a way that eliminates the need for user expertise.

4) If we could crack the problem of uploading and downloading to the JP1 cable from Java (especially on other platforms) we would really be on the way to well integrated software. I think that projects suffers from lack of anyone's attention, rather than from really being that hard.

But, but, but ... ir.exe is written in *shudder* Delphi. I haven't touched Delphi (or more particularly its older brother Pascal) since I was an undergrad.

Java is not particularly fast, but it IS portable with no rewrites necessary (for the most part). I cant see that speed of the app is particularly important - especially given current CPUs.

Anyway, I hear what you are saying. If you would like to see a Java app call the DecodeIR.dll, I'll put together a command line version for you - it is far simpler than writing the GUI and needing to deal with listeners. I'll take a crack at the option you listed below to read and interpret the IR and RDF files and see where we go from there. I'll keep you posted 8)

Token User wrote:But, but, but ... ir.exe is written in *shudder* Delphi. I haven't touched Delphi (or more particularly its older brother Pascal) since I was an undergrad.

But I don't think I was asking you to touch Delphi (sorry Mark, no insult intended).

I consider IR to involve mainly the following things:

1) Reading and understanding RDF files: RM might ignore some parts of the RDF file that don't apply to it and thus need a few improvements to its RDF reading (I'm not sure) but basically RM already reads and understands RDF files.

2) Packing and unpacking eeprom image raw data, a process very much dependant on having understood the RDF file: I wouldn't suggest getting the required information for that from IR (unless you're quite comfortable in Pascal). Most of that logic is simpler in the ExtInstall source code. Rob can probably point us to some old documents explaining it. I'd be glad to answer any questions about the S3C80 models (in which I think I'm the most expert on eeprom raw data structure issues) and you probably can get answers from someone on non S3C80 models.

3) Reading and writing the real EEPROM through the JP1 cable: There are several simple examples of that in C++ source code.

4) (The biggie) GUI: Obviously look at IR's GUI from the user side. It has well thought out ways of showing the user what the user should see and eliciting from the user what the program needs. But I can't imagine that the GUI source code would be at all useful to someone wanting to build a comperable GUI in platform independant Java.

BTW, on that IR_saved_file topic, the big feature request (actually the enabling technology for lots of otherwise easy things that users have as many "unrelated" feature requests) is to tack on some kind of addendum to that file format, so that it doesn't just store an eeprom image but also stores the reasons for things in the image (The fact that a KeyMove was tied to a specific upgrade. The name of the function in some other KeyMove. The name of a learned signal. The function of a macro. The brand and model that a device mode is being used for, etc.).

johnsfine wrote:But I don't think I was asking you to touch Delphi (sorry Mark, no insult intended).

Actually, I wasn't thinking of touching the Delphi code either (btw - nice code Mark, even without touching Pascal for over 10 years it all came flooding back to me ). But one of the beauties of Pascal is the way it is close to being pseudo code ... and that means that the guide to writing this in Java is there ... you just need to read between the lines.

johnsfine wrote:BTW, on that IR_saved_file topic, the big feature request (actually the enabling technology for lots of otherwise easy things that users have as many "unrelated" feature requests) is to tack on some kind of addendum to that file format, so that it doesn't just store an eeprom image but also stores the reasons for things in the image (The fact that a KeyMove was tied to a specific upgrade. The name of the function in some other KeyMove. The name of a learned signal. The function of a macro. The brand and model that a device mode is being used for, etc.).

Hmm, sounds like a job for a well defined XML file ... could provide a nice foundation for a unified toolset between Prontos and OFA style remotes. Sort of a "one file define them, and in darkenss bind them" type of deal.

CSE