help a newbie

[jwkxneud]

I've read a bunch of jp1 docs now, but I'm still struggling with the language. The part that I really don't get is how specific key presses are associated with specific IR commands. There seem to be several layers of logic between these two events.

So, if the key has an assigned macro, the macro is executed. Otherwise the behavior of the key is specified by the device mode. In a particular mode, if the key has been learned, the learned code is used.

This is were it gets fuzzy for me. At some point it has to resolve to a protocol, a device id and possible sub-device id, and a command, right?

So, if there's a keymove on this key, the keymove includes protocol, device id, and command (or perhaps setup code and command?). Otherwise the key only has a command associated with it, and the protocol and device id are looked up in the active setup code.

Is that correct? I don't get the difference between an OBC and an EFC. Which number is associated with a button? Which number is in the IR command? Is there another lookup happening here?

Also, why does it matter if an upgrade includes "advanced" codes that aren't bound to any button by default? I don't understand how you would use them. My impression is that you can generate any command (0-255) in the current setup code by using a special button sequence on the remote, but to actually associate one of these commands to a button you have to use the JP1 interface. Is that correct?

[gfb107]

The device type + setup code determine the protocol and device parameters (device id, sub-device, etc).

A keymove has associated with it a device type and setup code (which determines the above) and a hex command. The hex command may be one or two bytes. One of those bytes can be translated to EFC or OBC, which are abstractions of the hex command. The translation from OBC to hex is protocol specific.

It is good form to include all known commands in a device upgrade file, even if you don't want to use them by assigning them to a button, so that the next person who comes along and wants to use your upgrade can choose to do so without having to redesicover what the available commands are.

Even without JP1, you can assign arbitray functions to buttons using the EFC, but only for protocols that have single byte commands. And again, the protocol is determined by the device type and setup code.

[The Robman]

The lowest code on the button totem-pole is the code that's assigned as part of a setup code.

If a macro is then programmed to this button, it will override the code that's part of the setup code. (Macros are active across all the device modes).

If this button is then re-programmed either using learning or an advanced code, this will override both the macro and the setup code.

If the button is first programmed with an advanced code and then learning is used, the advanced code entry is deleted. The same is true in reverse.

[wwwoholic]

If this button is then re-programmed either using learning or an advanced code, this will override both the macro and the setup code.

Here is a quote from KeymoveMacroFormat.txt file:
Even though IR displays Macros and Keymoves on separate tabs, they are stored in the same section of memory in EEPROM in the same list. In fact, the list can have some macros in it, then some keymoves, then some more macros. The order of the entries in the list generally do not matter in an unextended remote.
In a remote with an extender, the order of the items in the list can make a difference, depending upon the extender.

Does this mean that built-in code scans entire advanced list and chooses keymove even if macro present for the same button, while extenders tend to pick the first found entry?

[jwkxneud]

Is an "advanced code" the same as a "keymove"? Both are full references to commands, including the setup code, right?

Is it correct to say a keymove includes an EFC, but an EFC is not a keymove?

So the remote derives the hex command from an EFC, and the EFC is what is stored on the button? Is the hex command the thing that is transmitted by IR? What uses OBC?

[The Robman]

If this button is then re-programmed either using learning or an advanced code, this will override both the macro and the setup code.

Here is a quote from KeymoveMacroFormat.txt file:
Even though IR displays Macros and Keymoves on separate tabs, they are stored in the same section of memory in EEPROM in the same list. In fact, the list can have some macros in it, then some keymoves, then some more macros. The order of the entries in the list generally do not matter in an unextended remote.
In a remote with an extender, the order of the items in the list can make a difference, depending upon the extender.

Does this mean that built-in code scans entire advanced list and chooses keymove even if macro present for the same button, while extenders tend to pick the first found entry?

If you're using an unextended remote, a key move will always override a macro. If you are using an extender, you are not using the standard UEI code which is fairly consistant from remote to remote, you are instead using a piece of code written by a JP1 member with the express purpose of overriding many of the restrictions imposed by the built in code. How this code works depends on what the extender writer wants it to do, so you would have to read the readme that accompanies each extender to answer your question.

[The Robman]

Is an "advanced code" the same as a "keymove"? Both are full references to commands, including the setup code, right?

Is it correct to say a keymove includes an EFC, but an EFC is not a keymove?

So the remote derives the hex command from an EFC, and the EFC is what is stored on the button? Is the hex command the thing that is transmitted by IR? What uses OBC?

A key move is a method of re-programming a button on your remote to do send a signal other than the one it would otherwise send. You can program a key move in 2 ways, you can copy a button from one place to another or you can program it using a "advanced code" (aka "EFC").

So the correct statement might be "an advanced code (or "EFC") is a code than you can use to program a keymove"

Every keymove refers to a setup code.

When you program a keymove, the remote stores the EFC in a hex format.

