Newbie question: simple steps for missing keys?

[TMPLee]

I just picked the newest model that matched the protocol info from your setup codes.

If you start to run out of keys to put all these commands on, check out Shifted functions in the Wiki.

Thanks again for all your help, but could I impose on you to go into more detail on exactly how you "just picked the newest model that matched..."? I finally got the RM tool running after I discovered my workhorse Powerbook is too old to run JRE v. 6 so I had to find a newer machine in the house that would. I was able successfully to track down a Sony code I needed for my DVD players and then tried to duplicate what you had done for the Insignia, and only partly succeeded. How did you go from the setup code to the right upgrade file? (Just for the Insignia there are 16 files in Forum Index -> File Section -> JP1 File Section -> Device Upgrades -> TV ) The LookUp tool isn't very helpful. It's not that I particularly need the answers now, but it might be helpful for someone in the future who is trying to go down the same path I did.

[mdavej]

You said you used setup code (fill in the blank) for you tv. I used the lookup tool to search for your code and noted the resulting protocol and device/subdevice. Then I did a file search for samsung. I downloaded the first file in the list and opened it in RM. I saw that the protocol info matched, so I knew the EFCs would probably work.

Most Sony DVD players share the same codes, so most any one should work. The key is to find a partially working code, find it with the lookup tool to identify the protocol device/subdevice. Then download a few sony DVD files and see what matches best.

The lookup tool is indispensable for finding the right setup code to start with.

[TMPLee]

You said you used setup code (fill in the blank) for you tv. I used the lookup tool to search for your code and noted the resulting protocol and device/subdevice. Then I did a file search for samsung. I downloaded the first file in the list and opened it in RM. I saw that the protocol info matched, so I knew the EFCs would probably work.

Most Sony DVD players share the same codes, so most any one should work. The key is to find a partially working code, find it with the lookup tool to identify the protocol device/subdevice. Then download a few sony DVD files and see what matches best.

The lookup tool is indispensable for finding the right setup code to start with.

I hear what you are saying but can't make as much sense out of it as I think I ought to be able to. (I see no way how using the LookUp tool leads to the right file -- in my case, it doesn't even mention Insignia as a brand for my remote and setup code, although it does reference Orion which I've seen suggested as the brand to use instead of Insignia.) I have a hunch I am missing some key understanding (no pun intended) about how all this works. I know a lot about electronics and computers (I won't bore you with my credentials) but haven't been able to get a good mental model of all this stuff. I intend to read over *all* the material here (more as a hobby than out of any particular need) and once I've done I'll give it another shot. What shows me that I must be missing something important is that I don't understand at all why EFC's are used instead of some representation of the small handful of bits that are transmitted with each key press. As I understand it, what is sent (in different ways in the different protocols) with each key press is at most something like 4 bytes -- 2 or less as what amounts to a device address and 2 or less as a function code. Anyway, if that understanding is wrong, then my whole mental picture of all this is all wrong, so I need to read all the gory details!

[mdavej]

You search for a file by mfg name here first, download what you think might be the closest match according to the model number or file date. The lookup tool is then used to find a built-in setup code that will work with the EFCs you found in the file. The lookup tool doesn't lead to the file, the lookup tool leads to a compatible setup code.

I think there are links to all the gory details on the wiki site at the top of this page.

[TMPLee]

You search for a file by mfg name here first, download what you think might be the closest match according to the model number or file date. The lookup tool is then used to find a built-in setup code that will work with the EFCs you found in the file. The lookup tool doesn't lead to the file, the lookup tool leads to a compatible setup code.

I think there are links to all the gory details on the wiki site at the top of this page.

Here's what you wrote a couple of messages earlier ...
"I used the lookup tool to search for your code and noted the resulting protocol and device/subdevice. Then I did a file search for samsung."

T'ain't what you just wrote -- I'm going to read the wiki (and other things referenced there) again slowly, but what you just wrote now squares better with how I understand things work. But be patient with me, if you can -- it'll take awhile!

[eferz]

I hear what you are saying but can't make as much sense out of it as I think I ought to be able to. (I see no way how using the LookUp tool leads to the right file -- in my case, it doesn't even mention Insignia as a brand for my remote and setup code, although it does reference Orion which I've seen suggested as the brand to use instead of Insignia.) I have a hunch I am missing some key understanding (no pun intended) about how all this works.

You search for a file by mfg name here first, download what you think might be the closest match according to the model number or file date. The lookup tool is then used to find a built-in setup code that will work with the EFCs you found in the file. The lookup tool doesn't lead to the file, the lookup tool leads to a compatible setup code.

I think there are links to all the gory details on the wiki site at the top of this page.

Perhaps either of you are referring to possessing different pieces of information.

