JP1 Remotes

[jsevinsk]

Where is the format of the data in the EEPROM (and the new flash-based "EEPROM") documented?

[unclemiltie]

What do you mean by "format"

The locations and useage of any given remote is best described by the RDF, which tells you where certain things are in the EEPROM. (for example: Upgrades start at $100 and go to $3FF)


The format of things like keymoves, upgrades, and macros is a bit more complicated and I'm not sure that this is "documented" anywhere. When IW as in learning mode I learned by entering macros in IR, looking at raw data, entering more, looking at more.

You can also learn a good bit by reading a reasonably well documented extender if you understand assembly language code.

[jsevinsk]

[johnsfine]

I don't recall where those things are documented. I'm sure we have that somewhere, but no clue where, nor whether it was ever copied from Yahoo to hifi-remote.

[unclemiltie]

Don't know, I was able to figure out a good bit by looking at what IR puts down and looking at extenders, maybe I've been staring at assembly too long.


Back to the original question.

The other thing to remember is that they are different on different remotes (and on some remotes, the way the extenders do it are different than the non-extended remote, the 6131 is a good example of this) I think I have an EXCEL sheet that documents a few different formats lying around somewhere let me see if I can dig it up and post it in the next day or so.

[The Robman]

The old keymove format, which was used in remotes up to and including the B00 version of the URC-9960, was as follows:

byte1 = keycode of button
byte2 (bits 7 thru 5) = index of device mode (eg, 0=cable, 1=TV, etc)
byte2 (bit 4) = keymove/macro indicator (0=keymove, 1=macro)
byte2 (bits 3 thru 0) = length of keymove data (ie, usually 3 or 4)
bytes3&4 = setup code
bytes5+ = variable data

Starting with the URC-6131, the keymove format started changing. Instead of saving the true hex code for the variable data, UEI introduced a new format where the keymove is a true "key copy". In this new format, instead of saving the hex code they save the button code of the key being copied, which imposes a limitation that there needs to be a setup code defined that includes the required code in order for this format to work. Obviously, one of the main reasons that people use the keymover function is to define buttons that are NOT part of the built in setup codes, so they needed to continue to support the use of EFCs, and while they were at it, they expanded the traditional 3-digit EFC (aka "EFC3") into a new 5-digit code (aka "EFC5"). For executors that use 1-byte of variable data, the new EFC5 codes are simply the old EFC3 codes with 2 zero digits added in front. For executors that use 2-bytes of variable data, the new EFC5 codes can be used to create the required hex code. Whenever an EFC keymove is stored in remotes that use this format, the hex code is always 2-bytes (true "key copies" use 1-byte hex code). If the EFC used was a 00+EFC3 code, the first byte will be zeroes and the second byte will be the EFC3 code stored in hex format. If the EFC used was a true EFC5, the 2 hex bytes will be the EFC5 value stored in hex format. (Note: a different encryption formula is used to convert EFC5 codes into signal data than that used to convert EFC3 codes).

Another change that was made with the newer remotes was that the old byte2 was split up into seperate bytes.

To find out which format a particular remote uses, look in the RDF. The entries that you're looking for are:

AdvCodeFormat - HEX or EFC
EFCDigits - 3 or 5
AdvCodeBindFormat - NORMAL or LONG

A more detailed description of these three variables is given in the RDF2Spec.doc document that's distribured in the IR.exe zip file.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!