EFC codes are a scambled version of the actual binary signal that gets sent. We assume they are scrambled to prevent us from knowing the true OBCs behind them (which evidently hasn't worked! )

OBCs are a subjective concept. When we look at the binary strings used for signals, we look for patterns. When we discover a pattern, we can usually reverse engineer the original button codes (OBC) that the engineer who invented the signal had in mind. For example, if you take any given upgrade code and look at the OBCs for the numeric buttons, you will usually find that they are in sequence, whereas the EFCs are all over the place.

[wwwoholic]

So, if there's a keymove on this key, the keymove includes protocol, device id, and command (or perhaps setup code and command?).

Keymove includes device type, setup code and command. Device type is required because (I guess) you can have same setup codes for different devices. Of course, they are the "same" by number only. That is why you usually refer to device as: TV/0250 etc. Devices, in turn, have protocol id to be used to send a command. They also have associated "fixed data" with device id, sub-device id etc. As I understand, this data is sent via IR along with command code.

Otherwise the key only has a command associated with it, and the protocol and device id are looked up in the active setup code. Is that correct?

Something like this. Current mode (TV, SAT etc) defines a pair "device type + setup code", just as in keymove. Unlike keymove, the command used corresponds to actual button pressed.

I don't get the difference between an OBC and an EFC. Which number is associated with a button? Which number is in the IR command? Is there another lookup happening here?

Take a look at: http://www.hifi-remote.com/ofa/adv-search.shtml
Oversimplified, you can say that there is no difference beetween them, as they correspond one-to-one. However, EFCs can be greater than 255 so the same OFC "FF" corresponds to EFCs 181, 437 and 693. On the other hand, you can say that OBC is in fact HEX command to be sent via IR. Again, you might be wrong here, because different protocols use different hexadecimal formats, so command "FF" can be OBC "0" as well as "255". My advice would be to not bother yourself with all these details.

Also, why does it matter if an upgrade includes "advanced" codes that aren't bound to any button by default? I don't understand how you would use them. My impression is that you can generate any command (0-255) in the current setup code by using a special button sequence on the remote, but to actually associate one of these commands to a button you have to use the JP1 interface. Is that correct?

Yes, this is correct. and the reason for using upgrade is exactly to replace "special button sequence" with a single push of a button.

[johnsfine]

Is an "advanced code" the same as a "keymove"? Both are full references to commands, including the setup code, right?

In common usage I guess you're roughly right. When we made an attempt to be more precise in terminology, we tried to make a distinction, but that distinction hasn't really become part of common (JP1 and OFA forum) usage. In precise terminology:

An "advanced code" is a command that is not bound to any key by the setup code, thus it is a command that (without JP1) can only be used by EFC and would normally be used by a KeyMove of an EFC.

Is it correct to say a keymove includes an EFC, but an EFC is not a keymove?

Not really. Setting aside a couple new models with strange KeyMove format, a KeyMove consists of four things:
1) The device mode it is bound in
2) The Key it is bound to
3) The setup code (both device-type and 4-digit number) it is based on.
4) The hex command.

An EFC is an encription of a single byte hex command, so "keymove includes an EFC" is almost correct, but not really correct.

So the remote derives the hex command from an EFC, and the EFC is what is stored on the button?

The hex command, not the EFC, is stored (with the partial exception of those two new models). The remote decrypts the EFC into a hex command immediately upon entry of the EFC and does not store the EFC.

Is the hex command the thing that is transmitted by IR? What uses OBC?

Nothing in the remote uses the OBC. The protocol executor in the remote contructs an IR signal from the fixed data and the hex command. The device receiving that IR signal decodes the OBC from that IR signal and uses it, but that OBC is usually not directly present in the remote. Typically the hex command is some translated form of the OBC from which it is easier to generate the IR signal than it would have been from the OBC itself. Sometimes it is simpler (the hex command just is the OBC). Sometimes it is more complicated (the hex command represents less than the whole OBC and/or more info outside the OBC).

[johnsfine]

Does this mean that built-in code scans entire advanced list and chooses keymove even if macro present for the same button, while extenders tend to pick the first found entry?

I haven't looked at every extender, but I'm nearly certain the statements (2 and 3) below cover them all (as split into those two cases).

1) Unextended, the remote stops the search at the first KeyMove for the correct Bound device and key. It notices, but doesn't stop at, a macro for the correct key, and if it finds no correct KeyMove will use a macro if it has found one.

2) An extender, which does NOT modify the eeprom location of the KeyMove area, uses the built-in search and thus exactly matches the above rules.

3) An extender, which does modify that location, uses a simpler search that stops at the first matching macro or KeyMove.

[jwkxneud]

The hex command, not the EFC, is stored (with the partial exception of those two new models). The remote decrypts the EFC into a hex command immediately upon entry of the EFC and does not store the EFC.

Wacky. So the EFC is only relevant if you're invoking it from the keypad? Is it also used during phone upgrades? Or does the upgrade use the hex command? How about JP1?

It sounds like OBCs are largely irrelevant to anything one might do, and EFCs are some weird obfuscation of the hex commands. Only the UEI remote knows about EFCs, right? The AV gear and its original remote don't know anything about EFCs.

Is it possible that the obfuscation or "encryption" or whatever it is has some functional role like error correction, or improving reliability during a phone upgrade, or something?