First of all, the File Section is great when there is a matched name listed for your device because then you don't have to hunt and peck for compatible upgrades. However, not all upgrades include a list of the compatible devices and that makes it difficult to pin down which is the right one for you if there's not an exact match.

If you already have the setup code due to a partially working remote then the Lookup Tool is invaluable, as it will define the appropriate protocol parameters. This makes it easier to discriminate any downloads which you may have found in the File Section. As, it will prevent you from wasting your time trying upgrades which do not meet the protocol's criteria that is defined by the setup code.

However, if you do not have a partially working remote then you'll have to download different upgrades and test them individually to hopefully find one that at least partially functions. This can be very time consuming and very tedious if you do not have any clue what is supposed to work. Especially, if the device you're trying to control is using parameters for a protocol which is not addressed by your specific remote. This is why I often volunteer to upload the respective or "close to" IR profile(s) if someone is unable to find a match.

The other caveat of not having a JP1 cable and programming with EFCs is that the setup code in the upgrade may not be valid for your remote. So, you'll have to use the Lookup Tool to find an appropriate setup code which is predefined on your remote. Unfortunately, if there isn't one already then there's no way of using EFC codes to address the appropriate signals necessary to control your device. Having a cable will override this deficiency because you can define your own protocol parameters. You can even the customize the layout and create macros with the JP1 tools and a cable.

[vickyg2003]

I hear what you are saying but can't make as much sense out of it as I think I ought to be able to. (I see no way how using the LookUp tool leads to the right file -- in my case, it doesn't even mention Insignia as a brand for my remote and setup code, although it does reference Orion which I've seen suggested as the brand to use instead of Insignia.) I have a hunch I am missing some key understanding (no pun intended) about how all this works. I know a lot about electronics and computers (I won't bore you with my credentials) but haven't been able to get a good mental model of all this stuff. I intend to read over *all* the material here (more as a hobby than out of any particular need) and once I've done I'll give it another shot.

Yes this is a world onto itself. Everything you need to know is written down here, but digesting the material is quite a task.

What shows me that I must be missing something important is that I don't understand at all why EFC's are used instead of some representation of the small handful of bits that are transmitted with each key press.

Well there is a LOT going on here. First off, an EFC is an UEI method that we need to be able to work with. Apparently UEI wanted to maintain control of the information, giving out EFC's or Advanced codes as needed. They encoded the information in the form of an EFC. Our tools calculate the EFC.

An EFC can represent up to two bytes of data.

Once the EFC is translated into the proper one or two byte code, then it is manipulated by the protocol to form a timed lighting pattern that can be recognized by your equipment.

The setup code selects the executor and provides "fixed data" that the exectuor needs. The EFC provides the variable part of the signal, the part that changes with each key press.

In order to send out a signal, you need an setup code that provides the correct fixed data and selects the proper protocol executor.

To further complicate matters, different executors can send out the same timed pattern, using different EFCs. So its important to know which executor is being employed by the selected setup code. That's where the lookup tool comes into play. We need to find a setup code that can send the information. We may need to use our tools to recompute the EFCs for the executor our setup code is using.

[TMPLee]

It's starting to make more sense Maybe answering this question will clear up most of my remaining confusion. The setup code selects an executor. The executor "knows" the protocol (how data is physically to be encoded in the IR signal), or "knows" how to select one, and any necessary device (and possibly subdevice) "addresses" -- what you call the fixed data. The executor uses the EFC to determine the variable data -- what I might call a function code, although conceivably it might have more structure than that. Suppose there are 256 possible function codes for a given protocol (an 8-bit field). Given the right EFC can the executor generate any of those 256 codes, or is it only able to generate some subset of them? Or, to put it differently, if I knew what the binary value of a particular function code were, is it possible (preferably without trying them all) to find or compute an EFC that would generate that function code (with a particular executor)? (I think what I am calling "function code" may be what is here called the "OBC" but I haven't read that discussion in a few days.)

[3FG]

Function numbers and an OBCs are the same thing. We ordinarily use RM to convert between OBCs and EFCs. For example, if you have a partially working setup code, you can use the Lookup Tool to find the executor name (which usually tells you the IR protocol also) and device numbers. If you select the same executor (called protocol in the RM UI), and make sure that the fixed data matches that of the Lookup Tool, then you can enter an OBC and RM will calculate the EFC. Or you can enter the EFC and RM will calculate the corresponding OBC.

If you only know an IR protocol, there may be a choice of several executors to use. But you can use the Lookup Tool to search out suitable executors which are in your remote. It is frequently helpful to read the procotol notes on the General Tab of RM to understand whether a particular executor is a good one to use.

[eferz]

It's starting to make more sense

Let me see if I can clarify or muddle it up for you.

