JP1 Remotes

ricara wrote:But if my understanding is correct, why use Device Type Aliases?

One reason (there probably are more) is to make it easy to change the remote in an upgrade and still have a valid upgrade. Some remotes have many device types (for example the URC-8090 has 15), while others only have a few (for example the 15-2103 only has 4). Without device type aliases, KM and RM wouldn't know how to what device type to use on the 15-2103 if the user took an upgrade designed for the URC-8900 using device type TAPE (index 12) and changed the remote to 15-2103. Because of the aliases, we know that the 15-2103 should use device type VCR/DVD (index 2). Also note that the index numbers of different for different remotes.

ricara wrote:To see what is happening, edit the 1.10 RDF for the Outlaw remote by adding the line:

OEM = OEM

at the end of the "DeviceTypeAliases" section.

For the sake of consistency between KM and RM (which also makes importing KM upgrades in RM work better), please use the following

OEM = OEM Mode

I took care of the OEM in the RDF and changed the device# to the real names.

Can some one tell me the position on the image for each device, top and bottom rows, left to right so I can define the map correctly.

Thanks

ricara wrote:I think I've finally figured what you were telling me about the second entry. If I understand correctly, each Device Type can use the same Setup Code (e.g., 0571) yet still invoke a different set of code to be executed. (There's a reason I'm posting in the "Beginner's Forum"! )

But if my understanding is correct, why use Device Type Aliases? Couldn't that lead to someone trying to assign two Setup Codes to the same Device Type?

In other words, I think it's OK if there is a VCR with Setup Code 0571 and also a CD with Setup Code 0571. But you wouldn't want to also have an Amp with Setup Code 0571, as that would conflict with the CD since both "CD" and "Amp" are really both "Audio" Device Types.

Or maybe I'm still all mixed up....

You're almost there

While you are technically correct that device types would allow 0571 to exist in each type (for any one specific remote), this does not happen in the built-in setup codes. Using Greg's example of the TAPE device, you will find that UEI will put that setup code into different device types in different remotes, so they need to keep the setup number unique regardless of the type.

The second entry (when present) assigns a device button to a particular device type within that remote. This is needed because in some remotes, more than one device button is assigned to the same device type.

Because it is just an index number, there is no way to tell what type of device it refers to (i.e., in one remote, 0 might be cable devices, while in another, 0 might be TV devices). This is where thae aliases come in. The alias definitions in the RDF tell us what type of device belongs in each device type for that particular remote.

Nils_Ekberg wrote:I took care of the OEM in the RDF and changed the device# to the real names.

Can some one tell me the position on the image for each device, top and bottom rows, left to right so I can define the map correctly.

Thanks

Hello Nils -

Man, you guys are *fast*! It don't get no better than this!

For info on the buttons, please go here.

This will take you to a detailed photo of the top half of the Outlaw remote that Rob posted in the Yahoo Group.

Thanks!

gfb107 wrote:One reason (there probably are more) is to make it easy to change the remote in an upgrade and still have a valid upgrade. Some remotes have many device types (for example the URC-8090 has 15), while others only have a few (for example the 15-2103 only has 4). Without device type aliases, KM and RM wouldn't know how to what device type to use on the 15-2103 if the user took an upgrade designed for the URC-8900 using device type TAPE (index 12) and changed the remote to 15-2103. Because of the aliases, we know that the 15-2103 should use device type VCR/DVD (index 2). Also note that the index numbers of different for different remotes.

Hello Greg,

Thanks for the explanation, that makes perfect sense. You guys think of everything!

mr_d_p_gumby wrote:You're almost there

Hello Mike,

Thanks for jumping in. I'm still not quite there...
I guess that's to be expected from me -- I've finally done my first "upgrade" after 6 months of trying to understand how to do this!

While you are technically correct that device types would allow 0571 to exist in each type (for any one specific remote), this does not happen in the built-in setup codes. Using Greg's example of the TAPE device, you will find that UEI will put that setup code into different device types in different remotes, so they need to keep the setup number unique regardless of the type.

OK, I'm with you so far.

The second entry (when present) assigns a device button to a particular device type within that remote. This is needed because in some remotes, more than one device button is assigned to the same device type.