[johnsfine]

Wacky. So the EFC is only relevant if you're invoking it from the keypad? Is it also used during phone upgrades? Or does the upgrade use the hex command? How about JP1?

EFC are not used during phone upgrades. Even in the two models that sometimes store EFCs in KeyMoves the hex commands are used in upgrades.

Any JP1 software that displays EFCs or allows input of EFCs or even stores EFCs (in a txt file saved or loaded by KM) is using the EFC to represent part or all of a hex command. By the time it gets transmitted through the JP1 cable, it is a hex command, not an EFC.

It sounds like OBCs are largely irrelevant to anything one might do,

1) They are often useful in guessing any missing commands (commands the device understands that aren't in the OEM remote).

2) Sometimes there are two different protocol executors for the same kind of signal and those use different rules for generating the signal from the hex command and thus different EFCs. By working with OBCs you can avoid problems when switching between such executors.

and EFCs are some weird obfuscation of the hex commands. Only the UEI remote knows about EFCs, right? The AV gear and its original remote don't know anything about EFCs.

Both the EFC and the hex command are UEI things and are not meaningful to the device itself nor to other (non UEI) universal remotes. The hex command sometimes matches similar data from LIRC or other systems that condense IR signals to a small hex form. The EFC (being an encription) won't be meaninful in other systems even in cases where the hex command is.

Is it possible that the obfuscation or "encryption" or whatever it is has some functional role like error correction, or improving reliability during a phone upgrade, or something?

No.

There is no doubt that its purpose is to hide some information from somebody. But it is such a crude and stupid encription that, even before JP1 made it easy, several different people independently figured out the encription rules.

I assume that UEI wanted to be able to give customers lists of advanced codes in EFC form without risking giving competitors advanced codes in any form the competitors could adapt to other remotes. I have no knowledge of any UEI competitors using any of that info (with or without JP1). But if they didn't do so, I have to assume that was for legal reasons rather than technical reasons (such as the EFC encription) because this (and other) UEI anti copying features are too crude to present more than a minor annoyance to such an effort.

[The Robman]

Let me see if I can try this from another angle.

Infrared signals used for remote controls have three main components:

1) the protocol - this basically defines what the signal looks like
2) device code - most signals have 1 or 2 device codes (some have more, some have none)
3) command code - every signal has to at least have a command code.

The device being controlled is programmed to look for IR signals using a specific protocol with a specidic device code. Once it recognizes that the correct signal is being used, it looks at the command code and checks it against a list of pre-programmed functions that it's been programmed to perform. For example, command 1 might be the POWER command, command 2 might be VOLUME-UP, etc.

Now, in JP1 terminology, the "command code" is also known as the OBC, which stands for Original button Code.

What I have said so far is a general description of how IR signals are used, so far nothing of what I have said is unique to UEI remote controls.

Now to get UEI specific...

To generate IR signals, UEI writes what they call "executors". These executors generate signals with a specific protocol, so in the JP1 world we tend to refer to these executors as protocols.

These executors are invoked by device upgrades. The device upgrade plugs in values to populate the signal with the correct device and command codes. The device codes are typically populated by "fixed data" at the beginning of the device upgrade, and the command codes are typically populated using "variable data" which is assigned to each button. Both the fixed and variable data is stored in hex format (as is all data in the EEPROM).

UEI also created a funcion called "Key Mover" which lets you use a concept called "Advanced Codes" (aka EFCs) to re-create the variable data hex codes. As has been previously discussed, an EFC is a slightly encrypted version of the hex code and there is a one-2-one relationship between the hex code and the EFC.

Let's say that the EFC for POWER on your device is 181, the equivilent hex for that is "FF". (I won't complicate things here by quoting the formula that you use to convert 181 to FF, just take it as given). Now, when UEI creates a setup code for this device, they will assign "FF" to the POWER button. Did they assign an EFC when they did that? That's a matter of interpretation.

If you were now to use the 994 Key Mover function to copy the POWER button to another button and you were then to look at that keymove in IR.exe (see note below), you would see that the "FF" hex code and the 181 EFC had been assigned to the new button. Now, if you were to program another button only this time you used the 181 EFC rather than coping the POWER button, and you were then to look at that keymove in IR.exe, you would see that the format was exactly the same.

Note: this is true for most JP1 remotes, but not the URC-6131 and a few select other remotes, that use the new keymove format.

So, you may ask, what's the point of even knowing the OBC? Well, the thing about OBCs is that they usually follow a logical pattern, the numeric buttons (for example) are often given OBCs 0 thru 9, and the four arrow buttons are usually given sequential OBCs also. Out of the typical 256 possible button codes, most devices use OBCs in the range 0 thru 50. So, if you want to go fishing for discrete codes and other functions that your device may support but are not covered by the original remote, rather that typing all 256 codes, you can focus on the OBCs that are approximately in the same range as the known OBCs.

Plus, if you were ever to communicate with someone outside of the JP1/UEI world about these signals, such as the original manuafacturer, they would not understand what EFCs are, they would only know OBCs (which they would call "command codes" or something similar).