JP1 Remotes

Okay, so for things like 'HT' I don't think it hurts to just alias it as 'OEM Mode' for completeness? So how about the dispositions below:


10621062 (URC-7780 One For All Stealth 12).rdf
NO ALIAS LIST HT
[Alias to OEM Mode]


11311131 (URC-7781 One For All Digital 12).rdf
NO ALIAS LIST HT
[Alias to OEM Mode]

1A251A25 (Atlas 5 Day URC-1055 JP1.2 Ext A7).rdf
NO ALIAS LIST VCR
[Alias to VCR]

30323032 (Atlas 5 Day URC-1055_11055 JP1.3 3032).rdf
NO ALIAS LIST VCR
[Alias to VCR]

30333033 (Atlas 5 Day URC-1055_11055 JP1.3 3033).rdf
NO ALIAS LIST VCR
[Alias to VCR]

3A003A00 (Atlas 5 Day URC-1055 JP1.3 3000 extender).rdf
NO ALIAS LIST VCR
[Alias to VCR]

3A333A33 (Atlas 5 Day URC-1055 JP1.3 3033 extender).rdf
NO ALIAS LIST VCR
[Alias to VCR]

98009800 (URC-9800 Learning Chip).rdf
NO ALIAS LIST TUNER
[Alias to Tuner]

EBV0EBV0 (URC-7550_7560-B00 One for All).rdf
NO ALIAS LIST DevType4
NO ALIAS LIST DevType5
[Alias to OEM Mode]

EBV0EBV1 (URC-7550_7552_7560_7562 One for All).rdf
NO ALIAS LIST DevType4
NO ALIAS LIST DevType5
[Alias to OEM Mode]

EBX0EBV0 (URC-7560_7562 Extender).rdf
NO ALIAS LIST DevType4
NO ALIAS LIST DevType5
NO ALIAS LIST Special
[Alias to OEM Mode]