I'm mostly following you here. For example, the Outlaw remote has 8 device buttons, but only 3 (or is it 5?) device types. There are three different Button Maps (the first part of the Device Type entry), but five different index numbers (the second part of the Device Type entry).

Because it is just an index number, there is no way to tell what type of device it refers to (i.e., in one remote, 0 might be cable devices, while in another, 0 might be TV devices). This is where thae aliases come in. The alias definitions in the RDF tell us what type of device belongs in each device type for that particular remote.

I'm mostly following you, but now I have a different question. If the Setup Codes used by UEI are unique, why bother to have different Device Types at all?

For example, in the Outlaw there are three different choices:

OEM -- Uses all the buttons.
VCR -- Uses most of the buttons.
Audio -- Uses the fewest number of buttons.

I had originally thought that it might save memory to use a Device Type with fewer buttons, so it would only make sense to use the Device Type with the smallest memory "footprint". But when I tried writing upgrades in RM and then seeing how much memory was used in IR, it didn't make any difference whether I used a Device Type with a lot of buttons or a Device Type with only a few buttons. (This experiment was done with a "small" upgrade that didn't require any key moves. If key moves were required in the Audio mode, then OEM mode used less memory as there were no key moves required.) Of course, maybe I just did the experiment wrong....

defining 10 keys in Cable vs. 10 keys in VCR will result in the same amount of bytes used. There is an advantage to using a device type with larger amounts of "legal" keys than one which uses a smaller number and the "overflow" gets assigned as keymoves because keymoves require 5-6 bytes of memory, albeit in the keymove/macro area. Unless you're using a VERY LARGE number of upgrades, you likely won't fill up "upgrade" memory. that means fewer keymoves being wiped due to just upgrades, and more left for other needed/wanted keymoves and macros.

In MOST normal ueic remotes, cable and/or vcr type upgrades offer more "legal" button/function assignments before you have to revert to assignments which use keymove area. If you check the further back sheets in KM, you'll see which keys are "legal" for each device type, and which offer the most key assignments before hitting into keymove area. The problem may arise, tho, that if you insist on a ceretain key for one function, the possible selections which have that as a "legal" button may put you in a position where you're cutting your own throat.
Another situation may arise. For example you may want to use VPT. In many cases, reassigning a device key may kill VPT. You should weigh all the factors and see what fits the total scheme of how you want your remote to work, and see the most efficient way to get there based on your devices and demands. Try and leave a little slop so you can add another device in the future which won't require a total revamp.

Jim

Hello Jim,

Thanks for the speedy reply! I appreciate your help.

Probably a lot of my questions come up because I only have experience with the Outlaw remote. But here goes anyways:

1) Using the Device Type with the largest number of legal keys (OEM for the Outlaw) will reduce or eliminate the need for Key Moves, which is a good thing.

2) On the Outlaw at least, there don't seem to be any VPT restrictions that are added by using OEM as the Device Type.

So it seems to me that I'd be better off by just using OEM as the Device Type for all my upgrades. Or am I still missing something?

A separate question -- what is the "Lock" function that is below the VPT modes in IR?

Thanks!

ricara wrote: If the Setup Codes used by UEI are unique, why bother to have different Device Types at all?

Who said they're unique? There's a TV/0000 and a VCR/0000 and they certainly aren't the same setup code even though they have the same 4 digit number.

One item related to this does seem like it represents a risk of confusing some users:

In RM, I can select 15-2104 (a remote in which CD and Tuner are actually the same device type) and create an upgrade CD/1234 and create another upgrade Tuner/1234 and load them both into IR.EXE. It might not be at all obvious to a beginner why the second one doesn't work (because they are the same setup code and the remote uses the first one). By contrast if I made CD/1234 and DVD/1234 in a 15-2104, those are different setup codes.

johnsfine wrote:Who said they're unique? There's a TV/0000 and a VCR/0000 and they certainly aren't the same setup code even though they have the same 4 digit number.

I was essentially repeating what Mike wrote about 6 posts above:

"While you are technically correct that device types would allow 0571 to exist in each type (for any one specific remote), this does not happen in the built-in setup codes. Using Greg's example of the TAPE device, you will find that UEI will put that setup code into different device types in different remotes, so they need to keep the setup number unique regardless of the type."

But either he misspoke or I misinterpreted.

One item related to this does seem like it represents a risk of confusing some users:

In RM, I can select 15-2104 (a remote in which CD and Tuner are actually the same device type) and create an upgrade CD/1234 and create another upgrade Tuner/1234 and load them both into IR.EXE. It might not be at all obvious to a beginner why the second one doesn't work (because they are the same setup code and the remote uses the first one). By contrast if I made CD/1234 and DVD/1234 in a 15-2104, those are different setup codes.

Yes, and I don't see any easy way around this. I suppose that you could have some sort of cross-reference in the IR program that would try to eliminate these conflicts, but it would be a lot of work. I guess it hasn't been a big problem in practice, or else there would be a lot of complaints about it.

Thanks for clarifying!

I think you overlooked one key word in Mike's post:

While you are technically correct that device types would allow 0571 to exist in each type (for any one specific remote), this does not happen in the built-in setup codes

UEI can make sure that there is no conflict between between codes for different device types that share the same device index, because they pick which codes they put in each remote. As JP1 users, we run the risk of reusing the same setup code that UEI built into the remote, but that is usually OK because we usually only need the one we are adding. If it causes a problem, we just edit the upgrade and use a different setup code and ecerything is fine.

Locks mean you can't change a setup code for that device type. In IR you can change the setting. It's usually a little more involved when manually programming, ie with 9xx comands. Cable remotes will usually have a cable lock, so you can't inadvertantly change the setup code that the cable box needs. So, many cable companies will turn that lock "on". Some remotes will also have locks for some of the other devices, and IF an RDF writer wants to take the time and energy sometimes he can fasion the rdf to effectively make locks for some devices. One such lock would be to define in the registers for a device with a fixed data entry. That would prevent IR from changing the data in that register. Most device keys will use two registers in the eeprom area below where the keymove area starts. those registers are typically in pairs, one for the device type, the other for the setup code. If the first (device type) is set at the value representing "cable" (for example), and the rdf defined that as "fixed data" you wouldn't be able to change that device key to "tv" for example. Defining the second register (setup code) as fixed data would result in not being able to change that setup code to some other setup code number. Typically, tho, they don't do it that way, but do it in the register(s) that control a certain feature, like VPT status, or channel lock are the most common ones. also, most times that status is usually either on or off, but not always. Some rdf writers took extra time to allow options so you may see a short list of options in "settings" on the general tab in IR. There's actually two ways, generally that you can set this up, but this isn't the forum for that discussion.

For my Mill4, "Cable" allows the most "legal" keys, so I reassign all my device buttons to be cable and make all cable upgrades. The keymoves I saved still leaves a lot of extra keymove space even considering if I had to make some keymoves because VPT got broke. Again you have to look at the total picture and evaluate your case individually, so there isn't any hard-set rules which will fit every case.

Jim

I don't remember any user complaints on that issue so maybe the problem is too unlikely to matter.

RM can't do anything about it because RM works with one upgrade at a time.

IR can't give a very understandable error message because IR has no place to store the specified device type. It only stores the number of the device type. IR ought to give an error when there are duplicate upgrade setup codes. Maybe it does. I last checked that behavior quite a long time ago when it didn't give any error. In my example it could only report the duplication, it would have forgotten by then that one was defined as CD and the other as Tuner.

I'm not sure of the exact rules for UEI creating built-in setup codes but:

1) They certainly do duplicate the 4 digit numbers as in my TV/0000, VCR/0000 example.

2) They can't duplicate across types within a model where the types have the same name (they can't have a Tuner and a CD have the same number in a 15-2104).

3) They try to make most setup codes possible as upgrades for most models, so the rarely if ever duplicate 4 digit numbers across types when those types share a number on ANY model. (So they won't have a CD and Tuner have the same number even on a model where CD and Tuner aren't the same type).

4) There seems to almost be an overall hierarchy across models as to which device types can share a number and which can't, and Rob has documented those sets somewhere on his web pages. But when we tried to use that initially as the basis for RM's understanding of device types the results weren't clean enough to be effective.

