JP1 Remotes

As the various Atlas 5-device remotes have come into service and their support has evolved, we have accrued a number of different rdfs which are difficult to keep track of, especially when trying to select the correct one from a drop-down list in IR or RM. Some say DVR-PVR, some say only PVR, some reverse the order of "5-Device" and "DVR-PVR", yet others have underscores or backslashes that may confuse certain applicataions. The NEWER rdfs seem to show some consistency, but the older ones may still confuse the user. Might I suggest a global renaming of them to result in their sequencing and displayed names in such lists to be in a readily-distinguishable order. To this end, I'd suggest the following nomenclature: Then as extenders come on line, hopefully the extender creators would simply replace the 0 in the second position with the Rev of the extender (A, B, etc.).

Additionally, the problem identified several weeks ago in which in some circumstances, UNDERSCORES were being inserted into downloaded rdf names instead of spaces, and those underscores affecting rdf recognition in RM, I suggest that a note be appended to the rdf.zip distribution for folks to check for unintended insertion of underscores.

I'd sure like to see it simplified, however I'd like to see the sticker number be part of the name. It should be something the end user can identify.

Atlas 5 1054 JP1
Atlas 5 DAY 1055 JP1.2
Atlas 5 DAY 1055BC1 JP1.3
Atlas 5 DAY 1055BC2 JP1.3
Atlas 5 Day 1056 JP1.3
Atlas 5 Opac 1056 JP1.3

But I'll bet not all the JP1.3 1055's have BC1 for the 3000 and BC2 for 3032. The signature is already part of the remote name, so that may be a bit redundant. Those long names absolutely kill me.

vickyg2003 wrote:I'd sure like to see it simplified, however I'd like to see the sticker number be part of the name. It should be something the end user can identify.

Atlas 5 1054 JP1
Atlas 5 DAY 1055 JP1.2
Atlas 5 DAY 1055BC1 JP1.3
Atlas 5 DAY 1055BC2 JP1.3
Atlas 5 Day 1056 JP1.3
Atlas 5 Opac 1056 JP1.3

But I'll bet not all the JP1.3 1055's have BC1 for the 3000 and BC2 for 3032. The signature is already part of the remote name, so that may be a bit redundant. Those long names absolutely kill me.

To my knowledge, there is no such remote as the one I bolded. There is an Atlas 5 DAY 1055 JP1.3. All 1056's are OCAPs.

vickyg2003 wrote:I'd sure like to see it simplified, however I'd like to see the sticker number be part of the name. It should be something the end user can identify.

Atlas 5 1054 JP1
Atlas 5 DAY 1055 JP1.2
Atlas 5 DAY 1055BC1 JP1.3
Atlas 5 DAY 1055BC2 JP1.3
Atlas 5 Day 1056 JP1.3
Atlas 5 Opac 1056 JP1.3

But I'll bet not all the JP1.3 1055's have BC1 for the 3000 and BC2 for 3032. The signature is already part of the remote name, so that may be a bit redundant. Those long names absolutely kill me.

I've been looking at this nomenclature business, and have been (due to having a small sample set) unable to confirm that the names you propose for the URC-1055s can be uniquely married to a particular rdf.

For example, my JP1.2 10251025 is labelled URC-1055BC0. Are they all so labelled?
My 30003000 (a learner) is labelled URC-11055BA1 (yes that is a double "1" at the beginning) which apparently differs from the URC-1055BC1 you have seen.

My OCAP 1056s have (unlike the other Atlases) a silkscreened label URC-1056B01 but the battery compartment sticker says URC-1056BG0;

whilst the 1056BCs (Silver) are silkscreened URC-1056B01-L and have a battery compartment label URC-1056BC1. I imagine that the "L" reflects the learning capability.

Now there is only one JP1.2 version (the 10251025), but the three JP1.3 variants seemingly have many more battery compartment labels than that.

So barring confirmation of unique identification via the battery compartment stickers, I don't see how we can go that route in RDF nomenclature. How about this (hopefully) simplified scheme?

The JP1.3 Atlas remotes that I have are as follows:

Battery/Model/Signature/Description

1055BA1/URC-1055/30003000/Black, 5-device with Day
1056BG1/URC-1056/30333033/Black,5-Device, with Day, OCAP
1056BC1/URC-1056/30333033/Silver,5-device, with Day, OCAP, learning
1055BC2/URC-1055/30333033/Black,5-device with day


What's interesting about these is that the "software" in all of the 30333033 remotes is identical except for the data in the setup area, advance code area, private area and upgrade area, so from an IR standpoint we should be able to treat them all the same.