Executors are programs written in assembly to generate an IR signal which conforms to a particular protocol. These executors may have different variables which can include toggle bits, delays, frequency, device, sub-device, prefix commands, and many other esoteric parameters. The remote's built-in setup code(s) defines the the appropriate executor and "fixed data" which addresses those variables to use when processing these signals.

If you've ever opened up Remote Master (RM) and looked at the function tab, you'll always see Original Button Code (OBC) and Hexadecimal (Hex) Data. These values are generally same information but shown in a different expression. You'll also see values for Extended Function Code (EFC) and depending on the remote maybe even EFC5 values. All of these values are interrelated, so if you change the value of one then the others are recalculated. The unique thing about the EFC values is that they are also related to the value of the fix data for the protocol. So, changing the parameters of the protocol will recalculate the EFCs but not necessarily change the OBC or Hex Data. Here's a good Wiki page that explains it better, "EFCs and OBCs".

Now to answer your questions,

Given the right EFC can the executor generate any of those 256 codes, or is it only able to generate some subset of them?

Yes, the three digit EFCs can represent a value from 0-255d (00-FFh), five digit EFCs as I understand can represent 0-65535d (0000-FFFFh).

Or, to put it differently, if I knew what the binary value of a particular function code were, is it possible (preferably without trying them all) to find or compute an EFC that would generate that function code (with a particular executor)?

I suppose it is possible for you to do without RM, but why would you? The tools are already in place to make these calculations for you. Even if you're only programming your remote with EFCs, RM is still a very valuable reference tool. Not only will it allow you to display the different upgrades from our file section in a human consumable format but it can also be used as an EFC calculator if you know what you're doing.

[vickyg2003]

It's starting to make more sense Maybe answering this question will clear up most of my remaining confusion. The setup code selects an executor. The executor "knows" the protocol (how data is physically to be encoded in the IR signal), or "knows" how to select one, and any necessary device (and possibly subdevice) "addresses" -- what you call the fixed data.

Good up to here.

The executor uses the EFC to determine the variable data -- what I might call a function code, although conceivably it might have more structure than that.

Actually the EFC is translated into one or two bytes of data that are the "variable data". The EFC is merely for entry into the keypad.

Suppose there are 256 possible function codes for a given protocol (an 8-bit field). Given the right EFC can the executor generate any of those 256 codes, or is it only able to generate some subset of them?

Depending on the executor, the variable data can be up to 65536

Or, to put it differently, if I knew what the binary value of a particular function code were, is it possible (preferably without trying them all) to find or compute an EFC that would generate that function code (with a particular executor)? (I think what I am calling "function code" may be what is here called the "OBC" but I haven't read that discussion in a few days.)

The short answer is yes. But the details of the executors are all different, so you'd need to know how the stuff is calculated. You could spend a few years figuring it out. How were you given the function code? Was it supposed to be read LSB or MSB? And then do you know if UEI's exector needs the data comped? Its a complex procedure that our tools work out for you.

[TMPLee]

Oh, I understand why you'd want and, now, may need to use RM! What I was trying to understand was whether a given executor could in principle generate all the "real" codes for a given device -- so if I found a code in an upgrade that was missing in the list for one of my devices, I ought to be able to find an EFC on my remote that would generate that code (as long as the remote is already partly supporting the device). For instance, I noticed that when I looked at what RM said the setup code for my TV and remote had as EFC's, there were several that are on the Insignia remote that aren't in that list. One of you found that much longer list of EFC;s for Insignia (I didn't look at all the upgrades to discover which one you found it in) -- I wasn't sure when I tried the missing ones that they would work, but what you just told me was that they probably would without having had to worry about it -- if they were the right EFC's for the missing codes. I'm not explaining myself very well, but what you told me is that if I only want to add a few missing functions I should be able to do that in a fairly straightforward fashion -- while it might take some investigation and experimentation (either if different upgrades give different codes, or one or more potentially relevant upgrades use different setups), if the function is supported on the device, the remote ought to be able to handle it without requiring a full JP1 reprogramming. I can also see that if we're talking about more than a handful of keys, having some functions (such as switching input) work "cross-modes", and adding a few macros very quickly it would be easier to use the tool to get everything laid out right and just burn a complete new remote package.

[eferz]