5) In RM we intentionally distinguish a 15-2104 CD upgrade from a 15-2104 Tuner upgrade even though there is no difference that IR.EXE or the 15-2104 itself cares about. We hope that makes it simpler for someone who wants to convert the upgrade for some model in which CD is not the same as Tuner.

johnsfine wrote:I'm not sure of the exact rules for UEI creating built-in setup codes but:

1) They certainly do duplicate the 4 digit numbers as in my TV/0000, VCR/0000 example.

2) They can't duplicate across types within a model where the types have the same name (they can't have a Tuner and a CD have the same number in a 15-2104).

3) They try to make most setup codes possible as upgrades for most models, so the rarely if ever duplicate 4 digit numbers across types when those types share a number on ANY model. (So they won't have a CD and Tuner have the same number even on a model where CD and Tuner aren't the same type).

4) There seems to almost be an overall hierarchy across models as to which device types can share a number and which can't, and Rob has documented those sets somewhere on his web pages. But when we tried to use that initially as the basis for RM's understanding of device types the results weren't clean enough to be effective.

5) In RM we intentionally distinguish a 15-2104 CD upgrade from a 15-2104 Tuner upgrade even though there is no difference that IR.EXE or the 15-2104 itself cares about. We hope that makes it simpler for someone who wants to convert the upgrade for some model in which CD is not the same as Tuner.

OK, I'm guilty of trying to oversimplify things a bit. I'll amend my statement to read:

While you are technically correct that device types would allow 0571 to exist in each type (for any one specific remote), this does not happen in the built-in setup codes very often. The logic used in determining a number for a given built-in setup code is entirely up to UEI, but they seldom seem to duplicate a setup code number unless they are sure they will never mix the two into the same device type. Once such a number is assigned, they are unlikely to change it or use the number for another device. Attempting to explain the logic used by UEI for any given decision can be an exercise in frustration...

ricara wrote:

The second entry (when present) assigns a device button to a particular device type within that remote. This is needed because in some remotes, more than one device button is assigned to the same device type.

I'm mostly following you here. For example, the Outlaw remote has 8 device buttons, but only 3 (or is it 5?) device types. There are three different Button Maps (the first part of the Device Type entry), but five different index numbers (the second part of the Device Type entry).

The first number indexes into the list of available button maps for that remote. The second number inedexes into the list of available device types for that remote. In many remotes, the two lists are indexed the same, so only the first number is required. However, the Outlaw, and several others, have differing separate lists of button maps and device types, hence both numbers are required.

ricara wrote:

Because it is just an index number, there is no way to tell what type of device it refers to (i.e., in one remote, 0 might be cable devices, while in another, 0 might be TV devices). This is where thae aliases come in. The alias definitions in the RDF tell us what type of device belongs in each device type for that particular remote.

I'm mostly following you, but now I have a different question. If the Setup Codes used by UEI are unique, why bother to have different Device Types at all?

<swag>Back when they set all this up, there were a lot fewer device types to contend with, so they probably intended to keep each device type separate and reuse the setup numbers. History shows that they had to alter their thinking along the way.</swag>

ricara wrote:I had originally thought that it might save memory to use a Device Type with fewer buttons, so it would only make sense to use the Device Type with the smallest memory "footprint". But when I tried writing upgrades in RM and then seeing how much memory was used in IR, it didn't make any difference whether I used a Device Type with a lot of buttons or a Device Type with only a few buttons. (This experiment was done with a "small" upgrade that didn't require any key moves. If key moves were required in the Audio mode, then OEM mode used less memory as there were no key moves required.) Of course, maybe I just did the experiment wrong....

The button map used by a device type only defines which buttons may be included in an upgrade/setup code. It only uses memory when you actually assign a code to a button. (Without getting too specific, approximately one bit and one byte per button, more or less.) There are exceptions to this for the number keys, volume keys and channel keys. For example, if you assign a code to one number key, the upgrade must provide a code for all ten number keys (KM defaults to 0 if you don't assign a code), unless all ten codes happen to coincide with one of the digit-key-maps built into the remote (but you didn't want to know about that just yet, did you?).