JP1 Remotes

Hi All!

I have just released a new version of IR. Here are the highlights:

Support has been added for two new interfaces. In addition to the parallel interface, IR now supports a serial interface (using a design that Tommy will be posting shortly) and a USB interface (using the Delcom USB chip).

Read-verification has been made optional. In prior versions, IR always read back the contents of the EEPROM after writing to it in order to verify that the write successful. This re-reading is probably overkill since problems encountered while writing should be identified as they occur, so users can now go to the Interface menu to disable the read-after-write verification.

IR now allows buttons to be restricted within the RDF. For each button, the RDF developer can now indicate where the button can be used and where it can’t. For example, a device button (such as VCR) can be defined so a user can’t bind a macro to it, but it can be used within a macro. These button restrictions should allow all of the P8-style remotes to be defined correctly with respect to their Shift and XShift capabilities as well.

The user can now specify both Shifted and XShifted keys. The names used by IR to label the “Shift” and “XShift” states can now be specified in the RDF. This will hopefully help to reduce confusion for remotes that contain an actual Shift key.

Support has been added for the URC-6131, and any other remote that stores KeyMoves in EFC format rather than as Hex Commands. (In this format, single-byte entries are interpreted as KeyCodes and two-byte entries are interpreted as 16-bit EFCs. Longer entries are preserved as is, but are interpreted as KeyCodes.)

Please refer to the release notes and the RDF spec (distributed with the new version) for more details.

-- Mark

This makes my life with RDF's a lot easier Thanks for all your work on this Mark.

From here forward I will only be releasing one set of RDF's that are compliant with RM Version .78 or greater and IR version 4.00 or greater.

I will not delete the older RDF's but they will become functionally stable at version 1.10.

Woo hoo! This will definitely make Nils' life easier, and will allow those who use RM and have been using 2 sets of RDFS to use only 1!

Also, now we should see some progress on getting the button restrictions set correctly, as well as use of the generic button names.
Some of the RDFs (particularly the extenders) can also reduce the number of button definitions by taking advantage of the XShift feature, rather than explicitly defining every XShifted button.

gfb107 wrote:Also, now we should see some progress on getting the button restrictions set correctly, as well as use of the generic button names.
Some of the RDFs (particularly the extenders) can also reduce the number of button definitions by taking advantage of the XShift feature, rather than explicitly defining every XShifted button.

The good news is that if you are referring to the "generic button names" as those that allow changing from one remote to another within RM and maintaining the button assignments, it is pretty much completed in the IR/RM compliant v1.10 RDF's (Unless I missed something).

Even finished a good many with the $xx: hex option in the maps to eliminate the dependancy of matching button names in IR and the maps. I sort of put that on hold when I started running into decimal assignments. Assuming the no $ does mean decimal in the button assignment. Some RDF's are even mixed. Really feel silly if I misinterpreted that.

I started looking at the XShifted options and will start updating the RDF's accordingly. This needs to be done slowly since the impact could be great.

Nils_Ekberg wrote:I started looking at the XShifted options and will start updating the RDF's accordingly. This needs to be done slowly since the impact could be great.

You might want to talk to Alain. He helped me to test this, and I believe that he already has an RDF or two with this implemented. I think you'll find that there is a bit of an art to this, as you can now set things up (correctly) in several different ways.

mpauker wrote:You might want to talk to Alain. He helped me to test this, and I believe that he already has an RDF or two with this implemented. I think you'll find that there is a bit of an art to this, as you can now set things up (correctly) in several different ways.

I will... I did follow the dialog way back when and also received what you sent to my e-mail.

Thanks

Just a small feature request.

It would be nice if ir had a subdir for the
rdf's like RM

Makes it easyer to look for things like the docs
and the binary

Keep up the good work...

mein wrote:Just a small feature request.It would be nice if ir had a subdir for the rdf's like RM. Makes it easyer [sic] to look for things like the docs and the binary Keep up the good work...

I was thinking this too. It would make things neat and tidy.

Just to be clear (in case Mark hasn't really looked at what RM does) it's not really a subdir. It's a dir.

What we'd like is some way (.ini file, environment variable, registery setting, black magic, etc.) to configure IR.EXE to tell it to look for all its RDF files in a specific place instead of looking for them in the directory where IR.EXE starts.

You may want a subdirectory as a default behavior (as RM has). But if a user reconfigures it that should be able to point to any directory and should stick until you reconfigure it again.

That will let us manage versions of IR, versions of RM and versions of RDF files as independent collections of files. Otherwise the end user has a complex cleanup problem when he wants to update one of those three.

is the IR 4.0 pascal source code available anywhere? I see source code folders at jp1 and jp1-km at yahoo but no IR unless I missed it

IR's written in Delphi and there is a source code folder for it in the JP1-KM group. The most recent version posted is v3.20

http://groups.yahoo.com/group/jp1-km/fi ... de/Delphi/

I'll post the new source in a little bit. I may need to make a few changes soon, and I also want to implement the separate RDF directory.