What I was trying to understand was whether a given executor could in principle generate all the "real" codes for a given device -- so if I found a code in an upgrade that was missing in the list for one of my devices, I ought to be able to find an EFC on my remote that would generate that code (as long as the remote is already partly supporting the device.

That's rather a tricky concept to explain. As we've already explained the EFCs can address all the possible variations for "button/function/hex codes" within a particular executor in accordance to its fixed data. However some devices, like the Emerson EWC1301, require multiple executors. In that particular case, I had to address all the different signals which it responds to with three different upgrades. Each of them addressing their own protocol; NEC, Emerson, and RCA. There was actually a fourth one, Async, if you look at the ICT file. But, I decided to ignore those signals since it was being send in tandem with the Emerson signals.

[eferz]

-- I wasn't sure when I tried the missing ones that they would work, but what you just told me was that they probably would without having had to worry about it -- if they were the right EFC's for the missing codes. I'm not explaining myself very well, but what you told me is that if I only want to add a few missing functions I should be able to do that in a fairly straightforward fashion

Okay, so... let's pretend that you found out that sending "real code" 143 will frame your Samsung television picture with hearts for Valentine's Day and that's something you want to surprise your significant other. Here's what you would do to calculate the correct EFC...

1. Download the Samsung UN46C8000 or another Samsung television upgrade which matches your profile. Even though, I know that's the one that mdavej used to provide you with the respective EFCs.
2. Open up the RMDU file in Remote Master (RM) to find out the protocol parameters.
3. Verify the protocol/fixed data is built-in to your remote by looking up its protocol parameters in the Lookup Tool (LT). Notice that the RMDU file in this cases specifies setup code TV-2013 which is not available on any remote. However, the Fixed Data from RM matches the LT for four different setup codes on your remote; TV-0702, TV-0812, TV-1903, and Video-0899.
   • If the fixed data doesn't match then it could mean the protocol parameters are jumbled in the upgrade as opposed to how it is represented in the built-in setup code. You'll need to resequence parameters in accordance to the LT's Dev[1-4] columns so that the fixed data matches up appropriately.
4. As long as your using one of those four setup codes, you can go into the Functions tab and create a "New" function then assign it OBC 143. This will calculate the appropriate EFC value in the respective column for you to manually program on your remote.

Okay, test time to see if you understand the process. Let's pretend you purchased a brand new 37" Hanseatic Television model# CTV 7037. How would you add the "Hanseatic CTV 7037" upgrade into your remote?

[vickyg2003]

Oh, I understand why you'd want and, now, may need to use RM! What I was trying to understand was whether a given executor could in principle generate all the "real" codes for a given device -- so if I found a code in an upgrade that was missing in the list for one of my devices, I ought to be able to find an EFC on my remote that would generate that code (as long as the remote is already partly supporting the device).

Yes, if you found a function in another upgrade that was missing in your remote, and if the setup code used in the upgrade, had the same fixed data & executor, then the EFC for keyborad use could be calculated. The thing here, is we often need to use the OBC or function code and let RM or KM calculate the EFCs. We can also calculate EFCs that work with different Executors. For example we may have a combo upgrade that needs to be broken appart to get the functions into a remote when the user doesn't have a cable.

For instance, I noticed that when I looked at what RM said the setup code for my TV and remote had as EFC's, there were several that are on the Insignia remote that aren't in that list. One of you found that much longer list of EFC;s for Insignia (I didn't look at all the upgrades to discover which one you found it in) -- I wasn't sure when I tried the missing ones that they would work, but what you just told me was that they probably would without having had to worry about it -- if they were the right EFC's for the missing codes.

Its a bad practice to just look for EFC's, that is really limiting and often wrong. People will tell us they found an EFC and tried it, without realizing that the EFC often needs to be calculated. If you place all this importance on the EFC, you are going to travel down the wrong path, and will need to do a lot of back tracking to get things right in your head. (been there done that).

I'm not explaining myself very well, but what you told me is that if I only want to add a few missing functions I should be able to do that in a fairly straightforward fashion -- while it might take some investigation and experimentation (either if different upgrades give different codes, or one or more potentially relevant upgrades use different setups), if the function is supported on the device, the remote ought to be able to handle it without requiring a full JP1 reprogramming.

Ususally. although there are some devices that have very complicated signal structures and use different device codes for different functions.

I can also see that if we're talking about more than a handful of keys, having some functions (such as switching input) work "cross-modes", and adding a few macros very quickly it would be easier to use the tool to get everything laid out right and just burn a complete new remote package.

While I LOVE my cables. I know it took a lot of pressure to get me to invest in a cable that was more expensive than my remote. I was very happy with my purchase. Programming a remote visually was enough to keep me happy for my first 6 years of JP1ing. I always felt that was a wise investment, and was quick to buy another cable when I moved on to JP1.2/3 remotes.

Then I had the missfortune of discovering extenders. I found I could make my remote jump through hoops. Judging by the # of times my extenders have been downloaded, I would say that most of the members don't utilizlize the remote the way I do. I use all the LKPs and DSMs that tame my systems so that even my DH can watch TV without an issue. Once I started using extenders I couldn't go back to an unextended remote. Extenders let me customize my remotes so that they are intuitive and easy to use.