As someone who is trying to write an extender for these remotes, this situation is really confusing. I've almost come to the conclusion that the extender during activation has to check the remote to make sure it's the right one and then refuse to activate if it's not.


-bill

How about my Time Warner "Day" with learning 11055BC0? Where do they fit in this scheme?
Labelled "JP1", sig 10251025...

So far, from the limited samples reported, here are my conclusions:

There is only one variant of the 1054 so anything after the 1054 is immaterial - all JP1 sig SA_7SA_7 - nothing to distinguish in RDFs.

There is only one variant each of the 1056 (black) and 1056BC (silver) - all JP1.3 sig 30333033, so there is no need to distinguish anything in the RDFs.

The 1055 has FOUR RDF variants - one would HOPE that they have distinguishing labels of some sort - but they do NOT:
JP1.2 10251025 - appears to be BC0
JP1.3 30003000 - appears to be BC1 or BA1
JP1.3 30323032 - appears to be BC2
JP1.3 30333033 - appears to ALSO be BC2

(the learning variants, which doesn't affect the RDF, appear to have an extra "1" in front of the 1055 (11055) on the sticker label)

I think the RDF naming I have adopted in the zip file above is about as simple as we're gonna get.

SA_7SA_7 (Atlas 5 URC-1054).rdf
SA_71Kx1 (Atlas 5 URC-1054 1K Extender 1).rdf
10251025 (Atlas 5 Day URC-1055 JP1.2).rdf
1A251A25 (Atlas 5 Day URC-1055 JP1.2 Ext A).rdf
30003000 (Atlas 5 Day URC-1055 JP1.3 3000).rdf
30323032 (Atlas 5 Day URC-1055 JP1.3 3032).rdf
30333033 (Atlas 5 Day URC-1055 JP1.3 3033).rdf
30333033 (Atlas OCAP URC-1056 JP1.3 (Black)_(Silver)).rdf

Cap'n

The only add that I'd put on this after having looked at a lot of the JP1.3 Atlas remotes now is that you need to include your 11055 in the definition that you use for the 1055 Signature 30003000.

The only differences are (1) learning and (2) the default stuff loaded into the E2 area (macros, private data and default installed devices). Other than that, the remotes are the same and IR really won't be able to tell them apart.


BTW, I'm using the "0" digit on all of th extenders for the Atlas families (ie: 3A333A33) as requested.


-bill

Just so that I understand what you are suggesting, you are recommending modifying the filenames of the applicable rdfs primarily for CLARITY for those with learning remotes that have the extra "1" before the model number on the battery compartment label, is that correct?

Such that (e.g.):
30003000 (Atlas 5 Day URC-1055 JP1.3 3000).rdf

would become:
30003000 (Atlas 5 Day URC-1055_11055 JP1.3 3000).rdf

I am happy to do so, and barring any comments to the contrary, will modify the rdf's in my add-on zip file after a few days of silence. Hopefully John will add them to the next RDF.zip distro.

The Capn

P.S. I didn't start the "replace the "0" with the rev letter of extender" thing - blame vickyg!

yes, that is what I'm suggesting.

Is the 30003000 the only 1055 that we have seen with this 11055 variant? I've NOT heard of it on the 1054 (unlikely to have a learning variant of a 1K EEPROM remote), nor do my learning 1056's have that usage (i.e. no "11056"), but do the 30323032 and 30333033 1055's also distinguish their learning variants with the extra leading 1?

It's easy enough to make the change to all three rdfs but then the drop-down list of Atlas RDFs in RM becomes pretty darned lengthy.

P.S. I didn't start the "replace the "0" with the rev letter of extender" thing - blame vickyg

Blame UEI for putting the checksum after the signature, requiring a signature that had a zero checksum! I just started replacing the 0's with a letter because that was the easiest way to get a zero checksum signature and still have it preserve the significant digits. 30's were all Jp1.3 and 10's were all JP1.2...... I suppose we could have had Binky modifiy IR's checksum calculation now that I'm thinking more clearly.

I have 11055 with a 10251025 signature...

speaker.guy wrote:I have 11055 with a 10251025 signature...

Is it a learner?

Updated zip of renamed Atlas RDFs. Addresses difference between 1055 and 11055 variants, and adds vickyg's modified 1A25 extender RDF as well as beta extender RDFs for 3000 and 3033 1055's and 1056 OCAP remote. Also packaged 1056 OCAP maps and images.

Use the 3000 and 3033 extender RDFs at your own risk.