ET80ET80 (URC-8550_5550 Topline Extender v2).rdf
NO ALIAS LIST @AMP
NO ALIAS LIST @TUNER
[Pending answer to mathdon's question]

ET80ET80 (URC-8550_5550 Topline Extender).rdf
NO ALIAS LIST @AMP
NO ALIAS LIST @TUNER
[Pending answer to mathdon's question]

ETPSTPS0 (Force - 2k version).rdf
NO ALIAS LIST xDev
[Alias to OEM Mode]

GI97GI97 (Maestro II).rdf
NO ALIAS LIST MUSIC_CH
[Alias to TUNER? OEM Mode?]

HT80HT80 (URC-8080_8090-B00 Producer 8).rdf
NO ALIAS LIST TUNER
[Alias to Tuner]

HT80HT8A (URC-8080_8090-B01 Producer 8).rdf
NO ALIAS LIST TUNER
[Alias to Tuner]

HT80HT8C (URC-8080_8090-B02 Producer 8).rdf
NO ALIAS LIST TUNER
[Alias to Tuner]

HT80HT8C (URC-8080_8090-B02 with Time and Extender Support).rdf
NO ALIAS LIST TUNER
[Alias to Tuner]

HUD0HUD0 (URC-9800_8800_8780 Producer 8 with Extender V1).rdf
NO ALIAS LIST TUNER
[Alias to Tuner]

HUD0HUD0 (URC-9800_8800_8780 Producer 8 with Extender V2).rdf
NO ALIAS LIST TUNER
[Alias to Tuner]

HUD0HUD0 (URC-9800_8800_8780 Producer 8).rdf
NO ALIAS LIST TUNER
[Alias to Tuner]

KASAKAS0 (URC-9960 B01 One For All Kameleon).rdf
NO ALIAS LIST other
[Alias to OEM Mode]

KASAKASX (URC-9960 B01 One For All Kameleon Extender).RDF
NO ALIAS LIST other
[Alias to OEM Mode]

LF32LAT0 (URC-7650 One for All 5).rdf
NO ALIAS LIST DevType4
NO ALIAS LIST DevType5
[Alias to OEM Mode]

OEM3OEM (ReplayTV Version1).rdf
NO ALIAS LIST OEM_Mode
[Alias to OEM Mode]

OEM3OEM (ReplayTV Version2).rdf
NO ALIAS LIST OEM_Mode
[Alias to OEM_Mode]

OEM8OEM0 (Kenwood VR507).rdf
NO ALIAS LIST OEM
[Alias to OEM Mode]

OUKAOUK1 (Dreambox V3 URC-39730 B02).rdf
NO ALIAS LIST OEM
[Alias to OEM Mode]

RS70RS70 (RS 15-1995 7 in 1 wTime & Extender Support).rdf
NO ALIAS LIST TUNER
NO ALIAS LIST DVD
[Alias to Tuner/DVD]

RS70RS70 (RS 15-1995 7-in-1 with More Memory).rdf
NO ALIAS LIST TUNER
NO ALIAS LIST DVD
[Alias to Tuner/DVD]

RS70RS70 (RS 15-1995 7-in-1).rdf
NO ALIAS LIST TUNER
NO ALIAS LIST DVD
[Alias to Tuner/DVD]

SAKAS0 (URC-9960 BJ5 One For All Kameleon).rdf
NO ALIAS LIST other
[Alias to Oem Mode]

NON STANDARD ALIASES


11421142 (URC-8308 Kameleon).rdf
OEM mode
[Fix capitalization]

30653065 (URC-1060).rdf
Misc AUdio
[Fix capitalization (does it really matter? or should Vicky's checking be loosened?]

31793179 (RCA RCRP05B black).rdf
DVR
[Change to PVR]

BAL0BAL0 (Balboa Dolphin).rdf
OEM
[Changed to OEM Mode]

EZP0EZP0 (URC-6540_6541 1K Version).rdf

OEM
[Change to OEM Mode]

OEM4OEM0 (Arcam CR80).rdf
AUX
AMP
[Fix capitalization]

OEM4OEM0 (Zap Station).rdf
AUX1
AUX2
AMP
[Change first two to OEM Mode, fix capitalization]

RS00RS00 (RS 15-1935_1934 7-in-1).rdf
Home auto
[Fix capitalization]

STANDARD ALIASES

TV
Cable
SAT
Video Acc
VCR
DVD
Tape
Laserdisc
DAT
CD
Tuner
Home Auto
Misc Audio
Phono
Amp
PVR
OEM Mode[/quote]

Misc AUdio
[Fix capitalization (does it really matter? or should Vicky's checking be loosened?]

I believe it just comes up with a message to pick from the list, so its not a crashing error. I just thought it looked better if we standardized the capitalization, but Greg handles that in his programming.

1A251A25 (Atlas 5 Day URC-1055 JP1.2 Ext A7).rdf
NO ALIAS LIST VCR
[Alias to VCR]

I built my RDF off the 1025 RDF that got fixed when it made RM crash, but I didn't catch when they closed. That's the same error that was making unclemilties extender crash IR. That's why I submit my RDF's to the RDF Librarian.

I don't really understand RDF's and how they impact RM or RMIR.

Here's a quick description of why the [DeviceTypeAliases] section exists.

The [DeviceTypeAliases] section of the RDF interacts with the [DeviveTypes] section, and is used primarily when changing an upgrade from one remote to another. Consider the following:
You download an upgrade from the files section for a DVD player. The person who created the file set the upgrade for a 15-1994 remote. You load the upgrade into RM, and want to change the remote to a URC-8810. Internally, RM has to create the upgrade using the Device Type number, since the remote itself has no idea what a DVD player is. The 15-1994 uses Device Type 2 for DVD devices. The URC-8810 uses Device Type 1 for DVD devices. How does RM know to change the Device Type number when you change the remote to the URC-8810? RM knows that this is a DVD upgrade, so it searches the URC-8810 RDF [DeviceTypeAliases] section until it finds "DVD" in the entries on the right of the equals sign. In this case, it will find it in the entry for "VCR/DVD": Then, RM searches the [DeviceTypes] section for "VCR/DVD", and finds this entry: Now RM knows to assign Device Type 1 to the upgrade.

I doubt that many RDF authors pay much attention to the [DeviceTypeAliases] section unless it causes RM problems. Even then, as Vicky points out, there is a lack of understanding regarding its function, so it is not surprising that Vicky's tool has found so many discrepancies.

This does seem like an appropriate place to play the RTFM card. Here is what the RDF specs say:

The [DeviceTypeAliases] section assigns each of the standard JP1 device categories to a particular device type in the remote. Each of the device types specified in the [DeviceTypes] section should also be listed in this section. This information is used by RM and other programs to make automatic device type translations across different remotes. For example, if a user creates a PVR upgrade for a 15-1994, and then another user changes the upgrade to a different remote, this data determines which device type will be assigned.
Each of the 16 standard JP1 device categories should be assigned to a device type in this section. If the remote has an OEM mode, the OEM Mode standard category should also be assigned.
The list of standard JP1 device categories is:
Cable, TV, VCR, CD, Tuner, DVD, SAT, Tape, Laserdisc, DAT, Home Auto, Misc Audio, Phono, Video Acc, Amp, PVR, OEM Mode (where applicable)

Some further points:

1) The 16 standard device categories were made up by the JP1 community, and have nothing to do with UEI.

2) While the RDF specs say that each category must be assigned to a device type, they do not mention that each category must only be assigned once. So, for example, "DVD" should not appear twice in the section.

3) I don't think upper/lower case is significant, at least as far as the original intent is concerned. But it would probably be wise to enforce it now, since JP1 tools are beginning to spread to non-Win platforms more often.

2) While the RDF specs say that each category must be assigned to a device type, they do not mention that each category must only be assigned once. So, for example, "DVD" should not appear twice in the section.

Oh, I didn't check for that. If I understand what you are saying, I believe I have one RDF that fails that test.


30333033 (Atlas OCAP URC-1056 JP1.3 (Black)_(Silver)).rdf
[DeviceTypeAliases]
Cable = Cable,SAT,Video Acc
TV = TV
DVD = VCR,DVD,Tape,Laserdisc,DAT
CD/Audio = CD,Tuner,Home Auto,Misc Audio,Phono,Amp
VCR = VCR

but it appears that for the most part that is not a problem.

Thanks Mike.

Do you think assigning 'OEM Mode' for devices that are not expected to be portable makes sense? Aka HT, other etc?

What is the significance (if any) of the '@' character?

Finally, why is it important that the type only be assigned once?

Thanks,
xnappo

xnappo wrote:Do you think assigning 'OEM Mode' for devices that are not expected to be portable makes sense? Aka HT, other etc?

The 'OEM Mode' that is part of the standard JP1 categories harkens back to some of the earlier remotes, like the ReplayTV & Sony Tivo, that had an extra device type for the OEM to use. I'm not sure if it makes sense to include HT in any of this, as it is not a device type.

xnappo wrote:What is the significance (if any) of the '@' character?

You've got me. It's not a standard syntax for RDF files. Maybe the RDF author was confused between device types and device buttons. In theory, there should not be two device types with the same name within any given remote, so 'TUNER' and '@TUNER' can't be the same device type.

xnappo wrote:Finally, why is it important that the type only be assigned once?

It's not the end of the world, but anything other than the first occurrence would be ignored. So, in Vicky's example above, if RM were looking to find the device type of a VCR upgrade, it would always find:and use the 'DVD' device type. It would never find the second VCR = VCR entry. (This is hypothetical; I don't know exactly how RM parses the RDF file, so maybe the last occurrence predominates. In any case, the double entry could lead to differing results depending on the parsing method used.)

mr_d_p_gumby wrote:

xnappo wrote:What is the significance (if any) of the '@' character?

You've got me. It's not a standard syntax for RDF files. Maybe the RDF author was confused between device types and device buttons. In theory, there should not be two device types with the same name within any given remote, so 'TUNER' and '@TUNER' can't be the same device type.

This is related to my earlier question. The [DeviceTypes] section of the URC-8550/5550 extender RDFs is
The unextended one is similar except that the @ signs are missing, so there are two AMP and two TUNER entries (the difference is not significant, it is because I worked on the unextended RDF and in doing so, deleted the @ signs.) I don't think the @ signs are significant, though. I think they just mark entries relevant to the URC-8550 but not to the URC-5550 as the RDF covers both remotes.

Here is the real issue: if you put in the default DevTypeNum entries where that field is blank, you get
The pairs have the same map (figure before the comma) and device type index (2nd byte after the comma) but differ in the 1st byte after the comma. The RDF Spec says:

If a TypeAddr is specified in the [DeviceButtons] section, then DevTypeNum is a 16-bit number where the high-order byte contains the value to be placed at the address specified by TypeAddr when a device of that type is chosen. If TypeAddr is not specified, then only the low-order byte is significant.

Fine, so the two entries in each pair differ only in that they put different values at the TypeAddr address. The values related to the normal functionality of a Device Type, i.e. the map number and device type index, are the same.

It doesn't look to me as if this is an error on behalf of the RDF writer. It looks deliberate. But what is the significance of the value held at the TypeAddr address???

I think I've got it. The values that are put into TypeAddr correspond to a grouping of devices, and by default, group X is assigned to the button with index X. A whole group can be copied to another button if required.

I've only deduced this from the URC-8550 instruction book, but what is given there does tally exactly with the [DeviceTypes] entry. The @AMP key (button index 4) is initially assigned group 4, which contains only the @AMP device type and the @TUNER key (button index 5) is assigned group 5, which contains only the @TUNER device type. However, the AUX1 key (button index 6) is initially assigned group 6, which contains the MISC_AUDIO, AMP, TUNER and HOME_CT device types. So AMP and TUNER occur in two groups, corresponding to their occurring twice in the [DeviceTypes] section.

The URC-5550 doesn't have either the buttons or the device types marked with @, so the AMP and TUNER device types would occur only once if a separate RDF were produced for it, and they would be available only in group 6, i.e. in the default setting, only on the AUX1 button (which in fact is labelled AUD on the actual URC-5550 remote).

I don't know what the effect of all this on the [DeviceTypeAliases] section should be. I can't really see any alternative than to have the aliases Amp and Tuner appear twice, against both the AMP and TUNER and also the @AMP and @TUNER device type names.

I think the @ symbols in the URC-8550/5550 RDF are my fault. I put them in there because, as the two remotes share the same RDF, they show which device modes are "phantom" in the URC-5550 (but real in the URC-8550).

I have been following the threads on the new Maps, Images and RDF distribution process but have not had much to contribute. I did however want to complement you folks and what appears to be a promising improvement over the way I did it.

Nice work

mathdon wrote:I don't know what the effect of all this on the [DeviceTypeAliases] section should be. I can't really see any alternative than to have the aliases Amp and Tuner appear twice, against both the AMP and TUNER and also the @AMP and @TUNER device type names.

I agree; in this case there does not seem to be any alternative. However, when you create an AMP or TUNER upgrade, RM can choose only one of the two. It may not matter because the upgrade will only use the lower byte, and that is the same for both sets of entries.

BTW, I noticed that the lack of any setup codes for type 9 tripped up my utility. If you are adding the setup codes to the RDF, you need to tack this at the end.

Okay guys,

I am going to try to summarize what I need to do the next release.

I made the mistake of moving stuff from development to SourceForge prematurely. So right now there is not a zip with some of the new RDFs nor are they in the development area - so please help me to resolve:

1. What should the alias be for HT? Just ignore it? I still think adding them as 'OEM Mode' does not hurt anything.

2. For RDFs with @Tuner etc - should I leave them or change them to remove the @? Can anyone confirm RM-IR is okay with the @?

3. For 'strange' device types (other,dev5, etc) is it okay to use OEM Mode? Basically anything that doesn't fit into a nice bucket gets OEM Mode

Thank you!
xnappo

Mike England has explained the purpose and meaning of the device type aliases.

It's only meaningful in the context of mapping the device type alias associated with a device upgrade to a remote specific device type. That's it.

What would it mean to create a device upgrade for the HT device? Is that even possible? Isn't the HT device actually a mash up of multiple devices?

RM/RMIR does not care about the @sign. I don't understand what these extra @device types are, and how anybody would use them, or if any changes are needed to IR/RMIR to make use of them.

Maybe the best thing to do is change RM/RMIR to remove the requirement that every device type has an entry in the device type aliases section. That requirement may be the result of the way I wrote the code, rather than a functional requirement. That would leave only the requirement that all of the standard aliases are listed exactly once (except for the special ones like OEM Mode, which are only required on remotes that support them).

xnappo wrote:1. What should the alias be for HT? Just ignore it? I still think adding them as 'OEM Mode' does not hurt anything.

HT is not a device mode, so it shouldn't be in these lists to begin with. Do you have examples where someone's added it to one of these lists? If so, let's look at them, but my guess is that it should be removed.

xnappo wrote:2. For RDFs with @Tuner etc - should I leave them or change them to remove the @? Can anyone confirm RM-IR is okay with the @?

It took some major re-reading of the RDF spec and checking out how upgrades work in the MITS remotes to know how to answer this, but I can see now what's going on.

Here's some background as to how the MITS remotes work (ie, remotes like the URC-8550, URC-9800, etc). Each device button has a master mode and this master mode can include several sub-modes. Looking at the URC-8550, it has the following master modes and sub-modes:

Master Group 0 (SAT): SAT, VID_ACC, CABLE
Master Group 1 (TV): TV
Master Group 2 (VCR): VCR
Master Group 3 (CD): CD, PHONO,
Master Group 6 (AMP): AMP, TUNER, MISC_AUDIO
Master Group 7 (AUX2): LASER, DVD, TAPE, DAT

So, if you want to program a DVD code to the CD button (for example), you would first have to do a MODE MAP to map the AUX2 button onto the CD button, and then you could select DVD as a device type.

In IR.exe, when you assign a setup code to a device button, in addition to storing the hex for the setup code in the right buckets, it also needs to set the correct master mode.

In the RDF, each device mode needs 3 pieces of information. It needs to know which button map to use (eg, DAT uses map 6), it needs to know the code for the sub-mode (eg, DAT = "E") and it needs to know the code for the master mode (eg, DAT = "7"). So the [DeviceTypes] entry for DAT will be:

DAT = 6, $070E

Back to the question of the [DeviceTypes] list for the URC-8550, I have reviewed the data in it and I think the following replacement list should work:

xnappo wrote:3. For 'strange' device types (other,dev5, etc) is it okay to use OEM Mode? Basically anything that doesn't fit into a nice bucket gets OEM Mode

Sure, I think that would work.

Thanks very much Rob! Especially for the detailed explanation and research on point 2.

The RDFs with HT as a device type are:
10621062 (URC-7780 One For All Stealth 12).rdf
11311131 (URC-7781 One For All Digital 12).rdf

Thanks,
xnappo