JP1 Remotes

We're going to need a new parm in the General section of the RDFs to tell IR.exe which format to use for keymoves, buttons programmed with advanced codes and macros.

I recommend KeyMoveFormat as the name, where the setting will be a number 1 thru whatever.

1 = this is the old fashioned format that we've been using for years
2 = the format used by the URC-6131
3 = the new format that's going to be used in all new UEI remotes

For format 2, if the length of the keymove is 3 (ie, 2 bytes for the setup code and 1 byte for the keymove) it means that this really is a "keymove" (as opposed to a button programmed with an advanced code) and the last byte (of the 5 byte keymove) is the keycode of the "from" button used in the keymove. If the lenth is 4, it means that the last 2 bytes (of the 6 byte keymove) are the EFC stored in hex (eg, EFC=001 would be hex "00 01")

Macros are unchanged in format 2


For format 3, the 2nd byte has been broken into 2, where the high nibble of the new byte2 is either "1" for keymoves or "8" for macros. The low nibble of the new byte2 is the code for the device button and is unused for macros. The new byte3 is the length of either the keymove or macro.

So, the new "3" format is as follows ....

keymoves format:
1-1 = button being programmed
2-2 = high-nibble: (1=keymove, 8=macro)
2-2 = low-nibble: device button
3-3 = length of remainder (ie, 03 or 04)
4-5 = setup code
6-6 = "from" button (when 3=03)
6-7 = EFC in 2-byte hex (when 3=04)

macros format:
1-1 = button being programmed
2-2 = "80" = macros
3-3 = length of macro
4-? = macro steps

Also, they have started using FF as the [EOF] marker rather than 00, so I think IR.exe should treat either 00 or FF as the [EOF] marker for all remotes.

Here's a few samples of how the data will look (for format 3):

2A 13 03 31 F7 29
2C 13 03 31 F7 2B
2D 80 08 01 15 16 17 21 19 1A 1B
16 11 04 10 2F 30 39

The first entry is a keymove from button "29"
The second entry is a keymove from button "2B"
The third entry is a macro with steps: TV,1,2,3
The final entry is a keymove programmed using 5-digit advanced code 12345

The Robman wrote:We're going to need a new parm in the General section of the RDFs to tell IR.exe which format to use for keymoves, buttons programmed with advanced codes and macros.

We already have an item named AdvCodeFormat, which currently has two possible values: HEX or EFC.

HEX refers to the normal method of storing keymoves.
EFC is intended to indicate the new-style (URC-6131) keymove format. RM uses this currently, but IR does not.

It sounds like we need to expand this item to include other possibilities.

Bump, Paul are you out there? Just FYI, I have an advanced prototype of a remote that uses this new format that I've been asked to try out, but I can't do anything with it until IR is modified to handle it.

Yep I'm here. Sorry I was deep in thought with Mark's request and I forgot this one.

As soon as we have the 5.01 hammered out I'll start on this...

Rob:

This is a fairly significant change as you can imagine. There is a lot of code in IR dealing with this.

I will be venturing into some areas of IR I've only seen in my dreams

Just FYI, we now have a confirmed sighting of the new Kameleon that needs these changes, so it's on the market already.

Ok...that sound you just heard is me holding my breath and jumping in..

One other thing that is new in the new Kameleon is it's use of number tables with two-byte protocols. This won't have too much effect on IR until KM & RM are modified to create such upgrades, but I thought I'd mention it here as a reminder that IR will eventually have to support it. In the meantime, should someone try to display a UEI-generated upgrade using a two-byte protocol and number table, it will be displayed incorrectly.

UEI doesn't use their own number tables for upgrades, so we're safe there.